From huizhe.wang at oracle.com Thu Sep 1 00:34:21 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Aug 2016 17:34:21 -0700 Subject: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message In-Reply-To: <04b25177-a4d6-d53c-d1c3-e49db89f78ca@oracle.com> References: <57C704E5.6010202@oracle.com> <94b5af5b-f645-70c3-cfa3-0895076ccd8c@oracle.com> <57C7245D.5080008@oracle.com> <57C7444F.7020304@oracle.com> <04b25177-a4d6-d53c-d1c3-e49db89f78ca@oracle.com> Message-ID: <57C7778D.2020205@oracle.com> Hi Aleksej, Yes, the change looks good with the System Property and StreamSource. As we discussed, apparently the processor won't issue warnings in other cases (with SAXSource). Thanks for being patient with me, going back and forth with test runs. Cheers, Joe On 8/31/16, 2:58 PM, Aleks Efimov wrote: > On 31/08/16 23:55, Joe Wang wrote: >> >> >> On 8/31/16, 12:08 PM, Aleks Efimov wrote: >>> Joe, >>> >>> (answers in-lined) >>> >>> >>> On 31/08/16 21:39, Joe Wang wrote: >>>> >>>> >>>> On 8/31/16, 10:51 AM, Aleks Efimov wrote: >>>>> Hi Joe, >>>>> >>>>> Thank you for reviewing the changes. I found one more >>>>> inconsistency with these tests: >>>>> >>>>> The TestSAXDriver class is not compiled by default now and because >>>>> of that the default SAX driver were used and the original issue >>>>> was not reproduced properly. New webrev can be found here: >>>>> >>>>> http://cr.openjdk.java.net/~aefimov/8150145/01 >>>>> >>>>> About intermittent failure: The test was added with 'othervm' >>>>> initially, but few months ago the transformation test was failing >>>>> due to concurrency issue in PackageEntry::package_exports_do ( >>>>> JDK-8152404). Now failures are not reproducible with latest JDK9 >>>>> builds and latest version of the tests. >>>> >>>> Did you mean it was later changed to othervm? The initial check-in >>>> record shows it wasn't [1] >>> >>> Yes, you're right - it was added without othervm initially. I was >>> looking at the different changeset *sigh*... >> >> Our memories can elude us, esp. after playing with it so many times :-) >>> >>>> >>>> othervm provents the potential interference by other tests that >>>> also set the system property, and therefore removes the need for a >>>> further refactoring of the code. So this is not required, but you >>>> may remove the SAX driver setting and use a new instance instead, e.g. >>>> SAXSource saxSource = new SAXSource(new TestSAXDriver(), new >>>> InputSource(new StringReader(xml))); >>> Thanks for the suggestion. Even with all sources changed to >>> SAXSource() and with explicitly specified TestSAXDriver the warning >>> generated by Validation test can't be reproduced. Hopefully, it is >>> ok to leave "org.xml.sax.driver" property setup in-place. >> >> It's okay now it's running in othervm. I was saying that the system >> property might have been the cause for the intermittent failure. I'm >> not sure I understand what you meant that the Validation test can't >> be reproduced. Did you mean no warning was generated or not more than >> 1 warning generated? > Ok, agree that without the othervm the system property might have been > the cause of the intermittent failures. > By "Validation test can't be reproduced" I meant that 0 warnings were > generated during ValidationWarningsTest run when the property setting > was removed and all sources were replaced with > "new SAXSource(new TestSAXDriver() ..." > >> >> Thanks, >> Joe >> >>> >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/6aa83d55614a/test/javax/xml/jaxp/unittest/common/TransformationWarningsTest.java >>>> >>>> Thanks, >>>> Joe >>>>> >>>>> -Aleksej >>>>> >>>>> >>>>> On 31/08/16 19:25, Joe Wang wrote: >>>>>> Hi Aleksej, >>>>>> >>>>>> It's good to put the tests back online. Thanks for the diligent >>>>>> work! I believe the change that made the tests run in othervm >>>>>> could have fixed the intermittent issue. But adding debugging >>>>>> code can always be helpful in case of failures. >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> On 8/30/16, 12:01 PM, Aleks Efimov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please, help to review the tests fix. >>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 >>>>>>> >>>>>>> The list of changes: >>>>>>> 1. Two tests were modified to print exception occurred during >>>>>>> execution. Before that these tests were failing silently. >>>>>>> 2. The tests were slightly modified to correctly run with >>>>>>> security manager run mode recently added to JAXP tests >>>>>>> (JDK-8067170). >>>>>>> 3. TransformationWarningsTest were modified to synchronize the >>>>>>> TransformerFactory instantiation. >>>>>>> >>>>>>> The modified tests were executed 2000+ times (alongside to other >>>>>>> tests from jaxp/test/javax/xml/jaxp/unittest/common) on >>>>>>> linux-x64 and there were no failures observed. According to this >>>>>>> result and that the tests were modified not to fail silently. I >>>>>>> would like to remove these two tests from the jaxp problem list. >>>>>>> If the tests will continue to fail on some configurations (JPRT >>>>>>> shows no failures for few runs though) the proposed changes will >>>>>>> help to diagnose the cause of failures. >>>>>>> >>>>>>> With Best Regards, >>>>>>> Aleksej >>>>>>> >>>>> >>> > From martinrb at google.com Thu Sep 1 01:32:47 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 31 Aug 2016 18:32:47 -0700 Subject: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain In-Reply-To: <25B397A7-4FDB-4471-BE59-3BEC93655A31@oracle.com> References: <547E7223-1234-4B7E-9F44-CB82F1602681@oracle.com> <0D1FBA33-5E00-4B01-AE13-66FE3376EBEB@oracle.com> <3F2EECFB-220F-4757-B6FB-9197796B94D4@oracle.com> <76d8e2fe-d29f-d5b0-4460-580fc461ee70@cs.oswego.edu> <25B397A7-4FDB-4471-BE59-3BEC93655A31@oracle.com> Message-ID: I'll try not to complain about this again. It was pointed out to me that users of off-heap VarHandles will usually want the Plain variety. java.util.concurrent will hopefully not be the only users! From martinrb at google.com Thu Sep 1 01:55:33 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 31 Aug 2016 18:55:33 -0700 Subject: RFR: JDK-8161360, , Deprecated vfork() should not be used on Solaris In-Reply-To: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> Message-ID: Does an attempt to use vfork on Solaris result in something reasonable like UnsupportedOperationException? On Wed, Aug 31, 2016 at 4:55 AM, Alan Burlison wrote: > vfork(2) is deprecated on Solaris and using it generates compiler > warnings. When compiled with warnings-as-errors, this results in > compilation failures. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161360 > Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8161360 > > Thanks, > > -- > Alan Burlison > -- > From david.holmes at oracle.com Thu Sep 1 07:33:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Sep 2016 17:33:58 +1000 Subject: RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c In-Reply-To: References: Message-ID: <85a336ff-1ce0-ee08-9366-d132a25dc85a@oracle.com> On 1/09/2016 5:51 AM, Henry Jen wrote: > Hi, > > Please review a trivial fix for 8081388, in a nutshell, > > - Return NULL from NewPlatformStringArray if an exception occurred > - All other places call this function already handled return value NULL > - Launcher handles exception in JavaMain, report error and exit. > > Cheers, > Henry > > diff --git a/src/java.base/share/native/libjli/java.c b/src/java.base/share/native/libjli/java.c > --- a/src/java.base/share/native/libjli/java.c > +++ b/src/java.base/share/native/libjli/java.c > @@ -1497,6 +1497,7 @@ > > NULL_CHECK0(cls = FindBootStrapClass(env, "java/lang/String")); > NULL_CHECK0(ary = (*env)->NewObjectArray(env, strc, cls, 0)); > + CHECK_EXCEPTION_RETURN_VALUE(0); You will only get a NULL if an exception is pending; conversely you will only have an exception pending if the return value is NULL. The new check will never execute in a "positive way" and is unnecessary. David ----- > for (i = 0; i < strc; i++) { > jstring str = NewPlatformString(env, *strv++); > NULL_CHECK0(str); > diff --git a/src/java.base/share/native/libjli/java.h b/src/java.base/share/native/libjli/java.h > --- a/src/java.base/share/native/libjli/java.h > +++ b/src/java.base/share/native/libjli/java.h > @@ -253,6 +253,13 @@ > #define NULL_CHECK(NC_check_pointer) \ > NULL_CHECK_RETURN_VALUE(NC_check_pointer, ) > > +#define CHECK_EXCEPTION_RETURN_VALUE(CER_value) \ > + do { \ > + if ((*env)->ExceptionOccurred(env)) { \ > + return CER_value; \ > + } \ > + } while (JNI_FALSE) > + > #define CHECK_EXCEPTION_RETURN() \ > do { \ > if ((*env)->ExceptionOccurred(env)) { \ > From Alan.Burlison at oracle.com Thu Sep 1 12:45:08 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 1 Sep 2016 13:45:08 +0100 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris In-Reply-To: References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> Message-ID: <479ebc00-3f86-cd2f-bfcb-5271df777e6e@oracle.com> On 01/09/2016 02:55, Martin Buchholz wrote: > Does an attempt to use vfork on Solaris result in something reasonable like > UnsupportedOperationException? Yes: $ jshell | Welcome to JShell -- Version 9-internal | For an introduction type: /help intro jshell> System.setProperty("jdk.lang.Process.launchMechanism", "VFORK") $1 ==> null jshell> Runtime.getRuntime().exec("ls"); | java.lang.Error thrown: VFORK is not a supported process launch mechanism on this platform. | at ProcessImpl$Platform.lambda$launchMechanism$0 (ProcessImpl.java:151) | at AccessController.doPrivileged (Native Method) | at ProcessImpl$Platform.launchMechanism (ProcessImpl.java:134) | at ProcessImpl. (ProcessImpl.java:174) | at ProcessBuilder.start (ProcessBuilder.java:1107) | at ProcessBuilder.start (ProcessBuilder.java:1071) | at Runtime.exec (Runtime.java:635) | at Runtime.exec (Runtime.java:459) | at Runtime.exec (Runtime.java:356) | at (#2:1) jshell> -- Alan Burlison -- From dmitry.samersoff at oracle.com Thu Sep 1 13:30:35 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 1 Sep 2016 16:30:35 +0300 Subject: RFR: JDK-8161360, , Deprecated vfork() should not be used on Solaris In-Reply-To: References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> Message-ID: Martin, Valid launch mechanisms for Solaris set in ProcessImpl.java as: SOLARIS(LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), So it's not possible to set VFORK as LaunchMechanism for Solaris. and this fix doesn't change anything from customer perspective. -Dmitry On 2016-09-01 04:55, Martin Buchholz wrote: > Does an attempt to use vfork on Solaris result in something reasonable like > UnsupportedOperationException? > > On Wed, Aug 31, 2016 at 4:55 AM, Alan Burlison > wrote: > >> vfork(2) is deprecated on Solaris and using it generates compiler >> warnings. When compiled with warnings-as-errors, this results in >> compilation failures. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161360 >> Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8161360 >> >> Thanks, >> >> -- >> Alan Burlison >> -- >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Sep 1 13:31:00 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 1 Sep 2016 16:31:00 +0300 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris In-Reply-To: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> Message-ID: Alan, Changes looks good for me. -Dmitry On 2016-08-31 14:55, Alan Burlison wrote: > vfork(2) is deprecated on Solaris and using it generates compiler > warnings. When compiled with warnings-as-errors, this results in > compilation failures. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161360 > Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8161360 > > Thanks, > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Burlison at oracle.com Thu Sep 1 13:34:20 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 1 Sep 2016 14:34:20 +0100 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris In-Reply-To: References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> Message-ID: On 01/09/2016 14:31, Dmitry Samersoff wrote: > Changes looks good for me. Thanks. Could someone possibly sponsor this for me? I don't have commit rights yet... -- Alan Burlison -- From weijun.wang at oracle.com Thu Sep 1 14:25:40 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 1 Sep 2016 22:25:40 +0800 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: Webrev updated at http://cr.openjdk.java.net/~weijun/8164705/webrev.01 Most suggestions from Alan accepted, including: 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead of public functions. 2. jdk.io.permissionsUseCanonicalPath=. 3. samepath.sh rewritten in ReadFileOnPath.java. Still using "ugly" method names. Thinking they are clear enough. Thanks Max On 8/29/2016 20:18, Alan Bateman wrote: > On 25/08/2016 04:55, Weijun Wang wrote: > >> Hi All >> >> Please take a look at >> >> http://cr.openjdk.java.net/~weijun/8164705/webrev.00 >> >> From the beginning of JDK, FilePermission canonicalizes the input path >> and use the result in implies() and equals(). This has been a big >> performance hurt and leads to confusing results when symlinks are >> involved. >> >> The code change above removes the canonicalization. >> >> This means FilePermission on "/the/current/working/directory/x" no >> longer implies that on "x". Since this might bring quite some >> compatibility risk, the code change includes some tweaks in permission >> checking to make sure an app is still able to read "x" when the >> FilePermission granted is on "/the/current/working/directory/x". >> However, we still hope the policy to be updated to be consistent of >> how a file is actually accessed. >> >> No tweak is devoted to make granting "/this/is/a/symlink" to imply >> reading of "/the/actual/target/file", because we think it should not. >> >> This is quite a big behavior change. If it breaks your app/lib, or >> does not work with your customized security manager or policy >> implementation, please let us know. >> >> Feel free to provide any feedback. >> >> Finally, a new system property "jdk.filepermission.canonicalize" is >> introduced and it can be "true", "false", or "compat". The out-of-box >> default is "compat", which means no canonicalization with check tweaks. > I've taken a first pass over this. A general comment then it's great to > see FilePermission changed to not do canonicalization. The "new > behavior" approach to match paths and support absolute => relative and > relative => absolute all makes sense. > > I agree that having a property to revert to legacy behavior make sense. > Is there any way to reduce this down to just current and legacy > behavior, it's otherwise too complicated to describe the subtle > differences between "false" and "compat". If it can be reduced to two > settings then a name such as > jdk.io.permissionsUseCanonicalPath= could be better than the > prototype name. > > For the implementation then I think it will cleanup before this is ready > to push. FilePermCompat is a ugly, particularly FilePermission changing > its public fields. Also method names like impliesWithAltFP, > newPermPlusAltPath, ... could be re-visited to make them much clearer. > > For the test then it would be good if samepath.sh could be replaced with > a non-shell test. > > -Alan From bodewig at apache.org Thu Sep 1 14:37:28 2016 From: bodewig at apache.org (Stefan Bodewig) Date: Thu, 01 Sep 2016 16:37:28 +0200 Subject: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions In-Reply-To: <57C66074.5080608@oracle.com> (Joe Wang's message of "Tue, 30 Aug 2016 21:43:32 -0700") References: <87eg58n7vx.fsf@v45346.1blu.de> <57C4825D.5070307@oracle.com> <87oa4ai5c5.fsf@v45346.1blu.de> <57C66074.5080608@oracle.com> Message-ID: <87poond6tz.fsf@v45346.1blu.de> On 2016-08-31, Joe Wang wrote: > On 8/30/16, 9:34 AM, Stefan Bodewig wrote: >> On 2016-08-29, Joe Wang wrote: >>> If you are using the built-in extension functions, try turning on the >>> following feature: >>> private static final String ENABLE_EXTENSION_FUNCTIONS = >>> "http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions"; >>> tf.setFeature(ENABLE_EXTENSION_FUNCTIONS, true); >> This is not supported by Xalan's TransformerFactoryImpl: > True, this is an impl-only feature. But Xalan doesn't need it anyways, > you may check the factory instance and skip it if it's Xalan. Thanks, you're comment made me take a third look at the test-case in question. I was confused by the setup and overlooked that we explicitly forced the use of the JDK's factory for just a single test. By selectively setting both features I can get the test to pass and am able to use the redirect extension of a version of Xalan on the classloader I specify. I'll need to add suppport for setting features on the TransformerFactory to Ant's task as I'd prefer to not hard-code the features into the task - and enable it for be default. >> When removing Xalan from the classpath and using the JDK's own >> TransformerFactory I get >> ,---- >> | Error! Use of the extension element 'redirect' is not allowed when the >> | secure processing feature is set to true. >> `---- >> even with the feature enabled. So "redirect" - >> i.e. xmlns:redirect="http://xml.apache.org/xalan/redirect" - which I >> assumed to be "built-in" for the JDK's fork of Xalan as well - doesn't >> seem to get through with just that. > I'll get this fixed in the next 1 or 2 > build. (https://bugs.openjdk.java.net/browse/JDK-8165116) This is great and will simplify things a lot. Many thanks Stefan From henry.jen at oracle.com Thu Sep 1 16:03:03 2016 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 1 Sep 2016 09:03:03 -0700 Subject: RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c In-Reply-To: <85a336ff-1ce0-ee08-9366-d132a25dc85a@oracle.com> References: <85a336ff-1ce0-ee08-9366-d132a25dc85a@oracle.com> Message-ID: That?s what I think too, this is just to silent parfait. I don?t know for sure that we always get NULL with exception pending though. Cheers, Henry On September 1, 2016 at 12:34:02 AM, David Holmes (david.holmes at oracle.com) wrote: > On 1/09/2016 5:51 AM, Henry Jen wrote: > > Hi, > > > > Please review a trivial fix for 8081388, in a nutshell, > > > > - Return NULL from NewPlatformStringArray if an exception occurred > > - All other places call this function already handled return value NULL > > - Launcher handles exception in JavaMain, report error and exit. > > > > Cheers, > > Henry > > > > diff --git a/src/java.base/share/native/libjli/java.c b/src/java.base/share/native/libjli/java.c > > --- a/src/java.base/share/native/libjli/java.c > > +++ b/src/java.base/share/native/libjli/java.c > > @@ -1497,6 +1497,7 @@ > > > > NULL_CHECK0(cls = FindBootStrapClass(env, "java/lang/String")); > > NULL_CHECK0(ary = (*env)->NewObjectArray(env, strc, cls, 0)); > > + CHECK_EXCEPTION_RETURN_VALUE(0); > > You will only get a NULL if an exception is pending; conversely you will > only have an exception pending if the return value is NULL. The new > check will never execute in a "positive way" and is unnecessary. > > David > ----- > > > for (i = 0; i < strc; i++) { > > jstring str = NewPlatformString(env, *strv++); > > NULL_CHECK0(str); > > diff --git a/src/java.base/share/native/libjli/java.h b/src/java.base/share/native/libjli/java.h > > --- a/src/java.base/share/native/libjli/java.h > > +++ b/src/java.base/share/native/libjli/java.h > > @@ -253,6 +253,13 @@ > > #define NULL_CHECK(NC_check_pointer) \ > > NULL_CHECK_RETURN_VALUE(NC_check_pointer, ) > > > > +#define CHECK_EXCEPTION_RETURN_VALUE(CER_value) \ > > + do { \ > > + if ((*env)->ExceptionOccurred(env)) { \ > > + return CER_value; \ > > + } \ > > + } while (JNI_FALSE) > > + > > #define CHECK_EXCEPTION_RETURN() \ > > do { \ > > if ((*env)->ExceptionOccurred(env)) { \ > > > From ivan.gerasimov at oracle.com Thu Sep 1 16:40:12 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 1 Sep 2016 19:40:12 +0300 Subject: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output Message-ID: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> Hello! An encoding output stream 'es' can be obtained as encoder.wrap(os). Normally, es.write(buf, off, len) throws IndexOutOfBoundException, if the referenced portion lies outside of the buffer. In this case, nothing is written to the underlying output stream 'os'. However, if (off + len) overflows, then the call to write() will produce some output, and only when it reaches the boundary of the buf will it throw the exception. This behavior looks inconsistent. Would you please help review the simple fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165243 WEBREV: http://cr.openjdk.java.net/~igerasim/8165243/00/webrev/ With kind regards, Ivan From Roger.Riggs at Oracle.com Thu Sep 1 17:23:07 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 1 Sep 2016 13:23:07 -0400 Subject: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> References: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> Message-ID: <657c5afe-cf91-f39a-1ef2-a8452048538c@Oracle.com> Looks fine Ivan. Thanks, Roger On 9/1/2016 12:40 PM, Ivan Gerasimov wrote: > Hello! > > An encoding output stream 'es' can be obtained as encoder.wrap(os). > Normally, es.write(buf, off, len) throws IndexOutOfBoundException, if > the referenced portion lies outside of the buffer. > In this case, nothing is written to the underlying output stream 'os'. > > However, if (off + len) overflows, then the call to write() will > produce some output, and only when it reaches the boundary of the buf > will it throw the exception. > > This behavior looks inconsistent. > > Would you please help review the simple fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165243 > WEBREV: http://cr.openjdk.java.net/~igerasim/8165243/00/webrev/ > > With kind regards, > Ivan > > From Alan.Bateman at oracle.com Thu Sep 1 17:39:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Sep 2016 18:39:32 +0100 Subject: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> References: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> Message-ID: On 01/09/2016 17:40, Ivan Gerasimov wrote: > Hello! > > An encoding output stream 'es' can be obtained as encoder.wrap(os). > Normally, es.write(buf, off, len) throws IndexOutOfBoundException, if > the referenced portion lies outside of the buffer. > In this case, nothing is written to the underlying output stream 'os'. > > However, if (off + len) overflows, then the call to write() will > produce some output, and only when it reaches the boundary of the buf > will it throw the exception. > > This behavior looks inconsistent. > > Would you please help review the simple fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165243 > WEBREV: http://cr.openjdk.java.net/~igerasim/8165243/00/webrev/ TestBase64 is the unit test for this API, should the test be added to that instead? -Alan From Alan.Burlison at oracle.com Thu Sep 1 17:43:15 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 1 Sep 2016 18:43:15 +0100 Subject: RFR: JDK-8165161 Solaris: /usr/ccs /opt/sfw and /opt/csw are dead, references should be expunged Message-ID: I posted this originally on build-dev, it was suggested I should also post it to core-libs-dev for review of some of the changes. /usr/ccs /opt/sfw and /opt/csw are all obsolete and should be removed from the Solaris-related build infrastructure. Bug: https://bugs.openjdk.java.net/browse/JDK-8165161 Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165161/ JPRT hotspot tests all pass. Thanks, -- Alan Burlison -- From patrick at reini.net Thu Sep 1 20:06:41 2016 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 1 Sep 2016 22:06:41 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream Message-ID: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Hi Alan, Hi Paul, Here is the first revision of the implementation based on our earlier conversation. http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.00 - Patrick From daniel.fuchs at oracle.com Thu Sep 1 22:37:51 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 1 Sep 2016 23:37:51 +0100 Subject: RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present In-Reply-To: <57C74256.10102@oracle.com> References: <57C70A0C.9080507@oracle.com> <5d76065f-3ea4-4f28-ed08-2682d5da6356@oracle.com> <57C74256.10102@oracle.com> Message-ID: <4793da77-8595-f1db-52af-94dcd9271371@oracle.com> On 31/08/16 21:47, Joe Wang wrote: > Thanks Aleksej! Hi Joe, Your last revision looks good. best, -- daniel > > -Joe > > On 8/31/16, 11:26 AM, Aleks Efimov wrote: >> Hi Joe, >> >> The changes looks nice (I'm not a reviewer) >> >> >> Best Regards, >> >> Aleksej >> >> >> On 31/08/16 19:47, Joe Wang wrote: >>> Hi, >>> >>> Please review a fix to the XSLTFunctionsTest. After enabling >>> SecurityManager, the test now needs to set the extension ClassLoader >>> for the extension class. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8161454 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8161454/webrev/ >>> >>> Thanks, >>> Joe >> From huizhe.wang at oracle.com Thu Sep 1 23:54:29 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 01 Sep 2016 16:54:29 -0700 Subject: RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present In-Reply-To: <4793da77-8595-f1db-52af-94dcd9271371@oracle.com> References: <57C70A0C.9080507@oracle.com> <5d76065f-3ea4-4f28-ed08-2682d5da6356@oracle.com> <57C74256.10102@oracle.com> <4793da77-8595-f1db-52af-94dcd9271371@oracle.com> Message-ID: <57C8BFB5.9010009@oracle.com> Thanks Daniel! -Joe On 9/1/16, 3:37 PM, Daniel Fuchs wrote: > On 31/08/16 21:47, Joe Wang wrote: >> Thanks Aleksej! > > Hi Joe, > > Your last revision looks good. > > best, > > -- daniel >> >> -Joe >> >> On 8/31/16, 11:26 AM, Aleks Efimov wrote: >>> Hi Joe, >>> >>> The changes looks nice (I'm not a reviewer) >>> >>> >>> Best Regards, >>> >>> Aleksej >>> >>> >>> On 31/08/16 19:47, Joe Wang wrote: >>>> Hi, >>>> >>>> Please review a fix to the XSLTFunctionsTest. After enabling >>>> SecurityManager, the test now needs to set the extension ClassLoader >>>> for the extension class. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8161454 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8161454/webrev/ >>>> >>>> Thanks, >>>> Joe >>> > From brian.burkhalter at oracle.com Fri Sep 2 00:18:50 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Sep 2016 17:18:50 -0700 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: At the API level and conceptually this all appears reasonable. I am going to need to take a deeper pass over it all however to comprehend the implementation at any kind of detailed level. The changes mentioned in response to Alan?s comments all appear good. Thanks, Brian On Sep 1, 2016, at 7:25 AM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8164705/webrev.01 > > Most suggestions from Alan accepted, including: > > 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead of public functions. > > 2. jdk.io.permissionsUseCanonicalPath=. > > 3. samepath.sh rewritten in ReadFileOnPath.java. > > Still using "ugly" method names. Thinking they are clear enough. From peter.firmstone at zeus.net.au Fri Sep 2 01:24:20 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 2 Sep 2016 11:24:20 +1000 (AEST) Subject: RFR 9: JEP 290: Filter Incoming Serialization Data Message-ID: <9ecc57c66aff7a554c283d78f8d850f8@org.tizen.email> ? Hi?Roger, Many?collections?classes?don't?read?arrays?in?directly,?instead?they?read?in?the?size?as?a?primitive?integer?and?create?the?array?before?reading?in?each?object. Clearly?the?filter?can?only?prevent?deserialization?of?dangerous?objects. My?personal?opinion?is?collections?classes?should?be?replaced?in?streams?with?safe?to?deserialize?serial?forms,?that?are?just?containers?backed?by?arrays?in?object?form??Client?classes?need?to?type?check?and?defensively?copy?their?content?into?new?Collection?object?instances?during?deserialization.? Filters?might?be?able?to?validate?these?types,?however?in?general,?since?there?is?no?way?to?atomically?fail?construction?during?deserialization,?object?construction?should?be?delayed?as?long?as?possible,?that?is,?after?all?fields?have?deserialized?unless?a?circular?link?exists. Circular?links?should?probably?be?avoided?or?their?recursion?depth?limited?in?untrusted?streams. Regards, Peter. Original?message: Hi Peter, Since the filter is passed information about each object created, a stateful filter can tabulate the cumulative size itself if that is a concern. Also, a stateless filter can be constructed to check a combination of the total number of objects, depth, array sizes, and stream size. Since arrays are initialized with data from the stream, the stream size provides a practical limit. Roger On 8/29/16 10:07 PM, Peter Firmstone wrote: > Include original message > > A quick thought on the array size filter: > > The system creates an array with a size read from the stream. > > If Mallory sends a multidimensional array in the stream, then Mallory can consume all jvm memory without exceeding the array size limit or the stream data limit. > > We also need an array combined length limit. > > Thanks, > > Peter. > > Sent from my Samsung device. > From stuart.marks at oracle.com Fri Sep 2 01:47:31 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 1 Sep 2016 18:47:31 -0700 Subject: RFR(m): 8159404: immutable collections should throw UOE unconditionally Message-ID: <34a6415a-f403-08b4-0cc1-83311199c920@oracle.com> Hi all, Please review this change to make the immutable collections (List.of, Set.of, Map.of) throw UnsupportedOperationException unconditionally. That is, they should throw UOE even if a mutator method is called with arguments that make it a no-op. Calling a mutator method on an immutable collection is always a programming error, and having it sometimes be a no-op potentially leads to errors. Note that the existing Collections unmodifiable wrappers always throw UOE unconditionally. This change makes the immutable collections behave consistently with the unmodifiable wrappers. For example, List unmodList = Collections.unmodifiableList(new ArrayList<>()); unmodList.addAll(List.of()); // throws UOE List.of().addAll(List.of()); // currently does nothing, change to throw UOE Unfortunately, various other specialized collections such as emptyList() etc. behave differently, e.g. Collections.emptyList().addAll(List.of()); // does nothing However, that change will be left for another day. Bug: https://bugs.openjdk.java.net/browse/JDK-8159404 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8159404/webrev.0/ Thanks, s'marks From david.holmes at oracle.com Fri Sep 2 02:15:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Sep 2016 12:15:46 +1000 Subject: RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c In-Reply-To: References: <85a336ff-1ce0-ee08-9366-d132a25dc85a@oracle.com> Message-ID: <6828b16a-9469-65fd-e1dc-541828a0510e@oracle.com> On 2/09/2016 2:03 AM, Henry Jen wrote: > That?s what I think too, this is just to silent parfait. We are doing similar things in VM code, but the NULL check suffices. If that is not the case here then I think a Parfait bug needs to be filed. > I don?t know for sure that we always get NULL with exception pending though. If you didn't that would be a VM bug. Either you get an array returned or you get NULL if the creation failed - the only way it can fail is if some exception is thrown. Thanks, David > Cheers, > Henry > > On September 1, 2016 at 12:34:02 AM, David Holmes (david.holmes at oracle.com) wrote: >> On 1/09/2016 5:51 AM, Henry Jen wrote: >>> Hi, >>> >>> Please review a trivial fix for 8081388, in a nutshell, >>> >>> - Return NULL from NewPlatformStringArray if an exception occurred >>> - All other places call this function already handled return value NULL >>> - Launcher handles exception in JavaMain, report error and exit. >>> >>> Cheers, >>> Henry >>> >>> diff --git a/src/java.base/share/native/libjli/java.c b/src/java.base/share/native/libjli/java.c >>> --- a/src/java.base/share/native/libjli/java.c >>> +++ b/src/java.base/share/native/libjli/java.c >>> @@ -1497,6 +1497,7 @@ >>> >>> NULL_CHECK0(cls = FindBootStrapClass(env, "java/lang/String")); >>> NULL_CHECK0(ary = (*env)->NewObjectArray(env, strc, cls, 0)); >>> + CHECK_EXCEPTION_RETURN_VALUE(0); >> >> You will only get a NULL if an exception is pending; conversely you will >> only have an exception pending if the return value is NULL. The new >> check will never execute in a "positive way" and is unnecessary. >> >> David >> ----- >> >>> for (i = 0; i < strc; i++) { >>> jstring str = NewPlatformString(env, *strv++); >>> NULL_CHECK0(str); >>> diff --git a/src/java.base/share/native/libjli/java.h b/src/java.base/share/native/libjli/java.h >>> --- a/src/java.base/share/native/libjli/java.h >>> +++ b/src/java.base/share/native/libjli/java.h >>> @@ -253,6 +253,13 @@ >>> #define NULL_CHECK(NC_check_pointer) \ >>> NULL_CHECK_RETURN_VALUE(NC_check_pointer, ) >>> >>> +#define CHECK_EXCEPTION_RETURN_VALUE(CER_value) \ >>> + do { \ >>> + if ((*env)->ExceptionOccurred(env)) { \ >>> + return CER_value; \ >>> + } \ >>> + } while (JNI_FALSE) >>> + >>> #define CHECK_EXCEPTION_RETURN() \ >>> do { \ >>> if ((*env)->ExceptionOccurred(env)) { \ >>> >> > From martinrb at google.com Fri Sep 2 03:41:48 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 1 Sep 2016 20:41:48 -0700 Subject: RFR(m): 8159404: immutable collections should throw UOE unconditionally In-Reply-To: <34a6415a-f403-08b4-0cc1-83311199c920@oracle.com> References: <34a6415a-f403-08b4-0cc1-83311199c920@oracle.com> Message-ID: Looks good to me! Another idea for another day: I would like the immutable collections to be more optimal than they currently are, even if we have to write more code. It bugs me is that all of these collections have a modCount, despite never being modified! (Even for mutable lists, I'm not sure the added safety of modCount was worth the price) java -jar jol-cli-0.5-full.jar internals java.util.ImmutableCollections\$List1 ... java.util.ImmutableCollections$List1 object internals: 0 12 (object header) N/A 12 4 int AbstractList.modCount N/A 16 4 Object List1.e0 N/A On Thu, Sep 1, 2016 at 6:47 PM, Stuart Marks wrote: > Hi all, > > Please review this change to make the immutable collections (List.of, > Set.of, Map.of) throw UnsupportedOperationException unconditionally. That > is, they should throw UOE even if a mutator method is called with arguments > that make it a no-op. Calling a mutator method on an immutable collection > is always a programming error, and having it sometimes be a no-op > potentially leads to errors. > > Note that the existing Collections unmodifiable wrappers always throw UOE > unconditionally. This change makes the immutable collections behave > consistently with the unmodifiable wrappers. For example, > > List unmodList = Collections.unmodifiableList(new > ArrayList<>()); > unmodList.addAll(List.of()); // throws UOE > List.of().addAll(List.of()); // currently does nothing, change to > throw UOE > > Unfortunately, various other specialized collections such as emptyList() > etc. behave differently, e.g. > > Collections.emptyList().addAll(List.of()); // does nothing > > However, that change will be left for another day. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8159404 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8159404/webrev.0/ > > Thanks, > > s'marks > From paul.sandoz at oracle.com Fri Sep 2 03:48:01 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Sep 2016 20:48:01 -0700 Subject: RFR(m): 8159404: immutable collections should throw UOE unconditionally In-Reply-To: References: <34a6415a-f403-08b4-0cc1-83311199c920@oracle.com> Message-ID: > On 1 Sep 2016, at 20:41, Martin Buchholz wrote: > > Looks good to me! > +1 Paul. From amaembo at gmail.com Fri Sep 2 04:56:27 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 2 Sep 2016 11:56:27 +0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: Hello! The documentation says: + *

The search order is described in the documentation for {@link+ * #getResource(String)}. I think it means that the order of the stream is well-defined. In this case should not we add ORDERED spliterator characteristic? With best regards, Tagir Valeev. On Fri, Sep 2, 2016 at 3:06 AM, Patrick Reinhart wrote: > Hi Alan, > Hi Paul, > > Here is the first revision of the implementation based on our earlier > conversation. > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.00 < > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.00> > > - Patrick > From andrej.golovnin at gmail.com Fri Sep 2 06:09:14 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 2 Sep 2016 08:09:14 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: Hi Patrick, src/java.base/share/classes/java/lang/ClassLoader.java The constant RESOURCE_CHARACTERISTICS in the line 215 should be defined near the #streamOf()-method. The distance between the line 1412 where the #streamOf()-method is defined and the line 215 is just too huge. Your patch seems to modify the JavaDocs of the methods #getParent(), #getPlatformClassLoader(), #getSystemClassLoader(). But I don see how it is related to the issue you try to solve. test/java/lang/ClassLoader/resources/ResourcesFailureCase.java test/java/lang/ClassLoader/resources/ResourcesSuccessCase.java The indentation is broken. You use tabs. But in JDK you must use spaces, see http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-indentation Best regards, Andrej Golovnin On Thu, Sep 1, 2016 at 10:06 PM, Patrick Reinhart wrote: > Hi Alan, > Hi Paul, > > Here is the first revision of the implementation based on our earlier conversation. > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.00 > > - Patrick From patrick at reini.net Fri Sep 2 07:41:31 2016 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 02 Sep 2016 09:41:31 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: On 2016-09-02 08:09, Andrej Golovnin wrote: > src/java.base/share/classes/java/lang/ClassLoader.java > > The constant RESOURCE_CHARACTERISTICS in the line 215 should be > defined near the #streamOf()-method. The distance between the line > 1412 where the #streamOf()-method is defined and the line 215 is just > too huge. No problem, moved to the method itself > Your patch seems to modify the JavaDocs of the methods #getParent(), > #getPlatformClassLoader(), #getSystemClassLoader(). But I don see how > it is related to the issue you try to solve.> Was a merge issue, removed those > test/java/lang/ClassLoader/resources/ResourcesFailureCase.java > test/java/lang/ClassLoader/resources/ResourcesSuccessCase.java > The indentation is broken. You use tabs. But in JDK you must use > spaces, see > http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-indentation Fixed those also. See updated webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01 - Patrick From amaembo at gmail.com Fri Sep 2 08:10:38 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 2 Sep 2016 15:10:38 +0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: Also small thing: > Spliterator.NONNULL & Spliterator.IMMUTABLE Should be Spliterator.NONNULL | Spliterator.IMMUTABLE With best regards, Tagir Valeev. On Fri, Sep 2, 2016 at 2:41 PM, Patrick Reinhart wrote: > On 2016-09-02 08:09, Andrej Golovnin wrote: > >> src/java.base/share/classes/java/lang/ClassLoader.java >> >> The constant RESOURCE_CHARACTERISTICS in the line 215 should be >> defined near the #streamOf()-method. The distance between the line >> 1412 where the #streamOf()-method is defined and the line 215 is just >> too huge. >> > > No problem, moved to the method itself > > Your patch seems to modify the JavaDocs of the methods #getParent(), >> #getPlatformClassLoader(), #getSystemClassLoader(). But I don see how >> it is related to the issue you try to solve.> >> > > Was a merge issue, removed those > > test/java/lang/ClassLoader/resources/ResourcesFailureCase.java >> test/java/lang/ClassLoader/resources/ResourcesSuccessCase.java >> > > The indentation is broken. You use tabs. But in JDK you must use >> spaces, see >> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.ht >> ml#toc-indentation >> > > Fixed those also. > > See updated webrev: > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01 > > - Patrick > From ivan.gerasimov at oracle.com Fri Sep 2 08:59:49 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 2 Sep 2016 11:59:49 +0300 Subject: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: References: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> Message-ID: Thank you Roger and Alan for review! On 01.09.2016 20:39, Alan Bateman wrote: > TestBase64 is the unit test for this API, should the test be added to > that instead? > Yes, it should be better. http://cr.openjdk.java.net/~igerasim/8165243/01/webrev/ I also added another test case to make sure the decoder doesn't expose the same bug. A cleanup pass was performed to make the code more compact. Is it good to go? With kind regards, Ivan From patrick at reini.net Fri Sep 2 09:50:33 2016 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 02 Sep 2016 11:50:33 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: On 2016-09-02 10:10, Tagir Valeev wrote: > Also small thing: > >> Spliterator.NONNULL & Spliterator.IMMUTABLE > > Should be Spliterator.NONNULL | Spliterator.IMMUTABLE > > With best regards, > Tagir Valeev. Updated the existing http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01 - Patrick From jbluettduncan at gmail.com Fri Sep 2 12:59:15 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Fri, 2 Sep 2016 13:59:15 +0100 Subject: Participating on https://bugs.openjdk.java.net/browse/JDK-8156070 In-Reply-To: References: Message-ID: Hi Stuart Marks, I've been told by Martijn Verburg on the discuss mailing list that you're the lead person for the Immutable Collections enhancements piece. Is there anything I can do to help you out with https://bugs.openjdk. java.net/browse/JDK-8156070 or any other part of JEP 269 ? Kind regards, Jonathan On 28 August 2016 at 17:25, Jonathan Bluett-Duncan wrote: > Hi all, > > My name is Jonathan, and it's my first time posting to this mailing list. > > I'm writing to you all as I'm rather interested in contributing to this > area of the OpenJDK. Particularly, I'm thinking I'd quite like to help out > with one of the subtasks for the Immutable Collections enhancements > . However I don't have > specific ideas and I don't know which of the subtasks would most closely > match my skills and knowledge, so I wondered if I could have some guidance > as to what I could do and how I can get started. > > FYI, I've partially read the contribution instructions > , and I just submitted an OCA > earlier today, so I don't expect to be actually ready to participate until > I hear back from Oracle, but nonetheless I'd like to try to get the ball > rolling as soon as possible. > > Kind regards, > Jonathan Bluett-Duncan > From harold.seigel at oracle.com Fri Sep 2 13:02:08 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 2 Sep 2016 09:02:08 -0400 Subject: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class Message-ID: Hi, Please review this new fix for JDK-8058575. This fix requires that a VM anonymous class be in either the same package as its host class or be in the unnamed package. If the anonymous class is in the unnamed package then this fix puts it into its host class's package, ensuring that the anonymous class and its host class are in the same module. This fix also throws an IllegalArgumentException if the host class is an array class. Additionally, the type of field ClassFileParser::_host_klass was changed to InstanceKlass* and some comments were cleaned up. JBS bug: https://bugs.openjdk.java.net/browse/JDK-8058575 Open webrevs: http://cr.openjdk.java.net/~hseigel/bug_8058575.jdk.3/ http://cr.openjdk.java.net/~hseigel/bug_8058575.hs.3/ The fix was tested with the JCK API, Lang and VM tests, the hotpot, and java/lang, java/util and other JTreg tests, the RBT tier2 tests, and the NSK colocated tests and non-colocated quick tests. Thanks, Harold From roger.riggs at oracle.com Fri Sep 2 13:49:10 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 2 Sep 2016 09:49:10 -0400 Subject: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: References: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> Message-ID: Hi Ivan, In the TestBase64.java: 563 throw new RuntimeException("Expected IOOBEx not thrown"); And 598 throw new RuntimeException("Expected IOOBEx not thrown"); I would say "was not thrown" to make the cause clearer. 567 throw new RuntimeException("No output expected"); I suppose this will never fail but including the size in the exception message would speed debugging. Otherwise, looks fine Roger On 9/2/16 4:59 AM, Ivan Gerasimov wrote: > Thank you Roger and Alan for review! On 01.09.2016 20:39, Alan Bateman > wrote: >> TestBase64 is the unit test for this API, should the test be added to >> that instead? > Yes, it should be better. > http://cr.openjdk.java.net/~igerasim/8165243/01/webrev/ I also added > another test case to make sure the decoder doesn't expose the same > bug. A cleanup pass was performed to make the code more compact. Is it > good to go? With kind regards, Ivan From Alan.Bateman at oracle.com Fri Sep 2 14:43:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Sep 2016 15:43:09 +0100 Subject: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class In-Reply-To: References: Message-ID: <71c3580b-eb25-cc0d-5408-1df421d3aba5@oracle.com> On 02/09/2016 14:02, harold seigel wrote: > Hi, > > Please review this new fix for JDK-8058575. This fix requires that a > VM anonymous class be in either the same package as its host class or > be in the unnamed package. If the anonymous class is in the unnamed > package then this fix puts it into its host class's package, ensuring > that the anonymous class and its host class are in the same module. > This fix also throws an IllegalArgumentException if the host class is > an array class. > > Additionally, the type of field ClassFileParser::_host_klass was > changed to InstanceKlass* and some comments were cleaned up. > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8058575 > > Open webrevs: > > http://cr.openjdk.java.net/~hseigel/bug_8058575.jdk.3/ In GetModuleTest then one clean-up is to change it to use hostClass.getPackageName() and remove packageName(String). -Alan From Alan.Bateman at oracle.com Fri Sep 2 14:51:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Sep 2016 15:51:34 +0100 Subject: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: References: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> Message-ID: <996a848b-788d-59de-1660-1890db1fea0f@oracle.com> On 02/09/2016 09:59, Ivan Gerasimov wrote: > : > > > On 01.09.2016 20:39, Alan Bateman wrote: >> TestBase64 is the unit test for this API, should the test be added to >> that instead? >> > > Yes, it should be better. > > http://cr.openjdk.java.net/~igerasim/8165243/01/webrev/ > > I also added another test case to make sure the decoder doesn't expose > the same bug. > A cleanup pass was performed to make the code more compact. > > Is it good to go? Using RandomFactory looks okay although more awkward to run the test standalone, I assume rnd should be final. Since you changing a lot of usages then personally I have input stream named "in" rather than "is" easier to read. I agree with Roger on making the exception messages clearer. A minor comment but the method names in the test are a bit inconsistent, "Encoder" vs "Enc" for example. -Alan From harold.seigel at oracle.com Fri Sep 2 15:03:34 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 2 Sep 2016 11:03:34 -0400 Subject: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class In-Reply-To: <71c3580b-eb25-cc0d-5408-1df421d3aba5@oracle.com> References: <71c3580b-eb25-cc0d-5408-1df421d3aba5@oracle.com> Message-ID: <4729582c-be95-9844-93e5-31fa1cb0f0ef@oracle.com> Thanks Alan. I'll go ahead and make that change. Harold On 9/2/2016 10:43 AM, Alan Bateman wrote: > > > On 02/09/2016 14:02, harold seigel wrote: >> Hi, >> >> Please review this new fix for JDK-8058575. This fix requires that a >> VM anonymous class be in either the same package as its host class or >> be in the unnamed package. If the anonymous class is in the unnamed >> package then this fix puts it into its host class's package, ensuring >> that the anonymous class and its host class are in the same module. >> This fix also throws an IllegalArgumentException if the host class is >> an array class. >> >> Additionally, the type of field ClassFileParser::_host_klass was >> changed to InstanceKlass* and some comments were cleaned up. >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8058575 >> >> Open webrevs: >> >> http://cr.openjdk.java.net/~hseigel/bug_8058575.jdk.3/ > In GetModuleTest then one clean-up is to change it to use > hostClass.getPackageName() and remove packageName(String). > > -Alan From forax at univ-mlv.fr Fri Sep 2 15:25:26 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 2 Sep 2016 17:25:26 +0200 (CEST) Subject: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class In-Reply-To: <4729582c-be95-9844-93e5-31fa1cb0f0ef@oracle.com> References: <71c3580b-eb25-cc0d-5408-1df421d3aba5@oracle.com> <4729582c-be95-9844-93e5-31fa1cb0f0ef@oracle.com> Message-ID: <738081554.2266730.1472829926986.JavaMail.zimbra@u-pem.fr> Harold, disallowing array classes as host classes seems unrelated and knowing that jdk 10 or 11 will certainly add default methods to arrays, we will want to have anonymous classes with arrays as host class in order to acts as bridges/mixins. regards, R?mi ----- Mail original ----- > De: "harold seigel" > ?: "Alan Bateman" , "Hotspot dev runtime" , > core-libs-dev at openjdk.java.net > Envoy?: Vendredi 2 Septembre 2016 17:03:34 > Objet: Re: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class > Thanks Alan. I'll go ahead and make that change. > > Harold > > > On 9/2/2016 10:43 AM, Alan Bateman wrote: >> >> >> On 02/09/2016 14:02, harold seigel wrote: >>> Hi, >>> >>> Please review this new fix for JDK-8058575. This fix requires that a >>> VM anonymous class be in either the same package as its host class or >>> be in the unnamed package. If the anonymous class is in the unnamed >>> package then this fix puts it into its host class's package, ensuring >>> that the anonymous class and its host class are in the same module. >>> This fix also throws an IllegalArgumentException if the host class is >>> an array class. >>> >>> Additionally, the type of field ClassFileParser::_host_klass was >>> changed to InstanceKlass* and some comments were cleaned up. >>> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8058575 >>> >>> Open webrevs: >>> >>> http://cr.openjdk.java.net/~hseigel/bug_8058575.jdk.3/ >> In GetModuleTest then one clean-up is to change it to use >> hostClass.getPackageName() and remove packageName(String). >> > > -Alan From ivan.gerasimov at oracle.com Fri Sep 2 16:39:24 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 2 Sep 2016 19:39:24 +0300 Subject: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: <996a848b-788d-59de-1660-1890db1fea0f@oracle.com> References: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> <996a848b-788d-59de-1660-1890db1fea0f@oracle.com> Message-ID: <31fa4231-3564-ddb9-7a27-2139111b5ab4@oracle.com> Roger and Alan, thanks for suggestions! I incorporated most of them: http://cr.openjdk.java.net/~igerasim/8165243/02/webrev/ >> >> Is it good to go? > Using RandomFactory looks okay although more awkward to run the test > standalone, I assume rnd should be final. > > Since you changing a lot of usages then personally I have input stream > named "in" rather than "is" easier to read. > But there are also os, baos, bais around, so changing only is to in would be inconsistent. > I agree with Roger on making the exception messages clearer. Sure, I made them clearer, as suggested. Hopefully, we won't see them too often :) > A minor comment but the method names in the test are a bit > inconsistent, "Encoder" vs "Enc" for example. > Yes, changed to full names and got rid of new checkXXX methods, as they weren't really needed. With kind regards, Ivan From xueming.shen at oracle.com Fri Sep 2 16:55:25 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 02 Sep 2016 09:55:25 -0700 Subject: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: <31fa4231-3564-ddb9-7a27-2139111b5ab4@oracle.com> References: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> <996a848b-788d-59de-1660-1890db1fea0f@oracle.com> <31fa4231-3564-ddb9-7a27-2139111b5ab4@oracle.com> Message-ID: <57C9AEFD.5060905@oracle.com> +1 On 09/02/2016 09:39 AM, Ivan Gerasimov wrote: > Roger and Alan, thanks for suggestions! > > I incorporated most of them: > http://cr.openjdk.java.net/~igerasim/8165243/02/webrev/ > > >>> >>> Is it good to go? >> Using RandomFactory looks okay although more awkward to run the test standalone, I assume rnd should be final. >> >> Since you changing a lot of usages then personally I have input stream named "in" rather than "is" easier to read. >> > But there are also os, baos, bais around, so changing only is to in would be inconsistent. > >> I agree with Roger on making the exception messages clearer. > Sure, I made them clearer, as suggested. > Hopefully, we won't see them too often :) > >> A minor comment but the method names in the test are a bit inconsistent, "Encoder" vs "Enc" for example. >> > Yes, changed to full names and got rid of new checkXXX methods, as they weren't really needed. > > With kind regards, > Ivan > From kumar.x.srinivasan at oracle.com Fri Sep 2 17:14:46 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 02 Sep 2016 10:14:46 -0700 Subject: RFR: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR In-Reply-To: <17BABD81-589E-42A0-B5F1-6B3BFE496392@oracle.com> References: <56F0504A.4030204@oracle.com> <17BABD81-589E-42A0-B5F1-6B3BFE496392@oracle.com> Message-ID: <57C9B386.8070404@oracle.com> Hi John, Please review the amended patch, based on our discussions. http://cr.openjdk.java.net/~ksrini/8151901/webrev.01/ Highlights: * adjust the ordering of the InnerClass and BootStrapMethods computations * enabled the test, and disabled memory leak check, which causes intermittent failures, because of GC's ergonomics etc. * added the two test files to golden.jar, just in case. Thanks Kumar > Good. > > Please change the comment: > s/null, no tuple change, force recomputation/null, drop ICs attribute, force CP recomputation/ > > Reordering BSMs and ICs should work. > The BSMs may need extra ICs, but ICs cannot depend on BSMs. > I wonder why we did the other order first? I guess because that is what the spec. says. > > Oh, there's a problem with the attribute insertion order logic; it's buggy that we unconditionally > insert a BSMs attr. and then delete it later. (That goes wrong when change<0 and we recompute > from scratch.) > > Suggested amended patch enclosed. > > --- John > > On Mar 21, 2016, at 12:49 PM, Kumar Srinivasan wrote: >> Hi John, >> >> This patch contains fixes for two bugs: >> 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR >> 8062335: Pack200 Java implementation differs from C version, outputs unused UTF8 for BootstrapMethods Note: The test case exhibits both of the above. >> >> With this the classes produced by java and the native implementation are congruent, >> though the JDK image's classes exhibit these issues, as a precaution I have extracted the >> minimal set of classes to reproduce the issues, into the golden jar. >> >> The webrev is at: >> http://cr.openjdk.java.net/~ksrini/8151901/webrev.00/ >> >> Thanks >> Kumar >> > > > diff --git a/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java b/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java > --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java > +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java > @@ -312,6 +312,12 @@ > void setBootstrapMethods(Collection bsms) { > assert(bootstrapMethods == null); // do not do this twice > bootstrapMethods = new ArrayList<>(bsms); > + // Edit the attribute list, if necessary. > + Attribute a = getAttribute(attrBootstrapMethodsEmpty); > + if (bootstrapMethods != null && a == null) > + addAttribute(attrBootstrapMethodsEmpty.canonicalInstance()); > + else if (bootstrapMethods == null && a != null) > + removeAttribute(a); > } > > boolean hasInnerClasses() { > diff --git a/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java b/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java > --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java > +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java > @@ -1193,16 +1193,25 @@ > cls.visitRefs(VRM_CLASSIC, cpRefs); > > ArrayList bsms = new ArrayList<>(); > - /* > - * BootstrapMethod(BSMs) are added here before InnerClasses(ICs), > - * so as to ensure the order. Noting that the BSMs may be > - * removed if they are not found in the CP, after the ICs expansion. > - */ > - cls.addAttribute(Package.attrBootstrapMethodsEmpty.canonicalInstance()); > > // flesh out the local constant pool > ConstantPool.completeReferencesIn(cpRefs, true, bsms); > > + // Add the BSMs and references as required. > + if (!bsms.isEmpty()) { > + // Add the attirbute name to the CP (visitRefs would have wanted this). > + cpRefs.add(Package.getRefString("BootstrapMethods")); > + // The pack-spec requires that BootstrapMethods precedes the InnerClasses attribute. > + // So add BSMs now before running expandLocalICs. > + // But first delete any local InnerClasses attr. (This is rare.) > + List localICs = cls.getInnerClasses(); > + cls.setInnerClasses(null); > + Collections.sort(bsms); > + cls.setBootstrapMethods(bsms); > + // Re-add the ICs, so the attribute lists are in the required order. > + cls.setInnerClasses(localICs); > + } > + > // Now that we know all our local class references, > // compute the InnerClasses attribute. > int changed = cls.expandLocalICs(); > @@ -1221,16 +1230,6 @@ > ConstantPool.completeReferencesIn(cpRefs, true, bsms); > } > > - // remove the attr previously set, otherwise add the bsm and > - // references as required > - if (bsms.isEmpty()) { > - cls.attributes.remove(Package.attrBootstrapMethodsEmpty.canonicalInstance()); > - } else { > - cpRefs.add(Package.getRefString("BootstrapMethods")); > - Collections.sort(bsms); > - cls.setBootstrapMethods(bsms); > - } > - > // construct a local constant pool > int numDoubles = 0; > for (Entry e : cpRefs) { > From Roger.Riggs at Oracle.com Fri Sep 2 17:28:22 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 2 Sep 2016 13:28:22 -0400 Subject: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: <31fa4231-3564-ddb9-7a27-2139111b5ab4@oracle.com> References: <374788db-204c-8e06-a63f-8f2874b97360@oracle.com> <996a848b-788d-59de-1660-1890db1fea0f@oracle.com> <31fa4231-3564-ddb9-7a27-2139111b5ab4@oracle.com> Message-ID: <7ceecfc2-342e-1640-b750-f46d45109692@Oracle.com> +1 On 9/2/2016 12:39 PM, Ivan Gerasimov wrote: > Roger and Alan, thanks for suggestions! > > I incorporated most of them: > http://cr.openjdk.java.net/~igerasim/8165243/02/webrev/ > > >>> >>> Is it good to go? >> Using RandomFactory looks okay although more awkward to run the test >> standalone, I assume rnd should be final. >> >> Since you changing a lot of usages then personally I have input >> stream named "in" rather than "is" easier to read. >> > But there are also os, baos, bais around, so changing only is to in > would be inconsistent. > >> I agree with Roger on making the exception messages clearer. > Sure, I made them clearer, as suggested. > Hopefully, we won't see them too often :) > >> A minor comment but the method names in the test are a bit >> inconsistent, "Encoder" vs "Enc" for example. >> > Yes, changed to full names and got rid of new checkXXX methods, as > they weren't really needed. > > With kind regards, > Ivan > From harold.seigel at oracle.com Fri Sep 2 18:32:55 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 2 Sep 2016 14:32:55 -0400 Subject: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class In-Reply-To: <738081554.2266730.1472829926986.JavaMail.zimbra@u-pem.fr> References: <71c3580b-eb25-cc0d-5408-1df421d3aba5@oracle.com> <4729582c-be95-9844-93e5-31fa1cb0f0ef@oracle.com> <738081554.2266730.1472829926986.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, Thank you for looking at this change. Not allowing host classes to be array classes is not completely unrelated to this bug because it affects the implementation of the code that prepends the host class's package to the anonymous class. We decided to not allow array host classes in JDK-9 because it makes no sense. A user who does this is likely doing so in error, and should be flagged for it. We recognize that this, and many other things, will have to change once array classes have their own methods. Thanks, Harold On 9/2/2016 11:25 AM, Remi Forax wrote: > Harold, > disallowing array classes as host classes seems unrelated and knowing that jdk 10 or 11 will certainly add default methods to arrays, > we will want to have anonymous classes with arrays as host class in order to acts as bridges/mixins. > > regards, > R?mi > > ----- Mail original ----- >> De: "harold seigel" >> ?: "Alan Bateman" , "Hotspot dev runtime" , >> core-libs-dev at openjdk.java.net >> Envoy?: Vendredi 2 Septembre 2016 17:03:34 >> Objet: Re: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class >> Thanks Alan. I'll go ahead and make that change. >> >> Harold >> >> >> On 9/2/2016 10:43 AM, Alan Bateman wrote: >>> >>> On 02/09/2016 14:02, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this new fix for JDK-8058575. This fix requires that a >>>> VM anonymous class be in either the same package as its host class or >>>> be in the unnamed package. If the anonymous class is in the unnamed >>>> package then this fix puts it into its host class's package, ensuring >>>> that the anonymous class and its host class are in the same module. >>>> This fix also throws an IllegalArgumentException if the host class is >>>> an array class. >>>> >>>> Additionally, the type of field ClassFileParser::_host_klass was >>>> changed to InstanceKlass* and some comments were cleaned up. >>>> >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8058575 >>>> >>>> Open webrevs: >>>> >>>> http://cr.openjdk.java.net/~hseigel/bug_8058575.jdk.3/ >>> In GetModuleTest then one clean-up is to change it to use >>> hostClass.getPackageName() and remove packageName(String). >>> >>> -Alan From forax at univ-mlv.fr Fri Sep 2 20:17:07 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 2 Sep 2016 22:17:07 +0200 (CEST) Subject: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class In-Reply-To: References: <71c3580b-eb25-cc0d-5408-1df421d3aba5@oracle.com> <4729582c-be95-9844-93e5-31fa1cb0f0ef@oracle.com> <738081554.2266730.1472829926986.JavaMail.zimbra@u-pem.fr> Message-ID: <2032024403.2318317.1472847427798.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "harold seigel" > ?: "Remi Forax" > Cc: "Alan Bateman" , "Hotspot dev runtime" , > core-libs-dev at openjdk.java.net > Envoy?: Vendredi 2 Septembre 2016 20:32:55 > Objet: Re: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class > Hi R?mi, > > Thank you for looking at this change. > > Not allowing host classes to be array classes is not completely > unrelated to this bug because it affects the implementation of the code > that prepends the host class's package to the anonymous class. yes, right. but i've always believed that the name was more for debugging purpose, i.e. because a VM anonymous class name is not registered in a Classloader, so the VM will never find an anonymous class by it's name. > > We decided to not allow array host classes in JDK-9 because it makes no > sense. A user who does this is likely doing so in error, and should be > flagged for it. yes, true. > > We recognize that this, and many other things, will have to change once > array classes have their own methods. > > Thanks, Harold Thanks for the explanation, R?mi > > > On 9/2/2016 11:25 AM, Remi Forax wrote: >> Harold, >> disallowing array classes as host classes seems unrelated and knowing that jdk >> 10 or 11 will certainly add default methods to arrays, >> we will want to have anonymous classes with arrays as host class in order to >> acts as bridges/mixins. >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "harold seigel" >>> ?: "Alan Bateman" , "Hotspot dev runtime" >>> , >>> core-libs-dev at openjdk.java.net >>> Envoy?: Vendredi 2 Septembre 2016 17:03:34 >>> Objet: Re: RFR 8058575: IllegalAccessError trying to access package-private >>> class from VM anonymous class >>> Thanks Alan. I'll go ahead and make that change. >>> >>> Harold >>> >>> >>> On 9/2/2016 10:43 AM, Alan Bateman wrote: >>>> >>>> On 02/09/2016 14:02, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review this new fix for JDK-8058575. This fix requires that a >>>>> VM anonymous class be in either the same package as its host class or >>>>> be in the unnamed package. If the anonymous class is in the unnamed >>>>> package then this fix puts it into its host class's package, ensuring >>>>> that the anonymous class and its host class are in the same module. >>>>> This fix also throws an IllegalArgumentException if the host class is >>>>> an array class. >>>>> >>>>> Additionally, the type of field ClassFileParser::_host_klass was >>>>> changed to InstanceKlass* and some comments were cleaned up. >>>>> >>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8058575 >>>>> >>>>> Open webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~hseigel/bug_8058575.jdk.3/ >>>> In GetModuleTest then one clean-up is to change it to use >>>> hostClass.getPackageName() and remove packageName(String). >>>> > >>> -Alan From harold.seigel at oracle.com Fri Sep 2 20:30:28 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 2 Sep 2016 16:30:28 -0400 Subject: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class In-Reply-To: <2032024403.2318317.1472847427798.JavaMail.zimbra@u-pem.fr> References: <71c3580b-eb25-cc0d-5408-1df421d3aba5@oracle.com> <4729582c-be95-9844-93e5-31fa1cb0f0ef@oracle.com> <738081554.2266730.1472829926986.JavaMail.zimbra@u-pem.fr> <2032024403.2318317.1472847427798.JavaMail.zimbra@u-pem.fr> Message-ID: <2c91e605-48c2-758f-9aac-b74b9fe273c0@oracle.com> On 9/2/2016 4:17 PM, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "harold seigel" >> ?: "Remi Forax" >> Cc: "Alan Bateman" , "Hotspot dev runtime" , >> core-libs-dev at openjdk.java.net >> Envoy?: Vendredi 2 Septembre 2016 20:32:55 >> Objet: Re: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class >> Hi R?mi, >> >> Thank you for looking at this change. >> >> Not allowing host classes to be array classes is not completely >> unrelated to this bug because it affects the implementation of the code >> that prepends the host class's package to the anonymous class. > yes, right. > but i've always believed that the name was more for debugging purpose, > i.e. because a VM anonymous class name is not registered in a Classloader, > so the VM will never find an anonymous class by it's name. Having a package name that matches its host class's ensures that the anonymous class is in the same module as its host class in cases where the VM determines a class's module from its Klass's package entry structure. Harold > >> We decided to not allow array host classes in JDK-9 because it makes no >> sense. A user who does this is likely doing so in error, and should be >> flagged for it. > yes, true. > >> We recognize that this, and many other things, will have to change once >> array classes have their own methods. >> >> Thanks, Harold > Thanks for the explanation, > R?mi > >> >> On 9/2/2016 11:25 AM, Remi Forax wrote: >>> Harold, >>> disallowing array classes as host classes seems unrelated and knowing that jdk >>> 10 or 11 will certainly add default methods to arrays, >>> we will want to have anonymous classes with arrays as host class in order to >>> acts as bridges/mixins. >>> >>> regards, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "harold seigel" >>>> ?: "Alan Bateman" , "Hotspot dev runtime" >>>> , >>>> core-libs-dev at openjdk.java.net >>>> Envoy?: Vendredi 2 Septembre 2016 17:03:34 >>>> Objet: Re: RFR 8058575: IllegalAccessError trying to access package-private >>>> class from VM anonymous class >>>> Thanks Alan. I'll go ahead and make that change. >>>> >>>> Harold >>>> >>>> >>>> On 9/2/2016 10:43 AM, Alan Bateman wrote: >>>>> On 02/09/2016 14:02, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this new fix for JDK-8058575. This fix requires that a >>>>>> VM anonymous class be in either the same package as its host class or >>>>>> be in the unnamed package. If the anonymous class is in the unnamed >>>>>> package then this fix puts it into its host class's package, ensuring >>>>>> that the anonymous class and its host class are in the same module. >>>>>> This fix also throws an IllegalArgumentException if the host class is >>>>>> an array class. >>>>>> >>>>>> Additionally, the type of field ClassFileParser::_host_klass was >>>>>> changed to InstanceKlass* and some comments were cleaned up. >>>>>> >>>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8058575 >>>>>> >>>>>> Open webrevs: >>>>>> >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8058575.jdk.3/ >>>>> In GetModuleTest then one clean-up is to change it to use >>>>> hostClass.getPackageName() and remove packageName(String). >>>>> >>>>> -Alan From mandy.chung at oracle.com Fri Sep 2 21:11:21 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 2 Sep 2016 14:11:21 -0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: > On Sep 2, 2016, at 2:50 AM, Patrick Reinhart wrote: > > Updated the existing http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01 ClassLoader::resources returning Stream is a good addition. 1386 * {@code IOException} occur getting the next resource element, it must be 1387 * wrapped into an {@code UncheckedIOException}. This has been mentioned in the paragraph above. This can be dropped from @apiNote. And add: @throws UncheckedIOException if I/O errors occur 1392 * @return An stream of resource {@link java.net.URL {@code URL}} {@code?} is not needed as @link generates the text in .. format. You can simply write: {@link java.net.URL URL} typo s/An/A I?m unsure if ?resource URL? clearly describes it. What about @return A stream of {@code URL} representing the location of the resources with the given name. 1399 * @since 1.9 should be @since 9. I have reservation in adding ClassLoader::systemResources static method. ClassLoader::getSystemResources is a convenient method that is equivalent to calling ClassLoader::getSystemClassLoader().getResources(), since the system class loader is never null. This method includes the resources in the application?s classpath. With the new ClassLoader::getPlatformClassLoader() method, a better way to get the ?system? resources from JDK (not the ones from the classpath), it can call: ClassLoader::getPlatformClassLoader().resources(); To get a Stream of URL of the resources visible to system class loader, it can call the new resources method: ClassLoader::getSystemClassLoader().resources(); So it doesn?t seem that the proposed systemResources static method is necessary. I suggest to combine the two tests in a single test, ResourcesStreamTest and add @bug JBS-id ResourcesSuccessCase 46 List resources = stream.collect(Collectors.toList()); 52 URL url = resources.get(0); You can check the size first. This can be simplified to use filter/findFirst to file the expected URL (yes need to call cl.resources again that is not an issue). Mandy P.S. process wide - RDP1 starts. This enhancement would need a sponsor and also request for approval [1]. I?m off for the long weekend and will follow up next Tuesday on this. [1] http://openjdk.java.net/projects/jdk9/fc-extension-process From john.r.rose at oracle.com Sat Sep 3 00:31:28 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 2 Sep 2016 17:31:28 -0700 Subject: RFR: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR In-Reply-To: <57C9B386.8070404@oracle.com> References: <56F0504A.4030204@oracle.com> <17BABD81-589E-42A0-B5F1-6B3BFE496392@oracle.com> <57C9B386.8070404@oracle.com> Message-ID: <7A7F0694-6A9D-4160-AC95-0F8EC7120C9A@oracle.com> > On Sep 2, 2016, at 10:14 AM, Kumar Srinivasan wrote: > > Hi John, > > Please review the amended patch, based on our discussions. > http://cr.openjdk.java.net/~ksrini/8151901/webrev.01/ > > Highlights: > * adjust the ordering of the InnerClass and BootStrapMethods computations > * enabled the test, and disabled memory leak check, which causes intermittent > failures, because of GC's ergonomics etc. > * added the two test files to golden.jar, just in case. > > Thanks > Kumar Much better; I'm glad we figured it out. This comment is wrong: + // remove the attr previously set, otherwise add the bsm and + // references as required Should be merely: + // add the bsm and references as required Reviewed! ? John From stuart.marks at oracle.com Sat Sep 3 00:41:07 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 2 Sep 2016 17:41:07 -0700 Subject: Participating on https://bugs.openjdk.java.net/browse/JDK-8156070 In-Reply-To: References: Message-ID: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Hi Jonathan, Welcome to OpenJDK, and thanks for your interest in JEP 269! I see you found a the subtasks of JDK-8156070, which is basically a container for a bunch of ideas for work on the JEP 269 collections. I took a quick look through them and this one seemed promising: JDK-8134373 explore potential uses of convenience factories within the JDK This isn't necessarily what you're looking for, as it's not working on the collections themselves, but instead it's attempting to put them to use within the JDK. I've added some notes to this bug about the dynamics of retrofitting usage into the JDK. Although it's not work directly on the collections, finding out where they can and cannot be applied would definitely be useful. It would also be useful, of course, if space savings could be realized by using them instead of conventional collections (where appropriate, of course). I'd also suggest looking beyond the JEP 269 tasks and at broader collections issues. To query for unresolved collections issues, go to bugs.openjdk.java.net; click Issues > Search for Issues; click Advanced; and paste the following query into the search box: project = jdk and component = core-libs and subcomponent = java.util:collections and resolution = unresolved (You should be able to run this query without having a JIRA account.) There's a wider variety of things here, which might turn up something more appropriate. (Then again, the choice might be overwhelming.) As Mark Reinhold mentioned, we're now in the "ramp-down phase 1" part of the JDK 9 schedule, so the proposal is to start restricting the kind of work that can be done. The low-priority bugs are probably off the table until JDK 10 (I'm not sure when that tree opens up), but some things like docs and tests are still fair game for the time being. (Also note that "the javadoc" is a mixture of specifications and informative documentation, and the differences between them aren't always apparent. Specification changes require a good deal more rigor, and they go through extra rounds of review.) Anyway, I hope you find something of interest. I'm going heads-down to prepare for JavaOne (Sep 18-22) but I'll try to keep an eye out for followup messages. s'marks [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html On 9/2/16 5:59 AM, Jonathan Bluett-Duncan wrote: > Hi Stuart Marks, > > I've been told by Martijn Verburg on the discuss mailing list that you're > the lead person for the Immutable Collections enhancements piece. > > Is there anything I can do to help you out with https://bugs.openjdk. > java.net/browse/JDK-8156070 or any other part of JEP 269 > ? > > Kind regards, > Jonathan > > On 28 August 2016 at 17:25, Jonathan Bluett-Duncan > wrote: > >> Hi all, >> >> My name is Jonathan, and it's my first time posting to this mailing list. >> >> I'm writing to you all as I'm rather interested in contributing to this >> area of the OpenJDK. Particularly, I'm thinking I'd quite like to help out >> with one of the subtasks for the Immutable Collections enhancements >> . However I don't have >> specific ideas and I don't know which of the subtasks would most closely >> match my skills and knowledge, so I wondered if I could have some guidance >> as to what I could do and how I can get started. >> >> FYI, I've partially read the contribution instructions >> , and I just submitted an OCA >> earlier today, so I don't expect to be actually ready to participate until >> I hear back from Oracle, but nonetheless I'd like to try to get the ball >> rolling as soon as possible. >> >> Kind regards, >> Jonathan Bluett-Duncan >> From stuart.marks at oracle.com Sat Sep 3 00:48:41 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 2 Sep 2016 17:48:41 -0700 Subject: RFR(m): 8159404: immutable collections should throw UOE unconditionally In-Reply-To: References: <34a6415a-f403-08b4-0cc1-83311199c920@oracle.com> Message-ID: <6c3701be-61b0-b965-4842-0448df9b2f8d@oracle.com> On 9/1/16 8:41 PM, Martin Buchholz wrote: > Looks good to me! Thanks! > Another idea for another day: I would like the immutable collections to be > more optimal than they currently are, even if we have to write more code. It > bugs me is that all of these collections have a modCount, despite never being > modified! (Even for mutable lists, I'm not sure the added safety of modCount > was worth the price) > > java -jar jol-cli-0.5-full.jar internals java.util.ImmutableCollections\$List1 > ... > java.util.ImmutableCollections$List1 object internals: > 0 12 (object header) N/A > 12 4 int AbstractList.modCount N/A > 16 4 Object List1.e0 N/A Yes, good idea. I've filed JDK-8165396 to track this. s'marks From rednaxelafx at gmail.com Sat Sep 3 02:41:08 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 2 Sep 2016 19:41:08 -0700 Subject: A bit of sugar for j.u.c.locks with try-with-resources? Message-ID: Hi core-libs developers, I mostly live down in the VM world, but recently I've been playing with j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API with the try-with-resources syntax. I wonder if anybody has brought this topic up before; apologies if there had been. >From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical usage: class X { private final ReentrantLock lock = new ReentrantLock(); // ... public void m() { lock.lock(); // block until condition holds try { // ... method body } finally { lock.unlock() } } } The try...finally construction really pops out as a try-with-resources candidate. So what if we retrofit that with something like: class X { private final ReentrantLock lock = new ReentrantLock(); // ... public void m() { try (lock.lock()) { // block until condition holds // ... method body } // automatic unlock at the end } } Assuming lock.lock() returns a temporary wrapper object (let's call it a "Locker" for this discussion), where Locker implements AutoCloseable, and its close() method calls lock.unlock(). That'll make the API look and feel quite similar to the built-in "synchronized () { ... }" syntax. With escape analysis and scalar replacement implemented correctly in the VM, this temporary Locker object wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it feels like a pure win to me. What do you think? Best regards, Kris (OpenJDK username: kmo) From vitalyd at gmail.com Sat Sep 3 02:55:19 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 2 Sep 2016 22:55:19 -0400 Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: References: Message-ID: Hi Kris, On Friday, September 2, 2016, Krystal Mok wrote: > Hi core-libs developers, > > I mostly live down in the VM world, but recently I've been playing with > j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API > with the try-with-resources syntax. I wonder if anybody has brought this > topic up before; apologies if there had been. > > From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical > usage: > > class X { > private final ReentrantLock lock = new ReentrantLock(); > // ... > > public void m() { > lock.lock(); // block until condition holds > try { > // ... method body > } finally { > lock.unlock() > } > } > } > > The try...finally construction really pops out as a try-with-resources > candidate. > > So what if we retrofit that with something like: > > class X { > private final ReentrantLock lock = new ReentrantLock(); > // ... > > public void m() { > try (lock.lock()) { // block until condition holds > // ... method body > } // automatic unlock at the end > } > } This is Java 9 syntax right? Java 7-8 require an assignment to a local in the TWR block. > > Assuming lock.lock() returns a temporary wrapper object (let's call it a > "Locker" for this discussion), where Locker implements AutoCloseable, and > its close() method calls lock.unlock(). > That'll make the API look and feel quite similar to the built-in > "synchronized () { ... }" syntax. With escape analysis and scalar > replacement implemented correctly in the VM, this temporary Locker object > wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it > feels like a pure win to me. > > What do you think? So using TWR with scoped objects, such as this, is used quite a bit; I've seen this idiom many times, and have used it myself. Now, what's the value add to have this in the JDK? One can write such a Locker themselves quite easily. I also don't hold as much confidence in EA as you, apparently - it's too brittle and unpredictable in its current form, IMHO. Of course when the allocation doesn't matter, that part isn't a big deal. My $.02. > > Best regards, > Kris (OpenJDK username: kmo) > -- Sent from my phone From rednaxelafx at gmail.com Sat Sep 3 03:28:03 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 2 Sep 2016 20:28:03 -0700 Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: References: Message-ID: Hi Vitaly, Thanks for your comments! On Fri, Sep 2, 2016 at 7:55 PM, Vitaly Davidovich wrote: > Hi Kris, > > > On Friday, September 2, 2016, Krystal Mok wrote: > >> Hi core-libs developers, >> >> I mostly live down in the VM world, but recently I've been playing with >> j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API >> with the try-with-resources syntax. I wonder if anybody has brought this >> topic up before; apologies if there had been. >> >> From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical >> usage: >> >> class X { >> private final ReentrantLock lock = new ReentrantLock(); >> // ... >> >> public void m() { >> lock.lock(); // block until condition holds >> try { >> // ... method body >> } finally { >> lock.unlock() >> } >> } >> } >> >> The try...finally construction really pops out as a try-with-resources >> candidate. >> >> So what if we retrofit that with something like: >> >> class X { >> private final ReentrantLock lock = new ReentrantLock(); >> // ... >> >> public void m() { >> try (lock.lock()) { // block until condition holds >> // ... method body >> } // automatic unlock at the end >> } >> } > > This is Java 9 syntax right? Java 7-8 require an assignment to a local in > the TWR block. > Yes, this is Java 9 syntax, although I was actually intending to use the old Java 7/8 syntax as the example...got too used to the new goodies. > >> Assuming lock.lock() returns a temporary wrapper object (let's call it a >> "Locker" for this discussion), where Locker implements AutoCloseable, and >> its close() method calls lock.unlock(). >> That'll make the API look and feel quite similar to the built-in >> "synchronized () { ... }" syntax. With escape analysis and scalar >> replacement implemented correctly in the VM, this temporary Locker object >> wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it >> feels like a pure win to me. >> >> What do you think? > > So using TWR with scoped objects, such as this, is used quite a bit; I've > seen this idiom many times, and have used it myself. > > Now, what's the value add to have this in the JDK? One can write such a > Locker themselves quite easily. > > Having the Locker integrated into the API makes the experience smoother. If we write our own wrapper, it might look like: try (locker = new Locker(lock)) { // ... method body } Which is okay-ish. Or maybe with the help of some statically imported helper method and the Java 9 syntax: try (locker(lock)) { // ... } Hmm...I can live with that. I also don't hold as much confidence in EA as you, apparently - it's too > brittle and unpredictable in its current form, IMHO. Of course when the > allocation doesn't matter, that part isn't a big deal. > > Haha, I know how C2's EA isn't giving everybody the kind of confidence they want. But for simple cases like this it should work nicely (and if not, let's fix it :-) And let's say when HotSpot gets a new JIT compiler, it'll have a more effective EA. All the better. Thanks, Kris > My $.02. > >> >> Best regards, >> Kris (OpenJDK username: kmo) >> > > > -- > Sent from my phone > From david.holmes at oracle.com Sat Sep 3 07:17:59 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 3 Sep 2016 17:17:59 +1000 Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: References: Message-ID: <68a4273b-cf94-5038-c7c2-d407f23a037d@oracle.com> Hi Kris, On 3/09/2016 12:41 PM, Krystal Mok wrote: > Hi core-libs developers, > > I mostly live down in the VM world, but recently I've been playing with > j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API > with the try-with-resources syntax. I wonder if anybody has brought this > topic up before; apologies if there had been. Yes brought up a few times. :) https://dzone.com/articles/project-coin-try-resources If the syntax is more permissive now then it might be more feasible. Cheers, David > From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical usage: > > class X { > private final ReentrantLock lock = new ReentrantLock(); > // ... > > public void m() { > lock.lock(); // block until condition holds > try { > // ... method body > } finally { > lock.unlock() > } > } > } > > The try...finally construction really pops out as a try-with-resources > candidate. > > So what if we retrofit that with something like: > > class X { > private final ReentrantLock lock = new ReentrantLock(); > // ... > > public void m() { > try (lock.lock()) { // block until condition holds > // ... method body > } // automatic unlock at the end > } > } > > Assuming lock.lock() returns a temporary wrapper object (let's call it a > "Locker" for this discussion), where Locker implements AutoCloseable, and > its close() method calls lock.unlock(). > That'll make the API look and feel quite similar to the built-in > "synchronized () { ... }" syntax. With escape analysis and scalar > replacement implemented correctly in the VM, this temporary Locker object > wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it > feels like a pure win to me. > > What do you think? > > Best regards, > Kris (OpenJDK username: kmo) > From rednaxelafx at gmail.com Sat Sep 3 07:27:11 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 3 Sep 2016 00:27:11 -0700 Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: <68a4273b-cf94-5038-c7c2-d407f23a037d@oracle.com> References: <68a4273b-cf94-5038-c7c2-d407f23a037d@oracle.com> Message-ID: Hi David, Thanks for the link! I'd reckon it's been brought up before, but I guess I didn't use the right keywords to get a good search. That's good enough history for me. It explains every issue I've thought about. The new Java 9 TWR syntax is still fairly limited, in that it still doesn't support the try (locker(lock)) { ... } usage. The new TWR syntax was just extended to allow effectively final variables in the TWR header... Best regards, Kris On Sat, Sep 3, 2016 at 12:17 AM, David Holmes wrote: > Hi Kris, > > On 3/09/2016 12:41 PM, Krystal Mok wrote: > >> Hi core-libs developers, >> >> I mostly live down in the VM world, but recently I've been playing with >> j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API >> with the try-with-resources syntax. I wonder if anybody has brought this >> topic up before; apologies if there had been. >> > > Yes brought up a few times. :) > > https://dzone.com/articles/project-coin-try-resources > > If the syntax is more permissive now then it might be more feasible. > > Cheers, > David > > > From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical >> usage: >> >> class X { >> private final ReentrantLock lock = new ReentrantLock(); >> // ... >> >> public void m() { >> lock.lock(); // block until condition holds >> try { >> // ... method body >> } finally { >> lock.unlock() >> } >> } >> } >> >> The try...finally construction really pops out as a try-with-resources >> candidate. >> >> So what if we retrofit that with something like: >> >> class X { >> private final ReentrantLock lock = new ReentrantLock(); >> // ... >> >> public void m() { >> try (lock.lock()) { // block until condition holds >> // ... method body >> } // automatic unlock at the end >> } >> } >> >> Assuming lock.lock() returns a temporary wrapper object (let's call it a >> "Locker" for this discussion), where Locker implements AutoCloseable, and >> its close() method calls lock.unlock(). >> That'll make the API look and feel quite similar to the built-in >> "synchronized () { ... }" syntax. With escape analysis and scalar >> replacement implemented correctly in the VM, this temporary Locker object >> wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it >> feels like a pure win to me. >> >> What do you think? >> >> Best regards, >> Kris (OpenJDK username: kmo) >> >> From ivan.gerasimov at oracle.com Sat Sep 3 10:23:28 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 3 Sep 2016 13:23:28 +0300 Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: References: Message-ID: <27420d9e-08de-ecac-d629-9828886b5747@oracle.com> Hi Krystal! On 03.09.2016 5:41, Krystal Mok wrote: > Hi core-libs developers, > > I mostly live down in the VM world, but recently I've been playing with > j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API > with the try-with-resources syntax. I wonder if anybody has brought this > topic up before; apologies if there had been. > > >From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical usage: > > class X { > private final ReentrantLock lock = new ReentrantLock(); > // ... > > public void m() { > lock.lock(); // block until condition holds > try { > // ... method body > } finally { > lock.unlock() > } > } > } It could be written as public void m() { lock.lock(); // block until condition holds try (Closeable unlocker = lock::unlock) { // ... method body } } This would save a couple of lines of code. With kind regards, Ivan > The try...finally construction really pops out as a try-with-resources > candidate. > > So what if we retrofit that with something like: > > class X { > private final ReentrantLock lock = new ReentrantLock(); > // ... > > public void m() { > try (lock.lock()) { // block until condition holds > // ... method body > } // automatic unlock at the end > } > } > > Assuming lock.lock() returns a temporary wrapper object (let's call it a > "Locker" for this discussion), where Locker implements AutoCloseable, and > its close() method calls lock.unlock(). > That'll make the API look and feel quite similar to the built-in > "synchronized () { ... }" syntax. With escape analysis and scalar > replacement implemented correctly in the VM, this temporary Locker object > wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it > feels like a pure win to me. > > What do you think? > > Best regards, > Kris (OpenJDK username: kmo) > From forax at univ-mlv.fr Sat Sep 3 11:06:59 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 3 Sep 2016 13:06:59 +0200 (CEST) Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: <27420d9e-08de-ecac-d629-9828886b5747@oracle.com> References: <27420d9e-08de-ecac-d629-9828886b5747@oracle.com> Message-ID: <1172519071.2364857.1472900819157.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Ivan Gerasimov" > ?: "Krystal Mok" , "core-libs-dev" > Envoy?: Samedi 3 Septembre 2016 12:23:28 > Objet: Re: A bit of sugar for j.u.c.locks with try-with-resources? > Hi Krystal! > > On 03.09.2016 5:41, Krystal Mok wrote: >> Hi core-libs developers, >> >> I mostly live down in the VM world, but recently I've been playing with >> j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API >> with the try-with-resources syntax. I wonder if anybody has brought this >> topic up before; apologies if there had been. >> >> >From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical usage: >> >> class X { >> private final ReentrantLock lock = new ReentrantLock(); >> // ... >> >> public void m() { >> lock.lock(); // block until condition holds >> try { >> // ... method body >> } finally { >> lock.unlock() >> } >> } >> } > It could be written as > public void m() { > lock.lock(); // block until condition holds > try (Closeable unlocker = lock::unlock) { > // ... method body > } > } > > This would save a couple of lines of code. but it does an allocation (if the escape analysis fails), i think it's better to wait for proper value types :) > > With kind regards, > Ivan regards, R?mi > >> The try...finally construction really pops out as a try-with-resources >> candidate. >> >> So what if we retrofit that with something like: >> >> class X { >> private final ReentrantLock lock = new ReentrantLock(); >> // ... >> >> public void m() { >> try (lock.lock()) { // block until condition holds >> // ... method body >> } // automatic unlock at the end >> } >> } >> >> Assuming lock.lock() returns a temporary wrapper object (let's call it a >> "Locker" for this discussion), where Locker implements AutoCloseable, and >> its close() method calls lock.unlock(). >> That'll make the API look and feel quite similar to the built-in >> "synchronized () { ... }" syntax. With escape analysis and scalar >> replacement implemented correctly in the VM, this temporary Locker object >> wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it >> feels like a pure win to me. >> >> What do you think? >> >> Best regards, >> Kris (OpenJDK username: kmo) From vitalyd at gmail.com Sat Sep 3 13:02:03 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Sat, 3 Sep 2016 09:02:03 -0400 Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: References: Message-ID: On Friday, September 2, 2016, Krystal Mok wrote: > Hi Vitaly, > > Thanks for your comments! > > On Fri, Sep 2, 2016 at 7:55 PM, Vitaly Davidovich > wrote: > >> Hi Kris, >> >> >> On Friday, September 2, 2016, Krystal Mok > > wrote: >> >>> Hi core-libs developers, >>> >>> I mostly live down in the VM world, but recently I've been playing with >>> j.u.c.locks a bit, and saw that there's an opportunity to retrofit the >>> API >>> with the try-with-resources syntax. I wonder if anybody has brought this >>> topic up before; apologies if there had been. >>> >>> From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical >>> usage: >>> >>> class X { >>> private final ReentrantLock lock = new ReentrantLock(); >>> // ... >>> >>> public void m() { >>> lock.lock(); // block until condition holds >>> try { >>> // ... method body >>> } finally { >>> lock.unlock() >>> } >>> } >>> } >>> >>> The try...finally construction really pops out as a try-with-resources >>> candidate. >>> >>> So what if we retrofit that with something like: >>> >>> class X { >>> private final ReentrantLock lock = new ReentrantLock(); >>> // ... >>> >>> public void m() { >>> try (lock.lock()) { // block until condition holds >>> // ... method body >>> } // automatic unlock at the end >>> } >>> } >> >> This is Java 9 syntax right? Java 7-8 require an assignment to a local in >> the TWR block. >> > > Yes, this is Java 9 syntax, although I was actually intending to use the > old Java 7/8 syntax as the example...got too used to the new goodies. > > >> >>> Assuming lock.lock() returns a temporary wrapper object (let's call it a >>> "Locker" for this discussion), where Locker implements AutoCloseable, and >>> its close() method calls lock.unlock(). >>> That'll make the API look and feel quite similar to the built-in >>> "synchronized () { ... }" syntax. With escape analysis and scalar >>> replacement implemented correctly in the VM, this temporary Locker object >>> wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it >>> feels like a pure win to me. >>> >>> What do you think? >> >> So using TWR with scoped objects, such as this, is used quite a bit; I've >> seen this idiom many times, and have used it myself. >> >> Now, what's the value add to have this in the JDK? One can write such a >> Locker themselves quite easily. >> >> Having the Locker integrated into the API makes the experience smoother. > If we write our own wrapper, it might look like: > > try (locker = new Locker(lock)) { > // ... method body > } > > Which is okay-ish. Or maybe with the help of some statically imported > helper method and the Java 9 syntax: > > try (locker(lock)) { > // ... > } > > Hmm...I can live with that. > What about just the following (in Java 9): try (new Locker(lock)) { // } > > I also don't hold as much confidence in EA as you, apparently - it's too >> brittle and unpredictable in its current form, IMHO. Of course when the >> allocation doesn't matter, that part isn't a big deal. >> >> Haha, I know how C2's EA isn't giving everybody the kind of confidence > they want. But for simple cases like this it should work nicely (and if > not, let's fix it :-) > Let's! :) As of right now, I consider EA as a bonus but never rely on it. Even simple cases like this, if inside a method that's considered too big for EA to run (particularly after inlining), will fail. > > And let's say when HotSpot gets a new JIT compiler, it'll have a more > effective EA. All the better. > You mean Graal? I'm with Remi - value types will make this much more palatable from an allocation perspective (and generally make more sense for uses like this than full blown reference types). > > Thanks, > Kris > > >> My $.02. >> >>> >>> Best regards, >>> Kris (OpenJDK username: kmo) >>> >> >> >> -- >> Sent from my phone >> > > -- Sent from my phone From joe.darcy at oracle.com Sat Sep 3 16:33:34 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 3 Sep 2016 09:33:34 -0700 Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: References: <68a4273b-cf94-5038-c7c2-d407f23a037d@oracle.com> Message-ID: <027682dd-508a-bbbe-28a9-2be5c4f2c483@oracle.com> On 9/3/2016 12:27 AM, Krystal Mok wrote: > Hi David, > > Thanks for the link! I'd reckon it's been brought up before, but I guess I > didn't use the right keywords to get a good search. That's good enough > history for me. It explains every issue I've thought about. > > The new Java 9 TWR syntax is still fairly limited, in that it still doesn't > support the try (locker(lock)) { ... } usage. The new TWR syntax was just > extended to allow effectively final variables in the TWR header... > > Originally try-with-resources allowed a general expression to be given for the resource. This was found to be problematic and thus the structure was limited to working on variables, originally fresh variables as in 7, now alternatively final and effectively final variables as of 9. Please see the coin-dev archives for discussions of this point. Cheers, -Joe From forax at univ-mlv.fr Sat Sep 3 17:54:23 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 3 Sep 2016 19:54:23 +0200 (CEST) Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: <57CB03FB.6080600@javaspecialists.eu> References: <27420d9e-08de-ecac-d629-9828886b5747@oracle.com> <1172519071.2364857.1472900819157.JavaMail.zimbra@u-pem.fr> <57CB03FB.6080600@javaspecialists.eu> Message-ID: <189893537.2388178.1472925263506.JavaMail.zimbra@u-pem.fr> > De: "Dr Heinz M. Kabutz" > ?: "Remi Forax" > Cc: "Ivan Gerasimov" , "core-libs-dev" > > Envoy?: Samedi 3 Septembre 2016 19:10:19 > Objet: Re: A bit of sugar for j.u.c.locks with try-with-resources? > Not sure why the discussion keeps on going to EA with try-with-resource with > locks. > 1. There is no reason to construct objects, for example just write this class: > import java.util.concurrent.locks.*; > public class AutoLock implements AutoCloseable { > private final Lock lock; > public AutoLock(Lock lock) { > this.lock = lock; > } > public AutoLock lock() { > lock.lock(); > return this; > } > public void close() { > lock.unlock(); > } > } > And then use it as such: > import java.util.concurrent.locks.*; > public class AutoLockTest { > private final Lock lock = new ReentrantLock(); > private final AutoLock al = new AutoLock(lock); > public void doSomething() { > try (AutoLock temp = al.lock()) { > // do something on the state > } > } > } > No objects are constructed. yes, you still pay the cost of an extra field in the class, an extra indirection when calling lock and unlock and an extra nullcheck (this one is hidden in the implementation of a try-with-resources). You may answer that ReentrantLock already pay the cost of an indirection over an AbstractQueuedSynchronizer (because a lock can be fair or unfair) so i suppose that an unfair implementation of AutoLock that directly extends AbstractQueuedSynchronizer should be faster or as fast as a ReentrantLock. > 2. No one uses ReentrantLock anyway (unless they absolutely have to). See the > comment in Java 9 CopyOnWriteArrayList :-) > /** > * The lock protecting all mutators. (We have a mild preference > * for builtin monitors over ReentrantLock when either will do.) > */ > final transient Object lock = new Object(); yes, synchronized is more versatile until you have contention, want fairness, a tryLock or several Conditions. > 3. If you were to construct objects in the TWR block, they would be escaped in > my experience, except in the one case where there are multiple threads trying > to lock at the same time. However, in that case, ReentrantLock will anyway > create objects to manage the contention. But it really is a non-issue, since it > is trivial to code to not construct any objects with the TWR block in the first > place. > I keep getting asked this question all over the world. Personally I think it's a > non-issue, since the code is so trivial to write yourself, plus so few people > would use ReentrantLock anyway. > Regards regards, R?mi > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Sun/Oracle Java Champion since 2005 > JavaOne Rock Star Speaker 2012 http://www.javaspecialists.eu Tel: +30 69 75 595 > 262 > Skype: kabutz > Remi Forax wrote: >> ----- Mail original ----- >>> De: "Ivan Gerasimov" ?: "Krystal Mok" >>> , "core-libs-dev" >>> Envoy?: Samedi 3 Septembre 2016 12:23:28 >>> Objet: Re: A bit of sugar for j.u.c.locks with try-with-resources? >>> Hi Krystal! >>> On 03.09.2016 5:41, Krystal Mok wrote: >>>> Hi core-libs developers, >>>> I mostly live down in the VM world, but recently I've been playing with >>>> j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API >>>> with the try-with-resources syntax. I wonder if anybody has brought this >>>> topic up before; apologies if there had been. >>>> >From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical usage: >>>> class X { >>>> private final ReentrantLock lock = new ReentrantLock(); >>>> // ... >>>> public void m() { >>>> lock.lock(); // block until condition holds >>>> try { >>>> // ... method body >>>> } finally { >>>> lock.unlock() >>>> } >>>> } >>>> } >>> It could be written as >>> public void m() { >>> lock.lock(); // block until condition holds >>> try (Closeable unlocker = lock::unlock) { >>> // ... method body >>> } >>> } >>> This would save a couple of lines of code. >> but it does an allocation (if the escape analysis fails), >> i think it's better to wait for proper value types :) >>> With kind regards, >>> Ivan >> regards, >> R?mi >>>> The try...finally construction really pops out as a try-with-resources >>>> candidate. >>>> So what if we retrofit that with something like: >>>> class X { >>>> private final ReentrantLock lock = new ReentrantLock(); >>>> // ... >>>> public void m() { >>>> try (lock.lock()) { // block until condition holds >>>> // ... method body >>>> } // automatic unlock at the end >>>> } >>>> } >>>> Assuming lock.lock() returns a temporary wrapper object (let's call it a >>>> "Locker" for this discussion), where Locker implements AutoCloseable, and >>>> its close() method calls lock.unlock(). >>>> That'll make the API look and feel quite similar to the built-in >>>> "synchronized () { ... }" syntax. With escape analysis and scalar >>>> replacement implemented correctly in the VM, this temporary Locker object >>>> wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it >>>> feels like a pure win to me. >>>> What do you think? >>>> Best regards, >>>> Kris (OpenJDK username: kmo) From vitalyd at gmail.com Sat Sep 3 18:22:28 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Sat, 3 Sep 2016 14:22:28 -0400 Subject: A bit of sugar for j.u.c.locks with try-with-resources? In-Reply-To: <189893537.2388178.1472925263506.JavaMail.zimbra@u-pem.fr> References: <27420d9e-08de-ecac-d629-9828886b5747@oracle.com> <1172519071.2364857.1472900819157.JavaMail.zimbra@u-pem.fr> <57CB03FB.6080600@javaspecialists.eu> <189893537.2388178.1472925263506.JavaMail.zimbra@u-pem.fr> Message-ID: On Saturday, September 3, 2016, wrote: > > De: "Dr Heinz M. Kabutz" > > > ?: "Remi Forax" > > > Cc: "Ivan Gerasimov" >, > "core-libs-dev" > > > > > Envoy?: Samedi 3 Septembre 2016 19:10:19 > > Objet: Re: A bit of sugar for j.u.c.locks with try-with-resources? > > > Not sure why the discussion keeps on going to EA with try-with-resource > with > > locks. > > > 1. There is no reason to construct objects, for example just write this > class: > > > import java.util.concurrent.locks.*; > > > public class AutoLock implements AutoCloseable { > > private final Lock lock; > > > public AutoLock(Lock lock) { > > this.lock = lock; > > } > > > public AutoLock lock() { > > lock.lock(); > > return this; > > } > > > public void close() { > > lock.unlock(); > > } > > } > > > And then use it as such: > > > import java.util.concurrent.locks.*; > > > public class AutoLockTest { > > private final Lock lock = new ReentrantLock(); > > private final AutoLock al = new AutoLock(lock); > > > public void doSomething() { > > try (AutoLock temp = al.lock()) { > > // do something on the state > > } > > } > > } > > > No objects are constructed. > yes, you still pay the cost of an extra field in the class, an extra > indirection when calling lock and unlock and an extra nullcheck (this one > is hidden in the implementation of a try-with-resources). > You may answer that ReentrantLock already pay the cost of an indirection > over an AbstractQueuedSynchronizer (because a lock can be fair or unfair) > so i suppose that an unfair implementation of AutoLock that directly > extends AbstractQueuedSynchronizer should be faster or as fast as a > ReentrantLock. Right. This particular example can be worked around by having an extra field. But it's a hack that besides the issues Remi lists, extends an object's lifetime unnecessarily. You want sugar/ergonomics for the try/finally usage, not anything beyond that. > > > 2. No one uses ReentrantLock anyway (unless they absolutely have to). > See the > > comment in Java 9 CopyOnWriteArrayList :-) > > /** > > * The lock protecting all mutators. (We have a mild preference > > * for builtin monitors over ReentrantLock when either will do.) > > */ > > final transient Object lock = new Object(); > yes, synchronized is more versatile until you have contention, want > fairness, a tryLock or several Conditions. Or lock and unlock aren't in the same scope/control flow. > > > 3. If you were to construct objects in the TWR block, they would be > escaped in > > my experience, except in the one case where there are multiple threads > trying > > to lock at the same time. However, in that case, ReentrantLock will > anyway > > create objects to manage the contention. But it really is a non-issue, > since it > > is trivial to code to not construct any objects with the TWR block in > the first > > place. Again, in this particular case it's a non issue besides the downsides already mentioned. Not all cases will be like that (e.g. you may receive a resource as an arg and not have access to it anywhere else, and want the ergonomics). > > > I keep getting asked this question all over the world. Personally I > think it's a > > non-issue, since the code is so trivial to write yourself, plus so few > people > > would use ReentrantLock anyway. > > Regards I know Kris started the thread in the context of a lock (and let's not forget it could be some other impl besides RL), but there's a more general pattern that's being discussed. > > regards, > R?mi > > > Heinz > > -- > > Dr Heinz M. Kabutz (PhD CompSci) > > Author of "The Java(tm) Specialists' Newsletter" > > Sun/Oracle Java Champion since 2005 > > JavaOne Rock Star Speaker 2012 http://www.javaspecialists.eu Tel: +30 > 69 75 595 > > 262 > > Skype: kabutz > > > Remi Forax wrote: > >> ----- Mail original ----- > > >>> De: "Ivan Gerasimov" > ?: > "Krystal Mok" > >>> > , "core-libs-dev" < > core-libs-dev at openjdk.java.net > > >>> Envoy?: Samedi 3 Septembre 2016 12:23:28 > >>> Objet: Re: A bit of sugar for j.u.c.locks with try-with-resources? > > >>> Hi Krystal! > > >>> On 03.09.2016 5:41, Krystal Mok wrote: > > >>>> Hi core-libs developers, > > >>>> I mostly live down in the VM world, but recently I've been playing > with > >>>> j.u.c.locks a bit, and saw that there's an opportunity to retrofit > the API > >>>> with the try-with-resources syntax. I wonder if anybody has brought > this > >>>> topic up before; apologies if there had been. > > >>>> >From the JavaDoc of j.u.c.l.ReentrantLock, the following is a > typical usage: > > >>>> class X { > >>>> private final ReentrantLock lock = new ReentrantLock(); > >>>> // ... > > >>>> public void m() { > >>>> lock.lock(); // block until condition holds > >>>> try { > >>>> // ... method body > >>>> } finally { > >>>> lock.unlock() > >>>> } > >>>> } > >>>> } > > >>> It could be written as > >>> public void m() { > >>> lock.lock(); // block until condition holds > >>> try (Closeable unlocker = lock::unlock) { > >>> // ... method body > >>> } > >>> } > > >>> This would save a couple of lines of code. > > >> but it does an allocation (if the escape analysis fails), > >> i think it's better to wait for proper value types :) > > >>> With kind regards, > >>> Ivan > > >> regards, > >> R?mi > > >>>> The try...finally construction really pops out as a try-with-resources > >>>> candidate. > > >>>> So what if we retrofit that with something like: > > >>>> class X { > >>>> private final ReentrantLock lock = new ReentrantLock(); > >>>> // ... > > >>>> public void m() { > >>>> try (lock.lock()) { // block until condition holds > >>>> // ... method body > >>>> } // automatic unlock at the end > >>>> } > >>>> } > > >>>> Assuming lock.lock() returns a temporary wrapper object (let's call > it a > >>>> "Locker" for this discussion), where Locker implements AutoCloseable, > and > >>>> its close() method calls lock.unlock(). > >>>> That'll make the API look and feel quite similar to the built-in > >>>> "synchronized () { ... }" syntax. With escape analysis and scalar > >>>> replacement implemented correctly in the VM, this temporary Locker > object > >>>> wouldn't incur much (or any) runtime cost after optimized JIT'ing, so > it > >>>> feels like a pure win to me. > > >>>> What do you think? > > >>>> Best regards, > >>>> Kris (OpenJDK username: kmo) > -- Sent from my phone From patrick at reini.net Sat Sep 3 19:55:00 2016 From: patrick at reini.net (Patrick Reinhart) Date: Sat, 3 Sep 2016 21:55:00 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: Hi Mandy, The current changes can be found here: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.02 On 02.09.2016 23:11, Mandy Chung wrote: >> On Sep 2, 2016, at 2:50 AM, Patrick Reinhart wrote: >> >> Updated the existing http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01 > ClassLoader::resources returning Stream is a good addition. > > 1386 * {@code IOException} occur getting the next resource element, it must be > 1387 * wrapped into an {@code UncheckedIOException}. > > This has been mentioned in the paragraph above. This can be dropped from @apiNote. And add: > > @throws UncheckedIOException if I/O errors occur There was already an discussion about this with Alan Bateman: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042792.html So I do not know is the best solution for this... > 1392 * @return An stream of resource {@link java.net.URL {@code URL}} > > {@code?} is not needed as @link generates the text in .. format. You can simply write: > {@link java.net.URL URL} > > typo s/An/A I have that fixed those now in the actual revision and hopefully using the correct "a" all the times. > I?m unsure if ?resource URL? clearly describes it. What about > @return A stream of {@code URL} representing the location of the resources with the given name. > > 1399 * @since 1.9 > > should be @since 9. Also this has been fixed - old habits ;-) > I have reservation in adding ClassLoader::systemResources static method. > > ClassLoader::getSystemResources is a convenient method that is equivalent to calling ClassLoader::getSystemClassLoader().getResources(), since the system class loader is never null. This method includes the resources in the application?s classpath. > > With the new ClassLoader::getPlatformClassLoader() method, a better way to get the ?system? resources from JDK (not the ones from the classpath), it can call: > ClassLoader::getPlatformClassLoader().resources(); > > To get a Stream of URL of the resources visible to system class loader, it can call the new resources method: > ClassLoader::getSystemClassLoader().resources(); > > So it doesn?t seem that the proposed systemResources static method is necessary. Hmm... We may have overlooked this, when we started by just looking into the API changes in general. I did those with Paul Sandoz in more deep in the following thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042752.html and this proposal is based on the "go" from Paul here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/043012.html > I suggest to combine the two tests in a single test, ResourcesStreamTest and add @bug JBS-id > > ResourcesSuccessCase > > 46 List resources = stream.collect(Collectors.toList()); > 52 URL url = resources.get(0); > > You can check the size first. This can be simplified to use filter/findFirst to file the expected URL (yes need to call cl.resources again that is not an issue). I have done this also in the new revision > Mandy > P.S. process wide - RDP1 starts. This enhancement would need a sponsor and also request for approval [1]. I?m off for the long weekend and will follow up next Tuesday on this. > > [1] http://openjdk.java.net/projects/jdk9/fc-extension-process - Patrick From spliterator at gmail.com Sat Sep 3 22:06:16 2016 From: spliterator at gmail.com (Stefan Zobel) Date: Sun, 4 Sep 2016 00:06:16 +0200 Subject: RFR 8164691 Stream specification clarifications for iterate and collect In-Reply-To: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> References: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> Message-ID: Hi Paul, there's a small copy & paste error in the code samples in Double/Int/LongStream#iterate() Example DoubleStream#iterate: * 

{@code
     *     for (T index=seed; hasNext.test(index); index = next.apply(index)) {
     *         ...
     *     }
     * }
That should be * for (double index=seed; hasNext.test(index); index = next.applyAsDouble(index)) { Same for Int/LongStream#iterate() Regards, Stefan 2016-08-27 1:13 GMT+02:00 Paul Sandoz : > Hi, > > Please review some minor tweaks to the stream specification: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164691-stream-iterate-collect-spec-updates/webrev/index.html > > The first tweak is to clarify the iterate methods and HB edges between function calls, the functions could potentially be stateful, they will never be called concurrently due to the nature of the source, but may be called in different threads. > > The second tweak is to the three-arg collect method. The combiner of result containers neglected to state how result containers should be merged. > > Thanks, > Paul. From david.simms at oracle.com Mon Sep 5 08:02:41 2016 From: david.simms at oracle.com (David Simms) Date: Mon, 5 Sep 2016 10:02:41 +0200 Subject: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame In-Reply-To: <8082b3e4-1983-8a03-f2c8-b007c8ac91db@oracle.com> References: <6b96634e-a9c0-47b2-c17b-f6b2057a5f14@oracle.com> <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> <58f4a6da-b3d0-a1c7-9086-a34883e6b590@oracle.com> <70aacfa1-ffa8-a4a9-8092-4cc12949d027@oracle.com> <8082b3e4-1983-8a03-f2c8-b007c8ac91db@oracle.com> Message-ID: <579cd983-aabe-a611-b365-74c21ceeb590@oracle.com> Hi David, I can make the checks silent, but the launcher itself produces warnings from checked JNI (it's use of unchecked Java method invocations), and this causes the test (http://cr.openjdk.java.net/~dsimms/8164086/webrev2/hotspot/test/runtime/jni/checked/TestCheckedJniExceptionCheck.java.html) to fail, with unchecked exception warnings popping up in the output. But yeah, I could adjust the test the ignore any start-up warnings and drop the changes to the launcher... Thanks /David Simms On 29/08/2016 9:24 a.m., David Holmes wrote: > Hi David, > > I still do not understand why you think you need to make any changes > in libjli ?? Certainly I do not think you should be printing anything > about exceptions. > > Thanks, > David H. > > On 26/08/2016 9:55 PM, David Simms wrote: >> Hi David, >> >> Updated webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev2/ >> >> On 26/08/16 02:27, David Holmes wrote: >>> Hi David, >>> >>> I'm missing some pieces of this puzzle I'm afraid. >>> >>> On 25/08/2016 8:05 PM, David Simms wrote: >>>> >>>> Updated the webrev here: >>>> http://cr.openjdk.java.net/~dsimms/8164086/webrev1/ >>> >>> hotspot/src/share/vm/prims/whitebox.cpp >>> >>> First I'm not sure that Whitebox isn't a special case here that could >>> be handled in the WB_START/END macros - see below. >>> >>> More generally you state below that the transition from native back to >>> the VM doesn't have to do anything with the pending_exception_check >>> flag because well behaved native code in that context will explicitly >>> check for exceptions, and so the pending-exception-check will already >>> be disabled before returning to Java. First, if that is the case then >>> we should assert that it is so in the native->VM return transition. >> >> Agreed, inserted assert. >> >>> >>> Second though, it doesn't seem to be the case in Whitebox because the >>> CHECK_JNI_EXCEPTION_ macro simply calls HAS_PENDING_EXCEPTION and so >>> won't touch the pending-exception-check flag. ?? >> >> Doh, you are correct...I mistook this for the CHECK_JNI_EXCEPTION macro >> in "java.c" which does perform check... >> >>> >>> It was a good pick up that some whitebox code was using values that >>> might be NULL because an exception had occurred. There are a couple of >>> changes that are unnecessary though: >>> >>> 1235 result = env->NewObjectArray(5, clazz, NULL); >>> 1236 CHECK_JNI_EXCEPTION_(env, NULL); >>> 1237 if (result == NULL) { >>> 1238 return result; >>> 1239 } >>> >>> (and similarly at 1322) >>> >>> result will be NULL iff there is a pending exception; and vice-versa. >>> So the existing check for NULL suffices for correctness. If you want >>> to check exceptions for the side-effect of clearing the >>> pending-exception-check flag then lines 1237-1239 can be deleted. >>> However I would suggest that if you truly do want to clear the >>> pending-exception-check flag then the place to do it is the WB_END >>> macro. That allows allows exception checks at the end of methods, eg: >>> >>> 1261 env->SetObjectArrayElement(result, 4, entry_point); >>> 1262 CHECK_JNI_EXCEPTION_(env, NULL); >>> 1263 >>> 1264 return result; >>> >>> to be elided. >>> >> >> Agreed, introduce StackObj with appropriate destructor, removed the >> checks above. >> >> >>> --- >>> >>> hotspot/src/share/vm/runtime/thread.hpp >>> >>> ! // which function name. Returning to a Java frame should >>> implicitly clear the >>> ! // need for, this is done for Native->Java transitions. >>> >>> Seems to be some text missing after "need for". >> >> Thanks for seeing that, fixed. >> >>> >>> --- >>> >>> For the tests we no longer use bug numbers as part of the test names. >>> Looks like some recent tests slipped by unfortunately. :( >>> >> >> Moved to "test/runtime/jni/checked" >> >>> You should be able to get rid of the: >>> >>> * @modules java.base/jdk.internal.misc >>> >>> with Christian's just pushed changes to ProcessTools to isolate the >>> Unsafe dependency. >>> >> >> Done >> >>>> core-libs & Kumar: java launcher: are you okay with the >>>> CHECK_EXCEPTION_PRINT macro, or would you rather it was silent (i.e. >>>> CHECK_EXCEPTION_RETURN) ? >>> >>> I'm not seeing the point of this logic. Any exceptions that remain >>> pending when the main thread detaches from the VM will be reported by >>> the uncaught-exception handling logic. The checks you put in are in >>> most cases immediately before a return so there is no need to check >>> for a pending exception and do an earlier return. And in one case you >>> would bypass tracing logic by doing an early return. >> >> Removed all the extra checks, add JNI exception check to within the >> existing CHECK_NULL0 macro (make more sense there). >> >>> >>> I had assumed this was just some debugging code you had left in by >>> mistake. >> >> The method invocations needed to find main class needs to check for the >> test to pass. >> >> Cheers >> /David From dbrosius at mebigfatguy.com Mon Sep 5 19:54:33 2016 From: dbrosius at mebigfatguy.com (Dave Brosius) Date: Mon, 5 Sep 2016 15:54:33 -0400 Subject: Deprecation of String(String) constructor In-Reply-To: <579cd983-aabe-a611-b365-74c21ceeb590@oracle.com> References: <6b96634e-a9c0-47b2-c17b-f6b2057a5f14@oracle.com> <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> <58f4a6da-b3d0-a1c7-9086-a34883e6b590@oracle.com> <70aacfa1-ffa8-a4a9-8092-4cc12949d027@oracle.com> <8082b3e4-1983-8a03-f2c8-b007c8ac91db@oracle.com> <579cd983-aabe-a611-b365-74c21ceeb590@oracle.com> Message-ID: <9a821e56-87a2-326d-3bfe-53e4f1e744ea@mebigfatguy.com> Hi Folks, I notice in that the String (String original) constructor as seen here http://download.java.net/java/jdk9/docs/api/index.html is not deprecated... Is there any reason it should not be? Originally it made some sense when String byte array sharing was used, but now that that is gone, i don't see the point. Am I missing something? From jbluettduncan at gmail.com Mon Sep 5 22:49:25 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Mon, 5 Sep 2016 23:49:25 +0100 Subject: Participating on https://bugs.openjdk.java.net/browse/JDK-8156070 In-Reply-To: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Message-ID: Hi Stuart, Thank you for the very detailed response. I decided to have a crack at "JDK-8134373 explore potential uses of convenience factories within the JDK" today. I recognise it's only a P4 bug and most likely won't be prioritised for Java 9, but I believe I found a number of places where uses of "Collections.unmodifiableList(Arrays.asList(...))" and "Arrays.asList(..)" can be replaced with "List.of(...)". I've thus made some changes to my local clone of the jdk9 codebase. I'm now at a point where I'm unfamiliar with what one does next when contributing to OpenJDK, so I wonder if you'd kindly advise me on what my next step(s) are. Kind regards, Jonathan On 3 September 2016 at 01:41, Stuart Marks wrote: > Hi Jonathan, > > Welcome to OpenJDK, and thanks for your interest in JEP 269! > > I see you found a the subtasks of JDK-8156070, which is basically a > container for a bunch of ideas for work on the JEP 269 collections. I took > a quick look through them and this one seemed promising: > > JDK-8134373 explore potential uses of convenience factories within the JDK > > This isn't necessarily what you're looking for, as it's not working on the > collections themselves, but instead it's attempting to put them to use > within the JDK. I've added some notes to this bug about the dynamics of > retrofitting usage into the JDK. Although it's not work directly on the > collections, finding out where they can and cannot be applied would > definitely be useful. It would also be useful, of course, if space savings > could be realized by using them instead of conventional collections (where > appropriate, of course). > > I'd also suggest looking beyond the JEP 269 tasks and at broader > collections issues. To query for unresolved collections issues, go to > bugs.openjdk.java.net; click Issues > Search for Issues; click Advanced; > and paste the following query into the search box: > > project = jdk and component = core-libs and subcomponent = > java.util:collections and resolution = unresolved > > (You should be able to run this query without having a JIRA account.) > > There's a wider variety of things here, which might turn up something more > appropriate. (Then again, the choice might be overwhelming.) > > As Mark Reinhold mentioned, we're now in the "ramp-down phase 1" part of > the JDK 9 schedule, so the proposal is to start restricting the kind of > work that can be done. The low-priority bugs are probably off the table > until JDK 10 (I'm not sure when that tree opens up), but some things like > docs and tests are still fair game for the time being. (Also note that "the > javadoc" is a mixture of specifications and informative documentation, and > the differences between them aren't always apparent. Specification changes > require a good deal more rigor, and they go through extra rounds of review.) > > Anyway, I hope you find something of interest. I'm going heads-down to > prepare for JavaOne (Sep 18-22) but I'll try to keep an eye out for > followup messages. > > s'marks > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/ > 004777.html From david.holmes at oracle.com Mon Sep 5 23:20:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Sep 2016 09:20:34 +1000 Subject: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame In-Reply-To: <579cd983-aabe-a611-b365-74c21ceeb590@oracle.com> References: <6b96634e-a9c0-47b2-c17b-f6b2057a5f14@oracle.com> <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> <58f4a6da-b3d0-a1c7-9086-a34883e6b590@oracle.com> <70aacfa1-ffa8-a4a9-8092-4cc12949d027@oracle.com> <8082b3e4-1983-8a03-f2c8-b007c8ac91db@oracle.com> <579cd983-aabe-a611-b365-74c21ceeb590@oracle.com> Message-ID: <7fa48b78-69b7-f8ef-520d-213f2b404d2a@oracle.com> Hi David, On 5/09/2016 6:02 PM, David Simms wrote: > Hi David, > > I can make the checks silent, but the launcher itself produces warnings > from checked JNI (it's use of unchecked Java method invocations), and > this causes the test > (http://cr.openjdk.java.net/~dsimms/8164086/webrev2/hotspot/test/runtime/jni/checked/TestCheckedJniExceptionCheck.java.html) > to fail, with unchecked exception warnings popping up in the output. I've looked back at your original changes in this area but I'm still not seeing exactly where the unchecked back-to-back JNI calls are happening. For example NewPlatformString can return with an exception pending, but will return NULL, and the calling code has checks for NULL. > But yeah, I could adjust the test the ignore any start-up warnings and > drop the changes to the launcher... Unless we can more clearly identify exactly where the launcher has a problem I would prefer not to involve it in these changes. But I would like to understand exactly why the launcher is triggering the check. Thanks, David H. > > Thanks > > /David Simms > > > On 29/08/2016 9:24 a.m., David Holmes wrote: >> Hi David, >> >> I still do not understand why you think you need to make any changes >> in libjli ?? Certainly I do not think you should be printing anything >> about exceptions. >> >> Thanks, >> David H. >> >> On 26/08/2016 9:55 PM, David Simms wrote: >>> Hi David, >>> >>> Updated webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev2/ >>> >>> On 26/08/16 02:27, David Holmes wrote: >>>> Hi David, >>>> >>>> I'm missing some pieces of this puzzle I'm afraid. >>>> >>>> On 25/08/2016 8:05 PM, David Simms wrote: >>>>> >>>>> Updated the webrev here: >>>>> http://cr.openjdk.java.net/~dsimms/8164086/webrev1/ >>>> >>>> hotspot/src/share/vm/prims/whitebox.cpp >>>> >>>> First I'm not sure that Whitebox isn't a special case here that could >>>> be handled in the WB_START/END macros - see below. >>>> >>>> More generally you state below that the transition from native back to >>>> the VM doesn't have to do anything with the pending_exception_check >>>> flag because well behaved native code in that context will explicitly >>>> check for exceptions, and so the pending-exception-check will already >>>> be disabled before returning to Java. First, if that is the case then >>>> we should assert that it is so in the native->VM return transition. >>> >>> Agreed, inserted assert. >>> >>>> >>>> Second though, it doesn't seem to be the case in Whitebox because the >>>> CHECK_JNI_EXCEPTION_ macro simply calls HAS_PENDING_EXCEPTION and so >>>> won't touch the pending-exception-check flag. ?? >>> >>> Doh, you are correct...I mistook this for the CHECK_JNI_EXCEPTION macro >>> in "java.c" which does perform check... >>> >>>> >>>> It was a good pick up that some whitebox code was using values that >>>> might be NULL because an exception had occurred. There are a couple of >>>> changes that are unnecessary though: >>>> >>>> 1235 result = env->NewObjectArray(5, clazz, NULL); >>>> 1236 CHECK_JNI_EXCEPTION_(env, NULL); >>>> 1237 if (result == NULL) { >>>> 1238 return result; >>>> 1239 } >>>> >>>> (and similarly at 1322) >>>> >>>> result will be NULL iff there is a pending exception; and vice-versa. >>>> So the existing check for NULL suffices for correctness. If you want >>>> to check exceptions for the side-effect of clearing the >>>> pending-exception-check flag then lines 1237-1239 can be deleted. >>>> However I would suggest that if you truly do want to clear the >>>> pending-exception-check flag then the place to do it is the WB_END >>>> macro. That allows allows exception checks at the end of methods, eg: >>>> >>>> 1261 env->SetObjectArrayElement(result, 4, entry_point); >>>> 1262 CHECK_JNI_EXCEPTION_(env, NULL); >>>> 1263 >>>> 1264 return result; >>>> >>>> to be elided. >>>> >>> >>> Agreed, introduce StackObj with appropriate destructor, removed the >>> checks above. >>> >>> >>>> --- >>>> >>>> hotspot/src/share/vm/runtime/thread.hpp >>>> >>>> ! // which function name. Returning to a Java frame should >>>> implicitly clear the >>>> ! // need for, this is done for Native->Java transitions. >>>> >>>> Seems to be some text missing after "need for". >>> >>> Thanks for seeing that, fixed. >>> >>>> >>>> --- >>>> >>>> For the tests we no longer use bug numbers as part of the test names. >>>> Looks like some recent tests slipped by unfortunately. :( >>>> >>> >>> Moved to "test/runtime/jni/checked" >>> >>>> You should be able to get rid of the: >>>> >>>> * @modules java.base/jdk.internal.misc >>>> >>>> with Christian's just pushed changes to ProcessTools to isolate the >>>> Unsafe dependency. >>>> >>> >>> Done >>> >>>>> core-libs & Kumar: java launcher: are you okay with the >>>>> CHECK_EXCEPTION_PRINT macro, or would you rather it was silent (i.e. >>>>> CHECK_EXCEPTION_RETURN) ? >>>> >>>> I'm not seeing the point of this logic. Any exceptions that remain >>>> pending when the main thread detaches from the VM will be reported by >>>> the uncaught-exception handling logic. The checks you put in are in >>>> most cases immediately before a return so there is no need to check >>>> for a pending exception and do an earlier return. And in one case you >>>> would bypass tracing logic by doing an early return. >>> >>> Removed all the extra checks, add JNI exception check to within the >>> existing CHECK_NULL0 macro (make more sense there). >>> >>>> >>>> I had assumed this was just some debugging code you had left in by >>>> mistake. >>> >>> The method invocations needed to find main class needs to check for the >>> test to pass. >>> >>> Cheers >>> /David > From Alan.Burlison at oracle.com Tue Sep 6 07:35:08 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Tue, 6 Sep 2016 08:35:08 +0100 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris In-Reply-To: References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> Message-ID: On 01/09/2016 14:34, Alan Burlison wrote: >> Changes looks good for me. > > Thanks. > > Could someone possibly sponsor this for me? I don't have commit rights > yet... Ping... -- Alan Burlison -- From Alan.Burlison at oracle.com Tue Sep 6 07:38:46 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Tue, 6 Sep 2016 08:38:46 +0100 Subject: RFR: JDK-8165161 Solaris: /usr/ccs /opt/sfw and /opt/csw are dead, references should be expunged In-Reply-To: References: Message-ID: On 01/09/2016 18:43, Alan Burlison wrote: > I posted this originally on build-dev, it was suggested I should also > post it to core-libs-dev for review of some of the changes. > > /usr/ccs /opt/sfw and /opt/csw are all obsolete and should be removed > from the Solaris-related build infrastructure. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165161 > Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165161/ > > JPRT hotspot tests all pass. Ping... -- Alan Burlison -- From david.simms at oracle.com Tue Sep 6 07:51:07 2016 From: david.simms at oracle.com (David Simms) Date: Tue, 6 Sep 2016 09:51:07 +0200 Subject: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame In-Reply-To: <7fa48b78-69b7-f8ef-520d-213f2b404d2a@oracle.com> References: <6b96634e-a9c0-47b2-c17b-f6b2057a5f14@oracle.com> <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> <58f4a6da-b3d0-a1c7-9086-a34883e6b590@oracle.com> <70aacfa1-ffa8-a4a9-8092-4cc12949d027@oracle.com> <8082b3e4-1983-8a03-f2c8-b007c8ac91db@oracle.com> <579cd983-aabe-a611-b365-74c21ceeb590@oracle.com> <7fa48b78-69b7-f8ef-520d-213f2b404d2a@oracle.com> Message-ID: <0246f75f-2be6-2971-fa6c-0742a30e5ec5@oracle.com> Updated webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev3/ On 06/09/16 01:20, David Holmes wrote: > Hi David, > > On 5/09/2016 6:02 PM, David Simms wrote: >> Hi David, >> >> I can make the checks silent, but the launcher itself produces warnings >> from checked JNI (it's use of unchecked Java method invocations), and >> this causes the test >> (http://cr.openjdk.java.net/~dsimms/8164086/webrev2/hotspot/test/runtime/jni/checked/TestCheckedJniExceptionCheck.java.html) >> >> to fail, with unchecked exception warnings popping up in the output. > > I've looked back at your original changes in this area but I'm still > not seeing exactly where the unchecked back-to-back JNI calls are > happening. For example NewPlatformString can return with an exception > pending, but will return NULL, and the calling code has checks for NULL. > LoadMainClass: http://hg.openjdk.java.net/jdk9/hs/jdk/file/090cbd92c744/src/java.base/share/native/libjli/java.c#l1530 Calls "CallStaticObjectMethod" from "NewPlatformString", then on line 1531 make another call "CallStaticObjectMethod". No exception check is made. The Xcheck:jni code cannot interpreter the return value from JNI "CallMethod" functions, so it triggers the "unchecked" exception warning at line 1531. >> But yeah, I could adjust the test the ignore any start-up warnings and >> drop the changes to the launcher... > > Unless we can more clearly identify exactly where the launcher has a > problem I would prefer not to involve it in these changes. But I would > like to understand exactly why the launcher is triggering the check. > Dropped launcher changes, adjusted the test to ignore any previous warnings. Cheers /David Simms From ashipile at redhat.com Tue Sep 6 08:46:12 2016 From: ashipile at redhat.com (Aleksey Shipilev) Date: Tue, 6 Sep 2016 11:46:12 +0300 Subject: Participating on https://bugs.openjdk.java.net/browse/JDK-8156070 In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Message-ID: On 09/06/2016 01:49 AM, Jonathan Bluett-Duncan wrote: > I decided to have a crack at "JDK-8134373 explore potential uses of > convenience factories within the JDK" today. I recognise it's only a P4 bug > and most likely won't be prioritised for Java 9, but I believe I found a > number of places where uses of > "Collections.unmodifiableList(Arrays.asList(...))" and "Arrays.asList(..)" > can be replaced with "List.of(...)". I've thus made some changes to my > local clone of the jdk9 codebase. > > I'm now at a point where I'm unfamiliar with what one does next when > contributing to OpenJDK, so I wonder if you'd kindly advise me on what my > next step(s) are. See: http://openjdk.java.net/contribute/ In short, sign and send OCA, prepare and send the patch for review, work with your sponsor. Thanks, -Aleksey From Roger.Riggs at Oracle.com Tue Sep 6 14:53:49 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Sep 2016 10:53:49 -0400 Subject: RFR: JDK-8165161 Solaris: /usr/ccs /opt/sfw and /opt/csw are dead, references should be expunged In-Reply-To: References: Message-ID: <489699c4-54d4-a4ba-a99e-dc540fa8339b@Oracle.com> Hi Alan, Looks ok from the core-libs perspective. Roger On 9/6/2016 3:38 AM, Alan Burlison wrote: > On 01/09/2016 18:43, Alan Burlison wrote: > >> I posted this originally on build-dev, it was suggested I should also >> post it to core-libs-dev for review of some of the changes. >> >> /usr/ccs /opt/sfw and /opt/csw are all obsolete and should be removed >> from the Solaris-related build infrastructure. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8165161 >> Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165161/ >> >> JPRT hotspot tests all pass. > > Ping... > From t.p.ellison at gmail.com Tue Sep 6 17:09:38 2016 From: t.p.ellison at gmail.com (Tim Ellison) Date: Tue, 6 Sep 2016 18:09:38 +0100 Subject: JEP 254: Compact Strings - length limits Message-ID: <1c4e7c12-8d1b-1680-fdcb-4ffd997422dd@gmail.com> Has it been noted that while JEP 254 reduces the space occupied by one byte per character strings, moving from a char[] to byte[] representation universally means that the maximum length of a UTF-16 (two bytes per char) string is now halved? Since the goal is "preserving full compatibility", this has been missed by failing to allow for UTF-16 strings of length greater than Integer.MAX_VALUE / 2. Regards, Tim From Roger.Riggs at Oracle.com Tue Sep 6 17:10:29 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Sep 2016 13:10:29 -0400 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris In-Reply-To: References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> Message-ID: <898d9c8c-0547-574f-d817-ee467e76f6c6@Oracle.com> ok, I will sponsor it. (Usually the patches are relative to the repo being modified). Thanks, Roger On 9/6/2016 3:35 AM, Alan Burlison wrote: > On 01/09/2016 14:34, Alan Burlison wrote: > >>> Changes looks good for me. >> >> Thanks. >> >> Could someone possibly sponsor this for me? I don't have commit rights >> yet... > > Ping... > From Alan.Burlison at oracle.com Tue Sep 6 17:25:13 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Tue, 6 Sep 2016 18:25:13 +0100 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris In-Reply-To: <898d9c8c-0547-574f-d817-ee467e76f6c6@Oracle.com> References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> <898d9c8c-0547-574f-d817-ee467e76f6c6@Oracle.com> Message-ID: On 06/09/2016 18:10, Roger Riggs wrote: > ok, I will sponsor it. Thanks. > (Usually the patches are relative to the repo being modified). I can regen it if you want, I've been doing a lot of cross-repo patches and have got into the habit of generating them from the topmost repo ;-) -- Alan Burlison -- From Roger.Riggs at Oracle.com Tue Sep 6 17:28:22 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Sep 2016 13:28:22 -0400 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris In-Reply-To: References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> <898d9c8c-0547-574f-d817-ee467e76f6c6@Oracle.com> Message-ID: Hi Alan, Not a problem, I usually use mq to wrangle patches. (per repo) Thanks, Roger On 9/6/2016 1:25 PM, Alan Burlison wrote: > On 06/09/2016 18:10, Roger Riggs wrote: > >> ok, I will sponsor it. > > Thanks. > >> (Usually the patches are relative to the repo being modified). > > I can regen it if you want, I've been doing a lot of cross-repo > patches and have got into the habit of generating them from the > topmost repo ;-) > From xueming.shen at oracle.com Tue Sep 6 18:04:51 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 06 Sep 2016 11:04:51 -0700 Subject: JEP 254: Compact Strings - length limits In-Reply-To: <1c4e7c12-8d1b-1680-fdcb-4ffd997422dd@gmail.com> References: <1c4e7c12-8d1b-1680-fdcb-4ffd997422dd@gmail.com> Message-ID: <57CF0543.7080900@oracle.com> On 9/6/16, 10:09 AM, Tim Ellison wrote: > Has it been noted that while JEP 254 reduces the space occupied by one > byte per character strings, moving from a char[] to byte[] > representation universally means that the maximum length of a UTF-16 > (two bytes per char) string is now halved? Hi Tim, Yes, it's a known "limit" given the nature of the approach. It is not considered to be an "incompatible change", because the max length the String class and the corresponding buffer/builder classes can support is really an implementation details, not a spec requirement. The conclusion from the discussion back then was this is something we can trade off for the benefits we gain from the approach. Do we have a real use case that impacted by this change? Thanks, Sherman > > Since the goal is "preserving full compatibility", this has been missed > by failing to allow for UTF-16 strings of length greater than > Integer.MAX_VALUE / 2. > > Regards, > Tim > > From martinrb at google.com Tue Sep 6 19:16:16 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 Sep 2016 12:16:16 -0700 Subject: Filing Bugs Against the Core Libs In-Reply-To: References: <06c9d8fd-5b50-1285-0621-ca89ab5e5378@oracle.com> Message-ID: On Mon, Aug 29, 2016 at 8:25 PM, Russ Harmon wrote: > > > The actual code that throws it doesn't know the exact reason. > > > To my understanding though, the reason is not outside of the purview of the > JDK (aka, the rejection is not decided upon by outside code), and therefore > some refactoring of the existing code could make it known. > > Like David, I have a hard time seeing how to make this clearly better. The only interface to the RejectedExecutionHandler is the rejectedExecution method, and that does not allow for any way to pass a reason. > > > But you > > seem to be running a custom RejectedExeceptionHandler so it should be > > able to determine whether the executor is shutdown, or if using a > > bounded queue which may have become full. > > > > There's a race condition if I do that. It's true we have a "reason reporting race" then. ThreadPoolExecutor code is doing something like if (isShutdown()) handler.rejectedExecution(command, this) but how to pass the reason to the handler? In practice, rechecking the shutdown status in the handler is good enough for most monitoring purposes. If the pool turns out to be shutdown, but the shutdown happened in a race, does it matter to the caller? Retry will be futile in such a case anyway. > If the executor has not been > shutdown, and the executor has reached capacity, the > RejectedExceptionHandler will be called. I can then check the queue size in > the RejectedExceptionHandler, but it's possible that tasks completed before > I'm able to check the size, so the queue won't appear full. > > I think that this is actually what has occurred in my case. The stack trace > I linked earlier shows a non-full queue, but I know that the executor was > not shutting down. Therefore, it must have been caused by the queue filling > up, then depleting before the size was read for generation of the error > message. > > From headius at headius.com Tue Sep 6 19:58:52 2016 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2016 14:58:52 -0500 Subject: JEP 254: Compact Strings - length limits In-Reply-To: <57CF0543.7080900@oracle.com> References: <1c4e7c12-8d1b-1680-fdcb-4ffd997422dd@gmail.com> <57CF0543.7080900@oracle.com> Message-ID: On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen wrote: > Yes, it's a known "limit" given the nature of the approach. It is not > considered > to be an "incompatible change", because the max length the String class > and > the corresponding buffer/builder classes can support is really an > implementation > details, not a spec requirement. The conclusion from the discussion back > then > was this is something we can trade off for the benefits we gain from the > approach. > Do we have a real use case that impacted by this change? > Well, doesn't this mean that any code out there consuming String data that's longer than Integer.MAX_VALUE / 2 will suddenly start failing on OpenJDK 9? Not that such a case is a particularly good pattern, but I'm sure there's code out there doing it. On JRuby we routinely get bug reports complaining that we can't support strings larger than 2GB (and we have used byte[] for strings since 2006). - Charlie From philip.race at oracle.com Tue Sep 6 20:01:46 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 6 Sep 2016 13:01:46 -0700 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris In-Reply-To: References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> <898d9c8c-0547-574f-d817-ee467e76f6c6@Oracle.com> Message-ID: FWIW "+1" from me since I just used/needed that patch to get my build to continue on Solaris 11.3. -phil. On 9/6/2016 10:28 AM, Roger Riggs wrote: > Hi Alan, > > Not a problem, I usually use mq to wrangle patches. (per repo) > > Thanks, Roger > > > On 9/6/2016 1:25 PM, Alan Burlison wrote: >> On 06/09/2016 18:10, Roger Riggs wrote: >> >>> ok, I will sponsor it. >> >> Thanks. >> >>> (Usually the patches are relative to the repo being modified). >> >> I can regen it if you want, I've been doing a lot of cross-repo >> patches and have got into the habit of generating them from the >> topmost repo ;-) >> > From Alan.Burlison at oracle.com Tue Sep 6 20:29:52 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Tue, 6 Sep 2016 21:29:52 +0100 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris In-Reply-To: References: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> <898d9c8c-0547-574f-d817-ee467e76f6c6@Oracle.com> Message-ID: On 06/09/2016 21:01, Phil Race wrote: > FWIW "+1" from me since I just used/needed that patch to get my build to > continue on Solaris 11.3. If you need it I have a jumbo patch that gets J9 to build on both S11.3 and S12. I'm working on splitting it up into individual patches and getting them pushed into the J9 repo. -- Alan Burlison -- From john.r.rose at oracle.com Tue Sep 6 21:11:35 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Sep 2016 14:11:35 -0700 Subject: JEP 254: Compact Strings - length limits In-Reply-To: References: <1c4e7c12-8d1b-1680-fdcb-4ffd997422dd@gmail.com> <57CF0543.7080900@oracle.com> Message-ID: <7BB1E14D-60E7-46DA-A9C2-D5491D78960F@oracle.com> On Sep 6, 2016, at 12:58 PM, Charles Oliver Nutter wrote: > > On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen > wrote: > >> Yes, it's a known "limit" given the nature of the approach. It is not >> considered >> to be an "incompatible change", because the max length the String class >> and >> the corresponding buffer/builder classes can support is really an >> implementation >> details, not a spec requirement. The conclusion from the discussion back >> then >> was this is something we can trade off for the benefits we gain from the >> approach. >> Do we have a real use case that impacted by this change? >> > > Well, doesn't this mean that any code out there consuming String data > that's longer than Integer.MAX_VALUE / 2 will suddenly start failing on > OpenJDK 9? > > Not that such a case is a particularly good pattern, but I'm sure there's > code out there doing it. On JRuby we routinely get bug reports complaining > that we can't support strings larger than 2GB (and we have used byte[] for > strings since 2006). > > - Charlie The most basic scale requirement for strings is that they support class-file constants, which top out at a UTF8-length of 2**16. Lengths beyond that, to fill up the 'int' return value of String::length, are less well specified. FTR, we could have chosen char[], int[], or long[] (not byte[]) as the backing store for string data. With long[] we could have strings above 4G-chars. But it would have come with a perf. tax, since the T[].length field would need to be combined with an extra bit or two (from a flag byte) to complete the length. That's 2-3 extra instructions for loading a string length, or else a redundant length field. So it's a trade-off. Likewise, choosing a third format deepens branch depth in order to get to payload. Likewise, making the second format (of two) have a length field embedded in the payload section requires a conditional load or branch, in order to load the string length. Again, more instructions. The team has looked at 20 possibilities like these. The current design is fastest. I hope it flies. ? John From xueming.shen at oracle.com Tue Sep 6 21:12:08 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 06 Sep 2016 14:12:08 -0700 Subject: JEP 254: Compact Strings - length limits In-Reply-To: References: <1c4e7c12-8d1b-1680-fdcb-4ffd997422dd@gmail.com> <57CF0543.7080900@oracle.com> Message-ID: <57CF3128.2010608@oracle.com> On 9/6/16, 12:58 PM, Charles Oliver Nutter wrote: > On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen > wrote: > > Yes, it's a known "limit" given the nature of the approach. It is > not considered > to be an "incompatible change", because the max length the String > class and > the corresponding buffer/builder classes can support is really an > implementation > details, not a spec requirement. The conclusion from the > discussion back then > was this is something we can trade off for the benefits we gain > from the approach. > Do we have a real use case that impacted by this change? > > Well, doesn't this mean that any code out there consuming String data > that's longer than Integer.MAX_VALUE / 2 will suddenly start failing > on OpenJDK 9? Yes, true. But arguably the code that uses huge length of String should have fallback code to handle the potential OOM exception, when the vm can't handle the size, as there is really no guarantee the vm can handle the > max_value/2 length of String. > > Not that such a case is a particularly good pattern, but I'm sure > there's code out there doing it. On JRuby we routinely get bug reports > complaining that we can't support strings larger than 2GB (and we have > used byte[] for strings since 2006). > That was a trade-off decision to make. Does JRuby have any better solution for such complain? ever consider to go back to use char[] to "fix" the problem? or some workaround such as to add another byte[] for example. btw, the single byte only string should work just fine :-) or :-( depends on the character set used. Sherman From t.p.ellison at gmail.com Tue Sep 6 21:18:48 2016 From: t.p.ellison at gmail.com (Tim Ellison) Date: Tue, 6 Sep 2016 22:18:48 +0100 Subject: JEP 254: Compact Strings - length limits In-Reply-To: <57CF0543.7080900@oracle.com> References: <1c4e7c12-8d1b-1680-fdcb-4ffd997422dd@gmail.com> <57CF0543.7080900@oracle.com> Message-ID: <0f3a93d2-6490-6722-6b5d-5ac528e6bc73@gmail.com> On 06/09/16 19:04, Xueming Shen wrote: > On 9/6/16, 10:09 AM, Tim Ellison wrote: >> Has it been noted that while JEP 254 reduces the space occupied by one >> byte per character strings, moving from a char[] to byte[] >> representation universally means that the maximum length of a UTF-16 >> (two bytes per char) string is now halved? Hey Sherman, > Yes, it's a known "limit" given the nature of the approach. It is > not considered to be an "incompatible change", because the max length > the String class and the corresponding buffer/builder classes can > support is really an implementation details, not a spec requirement. Don't confuse spec compliance with compatibility. Of course, the JEP should not break the formal specified behavior of String etc, but the goal was to ensure that the implementation be compatible with prior behavior. As you know, there are many places where compatible behavior beyond the spec is important to maintain. > The conclusion from the discussion back then was this is something we > can trade off for the benefits we gain from the approach. Out of curiosity, where was that? I did search for previous discussion of this topic but didn't see it -- it may be just my poor search foo. > Do we have a real use case that impacted by this change? People stash all sorts of things in (immutable) Strings. Reducing the limits in JDK9 seems like a regression. Was there any consideration to using the older Java 8 StringCoding APIs for UTF-16 strings (already highly perf tuned) and adding additional methods for compact strings rather than rewriting everything as byte[]'s? Regards, Tim >> Since the goal is "preserving full compatibility", this has been missed >> by failing to allow for UTF-16 strings of length greater than >> Integer.MAX_VALUE / 2. >> >> Regards, >> Tim >> >> > From xueming.shen at oracle.com Tue Sep 6 21:56:14 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 06 Sep 2016 14:56:14 -0700 Subject: JEP 254: Compact Strings - length limits In-Reply-To: <0f3a93d2-6490-6722-6b5d-5ac528e6bc73@gmail.com> References: <1c4e7c12-8d1b-1680-fdcb-4ffd997422dd@gmail.com> <57CF0543.7080900@oracle.com> <0f3a93d2-6490-6722-6b5d-5ac528e6bc73@gmail.com> Message-ID: <57CF3B7E.1050907@oracle.com> On 9/6/16, 2:18 PM, Tim Ellison wrote: > >> Do we have a real use case that impacted by this change? > People stash all sorts of things in (immutable) Strings. Reducing the > limits in JDK9 seems like a regression. Was there any consideration to > using the older Java 8 StringCoding APIs for UTF-16 strings (already > highly perf tuned) and adding additional methods for compact strings > rather than rewriting everything as byte[]'s? > > Hi Tim, I'm sorry I don't get the idea of "using StringCoding APIs for UTF-16 strings", can you explain a little more in detail? We did try various approaches, byte[] + flag, byte[] + coder, coder, char[] + coder, etc) the current one appears to be the best so far based on our measurement. Regards, Sherman From john.r.rose at oracle.com Tue Sep 6 22:09:38 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Sep 2016 15:09:38 -0700 Subject: JEP 254: Compact Strings - length limits In-Reply-To: <0f3a93d2-6490-6722-6b5d-5ac528e6bc73@gmail.com> References: <1c4e7c12-8d1b-1680-fdcb-4ffd997422dd@gmail.com> <57CF0543.7080900@oracle.com> <0f3a93d2-6490-6722-6b5d-5ac528e6bc73@gmail.com> Message-ID: <6CFCE908-AC12-400B-B703-338992B762F5@oracle.com> On Sep 6, 2016, at 2:18 PM, Tim Ellison wrote: > > People stash all sorts of things in (immutable) Strings. Reducing the > limits in JDK9 seems like a regression. Was there any consideration to > using the older Java 8 StringCoding APIs for UTF-16 strings (already > highly perf tuned) and adding additional methods for compact strings > rather than rewriting everything as byte[]'s? It doesn't help now, but https://bugs.openjdk.java.net/browse/JDK-8161256 proposes a better way to stash immutable bits, CONSTANT_Data. (Caveat: Language bindings not yet included.) Eventually we'll get there. ? John From paul.sandoz at oracle.com Tue Sep 6 23:22:56 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Sep 2016 16:22:56 -0700 Subject: RFR 8164691 Stream specification clarifications for iterate and collect In-Reply-To: References: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> Message-ID: > On 3 Sep 2016, at 15:06, Stefan Zobel wrote: > > Hi Paul, > > there's a small copy & paste error in the code samples in > Double/Int/LongStream#iterate() > > Example DoubleStream#iterate: > > * 
{@code
>     *     for (T index=seed; hasNext.test(index); index = next.apply(index)) {
>     *         ...
>     *     }
>     * }
> > That should be > > * for (double index=seed; hasNext.test(index); index = > next.applyAsDouble(index)) { > > > Same for Int/LongStream#iterate() > Thanks, well spotted, fixed in place. When can we have generics over primitives? :-) Paul. From mandy.chung at oracle.com Wed Sep 7 00:39:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 6 Sep 2016 17:39:27 -0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: > On Sep 3, 2016, at 12:55 PM, Patrick Reinhart wrote: > > Hi Mandy, > > The current changes can be found here: > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.02 > > > On 02.09.2016 23:11, Mandy Chung wrote: >>> On Sep 2, 2016, at 2:50 AM, Patrick Reinhart >>> wrote: >>> >>> Updated the existing >>> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01 >> ClassLoader::resources returning Stream is a good addition. >> >> 1386 * {@code IOException} occur getting the next resource element, it must be >> 1387 * wrapped into an {@code UncheckedIOException}. >> >> This has been mentioned in the paragraph above. This can be dropped from @apiNote. And add: >> >> @throws UncheckedIOException if I/O errors occur >> > There was already an discussion about this with Alan Bateman: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042792.html > I sample a few existing APIs and they document UncheckedIOException in the method description rather than @throws as Alan described. > So I do not know is the best solution for this? Your method description already covers it. It?s fine. line 1386-1387 in @apiNote is redundant that I still think can be taken out. >> >> I have reservation in adding ClassLoader::systemResources static method. >> >> ClassLoader::getSystemResources is a convenient method that is equivalent to calling ClassLoader::getSystemClassLoader().getResources(), since the system class loader is never null. This method includes the resources in the application?s classpath. >> >> With the new ClassLoader::getPlatformClassLoader() method, a better way to get the ?system? resources from JDK (not the ones from the classpath), it can call: >> ClassLoader::getPlatformClassLoader().resources(); >> >> To get a Stream of URL of the resources visible to system class loader, it can call the new resources method: >> ClassLoader::getSystemClassLoader().resources(); >> >> So it doesn?t seem that the proposed systemResources static method is necessary. >> > > Hmm... We may have overlooked this, when we started by just looking into the API changes in general. I did those with Paul Sandoz in more deep in the > following thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042752.html > > and this proposal is based on the "go" from Paul here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/043012.html > I file a bug to update the spec ClassLoader::getSystemClassLoader to return non-null: https://bugs.openjdk.java.net/browse/JDK-8165563 >> I suggest to combine the two tests in a single test, ResourcesStreamTest and add @bug JBS-id >> >> ResourcesSuccessCase >> >> 46 List resources = stream.collect(Collectors.toList()); >> 52 URL url = resources.get(0); >> >> You can check the size first. This can be simplified to use filter/findFirst to file the expected URL (yes need to call cl.resources again that is not an issue). >> > > I have done this also in the new revision testFailure method can be simplified to long count = cl.resources(?the name?).count(); if (count != 1) throw new Exception("expected resource is null or empty"); cl.resources("the name?) .filter(url -> "file:/somefile".equals(url.toExternalForm()) .findFirst() .orElseThrow(?) Mandy From david.holmes at oracle.com Wed Sep 7 05:37:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Sep 2016 15:37:12 +1000 Subject: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame In-Reply-To: <0246f75f-2be6-2971-fa6c-0742a30e5ec5@oracle.com> References: <6b96634e-a9c0-47b2-c17b-f6b2057a5f14@oracle.com> <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> <58f4a6da-b3d0-a1c7-9086-a34883e6b590@oracle.com> <70aacfa1-ffa8-a4a9-8092-4cc12949d027@oracle.com> <8082b3e4-1983-8a03-f2c8-b007c8ac91db@oracle.com> <579cd983-aabe-a611-b365-74c21ceeb590@oracle.com> <7fa48b78-69b7-f8ef-520d-213f2b404d2a@oracle.com> <0246f75f-2be6-2971-fa6c-0742a30e5ec5@oracle.com> Message-ID: <701dcca2-59c7-6f5a-1182-271fbe2f077c@oracle.com> On 6/09/2016 5:51 PM, David Simms wrote: > > Updated webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev3/ No further comments from me, but note my original comment re the platform specific code. More below. > On 06/09/16 01:20, David Holmes wrote: >> Hi David, >> >> On 5/09/2016 6:02 PM, David Simms wrote: >>> Hi David, >>> >>> I can make the checks silent, but the launcher itself produces warnings >>> from checked JNI (it's use of unchecked Java method invocations), and >>> this causes the test >>> (http://cr.openjdk.java.net/~dsimms/8164086/webrev2/hotspot/test/runtime/jni/checked/TestCheckedJniExceptionCheck.java.html) >>> >>> to fail, with unchecked exception warnings popping up in the output. >> >> I've looked back at your original changes in this area but I'm still >> not seeing exactly where the unchecked back-to-back JNI calls are >> happening. For example NewPlatformString can return with an exception >> pending, but will return NULL, and the calling code has checks for NULL. >> > > LoadMainClass: > > http://hg.openjdk.java.net/jdk9/hs/jdk/file/090cbd92c744/src/java.base/share/native/libjli/java.c#l1530 > > > Calls "CallStaticObjectMethod" from "NewPlatformString", then on line > 1531 make another call "CallStaticObjectMethod". > > No exception check is made. The Xcheck:jni code cannot interpreter the > return value from JNI "CallMethod" functions, so it triggers the > "unchecked" exception warning at line 1531. Ah I see. No bug in the launcher code though as it only makes the second JNI call if the original did not return NULL and hence there can be no exception pending. This is a limitation of the unchecked warning facility as it can't take control flow into account. :( > >>> But yeah, I could adjust the test the ignore any start-up warnings and >>> drop the changes to the launcher... >> >> Unless we can more clearly identify exactly where the launcher has a >> problem I would prefer not to involve it in these changes. But I would >> like to understand exactly why the launcher is triggering the check. >> > > Dropped launcher changes, adjusted the test to ignore any previous > warnings. Yep - that seems best: only monitor the test itself not the overall VM operation. Thanks, David H. ------- > Cheers > /David Simms From spliterator at gmail.com Wed Sep 7 07:49:03 2016 From: spliterator at gmail.com (Stefan Zobel) Date: Wed, 7 Sep 2016 09:49:03 +0200 Subject: RFR 8164691 Stream specification clarifications for iterate and collect In-Reply-To: References: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> Message-ID: 2016-09-07 1:22 GMT+02:00 Paul Sandoz : > >> On 3 Sep 2016, at 15:06, Stefan Zobel wrote: >> >> Hi Paul, >> >> there's a small copy & paste error in the code samples in >> Double/Int/LongStream#iterate() >> >> Example DoubleStream#iterate: >> >> * 
{@code
>>     *     for (T index=seed; hasNext.test(index); index = next.apply(index)) {
>>     *         ...
>>     *     }
>>     * }
>> >> That should be >> >> * for (double index=seed; hasNext.test(index); index = >> next.applyAsDouble(index)) { >> >> >> Same for Int/LongStream#iterate() >> > > Thanks, well spotted, fixed in place. Almost: next.apply(index) => next.applyAsDouble(index) > > When can we have generics over primitives? :-) > > Paul. Regards, Stefan From sergei.kovalev at oracle.com Wed Sep 7 09:25:44 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 7 Sep 2016 12:25:44 +0300 Subject: RFR(S): 8165583: Fix module dependencies for jdk/java/util/* tests Message-ID: Hello team, Please review the changes for fixing JDK issue: Bug ID: JDK-8165583 WebRev link: http://cr.openjdk.java.net/~skovalev/8165583/webrev.00/index.html Summary: added modules declaration if missed, e.g. jdk.localedata, java.logging, java.sql. Also for module tests added explicit module add for tests that used user defined modules. All changes have tested locally using jtreg for test execution. Thank you in advance. -- With best regards, Sergei From Alan.Bateman at oracle.com Wed Sep 7 09:41:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Sep 2016 10:41:36 +0100 Subject: RFR(S): 8165583: Fix module dependencies for jdk/java/util/* tests In-Reply-To: References: Message-ID: On 07/09/2016 10:25, Sergei Kovalev wrote: > Hello team, > > Please review the changes for fixing JDK issue: > > Bug ID: JDK-8165583 > WebRev link: > http://cr.openjdk.java.net/~skovalev/8165583/webrev.00/index.html > > Summary: added modules declaration if missed, e.g. jdk.localedata, > java.logging, java.sql. These looks okay. > Also for module tests added explicit module add for tests that used > user defined modules. The only scenario where these should be need be where the tests are run with --limit-modules. Is this how you are running into this? -Alan From sergei.kovalev at oracle.com Wed Sep 7 09:43:56 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 7 Sep 2016 12:43:56 +0300 Subject: RFR(S): 8165583: Fix module dependencies for jdk/java/util/* tests In-Reply-To: References: Message-ID: <768050b6-4369-8d34-f137-7af53b6107aa@oracle.com> 07.09.16 12:41, Alan Bateman wrote: > On 07/09/2016 10:25, Sergei Kovalev wrote: > >> Hello team, >> >> Please review the changes for fixing JDK issue: >> >> Bug ID: JDK-8165583 >> WebRev link: >> http://cr.openjdk.java.net/~skovalev/8165583/webrev.00/index.html >> >> Summary: added modules declaration if missed, e.g. jdk.localedata, >> java.logging, java.sql. > These looks okay. > >> Also for module tests added explicit module add for tests that used >> user defined modules. > The only scenario where these should be need be where the tests are > run with --limit-modules. Is this how you are running into this? You are right. I get into this with --limi-modules flags. If I don't provide the limitation the tests also works as expected. > > -Alan -- With best regards, Sergei From sergei.kovalev at oracle.com Wed Sep 7 12:41:05 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 7 Sep 2016 15:41:05 +0300 Subject: RFR(S): 8165592: Fix module dependencies for sun/text/* tests Message-ID: <8e78e7d5-ee34-38e0-a43d-08c12f76e7c8@oracle.com> Hello team, Please review small fix for tests issue: Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165592 Webrev: http://cr.openjdk.java.net/~skovalev/8165592/webrev.00/index.html Summary: added 'jdk.localedata' into modules declaration section to have an ability to skip the tests with --limit-modules execution if required. Also made some import clean up. The changes tested locally using jtreg tool. -- With best regards, Sergei From alexandre.iline at oracle.com Wed Sep 7 13:11:23 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 7 Sep 2016 06:11:23 -0700 Subject: RFR(S): 8165583: Fix module dependencies for jdk/java/util/* tests In-Reply-To: References: Message-ID: <5CCD2A55-30E1-4A42-87B5-BE842C2A63C2@oracle.com> This looks good, Sergei. Shura > On Sep 7, 2016, at 2:25 AM, Sergei Kovalev wrote: > > Hello team, > > Please review the changes for fixing JDK issue: > > Bug ID: JDK-8165583 > WebRev link: http://cr.openjdk.java.net/~skovalev/8165583/webrev.00/index.html > Summary: added modules declaration if missed, e.g. jdk.localedata, java.logging, java.sql. Also for module tests added explicit module add for tests that used user defined modules. > All changes have tested locally using jtreg for test execution. > Thank you in advance. > -- > With best regards, > Sergei From alexandre.iline at oracle.com Wed Sep 7 13:13:48 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 7 Sep 2016 06:13:48 -0700 Subject: RFR(S): 8165592: Fix module dependencies for sun/text/* tests In-Reply-To: <8e78e7d5-ee34-38e0-a43d-08c12f76e7c8@oracle.com> References: <8e78e7d5-ee34-38e0-a43d-08c12f76e7c8@oracle.com> Message-ID: <57E1A591-E762-49DF-97D8-8E7D276C3BDB@oracle.com> "Copyright (c) 2007,2016 Oracle? Should be "Copyright (c) 2007, 2016, Oracle? Otherwise good. Shura > On Sep 7, 2016, at 5:41 AM, Sergei Kovalev wrote: > > Hello team, > > Please review small fix for tests issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165592 > Webrev: http://cr.openjdk.java.net/~skovalev/8165592/webrev.00/index.html > > Summary: added 'jdk.localedata' into modules declaration section to have an ability to skip the tests with --limit-modules execution if required. Also made some import clean up. > > The changes tested locally using jtreg tool. > > -- > With best regards, > Sergei > From coleen.phillimore at oracle.com Wed Sep 7 13:35:00 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 7 Sep 2016 09:35:00 -0400 Subject: RFR: 8163014: Mysterious/wrong value for "long" frame local variable on 64-bit In-Reply-To: <57D01173.3040607@oracle.com> References: <57CF363F.7020600@oracle.com> <10d939f8-45b1-4324-e6e0-92d6930a0c86@oracle.com> <57D01173.3040607@oracle.com> Message-ID: On 9/7/16 9:09 AM, Max Ockner wrote: > Does the stackwalk API have access to the type of variable at each > slot? Where is this information stored? My operating assumption was > that it did not have this information, and therefore needed to read > the garbage slot. This is true. The StackWalk API does not have type information for these longs, so this prevents garbage values from being read. Adding core-libs. Thanks, Coleen > Max > > On 9/6/2016 8:24 PM, dean.long at oracle.com wrote: >> Instead of fixing this at write time, how about instead fixing it at >> read time? That was my understanding of John's comment: >> >> A virtualized API which >> produces a view on such an L[1] needs to return some >> default value (if pressed), and to indicate that the slot >> has no payload. >> >> SoLiveStackFrame.getLocals() would never read the physical garbage >> slot, but instead would act as if it >> read 0 instead. And by LiveStackFrame.getLocals() I really mean >> whatever code fills in its "locals" field, >> which I guess is the JVM. >> >> dl >> >> On 9/6/16 2:33 PM, Max Ockner wrote: >>> Hello, Please review this multi-platform fix for the stack walk API. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163014 Webrev: >>> http://cr.openjdk.java.net/~mockner/8163014.01/ In 64 bits, long >>> values can fit into a single slot, but two slots are still used. The >>> high slot contains garbage. This normally wouldn't matter since it >>> is never read from but the stack walk API expects to display useful >>> information. This is an issue when displaying longs from local >>> variables, so this means we can kill any garbage off by zeroing it >>> when it is pushed to the stack in the previous frame. This solution >>> zeroes the high byte of a long value when it is being pushed to the >>> stack (in push_l). This applies to x86, aarch64, and sparc. This >>> change does not apply to ppc, though the bug almost certainly does >>> affect it. I have left ppc untouched since I don't have access to >>> the hardware required to reproduce the bug and test the fix. I have >>> adapted the reproducer from the bug into a test. It is curently >>> sitting in runtime/locallong, but I believe there must be a better >>> place for it. Thanks, Max > From sergei.kovalev at oracle.com Wed Sep 7 14:22:10 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 7 Sep 2016 17:22:10 +0300 Subject: RFR(S): 8165592: Fix module dependencies for sun/text/* tests In-Reply-To: <57E1A591-E762-49DF-97D8-8E7D276C3BDB@oracle.com> References: <8e78e7d5-ee34-38e0-a43d-08c12f76e7c8@oracle.com> <57E1A591-E762-49DF-97D8-8E7D276C3BDB@oracle.com> Message-ID: <641d125b-ff6d-5359-c746-72198669eb46@oracle.com> Fixed. Please find new version here: http://cr.openjdk.java.net/~skovalev/8165592/webrev.01/ 07.09.16 16:13, Alexandre (Shura) Iline wrote: > "Copyright (c) 2007,2016 Oracle? > > Should be > > "Copyright (c) 2007, 2016, Oracle? > > Otherwise good. > > Shura > >> On Sep 7, 2016, at 5:41 AM, Sergei Kovalev wrote: >> >> Hello team, >> >> Please review small fix for tests issue: >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165592 >> Webrev: http://cr.openjdk.java.net/~skovalev/8165592/webrev.00/index.html >> >> Summary: added 'jdk.localedata' into modules declaration section to have an ability to skip the tests with --limit-modules execution if required. Also made some import clean up. >> >> The changes tested locally using jtreg tool. >> >> -- >> With best regards, >> Sergei >> -- With best regards, Sergei From sergei.kovalev at oracle.com Wed Sep 7 14:43:33 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 7 Sep 2016 17:43:33 +0300 Subject: RFR(s): 8165604: Fix module dependencies for sun/util/* tests Message-ID: <590bd09e-5689-13a5-310d-909449ac0005@oracle.com> Hello team, Please review small fix in tests source. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165604 Review link: http://cr.openjdk.java.net/~skovalev/8165604/webrev.00/ Goal: make test working with --limit-modules ... flag. Summary: added 'jdk.localedata' into modules declaration section. -- With best regards, Sergei From paul.sandoz at oracle.com Wed Sep 7 15:14:30 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Sep 2016 08:14:30 -0700 Subject: RFR 8164691 Stream specification clarifications for iterate and collect In-Reply-To: References: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> Message-ID: > On 7 Sep 2016, at 00:49, Stefan Zobel wrote: > > 2016-09-07 1:22 GMT+02:00 Paul Sandoz : >> >>> On 3 Sep 2016, at 15:06, Stefan Zobel wrote: >>> >>> Hi Paul, >>> >>> there's a small copy & paste error in the code samples in >>> Double/Int/LongStream#iterate() >>> >>> Example DoubleStream#iterate: >>> >>> * 
{@code
>>>    *     for (T index=seed; hasNext.test(index); index = next.apply(index)) {
>>>    *         ...
>>>    *     }
>>>    * }
>>> >>> That should be >>> >>> * for (double index=seed; hasNext.test(index); index = >>> next.applyAsDouble(index)) { >>> >>> >>> Same for Int/LongStream#iterate() >>> >> >> Thanks, well spotted, fixed in place. > > > Almost: next.apply(index) => next.applyAsDouble(index) > Grrr? updated. Thanks for being vigilant. I hesitated to update these, since we don?t mention the types, but i think it?s best to refer to method names corresponding to those of functional interfaces that would likely be used. Paul. From Roger.Riggs at Oracle.com Wed Sep 7 15:25:21 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Sep 2016 11:25:21 -0400 Subject: RFR(s): 8165604: Fix module dependencies for sun/util/* tests In-Reply-To: <590bd09e-5689-13a5-310d-909449ac0005@oracle.com> References: <590bd09e-5689-13a5-310d-909449ac0005@oracle.com> Message-ID: <4feb53ed-6e46-d4ac-1eae-3e910f82f12e@Oracle.com> Looks fine. +1 It might have been just as effective to add a TEST.properties file with modules = jdk.localedata in test/sun/util/resources and test/sun/util/locale directories. Though the cleanup of the test source is fine too. Thanks, Roger On 9/7/2016 10:43 AM, Sergei Kovalev wrote: > Hello team, > > Please review small fix in tests source. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165604 > Review link: http://cr.openjdk.java.net/~skovalev/8165604/webrev.00/ > > Goal: make test working with --limit-modules ... flag. > Summary: added 'jdk.localedata' into modules declaration section. > From naoto.sato at oracle.com Wed Sep 7 15:41:22 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 7 Sep 2016 08:41:22 -0700 Subject: RFR(s): 8165604: Fix module dependencies for sun/util/* tests In-Reply-To: <590bd09e-5689-13a5-310d-909449ac0005@oracle.com> References: <590bd09e-5689-13a5-310d-909449ac0005@oracle.com> Message-ID: <4616f5c2-ea2c-d0be-fa03-613004ce6679@oracle.com> Looks fine too. Thanks for cleaning those tests. Naoto On 9/7/16 7:43 AM, Sergei Kovalev wrote: > Hello team, > > Please review small fix in tests source. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165604 > Review link: http://cr.openjdk.java.net/~skovalev/8165604/webrev.00/ > > Goal: make test working with --limit-modules ... flag. > Summary: added 'jdk.localedata' into modules declaration section. > From sergei.kovalev at oracle.com Wed Sep 7 16:29:36 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 7 Sep 2016 19:29:36 +0300 Subject: RFR(s): 8165604: Fix module dependencies for sun/util/* tests In-Reply-To: <4616f5c2-ea2c-d0be-fa03-613004ce6679@oracle.com> References: <590bd09e-5689-13a5-310d-909449ac0005@oracle.com> <4616f5c2-ea2c-d0be-fa03-613004ce6679@oracle.com> Message-ID: Thank you for reviewing 07.09.16 18:41, Naoto Sato wrote: > Looks fine too. Thanks for cleaning those tests. > > Naoto > > On 9/7/16 7:43 AM, Sergei Kovalev wrote: >> Hello team, >> >> Please review small fix in tests source. >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165604 >> Review link: http://cr.openjdk.java.net/~skovalev/8165604/webrev.00/ >> >> Goal: make test working with --limit-modules ... flag. >> Summary: added 'jdk.localedata' into modules declaration section. >> -- With best regards, Sergei From huizhe.wang at oracle.com Wed Sep 7 17:32:27 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 07 Sep 2016 10:32:27 -0700 Subject: RFR (JAXP): 8165116: redirect function is not allowed even with enableExtensionFunctions Message-ID: <57D04F2B.5020106@oracle.com> Hi, Please review a fix for a missing check on the setting of property enableExtensionFunctions. Also closed the OutputStream after transformation is done. JBS: https://bugs.openjdk.java.net/browse/JDK-8165116 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165116/webrev/ Thanks, Joe From lance.andersen at oracle.com Wed Sep 7 17:49:24 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Sep 2016 13:49:24 -0400 Subject: RFR (JAXP): 8165116: redirect function is not allowed even with enableExtensionFunctions In-Reply-To: <57D04F2B.5020106@oracle.com> References: <57D04F2B.5020106@oracle.com> Message-ID: <227951D0-29B0-4A93-B07B-3EA91C681C95@oracle.com> Looks OK joe > On Sep 7, 2016, at 1:32 PM, Joe Wang wrote: > > Hi, > > Please review a fix for a missing check on the setting of property enableExtensionFunctions. Also closed the OutputStream after transformation is done. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8165116 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165116/webrev/ > > Thanks, > Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Wed Sep 7 17:48:34 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 7 Sep 2016 10:48:34 -0700 Subject: RFR(S): 8165583: Fix module dependencies for jdk/java/util/* tests In-Reply-To: References: Message-ID: +1 Naoto On 9/7/16 2:25 AM, Sergei Kovalev wrote: > Hello team, > > Please review the changes for fixing JDK issue: > > Bug ID: JDK-8165583 > WebRev link: > http://cr.openjdk.java.net/~skovalev/8165583/webrev.00/index.html > > Summary: added modules declaration if missed, e.g. jdk.localedata, > java.logging, java.sql. Also for module tests added explicit module add > for tests that used user defined modules. > All changes have tested locally using jtreg for test execution. > Thank you in advance. > From huizhe.wang at oracle.com Wed Sep 7 17:57:44 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 07 Sep 2016 10:57:44 -0700 Subject: RFR (JAXP): 8165116: redirect function is not allowed even with enableExtensionFunctions In-Reply-To: <227951D0-29B0-4A93-B07B-3EA91C681C95@oracle.com> References: <57D04F2B.5020106@oracle.com> <227951D0-29B0-4A93-B07B-3EA91C681C95@oracle.com> Message-ID: <57D05518.10505@oracle.com> Thanks Lance! Joe On 9/7/16, 10:49 AM, Lance Andersen wrote: > Looks OK joe > >> On Sep 7, 2016, at 1:32 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review a fix for a missing check on the setting of property >> enableExtensionFunctions. Also closed the OutputStream after >> transformation is done. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8165116 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165116/webrev/ >> >> >> Thanks, >> Joe > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From patrick at reini.net Wed Sep 7 18:38:12 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 7 Sep 2016 20:38:12 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: The current changes can be found here: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 On 07.09.2016 02:39, Mandy Chung wrote: > There was already an discussion about this with Alan Bateman: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042792.html >> > I sample a few existing APIs and they document UncheckedIOException in the method description rather than @throws as Alan described. > >> So I do not know is the best solution for this? > Your method description already covers it. It?s fine. line 1386-1387 in @apiNote is redundant that I still think can be taken out. Those lines are gone now ;-) >>> I have reservation in adding ClassLoader::systemResources static method. >>> >>> ClassLoader::getSystemResources is a convenient method that is equivalent to calling ClassLoader::getSystemClassLoader().getResources(), since the system class loader is never null. This method includes the resources in the application?s classpath. >>> >>> With the new ClassLoader::getPlatformClassLoader() method, a better way to get the ?system? resources from JDK (not the ones from the classpath), it can call: >>> ClassLoader::getPlatformClassLoader().resources(); >>> >>> To get a Stream of URL of the resources visible to system class loader, it can call the new resources method: >>> ClassLoader::getSystemClassLoader().resources(); >>> >>> So it doesn?t seem that the proposed systemResources static method is necessary. >>> >> Hmm... We may have overlooked this, when we started by just looking into the API changes in general. I did those with Paul Sandoz in more deep in the >> following thread: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042752.html >> >> and this proposal is based on the "go" from Paul here: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/043012.html > I file a bug to update the spec ClassLoader::getSystemClassLoader to return non-null: > https://bugs.openjdk.java.net/browse/JDK-8165563 > >>> I suggest to combine the two tests in a single test, ResourcesStreamTest and add @bug JBS-id >>> >>> ResourcesSuccessCase >>> >>> 46 List resources = stream.collect(Collectors.toList()); >>> 52 URL url = resources.get(0); >>> >>> You can check the size first. This can be simplified to use filter/findFirst to file the expected URL (yes need to call cl.resources again that is not an issue). >>> >> I have done this also in the new revision > testFailure method can be simplified to > long count = cl.resources(?the name?).count(); > if (count != 1) > throw new Exception("expected resource is null or empty"); > > cl.resources("the name?) > .filter(url -> "file:/somefile".equals(url.toExternalForm()) > .findFirst() > .orElseThrow(?) > > Mandy I also made those changes as you suggested.... -Patrick From paul.sandoz at oracle.com Wed Sep 7 19:09:59 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Sep 2016 12:09:59 -0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: Hi Patrick, I will sponsor this. Given what Mandy says about the system class loader i think we can drop the method systemResources. There is some ?race memory" not captured in the specification, which should be updated, as Mandy says. Then? 1401 public Stream resources(String name) { 1402 return streamOf(() -> { 1403 try { 1404 return getResources(name).asIterator(); 1405 } catch (IOException e) { 1406 throw new UncheckedIOException(e); 1407 } 1408 }); 1409 } 1410 1411 private static final int RESOURCE_CHARACTERISTICS = Spliterator.NONNULL | Spliterator.IMMUTABLE; 1412 1413 static Stream streamOf(Supplier> iteratorSupplier) { 1414 return StreamSupport.stream( 1415 () -> Spliterators.spliteratorUnknownSize(iteratorSupplier.get(), RESOURCE_CHARACTERISTICS), 1416 RESOURCE_CHARACTERISTICS, false); 1417 } 1418 ? you can merge the suppliers e.g: Supplier> si = () -> { try { return Spliterators.spliteratorUnknownSize(getResources(name).asIterator(), ?); } catch (IOException e) { throw new UncheckedIOException(e); } }; return StreamSupport.stream(si, ?); ? Paul. > On 7 Sep 2016, at 11:38, Patrick Reinhart wrote: > > The current changes can be found here: > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 > From mandy.chung at oracle.com Wed Sep 7 19:42:58 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 12:42:58 -0700 Subject: Review Request: JDK-8165563 ClassLoader::getSystemClassLoader will never be null Message-ID: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165563/webrev.00/ ClassLoader::getPlatformClassLoader [1] is added in JDK 9 that is parent or ancestor of the system class loader [1]. The system class loader will never be null. Another relevant change in JDK 9 was that the system initialization was reworked that the built-in system class loader is initialized very early during startup. This patch updates ClassLoader::getSystemClassLoader to return a non-null system class loader and the implementation of a few methods to handle the null system class loader case. Mandy [1] http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#builtinLoaders From patrick at reini.net Wed Sep 7 20:14:54 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 7 Sep 2016 22:14:54 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: Hi Paul, With the change for https://bugs.openjdk.java.net/browse/JDK-8165563 that Mandy has sent to review here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043363.html the method getSystemResources where systemResources method relies on, in my understanding should be working. If I'm correct I will make my enhancement dependent on JDK-8165563 -Patrick On 07.09.2016 21:09, Paul Sandoz wrote: > Hi Patrick, > > I will sponsor this. > > Given what Mandy says about the system class loader i think we can drop the method systemResources. There is some ?race memory" not captured in the specification, which should be updated, as Mandy says. > > Then? > > 1401 public Stream resources(String name) { > 1402 return streamOf(() -> { > 1403 try { > 1404 return getResources(name).asIterator(); > 1405 } catch (IOException e) { > 1406 throw new UncheckedIOException(e); > 1407 } > 1408 }); > 1409 } > 1410 > 1411 private static final int RESOURCE_CHARACTERISTICS = Spliterator.NONNULL | Spliterator.IMMUTABLE; > 1412 > 1413 static Stream streamOf(Supplier> iteratorSupplier) { > 1414 return StreamSupport.stream( > 1415 () -> Spliterators.spliteratorUnknownSize(iteratorSupplier.get(), RESOURCE_CHARACTERISTICS), > 1416 RESOURCE_CHARACTERISTICS, false); > 1417 } > 1418 > > ? you can merge the suppliers e.g: > > Supplier> si = () -> { > try { > return Spliterators.spliteratorUnknownSize(getResources(name).asIterator(), ?); > } catch (IOException e) { > throw new UncheckedIOException(e); > } > }; > return StreamSupport.stream(si, ?); > > ? > > Paul. > > >> On 7 Sep 2016, at 11:38, Patrick Reinhart wrote: >> >> The current changes can be found here: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 >> > > > From stuart.marks at oracle.com Wed Sep 7 20:52:33 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 7 Sep 2016 13:52:33 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler Message-ID: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> Hi all, Please review this small patch to deprecate java.lang.Compiler for removal. Thanks, s'marks # HG changeset patch # User smarks # Date 1473281459 25200 # Wed Sep 07 13:50:59 2016 -0700 # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c 4285505: deprecate java.lang.Compiler Reviewed-by: XXX diff -r 76ba1b74f268 -r e520c4e6970c src/java.base/share/classes/java/lang/Compiler.java --- a/src/java.base/share/classes/java/lang/Compiler.java Tue Sep 06 16:08:54 2016 -0700 +++ b/src/java.base/share/classes/java/lang/Compiler.java Wed Sep 07 13:50:59 2016 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -29,21 +29,18 @@ * The {@code Compiler} class is provided to support Java-to-native-code * compilers and related services. By design, the {@code Compiler} class does * nothing; it serves as a placeholder for a JIT compiler implementation. + * If no compiler is available, these methods do nothing. * - *

When the Java Virtual Machine first starts, it determines if the system - * property {@code java.compiler} exists. (System properties are accessible - * through {@link System#getProperty(String)} and {@link - * System#getProperty(String, String)}. If so, it is assumed to be the name of - * a library (with a platform-dependent exact location and type); {@link - * System#loadLibrary} is called to load that library. If this loading - * succeeds, the function named {@code java_lang_Compiler_start()} in that - * library is called. - * - *

If no compiler is available, these methods do nothing. + * @deprecated JIT compilers and their technologies vary too widely to + * be controlled effectively by a standardized interface. As such, many + * JIT compiler implementations ignore this interface, and are instead + * controllable by implementation-specific mechanisms such as command-line + * options. This class is subject to removal in a future version of Java SE. * * @author Frank Yellin * @since 1.0 */ + at Deprecated(since="9", forRemoval=true) public final class Compiler { private Compiler() {} // don't make instances From paul.sandoz at oracle.com Wed Sep 7 20:59:24 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Sep 2016 13:59:24 -0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: > On 7 Sep 2016, at 13:14, Patrick Reinhart wrote: > > > Hi Paul, > > With the change for https://bugs.openjdk.java.net/browse/JDK-8165563 > that Mandy has sent to review here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043363.html > > the method getSystemResources where systemResources method relies on, in > my understanding should be working. > > If I'm correct I will make my enhancement dependent on JDK-8165563 > You are not blocked on JDK-8165563, the two can proceed independently. Just remove the method systemResources from your patch, we don?t need it as Mandy noted, since JDK-8165563 will render redundant the methods getSystemResource/getSystemResources and thus by extension would also render redundant a new method systemResources. Paul. > -Patrick > > > On 07.09.2016 21:09, Paul Sandoz wrote: >> Hi Patrick, >> >> I will sponsor this. >> >> Given what Mandy says about the system class loader i think we can drop the method systemResources. There is some ?race memory" not captured in the specification, which should be updated, as Mandy says. >> >> Then? >> >> 1401 public Stream resources(String name) { >> 1402 return streamOf(() -> { >> 1403 try { >> 1404 return getResources(name).asIterator(); >> 1405 } catch (IOException e) { >> 1406 throw new UncheckedIOException(e); >> 1407 } >> 1408 }); >> 1409 } >> 1410 >> 1411 private static final int RESOURCE_CHARACTERISTICS = Spliterator.NONNULL | Spliterator.IMMUTABLE; >> 1412 >> 1413 static Stream streamOf(Supplier> iteratorSupplier) { >> 1414 return StreamSupport.stream( >> 1415 () -> Spliterators.spliteratorUnknownSize(iteratorSupplier.get(), RESOURCE_CHARACTERISTICS), >> 1416 RESOURCE_CHARACTERISTICS, false); >> 1417 } >> 1418 >> >> ? you can merge the suppliers e.g: >> >> Supplier> si = () -> { >> try { >> return Spliterators.spliteratorUnknownSize(getResources(name).asIterator(), ?); >> } catch (IOException e) { >> throw new UncheckedIOException(e); >> } >> }; >> return StreamSupport.stream(si, ?); >> >> ? >> >> Paul. >> >> >>> On 7 Sep 2016, at 11:38, Patrick Reinhart wrote: >>> >>> The current changes can be found here: >>> >>> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 >>> >> >> >> > > From paul.sandoz at oracle.com Wed Sep 7 21:02:00 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Sep 2016 14:02:00 -0700 Subject: Review Request: JDK-8165563 ClassLoader::getSystemClassLoader will never be null In-Reply-To: References: Message-ID: > On 7 Sep 2016, at 12:42, Mandy Chung wrote: > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165563/webrev.00/ > +1 Do we have any tests that can be cleaned up? If so log a separate issue for that? Paul. > ClassLoader::getPlatformClassLoader [1] is added in JDK 9 that is parent or ancestor of the system class loader [1]. The system class loader will never be null. Another relevant change in JDK 9 was that the system initialization was reworked that the built-in system class loader is initialized very early during startup. > > This patch updates ClassLoader::getSystemClassLoader to return a non-null system class loader and the implementation of a few methods to handle the null system class loader case. > > Mandy > > [1] http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#builtinLoaders From mandy.chung at oracle.com Wed Sep 7 21:10:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 14:10:55 -0700 Subject: Review Request: JDK-8165563 ClassLoader::getSystemClassLoader will never be null In-Reply-To: References: Message-ID: <1A1AD84E-4F29-46FC-8F6F-43E9B8E41D2F@oracle.com> > On Sep 7, 2016, at 2:02 PM, Paul Sandoz wrote: > > >> On 7 Sep 2016, at 12:42, Mandy Chung wrote: >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165563/webrev.00/ >> > > +1 > > Do we have any tests that can be cleaned up? If so log a separate issue for that? I did scan on the jdk/test and don?t see any test checking for null system class loader. Some of them actually assume non-null. On the other hand, there may be JDK classes that handle the null case and can be cleaned up. I didn?t do the audit and plan to leave it for the component teams to follow up. Mandy From stuart.marks at oracle.com Wed Sep 7 21:28:48 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 7 Sep 2016 14:28:48 -0700 Subject: RFR(xs): 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text Message-ID: Hi all, Please review this very small patch to add a bit of boilerplate text to the @deprecated text for Runtime.traceInstructions() and Runtime.traceMethodCalls() specifications. Thanks, s'marks # HG changeset patch # User smarks # Date 1473283632 25200 # Wed Sep 07 14:27:12 2016 -0700 # Node ID cbcdb97e8c53d4c3a88bb61ac7bf61e7287a99de # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text Reviewed-by: XXX diff -r 76ba1b74f268 -r cbcdb97e8c53 src/java.base/share/classes/java/lang/Runtime.java --- a/src/java.base/share/classes/java/lang/Runtime.java Tue Sep 06 16:08:54 2016 -0700 +++ b/src/java.base/share/classes/java/lang/Runtime.java Wed Sep 07 14:27:12 2016 -0700 @@ -733,6 +733,7 @@ * @deprecated * This method was intended to control instruction tracing. * It has been superseded by JVM-specific tracing mechanisms. + * This method is subject to removal in a future version of Java SE. * * @param on ignored */ @@ -745,6 +746,7 @@ * @deprecated * This method was intended to control method call tracing. * It has been superseded by JVM-specific tracing mechanisms. + * This method is subject to removal in a future version of Java SE. * * @param on ignored */ From iris.clark at oracle.com Wed Sep 7 21:31:08 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 7 Sep 2016 14:31:08 -0700 (PDT) Subject: RFR(xs): 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text In-Reply-To: References: Message-ID: <5ecbd73b-50c8-4ad3-93eb-24e2292f6d50@default> Hi, Stuart. These look fine to me. Thanks, Iris -----Original Message----- From: Stuart Marks Sent: Wednesday, September 07, 2016 2:29 PM To: core-libs-dev Subject: RFR(xs): 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text Hi all, Please review this very small patch to add a bit of boilerplate text to the @deprecated text for Runtime.traceInstructions() and Runtime.traceMethodCalls() specifications. Thanks, s'marks # HG changeset patch # User smarks # Date 1473283632 25200 # Wed Sep 07 14:27:12 2016 -0700 # Node ID cbcdb97e8c53d4c3a88bb61ac7bf61e7287a99de # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text Reviewed-by: XXX diff -r 76ba1b74f268 -r cbcdb97e8c53 src/java.base/share/classes/java/lang/Runtime.java --- a/src/java.base/share/classes/java/lang/Runtime.java Tue Sep 06 16:08:54 2016 -0700 +++ b/src/java.base/share/classes/java/lang/Runtime.java Wed Sep 07 14:27:12 2016 -0700 @@ -733,6 +733,7 @@ * @deprecated * This method was intended to control instruction tracing. * It has been superseded by JVM-specific tracing mechanisms. + * This method is subject to removal in a future version of Java SE. * * @param on ignored */ @@ -745,6 +746,7 @@ * @deprecated * This method was intended to control method call tracing. * It has been superseded by JVM-specific tracing mechanisms. + * This method is subject to removal in a future version of Java SE. * * @param on ignored */ From ashipile at redhat.com Wed Sep 7 21:34:02 2016 From: ashipile at redhat.com (Aleksey Shipilev) Date: Thu, 8 Sep 2016 00:34:02 +0300 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> Message-ID: On 09/07/2016 11:52 PM, Stuart Marks wrote: > Please review this small patch to deprecate java.lang.Compiler for removal. Yes, +1. This class is very confusing to have these days. -Aleksey From joe.darcy at oracle.com Wed Sep 7 21:35:26 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 7 Sep 2016 14:35:26 -0700 Subject: RFR(xs): 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text In-Reply-To: References: Message-ID: <9241abfd-d5d9-1f06-0376-9a477b091f7e@oracle.com> Looks fine Stuart; thanks, -Joe On 9/7/2016 2:28 PM, Stuart Marks wrote: > Hi all, > > Please review this very small patch to add a bit of boilerplate text > to the @deprecated text for Runtime.traceInstructions() and > Runtime.traceMethodCalls() specifications. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1473283632 25200 > # Wed Sep 07 14:27:12 2016 -0700 > # Node ID cbcdb97e8c53d4c3a88bb61ac7bf61e7287a99de > # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c > 8165636: add removal text to Runtime.traceInstructions/MethodCalls > deprecation text > Reviewed-by: XXX > > diff -r 76ba1b74f268 -r cbcdb97e8c53 > src/java.base/share/classes/java/lang/Runtime.java > --- a/src/java.base/share/classes/java/lang/Runtime.java Tue Sep 06 > 16:08:54 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/Runtime.java Wed Sep 07 > 14:27:12 2016 -0700 > @@ -733,6 +733,7 @@ > * @deprecated > * This method was intended to control instruction tracing. > * It has been superseded by JVM-specific tracing mechanisms. > + * This method is subject to removal in a future version of Java SE. > * > * @param on ignored > */ > @@ -745,6 +746,7 @@ > * @deprecated > * This method was intended to control method call tracing. > * It has been superseded by JVM-specific tracing mechanisms. > + * This method is subject to removal in a future version of Java SE. > * > * @param on ignored > */ From mandy.chung at oracle.com Wed Sep 7 21:36:28 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 14:36:28 -0700 Subject: RFR(xs): 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text In-Reply-To: References: Message-ID: +1 Mandy > On Sep 7, 2016, at 2:28 PM, Stuart Marks wrote: > > Hi all, > > Please review this very small patch to add a bit of boilerplate text to the @deprecated text for Runtime.traceInstructions() and Runtime.traceMethodCalls() specifications. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1473283632 25200 > # Wed Sep 07 14:27:12 2016 -0700 > # Node ID cbcdb97e8c53d4c3a88bb61ac7bf61e7287a99de > # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c > 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text > Reviewed-by: XXX > > diff -r 76ba1b74f268 -r cbcdb97e8c53 src/java.base/share/classes/java/lang/Runtime.java > --- a/src/java.base/share/classes/java/lang/Runtime.java Tue Sep 06 16:08:54 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/Runtime.java Wed Sep 07 14:27:12 2016 -0700 > @@ -733,6 +733,7 @@ > * @deprecated > * This method was intended to control instruction tracing. > * It has been superseded by JVM-specific tracing mechanisms. > + * This method is subject to removal in a future version of Java SE. > * > * @param on ignored > */ > @@ -745,6 +746,7 @@ > * @deprecated > * This method was intended to control method call tracing. > * It has been superseded by JVM-specific tracing mechanisms. > + * This method is subject to removal in a future version of Java SE. > * > * @param on ignored > */ From mandy.chung at oracle.com Wed Sep 7 21:39:51 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 14:39:51 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> Message-ID: Looks fine to me. Mandy > On Sep 7, 2016, at 1:52 PM, Stuart Marks wrote: > > Hi all, > > Please review this small patch to deprecate java.lang.Compiler for removal. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1473281459 25200 > # Wed Sep 07 13:50:59 2016 -0700 > # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d > # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c > 4285505: deprecate java.lang.Compiler > Reviewed-by: XXX > > diff -r 76ba1b74f268 -r e520c4e6970c src/java.base/share/classes/java/lang/Compiler.java > --- a/src/java.base/share/classes/java/lang/Compiler.java Tue Sep 06 16:08:54 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/Compiler.java Wed Sep 07 13:50:59 2016 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -29,21 +29,18 @@ > * The {@code Compiler} class is provided to support Java-to-native-code > * compilers and related services. By design, the {@code Compiler} class does > * nothing; it serves as a placeholder for a JIT compiler implementation. > + * If no compiler is available, these methods do nothing. > * > - *

When the Java Virtual Machine first starts, it determines if the system > - * property {@code java.compiler} exists. (System properties are accessible > - * through {@link System#getProperty(String)} and {@link > - * System#getProperty(String, String)}. If so, it is assumed to be the name of > - * a library (with a platform-dependent exact location and type); {@link > - * System#loadLibrary} is called to load that library. If this loading > - * succeeds, the function named {@code java_lang_Compiler_start()} in that > - * library is called. > - * > - *

If no compiler is available, these methods do nothing. > + * @deprecated JIT compilers and their technologies vary too widely to > + * be controlled effectively by a standardized interface. As such, many > + * JIT compiler implementations ignore this interface, and are instead > + * controllable by implementation-specific mechanisms such as command-line > + * options. This class is subject to removal in a future version of Java SE. > * > * @author Frank Yellin > * @since 1.0 > */ > + at Deprecated(since="9", forRemoval=true) > public final class Compiler { > private Compiler() {} // don't make instances > From patrick at reini.net Wed Sep 7 21:40:30 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 7 Sep 2016 23:40:30 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> Message-ID: <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> Hi Paul, On 07.09.2016 22:59, Paul Sandoz wrote: >> On 7 Sep 2016, at 13:14, Patrick Reinhart wrote: >> >> >> Hi Paul, >> >> With the change for https://bugs.openjdk.java.net/browse/JDK-8165563 >> that Mandy has sent to review here: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043363.html >> >> the method getSystemResources where systemResources method relies on, in >> my understanding should be working. >> >> If I'm correct I will make my enhancement dependent on JDK-8165563 >> > You are not blocked on JDK-8165563, the two can proceed independently. > > Just remove the method systemResources from your patch, we don?t need it as Mandy noted, since JDK-8165563 will render redundant the methods getSystemResource/getSystemResources and thus by extension would also render redundant a new method systemResources. > > Paul. Now I understand the points of Mandy. I updated the webrev accordingly http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 -Patrick From forax at univ-mlv.fr Wed Sep 7 21:44:28 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 7 Sep 2016 23:44:28 +0200 (CEST) Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> Message-ID: <1809480534.1383997.1473284668442.JavaMail.zimbra@u-pem.fr> Yes, i like this patch :) Aleksey, It's worst than what you think because for a lot of people Compiler == java compiler and not JIT compiler so they try to compile a .java file with the method compileClasses(String). I'm glad this class will disappear soon. R?mi ----- Mail original ----- > De: "Aleksey Shipilev" > ?: "Stuart Marks" , "core-libs-dev" > Envoy?: Mercredi 7 Septembre 2016 23:34:02 > Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler > On 09/07/2016 11:52 PM, Stuart Marks wrote: >> Please review this small patch to deprecate java.lang.Compiler for removal. > > Yes, +1. > This class is very confusing to have these days. > > -Aleksey From stuart.marks at oracle.com Wed Sep 7 21:50:22 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 7 Sep 2016 14:50:22 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <1809480534.1383997.1473284668442.JavaMail.zimbra@u-pem.fr> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> <1809480534.1383997.1473284668442.JavaMail.zimbra@u-pem.fr> Message-ID: Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler :-) On 9/7/16 2:44 PM, Remi Forax wrote: > Yes, i like this patch :) > > Aleksey, It's worst than what you think because for a lot of people Compiler == java compiler and not JIT compiler so they try to compile a .java file with the method compileClasses(String). > > I'm glad this class will disappear soon. > > R?mi > > ----- Mail original ----- >> De: "Aleksey Shipilev" >> ?: "Stuart Marks" , "core-libs-dev" >> Envoy?: Mercredi 7 Septembre 2016 23:34:02 >> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler > >> On 09/07/2016 11:52 PM, Stuart Marks wrote: >>> Please review this small patch to deprecate java.lang.Compiler for removal. >> >> Yes, +1. >> This class is very confusing to have these days. >> >> -Aleksey From patrick at reini.net Wed Sep 7 21:57:44 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 7 Sep 2016 23:57:44 +0200 Subject: Review Request: JDK-8165563 ClassLoader::getSystemClassLoader will never be null In-Reply-To: References: Message-ID: Hi Mandy Found a tiny typo ony line 1453, that could also be fixed with this change: 1451 * @throws IOException 1452 * If I/O errors occur 1453 1454 * @since 1.2 1455 */ 1456 public static Enumeration getSystemResources(String name) -Patrick On 07.09.2016 21:42, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165563/webrev.00/ > > ClassLoader::getPlatformClassLoader [1] is added in JDK 9 that is parent or ancestor of the system class loader [1]. The system class loader will never be null. Another relevant change in JDK 9 was that the system initialization was reworked that the built-in system class loader is initialized very early during startup. > > This patch updates ClassLoader::getSystemClassLoader to return a non-null system class loader and the implementation of a few methods to handle the null system class loader case. > > Mandy > > [1] http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#builtinLoaders From naoto.sato at oracle.com Wed Sep 7 22:03:11 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 7 Sep 2016 15:03:11 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base Message-ID: Please review the changes to the subject bug: https://bugs.openjdk.java.net/browse/JDK-8165605 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8165605/webrev.00/ The change is simply to move those 3 resources under sun.text.resources.ext package so that it won't cause the split package issue. Naoto From paul.sandoz at oracle.com Wed Sep 7 22:34:30 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Sep 2016 15:34:30 -0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> Message-ID: <72AFEAB3-2FF4-44A2-B854-2A390FB7DA22@oracle.com> > On 7 Sep 2016, at 14:40, Patrick Reinhart wrote: > > I updated the webrev accordingly > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 > Looks good. I?ll handle the internal process bits. Paul. From rednaxelafx at gmail.com Wed Sep 7 22:45:39 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 7 Sep 2016 15:45:39 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> <1809480534.1383997.1473284668442.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Stuart, I see that on the JBS page, your most recent comment says it's been decided that for JDK9 it's okay to deprecate and forRemoval=true, while also mentioning the uses of this class in IBM's implementation. Does that mean IBM has agreed on the deprecation of this class? I thought J9 had features that allowed Java applications to do fine-grained control over the JIT compiler at runtime, e.g. force compilation of specified methods *at some certain point* in the program. What JEP 165 is proposing can only statically configure JIT behaviors for HotSpot. The same approach doesn't seem to cover what J9 used to support. Could you please share more background on the discussions that led to the decision? Thanks, Kris On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks wrote: > Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler > > :-) > > > On 9/7/16 2:44 PM, Remi Forax wrote: > >> Yes, i like this patch :) >> >> Aleksey, It's worst than what you think because for a lot of people >> Compiler == java compiler and not JIT compiler so they try to compile a >> .java file with the method compileClasses(String). >> >> I'm glad this class will disappear soon. >> >> R?mi >> >> ----- Mail original ----- >> >>> De: "Aleksey Shipilev" >>> ?: "Stuart Marks" , "core-libs-dev" < >>> core-libs-dev at openjdk.java.net> >>> Envoy?: Mercredi 7 Septembre 2016 23:34:02 >>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler >>> >> >> On 09/07/2016 11:52 PM, Stuart Marks wrote: >>> >>>> Please review this small patch to deprecate java.lang.Compiler for >>>> removal. >>>> >>> >>> Yes, +1. >>> This class is very confusing to have these days. >>> >>> -Aleksey >>> >> From huizhe.wang at oracle.com Wed Sep 7 22:51:16 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 07 Sep 2016 15:51:16 -0700 Subject: Deprecate JDK internal Catalog API in JDK 9 Message-ID: <57D099E4.105@oracle.com> Hi, With the introduction of the new public Catalog API [1][2], we'd like to consider deprecating the old JDK internal API in package com.sun.org.apache.xml.internal.resolver and com.sun.org.apache.xerces.internal.util.XMLCatalogResolver. With JDK 9, this internal API is encapsulated (not exported), users of this API will shall consider migrating to the public API. The deprecation therefore is a further notice and also serves as an option to remove it in the future. Your feedback on this proposal is welcome. [1] http://openjdk.java.net/jeps/268 [2] http://download.java.net/java/jdk9/docs/api/javax/xml/catalog/package-summary.html Thanks, Joe From mandy.chung at oracle.com Wed Sep 7 22:53:25 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 15:53:25 -0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> Message-ID: <98ACE72C-1D69-41F9-B59D-6DC07B309D3D@oracle.com> > On Sep 7, 2016, at 2:40 PM, Patrick Reinhart wrote: > > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 Thanks for the update. Looks good. Mandy From naoto.sato at oracle.com Wed Sep 7 22:56:41 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 7 Sep 2016 15:56:41 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: Message-ID: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> Forgot to include jlink plugin changes. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8165605/webrev.01/ Naoto On 9/7/16 3:03 PM, Naoto Sato wrote: > Please review the changes to the subject bug: > > https://bugs.openjdk.java.net/browse/JDK-8165605 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8165605/webrev.00/ > > The change is simply to move those 3 resources under > sun.text.resources.ext package so that it won't cause the split package > issue. > > Naoto From stuart.marks at oracle.com Wed Sep 7 23:42:41 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 7 Sep 2016 16:42:41 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> <1809480534.1383997.1473284668442.JavaMail.zimbra@u-pem.fr> Message-ID: <5ee713b2-daa6-ce23-2836-17526b96a86e@oracle.com> Hi Kris, Well, there's not much background. We did contact IBM in regard to the mentions of java.lang.Compiler from their product pages, and they were OK with deprecating the API for removal. I can't speak to what impact this might have on IBM's products. I don't know much about JEP 165 [1] but it does appear to be able to update compiler directives at runtime. It doesn't seem to match the semantics of java.lang.Compiler. On the other hand, j.l.Compiler was introduced in the JDK 1.0 time frame, before production Java JIT compilers were delivered, so it's unlikely that its semantics match the needs of a modern JIT implementation. I really don't think anything is being lost by the deprecation and eventual removal of java.lang.Compiler. If anything, it's an improvement, as R?mi noted, since people will no longer confuse it with an API for invoking javac. s'marks [1] http://openjdk.java.net/jeps/165 On 9/7/16 3:45 PM, Krystal Mok wrote: > Hi Stuart, > > I see that on the JBS page, your most recent comment says it's been decided > that for JDK9 it's okay to deprecate and forRemoval=true, while also > mentioning the uses of this class in IBM's implementation. > > Does that mean IBM has agreed on the deprecation of this class? I thought J9 > had features that allowed Java applications to do fine-grained control over > the JIT compiler at runtime, e.g. force compilation of specified methods /at > some certain point/ in the program. > What JEP 165 is proposing can only statically configure JIT behaviors for > HotSpot. The same approach doesn't seem to cover what J9 used to support. > > Could you please share more background on the discussions that led to the > decision? > > Thanks, > Kris > > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks > wrote: > > Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler > > :-) > > > On 9/7/16 2:44 PM, Remi Forax wrote: > > Yes, i like this patch :) > > Aleksey, It's worst than what you think because for a lot of people > Compiler == java compiler and not JIT compiler so they try to compile > a .java file with the method compileClasses(String). > > I'm glad this class will disappear soon. > > R?mi > > ----- Mail original ----- > > De: "Aleksey Shipilev" > > ?: "Stuart Marks" >, "core-libs-dev" > > > Envoy?: Mercredi 7 Septembre 2016 23:34:02 > Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler > > > On 09/07/2016 11:52 PM, Stuart Marks wrote: > > Please review this small patch to deprecate java.lang.Compiler > for removal. > > > Yes, +1. > This class is very confusing to have these days. > > -Aleksey > > From rednaxelafx at gmail.com Wed Sep 7 23:57:15 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 7 Sep 2016 16:57:15 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <5ee713b2-daa6-ce23-2836-17526b96a86e@oracle.com> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> <1809480534.1383997.1473284668442.JavaMail.zimbra@u-pem.fr> <5ee713b2-daa6-ce23-2836-17526b96a86e@oracle.com> Message-ID: Hi Stuart, Thanks for your reply. Indeed, the class doesn't really fit into the modern world as it is now, for its original intended purpose. So, for its original intent of configuring and controlling the JIT compiler(s), I'm more than happy about the deprecation. There are a couple of scenarios that I know of that make uses of the java.lang.Compiler class as a generic entry point into the VM, not related to the original intent at all. Let me think a bit about how to phrase those scenarios correctly and update in a follow-up reply. Thanks, Kris On Wed, Sep 7, 2016 at 4:42 PM, Stuart Marks wrote: > Hi Kris, > > Well, there's not much background. We did contact IBM in regard to the > mentions of java.lang.Compiler from their product pages, and they were OK > with deprecating the API for removal. I can't speak to what impact this > might have on IBM's products. > > I don't know much about JEP 165 [1] but it does appear to be able to > update compiler directives at runtime. It doesn't seem to match the > semantics of java.lang.Compiler. On the other hand, j.l.Compiler was > introduced in the JDK 1.0 time frame, before production Java JIT compilers > were delivered, so it's unlikely that its semantics match the needs of a > modern JIT implementation. > > I really don't think anything is being lost by the deprecation and > eventual removal of java.lang.Compiler. If anything, it's an improvement, > as R?mi noted, since people will no longer confuse it with an API for > invoking javac. > > s'marks > > [1] http://openjdk.java.net/jeps/165 > > On 9/7/16 3:45 PM, Krystal Mok wrote: > > Hi Stuart, > > I see that on the JBS page, your most recent comment says it's been > decided that for JDK9 it's okay to deprecate and forRemoval=true, while > also mentioning the uses of this class in IBM's implementation. > > Does that mean IBM has agreed on the deprecation of this class? I thought > J9 had features that allowed Java applications to do fine-grained control > over the JIT compiler at runtime, e.g. force compilation of specified > methods *at some certain point* in the program. > What JEP 165 is proposing can only statically configure JIT behaviors for > HotSpot. The same approach doesn't seem to cover what J9 used to support. > > Could you please share more background on the discussions that led to the > decision? > > Thanks, > Kris > > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks > wrote: > >> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler >> >> :-) >> >> >> On 9/7/16 2:44 PM, Remi Forax wrote: >> >>> Yes, i like this patch :) >>> >>> Aleksey, It's worst than what you think because for a lot of people >>> Compiler == java compiler and not JIT compiler so they try to compile a >>> .java file with the method compileClasses(String). >>> >>> I'm glad this class will disappear soon. >>> >>> R?mi >>> >>> ----- Mail original ----- >>> >>>> De: "Aleksey Shipilev" >>>> ?: "Stuart Marks" , "core-libs-dev" < >>>> core-libs-dev at openjdk.java.net> >>>> Envoy?: Mercredi 7 Septembre 2016 23:34:02 >>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler >>>> >>> >>> On 09/07/2016 11:52 PM, Stuart Marks wrote: >>>> >>>>> Please review this small patch to deprecate java.lang.Compiler for >>>>> removal. >>>>> >>>> >>>> Yes, +1. >>>> This class is very confusing to have these days. >>>> >>>> -Aleksey >>>> >>> > > From mandy.chung at oracle.com Thu Sep 8 00:17:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 17:17:55 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> Message-ID: <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> Hi Naoto, Is there an alternative to get back the pathname of the resource e.g. adding a method in existing internal SPI to avoid hardcoding the module name and the resource pathname. Mandy > On Sep 7, 2016, at 3:56 PM, Naoto Sato wrote: > > Forgot to include jlink plugin changes. Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8165605/webrev.01/ > > Naoto > > On 9/7/16 3:03 PM, Naoto Sato wrote: >> Please review the changes to the subject bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8165605 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8165605/webrev.00/ >> >> The change is simply to move those 3 resources under >> sun.text.resources.ext package so that it won't cause the split package >> issue. >> >> Naoto From mandy.chung at oracle.com Thu Sep 8 00:56:44 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 17:56:44 -0700 Subject: RFR: 8163014: Mysterious/wrong value for "long" frame local variable on 64-bit In-Reply-To: References: <57CF363F.7020600@oracle.com> <10d939f8-45b1-4324-e6e0-92d6930a0c86@oracle.com> <57D01173.3040607@oracle.com> Message-ID: <235922EF-2EB1-4520-A115-1F7ADBD8AB0A@oracle.com> > On Sep 7, 2016, at 6:35 AM, Coleen Phillimore wrote: > > > > On 9/7/16 9:09 AM, Max Ockner wrote: >> Does the stackwalk API have access to the type of variable at each slot? Where is this information stored? My operating assumption was that it did not have this information, and therefore needed to read the garbage slot. > > This is true. The StackWalk API does not have type information for these longs, so this prevents garbage values from being read. > Adding core-libs. AFAIU, the type information is not available in the current implementation. The current non-public API does include the type but I plan to revise it and revisit in the future. Mandy From naoto.sato at oracle.com Thu Sep 8 01:29:53 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 7 Sep 2016 18:29:53 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> Message-ID: Hi Mandy, Although avoiding the hardcoded pathname is good, it is specific to the BreakIterator implementation of the COMPAT provider. So I am not sure making a generic SPI would be needed here. Anyway, this split package issue is blocking Alan's push, so I'd like to push the change as it is. We can get back to this later. Naoto On 9/7/16 5:17 PM, Mandy Chung wrote: > Hi Naoto, > > Is there an alternative to get back the pathname of the resource e.g. adding a method in existing internal SPI to avoid hardcoding the module name and the resource pathname. > > Mandy > >> On Sep 7, 2016, at 3:56 PM, Naoto Sato wrote: >> >> Forgot to include jlink plugin changes. Here is the updated webrev: >> >> http://cr.openjdk.java.net/~naoto/8165605/webrev.01/ >> >> Naoto >> >> On 9/7/16 3:03 PM, Naoto Sato wrote: >>> Please review the changes to the subject bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8165605 >>> >>> The proposed fix is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8165605/webrev.00/ >>> >>> The change is simply to move those 3 resources under >>> sun.text.resources.ext package so that it won't cause the split package >>> issue. >>> >>> Naoto > From mandy.chung at oracle.com Thu Sep 8 01:37:34 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Sep 2016 18:37:34 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> Message-ID: > On Sep 7, 2016, at 6:29 PM, Naoto Sato wrote: > > Hi Mandy, > > Although avoiding the hardcoded pathname is good, it is specific to the BreakIterator implementation of the COMPAT provider. So I am not sure making a generic SPI would be needed here. I was thinking of one of the internal services that jdk.localedata currently provides. > > Anyway, this split package issue is blocking Alan's push, so I'd like to push the change as it is. We can get back to this later. I agree this can be cleaned up as a separate issue. 152 InputStream is = module.getResourceAsStream( 153 ("jdk.localedata".equals(module.getName()) ? 154 "sun/text/resources/ext/" : "sun/text/resources/") + dictionaryName); It may be easier to read if line 153-154 are moved and assign to a separate variable. Otherwise, looks fine. Mandy > > Naoto > > On 9/7/16 5:17 PM, Mandy Chung wrote: >> Hi Naoto, >> >> Is there an alternative to get back the pathname of the resource e.g. adding a method in existing internal SPI to avoid hardcoding the module name and the resource pathname. >> >> Mandy >> >>> On Sep 7, 2016, at 3:56 PM, Naoto Sato wrote: >>> >>> Forgot to include jlink plugin changes. Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~naoto/8165605/webrev.01/ >>> >>> Naoto >>> >>> On 9/7/16 3:03 PM, Naoto Sato wrote: >>>> Please review the changes to the subject bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8165605 >>>> >>>> The proposed fix is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8165605/webrev.00/ >>>> >>>> The change is simply to move those 3 resources under >>>> sun.text.resources.ext package so that it won't cause the split package >>>> issue. >>>> >>>> Naoto >> From masayoshi.okutsu at oracle.com Thu Sep 8 02:51:22 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 8 Sep 2016 11:51:22 +0900 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> Message-ID: <81e12bc9-df11-580e-23f1-a6c2222c53c2@oracle.com> I thought Mandy suggested that the dictionary names in a ResourceBundle contain path names rather than base names, something like this: In BreakIteratorInfo_th.java: {"WordDictionary", "thai_dict"}, to {"WordDictionary", "sun/text/resources/ext/thai_dict"}, I haven't checked any side effects of this change, though. I still prefer that a ResourceBundle for BreakIterators returns dictionary data by calling getObject(key). But it'd be a bit late to make that change for JDK 9. Thanks, Masayoshi On 9/8/2016 10:37 AM, Mandy Chung wrote: >> On Sep 7, 2016, at 6:29 PM, Naoto Sato wrote: >> >> Hi Mandy, >> >> Although avoiding the hardcoded pathname is good, it is specific to the BreakIterator implementation of the COMPAT provider. So I am not sure making a generic SPI would be needed here. > I was thinking of one of the internal services that jdk.localedata currently provides. > >> Anyway, this split package issue is blocking Alan's push, so I'd like to push the change as it is. We can get back to this later. > I agree this can be cleaned up as a separate issue. > > 152 InputStream is = module.getResourceAsStream( > 153 ("jdk.localedata".equals(module.getName()) ? > 154 "sun/text/resources/ext/" : "sun/text/resources/") + dictionaryName); > > It may be easier to read if line 153-154 are moved and assign to a separate variable. Otherwise, looks fine. > > Mandy > >> Naoto >> >> On 9/7/16 5:17 PM, Mandy Chung wrote: >>> Hi Naoto, >>> >>> Is there an alternative to get back the pathname of the resource e.g. adding a method in existing internal SPI to avoid hardcoding the module name and the resource pathname. >>> >>> Mandy >>> >>>> On Sep 7, 2016, at 3:56 PM, Naoto Sato wrote: >>>> >>>> Forgot to include jlink plugin changes. Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~naoto/8165605/webrev.01/ >>>> >>>> Naoto >>>> >>>> On 9/7/16 3:03 PM, Naoto Sato wrote: >>>>> Please review the changes to the subject bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8165605 >>>>> >>>>> The proposed fix is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8165605/webrev.00/ >>>>> >>>>> The change is simply to move those 3 resources under >>>>> sun.text.resources.ext package so that it won't cause the split package >>>>> issue. >>>>> >>>>> Naoto From david.holmes at oracle.com Thu Sep 8 02:53:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Sep 2016 12:53:33 +1000 Subject: Review Request: JDK-8165563 ClassLoader::getSystemClassLoader will never be null In-Reply-To: References: Message-ID: <4044a52d-9739-2335-3987-a4d865ac8703@oracle.com> Hi Mandy, On 8/09/2016 5:42 AM, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165563/webrev.00/ > > ClassLoader::getPlatformClassLoader [1] is added in JDK 9 that is parent or ancestor of the system class loader [1]. The system class loader will never be null. Another relevant change in JDK 9 was that the system initialization was reworked that the built-in system class loader is initialized very early during startup. Despite code to contrary, I don't think the system classloader has "ever" been allowed to be null. If it can't be constructed then the whole initialization process will fail with an exception. But the changes taking advantage of that look good! :) Thanks, David ----- > This patch updates ClassLoader::getSystemClassLoader to return a non-null system class loader and the implementation of a few methods to handle the null system class loader case. > > Mandy > > [1] http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#builtinLoaders > From frank.yuan at oracle.com Thu Sep 8 03:33:23 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 8 Sep 2016 11:33:23 +0800 Subject: RFR JDK-8165617: Cleanup whitespace in jaxp/test Message-ID: <018c01d20981$c1e0ebe0$45a2c3a0$@oracle.com> Hi This bug is to remove the extra LF from the end of the java files, that will help to conform with the normalizer. Anyone would like to take a look? http://cr.openjdk.java.net/~fyuan/8165617/webrev.00/ Thanks Frank From huizhe.wang at oracle.com Thu Sep 8 04:11:25 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 07 Sep 2016 21:11:25 -0700 Subject: RFR JDK-8165617: Cleanup whitespace in jaxp/test In-Reply-To: <018c01d20981$c1e0ebe0$45a2c3a0$@oracle.com> References: <018c01d20981$c1e0ebe0$45a2c3a0$@oracle.com> Message-ID: <57D0E4ED.10505@oracle.com> Hi Frank, Looks good. Thanks for getting this cleaned up! Best, Joe On 9/7/16, 8:33 PM, Frank Yuan wrote: > Hi > > This bug is to remove the extra LF from the end of the java files, that will help to conform with the normalizer. > > Anyone would like to take a look? http://cr.openjdk.java.net/~fyuan/8165617/webrev.00/ > > > Thanks > Frank > From frank.yuan at oracle.com Thu Sep 8 04:34:36 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 8 Sep 2016 12:34:36 +0800 Subject: RFR JDK-8165617: Cleanup whitespace in jaxp/test In-Reply-To: <57D0E4ED.10505@oracle.com> References: <018c01d20981$c1e0ebe0$45a2c3a0$@oracle.com> <57D0E4ED.10505@oracle.com> Message-ID: <019a01d2098a$4f3361f0$ed9a25d0$@oracle.com> Thank you! Pushed. Frank -----Original Message----- From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Thursday, September 08, 2016 12:11 PM To: Frank Yuan Cc: 'core-libs-dev' Subject: Re: RFR JDK-8165617: Cleanup whitespace in jaxp/test Hi Frank, Looks good. Thanks for getting this cleaned up! Best, Joe On 9/7/16, 8:33 PM, Frank Yuan wrote: > Hi > > This bug is to remove the extra LF from the end of the java files, that will help to conform with the normalizer. > > Anyone would like to take a look? http://cr.openjdk.java.net/~fyuan/8165617/webrev.00/ > > > Thanks > Frank > From christoph.langer at sap.com Thu Sep 8 06:43:45 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 8 Sep 2016 06:43:45 +0000 Subject: RFR JDK-8165617: Cleanup whitespace in jaxp/test In-Reply-To: <019a01d2098a$4f3361f0$ed9a25d0$@oracle.com> References: <018c01d20981$c1e0ebe0$45a2c3a0$@oracle.com> <57D0E4ED.10505@oracle.com> <019a01d2098a$4f3361f0$ed9a25d0$@oracle.com> Message-ID: <1411c9a304bb43bcb5ed54ceaf48d5ee@DEWDFE13DE11.global.corp.sap> Hi Frank, just out of interest: Is it a rule not to have any LFs at the end of java files? Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Frank Yuan > Sent: Donnerstag, 8. September 2016 06:35 > To: 'Joe Wang' > Cc: 'core-libs-dev' > Subject: RE: RFR JDK-8165617: Cleanup whitespace in jaxp/test > > Thank you! Pushed. > > Frank > > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Sent: Thursday, September 08, 2016 12:11 PM > To: Frank Yuan > Cc: 'core-libs-dev' > Subject: Re: RFR JDK-8165617: Cleanup whitespace in jaxp/test > > Hi Frank, > > Looks good. Thanks for getting this cleaned up! > > Best, > Joe > > On 9/7/16, 8:33 PM, Frank Yuan wrote: > > Hi > > > > This bug is to remove the extra LF from the end of the java files, that will help > to conform with the normalizer. > > > > Anyone would like to take a look? > http://cr.openjdk.java.net/~fyuan/8165617/webrev.00/ > > > > > > Thanks > > Frank > > From Alan.Bateman at oracle.com Thu Sep 8 06:52:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Sep 2016 07:52:12 +0100 Subject: Review Request: JDK-8165563 ClassLoader::getSystemClassLoader will never be null In-Reply-To: <4044a52d-9739-2335-3987-a4d865ac8703@oracle.com> References: <4044a52d-9739-2335-3987-a4d865ac8703@oracle.com> Message-ID: <75b5646a-9f43-8e4a-41bd-8d79d2d12bdd@oracle.com> On 08/09/2016 03:53, David Holmes wrote: > Despite code to contrary, I don't think the system classloader has > "ever" been allowed to be null. If it can't be constructed then the > whole initialization process will fail with an exception. In the JDK then that's true, I think allowing it be null was for another scenario. It's also possible it may have returned null during startup in previous releases but that is hard to test (and completely changed in JDK 9 so a non-issue). > > But the changes taking advantage of that look good! :) I agree, the changes look good. -Alan From frank.yuan at oracle.com Thu Sep 8 07:07:31 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 8 Sep 2016 15:07:31 +0800 Subject: RFR JDK-8165617: Cleanup whitespace in jaxp/test In-Reply-To: <1411c9a304bb43bcb5ed54ceaf48d5ee@DEWDFE13DE11.global.corp.sap> References: <018c01d20981$c1e0ebe0$45a2c3a0$@oracle.com> <57D0E4ED.10505@oracle.com> <019a01d2098a$4f3361f0$ed9a25d0$@oracle.com> <1411c9a304bb43bcb5ed54ceaf48d5ee@DEWDFE13DE11.global.corp.sap> Message-ID: <01c801d2099f$af3a0170$0dae0450$@oracle.com> The normalizer tool will remove any extra LFs, only leave one. But it may be an internal tool, so I think it's not a rule. Thanks Frank > -----Original Message----- > From: Langer, Christoph [mailto:christoph.langer at sap.com] > Subject: RE: RFR JDK-8165617: Cleanup whitespace in jaxp/test > > Hi Frank, > > just out of interest: Is it a rule not to have any LFs at the end of java files? > > Best regards > Christoph > > > -----Original Message----- > > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > > Of Frank Yuan > > Sent: Donnerstag, 8. September 2016 06:35 > > To: 'Joe Wang' > > Cc: 'core-libs-dev' > > Subject: RE: RFR JDK-8165617: Cleanup whitespace in jaxp/test > > > > Thank you! Pushed. > > > > Frank > > > > -----Original Message----- > > From: Joe Wang [mailto:huizhe.wang at oracle.com] > > Sent: Thursday, September 08, 2016 12:11 PM > > To: Frank Yuan > > Cc: 'core-libs-dev' > > Subject: Re: RFR JDK-8165617: Cleanup whitespace in jaxp/test > > > > Hi Frank, > > > > Looks good. Thanks for getting this cleaned up! > > > > Best, > > Joe > > > > On 9/7/16, 8:33 PM, Frank Yuan wrote: > > > Hi > > > > > > This bug is to remove the extra LF from the end of the java files, that will help > > to conform with the normalizer. > > > > > > Anyone would like to take a look? > > http://cr.openjdk.java.net/~fyuan/8165617/webrev.00/ > > > > > > > > > Thanks > > > Frank > > > From Alan.Bateman at oracle.com Thu Sep 8 07:13:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Sep 2016 08:13:40 +0100 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> Message-ID: <57af294a-8a18-82be-d660-4fd5da2f27fe@oracle.com> On 07/09/2016 21:52, Stuart Marks wrote: > Hi all, > > Please review this small patch to deprecate java.lang.Compiler for > removal. Looks good, often confusing to see it in the javadoc. -Alan From andrej.golovnin at gmail.com Thu Sep 8 07:16:01 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 8 Sep 2016 09:16:01 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: <98ACE72C-1D69-41F9-B59D-6DC07B309D3D@oracle.com> References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> <98ACE72C-1D69-41F9-B59D-6DC07B309D3D@oracle.com> Message-ID: Hi all, Maybe I'm wrong but I think the JavaDocs for the new method need more love. The JavaDocs mention at multiple places that resources are loaded, e.g.: 1362 * Returns a stream that loads the resources with the given name. 1375 *

The loading of resources will occur when the returned stream is 1376 * evaluated. If the loading of resources results in an {@code IOException} In reality however, no resources are loaded. Only URLs for all resources that match the given name are created. To load the resources you must open the connection on the returned URLs. Therefore I think the JavaDocs do not reflect what the method does. And one more thing. Because we have now only one method to get a stream I think the constant RESOURCE_CHARACTERISTICS should be defined inside the #resources()-method. It is not needed to define it as a static final field. Best regards, Andrej Golovnin On Thu, Sep 8, 2016 at 12:53 AM, Mandy Chung wrote: > >> On Sep 7, 2016, at 2:40 PM, Patrick Reinhart wrote: >> >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 > > Thanks for the update. Looks good. > > Mandy From ramanand.patil at oracle.com Thu Sep 8 09:21:23 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 8 Sep 2016 02:21:23 -0700 (PDT) Subject: RFR: 8160951, 8160958: "Test javax/xml/bind/marshal/8134111/UnmarshalTest.java should be added into :needs_jre group", "Test java/net/SetFactoryPermission/SetFactoryPermission.java should be added into :needs_compact2 group" In-Reply-To: <5a7b02d5-390d-4817-a8be-5e8b4fefbe98@default> References: <5a7b02d5-390d-4817-a8be-5e8b4fefbe98@default> Message-ID: <5330e212-85b1-4e19-993b-1bcfd4a680e4@default> Gentle reminder... Please review this trivial change. Regards, Ramanand. -----Original Message----- From: Ramanand Patil Sent: Wednesday, August 31, 2016 3:02 PM To: core-libs-dev at openjdk.java.net Subject: RFR: 8160951, 8160958: "Test javax/xml/bind/marshal/8134111/UnmarshalTest.java should be added into :needs_jre group", "Test java/net/SetFactoryPermission/SetFactoryPermission.java should be added into :needs_compact2 group" Hi all, Please review this trivial fix which addresses the mentioned 2 bugs. Bugs: 1. https://bugs.openjdk.java.net/browse/JDK-8160951 2. https://bugs.openjdk.java.net/browse/JDK-8160958 Webrev: http://cr.openjdk.java.net/~rpatil/8160951%2b8160958/webrev.00/ Only test/TEST.groups is modified to add these tests to the required group. Regards, Ramanand. From ivan.gerasimov at oracle.com Thu Sep 8 09:44:43 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 8 Sep 2016 12:44:43 +0300 Subject: RFR: 8160951, 8160958: "Test javax/xml/bind/marshal/8134111/UnmarshalTest.java should be added into :needs_jre group", "Test java/net/SetFactoryPermission/SetFactoryPermission.java should be added into :needs_compact2 group" In-Reply-To: <5330e212-85b1-4e19-993b-1bcfd4a680e4@default> References: <5a7b02d5-390d-4817-a8be-5e8b4fefbe98@default> <5330e212-85b1-4e19-993b-1bcfd4a680e4@default> Message-ID: Looks good to me, Ramanand! With kind regards, Ivan On 08.09.2016 12:21, Ramanand Patil wrote: > Gentle reminder... > Please review this trivial change. > > > Regards, > Ramanand. > > -----Original Message----- > From: Ramanand Patil > Sent: Wednesday, August 31, 2016 3:02 PM > To: core-libs-dev at openjdk.java.net > Subject: RFR: 8160951, 8160958: "Test javax/xml/bind/marshal/8134111/UnmarshalTest.java should be added into :needs_jre group", "Test java/net/SetFactoryPermission/SetFactoryPermission.java should be added into :needs_compact2 group" > > Hi all, > Please review this trivial fix which addresses the mentioned 2 bugs. > > Bugs: > 1. https://bugs.openjdk.java.net/browse/JDK-8160951 > 2. https://bugs.openjdk.java.net/browse/JDK-8160958 > > Webrev: http://cr.openjdk.java.net/~rpatil/8160951%2b8160958/webrev.00/ > > Only test/TEST.groups is modified to add these tests to the required group. > > > Regards, > Ramanand. > From Alan.Bateman at oracle.com Thu Sep 8 12:46:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Sep 2016 13:46:14 +0100 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: <81e12bc9-df11-580e-23f1-a6c2222c53c2@oracle.com> References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> <81e12bc9-df11-580e-23f1-a6c2222c53c2@oracle.com> Message-ID: On 08/09/2016 03:51, Masayoshi Okutsu wrote: > I thought Mandy suggested that the dictionary names in a > ResourceBundle contain path names rather than base names, something > like this: > > In BreakIteratorInfo_th.java: > > {"WordDictionary", "thai_dict"}, > to > {"WordDictionary", "sun/text/resources/ext/thai_dict"}, > > I haven't checked any side effects of this change, though. That would be cleaner, assuming it doesn't cause issues. -Alan From harold.seigel at oracle.com Thu Sep 8 13:23:04 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 8 Sep 2016 09:23:04 -0400 Subject: RFR 8165634: Support multiple --add-module options on the command line Message-ID: Hi, Please review this fix for JDK-8165634. The fix changes the --add-modules option from being a 'last one wins' option to a cumulative one. With this change, if multiple --add-modules options are specified, the VM accumulates all the options' values, instead of ignoring all but the last option's value. The --add-modules values are reported back to the JDK as properties using the Arguments::create_numbered_property() function. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8165634 Open webrevs: http://cr.openjdk.java.net/~hseigel/bug_8165634.hs/ http://cr.openjdk.java.net/~hseigel/bug_8165634.jdk/ The fix was tested with the JCK Lang and VM tests, the hotpot, and java/lang, java/util and other JTreg tests, the RBT tier2 tests, and the NSK non-colocated quick tests. The JDK changes were done by Mandy Chung (mchung). Thanks, Harold From jwkozaczuk at gmail.com Tue Sep 6 23:33:50 2016 From: jwkozaczuk at gmail.com (Waldek Kozaczuk) Date: Tue, 6 Sep 2016 19:33:50 -0400 Subject: Jdeps logic resolve unnecessary dependencies Message-ID: So jdeps can recursively identify all dependencies given a list of the jars that my application is made of. Assume my main application jar is app.jar and it depends (per gradle or maven dependencies resolution) on following libraries like so: app.jar ----> a.jar, b.jar a.jar --> x.jar, y.jar, z.jar x.jar -> profile1 y.jar -> profile2 z.jar -> profile3 And now assume that the app.jar in reality depends only on the part of a.jar that depends only on x.jar. In other words in reality statically (no reflection) my application does not really depend on y.jar and z.jar and only needs compact1 to execute properly. There are libraries that are "well focused" and have very few dependencies and there are those that pull ton of dependencies even though an application may only be using 5% of it. Would jdeps show only real or all dependencies in this case? If latter would it show enough information that can be analyzed to determine that y.jar and z.jar are not really needed and can be removed from my deployment? Would Java 9 jdeps work differently in this case? Would jlink be able to figure the "real" dependencies and only pull really needed JRE modules into the output image? Waldek From mandy.chung at oracle.com Thu Sep 8 14:57:38 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Sep 2016 07:57:38 -0700 Subject: Review Request: JDK-8165563 ClassLoader::getSystemClassLoader will never be null In-Reply-To: <75b5646a-9f43-8e4a-41bd-8d79d2d12bdd@oracle.com> References: <4044a52d-9739-2335-3987-a4d865ac8703@oracle.com> <75b5646a-9f43-8e4a-41bd-8d79d2d12bdd@oracle.com> Message-ID: <792029FE-C29D-4A3E-8D46-2D221B76214F@oracle.com> > On Sep 7, 2016, at 11:52 PM, Alan Bateman wrote: > > On 08/09/2016 03:53, David Holmes wrote: > >> Despite code to contrary, I don't think the system classloader has "ever" been allowed to be null. If it can't be constructed then the whole initialization process will fail with an exception. > In the JDK then that's true, I think allowing it be null was for another scenario. It's also possible it may have returned null during startup in previous releases but that is hard to test (and completely changed in JDK 9 so a non-issue). Yes exactly. That?s one possible case before the system initialization was reworked in JDK 9. Mandy From naoto.sato at oracle.com Thu Sep 8 15:00:51 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 8 Sep 2016 08:00:51 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> <81e12bc9-df11-580e-23f1-a6c2222c53c2@oracle.com> Message-ID: Well, actually I tried this approach first, then found out that the data files are also used by the GenerateBreakIteratorData build tool which has some implicit assumption of the value being the file name w/o path. So I ended up with the fix. Naoto On 9/8/16 5:46 AM, Alan Bateman wrote: > > > On 08/09/2016 03:51, Masayoshi Okutsu wrote: >> I thought Mandy suggested that the dictionary names in a >> ResourceBundle contain path names rather than base names, something >> like this: >> >> In BreakIteratorInfo_th.java: >> >> {"WordDictionary", "thai_dict"}, >> to >> {"WordDictionary", "sun/text/resources/ext/thai_dict"}, >> >> I haven't checked any side effects of this change, though. > That would be cleaner, assuming it doesn't cause issues. > > -Alan From patrick at reini.net Thu Sep 8 15:20:47 2016 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 08 Sep 2016 17:20:47 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> <98ACE72C-1D69-41F9-B59D-6DC07B309D3D@oracle.com> Message-ID: On 2016-09-08 09:16, Andrej Golovnin wrote: > Hi all, > > Maybe I'm wrong but I think the JavaDocs for the new method need more > love. The JavaDocs mention at multiple places that resources are > loaded, e.g.: > > 1362 * Returns a stream that loads the resources with the given > name. > > 1375 *

The loading of resources will occur when the returned > stream is > 1376 * evaluated. If the loading of resources results in an > {@code IOException} > > In reality however, no resources are loaded. Only URLs for all > resources that match the given name are created. To load the resources > you must open the connection on the returned URLs. Therefore I think > the JavaDocs do not reflect what the method does. What do you suggest to write instead? > And one more thing. Because we have now only one method to get a > stream I think the constant RESOURCE_CHARACTERISTICS should be defined > inside the #resources()-method. It is not needed to define it as a > static final field. The reason is to have the computation of the characteristics only at compile time not on each method call. > > Best regards, > Andrej Golovnin -Patrick From naoto.sato at oracle.com Thu Sep 8 15:37:58 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 8 Sep 2016 08:37:58 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> Message-ID: Updated the webrev wrt the latter comment: http://cr.openjdk.java.net/~naoto/8165605/webrev.02/ Naoto On 9/7/16 6:37 PM, Mandy Chung wrote: > >> On Sep 7, 2016, at 6:29 PM, Naoto Sato wrote: >> >> Hi Mandy, >> >> Although avoiding the hardcoded pathname is good, it is specific to the BreakIterator implementation of the COMPAT provider. So I am not sure making a generic SPI would be needed here. > > I was thinking of one of the internal services that jdk.localedata currently provides. > >> >> Anyway, this split package issue is blocking Alan's push, so I'd like to push the change as it is. We can get back to this later. > > I agree this can be cleaned up as a separate issue. > > 152 InputStream is = module.getResourceAsStream( > 153 ("jdk.localedata".equals(module.getName()) ? > 154 "sun/text/resources/ext/" : "sun/text/resources/") + dictionaryName); > > It may be easier to read if line 153-154 are moved and assign to a separate variable. Otherwise, looks fine. > > Mandy > >> >> Naoto >> >> On 9/7/16 5:17 PM, Mandy Chung wrote: >>> Hi Naoto, >>> >>> Is there an alternative to get back the pathname of the resource e.g. adding a method in existing internal SPI to avoid hardcoding the module name and the resource pathname. >>> >>> Mandy >>> >>>> On Sep 7, 2016, at 3:56 PM, Naoto Sato wrote: >>>> >>>> Forgot to include jlink plugin changes. Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~naoto/8165605/webrev.01/ >>>> >>>> Naoto >>>> >>>> On 9/7/16 3:03 PM, Naoto Sato wrote: >>>>> Please review the changes to the subject bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8165605 >>>>> >>>>> The proposed fix is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8165605/webrev.00/ >>>>> >>>>> The change is simply to move those 3 resources under >>>>> sun.text.resources.ext package so that it won't cause the split package >>>>> issue. >>>>> >>>>> Naoto >>> > From mandy.chung at oracle.com Thu Sep 8 15:52:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Sep 2016 08:52:41 -0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> <98ACE72C-1D69-41F9-B59D-6DC07B309D3D@oracle.com> Message-ID: <179EF883-0C9A-4858-AEF7-319464C1DA94@oracle.com> > On Sep 8, 2016, at 12:16 AM, Andrej Golovnin wrote: > > Hi all, > > Maybe I'm wrong but I think the JavaDocs for the new method need more > love. The JavaDocs mention at multiple places that resources are > loaded, e.g.: > > 1362 * Returns a stream that loads the resources with the given name. > > 1375 *

The loading of resources will occur when the returned stream is > 1376 * evaluated. If the loading of resources results in an > {@code IOException} I have filed an issue to clean up the terminology: https://bugs.openjdk.java.net/browse/JDK-8165715 This was also brought up in a different thread. Alan suggests ?locating?. What about: The resources will be located when the returned stream is evaluated. If it results in an {@code IOException} Mandy From t.p.ellison at gmail.com Thu Sep 8 16:01:27 2016 From: t.p.ellison at gmail.com (Tim Ellison) Date: Thu, 8 Sep 2016 17:01:27 +0100 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> <1809480534.1383997.1473284668442.JavaMail.zimbra@u-pem.fr> Message-ID: <93cd4a54-6127-b096-969f-1a1adae279e1@gmail.com> On 07/09/16 23:45, Krystal Mok wrote: > I see that on the JBS page, your most recent comment says it's been decided > that for JDK9 it's okay to deprecate and forRemoval=true, while also > mentioning the uses of this class in IBM's implementation. > > Does that mean IBM has agreed on the deprecation of this class? Yep, I've seen those references and am ok with the deprecation in JDK9. > I thought J9 had features that allowed Java applications to do > fine-grained control over the JIT compiler at runtime, e.g. force > compilation of specified methods *at some certain point* in the > program. Not sure what you are thinking of there Kris. We do implement the five public methods on Compiler to do pretty much what you would expect: java.lang.Compiler.command(Object any) - this only does something for a couple of custom arguments, most objects passed to it are simply ignored. java.lang.Compiler.compileClass(Class clazz) - the JIT will compile all methods in the given class. These compilations are synchronous, i.e. the application thread that called the API will wait until all compilations are finished. java.lang.Compiler.compileClasses(String s) - the JIT will compile all methods from classes that match the given string. java.lang.Compiler.disable() - disables all future JIT compilations. java.lang.Compiler.enable() - resumes JIT compilations. IMO dropping these APIs would not be a great loss. > What JEP 165 is proposing can only statically configure JIT behaviors for > HotSpot. The same approach doesn't seem to cover what J9 used to support. > > Could you please share more background on the discussions that led to the > decision? As you would expect, IBM and Oracle talk regularly about all things Java, and this topic was raised as a heads-up that it was coming to OpenJDK. So there really isn't any background to the discussion. Regards, Tim (IBM Java team) > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks > wrote: > >> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler >> >> :-) >> >> >> On 9/7/16 2:44 PM, Remi Forax wrote: >> >>> Yes, i like this patch :) >>> >>> Aleksey, It's worst than what you think because for a lot of people >>> Compiler == java compiler and not JIT compiler so they try to compile a >>> .java file with the method compileClasses(String). >>> >>> I'm glad this class will disappear soon. >>> >>> R?mi >>> >>> ----- Mail original ----- >>> >>>> De: "Aleksey Shipilev" >>>> ?: "Stuart Marks" , "core-libs-dev" < >>>> core-libs-dev at openjdk.java.net> >>>> Envoy?: Mercredi 7 Septembre 2016 23:34:02 >>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler >>>> >>> >>> On 09/07/2016 11:52 PM, Stuart Marks wrote: >>>> >>>>> Please review this small patch to deprecate java.lang.Compiler for >>>>> removal. >>>>> >>>> >>>> Yes, +1. >>>> This class is very confusing to have these days. >>>> >>>> -Aleksey >>>> >>> From rednaxelafx at gmail.com Thu Sep 8 16:08:55 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 8 Sep 2016 09:08:55 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <93cd4a54-6127-b096-969f-1a1adae279e1@gmail.com> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> <1809480534.1383997.1473284668442.JavaMail.zimbra@u-pem.fr> <93cd4a54-6127-b096-969f-1a1adae279e1@gmail.com> Message-ID: Hi Tim, Thanks for your reply. It's good to know at least the known use cases from IBM have indeed been discussed. On Thu, Sep 8, 2016 at 9:01 AM, Tim Ellison wrote: > On 07/09/16 23:45, Krystal Mok wrote: > > I see that on the JBS page, your most recent comment says it's been > decided > > that for JDK9 it's okay to deprecate and forRemoval=true, while also > > mentioning the uses of this class in IBM's implementation. > > > > Does that mean IBM has agreed on the deprecation of this class? > > Yep, I've seen those references and am ok with the deprecation in JDK9. > > > I thought J9 had features that allowed Java applications to do > > fine-grained control over the JIT compiler at runtime, e.g. force > > compilation of specified methods *at some certain point* in the > > program. > > Not sure what you are thinking of there Kris. We do implement the five > public methods on Compiler to do pretty much what you would expect: > > java.lang.Compiler.command(Object any) - this only does something for a > couple of custom arguments, most objects passed to it are simply ignored. > > java.lang.Compiler.compileClass(Class clazz) - the JIT will compile > all methods in the given class. These compilations are synchronous, i.e. > the application thread that called the API will wait until all > compilations are finished. > > This and the next one are the ones I was talking about: these calls can be made at arbitrary points in time during Java program execution, so they are "dynamic". For instance, I may have a program that wishes to convey phase shift properties to the VM, by calling once of these methods right before the phase shift happens. That's something a static configuration means (e.g. compiler configuration file) won't be able to do. Ditto for the "waitOnCompilationQueue" command. Thanks, Kris > java.lang.Compiler.compileClasses(String s) - the JIT will compile all > methods from classes that match the given string. > > java.lang.Compiler.disable() - disables all future JIT compilations. > > java.lang.Compiler.enable() - resumes JIT compilations. > > IMO dropping these APIs would not be a great loss. > > > What JEP 165 is proposing can only statically configure JIT behaviors for > > HotSpot. The same approach doesn't seem to cover what J9 used to support. > > > > Could you please share more background on the discussions that led to the > > decision? > > As you would expect, IBM and Oracle talk regularly about all things > Java, and this topic was raised as a heads-up that it was coming to > OpenJDK. So there really isn't any background to the discussion. > > Regards, > Tim > (IBM Java team) > > > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks > > wrote: > > > >> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler > >> > >> :-) > >> > >> > >> On 9/7/16 2:44 PM, Remi Forax wrote: > >> > >>> Yes, i like this patch :) > >>> > >>> Aleksey, It's worst than what you think because for a lot of people > >>> Compiler == java compiler and not JIT compiler so they try to compile a > >>> .java file with the method compileClasses(String). > >>> > >>> I'm glad this class will disappear soon. > >>> > >>> R?mi > >>> > >>> ----- Mail original ----- > >>> > >>>> De: "Aleksey Shipilev" > >>>> ?: "Stuart Marks" , "core-libs-dev" < > >>>> core-libs-dev at openjdk.java.net> > >>>> Envoy?: Mercredi 7 Septembre 2016 23:34:02 > >>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler > >>>> > >>> > >>> On 09/07/2016 11:52 PM, Stuart Marks wrote: > >>>> > >>>>> Please review this small patch to deprecate java.lang.Compiler for > >>>>> removal. > >>>>> > >>>> > >>>> Yes, +1. > >>>> This class is very confusing to have these days. > >>>> > >>>> -Aleksey > >>>> > >>> > From gerard.ziemski at oracle.com Thu Sep 8 16:24:16 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 8 Sep 2016 11:24:16 -0500 Subject: RFR 8165634: Support multiple --add-module options on the command line In-Reply-To: References: Message-ID: <3E2271BC-9A94-4793-900B-FCF4CF70DA30@oracle.com> hi Harold, The changes look fine. I have a couple of questions though: #1 Would the "test/runtime/modules/ModuleOptionsTest.java? be more robust if we included a case with a non-error return value that takes more than one module? Ex: ?java --add-modules=java.base --add-modules=jdk.internal.reflect=ALL-UNNAMED -version? #2 Looking at the changes for jdk it appears we now also allow duplicate "--add-exports? and "--add-reads"? Does it also mean we allow duplicate "--add-modules?, Ex: ?java --add-modules=java.base --add-modules=java.base -version?? cheers > On Sep 8, 2016, at 8:23 AM, harold seigel wrote: > > Hi, > > Please review this fix for JDK-8165634. The fix changes the --add-modules option from being a 'last one wins' option to a cumulative one. With this change, if multiple --add-modules options are specified, the VM accumulates all the options' values, instead of ignoring all but the last option's value. The --add-modules values are reported back to the JDK as properties using the Arguments::create_numbered_property() function. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8165634 > > Open webrevs: > > http://cr.openjdk.java.net/~hseigel/bug_8165634.hs/ > > http://cr.openjdk.java.net/~hseigel/bug_8165634.jdk/ > > The fix was tested with the JCK Lang and VM tests, the hotpot, and java/lang, java/util and other JTreg tests, the RBT tier2 tests, and the NSK non-colocated quick tests. > > The JDK changes were done by Mandy Chung (mchung). > > Thanks, Harold > > From naoto.sato at oracle.com Thu Sep 8 16:29:41 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 8 Sep 2016 09:29:41 -0700 Subject: RFR(S): 8165592: Fix module dependencies for sun/text/* tests In-Reply-To: <641d125b-ff6d-5359-c746-72198669eb46@oracle.com> References: <8e78e7d5-ee34-38e0-a43d-08c12f76e7c8@oracle.com> <57E1A591-E762-49DF-97D8-8E7D276C3BDB@oracle.com> <641d125b-ff6d-5359-c746-72198669eb46@oracle.com> Message-ID: +1 Naoto On 9/7/16 7:22 AM, Sergei Kovalev wrote: > Fixed. Please find new version here: > http://cr.openjdk.java.net/~skovalev/8165592/webrev.01/ > > > 07.09.16 16:13, Alexandre (Shura) Iline wrote: >> "Copyright (c) 2007,2016 Oracle? >> >> Should be >> >> "Copyright (c) 2007, 2016, Oracle? >> >> Otherwise good. >> >> Shura >> >>> On Sep 7, 2016, at 5:41 AM, Sergei Kovalev >>> wrote: >>> >>> Hello team, >>> >>> Please review small fix for tests issue: >>> >>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165592 >>> Webrev: >>> http://cr.openjdk.java.net/~skovalev/8165592/webrev.00/index.html >>> >>> Summary: added 'jdk.localedata' into modules declaration section to >>> have an ability to skip the tests with --limit-modules execution if >>> required. Also made some import clean up. >>> >>> The changes tested locally using jtreg tool. >>> >>> -- >>> With best regards, >>> Sergei >>> > From claes.redestad at oracle.com Thu Sep 8 17:03:32 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 8 Sep 2016 19:03:32 +0200 Subject: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy Message-ID: <57D199E4.6020608@oracle.com> Hi, StringConcatFactory$MethodHandleInlineCopyStrategy was made the default strategy in 9+120, which brought with it a number of startup regressions due to heavy use of MethodHandles when running the bootstrap method for each String concatenation. In exchange it allows for better peak performance, so it's been argued that we're striking a good trade-off already. However, after some analysis it appears we could collapse a few transformations where we were padding out combinators with dummy arguments as a mean to select an argument from the parameter list (which can also avoid the need to permute arguments in some cases). By introducing a method on j.l.invoke.MethodHandles to do this we can simplify the MethodHandleInlineCopyStrategy and produce on average 25% fewer LFs. By further folding the CHECK_INDEX into the newString method we avoid a few additional LF shapes from being created early on, while proving performance neutral on micros. Bug: https://bugs.openjdk.java.net/browse/JDK-8165492 Webrev: http://cr.openjdk.java.net/~redestad/8165492/webrev.01/ Testing: RBT, no regressions observed on microbenchmarks[1], while recuperating ~25-30% of the largest startup regressions introduced in 9+120 It's not the intent of this change to make this new foldArguments a part of the public API, since it's simply too late for 9. Instead we'd like to defer the discussion of possibly including this in the public API until a later time, which also gives us ample opportunity to examine other options - such as being better at not fully generating intermediary LFs. Thanks! /Claes From lois.foltan at oracle.com Thu Sep 8 17:12:01 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 08 Sep 2016 13:12:01 -0400 Subject: RFR 8165634: Support multiple --add-module options on the command line In-Reply-To: References: Message-ID: <57D19BE1.2050405@oracle.com> On 9/8/2016 9:23 AM, harold seigel wrote: > Hi, > > Please review this fix for JDK-8165634. The fix changes the > --add-modules option from being a 'last one wins' option to a > cumulative one. With this change, if multiple --add-modules options > are specified, the VM accumulates all the options' values, instead of > ignoring all but the last option's value. The --add-modules values > are reported back to the JDK as properties using the > Arguments::create_numbered_property() function. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8165634 > > Open webrevs: > > http://cr.openjdk.java.net/~hseigel/bug_8165634.hs/ > > http://cr.openjdk.java.net/~hseigel/bug_8165634.jdk/ > > The fix was tested with the JCK Lang and VM tests, the hotpot, and > java/lang, java/util and other JTreg tests, the RBT tier2 tests, and > the NSK non-colocated quick tests. > > The JDK changes were done by Mandy Chung (mchung). Hi Harold, Looks good, thanks for removing Arguments::append_to_addmods_property! One minor comment, shouldn't --patch-modules also be in the unsupported_options list for Arguments::check_unsupported_dumping_properties? Thanks, Lois > > Thanks, Harold > > From huizhe.wang at oracle.com Thu Sep 8 17:20:09 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 08 Sep 2016 10:20:09 -0700 Subject: RFR JDK-8165617: Cleanup whitespace in jaxp/test In-Reply-To: <01c801d2099f$af3a0170$0dae0450$@oracle.com> References: <018c01d20981$c1e0ebe0$45a2c3a0$@oracle.com> <57D0E4ED.10505@oracle.com> <019a01d2098a$4f3361f0$ed9a25d0$@oracle.com> <1411c9a304bb43bcb5ed54ceaf48d5ee@DEWDFE13DE11.global.corp.sap> <01c801d2099f$af3a0170$0dae0450$@oracle.com> Message-ID: <57D19DC9.1020502@oracle.com> True, and it looks like there's a little gap between the normalizer tool and jcheck that I didn't know. The importance is that the source files shall not contain tabs, carriage returns, or trailing spaces. But as we found out in this case, the normalizer has an extra rule that is, there shall be one and only one empty line at the end of file. You're fine as long as you have jcheck[1] set up, but it's a good practice to keep only one empty line at the end of file. [1] http://openjdk.java.net/projects/code-tools/jcheck/ Best, Joe On 9/8/16, 12:07 AM, Frank Yuan wrote: > The normalizer tool will remove any extra LFs, only leave one. But it may be an internal tool, so I think it's not a rule. > > Thanks > Frank > >> -----Original Message----- >> From: Langer, Christoph [mailto:christoph.langer at sap.com] >> Subject: RE: RFR JDK-8165617: Cleanup whitespace in jaxp/test >> >> Hi Frank, >> >> just out of interest: Is it a rule not to have any LFs at the end of java files? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>> Of Frank Yuan >>> Sent: Donnerstag, 8. September 2016 06:35 >>> To: 'Joe Wang' >>> Cc: 'core-libs-dev' >>> Subject: RE: RFR JDK-8165617: Cleanup whitespace in jaxp/test >>> >>> Thank you! Pushed. >>> >>> Frank >>> >>> -----Original Message----- >>> From: Joe Wang [mailto:huizhe.wang at oracle.com] >>> Sent: Thursday, September 08, 2016 12:11 PM >>> To: Frank Yuan >>> Cc: 'core-libs-dev' >>> Subject: Re: RFR JDK-8165617: Cleanup whitespace in jaxp/test >>> >>> Hi Frank, >>> >>> Looks good. Thanks for getting this cleaned up! >>> >>> Best, >>> Joe >>> >>> On 9/7/16, 8:33 PM, Frank Yuan wrote: >>>> Hi >>>> >>>> This bug is to remove the extra LF from the end of the java files, that will help >>> to conform with the normalizer. >>>> Anyone would like to take a look? >>> http://cr.openjdk.java.net/~fyuan/8165617/webrev.00/ >>>> >>>> Thanks >>>> Frank >>>> > From calvin.cheung at oracle.com Thu Sep 8 17:23:37 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 08 Sep 2016 10:23:37 -0700 Subject: RFR 8165634: Support multiple --add-module options on the command line In-Reply-To: <57D19BE1.2050405@oracle.com> References: <57D19BE1.2050405@oracle.com> Message-ID: <57D19E99.1030200@oracle.com> On 9/8/16, 10:12 AM, Lois Foltan wrote: > > On 9/8/2016 9:23 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for JDK-8165634. The fix changes the >> --add-modules option from being a 'last one wins' option to a >> cumulative one. With this change, if multiple --add-modules options >> are specified, the VM accumulates all the options' values, instead of >> ignoring all but the last option's value. The --add-modules values >> are reported back to the JDK as properties using the >> Arguments::create_numbered_property() function. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8165634 >> >> Open webrevs: >> >> http://cr.openjdk.java.net/~hseigel/bug_8165634.hs/ >> >> http://cr.openjdk.java.net/~hseigel/bug_8165634.jdk/ >> >> The fix was tested with the JCK Lang and VM tests, the hotpot, and >> java/lang, java/util and other JTreg tests, the RBT tier2 tests, and >> the NSK non-colocated quick tests. >> >> The JDK changes were done by Mandy Chung (mchung). > > Hi Harold, > Looks good, thanks for removing > Arguments::append_to_addmods_property! One minor comment, shouldn't > --patch-modules also be in the unsupported_options list for > Arguments::check_unsupported_dumping_properties? Hi Lois, The check is currently in Arguments::set_shared_spaces_flags(). No need to change it because I'll have a fix related to --patch-modules soon. thanks, Calvin > Thanks, > Lois > >> >> Thanks, Harold >> >> > From max.schulze at uni-muenster.de Thu Sep 8 17:40:50 2016 From: max.schulze at uni-muenster.de (Max Schulze) Date: Thu, 8 Sep 2016 19:40:50 +0200 Subject: java.lang.IllegalStateException in getSavedProperty when properties is empty Message-ID: <61ba1c83-81ba-2dc9-6e0a-b7c767690399@uni-muenster.de> Hello, I am trying to implement my own virtual machine and making use of the rt.jar . I am following the language and vm specification and currently have not come across formalities that require implementation/prefill of java.lang.System*props. When the IntegerCache is being initialized, it calls getSavedProperty which doesn't like savedProps.isEmpty() at all (jdk/src/share/classes/sun/misc/VM.java:255) and throws the exception java.lang.IllegalStateException. 1) What are the minimal properties that have to be initialized for the runtime to be functioning? I found sun.misc.Version.init(), but is there any specification of what the bare minimum would be? 2) There is a function initializeSystemClass() (jdk/src/share/classes/java/lang/System.java:1152) that calls initProperties(props). This will be called by the JVM at > hotspot/src/share/vm/runtime/thread.cpp:1048: > JavaCalls::call_static(&result, klass, > vmSymbols::initializeSystemClass_name(), Shouldn't it be part of the JVM Specification to call this initializeSystemClass on thread setup then, if at all it wants to be able to run the rt.jar? Thanks, Max PS : talking about 1.8.0_91 (On a side-note, there is activity around moving sun.misc.VM to jdk.internal.misc for JEP 260/JDK9, but which doesn't change above mentioned problems) [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037853.html From Alan.Bateman at oracle.com Thu Sep 8 17:59:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Sep 2016 18:59:58 +0100 Subject: RFR 8165634: Support multiple --add-module options on the command line In-Reply-To: References: Message-ID: <8f37b774-16df-782a-2857-9ceb8aac3bc4@oracle.com> On 08/09/2016 14:23, harold seigel wrote: > Hi, > > Please review this fix for JDK-8165634. The fix changes the > --add-modules option from being a 'last one wins' option to a > cumulative one. With this change, if multiple --add-modules options > are specified, the VM accumulates all the options' values, instead of > ignoring all but the last option's value. The --add-modules values > are reported back to the JDK as properties using the > Arguments::create_numbered_property() function. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8165634 > > Open webrevs: > > http://cr.openjdk.java.net/~hseigel/bug_8165634.hs/ > > http://cr.openjdk.java.net/~hseigel/bug_8165634.jdk/ This drops a dup check from addExtraReads that I assume should not be in this patch. The rest of the jdk changes look okay. One suggestion for getExtraAddModules is to just return Collections.emptySet or Set.of when the first getAndRemoveProperty returns null. We're in the interpreter during this early start so everything counts. -Alan From paul.sandoz at oracle.com Thu Sep 8 18:09:58 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Sep 2016 11:09:58 -0700 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> <98ACE72C-1D69-41F9-B59D-6DC07B309D3D@oracle.com> Message-ID: > On 8 Sep 2016, at 08:20, Patrick Reinhart wrote: >> And one more thing. Because we have now only one method to get a >> stream I think the constant RESOURCE_CHARACTERISTICS should be defined >> inside the #resources()-method. It is not needed to define it as a >> static final field. > > The reason is to have the computation of the characteristics only at compile time not on each method call. > It?s ok, since the characteristics are constant the java compiler is free to constant fold and compute results and use that instead in the byte code (which is why for independent compilation it is dangerous to change the values of static final fields of certain types, such as stuff that can be represented directly in the constant pool or byte code). So there is no need to increase the static size of the ClassLoader class with a new static final field, although it probably makes little difference in this case. Paul. [*] Compile the following class and then view the byte code of the class file using javap. You will not observe any getstatic instructions. Instead you will see stuff like: sipush 1280 that is the result of Spliterator.IMMUTABLE | Spliterator.NONNULL. Also notice that the invoke dynamic for the Supplier lambda is de-surgared into a method that accepts an int parameter corresponding to the characteristics. Arguably javac could be smarter here and fold the constant into the lambda itself to avoid an additional parameter. public class Statics { public static void main(String[] args) { usage(Spliterator.IMMUTABLE | Spliterator.NONNULL); usage(Spliterator.IMMUTABLE | Spliterator.NONNULL); create("FOO"); } static Stream create(String name) { int cs = Spliterator.IMMUTABLE | Spliterator.NONNULL; Supplier> ss = () -> { Iterator i = List.of(name).iterator(); return Spliterators.spliteratorUnknownSize(i, cs); }; return StreamSupport.stream(ss, cs, false); } static void usage(int cs) {} } From joe.darcy at oracle.com Thu Sep 8 18:16:18 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 8 Sep 2016 11:16:18 -0700 Subject: JDK 9 RFR of JDK-8039854: Broken link in java.lang.RuntimePermission Message-ID: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com> Hello, Please review the patch below to address JDK-8039854: Broken link in java.lang.RuntimePermission Two broken links are replaced by a live link to the deployment guide. Thanks, -Joe --- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu Sep 08 16:16:44 2016 +0100 +++ b/src/java.base/share/classes/java/lang/RuntimePermission.java Thu Sep 08 10:35:10 2016 -0700 @@ -323,11 +323,9 @@ * usePolicy * Granting this permission disables the Java Plug-In's default * security prompting behavior. - * For more information, refer to Java Plug-In's guides, - * Applet Security Basics and - * usePolicy Permission. + * For more information, refer to the deployment guide. + * * * * manageProcess From lance.andersen at oracle.com Thu Sep 8 18:17:26 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 8 Sep 2016 14:17:26 -0400 Subject: JDK 9 RFR of JDK-8039854: Broken link in java.lang.RuntimePermission In-Reply-To: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com> References: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com> Message-ID: <795B335D-E0E5-4D78-A256-012FA24443A0@oracle.com> all good Joe > On Sep 8, 2016, at 2:16 PM, joe darcy wrote: > > Hello, > > Please review the patch below to address > > JDK-8039854: Broken link in java.lang.RuntimePermission > > Two broken links are replaced by a live link to the deployment guide. > > Thanks, > > -Joe > > > --- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu Sep 08 16:16:44 2016 +0100 > +++ b/src/java.base/share/classes/java/lang/RuntimePermission.java Thu Sep 08 10:35:10 2016 -0700 > @@ -323,11 +323,9 @@ > * usePolicy > * Granting this permission disables the Java Plug-In's default > * security prompting behavior. > - * For more information, refer to Java Plug-In's guides, - * "../../../technotes/guides/plugin/developer_guide/security.html"> > - * Applet Security Basics and - * "../../../technotes/guides/plugin/developer_guide/rsa_how.html#use"> > - * usePolicy Permission. > + * For more information, refer to the + * "../../../technotes/guides/deploy/index.html">deployment guide. > + * > * > * > * manageProcess > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.sandoz at oracle.com Thu Sep 8 18:21:35 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Sep 2016 11:21:35 -0700 Subject: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy In-Reply-To: <57D199E4.6020608@oracle.com> References: <57D199E4.6020608@oracle.com> Message-ID: <078A3C54-630B-4AF2-88A0-96A5AFD21641@oracle.com> Hi, Quick observation before diving in further. IIUC you are essentially adding a dummy index parameter to StringConcatHelper.newString, which should always be zero, and that helps compress LFs for the MH combinator: 341 static String newString(byte[] buf, int index, byte coder) { 342 // Use the private, non-copying constructor (unsafe!) 343 if (index != 0) { 344 throw new IllegalStateException("Storage is not completely initialized, " + index + " bytes left"); 345 } 346 return new String(buf, coder); 347 } Did you consider replacing the if block with an assert? presumably if it is non-zero it is an internal error? Paul. > On 8 Sep 2016, at 10:03, Claes Redestad wrote: > > Hi, > > StringConcatFactory$MethodHandleInlineCopyStrategy was made the default > strategy in 9+120, which brought with it a number of startup > regressions due to heavy use of MethodHandles when running the > bootstrap method for each String concatenation. In exchange it allows > for better peak performance, so it's been argued that we're striking a > good trade-off already. > > However, after some analysis it appears we could collapse a few > transformations where we were padding out combinators with dummy > arguments as a mean to select an argument from the parameter list > (which can also avoid the need to permute arguments in some cases). By > introducing a method on j.l.invoke.MethodHandles to do this we can > simplify the MethodHandleInlineCopyStrategy and produce on average 25% > fewer LFs. > > By further folding the CHECK_INDEX into the newString method we avoid > a few additional LF shapes from being created early on, while proving > performance neutral on micros. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165492 > > Webrev: http://cr.openjdk.java.net/~redestad/8165492/webrev.01/ > > Testing: RBT, no regressions observed on microbenchmarks[1], while > recuperating ~25-30% of the largest startup regressions introduced in > 9+120 > > It's not the intent of this change to make this new foldArguments a > part of the public API, since it's simply too late for 9. Instead we'd > like to defer the discussion of possibly including this in the public > API until a later time, which also gives us ample opportunity to > examine other options - such as being better at not fully generating > intermediary LFs. > > Thanks! > > /Claes From andrej.golovnin at gmail.com Thu Sep 8 18:41:34 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 8 Sep 2016 20:41:34 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> <98ACE72C-1D69-41F9-B59D-6DC07B309D3D@oracle.com> Message-ID: <500500F0-A4D5-457B-9833-1CC1B5F4EAD1@gmail.com> Hi Patrick, >> 1362 * Returns a stream that loads the resources with the given name. >> 1375 *

The loading of resources will occur when the returned stream is >> 1376 * evaluated. If the loading of resources results in an >> {@code IOException} >> In reality however, no resources are loaded. Only URLs for all >> resources that match the given name are created. To load the resources >> you must open the connection on the returned URLs. Therefore I think >> the JavaDocs do not reflect what the method does. > > What do you suggest to write instead? For the line 1362 maybe something like that: Returns a stream whose elements are the URLs of all the resources with the given name. And for the lines 1375 and 1376 you can use the wording suggested by Mandy. > >> And one more thing. Because we have now only one method to get a >> stream I think the constant RESOURCE_CHARACTERISTICS should be defined >> inside the #resources()-method. It is not needed to define it as a >> static final field. > > The reason is to have the computation of the characteristics only at compile time not on each method call. As explained by Paul, the bitwise OR-operator is evaluated by the Java compiler during the compilation time. Therefore there is no penalty at runtime if you define the constant inside the method. Best regards, Andrej Golovnin From shade at redhat.com Thu Sep 8 18:56:26 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 8 Sep 2016 21:56:26 +0300 Subject: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy In-Reply-To: <57D199E4.6020608@oracle.com> References: <57D199E4.6020608@oracle.com> Message-ID: <538593ee-1a8d-d016-1c69-bb381f031698@redhat.com> Hi, On 09/08/2016 08:03 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8165492/webrev.01/ It is a bit sad that we have to bust the doors with internal APIs, and not use the public API, thus robbing ourselves of the opportunity to optimize the public API for a wide range of use cases. Barring that, the patch looks good. > On 09/08/2016 09:21 PM, Paul Sandoz wrote: > Did you consider replacing the if block with an assert? presumably if > it is non-zero it is an internal error? The original check was to guard against Unsafe.allocateUnitializedArray usage, and so I would like to keep the code that checks the index unconditionally. asserts can be disabled. Thanks, -Aleksey From Roger.Riggs at Oracle.com Thu Sep 8 19:09:37 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Sep 2016 15:09:37 -0400 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> Message-ID: <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> Please review updates to the Serialization filtering API and implementation: - The ObjectInputFilter pattern based filters support matching on module names as well as package and class names. - Rename of system property and java.security property for configurable filters. (jdk.serialFilter) - ObjectInputFilter clarifications about the values passed to the filter - Javadoc editorial improvements - Clarification of SerializablePermission description of targets - More tests Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ SpecDiff: http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html Javadoc (subset) http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html Thanks, Roger From claes.redestad at oracle.com Thu Sep 8 19:37:28 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 8 Sep 2016 21:37:28 +0200 Subject: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy In-Reply-To: <538593ee-1a8d-d016-1c69-bb381f031698@redhat.com> References: <57D199E4.6020608@oracle.com> <538593ee-1a8d-d016-1c69-bb381f031698@redhat.com> Message-ID: <57D1BDF8.9090003@oracle.com> Hi, On 2016-09-08 20:56, Aleksey Shipilev wrote: > Hi, > > On 09/08/2016 08:03 PM, Claes Redestad wrote: >> Webrev: http://cr.openjdk.java.net/~redestad/8165492/webrev.01/ > > It is a bit sad that we have to bust the doors with internal APIs, and > not use the public API, thus robbing ourselves of the opportunity to > optimize the public API for a wide range of use cases. optimizing the public API would of course be ideal, and perhaps there's some ways improve the current impl under the hood that would remove the need for slightly odd, compound operations like this new foldArguments. I have some ideas, but, time is running short for 9. Just allowing this one in might be trying the patience of some people. :-) > > Barring that, the patch looks good. Thanks! > >> On 09/08/2016 09:21 PM, Paul Sandoz wrote: >> Did you consider replacing the if block with an assert? presumably if >> it is non-zero it is an internal error? > > The original check was to guard against Unsafe.allocateUnitializedArray > usage, and so I would like to keep the code that checks the index > unconditionally. asserts can be disabled. I have been down the road of trying to make this an assertion to get rid of the LF shapes and was dissuaded. Having found another (better?) way to get rid of the startup cost of having this check my concerns are resolved. Also, dropping the check entirely from this patch doesn't show a significant improvement on micros (at least for C2). Thanks! /Claes From mandy.chung at oracle.com Thu Sep 8 19:38:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Sep 2016 12:38:02 -0700 Subject: RFR 8165634: Support multiple --add-module options on the command line In-Reply-To: <8f37b774-16df-782a-2857-9ceb8aac3bc4@oracle.com> References: <8f37b774-16df-782a-2857-9ceb8aac3bc4@oracle.com> Message-ID: <2191ABE1-FD7C-4CA9-9735-74B169D36CAE@oracle.com> > On Sep 8, 2016, at 10:59 AM, Alan Bateman wrote: > > > > On 08/09/2016 14:23, harold seigel wrote: >> Hi, >> >> Please review this fix for JDK-8165634. The fix changes the --add-modules option from being a 'last one wins' option to a cumulative one. With this change, if multiple --add-modules options are specified, the VM accumulates all the options' values, instead of ignoring all but the last option's value. The --add-modules values are reported back to the JDK as properties using the Arguments::create_numbered_property() function. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8165634 >> >> Open webrevs: >> >> http://cr.openjdk.java.net/~hseigel/bug_8165634.hs/ >> >> http://cr.openjdk.java.net/~hseigel/bug_8165634.jdk/ > This drops a dup check from addExtraReads that I assume should not be in this patch. > This should not be in this patch. > The rest of the jdk changes look okay. One suggestion for getExtraAddModules is to just return Collections.emptySet or Set.of when the first getAndRemoveProperty returns null. We're in the interpreter during this early start so everything counts. Yes everything counts. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165634/webrev.01/ Mandy From henry.jen at oracle.com Thu Sep 8 19:52:42 2016 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 8 Sep 2016 12:52:42 -0700 Subject: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information Message-ID: Hi, Please review a trivial fix for bug 8042148 at following URL: Webrev:?http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/ Bug:?https://bugs.openjdk.java.net/browse/JDK-8042148 The fix added options asked for as discussed in the bug comments, and sort those options in alphabetical order like the web page does. Cheers, Henry From sean.mullan at oracle.com Thu Sep 8 19:55:24 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 8 Sep 2016 15:55:24 -0400 Subject: JDK 9 RFR of JDK-8039854: Broken link in java.lang.RuntimePermission In-Reply-To: <795B335D-E0E5-4D78-A256-012FA24443A0@oracle.com> References: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com> <795B335D-E0E5-4D78-A256-012FA24443A0@oracle.com> Message-ID: <22c06f4a-400b-fbce-dfff-40e47ba27f34@oracle.com> Actually, I don't really think this permission target belongs in RuntimePermission since it is specific to Oracle's Java Plugin. I would be in favor of removing it and only documenting it in the deployment guides. --Sean On 09/08/2016 02:17 PM, Lance Andersen wrote: > all good Joe >> On Sep 8, 2016, at 2:16 PM, joe darcy > > wrote: >> >> Hello, >> >> Please review the patch below to address >> >> JDK-8039854: Broken link in java.lang.RuntimePermission >> >> Two broken links are replaced by a live link to the deployment guide. >> >> Thanks, >> >> -Joe >> >> >> --- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu >> Sep 08 16:16:44 2016 +0100 >> +++ b/src/java.base/share/classes/java/lang/RuntimePermission.java Thu >> Sep 08 10:35:10 2016 -0700 >> @@ -323,11 +323,9 @@ >> * usePolicy >> * Granting this permission disables the Java Plug-In's default >> * security prompting behavior. >> - * For more information, refer to Java Plug-In's guides, > - * "../../../technotes/guides/plugin/developer_guide/security.html"> >> - * Applet Security Basics and > - * "../../../technotes/guides/plugin/developer_guide/rsa_how.html#use"> >> - * usePolicy Permission. >> + * For more information, refer to the > + * "../../../technotes/guides/deploy/index.html">deployment guide. >> + * >> * >> * >> * manageProcess >> > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From huizhe.wang at oracle.com Thu Sep 8 20:26:05 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 08 Sep 2016 13:26:05 -0700 Subject: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions In-Reply-To: <87poond6tz.fsf@v45346.1blu.de> References: <87eg58n7vx.fsf@v45346.1blu.de> <57C4825D.5070307@oracle.com> <87oa4ai5c5.fsf@v45346.1blu.de> <57C66074.5080608@oracle.com> <87poond6tz.fsf@v45346.1blu.de> Message-ID: <57D1C95D.7000409@oracle.com> Hi Stefan, It's great to know you've found the solution! Hopefully this is indeed the last issue for you with JDK 9 :-) I've checked in a fix for the redirect failure [1] into the dev repo. It would probably be included in the next week's build (b136). Please let me know if this doesn't work. [1] https://bugs.openjdk.java.net/browse/JDK-8165116 Best, Joe On 9/1/16, 7:37 AM, Stefan Bodewig wrote: > On 2016-08-31, Joe Wang wrote: > >> On 8/30/16, 9:34 AM, Stefan Bodewig wrote: >>> On 2016-08-29, Joe Wang wrote: >>>> If you are using the built-in extension functions, try turning on the >>>> following feature: >>>> private static final String ENABLE_EXTENSION_FUNCTIONS = >>>> "http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions"; >>>> tf.setFeature(ENABLE_EXTENSION_FUNCTIONS, true); >>> This is not supported by Xalan's TransformerFactoryImpl: >> True, this is an impl-only feature. But Xalan doesn't need it anyways, >> you may check the factory instance and skip it if it's Xalan. > Thanks, you're comment made me take a third look at the test-case in > question. I was confused by the setup and overlooked that we explicitly > forced the use of the JDK's factory for just a single test. > > By selectively setting both features I can get the test to pass and am > able to use the redirect extension of a version of Xalan on the > classloader I specify. > > I'll need to add suppport for setting features on the TransformerFactory > to Ant's task as I'd prefer to not hard-code the features into > the task - and enable it for be default. > >>> When removing Xalan from the classpath and using the JDK's own >>> TransformerFactory I get >>> ,---- >>> | Error! Use of the extension element 'redirect' is not allowed when the >>> | secure processing feature is set to true. >>> `---- >>> even with the feature enabled. So "redirect" - >>> i.e. xmlns:redirect="http://xml.apache.org/xalan/redirect" - which I >>> assumed to be "built-in" for the JDK's fork of Xalan as well - doesn't >>> seem to get through with just that. >> I'll get this fixed in the next 1 or 2 >> build. (https://bugs.openjdk.java.net/browse/JDK-8165116) > This is great and will simplify things a lot. > > Many thanks > > Stefan From paul.sandoz at oracle.com Thu Sep 8 20:31:12 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Sep 2016 13:31:12 -0700 Subject: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy In-Reply-To: <57D1BDF8.9090003@oracle.com> References: <57D199E4.6020608@oracle.com> <538593ee-1a8d-d016-1c69-bb381f031698@redhat.com> <57D1BDF8.9090003@oracle.com> Message-ID: > On 8 Sep 2016, at 12:37, Claes Redestad wrote: > >> >>> On 09/08/2016 09:21 PM, Paul Sandoz wrote: >>> Did you consider replacing the if block with an assert? presumably if >>> it is non-zero it is an internal error? >> >> The original check was to guard against Unsafe.allocateUnitializedArray >> usage, and so I would like to keep the code that checks the index >> unconditionally. asserts can be disabled. > > I have been down the road of trying to make this an assertion to get > rid of the LF shapes and was dissuaded. > > Having found another (better?) way to get rid of the startup cost of > having this check my concerns are resolved. Also, dropping the check > entirely from this patch doesn't show a significant improvement on > micros (at least for C2). > Ok, but is the IllegalStateException the right type to throw? should it be InternalError instead? Paul. From Alan.Bateman at oracle.com Thu Sep 8 20:32:28 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Sep 2016 21:32:28 +0100 Subject: RFR 8165634: Support multiple --add-module options on the command line In-Reply-To: <2191ABE1-FD7C-4CA9-9735-74B169D36CAE@oracle.com> References: <8f37b774-16df-782a-2857-9ceb8aac3bc4@oracle.com> <2191ABE1-FD7C-4CA9-9735-74B169D36CAE@oracle.com> Message-ID: <37334c70-db7d-70dd-74b2-6997e0726857@oracle.com> On 08/09/2016 20:38, Mandy Chung wrote: > : > Yes everything counts. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165634/webrev.01/ > Looks good. -Alan From shade at redhat.com Thu Sep 8 20:33:46 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 8 Sep 2016 23:33:46 +0300 Subject: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy In-Reply-To: References: <57D199E4.6020608@oracle.com> <538593ee-1a8d-d016-1c69-bb381f031698@redhat.com> <57D1BDF8.9090003@oracle.com> Message-ID: On 09/08/2016 11:31 PM, Paul Sandoz wrote: >> On 8 Sep 2016, at 12:37, Claes Redestad wrote: >>>> On 09/08/2016 09:21 PM, Paul Sandoz wrote: >>>> Did you consider replacing the if block with an assert? presumably if >>>> it is non-zero it is an internal error? >>> >>> The original check was to guard against Unsafe.allocateUnitializedArray >>> usage, and so I would like to keep the code that checks the index >>> unconditionally. asserts can be disabled. >> >> I have been down the road of trying to make this an assertion to get >> rid of the LF shapes and was dissuaded. >> >> Having found another (better?) way to get rid of the startup cost of >> having this check my concerns are resolved. Also, dropping the check >> entirely from this patch doesn't show a significant improvement on >> micros (at least for C2). > > Ok, but is the IllegalStateException the right type to throw? should it be InternalError instead? Yes, InternalError should be more fitting. This should indicate a fatal bug in JDK. Thanks, -Aleksey From patrick at reini.net Thu Sep 8 21:14:20 2016 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 8 Sep 2016 23:14:20 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> <98ACE72C-1D69-41F9-B59D-6DC07B309D3D@oracle.com> Message-ID: <01cf1bf4-f4f3-24f4-472b-5d21af386dac@reini.net> I tried to include all the feedback here: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.04 -Patrick On 08.09.2016 20:09, Paul Sandoz wrote: >> On 8 Sep 2016, at 08:20, Patrick Reinhart wrote: >>> And one more thing. Because we have now only one method to get a >>> stream I think the constant RESOURCE_CHARACTERISTICS should be defined >>> inside the #resources()-method. It is not needed to define it as a >>> static final field. >> The reason is to have the computation of the characteristics only at compile time not on each method call. >> > It?s ok, since the characteristics are constant the java compiler is free to constant fold and compute results and use that instead in the byte code (which is why for independent compilation it is dangerous to change the values of static final fields of certain types, such as stuff that can be represented directly in the constant pool or byte code). > > So there is no need to increase the static size of the ClassLoader class with a new static final field, although it probably makes little difference in this case. > > Paul. From paul.sandoz at oracle.com Thu Sep 8 21:18:37 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Sep 2016 14:18:37 -0700 Subject: RFR 8165731 Reference to removed method in VarHandle JavaDoc Message-ID: <019CB7D4-44C5-4D7B-A27B-D94E9D39110C@oracle.com> Hi, Please review this simple fix to remove a straggling reference to a previously removed method. Thanks, Paul. diff -r 10d8bdeabfa5 src/java.base/share/classes/java/lang/invoke/VarHandle.java --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java Thu Sep 08 09:59:54 2016 -0700 +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java Thu Sep 08 14:17:14 2016 -0700 @@ -152,7 +152,6 @@ * {@link #getAndAdd getAndAdd}, * {@link #getAndAddAcquire getAndAddAcquire}, * {@link #getAndAddRelease getAndAddRelease}, - * {@link #addAndGet addAndGet}. *

  • bitwise atomic update access modes that, for example, atomically get and * bitwise OR the value of a variable under specified memory ordering * effects. From joe.darcy at oracle.com Thu Sep 8 21:20:09 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 8 Sep 2016 14:20:09 -0700 Subject: JDK 9 RFR of JDK-8039854: Broken link in java.lang.RuntimePermission In-Reply-To: <22c06f4a-400b-fbce-dfff-40e47ba27f34@oracle.com> References: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com> <795B335D-E0E5-4D78-A256-012FA24443A0@oracle.com> <22c06f4a-400b-fbce-dfff-40e47ba27f34@oracle.com> Message-ID: Hi Sean, I'm going to push the fix to get a valid link in the table, but I don't oppose if someone else files a follow-up bug to change the spec and remove the row if that is appropriate course of action. Thanks, -Joe On 9/8/2016 12:55 PM, Sean Mullan wrote: > Actually, I don't really think this permission target belongs in > RuntimePermission since it is specific to Oracle's Java Plugin. I > would be in favor of removing it and only documenting it in the > deployment guides. > > --Sean > > On 09/08/2016 02:17 PM, Lance Andersen wrote: >> all good Joe >>> On Sep 8, 2016, at 2:16 PM, joe darcy >> > wrote: >>> >>> Hello, >>> >>> Please review the patch below to address >>> >>> JDK-8039854: Broken link in java.lang.RuntimePermission >>> >>> Two broken links are replaced by a live link to the deployment guide. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> --- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu >>> Sep 08 16:16:44 2016 +0100 >>> +++ b/src/java.base/share/classes/java/lang/RuntimePermission.java Thu >>> Sep 08 10:35:10 2016 -0700 >>> @@ -323,11 +323,9 @@ >>> * usePolicy >>> * Granting this permission disables the Java Plug-In's default >>> * security prompting behavior. >>> - * For more information, refer to Java Plug-In's guides, >> href= >>> - * "../../../technotes/guides/plugin/developer_guide/security.html"> >>> - * Applet Security Basics and >> - * >>> "../../../technotes/guides/plugin/developer_guide/rsa_how.html#use"> >>> - * usePolicy Permission. >>> + * For more information, refer to the >> + * "../../../technotes/guides/deploy/index.html">deployment guide. >>> + * >>> * >>> * >>> * manageProcess >>> >> >> >> >> >> Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> From shade at redhat.com Thu Sep 8 21:23:16 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 9 Sep 2016 00:23:16 +0300 Subject: RFR 8165731 Reference to removed method in VarHandle JavaDoc In-Reply-To: <019CB7D4-44C5-4D7B-A27B-D94E9D39110C@oracle.com> References: <019CB7D4-44C5-4D7B-A27B-D94E9D39110C@oracle.com> Message-ID: On 09/09/2016 12:18 AM, Paul Sandoz wrote: > diff -r 10d8bdeabfa5 src/java.base/share/classes/java/lang/invoke/VarHandle.java > --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java Thu Sep 08 09:59:54 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java Thu Sep 08 14:17:14 2016 -0700 > @@ -152,7 +152,6 @@ > * {@link #getAndAdd getAndAdd}, > * {@link #getAndAddAcquire getAndAddAcquire}, > * {@link #getAndAddRelease getAndAddRelease}, > - * {@link #addAndGet addAndGet}. > *
  • bitwise atomic update access modes that, for example, atomically get and > * bitwise OR the value of a variable under specified memory ordering > * effects. > Reviewed. Thanks, -Aleksey From brian.burkhalter at oracle.com Thu Sep 8 21:24:48 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 8 Sep 2016 14:24:48 -0700 Subject: RFR 8165731 Reference to removed method in VarHandle JavaDoc In-Reply-To: <019CB7D4-44C5-4D7B-A27B-D94E9D39110C@oracle.com> References: <019CB7D4-44C5-4D7B-A27B-D94E9D39110C@oracle.com> Message-ID: <78A7EAD8-033A-4BF2-9A46-8E6CB7602333@oracle.com> +1 On Sep 8, 2016, at 2:18 PM, Paul Sandoz wrote: > Hi, > > Please review this simple fix to remove a straggling reference to a previously removed method. > > Thanks, > Paul. > > diff -r 10d8bdeabfa5 src/java.base/share/classes/java/lang/invoke/VarHandle.java > --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java Thu Sep 08 09:59:54 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java Thu Sep 08 14:17:14 2016 -0700 > @@ -152,7 +152,6 @@ > * {@link #getAndAdd getAndAdd}, > * {@link #getAndAddAcquire getAndAddAcquire}, > * {@link #getAndAddRelease getAndAddRelease}, > - * {@link #addAndGet addAndGet}. > *
  • bitwise atomic update access modes that, for example, atomically get and > * bitwise OR the value of a variable under specified memory ordering > * effects. From mandy.chung at oracle.com Thu Sep 8 22:02:36 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Sep 2016 15:02:36 -0700 Subject: Review Request: JDK-8165346 j.l.ClassLoader.getDefinedPackage(String) throws NPE Message-ID: Spec bug: missing @throws NPE if the specified name is null in the relevant getPackage methods: ClassLoader.getDefinedPackage, ClassLoader::getPackage, Package::getPackage Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165346/webrev.00/index.html Mandy From lance.andersen at oracle.com Thu Sep 8 22:18:04 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 8 Sep 2016 18:18:04 -0400 Subject: Review Request: JDK-8165346 j.l.ClassLoader.getDefinedPackage(String) throws NPE In-Reply-To: References: Message-ID: <28A353B7-4E5E-4C9C-A9D9-12A9D3612F67@oracle.com> +1 > On Sep 8, 2016, at 6:02 PM, Mandy Chung wrote: > > Spec bug: missing @throws NPE if the specified name is null in the relevant getPackage methods: > ClassLoader.getDefinedPackage, ClassLoader::getPackage, Package::getPackage > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165346/webrev.00/index.html > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From shade at redhat.com Thu Sep 8 22:21:01 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 9 Sep 2016 01:21:01 +0300 Subject: Review Request: JDK-8165346 j.l.ClassLoader.getDefinedPackage(String) throws NPE In-Reply-To: References: Message-ID: On 09/09/2016 01:02 AM, Mandy Chung wrote: > Spec bug: missing @throws NPE if the specified name is null in the relevant getPackage methods: > ClassLoader.getDefinedPackage, ClassLoader::getPackage, Package::getPackage > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165346/webrev.00/index.html Looks good. Thanks, -Aleksey From kumar.x.srinivasan at oracle.com Thu Sep 8 22:25:55 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 08 Sep 2016 15:25:55 -0700 Subject: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information In-Reply-To: References: Message-ID: <57D1E573.7040904@oracle.com> Hi Henry, Looks a lot nicer with the alpha ordering, but it seems to be missing -Xusealtsigs use alternative signals instead of SIGUSR1 and SIGUSR2 for JVM internal signals Kumar On 9/8/2016 12:52 PM, Henry Jen wrote: > Hi, > > Please review a trivial fix for bug 8042148 at following URL: > Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8042148 > > > The fix added options asked for as discussed in the bug comments, and sort those options in alphabetical order like the web page does. > > Cheers, > Henry > From masayoshi.okutsu at oracle.com Thu Sep 8 23:31:06 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 9 Sep 2016 08:31:06 +0900 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> <81e12bc9-df11-580e-23f1-a6c2222c53c2@oracle.com> Message-ID: Is it just a matter of an extra step, new File(path).getName()? Masayoshi On 9/9/2016 12:00 AM, Naoto Sato wrote: > Well, actually I tried this approach first, then found out that the > data files are also used by the GenerateBreakIteratorData build tool > which has some implicit assumption of the value being the file name > w/o path. So I ended up with the fix. > > Naoto > > On 9/8/16 5:46 AM, Alan Bateman wrote: >> >> >> On 08/09/2016 03:51, Masayoshi Okutsu wrote: >>> I thought Mandy suggested that the dictionary names in a >>> ResourceBundle contain path names rather than base names, something >>> like this: >>> >>> In BreakIteratorInfo_th.java: >>> >>> {"WordDictionary", "thai_dict"}, >>> to >>> {"WordDictionary", "sun/text/resources/ext/thai_dict"}, >>> >>> I haven't checked any side effects of this change, though. >> That would be cleaner, assuming it doesn't cause issues. >> >> -Alan From henry.jen at oracle.com Fri Sep 9 03:05:14 2016 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 8 Sep 2016 20:05:14 -0700 Subject: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information In-Reply-To: <57D1E573.7040904@oracle.com> References: <57D1E573.7040904@oracle.com> Message-ID: According to David in the comments, -Xusealtsigs is no longer an option, is it? Cheers, Henry On September 8, 2016 at 3:27:21 PM, Kumar Srinivasan (kumar.x.srinivasan at oracle.com) wrote: > Hi Henry, > > Looks a lot nicer with the alpha ordering, but it seems to be missing > -Xusealtsigs use alternative signals instead of SIGUSR1 and SIGUSR2 for > JVM internal signals > > Kumar > > > On 9/8/2016 12:52 PM, Henry Jen wrote: > > Hi, > > > > Please review a trivial fix for bug 8042148 at following URL: > > Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042148 > > > > > > The fix added options asked for as discussed in the bug comments, and sort those options > in alphabetical order like the web page does. > > > > Cheers, > > Henry > > > > From david.holmes at oracle.com Fri Sep 9 03:36:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Sep 2016 13:36:34 +1000 Subject: java.lang.IllegalStateException in getSavedProperty when properties is empty In-Reply-To: <61ba1c83-81ba-2dc9-6e0a-b7c767690399@uni-muenster.de> References: <61ba1c83-81ba-2dc9-6e0a-b7c767690399@uni-muenster.de> Message-ID: Hi Max, On 9/09/2016 3:40 AM, Max Schulze wrote: > Hello, > > I am trying to implement my own virtual machine and making use of the > rt.jar . Difficult, because rt.jar is not a stand-alone implementation that can be mixed-and-matched with arbitrary VMs. The initialization sequence is very intricate and delicate and tightly coupled between the VM and the core classes involved. The Java classes know about specific VM entry points, and the VM knows about specific Java classes and methods 9and exactly what they do). > I am following the language and vm specification and currently have not > come across formalities that require implementation/prefill of > java.lang.System*props. > > > When the IntegerCache is being initialized, it calls getSavedProperty > which doesn't like savedProps.isEmpty() at all > (jdk/src/share/classes/sun/misc/VM.java:255) and throws the exception > java.lang.IllegalStateException. > > > 1) What are the minimal properties that have to be initialized for the > runtime to be functioning? I found sun.misc.Version.init(), but is there > any specification of what the bare minimum would be? All of the properties specified as standard properties in the System.getProperties() method are supposed to be pre-filled to comply with the platform specification. > 2) There is a function initializeSystemClass() > (jdk/src/share/classes/java/lang/System.java:1152) that calls > initProperties(props). This will be called by the JVM at > >> hotspot/src/share/vm/runtime/thread.cpp:1048: >> JavaCalls::call_static(&result, klass, >> vmSymbols::initializeSystemClass_name(), > > Shouldn't it be part of the JVM Specification to call this > initializeSystemClass on thread setup then, if at all it wants to be > able to run the rt.jar? No because this is just an implementation artifact of The OpenJDK implementation of the Java platform specifications. The initialization dance between the VM and library code is even more intricate in JDK 9 with the new module system. David ----- > > Thanks, > > Max > > PS : talking about 1.8.0_91 > > > (On a side-note, there is activity around moving sun.misc.VM to > jdk.internal.misc for JEP 260/JDK9, but which doesn't change above > mentioned problems) > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037853.html > From david.holmes at oracle.com Fri Sep 9 05:29:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Sep 2016 15:29:16 +1000 Subject: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information In-Reply-To: References: <57D1E573.7040904@oracle.com> Message-ID: On 9/09/2016 1:05 PM, Henry Jen wrote: > According to David in the comments, -Xusealtsigs is no longer an option, is it? We have deprecated a number of flags: // -Xoss, -Xsqnopause, -Xoptimize, -Xboundthreads, -Xusealtsigs so they are ignored. But we still allow the user to specify them - and they will get a warning that it is deprecated and being ignored. But these flags should no longer be documented. The deprecation is/will-be listed in the release notes. David > Cheers, > Henry > > On September 8, 2016 at 3:27:21 PM, Kumar Srinivasan (kumar.x.srinivasan at oracle.com) wrote: >> Hi Henry, >> >> Looks a lot nicer with the alpha ordering, but it seems to be missing >> -Xusealtsigs use alternative signals instead of SIGUSR1 and SIGUSR2 for >> JVM internal signals >> >> Kumar >> >> >> On 9/8/2016 12:52 PM, Henry Jen wrote: >>> Hi, >>> >>> Please review a trivial fix for bug 8042148 at following URL: >>> Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042148 >>> >>> >>> The fix added options asked for as discussed in the bug comments, and sort those options >> in alphabetical order like the web page does. >>> >>> Cheers, >>> Henry >>> >> >> > From Alan.Bateman at oracle.com Fri Sep 9 05:39:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Sep 2016 06:39:20 +0100 Subject: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information In-Reply-To: References: Message-ID: <652df729-1be5-cadd-f32e-00e51ee28c3b@oracle.com> On 08/09/2016 20:52, Henry Jen wrote: > Hi, > > Please review a trivial fix for bug 8042148 at following URL: > Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8042148 > > The ordering/re-wording looks okay, just surprised to see -Xcomp added (I realize the `java -X` output has listed -Xint and -Xmixed for a long time). -Alan From andrej.golovnin at gmail.com Fri Sep 9 06:32:17 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 9 Sep 2016 08:32:17 +0200 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> Message-ID: Hi Roger, src/java.base/share/classes/java/io/ObjectInputStream.java 259 private static class Logging { The class can be final. 1265 ? Logger.Level.DEBUG There is one space too much before "Logger". 2611 /** total bytes read from the stream */ 2612 private int totalBytesRead = 0; I think the type of the field totalBytesRead must be long. In the #skip(long)-method you update it with a long value. Best regards, Andrej Golovnin From andrej.golovnin at gmail.com Fri Sep 9 06:35:11 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 9 Sep 2016 08:35:11 +0200 Subject: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream In-Reply-To: <01cf1bf4-f4f3-24f4-472b-5d21af386dac@reini.net> References: <210523A9-95F2-4E07-A187-AB1B93AC100D@reini.net> <60487a5f-8c1f-09ac-2b45-bb4b23a2d09c@reini.net> <98ACE72C-1D69-41F9-B59D-6DC07B309D3D@oracle.com> <01cf1bf4-f4f3-24f4-472b-5d21af386dac@reini.net> Message-ID: Hi Patrick, looks good for me. Thanks! Best regards, Andrej Golovnin From vladimir.x.ivanov at oracle.com Fri Sep 9 10:35:51 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 9 Sep 2016 13:35:51 +0300 Subject: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy In-Reply-To: <57D199E4.6020608@oracle.com> References: <57D199E4.6020608@oracle.com> Message-ID: <2ec77f43-1722-8540-7930-45b1b22a3190@oracle.com> > Webrev: http://cr.openjdk.java.net/~redestad/8165492/webrev.01/ Looks good. As others, I prefer InternalError over IllegalStateException when buffer size mismatch. Best regards, Vladimir Ivanov > Testing: RBT, no regressions observed on microbenchmarks[1], while > recuperating ~25-30% of the largest startup regressions introduced in > 9+120 > > It's not the intent of this change to make this new foldArguments a > part of the public API, since it's simply too late for 9. Instead we'd > like to defer the discussion of possibly including this in the public > API until a later time, which also gives us ample opportunity to > examine other options - such as being better at not fully generating > intermediary LFs. > > Thanks! > > /Claes From claes.redestad at oracle.com Fri Sep 9 11:47:28 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 9 Sep 2016 13:47:28 +0200 Subject: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy In-Reply-To: <2ec77f43-1722-8540-7930-45b1b22a3190@oracle.com> References: <57D199E4.6020608@oracle.com> <2ec77f43-1722-8540-7930-45b1b22a3190@oracle.com> Message-ID: <57D2A150.8000606@oracle.com> On 2016-09-09 12:35, Vladimir Ivanov wrote: > > Looks good. > > As others, I prefer InternalError over IllegalStateException when buffer > size mismatch. Done: http://cr.openjdk.java.net/~redestad/8165492/webrev.02/ Gave it an extra round of testing since if there was a bug somewhere it might have gotten more visible with this, but seems we're good. :-) Thanks! /Claes From t.p.ellison at gmail.com Fri Sep 9 12:12:24 2016 From: t.p.ellison at gmail.com (Tim Ellison) Date: Fri, 9 Sep 2016 13:12:24 +0100 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> <1809480534.1383997.1473284668442.JavaMail.zimbra@u-pem.fr> <93cd4a54-6127-b096-969f-1a1adae279e1@gmail.com> Message-ID: On 08/09/16 17:08, Krystal Mok wrote: > Thanks for your reply. It's good to know at least the known use cases > from IBM have indeed been discussed. > > On Thu, Sep 8, 2016 at 9:01 AM, Tim Ellison > wrote: > > On 07/09/16 23:45, Krystal Mok wrote: > > I see that on the JBS page, your most recent comment says it's been decided > > that for JDK9 it's okay to deprecate and forRemoval=true, while also > > mentioning the uses of this class in IBM's implementation. > > > > Does that mean IBM has agreed on the deprecation of this class? > > Yep, I've seen those references and am ok with the deprecation in JDK9. > > > I thought J9 had features that allowed Java applications to do > > fine-grained control over the JIT compiler at runtime, e.g. force > > compilation of specified methods *at some certain point* in the > > program. > > Not sure what you are thinking of there Kris. We do implement the five > public methods on Compiler to do pretty much what you would expect: > > java.lang.Compiler.command(Object any) - this only does something for a > couple of custom arguments, most objects passed to it are simply > ignored. > > java.lang.Compiler.compileClass(Class clazz) - the JIT will compile > all methods in the given class. These compilations are synchronous, i.e. > the application thread that called the API will wait until all > compilations are finished. > > This and the next one are the ones I was talking about: these calls can > be made at arbitrary points in time during Java program execution, so > they are "dynamic". > For instance, I may have a program that wishes to convey phase shift > properties to the VM, by calling once of these methods right before the > phase shift happens. That's something a static configuration means (e.g. > compiler configuration file) won't be able to do. Ditto for the > "waitOnCompilationQueue" command. Yes, that is one way in which we can have an application indicate to the JIT that it is moving from start-up to run phase, and we have played with that. But come JDK9 and beyond there are much better opportunities for start-up optimizations that means these APIs can be removed without grief. Regards, Tim > java.lang.Compiler.compileClasses(String s) - the JIT will compile all > methods from classes that match the given string. > > java.lang.Compiler.disable() - disables all future JIT compilations. > > java.lang.Compiler.enable() - resumes JIT compilations. > > IMO dropping these APIs would not be a great loss. > > > What JEP 165 is proposing can only statically configure JIT behaviors for > > HotSpot. The same approach doesn't seem to cover what J9 used to support. > > > > Could you please share more background on the discussions that led to the > > decision? > > As you would expect, IBM and Oracle talk regularly about all things > Java, and this topic was raised as a heads-up that it was coming to > OpenJDK. So there really isn't any background to the discussion. > > Regards, > Tim > (IBM Java team) > > > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks > > > > wrote: > > > >> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler > >> > >> :-) > >> > >> > >> On 9/7/16 2:44 PM, Remi Forax wrote: > >> > >>> Yes, i like this patch :) > >>> > >>> Aleksey, It's worst than what you think because for a lot of people > >>> Compiler == java compiler and not JIT compiler so they try to > compile a > >>> .java file with the method compileClasses(String). > >>> > >>> I'm glad this class will disappear soon. > >>> > >>> R?mi > >>> > >>> ----- Mail original ----- > >>> > >>>> De: "Aleksey Shipilev" > > >>>> ?: "Stuart Marks" >, "core-libs-dev" < > >>>> core-libs-dev at openjdk.java.net > > > >>>> Envoy?: Mercredi 7 Septembre 2016 23:34:02 > >>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler > >>>> > >>> > >>> On 09/07/2016 11:52 PM, Stuart Marks wrote: > >>>> > >>>>> Please review this small patch to deprecate java.lang.Compiler for > >>>>> removal. > >>>>> > >>>> > >>>> Yes, +1. > >>>> This class is very confusing to have these days. > >>>> > >>>> -Aleksey > >>>> > >>> > > From harold.seigel at oracle.com Fri Sep 9 12:31:53 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 9 Sep 2016 08:31:53 -0400 Subject: RFR 8165634: Support multiple --add-module options on the command line In-Reply-To: <3E2271BC-9A94-4793-900B-FCF4CF70DA30@oracle.com> References: <3E2271BC-9A94-4793-900B-FCF4CF70DA30@oracle.com> Message-ID: <7f6c458f-e7de-e697-b038-0f68fdd17ba7@oracle.com> Hi Gerard, Thanks for the review! Please see comments inline. Harold On 9/8/2016 12:24 PM, Gerard Ziemski wrote: > hi Harold, > > The changes look fine. I have a couple of questions though: > > #1 Would the "test/runtime/modules/ModuleOptionsTest.java? be more robust if we included a case with a non-error return value that takes more than one module? Ex: ?java --add-modules=java.base --add-modules=jdk.internal.reflect=ALL-UNNAMED -version? The VM just converts each --add-modules option into a jdk.module.add.mods. property that it passes back to the JDK. The fact that the JDK throws an exception for the "--add-modules=i_dont_exist --add-modules=java.base" case means that the VM is successfully handling both --add-modules and returning both of their values to the JDK. So I don't think an additional test case is needed. Also, the JDK AddModsTest.java test has a multiple --add-modules test case that returns successfully. > > #2 Looking at the changes for jdk it appears we now also allow duplicate "--add-exports? and "--add-reads"? Does it also mean we allow duplicate "--add-modules?, Ex: ?java --add-modules=java.base --add-modules=java.base -version?? Thanks for also reviewing the JDK changes. The core-libs reviewers asked that the support for duplicate --add-exports and --add-reads be removed from this webrev. (See next revision.) Duplicate --add-modules are allowed. > > > cheers > > >> On Sep 8, 2016, at 8:23 AM, harold seigel wrote: >> >> Hi, >> >> Please review this fix for JDK-8165634. The fix changes the --add-modules option from being a 'last one wins' option to a cumulative one. With this change, if multiple --add-modules options are specified, the VM accumulates all the options' values, instead of ignoring all but the last option's value. The --add-modules values are reported back to the JDK as properties using the Arguments::create_numbered_property() function. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8165634 >> >> Open webrevs: >> >> http://cr.openjdk.java.net/~hseigel/bug_8165634.hs/ >> >> http://cr.openjdk.java.net/~hseigel/bug_8165634.jdk/ >> >> The fix was tested with the JCK Lang and VM tests, the hotpot, and java/lang, java/util and other JTreg tests, the RBT tier2 tests, and the NSK non-colocated quick tests. >> >> The JDK changes were done by Mandy Chung (mchung). >> >> Thanks, Harold >> >> From harold.seigel at oracle.com Fri Sep 9 12:32:28 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 9 Sep 2016 05:32:28 -0700 (PDT) Subject: RFR 8165634: Support multiple --add-module options on the command line In-Reply-To: <57D19BE1.2050405@oracle.com> References: <57D19BE1.2050405@oracle.com> Message-ID: <089ebfd5-5782-0bba-f07b-16dee86dfe90@oracle.com> Thanks Lois, for the review. Harold On 9/8/2016 1:12 PM, Lois Foltan wrote: > > On 9/8/2016 9:23 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for JDK-8165634. The fix changes the >> --add-modules option from being a 'last one wins' option to a >> cumulative one. With this change, if multiple --add-modules options >> are specified, the VM accumulates all the options' values, instead of >> ignoring all but the last option's value. The --add-modules values >> are reported back to the JDK as properties using the >> Arguments::create_numbered_property() function. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8165634 >> >> Open webrevs: >> >> http://cr.openjdk.java.net/~hseigel/bug_8165634.hs/ >> >> http://cr.openjdk.java.net/~hseigel/bug_8165634.jdk/ >> >> The fix was tested with the JCK Lang and VM tests, the hotpot, and >> java/lang, java/util and other JTreg tests, the RBT tier2 tests, and >> the NSK non-colocated quick tests. >> >> The JDK changes were done by Mandy Chung (mchung). > > Hi Harold, > Looks good, thanks for removing > Arguments::append_to_addmods_property! One minor comment, shouldn't > --patch-modules also be in the unsupported_options list for > Arguments::check_unsupported_dumping_properties? > Thanks, > Lois > >> >> Thanks, Harold >> >> > From Roger.Riggs at Oracle.com Fri Sep 9 13:55:10 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 9 Sep 2016 09:55:10 -0400 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> Message-ID: <2e29edb0-e418-5431-5c37-32226c6853f6@Oracle.com> Hi Stuart, Related to java.lang.Complier there is the System property "java.compiler" [1]. Is there some notation needed on the property or will it just go poof when the compiler is removed? Thanks, Roger [1] JDK-8041676 java.compiler property is uninitialized On 9/7/2016 4:52 PM, Stuart Marks wrote: > Hi all, > > Please review this small patch to deprecate java.lang.Compiler for > removal. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1473281459 25200 > # Wed Sep 07 13:50:59 2016 -0700 > # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d > # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c > 4285505: deprecate java.lang.Compiler > Reviewed-by: XXX > > diff -r 76ba1b74f268 -r e520c4e6970c > src/java.base/share/classes/java/lang/Compiler.java > --- a/src/java.base/share/classes/java/lang/Compiler.java Tue Sep > 06 16:08:54 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/Compiler.java Wed Sep > 07 13:50:59 2016 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -29,21 +29,18 @@ > * The {@code Compiler} class is provided to support Java-to-native-code > * compilers and related services. By design, the {@code Compiler} > class does > * nothing; it serves as a placeholder for a JIT compiler > implementation. > + * If no compiler is available, these methods do nothing. > * > - *

    When the Java Virtual Machine first starts, it determines if > the system > - * property {@code java.compiler} exists. (System properties are > accessible > - * through {@link System#getProperty(String)} and {@link > - * System#getProperty(String, String)}. If so, it is assumed to be > the name of > - * a library (with a platform-dependent exact location and type); {@link > - * System#loadLibrary} is called to load that library. If this loading > - * succeeds, the function named {@code java_lang_Compiler_start()} in > that > - * library is called. > - * > - *

    If no compiler is available, these methods do nothing. > + * @deprecated JIT compilers and their technologies vary too widely to > + * be controlled effectively by a standardized interface. As such, many > + * JIT compiler implementations ignore this interface, and are instead > + * controllable by implementation-specific mechanisms such as > command-line > + * options. This class is subject to removal in a future version of > Java SE. > * > * @author Frank Yellin > * @since 1.0 > */ > + at Deprecated(since="9", forRemoval=true) > public final class Compiler { > private Compiler() {} // don't make instances > From Alan.Bateman at oracle.com Fri Sep 9 13:57:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Sep 2016 14:57:21 +0100 Subject: Review Request: JDK-8165346 j.l.ClassLoader.getDefinedPackage(String) throws NPE In-Reply-To: References: Message-ID: <74252b44-ca47-f5b4-4779-c803195567bf@oracle.com> On 08/09/2016 23:02, Mandy Chung wrote: > Spec bug: missing @throws NPE if the specified name is null in the relevant getPackage methods: > ClassLoader.getDefinedPackage, ClassLoader::getPackage, Package::getPackage > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165346/webrev.00/index.html > This looks okay to me. -Alan From erik.joelsson at oracle.com Fri Sep 9 14:15:28 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Sep 2016 16:15:28 +0200 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> Message-ID: <3272ac93-8f66-cca7-6e4c-f7ccef43d7c5@oracle.com> Build change looks ok. /Erik On 2016-09-08 17:37, Naoto Sato wrote: > Updated the webrev wrt the latter comment: > > http://cr.openjdk.java.net/~naoto/8165605/webrev.02/ > > Naoto > > On 9/7/16 6:37 PM, Mandy Chung wrote: >> >>> On Sep 7, 2016, at 6:29 PM, Naoto Sato wrote: >>> >>> Hi Mandy, >>> >>> Although avoiding the hardcoded pathname is good, it is specific to >>> the BreakIterator implementation of the COMPAT provider. So I am not >>> sure making a generic SPI would be needed here. >> >> I was thinking of one of the internal services that jdk.localedata >> currently provides. >> >>> >>> Anyway, this split package issue is blocking Alan's push, so I'd >>> like to push the change as it is. We can get back to this later. >> >> I agree this can be cleaned up as a separate issue. >> >> 152 InputStream is = module.getResourceAsStream( >> 153 ("jdk.localedata".equals(module.getName()) ? >> 154 "sun/text/resources/ext/" : >> "sun/text/resources/") + dictionaryName); >> >> It may be easier to read if line 153-154 are moved and assign to a >> separate variable. Otherwise, looks fine. >> >> Mandy >> >>> >>> Naoto >>> >>> On 9/7/16 5:17 PM, Mandy Chung wrote: >>>> Hi Naoto, >>>> >>>> Is there an alternative to get back the pathname of the resource >>>> e.g. adding a method in existing internal SPI to avoid hardcoding >>>> the module name and the resource pathname. >>>> >>>> Mandy >>>> >>>>> On Sep 7, 2016, at 3:56 PM, Naoto Sato wrote: >>>>> >>>>> Forgot to include jlink plugin changes. Here is the updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8165605/webrev.01/ >>>>> >>>>> Naoto >>>>> >>>>> On 9/7/16 3:03 PM, Naoto Sato wrote: >>>>>> Please review the changes to the subject bug: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8165605 >>>>>> >>>>>> The proposed fix is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/8165605/webrev.00/ >>>>>> >>>>>> The change is simply to move those 3 resources under >>>>>> sun.text.resources.ext package so that it won't cause the split >>>>>> package >>>>>> issue. >>>>>> >>>>>> Naoto >>>> >> From Roger.Riggs at Oracle.com Fri Sep 9 14:55:57 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 9 Sep 2016 10:55:57 -0400 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> Message-ID: <48504133-6eca-b36d-4b61-bec73874a268@Oracle.com> Hi Andrej, Thanks for the review and comments.. On 9/9/2016 2:32 AM, Andrej Golovnin wrote: > Hi Roger, > > src/java.base/share/classes/java/io/ObjectInputStream.java > > 259 private static class Logging { > > The class can be final. But there is no advantage or limitation since it is an private implementation class. > > 1265 ? Logger.Level.DEBUG > > There is one space too much before "Logger". removed > > 2611 /** total bytes read from the stream */ > 2612 private int totalBytesRead = 0; > > I think the type of the field totalBytesRead must be long. In the > #skip(long)-method you update it with a long value. ok I'll fix these before pushing. Thanks, Roger > > Best regards, > Andrej Golovnin From ivan.gerasimov at oracle.com Fri Sep 9 15:43:20 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 9 Sep 2016 18:43:20 +0300 Subject: [8u-dev] Request for Review and Approval to backport: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output Message-ID: <9cd8af6e-11c4-ee7f-9bfe-0a00b750c006@oracle.com> Hello! I'd like to backport this fix to jdk8u. The unshuffled fix applies almost clearly: I only had to slightly modify the regression test. Bug: https://bugs.openjdk.java.net/browse/JDK-8165243 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a81f30fb7d8c Jdk9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043266.html Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8165243/03/webrev/ Would you please help review the change and approve the backport? Thanks in advance, Ivan From sean.coffey at oracle.com Fri Sep 9 15:50:28 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 9 Sep 2016 16:50:28 +0100 Subject: [8u-dev] Request for Review and Approval to backport: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: <9cd8af6e-11c4-ee7f-9bfe-0a00b750c006@oracle.com> References: <9cd8af6e-11c4-ee7f-9bfe-0a00b750c006@oracle.com> Message-ID: <57D2DA44.4090809@oracle.com> Looks fine Ivan. Reviewed. Approved for jdk8u-dev. Regards, Sean. On 09/09/16 16:43, Ivan Gerasimov wrote: > Hello! > > I'd like to backport this fix to jdk8u. > > The unshuffled fix applies almost clearly: I only had to slightly > modify the regression test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165243 > Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a81f30fb7d8c > Jdk9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043266.html > Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8165243/03/webrev/ > > Would you please help review the change and approve the backport? > > Thanks in advance, > Ivan > From ivan.gerasimov at oracle.com Fri Sep 9 15:53:08 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 9 Sep 2016 18:53:08 +0300 Subject: [8u-dev] Request for Review and Approval to backport: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output In-Reply-To: <57D2DA44.4090809@oracle.com> References: <9cd8af6e-11c4-ee7f-9bfe-0a00b750c006@oracle.com> <57D2DA44.4090809@oracle.com> Message-ID: <94e297e1-fcfb-aca9-fdb8-bb4a700d851c@oracle.com> Thank you very much Se?n! On 09.09.2016 18:50, Se?n Coffey wrote: > Looks fine Ivan. Reviewed. > > Approved for jdk8u-dev. > > Regards, > Sean. > > On 09/09/16 16:43, Ivan Gerasimov wrote: >> Hello! >> >> I'd like to backport this fix to jdk8u. >> >> The unshuffled fix applies almost clearly: I only had to slightly >> modify the regression test. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8165243 >> Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a81f30fb7d8c >> Jdk9 review: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043266.html >> Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8165243/03/webrev/ >> >> Would you please help review the change and approve the backport? >> >> Thanks in advance, >> Ivan >> > > From naoto.sato at oracle.com Fri Sep 9 16:28:23 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 9 Sep 2016 09:28:23 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> <81e12bc9-df11-580e-23f1-a6c2222c53c2@oracle.com> Message-ID: <867e4c74-4e88-1787-fa75-19c7f6271b5c@oracle.com> The build tool is getting the output directory as a parameter and that also need to be tweaked. That output directory path is specified in the makefile which I wanted to avoid. Naoto On 9/8/16 4:31 PM, Masayoshi Okutsu wrote: > Is it just a matter of an extra step, new File(path).getName()? > > Masayoshi > > > On 9/9/2016 12:00 AM, Naoto Sato wrote: >> Well, actually I tried this approach first, then found out that the >> data files are also used by the GenerateBreakIteratorData build tool >> which has some implicit assumption of the value being the file name >> w/o path. So I ended up with the fix. >> >> Naoto >> >> On 9/8/16 5:46 AM, Alan Bateman wrote: >>> >>> >>> On 08/09/2016 03:51, Masayoshi Okutsu wrote: >>>> I thought Mandy suggested that the dictionary names in a >>>> ResourceBundle contain path names rather than base names, something >>>> like this: >>>> >>>> In BreakIteratorInfo_th.java: >>>> >>>> {"WordDictionary", "thai_dict"}, >>>> to >>>> {"WordDictionary", "sun/text/resources/ext/thai_dict"}, >>>> >>>> I haven't checked any side effects of this change, though. >>> That would be cleaner, assuming it doesn't cause issues. >>> >>> -Alan > From sundararajan.athijegannathan at oracle.com Fri Sep 9 16:36:17 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 9 Sep 2016 22:06:17 +0530 Subject: RFR 8165726: fix for 8165595 revealed a bug in pack200 tool's handling of main class attribute of module-info classes Message-ID: Please review http://cr.openjdk.java.net/~sundar/8165726/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165726 Thanks, -Sundar From kumar.x.srinivasan at oracle.com Fri Sep 9 18:15:44 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 09 Sep 2016 11:15:44 -0700 Subject: RFR 8165726: fix for 8165595 revealed a bug in pack200 tool's handling of main class attribute of module-info classes In-Reply-To: References: Message-ID: <57D2FC50.2090108@oracle.com> Looks good, thanks for taking care of it. We need to double check these again, I will take a closer look later. Kumar On 9/9/2016 9:36 AM, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8165726/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8165726 > > Thanks, > > -Sundar > From stuart.marks at oracle.com Fri Sep 9 18:24:05 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 9 Sep 2016 11:24:05 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <2e29edb0-e418-5431-5c37-32226c6853f6@Oracle.com> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> <2e29edb0-e418-5431-5c37-32226c6853f6@Oracle.com> Message-ID: <1168a749-8ba1-a2bd-e872-10fcb309f093@oracle.com> Hi Roger, Thanks for mentioning bug JDK-8041676. As far as I understand, the java.compiler property is intended to be set by the user in order to tell the JVM which JIT compiler to use. This is hinted at in the text I'm removing from the java.lang.Compiler spec in this changeset. The java.compiler property is also mentioned in j.l.System.getProperties(), where it simply says java.compiler Name of JIT compiler to use which is pretty inconclusive. Bug JDK-8041676 is strange in that it implies that something in the JDK should be setting this property. But I think that's wrong. I did a quick survey, and there are bunch of places that set -Djava.compiler=none in test code, demos, and in various checked-in NetBeans projects, but the only place that seems to read it is hotspot/src/share/vm/runtime/arguments.cpp where the specific value of "none" for this property is treated as a synonym for -Xint (run in interpretive mode). This still seems to be active. I'll update JDK-8041676 with these findings. I don't think java.lang.Compiler deprecation has any impact on the java.compiler property, though, except to remove some long-obsolete text. s'marks On 9/9/16 6:55 AM, Roger Riggs wrote: > Hi Stuart, > > Related to java.lang.Complier there is the System property "java.compiler" [1]. > Is there some notation needed on the property or will it just go poof when the > compiler is removed? > > Thanks, Roger > > [1] JDK-8041676 java.compiler > property is uninitialized > > > On 9/7/2016 4:52 PM, Stuart Marks wrote: >> Hi all, >> >> Please review this small patch to deprecate java.lang.Compiler for removal. >> >> Thanks, >> >> s'marks >> >> # HG changeset patch >> # User smarks >> # Date 1473281459 25200 >> # Wed Sep 07 13:50:59 2016 -0700 >> # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d >> # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c >> 4285505: deprecate java.lang.Compiler >> Reviewed-by: XXX >> >> diff -r 76ba1b74f268 -r e520c4e6970c >> src/java.base/share/classes/java/lang/Compiler.java >> --- a/src/java.base/share/classes/java/lang/Compiler.java Tue Sep 06 >> 16:08:54 2016 -0700 >> +++ b/src/java.base/share/classes/java/lang/Compiler.java Wed Sep 07 >> 13:50:59 2016 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -29,21 +29,18 @@ >> * The {@code Compiler} class is provided to support Java-to-native-code >> * compilers and related services. By design, the {@code Compiler} class does >> * nothing; it serves as a placeholder for a JIT compiler implementation. >> + * If no compiler is available, these methods do nothing. >> * >> - *

    When the Java Virtual Machine first starts, it determines if the system >> - * property {@code java.compiler} exists. (System properties are accessible >> - * through {@link System#getProperty(String)} and {@link >> - * System#getProperty(String, String)}. If so, it is assumed to be the name of >> - * a library (with a platform-dependent exact location and type); {@link >> - * System#loadLibrary} is called to load that library. If this loading >> - * succeeds, the function named {@code java_lang_Compiler_start()} in that >> - * library is called. >> - * >> - *

    If no compiler is available, these methods do nothing. >> + * @deprecated JIT compilers and their technologies vary too widely to >> + * be controlled effectively by a standardized interface. As such, many >> + * JIT compiler implementations ignore this interface, and are instead >> + * controllable by implementation-specific mechanisms such as command-line >> + * options. This class is subject to removal in a future version of Java SE. >> * >> * @author Frank Yellin >> * @since 1.0 >> */ >> + at Deprecated(since="9", forRemoval=true) >> public final class Compiler { >> private Compiler() {} // don't make instances >> > From kim.barrett at oracle.com Fri Sep 9 20:23:26 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 9 Sep 2016 16:23:26 -0400 Subject: RFR(XS): 8165393: bad merge in java/lang/ref/package-info.java Message-ID: <745BE4CA-8551-496A-B537-9EEAB802ACBD@oracle.com> Please review this fix of a merge error in the package-info for java.lang.ref. This is a doc-only change; per the RDP1 process the CR has been labeled "noreg-doc". CR: https://bugs.openjdk.java.net/browse/JDK-8165393 Webrev: http://cr.openjdk.java.net/~kbarrett/8165393/webrev/ From Alan.Bateman at oracle.com Fri Sep 9 20:26:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Sep 2016 21:26:33 +0100 Subject: RFR 8165726: fix for 8165595 revealed a bug in pack200 tool's handling of main class attribute of module-info classes In-Reply-To: <57D2FC50.2090108@oracle.com> References: <57D2FC50.2090108@oracle.com> Message-ID: <9c7ff5a1-829f-2dd5-9f4b-a16d73f3997a@oracle.com> On 09/09/2016 19:15, Kumar Srinivasan wrote: > Looks good, thanks for taking care of it. > > We need to double check these again, I will take a closer look > later. It's a CONSTANT_Class_info so I think it's right. It would be good to check the others as it's easy to get these wrong, maybe additional comments at the topic would help. -Alan From Roger.Riggs at Oracle.com Fri Sep 9 20:27:04 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 9 Sep 2016 16:27:04 -0400 Subject: RFR(XS): 8165393: bad merge in java/lang/ref/package-info.java In-Reply-To: <745BE4CA-8551-496A-B537-9EEAB802ACBD@oracle.com> References: <745BE4CA-8551-496A-B537-9EEAB802ACBD@oracle.com> Message-ID: <4d00de1a-0501-718a-dd6e-f9f13c3d557a@Oracle.com> Hi Kim, Looks good, thanks for the correction. Roger On 9/9/2016 4:23 PM, Kim Barrett wrote: > Please review this fix of a merge error in the package-info for > java.lang.ref. > > This is a doc-only change; per the RDP1 process the CR has been > labeled "noreg-doc". > > CR: > https://bugs.openjdk.java.net/browse/JDK-8165393 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8165393/webrev/ > From kim.barrett at oracle.com Fri Sep 9 20:57:18 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 9 Sep 2016 16:57:18 -0400 Subject: RFR(XS): 8165393: bad merge in java/lang/ref/package-info.java In-Reply-To: <4d00de1a-0501-718a-dd6e-f9f13c3d557a@Oracle.com> References: <745BE4CA-8551-496A-B537-9EEAB802ACBD@oracle.com> <4d00de1a-0501-718a-dd6e-f9f13c3d557a@Oracle.com> Message-ID: <66EA7F11-5044-4AD8-96B9-81EB3382696D@oracle.com> > On Sep 9, 2016, at 4:27 PM, Roger Riggs wrote: > > Hi Kim, > > Looks good, thanks for the correction. Thanks. > > Roger > > > On 9/9/2016 4:23 PM, Kim Barrett wrote: >> Please review this fix of a merge error in the package-info for >> java.lang.ref. >> >> This is a doc-only change; per the RDP1 process the CR has been >> labeled "noreg-doc". >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8165393 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8165393/webrev/ From naoto.sato at oracle.com Fri Sep 9 21:58:20 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 9 Sep 2016 14:58:20 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: <3272ac93-8f66-cca7-6e4c-f7ccef43d7c5@oracle.com> References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> <3272ac93-8f66-cca7-6e4c-f7ccef43d7c5@oracle.com> Message-ID: While at it, I noticed two build issues and updated the webrev. They are not directly related to the split package issue per se, but related to Thai breakiterator: 1) BreakIteratorRules_th.class slipped into the product image, which shouldn't. 2) Removed BreakIteratorRulesProvider.java which is not needed, as the class above is only used at the build time and not through module. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8165605/webrev.03/ Naoto On 9/9/16 7:15 AM, Erik Joelsson wrote: > Build change looks ok. > > /Erik > > > On 2016-09-08 17:37, Naoto Sato wrote: >> Updated the webrev wrt the latter comment: >> >> http://cr.openjdk.java.net/~naoto/8165605/webrev.02/ >> >> Naoto >> >> On 9/7/16 6:37 PM, Mandy Chung wrote: >>> >>>> On Sep 7, 2016, at 6:29 PM, Naoto Sato wrote: >>>> >>>> Hi Mandy, >>>> >>>> Although avoiding the hardcoded pathname is good, it is specific to >>>> the BreakIterator implementation of the COMPAT provider. So I am not >>>> sure making a generic SPI would be needed here. >>> >>> I was thinking of one of the internal services that jdk.localedata >>> currently provides. >>> >>>> >>>> Anyway, this split package issue is blocking Alan's push, so I'd >>>> like to push the change as it is. We can get back to this later. >>> >>> I agree this can be cleaned up as a separate issue. >>> >>> 152 InputStream is = module.getResourceAsStream( >>> 153 ("jdk.localedata".equals(module.getName()) ? >>> 154 "sun/text/resources/ext/" : >>> "sun/text/resources/") + dictionaryName); >>> >>> It may be easier to read if line 153-154 are moved and assign to a >>> separate variable. Otherwise, looks fine. >>> >>> Mandy >>> >>>> >>>> Naoto >>>> >>>> On 9/7/16 5:17 PM, Mandy Chung wrote: >>>>> Hi Naoto, >>>>> >>>>> Is there an alternative to get back the pathname of the resource >>>>> e.g. adding a method in existing internal SPI to avoid hardcoding >>>>> the module name and the resource pathname. >>>>> >>>>> Mandy >>>>> >>>>>> On Sep 7, 2016, at 3:56 PM, Naoto Sato wrote: >>>>>> >>>>>> Forgot to include jlink plugin changes. Here is the updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/8165605/webrev.01/ >>>>>> >>>>>> Naoto >>>>>> >>>>>> On 9/7/16 3:03 PM, Naoto Sato wrote: >>>>>>> Please review the changes to the subject bug: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165605 >>>>>>> >>>>>>> The proposed fix is located at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~naoto/8165605/webrev.00/ >>>>>>> >>>>>>> The change is simply to move those 3 resources under >>>>>>> sun.text.resources.ext package so that it won't cause the split >>>>>>> package >>>>>>> issue. >>>>>>> >>>>>>> Naoto >>>>> >>> > From mandy.chung at oracle.com Fri Sep 9 22:34:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Sep 2016 15:34:24 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> <3272ac93-8f66-cca7-6e4c-f7ccef43d7c5@oracle.com> Message-ID: > On Sep 9, 2016, at 2:58 PM, Naoto Sato wrote: > > While at it, I noticed two build issues and updated the webrev. They are not directly related to the split package issue per se, but related to Thai breakiterator: > > 1) BreakIteratorRules_th.class slipped into the product image, which shouldn't. > > 2) Removed BreakIteratorRulesProvider.java which is not needed, as the class above is only used at the build time and not through module. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8165605/webrev.03/ Looks fine. It?d be good to file a follow-on issue and investigate what it takes to implement Masayoshi?s suggestion - have BreakIterators::getObject to return dictionary data instead of a resource name. Mandy From steve.drach at oracle.com Fri Sep 9 23:02:08 2016 From: steve.drach at oracle.com (Steve Drach) Date: Fri, 9 Sep 2016 16:02:08 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method Message-ID: Hi, Please review this changeset that adds a VersionedStream class to the jdk.internal.util.jar package. Some may recall that I submitted a similar RFR a few weeks ago; this is a redesign from that one. We decided not to make a public JarFile::versionedStream method at this time. Once we get sufficient experience with this and find a few more use cases, we will revisit the idea of making this a public method in JarFile. issue: https://bugs.openjdk.java.net/browse/JDK-8163798 webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.01/index.html Thanks, Steve From naoto.sato at oracle.com Fri Sep 9 23:26:32 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 9 Sep 2016 16:26:32 -0700 Subject: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base In-Reply-To: References: <6dc6c93c-1c0b-4120-ae2a-9a545f22da7d@oracle.com> <08C55B36-2E6B-491B-9DDA-9CCC50593767@oracle.com> <3272ac93-8f66-cca7-6e4c-f7ccef43d7c5@oracle.com> Message-ID: <26103d9c-4cc5-e6ba-00cd-665e0488ddc1@oracle.com> Thanks. Created an issue for the follow-on issue: https://bugs.openjdk.java.net/browse/JDK-8165804 Naoto On 9/9/16 3:34 PM, Mandy Chung wrote: > >> On Sep 9, 2016, at 2:58 PM, Naoto Sato wrote: >> >> While at it, I noticed two build issues and updated the webrev. They are not directly related to the split package issue per se, but related to Thai breakiterator: >> >> 1) BreakIteratorRules_th.class slipped into the product image, which shouldn't. >> >> 2) Removed BreakIteratorRulesProvider.java which is not needed, as the class above is only used at the build time and not through module. >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~naoto/8165605/webrev.03/ > > Looks fine. > > It?d be good to file a follow-on issue and investigate what it takes to implement Masayoshi?s suggestion - have BreakIterators::getObject to return dictionary data instead of a resource name. > > Mandy > From claes.redestad at oracle.com Sat Sep 10 00:58:20 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 10 Sep 2016 02:58:20 +0200 Subject: RFR: 8165723: JarFile::isMultiRelease() method returns false when it should return true Message-ID: <57D35AAC.3010502@oracle.com> Hi, JDK-8152733 introduced a corner-case where isMultiRelease returns false when it should return true due to an erroneously hand-crafted Boyer-Moore search. Webrev: http://cr.openjdk.java.net/~redestad/8165723/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8165723 Testing: created a test reproducer using randomly constructed manifests and verified the supplied jar is properly detected as being multi-release. Thanks! /Claes From martinrb at google.com Sat Sep 10 17:21:28 2016 From: martinrb at google.com (Martin Buchholz) Date: Sat, 10 Sep 2016 10:21:28 -0700 Subject: RFR: jsr166 jdk9 integration wave 10 Message-ID: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ Mostly docs and tests. jsr166 CVS is now caught up with jdk9+135 Paul, I think we need to update AtomicInteger for VarHandle#getAndAdd: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java.udiff.html From jbluettduncan at gmail.com Sat Sep 10 21:51:55 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Sat, 10 Sep 2016 22:51:55 +0100 Subject: Participating on https://bugs.openjdk.java.net/browse/JDK-8156070 In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Message-ID: Hi Aleksey, Sorry for the late reply. Thank for you pointing me to the contribute page; it gave me all the information I needed. Stuart, I'm now ready to make a patch review request, so submit one as soon as I have the time. Kind regards, Jonathan On 6 September 2016 at 09:46, Aleksey Shipilev wrote: > On 09/06/2016 01:49 AM, Jonathan Bluett-Duncan wrote: > > I decided to have a crack at "JDK-8134373 explore potential uses of > > convenience factories within the JDK" today. I recognise it's only a P4 > bug > > and most likely won't be prioritised for Java 9, but I believe I found a > > number of places where uses of > > "Collections.unmodifiableList(Arrays.asList(...))" and > "Arrays.asList(..)" > > can be replaced with "List.of(...)". I've thus made some changes to my > > local clone of the jdk9 codebase. > > > > I'm now at a point where I'm unfamiliar with what one does next when > > contributing to OpenJDK, so I wonder if you'd kindly advise me on what my > > next step(s) are. > > See: http://openjdk.java.net/contribute/ > > In short, sign and send OCA, prepare and send the patch for review, work > with your sponsor. > > Thanks, > -Aleksey > From dbrosius at mebigfatguy.com Sat Sep 10 22:13:50 2016 From: dbrosius at mebigfatguy.com (Dave Brosius) Date: Sat, 10 Sep 2016 18:13:50 -0400 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Message-ID: It would be nice to be able to associate each element in a collection with another element in the collection, which is something very easily done with index based collections, but with sets, etc this isn't so easy... unless i'm having a brainfart. So i'd like to do this, but Iterator doesn't implement Cloneable... Any reason not to? or is there another way that's missing me? public class ItClone { public static void main(String[] args) { Set s = Collections.newSetFromMap(new ConcurrentHashMap()); s.add("Fee"); s.add("Fi"); s.add("Fo"); s.add("Fum"); Iterator it1 = s.iterator(); while (it1.hasNext()) { String v1 = it1.next(); Iterator it2 = (Iterator) it1.*clone*(); while (it2.hasNext()) { String v2 = it2.next(); System.out.println(v1 + " <-->" + v2); } } } } From jbluettduncan at gmail.com Sat Sep 10 22:36:22 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Sat, 10 Sep 2016 23:36:22 +0100 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Message-ID: Hi Dave, Rather than using Iterator.clone(), how about you just call collection.iterator() 2 times to return 2 unique, non-same iterators; something like the following: import java.util.Collections; import java.util.Iterator; import java.util.Set; import java.util.concurrent.ConcurrentHashMap; public class Example { public static void main(String[] args) { Set s = Collections.newSetFromMap(new ConcurrentHashMap()); s.add("Fee"); s.add("Fi"); s.add("Fo"); s.add("Fum"); Iterator it1 = s.iterator(); for (String v1 = null; it1.hasNext(); v1 =it1.next()) { Iterator it2 = s.iterator(); // a completely separate iterator to it1 for (String v2 = null; it2.hasNext(); v2 = it2.next()) { System.out.println(v1 + " <-->" + v2); } } } } Or, even better, if you're using Java 5+, you can skip using Iterators altogether and use for-loops directly: import java.util.Collections; import java.util.Set; import java.util.concurrent.ConcurrentHashMap; public class Example { public static void main(String[] args) { Set s = Collections.newSetFromMap(new ConcurrentHashMap()); s.add("Fee"); s.add("Fi"); s.add("Fo"); s.add("Fum"); for (String v1 : s) { for (String v2 : s) { System.out.println(v1 + "<-->" + v2); } } } } Kind regards, Jonathan On 10 September 2016 at 23:13, Dave Brosius wrote: > It would be nice to be able to associate each element in a collection with > another element in the collection, which is something very easily done with > index based collections, but with sets, etc this isn't so easy... unless > i'm having a brainfart. > > So i'd like to do this, but Iterator doesn't implement Cloneable... Any > reason not to? or is there another way that's missing me? > > public class ItClone { > > public static void main(String[] args) { > Set s = Collections.newSetFromMap(new > ConcurrentHashMap()); > > s.add("Fee"); > s.add("Fi"); > s.add("Fo"); > s.add("Fum"); > > Iterator it1 = s.iterator(); > while (it1.hasNext()) { > String v1 = it1.next(); > > Iterator it2 = (Iterator) it1.*clone*(); > while (it2.hasNext()) { > String v2 = it2.next(); > > System.out.println(v1 + " <-->" + v2); > } > } > } > } > From lowasser at google.com Sat Sep 10 22:39:49 2016 From: lowasser at google.com (Louis Wasserman) Date: Sat, 10 Sep 2016 22:39:49 +0000 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Message-ID: Jonathan, I think Dave's point is that you cannot start the inner iteration from the same point as the first iteration. This is true; the API does not provide a good way to do that. (I have always perceived this as working-as-intended; that iterators are not in general cloneable, and that there really is no sane way to do this other than converting to an index-based collection.) On Sat, Sep 10, 2016 at 3:37 PM Jonathan Bluett-Duncan < jbluettduncan at gmail.com> wrote: > Hi Dave, > > Rather than using Iterator.clone(), how about you just call > collection.iterator() 2 times to return 2 unique, non-same iterators; > something like the following: > > import java.util.Collections; > import java.util.Iterator; > import java.util.Set; > import java.util.concurrent.ConcurrentHashMap; > > public class Example { > public static void main(String[] args) { > Set s = Collections.newSetFromMap(new > ConcurrentHashMap()); > > s.add("Fee"); > s.add("Fi"); > s.add("Fo"); > s.add("Fum"); > > Iterator it1 = s.iterator(); > for (String v1 = null; it1.hasNext(); v1 =it1.next()) { > Iterator it2 = s.iterator(); // a completely separate > iterator to it1 > for (String v2 = null; it2.hasNext(); v2 = it2.next()) { > System.out.println(v1 + " <-->" + v2); > } > } > } > } > > > Or, even better, if you're using Java 5+, you can skip using Iterators > altogether and use for-loops directly: > > import java.util.Collections; > import java.util.Set; > import java.util.concurrent.ConcurrentHashMap; > > public class Example { > public static void main(String[] args) { > Set s = Collections.newSetFromMap(new > ConcurrentHashMap()); > > s.add("Fee"); > s.add("Fi"); > s.add("Fo"); > s.add("Fum"); > > for (String v1 : s) { > for (String v2 : s) { > System.out.println(v1 + "<-->" + v2); > } > } > } > } > > > Kind regards, > Jonathan > > On 10 September 2016 at 23:13, Dave Brosius > wrote: > > > It would be nice to be able to associate each element in a collection > with > > another element in the collection, which is something very easily done > with > > index based collections, but with sets, etc this isn't so easy... unless > > i'm having a brainfart. > > > > So i'd like to do this, but Iterator doesn't implement Cloneable... Any > > reason not to? or is there another way that's missing me? > > > > public class ItClone { > > > > public static void main(String[] args) { > > Set s = Collections.newSetFromMap(new > > ConcurrentHashMap()); > > > > s.add("Fee"); > > s.add("Fi"); > > s.add("Fo"); > > s.add("Fum"); > > > > Iterator it1 = s.iterator(); > > while (it1.hasNext()) { > > String v1 = it1.next(); > > > > Iterator it2 = (Iterator) it1.*clone*(); > > while (it2.hasNext()) { > > String v2 = it2.next(); > > > > System.out.println(v1 + " <-->" + v2); > > } > > } > > } > > } > > > From jbluettduncan at gmail.com Sat Sep 10 22:45:16 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Sat, 10 Sep 2016 23:45:16 +0100 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Message-ID: Ah okay Louis, if that's the case then that certainly makes sense, and I'd agree that there's no good way of doing so, as one would need to copy the set into a list. Dave, did Louis hit the mark? If not, would you kindly go into further detail as to exactly what it is you're trying to do? Best, Jonathan On 10 September 2016 at 23:36, Jonathan Bluett-Duncan < jbluettduncan at gmail.com> wrote: > Hi Dave, > > Rather than using Iterator.clone(), how about you just call > collection.iterator() 2 times to return 2 unique, non-same iterators; > something like the following: > > import java.util.Collections; > import java.util.Iterator; > import java.util.Set; > import java.util.concurrent.ConcurrentHashMap; > > public class Example { > public static void main(String[] args) { > Set s = Collections.newSetFromMap(new ConcurrentHashMap()); > > s.add("Fee"); > s.add("Fi"); > s.add("Fo"); > s.add("Fum"); > > Iterator it1 = s.iterator(); > for (String v1 = null; it1.hasNext(); v1 =it1.next()) { > Iterator it2 = s.iterator(); // a completely separate iterator to it1 > for (String v2 = null; it2.hasNext(); v2 = it2.next()) { > System.out.println(v1 + " <-->" + v2); > } > } > } > } > > > Or, even better, if you're using Java 5+, you can skip using Iterators > altogether and use for-loops directly: > > import java.util.Collections; > import java.util.Set; > import java.util.concurrent.ConcurrentHashMap; > > public class Example { > public static void main(String[] args) { > Set s = Collections.newSetFromMap(new ConcurrentHashMap()); > > s.add("Fee"); > s.add("Fi"); > s.add("Fo"); > s.add("Fum"); > > for (String v1 : s) { > for (String v2 : s) { > System.out.println(v1 + "<-->" + v2); > } > } > } > } > > > Kind regards, > Jonathan > > On 10 September 2016 at 23:13, Dave Brosius > wrote: > >> It would be nice to be able to associate each element in a collection >> with another element in the collection, which is something very easily done >> with index based collections, but with sets, etc this isn't so easy... >> unless i'm having a brainfart. >> >> So i'd like to do this, but Iterator doesn't implement Cloneable... Any >> reason not to? or is there another way that's missing me? >> >> public class ItClone { >> >> public static void main(String[] args) { >> Set s = Collections.newSetFromMap(new >> ConcurrentHashMap()); >> >> s.add("Fee"); >> s.add("Fi"); >> s.add("Fo"); >> s.add("Fum"); >> >> Iterator it1 = s.iterator(); >> while (it1.hasNext()) { >> String v1 = it1.next(); >> >> Iterator it2 = (Iterator) it1.*clone*(); >> while (it2.hasNext()) { >> String v2 = it2.next(); >> >> System.out.println(v1 + " <-->" + v2); >> } >> } >> } >> } >> > > From dbrosius at mebigfatguy.com Sat Sep 10 23:33:15 2016 From: dbrosius at mebigfatguy.com (Dave Brosius) Date: Sat, 10 Sep 2016 19:33:15 -0400 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Message-ID: <2713a4d4-15f5-200b-facb-afa9f41af617@mebigfatguy.com> Yes Louis is correct. I want the pair wise associations or all elements of a set. Fee-Fi Fee-Fo Fee-Fum Fi-Fo Fi-Fum Fo-Fum the independent iterators produce Fee-Fee (etc) as well as the duplicate Fee-Fi and Fi-Fee (etc), both of which i don't want. This is obviously simplistic with index based collections, but not with sets/maps I don't see why an Iterator isn't by nature easily cloneable. On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote: > Ah okay Louis, if that's the case then that certainly makes sense, and > I'd agree that there's no good way of doing so, as one would need to > copy the set into a list. > > Dave, did Louis hit the mark? If not, would you kindly go into further > detail as to exactly what it is you're trying to do? > > Best, > Jonathan > > On 10 September 2016 at 23:36, Jonathan Bluett-Duncan > > wrote: > > Hi Dave, > > Rather than using Iterator.clone(), how about you just call > collection.iterator() 2 times to return 2 unique, non-same > iterators; something like the following: > > import java.util.Collections; > import java.util.Iterator; > import java.util.Set; > import java.util.concurrent.ConcurrentHashMap; > > public class Example {public static void main(String[] args) { Set s = > Collections.newSetFromMap(new ConcurrentHashMap Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); s.add("Fum"); > Iterator it1 = s.iterator(); for (String v1 =null; it1.hasNext(); v1 =it1.next()) { > Iterator it2 = s.iterator();// a completely separate iterator to it1 for (String v2 =null; it2.hasNext(); v2 = it2.next()) {System.out.println(v1 + " <-->" + v2); } } } } > > Or, even better, if you're using Java 5+, you can skip using > Iterators altogether and use for-loops directly: > > import java.util.Collections; > import java.util.Set; > import java.util.concurrent.ConcurrentHashMap; > > public class Example {public static void main(String[] args) { Set s = > Collections.newSetFromMap(new ConcurrentHashMap Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); s.add("Fum"); for (String v1 : s) { > for (String v2 : s) {System.out.println(v1 + "<-->" + v2); } } } } > > Kind regards, > Jonathan > On 10 September 2016 at 23:13, Dave Brosius > > wrote: > > It would be nice to be able to associate each element in a > collection with another element in the collection, which is > something very easily done with index based collections, but > with sets, etc this isn't so easy... unless i'm having a > brainfart. So i'd like to do this, but Iterator doesn't > implement Cloneable... Any reason not to? or is there another > way that's missing me? public class ItClone { public > static void main(String[] args) { Set s = > Collections.newSetFromMap(new ConcurrentHashMap Boolean>()); s.add("Fee"); s.add("Fi"); > s.add("Fo"); s.add("Fum"); Iterator > it1 = s.iterator(); while (it1.hasNext()) { > String v1 = it1.next(); Iterator it2 = > (Iterator) it1.*clone*(); while > (it2.hasNext()) { String v2 = it2.next(); > System.out.println(v1 + " <-->" + v2); > } } } } > From jbluettduncan at gmail.com Sat Sep 10 23:42:47 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Sun, 11 Sep 2016 00:42:47 +0100 Subject: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK Message-ID: Hi all, Would you kindly review this patch to replace existing uses of Collections.unmodifiable*(*Arrays.asList(*)) and plain Arrays.asList(*) with (List|Set|Map).of(*). You may find the patch files in the attachments. My rationale for replacing uses of Collections.unmodifiable*... with (List|Set|Map).of is to make use of the memory savings allowed by the newer APIs. The general rationale for replacing the Arrays.asList calls I've touched is to again make use of memory savings, but this may be naive or misguided reasoning on my part, as Arrays.asList may or may not be more memory-efficient than List.of. However, where I've replaced Arrays.asList for List.of in FileTreeIterator, my reasoning for doing so instead was to help prevent TOCTOU attacks, but again this may be misguided on my part. It doesn't seem practical to me to include new unit tests, as these are mainly performance improvements, but if it's believed that new unit tests are needed, then I'd be happy to go back and try to include some. Kind regards, Jonathan From lowasser at google.com Sat Sep 10 23:44:50 2016 From: lowasser at google.com (Louis Wasserman) Date: Sat, 10 Sep 2016 23:44:50 +0000 Subject: Make iterators cloneable? In-Reply-To: <2713a4d4-15f5-200b-facb-afa9f41af617@mebigfatguy.com> References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <2713a4d4-15f5-200b-facb-afa9f41af617@mebigfatguy.com> Message-ID: Some iterators might be. Many may not be. Certainly Iterator as an interface has been out there for long enough there are Iterator implementations out there that aren't cloneable -- say, Iterators reading from a BufferedReader, where there really won't be any way to do what you're hoping for; BufferedReaders certainly aren't cloneable. On Sat, Sep 10, 2016 at 4:33 PM Dave Brosius wrote: > Yes Louis is correct. > > I want the pair wise associations or all elements of a set. > > Fee-Fi > > Fee-Fo > > Fee-Fum > > Fi-Fo > > Fi-Fum > > Fo-Fum > > > the independent iterators produce Fee-Fee (etc) as well as the duplicate > Fee-Fi and Fi-Fee (etc), both of which i don't want. > > > This is obviously simplistic with index based collections, but not with > sets/maps > > I don't see why an Iterator isn't by nature easily cloneable. > > > > On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote: > > Ah okay Louis, if that's the case then that certainly makes sense, and I'd > agree that there's no good way of doing so, as one would need to copy the > set into a list. > > Dave, did Louis hit the mark? If not, would you kindly go into further > detail as to exactly what it is you're trying to do? > > Best, > Jonathan > > On 10 September 2016 at 23:36, Jonathan Bluett-Duncan < > jbluettduncan at gmail.com> wrote: > > Hi Dave, > > Rather than using Iterator.clone(), how about you just call > collection.iterator() 2 times to return 2 unique, non-same iterators; > something like the following: > > import java.util.Collections;import java.util.Iterator;import java.util.Set;import java.util.concurrent.ConcurrentHashMap; > public class Example { > public static void main(String[] args) { > Set s = Collections.newSetFromMap(new ConcurrentHashMap()); > > s.add("Fee"); > s.add("Fi"); > s.add("Fo"); > s.add("Fum"); > > Iterator it1 = s.iterator(); for (String v1 = null; it1.hasNext(); v1 =it1.next()) { > Iterator it2 = s.iterator(); // a completely separate iterator to it1 for (String v2 = null; it2.hasNext(); v2 = it2.next()) { > System.out.println(v1 + " <-->" + v2); > } > } > } > } > > Or, even better, if you're using Java 5+, you can skip using Iterators > altogether and use for-loops directly: > > import java.util.Collections;import java.util.Set;import java.util.concurrent.ConcurrentHashMap; > public class Example { > public static void main(String[] args) { > Set s = Collections.newSetFromMap(new ConcurrentHashMap()); > > s.add("Fee"); > s.add("Fi"); > s.add("Fo"); > s.add("Fum"); > for (String v1 : s) { > for (String v2 : s) { > System.out.println(v1 + "<-->" + v2); > } > } > } > } > > Kind regards, > Jonathan > On 10 September 2016 at 23:13, Dave Brosius > wrote: > > It would be nice to be able to associate each element in a collection with > another element in the collection, which is something very easily done with > index based collections, but with sets, etc this isn't so easy... unless > i'm having a brainfart. So i'd like to do this, but Iterator doesn't > implement Cloneable... Any reason not to? or is there another way that's > missing me? public class ItClone { public static void main(String[] > args) { Set s = Collections.newSetFromMap(new > ConcurrentHashMap()); s.add("Fee"); > s.add("Fi"); s.add("Fo"); s.add("Fum"); > Iterator it1 = s.iterator(); while (it1.hasNext()) { > String v1 = it1.next(); Iterator it2 = > (Iterator) it1.*clone*(); while (it2.hasNext()) { > String v2 = it2.next(); System.out.println(v1 + " > <-->" + v2); } } } } > > From jbluettduncan at gmail.com Sat Sep 10 23:54:52 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Sun, 11 Sep 2016 00:54:52 +0100 Subject: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: Message-ID: Oops, it didn't fully register for me that I actually needed to include attachments in the body! So here they are again, this time in the body (hopefully). From jbluettduncan at gmail.com Sun Sep 11 00:01:18 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Sun, 11 Sep 2016 01:01:18 +0100 Subject: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: Message-ID: Sorry, it seems Gmail is not cooperating with me... If anyone does need to see the patches in-body, then I'd be happy to inline them directly in a reply, but that wouldn't be ideal since there are 18 of them in total... :/ On 11 September 2016 at 00:54, Jonathan Bluett-Duncan < jbluettduncan at gmail.com> wrote: > Oops, it didn't fully register for me that I actually needed to include > attachments in the body! So here they are again, this time in the body > (hopefully). > From dbrosius at mebigfatguy.com Sun Sep 11 00:23:41 2016 From: dbrosius at mebigfatguy.com (Dave Brosius) Date: Sat, 10 Sep 2016 20:23:41 -0400 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <2713a4d4-15f5-200b-facb-afa9f41af617@mebigfatguy.com> Message-ID: >> Iterators reading from a BufferedReader yes that's true. altho given the contract of Cloneable, adding the clone method on Iterator would be safe, as it would only be available if the real implementing class 'extends Cloneable'... it's actually kind of funny that Object methods aren't available on interface references, anyway. But i get the "age of Iterator" answer.. Shame there isn't an answer, tho. thanks, dave On 09/10/2016 07:44 PM, Louis Wasserman wrote: > Some iterators might be. Many may not be. Certainly Iterator as an > interface has been out there for long enough there are Iterator > implementations out there that aren't cloneable -- say, Iterators > reading from a BufferedReader, where there really won't be any way to > do what you're hoping for; BufferedReaders certainly aren't cloneable. > > On Sat, Sep 10, 2016 at 4:33 PM Dave Brosius > wrote: > > Yes Louis is correct. > > I want the pair wise associations or all elements of a set. > > Fee-Fi > > Fee-Fo > > Fee-Fum > > Fi-Fo > > Fi-Fum > > Fo-Fum > > > the independent iterators produce Fee-Fee (etc) as well as the > duplicate Fee-Fi and Fi-Fee (etc), both of which i don't want. > > > This is obviously simplistic with index based collections, but not > with sets/maps > > I don't see why an Iterator isn't by nature easily cloneable. > > > > On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote: >> Ah okay Louis, if that's the case then that certainly makes >> sense, and I'd agree that there's no good way of doing so, as one >> would need to copy the set into a list. >> >> Dave, did Louis hit the mark? If not, would you kindly go into >> further detail as to exactly what it is you're trying to do? >> >> Best, >> Jonathan >> >> On 10 September 2016 at 23:36, Jonathan Bluett-Duncan >> > wrote: >> >> Hi Dave, >> >> Rather than using Iterator.clone(), how about you just call >> collection.iterator() 2 times to return 2 unique, non-same >> iterators; something like the following: >> >> import java.util.Collections; >> import java.util.Iterator; >> import java.util.Set; >> import java.util.concurrent.ConcurrentHashMap; >> >> public class Example {public static void main(String[] args) { Set s = >> Collections.newSetFromMap(new ConcurrentHashMap> Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); >> s.add("Fum"); Iterator it1 = s.iterator(); for (String v1 =null; it1.hasNext(); v1 =it1.next()) { >> Iterator it2 = s.iterator();// a completely separate iterator to it1 for (String v2 =null; it2.hasNext(); v2 = it2.next()) {System.out.println(v1 + " <-->" + v2); } } } } >> >> Or, even better, if you're using Java 5+, you can skip using >> Iterators altogether and use for-loops directly: >> >> import java.util.Collections; >> import java.util.Set; >> import java.util.concurrent.ConcurrentHashMap; >> >> public class Example {public static void main(String[] args) { Set s = >> Collections.newSetFromMap(new ConcurrentHashMap> Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); >> s.add("Fum"); for (String v1 : s) { >> for (String v2 : s) {System.out.println(v1 + "<-->" + v2); } } } } >> >> Kind regards, >> Jonathan >> On 10 September 2016 at 23:13, Dave Brosius >> > >> wrote: >> >> It would be nice to be able to associate each element in >> a collection with another element in the collection, >> which is something very easily done with index based >> collections, but with sets, etc this isn't so easy... >> unless i'm having a brainfart. So i'd like to do this, >> but Iterator doesn't implement Cloneable... Any reason >> not to? or is there another way that's missing me? public >> class ItClone { public static void main(String[] >> args) { Set s = >> Collections.newSetFromMap(new ConcurrentHashMap> Boolean>()); s.add("Fee"); s.add("Fi"); >> s.add("Fo"); s.add("Fum"); >> Iterator it1 = s.iterator(); while >> (it1.hasNext()) { String v1 = it1.next(); >> Iterator it2 = (Iterator) >> it1.*clone*(); while (it2.hasNext()) { >> String v2 = it2.next(); >> System.out.println(v1 + " <-->" + v2); } >> } } } >> From forax at univ-mlv.fr Sun Sep 11 09:40:52 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 11 Sep 2016 11:40:52 +0200 (CEST) Subject: Make iterators cloneable? In-Reply-To: References: <2713a4d4-15f5-200b-facb-afa9f41af617@mebigfatguy.com> Message-ID: <1136990230.2452856.1473586852231.JavaMail.zimbra@u-pem.fr> Hi, digging a little bit in the bug database, there is a bug from 1999 https://bugs.openjdk.java.net/browse/JDK-4244952 answers seems to be - having different iterators on the same collection is error prone because iterators are failfast, the proposed workaround to use an array or a List with several indexes - it's too C++ish, C++ defines clone and equals, Java tries to define a simpler iteration protocol (from now, given that this question is raised only once in a while, it's doesn't seem to be a bad idea) - iterators are interfaces, so having several iterators means several virtual dispatch calls (this one is not true anymore because any JITs routinely devirtualize this kind of call). cheers, R?mi ----- Mail original ----- > De: "Dave Brosius" > ?: "Louis Wasserman" , "Jonathan Bluett-Duncan" > Cc: core-libs-dev at openjdk.java.net > Envoy?: Dimanche 11 Septembre 2016 02:23:41 > Objet: Re: Make iterators cloneable? >>> Iterators reading from a BufferedReader > > yes that's true. altho given the contract of Cloneable, adding the clone > method on Iterator would be safe, as it would only be available if the > real implementing class 'extends Cloneable'... it's actually kind of > funny that Object methods aren't available on interface references, anyway. > > > But i get the "age of Iterator" answer.. Shame there isn't an answer, tho. > > thanks, dave > > On 09/10/2016 07:44 PM, Louis Wasserman wrote: >> Some iterators might be. Many may not be. Certainly Iterator as an >> interface has been out there for long enough there are Iterator >> implementations out there that aren't cloneable -- say, Iterators >> reading from a BufferedReader, where there really won't be any way to >> do what you're hoping for; BufferedReaders certainly aren't cloneable. >> >> On Sat, Sep 10, 2016 at 4:33 PM Dave Brosius > > wrote: >> >> Yes Louis is correct. >> >> I want the pair wise associations or all elements of a set. >> >> Fee-Fi >> >> Fee-Fo >> >> Fee-Fum >> >> Fi-Fo >> >> Fi-Fum >> >> Fo-Fum >> >> >> the independent iterators produce Fee-Fee (etc) as well as the >> duplicate Fee-Fi and Fi-Fee (etc), both of which i don't want. >> >> >> This is obviously simplistic with index based collections, but not >> with sets/maps >> >> I don't see why an Iterator isn't by nature easily cloneable. >> >> >> >> On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote: >>> Ah okay Louis, if that's the case then that certainly makes >>> sense, and I'd agree that there's no good way of doing so, as one >>> would need to copy the set into a list. >>> >>> Dave, did Louis hit the mark? If not, would you kindly go into >>> further detail as to exactly what it is you're trying to do? >>> >>> Best, >>> Jonathan >>> >>> On 10 September 2016 at 23:36, Jonathan Bluett-Duncan >>> > wrote: >>> >>> Hi Dave, >>> >>> Rather than using Iterator.clone(), how about you just call >>> collection.iterator() 2 times to return 2 unique, non-same >>> iterators; something like the following: >>> >>> import java.util.Collections; >>> import java.util.Iterator; >>> import java.util.Set; >>> import java.util.concurrent.ConcurrentHashMap; >>> >>> public class Example {public static void main(String[] args) { Set s = >>> Collections.newSetFromMap(new ConcurrentHashMap>> Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); >>> s.add("Fum"); Iterator it1 = s.iterator(); for (String v1 =null; >>> it1.hasNext(); v1 =it1.next()) { >>> Iterator it2 = s.iterator();// a completely separate iterator to it1 for >>> (String v2 =null; it2.hasNext(); v2 = it2.next()) {System.out.println(v1 + " >>> <-->" + v2); } } } } >>> >>> Or, even better, if you're using Java 5+, you can skip using >>> Iterators altogether and use for-loops directly: >>> >>> import java.util.Collections; >>> import java.util.Set; >>> import java.util.concurrent.ConcurrentHashMap; >>> >>> public class Example {public static void main(String[] args) { Set s = >>> Collections.newSetFromMap(new ConcurrentHashMap>> Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); >>> s.add("Fum"); for (String v1 : s) { >>> for (String v2 : s) {System.out.println(v1 + "<-->" + v2); } } } } >>> >>> Kind regards, >>> Jonathan >>> On 10 September 2016 at 23:13, Dave Brosius >>> > >>> wrote: >>> >>> It would be nice to be able to associate each element in >>> a collection with another element in the collection, >>> which is something very easily done with index based >>> collections, but with sets, etc this isn't so easy... >>> unless i'm having a brainfart. So i'd like to do this, >>> but Iterator doesn't implement Cloneable... Any reason >>> not to? or is there another way that's missing me? public >>> class ItClone { public static void main(String[] >>> args) { Set s = >>> Collections.newSetFromMap(new ConcurrentHashMap>> Boolean>()); s.add("Fee"); s.add("Fi"); >>> s.add("Fo"); s.add("Fum"); >>> Iterator it1 = s.iterator(); while >>> (it1.hasNext()) { String v1 = it1.next(); >>> Iterator it2 = (Iterator) >>> it1.*clone*(); while (it2.hasNext()) { >>> String v2 = it2.next(); >>> System.out.println(v1 + " <-->" + v2); } >>> } } } From dbrosius at mebigfatguy.com Sun Sep 11 11:42:17 2016 From: dbrosius at mebigfatguy.com (Dave Brosius) Date: Sun, 11 Sep 2016 07:42:17 -0400 Subject: Make iterators cloneable? In-Reply-To: <1136990230.2452856.1473586852231.JavaMail.zimbra@u-pem.fr> References: <2713a4d4-15f5-200b-facb-afa9f41af617@mebigfatguy.com> <1136990230.2452856.1473586852231.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, The failfast argument is is irrelevant. It only matters if you use it.remove() which is no different than any other failfast situation. Obviously the 3rd argument is bogus too, as you say. The second argument, ok, is not arguable, as it's just a persons opinion. The bug report is in the genre of subList implementation which is different than this use, but ok. The problem is that there are no reasonable concurrent indexable collections, and the thought of copying large collections into a List everytime you want to do this is crazy. Unfortunately you can't even have one-off fixes for specific collections by having an iterator with a 'copy constructor' for instance, as in the case of collection iterators you _really_ have no business knowing what the real class is. On 09/11/2016 05:40 AM, Remi Forax wrote: > Hi, > digging a little bit in the bug database, there is a bug from 1999 > https://bugs.openjdk.java.net/browse/JDK-4244952 > > answers seems to be > - having different iterators on the same collection is error prone because iterators are failfast, > the proposed workaround to use an array or a List with several indexes > - it's too C++ish, C++ defines clone and equals, Java tries to define a simpler iteration protocol > (from now, given that this question is raised only once in a while, it's doesn't seem to be a bad idea) > - iterators are interfaces, so having several iterators means several virtual dispatch calls > (this one is not true anymore because any JITs routinely devirtualize this kind of call). > > cheers, > R?mi > > ----- Mail original ----- >> De: "Dave Brosius" >> ?: "Louis Wasserman" , "Jonathan Bluett-Duncan" >> Cc: core-libs-dev at openjdk.java.net >> Envoy?: Dimanche 11 Septembre 2016 02:23:41 >> Objet: Re: Make iterators cloneable? >>>> Iterators reading from a BufferedReader >> yes that's true. altho given the contract of Cloneable, adding the clone >> method on Iterator would be safe, as it would only be available if the >> real implementing class 'extends Cloneable'... it's actually kind of >> funny that Object methods aren't available on interface references, anyway. >> >> >> But i get the "age of Iterator" answer.. Shame there isn't an answer, tho. >> >> thanks, dave >> >> On 09/10/2016 07:44 PM, Louis Wasserman wrote: >>> Some iterators might be. Many may not be. Certainly Iterator as an >>> interface has been out there for long enough there are Iterator >>> implementations out there that aren't cloneable -- say, Iterators >>> reading from a BufferedReader, where there really won't be any way to >>> do what you're hoping for; BufferedReaders certainly aren't cloneable. >>> >>> On Sat, Sep 10, 2016 at 4:33 PM Dave Brosius >> > wrote: >>> >>> Yes Louis is correct. >>> >>> I want the pair wise associations or all elements of a set. >>> >>> Fee-Fi >>> >>> Fee-Fo >>> >>> Fee-Fum >>> >>> Fi-Fo >>> >>> Fi-Fum >>> >>> Fo-Fum >>> >>> >>> the independent iterators produce Fee-Fee (etc) as well as the >>> duplicate Fee-Fi and Fi-Fee (etc), both of which i don't want. >>> >>> >>> This is obviously simplistic with index based collections, but not >>> with sets/maps >>> >>> I don't see why an Iterator isn't by nature easily cloneable. >>> >>> >>> >>> On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote: >>>> Ah okay Louis, if that's the case then that certainly makes >>>> sense, and I'd agree that there's no good way of doing so, as one >>>> would need to copy the set into a list. >>>> >>>> Dave, did Louis hit the mark? If not, would you kindly go into >>>> further detail as to exactly what it is you're trying to do? >>>> >>>> Best, >>>> Jonathan >>>> >>>> On 10 September 2016 at 23:36, Jonathan Bluett-Duncan >>>> > wrote: >>>> >>>> Hi Dave, >>>> >>>> Rather than using Iterator.clone(), how about you just call >>>> collection.iterator() 2 times to return 2 unique, non-same >>>> iterators; something like the following: >>>> >>>> import java.util.Collections; >>>> import java.util.Iterator; >>>> import java.util.Set; >>>> import java.util.concurrent.ConcurrentHashMap; >>>> >>>> public class Example {public static void main(String[] args) { Set s = >>>> Collections.newSetFromMap(new ConcurrentHashMap>>> Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); >>>> s.add("Fum"); Iterator it1 = s.iterator(); for (String v1 =null; >>>> it1.hasNext(); v1 =it1.next()) { >>>> Iterator it2 = s.iterator();// a completely separate iterator to it1 for >>>> (String v2 =null; it2.hasNext(); v2 = it2.next()) {System.out.println(v1 + " >>>> <-->" + v2); } } } } >>>> >>>> Or, even better, if you're using Java 5+, you can skip using >>>> Iterators altogether and use for-loops directly: >>>> >>>> import java.util.Collections; >>>> import java.util.Set; >>>> import java.util.concurrent.ConcurrentHashMap; >>>> >>>> public class Example {public static void main(String[] args) { Set s = >>>> Collections.newSetFromMap(new ConcurrentHashMap>>> Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); >>>> s.add("Fum"); for (String v1 : s) { >>>> for (String v2 : s) {System.out.println(v1 + "<-->" + v2); } } } } >>>> >>>> Kind regards, >>>> Jonathan >>>> On 10 September 2016 at 23:13, Dave Brosius >>>> > >>>> wrote: >>>> >>>> It would be nice to be able to associate each element in >>>> a collection with another element in the collection, >>>> which is something very easily done with index based >>>> collections, but with sets, etc this isn't so easy... >>>> unless i'm having a brainfart. So i'd like to do this, >>>> but Iterator doesn't implement Cloneable... Any reason >>>> not to? or is there another way that's missing me? public >>>> class ItClone { public static void main(String[] >>>> args) { Set s = >>>> Collections.newSetFromMap(new ConcurrentHashMap>>> Boolean>()); s.add("Fee"); s.add("Fi"); >>>> s.add("Fo"); s.add("Fum"); >>>> Iterator it1 = s.iterator(); while >>>> (it1.hasNext()) { String v1 = it1.next(); >>>> Iterator it2 = (Iterator) >>>> it1.*clone*(); while (it2.hasNext()) { >>>> String v2 = it2.next(); >>>> System.out.println(v1 + " <-->" + v2); } >>>> } } } From amaembo at gmail.com Sun Sep 11 12:02:12 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Sun, 11 Sep 2016 19:02:12 +0700 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> Message-ID: <1731236.20160911190212@gmail.com> Hello! As your keys are comparable, you can create normal iterators and filter the results like this: for(String v1 : s) { for(String v2 : s) { if(v1.compareTo(v2) < 0) { System.out.println(v1 + " <-->" + v2); } } } Or using Stream API: s.stream().flatMap(v1 -> s.stream() .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) .forEach(System.out::println); With best regards, Tagir Valeev. DB> It would be nice to be able to associate each element in a collection DB> with another element in the collection, which is something very easily DB> done with index based collections, but with sets, etc this isn't so DB> easy... unless i'm having a brainfart. DB> So i'd like to do this, but Iterator doesn't implement Cloneable... Any DB> reason not to? or is there another way that's missing me? DB> public class ItClone { DB> public static void main(String[] args) { DB> Set s = Collections.newSetFromMap(new DB> ConcurrentHashMap()); DB> s.add("Fee"); DB> s.add("Fi"); DB> s.add("Fo"); DB> s.add("Fum"); DB> Iterator it1 = s.iterator(); DB> while (it1.hasNext()) { DB> String v1 = it1.next(); DB> Iterator it2 = (Iterator) it1.*clone*(); DB> while (it2.hasNext()) { DB> String v2 = it2.next(); DB> System.out.println(v1 + " <-->" + v2); DB> } DB> } DB> } DB> } From peter.levart at gmail.com Sun Sep 11 12:20:01 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 11 Sep 2016 14:20:01 +0200 Subject: Make iterators cloneable? In-Reply-To: <1731236.20160911190212@gmail.com> References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <1731236.20160911190212@gmail.com> Message-ID: <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> Hi, Even if the elements are not comparable, you could rely on the fact that Collection(s) usually create iterators with stable iteration order, so you could do the following: Set set = Set.of(1, 2, 3, 4); Iterator it1 = set.iterator(); for (int n1 = 0; it1.hasNext(); n1++) { Integer e1 = it1.next(); Iterator it2 = set.iterator(); for (int n2 = 0; n2 < n1; n2++) { Integer e2 = it2.next(); System.out.println(e1 + " <-> " + e2); } } Regards, Peter On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: > Hello! > > As your keys are comparable, you can create normal iterators and > filter the results like this: > > for(String v1 : s) { > for(String v2 : s) { > if(v1.compareTo(v2) < 0) { > System.out.println(v1 + " <-->" + v2); > } > } > } > > Or using Stream API: > > s.stream().flatMap(v1 -> s.stream() > .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) > .forEach(System.out::println); > > With best regards, > Tagir Valeev. > > > DB> It would be nice to be able to associate each element in a collection > DB> with another element in the collection, which is something very easily > DB> done with index based collections, but with sets, etc this isn't so > DB> easy... unless i'm having a brainfart. > > DB> So i'd like to do this, but Iterator doesn't implement Cloneable... Any > DB> reason not to? or is there another way that's missing me? > > DB> public class ItClone { > > DB> public static void main(String[] args) { > DB> Set s = Collections.newSetFromMap(new > DB> ConcurrentHashMap()); > > DB> s.add("Fee"); > DB> s.add("Fi"); > DB> s.add("Fo"); > DB> s.add("Fum"); > > DB> Iterator it1 = s.iterator(); > DB> while (it1.hasNext()) { > DB> String v1 = it1.next(); > > DB> Iterator it2 = (Iterator) it1.*clone*(); > DB> while (it2.hasNext()) { > DB> String v2 = it2.next(); > > DB> System.out.println(v1 + " <-->" + v2); > DB> } > DB> } > DB> } > DB> } > From dbrosius at mebigfatguy.com Sun Sep 11 16:55:00 2016 From: dbrosius at mebigfatguy.com (Dave Brosius) Date: Sun, 11 Sep 2016 12:55:00 -0400 Subject: Make iterators cloneable? In-Reply-To: <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <1731236.20160911190212@gmail.com> <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> Message-ID: Sure, but both of those algorithms are n^2, which is a bit painful, especially given all the pointer chasing that occurs with iterators. On 09/11/2016 08:20 AM, Peter Levart wrote: > Hi, > > Even if the elements are not comparable, you could rely on the fact > that Collection(s) usually create iterators with stable iteration > order, so you could do the following: > > > Set set = Set.of(1, 2, 3, 4); > > Iterator it1 = set.iterator(); > for (int n1 = 0; it1.hasNext(); n1++) { > Integer e1 = it1.next(); > Iterator it2 = set.iterator(); > for (int n2 = 0; n2 < n1; n2++) { > Integer e2 = it2.next(); > System.out.println(e1 + " <-> " + e2); > } > } > > > Regards, Peter > > On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: >> Hello! >> >> As your keys are comparable, you can create normal iterators and >> filter the results like this: >> >> for(String v1 : s) { >> for(String v2 : s) { >> if(v1.compareTo(v2) < 0) { >> System.out.println(v1 + " <-->" + v2); >> } >> } >> } >> >> Or using Stream API: >> >> s.stream().flatMap(v1 -> s.stream() >> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) >> .forEach(System.out::println); >> >> With best regards, >> Tagir Valeev. >> >> >> DB> It would be nice to be able to associate each element in a collection >> DB> with another element in the collection, which is something very easily >> DB> done with index based collections, but with sets, etc this isn't so >> DB> easy... unless i'm having a brainfart. >> >> DB> So i'd like to do this, but Iterator doesn't implement Cloneable... Any >> DB> reason not to? or is there another way that's missing me? >> >> DB> public class ItClone { >> >> DB> public static void main(String[] args) { >> DB> Set s = Collections.newSetFromMap(new >> DB> ConcurrentHashMap()); >> >> DB> s.add("Fee"); >> DB> s.add("Fi"); >> DB> s.add("Fo"); >> DB> s.add("Fum"); >> >> DB> Iterator it1 = s.iterator(); >> DB> while (it1.hasNext()) { >> DB> String v1 = it1.next(); >> >> DB> Iterator it2 = (Iterator) it1.*clone*(); >> DB> while (it2.hasNext()) { >> DB> String v2 = it2.next(); >> >> DB> System.out.println(v1 + " <-->" + v2); >> DB> } >> DB> } >> DB> } >> DB> } >> > From jbluettduncan at gmail.com Sun Sep 11 17:12:34 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Sun, 11 Sep 2016 18:12:34 +0100 Subject: Fwd: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <1731236.20160911190212@gmail.com> <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> Message-ID: I think O(N^2)-like performance is unavoidable here Dave. However, although Peter's algorithm is indeed O(N^2), it should be faster than Tagir's and reasonable(-ish) in practice. This is because the inner loop starts off not executing at all in the outer loop's first iteration; and each time the outer loop iterates, the inner loop's number of iterations increases by 1, eventually reaching N iterations when the outer loop itself hits iteration N. So although Peter's algorithm is O(N^2) in theory, in practice it shouldn't or isn't as bad as most O(N^2) algos, since the number of steps it takes is less than some ratio of N^2 for sufficiently large N. On 11 September 2016 at 17:55, Dave Brosius wrote: > Sure, but both of those algorithms are n^2, which is a bit painful, > especially given all the pointer chasing that occurs with iterators. > > > > On 09/11/2016 08:20 AM, Peter Levart wrote: > >> Hi, >> >> Even if the elements are not comparable, you could rely on the fact that >> Collection(s) usually create iterators with stable iteration order, so you >> could do the following: >> >> >> Set set = Set.of(1, 2, 3, 4); >> >> Iterator it1 = set.iterator(); >> for (int n1 = 0; it1.hasNext(); n1++) { >> Integer e1 = it1.next(); >> Iterator it2 = set.iterator(); >> for (int n2 = 0; n2 < n1; n2++) { >> Integer e2 = it2.next(); >> System.out.println(e1 + " <-> " + e2); >> } >> } >> >> >> Regards, Peter >> >> On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: >> >>> Hello! >>> >>> As your keys are comparable, you can create normal iterators and >>> filter the results like this: >>> >>> for(String v1 : s) { >>> for(String v2 : s) { >>> if(v1.compareTo(v2) < 0) { >>> System.out.println(v1 + " <-->" + v2); >>> } >>> } >>> } >>> >>> Or using Stream API: >>> >>> s.stream().flatMap(v1 -> s.stream() >>> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) >>> .forEach(System.out::println); >>> >>> With best regards, >>> Tagir Valeev. >>> >>> >>> DB> It would be nice to be able to associate each element in a collection >>> DB> with another element in the collection, which is something very >>> easily >>> DB> done with index based collections, but with sets, etc this isn't so >>> DB> easy... unless i'm having a brainfart. >>> >>> DB> So i'd like to do this, but Iterator doesn't implement Cloneable... >>> Any >>> DB> reason not to? or is there another way that's missing me? >>> >>> DB> public class ItClone { >>> >>> DB> public static void main(String[] args) { >>> DB> Set s = Collections.newSetFromMap(new >>> DB> ConcurrentHashMap()); >>> >>> DB> s.add("Fee"); >>> DB> s.add("Fi"); >>> DB> s.add("Fo"); >>> DB> s.add("Fum"); >>> >>> DB> Iterator it1 = s.iterator(); >>> DB> while (it1.hasNext()) { >>> DB> String v1 = it1.next(); >>> >>> DB> Iterator it2 = (Iterator) it1.*clone*(); >>> DB> while (it2.hasNext()) { >>> DB> String v2 = it2.next(); >>> >>> DB> System.out.println(v1 + " <-->" + v2); >>> DB> } >>> DB> } >>> DB> } >>> DB> } >>> >>> >> > From steve.drach at oracle.com Sun Sep 11 20:12:32 2016 From: steve.drach at oracle.com (Steve Drach) Date: Sun, 11 Sep 2016 13:12:32 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: References: Message-ID: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> I made a simple change, the new webrev is http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ > On Sep 9, 2016, at 4:02 PM, Steve Drach wrote: > > Hi, > > Please review this changeset that adds a VersionedStream class to the jdk.internal.util.jar package. Some may recall that I submitted a similar RFR a few weeks ago; this is a redesign from that one. We decided not to make a public JarFile::versionedStream method at this time. Once we get sufficient experience with this and find a few more use cases, we will revisit the idea of making this a public method in JarFile. > > issue: https://bugs.openjdk.java.net/browse/JDK-8163798 > webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.01/index.html > > Thanks, > Steve From joe.darcy at oracle.com Sun Sep 11 20:12:55 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 11 Sep 2016 13:12:55 -0700 Subject: JDK 9 RFR of JDK-8165810: Problem list VersionCheck.java until JDK-8165772 is fixed Message-ID: Hello, Until the issues discussed in JDK-8165772 are fixed, the test tools/launcher/VersionCheck.java should added to the problem listed so clean test runs are possible. Please review the patch below to accomplish this. Thanks, Joe diff -r f2e94fd11c41 test/ProblemList.txt --- a/test/ProblemList.txt Sat Sep 10 06:46:45 2016 +0530 +++ b/test/ProblemList.txt Sun Sep 11 13:12:37 2016 -0700 @@ -314,6 +314,8 @@ tools/pack200/Pack200Props.java 8155857 generic-all +tools/launcher/VersionCheck.java 8165772 generic-all + ############################################################################ # jdk_jdi From lance.andersen at oracle.com Sun Sep 11 20:15:55 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 11 Sep 2016 16:15:55 -0400 Subject: JDK 9 RFR of JDK-8165810: Problem list VersionCheck.java until JDK-8165772 is fixed In-Reply-To: References: Message-ID: <16405E43-4101-49E7-8209-564927863090@oracle.com> +1 Best Lance > On Sep 11, 2016, at 4:12 PM, joe darcy wrote: > > Hello, > > Until the issues discussed in JDK-8165772 are fixed, the test > > tools/launcher/VersionCheck.java > > should added to the problem listed so clean test runs are possible. > > Please review the patch below to accomplish this. > > Thanks, > > Joe > > diff -r f2e94fd11c41 test/ProblemList.txt > --- a/test/ProblemList.txt Sat Sep 10 06:46:45 2016 +0530 > +++ b/test/ProblemList.txt Sun Sep 11 13:12:37 2016 -0700 > @@ -314,6 +314,8 @@ > > tools/pack200/Pack200Props.java 8155857 generic-all > > +tools/launcher/VersionCheck.java 8165772 generic-all > + > ############################################################################ > > # jdk_jdi > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From claes.redestad at oracle.com Sun Sep 11 20:15:50 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 11 Sep 2016 22:15:50 +0200 Subject: JDK 9 RFR of JDK-8165810: Problem list VersionCheck.java until JDK-8165772 is fixed In-Reply-To: References: Message-ID: <57D5BB76.6000303@oracle.com> Looks OK to me /Claes On 2016-09-11 22:12, joe darcy wrote: > Hello, > > Until the issues discussed in JDK-8165772 are fixed, the test > > tools/launcher/VersionCheck.java > > should added to the problem listed so clean test runs are possible. > > Please review the patch below to accomplish this. > > Thanks, > > Joe > > diff -r f2e94fd11c41 test/ProblemList.txt > --- a/test/ProblemList.txt Sat Sep 10 06:46:45 2016 +0530 > +++ b/test/ProblemList.txt Sun Sep 11 13:12:37 2016 -0700 > @@ -314,6 +314,8 @@ > > tools/pack200/Pack200Props.java 8155857 generic-all > > +tools/launcher/VersionCheck.java 8165772 generic-all > + > ############################################################################ > > # jdk_jdi > From claes.redestad at oracle.com Sun Sep 11 20:56:27 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 11 Sep 2016 22:56:27 +0200 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> Message-ID: <57D5C4FB.9090404@oracle.com> Hi, jdk/internal/util/jar/VersionedStream.java: - use Integer.parseInt(name, vptr, ptr, 10) to avoid creating vstr on every entry - folding allowedVersions into getBaseSuffix seems easier than to keep global state (sptr) and splitting the logic over a filter and a map operation - distinct() could be used instead of explicitly collecting to a LinkedHashSet, but this does make me wonder if we could do even better by creating a map from base name to the appropriate versioned JarEntry and return a stream over that map to avoid looking things up via jf::getJarEntry. Could be quite a bit more efficient, and as we have to create a set or do distinct the overheads should be roughly the same either way - declaring META_INF_VERSIONS_LEN seems like a premature optimization - nit: static final is preferred over final static - nit: rename *ptr to *Index Test and JarFile changes seem fine to me. Thanks! /Claes On 2016-09-11 22:12, Steve Drach wrote: > I made a simple change, the new webrev is http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ > >> On Sep 9, 2016, at 4:02 PM, Steve Drach wrote: >> >> Hi, >> >> Please review this changeset that adds a VersionedStream class to the jdk.internal.util.jar package. Some may recall that I submitted a similar RFR a few weeks ago; this is a redesign from that one. We decided not to make a public JarFile::versionedStream method at this time. Once we get sufficient experience with this and find a few more use cases, we will revisit the idea of making this a public method in JarFile. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8163798 >> webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.01/index.html >> >> Thanks, >> Steve > From peter.levart at gmail.com Sun Sep 11 21:42:29 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 11 Sep 2016 23:42:29 +0200 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <1731236.20160911190212@gmail.com> <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> Message-ID: <06efbb04-e97b-18b7-a1fe-5fa010811fdc@gmail.com> I would say the algorithm is O(n), when you take n to be the number of emitted pairs, wouldn't you ;-) You wanted an algorithm that emits n*(n-1) / 2 distinct pairs of elements from a set of n elements, didn't you? Regards, Peter On 09/11/2016 06:55 PM, Dave Brosius wrote: > Sure, but both of those algorithms are n^2, which is a bit painful, > especially given all the pointer chasing that occurs with iterators. > > > On 09/11/2016 08:20 AM, Peter Levart wrote: >> Hi, >> >> Even if the elements are not comparable, you could rely on the fact >> that Collection(s) usually create iterators with stable iteration >> order, so you could do the following: >> >> >> Set set = Set.of(1, 2, 3, 4); >> >> Iterator it1 = set.iterator(); >> for (int n1 = 0; it1.hasNext(); n1++) { >> Integer e1 = it1.next(); >> Iterator it2 = set.iterator(); >> for (int n2 = 0; n2 < n1; n2++) { >> Integer e2 = it2.next(); >> System.out.println(e1 + " <-> " + e2); >> } >> } >> >> >> Regards, Peter >> >> On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: >>> Hello! >>> >>> As your keys are comparable, you can create normal iterators and >>> filter the results like this: >>> >>> for(String v1 : s) { >>> for(String v2 : s) { >>> if(v1.compareTo(v2) < 0) { >>> System.out.println(v1 + " <-->" + v2); >>> } >>> } >>> } >>> >>> Or using Stream API: >>> >>> s.stream().flatMap(v1 -> s.stream() >>> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) >>> .forEach(System.out::println); >>> >>> With best regards, >>> Tagir Valeev. >>> >>> >>> DB> It would be nice to be able to associate each element in a >>> collection >>> DB> with another element in the collection, which is something very >>> easily >>> DB> done with index based collections, but with sets, etc this isn't so >>> DB> easy... unless i'm having a brainfart. >>> >>> DB> So i'd like to do this, but Iterator doesn't implement >>> Cloneable... Any >>> DB> reason not to? or is there another way that's missing me? >>> >>> DB> public class ItClone { >>> >>> DB> public static void main(String[] args) { >>> DB> Set s = Collections.newSetFromMap(new >>> DB> ConcurrentHashMap()); >>> >>> DB> s.add("Fee"); >>> DB> s.add("Fi"); >>> DB> s.add("Fo"); >>> DB> s.add("Fum"); >>> >>> DB> Iterator it1 = s.iterator(); >>> DB> while (it1.hasNext()) { >>> DB> String v1 = it1.next(); >>> >>> DB> Iterator it2 = (Iterator) >>> it1.*clone*(); >>> DB> while (it2.hasNext()) { >>> DB> String v2 = it2.next(); >>> >>> DB> System.out.println(v1 + " <-->" + v2); >>> DB> } >>> DB> } >>> DB> } >>> DB> } >>> >> > From david.holmes at oracle.com Mon Sep 12 00:50:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Sep 2016 10:50:49 +1000 Subject: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: Message-ID: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> Hi Jonathon, Attachments get stripped from most of the mailing lists so you will need to find someone to host these for you on cr.openjdk.java.net. That aside you may be hard pressed to find anyone who can look at this future work now, given where things are with the JDK 9 release schedule. Cheers, David On 11/09/2016 9:42 AM, Jonathan Bluett-Duncan wrote: > Hi all, > > Would you kindly review this patch to replace existing uses of > Collections.unmodifiable*(*Arrays.asList(*)) and plain Arrays.asList(*) > with (List|Set|Map).of(*). You may find the patch files in the attachments. > > My rationale for replacing uses of Collections.unmodifiable*... with > (List|Set|Map).of is to make use of the memory savings allowed by the newer > APIs. > > The general rationale for replacing the Arrays.asList calls I've touched is > to again make use of memory savings, but this may be naive or misguided > reasoning on my part, as Arrays.asList may or may not be more > memory-efficient than List.of. However, where I've replaced Arrays.asList > for List.of in FileTreeIterator, my reasoning for doing so instead was to > help prevent TOCTOU attacks, but again this may be misguided on my part. > > It doesn't seem practical to me to include new unit tests, as these are > mainly performance improvements, but if it's believed that new unit tests > are needed, then I'd be happy to go back and try to include some. > > Kind regards, > Jonathan > From amaembo at gmail.com Mon Sep 12 00:51:59 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 12 Sep 2016 07:51:59 +0700 Subject: Make iterators cloneable? In-Reply-To: <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <1731236.20160911190212@gmail.com> <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> Message-ID: Hello, Peter! I thought about numbering, but original Dave's code involved concurrent set, so I presume that it's expected to be modified from other threads. In this case my algorithm would output some legal pairs (probably reflecting changes or not or reflecting only partially) while your algorithm can output garbage (pair with equal e1, e2 or two pairs like e1 <-> e2, e2 <-> e1 or can even die with NoSuchElementException). Not sure what is better in author's case. Tagir. On Sun, Sep 11, 2016 at 7:20 PM, Peter Levart wrote: > Hi, > > Even if the elements are not comparable, you could rely on the fact that > Collection(s) usually create iterators with stable iteration order, so you > could do the following: > > > Set set = Set.of(1, 2, 3, 4); > > Iterator it1 = set.iterator(); > for (int n1 = 0; it1.hasNext(); n1++) { > Integer e1 = it1.next(); > Iterator it2 = set.iterator(); > for (int n2 = 0; n2 < n1; n2++) { > Integer e2 = it2.next(); > System.out.println(e1 + " <-> " + e2); > } > } > > > Regards, Peter > > > On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: > > Hello! > > As your keys are comparable, you can create normal iterators and > filter the results like this: > > for(String v1 : s) { > for(String v2 : s) { > if(v1.compareTo(v2) < 0) { > System.out.println(v1 + " <-->" + v2); > } > } > } > > Or using Stream API: > > s.stream().flatMap(v1 -> s.stream() > .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) > .forEach(System.out::println); > > With best regards, > Tagir Valeev. > > > DB> It would be nice to be able to associate each element in a collection > DB> with another element in the collection, which is something very easily > DB> done with index based collections, but with sets, etc this isn't so > DB> easy... unless i'm having a brainfart. > > DB> So i'd like to do this, but Iterator doesn't implement Cloneable... Any > DB> reason not to? or is there another way that's missing me? > > DB> public class ItClone { > > DB> public static void main(String[] args) { > DB> Set s = Collections.newSetFromMap(new > DB> ConcurrentHashMap()); > > DB> s.add("Fee"); > DB> s.add("Fi"); > DB> s.add("Fo"); > DB> s.add("Fum"); > > DB> Iterator it1 = s.iterator(); > DB> while (it1.hasNext()) { > DB> String v1 = it1.next(); > > DB> Iterator it2 = (Iterator) it1.*clone*(); > DB> while (it2.hasNext()) { > DB> String v2 = it2.next(); > > DB> System.out.println(v1 + " <-->" + v2); > DB> } > DB> } > DB> } > DB> } > > > > From amaembo at gmail.com Mon Sep 12 00:58:27 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 12 Sep 2016 07:58:27 +0700 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <1731236.20160911190212@gmail.com> <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> Message-ID: Actually given the fact that we're iterating the Set (so the elements are unique) and using the assumption that iteration of the same set is stable, you can avoid numbering like this: for(String e1 : set) { for(String e2 : set) { if(e1 == e2) break; System.out.println(e1+" <-> "+e2); } } Again, such algorithm is fragile to concurrent changes. With best regards, Tagir Valeev. On Mon, Sep 12, 2016 at 7:51 AM, Tagir Valeev wrote: > Hello, Peter! > > I thought about numbering, but original Dave's code involved concurrent > set, so I presume that it's expected to be modified from other threads. In > this case my algorithm would output some legal pairs (probably reflecting > changes or not or reflecting only partially) while your algorithm can > output garbage (pair with equal e1, e2 or two pairs like e1 <-> e2, e2 <-> > e1 or can even die with NoSuchElementException). Not sure what is better in > author's case. > > Tagir. > > On Sun, Sep 11, 2016 at 7:20 PM, Peter Levart > wrote: > >> Hi, >> >> Even if the elements are not comparable, you could rely on the fact that >> Collection(s) usually create iterators with stable iteration order, so you >> could do the following: >> >> >> Set set = Set.of(1, 2, 3, 4); >> >> Iterator it1 = set.iterator(); >> for (int n1 = 0; it1.hasNext(); n1++) { >> Integer e1 = it1.next(); >> Iterator it2 = set.iterator(); >> for (int n2 = 0; n2 < n1; n2++) { >> Integer e2 = it2.next(); >> System.out.println(e1 + " <-> " + e2); >> } >> } >> >> >> Regards, Peter >> >> >> On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: >> >> Hello! >> >> As your keys are comparable, you can create normal iterators and >> filter the results like this: >> >> for(String v1 : s) { >> for(String v2 : s) { >> if(v1.compareTo(v2) < 0) { >> System.out.println(v1 + " <-->" + v2); >> } >> } >> } >> >> Or using Stream API: >> >> s.stream().flatMap(v1 -> s.stream() >> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) >> .forEach(System.out::println); >> >> With best regards, >> Tagir Valeev. >> >> >> DB> It would be nice to be able to associate each element in a collection >> DB> with another element in the collection, which is something very easily >> DB> done with index based collections, but with sets, etc this isn't so >> DB> easy... unless i'm having a brainfart. >> >> DB> So i'd like to do this, but Iterator doesn't implement Cloneable... Any >> DB> reason not to? or is there another way that's missing me? >> >> DB> public class ItClone { >> >> DB> public static void main(String[] args) { >> DB> Set s = Collections.newSetFromMap(new >> DB> ConcurrentHashMap()); >> >> DB> s.add("Fee"); >> DB> s.add("Fi"); >> DB> s.add("Fo"); >> DB> s.add("Fum"); >> >> DB> Iterator it1 = s.iterator(); >> DB> while (it1.hasNext()) { >> DB> String v1 = it1.next(); >> >> DB> Iterator it2 = (Iterator) it1.*clone*(); >> DB> while (it2.hasNext()) { >> DB> String v2 = it2.next(); >> >> DB> System.out.println(v1 + " <-->" + v2); >> DB> } >> DB> } >> DB> } >> DB> } >> >> >> >> > From amy.lu at oracle.com Mon Sep 12 03:38:32 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 12 Sep 2016 11:38:32 +0800 Subject: JDK 9 RFR of JDK-8165818: Remove tools/pack200/Pack200Props.java from ProblemList Message-ID: <7498b951-367f-29e6-319f-f91ab2c2336d@oracle.com> tools/pack200/Pack200Props.java This test was put into ProblemList.txt in 9/117 due to test timed out issue: JDK-8155857. Test failure (timed out) is reproducible with 9/117 and 9/118, but issue gone in 9/119 and *not* reproducible anymore since 9/119. Issue must has been resolved with other fixes. Tested with the very latest build on all platforms, test pass. Standalone run test in loop for 500 times, test all pass. As issue does not exist anymore, test could be removed from ProblemList.txt bug: https://bugs.openjdk.java.net/browse/JDK-8165818 Thanks, Amy --- old/test/ProblemList.txt 2016-09-12 11:28:05.000000000 +0800 +++ new/test/ProblemList.txt 2016-09-12 11:28:05.000000000 +0800 @@ -1,4 +1,4 @@ -########################################################################### +e########################################################################## # # Copyright (c) 2009, 2016, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. @@ -312,8 +312,6 @@ tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all -tools/pack200/Pack200Props.java 8155857 generic-all - tools/launcher/VersionCheck.java 8165772 generic-all ############################################################################ From amy.lu at oracle.com Mon Sep 12 03:58:33 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 12 Sep 2016 11:58:33 +0800 Subject: JDK 9 RFR of JDK-8165818: Remove tools/pack200/Pack200Props.java from ProblemList In-Reply-To: <7498b951-367f-29e6-319f-f91ab2c2336d@oracle.com> References: <7498b951-367f-29e6-319f-f91ab2c2336d@oracle.com> Message-ID: On 9/12/16 11:38 AM, Amy Lu wrote: > tools/pack200/Pack200Props.java > > This test was put into ProblemList.txt in 9/117 due to test timed out > issue: JDK-8155857. > > Test failure (timed out) is reproducible with 9/117 and 9/118, but > issue gone in 9/119 and *not* reproducible anymore since 9/119. Issue > must has been resolved with other fixes. > > Tested with the very latest build on all platforms, test pass. > Standalone run test in loop for 500 times, test all pass. > > As issue does not exist anymore, test could be removed from > ProblemList.txt > > bug: https://bugs.openjdk.java.net/browse/JDK-8165818 > > Thanks, > Amy > Sorry, the patch: http://cr.openjdk.java.net/~amlu/8165818/webrev.00/ --- old/test/ProblemList.txt 2016-09-12 11:55:51.000000000 +0800 +++ new/test/ProblemList.txt 2016-09-12 11:55:51.000000000 +0800 @@ -312,8 +312,6 @@ tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all -tools/pack200/Pack200Props.java 8155857 generic-all - tools/launcher/VersionCheck.java 8165772 generic-all ############################################################################ From weijun.wang at oracle.com Mon Sep 12 07:23:43 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Sep 2016 15:23:43 +0800 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: BTW, please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8165836 Thanks Max On 9/1/2016 22:25, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8164705/webrev.01 From dbrosius at mebigfatguy.com Mon Sep 12 08:26:16 2016 From: dbrosius at mebigfatguy.com (Dave Brosius) Date: Mon, 12 Sep 2016 04:26:16 -0400 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <1731236.20160911190212@gmail.com> <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> Message-ID: That would give you unwanted duplicates Fi-Fum and Fum-Fi for instance On 09/11/2016 08:58 PM, Tagir Valeev wrote: > Actually given the fact that we're iterating the Set (so the elements > are unique) and using the assumption that iteration of the same set is > stable, you can avoid numbering like this: > > for(String e1 : set) { > for(String e2 : set) { > if(e1 == e2) break; > System.out.println(e1+" <-> "+e2); > } > } > > Again, such algorithm is fragile to concurrent changes. > > With best regards, > Tagir Valeev. > > On Mon, Sep 12, 2016 at 7:51 AM, Tagir Valeev > wrote: > > Hello, Peter! > > I thought about numbering, but original Dave's code involved > concurrent set, so I presume that it's expected to be modified > from other threads. In this case my algorithm would output some > legal pairs (probably reflecting changes or not or reflecting only > partially) while your algorithm can output garbage (pair with > equal e1, e2 or two pairs like e1 <-> e2, e2 <-> e1 or can even > die with NoSuchElementException). Not sure what is better in > author's case. > > Tagir. > > On Sun, Sep 11, 2016 at 7:20 PM, Peter Levart > > wrote: > > Hi, > > Even if the elements are not comparable, you could rely on the > fact that Collection(s) usually create iterators with stable > iteration order, so you could do the following: > > > Set set = Set.of(1, 2, 3, 4); > > Iterator it1 = set.iterator(); > for (int n1 = 0; it1.hasNext(); n1++) { > Integer e1 = it1.next(); > Iterator it2 = set.iterator(); > for (int n2 = 0; n2 < n1; n2++) { > Integer e2 = it2.next(); > System.out.println(e1 + " <-> " + e2); > } > } > > > Regards, Peter > > > On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: >> Hello! >> >> As your keys are comparable, you can create normal iterators and >> filter the results like this: >> >> for(String v1 : s) { >> for(String v2 : s) { >> if(v1.compareTo(v2) < 0) { >> System.out.println(v1 + " <-->" + v2); >> } >> } >> } >> >> Or using Stream API: >> >> s.stream().flatMap(v1 -> s.stream() >> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) >> .forEach(System.out::println); >> >> With best regards, >> Tagir Valeev. >> >> >> DB> It would be nice to be able to associate each element in a collection >> DB> with another element in the collection, which is something very easily >> DB> done with index based collections, but with sets, etc this isn't so >> DB> easy... unless i'm having a brainfart. >> >> DB> So i'd like to do this, but Iterator doesn't implement Cloneable... Any >> DB> reason not to? or is there another way that's missing me? >> >> DB> public class ItClone { >> >> DB> public static void main(String[] args) { >> DB> Set s = Collections.newSetFromMap(new >> DB> ConcurrentHashMap()); >> >> DB> s.add("Fee"); >> DB> s.add("Fi"); >> DB> s.add("Fo"); >> DB> s.add("Fum"); >> >> DB> Iterator it1 = s.iterator(); >> DB> while (it1.hasNext()) { >> DB> String v1 = it1.next(); >> >> DB> Iterator it2 = (Iterator) it1.*clone*(); >> DB> while (it2.hasNext()) { >> DB> String v2 = it2.next(); >> >> DB> System.out.println(v1 + " <-->" + v2); >> DB> } >> DB> } >> DB> } >> DB> } >> > > > From frank.yuan at oracle.com Mon Sep 12 09:54:56 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Mon, 12 Sep 2016 17:54:56 +0800 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore Message-ID: <022d01d20cdb$b8c2f000$2a48d000$@oracle.com> Hi Would you like to review http://cr.openjdk.java.net/~fyuan/8087303/webrev.01/? Bug: https://bugs.openjdk.java.net/browse/JDK-8087303 In this patch, I add handling for whitespace text node and support for xml:space attribute in xml serializer. Thanks, Frank From shade at redhat.com Mon Sep 12 10:22:31 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 12 Sep 2016 13:22:31 +0300 Subject: RFR: jsr166 jdk9 integration wave 10 In-Reply-To: References: Message-ID: On 09/10/2016 08:21 PM, Martin Buchholz wrote: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > Mostly docs and tests. Looks good. Very nice use of (frequently overlooked) local classes in examples. Minor things: CountedCompleter.java: 176 * setPendingCount(1); // not off by one ! is better spelled like this? 176 * setPendingCount(1); // only one pending, not two! SubmissionTest.java: + static long millisElapsedSince(long startTime) { + return (System.nanoTime() - startTime) / (1000L * 1000L); + } ... + if (millisElapsedSince(startTime) >= LONG_DELAY_MS) { I hate these unit conversions sprinkled everywhere. Can it be like this? if (TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime) >= LONG_DELAY_MS) Thanks, -Aleksey From shade at redhat.com Mon Sep 12 10:45:28 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 12 Sep 2016 13:45:28 +0300 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore In-Reply-To: <022d01d20cdb$b8c2f000$2a48d000$@oracle.com> References: <022d01d20cdb$b8c2f000$2a48d000$@oracle.com> Message-ID: <2f183b9a-9e1c-79ab-daf6-64dd3ef7e957@redhat.com> On 09/12/2016 12:54 PM, Frank Yuan wrote: > Would you like to review http://cr.openjdk.java.net/~fyuan/8087303/webrev.01/? Not an expert in the XML parsing area, so only a cursory code review: ToStream.java: *) Bad camel casing: 113 protected boolean m_ispreserveSpace = false; *) shouldHandleText(chars, start, length) predicates within a method can be computed once at the beginning? *) I wonder if you want to check "length() > 0" before doing delete in clearPendingWhiteSpaceText() which is frequently called *) "this." inconsistency here: 3240 this.m_preserves.clear(); 3241 m_ispreserveSpace = false; 3242 m_preserveSpaces.clear(); Thanks, -Aleksey From sundararajan.athijegannathan at oracle.com Mon Sep 12 12:32:26 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Sep 2016 18:02:26 +0530 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8165772 This VersionCheck.java test failed after main class was added to nashorn modules. VersionCheck expects all jdk/bin tools to be derived from the standard launcher. But, jlink generates shell scripts and batch files for modules with main class. I'm reverting back nashorn module main class addition makefile change and also removing VersionCheck from ProblemList.txt: Webrevs: Top: http://cr.openjdk.java.net/~sundar/8165772/top/webrev.02/ Jdk: http://cr.openjdk.java.net/~sundar/8165772/jdk/webrev.02/ I'm withdrawing my earlier jlink fix attempt: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009339.html Thanks, -Sundar From Alan.Bateman at oracle.com Mon Sep 12 12:37:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Sep 2016 13:37:33 +0100 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java In-Reply-To: References: Message-ID: <626952e4-3810-251d-8de1-a0fcadb7759d@oracle.com> On 12/09/2016 13:32, Sundararajan Athijegannathan wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8165772 > > This VersionCheck.java test failed after main class was added to nashorn > modules. VersionCheck expects all jdk/bin tools to be derived from the > standard launcher. But, jlink generates shell scripts and batch files > for modules with main class. I'm reverting back nashorn module main > class addition makefile change and also removing VersionCheck from > ProblemList.txt: > > Webrevs: > > Top: http://cr.openjdk.java.net/~sundar/8165772/top/webrev.02/ > > Jdk: http://cr.openjdk.java.net/~sundar/8165772/jdk/webrev.02/ > > I'm withdrawing my earlier jlink fix attempt: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009339.html > Looks okay (and I agree that dropping this is the right thing to do as jlink generating launcher scripts is just isn't aligned with modules that include pre-built launchers). -Alan From james.laskey at oracle.com Mon Sep 12 12:44:12 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 12 Sep 2016 09:44:12 -0300 Subject: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java In-Reply-To: References: Message-ID: <83DDDF18-D3D5-438B-A196-705EEDA65380@oracle.com> +1 > On Sep 12, 2016, at 9:32 AM, Sundararajan Athijegannathan wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165772 > > This VersionCheck.java test failed after main class was added to nashorn > modules. VersionCheck expects all jdk/bin tools to be derived from the > standard launcher. But, jlink generates shell scripts and batch files > for modules with main class. I'm reverting back nashorn module main > class addition makefile change and also removing VersionCheck from > ProblemList.txt: > > Webrevs: > > Top: http://cr.openjdk.java.net/~sundar/8165772/top/webrev.02/ > > Jdk: http://cr.openjdk.java.net/~sundar/8165772/jdk/webrev.02/ > > I'm withdrawing my earlier jlink fix attempt: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009339.html > > Thanks, > > -Sundar > From timo.kinnunen at gmail.com Mon Sep 12 12:57:21 2016 From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com) Date: Mon, 12 Sep 2016 14:57:21 +0200 Subject: Make iterators cloneable? In-Reply-To: References: <6e4d788c-e65a-843b-5856-9d7cc007883a@oracle.com> <1731236.20160911190212@gmail.com> <7c0777df-b867-2338-6108-c8cdb05caf68@gmail.com> Message-ID: <57d6a633.0575c20a.8f0a7.d397@mx.google.com> No, It breaks on Fi (or Fum) in the inner loop before it gets the chance to output Fi-Fum (or Fum-Fi) if Fi (respectively Fum) comes first in iteration order. -- Have a nice day, Timo Sent from Mail for Windows 10 From: Dave Brosius From matcdac at gmail.com Mon Sep 12 12:59:39 2016 From: matcdac at gmail.com (Prakhar Makhija) Date: Mon, 12 Sep 2016 18:29:39 +0530 Subject: Discussion core-libs-dev Digest, Vol 113, Issue 35 In-Reply-To: References: Message-ID: Could we update the Iterator, so it supports manipulation on the Collection itself, and not throw UnsupportedOperationException during the time of iteration? On Sep 12, 2016 9:29 AM, wrote: Send core-libs-dev mailing list submissions to core-libs-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev or, via email, send a message with subject or body 'help' to core-libs-dev-request at openjdk.java.net You can reach the person managing the list at core-libs-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of core-libs-dev digest..." Today's Topics: 1. Re: Make iterators cloneable? (Peter Levart) 2. Re: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK (David Holmes) 3. Re: Make iterators cloneable? (Tagir Valeev) 4. Re: Make iterators cloneable? (Tagir Valeev) 5. JDK 9 RFR of JDK-8165818: Remove tools/pack200/Pack200Props.java from ProblemList (Amy Lu) 6. Re: JDK 9 RFR of JDK-8165818: Remove tools/pack200/Pack200Props.java from ProblemList (Amy Lu) ---------------------------------------------------------------------- Message: 1 Date: Sun, 11 Sep 2016 23:42:29 +0200 From: Peter Levart To: Dave Brosius , "Tagir F. Valeev" , core-libs-dev at openjdk.java.net Subject: Re: Make iterators cloneable? Message-ID: <06efbb04-e97b-18b7-a1fe-5fa010811fdc at gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed I would say the algorithm is O(n), when you take n to be the number of emitted pairs, wouldn't you ;-) You wanted an algorithm that emits n*(n-1) / 2 distinct pairs of elements from a set of n elements, didn't you? Regards, Peter On 09/11/2016 06:55 PM, Dave Brosius wrote: > Sure, but both of those algorithms are n^2, which is a bit painful, > especially given all the pointer chasing that occurs with iterators. > > > On 09/11/2016 08:20 AM, Peter Levart wrote: >> Hi, >> >> Even if the elements are not comparable, you could rely on the fact >> that Collection(s) usually create iterators with stable iteration >> order, so you could do the following: >> >> >> Set set = Set.of(1, 2, 3, 4); >> >> Iterator it1 = set.iterator(); >> for (int n1 = 0; it1.hasNext(); n1++) { >> Integer e1 = it1.next(); >> Iterator it2 = set.iterator(); >> for (int n2 = 0; n2 < n1; n2++) { >> Integer e2 = it2.next(); >> System.out.println(e1 + " <-> " + e2); >> } >> } >> >> >> Regards, Peter >> >> On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: >>> Hello! >>> >>> As your keys are comparable, you can create normal iterators and >>> filter the results like this: >>> >>> for(String v1 : s) { >>> for(String v2 : s) { >>> if(v1.compareTo(v2) < 0) { >>> System.out.println(v1 + " <-->" + v2); >>> } >>> } >>> } >>> >>> Or using Stream API: >>> >>> s.stream().flatMap(v1 -> s.stream() >>> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) >>> .forEach(System.out::println); >>> >>> With best regards, >>> Tagir Valeev. >>> >>> >>> DB> It would be nice to be able to associate each element in a >>> collection >>> DB> with another element in the collection, which is something very >>> easily >>> DB> done with index based collections, but with sets, etc this isn't so >>> DB> easy... unless i'm having a brainfart. >>> >>> DB> So i'd like to do this, but Iterator doesn't implement >>> Cloneable... Any >>> DB> reason not to? or is there another way that's missing me? >>> >>> DB> public class ItClone { >>> >>> DB> public static void main(String[] args) { >>> DB> Set s = Collections.newSetFromMap(new >>> DB> ConcurrentHashMap()); >>> >>> DB> s.add("Fee"); >>> DB> s.add("Fi"); >>> DB> s.add("Fo"); >>> DB> s.add("Fum"); >>> >>> DB> Iterator it1 = s.iterator(); >>> DB> while (it1.hasNext()) { >>> DB> String v1 = it1.next(); >>> >>> DB> Iterator it2 = (Iterator) >>> it1.*clone*(); >>> DB> while (it2.hasNext()) { >>> DB> String v2 = it2.next(); >>> >>> DB> System.out.println(v1 + " <-->" + v2); >>> DB> } >>> DB> } >>> DB> } >>> DB> } >>> >> > ------------------------------ Message: 2 Date: Mon, 12 Sep 2016 10:50:49 +1000 From: David Holmes To: Jonathan Bluett-Duncan , core-libs-dev at openjdk.java.net Subject: Re: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK Message-ID: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0 at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Hi Jonathon, Attachments get stripped from most of the mailing lists so you will need to find someone to host these for you on cr.openjdk.java.net. That aside you may be hard pressed to find anyone who can look at this future work now, given where things are with the JDK 9 release schedule. Cheers, David On 11/09/2016 9:42 AM, Jonathan Bluett-Duncan wrote: > Hi all, > > Would you kindly review this patch to replace existing uses of > Collections.unmodifiable*(*Arrays.asList(*)) and plain Arrays.asList(*) > with (List|Set|Map).of(*). You may find the patch files in the attachments. > > My rationale for replacing uses of Collections.unmodifiable*... with > (List|Set|Map).of is to make use of the memory savings allowed by the newer > APIs. > > The general rationale for replacing the Arrays.asList calls I've touched is > to again make use of memory savings, but this may be naive or misguided > reasoning on my part, as Arrays.asList may or may not be more > memory-efficient than List.of. However, where I've replaced Arrays.asList > for List.of in FileTreeIterator, my reasoning for doing so instead was to > help prevent TOCTOU attacks, but again this may be misguided on my part. > > It doesn't seem practical to me to include new unit tests, as these are > mainly performance improvements, but if it's believed that new unit tests > are needed, then I'd be happy to go back and try to include some. > > Kind regards, > Jonathan > ------------------------------ Message: 3 Date: Mon, 12 Sep 2016 07:51:59 +0700 From: Tagir Valeev To: Peter Levart Cc: core-libs-dev Subject: Re: Make iterators cloneable? Message-ID: Content-Type: text/plain; charset=UTF-8 Hello, Peter! I thought about numbering, but original Dave's code involved concurrent set, so I presume that it's expected to be modified from other threads. In this case my algorithm would output some legal pairs (probably reflecting changes or not or reflecting only partially) while your algorithm can output garbage (pair with equal e1, e2 or two pairs like e1 <-> e2, e2 <-> e1 or can even die with NoSuchElementException). Not sure what is better in author's case. Tagir. On Sun, Sep 11, 2016 at 7:20 PM, Peter Levart wrote: > Hi, > > Even if the elements are not comparable, you could rely on the fact that > Collection(s) usually create iterators with stable iteration order, so you > could do the following: > > > Set set = Set.of(1, 2, 3, 4); > > Iterator it1 = set.iterator(); > for (int n1 = 0; it1.hasNext(); n1++) { > Integer e1 = it1.next(); > Iterator it2 = set.iterator(); > for (int n2 = 0; n2 < n1; n2++) { > Integer e2 = it2.next(); > System.out.println(e1 + " <-> " + e2); > } > } > > > Regards, Peter > > > On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: > > Hello! > > As your keys are comparable, you can create normal iterators and > filter the results like this: > > for(String v1 : s) { > for(String v2 : s) { > if(v1.compareTo(v2) < 0) { > System.out.println(v1 + " <-->" + v2); > } > } > } > > Or using Stream API: > > s.stream().flatMap(v1 -> s.stream() > .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) > .forEach(System.out::println); > > With best regards, > Tagir Valeev. > > > DB> It would be nice to be able to associate each element in a collection > DB> with another element in the collection, which is something very easily > DB> done with index based collections, but with sets, etc this isn't so > DB> easy... unless i'm having a brainfart. > > DB> So i'd like to do this, but Iterator doesn't implement Cloneable... Any > DB> reason not to? or is there another way that's missing me? > > DB> public class ItClone { > > DB> public static void main(String[] args) { > DB> Set s = Collections.newSetFromMap(new > DB> ConcurrentHashMap()); > > DB> s.add("Fee"); > DB> s.add("Fi"); > DB> s.add("Fo"); > DB> s.add("Fum"); > > DB> Iterator it1 = s.iterator(); > DB> while (it1.hasNext()) { > DB> String v1 = it1.next(); > > DB> Iterator it2 = (Iterator) it1.*clone*(); > DB> while (it2.hasNext()) { > DB> String v2 = it2.next(); > > DB> System.out.println(v1 + " <-->" + v2); > DB> } > DB> } > DB> } > DB> } > > > > ------------------------------ Message: 4 Date: Mon, 12 Sep 2016 07:58:27 +0700 From: Tagir Valeev To: Peter Levart Cc: core-libs-dev Subject: Re: Make iterators cloneable? Message-ID: Content-Type: text/plain; charset=UTF-8 Actually given the fact that we're iterating the Set (so the elements are unique) and using the assumption that iteration of the same set is stable, you can avoid numbering like this: for(String e1 : set) { for(String e2 : set) { if(e1 == e2) break; System.out.println(e1+" <-> "+e2); } } Again, such algorithm is fragile to concurrent changes. With best regards, Tagir Valeev. On Mon, Sep 12, 2016 at 7:51 AM, Tagir Valeev wrote: > Hello, Peter! > > I thought about numbering, but original Dave's code involved concurrent > set, so I presume that it's expected to be modified from other threads. In > this case my algorithm would output some legal pairs (probably reflecting > changes or not or reflecting only partially) while your algorithm can > output garbage (pair with equal e1, e2 or two pairs like e1 <-> e2, e2 <-> > e1 or can even die with NoSuchElementException). Not sure what is better in > author's case. > > Tagir. > > On Sun, Sep 11, 2016 at 7:20 PM, Peter Levart > wrote: > >> Hi, >> >> Even if the elements are not comparable, you could rely on the fact that >> Collection(s) usually create iterators with stable iteration order, so you >> could do the following: >> >> >> Set set = Set.of(1, 2, 3, 4); >> >> Iterator it1 = set.iterator(); >> for (int n1 = 0; it1.hasNext(); n1++) { >> Integer e1 = it1.next(); >> Iterator it2 = set.iterator(); >> for (int n2 = 0; n2 < n1; n2++) { >> Integer e2 = it2.next(); >> System.out.println(e1 + " <-> " + e2); >> } >> } >> >> >> Regards, Peter >> >> >> On 09/11/2016 02:02 PM, Tagir F. Valeev wrote: >> >> Hello! >> >> As your keys are comparable, you can create normal iterators and >> filter the results like this: >> >> for(String v1 : s) { >> for(String v2 : s) { >> if(v1.compareTo(v2) < 0) { >> System.out.println(v1 + " <-->" + v2); >> } >> } >> } >> >> Or using Stream API: >> >> s.stream().flatMap(v1 -> s.stream() >> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2)) >> .forEach(System.out::println); >> >> With best regards, >> Tagir Valeev. >> >> >> DB> It would be nice to be able to associate each element in a collection >> DB> with another element in the collection, which is something very easily >> DB> done with index based collections, but with sets, etc this isn't so >> DB> easy... unless i'm having a brainfart. >> >> DB> So i'd like to do this, but Iterator doesn't implement Cloneable... Any >> DB> reason not to? or is there another way that's missing me? >> >> DB> public class ItClone { >> >> DB> public static void main(String[] args) { >> DB> Set s = Collections.newSetFromMap(new >> DB> ConcurrentHashMap()); >> >> DB> s.add("Fee"); >> DB> s.add("Fi"); >> DB> s.add("Fo"); >> DB> s.add("Fum"); >> >> DB> Iterator it1 = s.iterator(); >> DB> while (it1.hasNext()) { >> DB> String v1 = it1.next(); >> >> DB> Iterator it2 = (Iterator) it1.*clone*(); >> DB> while (it2.hasNext()) { >> DB> String v2 = it2.next(); >> >> DB> System.out.println(v1 + " <-->" + v2); >> DB> } >> DB> } >> DB> } >> DB> } >> >> >> >> > ------------------------------ Message: 5 Date: Mon, 12 Sep 2016 11:38:32 +0800 From: Amy Lu To: Core-Libs-Dev , Kumar Srinivasan Subject: JDK 9 RFR of JDK-8165818: Remove tools/pack200/Pack200Props.java from ProblemList Message-ID: <7498b951-367f-29e6-319f-f91ab2c2336d at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed tools/pack200/Pack200Props.java This test was put into ProblemList.txt in 9/117 due to test timed out issue: JDK-8155857. Test failure (timed out) is reproducible with 9/117 and 9/118, but issue gone in 9/119 and *not* reproducible anymore since 9/119. Issue must has been resolved with other fixes. Tested with the very latest build on all platforms, test pass. Standalone run test in loop for 500 times, test all pass. As issue does not exist anymore, test could be removed from ProblemList.txt bug: https://bugs.openjdk.java.net/browse/JDK-8165818 Thanks, Amy --- old/test/ProblemList.txt 2016-09-12 11:28:05.000000000 +0800 +++ new/test/ProblemList.txt 2016-09-12 11:28:05.000000000 +0800 @@ -1,4 +1,4 @@ -########################################################################### +e########################################################################## # # Copyright (c) 2009, 2016, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. @@ -312,8 +312,6 @@ tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all -tools/pack200/Pack200Props.java 8155857 generic-all - tools/launcher/VersionCheck.java 8165772 generic-all ############################################################ ################ ------------------------------ Message: 6 Date: Mon, 12 Sep 2016 11:58:33 +0800 From: Amy Lu To: Core-Libs-Dev , Kumar Srinivasan Subject: Re: JDK 9 RFR of JDK-8165818: Remove tools/pack200/Pack200Props.java from ProblemList Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed On 9/12/16 11:38 AM, Amy Lu wrote: > tools/pack200/Pack200Props.java > > This test was put into ProblemList.txt in 9/117 due to test timed out > issue: JDK-8155857. > > Test failure (timed out) is reproducible with 9/117 and 9/118, but > issue gone in 9/119 and *not* reproducible anymore since 9/119. Issue > must has been resolved with other fixes. > > Tested with the very latest build on all platforms, test pass. > Standalone run test in loop for 500 times, test all pass. > > As issue does not exist anymore, test could be removed from > ProblemList.txt > > bug: https://bugs.openjdk.java.net/browse/JDK-8165818 > > Thanks, > Amy > Sorry, the patch: http://cr.openjdk.java.net/~amlu/8165818/webrev.00/ --- old/test/ProblemList.txt 2016-09-12 11:55:51.000000000 +0800 +++ new/test/ProblemList.txt 2016-09-12 11:55:51.000000000 +0800 @@ -312,8 +312,6 @@ tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all -tools/pack200/Pack200Props.java 8155857 generic-all - tools/launcher/VersionCheck.java 8165772 generic-all ############################################################ ################ End of core-libs-dev Digest, Vol 113, Issue 35 ********************************************** From Alan.Bateman at oracle.com Mon Sep 12 14:24:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Sep 2016 15:24:27 +0100 Subject: RFR: 8165723: JarFile::isMultiRelease() method returns false when it should return true In-Reply-To: <57D35AAC.3010502@oracle.com> References: <57D35AAC.3010502@oracle.com> Message-ID: On 10/09/2016 01:58, Claes Redestad wrote: > Hi, > > JDK-8152733 introduced a corner-case where isMultiRelease returns > false when it should return true due to an erroneously hand-crafted > Boyer-Moore search. > > Webrev: http://cr.openjdk.java.net/~redestad/8165723/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8165723 > > Testing: created a test reproducer using randomly constructed > manifests and verified the supplied jar is properly detected as being > multi-release. This looks okay. For the MultiReleaseJarAPI test then you probably should use jdk.testlibrary.RandomFactory so that the seed is recorded in the output for when the test fails. Also in CreateMultiReleaseTestJars then it might be cleaner to have a separate method to add extra stuff to the JAR file - I think that would make the usages a bit easier to read. -Alan From claes.redestad at oracle.com Mon Sep 12 15:10:15 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 12 Sep 2016 17:10:15 +0200 Subject: RFR: 8165723: JarFile::isMultiRelease() method returns false when it should return true In-Reply-To: References: <57D35AAC.3010502@oracle.com> Message-ID: <5ab0aebb-b1d4-d1c0-4232-6c320b1b1b07@oracle.com> On 2016-09-12 16:24, Alan Bateman wrote: > This looks okay. Thanks for the review! > For the MultiReleaseJarAPI test then you probably should use > jdk.testlibrary.RandomFactory so that the seed is recorded in the > output for when the test fails. Done. > Also in CreateMultiReleaseTestJars then it might be cleaner to have a > separate method to add extra stuff to the JAR file - I think that > would make the usages a bit easier to read. I took a second look, realized CreateMultiReleaseTestJars::buildShortMultiReleaseJar is no longer being used by any test, and simplified things a bit accordingly: http://cr.openjdk.java.net/~redestad/8165723/webrev.02/ Thanks! /Claes From kumar.x.srinivasan at oracle.com Mon Sep 12 15:38:47 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 12 Sep 2016 08:38:47 -0700 Subject: JDK 9 RFR of JDK-8165818: Remove tools/pack200/Pack200Props.java from ProblemList In-Reply-To: References: <7498b951-367f-29e6-319f-f91ab2c2336d@oracle.com> Message-ID: <57D6CC07.4020704@oracle.com> Looks good. Thanks for looking into this. Kumar > On 9/12/16 11:38 AM, Amy Lu wrote: >> tools/pack200/Pack200Props.java >> >> This test was put into ProblemList.txt in 9/117 due to test timed out >> issue: JDK-8155857. >> >> Test failure (timed out) is reproducible with 9/117 and 9/118, but >> issue gone in 9/119 and *not* reproducible anymore since 9/119. Issue >> must has been resolved with other fixes. >> >> Tested with the very latest build on all platforms, test pass. >> Standalone run test in loop for 500 times, test all pass. >> >> As issue does not exist anymore, test could be removed from >> ProblemList.txt >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8165818 >> >> Thanks, >> Amy >> > Sorry, the patch: http://cr.openjdk.java.net/~amlu/8165818/webrev.00/ > > --- old/test/ProblemList.txt 2016-09-12 11:55:51.000000000 +0800 > +++ new/test/ProblemList.txt 2016-09-12 11:55:51.000000000 +0800 > @@ -312,8 +312,6 @@ > > tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all > > -tools/pack200/Pack200Props.java 8155857 generic-all > - > tools/launcher/VersionCheck.java 8165772 generic-all > > ############################################################################ > > From paul.sandoz at oracle.com Mon Sep 12 16:15:29 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Sep 2016 09:15:29 -0700 Subject: RFR: jsr166 jdk9 integration wave 10 In-Reply-To: References: Message-ID: <360C809C-9AF8-4D7B-9D23-680BB903A043@oracle.com> > On 10 Sep 2016, at 10:21, Martin Buchholz wrote: > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > +1 CountedCompleter ? 176 * setPendingCount(1); // not off by one ! CountedCompleterTest ? 1910 setPendingCount(1); // not off by one ! I cannot resist saying you have an off by one (letter) error :-) > Mostly docs and tests. > > jsr166 CVS is now caught up with jdk9+135 > > Paul, I think we need to update AtomicInteger for VarHandle#getAndAdd: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java.udiff.html > > Oops, sorry about that, i missed ?em. Paul. From lance.andersen at oracle.com Mon Sep 12 16:29:05 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 12 Sep 2016 12:29:05 -0400 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded Message-ID: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> Happy Monday, This RFR is to add a test to validate that the DriverManager.println output is accessible when DriverManager is first loaded. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8159126/webrev.00/ Ran JPRT to sanity check across platforms Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.sandoz at oracle.com Mon Sep 12 16:57:35 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Sep 2016 09:57:35 -0700 Subject: RFR: 8165723: JarFile::isMultiRelease() method returns false when it should return true In-Reply-To: <5ab0aebb-b1d4-d1c0-4232-6c320b1b1b07@oracle.com> References: <57D35AAC.3010502@oracle.com> <5ab0aebb-b1d4-d1c0-4232-6c320b1b1b07@oracle.com> Message-ID: <3EE24EC3-71AB-460A-9FCC-62E9B4D4381B@oracle.com> > On 12 Sep 2016, at 08:10, Claes Redestad wrote: > > On 2016-09-12 16:24, Alan Bateman wrote: >> This looks okay. > > Thanks for the review! > >> For the MultiReleaseJarAPI test then you probably should use jdk.testlibrary.RandomFactory so that the seed is recorded in the output for when the test fails. > > Done. > >> Also in CreateMultiReleaseTestJars then it might be cleaner to have a separate method to add extra stuff to the JAR file - I think that would make the usages a bit easier to read. > > I took a second look, realized CreateMultiReleaseTestJars::buildShortMultiReleaseJar is no longer being used by any test, and simplified things a bit accordingly: > > http://cr.openjdk.java.net/~redestad/8165723/webrev.02/ > +1 (post review i see it is already committed). Our optimisation to compress the ?optoSft? data was premature, i guess we had an error in the initial data. Paul. From martinrb at google.com Mon Sep 12 16:57:40 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 12 Sep 2016 09:57:40 -0700 Subject: RFR: jsr166 jdk9 integration wave 10 In-Reply-To: References: Message-ID: On Mon, Sep 12, 2016 at 3:22 AM, Aleksey Shipilev wrote: > > Minor things: > > CountedCompleter.java: > > 176 * setPendingCount(1); // not off by one ! > > is better spelled like this? > > 176 * setPendingCount(1); // only one pending, not two! > I already struggled over the wording here .... hmmm ... how about // looks off by one, but correct! > > SubmissionTest.java: > > + static long millisElapsedSince(long startTime) { > + return (System.nanoTime() - startTime) / (1000L * 1000L); > + } > ... > + if (millisElapsedSince(startTime) >= LONG_DELAY_MS) { > > I hate these unit conversions sprinkled everywhere. Can it be like this? > > This is already used pervasively in the tck tests. Imagine that millisElapsedSince were moved to a utility class, like JSR166TestCase, but for jtreg tests. > if (TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime) >= > LONG_DELAY_MS) > I don't like the verbosity of that. Probably something closer to Guava's Stopwatch would be cleaner. http://google.github.io/guava/releases/19.0/api/docs/com/google/common/base/Stopwatch.html But that's a big TODO. From paul.sandoz at oracle.com Mon Sep 12 16:58:42 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Sep 2016 09:58:42 -0700 Subject: RFR: jsr166 jdk9 integration wave 10 In-Reply-To: References: Message-ID: <0098BEA9-8223-42BC-8CFB-E7DAA639C0CD@oracle.com> > On 12 Sep 2016, at 09:57, Martin Buchholz wrote: > > > > On Mon, Sep 12, 2016 at 3:22 AM, Aleksey Shipilev > wrote: > > Minor things: > > CountedCompleter.java: > > 176 * setPendingCount(1); // not off by one ! > > is better spelled like this? > > 176 * setPendingCount(1); // only one pending, not two! > > I already struggled over the wording here .... hmmm ... how about > > // looks off by one, but correct! > Ok, with me. Paul. From paul.sandoz at oracle.com Mon Sep 12 17:05:02 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Sep 2016 10:05:02 -0700 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded In-Reply-To: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> Message-ID: > On 12 Sep 2016, at 09:29, Lance Andersen wrote: > > Happy Monday, > > This RFR is to add a test to validate that the DriverManager.println output is accessible when DriverManager is first loaded. > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8159126/webrev.00/ > > > Ran JPRT to sanity check across platforms > Suggestion: 70 try (BufferedReader reader = new BufferedReader(new CharArrayReader(cw.toCharArray()))) { 71 boolean result 72 = reader.lines().anyMatch( 73 line -> line.matches(".*JDBC DriverManager initialized.*")); 74 assertFalse(result); Change anyMatch, to noneMatch, and assertTrue (note if the stream is empty none is ?vacuously? satisfied and will return true). Paul. > > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From daniel.fuchs at oracle.com Mon Sep 12 17:15:18 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 12 Sep 2016 18:15:18 +0100 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> Message-ID: <1ebf6da4-70df-93d7-2035-a0423bf55356@oracle.com> Hi Roger, ObjectInputStream.java: some cosmetic comments: 317 * {@link ObjectInputFilter.Config#getSerialFilter() the process-wide filter}. 352 * {@link ObjectInputFilter.Config#getSerialFilter() the process-wide filter}. => should be @linkplain 1185 * The filter, when not {@code null}, is invoked during {@linkplain #readObject()} 1186 * and {@linkplain #readUnshared readUnshared} for each object (+ also at lines 1207,1208,1211,1212, Should that be @link? I saw that in other places, readObject and readUnshared were not wrapped in {@code } - so for consistency it might make sense to use @linkplain. However the usual idiom would be to use {@link }. 2046 // Filter the replacement object 2047 if (rep != null) { 2048 if (rep.getClass().isArray()) { 2049 filterCheck(rep.getClass(), Array.getLength(rep)); 2050 } else { 2051 filterCheck(rep.getClass(), -1); 2052 } 2053 } In this case should the filter be also invoked with the class of each element in the substituted array? Or is it OK that only the array type is checked (could be "[Ljava.lang.Object;" containing elements of classes X, Y, Z, but the filter will only see the array type). best regards, -- daniel On 08/09/16 20:09, Roger Riggs wrote: > Please review updates to the Serialization filtering API and > implementation: > - The ObjectInputFilter pattern based filters support matching on > module names as well as package and class names. > - Rename of system property and java.security property for > configurable filters. (jdk.serialFilter) > - ObjectInputFilter clarifications about the values passed to the filter > - Javadoc editorial improvements > - Clarification of SerializablePermission description of targets > > - More tests > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ > > SpecDiff: > http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html > > Javadoc (subset) > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html > > > Thanks, Roger > > > From lance.andersen at oracle.com Mon Sep 12 17:15:25 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 12 Sep 2016 13:15:25 -0400 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded In-Reply-To: References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> Message-ID: > On Sep 12, 2016, at 1:05 PM, Paul Sandoz wrote: > >> >> On 12 Sep 2016, at 09:29, Lance Andersen wrote: >> >> Happy Monday, >> >> This RFR is to add a test to validate that the DriverManager.println output is accessible when DriverManager is first loaded. >> >> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8159126/webrev.00/ >> >> >> Ran JPRT to sanity check across platforms >> > > Suggestion: > > 70 try (BufferedReader reader = new BufferedReader(new CharArrayReader(cw.toCharArray()))) { > 71 boolean result > 72 = reader.lines().anyMatch( > 73 line -> line.matches(".*JDBC DriverManager initialized.*")); > 74 assertFalse(result); > > > Change anyMatch, to noneMatch, and assertTrue (note if the stream is empty none is ?vacuously? satisfied and will return true). Thank you Paul. I can make that change, was not sure (if one was faster than the other) Best Lance > > Paul. > >> >> >> Best >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Mon Sep 12 17:17:36 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 12 Sep 2016 10:17:36 -0700 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded In-Reply-To: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> Message-ID: <57D6E330.6020703@oracle.com> Hi Lance, Since this change adds a test only, I assume the issue was fixed in another bug, it would be good to add a link in JBS. It seems the initialization log has changed, no longer prints the first 2 lines. It might be worth it to add a note/comment in the JBS along with link to the original change. Best, Joe On 9/12/16, 9:29 AM, Lance Andersen wrote: > Happy Monday, > > This RFR is to add a test to validate that the DriverManager.println output is accessible when DriverManager is first loaded. > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8159126/webrev.00/ > > > Ran JPRT to sanity check across platforms > > > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Mon Sep 12 17:21:39 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 12 Sep 2016 13:21:39 -0400 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded In-Reply-To: <57D6E330.6020703@oracle.com> References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> <57D6E330.6020703@oracle.com> Message-ID: <3CEDA273-4B49-4DD8-8B06-1AF2683D5460@oracle.com> Hi Joe, > On Sep 12, 2016, at 1:17 PM, Joe Wang wrote: > > Hi Lance, > > Since this change adds a test only, I assume the issue was fixed in another bug, it would be good to add a link in JBS. Yes I had planned to do that > > It seems the initialization log has changed, no longer prints the first 2 lines. Not sure what you mean, the output can/will vary based on the drivers that are available at init time. The only output guaranteed is what the test validates and that is not required by the spec, it is just available debug trace. > It might be worth it to add a note/comment in the JBS along with link to the original change. Best Lance > > Best, > Joe > > On 9/12/16, 9:29 AM, Lance Andersen wrote: >> Happy Monday, >> >> This RFR is to add a test to validate that the DriverManager.println output is accessible when DriverManager is first loaded. >> >> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8159126/webrev.00/ >> >> >> Ran JPRT to sanity check across platforms >> >> >> >> Best >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Mon Sep 12 17:37:56 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 12 Sep 2016 10:37:56 -0700 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore In-Reply-To: <022d01d20cdb$b8c2f000$2a48d000$@oracle.com> References: <022d01d20cdb$b8c2f000$2a48d000$@oracle.com> Message-ID: <57D6E7F4.6050902@oracle.com> Hi Frank, I was thinking we could just fix the current issue. Then in order to be consistent among different processors, we made wider changes. As you said, we're not backward-compatible anymore. That, and plus xml:space, it looks like a CCC can not be avoided. If that's what we have to do, we might consider indent mixed content as well. Cheers, Joe On 9/12/16, 2:54 AM, Frank Yuan wrote: > Hi > > > > Would you like to review http://cr.openjdk.java.net/~fyuan/8087303/webrev.01/? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087303 > > > > In this patch, I add handling for whitespace text node and support for xml:space attribute in xml serializer. > > > > > > Thanks, > > > > Frank > > > From paul.sandoz at oracle.com Mon Sep 12 17:55:33 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Sep 2016 10:55:33 -0700 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded In-Reply-To: References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> Message-ID: <44B41B96-0784-4264-8ECF-7D4631956793@oracle.com> > On 12 Sep 2016, at 10:15, Lance Andersen wrote: >> >> Suggestion: >> >> 70 try (BufferedReader reader = new BufferedReader(new CharArrayReader(cw.toCharArray()))) { >> 71 boolean result >> 72 = reader.lines().anyMatch( >> 73 line -> line.matches(".*JDBC DriverManager initialized.*")); >> 74 assertFalse(result); >> >> >> Change anyMatch, to noneMatch, and assertTrue (note if the stream is empty none is ?vacuously? satisfied and will return true). > > Thank you Paul. I can make that change, was not sure (if one was faster than the other) > Both will short-circuiting when the predicate returns true, speed-wise it should not be an issue. Arguably, noneMatch better expresses the intent of that is being tested. Paul. From claes.redestad at oracle.com Mon Sep 12 18:07:50 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 12 Sep 2016 20:07:50 +0200 Subject: RFR: 8165890: [TESTBUG] Compilation issue in MultiReleaseJarTest after 8165723 Message-ID: <57D6EEF6.3080705@oracle.com> Hi, bug: https://bugs.openjdk.java.net/browse/JDK-8165890 webrev: http://cr.openjdk.java.net/~redestad/8165890/webrev.01/ Thanks (sorry)! /Claes From joe.darcy at oracle.com Mon Sep 12 18:10:37 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 12 Sep 2016 11:10:37 -0700 Subject: RFR: 8165890: [TESTBUG] Compilation issue in MultiReleaseJarTest after 8165723 In-Reply-To: <57D6EEF6.3080705@oracle.com> References: <57D6EEF6.3080705@oracle.com> Message-ID: <4ddba380-009a-138a-bf00-d8f119e36103@oracle.com> Approved; cheers, -Joe On 9/12/2016 11:07 AM, Claes Redestad wrote: > Hi, > > bug: https://bugs.openjdk.java.net/browse/JDK-8165890 > webrev: http://cr.openjdk.java.net/~redestad/8165890/webrev.01/ > > Thanks (sorry)! > > /Claes From shade at redhat.com Mon Sep 12 18:12:02 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 12 Sep 2016 21:12:02 +0300 Subject: RFR: jsr166 jdk9 integration wave 10 In-Reply-To: References: Message-ID: On 09/12/2016 07:57 PM, Martin Buchholz wrote: > is better spelled like this? > > 176 * setPendingCount(1); // only one pending, not two! > > I already struggled over the wording here .... hmmm ... how about > > // looks off by one, but correct! Yes, this is better. > I don't like the verbosity of that. Probably something closer to > Guava's Stopwatch would be cleaner. ... But that's a big TODO. Ok, fine. Thanks, -Aleksey From claes.redestad at oracle.com Mon Sep 12 18:12:51 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 12 Sep 2016 20:12:51 +0200 Subject: RFR: 8165890: [TESTBUG] Compilation issue in MultiReleaseJarTest after 8165723 In-Reply-To: <4ddba380-009a-138a-bf00-d8f119e36103@oracle.com> References: <57D6EEF6.3080705@oracle.com> <4ddba380-009a-138a-bf00-d8f119e36103@oracle.com> Message-ID: <57D6F023.6090803@oracle.com> Thanks for the quick review, Joe! Pushed. /Claes On 2016-09-12 20:10, joe darcy wrote: > Approved; cheers, > > -Joe > > > On 9/12/2016 11:07 AM, Claes Redestad wrote: >> Hi, >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8165890 >> webrev: http://cr.openjdk.java.net/~redestad/8165890/webrev.01/ >> >> Thanks (sorry)! >> >> /Claes > From brian.burkhalter at oracle.com Mon Sep 12 18:13:06 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 12 Sep 2016 11:13:06 -0700 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: Only picky comments: not sure but maybe change: 1) vice versa -> and vice versa 2) When it?s set to true -> When true 3) just like before -> as before Brian On Sep 12, 2016, at 12:23 AM, Weijun Wang wrote: > BTW, please also review the release note at > > https://bugs.openjdk.java.net/browse/JDK-8165836 > > Thanks > Max From huizhe.wang at oracle.com Mon Sep 12 18:20:08 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 12 Sep 2016 11:20:08 -0700 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded In-Reply-To: <3CEDA273-4B49-4DD8-8B06-1AF2683D5460@oracle.com> References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> <57D6E330.6020703@oracle.com> <3CEDA273-4B49-4DD8-8B06-1AF2683D5460@oracle.com> Message-ID: <57D6F1D8.3060506@oracle.com> On 9/12/16, 10:21 AM, Lance Andersen wrote: > Hi Joe, >> On Sep 12, 2016, at 1:17 PM, Joe Wang > > wrote: >> >> Hi Lance, >> >> Since this change adds a test only, I assume the issue was fixed in >> another bug, it would be good to add a link in JBS. > Yes I had planned to do that Sounds good. >> >> It seems the initialization log has changed, no longer prints the >> first 2 lines. > Not sure what you mean, the output can/will vary based on the drivers > that are available at init time. The only output guaranteed is what > the test validates and that is not required by the spec, it is just > available debug trace. The report said (in "EXPECTED") that at initialization in 6u45, sun.jdbc.odbc.JdbcOdbcDriver is loaded. The spec stated that at initialization, it will load any drivers through the service mechanism or system property, but it seems it didn't say whether it'd load the default if all others are not found. Is that a change? I ran the test, with 6u45, the returned drivers contain sun.jdbc.odbc.JdbcOdbcDriver, and with current build, it didn't. If it's changed, is it worth it to note in the test and comment in JBS? Best, Joe > >> It might be worth it to add a note/comment in the JBS along with link >> to the original change. > > Best > Lance >> >> Best, >> Joe >> >> On 9/12/16, 9:29 AM, Lance Andersen wrote: >>> Happy Monday, >>> >>> This RFR is to add a test to validate that the DriverManager.println >>> output is accessible when DriverManager is first loaded. >>> >>> The webrev can be found at: >>> http://cr.openjdk.java.net/~lancea/8159126/webrev.00/ >>> >>> >>> >>> Ran JPRT to sanity check across platforms >>> >>> >>> >>> Best >>> Lance >>> >>> >>> >>> Lance >>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >>> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Mon Sep 12 18:24:32 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 12 Sep 2016 14:24:32 -0400 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded In-Reply-To: <57D6F1D8.3060506@oracle.com> References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> <57D6E330.6020703@oracle.com> <3CEDA273-4B49-4DD8-8B06-1AF2683D5460@oracle.com> <57D6F1D8.3060506@oracle.com> Message-ID: > On Sep 12, 2016, at 2:20 PM, Joe Wang wrote: > > > > On 9/12/16, 10:21 AM, Lance Andersen wrote: >> >> Hi Joe, >>> On Sep 12, 2016, at 1:17 PM, Joe Wang > wrote: >>> >>> Hi Lance, >>> >>> Since this change adds a test only, I assume the issue was fixed in another bug, it would be good to add a link in JBS. >> Yes I had planned to do that > > Sounds good. >>> >>> It seems the initialization log has changed, no longer prints the first 2 lines. >> Not sure what you mean, the output can/will vary based on the drivers that are available at init time. The only output guaranteed is what the test validates and that is not required by the spec, it is just available debug trace. > > The report said (in "EXPECTED") that at initialization in 6u45, sun.jdbc.odbc.JdbcOdbcDriver is loaded. Never believe what you read Joe :-) > The spec stated that at initialization, it will load any drivers through the service mechanism or system property, but it seems it didn't say whether it'd load the default if all others are not found. There is no such thing as a default JDBC driver > > Is that a change? I ran the test, with 6u45, the returned drivers contain sun.jdbc.odbc.JdbcOdbcDriver, and with current build, it didn't. If it's changed, is it worth it to note in the test and comment in JBS? That is the JDBC-ODBC driver which was never supported and we removed it from the JDK as it is not supported. It was never a requirement of Java SE or JDBC to be there. It predates type 4 JDBC drivers going back to 1996-1997 during the initial prototyping of JDBC (back to my Sybase days). > > Best, > Joe >> >>> It might be worth it to add a note/comment in the JBS along with link to the original change. >> >> Best >> Lance >>> >>> Best, >>> Joe >>> >>> On 9/12/16, 9:29 AM, Lance Andersen wrote: >>>> Happy Monday, >>>> >>>> This RFR is to add a test to validate that the DriverManager.println output is accessible when DriverManager is first loaded. >>>> >>>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8159126/webrev.00/ >>>> >>>> >>>> Ran JPRT to sanity check across platforms >>>> >>>> >>>> >>>> Best >>>> Lance >>>> > >>>> > > >>>> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com > >>>> >>>> >>>> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Mon Sep 12 18:35:51 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 12 Sep 2016 14:35:51 -0400 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded In-Reply-To: <44B41B96-0784-4264-8ECF-7D4631956793@oracle.com> References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> <44B41B96-0784-4264-8ECF-7D4631956793@oracle.com> Message-ID: <221BB2B8-A39A-4B19-854D-48FF832CFA5D@oracle.com> > On Sep 12, 2016, at 1:55 PM, Paul Sandoz wrote: > > >> On 12 Sep 2016, at 10:15, Lance Andersen > wrote: >>> >>> Suggestion: >>> >>> 70 try (BufferedReader reader = new BufferedReader(new CharArrayReader(cw.toCharArray()))) { >>> 71 boolean result >>> 72 = reader.lines().anyMatch( >>> 73 line -> line.matches(".*JDBC DriverManager initialized.*")); >>> 74 assertFalse(result); >>> >>> >>> Change anyMatch, to noneMatch, and assertTrue (note if the stream is empty none is ?vacuously? satisfied and will return true). >> >> Thank you Paul. I can make that change, was not sure (if one was faster than the other) >> > > Both will short-circuiting when the predicate returns true, speed-wise it should not be an issue. Okie dokie, thank you for the clarification > Arguably, noneMatch better expresses the intent of that is being tested. Fair point. Updated the webrev: http://cr.openjdk.java.net/~lancea/8159126/webrev.01/ Waiting for JPRT to also finish, clean run (as expected) on my Mac > > Paul. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jbluettduncan at gmail.com Mon Sep 12 18:36:33 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Mon, 12 Sep 2016 19:36:33 +0100 Subject: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> Message-ID: Hi David, Thanks for letting me know about the attachment stripping behaviour, and reminding me about the current state of the JDK 9 release schedule. Stuart, would you be happy to host my patch on cr.openjdk.java.net? If not, do you know who else might be happy to host it for me? Or alternatively, would you prefer I wait until development of Java 9 Updates and/or Java 10 starts? Kind regards, Jonathan On 12 September 2016 at 01:50, David Holmes wrote: > Hi Jonathon, > > Attachments get stripped from most of the mailing lists so you will need > to find someone to host these for you on cr.openjdk.java.net. > > That aside you may be hard pressed to find anyone who can look at this > future work now, given where things are with the JDK 9 release schedule. > > Cheers, > David > > > On 11/09/2016 9:42 AM, Jonathan Bluett-Duncan wrote: > >> Hi all, >> >> Would you kindly review this patch to replace existing uses of >> Collections.unmodifiable*(*Arrays.asList(*)) and plain Arrays.asList(*) >> with (List|Set|Map).of(*). You may find the patch files in the >> attachments. >> >> My rationale for replacing uses of Collections.unmodifiable*... with >> (List|Set|Map).of is to make use of the memory savings allowed by the >> newer >> APIs. >> >> The general rationale for replacing the Arrays.asList calls I've touched >> is >> to again make use of memory savings, but this may be naive or misguided >> reasoning on my part, as Arrays.asList may or may not be more >> memory-efficient than List.of. However, where I've replaced Arrays.asList >> for List.of in FileTreeIterator, my reasoning for doing so instead was to >> help prevent TOCTOU attacks, but again this may be misguided on my part. >> >> It doesn't seem practical to me to include new unit tests, as these are >> mainly performance improvements, but if it's believed that new unit tests >> are needed, then I'd be happy to go back and try to include some. >> >> Kind regards, >> Jonathan >> >> From paul.sandoz at oracle.com Mon Sep 12 18:37:04 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Sep 2016 11:37:04 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> Message-ID: > On 11 Sep 2016, at 13:12, Steve Drach wrote: > > I made a simple change, the new webrev is http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ > I don?t like the state interplay between allowedVersions and getBaseSuffix, and the filtering for null. Consider merging filter.map.filter into a single flatMap. Also can getJarEntry ever return null? Claes makes a good point regarding performance. I would suggest getting this functional and tested then tweaking for performance. Paul. >> On Sep 9, 2016, at 4:02 PM, Steve Drach wrote: >> >> Hi, >> >> Please review this changeset that adds a VersionedStream class to the jdk.internal.util.jar package. Some may recall that I submitted a similar RFR a few weeks ago; this is a redesign from that one. We decided not to make a public JarFile::versionedStream method at this time. Once we get sufficient experience with this and find a few more use cases, we will revisit the idea of making this a public method in JarFile. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8163798 >> webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.01/index.html >> >> Thanks, >> Steve > From huizhe.wang at oracle.com Mon Sep 12 18:47:59 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 12 Sep 2016 11:47:59 -0700 Subject: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded In-Reply-To: References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> <57D6E330.6020703@oracle.com> <3CEDA273-4B49-4DD8-8B06-1AF2683D5460@oracle.com> <57D6F1D8.3060506@oracle.com> Message-ID: <57D6F85F.8060707@oracle.com> I see. Thanks for explaining a "short" / 20-year history in a couple of sentences :-) -Joe On 9/12/16, 11:24 AM, Lance Andersen wrote: > >> On Sep 12, 2016, at 2:20 PM, Joe Wang > > wrote: >> >> >> >> On 9/12/16, 10:21 AM, Lance Andersen wrote: >>> Hi Joe, >>>> On Sep 12, 2016, at 1:17 PM, Joe Wang >>> > wrote: >>>> >>>> Hi Lance, >>>> >>>> Since this change adds a test only, I assume the issue was fixed in >>>> another bug, it would be good to add a link in JBS. >>> Yes I had planned to do that >> >> Sounds good. >>>> >>>> It seems the initialization log has changed, no longer prints the >>>> first 2 lines. >>> Not sure what you mean, the output can/will vary based on the >>> drivers that are available at init time. The only output guaranteed >>> is what the test validates and that is not required by the spec, it >>> is just available debug trace. >> >> The report said (in "EXPECTED") that at initialization in 6u45, >> sun.jdbc.odbc.JdbcOdbcDriver is loaded. > Never believe what you read Joe :-) > >> The spec stated that at initialization, it will load any drivers >> through the service mechanism or system property, but it seems it >> didn't say whether it'd load the default if all others are not found. > There is no such thing as a default JDBC driver >> >> Is that a change? I ran the test, with 6u45, the returned drivers >> contain sun.jdbc.odbc.JdbcOdbcDriver, and with current build, it >> didn't. If it's changed, is it worth it to note in the test and >> comment in JBS? > > That is the JDBC-ODBC driver which was never supported and we removed > it from the JDK as it is not supported. It was never a requirement of > Java SE or JDBC to be there. It predates type 4 JDBC drivers going > back to 1996-1997 during the initial prototyping of JDBC (back to my > Sybase days). > > >> >> Best, >> Joe >>> >>>> It might be worth it to add a note/comment in the JBS along with >>>> link to the original change. >>> >>> Best >>> Lance >>>> >>>> Best, >>>> Joe >>>> >>>> On 9/12/16, 9:29 AM, Lance Andersen wrote: >>>>> Happy Monday, >>>>> >>>>> This RFR is to add a test to validate that the >>>>> DriverManager.println output is accessible when DriverManager is >>>>> first loaded. >>>>> >>>>> The webrev can be found >>>>> at:http://cr.openjdk.java.net/~lancea/8159126/webrev.00/ >>>>> >>>>> >>>>> >>>>> Ran JPRT to sanity check across platforms >>>>> >>>>> >>>>> >>>>> Best >>>>> Lance >>>>> >>>>> >>>>> >>>>> Lance >>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>> Lance >>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From ecki at zusammenkunft.net Mon Sep 12 19:10:03 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Mon, 12 Sep 2016 21:10:03 +0200 Subject: RFR 8159126 Add test to validate DriverManager.println output whenDriverManager is initially loaded In-Reply-To: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> Message-ID: <57d6fd8f.274fc20a.d0260.5db2@mx.google.com> Hello, It looks like the test passes when the IOException happens (skips assert). Besides, what about actually providing a well known driver (only?). Then you dont have to depend on the debug output. Gruss Bernd -- http://bernd.eckenfels.net >From Win 10 Mobile Von: Lance Andersen From steve.drach at oracle.com Mon Sep 12 19:35:09 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 12 Sep 2016 12:35:09 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: <57D5C4FB.9090404@oracle.com> References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> <57D5C4FB.9090404@oracle.com> Message-ID: <1E207D57-CE03-4D2F-A59A-FF54C30F51AF@oracle.com> > jdk/internal/util/jar/VersionedStream.java: > > - use Integer.parseInt(name, vptr, ptr, 10) to avoid creating vstr on > every entry done > > - folding allowedVersions into getBaseSuffix seems easier than to keep > global state (sptr) and splitting the logic over a filter and a map > operation done > > - distinct() could be used instead of explicitly collecting to a I did use distinct in webrev.02. I left it in webrev.03 (coming soon). > LinkedHashSet, but this does make me wonder if we could do even > better by creating a map from base name to the appropriate versioned > JarEntry and return a stream over that map to avoid looking things up > via jf::getJarEntry. I look things up with getJarEntry to get the aliased entry. Otherwise we get the real name and we want to refer to entries by the base name. > Could be quite a bit more efficient, and as we > have to create a set or do distinct the overheads should be roughly > the same either way > > - declaring META_INF_VERSIONS_LEN seems like a premature optimization Left it in, it?s harmless and doesn?t need to be computed every time > > - nit: static final is preferred over final static done > > - nit: rename *ptr to *Index done > > Test and JarFile changes seem fine to me. > > Thanks! > > /Claes > > On 2016-09-11 22:12, Steve Drach wrote: >> I made a simple change, the new webrev is http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ >> >>> On Sep 9, 2016, at 4:02 PM, Steve Drach wrote: >>> >>> Hi, >>> >>> Please review this changeset that adds a VersionedStream class to the jdk.internal.util.jar package. Some may recall that I submitted a similar RFR a few weeks ago; this is a redesign from that one. We decided not to make a public JarFile::versionedStream method at this time. Once we get sufficient experience with this and find a few more use cases, we will revisit the idea of making this a public method in JarFile. >>> >>> issue: https://bugs.openjdk.java.net/browse/JDK-8163798 >>> webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.01/index.html >>> >>> Thanks, >>> Steve >> From steve.drach at oracle.com Mon Sep 12 19:36:12 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 12 Sep 2016 12:36:12 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> Message-ID: >> I made a simple change, the new webrev is http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ >> > > I don?t like the state interplay between allowedVersions and getBaseSuffix, and the filtering for null. Consider merging filter.map.filter into a single flatMap. Moved it into a map as Claes suggested > > Also can getJarEntry ever return null? yes, that?s why it?s filtered out > > Claes makes a good point regarding performance. I would suggest getting this functional and tested then tweaking for performance. > > Paul. > > > >>> On Sep 9, 2016, at 4:02 PM, Steve Drach wrote: >>> >>> Hi, >>> >>> Please review this changeset that adds a VersionedStream class to the jdk.internal.util.jar package. Some may recall that I submitted a similar RFR a few weeks ago; this is a redesign from that one. We decided not to make a public JarFile::versionedStream method at this time. Once we get sufficient experience with this and find a few more use cases, we will revisit the idea of making this a public method in JarFile. >>> >>> issue: https://bugs.openjdk.java.net/browse/JDK-8163798 >>> webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.01/index.html >>> >>> Thanks, >>> Steve >> > From steve.drach at oracle.com Mon Sep 12 19:36:19 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 12 Sep 2016 12:36:19 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> Message-ID: <7D314CD8-925A-4A3F-928E-00C15D4E1521@oracle.com> Here?s a new webrev that addresses Claes? and Paul?s concerns http://cr.openjdk.java.net/~sdrach/8163798/webrev.03/ > On Sep 11, 2016, at 1:12 PM, Steve Drach wrote: > > I made a simple change, the new webrev is http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ > >> On Sep 9, 2016, at 4:02 PM, Steve Drach wrote: >> >> Hi, >> >> Please review this changeset that adds a VersionedStream class to the jdk.internal.util.jar package. Some may recall that I submitted a similar RFR a few weeks ago; this is a redesign from that one. We decided not to make a public JarFile::versionedStream method at this time. Once we get sufficient experience with this and find a few more use cases, we will revisit the idea of making this a public method in JarFile. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8163798 >> webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.01/index.html >> >> Thanks, >> Steve > From lance.andersen at oracle.com Mon Sep 12 19:56:11 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 12 Sep 2016 15:56:11 -0400 Subject: RFR 8159126 Add test to validate DriverManager.println output whenDriverManager is initially loaded In-Reply-To: <57d6fd8f.274fc20a.d0260.5db2@mx.google.com> References: <1AA5E21E-D328-428D-BCBC-DDEF011DF2D1@oracle.com> <57d6fd8f.274fc20a.d0260.5db2@mx.google.com> Message-ID: <28006FF1-ECFF-4270-9A81-765748A35A6B@oracle.com> Thank you for the suggestions? > On Sep 12, 2016, at 3:10 PM, ecki at zusammenkunft.net wrote: > > Hello, > > It looks like the test passes when the IOException happens (skips assert). While I could add Assert.fail() catch blocks, I did not really see the need given this is in a controlled environment > > Besides, what about actually providing a well known driver (only?). That makes the test heavier than it needs to be for this specific scenario and really do not need a driver to validate, including a stub driver > Then you dont have to depend on the debug output. The idea is to validate the println output is available and that specific message has been there for almost 20 years and no plans to change that anytime soon. > > > Gruss > Bernd > -- > http://bernd.eckenfels.net > From Win 10 Mobile > > Von: Lance Andersen Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.sandoz at oracle.com Mon Sep 12 20:02:29 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Sep 2016 13:02:29 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> Message-ID: > On 12 Sep 2016, at 12:36, Steve Drach wrote: > >>> I made a simple change, the new webrev is http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ >>> >> >> I don?t like the state interplay between allowedVersions and getBaseSuffix, and the filtering for null. Consider merging filter.map.filter into a single flatMap. > > Moved it into a map as Claes suggested > Ok, better. Now there is no need to create an instance of VersionedStream, all methods can be static. I wonder if you can combine the checks for the index: 64 int index = name.indexOf('/', META_INF_VERSIONS_LEN); 65 if (index == -1) { 77 if (++index < name.length()) { e.g. no slash, or found at end (not just malformed since we want to skip version directory entries if present?) if (index == -1 || index == name.length() - 1) >> >> Also can getJarEntry ever return null? > > yes, that?s why it?s filtered out > Under what circumstances in this case can it return null? since you have iterated over the existing entries and reduced to a distinct subset. Paul. >> >> Claes makes a good point regarding performance. I would suggest getting this functional and tested then tweaking for performance. >> >> Paul. From patrick at reini.net Mon Sep 12 20:08:56 2016 From: patrick at reini.net (Patrick Reinhart) Date: Mon, 12 Sep 2016 22:08:56 +0200 Subject: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> Message-ID: <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> Hi Jonathan, As just also wanted to help some more clean-up in the JDKs final phase, I could offer you to hold that patch. Just send it to me and I will prepare the webrev for you?. -Patrick > Am 12.09.2016 um 20:36 schrieb Jonathan Bluett-Duncan : > > Hi David, > > Thanks for letting me know about the attachment stripping behaviour, and > reminding me about the current state of the JDK 9 release schedule. > > Stuart, would you be happy to host my patch on cr.openjdk.java.net? If not, > do you know who else might be happy to host it for me? Or alternatively, > would you prefer I wait until development of Java 9 Updates and/or Java 10 > starts? > > Kind regards, > Jonathan > > On 12 September 2016 at 01:50, David Holmes wrote: > >> Hi Jonathon, >> >> Attachments get stripped from most of the mailing lists so you will need >> to find someone to host these for you on cr.openjdk.java.net. >> >> That aside you may be hard pressed to find anyone who can look at this >> future work now, given where things are with the JDK 9 release schedule. >> >> Cheers, >> David >> >> >> On 11/09/2016 9:42 AM, Jonathan Bluett-Duncan wrote: >> >>> Hi all, >>> >>> Would you kindly review this patch to replace existing uses of >>> Collections.unmodifiable*(*Arrays.asList(*)) and plain Arrays.asList(*) >>> with (List|Set|Map).of(*). You may find the patch files in the >>> attachments. >>> >>> My rationale for replacing uses of Collections.unmodifiable*... with >>> (List|Set|Map).of is to make use of the memory savings allowed by the >>> newer >>> APIs. >>> >>> The general rationale for replacing the Arrays.asList calls I've touched >>> is >>> to again make use of memory savings, but this may be naive or misguided >>> reasoning on my part, as Arrays.asList may or may not be more >>> memory-efficient than List.of. However, where I've replaced Arrays.asList >>> for List.of in FileTreeIterator, my reasoning for doing so instead was to >>> help prevent TOCTOU attacks, but again this may be misguided on my part. >>> >>> It doesn't seem practical to me to include new unit tests, as these are >>> mainly performance improvements, but if it's believed that new unit tests >>> are needed, then I'd be happy to go back and try to include some. >>> >>> Kind regards, >>> Jonathan >>> >>> From Roger.Riggs at Oracle.com Mon Sep 12 20:25:33 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 12 Sep 2016 16:25:33 -0400 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: <1ebf6da4-70df-93d7-2035-a0423bf55356@oracle.com> References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> <1ebf6da4-70df-93d7-2035-a0423bf55356@oracle.com> Message-ID: Hi Daniel, Thanks for the review and suggestions: Updated in place: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ SpecDiff: http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html Javadoc (subset) http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html On 9/12/2016 1:15 PM, Daniel Fuchs wrote: > Hi Roger, > > ObjectInputStream.java: some cosmetic comments: > > 317 * {@link ObjectInputFilter.Config#getSerialFilter() the > process-wide filter}. > 352 * {@link ObjectInputFilter.Config#getSerialFilter() the > process-wide filter}. > > => should be @linkplain ok > > 1185 * The filter, when not {@code null}, is invoked during > {@linkplain #readObject()} > 1186 * and {@linkplain #readUnshared readUnshared} for each object > (+ also at lines 1207,1208,1211,1212, > Should that be @link? I saw that in other places, readObject and > readUnshared were not wrapped in {@code } - so for consistency it > might make sense to use @linkplain. However the usual idiom would > be to use {@link }. ok, with explicit method references and class references it should be @link. > > 2046 // Filter the replacement object > 2047 if (rep != null) { > 2048 if (rep.getClass().isArray()) { > 2049 filterCheck(rep.getClass(), > Array.getLength(rep)); > 2050 } else { > 2051 filterCheck(rep.getClass(), -1); > 2052 } > 2053 } > > In this case should the filter be also invoked with the > class of each element in the substituted array? > Or is it OK that only the array type is checked (could be > "[Ljava.lang.Object;" containing elements of classes > X, Y, Z, but the filter will only see the array type). The filter sees the type of the object returned from resolveObject whether it is an array or another object type. In the case of arrays, it is usually the array length that is most interesting to the filter. Thanks, Roger From Roger.Riggs at Oracle.com Mon Sep 12 20:42:33 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 12 Sep 2016 16:42:33 -0400 Subject: RFR 9: 8165261: RMI API to export an object with a serialization filter Message-ID: <7d212dc9-b211-76e6-2f6e-b903f4ea0ff6@Oracle.com> Please review an update to enable serialization filtering for exported RMI objects. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-rmi-filter-8165261/ Issue: https://bugs.openjdk.java.net/browse/JDK-8165261 Thanks, Roger From kumar.x.srinivasan at oracle.com Mon Sep 12 20:57:26 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 12 Sep 2016 13:57:26 -0700 Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using Message-ID: <57D716B6.4000800@oracle.com> Hello, I am sponsoring this changeset for Chris Bensen of the java packager team, please review fix for the launcher to better locate java.home. http://cr.openjdk.java.net/~ksrini/8165524/ Thanks Kumar From steve.drach at oracle.com Mon Sep 12 21:17:33 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 12 Sep 2016 14:17:33 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> Message-ID: Here?s a new webrev addressing Paul?s additional concerns http://cr.openjdk.java.net/~sdrach/8163798/webrev.04/ > Ok, better. Now there is no need to create an instance of VersionedStream, all methods can be static. Done > > I wonder if you can combine the checks for the index: > > 64 int index = name.indexOf('/', META_INF_VERSIONS_LEN); > 65 if (index == -1) { Removed that test, let Integer.parseint handle it > > 77 if (++index < name.length()) { > > e.g. no slash, or found at end (not just malformed since we want to skip version directory entries if present?) > > if (index == -1 || index == name.length() - 1) > > >>> >>> Also can getJarEntry ever return null? >> >> yes, that?s why it?s filtered out >> > > Under what circumstances in this case can it return null? since you have iterated over the existing entries and reduced to a distinct subset. Right, that was before I put the ?fix? in JarFile at line 561. I removed the null check > > Paul. > >>> >>> Claes makes a good point regarding performance. I would suggest getting this functional and tested then tweaking for performance. >>> >>> Paul. > From mandy.chung at oracle.com Mon Sep 12 23:26:20 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 Sep 2016 16:26:20 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> Message-ID: <9EB9B349-9A81-4504-8F75-454A3018CBB7@oracle.com> > On Sep 12, 2016, at 2:17 PM, Steve Drach wrote: > > Here?s a new webrev addressing Paul?s additional concerns > > http://cr.openjdk.java.net/~sdrach/8163798/webrev.04/ This version looks good. Can you add the javadoc to describe what the stream method returns (a union of the base entries + all versioned entries <= JarFile::getVersion. Nit: you may want to call jf.getVersion().major() once rather than the number of entries. Now that you have jdk.internal.util.jar internal API for MRJAR. It may be useful to add a static getRealName(JarFile jar, JarEntry entry) method for convenience such that jdeps and jlink can use this MRJAR-specific internal API and no need to use the shared secret. Maybe rename VersionedStream to VersionedJarFileHelper? TestVersionedStream::close You may want to use jdk.testlibrary.FileUtils and deleteFileTreeWithRetry may be what you want. Mandy From jbluettduncan at gmail.com Tue Sep 13 00:13:08 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Tue, 13 Sep 2016 01:13:08 +0100 Subject: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> Message-ID: Hi Patrick, Thank you very much for the offer to hold my patch for me! Is it common practice to send patches to others using PGP? Kind regards, Jonathan On 12 September 2016 at 21:08, Patrick Reinhart wrote: > Hi Jonathan, > > As just also wanted to help some more clean-up in the JDKs final phase, I > could offer you to hold that patch. Just send it to me and I will prepare > the webrev for you?. > > -Patrick > > > > Am 12.09.2016 um 20:36 schrieb Jonathan Bluett-Duncan < > jbluettduncan at gmail.com>: > > > > Hi David, > > > > Thanks for letting me know about the attachment stripping behaviour, and > > reminding me about the current state of the JDK 9 release schedule. > > > > Stuart, would you be happy to host my patch on cr.openjdk.java.net? If > not, > > do you know who else might be happy to host it for me? Or alternatively, > > would you prefer I wait until development of Java 9 Updates and/or Java > 10 > > starts? > > > > Kind regards, > > Jonathan > > > > On 12 September 2016 at 01:50, David Holmes > wrote: > > > >> Hi Jonathon, > >> > >> Attachments get stripped from most of the mailing lists so you will need > >> to find someone to host these for you on cr.openjdk.java.net. > >> > >> That aside you may be hard pressed to find anyone who can look at this > >> future work now, given where things are with the JDK 9 release schedule. > >> > >> Cheers, > >> David > >> > >> > >> On 11/09/2016 9:42 AM, Jonathan Bluett-Duncan wrote: > >> > >>> Hi all, > >>> > >>> Would you kindly review this patch to replace existing uses of > >>> Collections.unmodifiable*(*Arrays.asList(*)) and plain > Arrays.asList(*) > >>> with (List|Set|Map).of(*). You may find the patch files in the > >>> attachments. > >>> > >>> My rationale for replacing uses of Collections.unmodifiable*... with > >>> (List|Set|Map).of is to make use of the memory savings allowed by the > >>> newer > >>> APIs. > >>> > >>> The general rationale for replacing the Arrays.asList calls I've > touched > >>> is > >>> to again make use of memory savings, but this may be naive or misguided > >>> reasoning on my part, as Arrays.asList may or may not be more > >>> memory-efficient than List.of. However, where I've replaced > Arrays.asList > >>> for List.of in FileTreeIterator, my reasoning for doing so instead was > to > >>> help prevent TOCTOU attacks, but again this may be misguided on my > part. > >>> > >>> It doesn't seem practical to me to include new unit tests, as these are > >>> mainly performance improvements, but if it's believed that new unit > tests > >>> are needed, then I'd be happy to go back and try to include some. > >>> > >>> Kind regards, > >>> Jonathan > >>> > >>> > > From steve.drach at oracle.com Tue Sep 13 00:14:54 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 12 Sep 2016 17:14:54 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: <9EB9B349-9A81-4504-8F75-454A3018CBB7@oracle.com> References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> <9EB9B349-9A81-4504-8F75-454A3018CBB7@oracle.com> Message-ID: <5C6F815D-373D-4EAD-A87C-175CAA61361A@oracle.com> I guess I?m going to keep doing this until I get it right ;-) Here?s another webrev that doesn?t use an exception for a common case, and addresses most of Mandy concerns. http://cr.openjdk.java.net/~sdrach/8163798/webrev.06/ Comments in-line > This version looks good. > > Can you add the javadoc to describe what the stream method returns (a union of the base entries + all versioned entries <= JarFile::getVersion. Done > > Nit: you may want to call jf.getVersion().major() once rather than the number of entries. Done > > Now that you have jdk.internal.util.jar internal API for MRJAR. It may be useful to add a static getRealName(JarFile jar, JarEntry entry) method for convenience such that jdeps and jlink can use this MRJAR-specific internal API and no need to use the shared secret. Maybe rename VersionedStream to VersionedJarFileHelper? > > TestVersionedStream::close > You may want to use jdk.testlibrary.FileUtils and deleteFileTreeWithRetry may be what you want. I can?t use it because it removes the top-level directory (i.e. JTwork/scratch). > > Mandy From weijun.wang at oracle.com Tue Sep 13 02:41:35 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 13 Sep 2016 10:41:35 +0800 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: <61453466-05aa-f799-f7ed-55ceec507504@oracle.com> On 9/13/2016 2:13, Brian Burkhalter wrote: > Only picky comments: not sure but maybe change: > > 1) vice versa -> and vice versa > 2) When it?s set to true -> When true > 3) just like before -> as before All accepted. Thanks Max > > Brian > > On Sep 12, 2016, at 12:23 AM, Weijun Wang > wrote: > >> BTW, please also review the release note at >> >> https://bugs.openjdk.java.net/browse/JDK-8165836 >> >> Thanks >> Max > From frank.yuan at oracle.com Tue Sep 13 02:54:12 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 13 Sep 2016 10:54:12 +0800 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore In-Reply-To: <2f183b9a-9e1c-79ab-daf6-64dd3ef7e957@redhat.com> References: <022d01d20cdb$b8c2f000$2a48d000$@oracle.com> <2f183b9a-9e1c-79ab-daf6-64dd3ef7e957@redhat.com> Message-ID: <01d101d20d6a$1cedb2c0$56c91840$@oracle.com> Hi Aleksey Thank you very much for your review an comments! > -----Original Message----- > From: Aleksey Shipilev [mailto:shade at redhat.com] > Sent: Monday, September 12, 2016 6:45 PM > To: Frank Yuan; 'core-libs-dev' > Subject: Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore > > On 09/12/2016 12:54 PM, Frank Yuan wrote: > > Would you like to review http://cr.openjdk.java.net/~fyuan/8087303/webrev.01/? > > Not an expert in the XML parsing area, so only a cursory code review: > > ToStream.java: > > *) Bad camel casing: > 113 protected boolean m_ispreserveSpace = false; > It's to keep consistent with other members, you know, our jaxp library comes from Apache project. > *) shouldHandleText(chars, start, length) predicates within a method > can be computed once at the beginning? > Yes, thanks > *) I wonder if you want to check "length() > 0" before doing delete in > clearPendingWhiteSpaceText() which is frequently called > Yes, good suggestion, it has better performance! > *) "this." inconsistency here: > > 3240 this.m_preserves.clear(); > 3241 m_ispreserveSpace = false; > 3242 m_preserveSpaces.clear(); > Will change to be consistent, thanks. > Thanks, > -Aleksey Anyway, because Joe suggest to make further enhancement, I will get back after making more changes. Thanks Frank From weijun.wang at oracle.com Tue Sep 13 03:34:38 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 13 Sep 2016 11:34:38 +0800 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: Have you finished the deeper pass? :-) Thanks Max On 9/2/2016 8:18, Brian Burkhalter wrote: > At the API level and conceptually this all appears reasonable. I am > going to need to take a deeper pass over it all however to comprehend > the implementation at any kind of detailed level. The changes mentioned > in response to Alan?s comments all appear good. > > Thanks, > > Brian > > On Sep 1, 2016, at 7:25 AM, Weijun Wang > wrote: > >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8164705/webrev.01 >> >> Most suggestions from Alan accepted, including: >> >> 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead >> of public functions. >> >> 2. jdk.io.permissionsUseCanonicalPath=. >> >> 3. samepath.sh rewritten in ReadFileOnPath.java. >> >> Still using "ugly" method names. Thinking they are clear enough. > From volker.simonis at gmail.com Tue Sep 13 08:37:08 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 13 Sep 2016 10:37:08 +0200 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc Message-ID: Hi Alan, Sean, can we please get a review for this rather trivial change? > jira: https://bugs.openjdk.java.net/browse/JDK-8165231 > webrev: http://cr.openjdk.java.net/~gromero/8165231/ As outlined in Hiroshi's initial mail, we can not simply downport the solution used in jdk9 for querying the unaligned access support in nio because of differences in Unsafe. So this is a jsk8u-only change. But I think it is simple enough and doesn't affect any other platform except ppc to justify it. As nobody from the ppc porting team is jdk8u reviewer, I kindly ask you for a review and the permission to integrate into jdk8u. Thanks a lot and best regards, Volker On Thu, Sep 1, 2016 at 5:06 PM, Doerr, Martin wrote: > Hi Hiroshi, > > > > thanks for providing a fix. > > > > The fix > > 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of > illegal instructions > > was downported to 8, so I think your change is good. > > > > Best regards, > > Martin > > > > > > From: Hiroshi H Horii [mailto:HORII at jp.ibm.com] > Sent: Donnerstag, 1. September 2016 16:27 > To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Cc: Gustavo Bueno Romero ; Volker Simonis > (volker.simonis at gmail.com) ; Doerr, Martin > > Subject: RFR(m): java.nio.Bits.unaligned() doesn't return true on ppc > > > > Dear all: > > Can I please request reviews for the following change? > This change was created for JDK 8. > > Some open sources (such as Spark 2.0) check java.nio.Bits.unaligned() > to recognize support of unaligned memory access in platform. > Though ppc64 and ppc64le support it, unaligned() returns false. > > In JDK 9, this method returns unalignedAccess() of jdk.internal.misc.Unsafe > that doesn't exist in JDK8. > > jira: https://bugs.openjdk.java.net/browse/JDK-8165231 > webrev: http://cr.openjdk.java.net/~gromero/8165231/ > (Due to my login issue to the cs.openjdk.java.net, Gustavo thankfully > created this webrev.) > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo From daniel.fuchs at oracle.com Tue Sep 13 08:57:03 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Sep 2016 09:57:03 +0100 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> <1ebf6da4-70df-93d7-2035-a0423bf55356@oracle.com> Message-ID: Hi Roger, Looks good! One nit: In ObjectInputFilter.java, links to Status.XXXX should probably use @link instead of @linkplain - e.g {@linkplain Status#REJECTED REJECTED} or {@linkplain Status#REJECTED Status.REJECTED} should probably be @link to make the constants appear in code font. No need to regenerate a webrev if you decide to change that. best regards, -- daniel On 12/09/16 21:25, Roger Riggs wrote: > Hi Daniel, > > Thanks for the review and suggestions: > > Updated in place: > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ > SpecDiff: > http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html > Javadoc (subset) > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html > > > On 9/12/2016 1:15 PM, Daniel Fuchs wrote: >> Hi Roger, >> >> ObjectInputStream.java: some cosmetic comments: >> >> 317 * {@link ObjectInputFilter.Config#getSerialFilter() the >> process-wide filter}. >> 352 * {@link ObjectInputFilter.Config#getSerialFilter() the >> process-wide filter}. >> >> => should be @linkplain > ok >> >> 1185 * The filter, when not {@code null}, is invoked during >> {@linkplain #readObject()} >> 1186 * and {@linkplain #readUnshared readUnshared} for each object >> (+ also at lines 1207,1208,1211,1212, >> Should that be @link? I saw that in other places, readObject and >> readUnshared were not wrapped in {@code } - so for consistency it >> might make sense to use @linkplain. However the usual idiom would >> be to use {@link }. > > ok, with explicit method references and class references it should be @link. > >> >> 2046 // Filter the replacement object >> 2047 if (rep != null) { >> 2048 if (rep.getClass().isArray()) { >> 2049 filterCheck(rep.getClass(), >> Array.getLength(rep)); >> 2050 } else { >> 2051 filterCheck(rep.getClass(), -1); >> 2052 } >> 2053 } >> >> In this case should the filter be also invoked with the >> class of each element in the substituted array? >> Or is it OK that only the array type is checked (could be >> "[Ljava.lang.Object;" containing elements of classes >> X, Y, Z, but the filter will only see the array type). > The filter sees the type of the object returned from resolveObject > whether it > is an array or another object type. In the case of arrays, it is > usually the array > length that is most interesting to the filter. > > Thanks, Roger > > From daniel.fuchs at oracle.com Tue Sep 13 10:14:14 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Sep 2016 11:14:14 +0100 Subject: RFR 9: 8165261: RMI API to export an object with a serialization filter In-Reply-To: <7d212dc9-b211-76e6-2f6e-b903f4ea0ff6@Oracle.com> References: <7d212dc9-b211-76e6-2f6e-b903f4ea0ff6@Oracle.com> Message-ID: <9069d70c-f6ba-44ca-8592-9977abb9b28b@oracle.com> Hi Roger, On 12/09/16 21:42, Roger Riggs wrote: > Please review an update to enable serialization filtering for exported > RMI objects. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-rmi-filter-8165261/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8165261 > > Thanks, Roger > In UnicastRemoteObject.java: 142 *

    143 * Exported remote objects receive method invocations from the stubs 144 * as described in the RMI specification. Each invocation's operation and 145 * parameters are unmarshaled using a custom {@link java.io.ObjectInputStream}. 146 * If an {@link ObjectInputFilter} is provided and is not {@code null} when the object 147 * is exported, it is used to filter the parameters as they are unmarshaled from the stream. 148 * The filter is used for all invocations and all parameters regardless of 149 * the method being invoked or the parameter values. 150 * If no filter is provided or is {@code null} for the exported object then the 151 * {@code ObjectInputStream} default filter, if any, is used. The default filter is 152 * configured with {@link ObjectInputFilter.Config#setSerialFilter(ObjectInputFilter) 153 * ObjectInputFilter.Config.setSerialFilter}. Maybe this paragraph should say what happens when the filter rejects a parameter - or at least hints that there are more details to be found on the subject in ObjectInputFilter? 381 * @param filter an ObjectInputFilter applied when deserializing invocation arguments; 382 * may be null and: 408 * @param filter an ObjectInputFilter applied when deserializing invocation arguments; 409 * may be null => {@link ObjectInputFilter} ... may be {@code null} Otherwise looks good to me! -- daniel From sean.coffey at oracle.com Tue Sep 13 10:35:16 2016 From: sean.coffey at oracle.com (Sean Coffey) Date: Tue, 13 Sep 2016 11:35:16 +0100 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: References: Message-ID: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> Hi Volker, The fix looks fine to me. Please add the '9-na' label to the bug report. Also add a suitable noreg- label. It would also be useful to link the issue to JDK-8158260 Approved for jdk8u-dev. regards, Sean. On 13/09/2016 09:37, Volker Simonis wrote: > Hi Alan, Sean, > > can we please get a review for this rather trivial change? > >> jira: https://bugs.openjdk.java.net/browse/JDK-8165231 >> webrev: http://cr.openjdk.java.net/~gromero/8165231/ > As outlined in Hiroshi's initial mail, we can not simply downport the > solution used in jdk9 for querying the unaligned access support in nio > because of differences in Unsafe. So this is a jsk8u-only change. But > I think it is simple enough and doesn't affect any other platform > except ppc to justify it. > > As nobody from the ppc porting team is jdk8u reviewer, I kindly ask > you for a review and the permission to integrate into jdk8u. > > Thanks a lot and best regards, > Volker > > > On Thu, Sep 1, 2016 at 5:06 PM, Doerr, Martin wrote: >> Hi Hiroshi, >> >> >> >> thanks for providing a fix. >> >> >> >> The fix >> >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of >> illegal instructions >> >> was downported to 8, so I think your change is good. >> >> >> >> Best regards, >> >> Martin >> >> >> >> >> >> From: Hiroshi H Horii [mailto:HORII at jp.ibm.com] >> Sent: Donnerstag, 1. September 2016 16:27 >> To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Cc: Gustavo Bueno Romero ; Volker Simonis >> (volker.simonis at gmail.com) ; Doerr, Martin >> >> Subject: RFR(m): java.nio.Bits.unaligned() doesn't return true on ppc >> >> >> >> Dear all: >> >> Can I please request reviews for the following change? >> This change was created for JDK 8. >> >> Some open sources (such as Spark 2.0) check java.nio.Bits.unaligned() >> to recognize support of unaligned memory access in platform. >> Though ppc64 and ppc64le support it, unaligned() returns false. >> >> In JDK 9, this method returns unalignedAccess() of jdk.internal.misc.Unsafe >> that doesn't exist in JDK8. >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8165231 >> webrev: http://cr.openjdk.java.net/~gromero/8165231/ >> (Due to my login issue to the cs.openjdk.java.net, Gustavo thankfully >> created this webrev.) >> >> Regards, >> Hiroshi >> ----------------------- >> Hiroshi Horii, Ph.D. >> IBM Research - Tokyo From thomas.stuefe at gmail.com Tue Sep 13 10:53:57 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 13 Sep 2016 12:53:57 +0200 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files Message-ID: Dear all, please take a look at this small change: Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.00/webrev/ readdir_r is used to iterate over the content of a system directory, but the buffer passed to it is too small: Its size should include the size of the dirent structure itself (minus the d_name member). The fix also now checks the return code of pathconf(), and if pathconf() returns an error, falls back to the NAME_MAX compile time constant. Finally, it imposes a minimum size for the buffer, because on older System V systems NAME_MAX may be surprisingly small and readdir_r will not check the output buffer size. I think it is better to err on the safe side here. Kind Regards, Thomas From volker.simonis at gmail.com Tue Sep 13 12:09:39 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 13 Sep 2016 14:09:39 +0200 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> References: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> Message-ID: Hi Sean, thanks a lot for the fast response. I've updated the bug entry as requested and will push the change - maybe with the following potential improvement: @Hiroshi: also maybe not that performance relevant, I think we should we also fix sun/security/provider/ByteArrayAccess.java which contains the same construct: // Return whether this platform supports full speed int/long memory access // at unaligned addresses. // This code was copied from java.nio.Bits because there is no equivalent // public API. private static boolean unaligned() { String arch = java.security.AccessController.doPrivileged (new sun.security.action.GetPropertyAction("os.arch", "")); return arch.equals("i386") || arch.equals("x86") || arch.equals("amd64") || arch.equals("x86_64"); } Regards, Volker From christoph.langer at sap.com Tue Sep 13 12:35:36 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 13 Sep 2016 12:35:36 +0000 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: References: Message-ID: Hi Thomas, your change looks good. I'm also forwarding this to i18n-dev as issues in TimeZone implementation are mostly handled there. One remark: Can you take the opportunity to also remove the blank between the cast and malloc in line 150: "(struct dirent64 *) malloc..."? Unfortunately I'm no reviewer, so you still need an official review. Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Thomas St?fe > Sent: Dienstag, 13. September 2016 12:54 > To: Java Core Libs > Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching > timezone info files > > Dear all, > > please take a look at this small change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer- > overflow-when-seaching-timezone-info-files/webrev.00/webrev/ > > readdir_r is used to iterate over the content of a system directory, but > the buffer passed to it is too small: Its size should include the size of > the dirent structure itself (minus the d_name member). > > The fix also now checks the return code of pathconf(), and if pathconf() > returns an error, falls back to the NAME_MAX compile time constant. > Finally, it imposes a minimum size for the buffer, because on older System > V systems NAME_MAX may be surprisingly small and readdir_r will not check > the output buffer size. I think it is better to err on the safe side here. > > Kind Regards, Thomas From daniel.fuchs at oracle.com Tue Sep 13 12:45:05 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Sep 2016 13:45:05 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> <7999F927-ADBF-4C1E-B629-9C8284361359@oracle.com> <0dd01d6c-dec4-3305-99f2-bb1fe4f09fee@oracle.com> Message-ID: <577d4e5a-57a3-3978-2ded-5be975a9e7ac@oracle.com> Hi Mandy, Here is a new webrev with your feedback integrated. Finally I managed to get rid of the InternalError in MethodHandle by using: PrivilegedAction pa = () -> customLevel.getClass().getClassLoader(); instead of PrivilegedAction pa = customLevel.getClass()::getClassLoader; Not quite sure what was the issue. I can't manage to reproduce it in a stand alone test :-( Anyway - the new webrev no longer has the KnownLevelCLV class: http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.05 best regards, -- daniel On 29/08/16 21:10, Mandy Chung wrote: > >> On Aug 29, 2016, at 6:10 AM, Daniel Fuchs wrote: >> >> Here is a new webrev that uses ClassLoaderValue as Peter suggested. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.04/ >> > > Looks good in general. > > 553 // KnowLevelCLV is used to register custom level instances with > > typo: s/KnowLevelCLV/KnownLevelCLV > > 568 final Level level; > > Nit: perhaps renaming level to customLevel to make it clear what this is. > > line 645, 646: s/gced/GC?ed/ > > >> I had to introduce a new private static class (KnownLevelCLV) >> to avoid using lambdas in KnownLevel.add - as CustomLevel.java >> was failing with an InternalError raised in MethodHandles$Lookup >> otherwise. > > I agree it?s good to make progress on JDK-6543126. I think it?d be good to understand how we get to this InternalError during bindCaller. Can you file a low priority JBS issue to track that? > > Mandy > From patrick at reini.net Tue Sep 13 12:45:22 2016 From: patrick at reini.net (Patrick Reinhart) Date: Tue, 13 Sep 2016 14:45:22 +0200 Subject: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> Message-ID: Hi Jonathan, On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: > Hi Patrick, > > Thank you very much for the offer to hold my patch for me! No problem. > > Is it common practice to send patches to others using PGP? > No, this is my personal setting. > Kind regards, > Jonathan > > On 12 September 2016 at 21:08, Patrick Reinhart > wrote: > >> Hi Jonathan, >> >> As just also wanted to help some more clean-up in the JDKs final >> phase, I >> could offer you to hold that patch. Just send it to me and I will >> prepare >> the webrev for you?. >> >> -Patrick >> -Patrick From sean.coffey at oracle.com Tue Sep 13 12:45:19 2016 From: sean.coffey at oracle.com (Sean Coffey) Date: Tue, 13 Sep 2016 13:45:19 +0100 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: References: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> Message-ID: <962ae958-5897-6e9b-eec3-33680358ad0b@oracle.com> Sounds good Volker. Good catch. regards, Sean. On 13/09/2016 13:09, Volker Simonis wrote: > Hi Sean, > > thanks a lot for the fast response. I've updated the bug entry as > requested and will push the change - maybe with the following > potential improvement: > > @Hiroshi: also maybe not that performance relevant, I think we should > we also fix sun/security/provider/ByteArrayAccess.java which contains > the same construct: > > // Return whether this platform supports full speed int/long memory access > // at unaligned addresses. > // This code was copied from java.nio.Bits because there is no equivalent > // public API. > private static boolean unaligned() { > String arch = java.security.AccessController.doPrivileged > (new sun.security.action.GetPropertyAction("os.arch", "")); > return arch.equals("i386") || arch.equals("x86") || arch.equals("amd64") > || arch.equals("x86_64"); > } > > Regards, > Volker From Roger.Riggs at Oracle.com Tue Sep 13 14:03:35 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Sep 2016 10:03:35 -0400 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: References: Message-ID: <99bbc933-74fc-4a6b-8db7-31db8d7df2bc@Oracle.com> Hi Thomas, One minor point, it seems a bit asymmetric (@line 150) to cast to dirent64 but use dirent in the offsetof calculation. Otherwise, looks fine. Roger On 9/13/2016 8:35 AM, Langer, Christoph wrote: > Hi Thomas, > > your change looks good. I'm also forwarding this to i18n-dev as issues in TimeZone implementation are mostly handled there. > > One remark: Can you take the opportunity to also remove the blank between the cast and malloc in line 150: "(struct dirent64 *) malloc..."? > > Unfortunately I'm no reviewer, so you still need an official review. > > Best regards > Christoph > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Thomas St?fe >> Sent: Dienstag, 13. September 2016 12:54 >> To: Java Core Libs >> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching >> timezone info files >> >> Dear all, >> >> please take a look at this small change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer- >> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >> >> readdir_r is used to iterate over the content of a system directory, but >> the buffer passed to it is too small: Its size should include the size of >> the dirent structure itself (minus the d_name member). >> >> The fix also now checks the return code of pathconf(), and if pathconf() >> returns an error, falls back to the NAME_MAX compile time constant. >> Finally, it imposes a minimum size for the buffer, because on older System >> V systems NAME_MAX may be surprisingly small and readdir_r will not check >> the output buffer size. I think it is better to err on the safe side here. >> >> Kind Regards, Thomas From thomas.stuefe at gmail.com Tue Sep 13 14:49:51 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 13 Sep 2016 16:49:51 +0200 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: References: Message-ID: Hi Christoph, thanks for your review! Yes, I can remove the blank. Kind Regards, Thomas On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph wrote: > Hi Thomas, > > your change looks good. I'm also forwarding this to i18n-dev as issues in > TimeZone implementation are mostly handled there. > > One remark: Can you take the opportunity to also remove the blank between > the cast and malloc in line 150: "(struct dirent64 *) malloc..."? > > Unfortunately I'm no reviewer, so you still need an official review. > > Best regards > Christoph > > > -----Original Message----- > > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf > > Of Thomas St?fe > > Sent: Dienstag, 13. September 2016 12:54 > > To: Java Core Libs > > Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching > > timezone info files > > > > Dear all, > > > > please take a look at this small change: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 > > Webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8165936- > Potential-Heap-buffer- > > overflow-when-seaching-timezone-info-files/webrev.00/webrev/ > > > > readdir_r is used to iterate over the content of a system directory, but > > the buffer passed to it is too small: Its size should include the size of > > the dirent structure itself (minus the d_name member). > > > > The fix also now checks the return code of pathconf(), and if pathconf() > > returns an error, falls back to the NAME_MAX compile time constant. > > Finally, it imposes a minimum size for the buffer, because on older > System > > V systems NAME_MAX may be surprisingly small and readdir_r will not check > > the output buffer size. I think it is better to err on the safe side > here. > > > > Kind Regards, Thomas > From thomas.stuefe at gmail.com Tue Sep 13 14:50:31 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 13 Sep 2016 16:50:31 +0200 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: <99bbc933-74fc-4a6b-8db7-31db8d7df2bc@Oracle.com> References: <99bbc933-74fc-4a6b-8db7-31db8d7df2bc@Oracle.com> Message-ID: Hi Roger, thanks for the review! You are right, I will use dirent64 in offsetof. Kind Regards, Thomas On Tue, Sep 13, 2016 at 4:03 PM, Roger Riggs wrote: > Hi Thomas, > > One minor point, it seems a bit asymmetric (@line 150) to cast to dirent64 > but use dirent in the offsetof calculation. > Otherwise, looks fine. > > Roger > > > > > On 9/13/2016 8:35 AM, Langer, Christoph wrote: > >> Hi Thomas, >> >> your change looks good. I'm also forwarding this to i18n-dev as issues in >> TimeZone implementation are mostly handled there. >> >> One remark: Can you take the opportunity to also remove the blank between >> the cast and malloc in line 150: "(struct dirent64 *) malloc..."? >> >> Unfortunately I'm no reviewer, so you still need an official review. >> >> Best regards >> Christoph >> >> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >>> Behalf >>> Of Thomas St?fe >>> Sent: Dienstag, 13. September 2016 12:54 >>> To: Java Core Libs >>> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching >>> timezone info files >>> >>> Dear all, >>> >>> please take a look at this small change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >>> Webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential >>> -Heap-buffer- >>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >>> >>> readdir_r is used to iterate over the content of a system directory, but >>> the buffer passed to it is too small: Its size should include the size of >>> the dirent structure itself (minus the d_name member). >>> >>> The fix also now checks the return code of pathconf(), and if pathconf() >>> returns an error, falls back to the NAME_MAX compile time constant. >>> Finally, it imposes a minimum size for the buffer, because on older >>> System >>> V systems NAME_MAX may be surprisingly small and readdir_r will not check >>> the output buffer size. I think it is better to err on the safe side >>> here. >>> >>> Kind Regards, Thomas >>> >> > From mandy.chung at oracle.com Tue Sep 13 14:56:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Sep 2016 07:56:59 -0700 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <577d4e5a-57a3-3978-2ded-5be975a9e7ac@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> <7999F927-ADBF-4C1E-B629-9C8284361359@oracle.com> <0dd01d6c-dec4-3305-99f2-bb1fe4f09fee@oracle.com> <577d4e5a-57a3-3978-2ded-5be975a9e7ac@oracle.com> Message-ID: <5026C4F6-961B-405E-B8EA-459EB4E48C5F@oracle.com> The new webrev.05 looks good. > On Sep 13, 2016, at 5:45 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Here is a new webrev with your feedback integrated. > > Finally I managed to get rid of the InternalError in MethodHandle > by using: > PrivilegedAction pa = () -> > customLevel.getClass().getClassLoader(); > > instead of > PrivilegedAction pa = > customLevel.getClass()::getClassLoader; > > Not quite sure what was the issue. I can't manage to reproduce > it in a stand alone test :-( There might be some bug lurking. Are you able to reproduce it changing to method reference in the logging code? It worths filing a bug to track it. Mandy > > Anyway - the new webrev no longer has the KnownLevelCLV class: > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.05 > > best regards, > > -- daniel > > On 29/08/16 21:10, Mandy Chung wrote: >> >>> On Aug 29, 2016, at 6:10 AM, Daniel Fuchs wrote: >>> >>> Here is a new webrev that uses ClassLoaderValue as Peter suggested. >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.04/ >>> >> >> Looks good in general. >> >> 553 // KnowLevelCLV is used to register custom level instances with >> >> typo: s/KnowLevelCLV/KnownLevelCLV >> >> 568 final Level level; >> >> Nit: perhaps renaming level to customLevel to make it clear what this is. >> >> line 645, 646: s/gced/GC?ed/ >> >> >>> I had to introduce a new private static class (KnownLevelCLV) >>> to avoid using lambdas in KnownLevel.add - as CustomLevel.java >>> was failing with an InternalError raised in MethodHandles$Lookup >>> otherwise. >> >> I agree it?s good to make progress on JDK-6543126. I think it?d be good to understand how we get to this InternalError during bindCaller. Can you file a low priority JBS issue to track that? >> >> Mandy >> > From daniel.fuchs at oracle.com Tue Sep 13 15:06:02 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Sep 2016 16:06:02 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <5026C4F6-961B-405E-B8EA-459EB4E48C5F@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> <7999F927-ADBF-4C1E-B629-9C8284361359@oracle.com> <0dd01d6c-dec4-3305-99f2-bb1fe4f09fee@oracle.com> <577d4e5a-57a3-3978-2ded-5be975a9e7ac@oracle.com> <5026C4F6-961B-405E-B8EA-459EB4E48C5F@oracle.com> Message-ID: Thanks Mandy! On 13/09/16 15:56, Mandy Chung wrote: > The new webrev.05 looks good. > >> On Sep 13, 2016, at 5:45 AM, Daniel Fuchs wrote: >> >> Hi Mandy, >> >> Here is a new webrev with your feedback integrated. >> >> Finally I managed to get rid of the InternalError in MethodHandle >> by using: >> PrivilegedAction pa = () -> >> customLevel.getClass().getClassLoader(); >> >> instead of >> PrivilegedAction pa = >> customLevel.getClass()::getClassLoader; >> >> Not quite sure what was the issue. I can't manage to reproduce >> it in a stand alone test :-( > > There might be some bug lurking. Are you able to reproduce it changing to method reference in the logging code? Interesting. I'll try that. See if customLevel.getClass()::getName exhibits the same behaviour. > It worths filing a bug to track it. Yes - I talked with Maurizio about the issue. I will file a bug, but I'm waiting until the code is in, since I've not managed to reproduced by any other means than hacking Level.java... best regards, -- daniel > > Mandy > >> >> Anyway - the new webrev no longer has the KnownLevelCLV class: >> >> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.05 >> >> best regards, >> >> -- daniel >> >> On 29/08/16 21:10, Mandy Chung wrote: >>> >>>> On Aug 29, 2016, at 6:10 AM, Daniel Fuchs wrote: >>>> >>>> Here is a new webrev that uses ClassLoaderValue as Peter suggested. >>>> >>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.04/ >>>> >>> >>> Looks good in general. >>> >>> 553 // KnowLevelCLV is used to register custom level instances with >>> >>> typo: s/KnowLevelCLV/KnownLevelCLV >>> >>> 568 final Level level; >>> >>> Nit: perhaps renaming level to customLevel to make it clear what this is. >>> >>> line 645, 646: s/gced/GC?ed/ >>> >>> >>>> I had to introduce a new private static class (KnownLevelCLV) >>>> to avoid using lambdas in KnownLevel.add - as CustomLevel.java >>>> was failing with an InternalError raised in MethodHandles$Lookup >>>> otherwise. >>> >>> I agree it?s good to make progress on JDK-6543126. I think it?d be good to understand how we get to this InternalError during bindCaller. Can you file a low priority JBS issue to track that? >>> >>> Mandy >>> >> > From brian.burkhalter at oracle.com Tue Sep 13 15:09:06 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 13 Sep 2016 08:09:06 -0700 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: <0AB49214-E670-42A6-88C7-9761D3C652DA@oracle.com> Not really. Will continue with it. I?m not sure whether Alan is done with it either. Brian On Sep 12, 2016, at 8:34 PM, Weijun Wang wrote: > Have you finished the deeper pass? :-) > > Thanks > Max > > On 9/2/2016 8:18, Brian Burkhalter wrote: >> At the API level and conceptually this all appears reasonable. I am >> going to need to take a deeper pass over it all however to comprehend >> the implementation at any kind of detailed level. The changes mentioned >> in response to Alan?s comments all appear good. >> >> Thanks, >> >> Brian >> >> On Sep 1, 2016, at 7:25 AM, Weijun Wang > > wrote: >> >>> Webrev updated at >>> >>> http://cr.openjdk.java.net/~weijun/8164705/webrev.01 >>> >>> Most suggestions from Alan accepted, including: >>> >>> 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead >>> of public functions. >>> >>> 2. jdk.io.permissionsUseCanonicalPath=. >>> >>> 3. samepath.sh rewritten in ReadFileOnPath.java. >>> >>> Still using "ugly" method names. Thinking they are clear enough. >> From masayoshi.okutsu at oracle.com Tue Sep 13 15:25:34 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 14 Sep 2016 00:25:34 +0900 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: References: Message-ID: Looks good to me. Thank you for fixing this bug! Masayoshi On 9/13/2016 11:49 PM, Thomas St?fe wrote: > Hi Christoph, thanks for your review! Yes, I can remove the blank. > > Kind Regards, Thomas > > On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph > wrote: >> Hi Thomas, >> >> your change looks good. I'm also forwarding this to i18n-dev as issues in >> TimeZone implementation are mostly handled there. >> >> One remark: Can you take the opportunity to also remove the blank between >> the cast and malloc in line 150: "(struct dirent64 *) malloc..."? >> >> Unfortunately I'm no reviewer, so you still need an official review. >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >> Behalf >>> Of Thomas St?fe >>> Sent: Dienstag, 13. September 2016 12:54 >>> To: Java Core Libs >>> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching >>> timezone info files >>> >>> Dear all, >>> >>> please take a look at this small change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >>> Webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936- >> Potential-Heap-buffer- >>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >>> >>> readdir_r is used to iterate over the content of a system directory, but >>> the buffer passed to it is too small: Its size should include the size of >>> the dirent structure itself (minus the d_name member). >>> >>> The fix also now checks the return code of pathconf(), and if pathconf() >>> returns an error, falls back to the NAME_MAX compile time constant. >>> Finally, it imposes a minimum size for the buffer, because on older >> System >>> V systems NAME_MAX may be surprisingly small and readdir_r will not check >>> the output buffer size. I think it is better to err on the safe side >> here. >>> Kind Regards, Thomas From paul.sandoz at oracle.com Tue Sep 13 17:49:14 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 Sep 2016 10:49:14 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: <5C6F815D-373D-4EAD-A87C-175CAA61361A@oracle.com> References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> <9EB9B349-9A81-4504-8F75-454A3018CBB7@oracle.com> <5C6F815D-373D-4EAD-A87C-175CAA61361A@oracle.com> Message-ID: > On 12 Sep 2016, at 17:14, Steve Drach wrote: > > I guess I?m going to keep doing this until I get it right ;-) Here?s another webrev that doesn?t use an exception for a common case, and addresses most of Mandy concerns. > > http://cr.openjdk.java.net/~sdrach/8163798/webrev.06/ > Looks good, Paul. From mandy.chung at oracle.com Tue Sep 13 18:01:29 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Sep 2016 11:01:29 -0700 Subject: RFR: 8163798: Create a JarFile versionedStream method In-Reply-To: <5C6F815D-373D-4EAD-A87C-175CAA61361A@oracle.com> References: <46124030-5274-4D90-8F5E-9F0B8AE9EDA8@oracle.com> <9EB9B349-9A81-4504-8F75-454A3018CBB7@oracle.com> <5C6F815D-373D-4EAD-A87C-175CAA61361A@oracle.com> Message-ID: > On Sep 12, 2016, at 5:14 PM, Steve Drach wrote: > > http://cr.openjdk.java.net/~sdrach/8163798/webrev.06/ +1 Mandy From Roger.Riggs at Oracle.com Tue Sep 13 18:22:18 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Sep 2016 14:22:18 -0400 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> <1ebf6da4-70df-93d7-2035-a0423bf55356@oracle.com> Message-ID: Hi Daniel, Thanks for the suggestion, fixed. Roger On 9/13/2016 4:57 AM, Daniel Fuchs wrote: > Hi Roger, > > Looks good! > > One nit: In ObjectInputFilter.java, links to Status.XXXX > should probably use @link instead of @linkplain - e.g > {@linkplain Status#REJECTED REJECTED} or {@linkplain Status#REJECTED > Status.REJECTED} should probably be @link to make the constants > appear in code font. > > No need to regenerate a webrev if you decide to change that. > > best regards, > > -- daniel > > On 12/09/16 21:25, Roger Riggs wrote: >> Hi Daniel, >> >> Thanks for the review and suggestions: >> >> Updated in place: >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ >> SpecDiff: >> http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html >> Javadoc (subset) >> >> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html >> >> >> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html >> >> >> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html >> >> >> >> On 9/12/2016 1:15 PM, Daniel Fuchs wrote: >>> Hi Roger, >>> >>> ObjectInputStream.java: some cosmetic comments: >>> >>> 317 * {@link ObjectInputFilter.Config#getSerialFilter() the >>> process-wide filter}. >>> 352 * {@link ObjectInputFilter.Config#getSerialFilter() the >>> process-wide filter}. >>> >>> => should be @linkplain >> ok >>> >>> 1185 * The filter, when not {@code null}, is invoked during >>> {@linkplain #readObject()} >>> 1186 * and {@linkplain #readUnshared readUnshared} for each object >>> (+ also at lines 1207,1208,1211,1212, >>> Should that be @link? I saw that in other places, readObject and >>> readUnshared were not wrapped in {@code } - so for consistency it >>> might make sense to use @linkplain. However the usual idiom would >>> be to use {@link }. >> >> ok, with explicit method references and class references it should be >> @link. >> >>> >>> 2046 // Filter the replacement object >>> 2047 if (rep != null) { >>> 2048 if (rep.getClass().isArray()) { >>> 2049 filterCheck(rep.getClass(), >>> Array.getLength(rep)); >>> 2050 } else { >>> 2051 filterCheck(rep.getClass(), -1); >>> 2052 } >>> 2053 } >>> >>> In this case should the filter be also invoked with the >>> class of each element in the substituted array? >>> Or is it OK that only the array type is checked (could be >>> "[Ljava.lang.Object;" containing elements of classes >>> X, Y, Z, but the filter will only see the array type). >> The filter sees the type of the object returned from resolveObject >> whether it >> is an array or another object type. In the case of arrays, it is >> usually the array >> length that is most interesting to the filter. >> >> Thanks, Roger >> >> > From mandy.chung at oracle.com Tue Sep 13 18:24:04 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Sep 2016 11:24:04 -0700 Subject: Review Request: JDK-8157464: StackWalker.getCallerClass() is not In-Reply-To: References: Message-ID: <3C905A04-5FEF-4C2F-99D3-513E754E454C@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.01 This revises the proposal posted some time ago [1]. StackWalker::getCallerClass is a convenient method to find the caller class. It will return the invoker of the MethodHandle and java.lang.reflect.Method for the method calling StackWalker::getCallerClass, as it?s currently specified. This issue is related to MethodHandle for @CallerSensitive method. It behaves as if the caller is the lookup class and in the current implementation, the actual caller class is not the lookup class but a generated class. One intended usage of StackWalker::getCallerClass is to be called by library code acting as an agent that calls @CallerSensitive method on behalf of the true caller and typically it will call an appropriate method with the appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader). Given that StackWalker::getCallerClass is not expected to be used by any @CS method, this patch proposes to catch and throw an exception if StackWalker::getCallerClass is called by a @CS method. This will allow time to revisit this when such need is identified. thanks Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042345.html From daniel.fuchs at oracle.com Tue Sep 13 18:54:25 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Sep 2016 19:54:25 +0100 Subject: Review Request: JDK-8157464: StackWalker.getCallerClass() is not In-Reply-To: <3C905A04-5FEF-4C2F-99D3-513E754E454C@oracle.com> References: <3C905A04-5FEF-4C2F-99D3-513E754E454C@oracle.com> Message-ID: Hi Mandy, This looks good to me. But I wonder about these 5 lines - isn't this introducing a change of behavior if the caller is an anonymous class? 149 InstanceKlass* ik = method->method_holder(); 150 if (ik->is_anonymous()) { 151 // use the host class as the caller class 152 ik = ik->host_klass(); 153 } What is the reason for returning the host class instead? best regards, -- daniel On 13/09/16 19:24, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.01 > > This revises the proposal posted some time ago [1]. > > StackWalker::getCallerClass is a convenient method to find the caller class. It will return the invoker of the MethodHandle and java.lang.reflect.Method for the method calling StackWalker::getCallerClass, as it?s currently specified. > > This issue is related to MethodHandle for @CallerSensitive method. It behaves as if the caller is the lookup class and in the current implementation, the actual caller class is not the lookup class but a generated class. > > One intended usage of StackWalker::getCallerClass is to be called by library code acting as an agent that calls @CallerSensitive method on behalf of the true caller and typically it will call an appropriate method with the appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader). > > Given that StackWalker::getCallerClass is not expected to be used by any @CS method, this patch proposes to catch and throw an exception if StackWalker::getCallerClass is called by a @CS method. This will allow time to revisit this when such need is identified. > > thanks > Mandy > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042345.html > From Roger.Riggs at Oracle.com Tue Sep 13 19:10:01 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Sep 2016 15:10:01 -0400 Subject: RFR 9: 8165261: RMI API to export an object with a serialization filter In-Reply-To: <9069d70c-f6ba-44ca-8592-9977abb9b28b@oracle.com> References: <7d212dc9-b211-76e6-2f6e-b903f4ea0ff6@Oracle.com> <9069d70c-f6ba-44ca-8592-9977abb9b28b@oracle.com> Message-ID: <1b63633f-a2a7-e11d-dbf4-7bd496bd4d2c@Oracle.com> Hi Daniel, Thanks for the review and comments... Webrev updated in place. On 9/13/2016 6:14 AM, Daniel Fuchs wrote: > Hi Roger, > > On 12/09/16 21:42, Roger Riggs wrote: >> Please review an update to enable serialization filtering for exported >> RMI objects. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-rmi-filter-8165261/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8165261 >> >> Thanks, Roger >> > > In UnicastRemoteObject.java: > > 142 *

    > 143 * Exported remote objects receive method invocations from the stubs > 144 * as described in the RMI specification. Each invocation's > operation and > 145 * parameters are unmarshaled using a custom {@link > java.io.ObjectInputStream}. > 146 * If an {@link ObjectInputFilter} is provided and is not {@code > null} when the object > 147 * is exported, it is used to filter the parameters as they are > unmarshaled from the stream. > 148 * The filter is used for all invocations and all parameters > regardless of > 149 * the method being invoked or the parameter values. > 150 * If no filter is provided or is {@code null} for the exported > object then the > 151 * {@code ObjectInputStream} default filter, if any, is used. The > default filter is > 152 * configured with {@link > ObjectInputFilter.Config#setSerialFilter(ObjectInputFilter) > 153 * ObjectInputFilter.Config.setSerialFilter}. > > Maybe this paragraph should say what happens when the filter > rejects a parameter - or at least hints that there are more > details to be found on the subject in ObjectInputFilter? It will be reported as any other IOException from ObjectInputStream; I added: * If the filter rejects any of the parameters, the {@code InvalidClassException} * thrown by {@code ObjectInputStream} is reported as the cause of an * {@link UnmarshalException}. > > > 381 * @param filter an ObjectInputFilter applied when > deserializing invocation arguments; > 382 * may be null > and: > 408 * @param filter an ObjectInputFilter applied when > deserializing invocation arguments; > 409 * may be null > > > => {@link ObjectInputFilter} ... may be {@code null} fixed. Thanks, Roger > > Otherwise looks good to me! > > -- daniel > From mandy.chung at oracle.com Tue Sep 13 22:18:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Sep 2016 15:18:02 -0700 Subject: Review Request: JDK-8157464: StackWalker.getCallerClass() is not In-Reply-To: References: <3C905A04-5FEF-4C2F-99D3-513E754E454C@oracle.com> Message-ID: Hi Daniel, StackWalker::getCallerClass is a convenient method to find the caller class and is specified to skip the hidden frames (that?s the caller we are interested in). Since StackWalker only asks VM to fill in classes, the library can?t tell if it?s an anonymous class or not. Your question prompts me to revise the patch and simply skip the hidden frame if this stack walk is to lookup caller class to match the specification. I think this is a better fix: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.02/ We may re-examine this in the future if getCallerClass should get MemberName like the walk method such that we can determine if it?s a hidden frame and the performance difference. Mandy > On Sep 13, 2016, at 11:54 AM, Daniel Fuchs wrote: > > Hi Mandy, > > This looks good to me. > But I wonder about these 5 lines - isn't this introducing a change > of behavior if the caller is an anonymous class? > > 149 InstanceKlass* ik = method->method_holder(); > 150 if (ik->is_anonymous()) { > 151 // use the host class as the caller class > 152 ik = ik->host_klass(); > 153 } > > What is the reason for returning the host class instead? > > best regards, > > -- daniel > > On 13/09/16 19:24, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.01 >> >> This revises the proposal posted some time ago [1]. >> >> StackWalker::getCallerClass is a convenient method to find the caller class. It will return the invoker of the MethodHandle and java.lang.reflect.Method for the method calling StackWalker::getCallerClass, as it?s currently specified. >> >> This issue is related to MethodHandle for @CallerSensitive method. It behaves as if the caller is the lookup class and in the current implementation, the actual caller class is not the lookup class but a generated class. >> >> One intended usage of StackWalker::getCallerClass is to be called by library code acting as an agent that calls @CallerSensitive method on behalf of the true caller and typically it will call an appropriate method with the appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader). >> >> Given that StackWalker::getCallerClass is not expected to be used by any @CS method, this patch proposes to catch and throw an exception if StackWalker::getCallerClass is called by a @CS method. This will allow time to revisit this when such need is identified. >> >> thanks >> Mandy >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042345.html >> > From brent.christian at oracle.com Tue Sep 13 23:09:36 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 13 Sep 2016 16:09:36 -0700 Subject: Review Request: JDK-8157464: StackWalker.getCallerClass() is not In-Reply-To: References: <3C905A04-5FEF-4C2F-99D3-513E754E454C@oracle.com> Message-ID: <57D88730.8000003@oracle.com> Hi, Mandy Is a new JVM_STACKWALK_GET_CALLER_CLASS bit needed in jvm.h? AFAICT, JVM_STACKWALK_FILL_CLASS_REFS_ONLY is already only set for the getCallerClass() case. Could the new get_caller_class() instead check if JVM_STACKWALK_FILL_CLASS_REFS_ONLY is set? (Yes, this would be a third function checking the same thing, along with need_method_info() and use_frames_array()...) -Brent On 09/13/2016 03:18 PM, Mandy Chung wrote: > Hi Daniel, > > StackWalker::getCallerClass is a convenient method to find the caller class and is specified to skip the hidden frames (that?s the caller we are interested in). Since StackWalker only asks VM to fill in classes, the library can?t tell if it?s an anonymous class or not. > > Your question prompts me to revise the patch and simply skip the hidden frame if this stack walk is to lookup caller class to match the specification. I think this is a better fix: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.02/ > > We may re-examine this in the future if getCallerClass should get MemberName like the walk method such that we can determine if it?s a hidden frame and the performance difference. > > Mandy > >> On Sep 13, 2016, at 11:54 AM, Daniel Fuchs wrote: >> >> Hi Mandy, >> >> This looks good to me. >> But I wonder about these 5 lines - isn't this introducing a change >> of behavior if the caller is an anonymous class? >> >> 149 InstanceKlass* ik = method->method_holder(); >> 150 if (ik->is_anonymous()) { >> 151 // use the host class as the caller class >> 152 ik = ik->host_klass(); >> 153 } >> >> What is the reason for returning the host class instead? >> >> best regards, >> >> -- daniel >> >> On 13/09/16 19:24, Mandy Chung wrote: >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.01 >>> >>> This revises the proposal posted some time ago [1]. >>> >>> StackWalker::getCallerClass is a convenient method to find the caller class. It will return the invoker of the MethodHandle and java.lang.reflect.Method for the method calling StackWalker::getCallerClass, as it?s currently specified. >>> >>> This issue is related to MethodHandle for @CallerSensitive method. It behaves as if the caller is the lookup class and in the current implementation, the actual caller class is not the lookup class but a generated class. >>> >>> One intended usage of StackWalker::getCallerClass is to be called by library code acting as an agent that calls @CallerSensitive method on behalf of the true caller and typically it will call an appropriate method with the appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader). >>> >>> Given that StackWalker::getCallerClass is not expected to be used by any @CS method, this patch proposes to catch and throw an exception if StackWalker::getCallerClass is called by a @CS method. This will allow time to revisit this when such need is identified. >>> >>> thanks >>> Mandy >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042345.html >>> >> > From mandy.chung at oracle.com Wed Sep 14 00:04:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Sep 2016 17:04:14 -0700 Subject: Review Request: JDK-8157464: StackWalker.getCallerClass() is not In-Reply-To: <57D88730.8000003@oracle.com> References: <3C905A04-5FEF-4C2F-99D3-513E754E454C@oracle.com> <57D88730.8000003@oracle.com> Message-ID: <6F189334-AEC8-4C7D-A611-EA26711880FD@oracle.com> Yes that?s one option. JVM_STACKWALK_FILL_CLASS_REFS_ONLY is not necessarily used to get caller class. For example, AccessControlContext is interested in protection domains. We could build a specialized impl class to walk the stack fetching Class only whereas getCallerClass will stop walking after a few top frames. So a different bit will enable future experiment. Having said that, the assert should be reverted and minor adjustment: @@ -140,6 +143,13 @@ fill_stackframe(stackFrame, method, bci); } else { assert (use_frames_array(mode) == false, "Bad mode for get caller class"); + if (get_caller_class(mode) && index == start_index && method->caller_sensitive()) { + ResourceMark rm(THREAD); + THROW_MSG_0(vmSymbols::java_lang_UnsupportedOperationException(), + err_msg("StackWalker::getCallerClass called from @CallerSensitive %s method", + method->name_and_sig_as_C_string())); + } + http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.03/ Mandy > On Sep 13, 2016, at 4:09 PM, Brent Christian wrote: > > Hi, Mandy > > Is a new JVM_STACKWALK_GET_CALLER_CLASS bit needed in jvm.h? AFAICT, JVM_STACKWALK_FILL_CLASS_REFS_ONLY is already only set for the getCallerClass() case. > > Could the new get_caller_class() instead check if JVM_STACKWALK_FILL_CLASS_REFS_ONLY is set? (Yes, this would be a third function checking the same thing, along with need_method_info() and use_frames_array()...) > > -Brent > On 09/13/2016 03:18 PM, Mandy Chung wrote: >> Hi Daniel, >> >> StackWalker::getCallerClass is a convenient method to find the caller class and is specified to skip the hidden frames (that?s the caller we are interested in). Since StackWalker only asks VM to fill in classes, the library can?t tell if it?s an anonymous class or not. >> >> Your question prompts me to revise the patch and simply skip the hidden frame if this stack walk is to lookup caller class to match the specification. I think this is a better fix: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.02/ >> >> We may re-examine this in the future if getCallerClass should get MemberName like the walk method such that we can determine if it?s a hidden frame and the performance difference. >> >> Mandy >> >>> On Sep 13, 2016, at 11:54 AM, Daniel Fuchs wrote: >>> >>> Hi Mandy, >>> >>> This looks good to me. >>> But I wonder about these 5 lines - isn't this introducing a change >>> of behavior if the caller is an anonymous class? >>> >>> 149 InstanceKlass* ik = method->method_holder(); >>> 150 if (ik->is_anonymous()) { >>> 151 // use the host class as the caller class >>> 152 ik = ik->host_klass(); >>> 153 } >>> >>> What is the reason for returning the host class instead? >>> >>> best regards, >>> >>> -- daniel >>> >>> On 13/09/16 19:24, Mandy Chung wrote: >>>> Webrev: >>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.01 >>>> >>>> This revises the proposal posted some time ago [1]. >>>> >>>> StackWalker::getCallerClass is a convenient method to find the caller class. It will return the invoker of the MethodHandle and java.lang.reflect.Method for the method calling StackWalker::getCallerClass, as it?s currently specified. >>>> >>>> This issue is related to MethodHandle for @CallerSensitive method. It behaves as if the caller is the lookup class and in the current implementation, the actual caller class is not the lookup class but a generated class. >>>> >>>> One intended usage of StackWalker::getCallerClass is to be called by library code acting as an agent that calls @CallerSensitive method on behalf of the true caller and typically it will call an appropriate method with the appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader). >>>> >>>> Given that StackWalker::getCallerClass is not expected to be used by any @CS method, this patch proposes to catch and throw an exception if StackWalker::getCallerClass is called by a @CS method. This will allow time to revisit this when such need is identified. >>>> >>>> thanks >>>> Mandy >>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042345.html >>>> >>> >> > From rednaxelafx at gmail.com Wed Sep 14 00:09:54 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 13 Sep 2016 17:09:54 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> Message-ID: Hi OpenJDK developers, Replying on behalf of Azul Systems: java.lang.Compiler is an integral part of the current Java SE spec, and is currently being used by multiple independent Java SE implementations of that spec in a spec-conforming way (Azul Zing, Azul Vega, and IBM J9 being concrete exampleS). Before deprecation, a proposed replacement for Java SE 9 would need to be vetted to make sure that is satisfies the needs of current implementations. While JEP165 is a start in that direction, it appears to be very HotSpot specific, and is not written in a specification form (e.g. there is no "If no compiler is available, these methods do nothing." mention). For example, Azul Zing?s ReadyNow feature makes use of the java.lang.Compiler API to allow applications to pass directives down to the VM, in a similar spirit to what IBM J9 does with the API. We continuously evolve and enrich the commands we support in the API, e.g. in the ?Object command(Object)? method, and it would be potentially problematic for us to lose the current API without having a flexible replacement in the Java SE spec. As such, we suggest that for the time being, java.lang.Compiler should be neither depracated nor removed in Java SE 9. As a practical spec'ed replacement is proposed that will cover the needs of implementations currently using java.lang.Compiler, this can change. Perhaps in the Java SE 10 timeframe. Thanks, Kris (OpenJDK username: kmo) On Wed, Sep 7, 2016 at 1:52 PM, Stuart Marks wrote: > Hi all, > > Please review this small patch to deprecate java.lang.Compiler for removal. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1473281459 25200 > # Wed Sep 07 13:50:59 2016 -0700 > # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d > # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c > 4285505: deprecate java.lang.Compiler > Reviewed-by: XXX > > diff -r 76ba1b74f268 -r e520c4e6970c src/java.base/share/classes/ja > va/lang/Compiler.java > --- a/src/java.base/share/classes/java/lang/Compiler.java Tue Sep > 06 16:08:54 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/Compiler.java Wed Sep > 07 13:50:59 2016 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -29,21 +29,18 @@ > * The {@code Compiler} class is provided to support Java-to-native-code > * compilers and related services. By design, the {@code Compiler} class > does > * nothing; it serves as a placeholder for a JIT compiler implementation. > + * If no compiler is available, these methods do nothing. > * > - *

    When the Java Virtual Machine first starts, it determines if the > system > - * property {@code java.compiler} exists. (System properties are > accessible > - * through {@link System#getProperty(String)} and {@link > - * System#getProperty(String, String)}. If so, it is assumed to be the > name of > - * a library (with a platform-dependent exact location and type); {@link > - * System#loadLibrary} is called to load that library. If this loading > - * succeeds, the function named {@code java_lang_Compiler_start()} in that > - * library is called. > - * > - *

    If no compiler is available, these methods do nothing. > + * @deprecated JIT compilers and their technologies vary too widely to > + * be controlled effectively by a standardized interface. As such, many > + * JIT compiler implementations ignore this interface, and are instead > + * controllable by implementation-specific mechanisms such as command-line > + * options. This class is subject to removal in a future version of Java > SE. > * > * @author Frank Yellin > * @since 1.0 > */ > + at Deprecated(since="9", forRemoval=true) > public final class Compiler { > private Compiler() {} // don't make instances > > From naoto.sato at oracle.com Wed Sep 14 00:28:18 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 13 Sep 2016 17:28:18 -0700 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: References: Message-ID: <027936ea-731f-6931-86bd-d7020ce8138f@oracle.com> Hi Thomas, Another cosmetic comment: please use 4 space indentation inside those "if" clauses. Otherwise, +1. Naoto On 9/13/16 7:49 AM, Thomas St?fe wrote: > Hi Christoph, thanks for your review! Yes, I can remove the blank. > > Kind Regards, Thomas > > On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph > wrote: > >> Hi Thomas, >> >> your change looks good. I'm also forwarding this to i18n-dev as issues in >> TimeZone implementation are mostly handled there. >> >> One remark: Can you take the opportunity to also remove the blank between >> the cast and malloc in line 150: "(struct dirent64 *) malloc..."? >> >> Unfortunately I'm no reviewer, so you still need an official review. >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >> Behalf >>> Of Thomas St?fe >>> Sent: Dienstag, 13. September 2016 12:54 >>> To: Java Core Libs >>> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching >>> timezone info files >>> >>> Dear all, >>> >>> please take a look at this small change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >>> Webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936- >> Potential-Heap-buffer- >>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >>> >>> readdir_r is used to iterate over the content of a system directory, but >>> the buffer passed to it is too small: Its size should include the size of >>> the dirent structure itself (minus the d_name member). >>> >>> The fix also now checks the return code of pathconf(), and if pathconf() >>> returns an error, falls back to the NAME_MAX compile time constant. >>> Finally, it imposes a minimum size for the buffer, because on older >> System >>> V systems NAME_MAX may be surprisingly small and readdir_r will not check >>> the output buffer size. I think it is better to err on the safe side >> here. >>> >>> Kind Regards, Thomas >> From steve.drach at oracle.com Wed Sep 14 00:52:44 2016 From: steve.drach at oracle.com (Steve Drach) Date: Tue, 13 Sep 2016 17:52:44 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: <8E7A5A0F-1789-43B5-AA88-AA3FBC57C267@oracle.com> References: <8E7A5A0F-1789-43B5-AA88-AA3FBC57C267@oracle.com> Message-ID: <23D4FB21-E8A4-400E-AC56-A946D0D95709@oracle.com> The latest web revs. Answers to questions in-line below: http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/ http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ >>> >>> This looks quite good. JDK-8163798 and JDK-8164665 will define public APIs to get the versioned entries and real name which I think are useful for tools. It?s fine to proceed with this change and update jdeps to use the public APIs when available. >> >> The product team has decided not to move forward on those two issues for now, they will remain unresolved. > > OK. What about putting these helper methods in jdk.internal.jar package as jlink and jdeps both use them to would avoid duplicated code. VersionedStream is now in jdk.internal.util.jar > > >>> >>> This patch parse MR-JAR only if ?-multi-release option is specified. It would also be useful to analyze all versioned entries for the default option (i.e. analyze direct dependencies from class files) that can be done in a separate RFE. >>> >>> Comments to this patch: >>> >>> ClassFileReader.java >>> >>> 386 if (Integer.parseInt(v) < 9) { >>> 387 String[] msg = {"err.multirelease.jar.malformed", >>> 388 jarfile.getName(), rn >>> 389 }; >>> 390 throw new MultiReleaseException(msg); >>> 391 } >>> >>> To get here, I can think of the case when it?s not a MRJAR (so JarFile::stream returns all entries). >> >> fixed >> >>> If it?s a MR-JAR, the JarFile will be opened with a valid version. versionedStream should only return the proper versioned entries. Maybe you should emit warning (add it to skippedEntries if this happens) or make it an assert. >> >> I?m not sure what you mean. > > My point is that JarFile::getEntry should not return such JarEntry - is that true? > > In that case, how SharedSecrets.javaUtilJarAccess().getRealName(jarfile, e) would return META-INF/versions/$n where n < 9? > > This is not an expected error and so InternalError (or assert) is more appropriate than throwing MultiReleaseException. I put an assert in. > >> >>> >>> Can you add the following scenario in the new test and Bar and Gee are public and shows the result when -?multi-release 9 or 10 or base? >>> p/Foo.class >>> META-INF/versions/9/p/Foo.class >>> META-INF/versions/9/q/Bar.class >>> META-INF/versions/10/q/Bar.class >>> META-INF/versions/10/q/Gee.class >> >> One can not put new public classes in the versioned section, so that layout is not legal If I make Bar and Gee non-public, I can build a jar with them in it. See the second test I added in test.tools.jdep.MultireleaseJar > > But such JAR file can be created. What about adding a non-public class under: > META-INF/versions/9/q/Zee.class > META-INF/versions/10/q/Zee.class > > Keeping public q/Bar.class is okay as JarFile::getName(?q/Bar.class?) should return null if not allowed for any Runtime.Version. jar tool won?t validate a q.Bar as a public class. > >> >>> >>> JDK-8163798 would cover more scenarios in depth. I?m okay to use the versionedStream you have and leave that to JDK-8163798. >> >>> BTW the copyright header is missing in the new tests. >> >> All the existing test input source files do not have the copyright header. These little classes are just there to feed the test that does have the required copyright > > I put the copyright headers in all source files, including tiny test classes. Done. > >> >>> >>> JdepsTask.java >>> 401 throw new BadArgs("err.multirelease.option.illegal", arg); >>> >>> You can simply use err.invalid.arg.for.option which I think is simple and adequate. >> >> That?s not an existing property, so I left it where it is with all the multi-release properties > > err.invalid.arg.for.option is an existing property. Okay. Unfortunately we lose a better error message. > >> >>> jdeps.properties: what about a shorter version: >>> >>> --multi-release Specifies the version when processing >>> multi-release jar files. can be >>>> = 9 or base. >> >> I did that but I think it?s more confusing > > User guides, man page to include examples would help that. > > Mandy > From naoto.sato at oracle.com Wed Sep 14 04:04:47 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 13 Sep 2016 21:04:47 -0700 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: <027936ea-731f-6931-86bd-d7020ce8138f@oracle.com> References: <027936ea-731f-6931-86bd-d7020ce8138f@oracle.com> Message-ID: Line 137: The declaration of "min" cannot follow statements (not all platforms support C99). It has to move up around line 131. Naoto On 9/13/16 5:28 PM, Naoto Sato wrote: > Hi Thomas, > > Another cosmetic comment: please use 4 space indentation inside those > "if" clauses. Otherwise, +1. > > Naoto > > On 9/13/16 7:49 AM, Thomas St?fe wrote: >> Hi Christoph, thanks for your review! Yes, I can remove the blank. >> >> Kind Regards, Thomas >> >> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph >> >> wrote: >> >>> Hi Thomas, >>> >>> your change looks good. I'm also forwarding this to i18n-dev as >>> issues in >>> TimeZone implementation are mostly handled there. >>> >>> One remark: Can you take the opportunity to also remove the blank >>> between >>> the cast and malloc in line 150: "(struct dirent64 *) malloc..."? >>> >>> Unfortunately I'm no reviewer, so you still need an official review. >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >>> Behalf >>>> Of Thomas St?fe >>>> Sent: Dienstag, 13. September 2016 12:54 >>>> To: Java Core Libs >>>> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching >>>> timezone info files >>>> >>>> Dear all, >>>> >>>> please take a look at this small change: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >>>> Webrev: >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936- >>> Potential-Heap-buffer- >>>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >>>> >>>> readdir_r is used to iterate over the content of a system directory, >>>> but >>>> the buffer passed to it is too small: Its size should include the >>>> size of >>>> the dirent structure itself (minus the d_name member). >>>> >>>> The fix also now checks the return code of pathconf(), and if >>>> pathconf() >>>> returns an error, falls back to the NAME_MAX compile time constant. >>>> Finally, it imposes a minimum size for the buffer, because on older >>> System >>>> V systems NAME_MAX may be surprisingly small and readdir_r will not >>>> check >>>> the output buffer size. I think it is better to err on the safe side >>> here. >>>> >>>> Kind Regards, Thomas >>> From huizhe.wang at oracle.com Wed Sep 14 04:48:55 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 13 Sep 2016 21:48:55 -0700 Subject: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9 Message-ID: <57D8D6B7.8040900@oracle.com> Hi, Please review the deprecation of the internal Catalog API. JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ Thanks, Joe From thomas.stuefe at gmail.com Wed Sep 14 06:34:12 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 14 Sep 2016 08:34:12 +0200 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: References: Message-ID: Hi all, thanks for the reviews. Here is version two: http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ Only cosmetic changes: - made code pre-c99 compatible - consistently use dirent64 - fix indentation in ifs - removed black between malloc and cast Kind Regards, Thomas On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu < masayoshi.okutsu at oracle.com> wrote: > Looks good to me. Thank you for fixing this bug! > > Masayoshi > > > > On 9/13/2016 11:49 PM, Thomas St?fe wrote: > >> Hi Christoph, thanks for your review! Yes, I can remove the blank. >> >> Kind Regards, Thomas >> >> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph < >> christoph.langer at sap.com >> >>> wrote: >>> Hi Thomas, >>> >>> your change looks good. I'm also forwarding this to i18n-dev as issues in >>> TimeZone implementation are mostly handled there. >>> >>> One remark: Can you take the opportunity to also remove the blank between >>> the cast and malloc in line 150: "(struct dirent64 *) malloc..."? >>> >>> Unfortunately I'm no reviewer, so you still need an official review. >>> >>> Best regards >>> Christoph >>> >>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >>>> >>> Behalf >>> >>>> Of Thomas St?fe >>>> Sent: Dienstag, 13. September 2016 12:54 >>>> To: Java Core Libs >>>> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching >>>> timezone info files >>>> >>>> Dear all, >>>> >>>> please take a look at this small change: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >>>> Webrev: >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936- >>>> >>> Potential-Heap-buffer- >>> >>>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >>>> >>>> readdir_r is used to iterate over the content of a system directory, but >>>> the buffer passed to it is too small: Its size should include the size >>>> of >>>> the dirent structure itself (minus the d_name member). >>>> >>>> The fix also now checks the return code of pathconf(), and if pathconf() >>>> returns an error, falls back to the NAME_MAX compile time constant. >>>> Finally, it imposes a minimum size for the buffer, because on older >>>> >>> System >>> >>>> V systems NAME_MAX may be surprisingly small and readdir_r will not >>>> check >>>> the output buffer size. I think it is better to err on the safe side >>>> >>> here. >>> >>>> Kind Regards, Thomas >>>> >>> > From daniel.fuchs at oracle.com Wed Sep 14 07:53:26 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Sep 2016 08:53:26 +0100 Subject: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9 In-Reply-To: <57D8D6B7.8040900@oracle.com> References: <57D8D6B7.8040900@oracle.com> Message-ID: Hi Joe, I will review it in more details but here is an early feedback: 66 * 67 * new public API.

    The following should work (it did in the past, might be worth checking that it still does): * {@linkplain javax.xml.catalog new public API} and should avoid putting in absolute hyperlinks that might become obsolete. best regards -- daniel On 14/09/16 05:48, Joe Wang wrote: > Hi, > > Please review the deprecation of the internal Catalog API. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ > > Thanks, > Joe From daniel.fuchs at oracle.com Wed Sep 14 08:55:19 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Sep 2016 09:55:19 +0100 Subject: Review Request: JDK-8157464: StackWalker.getCallerClass() is not In-Reply-To: <6F189334-AEC8-4C7D-A611-EA26711880FD@oracle.com> References: <3C905A04-5FEF-4C2F-99D3-513E754E454C@oracle.com> <57D88730.8000003@oracle.com> <6F189334-AEC8-4C7D-A611-EA26711880FD@oracle.com> Message-ID: <41784106-6dbb-97e9-5837-3ebb9f27484d@oracle.com> Hi Mandy, webrev.03 looks good to me! best regards, -- daniel On 14/09/16 01:04, Mandy Chung wrote: > Yes that?s one option. > > JVM_STACKWALK_FILL_CLASS_REFS_ONLY is not necessarily used to get caller class. For example, AccessControlContext is interested in protection domains. We could build a specialized impl class to walk the stack fetching Class only whereas getCallerClass will stop walking after a few top frames. So a different bit will enable future experiment. Having said that, the assert should be reverted and minor adjustment: > > @@ -140,6 +143,13 @@ > fill_stackframe(stackFrame, method, bci); > } else { > assert (use_frames_array(mode) == false, "Bad mode for get caller class"); > + if (get_caller_class(mode) && index == start_index && method->caller_sensitive()) { > + ResourceMark rm(THREAD); > + THROW_MSG_0(vmSymbols::java_lang_UnsupportedOperationException(), > + err_msg("StackWalker::getCallerClass called from @CallerSensitive %s method", > + method->name_and_sig_as_C_string())); > + } > + > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.03/ > > Mandy From daniel.fuchs at oracle.com Wed Sep 14 09:11:57 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Sep 2016 10:11:57 +0100 Subject: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9 In-Reply-To: <57D8D6B7.8040900@oracle.com> References: <57D8D6B7.8040900@oracle.com> Message-ID: <229369b5-1762-6d01-dabf-407c3fc7b17f@oracle.com> Hi Joe, As much as I would like to support removing obsolete classes, I wonder if the forRemoval=true is a bit premature. I see that for instance, com.sun.org.apache.xml.internal.resolver.Catalog seems to be still used at many places in our code base. It would be more convincing if we could first make our own codebase stop using these classes: then we could be confident that forRemoval=true is the better choice! best regards, -- daniel On 14/09/16 05:48, Joe Wang wrote: > Hi, > > Please review the deprecation of the internal Catalog API. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ > > Thanks, > Joe From chris.hegarty at oracle.com Wed Sep 14 09:46:09 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 14 Sep 2016 10:46:09 +0100 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> Message-ID: On 08/09/16 20:09, Roger Riggs wrote: > Please review updates to the Serialization filtering API and > implementation: > - The ObjectInputFilter pattern based filters support matching on > module names as well as package and class names. > - Rename of system property and java.security property for > configurable filters. (jdk.serialFilter) > - ObjectInputFilter clarifications about the values passed to the filter > - Javadoc editorial improvements > - Clarification of SerializablePermission description of targets > > - More tests > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ This looks very good Roger, just a few comments: 1) The pattern separator in the java.security file should be ';' Right? 925 #jdk.serialFilter=pattern,pattern ^^^ 2) A question on the excepted usage. During the initialization of OIS the process-wide filter is cached in an instance field, 'serialFilter'. A subsequent change to the process-wide filter will not affect the OIS instance. I think this is ok, just checking the expected usage, as the example in the OIF class description reads the process-wide filter ever time. Maybe the example should be changed slightly to no promote this type of usage? Maybe just remove the call to getSerialFilter? 3) Are third-party OIS implementations required, or expected, to "callback" to the filter? The spec, of course, would appear to allow it, but not require it? Just wondering if this is required, or not, as it is not clear to me. -Chris. > SpecDiff: > http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html > > Javadoc (subset) > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html > > > Thanks, Roger > > > From chris.hegarty at oracle.com Wed Sep 14 10:11:52 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 14 Sep 2016 11:11:52 +0100 Subject: RFR 9: 8165261: RMI API to export an object with a serialization filter In-Reply-To: <7d212dc9-b211-76e6-2f6e-b903f4ea0ff6@Oracle.com> References: <7d212dc9-b211-76e6-2f6e-b903f4ea0ff6@Oracle.com> Message-ID: On 12/09/16 21:42, Roger Riggs wrote: > Please review an update to enable serialization filtering for exported > RMI objects. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-rmi-filter-8165261/ This looks good to me Roger. -Chris. From daniel.fuchs at oracle.com Wed Sep 14 10:20:09 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Sep 2016 11:20:09 +0100 Subject: RFR 9: 8165261: RMI API to export an object with a serialization filter In-Reply-To: <1b63633f-a2a7-e11d-dbf4-7bd496bd4d2c@Oracle.com> References: <7d212dc9-b211-76e6-2f6e-b903f4ea0ff6@Oracle.com> <9069d70c-f6ba-44ca-8592-9977abb9b28b@oracle.com> <1b63633f-a2a7-e11d-dbf4-7bd496bd4d2c@Oracle.com> Message-ID: <8ae90280-78c1-a03f-d6b5-6b58224e3031@oracle.com> Hi Roger, On 13/09/16 20:10, Roger Riggs wrote: > Hi Daniel, > > Thanks for the review and comments... > Webrev updated in place. > Looks good to me! best regards, -- daniel From forax at univ-mlv.fr Wed Sep 14 11:19:54 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 14 Sep 2016 13:19:54 +0200 (CEST) Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> Message-ID: <1958149215.1338325.1473851994656.JavaMail.zimbra@u-pem.fr> Hi Krys, why do you need a public API to send the profile to the JIT compiler ? R?mi ----- Mail original ----- > De: "Krystal Mok" > ?: "Stuart Marks" > Cc: "core-libs-dev" > Envoy?: Mercredi 14 Septembre 2016 02:09:54 > Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler > Hi OpenJDK developers, > > Replying on behalf of Azul Systems: > > java.lang.Compiler is an integral part of the current Java SE spec, and is > currently being used by multiple independent Java SE implementations of > that spec in a spec-conforming way (Azul Zing, Azul Vega, and IBM J9 being > concrete exampleS). Before deprecation, a proposed replacement for Java SE > 9 would need to be vetted to make sure that is satisfies the needs of > current implementations. While JEP165 is a start in that direction, it > appears to be very HotSpot specific, and is not written in a specification > form (e.g. there is no "If no compiler is available, these methods do > nothing." mention). > > For example, Azul Zing?s ReadyNow feature makes use of the > java.lang.Compiler API to allow applications to pass directives down to the > VM, in a similar spirit to what IBM J9 does with the API. We continuously > evolve and enrich the commands we support in the API, e.g. in the ?Object > command(Object)? method, and it would be potentially problematic for us to > lose the current API without having a flexible replacement in the Java SE > spec. > > As such, we suggest that for the time being, java.lang.Compiler should be > neither depracated nor removed in Java SE 9. As a practical spec'ed > replacement is proposed that will cover the needs of implementations > currently using java.lang.Compiler, this can change. Perhaps in the Java SE > 10 timeframe. > > Thanks, > Kris (OpenJDK username: kmo) > > On Wed, Sep 7, 2016 at 1:52 PM, Stuart Marks > wrote: > >> Hi all, >> >> Please review this small patch to deprecate java.lang.Compiler for removal. >> >> Thanks, >> >> s'marks >> >> # HG changeset patch >> # User smarks >> # Date 1473281459 25200 >> # Wed Sep 07 13:50:59 2016 -0700 >> # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d >> # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c >> 4285505: deprecate java.lang.Compiler >> Reviewed-by: XXX >> >> diff -r 76ba1b74f268 -r e520c4e6970c src/java.base/share/classes/ja >> va/lang/Compiler.java >> --- a/src/java.base/share/classes/java/lang/Compiler.java Tue Sep >> 06 16:08:54 2016 -0700 >> +++ b/src/java.base/share/classes/java/lang/Compiler.java Wed Sep >> 07 13:50:59 2016 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -29,21 +29,18 @@ >> * The {@code Compiler} class is provided to support Java-to-native-code >> * compilers and related services. By design, the {@code Compiler} class >> does >> * nothing; it serves as a placeholder for a JIT compiler implementation. >> + * If no compiler is available, these methods do nothing. >> * >> - *

    When the Java Virtual Machine first starts, it determines if the >> system >> - * property {@code java.compiler} exists. (System properties are >> accessible >> - * through {@link System#getProperty(String)} and {@link >> - * System#getProperty(String, String)}. If so, it is assumed to be the >> name of >> - * a library (with a platform-dependent exact location and type); {@link >> - * System#loadLibrary} is called to load that library. If this loading >> - * succeeds, the function named {@code java_lang_Compiler_start()} in that >> - * library is called. >> - * >> - *

    If no compiler is available, these methods do nothing. >> + * @deprecated JIT compilers and their technologies vary too widely to >> + * be controlled effectively by a standardized interface. As such, many >> + * JIT compiler implementations ignore this interface, and are instead >> + * controllable by implementation-specific mechanisms such as command-line >> + * options. This class is subject to removal in a future version of Java >> SE. >> * >> * @author Frank Yellin >> * @since 1.0 >> */ >> + at Deprecated(since="9", forRemoval=true) >> public final class Compiler { >> private Compiler() {} // don't make instances >> From forax at univ-mlv.fr Wed Sep 14 13:19:41 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 14 Sep 2016 15:19:41 +0200 (CEST) Subject: MethodHandle loop body parameters and Stream.reduce accumulator parameters are not in the same order Message-ID: <929153152.1409018.1473859181630.JavaMail.zimbra@u-pem.fr> Hi everybody, i've just found that the parameters of the body (a MethodHandle) of MethodHandles.countedLoop (both overloads) and iteratedLoop are not in the same order as the accumulator in methods Stream.reduce, given that they conceptually represent the same thing, i think the first two parameters of body should be swapped in countedLoop and iteratedLoop. in Stream: U reduce(U identity, BiFunction accumulator, BinaryOperator combiner) so this is equivalent to value = accumulator(value, element) In MethodHandles: MethodHandle iteratedLoop(MethodHandle iterator, MethodHandle init, MethodHandle body) with value = body(element, value, iterable) it should be value = body(value, element, iterable). Same things for MethodHandle countedLoop(MethodHandle start, MethodHandle end, MethodHandle init, MethodHandle body) it should be value = body(value, index, array); instead of value = body(index, value, array); the other loop combinators do not be to be changed. cheers, R?mi From Roger.Riggs at Oracle.com Wed Sep 14 13:50:34 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Sep 2016 09:50:34 -0400 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: References: Message-ID: <1849efb3-d8de-a885-9e35-d0e3c7afa292@Oracle.com> +1 On 9/14/2016 2:34 AM, Thomas St?fe wrote: > Hi all, > > thanks for the reviews. Here is version two: > > http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ > > > Only cosmetic changes: > - made code pre-c99 compatible > - consistently use dirent64 > - fix indentation in ifs > - removed blank between malloc and cast > > Kind Regards, Thomas > > > > On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu > > wrote: > > Looks good to me. Thank you for fixing this bug! > > Masayoshi > > > > On 9/13/2016 11:49 PM, Thomas St?fe wrote: > > Hi Christoph, thanks for your review! Yes, I can remove the blank. > > Kind Regards, Thomas > > On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph > > > wrote: > Hi Thomas, > > your change looks good. I'm also forwarding this to > i18n-dev as issues in > TimeZone implementation are mostly handled there. > > One remark: Can you take the opportunity to also remove > the blank between > the cast and malloc in line 150: "(struct dirent64 *) > malloc..."? > > Unfortunately I'm no reviewer, so you still need an > official review. > > Best regards > Christoph > > -----Original Message----- > From: core-libs-dev > [mailto:core-libs-dev-bounces at openjdk.java.net > ] On > > Behalf > > Of Thomas St?fe > Sent: Dienstag, 13. September 2016 12:54 > To: Java Core Libs > > Subject: RFR(xs): 8165936: Potential Heap buffer > overflow when seaching > timezone info files > > Dear all, > > please take a look at this small change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8165936- > > > Potential-Heap-buffer- > > overflow-when-seaching-timezone-info-files/webrev.00/webrev/ > > readdir_r is used to iterate over the content of a > system directory, but > the buffer passed to it is too small: Its size should > include the size of > the dirent structure itself (minus the d_name member). > > The fix also now checks the return code of pathconf(), > and if pathconf() > returns an error, falls back to the NAME_MAX compile > time constant. > Finally, it imposes a minimum size for the buffer, > because on older > > System > > V systems NAME_MAX may be surprisingly small and > readdir_r will not check > the output buffer size. I think it is better to err on > the safe side > > here. > > Kind Regards, Thomas > > > From Roger.Riggs at Oracle.com Wed Sep 14 14:27:33 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Sep 2016 10:27:33 -0400 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> Message-ID: <2a38fec0-3fab-9f98-6dbf-cb2d7c538568@Oracle.com> Hi Chris, Thanks for the review and comments... On 9/14/2016 5:46 AM, Chris Hegarty wrote: > On 08/09/16 20:09, Roger Riggs wrote: >> Please review updates to the Serialization filtering API and >> implementation: >> - The ObjectInputFilter pattern based filters support matching on >> module names as well as package and class names. >> - Rename of system property and java.security property for >> configurable filters. (jdk.serialFilter) >> - ObjectInputFilter clarifications about the values passed to the >> filter >> - Javadoc editorial improvements >> - Clarification of SerializablePermission description of targets >> >> - More tests >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ > > This looks very good Roger, just a few comments: > > 1) The pattern separator in the java.security file should be ';' > Right? > 925 #jdk.serialFilter=pattern,pattern Good catch, will fix > ^^^ > > 2) A question on the expected usage. During the initialization of > OIS the process-wide filter is cached in an instance field, > 'serialFilter'. A subsequent change to the process-wide filter > will not affect the OIS instance. I think this is ok, just > checking the expected usage, as the example in the OIF class > description reads the process-wide filter ever time. Maybe > the example should be changed slightly to not promote this type > of usage? Maybe just remove the call to getSerialFilter? The process-wide filter is set-once, so it can't change. (ObjectInputFilter.setSerialFilter()) The caching in OIS as a final field allows some optimizations; Client code as in the example could do the same for performance reasons. > > 3) Are third-party OIS implementations required, or expected, to > "callback" to the filter? The spec, of course, would appear to > allow it, but not require it? Just wondering if this is required, > or not, as it is not clear to me. Practically, I don't think it can be required; but is encouraged. Thanks, Roger > > -Chris. > > >> SpecDiff: >> http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html >> >> Javadoc (subset) >> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html >> >> >> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html >> >> >> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html >> >> >> >> Thanks, Roger >> >> >> From naoto.sato at oracle.com Wed Sep 14 14:58:48 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 14 Sep 2016 07:58:48 -0700 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: <1849efb3-d8de-a885-9e35-d0e3c7afa292@Oracle.com> References: <1849efb3-d8de-a885-9e35-d0e3c7afa292@Oracle.com> Message-ID: +1 Naoto On 9/14/16 6:50 AM, Roger Riggs wrote: > +1 > > On 9/14/2016 2:34 AM, Thomas St?fe wrote: >> Hi all, >> >> thanks for the reviews. Here is version two: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ >> >> >> Only cosmetic changes: >> - made code pre-c99 compatible >> - consistently use dirent64 >> - fix indentation in ifs >> - removed blank between malloc and cast >> >> Kind Regards, Thomas >> >> >> >> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu >> > wrote: >> >> Looks good to me. Thank you for fixing this bug! >> >> Masayoshi >> >> >> >> On 9/13/2016 11:49 PM, Thomas St?fe wrote: >> >> Hi Christoph, thanks for your review! Yes, I can remove the blank. >> >> Kind Regards, Thomas >> >> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph >> >> >> wrote: >> Hi Thomas, >> >> your change looks good. I'm also forwarding this to >> i18n-dev as issues in >> TimeZone implementation are mostly handled there. >> >> One remark: Can you take the opportunity to also remove >> the blank between >> the cast and malloc in line 150: "(struct dirent64 *) >> malloc..."? >> >> Unfortunately I'm no reviewer, so you still need an >> official review. >> >> Best regards >> Christoph >> >> -----Original Message----- >> From: core-libs-dev >> [mailto:core-libs-dev-bounces at openjdk.java.net >> ] On >> >> Behalf >> >> Of Thomas St?fe >> Sent: Dienstag, 13. September 2016 12:54 >> To: Java Core Libs > > >> Subject: RFR(xs): 8165936: Potential Heap buffer >> overflow when seaching >> timezone info files >> >> Dear all, >> >> please take a look at this small change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >> >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8165936- >> >> >> Potential-Heap-buffer- >> >> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >> >> readdir_r is used to iterate over the content of a >> system directory, but >> the buffer passed to it is too small: Its size should >> include the size of >> the dirent structure itself (minus the d_name member). >> >> The fix also now checks the return code of pathconf(), >> and if pathconf() >> returns an error, falls back to the NAME_MAX compile >> time constant. >> Finally, it imposes a minimum size for the buffer, >> because on older >> >> System >> >> V systems NAME_MAX may be surprisingly small and >> readdir_r will not check >> the output buffer size. I think it is better to err on >> the safe side >> >> here. >> >> Kind Regards, Thomas >> >> >> > From henry.jen at oracle.com Wed Sep 14 16:05:47 2016 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 14 Sep 2016 09:05:47 -0700 Subject: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information In-Reply-To: <652df729-1be5-cadd-f32e-00e51ee28c3b@oracle.com> References: <652df729-1be5-cadd-f32e-00e51ee28c3b@oracle.com> Message-ID: Well, comments about -Xcomp and -Xusealtsigs doesn?t seem to require a change, are we good on this webrev? Let me know if there is anything need to change, otherwise, I would need official +1 from reviewers. :) Cheers, Henry On September 8, 2016 at 10:39:13 PM, Alan Bateman (alan.bateman at oracle.com) wrote: > > > On 08/09/2016 20:52, Henry Jen wrote: > > Hi, > > > > Please review a trivial fix for bug 8042148 at following URL: > > Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042148 > > > > > The ordering/re-wording looks okay, just surprised to see -Xcomp added > (I realize the `java -X` output has listed -Xint and -Xmixed for a long > time). > > -Alan > From brent.christian at oracle.com Wed Sep 14 16:38:39 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 14 Sep 2016 09:38:39 -0700 Subject: Review Request: JDK-8157464: StackWalker.getCallerClass() is not In-Reply-To: <6F189334-AEC8-4C7D-A611-EA26711880FD@oracle.com> References: <3C905A04-5FEF-4C2F-99D3-513E754E454C@oracle.com> <57D88730.8000003@oracle.com> <6F189334-AEC8-4C7D-A611-EA26711880FD@oracle.com> Message-ID: <57D97D0F.2010007@oracle.com> Thanks, Mandy - sounds fine. webrev.03 all looks good to me. -Brent On 09/13/2016 05:04 PM, Mandy Chung wrote: > Yes that?s one option. > > JVM_STACKWALK_FILL_CLASS_REFS_ONLY is not necessarily used to get caller class. For example, AccessControlContext is interested in protection domains. We could build a specialized impl class to walk the stack fetching Class only whereas getCallerClass will stop walking after a few top frames. So a different bit will enable future experiment. Having said that, the assert should be reverted and minor adjustment: > > @@ -140,6 +143,13 @@ > fill_stackframe(stackFrame, method, bci); > } else { > assert (use_frames_array(mode) == false, "Bad mode for get caller class"); > + if (get_caller_class(mode) && index == start_index && method->caller_sensitive()) { > + ResourceMark rm(THREAD); > + THROW_MSG_0(vmSymbols::java_lang_UnsupportedOperationException(), > + err_msg("StackWalker::getCallerClass called from @CallerSensitive %s method", > + method->name_and_sig_as_C_string())); > + } > + > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.03/ > > Mandy > >> On Sep 13, 2016, at 4:09 PM, Brent Christian wrote: >> >> Hi, Mandy >> >> Is a new JVM_STACKWALK_GET_CALLER_CLASS bit needed in jvm.h? AFAICT, JVM_STACKWALK_FILL_CLASS_REFS_ONLY is already only set for the getCallerClass() case. >> >> Could the new get_caller_class() instead check if JVM_STACKWALK_FILL_CLASS_REFS_ONLY is set? (Yes, this would be a third function checking the same thing, along with need_method_info() and use_frames_array()...) >> >> -Brent >> On 09/13/2016 03:18 PM, Mandy Chung wrote: >>> Hi Daniel, >>> >>> StackWalker::getCallerClass is a convenient method to find the caller class and is specified to skip the hidden frames (that?s the caller we are interested in). Since StackWalker only asks VM to fill in classes, the library can?t tell if it?s an anonymous class or not. >>> >>> Your question prompts me to revise the patch and simply skip the hidden frame if this stack walk is to lookup caller class to match the specification. I think this is a better fix: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.02/ >>> >>> We may re-examine this in the future if getCallerClass should get MemberName like the walk method such that we can determine if it?s a hidden frame and the performance difference. >>> >>> Mandy >>> >>>> On Sep 13, 2016, at 11:54 AM, Daniel Fuchs wrote: >>>> >>>> Hi Mandy, >>>> >>>> This looks good to me. >>>> But I wonder about these 5 lines - isn't this introducing a change >>>> of behavior if the caller is an anonymous class? >>>> >>>> 149 InstanceKlass* ik = method->method_holder(); >>>> 150 if (ik->is_anonymous()) { >>>> 151 // use the host class as the caller class >>>> 152 ik = ik->host_klass(); >>>> 153 } >>>> >>>> What is the reason for returning the host class instead? >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 13/09/16 19:24, Mandy Chung wrote: >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.01 >>>>> >>>>> This revises the proposal posted some time ago [1]. >>>>> >>>>> StackWalker::getCallerClass is a convenient method to find the caller class. It will return the invoker of the MethodHandle and java.lang.reflect.Method for the method calling StackWalker::getCallerClass, as it?s currently specified. >>>>> >>>>> This issue is related to MethodHandle for @CallerSensitive method. It behaves as if the caller is the lookup class and in the current implementation, the actual caller class is not the lookup class but a generated class. >>>>> >>>>> One intended usage of StackWalker::getCallerClass is to be called by library code acting as an agent that calls @CallerSensitive method on behalf of the true caller and typically it will call an appropriate method with the appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader). >>>>> >>>>> Given that StackWalker::getCallerClass is not expected to be used by any @CS method, this patch proposes to catch and throw an exception if StackWalker::getCallerClass is called by a @CS method. This will allow time to revisit this when such need is identified. >>>>> >>>>> thanks >>>>> Mandy >>>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042345.html >>>>> >>>> >>> >> > From joe.darcy at oracle.com Wed Sep 14 17:07:58 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 14 Sep 2016 10:07:58 -0700 Subject: JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed Message-ID: Hello, Until JDK-8165988 is fixed, the test sun/net/www/protocol/jar/JarURLConnectionUseCaches.java should be problem listed on windows. Please review the patch below. Thanks, -Joe --- a/test/ProblemList.txt Wed Sep 14 07:37:15 2016 -0700 +++ b/test/ProblemList.txt Wed Sep 14 10:03:29 2016 -0700 @@ -159,7 +159,6 @@ # jdk_net - java/net/MulticastSocket/NoLoopbackPackets.java 7122846 macosx-all java/net/MulticastSocket/SetLoopbackMode.java 7122846 macosx-all @@ -173,6 +172,8 @@ java/net/httpclient/http2/ErrorTest.java 8158127 solaris-all,windows-all java/net/httpclient/http2/TLSConnection.java 8157482 macosx-all +sun/net/www/protocol/jar/JarURLConnectionUseCaches.java 8165988 windows-all + ############################################################################ # jdk_nio From daniel.fuchs at oracle.com Wed Sep 14 17:09:54 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Sep 2016 18:09:54 +0100 Subject: JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed In-Reply-To: References: Message-ID: Hi Joe, Looks good to me! -- daniel On 14/09/16 18:07, joe darcy wrote: > Hello, > > Until JDK-8165988 is fixed, the test > > sun/net/www/protocol/jar/JarURLConnectionUseCaches.java > > should be problem listed on windows. Please review the patch below. > > Thanks, > > -Joe > > --- a/test/ProblemList.txt Wed Sep 14 07:37:15 2016 -0700 > +++ b/test/ProblemList.txt Wed Sep 14 10:03:29 2016 -0700 > @@ -159,7 +159,6 @@ > > # jdk_net > > - > java/net/MulticastSocket/NoLoopbackPackets.java 7122846 macosx-all > java/net/MulticastSocket/SetLoopbackMode.java 7122846 macosx-all > > @@ -173,6 +172,8 @@ > java/net/httpclient/http2/ErrorTest.java 8158127 solaris-all,windows-all > java/net/httpclient/http2/TLSConnection.java 8157482 macosx-all > > +sun/net/www/protocol/jar/JarURLConnectionUseCaches.java 8165988 > windows-all > + > ############################################################################ > > > # jdk_nio > From Roger.Riggs at Oracle.com Wed Sep 14 17:15:28 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Sep 2016 13:15:28 -0400 Subject: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9 In-Reply-To: <229369b5-1762-6d01-dabf-407c3fc7b17f@oracle.com> References: <57D8D6B7.8040900@oracle.com> <229369b5-1762-6d01-dabf-407c3fc7b17f@oracle.com> Message-ID: <464f0f81-759b-7749-efbc-f06a93924f9f@Oracle.com> Hi, I don't see there is much point in deprecating an API that is not exported. It doesn't show up in the javadoc and the compiler overrides with -addexports would already be needed. The internal uses should be updated but that should not be a reason to put off warning other consumers that a transition to another API is needed. One of the purposes of @deprecated is to start a very slow/long process moving. $.02, Roger On 9/14/2016 5:11 AM, Daniel Fuchs wrote: > Hi Joe, > > As much as I would like to support removing obsolete > classes, I wonder if the forRemoval=true is a bit > premature. > > I see that for instance, com.sun.org.apache.xml.internal.resolver.Catalog > seems to be still used at many places in our code base. > > It would be more convincing if we could first make our > own codebase stop using these classes: then we could > be confident that forRemoval=true is the better choice! > > best regards, > > -- daniel > > On 14/09/16 05:48, Joe Wang wrote: >> Hi, >> >> Please review the deprecation of the internal Catalog API. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ >> >> Thanks, >> Joe > From stuart.marks at oracle.com Wed Sep 14 17:18:31 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 14 Sep 2016 10:18:31 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> Message-ID: <50807af7-e002-780c-6446-4de22077e5d2@oracle.com> Hi Kris, Based on your email earlier in this thread, it seemed like you didn't object to deprecating j.l.Compiler in Java 9. Since the other respondents were already in favor, I've already pushed the changeset. (Sorry.) As things stand, the changeset is in the jdk9/dev forest, but it's not in any promoted JDK 9 builds. If we were to proceed with this as it stands, then the API change in Java SE 9 visible to programs will merely be the addition of the following annotation to java.lang.Compiler: @Deprecated(since="9", forRemoval=true) Existing binaries use j.l.Compiler will continue to run, and existing sources that use it can still compile, though they will get compilation warnings. The earliest release in which java.lang.Compiler would actually be absent is Java SE 10. There is currently no schedule or project for SE 10, but I would guess that it wouldn't ship anytime before mid-2018. If removal in this time frame is really a problem for Azul, then I suppose this deprecation can be revisited and possibly changed in Java SE 9. But I'm hard pressed to see what value is actually being added by java.lang.Compiler that can't be done better by a platform-specific API. You mentioned the command() method: public staticObject command(Object any) Anything that uses this API is platform-specific. Even if it avoids platform-specific types, for example by using String arrays, the values it passes and returns are unavoidably platform-specific. Users of this API would be better served by using a platform-specific API. Can't Azul create one and migrate to it? s'marks On 9/13/16 5:09 PM, Krystal Mok wrote: > Hi OpenJDK developers, > > Replying on behalf of Azul Systems: > > java.lang.Compiler is an integral part of the current Java SE spec, and is > currently being used by multiple independent Java SE implementations of that > spec in a spec-conforming way (Azul Zing, Azul Vega, and IBM J9 being concrete > exampleS). Before deprecation, a proposed replacement for Java SE 9 would need > to be vetted to make sure that is satisfies the needs of current > implementations. While JEP165 is a start in that direction, it appears to be > very HotSpot specific, and is not written in a specification form (e.g. there > is no "If no compiler is available, these methods do nothing." mention). > > For example, Azul Zing?s ReadyNow feature makes use of the java.lang.Compiler > API to allow applications to pass directives down to the VM, in a similar > spirit to what IBM J9 does with the API. We continuously evolve and enrich the > commands we support in the API, e.g. in the ?Object command(Object)? method, > and it would be potentially problematic for us to lose the current API without > having a flexible replacement in the Java SE spec. > > As such, we suggest that for the time being, java.lang.Compiler should be > neither depracated nor removed in Java SE 9. As a practical spec'ed > replacement is proposed that will cover the needs of implementations currently > using java.lang.Compiler, this can change. Perhaps in the Java SE 10 timeframe. > > Thanks, > Kris (OpenJDK username: kmo) > > On Wed, Sep 7, 2016 at 1:52 PM, Stuart Marks > wrote: > > Hi all, > > Please review this small patch to deprecate java.lang.Compiler for removal. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1473281459 25200 > # Wed Sep 07 13:50:59 2016 -0700 > # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d > # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c > 4285505: deprecate java.lang.Compiler > Reviewed-by: XXX > > diff -r 76ba1b74f268 -r e520c4e6970c > src/java.base/share/classes/java/lang/Compiler.java > --- a/src/java.base/share/classes/java/lang/Compiler.java Tue Sep 06 > 16:08:54 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/Compiler.java Wed Sep 07 > 13:50:59 2016 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -29,21 +29,18 @@ > * The {@code Compiler} class is provided to support Java-to-native-code > * compilers and related services. By design, the {@code Compiler} class does > * nothing; it serves as a placeholder for a JIT compiler implementation. > + * If no compiler is available, these methods do nothing. > * > - *

    When the Java Virtual Machine first starts, it determines if the > system > - * property {@code java.compiler} exists. (System properties are accessible > - * through {@link System#getProperty(String)} and {@link > - * System#getProperty(String, String)}. If so, it is assumed to be the > name of > - * a library (with a platform-dependent exact location and type); {@link > - * System#loadLibrary} is called to load that library. If this loading > - * succeeds, the function named {@code java_lang_Compiler_start()} in that > - * library is called. > - * > - *

    If no compiler is available, these methods do nothing. > + * @deprecated JIT compilers and their technologies vary too widely to > + * be controlled effectively by a standardized interface. As such, many > + * JIT compiler implementations ignore this interface, and are instead > + * controllable by implementation-specific mechanisms such as command-line > + * options. This class is subject to removal in a future version of Java SE. > * > * @author Frank Yellin > * @since 1.0 > */ > + at Deprecated(since="9", forRemoval=true) > public final class Compiler { > private Compiler() {} // don't make instances > > From kumar.x.srinivasan at oracle.com Wed Sep 14 17:35:29 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 14 Sep 2016 10:35:29 -0700 Subject: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information In-Reply-To: References: <652df729-1be5-cadd-f32e-00e51ee28c3b@oracle.com> Message-ID: <57D98A61.6030502@oracle.com> Henry, Thanks for taking care of this, if the VM team is happy with it. I am good, consider me as reviewer. Thanks Kumar > Well, comments about -Xcomp and -Xusealtsigs doesn?t seem to require a change, are we good on this webrev? > > Let me know if there is anything need to change, otherwise, I would need official +1 from reviewers. :) > > Cheers, > Henry > > On September 8, 2016 at 10:39:13 PM, Alan Bateman (alan.bateman at oracle.com) wrote: >> >> >> On 08/09/2016 20:52, Henry Jen wrote: >>> Hi, >>> >>> Please review a trivial fix for bug 8042148 at following URL: >>> Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042148 >>> >>> >> The ordering/re-wording looks okay, just surprised to see -Xcomp added >> (I realize the `java -X` output has listed -Xint and -Xmixed for a long >> time). >> >> -Alan >> From rob.mckenna at oracle.com Wed Sep 14 17:52:44 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 14 Sep 2016 18:52:44 +0100 Subject: JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed In-Reply-To: References: Message-ID: <20160914175244.GI5356@vimes> Sorry Joe, This passed just fine in jprt. I'll change it to othervm now. (I only noticed this problem on 8 last night) -Rob On 14/09/16 06:09, Daniel Fuchs wrote: > Hi Joe, > > Looks good to me! > > -- daniel > > On 14/09/16 18:07, joe darcy wrote: > >Hello, > > > >Until JDK-8165988 is fixed, the test > > > > sun/net/www/protocol/jar/JarURLConnectionUseCaches.java > > > >should be problem listed on windows. Please review the patch below. > > > >Thanks, > > > >-Joe > > > >--- a/test/ProblemList.txt Wed Sep 14 07:37:15 2016 -0700 > >+++ b/test/ProblemList.txt Wed Sep 14 10:03:29 2016 -0700 > >@@ -159,7 +159,6 @@ > > > > # jdk_net > > > >- > > java/net/MulticastSocket/NoLoopbackPackets.java 7122846 macosx-all > > java/net/MulticastSocket/SetLoopbackMode.java 7122846 macosx-all > > > >@@ -173,6 +172,8 @@ > > java/net/httpclient/http2/ErrorTest.java 8158127 solaris-all,windows-all > > java/net/httpclient/http2/TLSConnection.java 8157482 macosx-all > > > >+sun/net/www/protocol/jar/JarURLConnectionUseCaches.java 8165988 > >windows-all > >+ > > ############################################################################ > > > > > > # jdk_nio > > > From mandy.chung at oracle.com Wed Sep 14 18:32:47 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 14 Sep 2016 11:32:47 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: <23D4FB21-E8A4-400E-AC56-A946D0D95709@oracle.com> References: <8E7A5A0F-1789-43B5-AA88-AA3FBC57C267@oracle.com> <23D4FB21-E8A4-400E-AC56-A946D0D95709@oracle.com> Message-ID: <270759B0-3B61-46C1-B127-8B36499BA0EA@oracle.com> > On Sep 13, 2016, at 5:52 PM, Steve Drach wrote: > > The latest web revs. Answers to questions in-line below: > > http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/ > > http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ This looks pretty good. My main comment is in VersionHelper (see below). ClassFileReader.java 337 String[] msg = {"err.multirelease.option.exists", f.getName()}; 389 String[] msg = {"err.multirelease.jar.malformed?, 390 jarfile.getName(), rn 391 }; `msg` is not used. These lines can be removed. line 81-95: this wants to add to VersionHelper if it?s a versioned entry. I suggest to move this to VersionHelper, something like this and replace the add method. public static void addIfVersionedEntry(Path jarfile, String realEntryName, String className) { if (realEntryName.startsWith(META_INF_VERSIONS)) { int len = META_INF_VERSIONS.length(); int n = realEntryName.indexOf('/', len); if (n > 0) { String version = realEntryName.substring(len, n); assert (Integer.parseInt(version) > 8); String v = versionMap.get(className); if (v != null && !v.equals(version)) { // name associated with a different ClassFile throw new MultiReleaseException("err.multirelease.version.associated", className, v, version); } versionMap.put(className, version); } else { throw new MultiReleaseException("err.multirelease.jar.malformed", jarfile.toString(), realEntryName); } } } I prefer to call String::length rather than hardcoding the length. I don?t see why VersionHelper caches ClassFile. I think it can cache a map from class name to the version for now. We may have to handle duplicated classes in more than one modular jar (it?s not exported and should be allowed). We could file a separate issue to look into later. This needs a CCC for the new --multi-release option. Mandy From huizhe.wang at oracle.com Wed Sep 14 19:09:31 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 14 Sep 2016 12:09:31 -0700 Subject: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9 In-Reply-To: <464f0f81-759b-7749-efbc-f06a93924f9f@Oracle.com> References: <57D8D6B7.8040900@oracle.com> <229369b5-1762-6d01-dabf-407c3fc7b17f@oracle.com> <464f0f81-759b-7749-efbc-f06a93924f9f@Oracle.com> Message-ID: <57D9A06B.3050108@oracle.com> Hi Daniel, Roger, Thanks for the review! The webrev is updated as we discussed. The deprecation message is in the main interface classes but stresses that the entire application under the resolver package and the util class (XMLCatalogResolver.java) are deprecated and subject to removal in a future release. http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ As you noted, there's an internal usage in jaxws/jaxb. Aleksej and I have worked together to get the standalone updated with the new Catalog API. The JDK integration will happen soon. The deprecation is not technically necessary for an internal API. Even without the JDK 9 encapsulation, the compiler has always produced a warning that the internal API is subject to change/removal, and should not be directly referenced. Unfortunately, this particular one is in a awkward situation. It was integrated along with jaxp from the Apache library without a public API. Internal and external users are therefore taken it as if it's okay to use. The encapsulation could be viewed similarly as the existing compiler warning. The deprecation message therefore serves as an enforcement that it is indeed in the plan to be removed. Best, Joe On 9/14/16, 10:15 AM, Roger Riggs wrote: > Hi, > > I don't see there is much point in deprecating an API that is not > exported. > It doesn't show up in the javadoc and the compiler overrides with > -addexports would already be needed. > > The internal uses should be updated but that should not be a reason to > put off warning other > consumers that a transition to another API is needed. One of the > purposes of @deprecated is to start > a very slow/long process moving. > > $.02, Roger > > > On 9/14/2016 5:11 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> As much as I would like to support removing obsolete >> classes, I wonder if the forRemoval=true is a bit >> premature. >> >> I see that for instance, >> com.sun.org.apache.xml.internal.resolver.Catalog >> seems to be still used at many places in our code base. >> >> It would be more convincing if we could first make our >> own codebase stop using these classes: then we could >> be confident that forRemoval=true is the better choice! >> >> best regards, >> >> -- daniel >> >> On 14/09/16 05:48, Joe Wang wrote: >>> Hi, >>> >>> Please review the deprecation of the internal Catalog API. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ >>> >>> Thanks, >>> Joe >> > From daniel.fuchs at oracle.com Wed Sep 14 19:25:34 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Sep 2016 20:25:34 +0100 Subject: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9 In-Reply-To: <57D9A06B.3050108@oracle.com> References: <57D8D6B7.8040900@oracle.com> <229369b5-1762-6d01-dabf-407c3fc7b17f@oracle.com> <464f0f81-759b-7749-efbc-f06a93924f9f@Oracle.com> <57D9A06B.3050108@oracle.com> Message-ID: <7c36d272-32b9-de6e-1e20-d340f5e83f70@oracle.com> On 14/09/16 20:09, Joe Wang wrote: > Hi Daniel, Roger, > > Thanks for the review! > > The webrev is updated as we discussed. The deprecation message is in the > main interface classes but stresses that the entire application under > the resolver package and the util class (XMLCatalogResolver.java) are > deprecated and subject to removal in a future release. > > http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ This looks good to me Joe! Thanks for the detailed explanations. +1 -- daniel > > > As you noted, there's an internal usage in jaxws/jaxb. Aleksej and I > have worked together to get the standalone updated with the new Catalog > API. The JDK integration will happen soon. > > The deprecation is not technically necessary for an internal API. Even > without the JDK 9 encapsulation, the compiler has always produced a > warning that the internal API is subject to change/removal, and should > not be directly referenced. Unfortunately, this particular one is in a > awkward situation. It was integrated along with jaxp from the Apache > library without a public API. Internal and external users are therefore > taken it as if it's okay to use. The encapsulation could be viewed > similarly as the existing compiler warning. The deprecation message > therefore serves as an enforcement that it is indeed in the plan to be > removed. > > Best, > Joe > > On 9/14/16, 10:15 AM, Roger Riggs wrote: >> Hi, >> >> I don't see there is much point in deprecating an API that is not >> exported. >> It doesn't show up in the javadoc and the compiler overrides with >> -addexports would already be needed. >> >> The internal uses should be updated but that should not be a reason to >> put off warning other >> consumers that a transition to another API is needed. One of the >> purposes of @deprecated is to start >> a very slow/long process moving. >> >> $.02, Roger >> >> >> On 9/14/2016 5:11 AM, Daniel Fuchs wrote: >>> Hi Joe, >>> >>> As much as I would like to support removing obsolete >>> classes, I wonder if the forRemoval=true is a bit >>> premature. >>> >>> I see that for instance, >>> com.sun.org.apache.xml.internal.resolver.Catalog >>> seems to be still used at many places in our code base. >>> >>> It would be more convincing if we could first make our >>> own codebase stop using these classes: then we could >>> be confident that forRemoval=true is the better choice! >>> >>> best regards, >>> >>> -- daniel >>> >>> On 14/09/16 05:48, Joe Wang wrote: >>>> Hi, >>>> >>>> Please review the deprecation of the internal Catalog API. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ >>>> >>>> Thanks, >>>> Joe >>> >> From huizhe.wang at oracle.com Wed Sep 14 20:19:04 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 14 Sep 2016 13:19:04 -0700 Subject: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9 In-Reply-To: <7c36d272-32b9-de6e-1e20-d340f5e83f70@oracle.com> References: <57D8D6B7.8040900@oracle.com> <229369b5-1762-6d01-dabf-407c3fc7b17f@oracle.com> <464f0f81-759b-7749-efbc-f06a93924f9f@Oracle.com> <57D9A06B.3050108@oracle.com> <7c36d272-32b9-de6e-1e20-d340f5e83f70@oracle.com> Message-ID: <57D9B0B8.8090100@oracle.com> Thanks again, Daniel! Joe On 9/14/16, 12:25 PM, Daniel Fuchs wrote: > On 14/09/16 20:09, Joe Wang wrote: >> Hi Daniel, Roger, >> >> Thanks for the review! >> >> The webrev is updated as we discussed. The deprecation message is in the >> main interface classes but stresses that the entire application under >> the resolver package and the util class (XMLCatalogResolver.java) are >> deprecated and subject to removal in a future release. >> >> http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ > > This looks good to me Joe! > Thanks for the detailed explanations. > > +1 > > -- daniel > >> >> >> As you noted, there's an internal usage in jaxws/jaxb. Aleksej and I >> have worked together to get the standalone updated with the new Catalog >> API. The JDK integration will happen soon. >> >> The deprecation is not technically necessary for an internal API. Even >> without the JDK 9 encapsulation, the compiler has always produced a >> warning that the internal API is subject to change/removal, and should >> not be directly referenced. Unfortunately, this particular one is in a >> awkward situation. It was integrated along with jaxp from the Apache >> library without a public API. Internal and external users are therefore >> taken it as if it's okay to use. The encapsulation could be viewed >> similarly as the existing compiler warning. The deprecation message >> therefore serves as an enforcement that it is indeed in the plan to be >> removed. >> >> Best, >> Joe >> >> On 9/14/16, 10:15 AM, Roger Riggs wrote: >>> Hi, >>> >>> I don't see there is much point in deprecating an API that is not >>> exported. >>> It doesn't show up in the javadoc and the compiler overrides with >>> -addexports would already be needed. >>> >>> The internal uses should be updated but that should not be a reason to >>> put off warning other >>> consumers that a transition to another API is needed. One of the >>> purposes of @deprecated is to start >>> a very slow/long process moving. >>> >>> $.02, Roger >>> >>> >>> On 9/14/2016 5:11 AM, Daniel Fuchs wrote: >>>> Hi Joe, >>>> >>>> As much as I would like to support removing obsolete >>>> classes, I wonder if the forRemoval=true is a bit >>>> premature. >>>> >>>> I see that for instance, >>>> com.sun.org.apache.xml.internal.resolver.Catalog >>>> seems to be still used at many places in our code base. >>>> >>>> It would be more convincing if we could first make our >>>> own codebase stop using these classes: then we could >>>> be confident that forRemoval=true is the better choice! >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 14/09/16 05:48, Joe Wang wrote: >>>>> Hi, >>>>> >>>>> Please review the deprecation of the internal Catalog API. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 >>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ >>>>> >>>>> Thanks, >>>>> Joe >>>> >>> > From patrick at reini.net Wed Sep 14 20:55:37 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 14 Sep 2016 22:55:37 +0200 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> Message-ID: <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> Hi Jonathan, Here are your changes in a webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 -Patrick > Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : > > Hi Jonathan, > > On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: >> Hi Patrick, >> Thank you very much for the offer to hold my patch for me! > > No problem. > >> Is it common practice to send patches to others using PGP? > > No, this is my personal setting. > >> Kind regards, >> Jonathan >> On 12 September 2016 at 21:08, Patrick Reinhart wrote: >>> Hi Jonathan, >>> As I just also wanted to help some more clean-up in the JDKs final phase, I >>> could offer you to hold that patch. Just send it to me and I will prepare >>> the webrev for you?. >>> -Patrick > > -Patrick From steve.drach at oracle.com Wed Sep 14 23:06:56 2016 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 14 Sep 2016 16:06:56 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: <270759B0-3B61-46C1-B127-8B36499BA0EA@oracle.com> References: <8E7A5A0F-1789-43B5-AA88-AA3FBC57C267@oracle.com> <23D4FB21-E8A4-400E-AC56-A946D0D95709@oracle.com> <270759B0-3B61-46C1-B127-8B36499BA0EA@oracle.com> Message-ID: The most recent webrev is http://cr.openjdk.java.net/~sdrach/8153654/webrev.11/ Comments inline >> The latest web revs. Answers to questions in-line below: >> >> http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/ >> >> http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ > > This looks pretty good. My main comment is in VersionHelper (see below). > > ClassFileReader.java > > 337 String[] msg = {"err.multirelease.option.exists", f.getName()}; > 389 String[] msg = {"err.multirelease.jar.malformed?, > 390 jarfile.getName(), rn > 391 }; > > `msg` is not used. These lines can be removed. Done > > line 81-95: this wants to add to VersionHelper if it?s a versioned entry. I suggest to move this to VersionHelper, something like this and replace the add method. I did essentially the same thing, but not exactly the same. > > public static void addIfVersionedEntry(Path jarfile, String realEntryName, String className) { > if (realEntryName.startsWith(META_INF_VERSIONS)) { > int len = META_INF_VERSIONS.length(); > int n = realEntryName.indexOf('/', len); > if (n > 0) { > String version = realEntryName.substring(len, n); > assert (Integer.parseInt(version) > 8); > > String v = versionMap.get(className); > if (v != null && !v.equals(version)) { > // name associated with a different ClassFile > throw new MultiReleaseException("err.multirelease.version.associated", className, > v, version); > } > versionMap.put(className, version); > } else { > throw new MultiReleaseException("err.multirelease.jar.malformed", > jarfile.toString(), realEntryName); > } > } > } > > I prefer to call String::length rather than hardcoding the length. OK > I don?t see why VersionHelper caches ClassFile. A JarEntry (base) name has a one to many relationship with versions. This implies the class name also has a one to many relationship with versions. But a ClassFile (derived from the contents of the JarEntry) has a one to one relationship with version. We desire a one to one relationship for className to version and one way to assure that is to create two maps as I now have done. I think the code is more obvious now, at least I hope it is. > I think it can cache a map from class name to the version for now. We may have to handle duplicated classes in more than one modular jar (it?s not exported and should be allowed). We could file a separate issue to look into later. > > This needs a CCC for the new --multi-release option. That?s next. > > Mandy From manju.jccs at gmail.com Thu Sep 15 06:36:51 2016 From: manju.jccs at gmail.com (Manjunath SV) Date: Thu, 15 Sep 2016 12:06:51 +0530 Subject: Fwd: Reg - Sub Process creation from java takes more time In-Reply-To: References: Message-ID: Hi All, I am Manjunath, We are facing below issue in Java application. Issue Details :- Java application has a thread pool of size 30, When it receives Job message from JMS, It creates around 200+ jobs and submit into thread pool,initially 30 threads creates shell script process very quick, later process creation time gradually increases (5-9 mins). Java application invokes shell script, Below is the code. process = Runtime.getRuntime().exec(new String[] { script_name, param1, param2, param3,param4 }); int response = process.waitFor(); Shell script :- #!/bin/ksh linux-command -un $1 -pw $2 -f batch.txt < $3 > $4 2>&1 We redirected command output and errors to a file. First job execution after application restart takes just 15 sec, later job execution takes around 15 mins, some times 40 mins also. We are using java 1.8.0_92. Please advise on this. Thanks in advance. Regards, Manjunath From shade at redhat.com Thu Sep 15 06:42:30 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 15 Sep 2016 08:42:30 +0200 Subject: RFC: System.console().encoding() Message-ID: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> Hi, Claes pointed out that our own reflective hacks to figure out console encoding do not work anymore [1]. But, we need the console encoding for reliably printing on the console from within different sources. Note that you would normally just use System.console() and its PrintWriter, but reality is a bit more complicated, and sometimes you need to write the plain char stream directly into the byte[]-accepting methods, encoding on your own. So, my question: should we, in the light of extended Jigsaw-solving crunch, provide the public Console.encoding() method that would return the console charset? Thanks, -Aleksey [1] http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html From dawid.weiss at gmail.com Thu Sep 15 06:55:45 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 15 Sep 2016 08:55:45 +0200 Subject: RFC: System.console().encoding() In-Reply-To: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> Message-ID: +1 for adding a public Console.encoding(). I remember needing it as well, the current hacks are very ugly. Dawid On Thu, Sep 15, 2016 at 8:42 AM, Aleksey Shipilev wrote: > Hi, > > Claes pointed out that our own reflective hacks to figure out console > encoding do not work anymore [1]. But, we need the console encoding for > reliably printing on the console from within different sources. Note > that you would normally just use System.console() and its PrintWriter, > but reality is a bit more complicated, and sometimes you need to write > the plain char stream directly into the byte[]-accepting methods, > encoding on your own. > > So, my question: should we, in the light of extended Jigsaw-solving > crunch, provide the public Console.encoding() method that would return > the console charset? > > Thanks, > -Aleksey > > [1] > http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html > From xueming.shen at oracle.com Thu Sep 15 07:06:05 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 15 Sep 2016 00:06:05 -0700 Subject: RFC: System.console().encoding() In-Reply-To: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> Message-ID: <57DA485D.100@oracle.com> -1 :-) Console is supposed to be a "char/String" based class, "encoding" really should have no business here in its api. Simply for some implementation convenience is really not a good reason to add such a public method. That said, I would be fine to have such informative info in the system properties, together with its siblings, file,encoding and another "supposed to be private" property sun.jnu.encoding. sherman On 9/14/16, 11:42 PM, Aleksey Shipilev wrote: > Hi, > > Claes pointed out that our own reflective hacks to figure out console > encoding do not work anymore [1]. But, we need the console encoding for > reliably printing on the console from within different sources. Note > that you would normally just use System.console() and its PrintWriter, > but reality is a bit more complicated, and sometimes you need to write > the plain char stream directly into the byte[]-accepting methods, > encoding on your own. > > So, my question: should we, in the light of extended Jigsaw-solving > crunch, provide the public Console.encoding() method that would return > the console charset? > > Thanks, > -Aleksey > > [1] > http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html > From dawid.weiss at gmail.com Thu Sep 15 07:21:01 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 15 Sep 2016 09:21:01 +0200 Subject: RFC: System.console().encoding() In-Reply-To: <57DA485D.100@oracle.com> References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> <57DA485D.100@oracle.com> Message-ID: > Console is supposed to be a "char/String" based class, "encoding" really > should have no business here in its api. While I agree with your concerns about the functional side of the API, I disagree about this method having no practical use. I can give you a concrete example. The use case that we had was to check whether the "terminal" (console) would be able to handle non-ASCII characters. A Writer doesn't tell you anything. An encoding does provide at least some confidence that certain characters will be translated properly -- if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't get displayed for sure. This doesn't mean 100% confidence in actual glyph rendering of course, but it's a cheap and safe sanity check of the terminal's capabilities. An (undocumented) proprietary property? Sure, but I really don't see the reason why this shouldn't be in the API, unless you know of terminals that handle Unicode-based streams directly (in which case the encoding method would simply return UTF32). Dawid From claes.redestad at oracle.com Thu Sep 15 08:18:29 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Sep 2016 10:18:29 +0200 Subject: RFC: System.console().encoding() In-Reply-To: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> Message-ID: <57DA5955.4070401@oracle.com> +1 Won't be enough, though, since in JMH it appears you're also getting the encoding from System.out (java.io.PrintStream) via reflective hacks. /Claes On 2016-09-15 08:42, Aleksey Shipilev wrote: > Hi, > > Claes pointed out that our own reflective hacks to figure out console > encoding do not work anymore [1]. But, we need the console encoding for > reliably printing on the console from within different sources. Note > that you would normally just use System.console() and its PrintWriter, > but reality is a bit more complicated, and sometimes you need to write > the plain char stream directly into the byte[]-accepting methods, > encoding on your own. > > So, my question: should we, in the light of extended Jigsaw-solving > crunch, provide the public Console.encoding() method that would return > the console charset? > > Thanks, > -Aleksey > > [1] > http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html > From jbluettduncan at gmail.com Thu Sep 15 08:52:47 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 15 Sep 2016 09:52:47 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> Message-ID: Thanks Patrick! Stuart, would you be happy to sponsor this change? If anyone else has any thoughts regarding this change, then I'm all ears. Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 Rationale for changes: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043484.html Kind regards, Jonathan On 14 September 2016 at 21:55, Patrick Reinhart wrote: > Hi Jonathan, > > Here are your changes in a webrev: > > http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 > > -Patrick > > Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : > > Hi Jonathan, > > On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: > > Hi Patrick, > Thank you very much for the offer to hold my patch for me! > > > No problem. > > Is it common practice to send patches to others using PGP? > > > No, this is my personal setting. > > Kind regards, > Jonathan > On 12 September 2016 at 21:08, Patrick Reinhart wrote: > > Hi Jonathan, > As I just also wanted to help some more clean-up in the JDKs final phase, I > could offer you to hold that patch. Just send it to me and I will prepare > the webrev for you?. > -Patrick > > > -Patrick > > > From ecki at zusammenkunft.net Thu Sep 15 09:01:01 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 15 Sep 2016 11:01:01 +0200 Subject: Reg - Sub Process creation from java takes more time In-Reply-To: References: Message-ID: <57da634c.c336c20a.19b0c.bec8@mx.google.com> Hello, Do you monitor heap usage and virtual memory size of your Java process? I would look out for increase (which causes slower for tines). Also it is generally a good idea to turn on GC logging and look into it if a java process degregades over time Gruss Bernd Just BTW: I think Java would not be the right tool to spawn and control sich a high number of external processes. Maybe it would be better to hand that off to a more native component. -- http://bernd.eckenfels.net Von: Manjunath SV From blackdrag at gmx.org Thu Sep 15 10:05:04 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 15 Sep 2016 12:05:04 +0200 Subject: RFC: System.console().encoding() In-Reply-To: References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> <57DA485D.100@oracle.com> Message-ID: <57DA7250.9020406@gmx.org> On 15.09.2016 09:21, Dawid Weiss wrote: >> Console is supposed to be a "char/String" based class, "encoding" really >> should have no business here in its api. > > While I agree with your concerns about the functional side of the API, > I disagree about this method having no practical use. I can give you a > concrete example. The use case that we had was to check whether the > "terminal" (console) would be able to handle non-ASCII characters. A > Writer doesn't tell you anything. An encoding does provide at least > some confidence that certain characters will be translated properly -- > if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't > get displayed for sure. This doesn't mean 100% confidence in actual > glyph rendering of course, but it's a cheap and safe sanity check of > the terminal's capabilities. out of curiosity... what will you do if you find the encoding lacking what you need? bye Jochen From dawid.weiss at gmail.com Thu Sep 15 10:17:26 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 15 Sep 2016 12:17:26 +0200 Subject: RFC: System.console().encoding() In-Reply-To: <57DA7250.9020406@gmx.org> References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> <57DA485D.100@oracle.com> <57DA7250.9020406@gmx.org> Message-ID: > out of curiosity... what will you do if you find the encoding lacking what > you need? Oh, display a warning. Helps to figure out where those "???" characters are coming from... Naive, I know. But it's the best one can do and it works (most of the time). D. From pavel.rappo at oracle.com Thu Sep 15 10:46:17 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 15 Sep 2016 11:46:17 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> Message-ID: Hi, I have had a look at the change. It looks good. Retrofitting Collections.unmodifiableXXX/Arrays.asList with Convenience Factory Methods requires extra carefulness as the factory methods are stricter than any of those. Not only do they provide unconditional non-modifiability [0], they also do not tolerate `null` elements. It looks like you took all that into account. Tiny little comments and suggestions. 1. It might be the case we no longer need this [1]: finderList.forEach(Objects::requireNonNull); as the List.of does the same thing for free. Though it might be okay to leave it as an explicit check. Also, could you please fix a typo here (the same file): * will be propogated to the caller of the resulting module finder's ^ 2. An interesting question (though it's a completely different issue) is whether or not the `cookieHeader` list in the map should also be unmodifiable [2]? 3. Could you please also fix the same (copy-pasted?) typo in FileTreeWalker? if {@code options} is {@ocde null} or the options ^^ 4. Please remove this line from the ZoneRules constructor's javadoc: @return the zone rules, not null 5. Maybe we should revisit javadoc on those fields in [3]: This List is {@linkplain Collections#unmodifiableList(List) unmodifiable}. Since it's no longer the case. 6. I couldn't find any evidence that `resolverFields` might contain `null`. Am I missing a javadoc or a line of code? Maybe we should talk to java.time folks to see if it's the case? 7. Try to not make lines longer than they were before: 80 characters. Unless it's really needed. Thanks, -Pavel -------------------------------------------------------------------------------- [0] Compare List.of().remove(new Object()) with Collections.emptyList().remove(new Object()) [1] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/lang/module/ModuleFinder.java.sdiff.html [2] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/net/CookieManager.java.sdiff.html [3] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/util/ResourceBundle.java.sdiff.html > On 15 Sep 2016, at 09:52, Jonathan Bluett-Duncan wrote: > > Thanks Patrick! > > Stuart, would you be happy to sponsor this change? > > If anyone else has any thoughts regarding this change, then I'm all ears. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 > Rationale for changes: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043484.html > > Kind regards, > Jonathan > > > On 14 September 2016 at 21:55, Patrick Reinhart wrote: > >> Hi Jonathan, >> >> Here are your changes in a webrev: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 >> >> -Patrick >> >> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : >> >> Hi Jonathan, >> >> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: >> >> Hi Patrick, >> Thank you very much for the offer to hold my patch for me! >> >> >> No problem. >> >> Is it common practice to send patches to others using PGP? >> >> >> No, this is my personal setting. >> >> Kind regards, >> Jonathan >> On 12 September 2016 at 21:08, Patrick Reinhart wrote: >> >> Hi Jonathan, >> As I just also wanted to help some more clean-up in the JDKs final phase, I >> could offer you to hold that patch. Just send it to me and I will prepare >> the webrev for you?. >> -Patrick >> >> >> -Patrick >> >> >> From daniel.fuchs at oracle.com Thu Sep 15 11:06:16 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 15 Sep 2016 12:06:16 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> Message-ID: <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> Hi, I'm not sure I like the replacement of Collections.emptyList() by List.of(); I find emptyList() more expressive (+ it always returns the same instance). best regards, -- daniel On 15/09/16 11:46, Pavel Rappo wrote: > Hi, > > I have had a look at the change. It looks good. > > Retrofitting Collections.unmodifiableXXX/Arrays.asList with Convenience Factory > Methods requires extra carefulness as the factory methods are stricter than any > of those. Not only do they provide unconditional non-modifiability [0], they > also do not tolerate `null` elements. > > It looks like you took all that into account. > Tiny little comments and suggestions. > > 1. It might be the case we no longer need this [1]: > > finderList.forEach(Objects::requireNonNull); > > as the List.of does the same thing for free. Though it might be okay to leave it > as an explicit check. > > Also, could you please fix a typo here (the same file): > > * will be propogated to the caller of the resulting module finder's > ^ > 2. An interesting question (though it's a completely different issue) is whether > or not the `cookieHeader` list in the map should also be unmodifiable [2]? > > 3. Could you please also fix the same (copy-pasted?) typo in FileTreeWalker? > > if {@code options} is {@ocde null} or the options > ^^ > 4. Please remove this line from the ZoneRules constructor's javadoc: > > @return the zone rules, not null > > 5. Maybe we should revisit javadoc on those fields in [3]: > > This List is {@linkplain Collections#unmodifiableList(List) unmodifiable}. > > Since it's no longer the case. > > 6. I couldn't find any evidence that `resolverFields` might contain `null`. > Am I missing a javadoc or a line of code? Maybe we should talk to java.time > folks to see if it's the case? > > 7. Try to not make lines longer than they were before: 80 characters. Unless > it's really needed. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [0] Compare List.of().remove(new Object()) with Collections.emptyList().remove(new Object()) > [1] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/lang/module/ModuleFinder.java.sdiff.html > [2] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/net/CookieManager.java.sdiff.html > [3] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/util/ResourceBundle.java.sdiff.html > >> On 15 Sep 2016, at 09:52, Jonathan Bluett-Duncan wrote: >> >> Thanks Patrick! >> >> Stuart, would you be happy to sponsor this change? >> >> If anyone else has any thoughts regarding this change, then I'm all ears. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 >> Rationale for changes: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043484.html >> >> Kind regards, >> Jonathan >> >> >> On 14 September 2016 at 21:55, Patrick Reinhart wrote: >> >>> Hi Jonathan, >>> >>> Here are your changes in a webrev: >>> >>> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 >>> >>> -Patrick >>> >>> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : >>> >>> Hi Jonathan, >>> >>> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: >>> >>> Hi Patrick, >>> Thank you very much for the offer to hold my patch for me! >>> >>> >>> No problem. >>> >>> Is it common practice to send patches to others using PGP? >>> >>> >>> No, this is my personal setting. >>> >>> Kind regards, >>> Jonathan >>> On 12 September 2016 at 21:08, Patrick Reinhart wrote: >>> >>> Hi Jonathan, >>> As I just also wanted to help some more clean-up in the JDKs final phase, I >>> could offer you to hold that patch. Just send it to me and I will prepare >>> the webrev for you?. >>> -Patrick >>> >>> >>> -Patrick >>> >>> >>> > From scolebourne at joda.org Thu Sep 15 11:21:56 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 15 Sep 2016 12:21:56 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> Message-ID: The date/time changes seem reasonable. Stephen On 14 September 2016 at 21:55, Patrick Reinhart wrote: > Hi Jonathan, > > Here are your changes in a webrev: > > http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 > > -Patrick > >> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : >> >> Hi Jonathan, >> >> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: >>> Hi Patrick, >>> Thank you very much for the offer to hold my patch for me! >> >> No problem. >> >>> Is it common practice to send patches to others using PGP? >> >> No, this is my personal setting. >> >>> Kind regards, >>> Jonathan >>> On 12 September 2016 at 21:08, Patrick Reinhart wrote: >>>> Hi Jonathan, >>>> As I just also wanted to help some more clean-up in the JDKs final phase, I >>>> could offer you to hold that patch. Just send it to me and I will prepare >>>> the webrev for you?. >>>> -Patrick >> >> -Patrick > From pavel.rappo at oracle.com Thu Sep 15 11:32:39 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 15 Sep 2016 12:32:39 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> Message-ID: <8E59D4A4-8A04-4D59-92FF-AA9B6E28C197@oracle.com> Daniel, if you're referring to 388 List getValidOffsets() { 389 if (isGap()) { > 390 return List.of(); 391 } 392 return List.of(getOffsetBefore(), getOffsetAfter()); 393 } I think in this particular case, List.of is more consistent. > On 15 Sep 2016, at 12:06, Daniel Fuchs wrote: > > I find emptyList() more expressive (+ it always returns > the same instance). From claes.redestad at oracle.com Thu Sep 15 11:35:25 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Sep 2016 13:35:25 +0200 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> Message-ID: <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> +1 I don't mind List.of() aesthetically, but there are places where startup/footprint is important where Collections.emptyList() is simply superior, e.g., constituting permanent data structures such as the module graph during early bootstrap. I know there are some drawbacks to the singleton approach of Collections.emptyList() (forces a potentially expensive memory load instead of just quickly allocating something that most likely will be thrown away just as quick), but having a very limited set of known constants for such things should be hard to notice on any workload since they'll be very likely to be in a CPU cache. Also saves having a few extra classes and decreases chances for profile pollution when calling methods with both Collections.emptyList() and List.of(). TL;DR: I think List.of() should be an alias for Collections.emptyList() (same for Set.of() <-> Collections.emptySet(), Map.of() ..). Sorry. :-) /Claes On 2016-09-15 13:06, Daniel Fuchs wrote: > Hi, > > I'm not sure I like the replacement of Collections.emptyList() > by List.of(); > I find emptyList() more expressive (+ it always returns > the same instance). > > best regards, > > -- daniel > > On 15/09/16 11:46, Pavel Rappo wrote: >> Hi, >> >> I have had a look at the change. It looks good. >> >> Retrofitting Collections.unmodifiableXXX/Arrays.asList with >> Convenience Factory >> Methods requires extra carefulness as the factory methods are >> stricter than any >> of those. Not only do they provide unconditional non-modifiability >> [0], they >> also do not tolerate `null` elements. >> >> It looks like you took all that into account. >> Tiny little comments and suggestions. >> >> 1. It might be the case we no longer need this [1]: >> >> finderList.forEach(Objects::requireNonNull); >> >> as the List.of does the same thing for free. Though it might be okay >> to leave it >> as an explicit check. >> >> Also, could you please fix a typo here (the same file): >> >> * will be propogated to the caller of the resulting module finder's >> ^ >> 2. An interesting question (though it's a completely different issue) >> is whether >> or not the `cookieHeader` list in the map should also be unmodifiable >> [2]? >> >> 3. Could you please also fix the same (copy-pasted?) typo in >> FileTreeWalker? >> >> if {@code options} is {@ocde null} or the options >> ^^ >> 4. Please remove this line from the ZoneRules constructor's javadoc: >> >> @return the zone rules, not null >> >> 5. Maybe we should revisit javadoc on those fields in [3]: >> >> This List is {@linkplain >> Collections#unmodifiableList(List) unmodifiable}. >> >> Since it's no longer the case. >> >> 6. I couldn't find any evidence that `resolverFields` might contain >> `null`. >> Am I missing a javadoc or a line of code? Maybe we should talk to >> java.time >> folks to see if it's the case? >> >> 7. Try to not make lines longer than they were before: 80 characters. >> Unless >> it's really needed. >> >> Thanks, >> -Pavel >> >> -------------------------------------------------------------------------------- >> >> [0] Compare List.of().remove(new Object()) with >> Collections.emptyList().remove(new Object()) >> [1] >> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/lang/module/ModuleFinder.java.sdiff.html >> [2] >> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/net/CookieManager.java.sdiff.html >> [3] >> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/util/ResourceBundle.java.sdiff.html >> >>> On 15 Sep 2016, at 09:52, Jonathan Bluett-Duncan >>> wrote: >>> >>> Thanks Patrick! >>> >>> Stuart, would you be happy to sponsor this change? >>> >>> If anyone else has any thoughts regarding this change, then I'm all >>> ears. >>> >>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 >>> Rationale for changes: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043484.html >>> >>> >>> Kind regards, >>> Jonathan >>> >>> >>> On 14 September 2016 at 21:55, Patrick Reinhart >>> wrote: >>> >>>> Hi Jonathan, >>>> >>>> Here are your changes in a webrev: >>>> >>>> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 >>>> >>>> -Patrick >>>> >>>> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : >>>> >>>> Hi Jonathan, >>>> >>>> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: >>>> >>>> Hi Patrick, >>>> Thank you very much for the offer to hold my patch for me! >>>> >>>> >>>> No problem. >>>> >>>> Is it common practice to send patches to others using PGP? >>>> >>>> >>>> No, this is my personal setting. >>>> >>>> Kind regards, >>>> Jonathan >>>> On 12 September 2016 at 21:08, Patrick Reinhart >>>> wrote: >>>> >>>> Hi Jonathan, >>>> As I just also wanted to help some more clean-up in the JDKs final >>>> phase, I >>>> could offer you to hold that patch. Just send it to me and I will >>>> prepare >>>> the webrev for you?. >>>> -Patrick >>>> >>>> >>>> -Patrick >>>> >>>> >>>> >> > From pavel.rappo at oracle.com Thu Sep 15 11:48:51 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 15 Sep 2016 12:48:51 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> Message-ID: <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> Daniel, Claes, List.of() and Collections.emptyList() are not the same. The behaviours are different. Moreover, immutable static factory methods return instances which are value-based. I believe it also means we are not tied with unconditional instantiation, and in case of empty collections/maps could probably return the same object every time. We should ask Stuart why it has been done like that in the first place. Maybe out of concern people might synchronize of those objects? I don't know. Let's say for now it's an implementation-specific detail. > On 15 Sep 2016, at 12:35, Claes Redestad wrote: > > +1 > > I don't mind List.of() aesthetically, but there are places where > startup/footprint is important where Collections.emptyList() > is simply superior, e.g., constituting permanent data structures > such as the module graph during early bootstrap. > > I know there are some drawbacks to the singleton approach of > Collections.emptyList() (forces a potentially expensive memory > load instead of just quickly allocating something that most likely > will be thrown away just as quick), but having a very limited set > of known constants for such things should be hard to notice on > any workload since they'll be very likely to be in a CPU cache. > > Also saves having a few extra classes and decreases chances for > profile pollution when calling methods with both > Collections.emptyList() and List.of(). > > TL;DR: I think List.of() should be an alias for Collections.emptyList() > (same for Set.of() <-> Collections.emptySet(), Map.of() ..). > > Sorry. :-) > > /Claes > > On 2016-09-15 13:06, Daniel Fuchs wrote: >> Hi, >> >> I'm not sure I like the replacement of Collections.emptyList() >> by List.of(); >> I find emptyList() more expressive (+ it always returns >> the same instance). >> >> best regards, >> >> -- daniel >> >> On 15/09/16 11:46, Pavel Rappo wrote: >>> Hi, >>> >>> I have had a look at the change. It looks good. >>> >>> Retrofitting Collections.unmodifiableXXX/Arrays.asList with Convenience Factory >>> Methods requires extra carefulness as the factory methods are stricter than any >>> of those. Not only do they provide unconditional non-modifiability [0], they >>> also do not tolerate `null` elements. >>> >>> It looks like you took all that into account. >>> Tiny little comments and suggestions. >>> >>> 1. It might be the case we no longer need this [1]: >>> >>> finderList.forEach(Objects::requireNonNull); >>> >>> as the List.of does the same thing for free. Though it might be okay to leave it >>> as an explicit check. >>> >>> Also, could you please fix a typo here (the same file): >>> >>> * will be propogated to the caller of the resulting module finder's >>> ^ >>> 2. An interesting question (though it's a completely different issue) is whether >>> or not the `cookieHeader` list in the map should also be unmodifiable [2]? >>> >>> 3. Could you please also fix the same (copy-pasted?) typo in FileTreeWalker? >>> >>> if {@code options} is {@ocde null} or the options >>> ^^ >>> 4. Please remove this line from the ZoneRules constructor's javadoc: >>> >>> @return the zone rules, not null >>> >>> 5. Maybe we should revisit javadoc on those fields in [3]: >>> >>> This List is {@linkplain Collections#unmodifiableList(List) unmodifiable}. >>> >>> Since it's no longer the case. >>> >>> 6. I couldn't find any evidence that `resolverFields` might contain `null`. >>> Am I missing a javadoc or a line of code? Maybe we should talk to java.time >>> folks to see if it's the case? >>> >>> 7. Try to not make lines longer than they were before: 80 characters. Unless >>> it's really needed. >>> >>> Thanks, >>> -Pavel >>> >>> -------------------------------------------------------------------------------- >>> [0] Compare List.of().remove(new Object()) with Collections.emptyList().remove(new Object()) >>> [1] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/lang/module/ModuleFinder.java.sdiff.html >>> [2] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/net/CookieManager.java.sdiff.html >>> [3] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00/src/java.base/share/classes/java/util/ResourceBundle.java.sdiff.html >>> >>>> On 15 Sep 2016, at 09:52, Jonathan Bluett-Duncan wrote: >>>> >>>> Thanks Patrick! >>>> >>>> Stuart, would you be happy to sponsor this change? >>>> >>>> If anyone else has any thoughts regarding this change, then I'm all ears. >>>> >>>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 >>>> Rationale for changes: >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043484.html >>>> >>>> Kind regards, >>>> Jonathan >>>> >>>> >>>> On 14 September 2016 at 21:55, Patrick Reinhart wrote: >>>> >>>>> Hi Jonathan, >>>>> >>>>> Here are your changes in a webrev: >>>>> >>>>> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 >>>>> >>>>> -Patrick >>>>> >>>>> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : >>>>> >>>>> Hi Jonathan, >>>>> >>>>> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: >>>>> >>>>> Hi Patrick, >>>>> Thank you very much for the offer to hold my patch for me! >>>>> >>>>> >>>>> No problem. >>>>> >>>>> Is it common practice to send patches to others using PGP? >>>>> >>>>> >>>>> No, this is my personal setting. >>>>> >>>>> Kind regards, >>>>> Jonathan >>>>> On 12 September 2016 at 21:08, Patrick Reinhart wrote: >>>>> >>>>> Hi Jonathan, >>>>> As I just also wanted to help some more clean-up in the JDKs final phase, I >>>>> could offer you to hold that patch. Just send it to me and I will prepare >>>>> the webrev for you?. >>>>> -Patrick >>>>> >>>>> >>>>> -Patrick >>>>> >>>>> >>>>> >>> >> > From patrick at reini.net Thu Sep 15 12:33:51 2016 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 15 Sep 2016 14:33:51 +0200 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> Message-ID: <95429a179c85cae087303afb969b35bd@reini.net> Hello together, I tried to process all suggested change input into the following new webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01 Give me feedback if something is missing/wrong -Patrick On 2016-09-15 13:48, Pavel Rappo wrote: > Daniel, Claes, > > List.of() and Collections.emptyList() are not the same. The behaviours > are > different. Moreover, immutable static factory methods return instances > which are > value-based. I believe it also means we are not tied with unconditional > instantiation, and in case of empty collections/maps could probably > return the > same object every time. > > We should ask Stuart why it has been done like that in the first place. > Maybe > out of concern people might synchronize of those objects? I don't know. > Let's > say for now it's an implementation-specific detail. > >> On 15 Sep 2016, at 12:35, Claes Redestad >> wrote: >> >> +1 >> >> I don't mind List.of() aesthetically, but there are places where >> startup/footprint is important where Collections.emptyList() >> is simply superior, e.g., constituting permanent data structures >> such as the module graph during early bootstrap. >> From jbluettduncan at gmail.com Thu Sep 15 14:02:42 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 15 Sep 2016 15:02:42 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <95429a179c85cae087303afb969b35bd@reini.net> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> <95429a179c85cae087303afb969b35bd@reini.net> Message-ID: Wow, lots of discussion went on since I was busy doing other stuff! Thanks Patrick for doing the work of creating a new webrev for me. Really appreciated! Pavel already mentioned it, but I think List.of instead of Collections.emptyList in ZoneOffsetTransition is the right thing to do for visual and behavioural consistency. If it turns out that we need to revert to Collections.empty* and Collections.unmodifiable* for e.g. serializability or class loading concerns, then I'd be happy to revert both of the lines I touched. Otherwise I believe that List.of should be used consistently. I think Stuart made List.of() non-singleton because there wasn't any evidence that it made List.of() more memory- or time-intensive than Collections.emptyList(), but I might be wrong on this. I'm sure he can explain more or correct me in this case. Kind regards, Jonathan On 15 September 2016 at 13:33, Patrick Reinhart wrote: > Hello together, > > I tried to process all suggested change input into the following new > webrev: > > http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01 > > Give me feedback if something is missing/wrong > > -Patrick > > > On 2016-09-15 13:48, Pavel Rappo wrote: > >> Daniel, Claes, >> >> List.of() and Collections.emptyList() are not the same. The behaviours are >> different. Moreover, immutable static factory methods return instances >> which are >> value-based. I believe it also means we are not tied with unconditional >> instantiation, and in case of empty collections/maps could probably >> return the >> same object every time. >> >> We should ask Stuart why it has been done like that in the first place. >> Maybe >> out of concern people might synchronize of those objects? I don't know. >> Let's >> say for now it's an implementation-specific detail. >> >> On 15 Sep 2016, at 12:35, Claes Redestad >>> wrote: >>> >>> +1 >>> >>> I don't mind List.of() aesthetically, but there are places where >>> startup/footprint is important where Collections.emptyList() >>> is simply superior, e.g., constituting permanent data structures >>> such as the module graph during early bootstrap. >>> >>> From jbluettduncan at gmail.com Thu Sep 15 14:06:14 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 15 Sep 2016 15:06:14 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> <95429a179c85cae087303afb969b35bd@reini.net> Message-ID: Pavel, > 6. I couldn't find any evidence that `resolverFields` might contain `null`. > Am I missing a javadoc or a line of code? Maybe we should talk to java.time > folks to see if it's the case? > When I ran the tests for java.time, one of them failed because `null` was being passed to `resolverFields`, so I came the conclusion that it was unsafe to make a change there. Kind regards, Jonathan From jbluettduncan at gmail.com Thu Sep 15 14:10:51 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 15 Sep 2016 15:10:51 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> <95429a179c85cae087303afb969b35bd@reini.net> Message-ID: Patrick, would you kindly line-wrap the TOCTOU comment in http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01/src/java.base/share/classes/java/nio/file/FileTreeIterator.java.cdiff.html for me, so that each line has 80 characters or less (and maybe insert a `.` at the end)? Kind regards, Jonathan On 15 September 2016 at 15:06, Jonathan Bluett-Duncan < jbluettduncan at gmail.com> wrote: > Pavel, > > >> 6. I couldn't find any evidence that `resolverFields` might contain >> `null`. >> Am I missing a javadoc or a line of code? Maybe we should talk to >> java.time >> folks to see if it's the case? >> > > When I ran the tests for java.time, one of them failed because `null` was > being passed to `resolverFields`, so I came the conclusion that it was > unsafe to make a change there. > > Kind regards, > Jonathan > > From manju.jccs at gmail.com Thu Sep 15 14:39:55 2016 From: manju.jccs at gmail.com (Manjunath SV) Date: Thu, 15 Sep 2016 20:09:55 +0530 Subject: core-libs-dev Digest, Vol 113, Issue 53 In-Reply-To: References: Message-ID: Hi, I monitored memory usage, below are the details. Heap usage :- 857mb Virtual memory:- 12.6gb -Xmx set to 4gb. I have taken virtual and heap memory usage when Java spawns sub processes. Thanks & Regards, Manjunath On 15 Sep 2016 4:17 p.m., wrote: Send core-libs-dev mailing list submissions to core-libs-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev or, via email, send a message with subject or body 'help' to core-libs-dev-request at openjdk.java.net You can reach the person managing the list at core-libs-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of core-libs-dev digest..." Today's Topics: 1. Re: RFC: System.console().encoding() (Xueming Shen) 2. Re: RFC: System.console().encoding() (Dawid Weiss) 3. Re: RFC: System.console().encoding() (Claes Redestad) 4. Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK (Jonathan Bluett-Duncan) 5. Re: Reg - Sub Process creation from java takes more time (ecki at zusammenkunft.net) 6. Re: RFC: System.console().encoding() (Jochen Theodorou) 7. Re: RFC: System.console().encoding() (Dawid Weiss) 8. Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK (Pavel Rappo) ---------------------------------------------------------------------- Message: 1 Date: Thu, 15 Sep 2016 00:06:05 -0700 From: Xueming Shen To: core-libs-dev at openjdk.java.net Subject: Re: RFC: System.console().encoding() Message-ID: <57DA485D.100 at oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed -1 :-) Console is supposed to be a "char/String" based class, "encoding" really should have no business here in its api. Simply for some implementation convenience is really not a good reason to add such a public method. That said, I would be fine to have such informative info in the system properties, together with its siblings, file,encoding and another "supposed to be private" property sun.jnu.encoding. sherman On 9/14/16, 11:42 PM, Aleksey Shipilev wrote: > Hi, > > Claes pointed out that our own reflective hacks to figure out console > encoding do not work anymore [1]. But, we need the console encoding for > reliably printing on the console from within different sources. Note > that you would normally just use System.console() and its PrintWriter, > but reality is a bit more complicated, and sometimes you need to write > the plain char stream directly into the byte[]-accepting methods, > encoding on your own. > > So, my question: should we, in the light of extended Jigsaw-solving > crunch, provide the public Console.encoding() method that would return > the console charset? > > Thanks, > -Aleksey > > [1] > http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html > ------------------------------ Message: 2 Date: Thu, 15 Sep 2016 09:21:01 +0200 From: Dawid Weiss To: Xueming Shen Cc: core-libs-dev Subject: Re: RFC: System.console().encoding() Message-ID: Content-Type: text/plain; charset=UTF-8 > Console is supposed to be a "char/String" based class, "encoding" really > should have no business here in its api. While I agree with your concerns about the functional side of the API, I disagree about this method having no practical use. I can give you a concrete example. The use case that we had was to check whether the "terminal" (console) would be able to handle non-ASCII characters. A Writer doesn't tell you anything. An encoding does provide at least some confidence that certain characters will be translated properly -- if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't get displayed for sure. This doesn't mean 100% confidence in actual glyph rendering of course, but it's a cheap and safe sanity check of the terminal's capabilities. An (undocumented) proprietary property? Sure, but I really don't see the reason why this shouldn't be in the API, unless you know of terminals that handle Unicode-based streams directly (in which case the encoding method would simply return UTF32). Dawid ------------------------------ Message: 3 Date: Thu, 15 Sep 2016 10:18:29 +0200 From: Claes Redestad To: core-libs-dev at openjdk.java.net Subject: Re: RFC: System.console().encoding() Message-ID: <57DA5955.4070401 at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed +1 Won't be enough, though, since in JMH it appears you're also getting the encoding from System.out (java.io.PrintStream) via reflective hacks. /Claes On 2016-09-15 08:42, Aleksey Shipilev wrote: > Hi, > > Claes pointed out that our own reflective hacks to figure out console > encoding do not work anymore [1]. But, we need the console encoding for > reliably printing on the console from within different sources. Note > that you would normally just use System.console() and its PrintWriter, > but reality is a bit more complicated, and sometimes you need to write > the plain char stream directly into the byte[]-accepting methods, > encoding on your own. > > So, my question: should we, in the light of extended Jigsaw-solving > crunch, provide the public Console.encoding() method that would return > the console charset? > > Thanks, > -Aleksey > > [1] > http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html > ------------------------------ Message: 4 Date: Thu, 15 Sep 2016 09:52:47 +0100 From: Jonathan Bluett-Duncan To: Patrick Reinhart , Stuart Marks Cc: core-libs-dev Subject: Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK Message-ID: Content-Type: text/plain; charset=UTF-8 Thanks Patrick! Stuart, would you be happy to sponsor this change? If anyone else has any thoughts regarding this change, then I'm all ears. Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 Rationale for changes: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- September/043484.html Kind regards, Jonathan On 14 September 2016 at 21:55, Patrick Reinhart wrote: > Hi Jonathan, > > Here are your changes in a webrev: > > http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 > > -Patrick > > Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : > > Hi Jonathan, > > On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: > > Hi Patrick, > Thank you very much for the offer to hold my patch for me! > > > No problem. > > Is it common practice to send patches to others using PGP? > > > No, this is my personal setting. > > Kind regards, > Jonathan > On 12 September 2016 at 21:08, Patrick Reinhart wrote: > > Hi Jonathan, > As I just also wanted to help some more clean-up in the JDKs final phase, I > could offer you to hold that patch. Just send it to me and I will prepare > the webrev for you?. > -Patrick > > > -Patrick > > > ------------------------------ Message: 5 Date: Thu, 15 Sep 2016 11:01:01 +0200 From: To: "core-libs-dev at openjdk.java.net" Subject: Re: Reg - Sub Process creation from java takes more time Message-ID: <57da634c.c336c20a.19b0c.bec8 at mx.google.com> Content-Type: text/plain; charset="utf-8" Hello, Do you monitor heap usage and virtual memory size of your Java process? I would look out for increase (which causes slower for tines). Also it is generally a good idea to turn on GC logging and look into it if a java process degregades over time Gruss Bernd Just BTW: I think Java would not be the right tool to spawn and control sich a high number of external processes. Maybe it would be better to hand that off to a more native component. -- http://bernd.eckenfels.net Von: Manjunath SV ------------------------------ Message: 6 Date: Thu, 15 Sep 2016 12:05:04 +0200 From: Jochen Theodorou To: core-libs-dev at openjdk.java.net Subject: Re: RFC: System.console().encoding() Message-ID: <57DA7250.9020406 at gmx.org> Content-Type: text/plain; charset=utf-8; format=flowed On 15.09.2016 09:21, Dawid Weiss wrote: >> Console is supposed to be a "char/String" based class, "encoding" really >> should have no business here in its api. > > While I agree with your concerns about the functional side of the API, > I disagree about this method having no practical use. I can give you a > concrete example. The use case that we had was to check whether the > "terminal" (console) would be able to handle non-ASCII characters. A > Writer doesn't tell you anything. An encoding does provide at least > some confidence that certain characters will be translated properly -- > if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't > get displayed for sure. This doesn't mean 100% confidence in actual > glyph rendering of course, but it's a cheap and safe sanity check of > the terminal's capabilities. out of curiosity... what will you do if you find the encoding lacking what you need? bye Jochen ------------------------------ Message: 7 Date: Thu, 15 Sep 2016 12:17:26 +0200 From: Dawid Weiss To: Jochen Theodorou Cc: core-libs-dev Subject: Re: RFC: System.console().encoding() Message-ID: Content-Type: text/plain; charset=UTF-8 > out of curiosity... what will you do if you find the encoding lacking what > you need? Oh, display a warning. Helps to figure out where those "???" characters are coming from... Naive, I know. But it's the best one can do and it works (most of the time). D. ------------------------------ Message: 8 Date: Thu, 15 Sep 2016 11:46:17 +0100 From: Pavel Rappo To: Jonathan Bluett-Duncan Cc: core-libs-dev Subject: Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK Message-ID: Content-Type: text/plain; charset=utf-8 Hi, I have had a look at the change. It looks good. Retrofitting Collections.unmodifiableXXX/Arrays.asList with Convenience Factory Methods requires extra carefulness as the factory methods are stricter than any of those. Not only do they provide unconditional non-modifiability [0], they also do not tolerate `null` elements. It looks like you took all that into account. Tiny little comments and suggestions. 1. It might be the case we no longer need this [1]: finderList.forEach(Objects::requireNonNull); as the List.of does the same thing for free. Though it might be okay to leave it as an explicit check. Also, could you please fix a typo here (the same file): * will be propogated to the caller of the resulting module finder's ^ 2. An interesting question (though it's a completely different issue) is whether or not the `cookieHeader` list in the map should also be unmodifiable [2]? 3. Could you please also fix the same (copy-pasted?) typo in FileTreeWalker? if {@code options} is {@ocde null} or the options ^^ 4. Please remove this line from the ZoneRules constructor's javadoc: @return the zone rules, not null 5. Maybe we should revisit javadoc on those fields in [3]: This List is {@linkplain Collections#unmodifiableList(List) unmodifiable}. Since it's no longer the case. 6. I couldn't find any evidence that `resolverFields` might contain `null`. Am I missing a javadoc or a line of code? Maybe we should talk to java.time folks to see if it's the case? 7. Try to not make lines longer than they were before: 80 characters. Unless it's really needed. Thanks, -Pavel ------------------------------------------------------------ -------------------- [0] Compare List.of().remove(new Object()) with Collections.emptyList().remove(new Object()) [1] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/ webrev.00/src/java.base/share/classes/java/lang/module/ ModuleFinder.java.sdiff.html [2] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/ webrev.00/src/java.base/share/classes/java/net/CookieManager.java.sdiff.html [3] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/ webrev.00/src/java.base/share/classes/java/util/ ResourceBundle.java.sdiff.html > On 15 Sep 2016, at 09:52, Jonathan Bluett-Duncan wrote: > > Thanks Patrick! > > Stuart, would you be happy to sponsor this change? > > If anyone else has any thoughts regarding this change, then I'm all ears. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 > Rationale for changes: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- September/043484.html > > Kind regards, > Jonathan > > > On 14 September 2016 at 21:55, Patrick Reinhart wrote: > >> Hi Jonathan, >> >> Here are your changes in a webrev: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 >> >> -Patrick >> >> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : >> >> Hi Jonathan, >> >> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: >> >> Hi Patrick, >> Thank you very much for the offer to hold my patch for me! >> >> >> No problem. >> >> Is it common practice to send patches to others using PGP? >> >> >> No, this is my personal setting. >> >> Kind regards, >> Jonathan >> On 12 September 2016 at 21:08, Patrick Reinhart wrote: >> >> Hi Jonathan, >> As I just also wanted to help some more clean-up in the JDKs final phase, I >> could offer you to hold that patch. Just send it to me and I will prepare >> the webrev for you?. >> -Patrick >> >> >> -Patrick >> >> >> End of core-libs-dev Digest, Vol 113, Issue 53 ********************************************** From david.lloyd at redhat.com Thu Sep 15 15:47:44 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 15 Sep 2016 10:47:44 -0500 Subject: RFC: System.console().encoding() In-Reply-To: <57DA485D.100@oracle.com> References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> <57DA485D.100@oracle.com> Message-ID: <0d49827b-7f0a-d05b-9eef-9deeb1f3d8aa@redhat.com> On 09/15/2016 02:06 AM, Xueming Shen wrote: > -1 :-) > > Console is supposed to be a "char/String" based class, "encoding" really > should > have no business here in its api. Simply for some implementation > convenience > is really not a good reason to add such a public method. Let's look at the two likely cases fairly though: if the console is purely char-based it could easily report a Unicode-based encoding (like UTF-16_BE), implying full support for any string that is output or input. If the console is byte-based, then the encoding definitely provides real, useful information that could be relevant to the application. Overall it seems harmless to me. > That said, I would be fine to have such informative info in the system > properties, > together with its siblings, file,encoding and another "supposed to be > private" > property sun.jnu.encoding. > > sherman > > > On 9/14/16, 11:42 PM, Aleksey Shipilev wrote: >> Hi, >> >> Claes pointed out that our own reflective hacks to figure out console >> encoding do not work anymore [1]. But, we need the console encoding for >> reliably printing on the console from within different sources. Note >> that you would normally just use System.console() and its PrintWriter, >> but reality is a bit more complicated, and sometimes you need to write >> the plain char stream directly into the byte[]-accepting methods, >> encoding on your own. >> >> So, my question: should we, in the light of extended Jigsaw-solving >> crunch, provide the public Console.encoding() method that would return >> the console charset? >> >> Thanks, >> -Aleksey >> >> [1] >> http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html >> > -- - DML From shade at redhat.com Thu Sep 15 15:56:48 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 15 Sep 2016 17:56:48 +0200 Subject: RFC: System.console().encoding() In-Reply-To: <57DA485D.100@oracle.com> References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> <57DA485D.100@oracle.com> Message-ID: On 09/15/2016 09:06 AM, Xueming Shen wrote: > Console is supposed to be a "char/String" based class, "encoding" > really should have no business here in its api. Simply for some > implementation convenience is really not a good reason to add such a > public method. Let's look at it this way: there is a problem with console encoding that Console class solves, nicely abstracting the subtleties away. In doing so, it polls GetConsoleCP, the WinAPI call: JNIEXPORT jstring JNICALL Java_java_io_Console_encoding(JNIEnv *env, jclass cls) { char buf[64]; int cp = GetConsoleCP(); if (cp >= 874 && cp <= 950) sprintf(buf, "ms%d", cp); else sprintf(buf, "cp%d", cp); return JNU_NewStringPlatform(env, buf); } If by "convenience" you mean avoiding doing the JNI call that polls that OS-specific bit of data, then yes, APIs provide lots of those conveniences. > That said, I would be fine to have such informative info in the > system properties, together with its siblings, file,encoding and > another "supposed to be private" property sun.jnu.encoding. Actually, if you look into the launcher, it does: static char* getConsoleEncoding() { char* buf = malloc(16); int cp; if (buf == NULL) { return NULL; } cp = GetConsoleCP(); if (cp >= 874 && cp <= 950) sprintf(buf, "ms%d", cp); else sprintf(buf, "cp%d", cp); return buf; } ... sprops.sun_stdout_encoding = getConsoleEncoding(); ...which opens a way to poll this without a Reflection hack. Extended the JMH hack with it, but it still fragile: http://hg.openjdk.java.net/code-tools/jmh/rev/8c20adb08b2d Thanks, -Aleksey From Ulf.Zibis at CoSoCo.de Thu Sep 15 16:35:24 2016 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 15 Sep 2016 18:35:24 +0200 Subject: RFC: System.console().encoding() In-Reply-To: References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> <57DA485D.100@oracle.com> Message-ID: Am 15.09.2016 um 17:56 schrieb Aleksey Shipilev: > ...which opens a way to poll this without a Reflection hack. Extended > the JMH hack with it, but it still fragile: > http://hg.openjdk.java.net/code-tools/jmh/rev/8c20adb08b2d Maybe keep it simple - no need for (prop != null) - and in design line with the 2 other tries: // Try 3. Try to poll internal properties. try { return Charset.forName(System.getProperty("sun.stdout.encoding") ); } catch (Exception e) { // fall-through } -Ulf From HORII at jp.ibm.com Thu Sep 15 06:08:41 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Thu, 15 Sep 2016 15:08:41 +0900 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: <962ae958-5897-6e9b-eec3-33680358ad0b@oracle.com> References: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> <962ae958-5897-6e9b-eec3-33680358ad0b@oracle.com> Message-ID: Hi Volker, and Sean, Thank you for your comments and suggestion. I and Gustavo created a webrev that includes Bits and ByteArrayAccess. http://cr.openjdk.java.net/~gromero/8165231/02/ I believe there is no other similar methods in jdk. Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo From: Sean Coffey To: Volker Simonis Cc: "jdk8u-dev at openjdk.java.net" , Java Core Libs , Hiroshi H Horii/Japan/IBM at IBMJP, "ppc-aix-port-dev at openjdk.java.net" , Gustavo Bueno Romero , "Doerr, Martin" Date: 09/13/2016 21:46 Subject: Re: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc Sounds good Volker. Good catch. regards, Sean. On 13/09/2016 13:09, Volker Simonis wrote: > Hi Sean, > > thanks a lot for the fast response. I've updated the bug entry as > requested and will push the change - maybe with the following > potential improvement: > > @Hiroshi: also maybe not that performance relevant, I think we should > we also fix sun/security/provider/ByteArrayAccess.java which contains > the same construct: > > // Return whether this platform supports full speed int/long memory access > // at unaligned addresses. > // This code was copied from java.nio.Bits because there is no equivalent > // public API. > private static boolean unaligned() { > String arch = java.security.AccessController.doPrivileged > (new sun.security.action.GetPropertyAction("os.arch", "")); > return arch.equals("i386") || arch.equals("x86") || arch.equals("amd64") > || arch.equals("x86_64"); > } > > Regards, > Volker From xueming.shen at oracle.com Thu Sep 15 16:40:14 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 15 Sep 2016 09:40:14 -0700 Subject: RFC: System.console().encoding() In-Reply-To: References: <3e6817ac-e1d3-82b5-c5eb-e5a3e815ce48@redhat.com> <57DA485D.100@oracle.com> Message-ID: <9eb2ce4e-8f96-0165-1b0e-91328b58c58e@oracle.com> On 9/15/16 8:56 AM, Aleksey Shipilev wrote: > On 09/15/2016 09:06 AM, Xueming Shen wrote: >> Console is supposed to be a "char/String" based class, "encoding" >> really should have no business here in its api. Simply for some >> implementation convenience is really not a good reason to add such a >> public method. > Let's look at it this way: there is a problem with console encoding that > Console class solves, nicely abstracting the subtleties away. In doing > so, it polls GetConsoleCP, the WinAPI call: What I meant is that the Console was/is designed the way that the user can access the console/terminal without knowing/dealing with the "encoding". The encoding concept is purposely hidden from the very beginning, with the assumption/believe that this is a implementation detail you really don't need to know when using the Console class in general use scenario. It's obviously it would be helpful and convenient if this encoding info can be accessed in your use case, but given this is really not a "normal" use scenario, what I'm saying is the System properties might be better place for such information. Seems like the jmh.util.Utils is accessing the System.properties already for other system/vm-wide info, such as the vm version, os.name ...as well as the file.encoding you might need for non-console in/output. Sherman > > JNIEXPORT jstring JNICALL > Java_java_io_Console_encoding(JNIEnv *env, jclass cls) > { > char buf[64]; > int cp = GetConsoleCP(); > if (cp >= 874 && cp <= 950) > sprintf(buf, "ms%d", cp); > else > sprintf(buf, "cp%d", cp); > return JNU_NewStringPlatform(env, buf); > } > > If by "convenience" you mean avoiding doing the JNI call that polls that > OS-specific bit of data, then yes, APIs provide lots of those conveniences. > >> That said, I would be fine to have such informative info in the >> system properties, together with its siblings, file,encoding and >> another "supposed to be private" property sun.jnu.encoding. > Actually, if you look into the launcher, it does: > > static char* getConsoleEncoding() > { > char* buf = malloc(16); > int cp; > if (buf == NULL) { > return NULL; > } > cp = GetConsoleCP(); > if (cp >= 874 && cp <= 950) > sprintf(buf, "ms%d", cp); > else > sprintf(buf, "cp%d", cp); > return buf; > } > > ... > sprops.sun_stdout_encoding = getConsoleEncoding(); > > ...which opens a way to poll this without a Reflection hack. Extended > the JMH hack with it, but it still fragile: > http://hg.openjdk.java.net/code-tools/jmh/rev/8c20adb08b2d > > Thanks, > -Aleksey > > > From stuart.marks at oracle.com Thu Sep 15 17:20:07 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 15 Sep 2016 10:20:07 -0700 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> <95429a179c85cae087303afb969b35bd@reini.net> Message-ID: <8c206fe5-6caa-bc5b-c073-dcc38fb3d0a0@oracle.com> Hi all, Unfortunately I don't have time to work on any of this at the moment, because of JavaOne preparation, and JavaOne next week. Jonathan, thanks for pushing forward with this. I'm glad that others have picked it up. Patrick, thanks for posting the changeset on Jonathan's behalf. This is very helpful. A few comments regarding issues raised up-thread. Regarding the (non)singleton-ness of the empty collections, this is covered by https://bugs.openjdk.java.net/browse/JDK-8156079 consider making empty instances singletons It wasn't a design decision to make them not singletons. The spec requirement is only that the returned instance satisfy the requirements of the interfaces it implements (e.g., List) and nothing more. Certainly there is no spec requirement regarding object identity. Making the empty collections singletons is the "obvious" thing to do, but it's often the case that the "obvious" thing isn't the right thing. That said, it may still be the right thing to make them singletons. Given the proposed extension to the JDK 9 schedule, it might be possible to change this in JDK 9. Note that List.of() should be functionally equivalent to Collections.emptyList() -- and correspondingly for Set and Map -- but they do differ. In particular, they have different serialization formats. Also on this topic, please note comments that Daniel Fuchs and I have added to https://bugs.openjdk.java.net/browse/JDK-8134373 regarding serialization compatibility. Reviewers should take care that updating code to use these new collection factories doesn't change any serialization formats. Unfortunately I am not confident that we have sufficient tests for serialization compatibility. s'marks On 9/15/16 7:02 AM, Jonathan Bluett-Duncan wrote: > Wow, lots of discussion went on since I was busy doing other stuff! > > Thanks Patrick for doing the work of creating a new webrev for me. Really > appreciated! > > Pavel already mentioned it, but I think List.of instead of > Collections.emptyList in ZoneOffsetTransition is the right thing to do for > visual and behavioural consistency. If it turns out that we need to revert > to Collections.empty* and Collections.unmodifiable* for e.g. > serializability or class loading concerns, then I'd be happy to revert both > of the lines I touched. Otherwise I believe that List.of should be used > consistently. > > I think Stuart made List.of() non-singleton because there wasn't any > evidence that it made List.of() more memory- or time-intensive than > Collections.emptyList(), but I might be wrong on this. I'm sure he can > explain more or correct me in this case. > > Kind regards, > Jonathan > > > On 15 September 2016 at 13:33, Patrick Reinhart wrote: > >> Hello together, >> >> I tried to process all suggested change input into the following new >> webrev: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01 >> >> Give me feedback if something is missing/wrong >> >> -Patrick >> >> >> On 2016-09-15 13:48, Pavel Rappo wrote: >> >>> Daniel, Claes, >>> >>> List.of() and Collections.emptyList() are not the same. The behaviours are >>> different. Moreover, immutable static factory methods return instances >>> which are >>> value-based. I believe it also means we are not tied with unconditional >>> instantiation, and in case of empty collections/maps could probably >>> return the >>> same object every time. >>> >>> We should ask Stuart why it has been done like that in the first place. >>> Maybe >>> out of concern people might synchronize of those objects? I don't know. >>> Let's >>> say for now it's an implementation-specific detail. >>> >>> On 15 Sep 2016, at 12:35, Claes Redestad >>>> wrote: >>>> >>>> +1 >>>> >>>> I don't mind List.of() aesthetically, but there are places where >>>> startup/footprint is important where Collections.emptyList() >>>> is simply superior, e.g., constituting permanent data structures >>>> such as the module graph during early bootstrap. >>>> >>>> From Roger.Riggs at Oracle.com Thu Sep 15 17:39:13 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 15 Sep 2016 13:39:13 -0400 Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: References: Message-ID: <00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com> Hi Thomas, It looks like NAME_MAX is not defined on Solaris and breaks the build on Solaris. [1] An alternative would be to conditionally use PATH_MAX. But I think it would be reasonable to just remove the use of NAME_MAX, since the following code increases the value to at least 1024, which should be safe. If you don't have time to address this, I can propose a fix. Roger [1] 8166148 fix for JDK-8165936 broke solaris builds On 9/14/2016 2:34 AM, Thomas St?fe wrote: > Hi all, > > thanks for the reviews. Here is version two: > > http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ > > > Only cosmetic changes: > - made code pre-c99 compatible > - consistently use dirent64 > - fix indentation in ifs > - removed black between malloc and cast > > Kind Regards, Thomas > > > > On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu > > wrote: > > Looks good to me. Thank you for fixing this bug! > > Masayoshi > > > > On 9/13/2016 11:49 PM, Thomas St?fe wrote: > > Hi Christoph, thanks for your review! Yes, I can remove the blank. > > Kind Regards, Thomas > > On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph > > > wrote: > Hi Thomas, > > your change looks good. I'm also forwarding this to > i18n-dev as issues in > TimeZone implementation are mostly handled there. > > One remark: Can you take the opportunity to also remove > the blank between > the cast and malloc in line 150: "(struct dirent64 *) > malloc..."? > > Unfortunately I'm no reviewer, so you still need an > official review. > > Best regards > Christoph > > -----Original Message----- > From: core-libs-dev > [mailto:core-libs-dev-bounces at openjdk.java.net > ] On > > Behalf > > Of Thomas St?fe > Sent: Dienstag, 13. September 2016 12:54 > To: Java Core Libs > > Subject: RFR(xs): 8165936: Potential Heap buffer > overflow when seaching > timezone info files > > Dear all, > > please take a look at this small change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8165936- > > > Potential-Heap-buffer- > > overflow-when-seaching-timezone-info-files/webrev.00/webrev/ > > readdir_r is used to iterate over the content of a > system directory, but > the buffer passed to it is too small: Its size should > include the size of > the dirent structure itself (minus the d_name member). > > The fix also now checks the return code of pathconf(), > and if pathconf() > returns an error, falls back to the NAME_MAX compile > time constant. > Finally, it imposes a minimum size for the buffer, > because on older > > System > > V systems NAME_MAX may be surprisingly small and > readdir_r will not check > the output buffer size. I think it is better to err on > the safe side > > here. > > Kind Regards, Thomas > > > From Roger.Riggs at Oracle.com Thu Sep 15 19:16:21 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 15 Sep 2016 15:16:21 -0400 Subject: RFR 9: 8166148 Fix for JDK-8165936 broke Solaris builds In-Reply-To: <00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com> References: <00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com> Message-ID: <949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com> Please review a fix for build breakage on Solaris. The NAME_MAX value does not seem to add much value in this case and is not defined on all supported platforms. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-max-8166148/ Issue: https://bugs.openjdk.java.net/browse/JDK-8166148 Thanks, Roger On 9/15/2016 1:39 PM, Roger Riggs wrote: > Hi Thomas, > > It looks like NAME_MAX is not defined on Solaris and breaks the build > on Solaris. [1] > > An alternative would be to conditionally use PATH_MAX. > > But I think it would be reasonable to just remove the use of NAME_MAX, > since the following > code increases the value to at least 1024, which should be safe. > > If you don't have time to address this, I can propose a fix. > > Roger > > [1] 8166148 fix for JDK-8165936 broke solaris builds > > > > On 9/14/2016 2:34 AM, Thomas St?fe wrote: >> Hi all, >> >> thanks for the reviews. Here is version two: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ >> >> >> >> Only cosmetic changes: >> - made code pre-c99 compatible >> - consistently use dirent64 >> - fix indentation in ifs >> - removed black between malloc and cast >> >> Kind Regards, Thomas >> >> >> >> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu >> > >> wrote: >> >> Looks good to me. Thank you for fixing this bug! >> >> Masayoshi >> >> >> >> On 9/13/2016 11:49 PM, Thomas St?fe wrote: >> >> Hi Christoph, thanks for your review! Yes, I can remove the >> blank. >> >> Kind Regards, Thomas >> >> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph >> >> >> wrote: >> Hi Thomas, >> >> your change looks good. I'm also forwarding this to >> i18n-dev as issues in >> TimeZone implementation are mostly handled there. >> >> One remark: Can you take the opportunity to also remove >> the blank between >> the cast and malloc in line 150: "(struct dirent64 *) >> malloc..."? >> >> Unfortunately I'm no reviewer, so you still need an >> official review. >> >> Best regards >> Christoph >> >> -----Original Message----- >> From: core-libs-dev >> [mailto:core-libs-dev-bounces at openjdk.java.net >> ] On >> >> Behalf >> >> Of Thomas St?fe >> Sent: Dienstag, 13. September 2016 12:54 >> To: Java Core Libs > > >> Subject: RFR(xs): 8165936: Potential Heap buffer >> overflow when seaching >> timezone info files >> >> Dear all, >> >> please take a look at this small change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >> >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8165936- >> >> >> Potential-Heap-buffer- >> >> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >> >> readdir_r is used to iterate over the content of a >> system directory, but >> the buffer passed to it is too small: Its size should >> include the size of >> the dirent structure itself (minus the d_name member). >> >> The fix also now checks the return code of pathconf(), >> and if pathconf() >> returns an error, falls back to the NAME_MAX compile >> time constant. >> Finally, it imposes a minimum size for the buffer, >> because on older >> >> System >> >> V systems NAME_MAX may be surprisingly small and >> readdir_r will not check >> the output buffer size. I think it is better to err on >> the safe side >> >> here. >> >> Kind Regards, Thomas >> >> >> > From jbluettduncan at gmail.com Thu Sep 15 19:36:43 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 15 Sep 2016 20:36:43 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: <8c206fe5-6caa-bc5b-c073-dcc38fb3d0a0@oracle.com> References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> <95429a179c85cae087303afb969b35bd@reini.net> <8c206fe5-6caa-bc5b-c073-dcc38fb3d0a0@oracle.com> Message-ID: Hi all, Stuart, thank you very much for your thorough response. Regarding serializability concerns, I've just checked my changes and all non-test code in the JDK which calls it, and it doesn't seem to me that they affect any fields in `Serializable` classes or the return values of methods which either return instances of `Serializable` classes or whose javadoc mention that the returned object is serializable. So I'm somewhat certain that my changes are serialization-compatible, but only somewhat, because I'm not that familiar with the intricacies of serialization... Considering how busy Stuart is, would anyone else be happy to sponsor this change? Kind regards, Jonathan On 15 September 2016 at 18:20, Stuart Marks wrote: > Hi all, > > Unfortunately I don't have time to work on any of this at the moment, > because of JavaOne preparation, and JavaOne next week. > > Jonathan, thanks for pushing forward with this. I'm glad that others have > picked it up. > > Patrick, thanks for posting the changeset on Jonathan's behalf. This is > very helpful. > > A few comments regarding issues raised up-thread. > > Regarding the (non)singleton-ness of the empty collections, this is > covered by > > https://bugs.openjdk.java.net/browse/JDK-8156079 > consider making empty instances singletons > > It wasn't a design decision to make them not singletons. The spec > requirement is only that the returned instance satisfy the requirements of > the interfaces it implements (e.g., List) and nothing more. Certainly there > is no spec requirement regarding object identity. > > Making the empty collections singletons is the "obvious" thing to do, but > it's often the case that the "obvious" thing isn't the right thing. That > said, it may still be the right thing to make them singletons. Given the > proposed extension to the JDK 9 schedule, it might be possible to change > this in JDK 9. > > Note that List.of() should be functionally equivalent to > Collections.emptyList() -- and correspondingly for Set and Map -- but they > do differ. In particular, they have different serialization formats. > > Also on this topic, please note comments that Daniel Fuchs and I have > added to > > https://bugs.openjdk.java.net/browse/JDK-8134373 > > regarding serialization compatibility. Reviewers should take care that > updating code to use these new collection factories doesn't change any > serialization formats. Unfortunately I am not confident that we have > sufficient tests for serialization compatibility. > > s'marks > > > > On 9/15/16 7:02 AM, Jonathan Bluett-Duncan wrote: > >> Wow, lots of discussion went on since I was busy doing other stuff! >> >> Thanks Patrick for doing the work of creating a new webrev for me. Really >> appreciated! >> >> Pavel already mentioned it, but I think List.of instead of >> Collections.emptyList in ZoneOffsetTransition is the right thing to do for >> visual and behavioural consistency. If it turns out that we need to revert >> to Collections.empty* and Collections.unmodifiable* for e.g. >> serializability or class loading concerns, then I'd be happy to revert >> both >> of the lines I touched. Otherwise I believe that List.of should be used >> consistently. >> >> I think Stuart made List.of() non-singleton because there wasn't any >> evidence that it made List.of() more memory- or time-intensive than >> Collections.emptyList(), but I might be wrong on this. I'm sure he can >> explain more or correct me in this case. >> >> Kind regards, >> Jonathan >> >> >> On 15 September 2016 at 13:33, Patrick Reinhart >> wrote: >> >> Hello together, >>> >>> I tried to process all suggested change input into the following new >>> webrev: >>> >>> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01 >>> >>> Give me feedback if something is missing/wrong >>> >>> -Patrick >>> >>> >>> On 2016-09-15 13:48, Pavel Rappo wrote: >>> >>> Daniel, Claes, >>>> >>>> List.of() and Collections.emptyList() are not the same. The behaviours >>>> are >>>> different. Moreover, immutable static factory methods return instances >>>> which are >>>> value-based. I believe it also means we are not tied with unconditional >>>> instantiation, and in case of empty collections/maps could probably >>>> return the >>>> same object every time. >>>> >>>> We should ask Stuart why it has been done like that in the first place. >>>> Maybe >>>> out of concern people might synchronize of those objects? I don't know. >>>> Let's >>>> say for now it's an implementation-specific detail. >>>> >>>> On 15 Sep 2016, at 12:35, Claes Redestad >>>> >>>>> wrote: >>>>> >>>>> +1 >>>>> >>>>> I don't mind List.of() aesthetically, but there are places where >>>>> startup/footprint is important where Collections.emptyList() >>>>> is simply superior, e.g., constituting permanent data structures >>>>> such as the module graph during early bootstrap. >>>>> >>>>> >>>>> From rednaxelafx at gmail.com Thu Sep 15 19:42:35 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 15 Sep 2016 12:42:35 -0700 Subject: RFR(s): 4285505: deprecate java.lang.Compiler In-Reply-To: <50807af7-e002-780c-6446-4de22077e5d2@oracle.com> References: <6d7a5899-e73a-600f-7936-0d7fbf356378@oracle.com> <50807af7-e002-780c-6446-4de22077e5d2@oracle.com> Message-ID: Hi Stuart, Again, replying on behalf of Azul Systems: Removal is the real concern. We can probably live with deprecation (if this amounts to annotation) as long as removal does not occur until a vetted alternative is in place. But we suggest a re-consideration of the deprecation issue if it's driver is an intent to move the functionality to platform specific classes. We think such a move would be a mistake. While it is true that we did not flag this earlier, thinking through the issues around removal of this API and moving it to a platform specific namespace, and the resulting implications for code portability between JDK implementations has made us reconsider the issue. To address the the platform specific questions: A "common home" is very much needed for the platform specific stuff that controls compiler behavior, and this common home belongs in the common class namespace [it currently lives in java.lang.Compiler]. Specifically, we strongly believe that control of compiler behavior should not require the use and reliance on platform specific classes. This allows portability of Java code across Java SE implementations, with [optional] platform specific commands that may be used by a Java program, and that may differ in choice between target platforms based on discovery, but that do not require any use of platform specific classes that do not exist in all compliant JREs. This portability is key. Note that to date, both Zing and Vega have managed to avoid exposing ANY platform specific control APIs in the form of platform-specific classes, and we would like to keep it that way. We have succeeded at leveraging the generic APIs available is the spec'ed Java SE platform for control and monitoring purposes. The portability this affords means that people don't write and deploy Zing-specific and works-only-on-Zing Java code. This quality is important for us and for others to maintain. To be specific about how java.lang.Compiler.command is important (as opposed to com.azul.zing.Compiler.command) in this context: Current Java code, which can be build and run using any Java SE compliant JRE, can currently check the JVM vendor and version (using e.g. java.lang.management.RuntimeMXBean), and based on what it finds issue specific compiler control commands using java.lang.Compiler.command. This is a real, current, and common use case for our JDK. Since no platform specific classes are used, this Java code remains portable, can be compiled and tested using any compliant JDK, and runs and resolves completely on any complaint JRE. If we were to replace java.lang.Compiler.command with platform specific classes that control compiler behavior, it would make Java code that would attempt to leverage them non-portable, would limit the code using the features to compile and test only on JDKs that included platform specific features, and would prevent using it (or make it more cumbersome to use) on JREs that did not include the platform specific classes. [And yes, while there are cumbersome alternatives that would involve reflection based class discovery, the code for doing that while remaining portable becomes very "ugly" on the user side]. The JDK is full of common namespace areas that are meant to expose platform specific behaviors in a portable way. The java.lang.management package is full of examples of this, and we certainly hope that we are not trending towards deprecating those with an intent to remove them. So to summarize: java.lang.Compiler.command is a key API for functionality that we currently use, and that we leverage and need to remain in the common (non platform specific) name space. While we can live with deprecation as part of an API cleanup, this cleanup should result in a suitable replacement API, and we would want a non-platform-specific-namespace replacement to exist before the current API is actually removed at any future date. Best regards, Kris (OpenJDK username: kmo) On Wed, Sep 14, 2016 at 10:18 AM, Stuart Marks wrote: > Hi Kris, > > Based on your email earlier in this thread, it seemed like you didn't > object to deprecating j.l.Compiler in Java 9. Since the other respondents > were already in favor, I've already pushed the changeset. (Sorry.) As > things stand, the changeset is in the jdk9/dev forest, but it's not in any > promoted JDK 9 builds. > > If we were to proceed with this as it stands, then the API change in Java > SE 9 visible to programs will merely be the addition of the following > annotation to java.lang.Compiler: > > @Deprecated(since="9", forRemoval=true) > > Existing binaries use j.l.Compiler will continue to run, and existing > sources that use it can still compile, though they will get compilation > warnings. The earliest release in which java.lang.Compiler would actually > be absent is Java SE 10. There is currently no schedule or project for SE > 10, but I would guess that it wouldn't ship anytime before mid-2018. > > If removal in this time frame is really a problem for Azul, then I suppose > this deprecation can be revisited and possibly changed in Java SE 9. > > But I'm hard pressed to see what value is actually being added by > java.lang.Compiler that can't be done better by a platform-specific API. > You mentioned the command() method: > > public static Object command(Object any) > > Anything that uses this API is platform-specific. Even if it avoids > platform-specific types, for example by using String arrays, the values it > passes and returns are unavoidably platform-specific. Users of this API > would be better served by using a platform-specific API. Can't Azul create > one and migrate to it? > > s'marks > > > On 9/13/16 5:09 PM, Krystal Mok wrote: > > Hi OpenJDK developers, > > Replying on behalf of Azul Systems: > > java.lang.Compiler is an integral part of the current Java SE spec, and is > currently being used by multiple independent Java SE implementations of > that spec in a spec-conforming way (Azul Zing, Azul Vega, and IBM J9 being > concrete exampleS). Before deprecation, a proposed replacement for Java SE > 9 would need to be vetted to make sure that is satisfies the needs of > current implementations. While JEP165 is a start in that direction, it > appears to be very HotSpot specific, and is not written in a specification > form (e.g. there is no "If no compiler is available, these methods do > nothing." mention). > > For example, Azul Zing?s ReadyNow feature makes use of the > java.lang.Compiler API to allow applications to pass directives down to the > VM, in a similar spirit to what IBM J9 does with the API. We continuously > evolve and enrich the commands we support in the API, e.g. in the ?Object > command(Object)? method, and it would be potentially problematic for us to > lose the current API without having a flexible replacement in the Java SE > spec. > > As such, we suggest that for the time being, java.lang.Compiler should be > neither depracated nor removed in Java SE 9. As a practical spec'ed > replacement is proposed that will cover the needs of implementations > currently using java.lang.Compiler, this can change. Perhaps in the Java SE > 10 timeframe. > > Thanks, > Kris (OpenJDK username: kmo) > > On Wed, Sep 7, 2016 at 1:52 PM, Stuart Marks > wrote: > >> Hi all, >> >> Please review this small patch to deprecate java.lang.Compiler for >> removal. >> >> Thanks, >> >> s'marks >> >> # HG changeset patch >> # User smarks >> # Date 1473281459 25200 >> # Wed Sep 07 13:50:59 2016 -0700 >> # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d >> # Parent 76ba1b74f268f1acc4847e242a2cfcd29880418c >> 4285505: deprecate java.lang.Compiler >> Reviewed-by: XXX >> >> diff -r 76ba1b74f268 -r e520c4e6970c src/java.base/share/classes/ja >> va/lang/Compiler.java >> --- a/src/java.base/share/classes/java/lang/Compiler.java Tue Sep >> 06 16:08:54 2016 -0700 >> +++ b/src/java.base/share/classes/java/lang/Compiler.java Wed Sep >> 07 13:50:59 2016 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -29,21 +29,18 @@ >> * The {@code Compiler} class is provided to support Java-to-native-code >> * compilers and related services. By design, the {@code Compiler} class >> does >> * nothing; it serves as a placeholder for a JIT compiler implementation. >> + * If no compiler is available, these methods do nothing. >> * >> - *

    When the Java Virtual Machine first starts, it determines if the >> system >> - * property {@code java.compiler} exists. (System properties are >> accessible >> - * through {@link System#getProperty(String)} and {@link >> - * System#getProperty(String, String)}. If so, it is assumed to be the >> name of >> - * a library (with a platform-dependent exact location and type); {@link >> - * System#loadLibrary} is called to load that library. If this loading >> - * succeeds, the function named {@code java_lang_Compiler_start()} in >> that >> - * library is called. >> - * >> - *

    If no compiler is available, these methods do nothing. >> + * @deprecated JIT compilers and their technologies vary too widely to >> + * be controlled effectively by a standardized interface. As such, many >> + * JIT compiler implementations ignore this interface, and are instead >> + * controllable by implementation-specific mechanisms such as >> command-line >> + * options. This class is subject to removal in a future version of Java >> SE. >> * >> * @author Frank Yellin >> * @since 1.0 >> */ >> + at Deprecated(since="9", forRemoval=true) >> public final class Compiler { >> private Compiler() {} // don't make instances >> >> > > From naoto.sato at oracle.com Thu Sep 15 19:42:02 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 15 Sep 2016 12:42:02 -0700 Subject: RFR 9: 8166148 Fix for JDK-8165936 broke Solaris builds In-Reply-To: <949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com> References: <00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com> <949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com> Message-ID: <68a16c00-b24b-89cb-4121-c7a8e1f837ec@oracle.com> +1 Naoto On 9/15/16 12:16 PM, Roger Riggs wrote: > Please review a fix for build breakage on Solaris. > The NAME_MAX value does not seem to add much value in this case and is > not defined on all supported platforms. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-max-8166148/ > Issue: > https://bugs.openjdk.java.net/browse/JDK-8166148 > > Thanks, Roger > > > On 9/15/2016 1:39 PM, Roger Riggs wrote: >> Hi Thomas, >> >> It looks like NAME_MAX is not defined on Solaris and breaks the build >> on Solaris. [1] >> >> An alternative would be to conditionally use PATH_MAX. >> >> But I think it would be reasonable to just remove the use of NAME_MAX, >> since the following >> code increases the value to at least 1024, which should be safe. >> >> If you don't have time to address this, I can propose a fix. >> >> Roger >> >> [1] 8166148 fix for JDK-8165936 broke solaris builds >> >> >> >> On 9/14/2016 2:34 AM, Thomas St?fe wrote: >>> Hi all, >>> >>> thanks for the reviews. Here is version two: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ >>> >>> >>> >>> Only cosmetic changes: >>> - made code pre-c99 compatible >>> - consistently use dirent64 >>> - fix indentation in ifs >>> - removed black between malloc and cast >>> >>> Kind Regards, Thomas >>> >>> >>> >>> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu >>> > >>> wrote: >>> >>> Looks good to me. Thank you for fixing this bug! >>> >>> Masayoshi >>> >>> >>> >>> On 9/13/2016 11:49 PM, Thomas St?fe wrote: >>> >>> Hi Christoph, thanks for your review! Yes, I can remove the >>> blank. >>> >>> Kind Regards, Thomas >>> >>> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph >>> >>> >>> wrote: >>> Hi Thomas, >>> >>> your change looks good. I'm also forwarding this to >>> i18n-dev as issues in >>> TimeZone implementation are mostly handled there. >>> >>> One remark: Can you take the opportunity to also remove >>> the blank between >>> the cast and malloc in line 150: "(struct dirent64 *) >>> malloc..."? >>> >>> Unfortunately I'm no reviewer, so you still need an >>> official review. >>> >>> Best regards >>> Christoph >>> >>> -----Original Message----- >>> From: core-libs-dev >>> [mailto:core-libs-dev-bounces at openjdk.java.net >>> ] On >>> >>> Behalf >>> >>> Of Thomas St?fe >>> Sent: Dienstag, 13. September 2016 12:54 >>> To: Java Core Libs >> > >>> Subject: RFR(xs): 8165936: Potential Heap buffer >>> overflow when seaching >>> timezone info files >>> >>> Dear all, >>> >>> please take a look at this small change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936- >>> >>> >>> Potential-Heap-buffer- >>> >>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >>> >>> readdir_r is used to iterate over the content of a >>> system directory, but >>> the buffer passed to it is too small: Its size should >>> include the size of >>> the dirent structure itself (minus the d_name member). >>> >>> The fix also now checks the return code of pathconf(), >>> and if pathconf() >>> returns an error, falls back to the NAME_MAX compile >>> time constant. >>> Finally, it imposes a minimum size for the buffer, >>> because on older >>> >>> System >>> >>> V systems NAME_MAX may be surprisingly small and >>> readdir_r will not check >>> the output buffer size. I think it is better to err on >>> the safe side >>> >>> here. >>> >>> Kind Regards, Thomas >>> >>> >>> >> > From thomas.stuefe at gmail.com Thu Sep 15 20:56:55 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 15 Sep 2016 22:56:55 +0200 Subject: RFR 9: 8166148 Fix for JDK-8165936 broke Solaris builds In-Reply-To: <949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com> References: <00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com> <949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com> Message-ID: Hi Roger, Thank you for taking care of this! Fix looks fine. Kind Regards, Thomas On Thursday, 15 September 2016, Roger Riggs wrote: > Please review a fix for build breakage on Solaris. > The NAME_MAX value does not seem to add much value in this case and is not > defined on all supported platforms. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-max-8166148/ > Issue: > https://bugs.openjdk.java.net/browse/JDK-8166148 > > Thanks, Roger > > > On 9/15/2016 1:39 PM, Roger Riggs wrote: > >> Hi Thomas, >> >> It looks like NAME_MAX is not defined on Solaris and breaks the build on >> Solaris. [1] >> >> An alternative would be to conditionally use PATH_MAX. >> >> But I think it would be reasonable to just remove the use of NAME_MAX, >> since the following >> code increases the value to at least 1024, which should be safe. >> >> If you don't have time to address this, I can propose a fix. >> >> Roger >> >> [1] 8166148 fix for JDK-8165936 broke solaris builds < >> https://bugs.openjdk.java.net/browse/JDK-8166148> >> >> >> On 9/14/2016 2:34 AM, Thomas St?fe wrote: >> >>> Hi all, >>> >>> thanks for the reviews. Here is version two: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential >>> -Heap-buffer-overflow-when-seaching-timezone-info-files/ >>> webrev.01/webrev/ >> Estuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when- >>> seaching-timezone-info-files/webrev.01/webrev/> >>> >>> Only cosmetic changes: >>> - made code pre-c99 compatible >>> - consistently use dirent64 >>> - fix indentation in ifs >>> - removed black between malloc and cast >>> >>> Kind Regards, Thomas >>> >>> >>> >>> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu < >>> masayoshi.okutsu at oracle.com > wrote: >>> >>> Looks good to me. Thank you for fixing this bug! >>> >>> Masayoshi >>> >>> >>> >>> On 9/13/2016 11:49 PM, Thomas St?fe wrote: >>> >>> Hi Christoph, thanks for your review! Yes, I can remove the >>> blank. >>> >>> Kind Regards, Thomas >>> >>> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph >>> >>> >>> wrote: >>> Hi Thomas, >>> >>> your change looks good. I'm also forwarding this to >>> i18n-dev as issues in >>> TimeZone implementation are mostly handled there. >>> >>> One remark: Can you take the opportunity to also remove >>> the blank between >>> the cast and malloc in line 150: "(struct dirent64 *) >>> malloc..."? >>> >>> Unfortunately I'm no reviewer, so you still need an >>> official review. >>> >>> Best regards >>> Christoph >>> >>> -----Original Message----- >>> From: core-libs-dev >>> [mailto:core-libs-dev-bounces at openjdk.java.net >>> ] On >>> >>> Behalf >>> >>> Of Thomas St?fe >>> Sent: Dienstag, 13. September 2016 12:54 >>> To: Java Core Libs >> > >>> Subject: RFR(xs): 8165936: Potential Heap buffer >>> overflow when seaching >>> timezone info files >>> >>> Dear all, >>> >>> please take a look at this small change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936- >>> >>> >>> Potential-Heap-buffer- >>> >>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/ >>> >>> readdir_r is used to iterate over the content of a >>> system directory, but >>> the buffer passed to it is too small: Its size should >>> include the size of >>> the dirent structure itself (minus the d_name member). >>> >>> The fix also now checks the return code of pathconf(), >>> and if pathconf() >>> returns an error, falls back to the NAME_MAX compile >>> time constant. >>> Finally, it imposes a minimum size for the buffer, >>> because on older >>> >>> System >>> >>> V systems NAME_MAX may be surprisingly small and >>> readdir_r will not check >>> the output buffer size. I think it is better to err on >>> the safe side >>> >>> here. >>> >>> Kind Regards, Thomas >>> >>> >>> >>> >> > From david.holmes at oracle.com Fri Sep 16 01:47:43 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Sep 2016 11:47:43 +1000 Subject: core-libs-dev Digest, Vol 113, Issue 53 In-Reply-To: References: Message-ID: <2f269a46-fcd7-bc73-c892-0469728cca1a@oracle.com> Hi Manjunath, When replying to something you see in a digest it would be a lot easier to follow if you could use the original subject line, or even go to the archives and respond to the original mail. Thanks, David On 16/09/2016 12:39 AM, Manjunath SV wrote: > Hi, > > I monitored memory usage, below are the details. > > Heap usage :- 857mb > Virtual memory:- 12.6gb > -Xmx set to 4gb. > > I have taken virtual and heap memory usage when Java spawns sub > processes. > > Thanks & Regards, > Manjunath > > On 15 Sep 2016 4:17 p.m., wrote: > > Send core-libs-dev mailing list submissions to > core-libs-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > or, via email, send a message with subject or body 'help' to > core-libs-dev-request at openjdk.java.net > > You can reach the person managing the list at > core-libs-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core-libs-dev digest..." > > > Today's Topics: > > 1. Re: RFC: System.console().encoding() (Xueming Shen) > 2. Re: RFC: System.console().encoding() (Dawid Weiss) > 3. Re: RFC: System.console().encoding() (Claes Redestad) > 4. Re: RFR: JDK-8134373: explore potential uses of convenience > factories within the JDK (Jonathan Bluett-Duncan) > 5. Re: Reg - Sub Process creation from java takes more time > (ecki at zusammenkunft.net) > 6. Re: RFC: System.console().encoding() (Jochen Theodorou) > 7. Re: RFC: System.console().encoding() (Dawid Weiss) > 8. Re: RFR: JDK-8134373: explore potential uses of convenience > factories within the JDK (Pavel Rappo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 15 Sep 2016 00:06:05 -0700 > From: Xueming Shen > To: core-libs-dev at openjdk.java.net > Subject: Re: RFC: System.console().encoding() > Message-ID: <57DA485D.100 at oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > -1 :-) > > Console is supposed to be a "char/String" based class, "encoding" really > should > have no business here in its api. Simply for some implementation convenience > is really not a good reason to add such a public method. > > That said, I would be fine to have such informative info in the system > properties, > together with its siblings, file,encoding and another "supposed to be > private" > property sun.jnu.encoding. > > sherman > > > On 9/14/16, 11:42 PM, Aleksey Shipilev wrote: >> Hi, >> >> Claes pointed out that our own reflective hacks to figure out console >> encoding do not work anymore [1]. But, we need the console encoding for >> reliably printing on the console from within different sources. Note >> that you would normally just use System.console() and its PrintWriter, >> but reality is a bit more complicated, and sometimes you need to write >> the plain char stream directly into the byte[]-accepting methods, >> encoding on your own. >> >> So, my question: should we, in the light of extended Jigsaw-solving >> crunch, provide the public Console.encoding() method that would return >> the console charset? >> >> Thanks, >> -Aleksey >> >> [1] >> http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html >> > > > > ------------------------------ > > Message: 2 > Date: Thu, 15 Sep 2016 09:21:01 +0200 > From: Dawid Weiss > To: Xueming Shen > Cc: core-libs-dev > Subject: Re: RFC: System.console().encoding() > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > >> Console is supposed to be a "char/String" based class, "encoding" really >> should have no business here in its api. > > While I agree with your concerns about the functional side of the API, > I disagree about this method having no practical use. I can give you a > concrete example. The use case that we had was to check whether the > "terminal" (console) would be able to handle non-ASCII characters. A > Writer doesn't tell you anything. An encoding does provide at least > some confidence that certain characters will be translated properly -- > if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't > get displayed for sure. This doesn't mean 100% confidence in actual > glyph rendering of course, but it's a cheap and safe sanity check of > the terminal's capabilities. > > An (undocumented) proprietary property? Sure, but I really don't see > the reason why this shouldn't be in the API, unless you know of > terminals that handle Unicode-based streams directly (in which case > the encoding method would simply return UTF32). > > Dawid > > > ------------------------------ > > Message: 3 > Date: Thu, 15 Sep 2016 10:18:29 +0200 > From: Claes Redestad > To: core-libs-dev at openjdk.java.net > Subject: Re: RFC: System.console().encoding() > Message-ID: <57DA5955.4070401 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > +1 > > Won't be enough, though, since in JMH it appears you're also getting > the encoding from System.out (java.io.PrintStream) via reflective > hacks. > > /Claes > > On 2016-09-15 08:42, Aleksey Shipilev wrote: >> Hi, >> >> Claes pointed out that our own reflective hacks to figure out console >> encoding do not work anymore [1]. But, we need the console encoding for >> reliably printing on the console from within different sources. Note >> that you would normally just use System.console() and its PrintWriter, >> but reality is a bit more complicated, and sometimes you need to write >> the plain char stream directly into the byte[]-accepting methods, >> encoding on your own. >> >> So, my question: should we, in the light of extended Jigsaw-solving >> crunch, provide the public Console.encoding() method that would return >> the console charset? >> >> Thanks, >> -Aleksey >> >> [1] >> http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html >> > > > ------------------------------ > > Message: 4 > Date: Thu, 15 Sep 2016 09:52:47 +0100 > From: Jonathan Bluett-Duncan > To: Patrick Reinhart , Stuart Marks > > Cc: core-libs-dev > Subject: Re: RFR: JDK-8134373: explore potential uses of convenience > factories within the JDK > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Thanks Patrick! > > Stuart, would you be happy to sponsor this change? > > If anyone else has any thoughts regarding this change, then I'm all ears. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 > Rationale for changes: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- > September/043484.html > > Kind regards, > Jonathan > > > On 14 September 2016 at 21:55, Patrick Reinhart wrote: > >> Hi Jonathan, >> >> Here are your changes in a webrev: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 >> >> -Patrick >> >> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : >> >> Hi Jonathan, >> >> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: >> >> Hi Patrick, >> Thank you very much for the offer to hold my patch for me! >> >> >> No problem. >> >> Is it common practice to send patches to others using PGP? >> >> >> No, this is my personal setting. >> >> Kind regards, >> Jonathan >> On 12 September 2016 at 21:08, Patrick Reinhart wrote: >> >> Hi Jonathan, >> As I just also wanted to help some more clean-up in the JDKs final phase, > I >> could offer you to hold that patch. Just send it to me and I will prepare >> the webrev for you?. >> -Patrick >> >> >> -Patrick >> >> >> > > > ------------------------------ > > Message: 5 > Date: Thu, 15 Sep 2016 11:01:01 +0200 > From: > To: "core-libs-dev at openjdk.java.net" > Subject: Re: Reg - Sub Process creation from java takes more time > Message-ID: <57da634c.c336c20a.19b0c.bec8 at mx.google.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > Do you monitor heap usage and virtual memory size of your Java process? I > would look out for increase (which causes slower for tines). > > Also it is generally a good idea to turn on GC logging and look into it if > a java process degregades over time > > Gruss > Bernd > > Just BTW: I think Java would not be the right tool to spawn and control > sich a high number of external processes. Maybe it would be better to hand > that off to a more native component. > -- > http://bernd.eckenfels.net > > Von: Manjunath SV > > ------------------------------ > > Message: 6 > Date: Thu, 15 Sep 2016 12:05:04 +0200 > From: Jochen Theodorou > To: core-libs-dev at openjdk.java.net > Subject: Re: RFC: System.console().encoding() > Message-ID: <57DA7250.9020406 at gmx.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > > > On 15.09.2016 09:21, Dawid Weiss wrote: >>> Console is supposed to be a "char/String" based class, "encoding" really >>> should have no business here in its api. >> >> While I agree with your concerns about the functional side of the API, >> I disagree about this method having no practical use. I can give you a >> concrete example. The use case that we had was to check whether the >> "terminal" (console) would be able to handle non-ASCII characters. A >> Writer doesn't tell you anything. An encoding does provide at least >> some confidence that certain characters will be translated properly -- >> if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't >> get displayed for sure. This doesn't mean 100% confidence in actual >> glyph rendering of course, but it's a cheap and safe sanity check of >> the terminal's capabilities. > > out of curiosity... what will you do if you find the encoding lacking > what you need? > > > bye Jochen > > > ------------------------------ > > Message: 7 > Date: Thu, 15 Sep 2016 12:17:26 +0200 > From: Dawid Weiss > To: Jochen Theodorou > Cc: core-libs-dev > Subject: Re: RFC: System.console().encoding() > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > >> out of curiosity... what will you do if you find the encoding lacking what >> you need? > > Oh, display a warning. Helps to figure out where those "???" > characters are coming from... > > Naive, I know. But it's the best one can do and it works (most of the time). > > D. > > > ------------------------------ > > Message: 8 > Date: Thu, 15 Sep 2016 11:46:17 +0100 > From: Pavel Rappo > To: Jonathan Bluett-Duncan > Cc: core-libs-dev > Subject: Re: RFR: JDK-8134373: explore potential uses of convenience > factories within the JDK > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Hi, > > I have had a look at the change. It looks good. > > Retrofitting Collections.unmodifiableXXX/Arrays.asList with Convenience > Factory > Methods requires extra carefulness as the factory methods are stricter than > any > of those. Not only do they provide unconditional non-modifiability [0], they > also do not tolerate `null` elements. > > It looks like you took all that into account. > Tiny little comments and suggestions. > > 1. It might be the case we no longer need this [1]: > > finderList.forEach(Objects::requireNonNull); > > as the List.of does the same thing for free. Though it might be okay to > leave it > as an explicit check. > > Also, could you please fix a typo here (the same file): > > * will be propogated to the caller of the resulting module finder's > ^ > 2. An interesting question (though it's a completely different issue) is > whether > or not the `cookieHeader` list in the map should also be unmodifiable [2]? > > 3. Could you please also fix the same (copy-pasted?) typo in FileTreeWalker? > > if {@code options} is {@ocde null} or the options > ^^ > 4. Please remove this line from the ZoneRules constructor's javadoc: > > @return the zone rules, not null > > 5. Maybe we should revisit javadoc on those fields in [3]: > > This List is {@linkplain Collections#unmodifiableList(List) > unmodifiable}. > > Since it's no longer the case. > > 6. I couldn't find any evidence that `resolverFields` might contain `null`. > Am I missing a javadoc or a line of code? Maybe we should talk to java.time > folks to see if it's the case? > > 7. Try to not make lines longer than they were before: 80 characters. Unless > it's really needed. > > Thanks, > -Pavel > > ------------------------------------------------------------ > -------------------- > [0] Compare List.of().remove(new Object()) with > Collections.emptyList().remove(new > Object()) > [1] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/ > webrev.00/src/java.base/share/classes/java/lang/module/ > ModuleFinder.java.sdiff.html > [2] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/ > webrev.00/src/java.base/share/classes/java/net/CookieManager.java.sdiff.html > [3] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/ > webrev.00/src/java.base/share/classes/java/util/ > ResourceBundle.java.sdiff.html > >> On 15 Sep 2016, at 09:52, Jonathan Bluett-Duncan > wrote: >> >> Thanks Patrick! >> >> Stuart, would you be happy to sponsor this change? >> >> If anyone else has any thoughts regarding this change, then I'm all ears. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 >> Rationale for changes: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- > September/043484.html >> >> Kind regards, >> Jonathan >> >> >> On 14 September 2016 at 21:55, Patrick Reinhart wrote: >> >>> Hi Jonathan, >>> >>> Here are your changes in a webrev: >>> >>> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 >>> >>> -Patrick >>> >>> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : >>> >>> Hi Jonathan, >>> >>> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: >>> >>> Hi Patrick, >>> Thank you very much for the offer to hold my patch for me! >>> >>> >>> No problem. >>> >>> Is it common practice to send patches to others using PGP? >>> >>> >>> No, this is my personal setting. >>> >>> Kind regards, >>> Jonathan >>> On 12 September 2016 at 21:08, Patrick Reinhart > wrote: >>> >>> Hi Jonathan, >>> As I just also wanted to help some more clean-up in the JDKs final > phase, I >>> could offer you to hold that patch. Just send it to me and I will prepare >>> the webrev for you?. >>> -Patrick >>> >>> >>> -Patrick >>> >>> >>> > > > > End of core-libs-dev Digest, Vol 113, Issue 53 > ********************************************** > From manju.jccs at gmail.com Fri Sep 16 05:48:43 2016 From: manju.jccs at gmail.com (Manjunath SV) Date: Fri, 16 Sep 2016 11:18:43 +0530 Subject: Reg - Sub Process creation from java takes more time Message-ID: Hi, I monitored memory usage, below are the details. Heap usage :- 857mb Virtual memory:- 12.6gb -Xmx set to 4gb. I have taken virtual and heap memory usage when Java spawns sub processes. Sub processes have short life, will be done in milli seconds. Thanks & Regards, Manjunath Message: 5 Date: Thu, 15 Sep 2016 11:01:01 +0200 From: To: "core-libs-dev at openjdk.java.net" Subject: Re: Reg - Sub Process creation from java takes more time Message-ID: <57da634c.c336c20a.19b0c.bec8 at mx.google.com> Content-Type: text/plain; charset="utf-8" Hello, Do you monitor heap usage and virtual memory size of your Java process? I would look out for increase (which causes slower for tines). Also it is generally a good idea to turn on GC logging and look into it if a java process degregades over time Gruss Bernd Just BTW: I think Java would not be the right tool to spawn and control sich a high number of external processes. Maybe it would be better to hand that off to a more native component. -- http://bernd.eckenfels.net Von: Manjunath SV From ecki at zusammenkunft.net Fri Sep 16 06:33:01 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Fri, 16 Sep 2016 08:33:01 +0200 Subject: Reg - Sub Process creation from java takes more time In-Reply-To: References: Message-ID: <57db921d.d8941c0a.2ec57.1002@mx.google.com> Hello, Does the (virtual) size increase over time when it gets slower? How does the GC log looks like, any increasing activity or longer pauses? If you let this VM run for longer time (when it slows down), will it eventually fail because of some resource exhaustion? How often does the execute work fast, after what numberbof executions and what runtime it gets slower? You can also strace the process to see if the execution time of fork() and exec() syscalls increase. Gruss Bernd -- http://bernd.eckenfels.net >From Win 10 Mobile Von: Manjunath SV From jan.lahoda at oracle.com Fri Sep 16 09:23:57 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 16 Sep 2016 11:23:57 +0200 Subject: RFR 8166051: [jline] Cannot parse .inputrc with \r Message-ID: <57DBBA2D.9050705@oracle.com> Please review a change to how .inputrc is read. Currently, it uses BufferedReader.readLine(), which interprets '\r' as a line separator, and so the '\r' character cannot be used in the macros. The proposed change is to use System.getProperty("line.separator") and "\n" as line separators. Bug: https://bugs.openjdk.java.net/browse/JDK-8166051 Webrev: http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/ Thanks! Jan From christoph.langer at sap.com Fri Sep 16 09:58:27 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 16 Sep 2016 09:58:27 +0000 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build Message-ID: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Hi, the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ Thanks Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Kumar Srinivasan > Sent: Montag, 12. September 2016 22:57 > To: core-libs-dev ; Mandy Chung > ; Chris Bensen > Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > > Hello, > > I am sponsoring this changeset for Chris Bensen of the java packager > team, please review fix for the launcher to better locate java.home. > > http://cr.openjdk.java.net/~ksrini/8165524/ > > Thanks > Kumar From alexey.ivanov at oracle.com Fri Sep 16 10:20:30 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 16 Sep 2016 13:20:30 +0300 Subject: OpenJDK JDK-7067885 code changes for community review In-Reply-To: References: Message-ID: <549b7026-cbf3-8bc3-a593-561699431554@oracle.com> Hi Alok, This change should be discussed on swing-dev mailing list because you modify behavior of javax.swing.JFileChooser, and on core-libs-dev because you also modify java.io.File. I agree with Alan, using the new API appears to be a better alternative than changing java.io.File. Regards, Alexey On 12.09.2016 19:08, Alan Bateman wrote: > Best to follow-up on swing-dev as I assume the right thing is to > update JFileChooser rather than changing java.io.File to be mutable. > You did acknowledge near the end of your mail that the new file system > API supports sym links so it may be that JFileChooser could use that. > > -Alan > > > On 12/09/2016 08:41, Sharma, Alok Kumar (OSTL) wrote: >> Following is the fix for JDK-7067885. I am not sure which mailing ID >> to post this. >> >> Bug: FileChooser does not display soft link name if link is to >> nonexistent file/directory >> https://bugs.openjdk.java.net/browse/JDK-7067885 >> >> This bug is unassigned. Can someone please look into these changes >> and get back to me? Explanation of fix is at the end of the source >> code diff. >> >> Mercurial diff for source change: >> ------------------------------------------------------------------- >> diff -r 021369229cfd src/java.base/share/classes/java/io/File.java >> --- a/src/java.base/share/classes/java/io/File.java Tue Sep 06 >> 13:09:29 2016 -0400 >> +++ b/src/java.base/share/classes/java/io/File.java Mon Sep 12 >> 11:27:07 2016 +0530 >> @@ -164,6 +164,27 @@ >> private final String path; >> >> /** >> + * The flag indicates whether to follow the symlink. >> + */ >> + private boolean follow_link = true; >> + >> + /** >> + * Sets the follow_link of file. >> + * description: Sets follow_link on or off. >> + * @param follow_link the value that determines whether to follow >> the symlink or not. >> + * TRUE: file.io.exists() checks the file existence using >> stat() which follows the symlink. >> + * >> + * FALSE: file.io.exists() checks the file existence using >> lstat() if stat() fails to retrieve >> + * the file info. lstat() if file is a symbolic link, then >> it returns information >> + * about the link itself. >> + * @return Returns ZERO at success >> + */ >> + public int set_follow_link(boolean follow_link) { >> + this.follow_link=follow_link; >> + return 0; >> + } >> + >> + /** >> * Enum type that indicates the status of a file path. >> */ >> private static enum PathStatus { INVALID, CHECKED }; >> diff -r 021369229cfd >> src/java.base/unix/native/libjava/UnixFileSystem_md.c >> --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Tue Sep >> 06 13:09:29 2016 -0400 >> +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon Sep >> 12 11:27:07 2016 +0530 >> @@ -51,6 +51,7 @@ >> #define dirent64 dirent >> #define readdir64_r readdir_r >> #define stat64 stat >> +#define lstat64 lstat >> #ifndef MACOSX >> #define statvfs64 statvfs >> #endif >> @@ -62,6 +63,7 @@ >> jfieldID path; >> } ids; >> >> +jfieldID ufs_follow_link; >> >> JNIEXPORT void JNICALL >> Java_java_io_UnixFileSystem_initIDs(JNIEnv *env, jclass cls) >> @@ -70,6 +72,8 @@ >> if (!fileClass) return; >> ids.path = (*env)->GetFieldID(env, fileClass, >> "path", "Ljava/lang/String;"); >> + ufs_follow_link = (*env)->GetFieldID(env, fileClass, >> + "follow_link", "Z"); >> } >> >> /* -- Path operations -- */ >> @@ -113,20 +117,42 @@ >> return JNI_FALSE; >> } >> >> +static jboolean >> +lstatMode(const char *path, int *mode) >> +{ >> + struct stat64 sb; >> + if (lstat64(path, &sb) == 0) { >> + *mode = sb.st_mode; >> + return JNI_TRUE; >> + } >> + return JNI_FALSE; >> +} >> >> JNIEXPORT jint JNICALL >> Java_java_io_UnixFileSystem_getBooleanAttributes0(JNIEnv *env, >> jobject this, >> jobject file) >> { >> jint rv = 0; >> + jint follow_link = 0; >> >> WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) { >> int mode; >> - if (statMode(path, &mode)) { >> - int fmt = mode & S_IFMT; >> - rv = (jint) (java_io_FileSystem_BA_EXISTS >> - | ((fmt == S_IFREG) ? >> java_io_FileSystem_BA_REGULAR : 0) >> - | ((fmt == S_IFDIR) ? >> java_io_FileSystem_BA_DIRECTORY : 0)); >> + follow_link = (*env)->GetBooleanField(env, file, >> ufs_follow_link); >> + if ( follow_link ) { >> + if (statMode(path, &mode)) { >> + int fmt = mode & S_IFMT; >> + rv = (jint) (java_io_FileSystem_BA_EXISTS >> + | ((fmt == S_IFREG) ? >> java_io_FileSystem_BA_REGULAR : 0) >> + | ((fmt == S_IFDIR) ? >> java_io_FileSystem_BA_DIRECTORY : 0)); >> + } >> + } >> + else { >> + if (lstatMode(path, &mode)) { >> + int fmt = mode & S_IFMT; >> + rv = (jint) (java_io_FileSystem_BA_EXISTS >> + | ((fmt == S_IFREG) ? >> java_io_FileSystem_BA_REGULAR : 0) >> + | ((fmt == S_IFDIR) ? >> java_io_FileSystem_BA_DIRECTORY : 0)); >> + } >> } >> } END_PLATFORM_STRING(env, path); >> return rv; >> diff -r 021369229cfd >> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >> --- >> a/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >> Tue Sep 06 13:09:29 2016 -0400 >> +++ >> b/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >> Mon Sep 12 11:27:07 2016 +0530 >> @@ -521,6 +521,7 @@ >> f = createFileSystemRoot(f); >> } >> try { >> + f.set_follow_link(false); >> f = ShellFolder.getShellFolder(f); >> } catch (FileNotFoundException e) { >> // Not a valid file (wouldn't show in native >> file chooser) >> ------------------------------------------ >> >> Below is the explanation for fix. >> >> Problem description: >> FileChooser behavior when there is a soft link to a non-existent >> file/directory. >> Soft link to be displayed with an error/exception when attempt is >> made to >> open it. Instead the soft link name is not displayed in the file >> chooser. >> >> Analysis: >> JFileChooser() internally uses java.io.exists() to check whether file >> exists. >> In this scenario JFileChooser() checks dangling symlink existence >> using java.io.exists(). >> java.io.exists() api does not handle dangling symlink and returns false. >> >> JFileChooser() expects exists() api to return true for dangling >> symlink but, java.io.exists() returns false. >> >> We see that there are two exists() apis in JAVA java.io.exists() and >> java.nio.exists(). >> >> java.nio.exists() handles dangling symlinks it accepts second >> argument link option which >> determines whether to follow the link or not and returns true for >> dangling symlinks. >> java.io.exists() follows the symlink and returns false if target file >> doesn't exist. >> >> We have enhanced the java.io.exists() api to return true if it is a >> dangling symlink. >> >> Changes in code: >> >> New variable "follow_link" is introduced in >> "jdk/src/java.base/share/classes/java/io/File.java", we check for >> this flag in exists() code >> if its set then we handle symlinks. In case of dangling symlink >> java.io.exists() api checks file existence >> symlink itself not the target file and returns true. >> >> JFileChooser() issue (JDK-7067885) gets resolved with these changes. >> >> Testing: >> I have covered the testing for the below apis. >> Jfilechooser >> getShellFolder >> FileSystemView >> and ran /openjdk9/jdk/test/javax/swing/JFileChooser/* tests. >> > From brian.goetz at oracle.com Fri Sep 16 15:09:39 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 16 Sep 2016 08:09:39 -0700 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> Message-ID: <466883E6-60CC-4CE5-BE2F-A29AE5EA4C04@oracle.com> Sorry for being late to this party. I like the approach, but I have some concerns about the evolvability of this API. The filter already receives a handful of parameters; it seems quite unlikely that a use case will not emerge where the filter needs more information in the future (say, the caller context, the caller class loader, etc.) One strategy for evolution is, rather than pass a handful of parameters, pass an aggregate, where the aggregate has getters for the parameters. Then more getters can be added in the future. There are other strategies too - but I am concerned about being in a migration situation only a few years down the road, where there is information that the filter needs. > On Sep 8, 2016, at 12:09 PM, Roger Riggs wrote: > > Please review updates to the Serialization filtering API and implementation: > - The ObjectInputFilter pattern based filters support matching on module names as well as package and class names. > - Rename of system property and java.security property for configurable filters. (jdk.serialFilter) > - ObjectInputFilter clarifications about the values passed to the filter > - Javadoc editorial improvements > - Clarification of SerializablePermission description of targets > > - More tests > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ > > SpecDiff: > http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html > > Javadoc (subset) > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html > > Thanks, Roger > > > From mandy.chung at oracle.com Fri Sep 16 17:31:10 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Sep 2016 10:31:10 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <798C46FD-9A42-4DC2-AE6F-BE51FD636987@oracle.com> > On Sep 16, 2016, at 2:58 AM, Langer, Christoph wrote: > > Hi, > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ This looks okay. It?d be good to consolidate the hotspot and awt code as a JVM entry point. But launcher would need to carry this copy since dladdr is called before libjvm.so is loaded. formatting nit: not align with lines above (4-space indentation) 55 } 56 return 0; Mandy From volker.simonis at gmail.com Fri Sep 16 17:34:07 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 16 Sep 2016 19:34:07 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: Hi Christoph, I think your change is fine as a quick-fix to fix the build. But you're completely right that this should be reworked in the long term. I hate to see that we now have the third version of these routines in the OpenJDK. Unfortunately a clean solution is not trivial. libjli is not linked against libjvm because libjli is actually used to load libjvm. So we can not put the dladdr routines for AIX there. But I think we should at least consolidate the two versions which will be in the class library after your change. Initially I intentionally put porting_aix.{c,h} into jdk/aix/porting with the intent to make it available to ALL jdk native libraries. Unfortunately, with the source code reorganization due to the modular changes, the common, top-level aix repository had to go away and the code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. With the reorganized, modularized source code layout and build system it is not possible to share code between modules. We somehow have to fix this although I currently don't know how. IF somebody has an idea, please let me know :) Regarding your change: - can you please move +#if defined(_AIX) +#include "java_md_aix.h" +#endif + from java_md_common.c to the end of java.base/unix/native/libjli/java_md.h. It will then be automatically included into java_md_common.c trough java.h which includes java_md.h Also, this version of dladdr is inherently not thread safe. I don't think that's a problem here, but it would be nice if you could quickly check if that's indeed true. Besides that, looks good. Thanks for fixing, Volker On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph wrote: > Hi, > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > Thanks > Christoph > > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Kumar Srinivasan >> Sent: Montag, 12. September 2016 22:57 >> To: core-libs-dev ; Mandy Chung >> ; Chris Bensen >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >> >> Hello, >> >> I am sponsoring this changeset for Chris Bensen of the java packager >> team, please review fix for the launcher to better locate java.home. >> >> http://cr.openjdk.java.net/~ksrini/8165524/ >> >> Thanks >> Kumar > From chris.bensen at oracle.com Fri Sep 16 17:47:41 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Fri, 16 Sep 2016 10:47:41 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <23CB8480-3742-4120-BEDA-9055155B31EE@oracle.com> I assume libjvm.so has access to dlopen and dlsym? Can the AIX implementation of dladdr live in libjli.so and libjvm.so load it from there? Chris > On Sep 16, 2016, at 10:34 AM, Volker Simonis wrote: > > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the long term. > I hate to see that we now have the third version of these routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually used to > load libjvm. So we can not put the dladdr routines for AIX there. But > I think we should at least consolidate the two versions which will be > in the class library after your change. Initially I intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the modular > changes, the common, top-level aix repository had to go away and the > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build system > it is not possible to share code between modules. We somehow have to > fix this although I currently don't know how. IF somebody has an idea, > please let me know :) > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be automatically > included into java_md_common.c trough java.h which includes java_md.h > > Also, this version of dladdr is inherently not thread safe. I don't > think that's a problem here, but it would be nice if you could quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > wrote: >> Hi, >> >> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. >> >> There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >> >> Thanks >> Christoph >> >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>> Of Kumar Srinivasan >>> Sent: Montag, 12. September 2016 22:57 >>> To: core-libs-dev ; Mandy Chung >>> ; Chris Bensen >>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>> >>> Hello, >>> >>> I am sponsoring this changeset for Chris Bensen of the java packager >>> team, please review fix for the launcher to better locate java.home. >>> >>> http://cr.openjdk.java.net/~ksrini/8165524/ >>> >>> Thanks >>> Kumar >> From steve.drach at oracle.com Fri Sep 16 18:40:08 2016 From: steve.drach at oracle.com (Steve Drach) Date: Fri, 16 Sep 2016 11:40:08 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: References: <8E7A5A0F-1789-43B5-AA88-AA3FBC57C267@oracle.com> <23D4FB21-E8A4-400E-AC56-A946D0D95709@oracle.com> <270759B0-3B61-46C1-B127-8B36499BA0EA@oracle.com> Message-ID: <8A53F66F-1A97-41B8-8AEF-83ED1F12F690@oracle.com> A relatively minor update. I simplified VersionHelper. No other changes. http://cr.openjdk.java.net/~sdrach/8153654/webrev.12/ > On Sep 14, 2016, at 4:06 PM, Steve Drach wrote: > > The most recent webrev is http://cr.openjdk.java.net/~sdrach/8153654/webrev.11/ > > Comments inline > >>> The latest web revs. Answers to questions in-line below: >>> >>> http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/ >>> >>> http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ >> >> This looks pretty good. My main comment is in VersionHelper (see below). >> >> ClassFileReader.java >> >> 337 String[] msg = {"err.multirelease.option.exists", f.getName()}; >> 389 String[] msg = {"err.multirelease.jar.malformed?, >> 390 jarfile.getName(), rn >> 391 }; >> >> `msg` is not used. These lines can be removed. > > Done > >> >> line 81-95: this wants to add to VersionHelper if it?s a versioned entry. I suggest to move this to VersionHelper, something like this and replace the add method. > > I did essentially the same thing, but not exactly the same. > >> >> public static void addIfVersionedEntry(Path jarfile, String realEntryName, String className) { >> if (realEntryName.startsWith(META_INF_VERSIONS)) { >> int len = META_INF_VERSIONS.length(); >> int n = realEntryName.indexOf('/', len); >> if (n > 0) { >> String version = realEntryName.substring(len, n); >> assert (Integer.parseInt(version) > 8); >> >> String v = versionMap.get(className); >> if (v != null && !v.equals(version)) { >> // name associated with a different ClassFile >> throw new MultiReleaseException("err.multirelease.version.associated", className, >> v, version); >> } >> versionMap.put(className, version); >> } else { >> throw new MultiReleaseException("err.multirelease.jar.malformed", >> jarfile.toString(), realEntryName); >> } >> } >> } >> >> I prefer to call String::length rather than hardcoding the length. > > OK > >> I don?t see why VersionHelper caches ClassFile. > > A JarEntry (base) name has a one to many relationship with versions. This implies the class name also has a one to many relationship with versions. But a ClassFile (derived from the contents of the JarEntry) has a one to one relationship with version. We desire a one to one > relationship for className to version and one way to assure that is to create two maps as I now have done. I think the code is more obvious now, at least I hope it is. > >> I think it can cache a map from class name to the version for now. We may have to handle duplicated classes in more than one modular jar (it?s not exported and should be allowed). We could file a separate issue to look into later. >> >> This needs a CCC for the new --multi-release option. > > That?s next. > >> >> Mandy > From mandy.chung at oracle.com Fri Sep 16 20:18:33 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Sep 2016 13:18:33 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: <8A53F66F-1A97-41B8-8AEF-83ED1F12F690@oracle.com> References: <8E7A5A0F-1789-43B5-AA88-AA3FBC57C267@oracle.com> <23D4FB21-E8A4-400E-AC56-A946D0D95709@oracle.com> <270759B0-3B61-46C1-B127-8B36499BA0EA@oracle.com> <8A53F66F-1A97-41B8-8AEF-83ED1F12F690@oracle.com> Message-ID: > On Sep 16, 2016, at 11:40 AM, Steve Drach wrote: > > A relatively minor update. I simplified VersionHelper. No other changes. > > http://cr.openjdk.java.net/~sdrach/8153654/webrev.12/ This looks good. Thanks for the update. Minor comments below and you can make the change before you push (no need for a new webrev). MultiReleaseException.java key and msg should be final fields VersionHelper.java nameToVersion can simply be Map (I missed this last round) 63 public static void add(JarFile jarfile, JarEntry e, ClassFile cf) throws ConstantPoolException { - can you break ?throws ?? to the next line. 56 String name = cf.getName().replace('/', '.'); 57 nameToVersion.put(name, version); Can you add a check to make sure the version is the same if the entry is present; otherwise, throw InternalError. This will catch any unexpected code path. Mandy From steve.drach at oracle.com Fri Sep 16 20:30:54 2016 From: steve.drach at oracle.com (Steve Drach) Date: Fri, 16 Sep 2016 13:30:54 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: References: <8E7A5A0F-1789-43B5-AA88-AA3FBC57C267@oracle.com> <23D4FB21-E8A4-400E-AC56-A946D0D95709@oracle.com> <270759B0-3B61-46C1-B127-8B36499BA0EA@oracle.com> <8A53F66F-1A97-41B8-8AEF-83ED1F12F690@oracle.com> Message-ID: <4569C966-D70B-47BF-B154-60920DC1997D@oracle.com> > This looks good. Thanks for the update. > > Minor comments below and you can make the change before you push (no need for a new webrev). > > MultiReleaseException.java > key and msg should be final fields Done. > > VersionHelper.java > nameToVersion can simply be Map (I missed this last round) It should be , see line 43 of VersionHelper. > > 63 public static void add(JarFile jarfile, JarEntry e, ClassFile cf) throws ConstantPoolException { > > - can you break ?throws ?? to the next line. Done > > 56 String name = cf.getName().replace('/', '.'); > 57 nameToVersion.put(name, version); > > Can you add a check to make sure the version is the same if the entry is present; otherwise, throw InternalError. This will catch any unexpected code path. That?s a good idea, but is InternalError the right one? The spec is a bit ambiguous but implies to me that it?s a JVM error since it?s a subclass of VirtualMachineError. How about just using the MultiReleaseException? > > Mandy From mandy.chung at oracle.com Fri Sep 16 20:56:13 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Sep 2016 13:56:13 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: <4569C966-D70B-47BF-B154-60920DC1997D@oracle.com> References: <8E7A5A0F-1789-43B5-AA88-AA3FBC57C267@oracle.com> <23D4FB21-E8A4-400E-AC56-A946D0D95709@oracle.com> <270759B0-3B61-46C1-B127-8B36499BA0EA@oracle.com> <8A53F66F-1A97-41B8-8AEF-83ED1F12F690@oracle.com> <4569C966-D70B-47BF-B154-60920DC1997D@oracle.com> Message-ID: > On Sep 16, 2016, at 1:30 PM, Steve Drach wrote: > >> >> VersionHelper.java >> nameToVersion can simply be Map (I missed this last round) > > It should be , see line 43 of VersionHelper. This returns a concatenated string. line 43 will work as is as (javap shows what javac emits.) > >> >> 56 String name = cf.getName().replace('/', '.'); >> 57 nameToVersion.put(name, version); >> >> Can you add a check to make sure the version is the same if the entry is present; otherwise, throw InternalError. This will catch any unexpected code path. > > That?s a good idea, but is InternalError the right one? The spec is a bit ambiguous but implies to me that it?s a JVM error since it?s a subclass of VirtualMachineError. How about just using the MultiReleaseException? MultiReleaseException or InternalError is fine too. Right now jdeps will only parse a MRJAR of a given version. I expect that we won?t run into this conflict but we may have missed other scenarios. Mandy From volker.simonis at gmail.com Sat Sep 17 15:11:04 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 17 Sep 2016 17:11:04 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <23CB8480-3742-4120-BEDA-9055155B31EE@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <23CB8480-3742-4120-BEDA-9055155B31EE@oracle.com> Message-ID: Not sure if that's a good idea. You can have a custom launcher which doesn't use libjli.so and I don't think we want to make libjvm.so dependent on libjli.so. On Fri, Sep 16, 2016 at 7:47 PM, Chris Bensen wrote: > I assume libjvm.so has access to dlopen and dlsym? Can the AIX > implementation of dladdr live in libjli.so and libjvm.so load it from there? > > Chris > > > On Sep 16, 2016, at 10:34 AM, Volker Simonis > wrote: > > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the long term. > I hate to see that we now have the third version of these routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually used to > load libjvm. So we can not put the dladdr routines for AIX there. But > I think we should at least consolidate the two versions which will be > in the class library after your change. Initially I intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the modular > changes, the common, top-level aix repository had to go away and the > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build system > it is not possible to share code between modules. We somehow have to > fix this although I currently don't know how. IF somebody has an idea, > please let me know :) > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be automatically > included into java_md_common.c trough java.h which includes java_md.h > > Also, this version of dladdr is inherently not thread safe. I don't > think that's a problem here, but it would be nice if you could quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > wrote: > > Hi, > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX > build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. With the proposed > change I duplicate the awt port to libjli. This is maybe only a quick fix - > eventually we should think about consolidating and using the hotspot port in > all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > Thanks > Christoph > > > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf > Of Kumar Srinivasan > Sent: Montag, 12. September 2016 22:57 > To: core-libs-dev ; Mandy Chung > ; Chris Bensen > Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > > Hello, > > I am sponsoring this changeset for Chris Bensen of the java packager > team, please review fix for the launcher to better locate java.home. > > http://cr.openjdk.java.net/~ksrini/8165524/ > > Thanks > Kumar > > > From dmitry.samersoff at oracle.com Sat Sep 17 18:30:40 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 17 Sep 2016 21:30:40 +0300 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <0b84a890-e6b0-8a85-c87c-7632fab2b6e1@oracle.com> Christoph, java_md_aix.c 32: missed comma after L_GETINFO Should you return an error from fill_dll_info rather than print it to stderr? -Dmitry On 2016-09-16 12:58, Langer, Christoph wrote: > Hi, > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > Thanks > Christoph > > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Kumar Srinivasan >> Sent: Montag, 12. September 2016 22:57 >> To: core-libs-dev ; Mandy Chung >> ; Chris Bensen >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >> >> Hello, >> >> I am sponsoring this changeset for Chris Bensen of the java packager >> team, please review fix for the launcher to better locate java.home. >> >> http://cr.openjdk.java.net/~ksrini/8165524/ >> >> Thanks >> Kumar > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Roger.Riggs at Oracle.com Sat Sep 17 19:26:20 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Sat, 17 Sep 2016 15:26:20 -0400 Subject: RFR 9: 8155760 Implement Serialization Filtering In-Reply-To: <466883E6-60CC-4CE5-BE2F-A29AE5EA4C04@oracle.com> References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> <466883E6-60CC-4CE5-BE2F-A29AE5EA4C04@oracle.com> Message-ID: <435b73b8-e87c-9042-18a3-293aea0062e7@Oracle.com> Hi Brian, ok, I'll take a look at making the information available about the object being created and from the stream easy to extend. Thanks, Roger On 9/16/2016 11:09 AM, Brian Goetz wrote: > Sorry for being late to this party. > > I like the approach, but I have some concerns about the evolvability of this API. The filter already receives a handful of parameters; it seems quite unlikely that a use case will not emerge where the filter needs more information in the future (say, the caller context, the caller class loader, etc.) One strategy for evolution is, rather than pass a handful of parameters, pass an aggregate, where the aggregate has getters for the parameters. Then more getters can be added in the future. There are other strategies too - but I am concerned about being in a migration situation only a few years down the road, where there is information that the filter needs. > > > >> On Sep 8, 2016, at 12:09 PM, Roger Riggs wrote: >> >> Please review updates to the Serialization filtering API and implementation: >> - The ObjectInputFilter pattern based filters support matching on module names as well as package and class names. >> - Rename of system property and java.security property for configurable filters. (jdk.serialFilter) >> - ObjectInputFilter clarifications about the values passed to the filter >> - Javadoc editorial improvements >> - Clarification of SerializablePermission description of targets >> >> - More tests >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ >> >> SpecDiff: >> http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html >> >> Javadoc (subset) >> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html >> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html >> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html >> >> Thanks, Roger >> >> >> From christoph.langer at sap.com Mon Sep 19 08:44:38 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 19 Sep 2016 08:44:38 +0000 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <117e635e0107427096606bd19906fe8b@DEWDFE13DE11.global.corp.sap> Hi all, thanks for your valuable input. So, since libjli.so can't use libjvm.so and its dladdr() port, there's no way around the libjli.so specific version of it. However, in libjli.so it is only used for resolving pathnames of the program, so the code can be very lean. Hence I completely reduced it to delivering the pathname of a module. And this code is not thread safe, as Volker mentioned. I would think/hope that a launcher would do its resolving work all in one thread and this should not be an issue. Maybe someone of the jli experts can confirm this or object against it. For now I would not spend more efforts in making this multi thread capable. As for the libawt version of dladdr(), this one should be removed and redirected to hotspot. I'll have a look at this when I find time. Please find a new webrev where I have addressed all findings and concerns - corrected spaces and indentation - removed the printf output in favor of handling the return code - only fill the info->dli_fname field - move conditional include to src/java.base/unix/native/libjli/java_md.h http://cr.openjdk.java.net/~clanger/webrevs/8166189.1/ Best regards Christoph > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Freitag, 16. September 2016 19:34 > To: Langer, Christoph > Cc: Kumar Srinivasan ; Mandy Chung > ; Chris Bensen ; > Thomas St?fe ; Lindenmaier, Goetz > ; core-libs-dev dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the long term. > I hate to see that we now have the third version of these routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually used to > load libjvm. So we can not put the dladdr routines for AIX there. But > I think we should at least consolidate the two versions which will be > in the class library after your change. Initially I intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the modular > changes, the common, top-level aix repository had to go away and the > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build system > it is not possible to share code between modules. We somehow have to > fix this although I currently don't know how. IF somebody has an idea, > please let me know :) > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be automatically > included into java_md_common.c trough java.h which includes java_md.h > > Also, this version of dladdr is inherently not thread safe. I don't > think that's a problem here, but it would be nice if you could quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > wrote: > > Hi, > > > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX > build as function dladdr is not available on AIX. > > > > There already exist ports of that API in hotspot and awt. With the proposed > change I duplicate the awt port to libjli. This is maybe only a quick fix - > eventually we should think about consolidating and using the hotspot port in all > places by exporting it from libjvm.so for AIX. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > > > Thanks > > Christoph > > > > > >> -----Original Message----- > >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf > >> Of Kumar Srinivasan > >> Sent: Montag, 12. September 2016 22:57 > >> To: core-libs-dev ; Mandy Chung > >> ; Chris Bensen > >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > >> > >> Hello, > >> > >> I am sponsoring this changeset for Chris Bensen of the java packager > >> team, please review fix for the launcher to better locate java.home. > >> > >> http://cr.openjdk.java.net/~ksrini/8165524/ > >> > >> Thanks > >> Kumar > > From goetz.lindenmaier at sap.com Mon Sep 19 09:09:42 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 19 Sep 2016 09:09:42 +0000 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <117e635e0107427096606bd19906fe8b@DEWDFE13DE11.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <117e635e0107427096606bd19906fe8b@DEWDFE13DE11.global.corp.sap> Message-ID: <9bcadb4ee1a843528829b9eee07bad97@DEWDFE13DE50.global.corp.sap> Hi Christoph, This looks good now. Please adapt the copyright year in java_md.h. I would appreciate this getting pushed to get our builds going again. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 19. September 2016 10:45 > To: Volker Simonis > Cc: Kumar Srinivasan ; Mandy Chung > ; Chris Bensen ; > Lindenmaier, Goetz ; core-libs-dev dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; Dmitry > Samersoff > Subject: RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > Hi all, > > thanks for your valuable input. > > So, since libjli.so can't use libjvm.so and its dladdr() port, there's no way > around the libjli.so specific version of it. However, in libjli.so it is only used for > resolving pathnames of the program, so the code can be very lean. Hence I > completely reduced it to delivering the pathname of a module. And this code > is not thread safe, as Volker mentioned. I would think/hope that a launcher > would do its resolving work all in one thread and this should not be an issue. > Maybe someone of the jli experts can confirm this or object against it. For > now I would not spend more efforts in making this multi thread capable. > > As for the libawt version of dladdr(), this one should be removed and > redirected to hotspot. I'll have a look at this when I find time. > > Please find a new webrev where I have addressed all findings and concerns > - corrected spaces and indentation > - removed the printf output in favor of handling the return code > - only fill the info->dli_fname field > - move conditional include to src/java.base/unix/native/libjli/java_md.h > > http://cr.openjdk.java.net/~clanger/webrevs/8166189.1/ > > Best regards > Christoph > > > -----Original Message----- > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > Sent: Freitag, 16. September 2016 19:34 > > To: Langer, Christoph > > Cc: Kumar Srinivasan ; Mandy Chung > > ; Chris Bensen ; > > Thomas St?fe ; Lindenmaier, Goetz > > ; core-libs-dev > dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net > > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > > > Hi Christoph, > > > > I think your change is fine as a quick-fix to fix the build. But > > you're completely right that this should be reworked in the long term. > > I hate to see that we now have the third version of these routines in > > the OpenJDK. Unfortunately a clean solution is not trivial. > > > > libjli is not linked against libjvm because libjli is actually used to > > load libjvm. So we can not put the dladdr routines for AIX there. But > > I think we should at least consolidate the two versions which will be > > in the class library after your change. Initially I intentionally put > > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > > available to ALL jdk native libraries. > > > > Unfortunately, with the source code reorganization due to the modular > > changes, the common, top-level aix repository had to go away and the > > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > > With the reorganized, modularized source code layout and build system > > it is not possible to share code between modules. We somehow have to > > fix this although I currently don't know how. IF somebody has an idea, > > please let me know :) > > > > Regarding your change: > > > > - can you please move > > > > +#if defined(_AIX) > > +#include "java_md_aix.h" > > +#endif > > + > > > > from java_md_common.c to the end of > > java.base/unix/native/libjli/java_md.h. It will then be automatically > > included into java_md_common.c trough java.h which includes java_md.h > > > > Also, this version of dladdr is inherently not thread safe. I don't > > think that's a problem here, but it would be nice if you could quickly > > check if that's indeed true. > > > > Besides that, looks good. > > > > Thanks for fixing, > > Volker > > > > > > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > > wrote: > > > Hi, > > > > > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks > the AIX > > build as function dladdr is not available on AIX. > > > > > > There already exist ports of that API in hotspot and awt. With the > proposed > > change I duplicate the awt port to libjli. This is maybe only a quick fix - > > eventually we should think about consolidating and using the hotspot port > in all > > places by exporting it from libjvm.so for AIX. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > > > > > Thanks > > > Christoph > > > > > > > > >> -----Original Message----- > > >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] > On > > Behalf > > >> Of Kumar Srinivasan > > >> Sent: Montag, 12. September 2016 22:57 > > >> To: core-libs-dev ; Mandy Chung > > >> ; Chris Bensen > > > >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > > >> > > >> Hello, > > >> > > >> I am sponsoring this changeset for Chris Bensen of the java packager > > >> team, please review fix for the launcher to better locate java.home. > > >> > > >> http://cr.openjdk.java.net/~ksrini/8165524/ > > >> > > >> Thanks > > >> Kumar > > > From igor.ignatyev at oracle.com Mon Sep 19 09:17:20 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 19 Sep 2016 12:17:20 +0300 Subject: RFR(S) : 8166262 : failurehandler should not use jtreg internal API Message-ID: <52CCFEE2-1F82-4A2C-909F-43EA26FD163B@oracle.com> http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ > 62 lines changed: 56 ins; 2 del; 4 mod; Hi all, could you please review this small patch which removes usage of jtreg internal API from failurehandler lib? JBS: https://bugs.openjdk.java.net/browse/JDK-8166262 webrev: http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ Thanks, ? Igor From staffan.larsen at oracle.com Mon Sep 19 09:25:50 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 19 Sep 2016 11:25:50 +0200 Subject: RFR(S) : 8166262 : failurehandler should not use jtreg internal API In-Reply-To: <52CCFEE2-1F82-4A2C-909F-43EA26FD163B@oracle.com> References: <52CCFEE2-1F82-4A2C-909F-43EA26FD163B@oracle.com> Message-ID: <00F2839C-A3DD-44AB-B7EA-C6C7D482FE69@oracle.com> Looks good! Thanks, /Staffan > On 19 sep. 2016, at 11:17, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ >> 62 lines changed: 56 ins; 2 del; 4 mod; > > Hi all, > > could you please review this small patch which removes usage of jtreg internal API from failurehandler lib? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8166262 > webrev: http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ > > Thanks, > ? Igor From dmitry.samersoff at oracle.com Mon Sep 19 10:40:27 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 19 Sep 2016 13:40:27 +0300 Subject: RFR(S) : 8166262 : failurehandler should not use jtreg internal API In-Reply-To: <52CCFEE2-1F82-4A2C-909F-43EA26FD163B@oracle.com> References: <52CCFEE2-1F82-4A2C-909F-43EA26FD163B@oracle.com> Message-ID: <6bae7fe5-9ba6-0428-d0e0-8589c756d449@oracle.com> Igor, Looks good for me. -Dmitry On 2016-09-19 12:17, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ >> 62 lines changed: 56 ins; 2 del; 4 mod; > > Hi all, > > could you please review this small patch which removes usage of jtreg internal API from failurehandler lib? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8166262 > webrev: http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ > > Thanks, > ? Igor > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From igor.ignatyev at oracle.com Mon Sep 19 10:42:56 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 19 Sep 2016 13:42:56 +0300 Subject: RFR(S) : 8166262 : failurehandler should not use jtreg internal API In-Reply-To: <6bae7fe5-9ba6-0428-d0e0-8589c756d449@oracle.com> References: <52CCFEE2-1F82-4A2C-909F-43EA26FD163B@oracle.com> <6bae7fe5-9ba6-0428-d0e0-8589c756d449@oracle.com> Message-ID: Dmitry, Thank you for review. ? Igor > On Sep 19, 2016, at 1:40 PM, Dmitry Samersoff wrote: > > Igor, > > Looks good for me. > > -Dmitry > > On 2016-09-19 12:17, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ >>> 62 lines changed: 56 ins; 2 del; 4 mod; >> >> Hi all, >> >> could you please review this small patch which removes usage of jtreg internal API from failurehandler lib? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8166262 >> webrev: http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ >> >> Thanks, >> ? Igor >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From igor.ignatyev at oracle.com Mon Sep 19 10:43:12 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 19 Sep 2016 13:43:12 +0300 Subject: RFR(S) : 8166262 : failurehandler should not use jtreg internal API In-Reply-To: <00F2839C-A3DD-44AB-B7EA-C6C7D482FE69@oracle.com> References: <52CCFEE2-1F82-4A2C-909F-43EA26FD163B@oracle.com> <00F2839C-A3DD-44AB-B7EA-C6C7D482FE69@oracle.com> Message-ID: Staffan, Thank you for review! ? Igor > On Sep 19, 2016, at 12:25 PM, Staffan Larsen wrote: > > Looks good! > > Thanks, > /Staffan > >> On 19 sep. 2016, at 11:17, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ >>> 62 lines changed: 56 ins; 2 del; 4 mod; >> >> Hi all, >> >> could you please review this small patch which removes usage of jtreg internal API from failurehandler lib? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8166262 >> webrev: http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/ >> >> Thanks, >> ? Igor > From huizhe.wang at oracle.com Mon Sep 19 19:11:41 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 19 Sep 2016 12:11:41 -0700 Subject: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage Message-ID: <57E0386D.8010901@oracle.com> Hi, Please review an addition of StAX tests to the Catalog Support test set. JBS: https://bugs.openjdk.java.net/browse/JDK-8166220 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/ Thanks, Joe From brent.christian at oracle.com Mon Sep 19 19:35:17 2016 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 19 Sep 2016 12:35:17 -0700 Subject: RFR 8165372 : StackWalker performance regression following JDK-8147039 Message-ID: <57E03DF5.1050003@oracle.com> Hi, Please review my fix for 8165372 : "StackWalker performance regression following JDK-8147039" Bug: https://bugs.openjdk.java.net/browse/JDK-8165372 Webrev: http://cr.openjdk.java.net/~bchristi/8165372/webrev.00/ 8147039 reimplemented stack walking using javaVFrames in place of vframeStream, in order to give correct results for the experimental LiveStackFrame feature. However, this also resulted in a significant StackWalker performance regression (25-60%, depending on specific operation and stack depth). This fix includes stack walking implemented both ways, encapsulated within C++ classes. JavaFrameStream provides the speed we had before for most use cases, while LiveFrameStream provides correct results when using LiveStackFrames. Performance is much improved, back within 5% or so of pre-8147039 levels, based on my measurements. Thanks, -Brent 1. http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/6174ad93770c From lance.andersen at oracle.com Mon Sep 19 20:13:22 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 19 Sep 2016 16:13:22 -0400 Subject: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage In-Reply-To: <57E0386D.8010901@oracle.com> References: <57E0386D.8010901@oracle.com> Message-ID: <5AA2DAFD-54D8-4EC2-B2F9-E3A675FF8655@oracle.com> Hi Joe, Seems OK. Best Lance > On Sep 19, 2016, at 3:11 PM, Joe Wang wrote: > > Hi, > > Please review an addition of StAX tests to the Catalog Support test set. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8166220 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/ > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Mon Sep 19 21:06:00 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Sep 2016 14:06:00 -0700 Subject: RFR 8165372 : StackWalker performance regression following JDK-8147039 In-Reply-To: <57E03DF5.1050003@oracle.com> References: <57E03DF5.1050003@oracle.com> Message-ID: > On Sep 19, 2016, at 12:35 PM, Brent Christian wrote: > > Hi, > > Please review my fix for 8165372 : "StackWalker performance regression following JDK-8147039" > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165372 > Webrev: http://cr.openjdk.java.net/~bchristi/8165372/webrev.00/ > This looks good and clean. I have the same comment what Coleen pointed out: + if (need_method_info(mode) == false && get_caller_class(mode) && and Handle stackFrame. Mandy From huizhe.wang at oracle.com Mon Sep 19 21:18:23 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 19 Sep 2016 14:18:23 -0700 Subject: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage In-Reply-To: <5AA2DAFD-54D8-4EC2-B2F9-E3A675FF8655@oracle.com> References: <57E0386D.8010901@oracle.com> <5AA2DAFD-54D8-4EC2-B2F9-E3A675FF8655@oracle.com> Message-ID: <57E0561F.6070609@oracle.com> Thanks Lance! Best Joe On 9/19/16, 1:13 PM, Lance Andersen wrote: > Hi Joe, > > Seems OK. > > Best > Lance >> On Sep 19, 2016, at 3:11 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review an addition of StAX tests to the Catalog Support test set. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8166220 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/ >> >> >> Thanks, >> Joe >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From brent.christian at oracle.com Mon Sep 19 22:57:05 2016 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 19 Sep 2016 15:57:05 -0700 Subject: RFR 8165372 : StackWalker performance regression following JDK-8147039 In-Reply-To: References: <57E03DF5.1050003@oracle.com> Message-ID: <57E06D41.8020507@oracle.com> Thanks for the good suggestions. Webrev updated in place: http://cr.openjdk.java.net/~bchristi/8165372/webrev.00/ -Brent From mandy.chung at oracle.com Tue Sep 20 00:19:50 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Sep 2016 17:19:50 -0700 Subject: RFR 8165372 : StackWalker performance regression following JDK-8147039 In-Reply-To: <57E06D41.8020507@oracle.com> References: <57E03DF5.1050003@oracle.com> <57E06D41.8020507@oracle.com> Message-ID: +1 Mandy > On Sep 19, 2016, at 3:57 PM, Brent Christian wrote: > > Thanks for the good suggestions. Webrev updated in place: > http://cr.openjdk.java.net/~bchristi/8165372/webrev.00/ > > -Brent > From christoph.langer at sap.com Tue Sep 20 06:53:37 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 20 Sep 2016 06:53:37 +0000 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <9bcadb4ee1a843528829b9eee07bad97@DEWDFE13DE50.global.corp.sap> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <117e635e0107427096606bd19906fe8b@DEWDFE13DE11.global.corp.sap> <9bcadb4ee1a843528829b9eee07bad97@DEWDFE13DE50.global.corp.sap> Message-ID: Hi all, hearing no objections and having the final ok from Goetz, I pushed the fix: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c709e74ffcf6 Best regards Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 19. September 2016 11:10 > To: Langer, Christoph ; Volker Simonis > > Cc: Kumar Srinivasan ; Mandy Chung > ; Chris Bensen ; core- > libs-dev ; ppc-aix-port-dev at openjdk.java.net; > Dmitry Samersoff > Subject: RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > Hi Christoph, > > This looks good now. Please adapt the copyright year in java_md.h. > I would appreciate this getting pushed to get our builds going again. > > Best regards, > Goetz. > > > > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Montag, 19. September 2016 10:45 > > To: Volker Simonis > > Cc: Kumar Srinivasan ; Mandy Chung > > ; Chris Bensen ; > > Lindenmaier, Goetz ; core-libs-dev > dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; Dmitry > > Samersoff > > Subject: RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > > > Hi all, > > > > thanks for your valuable input. > > > > So, since libjli.so can't use libjvm.so and its dladdr() port, there's no way > > around the libjli.so specific version of it. However, in libjli.so it is only used for > > resolving pathnames of the program, so the code can be very lean. Hence I > > completely reduced it to delivering the pathname of a module. And this code > > is not thread safe, as Volker mentioned. I would think/hope that a launcher > > would do its resolving work all in one thread and this should not be an issue. > > Maybe someone of the jli experts can confirm this or object against it. For > > now I would not spend more efforts in making this multi thread capable. > > > > As for the libawt version of dladdr(), this one should be removed and > > redirected to hotspot. I'll have a look at this when I find time. > > > > Please find a new webrev where I have addressed all findings and concerns > > - corrected spaces and indentation > > - removed the printf output in favor of handling the return code > > - only fill the info->dli_fname field > > - move conditional include to src/java.base/unix/native/libjli/java_md.h > > > > http://cr.openjdk.java.net/~clanger/webrevs/8166189.1/ > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > > Sent: Freitag, 16. September 2016 19:34 > > > To: Langer, Christoph > > > Cc: Kumar Srinivasan ; Mandy Chung > > > ; Chris Bensen ; > > > Thomas St?fe ; Lindenmaier, Goetz > > > ; core-libs-dev > > dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net > > > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > > > > > > Hi Christoph, > > > > > > I think your change is fine as a quick-fix to fix the build. But > > > you're completely right that this should be reworked in the long term. > > > I hate to see that we now have the third version of these routines in > > > the OpenJDK. Unfortunately a clean solution is not trivial. > > > > > > libjli is not linked against libjvm because libjli is actually used to > > > load libjvm. So we can not put the dladdr routines for AIX there. But > > > I think we should at least consolidate the two versions which will be > > > in the class library after your change. Initially I intentionally put > > > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > > > available to ALL jdk native libraries. > > > > > > Unfortunately, with the source code reorganization due to the modular > > > changes, the common, top-level aix repository had to go away and the > > > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > > > With the reorganized, modularized source code layout and build system > > > it is not possible to share code between modules. We somehow have to > > > fix this although I currently don't know how. IF somebody has an idea, > > > please let me know :) > > > > > > Regarding your change: > > > > > > - can you please move > > > > > > +#if defined(_AIX) > > > +#include "java_md_aix.h" > > > +#endif > > > + > > > > > > from java_md_common.c to the end of > > > java.base/unix/native/libjli/java_md.h. It will then be automatically > > > included into java_md_common.c trough java.h which includes java_md.h > > > > > > Also, this version of dladdr is inherently not thread safe. I don't > > > think that's a problem here, but it would be nice if you could quickly > > > check if that's indeed true. > > > > > > Besides that, looks good. > > > > > > Thanks for fixing, > > > Volker > > > > > > > > > > > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > > > wrote: > > > > Hi, > > > > > > > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks > > the AIX > > > build as function dladdr is not available on AIX. > > > > > > > > There already exist ports of that API in hotspot and awt. With the > > proposed > > > change I duplicate the awt port to libjli. This is maybe only a quick fix - > > > eventually we should think about consolidating and using the hotspot port > > in all > > > places by exporting it from libjvm.so for AIX. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > > > > > > > Thanks > > > > Christoph > > > > > > > > > > > >> -----Original Message----- > > > >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] > > On > > > Behalf > > > >> Of Kumar Srinivasan > > > >> Sent: Montag, 12. September 2016 22:57 > > > >> To: core-libs-dev ; Mandy Chung > > > >> ; Chris Bensen > > > > > >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using > > > >> > > > >> Hello, > > > >> > > > >> I am sponsoring this changeset for Chris Bensen of the java packager > > > >> team, please review fix for the launcher to better locate java.home. > > > >> > > > >> http://cr.openjdk.java.net/~ksrini/8165524/ > > > >> > > > >> Thanks > > > >> Kumar > > > > From daniel.fuchs at oracle.com Tue Sep 20 09:20:01 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 20 Sep 2016 10:20:01 +0100 Subject: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage In-Reply-To: <57E0386D.8010901@oracle.com> References: <57E0386D.8010901@oracle.com> Message-ID: <24906308-98a9-5cd1-544a-b23ead912b1a@oracle.com> Hi Joe, test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java 603 /** 604 * Returns the text of the first element found by the reader. 605 * @param streamReader the XMLStreamReader 606 * @return the text of the first element 607 * @throws XMLStreamException 608 */ 609 String getText(XMLStreamReader streamReader, int type) throws XMLStreamException { It would be good to update the javadoc of this method (in particular document the new 'type' parameter) so that future maintainer can understand what that method is supposed to do. In particular would it be OK to encounter both CHARACTERS and ENTITY_REFERENCE, or are these exclusive. If they are should some exception be thrown? I can't say I understand how the new test works, but nothing else jumped at me in your webrev :-) best regards, -- daniel On 19/09/16 20:11, Joe Wang wrote: > Hi, > > Please review an addition of StAX tests to the Catalog Support test set. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8166220 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/ > > Thanks, > Joe > From manju.jccs at gmail.com Tue Sep 20 10:53:39 2016 From: manju.jccs at gmail.com (Manjunath SV) Date: Tue, 20 Sep 2016 16:23:39 +0530 Subject: Reg - Sub Process creation from java takes more time Message-ID: Hi, Virtual size is always constant - 12.6gb, no longer pauses in GC logs. VM will not fail if we run for loner time. We submit 400+ jobs(3-4 times per day) to thread pool of size 30, each thread has to execute more than 13+ jobs, initially threads starts sub process in milli seconds, some times after executing 6 or 7 jobs threads take more time to create a sub process, some times threads always take (For 13+ jobs) milli secs to create a sub process. Thanks & Regards, Manjunath From: Date: 16 Sep 2016 12:03 p.m. Subject: Re: Reg - Sub Process creation from java takes more time To: "Manjunath SV" , "core-libs-dev at openjdk.java.net" Cc: Hello, Does the (virtual) size increase over time when it gets slower? How does the GC log looks like, any increasing activity or longer pauses? If you let this VM run for longer time (when it slows down), will it eventually fail because of some resource exhaustion? How often does the execute work fast, after what numberbof executions and what runtime it gets slower? You can also strace the process to see if the execution time of fork() and exec() syscalls increase. Gruss Bernd -- Von: Manjunath SV Gesendet: Freitag, 16. September 2016 08:19 An: core-libs-dev at openjdk.java.net Betreff: Reg - Sub Process creation from java takes more time Hi, I monitored memory usage, below are the details. Heap usage :- 857mb Virtual memory:- 12.6gb -Xmx set to 4gb. I have taken virtual and heap memory usage when Java spawns sub processes. Sub processes have short life, will be done in milli seconds. Thanks & Regards, Manjunath Date: Thu, 15 Sep 2016 11:01:01 +0200 From: To: "core-libs-dev at openjdk.java.net" Subject: Re: Reg - Sub Process creation from java takes more time Message-ID: <57da634c.c336c20a.19b0c.bec8 at mx.google.com> Content-Type: text/plain; charset="utf-8" Hello, Do you monitor heap usage and virtual memory size of your Java process? I would look out for increase (which causes slower for tines). Also it is generally a good idea to turn on GC logging and look into it if a java process degregades over time Gruss Bernd Just BTW: I think Java would not be the right tool to spawn and control sich a high number of external processes. Maybe it would be better to hand that off to a more native component. -- http://bernd.eckenfels.net Von: Manjunath SV Hi All, I am Manjunath, We are facing below issue in Java application. Issue Details :- Java application has a thread pool of size 30, When it receives Job message from JMS, It creates around 200+ jobs and submit into thread pool,initially 30 threads creates shell script process very quick, later process creation time gradually increases (5-9 mins). Java application invokes shell script, Below is the code. process = Runtime.getRuntime().exec(new String[] { script_name, param1, param2, param3,param4 }); int response = process.waitFor(); Shell script :- #!/bin/ksh linux-command -un $1 -pw $2 -f batch.txt < $3 > $4 2>&1 We redirected command output and errors to a file. First job execution after application restart takes just 15 sec, later job execution takes around 15 mins, some times 40 mins also. We are using java 1.8.0_92. Please advise on this. Thanks in advance. Regards, Manjunath From peter.levart at gmail.com Tue Sep 20 12:20:32 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 20 Sep 2016 14:20:32 +0200 Subject: Reg - Sub Process creation from java takes more time In-Reply-To: References: Message-ID: Hi Manjunath, There could be a bug somewhere in the process API. Could you try using ProcessBuilder API to execute linux-command directly and use the API to setup stdin/out/err redirects instead of using a shell script. Just to see if you get the same slowdown in that case. Regards, Peter On Sep 20, 2016 03:54, "Manjunath SV" wrote: > Hi, > > Virtual size is always constant - 12.6gb, no longer pauses in GC logs. > > VM will not fail if we run for loner time. > > > We submit 400+ jobs(3-4 times per day) to thread pool of size 30, each > thread has to execute more than 13+ jobs, initially threads starts sub > process in milli seconds, some times after executing 6 or 7 jobs threads > take more time to create a sub process, some times threads always take > (For 13+ jobs) milli secs to create a sub process. > > Thanks & Regards, > Manjunath > > From: > Date: 16 Sep 2016 12:03 p.m. > Subject: Re: Reg - Sub Process creation from java takes more time > To: "Manjunath SV" , "core-libs-dev at openjdk.java.net > " > > Cc: > > Hello, > > Does the (virtual) size increase over time when it gets slower? How does > the GC log looks like, any increasing activity or longer pauses? > > If you let this VM run for longer time (when it slows down), will it > eventually fail because of some resource exhaustion? > > How often does the execute work fast, after what numberbof executions and > what runtime it gets slower? > > You can also strace the process to see if the execution time of fork() and > exec() syscalls increase. > > Gruss > Bernd > -- > Von: Manjunath SV > Gesendet: Freitag, 16. September 2016 08:19 > An: core-libs-dev at openjdk.java.net > Betreff: Reg - Sub Process creation from java takes more time > > Hi, > > I monitored memory usage, below are the details. > > Heap usage :- 857mb > Virtual memory:- 12.6gb > -Xmx set to 4gb. > > I have taken virtual and heap memory usage when Java spawns sub processes. > > Sub processes have short life, will be done in milli seconds. > > > Thanks & Regards, > Manjunath > > > Date: Thu, 15 Sep 2016 11:01:01 +0200 > From: > To: "core-libs-dev at openjdk.java.net" > Subject: Re: Reg - Sub Process creation from java takes more time > Message-ID: <57da634c.c336c20a.19b0c.bec8 at mx.google.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > Do you monitor heap usage and virtual memory size of your Java process? I > would look out for increase (which causes slower for tines). > > Also it is generally a good idea to turn on GC logging and look into it if > a java process degregades over time > > Gruss > Bernd > > Just BTW: I think Java would not be the right tool to spawn and control > sich a high number of external processes. Maybe it would be better to hand > that off to a more native component. > -- > http://bernd.eckenfels.net > > Von: Manjunath SV > > Hi All, > > I am Manjunath, We are facing below issue in Java application. > > Issue Details :- > > Java application has a thread pool of size 30, When it receives Job message > from JMS, It creates around 200+ jobs and submit into thread > pool,initially 30 threads creates shell script process very quick, later > process creation time gradually increases (5-9 mins). > > > Java application invokes shell script, Below is the code. > > process = Runtime.getRuntime().exec(new String[] { script_name, > param1, param2, param3,param4 }); > > int response = process.waitFor(); > > Shell script :- > > #!/bin/ksh > linux-command -un $1 -pw $2 -f batch.txt < $3 > $4 2>&1 > > We redirected command output and errors to a file. > > First job execution after application restart takes just 15 sec, later job > execution takes around 15 mins, some times 40 mins also. > > We are using java 1.8.0_92. > > Please advise on this. > > Thanks in advance. > > Regards, > Manjunath > From michael.haupt at oracle.com Tue Sep 20 12:53:48 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 20 Sep 2016 14:53:48 +0200 Subject: RFR(L): 8161211: better inlining support for loop bytecode intrinsics Message-ID: <68C2D28E-C2DB-4156-86E3-715069D6AB42@oracle.com> Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8161211 Webrev: http://cr.openjdk.java.net/~mhaupt/8161211/webrev.00/ The method handle loop combinators introduced with JEP 274 were originally not intrinsified, leading to poor performance as compared to a pure-Java baseline, but also to handwired method handle combinations. The intrinsics introduced with 8143211 [1] improved on the situation somewhat, but still did not provide good inlining opportunities for the JIT compiler. This change introduces a usage of BoundMethodHandles as arrays to carry the various handles involved in loop execution. Extra credits to Vladimir Ivanov, who suggested the BMH-as-arrays approach in the first place, and Claes Redestad, who suggested to use LambdaForm editing to neatly enable caching. Thanks! Performance improves considerably. The table below reports scores in ns/op. The "unpatched" column contains results from before applying the patch for 8161211; the "patched" column, from thereafter. The create benchmarks measure the cost of loop handle creation. The baseline and baselineMH benchmarks measure the cost of running a pure Java and handwired method handle construct. Relevant comparisons include loop combinator results versus baselines, and versus unpatched loop combinator results. For the latter, there are significant improvements, except for the creation benchmarks (creation has a more complex workflow now). For the former, it can be seen that the BMH-array intrinsics generally perform better than handwired handle constructs, and have moved much closer to. Thanks, Michael [1] https://bugs.openjdk.java.net/browse/JDK-8143211 Benchmark (iterations) unpatched patched MethodHandlesCountedLoop.Create.create3 N/A 16039.108 18400.405 MethodHandlesCountedLoop.Create.create4 N/A 15621.959 17924.696 MethodHandlesCountedLoop.Invoke.baseline3 0 2.858 2.839 MethodHandlesCountedLoop.Invoke.baseline3 1 5.125 5.164 MethodHandlesCountedLoop.Invoke.baseline3 10 11.887 11.924 MethodHandlesCountedLoop.Invoke.baseline3 100 67.441 67.281 MethodHandlesCountedLoop.Invoke.baseline4 0 2.855 2.838 MethodHandlesCountedLoop.Invoke.baseline4 1 5.120 5.179 MethodHandlesCountedLoop.Invoke.baseline4 10 11.875 11.906 MethodHandlesCountedLoop.Invoke.baseline4 100 67.607 67.374 MethodHandlesCountedLoop.Invoke.baselineMH3 0 9.734 9.606 MethodHandlesCountedLoop.Invoke.baselineMH3 1 15.689 15.674 MethodHandlesCountedLoop.Invoke.baselineMH3 10 68.912 69.303 MethodHandlesCountedLoop.Invoke.baselineMH3 100 605.666 606.432 MethodHandlesCountedLoop.Invoke.baselineMH4 0 14.561 13.234 MethodHandlesCountedLoop.Invoke.baselineMH4 1 19.543 19.773 MethodHandlesCountedLoop.Invoke.baselineMH4 10 71.977 72.466 MethodHandlesCountedLoop.Invoke.baselineMH4 100 596.842 602.469 MethodHandlesCountedLoop.Invoke.countedLoop3 0 49.339 5.810 MethodHandlesCountedLoop.Invoke.countedLoop3 1 95.444 7.441 MethodHandlesCountedLoop.Invoke.countedLoop3 10 508.746 21.002 MethodHandlesCountedLoop.Invoke.countedLoop3 100 4701.808 145.996 MethodHandlesCountedLoop.Invoke.countedLoop4 0 49.443 5.798 MethodHandlesCountedLoop.Invoke.countedLoop4 1 98.721 7.438 MethodHandlesCountedLoop.Invoke.countedLoop4 10 503.825 21.049 MethodHandlesCountedLoop.Invoke.countedLoop4 100 4681.803 147.020 MethodHandlesDoWhileLoop.Create.create N/A 7628.312 9100.332 MethodHandlesDoWhileLoop.Invoke.baseline 1 3.868 3.909 MethodHandlesDoWhileLoop.Invoke.baseline 10 16.480 16.461 MethodHandlesDoWhileLoop.Invoke.baseline 100 144.260 144.232 MethodHandlesDoWhileLoop.Invoke.baselineMH 1 14.434 14.494 MethodHandlesDoWhileLoop.Invoke.baselineMH 10 92.542 93.454 MethodHandlesDoWhileLoop.Invoke.baselineMH 100 877.480 880.496 MethodHandlesDoWhileLoop.Invoke.doWhileLoop 1 26.791 7.153 MethodHandlesDoWhileLoop.Invoke.doWhileLoop 10 158.985 16.990 MethodHandlesDoWhileLoop.Invoke.doWhileLoop 100 1391.746 130.946 MethodHandlesIteratedLoop.Create.create N/A 13547.499 15478.542 MethodHandlesIteratedLoop.Invoke.baseline 0 2.973 2.980 MethodHandlesIteratedLoop.Invoke.baseline 1 6.771 6.658 MethodHandlesIteratedLoop.Invoke.baseline 10 14.955 14.955 MethodHandlesIteratedLoop.Invoke.baseline 100 81.842 82.582 MethodHandlesIteratedLoop.Invoke.baselineMH 0 14.893 14.668 MethodHandlesIteratedLoop.Invoke.baselineMH 1 20.998 21.304 MethodHandlesIteratedLoop.Invoke.baselineMH 10 73.677 72.703 MethodHandlesIteratedLoop.Invoke.baselineMH 100 613.913 614.475 MethodHandlesIteratedLoop.Invoke.iteratedLoop 0 33.583 9.603 MethodHandlesIteratedLoop.Invoke.iteratedLoop 1 82.239 14.433 MethodHandlesIteratedLoop.Invoke.iteratedLoop 10 448.356 38.650 MethodHandlesIteratedLoop.Invoke.iteratedLoop 100 4189.034 279.779 MethodHandlesLoop.Create.create N/A 15505.970 17559.399 MethodHandlesLoop.Invoke0.baseline 1 3.179 3.181 MethodHandlesLoop.Invoke0.baseline 10 5.952 6.115 MethodHandlesLoop.Invoke0.baseline 100 50.942 50.943 MethodHandlesLoop.Invoke0.loop 1 46.454 5.353 MethodHandlesLoop.Invoke0.loop 10 514.230 8.487 MethodHandlesLoop.Invoke0.loop 100 5166.251 52.188 MethodHandlesLoop.Invoke1.loop 1 34.321 5.277 MethodHandlesLoop.Invoke1.loop 10 430.839 8.481 MethodHandlesLoop.Invoke1.loop 100 4095.302 52.206 MethodHandlesTryFinally.baselineExceptional N/A 3.005 3.002 MethodHandlesTryFinally.baselineMHExceptional N/A 166.316 166.087 MethodHandlesTryFinally.baselineMHNormal N/A 9.337 9.276 MethodHandlesTryFinally.baselineNormal N/A 2.696 2.683 MethodHandlesTryFinally.create N/A 406.255 406.594 MethodHandlesTryFinally.invokeTryFinallyExceptional N/A 154.121 154.692 MethodHandlesTryFinally.invokeTryFinallyNormal N/A 5.350 5.334 MethodHandlesWhileLoop.Create.create N/A 12214.383 14503.515 MethodHandlesWhileLoop.Invoke.baseline 0 3.886 3.888 MethodHandlesWhileLoop.Invoke.baseline 1 5.379 5.377 MethodHandlesWhileLoop.Invoke.baseline 10 16.000 16.201 MethodHandlesWhileLoop.Invoke.baseline 100 142.066 143.338 MethodHandlesWhileLoop.Invoke.baselineMH 0 11.028 11.012 MethodHandlesWhileLoop.Invoke.baselineMH 1 21.269 21.159 MethodHandlesWhileLoop.Invoke.baselineMH 10 97.493 97.656 MethodHandlesWhileLoop.Invoke.baselineMH 100 887.579 886.532 MethodHandlesWhileLoop.Invoke.whileLoop 0 24.829 7.108 MethodHandlesWhileLoop.Invoke.whileLoop 1 46.039 8.573 MethodHandlesWhileLoop.Invoke.whileLoop 10 240.963 21.088 MethodHandlesWhileLoop.Invoke.whileLoop 100 2092.671 159.016 -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Tue Sep 20 13:19:54 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 20 Sep 2016 15:19:54 +0200 Subject: MethodHandle loop body parameters and Stream.reduce accumulator parameters are not in the same order In-Reply-To: <929153152.1409018.1473859181630.JavaMail.zimbra@u-pem.fr> References: <929153152.1409018.1473859181630.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, I think you can stay tuned for the fix to JDK-8151179; part of what it addresses is just this. The changes are currently in the CCC loop but should come up for public re-review soon. Best, Michael > Am 14.09.2016 um 15:19 schrieb Remi Forax : > > Hi everybody, > i've just found that the parameters of the body (a MethodHandle) of MethodHandles.countedLoop (both overloads) and iteratedLoop are not in the same order as the accumulator in methods Stream.reduce, given that they conceptually represent the same thing, i think the first two parameters of body should be swapped in countedLoop and iteratedLoop. > > in Stream: > U reduce(U identity, > BiFunction accumulator, > BinaryOperator combiner) > so this is equivalent to value = accumulator(value, element) > > In MethodHandles: > MethodHandle iteratedLoop(MethodHandle iterator, > MethodHandle init, > MethodHandle body) > with value = body(element, value, iterable) > it should be > value = body(value, element, iterable). > > Same things for > MethodHandle countedLoop(MethodHandle start, > MethodHandle end, > MethodHandle init, > MethodHandle body) > it should be > value = body(value, index, array); > instead of > value = body(index, value, array); > > the other loop combinators do not be to be changed. > > cheers, > R?mi > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From bodewig at apache.org Tue Sep 20 13:46:50 2016 From: bodewig at apache.org (Stefan Bodewig) Date: Tue, 20 Sep 2016 15:46:50 +0200 Subject: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions In-Reply-To: <57D1C95D.7000409@oracle.com> (Joe Wang's message of "Thu, 08 Sep 2016 13:26:05 -0700") References: <87eg58n7vx.fsf@v45346.1blu.de> <57C4825D.5070307@oracle.com> <87oa4ai5c5.fsf@v45346.1blu.de> <57C66074.5080608@oracle.com> <87poond6tz.fsf@v45346.1blu.de> <57D1C95D.7000409@oracle.com> Message-ID: <87wpi6heet.fsf@v45346.1blu.de> Hi Joe On 2016-09-08, Joe Wang wrote: > It's great to know you've found the solution! Hopefully this is indeed > the last issue for you with JDK 9 :-) > I've checked in a fix for the redirect failure [1] into the dev > repo. It would probably be included in the next week's build > (b136). Please let me know if this doesn't work. > [1] https://bugs.openjdk.java.net/browse/JDK-8165116 I can confirm it works, all of Ant's tests pass with b136 :-) Many thanks Stefan From amy.lu at oracle.com Tue Sep 20 14:24:29 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 20 Sep 2016 22:24:29 +0800 Subject: JDK 9 RFR of JDK-8166248: tools/pack200/Pack200Test.java fails on Win32: Could not reserve enough space Message-ID: tools/pack200/Pack200Test.java This test requires -Xmx1280m to run. Test is not suitable for 32-bit platform. Please review this patch to skip on 32-bit platform. bug: https://bugs.openjdk.java.net/browse/JDK-8166248 webrev: http://cr.openjdk.java.net/~amlu/8166248/webrev.00/ Thanks, Amy --- old/test/tools/pack200/Pack200Test.java 2016-09-20 22:14:31.000000000 +0800 +++ new/test/tools/pack200/Pack200Test.java 2016-09-20 22:14:31.000000000 +0800 @@ -24,6 +24,7 @@ /* * @test * @bug 6521334 6712743 8007902 8151901 + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 4g) * @summary test general packer/unpacker functionality * using native and java unpackers * @compile -XDignore.symbol.file Utils.java Pack200Test.java From kumar.x.srinivasan at oracle.com Tue Sep 20 14:53:43 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 20 Sep 2016 07:53:43 -0700 Subject: JDK 9 RFR of JDK-8166248: tools/pack200/Pack200Test.java fails on Win32: Could not reserve enough space In-Reply-To: References: Message-ID: <57E14D77.9010609@oracle.com> Looks good. Thanks for making the change. Kumar > tools/pack200/Pack200Test.java > > This test requires -Xmx1280m to run. Test is not suitable for 32-bit > platform. > > Please review this patch to skip on 32-bit platform. > > bug: https://bugs.openjdk.java.net/browse/JDK-8166248 > webrev: http://cr.openjdk.java.net/~amlu/8166248/webrev.00/ > > Thanks, > Amy > > --- old/test/tools/pack200/Pack200Test.java 2016-09-20 22:14:31.000000000 +0800 > +++ new/test/tools/pack200/Pack200Test.java 2016-09-20 22:14:31.000000000 +0800 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 6521334 6712743 8007902 8151901 > + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 4g) > * @summary test general packer/unpacker functionality > * using native and java unpackers > * @compile -XDignore.symbol.file Utils.java Pack200Test.java > > From vladimir.x.ivanov at oracle.com Tue Sep 20 15:17:47 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 20 Sep 2016 18:17:47 +0300 Subject: RFR(L): 8161211: better inlining support for loop bytecode intrinsics In-Reply-To: <68C2D28E-C2DB-4156-86E3-715069D6AB42@oracle.com> References: <68C2D28E-C2DB-4156-86E3-715069D6AB42@oracle.com> Message-ID: <810545e8-1798-1f35-e03f-fdcb55cec46f@oracle.com> Looks good. src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java: + LambdaForm bmhArrayForm(MethodType type, BoundMethodHandle.SpeciesData speciesData) { + int size = type.parameterCount(); + Transform key = Transform.of(Transform.BMH_AS_ARRAY, size); + LambdaForm form = getInCache(key); + if (form != null) { + return form; + } Please, add an assert to ensure the cached LF has the same constraint as requested (speciesData). Best regards, Vladimir Ivanov On 9/20/16 3:53 PM, Michael Haupt wrote: > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8161211 > Webrev: http://cr.openjdk.java.net/~mhaupt/8161211/webrev.00/ > > The method handle loop combinators introduced with JEP 274 were originally not intrinsified, leading to poor performance as compared to a pure-Java baseline, but also to handwired method handle combinations. The intrinsics introduced with 8143211 [1] improved on the situation somewhat, but still did not provide good inlining opportunities for the JIT compiler. This change introduces a usage of BoundMethodHandles as arrays to carry the various handles involved in loop execution. > > Extra credits to Vladimir Ivanov, who suggested the BMH-as-arrays approach in the first place, and Claes Redestad, who suggested to use LambdaForm editing to neatly enable caching. Thanks! > > Performance improves considerably. The table below reports scores in ns/op. The "unpatched" column contains results from before applying the patch for 8161211; the "patched" column, from thereafter. > > The create benchmarks measure the cost of loop handle creation. The baseline and baselineMH benchmarks measure the cost of running a pure Java and handwired method handle construct. > > Relevant comparisons include loop combinator results versus baselines, and versus unpatched loop combinator results. For the latter, there are significant improvements, except for the creation benchmarks (creation has a more complex workflow now). For the former, it can be seen that the BMH-array intrinsics generally perform better than handwired handle constructs, and have moved much closer to. > > Thanks, > > Michael > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8143211 > > > > Benchmark (iterations) unpatched patched > MethodHandlesCountedLoop.Create.create3 N/A 16039.108 18400.405 > MethodHandlesCountedLoop.Create.create4 N/A 15621.959 17924.696 > MethodHandlesCountedLoop.Invoke.baseline3 0 2.858 2.839 > MethodHandlesCountedLoop.Invoke.baseline3 1 5.125 5.164 > MethodHandlesCountedLoop.Invoke.baseline3 10 11.887 11.924 > MethodHandlesCountedLoop.Invoke.baseline3 100 67.441 67.281 > MethodHandlesCountedLoop.Invoke.baseline4 0 2.855 2.838 > MethodHandlesCountedLoop.Invoke.baseline4 1 5.120 5.179 > MethodHandlesCountedLoop.Invoke.baseline4 10 11.875 11.906 > MethodHandlesCountedLoop.Invoke.baseline4 100 67.607 67.374 > MethodHandlesCountedLoop.Invoke.baselineMH3 0 9.734 9.606 > MethodHandlesCountedLoop.Invoke.baselineMH3 1 15.689 15.674 > MethodHandlesCountedLoop.Invoke.baselineMH3 10 68.912 69.303 > MethodHandlesCountedLoop.Invoke.baselineMH3 100 605.666 606.432 > MethodHandlesCountedLoop.Invoke.baselineMH4 0 14.561 13.234 > MethodHandlesCountedLoop.Invoke.baselineMH4 1 19.543 19.773 > MethodHandlesCountedLoop.Invoke.baselineMH4 10 71.977 72.466 > MethodHandlesCountedLoop.Invoke.baselineMH4 100 596.842 602.469 > MethodHandlesCountedLoop.Invoke.countedLoop3 0 49.339 5.810 > MethodHandlesCountedLoop.Invoke.countedLoop3 1 95.444 7.441 > MethodHandlesCountedLoop.Invoke.countedLoop3 10 508.746 21.002 > MethodHandlesCountedLoop.Invoke.countedLoop3 100 4701.808 145.996 > MethodHandlesCountedLoop.Invoke.countedLoop4 0 49.443 5.798 > MethodHandlesCountedLoop.Invoke.countedLoop4 1 98.721 7.438 > MethodHandlesCountedLoop.Invoke.countedLoop4 10 503.825 21.049 > MethodHandlesCountedLoop.Invoke.countedLoop4 100 4681.803 147.020 > MethodHandlesDoWhileLoop.Create.create N/A 7628.312 9100.332 > MethodHandlesDoWhileLoop.Invoke.baseline 1 3.868 3.909 > MethodHandlesDoWhileLoop.Invoke.baseline 10 16.480 16.461 > MethodHandlesDoWhileLoop.Invoke.baseline 100 144.260 144.232 > MethodHandlesDoWhileLoop.Invoke.baselineMH 1 14.434 14.494 > MethodHandlesDoWhileLoop.Invoke.baselineMH 10 92.542 93.454 > MethodHandlesDoWhileLoop.Invoke.baselineMH 100 877.480 880.496 > MethodHandlesDoWhileLoop.Invoke.doWhileLoop 1 26.791 7.153 > MethodHandlesDoWhileLoop.Invoke.doWhileLoop 10 158.985 16.990 > MethodHandlesDoWhileLoop.Invoke.doWhileLoop 100 1391.746 130.946 > MethodHandlesIteratedLoop.Create.create N/A 13547.499 15478.542 > MethodHandlesIteratedLoop.Invoke.baseline 0 2.973 2.980 > MethodHandlesIteratedLoop.Invoke.baseline 1 6.771 6.658 > MethodHandlesIteratedLoop.Invoke.baseline 10 14.955 14.955 > MethodHandlesIteratedLoop.Invoke.baseline 100 81.842 82.582 > MethodHandlesIteratedLoop.Invoke.baselineMH 0 14.893 14.668 > MethodHandlesIteratedLoop.Invoke.baselineMH 1 20.998 21.304 > MethodHandlesIteratedLoop.Invoke.baselineMH 10 73.677 72.703 > MethodHandlesIteratedLoop.Invoke.baselineMH 100 613.913 614.475 > MethodHandlesIteratedLoop.Invoke.iteratedLoop 0 33.583 9.603 > MethodHandlesIteratedLoop.Invoke.iteratedLoop 1 82.239 14.433 > MethodHandlesIteratedLoop.Invoke.iteratedLoop 10 448.356 38.650 > MethodHandlesIteratedLoop.Invoke.iteratedLoop 100 4189.034 279.779 > MethodHandlesLoop.Create.create N/A 15505.970 17559.399 > MethodHandlesLoop.Invoke0.baseline 1 3.179 3.181 > MethodHandlesLoop.Invoke0.baseline 10 5.952 6.115 > MethodHandlesLoop.Invoke0.baseline 100 50.942 50.943 > MethodHandlesLoop.Invoke0.loop 1 46.454 5.353 > MethodHandlesLoop.Invoke0.loop 10 514.230 8.487 > MethodHandlesLoop.Invoke0.loop 100 5166.251 52.188 > MethodHandlesLoop.Invoke1.loop 1 34.321 5.277 > MethodHandlesLoop.Invoke1.loop 10 430.839 8.481 > MethodHandlesLoop.Invoke1.loop 100 4095.302 52.206 > MethodHandlesTryFinally.baselineExceptional N/A 3.005 3.002 > MethodHandlesTryFinally.baselineMHExceptional N/A 166.316 166.087 > MethodHandlesTryFinally.baselineMHNormal N/A 9.337 9.276 > MethodHandlesTryFinally.baselineNormal N/A 2.696 2.683 > MethodHandlesTryFinally.create N/A 406.255 406.594 > MethodHandlesTryFinally.invokeTryFinallyExceptional N/A 154.121 154.692 > MethodHandlesTryFinally.invokeTryFinallyNormal N/A 5.350 5.334 > MethodHandlesWhileLoop.Create.create N/A 12214.383 14503.515 > MethodHandlesWhileLoop.Invoke.baseline 0 3.886 3.888 > MethodHandlesWhileLoop.Invoke.baseline 1 5.379 5.377 > MethodHandlesWhileLoop.Invoke.baseline 10 16.000 16.201 > MethodHandlesWhileLoop.Invoke.baseline 100 142.066 143.338 > MethodHandlesWhileLoop.Invoke.baselineMH 0 11.028 11.012 > MethodHandlesWhileLoop.Invoke.baselineMH 1 21.269 21.159 > MethodHandlesWhileLoop.Invoke.baselineMH 10 97.493 97.656 > MethodHandlesWhileLoop.Invoke.baselineMH 100 887.579 886.532 > MethodHandlesWhileLoop.Invoke.whileLoop 0 24.829 7.108 > MethodHandlesWhileLoop.Invoke.whileLoop 1 46.039 8.573 > MethodHandlesWhileLoop.Invoke.whileLoop 10 240.963 21.088 > MethodHandlesWhileLoop.Invoke.whileLoop 100 2092.671 159.016 > > > From huizhe.wang at oracle.com Tue Sep 20 18:22:58 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 20 Sep 2016 11:22:58 -0700 Subject: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage In-Reply-To: <24906308-98a9-5cd1-544a-b23ead912b1a@oracle.com> References: <57E0386D.8010901@oracle.com> <24906308-98a9-5cd1-544a-b23ead912b1a@oracle.com> Message-ID: <57E17E82.8020305@oracle.com> On 9/20/16, 2:20 AM, Daniel Fuchs wrote: > Hi Joe, > > test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java > > 603 /** > 604 * Returns the text of the first element found by the reader. > 605 * @param streamReader the XMLStreamReader > 606 * @return the text of the first element > 607 * @throws XMLStreamException > 608 */ > 609 String getText(XMLStreamReader streamReader, int type) throws > XMLStreamException { > > It would be good to update the javadoc of this method (in particular > document the new 'type' parameter) so that future maintainer > can understand what that method is supposed to do. Thanks Daniel! I'll fix this. As I went through the tests again, I found there's actually an error in the StAX test where the handler was missed. I filed a new bug: https://bugs.openjdk.java.net/browse/JDK-8166398 > > In particular would it be OK to encounter both CHARACTERS and > ENTITY_REFERENCE, or are these exclusive. If they are should some > exception be thrown? They can't. At any given point, the StAX parser returns an unique event and its event type. > > I can't say I understand how the new test works, but nothing > else jumped at me in your webrev :-) The incorrect javadoc was enough to raise an alarm, that this part of code was copied and forgot to update. It led me to double-check the code and found the issue (JDK-8166398). I really appreciate it! Best, Joe > > best regards, > > -- daniel > > > On 19/09/16 20:11, Joe Wang wrote: >> Hi, >> >> Please review an addition of StAX tests to the Catalog Support test set. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8166220 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/ >> >> Thanks, >> Joe >> > From huizhe.wang at oracle.com Tue Sep 20 18:26:58 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 20 Sep 2016 11:26:58 -0700 Subject: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions In-Reply-To: <87wpi6heet.fsf@v45346.1blu.de> References: <87eg58n7vx.fsf@v45346.1blu.de> <57C4825D.5070307@oracle.com> <87oa4ai5c5.fsf@v45346.1blu.de> <57C66074.5080608@oracle.com> <87poond6tz.fsf@v45346.1blu.de> <57D1C95D.7000409@oracle.com> <87wpi6heet.fsf@v45346.1blu.de> Message-ID: <57E17F72.7090409@oracle.com> Thanks Stefan for the update! I'm very glad to know you've gotten all of Ant's tests passed! Best regards, Joe On 9/20/16, 6:46 AM, Stefan Bodewig wrote: > Hi Joe > > On 2016-09-08, Joe Wang wrote: > >> It's great to know you've found the solution! Hopefully this is indeed >> the last issue for you with JDK 9 :-) >> I've checked in a fix for the redirect failure [1] into the dev >> repo. It would probably be included in the next week's build >> (b136). Please let me know if this doesn't work. >> [1] https://bugs.openjdk.java.net/browse/JDK-8165116 > I can confirm it works, all of Ant's tests pass with b136 :-) > > Many thanks > > Stefan From john.r.rose at oracle.com Tue Sep 20 19:54:43 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Sep 2016 12:54:43 -0700 Subject: RFR(L): 8161211: better inlining support for loop bytecode intrinsics In-Reply-To: <810545e8-1798-1f35-e03f-fdcb55cec46f@oracle.com> References: <68C2D28E-C2DB-4156-86E3-715069D6AB42@oracle.com> <810545e8-1798-1f35-e03f-fdcb55cec46f@oracle.com> Message-ID: There should also be an assert in the new LF constructor, which ensures that the two arguments are congruent. Better yet, just supply one argument (the speciesData), and derive the MT. These new LFs are pretty confusing, and it's best to nail down unused degrees of freedom. ? John P.S. I would have expected this problem to be solved by having the MHI.toArray function return a box object with a single @Stable array field. Did that approach fail? I.e., this wrapper emulates a frozen array (until that happy day when we have real frozen arrays): class ArrayConstant { private final @Stable T[] values; public ArrayConstant(T[] values) { for (T v : values) Objects.requireNonNull(v); this.values = values.clone(); } public T get(int i) { return values[i]; } //public int length() { return values.length; } } The JIT should be able to constant fold through ac.get(i) whenever ac and i are constants. On Sep 20, 2016, at 8:17 AM, Vladimir Ivanov wrote: > > Looks good. > > src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java: > + LambdaForm bmhArrayForm(MethodType type, BoundMethodHandle.SpeciesData speciesData) { > + int size = type.parameterCount(); > + Transform key = Transform.of(Transform.BMH_AS_ARRAY, size); > + LambdaForm form = getInCache(key); > + if (form != null) { > + return form; > + } > > Please, add an assert to ensure the cached LF has the same constraint as requested (speciesData). > > Best regards, > Vladimir Ivanov > > On 9/20/16 3:53 PM, Michael Haupt wrote: >> Dear all, >> >> please review this change. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161211 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8161211/webrev.00/ >> >> The method handle loop combinators introduced with JEP 274 were originally not intrinsified, leading to poor performance as compared to a pure-Java baseline, but also to handwired method handle combinations. The intrinsics introduced with 8143211 [1] improved on the situation somewhat, but still did not provide good inlining opportunities for the JIT compiler. This change introduces a usage of BoundMethodHandles as arrays to carry the various handles involved in loop execution. >> >> Extra credits to Vladimir Ivanov, who suggested the BMH-as-arrays approach in the first place, and Claes Redestad, who suggested to use LambdaForm editing to neatly enable caching. Thanks! >> >> Performance improves considerably. The table below reports scores in ns/op. The "unpatched" column contains results from before applying the patch for 8161211; the "patched" column, from thereafter. >> >> The create benchmarks measure the cost of loop handle creation. The baseline and baselineMH benchmarks measure the cost of running a pure Java and handwired method handle construct. >> >> Relevant comparisons include loop combinator results versus baselines, and versus unpatched loop combinator results. For the latter, there are significant improvements, except for the creation benchmarks (creation has a more complex workflow now). For the former, it can be seen that the BMH-array intrinsics generally perform better than handwired handle constructs, and have moved much closer to. >> >> Thanks, >> >> Michael >> >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8143211 >> >> >> >> Benchmark (iterations) unpatched patched >> MethodHandlesCountedLoop.Create.create3 N/A 16039.108 18400.405 >> MethodHandlesCountedLoop.Create.create4 N/A 15621.959 17924.696 >> MethodHandlesCountedLoop.Invoke.baseline3 0 2.858 2.839 >> MethodHandlesCountedLoop.Invoke.baseline3 1 5.125 5.164 >> MethodHandlesCountedLoop.Invoke.baseline3 10 11.887 11.924 >> MethodHandlesCountedLoop.Invoke.baseline3 100 67.441 67.281 >> MethodHandlesCountedLoop.Invoke.baseline4 0 2.855 2.838 >> MethodHandlesCountedLoop.Invoke.baseline4 1 5.120 5.179 >> MethodHandlesCountedLoop.Invoke.baseline4 10 11.875 11.906 >> MethodHandlesCountedLoop.Invoke.baseline4 100 67.607 67.374 >> MethodHandlesCountedLoop.Invoke.baselineMH3 0 9.734 9.606 >> MethodHandlesCountedLoop.Invoke.baselineMH3 1 15.689 15.674 >> MethodHandlesCountedLoop.Invoke.baselineMH3 10 68.912 69.303 >> MethodHandlesCountedLoop.Invoke.baselineMH3 100 605.666 606.432 >> MethodHandlesCountedLoop.Invoke.baselineMH4 0 14.561 13.234 >> MethodHandlesCountedLoop.Invoke.baselineMH4 1 19.543 19.773 >> MethodHandlesCountedLoop.Invoke.baselineMH4 10 71.977 72.466 >> MethodHandlesCountedLoop.Invoke.baselineMH4 100 596.842 602.469 >> MethodHandlesCountedLoop.Invoke.countedLoop3 0 49.339 5.810 >> MethodHandlesCountedLoop.Invoke.countedLoop3 1 95.444 7.441 >> MethodHandlesCountedLoop.Invoke.countedLoop3 10 508.746 21.002 >> MethodHandlesCountedLoop.Invoke.countedLoop3 100 4701.808 145.996 >> MethodHandlesCountedLoop.Invoke.countedLoop4 0 49.443 5.798 >> MethodHandlesCountedLoop.Invoke.countedLoop4 1 98.721 7.438 >> MethodHandlesCountedLoop.Invoke.countedLoop4 10 503.825 21.049 >> MethodHandlesCountedLoop.Invoke.countedLoop4 100 4681.803 147.020 >> MethodHandlesDoWhileLoop.Create.create N/A 7628.312 9100.332 >> MethodHandlesDoWhileLoop.Invoke.baseline 1 3.868 3.909 >> MethodHandlesDoWhileLoop.Invoke.baseline 10 16.480 16.461 >> MethodHandlesDoWhileLoop.Invoke.baseline 100 144.260 144.232 >> MethodHandlesDoWhileLoop.Invoke.baselineMH 1 14.434 14.494 >> MethodHandlesDoWhileLoop.Invoke.baselineMH 10 92.542 93.454 >> MethodHandlesDoWhileLoop.Invoke.baselineMH 100 877.480 880.496 >> MethodHandlesDoWhileLoop.Invoke.doWhileLoop 1 26.791 7.153 >> MethodHandlesDoWhileLoop.Invoke.doWhileLoop 10 158.985 16.990 >> MethodHandlesDoWhileLoop.Invoke.doWhileLoop 100 1391.746 130.946 >> MethodHandlesIteratedLoop.Create.create N/A 13547.499 15478.542 >> MethodHandlesIteratedLoop.Invoke.baseline 0 2.973 2.980 >> MethodHandlesIteratedLoop.Invoke.baseline 1 6.771 6.658 >> MethodHandlesIteratedLoop.Invoke.baseline 10 14.955 14.955 >> MethodHandlesIteratedLoop.Invoke.baseline 100 81.842 82.582 >> MethodHandlesIteratedLoop.Invoke.baselineMH 0 14.893 14.668 >> MethodHandlesIteratedLoop.Invoke.baselineMH 1 20.998 21.304 >> MethodHandlesIteratedLoop.Invoke.baselineMH 10 73.677 72.703 >> MethodHandlesIteratedLoop.Invoke.baselineMH 100 613.913 614.475 >> MethodHandlesIteratedLoop.Invoke.iteratedLoop 0 33.583 9.603 >> MethodHandlesIteratedLoop.Invoke.iteratedLoop 1 82.239 14.433 >> MethodHandlesIteratedLoop.Invoke.iteratedLoop 10 448.356 38.650 >> MethodHandlesIteratedLoop.Invoke.iteratedLoop 100 4189.034 279.779 >> MethodHandlesLoop.Create.create N/A 15505.970 17559.399 >> MethodHandlesLoop.Invoke0.baseline 1 3.179 3.181 >> MethodHandlesLoop.Invoke0.baseline 10 5.952 6.115 >> MethodHandlesLoop.Invoke0.baseline 100 50.942 50.943 >> MethodHandlesLoop.Invoke0.loop 1 46.454 5.353 >> MethodHandlesLoop.Invoke0.loop 10 514.230 8.487 >> MethodHandlesLoop.Invoke0.loop 100 5166.251 52.188 >> MethodHandlesLoop.Invoke1.loop 1 34.321 5.277 >> MethodHandlesLoop.Invoke1.loop 10 430.839 8.481 >> MethodHandlesLoop.Invoke1.loop 100 4095.302 52.206 >> MethodHandlesTryFinally.baselineExceptional N/A 3.005 3.002 >> MethodHandlesTryFinally.baselineMHExceptional N/A 166.316 166.087 >> MethodHandlesTryFinally.baselineMHNormal N/A 9.337 9.276 >> MethodHandlesTryFinally.baselineNormal N/A 2.696 2.683 >> MethodHandlesTryFinally.create N/A 406.255 406.594 >> MethodHandlesTryFinally.invokeTryFinallyExceptional N/A 154.121 154.692 >> MethodHandlesTryFinally.invokeTryFinallyNormal N/A 5.350 5.334 >> MethodHandlesWhileLoop.Create.create N/A 12214.383 14503.515 >> MethodHandlesWhileLoop.Invoke.baseline 0 3.886 3.888 >> MethodHandlesWhileLoop.Invoke.baseline 1 5.379 5.377 >> MethodHandlesWhileLoop.Invoke.baseline 10 16.000 16.201 >> MethodHandlesWhileLoop.Invoke.baseline 100 142.066 143.338 >> MethodHandlesWhileLoop.Invoke.baselineMH 0 11.028 11.012 >> MethodHandlesWhileLoop.Invoke.baselineMH 1 21.269 21.159 >> MethodHandlesWhileLoop.Invoke.baselineMH 10 97.493 97.656 >> MethodHandlesWhileLoop.Invoke.baselineMH 100 887.579 886.532 >> MethodHandlesWhileLoop.Invoke.whileLoop 0 24.829 7.108 >> MethodHandlesWhileLoop.Invoke.whileLoop 1 46.039 8.573 >> MethodHandlesWhileLoop.Invoke.whileLoop 10 240.963 21.088 >> MethodHandlesWhileLoop.Invoke.whileLoop 100 2092.671 159.016 >> >> >> From kumar.x.srinivasan at oracle.com Wed Sep 21 13:38:05 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 21 Sep 2016 06:38:05 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> Message-ID: <57E28D3D.5040802@oracle.com> On 9/16/2016 10:34 AM, Volker Simonis wrote: > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the long term. > I hate to see that we now have the third version of these routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually used to > load libjvm. So we can not put the dladdr routines for AIX there. But > I think we should at least consolidate the two versions which will be > in the class library after your change. Initially I intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the modular > changes, the common, top-level aix repository had to go away and the > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build system > it is not possible to share code between modules. We somehow have to > fix this although I currently don't know how. IF somebody has an idea, > please let me know :) Why doesn't AIX support a Standard C API that most other *nix based OS'es support ? Thanks Kumar > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be automatically > included into java_md_common.c trough java.h which includes java_md.h > > Also, this version of dladdr is inherently not thread safe. I don't > think that's a problem here, but it would be nice if you could quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > wrote: >> Hi, >> >> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. >> >> There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >> >> Thanks >> Christoph >> >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>> Of Kumar Srinivasan >>> Sent: Montag, 12. September 2016 22:57 >>> To: core-libs-dev ; Mandy Chung >>> ; Chris Bensen >>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>> >>> Hello, >>> >>> I am sponsoring this changeset for Chris Bensen of the java packager >>> team, please review fix for the launcher to better locate java.home. >>> >>> http://cr.openjdk.java.net/~ksrini/8165524/ >>> >>> Thanks >>> Kumar From sean.coffey at oracle.com Wed Sep 21 15:56:06 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 21 Sep 2016 16:56:06 +0100 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <574EF893.4010602@oracle.com> References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> <5739D4F3.70801@oracle.com> <574EA907.3070306@oracle.com> <574EF893.4010602@oracle.com> Message-ID: <57E2AD96.9090404@oracle.com> Resurrecting this old review thread. After some internal discussion, I've dropped the minor edit that was made in StackTraceElementCompositeData. It could be noisy data for exception purposes. I've corrected the other issues raised by Alan and Jim has long pushed the changes mentioned below. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/ Regards, Sean. On 01/06/16 16:00, Se?n Coffey wrote: > > On 01/06/16 10:21, Alan Bateman wrote: >> On 31/05/2016 18:57, Se?n Coffey wrote: >>> >>> >>> new webrev : >>> http://cr.openjdk.java.net/~coffeys/webrev.8151832.v2/webrev/ >>> >> Also in JprtPath.checkPath then I assume path.getClass() is enough as >> the toString is specified to return a useful string. >> >> In JrtPath then "nul" has been renamed to "null". I'm not sure why >> this has changed. If it is confusing the NUL (one L) should be fine. > nul looked odd/wrong. I'll replace with NUL then. >> >> Jim might want to comment on the jimage updates. In most cases then >> hitting any of these means the JDK is hosed. That is, if we have a >> bug here or the jimage container file is corrupted then it will >> likely not start. > Ok - will pass this by Jim. >> >> In StackTraceElementCompositeData then I'm not sure if printing the >> CompositeType adds anything useful. I might be better to extract >> wording from the table in ThreadInfo.from to make it clear that the >> stackTrace attribute is missing attributes. This reminds me, I >> suspect this table might need to be updated for JDK 9. I will create >> a bug for that. > CompositeType.toString() is pretty comprehensive and iterates through > the instance's keyset. I thought the extra output would hint at what > went wrong. I could print both Objects if you want a better > comparison. Or I can start delving into the ThreadInfo.from table if > you think that's a more correct approach. > > regards, > Sean. >> >> -Alan > From huizhe.wang at oracle.com Wed Sep 21 16:47:15 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 21 Sep 2016 09:47:15 -0700 Subject: RFR: 8166398: CatalogSupport tests need to be fixed -> Re: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage In-Reply-To: <57E17E82.8020305@oracle.com> References: <57E0386D.8010901@oracle.com> <24906308-98a9-5cd1-544a-b23ead912b1a@oracle.com> <57E17E82.8020305@oracle.com> Message-ID: <57E2B993.8090209@oracle.com> Hi Daniel, Here's the fix for the test issues, a couple of errors including missing handler in StAX test, and dtd was mistakingly typed as xsd . The root cause is a debugging assertEquals method that printed out debugging message without throwing Exception. I've searched the jaxp/test to make sure this is the only case where this is used. While fixing the tests, also refactored the code so that the use-catalog is checked as a top condition, removed a ObjectFactory call in the course. JBS: https://bugs.openjdk.java.net/browse/JDK-8166398 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166398/webrev/ Thanks, Joe On 9/20/16, 11:22 AM, Joe Wang wrote: > > > On 9/20/16, 2:20 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java >> >> 603 /** >> 604 * Returns the text of the first element found by the reader. >> 605 * @param streamReader the XMLStreamReader >> 606 * @return the text of the first element >> 607 * @throws XMLStreamException >> 608 */ >> 609 String getText(XMLStreamReader streamReader, int type) >> throws XMLStreamException { >> >> It would be good to update the javadoc of this method (in particular >> document the new 'type' parameter) so that future maintainer >> can understand what that method is supposed to do. > > Thanks Daniel! I'll fix this. > > As I went through the tests again, I found there's actually an error > in the StAX test where the handler was missed. I filed a new bug: > https://bugs.openjdk.java.net/browse/JDK-8166398 > >> >> In particular would it be OK to encounter both CHARACTERS and >> ENTITY_REFERENCE, or are these exclusive. If they are should some >> exception be thrown? > > They can't. At any given point, the StAX parser returns an unique > event and its event type. >> >> I can't say I understand how the new test works, but nothing >> else jumped at me in your webrev :-) > > The incorrect javadoc was enough to raise an alarm, that this part of > code was copied and forgot to update. It led me to double-check the > code and found the issue (JDK-8166398). I really appreciate it! > > Best, > Joe >> >> best regards, >> >> -- daniel >> >> >> On 19/09/16 20:11, Joe Wang wrote: >>> Hi, >>> >>> Please review an addition of StAX tests to the Catalog Support test >>> set. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8166220 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/ >>> >>> Thanks, >>> Joe >>> >> From chris.bensen at oracle.com Wed Sep 21 17:10:48 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 21 Sep 2016 10:10:48 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57E28D3D.5040802@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> Message-ID: > On Sep 21, 2016, at 6:38 AM, Kumar Srinivasan wrote: > > > On 9/16/2016 10:34 AM, Volker Simonis wrote: >> Hi Christoph, >> >> I think your change is fine as a quick-fix to fix the build. But >> you're completely right that this should be reworked in the long term. >> I hate to see that we now have the third version of these routines in >> the OpenJDK. Unfortunately a clean solution is not trivial. >> >> libjli is not linked against libjvm because libjli is actually used to >> load libjvm. So we can not put the dladdr routines for AIX there. But >> I think we should at least consolidate the two versions which will be >> in the class library after your change. Initially I intentionally put >> porting_aix.{c,h} into jdk/aix/porting with the intent to make it >> available to ALL jdk native libraries. >> >> Unfortunately, with the source code reorganization due to the modular >> changes, the common, top-level aix repository had to go away and the >> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. >> With the reorganized, modularized source code layout and build system >> it is not possible to share code between modules. We somehow have to >> fix this although I currently don't know how. IF somebody has an idea, >> please let me know :) > > Why doesn't AIX support a Standard C API that most other > *nix based OS'es support ? I was wondering the same thing. Chris > > Thanks > > Kumar > >> >> Regarding your change: >> >> - can you please move >> >> +#if defined(_AIX) >> +#include "java_md_aix.h" >> +#endif >> + >> >> from java_md_common.c to the end of >> java.base/unix/native/libjli/java_md.h. It will then be automatically >> included into java_md_common.c trough java.h which includes java_md.h >> >> Also, this version of dladdr is inherently not thread safe. I don't >> think that's a problem here, but it would be nice if you could quickly >> check if that's indeed true. >> >> Besides that, looks good. >> >> Thanks for fixing, >> Volker >> >> >> >> >> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >> wrote: >>> Hi, >>> >>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX build as function dladdr is not available on AIX. >>> >>> There already exist ports of that API in hotspot and awt. With the proposed change I duplicate the awt port to libjli. This is maybe only a quick fix - eventually we should think about consolidating and using the hotspot port in all places by exporting it from libjvm.so for AIX. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >>> >>> Thanks >>> Christoph >>> >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>>> Of Kumar Srinivasan >>>> Sent: Montag, 12. September 2016 22:57 >>>> To: core-libs-dev ; Mandy Chung >>>> ; Chris Bensen >>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>>> >>>> Hello, >>>> >>>> I am sponsoring this changeset for Chris Bensen of the java packager >>>> team, please review fix for the launcher to better locate java.home. >>>> >>>> http://cr.openjdk.java.net/~ksrini/8165524/ >>>> >>>> Thanks >>>> Kumar > From martinrb at google.com Wed Sep 21 19:33:07 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 Sep 2016 12:33:07 -0700 Subject: RFR: jsr166 jdk9 integration wave 11 Message-ID: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ Notable here is an attempt to make a minimal completion stage more acceptable as a return value from APIs, by making completableFuture.minimalCompletionStage().toCompletableFuture() useful. Lots of boring changes to appease static analysis tools. From shade at redhat.com Wed Sep 21 19:46:31 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Sep 2016 21:46:31 +0200 Subject: RFR: jsr166 jdk9 integration wave 11 In-Reply-To: References: Message-ID: <8971dbc5-74f0-476b-2b79-61a143c18b32@redhat.com> On 09/21/2016 09:33 PM, Martin Buchholz wrote: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ Looks fine. Multi-story predicates sure look better now... -Aleksey From martinrb at google.com Wed Sep 21 20:43:13 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 Sep 2016 13:43:13 -0700 Subject: We need to add blocking methods to CompletionStage! Message-ID: (Sorry to re-open this discussion) The separation of a read-only CompletionStage from CompletableFuture is great. I'm a fan of the scala style Promise/Future split as described in http://docs.scala-lang.org/overviews/core/futures.html, but: we need to re-add (safe, read-only) blocking methods like join. Java is not Node.js, where there are no threads but there is a universal event loop. Java programmers are used to Future, where the *only* way to use a future's value is to block waiting for it. The existing CompletionStage methods are a better scaling alternative to blocking all the time, but blocking is almost always eventually necessary in Java. For example, junit test methods that start any asynchronous computation need to block until the computation is done, before returning. As Viktor has pointed out, users can always implement blocking themselves by writing static CompletableFuture toCompletableFuture(CompletionStage stage) { CompletableFuture f = new CompletableFuture<>(); stage.handle((T t, Throwable ex) -> { if (ex != null) f.completeExceptionally(ex); else f.complete(t); return null; }); return f; } static T join(CompletionStage stage) { return toCompletableFuture(stage).join(); } but unlike Viktor, I think it's unreasonable to not provide this for users (especially when we can do so more efficiently). What is happening instead is API providers not using CompletionStage as return values in public APIs because of the lack of convenient blocking, and instead returning CompletableFuture, which is a tragic software engineering failure. Re-adding join is easy. We discourage CompletionStage.toCompletableFuture from throwing UnsupportedOperationException, and implement join as: public default T join() { return toCompletableFuture().join(); } There is a risk of multiple-inheritance conflict with Future if we add e.g. isDone(), but there are no current plans to turn those Future methods into default methods, and even if we did in some future release, it would be only a source, not binary incompatibility, so far less serious. From martinrb at google.com Wed Sep 21 21:44:46 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 Sep 2016 14:44:46 -0700 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On Wed, Sep 21, 2016 at 2:38 PM, Pavel Rappo wrote: > On Wed, Sep 21, 2016 at 9:43 PM, Martin Buchholz > wrote: > > What is happening instead is API providers not using CompletionStage as > > return values in public APIs because of the lack of convenient blocking, > and > > instead returning CompletableFuture, which is a tragic software > engineering > > failure. > > On Wed, Sep 21, 2016 at 10:25 PM, Benjamin Manes > wrote: > > I've gradually come to terms using CF as part of an API and haven't > > experienced a downside yet. > > I agree with Benjamin and would like to hear more about how it's a > "tragic software engineering failure". > Obviously I was exaggerating, but the software engineering benefits of separating the producer and consumer users into separate types seems big (like the Builder pattern for immutable collections). Would you use CompletionStage if it had the other methods consumers need? From thomas.stuefe at gmail.com Thu Sep 22 07:05:00 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 22 Sep 2016 09:05:00 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57E28D3D.5040802@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> Message-ID: Hi Kumar, > On 9/16/2016 10:34 AM, Volker Simonis wrote: > >> Hi Christoph, >> >> I think your change is fine as a quick-fix to fix the build. But >> you're completely right that this should be reworked in the long term. >> I hate to see that we now have the third version of these routines in >> the OpenJDK. Unfortunately a clean solution is not trivial. >> >> libjli is not linked against libjvm because libjli is actually used to >> load libjvm. So we can not put the dladdr routines for AIX there. But >> I think we should at least consolidate the two versions which will be >> in the class library after your change. Initially I intentionally put >> porting_aix.{c,h} into jdk/aix/porting with the intent to make it >> available to ALL jdk native libraries. >> >> Unfortunately, with the source code reorganization due to the modular >> changes, the common, top-level aix repository had to go away and the >> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. >> With the reorganized, modularized source code layout and build system >> it is not possible to share code between modules. We somehow have to >> fix this although I currently don't know how. IF somebody has an idea, >> please let me know :) >> > > Why doesn't AIX support a Standard C API that most other > *nix based OS'es support ? > > dladdr() is not Posix, hence it should not be used in code that wants to be portable across Unix systems. Afaik dladdr() is a propietary Solaris API that was adapted by the glibc and slowly spread over to some other Unices, but by no means all of them. dladdr makes a number of assumptions about the architecture: e.g. that a C function pointer points into the text segment of the binary instead of e.g. a PLT, or that a loaded binary is placed continuously in memory (we only have one dli_fbase in DL_info). So imho it makes sense to not make this a standard Posix API. We (SAP) implemented dladdr atop of loadquery(), and this kind of works, although we had to add some hacks to handle both real code addresses and C function pointers. So the code is there, it is "just" a question of where to place it. Kind Regards, Thomas Thanks > > Kumar > > > >> Regarding your change: >> >> - can you please move >> >> +#if defined(_AIX) >> +#include "java_md_aix.h" >> +#endif >> + >> >> from java_md_common.c to the end of >> java.base/unix/native/libjli/java_md.h. It will then be automatically >> included into java_md_common.c trough java.h which includes java_md.h >> >> Also, this version of dladdr is inherently not thread safe. I don't >> think that's a problem here, but it would be nice if you could quickly >> check if that's indeed true. >> >> Besides that, looks good. >> >> Thanks for fixing, >> Volker >> >> >> >> >> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >> wrote: >> >>> Hi, >>> >>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the >>> AIX build as function dladdr is not available on AIX. >>> >>> There already exist ports of that API in hotspot and awt. With the >>> proposed change I duplicate the awt port to libjli. This is maybe only a >>> quick fix - eventually we should think about consolidating and using the >>> hotspot port in all places by exporting it from libjvm.so for AIX. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >>> >>> Thanks >>> Christoph >>> >>> >>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >>>> Behalf >>>> Of Kumar Srinivasan >>>> Sent: Montag, 12. September 2016 22:57 >>>> To: core-libs-dev ; Mandy Chung >>>> ; Chris Bensen >>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>>> >>>> Hello, >>>> >>>> I am sponsoring this changeset for Chris Bensen of the java packager >>>> team, please review fix for the launcher to better locate java.home. >>>> >>>> http://cr.openjdk.java.net/~ksrini/8165524/ >>>> >>>> Thanks >>>> Kumar >>>> >>> > From michael.haupt at oracle.com Thu Sep 22 07:23:39 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 22 Sep 2016 09:23:39 +0200 Subject: RFR(L): 8161211: better inlining support for loop bytecode intrinsics In-Reply-To: References: <68C2D28E-C2DB-4156-86E3-715069D6AB42@oracle.com> <810545e8-1798-1f35-e03f-fdcb55cec46f@oracle.com> Message-ID: <75F40E78-F91C-4CCA-8A01-335DF3B00DA7@oracle.com> Hi John, thanks for your review, and thanks Vladimir! I've had another go at the implementation to use a dedicated loop clause holder class with a stable array; performance is roughly on par with that of the BMHs-as-arrays approach (see below). The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/; please review. Thanks, Michael Benchmark (iterations) unpatched patched CntL.Cr.cr3 N/A 16039.108 15821.583 CntL.Cr.cr4 N/A 15621.959 15869.730 CntL.Inv.bl3 0 2.858 2.835 CntL.Inv.bl3 1 5.125 5.179 CntL.Inv.bl3 10 11.887 12.005 CntL.Inv.bl3 100 67.441 67.279 CntL.Inv.bl4 0 2.855 2.858 CntL.Inv.bl4 1 5.120 5.210 CntL.Inv.bl4 10 11.875 12.012 CntL.Inv.bl4 100 67.607 67.296 CntL.Inv.blMH3 0 9.734 9.722 CntL.Inv.blMH3 1 15.689 15.865 CntL.Inv.blMH3 10 68.912 69.098 CntL.Inv.blMH3 100 605.666 605.526 CntL.Inv.blMH4 0 14.561 13.274 CntL.Inv.blMH4 1 19.543 19.709 CntL.Inv.blMH4 10 71.977 72.446 CntL.Inv.blMH4 100 596.842 598.271 CntL.Inv.cntL3 0 49.339 6.311 CntL.Inv.cntL3 1 95.444 7.333 CntL.Inv.cntL3 10 508.746 20.930 CntL.Inv.cntL3 100 4701.808 147.383 CntL.Inv.cntL4 0 49.443 5.780 CntL.Inv.cntL4 1 98.721 7.465 CntL.Inv.cntL4 10 503.825 20.932 CntL.Inv.cntL4 100 4681.803 147.278 DoWhL.Cr.cr N/A 7628.312 7803.187 DoWhL.Inv.bl 1 3.868 3.869 DoWhL.Inv.bl 10 16.480 16.528 DoWhL.Inv.bl 100 144.260 144.290 DoWhL.Inv.blMH 1 14.434 14.430 DoWhL.Inv.blMH 10 92.542 92.733 DoWhL.Inv.blMH 100 877.480 876.735 DoWhL.Inv.doWhL 1 26.791 7.134 DoWhL.Inv.doWhL 10 158.985 17.004 DoWhL.Inv.doWhL 100 1391.746 133.253 ItrL.Cr.cr N/A 13547.499 13248.913 ItrL.Inv.bl 0 2.973 2.983 ItrL.Inv.bl 1 6.771 6.705 ItrL.Inv.bl 10 14.955 14.952 ItrL.Inv.bl 100 81.842 82.152 ItrL.Inv.blMH 0 14.893 15.014 ItrL.Inv.blMH 1 20.998 21.459 ItrL.Inv.blMH 10 73.677 73.888 ItrL.Inv.blMH 100 613.913 615.208 ItrL.Inv.itrL 0 33.583 10.842 ItrL.Inv.itrL 1 82.239 13.573 ItrL.Inv.itrL 10 448.356 38.773 ItrL.Inv.itrL 100 4189.034 279.918 L.Cr.cr N/A 15505.970 15640.994 L.Inv0.bl 1 3.179 3.186 L.Inv0.bl 10 5.952 5.912 L.Inv0.bl 100 50.942 50.964 L.Inv0.lo 1 46.454 5.290 L.Inv0.lo 10 514.230 8.492 L.Inv0.lo 100 5166.251 52.187 L.Inv1.lo 1 34.321 5.291 L.Inv1.lo 10 430.839 8.474 L.Inv1.lo 100 4095.302 52.173 TF.blEx N/A 3.005 2.986 TF.blMHEx N/A 166.316 165.856 TF.blMHNor N/A 9.337 9.290 TF.blNor N/A 2.696 2.682 TF.cr N/A 406.255 415.090 TF.invTFEx N/A 154.121 154.826 TF.invTFNor N/A 5.350 5.328 WhL.Cr.cr N/A 12214.383 12112.535 WhL.Inv.bl 0 3.886 3.931 WhL.Inv.bl 1 5.379 5.411 WhL.Inv.bl 10 16.000 16.203 WhL.Inv.bl 100 142.066 142.127 WhL.Inv.blMH 0 11.028 10.915 WhL.Inv.blMH 1 21.269 21.419 WhL.Inv.blMH 10 97.493 98.373 WhL.Inv.blMH 100 887.579 892.955 WhL.Inv.whL 0 24.829 7.082 WhL.Inv.whL 1 46.039 8.598 WhL.Inv.whL 10 240.963 21.108 WhL.Inv.whL 100 2092.671 167.619 > Am 20.09.2016 um 21:54 schrieb John Rose : > > There should also be an assert in the new LF constructor, which ensures that the two > arguments are congruent. Better yet, just supply one argument (the speciesData), > and derive the MT. These new LFs are pretty confusing, and it's best to nail down > unused degrees of freedom. > > ? John > > P.S. I would have expected this problem to be solved by having the MHI.toArray function > return a box object with a single @Stable array field. Did that approach fail? > > I.e., this wrapper emulates a frozen array (until that happy day when we have real > frozen arrays): > > class ArrayConstant { > private final @Stable T[] values; > public ArrayConstant(T[] values) { > for (T v : values) Objects.requireNonNull(v); > this.values = values.clone(); > } > public T get(int i) { return values[i]; } > //public int length() { return values.length; } > } > > The JIT should be able to constant fold through ac.get(i) whenever ac and i are constants. > > On Sep 20, 2016, at 8:17 AM, Vladimir Ivanov wrote: >> >> Looks good. >> >> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java: >> + LambdaForm bmhArrayForm(MethodType type, BoundMethodHandle.SpeciesData speciesData) { >> + int size = type.parameterCount(); >> + Transform key = Transform.of(Transform.BMH_AS_ARRAY, size); >> + LambdaForm form = getInCache(key); >> + if (form != null) { >> + return form; >> + } >> >> Please, add an assert to ensure the cached LF has the same constraint as requested (speciesData). >> >> Best regards, >> Vladimir Ivanov >> >> On 9/20/16 3:53 PM, Michael Haupt wrote: >>> Dear all, >>> >>> please review this change. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161211 >>> Webrev: http://cr.openjdk.java.net/~mhaupt/8161211/webrev.00/ >>> >>> The method handle loop combinators introduced with JEP 274 were originally not intrinsified, leading to poor performance as compared to a pure-Java baseline, but also to handwired method handle combinations. The intrinsics introduced with 8143211 [1] improved on the situation somewhat, but still did not provide good inlining opportunities for the JIT compiler. This change introduces a usage of BoundMethodHandles as arrays to carry the various handles involved in loop execution. >>> >>> Extra credits to Vladimir Ivanov, who suggested the BMH-as-arrays approach in the first place, and Claes Redestad, who suggested to use LambdaForm editing to neatly enable caching. Thanks! >>> >>> Performance improves considerably. The table below reports scores in ns/op. The "unpatched" column contains results from before applying the patch for 8161211; the "patched" column, from thereafter. >>> >>> The create benchmarks measure the cost of loop handle creation. The baseline and baselineMH benchmarks measure the cost of running a pure Java and handwired method handle construct. >>> >>> Relevant comparisons include loop combinator results versus baselines, and versus unpatched loop combinator results. For the latter, there are significant improvements, except for the creation benchmarks (creation has a more complex workflow now). For the former, it can be seen that the BMH-array intrinsics generally perform better than handwired handle constructs, and have moved much closer to. >>> >>> Thanks, >>> >>> Michael >>> >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8143211 >>> >>> >>> >>> Benchmark (iterations) unpatched patched >>> MethodHandlesCountedLoop.Create.create3 N/A 16039.108 18400.405 >>> MethodHandlesCountedLoop.Create.create4 N/A 15621.959 17924.696 >>> MethodHandlesCountedLoop.Invoke.baseline3 0 2.858 2.839 >>> MethodHandlesCountedLoop.Invoke.baseline3 1 5.125 5.164 >>> MethodHandlesCountedLoop.Invoke.baseline3 10 11.887 11.924 >>> MethodHandlesCountedLoop.Invoke.baseline3 100 67.441 67.281 >>> MethodHandlesCountedLoop.Invoke.baseline4 0 2.855 2.838 >>> MethodHandlesCountedLoop.Invoke.baseline4 1 5.120 5.179 >>> MethodHandlesCountedLoop.Invoke.baseline4 10 11.875 11.906 >>> MethodHandlesCountedLoop.Invoke.baseline4 100 67.607 67.374 >>> MethodHandlesCountedLoop.Invoke.baselineMH3 0 9.734 9.606 >>> MethodHandlesCountedLoop.Invoke.baselineMH3 1 15.689 15.674 >>> MethodHandlesCountedLoop.Invoke.baselineMH3 10 68.912 69.303 >>> MethodHandlesCountedLoop.Invoke.baselineMH3 100 605.666 606.432 >>> MethodHandlesCountedLoop.Invoke.baselineMH4 0 14.561 13.234 >>> MethodHandlesCountedLoop.Invoke.baselineMH4 1 19.543 19.773 >>> MethodHandlesCountedLoop.Invoke.baselineMH4 10 71.977 72.466 >>> MethodHandlesCountedLoop.Invoke.baselineMH4 100 596.842 602.469 >>> MethodHandlesCountedLoop.Invoke.countedLoop3 0 49.339 5.810 >>> MethodHandlesCountedLoop.Invoke.countedLoop3 1 95.444 7.441 >>> MethodHandlesCountedLoop.Invoke.countedLoop3 10 508.746 21.002 >>> MethodHandlesCountedLoop.Invoke.countedLoop3 100 4701.808 145.996 >>> MethodHandlesCountedLoop.Invoke.countedLoop4 0 49.443 5.798 >>> MethodHandlesCountedLoop.Invoke.countedLoop4 1 98.721 7.438 >>> MethodHandlesCountedLoop.Invoke.countedLoop4 10 503.825 21.049 >>> MethodHandlesCountedLoop.Invoke.countedLoop4 100 4681.803 147.020 >>> MethodHandlesDoWhileLoop.Create.create N/A 7628.312 9100.332 >>> MethodHandlesDoWhileLoop.Invoke.baseline 1 3.868 3.909 >>> MethodHandlesDoWhileLoop.Invoke.baseline 10 16.480 16.461 >>> MethodHandlesDoWhileLoop.Invoke.baseline 100 144.260 144.232 >>> MethodHandlesDoWhileLoop.Invoke.baselineMH 1 14.434 14.494 >>> MethodHandlesDoWhileLoop.Invoke.baselineMH 10 92.542 93.454 >>> MethodHandlesDoWhileLoop.Invoke.baselineMH 100 877.480 880.496 >>> MethodHandlesDoWhileLoop.Invoke.doWhileLoop 1 26.791 7.153 >>> MethodHandlesDoWhileLoop.Invoke.doWhileLoop 10 158.985 16.990 >>> MethodHandlesDoWhileLoop.Invoke.doWhileLoop 100 1391.746 130.946 >>> MethodHandlesIteratedLoop.Create.create N/A 13547.499 15478.542 >>> MethodHandlesIteratedLoop.Invoke.baseline 0 2.973 2.980 >>> MethodHandlesIteratedLoop.Invoke.baseline 1 6.771 6.658 >>> MethodHandlesIteratedLoop.Invoke.baseline 10 14.955 14.955 >>> MethodHandlesIteratedLoop.Invoke.baseline 100 81.842 82.582 >>> MethodHandlesIteratedLoop.Invoke.baselineMH 0 14.893 14.668 >>> MethodHandlesIteratedLoop.Invoke.baselineMH 1 20.998 21.304 >>> MethodHandlesIteratedLoop.Invoke.baselineMH 10 73.677 72.703 >>> MethodHandlesIteratedLoop.Invoke.baselineMH 100 613.913 614.475 >>> MethodHandlesIteratedLoop.Invoke.iteratedLoop 0 33.583 9.603 >>> MethodHandlesIteratedLoop.Invoke.iteratedLoop 1 82.239 14.433 >>> MethodHandlesIteratedLoop.Invoke.iteratedLoop 10 448.356 38.650 >>> MethodHandlesIteratedLoop.Invoke.iteratedLoop 100 4189.034 279.779 >>> MethodHandlesLoop.Create.create N/A 15505.970 17559.399 >>> MethodHandlesLoop.Invoke0.baseline 1 3.179 3.181 >>> MethodHandlesLoop.Invoke0.baseline 10 5.952 6.115 >>> MethodHandlesLoop.Invoke0.baseline 100 50.942 50.943 >>> MethodHandlesLoop.Invoke0.loop 1 46.454 5.353 >>> MethodHandlesLoop.Invoke0.loop 10 514.230 8.487 >>> MethodHandlesLoop.Invoke0.loop 100 5166.251 52.188 >>> MethodHandlesLoop.Invoke1.loop 1 34.321 5.277 >>> MethodHandlesLoop.Invoke1.loop 10 430.839 8.481 >>> MethodHandlesLoop.Invoke1.loop 100 4095.302 52.206 >>> MethodHandlesTryFinally.baselineExceptional N/A 3.005 3.002 >>> MethodHandlesTryFinally.baselineMHExceptional N/A 166.316 166.087 >>> MethodHandlesTryFinally.baselineMHNormal N/A 9.337 9.276 >>> MethodHandlesTryFinally.baselineNormal N/A 2.696 2.683 >>> MethodHandlesTryFinally.create N/A 406.255 406.594 >>> MethodHandlesTryFinally.invokeTryFinallyExceptional N/A 154.121 154.692 >>> MethodHandlesTryFinally.invokeTryFinallyNormal N/A 5.350 5.334 >>> MethodHandlesWhileLoop.Create.create N/A 12214.383 14503.515 >>> MethodHandlesWhileLoop.Invoke.baseline 0 3.886 3.888 >>> MethodHandlesWhileLoop.Invoke.baseline 1 5.379 5.377 >>> MethodHandlesWhileLoop.Invoke.baseline 10 16.000 16.201 >>> MethodHandlesWhileLoop.Invoke.baseline 100 142.066 143.338 >>> MethodHandlesWhileLoop.Invoke.baselineMH 0 11.028 11.012 >>> MethodHandlesWhileLoop.Invoke.baselineMH 1 21.269 21.159 >>> MethodHandlesWhileLoop.Invoke.baselineMH 10 97.493 97.656 >>> MethodHandlesWhileLoop.Invoke.baselineMH 100 887.579 886.532 >>> MethodHandlesWhileLoop.Invoke.whileLoop 0 24.829 7.108 >>> MethodHandlesWhileLoop.Invoke.whileLoop 1 46.039 8.573 >>> MethodHandlesWhileLoop.Invoke.whileLoop 10 240.963 21.088 >>> MethodHandlesWhileLoop.Invoke.whileLoop 100 2092.671 159.016 >>> >>> >>> > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From daniel.fuchs at oracle.com Thu Sep 22 09:09:32 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 22 Sep 2016 10:09:32 +0100 Subject: RFR: 8166398: CatalogSupport tests need to be fixed -> Re: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage In-Reply-To: <57E2B993.8090209@oracle.com> References: <57E0386D.8010901@oracle.com> <24906308-98a9-5cd1-544a-b23ead912b1a@oracle.com> <57E17E82.8020305@oracle.com> <57E2B993.8090209@oracle.com> Message-ID: <5a21407b-d890-26a0-728b-1a8c8b54754c@oracle.com> Hi Joe, Looks good to me. Thanks for having taken the time to take a second look :-) best regards, -- daniel On 21/09/16 17:47, Joe Wang wrote: > Hi Daniel, > > Here's the fix for the test issues, a couple of errors including missing > handler in StAX test, and dtd was mistakingly typed as xsd . The root > cause is a debugging assertEquals method that printed out debugging > message without throwing Exception. I've searched the jaxp/test to make > sure this is the only case where this is used. > > While fixing the tests, also refactored the code so that the use-catalog > is checked as a top condition, removed a ObjectFactory call in the course. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8166398 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166398/webrev/ > > Thanks, > Joe > > On 9/20/16, 11:22 AM, Joe Wang wrote: >> >> >> On 9/20/16, 2:20 AM, Daniel Fuchs wrote: >>> Hi Joe, >>> >>> test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java >>> >>> 603 /** >>> 604 * Returns the text of the first element found by the reader. >>> 605 * @param streamReader the XMLStreamReader >>> 606 * @return the text of the first element >>> 607 * @throws XMLStreamException >>> 608 */ >>> 609 String getText(XMLStreamReader streamReader, int type) >>> throws XMLStreamException { >>> >>> It would be good to update the javadoc of this method (in particular >>> document the new 'type' parameter) so that future maintainer >>> can understand what that method is supposed to do. >> >> Thanks Daniel! I'll fix this. >> >> As I went through the tests again, I found there's actually an error >> in the StAX test where the handler was missed. I filed a new bug: >> https://bugs.openjdk.java.net/browse/JDK-8166398 >> >>> >>> In particular would it be OK to encounter both CHARACTERS and >>> ENTITY_REFERENCE, or are these exclusive. If they are should some >>> exception be thrown? >> >> They can't. At any given point, the StAX parser returns an unique >> event and its event type. >>> >>> I can't say I understand how the new test works, but nothing >>> else jumped at me in your webrev :-) >> >> The incorrect javadoc was enough to raise an alarm, that this part of >> code was copied and forgot to update. It led me to double-check the >> code and found the issue (JDK-8166398). I really appreciate it! >> >> Best, >> Joe >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 19/09/16 20:11, Joe Wang wrote: >>>> Hi, >>>> >>>> Please review an addition of StAX tests to the Catalog Support test >>>> set. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8166220 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/ >>>> >>>> Thanks, >>>> Joe >>>> >>> From chris.hegarty at oracle.com Thu Sep 22 11:47:27 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 22 Sep 2016 12:47:27 +0100 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: Until now CS and CF have not appeared in Java SE API signatures, outside of the j.u.c package. They are, however, currently being proposed for use in API signatures for Java SE 9 [1][2], namely j.l.Process[Handle]::onExit, and more extensively in the proposed new HTTP Client. CF was chosen, in some cases, mainly because it provides 'join'. While some may not like it, a large number of developers still, at some point, want to be able to block. It was felt that CF was more convenient, rather than the CS::toCF dance. In some cases CF provides too many knobs and is not quite suited. For example, the java.net.http package description has the following paragraph [3]: *

    {@code CompletableFuture}s returned by this API will throw * {@link java.lang.UnsupportedOperationException} for their {@link * java.util.concurrent.CompletableFuture#obtrudeValue(Object) obtrudeValue} * and {@link java.util.concurrent.CompletableFuture#obtrudeException(Throwable) * obtrudeException} methods. Invoking the {@link * java.util.concurrent.CompletableFuture#cancel cancel} method on a * {@code CompletableFuture} returned by this API will not interrupt * the underlying operation, but may be useful to complete, exceptionally, * dependent stages that have not already completed. At a minimum adding 'join' to CS would help ( and may cause the above usages in JDK 9 to be revisited ). If this is not acceptable, or maybe even separately, is there any appetite for a type between CS and CF, that would expose a select set of methods ( which methods tbd ) that are "more suited" [*] for use in the above kind of APIs, where the platform or library is using them as a notification mechanism ( cancel may, or may not, be useful to notify the platform / library that the operation / result is no longer interesting, albeit somewhat of a hint ). -Chris. [1] http://download.java.net/java/jdk9/docs/api/java/util/concurrent/class-use/CompletableFuture.html [2] http://download.java.net/java/jdk9/docs/api/java/util/concurrent/class-use/CompletionStage.html [3] http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/1fdd889687c8/src/java.httpclient/share/classes/java/net/http/package-info.java#l46 [*] for some definition of ... > On 21 Sep 2016, at 21:43, Martin Buchholz wrote: > > (Sorry to re-open this discussion) > > The separation of a read-only CompletionStage from CompletableFuture is great. I'm a fan of the scala style Promise/Future split as described in http://docs.scala-lang.org/overviews/core/futures.html, but: we need to re-add (safe, read-only) blocking methods like join. Java is not Node.js, where there are no threads but there is a universal event loop. Java programmers are used to Future, where the *only* way to use a future's value is to block waiting for it. The existing CompletionStage methods are a better scaling alternative to blocking all the time, but blocking is almost always eventually necessary in Java. For example, junit test methods that start any asynchronous computation need to block until the computation is done, before returning. > > As Viktor has pointed out, users can always implement blocking themselves by writing > > static CompletableFuture toCompletableFuture(CompletionStage stage) { > CompletableFuture f = new CompletableFuture<>(); > stage.handle((T t, Throwable ex) -> { > if (ex != null) f.completeExceptionally(ex); > else f.complete(t); > return null; > }); > return f; > } > > static T join(CompletionStage stage) { > return toCompletableFuture(stage).join(); > } > > but unlike Viktor, I think it's unreasonable to not provide this for users (especially when we can do so more efficiently). What is happening instead is API providers not using CompletionStage as return values in public APIs because of the lack of convenient blocking, and instead returning CompletableFuture, which is a tragic software engineering failure. > > Re-adding join is easy. We discourage CompletionStage.toCompletableFuture from throwing UnsupportedOperationException, and implement join as: > > public default T join() { return toCompletableFuture().join(); } > > There is a risk of multiple-inheritance conflict with Future if we add e.g. isDone(), but there are no current plans to turn those Future methods into default methods, and even if we did in some future release, it would be only a source, not binary incompatibility, so far less serious. From chris.hegarty at oracle.com Thu Sep 22 12:39:47 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 22 Sep 2016 13:39:47 +0100 Subject: RFR: jsr166 jdk9 integration wave 11 In-Reply-To: References: Message-ID: <673371B4-D6F5-4809-B214-F8515367E850@oracle.com> On 21 Sep 2016, at 20:33, Martin Buchholz wrote: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > Notable here is an attempt to make a minimal completion stage more acceptable as a return value from APIs, by making completableFuture.minimalCompletionStage().toCompletableFuture() useful. Looks good. CompletableFuture.minimalCompletionStage().toCompletableFuture(), this is subtle. I think what you have is right. Thankfully CS::toCompletableFuture allows this; "If this stage is already a CompletableFuture, this method MAY return this stage itself." Can you please check the indentation in testCopy_normalCompletion and testCopy_exceptionalCompletion. -Chris. From Alan.Bateman at oracle.com Thu Sep 22 13:14:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 Sep 2016 06:14:27 -0700 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <57E2AD96.9090404@oracle.com> References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> <5739D4F3.70801@oracle.com> <574EA907.3070306@oracle.com> <574EF893.4010602@oracle.com> <57E2AD96.9090404@oracle.com> Message-ID: <1f70fa12-3e7f-2756-6ed2-7a68efd55e0d@oracle.com> On 21/09/2016 08:56, Se?n Coffey wrote: > Resurrecting this old review thread. After some internal discussion, > I've dropped the minor edit that was made in > StackTraceElementCompositeData. It could be noisy data for exception > purposes. I've corrected the other issues raised by Alan and Jim has > long pushed the changes mentioned below. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/ This looks okay to me. You may want to change the bug message to drop "thrown by jigsaw code" as most of the changed files are jimage or other areas. -Alan From martinrb at google.com Thu Sep 22 14:57:10 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 22 Sep 2016 07:57:10 -0700 Subject: RFR: jsr166 jdk9 integration wave 11 In-Reply-To: <673371B4-D6F5-4809-B214-F8515367E850@oracle.com> References: <673371B4-D6F5-4809-B214-F8515367E850@oracle.com> Message-ID: On Thu, Sep 22, 2016 at 5:39 AM, Chris Hegarty wrote: > > Can you please check the indentation in testCopy_normalCompletion > and testCopy_exceptionalCompletion. > CompletableFutureTest.java has a unique experimental indentation style, that is not clearly worse than the alternatives. From sean.coffey at oracle.com Thu Sep 22 15:29:17 2016 From: sean.coffey at oracle.com (Sean Coffey) Date: Thu, 22 Sep 2016 16:29:17 +0100 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <1f70fa12-3e7f-2756-6ed2-7a68efd55e0d@oracle.com> References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> <5739D4F3.70801@oracle.com> <574EA907.3070306@oracle.com> <574EF893.4010602@oracle.com> <57E2AD96.9090404@oracle.com> <1f70fa12-3e7f-2756-6ed2-7a68efd55e0d@oracle.com> Message-ID: <28bf0e67-c2f7-eca6-60f4-915e7a2b2fc2@oracle.com> On 22/09/2016 14:14, Alan Bateman wrote: > This looks okay to me. You may want to change the bug message to drop > "thrown by jigsaw code" as most of the changed files are jimage or > other areas. Thanks Alan - Yes - will correct that before I push then. regards, Sean. From huizhe.wang at oracle.com Thu Sep 22 16:01:30 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 22 Sep 2016 09:01:30 -0700 Subject: RFR: 8166398: CatalogSupport tests need to be fixed -> Re: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage In-Reply-To: <5a21407b-d890-26a0-728b-1a8c8b54754c@oracle.com> References: <57E0386D.8010901@oracle.com> <24906308-98a9-5cd1-544a-b23ead912b1a@oracle.com> <57E17E82.8020305@oracle.com> <57E2B993.8090209@oracle.com> <5a21407b-d890-26a0-728b-1a8c8b54754c@oracle.com> Message-ID: <57E4005A.1020004@oracle.com> Thanks Daniel! I'm glad the issue was caught! I'm also making sure any the debugging method shall throw Exception as well :-) Best, Joe On 9/22/16, 2:09 AM, Daniel Fuchs wrote: > Hi Joe, > > Looks good to me. > > Thanks for having taken the time to take a second look :-) > > best regards, > > -- daniel > > On 21/09/16 17:47, Joe Wang wrote: >> Hi Daniel, >> >> Here's the fix for the test issues, a couple of errors including missing >> handler in StAX test, and dtd was mistakingly typed as xsd . The root >> cause is a debugging assertEquals method that printed out debugging >> message without throwing Exception. I've searched the jaxp/test to make >> sure this is the only case where this is used. >> >> While fixing the tests, also refactored the code so that the use-catalog >> is checked as a top condition, removed a ObjectFactory call in the >> course. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8166398 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166398/webrev/ >> >> Thanks, >> Joe >> >> On 9/20/16, 11:22 AM, Joe Wang wrote: >>> >>> >>> On 9/20/16, 2:20 AM, Daniel Fuchs wrote: >>>> Hi Joe, >>>> >>>> test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java >>>> >>>> 603 /** >>>> 604 * Returns the text of the first element found by the reader. >>>> 605 * @param streamReader the XMLStreamReader >>>> 606 * @return the text of the first element >>>> 607 * @throws XMLStreamException >>>> 608 */ >>>> 609 String getText(XMLStreamReader streamReader, int type) >>>> throws XMLStreamException { >>>> >>>> It would be good to update the javadoc of this method (in particular >>>> document the new 'type' parameter) so that future maintainer >>>> can understand what that method is supposed to do. >>> >>> Thanks Daniel! I'll fix this. >>> >>> As I went through the tests again, I found there's actually an error >>> in the StAX test where the handler was missed. I filed a new bug: >>> https://bugs.openjdk.java.net/browse/JDK-8166398 >>> >>>> >>>> In particular would it be OK to encounter both CHARACTERS and >>>> ENTITY_REFERENCE, or are these exclusive. If they are should some >>>> exception be thrown? >>> >>> They can't. At any given point, the StAX parser returns an unique >>> event and its event type. >>>> >>>> I can't say I understand how the new test works, but nothing >>>> else jumped at me in your webrev :-) >>> >>> The incorrect javadoc was enough to raise an alarm, that this part of >>> code was copied and forgot to update. It led me to double-check the >>> code and found the issue (JDK-8166398). I really appreciate it! >>> >>> Best, >>> Joe >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>> On 19/09/16 20:11, Joe Wang wrote: >>>>> Hi, >>>>> >>>>> Please review an addition of StAX tests to the Catalog Support test >>>>> set. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8166220 >>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/ >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>>> > From brent.christian at oracle.com Thu Sep 22 16:04:56 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 22 Sep 2016 09:04:56 -0700 Subject: RFR 8166501 : compilation error in stackwalk.cpp on some gccs Message-ID: <57E40128.8010409@oracle.com> Hi, Looks like my 8165372 change broke the slowdebug build. Please review my fix (which also breaks up a pretty long line): --- a/src/share/vm/prims/stackwalk.cpp +++ b/src/share/vm/prims/stackwalk.cpp @@ -331,10 +331,12 @@ assert (use_frames_array(mode), "Bad mode for get live frame"); RegisterMap regMap(jt, true); LiveFrameStream stream(jt, ®Map); - return fetchFirstBatch(stream, stackStream, mode, skip_frames, frame_count, start_index, frames_array, CHECK_NULL); + return fetchFirstBatch(stream, stackStream, mode, skip_frames, frame_count, + start_index, frames_array, THREAD); } else { JavaFrameStream stream(jt, mode); - return fetchFirstBatch(stream, stackStream, mode, skip_frames, frame_count, start_index, frames_array, CHECK_NULL); + return fetchFirstBatch(stream, stackStream, mode, skip_frames, frame_count, + start_index, frames_array, THREAD); } } Thanks! -Brent From john.r.rose at oracle.com Thu Sep 22 18:04:29 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 22 Sep 2016 11:04:29 -0700 Subject: RFR(L): 8161211: better inlining support for loop bytecode intrinsics In-Reply-To: <75F40E78-F91C-4CCA-8A01-335DF3B00DA7@oracle.com> References: <68C2D28E-C2DB-4156-86E3-715069D6AB42@oracle.com> <810545e8-1798-1f35-e03f-fdcb55cec46f@oracle.com> <75F40E78-F91C-4CCA-8A01-335DF3B00DA7@oracle.com> Message-ID: On Sep 22, 2016, at 12:23 AM, Michael Haupt wrote: > thanks for your review, and thanks Vladimir! I've had another go at the implementation to use a dedicated loop clause holder class with a stable array; performance is roughly on par with that of the BMHs-as-arrays approach (see below). > > The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/ ; please review. Yes, that's cleaner. Suggestion: Filter all loop clause functions with ".asFixedArity" when you wrap up the constant array. This will do two things: 1. double-check for nulls (which @Stable doesn't like) and 2. allow you to omit all asFixedArity calls from the driver function (MHI.loop). The asFixedArity normalization could move into MethodHandles.java, in fact, since that's part of the advertised semantics (hmm, right?). Also (this is a nit) consider commoning (binding a temp for) the three expressions 'init[i]' in the driver. I noticed that while peeking at the asFixedArity calls. The JIT will DTRT here, but we might as well make its job a bit easier. JITs enjoy little favors like that; they are less likely to drop optimizations. Reviewed! ? John From mandy.chung at oracle.com Thu Sep 22 18:23:08 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 22 Sep 2016 11:23:08 -0700 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <57E2AD96.9090404@oracle.com> References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> <5739D4F3.70801@oracle.com> <574EA907.3070306@oracle.com> <574EF893.4010602@oracle.com> <57E2AD96.9090404@oracle.com> Message-ID: <2148F202-1B40-4BDB-A207-808F0E97B615@oracle.com> > On Sep 21, 2016, at 8:56 AM, Se?n Coffey wrote: > > Resurrecting this old review thread. After some internal discussion, I've dropped the minor edit that was made in StackTraceElementCompositeData. It could be noisy data for exception purposes. I've corrected the other issues raised by Alan and Jim has long pushed the changes mentioned below. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/ The change looks okay. src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java 189 throw new IOException("The image file \"" + name + "\" is not " + 190 "the correct version. Major: " + result.getMajorVersion() + 191 ". Minor: " + result.getMinorVersion()); One suggestion for this exception message to: throw new IOException("The image file \"" + name + "\? version ? + result.getMajorVersion() + "." + result.getMinorVersion() + ? not supported?); No need for a new webrev and you can update this before you push. Mandy From sean.coffey at oracle.com Thu Sep 22 18:43:30 2016 From: sean.coffey at oracle.com (Sean Coffey) Date: Thu, 22 Sep 2016 19:43:30 +0100 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <2148F202-1B40-4BDB-A207-808F0E97B615@oracle.com> References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> <5739D4F3.70801@oracle.com> <574EA907.3070306@oracle.com> <574EF893.4010602@oracle.com> <57E2AD96.9090404@oracle.com> <2148F202-1B40-4BDB-A207-808F0E97B615@oracle.com> Message-ID: <943be05e-c761-e05a-4713-eb0e39810a01@oracle.com> Thanks Mandy. I pushed this change earlier today. If BasicImageReader.java is being edited again in the near future, we might be able to make your suggested edits then. regards, Sean. On 22/09/2016 19:23, Mandy Chung wrote: >> On Sep 21, 2016, at 8:56 AM, Se?n Coffey wrote: >> >> Resurrecting this old review thread. After some internal discussion, I've dropped the minor edit that was made in StackTraceElementCompositeData. It could be noisy data for exception purposes. I've corrected the other issues raised by Alan and Jim has long pushed the changes mentioned below. >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/ > The change looks okay. > > src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java > 189 throw new IOException("The image file \"" + name + "\" is not " + > 190 "the correct version. Major: " + result.getMajorVersion() + > 191 ". Minor: " + result.getMinorVersion()); > > One suggestion for this exception message to: > > throw new IOException("The image file \"" + name + "\? version ? + > result.getMajorVersion() + "." + result.getMinorVersion() + > ? not supported?); > > No need for a new webrev and you can update this before you push. > > Mandy From dmitry.samersoff at oracle.com Thu Sep 22 18:43:42 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 22 Sep 2016 21:43:42 +0300 Subject: RFR 8166501 : compilation error in stackwalk.cpp on some gccs In-Reply-To: <57E40128.8010409@oracle.com> References: <57E40128.8010409@oracle.com> Message-ID: <4724b2d4-a2ab-8251-86e3-37ffc0ea87c7@oracle.com> Brent, Looks good for me. -Dmitry On 2016-09-22 19:04, Brent Christian wrote: > Hi, > > Looks like my 8165372 change broke the slowdebug build. Please review > my fix (which also breaks up a pretty long line): > > --- a/src/share/vm/prims/stackwalk.cpp > +++ b/src/share/vm/prims/stackwalk.cpp > @@ -331,10 +331,12 @@ > assert (use_frames_array(mode), "Bad mode for get live frame"); > RegisterMap regMap(jt, true); > LiveFrameStream stream(jt, ®Map); > - return fetchFirstBatch(stream, stackStream, mode, skip_frames, > frame_count, start_index, frames_array, CHECK_NULL); > + return fetchFirstBatch(stream, stackStream, mode, skip_frames, > frame_count, > + start_index, frames_array, THREAD); > } else { > JavaFrameStream stream(jt, mode); > - return fetchFirstBatch(stream, stackStream, mode, skip_frames, > frame_count, start_index, frames_array, CHECK_NULL); > + return fetchFirstBatch(stream, stackStream, mode, skip_frames, > frame_count, > + start_index, frames_array, THREAD); > } > } > > Thanks! > -Brent > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mandy.chung at oracle.com Thu Sep 22 18:46:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 22 Sep 2016 11:46:48 -0700 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <943be05e-c761-e05a-4713-eb0e39810a01@oracle.com> References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> <5739D4F3.70801@oracle.com> <574EA907.3070306@oracle.com> <574EF893.4010602@oracle.com> <57E2AD96.9090404@oracle.com> <2148F202-1B40-4BDB-A207-808F0E97B615@oracle.com> <943be05e-c761-e05a-4713-eb0e39810a01@oracle.com> Message-ID: <496D2665-B3AF-447E-BCE5-381A11D33605@oracle.com> That?d be fine. Mandy > On Sep 22, 2016, at 11:43 AM, Sean Coffey wrote: > > Thanks Mandy. I pushed this change earlier today. If BasicImageReader.java is being edited again in the near future, we might be able to make your suggested edits then. > > regards, > Sean. > > On 22/09/2016 19:23, Mandy Chung wrote: >>> On Sep 21, 2016, at 8:56 AM, Se?n Coffey wrote: >>> >>> Resurrecting this old review thread. After some internal discussion, I've dropped the minor edit that was made in StackTraceElementCompositeData. It could be noisy data for exception purposes. I've corrected the other issues raised by Alan and Jim has long pushed the changes mentioned below. >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/ >> The change looks okay. >> >> src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java >> 189 throw new IOException("The image file \"" + name + "\" is not " + >> 190 "the correct version. Major: " + result.getMajorVersion() + >> 191 ". Minor: " + result.getMinorVersion()); >> >> One suggestion for this exception message to: >> >> throw new IOException("The image file \"" + name + "\? version ? + >> result.getMajorVersion() + "." + result.getMinorVersion() + >> ? not supported?); >> >> No need for a new webrev and you can update this before you push. >> >> Mandy > From martinrb at google.com Thu Sep 22 21:27:01 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 22 Sep 2016 14:27:01 -0700 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: Thanks for the lesson, James! On Wed, Sep 21, 2016 at 3:57 PM, James Roper wrote: > On 22 September 2016 at 06:43, Martin Buchholz > wrote: > >> What is happening instead is API providers not using CompletionStage as >> return values in public APIs because of the lack of convenient blocking, >> and instead returning CompletableFuture, which is a tragic software >> engineering failure. >> > > Out of interest, which APIs are returning CompletableFuture rather than > CompletionStage? In the Play Framework Java API, we have embraced > CompletionStage, we use it absolutely everywhere. Likewise in Lagom > Framework and the Java API for Akka streams. > > When it comes to blocking, we strongly advocate never blocking (in the > threading models of these projects, blocking on a future will make you very > prone to deadlocks). > I took a look at the Scala/Akka/LightBend world. Even there, blocking always remains a possibility, even if discouraged, e.g. scala.concurrent.Future extends Awaitable (!), and http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#Blocking_Needs_Careful_Management . And any general purpose Java API needs to be useful outside of a framework. > But of course, the exception is junit tests, in that case, we encourage > the use of CompletionStage.toCompletableFuture to block. > We're currently fixing jdk9 CompletableFuture.minimalCompletionStage().toCompletableFuture() to be awaitable. To make toCompletableFuture().join() more reliable as a recommended way to block, I think we should remove the encouragement to throw UOE from: http://download.java.net/java/jdk9/docs/api/java/util/concurrent/CompletionStage.html#toCompletableFuture-- It sounds like the Akka/LightBend World is happy with current CompletionStage API (may I call this the "actor purist API"?), while other users will want a bigger, more general CompletableFuture subset for consuming future values. Frustratingly, some of them will want cancel(), some not; and we have no good names for any new interfaces; right now all I can think of is CompletionStage2 and CompletionStage3 !) The current implementation of CompletableFuture has a "memory leak problem" in that e.g. minimalStage().toCompletableFuture().isDone() will leak a Completion object until the source stage itself is collected. Which doesn't happen if e.g. a direct isDone() is provided. JDK-8161600: Garbage retention when source CompletableFutures are never completed (but no one has ever complained!) From david.holmes at oracle.com Fri Sep 23 00:44:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Sep 2016 10:44:36 +1000 Subject: RFR 8166501 : compilation error in stackwalk.cpp on some gccs In-Reply-To: <57E40128.8010409@oracle.com> References: <57E40128.8010409@oracle.com> Message-ID: This is the second example I've seen in two days concerning misuse of CHECK_ macros. They expand into an if statement after the call, so can not appear on calls that are part of a return statement, or a conditional statement, or likely a number of other places, as the if code either becomes unreachable or else does not do what may be expected. David ----- On 23/09/2016 2:04 AM, Brent Christian wrote: > Hi, > > Looks like my 8165372 change broke the slowdebug build. Please review > my fix (which also breaks up a pretty long line): > > --- a/src/share/vm/prims/stackwalk.cpp > +++ b/src/share/vm/prims/stackwalk.cpp > @@ -331,10 +331,12 @@ > assert (use_frames_array(mode), "Bad mode for get live frame"); > RegisterMap regMap(jt, true); > LiveFrameStream stream(jt, ®Map); > - return fetchFirstBatch(stream, stackStream, mode, skip_frames, > frame_count, start_index, frames_array, CHECK_NULL); > + return fetchFirstBatch(stream, stackStream, mode, skip_frames, > frame_count, > + start_index, frames_array, THREAD); > } else { > JavaFrameStream stream(jt, mode); > - return fetchFirstBatch(stream, stackStream, mode, skip_frames, > frame_count, start_index, frames_array, CHECK_NULL); > + return fetchFirstBatch(stream, stackStream, mode, skip_frames, > frame_count, > + start_index, frames_array, THREAD); > } > } > > Thanks! > -Brent > From goetz.lindenmaier at sap.com Fri Sep 23 05:52:31 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 23 Sep 2016 05:52:31 +0000 Subject: RFR(M): 8166560: [s390] Basic enablement of s390 port. Message-ID: Hi, This change is part of the s390 port. It contains some basic adaptions needed for a full hotspot port for linux s390x. It defines the required macros, platform names and includes. The s390 port calles CodeCache::contains() in current_frame(), which is used in NMT. As NMT already collects stack traces before the CodeCache is initialized, contains() needs a check for this. Wherever a row of platforms are listed, I sorted them alphabetically. The jdk requires the file jvm.cfg. Please review. I please need a sponsor. http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/ http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/jdk.wr01/ Best regards, Goetz. From david.holmes at oracle.com Fri Sep 23 06:11:20 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Sep 2016 16:11:20 +1000 Subject: RFR(M): 8166560: [s390] Basic enablement of s390 port. In-Reply-To: References: Message-ID: Hi Goetz, I see a change not related directly to S390 ie change from ARM to ARM32 in src/os/linux/vm/os_linux.cpp It will be a while before I can go through this in any detail. David On 23/09/2016 3:52 PM, Lindenmaier, Goetz wrote: > Hi, > > This change is part of the s390 port. It contains some basic adaptions needed for a full hotspot port for linux s390x. > > It defines the required macros, platform names and includes. > > The s390 port calles CodeCache::contains() in current_frame(), which is used in NMT. As NMT already collects stack traces before the CodeCache is initialized, contains() needs a check for this. > > Wherever a row of platforms are listed, I sorted them alphabetically. > > The jdk requires the file jvm.cfg. > > Please review. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/ > http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/jdk.wr01/ > > Best regards, > Goetz. > From kasperni at gmail.com Fri Sep 23 06:13:36 2016 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 23 Sep 2016 08:13:36 +0200 Subject: Collection Design FAQ Message-ID: Hi, I accidently bumped into an old friend today https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html There are couple of questions that might need an update after Java 8. Such as Why don't you provide an "apply" method in Collection to apply a given method ("upcall") to all the elements of the Collection? Why didn't you provide a "Predicate" interface, and related methods (e.g., a method to find the first element in the Collection satisfying the predicate)? Best Kasper From kasperni at gmail.com Fri Sep 23 06:45:42 2016 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 23 Sep 2016 08:45:42 +0200 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On 21 September 2016 at 22:43, Martin Buchholz wrote: > (Sorry to re-open this discussion) > > The separation of a read-only CompletionStage from CompletableFuture is > great. I'm a fan of the scala style Promise/Future split as described in > http://docs.scala-lang.org/overviews/core/futures.html, but: we need to > re-add (safe, read-only) blocking methods like join. Just want to say that I agree. I have using CS/CF for APIs extensively since Java 8. And all my usage basically boils down to 3 basic use cases. And I think most others will end up with the same use cases. 1) Observing The user receives a CS where he can query about the state of the future and add follow up actions. I really would like to see the rest of the non-mutating methods from CompletableFuture added to CompletionStage here if possible. get() get(long, TimeUnit) getNow() isCompletedExceptionally isDone() isCompletedNormally() (isDone && !isCompletedExceptionally) <- new method 2) Cancellable Tasks that can be cancelled by the user but where the user should not be able to modify the result or set a custom exception. For example, cancel connecting to a remote host or cancel some internal computation. Right not this is a bit painfull. I have to wrap CompletableFuture to allow cancel but hide complete/obtrude Would not mind a CancellableCompletionStage interface CancellableCompletionStage extends CompletionStage { isCancelled(); cancel(boolean) } 3) Mutable The user has complete control. Basically just these three additional methods compared to CancellableCompletionStage. complete() completeExceptionally() obtrudeException() I'm fine with returning CompletableFuture here. Best Kasper From forax at univ-mlv.fr Fri Sep 23 06:53:59 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 23 Sep 2016 06:53:59 +0000 Subject: Collection Design FAQ In-Reply-To: References: Message-ID: <9E993897-3A0B-432B-9BDA-1A1A98E65F5F@univ-mlv.fr> On September 23, 2016 8:13:36 AM GMT+02:00, Kasper Nielsen wrote: >Hi, > >I accidently bumped into an old friend today >https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html >There are couple of questions that might need an update after Java 8. >Such >as > >Why don't you provide an "apply" method in Collection to apply a given >method ("upcall") to all the elements of the Collection? Take a look to Iterable.forEach >Why didn't you provide a "Predicate" interface, and related methods >(e.g., >a method to find the first element in the Collection satisfying the >predicate)? predicate => java.util.function.Predicate col.stream ().filter(predicate).findFirst () (or findAny()) it's on Stream because you can choose if you want a parallel operation or not. > >Best > Kasper Remi -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From kasperni at gmail.com Fri Sep 23 07:41:05 2016 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 23 Sep 2016 09:41:05 +0200 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: > > Would not mind a CancellableCompletionStage interface > CancellableCompletionStage extends CompletionStage { > isCancelled(); > cancel(boolean) > } > > Just wanted to note. This is not just a question about functionality. It is also a signal to users about "hey this a computation you can cancel". For example, if you where to retrofit all of java.nio you would probably use CancellableCompletionStage (or whatever the name) for all methods. You do not really need to set an int or whatever the read/write methods return in 99% of all cases. Best Kasper From roman.grigoriadi at oracle.com Fri Sep 23 10:39:31 2016 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Fri, 23 Sep 2016 12:39:31 +0200 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version Message-ID: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> Hi, Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8164479 Webrev: http://cr.openjdk.java.net/~aefimov/8164479/00/ You can find change list in the description of JBS and its linked issues. Most important is removal of code incompatible with JDK9 module system. With best regards, Roman From michael.haupt at oracle.com Fri Sep 23 13:40:21 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 23 Sep 2016 15:40:21 +0200 Subject: RFR(L): 8161211: better inlining support for loop bytecode intrinsics In-Reply-To: References: <68C2D28E-C2DB-4156-86E3-715069D6AB42@oracle.com> <810545e8-1798-1f35-e03f-fdcb55cec46f@oracle.com> <75F40E78-F91C-4CCA-8A01-335DF3B00DA7@oracle.com> Message-ID: <85E213CC-26A2-409F-9034-ABA1A553BFA6@oracle.com> Hi John, thank you for your review. Comments on your suggestions are inlined. > Am 22.09.2016 um 20:04 schrieb John Rose : > On Sep 22, 2016, at 12:23 AM, Michael Haupt > wrote: >> The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/ ; please review. > > > Suggestion: Filter all loop clause functions with ".asFixedArity" when you wrap up the constant array. > This will do two things: 1. double-check for nulls (which @Stable doesn't like) and 2. allow you to > omit all asFixedArity calls from the driver function (MHI.loop). The asFixedArity normalization could > move into MethodHandles.java, in fact, since that's part of the advertised semantics (hmm, right?). The double-checking for nulls is not strictly required, as none of the handles in any of the loop clauses will be null at the point the call to MethodHandleImpl.makeLoop() is made. I still like the idea of moving these calls out of the driver and will apply it. I'm applying the same transformation to the tryFinally combinator. > Also (this is a nit) consider commoning (binding a temp for) the three expressions 'init[i]' in the driver. > I noticed that while peeking at the asFixedArity calls. The JIT will DTRT here, but we might as well > make its job a bit easier. JITs enjoy little favors like that; they are less likely to drop optimizations. Agreed. With the performance measurements showing no difference, I'm going to push with these modifications. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sergei.kovalev at oracle.com Fri Sep 23 13:54:14 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Fri, 23 Sep 2016 16:54:14 +0300 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies Message-ID: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> Hello team, Could you please review a very small fix that relates to tests only. BugID: https://bugs.openjdk.java.net/browse/JDK-8166624 Webrev: http://cr.openjdk.java.net/~skovalev/8166624/webrev.00/ Issue: Some regression tests fails in case of usage "--limit-modules java.base" command line option. Root cause: The tests have no module declaration in jtreg header. Solution: add module dependencies to the tests header. Testing done: tested locally by jtreg. -- With best regards, Sergei From vladimir.x.ivanov at oracle.com Fri Sep 23 16:41:53 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 23 Sep 2016 19:41:53 +0300 Subject: RFR(L): 8161211: better inlining support for loop bytecode intrinsics In-Reply-To: <75F40E78-F91C-4CCA-8A01-335DF3B00DA7@oracle.com> References: <68C2D28E-C2DB-4156-86E3-715069D6AB42@oracle.com> <810545e8-1798-1f35-e03f-fdcb55cec46f@oracle.com> <75F40E78-F91C-4CCA-8A01-335DF3B00DA7@oracle.com> Message-ID: Looks even better :-) Reviewed. Best regards, Vladimir Ivanov On 9/22/16 10:23 AM, Michael Haupt wrote: > Hi John, > > thanks for your review, and thanks Vladimir! I've had another go at the implementation to use a dedicated loop clause holder class with a stable array; performance is roughly on par with that of the BMHs-as-arrays approach (see below). > > The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/; please review. > > Thanks, > > Michael > > > > > Benchmark (iterations) unpatched patched > CntL.Cr.cr3 N/A 16039.108 15821.583 > CntL.Cr.cr4 N/A 15621.959 15869.730 > CntL.Inv.bl3 0 2.858 2.835 > CntL.Inv.bl3 1 5.125 5.179 > CntL.Inv.bl3 10 11.887 12.005 > CntL.Inv.bl3 100 67.441 67.279 > CntL.Inv.bl4 0 2.855 2.858 > CntL.Inv.bl4 1 5.120 5.210 > CntL.Inv.bl4 10 11.875 12.012 > CntL.Inv.bl4 100 67.607 67.296 > CntL.Inv.blMH3 0 9.734 9.722 > CntL.Inv.blMH3 1 15.689 15.865 > CntL.Inv.blMH3 10 68.912 69.098 > CntL.Inv.blMH3 100 605.666 605.526 > CntL.Inv.blMH4 0 14.561 13.274 > CntL.Inv.blMH4 1 19.543 19.709 > CntL.Inv.blMH4 10 71.977 72.446 > CntL.Inv.blMH4 100 596.842 598.271 > CntL.Inv.cntL3 0 49.339 6.311 > CntL.Inv.cntL3 1 95.444 7.333 > CntL.Inv.cntL3 10 508.746 20.930 > CntL.Inv.cntL3 100 4701.808 147.383 > CntL.Inv.cntL4 0 49.443 5.780 > CntL.Inv.cntL4 1 98.721 7.465 > CntL.Inv.cntL4 10 503.825 20.932 > CntL.Inv.cntL4 100 4681.803 147.278 > DoWhL.Cr.cr N/A 7628.312 7803.187 > DoWhL.Inv.bl 1 3.868 3.869 > DoWhL.Inv.bl 10 16.480 16.528 > DoWhL.Inv.bl 100 144.260 144.290 > DoWhL.Inv.blMH 1 14.434 14.430 > DoWhL.Inv.blMH 10 92.542 92.733 > DoWhL.Inv.blMH 100 877.480 876.735 > DoWhL.Inv.doWhL 1 26.791 7.134 > DoWhL.Inv.doWhL 10 158.985 17.004 > DoWhL.Inv.doWhL 100 1391.746 133.253 > ItrL.Cr.cr N/A 13547.499 13248.913 > ItrL.Inv.bl 0 2.973 2.983 > ItrL.Inv.bl 1 6.771 6.705 > ItrL.Inv.bl 10 14.955 14.952 > ItrL.Inv.bl 100 81.842 82.152 > ItrL.Inv.blMH 0 14.893 15.014 > ItrL.Inv.blMH 1 20.998 21.459 > ItrL.Inv.blMH 10 73.677 73.888 > ItrL.Inv.blMH 100 613.913 615.208 > ItrL.Inv.itrL 0 33.583 10.842 > ItrL.Inv.itrL 1 82.239 13.573 > ItrL.Inv.itrL 10 448.356 38.773 > ItrL.Inv.itrL 100 4189.034 279.918 > L.Cr.cr N/A 15505.970 15640.994 > L.Inv0.bl 1 3.179 3.186 > L.Inv0.bl 10 5.952 5.912 > L.Inv0.bl 100 50.942 50.964 > L.Inv0.lo 1 46.454 5.290 > L.Inv0.lo 10 514.230 8.492 > L.Inv0.lo 100 5166.251 52.187 > L.Inv1.lo 1 34.321 5.291 > L.Inv1.lo 10 430.839 8.474 > L.Inv1.lo 100 4095.302 52.173 > TF.blEx N/A 3.005 2.986 > TF.blMHEx N/A 166.316 165.856 > TF.blMHNor N/A 9.337 9.290 > TF.blNor N/A 2.696 2.682 > TF.cr N/A 406.255 415.090 > TF.invTFEx N/A 154.121 154.826 > TF.invTFNor N/A 5.350 5.328 > WhL.Cr.cr N/A 12214.383 12112.535 > WhL.Inv.bl 0 3.886 3.931 > WhL.Inv.bl 1 5.379 5.411 > WhL.Inv.bl 10 16.000 16.203 > WhL.Inv.bl 100 142.066 142.127 > WhL.Inv.blMH 0 11.028 10.915 > WhL.Inv.blMH 1 21.269 21.419 > WhL.Inv.blMH 10 97.493 98.373 > WhL.Inv.blMH 100 887.579 892.955 > WhL.Inv.whL 0 24.829 7.082 > WhL.Inv.whL 1 46.039 8.598 > WhL.Inv.whL 10 240.963 21.108 > WhL.Inv.whL 100 2092.671 167.619 > > > > > >> Am 20.09.2016 um 21:54 schrieb John Rose : >> >> There should also be an assert in the new LF constructor, which ensures that the two >> arguments are congruent. Better yet, just supply one argument (the speciesData), >> and derive the MT. These new LFs are pretty confusing, and it's best to nail down >> unused degrees of freedom. >> >> ? John >> >> P.S. I would have expected this problem to be solved by having the MHI.toArray function >> return a box object with a single @Stable array field. Did that approach fail? >> >> I.e., this wrapper emulates a frozen array (until that happy day when we have real >> frozen arrays): >> >> class ArrayConstant { >> private final @Stable T[] values; >> public ArrayConstant(T[] values) { >> for (T v : values) Objects.requireNonNull(v); >> this.values = values.clone(); >> } >> public T get(int i) { return values[i]; } >> //public int length() { return values.length; } >> } >> >> The JIT should be able to constant fold through ac.get(i) whenever ac and i are constants. >> >> On Sep 20, 2016, at 8:17 AM, Vladimir Ivanov wrote: >>> >>> Looks good. >>> >>> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java: >>> + LambdaForm bmhArrayForm(MethodType type, BoundMethodHandle.SpeciesData speciesData) { >>> + int size = type.parameterCount(); >>> + Transform key = Transform.of(Transform.BMH_AS_ARRAY, size); >>> + LambdaForm form = getInCache(key); >>> + if (form != null) { >>> + return form; >>> + } >>> >>> Please, add an assert to ensure the cached LF has the same constraint as requested (speciesData). >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 9/20/16 3:53 PM, Michael Haupt wrote: >>>> Dear all, >>>> >>>> please review this change. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161211 >>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8161211/webrev.00/ >>>> >>>> The method handle loop combinators introduced with JEP 274 were originally not intrinsified, leading to poor performance as compared to a pure-Java baseline, but also to handwired method handle combinations. The intrinsics introduced with 8143211 [1] improved on the situation somewhat, but still did not provide good inlining opportunities for the JIT compiler. This change introduces a usage of BoundMethodHandles as arrays to carry the various handles involved in loop execution. >>>> >>>> Extra credits to Vladimir Ivanov, who suggested the BMH-as-arrays approach in the first place, and Claes Redestad, who suggested to use LambdaForm editing to neatly enable caching. Thanks! >>>> >>>> Performance improves considerably. The table below reports scores in ns/op. The "unpatched" column contains results from before applying the patch for 8161211; the "patched" column, from thereafter. >>>> >>>> The create benchmarks measure the cost of loop handle creation. The baseline and baselineMH benchmarks measure the cost of running a pure Java and handwired method handle construct. >>>> >>>> Relevant comparisons include loop combinator results versus baselines, and versus unpatched loop combinator results. For the latter, there are significant improvements, except for the creation benchmarks (creation has a more complex workflow now). For the former, it can be seen that the BMH-array intrinsics generally perform better than handwired handle constructs, and have moved much closer to. >>>> >>>> Thanks, >>>> >>>> Michael >>>> >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8143211 >>>> >>>> >>>> >>>> Benchmark (iterations) unpatched patched >>>> MethodHandlesCountedLoop.Create.create3 N/A 16039.108 18400.405 >>>> MethodHandlesCountedLoop.Create.create4 N/A 15621.959 17924.696 >>>> MethodHandlesCountedLoop.Invoke.baseline3 0 2.858 2.839 >>>> MethodHandlesCountedLoop.Invoke.baseline3 1 5.125 5.164 >>>> MethodHandlesCountedLoop.Invoke.baseline3 10 11.887 11.924 >>>> MethodHandlesCountedLoop.Invoke.baseline3 100 67.441 67.281 >>>> MethodHandlesCountedLoop.Invoke.baseline4 0 2.855 2.838 >>>> MethodHandlesCountedLoop.Invoke.baseline4 1 5.120 5.179 >>>> MethodHandlesCountedLoop.Invoke.baseline4 10 11.875 11.906 >>>> MethodHandlesCountedLoop.Invoke.baseline4 100 67.607 67.374 >>>> MethodHandlesCountedLoop.Invoke.baselineMH3 0 9.734 9.606 >>>> MethodHandlesCountedLoop.Invoke.baselineMH3 1 15.689 15.674 >>>> MethodHandlesCountedLoop.Invoke.baselineMH3 10 68.912 69.303 >>>> MethodHandlesCountedLoop.Invoke.baselineMH3 100 605.666 606.432 >>>> MethodHandlesCountedLoop.Invoke.baselineMH4 0 14.561 13.234 >>>> MethodHandlesCountedLoop.Invoke.baselineMH4 1 19.543 19.773 >>>> MethodHandlesCountedLoop.Invoke.baselineMH4 10 71.977 72.466 >>>> MethodHandlesCountedLoop.Invoke.baselineMH4 100 596.842 602.469 >>>> MethodHandlesCountedLoop.Invoke.countedLoop3 0 49.339 5.810 >>>> MethodHandlesCountedLoop.Invoke.countedLoop3 1 95.444 7.441 >>>> MethodHandlesCountedLoop.Invoke.countedLoop3 10 508.746 21.002 >>>> MethodHandlesCountedLoop.Invoke.countedLoop3 100 4701.808 145.996 >>>> MethodHandlesCountedLoop.Invoke.countedLoop4 0 49.443 5.798 >>>> MethodHandlesCountedLoop.Invoke.countedLoop4 1 98.721 7.438 >>>> MethodHandlesCountedLoop.Invoke.countedLoop4 10 503.825 21.049 >>>> MethodHandlesCountedLoop.Invoke.countedLoop4 100 4681.803 147.020 >>>> MethodHandlesDoWhileLoop.Create.create N/A 7628.312 9100.332 >>>> MethodHandlesDoWhileLoop.Invoke.baseline 1 3.868 3.909 >>>> MethodHandlesDoWhileLoop.Invoke.baseline 10 16.480 16.461 >>>> MethodHandlesDoWhileLoop.Invoke.baseline 100 144.260 144.232 >>>> MethodHandlesDoWhileLoop.Invoke.baselineMH 1 14.434 14.494 >>>> MethodHandlesDoWhileLoop.Invoke.baselineMH 10 92.542 93.454 >>>> MethodHandlesDoWhileLoop.Invoke.baselineMH 100 877.480 880.496 >>>> MethodHandlesDoWhileLoop.Invoke.doWhileLoop 1 26.791 7.153 >>>> MethodHandlesDoWhileLoop.Invoke.doWhileLoop 10 158.985 16.990 >>>> MethodHandlesDoWhileLoop.Invoke.doWhileLoop 100 1391.746 130.946 >>>> MethodHandlesIteratedLoop.Create.create N/A 13547.499 15478.542 >>>> MethodHandlesIteratedLoop.Invoke.baseline 0 2.973 2.980 >>>> MethodHandlesIteratedLoop.Invoke.baseline 1 6.771 6.658 >>>> MethodHandlesIteratedLoop.Invoke.baseline 10 14.955 14.955 >>>> MethodHandlesIteratedLoop.Invoke.baseline 100 81.842 82.582 >>>> MethodHandlesIteratedLoop.Invoke.baselineMH 0 14.893 14.668 >>>> MethodHandlesIteratedLoop.Invoke.baselineMH 1 20.998 21.304 >>>> MethodHandlesIteratedLoop.Invoke.baselineMH 10 73.677 72.703 >>>> MethodHandlesIteratedLoop.Invoke.baselineMH 100 613.913 614.475 >>>> MethodHandlesIteratedLoop.Invoke.iteratedLoop 0 33.583 9.603 >>>> MethodHandlesIteratedLoop.Invoke.iteratedLoop 1 82.239 14.433 >>>> MethodHandlesIteratedLoop.Invoke.iteratedLoop 10 448.356 38.650 >>>> MethodHandlesIteratedLoop.Invoke.iteratedLoop 100 4189.034 279.779 >>>> MethodHandlesLoop.Create.create N/A 15505.970 17559.399 >>>> MethodHandlesLoop.Invoke0.baseline 1 3.179 3.181 >>>> MethodHandlesLoop.Invoke0.baseline 10 5.952 6.115 >>>> MethodHandlesLoop.Invoke0.baseline 100 50.942 50.943 >>>> MethodHandlesLoop.Invoke0.loop 1 46.454 5.353 >>>> MethodHandlesLoop.Invoke0.loop 10 514.230 8.487 >>>> MethodHandlesLoop.Invoke0.loop 100 5166.251 52.188 >>>> MethodHandlesLoop.Invoke1.loop 1 34.321 5.277 >>>> MethodHandlesLoop.Invoke1.loop 10 430.839 8.481 >>>> MethodHandlesLoop.Invoke1.loop 100 4095.302 52.206 >>>> MethodHandlesTryFinally.baselineExceptional N/A 3.005 3.002 >>>> MethodHandlesTryFinally.baselineMHExceptional N/A 166.316 166.087 >>>> MethodHandlesTryFinally.baselineMHNormal N/A 9.337 9.276 >>>> MethodHandlesTryFinally.baselineNormal N/A 2.696 2.683 >>>> MethodHandlesTryFinally.create N/A 406.255 406.594 >>>> MethodHandlesTryFinally.invokeTryFinallyExceptional N/A 154.121 154.692 >>>> MethodHandlesTryFinally.invokeTryFinallyNormal N/A 5.350 5.334 >>>> MethodHandlesWhileLoop.Create.create N/A 12214.383 14503.515 >>>> MethodHandlesWhileLoop.Invoke.baseline 0 3.886 3.888 >>>> MethodHandlesWhileLoop.Invoke.baseline 1 5.379 5.377 >>>> MethodHandlesWhileLoop.Invoke.baseline 10 16.000 16.201 >>>> MethodHandlesWhileLoop.Invoke.baseline 100 142.066 143.338 >>>> MethodHandlesWhileLoop.Invoke.baselineMH 0 11.028 11.012 >>>> MethodHandlesWhileLoop.Invoke.baselineMH 1 21.269 21.159 >>>> MethodHandlesWhileLoop.Invoke.baselineMH 10 97.493 97.656 >>>> MethodHandlesWhileLoop.Invoke.baselineMH 100 887.579 886.532 >>>> MethodHandlesWhileLoop.Invoke.whileLoop 0 24.829 7.108 >>>> MethodHandlesWhileLoop.Invoke.whileLoop 1 46.039 8.573 >>>> MethodHandlesWhileLoop.Invoke.whileLoop 10 240.963 21.088 >>>> MethodHandlesWhileLoop.Invoke.whileLoop 100 2092.671 159.016 >>>> >>>> >>>> >> > From lance.andersen at oracle.com Fri Sep 23 17:11:21 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 23 Sep 2016 13:11:21 -0400 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> Message-ID: <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> Hi Roman, I made a pass through the webrev and overall, looks OK. Would be good to have Joe Wang take a look at the Catalog changes as an additional sanity check. I am a bit concerned where we reference jaxb.java.net as in the package.html given we are not sure where the project will end up based on the pending changes coming to java.net. For the specification, I would point to jcp.org vs java.net I am assuming the standalone TCKs in addition to the JCK are clean when run against these changes? HTH Best Lance > On Sep 23, 2016, at 6:39 AM, Roman Grigoriadi wrote: > > Hi, > > Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8164479 > Webrev: http://cr.openjdk.java.net/~aefimov/8164479/00/ > > You can find change list in the description of JBS and its linked issues. Most important is removal of code incompatible with JDK9 module system. > > With best regards, > Roman Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Fri Sep 23 20:29:18 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 23 Sep 2016 13:29:18 -0700 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> Message-ID: <57E5909E.3050702@oracle.com> On 9/23/16, 10:11 AM, Lance Andersen wrote: > Hi Roman, > > I made a pass through the webrev and overall, looks OK. Would be good to have Joe Wang take a look at the Catalog changes as an additional sanity check. They look good to me. The dev note in Options.java, // use Sun's "XML Entity and URI Resolvers" by Norman Walsh // to resolve external entities. - // http://www.sun.com/xml/developers/resolver/ + // https://xerces.apache.org/xml-commons/components/resolver/resolver-article.html The whole comment can be changed to: // use javax.xml.catalog to resolve external entities. Best, Joe > > I am a bit concerned where we reference jaxb.java.net as in the package.html given we are not sure where the project will end up based on the pending changes coming to java.net. For the specification, I would point to jcp.org vs java.net > > I am assuming the standalone TCKs in addition to the JCK are clean when run against these changes? > > HTH > > Best > Lance > >> On Sep 23, 2016, at 6:39 AM, Roman Grigoriadi wrote: >> >> Hi, >> >> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8164479 >> Webrev: http://cr.openjdk.java.net/~aefimov/8164479/00/ >> >> You can find change list in the description of JBS and its linked issues. Most important is removal of code incompatible with JDK9 module system. >> >> With best regards, >> Roman > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From Alan.Bateman at oracle.com Sat Sep 24 09:53:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 24 Sep 2016 10:53:47 +0100 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <57E5909E.3050702@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> Message-ID: Joe - do you mind also checking the list of of qualified exports declared in java.xml's module-info as I assume that some of these should be removed as part of this patch (particularly com.sun.org.apache.xml.internal.resolver and resolver.tools). -Alan On 23/09/2016 21:29, Joe Wang wrote: > > > On 9/23/16, 10:11 AM, Lance Andersen wrote: >> Hi Roman, >> >> I made a pass through the webrev and overall, looks OK. Would be >> good to have Joe Wang take a look at the Catalog changes as an >> additional sanity check. > > They look good to me. The dev note in Options.java, > // use Sun's "XML Entity and URI Resolvers" by Norman Walsh > // to resolve external entities. > - // http://www.sun.com/xml/developers/resolver/ > + // > https://xerces.apache.org/xml-commons/components/resolver/resolver-article.html > > The whole comment can be changed to: > > // use javax.xml.catalog to resolve external entities. > > Best, > Joe > >> >> I am a bit concerned where we reference jaxb.java.net as in the >> package.html given we are not sure where the project will end up >> based on the pending changes coming to java.net. For the >> specification, I would point to jcp.org vs java.net >> >> I am assuming the standalone TCKs in addition to the JCK are clean >> when run against these changes? >> >> HTH >> >> Best >> Lance >> >>> On Sep 23, 2016, at 6:39 AM, Roman >>> Grigoriadi wrote: >>> >>> Hi, >>> >>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8164479 >>> Webrev: http://cr.openjdk.java.net/~aefimov/8164479/00/ >>> >>> You can find change list in the description of JBS and its linked >>> issues. Most important is removal of code incompatible with JDK9 >>> module system. >>> >>> With best regards, >>> Roman >> >> >> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> From Alan.Bateman at oracle.com Sat Sep 24 10:02:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 24 Sep 2016 11:02:46 +0100 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies In-Reply-To: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> References: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> Message-ID: <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> On 23/09/2016 14:54, Sergei Kovalev wrote: > Hello team, > > Could you please review a very small fix that relates to tests only. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8166624 > Webrev: http://cr.openjdk.java.net/~skovalev/8166624/webrev.00/ "@modules java.compiler/javax.tools" looks odd, should this be simply "@modules java.compiler"? In any case, I would have thought that the modules list in mrjar/TEST.properties was enough to ensure these tests don't run when the runtime under test doesn't have jdk.jartool or jdk.compiler. But perhaps the motivation of the change is to make it more fine grained? -Alan From Alan.Bateman at oracle.com Sat Sep 24 10:08:49 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 24 Sep 2016 11:08:49 +0100 Subject: RFR(M): 8166560: [s390] Basic enablement of s390 port. In-Reply-To: References: Message-ID: <903643bb-9a78-5254-fd0e-108da29802bd@oracle.com> On 23/09/2016 06:52, Lindenmaier, Goetz wrote: > Hi, > > This change is part of the s390 port. It contains some basic adaptions needed for a full hotspot port for linux s390x. > > Out of curiosity, is there is JEP for the Linux/S390 port? There were JEPs for the Linux/AArch64 and PowerPC/AIX ports and just wondering if there is one coming for the S390 port too? -Alan From ben.manes at gmail.com Wed Sep 21 21:25:58 2016 From: ben.manes at gmail.com (Benjamin Manes) Date: Wed, 21 Sep 2016 14:25:58 -0700 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: My limited understanding is that the original API was only CompletableFuture and that CompletionStage introduced as a compromise. It did not appear to be an attempt to strictly follow an interface-implementation separation, e.g. collections. As you said #toCompletableFuture() may throw an UOE, which means some use-cases can't rely on CompletionState which limits its usefulness. In my case that would be an AsyncLoadingCache with a synchronous LoadingCache view. I think having to code that the resulting implementation would be worse if it called toCompletableFuture, caught the exception, and then adapted as you said. When the new future class was introduced it was stated, "In other words, we (j.u.c) are not now in a position to dictate a common interface for all SettableFuture, FutureValue, Promise, ListenableFuture, etc like APIs. And as we've seen, different audiences want/need different subsets of this API exposed as interfaces for their usages, and are in any case unlikely to want change all their existing interfaces. However, what we can do is provide a common underlying implementation that is as fast, scalable, space-conserving, carefully-specified, and reliable as possible. It should then be easy and attractive for others creating or reworking higher-level APIs to relay all functionality to the CompletableFuture implementation." - Doug Lea, '12 I've gradually come to terms using CF as part of an API and haven't experienced a downside yet. On Wed, Sep 21, 2016 at 1:43 PM, Martin Buchholz wrote: > (Sorry to re-open this discussion) > > The separation of a read-only CompletionStage from CompletableFuture is > great. I'm a fan of the scala style Promise/Future split as described in > http://docs.scala-lang.org/overviews/core/futures.html, but: we need to > re-add (safe, read-only) blocking methods like join. Java is not Node.js, > where there are no threads but there is a universal event loop. Java > programmers are used to Future, where the *only* way to use a future's > value is to block waiting for it. The existing CompletionStage methods are > a better scaling alternative to blocking all the time, but blocking is > almost always eventually necessary in Java. For example, junit test > methods that start any asynchronous computation need to block until the > computation is done, before returning. > > As Viktor has pointed out, users can always implement blocking themselves > by writing > > static CompletableFuture toCompletableFuture(CompletionStage > stage) { > CompletableFuture f = new CompletableFuture<>(); > stage.handle((T t, Throwable ex) -> { > if (ex != null) f.completeExceptionally(ex); > else f.complete(t); > return null; > }); > return f; > } > > static T join(CompletionStage stage) { > return toCompletableFuture(stage).join(); > } > > but unlike Viktor, I think it's unreasonable to not provide this for users > (especially when we can do so more efficiently). What is happening instead > is API providers not using CompletionStage as return values in public APIs > because of the lack of convenient blocking, and instead returning > CompletableFuture, which is a tragic software engineering failure. > > Re-adding join is easy. We discourage CompletionStage.toCompletableFuture > from throwing UnsupportedOperationException, and implement join as: > > public default T join() { return toCompletableFuture().join(); } > > There is a risk of multiple-inheritance conflict with Future if we add > e.g. isDone(), but there are no current plans to turn those Future methods > into default methods, and even if we did in some future release, it would > be only a source, not binary incompatibility, so far less serious. > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > From pavel.rappo at gmail.com Wed Sep 21 21:38:28 2016 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 21 Sep 2016 22:38:28 +0100 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On Wed, Sep 21, 2016 at 9:43 PM, Martin Buchholz wrote: > What is happening instead is API providers not using CompletionStage as > return values in public APIs because of the lack of convenient blocking, and > instead returning CompletableFuture, which is a tragic software engineering > failure. On Wed, Sep 21, 2016 at 10:25 PM, Benjamin Manes wrote: > I've gradually come to terms using CF as part of an API and haven't > experienced a downside yet. I agree with Benjamin and would like to hear more about how it's a "tragic software engineering failure". From james at lightbend.com Wed Sep 21 22:57:47 2016 From: james at lightbend.com (James Roper) Date: Thu, 22 Sep 2016 08:57:47 +1000 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On 22 September 2016 at 06:43, Martin Buchholz wrote: > What is happening instead is API providers not using CompletionStage as > return values in public APIs because of the lack of convenient blocking, > and instead returning CompletableFuture, which is a tragic software > engineering failure. > Out of interest, which APIs are returning CompletableFuture rather than CompletionStage? In the Play Framework Java API, we have embraced CompletionStage, we use it absolutely everywhere. Likewise in Lagom Framework and the Java API for Akka streams. When it comes to blocking, we strongly advocate never blocking (in the threading models of these projects, blocking on a future will make you very prone to deadlocks). But of course, the exception is junit tests, in that case, we encourage the use of CompletionStage.toCompletableFuture to block. In these projects, you'll generally encounter two different implementations of CompletionStage, one is CompletableFuture, the other is a scala.concurrent.Future backed implementation. Both implement toCompletableFuture. But a user that integrates a third party library with its own CompletionStage implementation of course may encounter issues, that said, I haven't yet seen many (or any?) libraries outside of our ecosystem that are embracing CompletionStage or CompletableFuture in their public APIs yet (this is probably due to my ignorance, not due to there not being any), which is part of why I'm interested in knowing what libraries you know of that are using it. Re-adding join is easy. We discourage CompletionStage.toCompletableFuture > from throwing UnsupportedOperationException, and implement join as: > > public default T join() { return toCompletableFuture().join(); } > > There is a risk of multiple-inheritance conflict with Future if we add > e.g. isDone(), but there are no current plans to turn those Future methods > into default methods, and even if we did in some future release, it would > be only a source, not binary incompatibility, so far less serious. > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > -- *James Roper* *Software Engineer* Lightbend ? Build reactive apps! Twitter: @jroper From james at lightbend.com Fri Sep 23 02:51:14 2016 From: james at lightbend.com (James Roper) Date: Fri, 23 Sep 2016 12:51:14 +1000 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On 23 September 2016 at 07:27, Martin Buchholz wrote: > Thanks for the lesson, James! > > I took a look at the Scala/Akka/LightBend world. Even there, blocking > always remains a possibility, even if discouraged, e.g. > scala.concurrent.Future extends Awaitable (!), and > http://doc.akka.io/docs/akka/snapshot/general/actor- > systems.html#Blocking_Needs_Careful_Management. > And any general purpose Java API needs to be useful outside of a framework. > Yes absolutely - personally I'm not against putting join on CompletionStage (I'm happy to leave the disagreement of this to Viktor), my main concern regarding CS/CF is encapsulation - if a library performs an asynchronous computation, that library should be able to safely return a future of that (using the term future here in the general sense) to clients and remain in control of it, without worrying about what the clients will do with it - the future should be effectively "immutable" from the clients perspective, that is to say, the client shouldn't be able to change it's behaviour at all. For example, we often cache futures and return them from a libraries API, if a client could cancel a future, that would break everything else that received that future. We'd rather not have to be in a situation where to build a resilient API, we have to "copy" every future before we return it, like APIs currently have to do with the Java collections API. > But of course, the exception is junit tests, in that case, we encourage >> the use of CompletionStage.toCompletableFuture to block. >> > > We're currently fixing jdk9 CompletableFuture.minimalCompletionStage().toCompletableFuture() > to be awaitable. > > To make toCompletableFuture().join() more reliable as a recommended way to > block, I think we should remove the encouragement to throw UOE from: > http://download.java.net/java/jdk9/docs/api/java/util/ > concurrent/CompletionStage.html#toCompletableFuture-- > > It sounds like the Akka/LightBend World is happy with current > CompletionStage API (may I call this the "actor purist API"?), while other > users will want a bigger, more general CompletableFuture subset for > consuming future values. Frustratingly, some of them will want cancel(), > some not; and we have no good names for any new interfaces; right now all I > can think of is CompletionStage2 and CompletionStage3 !) > > The current implementation of CompletableFuture has a "memory leak > problem" in that e.g. minimalStage().toCompletableFuture().isDone() will > leak a Completion object until the source stage itself is collected. Which > doesn't happen if e.g. a direct isDone() is provided. > JDK-8161600: Garbage retention when source CompletableFutures are never > completed > (but no one has ever complained!) > -- *James Roper* *Software Engineer* Lightbend ? Build reactive apps! Twitter: @jroper From viktor.klang at gmail.com Fri Sep 23 21:24:55 2016 From: viktor.klang at gmail.com (Viktor Klang) Date: Fri, 23 Sep 2016 23:24:55 +0200 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: Hi Martin, *Unsurprisingly*, I think it is a bad idea to pollute something which was created as a non-blocking superset intended to provide maximum utility with minimum of sharp edges. However, I think you have a point in that toCompletableFuture throwing UOE is rather unhelpful, and if some people are huge fans of parking threads then let's see if we can come to terms on a solution which doesn't compromise the solution for everyone else. The subject of this thread, "We need to add blocking methods to CompletionStage!", gave me a few questions: "who is 'we'?", "when do we need blocking methods?" and "Why is CompletionStage the right place to add this?" I think it's great that you point out that Scala's Future (full disclosure: I am a co-designer of that) extends the Awaitable[1] trait (think interface). It is worth pointing out that those methods are not callable on the instance directly (notice the implicit evidence type) so all invocations need to go through an external construct, Await, which makes it abundantly clear that something different is going to happen. I wrote a long explanation of the design process (at least parts of it) here[2], but I'm including the relevant section on Await below: There?s an underlying question that I think is worth answering: ?Why does Await.result exist, and why doesn?t it exist *on* Future?? When we designed Scala?s Future one thing we based it on was the experience with Akka Future ( http://doc.akka.io/api/akka/1.3.1/?_ga=1.21043707.1579561034.1353497989#akka.dispatch.Future ) Note how it had `get` and `await` methods, which do similar things as the C# `Result` method ? block the currently executing Thread from progressing until the value is available. Such a method is the counterpart to asynchronous, it is synchronizing the current Thread with the Thread which executes the Future ? i.e. an API for synchronous programming. Not only did we find that methods like that introduce performance problems due to blocking Threads (delay until the value is available but also due to Thread scheduler wakeup lag), but these methods also produce programs that are difficult to reason about since they can deadlock and become non-deterministic in their runtime behavior as things like GC-pauses etc may cause either spurious failures (where timeouts are supplied) or prolonged resource starvation due to unavailability of Threads to execute other logic. Having a single method for performing these potentially dangerous operations and putting it outside of the Future API itself meant that it is easy to spot where blocking is performed as well as easy to outlaw it (by disallowing it to be present in source code). But we also took it a step further, by creating the BlockContext mechanism we also made it possible to the runtime to perform evasive manoeuvres in the presence of blocking. ( http://www.scala-lang.org/api/current/index.html#scala.concurrent.BlockContext ) *Option 1:* Now, if Java's type system was just a tad more powerful, it would support intersection types and APIs expressing the problem of wanting to expose more than CompletionStage but less than the concrete CompletableFuture type could very easily return `*CompletionStage[T] with Future[T]*`. Now we don't really have that, so it needs to be poorly emulated using compound interfaces, becoming something like `*FutureCompletionStage[T]*` which would have the `join`-method on Future. And that may actually not be a bad idea at all. So let's call that *Option 1.* *Option 2:* Add a `toFuture` method to CompletionStage such that if you want to go and use the blocking methods of Future, it is both shorter and does not expose a concrete type in the signature. *Futher proposals:* * Adding a constructor to `CompletableFuture` which takes a `CompletionStage` as parameter would make the boilerplate discussed earlier[3] obsolete. * I'd like to see if we could make the `toCompletableFuture` be a default method which delegates to `new CompletableFuture<>(this)`, meaning that the UOE problem would sort of solvable. *Summary:* * I think there is already a great place to host blocking methods: j.u.c.Future * We can get around the UOE by introducing the constructor on CompletableFuture both as a fallback to things which do throw UOE on toCompletableFuture, but also provides a terrific default implementation for toCompletableFuture. * We can introduce a toFuture-method with a default implementation which calls `new CompletableFuture<>(this)` Have a great weekend! *Footnotes:* 1: http://www.scala-lang.org/files/archive/api/2.11.8/index.html#scala.concurrent.Awaitable 2: https://medium.com/@viktorklang/hi-eef4acf316a8#.uesy1fqgo 3: static CompletableFuture toCompletableFuture(CompletionStage stage) { ? } PS. As a sidenote, Martin, and in all friendliness, "actor purist API"? C'mon, I know you're better than that! CompletionStage's design has nothing to do with Actors and if Single Responsibility Principle is considered purism then I'm not sure why we don't have a single interface with all methods in it. Let's try to keep things friendly. PPS: A misunderstanding is that CompletionStage represents a running task of sorts, one that can be cancelled etc. This is not the case. PPPS: Adding blocking methods without mandatory timeouts has in practice proven to be a recipe for disaster. PPPPS: "I think it's unreasonable to not provide this for users (especially when we can do so more efficiently)." <- If efficiency is desired then blocking is definitely not the right solution. PPPPPS: I'm currently moving cross-country so there will be delays of any responses from me On Wed, Sep 21, 2016 at 10:43 PM, Martin Buchholz wrote: > (Sorry to re-open this discussion) > > The separation of a read-only CompletionStage from CompletableFuture is > great. I'm a fan of the scala style Promise/Future split as described in > http://docs.scala-lang.org/overviews/core/futures.html, but: we need to > re-add (safe, read-only) blocking methods like join. Java is not Node.js, > where there are no threads but there is a universal event loop. Java > programmers are used to Future, where the *only* way to use a future's > value is to block waiting for it. The existing CompletionStage methods are > a better scaling alternative to blocking all the time, but blocking is > almost always eventually necessary in Java. For example, junit test > methods that start any asynchronous computation need to block until the > computation is done, before returning. > > As Viktor has pointed out, users can always implement blocking themselves > by writing > > static CompletableFuture toCompletableFuture(CompletionStage > stage) { > CompletableFuture f = new CompletableFuture<>(); > stage.handle((T t, Throwable ex) -> { > if (ex != null) f.completeExceptionally(ex); > else f.complete(t); > return null; > }); > return f; > } > > static T join(CompletionStage stage) { > return toCompletableFuture(stage).join(); > } > > but unlike Viktor, I think it's unreasonable to not provide this for users > (especially when we can do so more efficiently). What is happening instead > is API providers not using CompletionStage as return values in public APIs > because of the lack of convenient blocking, and instead returning > CompletableFuture, which is a tragic software engineering failure. > > Re-adding join is easy. We discourage CompletionStage.toCompletableFuture > from throwing UnsupportedOperationException, and implement join as: > > public default T join() { return toCompletableFuture().join(); } > > There is a risk of multiple-inheritance conflict with Future if we add > e.g. isDone(), but there are no current plans to turn those Future methods > into default methods, and even if we did in some future release, it would > be only a source, not binary incompatibility, so far less serious. > -- Cheers, ? From mandy.chung at oracle.com Sat Sep 24 17:57:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 24 Sep 2016 10:57:55 -0700 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> Message-ID: <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> You can run jdeps --check java.xml.ws on your local build with this change. This will analyze the dependences and any unused qualified exports. Mandy > On Sep 24, 2016, at 2:53 AM, Alan Bateman wrote: > > Joe - do you mind also checking the list of of qualified exports declared in java.xml's module-info as I assume that some of these should be removed as part of this patch (particularly com.sun.org.apache.xml.internal.resolver and resolver.tools). > > -Alan > > > On 23/09/2016 21:29, Joe Wang wrote: >> >> >> On 9/23/16, 10:11 AM, Lance Andersen wrote: >>> Hi Roman, >>> >>> I made a pass through the webrev and overall, looks OK. Would be good to have Joe Wang take a look at the Catalog changes as an additional sanity check. >> >> They look good to me. The dev note in Options.java, >> // use Sun's "XML Entity and URI Resolvers" by Norman Walsh >> // to resolve external entities. >> - // http://www.sun.com/xml/developers/resolver/ >> + // https://xerces.apache.org/xml-commons/components/resolver/resolver-article.html >> >> The whole comment can be changed to: >> >> // use javax.xml.catalog to resolve external entities. >> >> Best, >> Joe >> >>> >>> I am a bit concerned where we reference jaxb.java.net as in the package.html given we are not sure where the project will end up based on the pending changes coming to java.net. For the specification, I would point to jcp.org vs java.net >>> >>> I am assuming the standalone TCKs in addition to the JCK are clean when run against these changes? >>> >>> HTH >>> >>> Best >>> Lance >>> >>>> On Sep 23, 2016, at 6:39 AM, Roman Grigoriadi wrote: >>>> >>>> Hi, >>>> >>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8164479 >>>> Webrev: http://cr.openjdk.java.net/~aefimov/8164479/00/ >>>> >>>> You can find change list in the description of JBS and its linked issues. Most important is removal of code incompatible with JDK9 module system. >>>> >>>> With best regards, >>>> Roman >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> > From martinrb at google.com Sat Sep 24 20:41:46 2016 From: martinrb at google.com (Martin Buchholz) Date: Sat, 24 Sep 2016 13:41:46 -0700 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: No one is suggesting we add cancel to CompletionStage - I agree that would break users, by making an immutable interface mutable. This also means that CompletionStage cannot extend Future. I also would not want to have a toFuture method that would return a j.u.c.Future, because of misfit Future.cancel. If we are adding cancel, then it will be to make a new interface, such as the suggested CancellableCompletionStage. I also agree that CompletionStage does *not* represent "a running task of sorts", j.u.c. Future specs are still confusing in that way due to FutureTask heritage. On Thu, Sep 22, 2016 at 7:51 PM, James Roper wrote: > For example, we often cache futures and return them from a libraries API, > if a client could cancel a future, that would break everything else that > received that future. On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang wrote: > PPS: A misunderstanding is that CompletionStage represents a running task > of sorts, one that can be cancelled etc. This is not the case. > From davidcholmes at aapt.net.au Sun Sep 25 11:45:44 2016 From: davidcholmes at aapt.net.au (David Holmes) Date: Sun, 25 Sep 2016 21:45:44 +1000 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> I think that was meant to read ?After this method returns _true_, subsequent calls ?? David From: Concurrency-interest [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Viktor Klang Sent: Sunday, September 25, 2016 9:03 PM To: Martin Buchholz Cc: concurrency-interest ; core-libs-dev Subject: Re: [concurrency-interest] We need to add blocking methods to CompletionStage! On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang > wrote: On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz > wrote: No one is suggesting we add cancel to CompletionStage - I agree that would break users, by making an immutable interface mutable. +10000 This also means that CompletionStage cannot extend Future. +10000 I also would not want to have a toFuture method that would return a j.u.c.Future, because of misfit Future.cancel. Would you mind elaborating here? According to the cancel method spec on Future it is completely fine for it to be a no-op which always returns false: "This attempt will fail if the task has already completed, has already been cancelled, or could not be cancelled for some other reason." Source: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html There's an interesting (read: weird) spec clause in cancel: "After this method returns, subsequent calls to isDone() will always return true. Subsequent calls to isCancelled() will always return true if this method returned true." That clause is in contradiction with the previously quoted line. If we are adding cancel, then it will be to make a new interface, such as the suggested CancellableCompletionStage. I also agree that CompletionStage does *not* represent "a running task of sorts", j.u.c. Future specs are still confusing in that way due to FutureTask heritage. +10000 On Thu, Sep 22, 2016 at 7:51 PM, James Roper > wrote: For example, we often cache futures and return them from a libraries API, if a client could cancel a future, that would break everything else that received that future. On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang > wrote: PPS: A misunderstanding is that CompletionStage represents a running task of sorts, one that can be cancelled etc. This is not the case. -- Cheers, ? -- Cheers, ? From sergei.kovalev at oracle.com Sun Sep 25 12:53:38 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Sun, 25 Sep 2016 15:53:38 +0300 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies In-Reply-To: <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> References: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> Message-ID: <8a56f878-ee4b-0996-1d68-543d0aff90fe@oracle.com> Hi Alan, The modules list in mrar/TEST.properties guarantee that jtreg add "--add-module @modules" command line option during test execution. If you create custom JRE that does not contains the modules, the tests fails. The proposed fix guarantee that jtreg skips the tests if no listed modules found. 24.09.16 13:02, Alan Bateman wrote: > On 23/09/2016 14:54, Sergei Kovalev wrote: > >> Hello team, >> >> Could you please review a very small fix that relates to tests only. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8166624 >> Webrev: http://cr.openjdk.java.net/~skovalev/8166624/webrev.00/ > "@modules java.compiler/javax.tools" looks odd, should this be simply > "@modules java.compiler"? > > In any case, I would have thought that the modules list in > mrjar/TEST.properties was enough to ensure these tests don't run when > the runtime under test doesn't have jdk.jartool or jdk.compiler. But > perhaps the motivation of the change is to make it more fine grained? > > -Alan -- With best regards, Sergei From viktor.klang at gmail.com Sun Sep 25 14:34:12 2016 From: viktor.klang at gmail.com (Viktor Klang) Date: Sun, 25 Sep 2016 16:34:12 +0200 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> Message-ID: If that truely is the case then the only way of implementing a readonly Future is by throwing an exception from cancel... -- Cheers, ? On Sep 25, 2016 4:20 PM, "Joe Bowbeer" wrote: > This statement regarding what happens after cancel is called is correct: > > "*After this method returns, subsequent calls to **isDone**() will always > return true*. Subsequent calls to isCancelled() will always return true > if this method returned true." > > After cancel returns, the future is completed, hence isDone. If cancel > returns true, i.e. it was cancelled, then isCancelled returns true. But, > for example if the future is already completed when cancel is called, then > cancel will return false and isCancelled will return false. > > On Sep 25, 2016 6:49 AM, "David Holmes" wrote: > >> I think that was meant to read ?After this method returns _*true*_, >> subsequent calls ?? >> >> >> >> David >> >> >> >> *From:* Concurrency-interest [mailto:concurrency-interest-b >> ounces at cs.oswego.edu] *On Behalf Of *Viktor Klang >> *Sent:* Sunday, September 25, 2016 9:03 PM >> *To:* Martin Buchholz >> *Cc:* concurrency-interest ; >> core-libs-dev >> *Subject:* Re: [concurrency-interest] We need to add blocking methods to >> CompletionStage! >> >> >> >> >> >> >> >> On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang >> wrote: >> >> >> >> >> >> On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz >> wrote: >> >> No one is suggesting we add cancel to CompletionStage - I agree that >> would break users, by making an immutable interface mutable. >> >> >> >> +10000 >> >> >> >> This also means that CompletionStage cannot extend Future. >> >> >> >> +10000 >> >> >> >> I also would not want to have a toFuture method that would return a >> j.u.c.Future, because of misfit Future.cancel. >> >> >> >> Would you mind elaborating here? According to the cancel method spec on >> Future it is completely fine for it to be a no-op which always returns >> false: >> >> >> >> "This attempt will fail if the task has already completed, has already >> been cancelled, *or could not be cancelled for some other reason.*" >> >> >> >> Source: https://docs.oracle.com/javase/8/docs/api/java/util/concurre >> nt/Future.html >> >> >> >> There's an interesting (read: weird) spec clause in cancel: >> >> >> >> "*After this method returns, subsequent calls to isDone() will always >> return true*. Subsequent calls to isCancelled() will always return true >> if this method returned true." >> >> >> >> That clause is in contradiction with the previously quoted line. >> >> >> >> >> >> >> >> >> >> If we are adding cancel, then it will be to make a new interface, such >> as the suggested CancellableCompletionStage. >> >> >> >> I also agree that CompletionStage does *not* represent "a running task of >> sorts", j.u.c. Future specs are still confusing in that way due to >> FutureTask heritage. >> >> >> >> +10000 >> >> >> >> >> >> On Thu, Sep 22, 2016 at 7:51 PM, James Roper wrote: >> >> For example, we often cache futures and return them from a libraries API, >> if a client could cancel a future, that would break everything else that >> received that future. >> >> >> >> On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang >> wrote: >> >> PPS: A misunderstanding is that CompletionStage represents a running task >> of sorts, one that can be cancelled etc. This is not the case. >> >> >> >> >> >> >> >> >> >> -- >> >> Cheers, >> >> ? >> >> >> >> >> >> -- >> >> Cheers, >> >> ? >> >> _______________________________________________ >> Concurrency-interest mailing list >> Concurrency-interest at cs.oswego.edu >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> >> From Alan.Bateman at oracle.com Sun Sep 25 14:48:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 25 Sep 2016 15:48:36 +0100 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies In-Reply-To: <8a56f878-ee4b-0996-1d68-543d0aff90fe@oracle.com> References: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> <8a56f878-ee4b-0996-1d68-543d0aff90fe@oracle.com> Message-ID: On 25/09/2016 13:53, Sergei Kovalev wrote: > Hi Alan, > > The modules list in mrar/TEST.properties guarantee that jtreg add > "--add-module @modules" command line option during test execution. If > you create custom JRE that does not contains the modules, the tests > fails. The proposed fix guarantee that jtreg skips the tests if no > listed modules found. Are you sure about this? I believe the original intent was that jtreg would select the test to run when the runtime has the required modules (@modules just overrides the value of "modules" that is read from TEST.properties). In any case, it should be "@modules java.compiler", no need to include /javax.tools because that package is exported. -Alan From Alan.Bateman at oracle.com Sun Sep 25 14:49:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 25 Sep 2016 15:49:42 +0100 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> Message-ID: <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> On 24/09/2016 18:57, Mandy Chung wrote: > You can run jdeps --check java.xml.ws on your local build with this change. > > This will analyze the dependences and any unused qualified exports. > Good idea. I think java.activation's module-info.java will need updating too as it no longer requires java.desktop (we can decide at a later time whether to change this to `requires static` and change this code to use a reflection guard + static reference). -Alan From sergei.kovalev at oracle.com Sun Sep 25 15:05:26 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Sun, 25 Sep 2016 18:05:26 +0300 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies In-Reply-To: References: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> <8a56f878-ee4b-0996-1d68-543d0aff90fe@oracle.com> Message-ID: <6ab8113e-9e34-5192-ed03-26e2eb272be3@oracle.com> Hi Alan, Here is the result of one of the tests run in initial state (no fix applied) 1) no module limitation jtreg -jdk:/home/skovalev/TRASH/jdk-9 -verbose:all /home/skovalev/repos/jake/jdk/test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java TEST RESULT: Passed. Execution successful 2) limit modules java.base jtreg -jdk:/home/skovalev/jdk-9 -verbose:all -javaoptions:"--limit-modules java.base" /home/skovalev/repos/jake/jdk/test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java STDOUT: Error occurred during initialization of VM java.lang.module.ResolutionException: Module java.compiler not found, required by jdk.compiler at java.lang.module.Resolver.fail(java.base at 9-ea/Resolver.java:790) at java.lang.module.Resolver.resolve(java.base at 9-ea/Resolver.java:138) at java.lang.module.Resolver.resolveRequires(java.base at 9-ea/Resolver.java:108) at java.lang.module.Configuration.resolveRequiresAndUses(java.base at 9-ea/Configuration.java:370) at java.lang.module.ModuleDescriptor$1.resolveRequiresAndUses(java.base at 9-ea/ModuleDescriptor.java:1986) at jdk.internal.module.ModuleBootstrap.boot(java.base at 9-ea/ModuleBootstrap.java:263) at java.lang.System.initPhase2(java.base at 9-ea/System.java:1927) 3) In case I limiting modules java.base and jdk.compiler only (with modified TEST.prioperties) jtreg -jdk:/home/skovalev/jdk-9 -verbose:all -javaoptions:"--limit-modules java.base,jdk.compiler" /home/skovalev/repos/jdk9-dev/jdk/test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java config MultiReleaseJarAPI.initialize(): failure java.lang.NoClassDefFoundError: jdk/security/jarsigner/JarSigner$Builder at CreateMultiReleaseTestJars.buildSignedMultiReleaseJar(CreateMultiReleaseTestJars.java:147) at MultiReleaseJarAPI.initialize(MultiReleaseJarAPI.java:74) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:535) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:515) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:216) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:143) at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:178) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:184) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:535) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) 25.09.16 17:48, Alan Bateman wrote: > On 25/09/2016 13:53, Sergei Kovalev wrote: > >> Hi Alan, >> >> The modules list in mrar/TEST.properties guarantee that jtreg add >> "--add-module @modules" command line option during test execution. If >> you create custom JRE that does not contains the modules, the tests >> fails. The proposed fix guarantee that jtreg skips the tests if no >> listed modules found. > Are you sure about this? I believe the original intent was that jtreg > would select the test to run when the runtime has the required modules > (@modules just overrides the value of "modules" that is read from > TEST.properties). > > In any case, it should be "@modules java.compiler", no need to include > /javax.tools because that package is exported. > > -Alan -- With best regards, Sergei From Alan.Bateman at oracle.com Sun Sep 25 15:13:04 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 25 Sep 2016 16:13:04 +0100 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies In-Reply-To: <6ab8113e-9e34-5192-ed03-26e2eb272be3@oracle.com> References: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> <8a56f878-ee4b-0996-1d68-543d0aff90fe@oracle.com> <6ab8113e-9e34-5192-ed03-26e2eb272be3@oracle.com> Message-ID: <3ae62448-9d2c-ba7f-3d1d-a54a91ef5725@oracle.com> On 25/09/2016 16:05, Sergei Kovalev wrote: > Hi Alan, > > Here is the result of one of the tests run in initial state (no fix > applied) For #2 and #3 then jtreg should ignore the test because they require jdk.compiler and jdk.jartool (declared in TEST.properties). This is why I'm wondering if we have a jtreg issue here. As I said, I don't have any issue working around this with the @modules that you propose but you can drop "/javax.tools" as it is not needed. -Alan From sergei.kovalev at oracle.com Sun Sep 25 15:16:00 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Sun, 25 Sep 2016 18:16:00 +0300 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies In-Reply-To: <3ae62448-9d2c-ba7f-3d1d-a54a91ef5725@oracle.com> References: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> <8a56f878-ee4b-0996-1d68-543d0aff90fe@oracle.com> <6ab8113e-9e34-5192-ed03-26e2eb272be3@oracle.com> <3ae62448-9d2c-ba7f-3d1d-a54a91ef5725@oracle.com> Message-ID: <422cf7fd-6975-d195-8ea7-aeae9f1f1a65@oracle.com> If I've drop jdk.jartool, I faced with ClassNotFound error as I showed in #3 java.lang.ClassNotFoundException: jdk.security.jarsigner.JarSigner$Builder As you can see TEST.properties contains both: jdk.compiler and jdk.jartool 25.09.16 18:13, Alan Bateman wrote: > On 25/09/2016 16:05, Sergei Kovalev wrote: > >> Hi Alan, >> >> Here is the result of one of the tests run in initial state (no fix >> applied) > For #2 and #3 then jtreg should ignore the test because they require > jdk.compiler and jdk.jartool (declared in TEST.properties). This is > why I'm wondering if we have a jtreg issue here. As I said, I don't > have any issue working around this with the @modules that you propose > but you can drop "/javax.tools" as it is not needed. > > -Alan -- With best regards, Sergei From martinrb at google.com Sun Sep 25 20:01:27 2016 From: martinrb at google.com (Martin Buchholz) Date: Sun, 25 Sep 2016 13:01:27 -0700 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> Message-ID: On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang wrote: > If that truely is the case then the only way of implementing a readonly > Future is by throwing an exception from cancel... > We the maintainers of j.u.c.Future have always thought that canceling a Future will surely leave it completed. Of course, implementers of any Java interface can choose to throw UOE for any method, but this is not intended for Future.cancel. An interface without cancel probably should not be extending Future. --- Here's another way to think of the range of functionality between current CompletionStage and current CompletableFuture: - Add Polling methods from scala Future such as isCompleted These are also discouraged, but less so than Await methods """Note: using this method yields nondeterministic dataflow programs.""" Will adding these to CompletionStage be less controversial? - Add Await blocking methods (that in scala cannot be called directly, using the CanAwait mechanism) - Add cancellation - Add other methods to complete the future ("Promise") - Add the full CompletableFuture API, including the obtrude methods Cancellation is interesting, because it's a mutating method, and so cannot be used with a future shared with other users, but it also seems very reasonable as a "client" operation. One can think of obtaining a non-shared future as a subscription to a one-time event, and that subscription takes up resources in the form of an object. If the client is no longer interested in the event, then cancellation of the future can free up resources. I'm still thinking of what Process.onExit should return. There's a tension between the various roles that CompletableFuture serves - as a container to write a value, as a possibly cancellable subscription to that value, and as a way to chain async computations together. On Wed, Sep 21, 2016 at 2:25 PM, Benjamin Manes wrote: > I've gradually come to terms using CF as part of an API and haven't > experienced a downside yet. > Hmmmm.... I seem to be moving in that direction as well... From davidcholmes at aapt.net.au Sun Sep 25 21:22:00 2016 From: davidcholmes at aapt.net.au (David Holmes) Date: Mon, 26 Sep 2016 07:22:00 +1000 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> Message-ID: <030e01d21772$dbe934d0$93bb9e70$@aapt.net.au> Joe, That is ignoring the error case. If the cancel fails then it is not complete and it is not cancelled. We added the extra wording back in August 2005. It is interesting to note that Martin?s initial query then only related to the state of the thread, but that it was clear about things only happening if cancel returned true: ?My guess is that if cancel(true) returns true, then subsequent cals to isCancelled() and isDone() will return true, *even if the thread executing the task is still running*? Yet we somehow added the clarification with no regard as to whether cancel returned true or not. That seems wrong. David From: Concurrency-interest [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Joe Bowbeer Sent: Monday, September 26, 2016 12:20 AM To: David Holmes Cc: Martin Buchholz ; concurrency-interest ; core-libs-dev Subject: Re: [concurrency-interest] We need to add blocking methods to CompletionStage! This statement regarding what happens after cancel is called is correct: "After this method returns, subsequent calls to isDone() will always return true. Subsequent calls to isCancelled() will always return true if this method returned true." After cancel returns, the future is completed, hence isDone. If cancel returns true, i.e. it was cancelled, then isCancelled returns true. But, for example if the future is already completed when cancel is called, then cancel will return false and isCancelled will return false. On Sep 25, 2016 6:49 AM, "David Holmes" > wrote: I think that was meant to read ?After this method returns _true_, subsequent calls ?? David From: Concurrency-interest [mailto:concurrency-interest-bounces at cs.oswego.edu ] On Behalf Of Viktor Klang Sent: Sunday, September 25, 2016 9:03 PM To: Martin Buchholz > Cc: concurrency-interest >; core-libs-dev > Subject: Re: [concurrency-interest] We need to add blocking methods to CompletionStage! On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang > wrote: On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz > wrote: No one is suggesting we add cancel to CompletionStage - I agree that would break users, by making an immutable interface mutable. +10000 This also means that CompletionStage cannot extend Future. +10000 I also would not want to have a toFuture method that would return a j.u.c.Future, because of misfit Future.cancel. Would you mind elaborating here? According to the cancel method spec on Future it is completely fine for it to be a no-op which always returns false: "This attempt will fail if the task has already completed, has already been cancelled, or could not be cancelled for some other reason." Source: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html There's an interesting (read: weird) spec clause in cancel: "After this method returns, subsequent calls to isDone() will always return true. Subsequent calls to isCancelled() will always return true if this method returned true." That clause is in contradiction with the previously quoted line. If we are adding cancel, then it will be to make a new interface, such as the suggested CancellableCompletionStage. I also agree that CompletionStage does *not* represent "a running task of sorts", j.u.c. Future specs are still confusing in that way due to FutureTask heritage. +10000 On Thu, Sep 22, 2016 at 7:51 PM, James Roper > wrote: For example, we often cache futures and return them from a libraries API, if a client could cancel a future, that would break everything else that received that future. On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang > wrote: PPS: A misunderstanding is that CompletionStage represents a running task of sorts, one that can be cancelled etc. This is not the case. -- Cheers, ? -- Cheers, ? _______________________________________________ Concurrency-interest mailing list Concurrency-interest at cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest From martinrb at google.com Sun Sep 25 21:49:23 2016 From: martinrb at google.com (Martin Buchholz) Date: Sun, 25 Sep 2016 14:49:23 -0700 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang wrote: > > PS. As a sidenote, Martin, and in all friendliness, "actor purist API"? > C'mon, I know you're better than that! CompletionStage's design has nothing > to do with Actors and if Single Responsibility Principle is considered > purism then I'm not sure why we don't have a single interface with all > methods in it. > Let's try to keep things friendly. > Let's be best friends! The programming profession is still learning how to write concurrent programs, fumbling in the dark, and that's particularly true for myself! There are competing approaches and we don't know which will prove successful. PPPS: Adding blocking methods without mandatory timeouts has in practice > proven to be a recipe for disaster. > Hmmmm... By design, Unix processes that create subprocesses should dedicate a thread for each subprocess, that waits indefinitely in waitpid. Linux kernel folks deliberately decided this was fine. In the Real World, one needs to interface with Other Peoples' APIs. Software that rarely blocks is a great idea. Especially the folks who write network server infrastructure increasingly agree. But it is truly a difficult paradigm shift; we will get there slowly. --- Say you are implementing some existing function with a traditional synchronous API. Your implementation is multi-threaded, but that's an implementation detail. Before you return to the caller, you must wait for the various parts of your computation to complete (the "join" part of fork/join). It seems reasonable to wait forever. If some part of your computation is interacting with an unreliable external resource, then it makes sense for that particular "wait" (which need not occupy a thread) to have a timeout. Test methods, main methods and unix process reapers are all examples where it's reasonable to block forever. > PPPPS: "I think it's unreasonable to not provide this for users > (especially when we can do so more efficiently)." <- If efficiency is > desired then blocking is definitely not the right solution. > What about efficiently providing isComplete? The result may already be available without actually blocking. It may even be known to be available immediately. One would like to get the value without additional allocation. From aleksej.efimov at oracle.com Sun Sep 25 23:41:33 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Mon, 26 Sep 2016 02:41:33 +0300 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> Message-ID: <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> Hi Alan, Joe, Mandy, Roman, Suggested changes to the comment section (will bring this change to standalone JAXB) and to the exported internal API were made: com.sun.xml.internal.stream.writers, com.sun.org.apache.xml.internal.resolver, com.sun.org.apache.xml.internal.resolver.tools dependencies were removed. The updated webrev: http://cr.openjdk.java.net/~aefimov/8164479/01 Best Regards, Aleksej On 25/09/16 17:49, Alan Bateman wrote: > On 24/09/2016 18:57, Mandy Chung wrote: > >> You can run jdeps --check java.xml.ws on your local build with this >> change. >> >> This will analyze the dependences and any unused qualified exports. >> > Good idea. I think java.activation's module-info.java will need > updating too as it no longer requires java.desktop (we can decide at a > later time whether to change this to `requires static` and change this > code to use a reflection guard + static reference). > > -Alan From lance.andersen at oracle.com Mon Sep 26 00:00:27 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 25 Sep 2016 20:00:27 -0400 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> Message-ID: Hi Aleks, I still would suggest not pointing at jaxb.java.net for the specification given these projects are going to have to migrate elsewhere. Best Lance > On Sep 25, 2016, at 7:41 PM, Aleks Efimov wrote: > > Hi Alan, Joe, Mandy, Roman, > > Suggested changes to the comment section (will bring this change to standalone JAXB) and to the exported internal API were made: > com.sun.xml.internal.stream.writers, com.sun.org.apache.xml.internal.resolver, com.sun.org.apache.xml.internal.resolver.tools dependencies were removed. > > The updated webrev: > http://cr.openjdk.java.net/~aefimov/8164479/01 > > Best Regards, > Aleksej > > > On 25/09/16 17:49, Alan Bateman wrote: >> On 24/09/2016 18:57, Mandy Chung wrote: >> >>> You can run jdeps --check java.xml.ws on your local build with this change. >>> >>> This will analyze the dependences and any unused qualified exports. >>> >> Good idea. I think java.activation's module-info.java will need updating too as it no longer requires java.desktop (we can decide at a later time whether to change this to `requires static` and change this code to use a reflection guard + static reference). >> >> -Alan > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Mon Sep 26 00:39:32 2016 From: martinrb at google.com (Martin Buchholz) Date: Sun, 25 Sep 2016 17:39:32 -0700 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: <030e01d21772$dbe934d0$93bb9e70$@aapt.net.au> References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> <030e01d21772$dbe934d0$93bb9e70$@aapt.net.au> Message-ID: On Sun, Sep 25, 2016 at 2:22 PM, David Holmes wrote: > > Yet we somehow added the clarification with no regard as to whether cancel > returned true or not. That seems wrong. > Yikes! I had always assumed that cancel was not permitted to leave the Future incomplete, perhaps influenced by the wording, """After this method returns, subsequent calls to {@link #isDone} will always return {@code true}.""" It's much more in the spirit of Java to throw an exception if the future cannot be completed. It's never come up, I think. From Alan.Bateman at oracle.com Mon Sep 26 07:06:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Sep 2016 08:06:02 +0100 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies In-Reply-To: <422cf7fd-6975-d195-8ea7-aeae9f1f1a65@oracle.com> References: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> <8a56f878-ee4b-0996-1d68-543d0aff90fe@oracle.com> <6ab8113e-9e34-5192-ed03-26e2eb272be3@oracle.com> <3ae62448-9d2c-ba7f-3d1d-a54a91ef5725@oracle.com> <422cf7fd-6975-d195-8ea7-aeae9f1f1a65@oracle.com> Message-ID: <2e3bb0dd-4e10-4bb4-1917-c2b8c2312034@oracle.com> On 25/09/2016 16:16, Sergei Kovalev wrote: > If I've drop jdk.jartool, I faced with ClassNotFound error as I showed > in #3 > > java.lang.ClassNotFoundException: > jdk.security.jarsigner.JarSigner$Builder > > As you can see TEST.properties contains both: jdk.compiler and > jdk.jartool I didn't suggesting dropping jdk.jartool, I was suggesting changing "@module java.compiler/javax.tools" to "@modules java.compiler". I think we need to start a new thread on jtreg-dev about this issue as this is about test selection when TEST.properties is used to list the required modules. -Alan From Alan.Bateman at oracle.com Mon Sep 26 07:25:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Sep 2016 08:25:31 +0100 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> Message-ID: <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> On 26/09/2016 00:41, Aleks Efimov wrote: > Hi Alan, Joe, Mandy, Roman, > > Suggested changes to the comment section (will bring this change to > standalone JAXB) and to the exported internal API were made: > com.sun.xml.internal.stream.writers, > com.sun.org.apache.xml.internal.resolver, > com.sun.org.apache.xml.internal.resolver.tools dependencies were removed. > > The updated webrev: > http://cr.openjdk.java.net/~aefimov/8164479/01 Thanks Aleks. If com.sun.xml.internal.stream.writers is not used directly then I assume the comment "// reflection access ..." can be removed too. Do we have any issues tracking the issue of direct access to types in com.sun.org.apache.xerces.internal.**. Those will need to be addressed if JAX-WS is to be truely standalone without needing --add-exports options on the command line. For java.activation then I assume you can run deps too as it should no longer need the `requires java.desktop`. Also I think we can improve the javadoc of CommandInfo.getCommandObject to replace the proposed "If the current runtime environment supports Beans.instantiate ..." to something like "If java.beans.Beans is visible ...". -Alan From roman.grigoriadi at oracle.com Mon Sep 26 13:07:08 2016 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Mon, 26 Sep 2016 15:07:08 +0200 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> Message-ID: Hi, Thank you for review. We were discussing java.net will go down eventually, links to jaxb.java.net is best we have now (to fix submitted javadoc bug), we will update links again when we know new location of standalone projects documentation. Regarding clean standalone TCK tests - yes they are clean against these changes, but there is one caveat to it: Standalone tests were never run on JDK9 yet. We are trying to utilize a "multirelease-jar" feauture of JDK9 in standalone projects, to avoid using reflection for JDK9 api and checks for module system. This multirelease version of standalone project is still work in progress, tests cannot be run against it yet. We are running standalone TCK tests on JDK8 in separate branch, which has all these changes merged, but lacks JDK9 only compatible classes - namely catalog API and some resource loading with Module#getResourceAsStream. So lets say TCK tests are "almost clean" against this version. Roman On 09/26/2016 09:25 AM, Alan Bateman wrote: > > > On 26/09/2016 00:41, Aleks Efimov wrote: >> Hi Alan, Joe, Mandy, Roman, >> >> Suggested changes to the comment section (will bring this change to >> standalone JAXB) and to the exported internal API were made: >> com.sun.xml.internal.stream.writers, >> com.sun.org.apache.xml.internal.resolver, >> com.sun.org.apache.xml.internal.resolver.tools dependencies were >> removed. >> >> The updated webrev: >> http://cr.openjdk.java.net/~aefimov/8164479/01 > Thanks Aleks. > > If com.sun.xml.internal.stream.writers is not used directly then I > assume the comment "// reflection access ..." can be removed too. > > Do we have any issues tracking the issue of direct access to types in > com.sun.org.apache.xerces.internal.**. Those will need to be addressed > if JAX-WS is to be truely standalone without needing --add-exports > options on the command line. > > For java.activation then I assume you can run deps too as it should no > longer need the `requires java.desktop`. Also I think we can improve > the javadoc of CommandInfo.getCommandObject to replace the proposed > "If the current runtime environment supports Beans.instantiate ..." to > something like "If java.beans.Beans is visible ...". > > -Alan > From Alan.Bateman at oracle.com Mon Sep 26 14:00:04 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Sep 2016 15:00:04 +0100 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> Message-ID: <19bf4809-954e-f8c3-1e20-6abad239157b@oracle.com> On 26/09/2016 14:07, Roman Grigoriadi wrote: > Hi, > > Thank you for review. We were discussing java.net will go down > eventually, links to jaxb.java.net is best we have now (to fix > submitted javadoc bug), we will update links again when we know new > location of standalone projects documentation. > > Regarding clean standalone TCK tests - yes they are clean against > these changes, but there is one caveat to it: > Standalone tests were never run on JDK9 yet. We are trying to utilize > a "multirelease-jar" feauture of JDK9 in standalone projects, to avoid > using reflection for JDK9 api and checks for module system. This > multirelease version of standalone project is still work in progress, > tests cannot be run against it yet. We are running standalone TCK > tests on JDK8 in separate branch, which has all these changes merged, > but lacks JDK9 only compatible classes - namely catalog API and some > resource loading with Module#getResourceAsStream. So lets say TCK > tests are "almost clean" against this version. This seems a good use of MR JAR. Will the standalone version also have module-info in the top-level directory of the JAR file so that it can be deployed on the [upgrade] module path too? -Alan From viktor.klang at gmail.com Mon Sep 26 14:29:48 2016 From: viktor.klang at gmail.com (Viktor Klang) Date: Mon, 26 Sep 2016 16:29:48 +0200 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> Message-ID: On Sun, Sep 25, 2016 at 10:01 PM, Martin Buchholz wrote: > > > On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang > wrote: > >> If that truely is the case then the only way of implementing a readonly >> Future is by throwing an exception from cancel... >> > We the maintainers of j.u.c.Future have always thought that canceling a > Future will surely leave it completed. Of course, implementers of any Java > interface can choose to throw UOE for any method, but this is not intended > for Future.cancel. An interface without cancel probably should not be > extending Future. > This seems to have been "addressed" further down this thread. > > --- > > Here's another way to think of the range of functionality between current > CompletionStage and current CompletableFuture: > > - Add Polling methods from scala Future such as isCompleted > > These are also discouraged, but less so than Await methods > """Note: using this method yields nondeterministic dataflow programs.""" > Will adding these to CompletionStage be less controversial? > > - Add Await blocking methods (that in scala cannot be called directly, > using the CanAwait mechanism) > > - Add cancellation > > - Add other methods to complete the future ("Promise") > > - Add the full CompletableFuture API, including the obtrude methods > > Cancellation is interesting, because it's a mutating method, and so cannot > be used with a future shared with other users, but it also seems very > reasonable as a "client" operation. One can think of obtaining a > non-shared future as a subscription to a one-time event, and that > subscription takes up resources in the form of an object. If the client is > no longer interested in the event, then cancellation of the future can free > up resources. I'm still thinking of what Process.onExit > > should return. There's a tension between the various roles that > CompletableFuture serves - as a container to write a value, as a possibly > cancellable subscription to that value, and as a way to chain async > computations together. > I'd rather suggest creating a 2.0 of FutureTask (i.e. represent the Task part separately from the Future part) Have something represents something being executed somewhere else, that can support cancellation but also expose a read-only facet of itself. I think you're right in that something is missing which would lie somewhere in between CompletionStage and CompletableFuture. What methods would you propose to add to such an interface and why? > > On Wed, Sep 21, 2016 at 2:25 PM, Benjamin Manes > wrote: > >> I've gradually come to terms using CF as part of an API and haven't >> experienced a downside yet. >> > > Hmmmm.... I seem to be moving in that direction as well... > -- Cheers, ? From viktor.klang at gmail.com Mon Sep 26 14:30:21 2016 From: viktor.klang at gmail.com (Viktor Klang) Date: Mon, 26 Sep 2016 16:30:21 +0200 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: <030e01d21772$dbe934d0$93bb9e70$@aapt.net.au> References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> <030e01d21772$dbe934d0$93bb9e70$@aapt.net.au> Message-ID: On Sun, Sep 25, 2016 at 11:22 PM, David Holmes wrote: > Joe, > > > > That is ignoring the error case. If the cancel fails then it is not > complete and it is not cancelled. We added the extra wording back in August > 2005. It is interesting to note that Martin?s initial query then only > related to the state of the thread, but that it was clear about things only > happening if cancel returned true: > > > > ?My guess is that if cancel(true) returns true, then subsequent cals to > isCancelled() and isDone() will return true, *even if the thread executing > the task is still running*? > > > > Yet we somehow added the clarification with no regard as to whether cancel > returned true or not. That seems wrong. > Agreed. > > > David > > > > *From:* Concurrency-interest [mailto:concurrency-interest- > bounces at cs.oswego.edu] *On Behalf Of *Joe Bowbeer > *Sent:* Monday, September 26, 2016 12:20 AM > *To:* David Holmes > *Cc:* Martin Buchholz ; concurrency-interest < > concurrency-interest at cs.oswego.edu>; core-libs-dev < > core-libs-dev at openjdk.java.net> > > *Subject:* Re: [concurrency-interest] We need to add blocking methods to > CompletionStage! > > > > This statement regarding what happens after cancel is called is correct: > > "*After this method returns, subsequent calls to isDone() will always > return true*. Subsequent calls to isCancelled() will always return true > if this method returned true." > > After cancel returns, the future is completed, hence isDone. If cancel > returns true, i.e. it was cancelled, then isCancelled returns true. But, > for example if the future is already completed when cancel is called, then > cancel will return false and isCancelled will return false. > > > > On Sep 25, 2016 6:49 AM, "David Holmes" wrote: > > I think that was meant to read ?After this method returns _*true*_, > subsequent calls ?? > > > > David > > > > *From:* Concurrency-interest [mailto:concurrency-interest- > bounces at cs.oswego.edu] *On Behalf Of *Viktor Klang > *Sent:* Sunday, September 25, 2016 9:03 PM > *To:* Martin Buchholz > *Cc:* concurrency-interest ; > core-libs-dev > *Subject:* Re: [concurrency-interest] We need to add blocking methods to > CompletionStage! > > > > > > > > On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang > wrote: > > > > > > On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz > wrote: > > No one is suggesting we add cancel to CompletionStage - I agree that would > break users, by making an immutable interface mutable. > > > > +10000 > > > > This also means that CompletionStage cannot extend Future. > > > > +10000 > > > > I also would not want to have a toFuture method that would return a > j.u.c.Future, because of misfit Future.cancel. > > > > Would you mind elaborating here? According to the cancel method spec on > Future it is completely fine for it to be a no-op which always returns > false: > > > > "This attempt will fail if the task has already completed, has already > been cancelled, *or could not be cancelled for some other reason.*" > > > > Source: https://docs.oracle.com/javase/8/docs/api/java/util/ > concurrent/Future.html > > > > There's an interesting (read: weird) spec clause in cancel: > > > > "*After this method returns, subsequent calls to isDone() will always > return true*. Subsequent calls to isCancelled() will always return true > if this method returned true." > > > > That clause is in contradiction with the previously quoted line. > > > > > > > > > > If we are adding cancel, then it will be to make a new interface, such > as the suggested CancellableCompletionStage. > > > > I also agree that CompletionStage does *not* represent "a running task of > sorts", j.u.c. Future specs are still confusing in that way due to > FutureTask heritage. > > > > +10000 > > > > > > On Thu, Sep 22, 2016 at 7:51 PM, James Roper wrote: > > For example, we often cache futures and return them from a libraries API, > if a client could cancel a future, that would break everything else that > received that future. > > > > On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang > wrote: > > PPS: A misunderstanding is that CompletionStage represents a running task > of sorts, one that can be cancelled etc. This is not the case. > > > > > > > > > > -- > > Cheers, > > ? > > > > > > -- > > Cheers, > > ? > > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > -- Cheers, ? From viktor.klang at gmail.com Mon Sep 26 14:55:17 2016 From: viktor.klang at gmail.com (Viktor Klang) Date: Mon, 26 Sep 2016 16:55:17 +0200 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On Sun, Sep 25, 2016 at 11:49 PM, Martin Buchholz wrote: > > > On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang > wrote: > >> >> PS. As a sidenote, Martin, and in all friendliness, "actor purist API"? >> C'mon, I know you're better than that! CompletionStage's design has nothing >> to do with Actors and if Single Responsibility Principle is considered >> purism then I'm not sure why we don't have a single interface with all >> methods in it. >> Let's try to keep things friendly. >> > > Let's be best friends! > One step at a time? :) > > The programming profession is still learning how to write concurrent > programs, fumbling in the dark, and that's particularly true for myself! > There are competing approaches and we don't know which will prove > successful. > I'm not sure that they are all that competing TBH! There's always the tradeoff between utility and safety. The problem is that the JDK is a single layer for ALL Java programmers. Sometimes I think it would be wiser to have one layer of high-utility/unsafer for library developers and other "low-level tasks" and have a lower-utility/safer layer for more App-level development. (I.e. always choose the least powerful thing with the highest safety which gets the job done.) > > PPPS: Adding blocking methods without mandatory timeouts has in practice >> proven to be a recipe for disaster. >> > > Hmmmm... By design, Unix processes that create subprocesses should > dedicate a thread for each subprocess, that waits indefinitely in waitpid. > Linux kernel folks deliberately decided this was fine. In the Real World, > one needs to interface with Other Peoples' APIs. > If you expect the machine to be up until the end of the universe, I think it's fine to put an unbounded wait. In the Real World?nothing waits forever for anything. (Evolution and all that?) > > Software that rarely blocks is a great idea. Especially the folks who > write network server infrastructure increasingly agree. But it is truly a > difficult paradigm shift; we will get there slowly. > Trust me?having spent the past 6+ years on that journey?I know exactly what you're talking about! > > --- > > Say you are implementing some existing function with a traditional > synchronous API. Your implementation is multi-threaded, but that's an > implementation detail. Before you return to the caller, you must wait for > the various parts of your computation to complete (the "join" part of > fork/join). It seems reasonable to wait forever. If some part of your > computation is interacting with an unreliable external resource, then it > makes sense for that particular "wait" (which need not occupy a thread) to > have a timeout. > If you're implementing some existing method which expects a synchronous response, but are doing so in a deferred way, that is exactly the kids of situations where that tends to come back haunt you after a while. Especially if calls to said implementation by some chance ends up being executed on said multithreaded implementation's thread pool. (Enqueue "hilarious" production deadlock-forever) > Test methods, > Yeah, I thought so as well, but it turns out that when you have tons of async tests, not being able to start new tests until either that timeout or result makes for a very slow test suite, so that's why most serious test frameworks are growing support for dealing with async code. Then all you want to be able to limit is work-in-progress (sloppily called parallelism) > main methods > That's a common scenario, but one that can be solved by having non-daemonic pooled worker threads. > and unix process reapers are all examples where it's reasonable to block > forever. > What about waitpid() + WNOHANG? > > >> PPPPS: "I think it's unreasonable to not provide this for users >> (especially when we can do so more efficiently)." <- If efficiency is >> desired then blocking is definitely not the right solution. >> > > What about efficiently providing isComplete? > In my experience isComplete is virtually useless without being able to extract the value, in which case you may as well introduce a non-blocking `Optional poll()` > > The result may already be available without actually blocking. It may > even be known to be available immediately. One would like to get the value > without additional allocation. > I've seen that use-case :), and it tends to either be a situation where the value is available by pure luck (or?scheduling artifacts) or when one is keeping CompletionStages where strict values could be kept instead (think rebinding a value on completion). Reading what your'e writing, may I dare propose that what you're after is something along the lines of a: PollableCompletionStage which sits in between CompletionStage and CompletableFuture? -- Cheers, ? From volker.simonis at gmail.com Mon Sep 26 15:00:20 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 26 Sep 2016 17:00:20 +0200 Subject: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc In-Reply-To: References: <13e66bbd-d896-673f-23ce-ea2eef45b230@oracle.com> <962ae958-5897-6e9b-eec3-33680358ad0b@oracle.com> Message-ID: Hi, I've been a little busy with JavaOne but now I've finally pushed this change. Thanks to everybody, Volker On Thu, Sep 15, 2016 at 8:08 AM, Hiroshi H Horii wrote: > Hi Volker, and Sean, > > Thank you for your comments and suggestion. > > I and Gustavo created a webrev that includes Bits and ByteArrayAccess. > > http://cr.openjdk.java.net/~gromero/8165231/02/ > > I believe there is no other similar methods in jdk. > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > > > From: Sean Coffey > To: Volker Simonis > Cc: "jdk8u-dev at openjdk.java.net" , Java > Core Libs , Hiroshi H Horii/Japan/IBM at IBMJP, > "ppc-aix-port-dev at openjdk.java.net" , > Gustavo Bueno Romero , "Doerr, Martin" > > Date: 09/13/2016 21:46 > Subject: Re: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() > doesn't return true on ppc > ________________________________ > > > > Sounds good Volker. Good catch. > > regards, > Sean. > > On 13/09/2016 13:09, Volker Simonis wrote: >> Hi Sean, >> >> thanks a lot for the fast response. I've updated the bug entry as >> requested and will push the change - maybe with the following >> potential improvement: >> >> @Hiroshi: also maybe not that performance relevant, I think we should >> we also fix sun/security/provider/ByteArrayAccess.java which contains >> the same construct: >> >> // Return whether this platform supports full speed int/long memory >> access >> // at unaligned addresses. >> // This code was copied from java.nio.Bits because there is no >> equivalent >> // public API. >> private static boolean unaligned() { >> String arch = java.security.AccessController.doPrivileged >> (new sun.security.action.GetPropertyAction("os.arch", "")); >> return arch.equals("i386") || arch.equals("x86") || >> arch.equals("amd64") >> || arch.equals("x86_64"); >> } >> >> Regards, >> Volker > > > > From roman.grigoriadi at oracle.com Mon Sep 26 15:10:23 2016 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Mon, 26 Sep 2016 17:10:23 +0200 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <19bf4809-954e-f8c3-1e20-6abad239157b@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> <19bf4809-954e-f8c3-1e20-6abad239157b@oracle.com> Message-ID: On 09/26/2016 04:00 PM, Alan Bateman wrote: > This seems a good use of MR JAR. Will the standalone version also have > module-info in the top-level directory of the JAR file so that it can > be deployed on the [upgrade] module path too? We are planning to set modularization along with runnable JDK9 TCK tests to be next main goal for standalone projects. Roman From viktor.klang at gmail.com Sun Sep 25 10:34:58 2016 From: viktor.klang at gmail.com (Viktor Klang) Date: Sun, 25 Sep 2016 12:34:58 +0200 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz wrote: > No one is suggesting we add cancel to CompletionStage - I agree that would > break users, by making an immutable interface mutable. > +10000 > This also means that CompletionStage cannot extend Future. > +10000 > I also would not want to have a toFuture method that would return a > j.u.c.Future, because of misfit Future.cancel. > Would you mind elaborating here? According to the cancel method spec on Future it is completely fine for it to be a no-op which always returns false: "This attempt will fail if the task has already completed, has already been cancelled, *or could not be cancelled for some other reason.*" Source: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html > If we are adding cancel, then it will be to make a new interface, such > as the suggested CancellableCompletionStage. > > I also agree that CompletionStage does *not* represent "a running task of > sorts", j.u.c. Future specs are still confusing in that way due to > FutureTask heritage. > +10000 > > On Thu, Sep 22, 2016 at 7:51 PM, James Roper wrote: > >> For example, we often cache futures and return them from a libraries API, >> if a client could cancel a future, that would break everything else that >> received that future. > > > On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang > wrote: > >> PPS: A misunderstanding is that CompletionStage represents a running task >> of sorts, one that can be cancelled etc. This is not the case. >> > > > -- Cheers, ? From viktor.klang at gmail.com Sun Sep 25 11:03:21 2016 From: viktor.klang at gmail.com (Viktor Klang) Date: Sun, 25 Sep 2016 13:03:21 +0200 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang wrote: > > > On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz > wrote: > >> No one is suggesting we add cancel to CompletionStage - I agree that >> would break users, by making an immutable interface mutable. >> > > +10000 > > >> This also means that CompletionStage cannot extend Future. >> > > +10000 > > >> I also would not want to have a toFuture method that would return a >> j.u.c.Future, because of misfit Future.cancel. >> > > Would you mind elaborating here? According to the cancel method spec on > Future it is completely fine for it to be a no-op which always returns > false: > > "This attempt will fail if the task has already completed, has already > been cancelled, *or could not be cancelled for some other reason.*" > > Source: https://docs.oracle.com/javase/8/docs/api/java/util/ > concurrent/Future.html > There's an interesting (read: weird) spec clause in cancel: "*After this method returns, subsequent calls to isDone() will always return true*. Subsequent calls to isCancelled() will always return true if this method returned true." That clause is in contradiction with the previously quoted line. > > > >> If we are adding cancel, then it will be to make a new interface, such >> as the suggested CancellableCompletionStage. >> >> I also agree that CompletionStage does *not* represent "a running task of >> sorts", j.u.c. Future specs are still confusing in that way due to >> FutureTask heritage. >> > > +10000 > > >> >> On Thu, Sep 22, 2016 at 7:51 PM, James Roper wrote: >> >>> For example, we often cache futures and return them from a libraries >>> API, if a client could cancel a future, that would break everything else >>> that received that future. >> >> >> On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang >> wrote: >> >>> PPS: A misunderstanding is that CompletionStage represents a running >>> task of sorts, one that can be cancelled etc. This is not the case. >>> >> >> >> > > > > -- > Cheers, > ? > -- Cheers, ? From joe.bowbeer at gmail.com Sun Sep 25 14:20:04 2016 From: joe.bowbeer at gmail.com (Joe Bowbeer) Date: Sun, 25 Sep 2016 07:20:04 -0700 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> Message-ID: This statement regarding what happens after cancel is called is correct: "*After this method returns, subsequent calls to **isDone**() will always return true*. Subsequent calls to isCancelled() will always return true if this method returned true." After cancel returns, the future is completed, hence isDone. If cancel returns true, i.e. it was cancelled, then isCancelled returns true. But, for example if the future is already completed when cancel is called, then cancel will return false and isCancelled will return false. On Sep 25, 2016 6:49 AM, "David Holmes" wrote: > I think that was meant to read ?After this method returns _*true*_, > subsequent calls ?? > > > > David > > > > *From:* Concurrency-interest [mailto:concurrency-interest- > bounces at cs.oswego.edu] *On Behalf Of *Viktor Klang > *Sent:* Sunday, September 25, 2016 9:03 PM > *To:* Martin Buchholz > *Cc:* concurrency-interest ; > core-libs-dev > *Subject:* Re: [concurrency-interest] We need to add blocking methods to > CompletionStage! > > > > > > > > On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang > wrote: > > > > > > On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz > wrote: > > No one is suggesting we add cancel to CompletionStage - I agree that would > break users, by making an immutable interface mutable. > > > > +10000 > > > > This also means that CompletionStage cannot extend Future. > > > > +10000 > > > > I also would not want to have a toFuture method that would return a > j.u.c.Future, because of misfit Future.cancel. > > > > Would you mind elaborating here? According to the cancel method spec on > Future it is completely fine for it to be a no-op which always returns > false: > > > > "This attempt will fail if the task has already completed, has already > been cancelled, *or could not be cancelled for some other reason.*" > > > > Source: https://docs.oracle.com/javase/8/docs/api/java/util/ > concurrent/Future.html > > > > There's an interesting (read: weird) spec clause in cancel: > > > > "*After this method returns, subsequent calls to isDone() will always > return true*. Subsequent calls to isCancelled() will always return true > if this method returned true." > > > > That clause is in contradiction with the previously quoted line. > > > > > > > > > > If we are adding cancel, then it will be to make a new interface, such > as the suggested CancellableCompletionStage. > > > > I also agree that CompletionStage does *not* represent "a running task of > sorts", j.u.c. Future specs are still confusing in that way due to > FutureTask heritage. > > > > +10000 > > > > > > On Thu, Sep 22, 2016 at 7:51 PM, James Roper wrote: > > For example, we often cache futures and return them from a libraries API, > if a client could cancel a future, that would break everything else that > received that future. > > > > On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang > wrote: > > PPS: A misunderstanding is that CompletionStage represents a running task > of sorts, one that can be cancelled etc. This is not the case. > > > > > > > > > > -- > > Cheers, > > ? > > > > > > -- > > Cheers, > > ? > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > From oleksandr.otenko at gmail.com Sun Sep 25 22:22:35 2016 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sun, 25 Sep 2016 23:22:35 +0100 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: <0D29F308-9D16-44A0-9232-CCD9183FFC94@gmail.com> > On 25 Sep 2016, at 22:49, Martin Buchholz wrote: > ...Say you are implementing some existing function with a traditional synchronous API. Your implementation is multi-threaded, but that's an implementation detail. Before you return to the caller, you must wait for the various parts of your computation to complete (the "join" part of fork/join). It seems reasonable to wait forever. If some part of your computation is interacting with an unreliable external resource, then it makes sense for that particular "wait" (which need not occupy a thread) to have a timeout. Test methods, main methods and unix process reapers are all examples where it's reasonable to block forever. More than that, cancelling the wait does not cancel the computation it was waiting for. You need to time out / cancel the wait at the junctions where you have the power to arbitrate fair use of resource locked up in the caller, by the caller. Alex From joe.bowbeer at gmail.com Mon Sep 26 06:00:44 2016 From: joe.bowbeer at gmail.com (Joe Bowbeer) Date: Sun, 25 Sep 2016 23:00:44 -0700 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> <030e01d21772$dbe934d0$93bb9e70$@aapt.net.au> Message-ID: Cancellation: David, I can see your point. Future.cancel(true) was discussed 8/27/05 and the extra text was added to make it clearer that the state of Future after cancel is called is separate from the state of any associated thread or task. However, I think the added text corresponded too closely to the only implementation of Future.cancel that existed at the time. Elsewhere the spec tries to permit Future.cancel to fail for some reason other than because the Future had already completed: "This attempt will fail if the task [...] could not be cancelled for some other reason." "returns false if the task could not be cancelled, typically because it has already completed normally" Without the added text, my interpretation would be that if cancel returns false and then isDone returns false, then cancel failed for some other reason. On Sun, Sep 25, 2016 at 5:39 PM, Martin Buchholz wrote: > > > On Sun, Sep 25, 2016 at 2:22 PM, David Holmes > wrote: > >> >> Yet we somehow added the clarification with no regard as to whether >> cancel returned true or not. That seems wrong. >> > > Yikes! I had always assumed that cancel was not permitted to leave the > Future incomplete, perhaps influenced by the wording, > > """After this method returns, subsequent calls to {@link #isDone} will > always return {@code true}.""" > > It's much more in the spirit of Java to throw an exception if the future > cannot be completed. It's never come up, I think. > From yingqi.lu at intel.com Mon Sep 26 18:17:06 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 26 Sep 2016 18:17:06 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com>, Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> Hi All, The second version of the patch is now available at http://cr.openjdk.java.net/~igraves/8164900-1/. In this version, we moved the O_DIRECT support from FIS/FOS/RAF to FileChannel. We implemented O_DIRECT as a StandardOpenOption. The reason we did not make it as one of the ExtendedOpenOptions is because we found ExtendedOpenOption is now moved to jdk.unsupported. Please let us know if we misunderstood anything here. We can modify it accordingly if there is a better place to put this flag. Please let us know your feedback and comments on the patch! Thanks, Lucy -----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Lu, Yingqi Sent: Saturday, August 27, 2016 9:01 AM To: Alan Bateman Cc: core-libs-dev at openjdk.java.net; Kaczmarek, Eric Subject: Re: Proposal for adding O_DIRECT support into JDK 9 The workload we have uses fis/fos/raf, that is why we started here following the example of other file open flags. We can surely look into filechannel extended open options to see if it fits better there. Thanks, Lucy Sent from my iPhone > On Aug 27, 2016, at 12:43 AM, Alan Bateman wrote: > >> On 26/08/2016 23:31, Lu, Yingqi wrote: >> >> Dear All, >> >> This is a proposal for adding O_DIRECT support into JDK 9 for reading/writing from/to a file on Linux platform. O_DIRECT is a file-open flag to pass to OPEN (2). It tries to minimize cache effects of the I/O to and from this file. File I/O is done directly to/from user-space buffers. Please refer to http://man7.org/linux/man-pages/man2/open.2.html for more details. > FIS/FOS/RAF doesn't seem the right place for this. Have you looked at using extended open options with FileChannel instead? > > -Alan From Alan.Bateman at oracle.com Mon Sep 26 18:41:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Sep 2016 19:41:48 +0100 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> Message-ID: <062c589c-fa54-1652-683a-4e779816391d@oracle.com> On 26/09/2016 19:17, Lu, Yingqi wrote: > Hi All, > > The second version of the patch is now available at http://cr.openjdk.java.net/~igraves/8164900-1/. In this version, we moved the O_DIRECT support from FIS/FOS/RAF to FileChannel. We implemented O_DIRECT as a StandardOpenOption. The reason we did not make it as one of the ExtendedOpenOptions is because we found ExtendedOpenOption is now moved to jdk.unsupported. Please let us know if we misunderstood anything here. We can modify it accordingly if there is a better place to put this flag. ExtendedOpenOption seems the right place for this (we haven't found a good home for this yet). I skimmed the implementation and the changes to readv0/write0 are a concern - I suspect you'll need to hoist the bulk of this into FileChannelImpl so that most of this native code can be eliminated. -Alan From yingqi.lu at intel.com Mon Sep 26 18:50:22 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 26 Sep 2016 18:50:22 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <062c589c-fa54-1652-683a-4e779816391d@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> Alan, you mean readv0/write0 or read0/write0? I just want to make sure :-) Anyone else has other opinions on where is the best home for O_DIRECT flag? The flags under jdk.unsupported will eventually be removed in the future JDK release? If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify that for sure. Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Monday, September 26, 2016 11:42 AM To: Lu, Yingqi ; core-libs-dev at openjdk.java.net Cc: nio-dev at openjdk.java.net Subject: Re: Proposal for adding O_DIRECT support into JDK 9 On 26/09/2016 19:17, Lu, Yingqi wrote: > Hi All, > > The second version of the patch is now available at http://cr.openjdk.java.net/~igraves/8164900-1/. In this version, we moved the O_DIRECT support from FIS/FOS/RAF to FileChannel. We implemented O_DIRECT as a StandardOpenOption. The reason we did not make it as one of the ExtendedOpenOptions is because we found ExtendedOpenOption is now moved to jdk.unsupported. Please let us know if we misunderstood anything here. We can modify it accordingly if there is a better place to put this flag. ExtendedOpenOption seems the right place for this (we haven't found a good home for this yet). I skimmed the implementation and the changes to readv0/write0 are a concern - I suspect you'll need to hoist the bulk of this into FileChannelImpl so that most of this native code can be eliminated. -Alan From michael.haupt at oracle.com Mon Sep 26 19:01:12 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 26 Sep 2016 21:01:12 +0200 Subject: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API In-Reply-To: <3FA2149A-C14D-466D-BF5E-2FCAF958F6D4@oracle.com> References: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> <7C0D47C4-233E-40CA-BE87-82C0FD6378EE@oracle.com> <3FA2149A-C14D-466D-BF5E-2FCAF958F6D4@oracle.com> Message-ID: <91966279-F402-4A69-B802-E0BC12E458EA@oracle.com> Hi John, all, thank you very much for your reviews - may I ask for a second round? The updated webrev is at http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ ; an accompanying specdiff, at http://cr.openjdk.java.net/~mhaupt/8151179/specdiff.01/ . Thanks, Michael > Am 16.08.2016 um 01:39 schrieb John Rose : > > I'm working on this. The javadoc has some re-filling which creates lots of diffs of whitespace only, which makes things go a little slower. > > I am trying to like the cleaner, more restricted semantics for the utility methods, but they really do some harm to the use cases. The really notable change is the loss of defaulting behavior of the first parameter to iteratedLoop, which was List::iterator. That was intended to corresponding to the for-each syntax, and it is hard (and probably non-performant) to ask the user to rebuild a MH for Iterable::iterator at each use site for iteratedLoop. > > ? John -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From steve.drach at oracle.com Mon Sep 26 19:31:22 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 26 Sep 2016 12:31:22 -0700 Subject: RFR: 8165944 jar utility doesn't process more than one -C argument Message-ID: Hi, Please review these changes to the jar tool to fix a capability regression I introduced in an earlier revision. The issue is that this $ jar -cf test.jar -C test1 . -C test2 . only puts the files under test1 in the jar and ignores the files under test2. The DoubleCs test verified the problem and the solution. issue: https://bugs.openjdk.java.net/browse/JDK-8165944 webrev: http://cr.openjdk.java.net/~sdrach/8165944/webrev.00/ Thanks, Steve From mandy.chung at oracle.com Mon Sep 26 20:41:12 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 26 Sep 2016 13:41:12 -0700 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> Message-ID: > On Sep 26, 2016, at 12:25 AM, Alan Bateman wrote: > > Do we have any issues tracking the issue of direct access to types in com.sun.org.apache.xerces.internal.**. Those will need to be addressed if JAX-WS is to be truely standalone without needing --add-exports options on the command line. I brought this up a while back. SAAJ uses the java.xml's internal dom implementation. Just to double check: Is the standalone referencing com.sun.org.apache.xerces.internal.**? Does the package naming apply only to the JAX-WS types (but not these xerces types)? I couldn?t find any issue tracking it and will file one. Mandy From Roger.Riggs at Oracle.com Mon Sep 26 20:46:54 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 26 Sep 2016 16:46:54 -0400 Subject: RFR 9: 8155760 Implement Serialization Filtering - revised for extensibility In-Reply-To: <435b73b8-e87c-9042-18a3-293aea0062e7@Oracle.com> References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> <466883E6-60CC-4CE5-BE2F-A29AE5EA4C04@oracle.com> <435b73b8-e87c-9042-18a3-293aea0062e7@Oracle.com> Message-ID: To more easily support future enhancement of the information provided to the serial filter the API has been modified to pass the information to the filter via an interface with methods for the class, array length, references, depth and stream bytes. Complete webrev supporting Serialization Filtering: http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ The specdiff of these changes are: http://cr.openjdk.java.net/~rriggs/filter-diffs-8166739/overview-summary.html Javadoc (subset) http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html Thanks, Roger From szegedia at gmail.com Mon Sep 26 21:29:11 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 26 Sep 2016 23:29:11 +0200 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> Message-ID: Not at all, you could just have a call to cancel() block until the future completes. *ducks* Attila. > On 25 Sep 2016, at 16:34, Viktor Klang wrote: > > If that truely is the case then the only way of implementing a readonly > Future is by throwing an exception from cancel... > > -- > Cheers, > ? > > On Sep 25, 2016 4:20 PM, "Joe Bowbeer" wrote: > >> This statement regarding what happens after cancel is called is correct: >> >> "*After this method returns, subsequent calls to **isDone**() will always >> return true*. Subsequent calls to isCancelled() will always return true >> if this method returned true." >> >> After cancel returns, the future is completed, hence isDone. If cancel >> returns true, i.e. it was cancelled, then isCancelled returns true. But, >> for example if the future is already completed when cancel is called, then >> cancel will return false and isCancelled will return false. >> >> On Sep 25, 2016 6:49 AM, "David Holmes" wrote: >> >>> I think that was meant to read ?After this method returns _*true*_, >>> subsequent calls ?? >>> >>> >>> >>> David From martinrb at google.com Mon Sep 26 23:18:52 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 26 Sep 2016 16:18:52 -0700 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang wrote: > >> > Test methods, >> > > Yeah, I thought so as well, but it turns out that when you have tons of > async tests, not being able to start new tests until either that timeout or > result makes for a very slow test suite, so that's why most serious test > frameworks are growing support for dealing with async code. Then all you > want to be able to limit is work-in-progress (sloppily called parallelism) > I don't see any support in junit or testng for multi-threaded tests. jtreg uses the strategy of having a set of reusable JVM processes, each of which is running only one test at a time, which provides "pretty good" isolation, and seems to work well. > main methods >> > > That's a common scenario, but one that can be solved by having > non-daemonic pooled worker threads. > Do you have docs for such a thread pool? > and unix process reapers are all examples where it's reasonable to block >> forever. >> > > What about waitpid() + WNOHANG? > Are you suggesting periodic polling is better than blocking? > PPPPS: "I think it's unreasonable to not provide this for users >>> (especially when we can do so more efficiently)." <- If efficiency is >>> desired then blocking is definitely not the right solution. >>> >> >> What about efficiently providing isComplete? >> > > In my experience isComplete is virtually useless without being able to > extract the value, in which case you may as well introduce a non-blocking > `Optional poll()` > Do you support adding the Polling methods from http://www.scala-lang.org/api/2.12.0-RC1/scala/concurrent/Future.html to CompletionStage, i.e. isDone and getNow? > The result may already be available without actually blocking. It may >> even be known to be available immediately. One would like to get the value >> without additional allocation. >> > > I've seen that use-case :), and it tends to either be a situation where > the value is available by pure luck (or?scheduling artifacts) or when one > is keeping CompletionStages where strict values could be kept instead > (think rebinding a value on completion). > > Reading what your'e writing, may I dare propose that what you're after is > something along the lines of a: PollableCompletionStage which sits in > between CompletionStage and CompletableFuture? > I've been waffling! Right now, I'm leaning towards having Java APIs return fully mutable CompletableFutures as Benjamin and Pavel suggested upthread. Why? Because a completion stage can be thought of as all of: - a consumer of an upstream value - a subscription to the event that makes the upstream value available, and - the producer of a possible value for downstream consumers. Cancellation could be interpreted as a request to unsubscribe from upstream producer or a notification to downstream consumers that no value will be forthcoming, or both. Here's a problem with jdk9 minimalCompletionStage: even if you are happy with the minimality of the source stage (perhaps it's shared) you might want downstream stages to be mutable, but the methods such as thenApply also create minimal completion stages. If you want to convert to a mutable future, you can try calling toCompletableFuture, but there's no guarantee that will work, even if it doesn't throw UOE. You can hand-construct a CompletableFuture which is then completed in a Runnable via thenRun, but then this is opaque to the CompletableFuture implementation, and implementation features such as stack overflow prevention will be ineffective. So right now I'm OK with e.g. Process#onExit simply returning CompletableFuture. From martinrb at google.com Tue Sep 27 03:42:32 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 26 Sep 2016 20:42:32 -0700 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> <030e01d21772$dbe934d0$93bb9e70$@aapt.net.au> Message-ID: I don't remember what happened in 2005, but records say that I wrote: """Why not ...... - add to the spec of Future.cancel() a guarantee that subsequent calls to Future.isDone() always return true? """ which led to the spec: """After this method returns, subsequent calls to isDone() will always return true.""" which does sort-of seem to contradict """This attempt will fail if ... or could not be cancelled for some other reason.""" although if you squint, you can interpret that as a requirement to throw rather than return normally if ... could not be cancelled for some other reason. There's no @throws clause, but runtime exception specs are often incomplete! The Future javadoc is in need of some love, but perhaps there's little progress because the troubles run deep. On Sun, Sep 25, 2016 at 11:00 PM, Joe Bowbeer wrote: > Cancellation: David, I can see your point. Future.cancel(true) was > discussed 8/27/05 and the extra text was added to make it clearer that the > state of Future after cancel is called is separate from the state of any > associated thread or task. > > However, I think the added text corresponded too closely to the only > implementation of Future.cancel that existed at the time. Elsewhere the > spec tries to permit Future.cancel to fail for some reason other than > because the Future had already completed: > > "This attempt will fail if the task [...] could not be cancelled for > some other reason." > > "returns false if the task could not be cancelled, typically because it > has already completed normally" > > Without the added text, my interpretation would be that if cancel returns > false and then isDone returns false, then cancel failed for some other > reason. > > On Sun, Sep 25, 2016 at 5:39 PM, Martin Buchholz > wrote: > >> >> >> On Sun, Sep 25, 2016 at 2:22 PM, David Holmes >> wrote: >> >>> >>> Yet we somehow added the clarification with no regard as to whether >>> cancel returned true or not. That seems wrong. >>> >> >> Yikes! I had always assumed that cancel was not permitted to leave the >> Future incomplete, perhaps influenced by the wording, >> >> """After this method returns, subsequent calls to {@link #isDone} will >> always return {@code true}.""" >> >> It's much more in the spirit of Java to throw an exception if the future >> cannot be completed. It's never come up, I think. >> > > From viktor.klang at gmail.com Tue Sep 27 08:39:19 2016 From: viktor.klang at gmail.com (Viktor Klang) Date: Tue, 27 Sep 2016 10:39:19 +0200 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> Message-ID: Seems legit -- Cheers, ? On Sep 26, 2016 23:29, "Attila Szegedi" wrote: > Not at all, you could just have a call to cancel() block until the future > completes. > > *ducks* > > Attila. > > > On 25 Sep 2016, at 16:34, Viktor Klang wrote: > > > > If that truely is the case then the only way of implementing a readonly > > Future is by throwing an exception from cancel... > > > > -- > > Cheers, > > ? > > > > On Sep 25, 2016 4:20 PM, "Joe Bowbeer" wrote: > > > >> This statement regarding what happens after cancel is called is correct: > >> > >> "*After this method returns, subsequent calls to **isDone**() will > always > >> return true*. Subsequent calls to isCancelled() will always return true > >> if this method returned true." > >> > >> After cancel returns, the future is completed, hence isDone. If cancel > >> returns true, i.e. it was cancelled, then isCancelled returns true. > But, > >> for example if the future is already completed when cancel is called, > then > >> cancel will return false and isCancelled will return false. > >> > >> On Sep 25, 2016 6:49 AM, "David Holmes" > wrote: > >> > >>> I think that was meant to read ?After this method returns _*true*_, > >>> subsequent calls ?? > >>> > >>> > >>> > >>> David > From viktor.klang at gmail.com Tue Sep 27 09:07:40 2016 From: viktor.klang at gmail.com (Viktor Klang) Date: Tue, 27 Sep 2016 11:07:40 +0200 Subject: We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: On Sep 27, 2016 01:18, "Martin Buchholz" wrote: > > > > On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang wrote: >>> >>> >>> >>> Test methods, >> >> >> Yeah, I thought so as well, but it turns out that when you have tons of async tests, not being able to start new tests until either that timeout or result makes for a very slow test suite, so that's why most serious test frameworks are growing support for dealing with async code. Then all you want to be able to limit is work-in-progress (sloppily called parallelism) > > > I don't see any support in junit or testng for multi-threaded tests. jtreg uses the strategy of having a set of reusable JVM processes, each of which is running only one test at a time, which provides "pretty good" isolation, and seems to work well. It's less about multithreading per-se and more about async/non-blocking. Here's one example of a fwk which supports it: http://www.scalatest.org/user_guide/async_testing > >>> >>> main methods >> >> >> That's a common scenario, but one that can be solved by having non-daemonic pooled worker threads. > > > Do you have docs for such a thread pool? You mean one which has a ThreadFactory which enables setDaemonic(false)? > >>> >>> and unix process reapers are all examples where it's reasonable to block forever. >> >> >> What about waitpid() + WNOHANG? > > > Are you suggesting periodic polling is better than blocking? The botion of "better" requires some context to measure against: >From a liveness, responsiveness and scalability PoV, I'd say, barring selector support (which is arguably also polling), it's the next best thing. Since it allows you to monitor N number of external processes with a low constant factor. > >>>> >>>> PPPPS: "I think it's unreasonable to not provide this for users (especially when we can do so more efficiently)." <- If efficiency is desired then blocking is definitely not the right solution. >>> >>> >>> What about efficiently providing isComplete? >> >> >> In my experience isComplete is virtually useless without being able to extract the value, in which case you may as well introduce a non-blocking `Optional poll()` > > > Do you support adding the Polling methods from > http://www.scala-lang.org/api/2.12.0-RC1/scala/concurrent/Future.html > to CompletionStage, i.e. isDone and getNow? After thinking about it, I'd say 'No'. Since then people would ask to add more polling options: isFailed etc. Having been a part of creating s.c.Future I'd say adding the polling methods (barring possibly 'value: Option[Try[T]]') has been proven to add little in terms of value while adding a much larger API surface area. Since Java lacks value-level try-catch (scala.util.Try) and Java lacks disjoint union types, the signature of 'getNow' would have to throw, which is generally a bad thing. So I think a PollableCompletionStage would be a better option, where the broader surface area of these kinds of ops can be contained. Adding a CompletionStage constructor to CompletableFuture would make conversions simple. Reiterating Dougs sentiment: there is no API which will appease everyone, and if everything always should be added, not only does every API become a kitchen sink, but also all implementations thereof will be needlessly complex, slow and hard to maintain. > >>> >>> The result may already be available without actually blocking. It may even be known to be available immediately. One would like to get the value without additional allocation. >> >> >> I've seen that use-case :), and it tends to either be a situation where the value is available by pure luck (or?scheduling artifacts) or when one is keeping CompletionStages where strict values could be kept instead (think rebinding a value on completion). >> >> Reading what your'e writing, may I dare propose that what you're after is something along the lines of a: PollableCompletionStage which sits in between CompletionStage and CompletableFuture? > > > I've been waffling! Right now, I'm leaning towards having Java APIs return fully mutable CompletableFutures as Benjamin and Pavel suggested upthread. Why? Because a completion stage can be thought of as all of: > - a consumer of an upstream value Not this, CompletionStage doesn't specify how its value comes to be. > - a subscription to the event that makes the upstream value available, and Never this, since CompletionStage is not cancellable. > - the producer of a possible value for downstream consumers. This is exactly what it is. > Cancellation could be interpreted as a request to unsubscribe from upstream producer or a notification to downstream consumers that no value will be forthcoming, or both. CompletionStage is not cancellable so this concern does not exist. > > Here's a problem with jdk9 minimalCompletionStage: even if you are happy with the minimality of the source stage (perhaps it's shared) you might want downstream stages to be mutable, but the methods such as thenApply also create minimal completion stages. If you want to convert to a mutable future, you can try calling toCompletableFuture, but there's no guarantee that will work, even if it doesn't throw UOE. You can hand-construct a CompletableFuture which is then completed in a Runnable via thenRun, but then this is opaque to the CompletableFuture implementation, and implementation features such as stack overflow prevention will be ineffective. This is what I mean by a missing abstraction: There is no API to define a workflow which would be cancellable. Fortunately the basis (an SPI) of such thing will be available: j.u.c.Flow > > So right now I'm OK with e.g. Process#onExit simply returning CompletableFuture. I would not name it onExit since that signals, to me, a callback, and in which case it ought to take a callback as a parameter. Also, what does cancellation of onExit mean? Cheers, ? From huaming.li at oracle.com Tue Sep 27 09:22:55 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 27 Sep 2016 17:22:55 +0800 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" Message-ID: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> Please review the fix for JDK-8085192. The fix checks whether it fails to launch rmid due to "Port already in use" error, it will launch rmid again and again(20 times at most) until no such issue. bug: https://bugs.openjdk.java.net/browse/JDK-8085192 webrev: http://cr.openjdk.java.net/~mli/8085192/webrev.00/ Thank you -Hamlin From sergei.kovalev at oracle.com Tue Sep 27 15:03:31 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 27 Sep 2016 18:03:31 +0300 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies In-Reply-To: <2e3bb0dd-4e10-4bb4-1917-c2b8c2312034@oracle.com> References: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> <8a56f878-ee4b-0996-1d68-543d0aff90fe@oracle.com> <6ab8113e-9e34-5192-ed03-26e2eb272be3@oracle.com> <3ae62448-9d2c-ba7f-3d1d-a54a91ef5725@oracle.com> <422cf7fd-6975-d195-8ea7-aeae9f1f1a65@oracle.com> <2e3bb0dd-4e10-4bb4-1917-c2b8c2312034@oracle.com> Message-ID: Hi Alan, Looks like the root cause is jtreg issue. I'm going to close the CR as "Not an issue". Do you agree? Thank you for review. -- With best regards, Sergei 26.09.16 10:06, Alan Bateman wrote: > On 25/09/2016 16:16, Sergei Kovalev wrote: > >> If I've drop jdk.jartool, I faced with ClassNotFound error as I >> showed in #3 >> >> java.lang.ClassNotFoundException: >> jdk.security.jarsigner.JarSigner$Builder >> >> As you can see TEST.properties contains both: jdk.compiler and >> jdk.jartool > I didn't suggesting dropping jdk.jartool, I was suggesting changing > "@module java.compiler/javax.tools" to "@modules java.compiler". > > I think we need to start a new thread on jtreg-dev about this issue as > this is about test selection when TEST.properties is used to list the > required modules. > > -Alan From Roger.Riggs at Oracle.com Tue Sep 27 15:14:37 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 27 Sep 2016 11:14:37 -0400 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> Message-ID: Hi Hamlin, Marking each test that uses RMID.launch with the bugid does not seem to be meaningful since the bug is in the support infrastructure of the test and not specific to the test itself. It would be overkill to try to confirm the bug was fixed by running all those tests. Putting the bugid on 1 of the tests would be sufficient. JavaVM.java: - 134-138: Why define these private methods if they are not going to be used in outputContains? - 185: Its inefficient to convert the byte array to a string for when looking for each string. It would be cleaner for JavaVM to have public outputString and errorString methods and check them separately in RMID. (remove the JavaVM.outputContains method which hides which stream the string appeared in). (It would be a bigger change to change this to use the test library ProcessTools and OutputAnalyzer). Roger On 9/27/2016 5:22 AM, Hamlin Li wrote: > Please review the fix for JDK-8085192. The fix checks whether it fails > to launch rmid due to "Port already in use" error, it will launch rmid > again and again(20 times at most) until no such issue. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8085192 > webrev: > http://cr.openjdk.java.net/~mli/8085192/webrev.00/ > > Thank you > -Hamlin From Alan.Bateman at oracle.com Tue Sep 27 15:45:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Sep 2016 16:45:17 +0100 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> Message-ID: <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> On 26/09/2016 19:50, Lu, Yingqi wrote: > Alan, you mean readv0/write0 or read0/write0? I just want to make sure :-) Apologies, I meant each of the native methods where the decision to use direct I/O or not would be a lot more maintainable in Java. You'll see that there are already code paths for direct vs. heap buffers. > > Anyone else has other opinions on where is the best home for O_DIRECT flag? The flags under jdk.unsupported will eventually be removed in the future JDK release? > > If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify that for sure. > I think ExtendedOpenOption is the right place. It's still TDB as to whether to put these extensions but that should be transparent to anyone using this when on the class path. -Alan From roman.grigoriadi at oracle.com Tue Sep 27 15:52:16 2016 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Tue, 27 Sep 2016 17:52:16 +0200 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> Message-ID: <4ff0efee-19fe-8125-163c-5f2981941e39@oracle.com> Thanks for pointing Mandy, this package naming does apply to xerces types. I am not aware of any xerces package inside JAX-WS components. I checked saaj-ri code and commented on issue (JDK-8166745). If elimination of com.sun.org.apache.xerces.internal.* is possible, it would not be an easy fix to include with this code sync. Roman On 09/26/2016 10:41 PM, Mandy Chung wrote: > I brought this up a while back. SAAJ uses the java.xml's internal dom implementation. > > Just to double check: > Is the standalone referencing com.sun.org.apache.xerces.internal.**? Does the package naming apply only to the JAX-WS types (but not these xerces types)? > > I couldn?t find any issue tracking it and will file one. From ben.manes at gmail.com Tue Sep 27 00:21:38 2016 From: ben.manes at gmail.com (Benjamin Manes) Date: Mon, 26 Sep 2016 17:21:38 -0700 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: > > I don't see any support in junit or testng for multi-threaded tests. TestNG has basic support on @Test for running a test method concurrently. This assumes synchronous code that does not perform complex coordination, e.g. simple writes into a ConcurrentMap. Specifically the annotation provides "threadPoolSize", "invocationCount", and "invocationTimeOut". It does support multi-threaded test execution at the class or method level, or isolation by JVM forking, for faster build times. For test methods I most often use Awaitility with a JCiP-style test harness . Lots of other options out there depending on your needs. I do think Doug's original design statement, quoted earlier, is probably the best answer. It seems impossible for j.u.c. to provide the perfect API for everyone for any given scenario. Instead CF is a building block that you can limit or enhance by exposing a custom class. That may mean a proliferation of subsets or over use of returning CF, but that could happen regardless. Since it is easy to compose with lambdas, I consider the approach taken pragmatic and the best of unsatisfying options. Other than a few minor enhancements coming in JDK9, I'm pretty happy with CF as is. On Mon, Sep 26, 2016 at 4:18 PM, Martin Buchholz wrote: > > > On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang > wrote: > >> >>> >> Test methods, >>> >> >> Yeah, I thought so as well, but it turns out that when you have tons of >> async tests, not being able to start new tests until either that timeout or >> result makes for a very slow test suite, so that's why most serious test >> frameworks are growing support for dealing with async code. Then all you >> want to be able to limit is work-in-progress (sloppily called parallelism) >> > > I don't see any support in junit or testng for multi-threaded tests. > jtreg uses the strategy of having a set of reusable JVM processes, each of > which is running only one test at a time, which provides "pretty good" > isolation, and seems to work well. > > >> main methods >>> >> >> That's a common scenario, but one that can be solved by having >> non-daemonic pooled worker threads. >> > > Do you have docs for such a thread pool? > > >> and unix process reapers are all examples where it's reasonable to block >>> forever. >>> >> >> What about waitpid() + WNOHANG? >> > > Are you suggesting periodic polling is better than blocking? > > >> PPPPS: "I think it's unreasonable to not provide this for users >>>> (especially when we can do so more efficiently)." <- If efficiency is >>>> desired then blocking is definitely not the right solution. >>>> >>> >>> What about efficiently providing isComplete? >>> >> >> In my experience isComplete is virtually useless without being able to >> extract the value, in which case you may as well introduce a non-blocking >> `Optional poll()` >> > > Do you support adding the Polling methods from > http://www.scala-lang.org/api/2.12.0-RC1/scala/concurrent/Future.html > to CompletionStage, i.e. isDone and getNow? > > >> The result may already be available without actually blocking. It may >>> even be known to be available immediately. One would like to get the value >>> without additional allocation. >>> >> >> I've seen that use-case :), and it tends to either be a situation where >> the value is available by pure luck (or?scheduling artifacts) or when one >> is keeping CompletionStages where strict values could be kept instead >> (think rebinding a value on completion). >> >> Reading what your'e writing, may I dare propose that what you're after is >> something along the lines of a: PollableCompletionStage which sits in >> between CompletionStage and CompletableFuture? >> > > I've been waffling! Right now, I'm leaning towards having Java APIs > return fully mutable CompletableFutures as Benjamin and Pavel suggested > upthread. Why? Because a completion stage can be thought of as all of: > - a consumer of an upstream value > - a subscription to the event that makes the upstream value available, and > - the producer of a possible value for downstream consumers. > Cancellation could be interpreted as a request to unsubscribe from > upstream producer or a notification to downstream consumers that no value > will be forthcoming, or both. > > Here's a problem with jdk9 minimalCompletionStage: even if you are happy > with the minimality of the source stage (perhaps it's shared) you might > want downstream stages to be mutable, but the methods such as thenApply > also create minimal completion stages. If you want to convert to a mutable > future, you can try calling toCompletableFuture, but there's no guarantee > that will work, even if it doesn't throw UOE. You can hand-construct a > CompletableFuture which is then completed in a Runnable via thenRun, but > then this is opaque to the CompletableFuture implementation, and > implementation features such as stack overflow prevention will be > ineffective. > > So right now I'm OK with e.g. Process#onExit simply returning > CompletableFuture. > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > From akarnokd at gmail.com Tue Sep 27 08:53:10 2016 From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=) Date: Tue, 27 Sep 2016 10:53:10 +0200 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: <02e401d21722$59ec48f0$0dc4dad0$@aapt.net.au> Message-ID: If not a straight blocking method, a fluent conversion method to type R could be useful IMO: R to(Function, R> converter) { return converter.apply(this); } This way, who needs a blocking get can have a function prepared with a blocking operation: Function, T> blockingGet() { cs -> { Object[] result = { null, null }; CountDownLatch cdl = new CountDownLatch(); cs.whenComplete((v, e) -> { if (e != null) { result[1] = e; } else { result[0] = v; } cdl.countDown(); }); try { cdl.await(); } catch (InterruptedException ex) { throw new RuntimeException(ex); } if (result[1] != null) { throw new RuntimeException(result[1]); } return result[0]; } } T t = cs.to(blockingGet()); while others can convert it to a more enabled dataflow system: cs.to(Flux::fromFuture) .filter(v -> v < 50) .defaultIfEmpty(-10) .subscribe(System.out::println, Throwable::printStackTrace); 2016-09-27 10:39 GMT+02:00 Viktor Klang : > Seems legit > > -- > Cheers, > ? > > On Sep 26, 2016 23:29, "Attila Szegedi" wrote: > >> Not at all, you could just have a call to cancel() block until the future >> completes. >> >> *ducks* >> >> Attila. >> >> > On 25 Sep 2016, at 16:34, Viktor Klang wrote: >> > >> > If that truely is the case then the only way of implementing a readonly >> > Future is by throwing an exception from cancel... >> > >> > -- >> > Cheers, >> > ? >> > >> > On Sep 25, 2016 4:20 PM, "Joe Bowbeer" wrote: >> > >> >> This statement regarding what happens after cancel is called is >> correct: >> >> >> >> "*After this method returns, subsequent calls to **isDone**() will >> always >> >> return true*. Subsequent calls to isCancelled() will always return true >> >> if this method returned true." >> >> >> >> After cancel returns, the future is completed, hence isDone. If cancel >> >> returns true, i.e. it was cancelled, then isCancelled returns true. >> But, >> >> for example if the future is already completed when cancel is called, >> then >> >> cancel will return false and isCancelled will return false. >> >> >> >> On Sep 25, 2016 6:49 AM, "David Holmes" >> wrote: >> >> >> >>> I think that was meant to read ?After this method returns _*true*_, >> >>> subsequent calls ?? >> >>> >> >>> >> >>> >> >>> David >> > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > -- Best regards, David Karnok From yingqi.lu at intel.com Tue Sep 27 16:57:06 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Tue, 27 Sep 2016 16:57:06 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> Alan, Thank you for the explanation, we will modify the code accordingly and send it out soon for review. Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, September 27, 2016 8:45 AM To: Lu, Yingqi ; core-libs-dev at openjdk.java.net Cc: nio-dev at openjdk.java.net Subject: Re: Proposal for adding O_DIRECT support into JDK 9 On 26/09/2016 19:50, Lu, Yingqi wrote: > Alan, you mean readv0/write0 or read0/write0? I just want to make sure > :-) Apologies, I meant each of the native methods where the decision to use direct I/O or not would be a lot more maintainable in Java. You'll see that there are already code paths for direct vs. heap buffers. > > Anyone else has other opinions on where is the best home for O_DIRECT flag? The flags under jdk.unsupported will eventually be removed in the future JDK release? > > If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify that for sure. > I think ExtendedOpenOption is the right place. It's still TDB as to whether to put these extensions but that should be transparent to anyone using this when on the class path. -Alan From volker.simonis at gmail.com Tue Sep 27 17:49:18 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 Sep 2016 19:49:18 +0200 Subject: RFR: JEP draft for Linux/s3990x port Message-ID: Hi, can you please review and endorse the following draft JEP for the integration of the Linux/s390x port into the jkd9 master repository: https://bugs.openjdk.java.net/browse/JDK-8166730 As detailed in the JEP, the Linux/s390x requires very few shared changes and we therefore don't foresee any impact on the existing platforms at all. Following you can find a short description of the planned changes: hotspot: ======= Out for review: 8166560: [s390] Basic enablement of s390 port. http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/ Reviewed: 8166562: C2: Suppress relocations in scratch emit. http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01/ Will send RFR soon (depends on 8166560): 8166561: [s390] Adaptions needed for s390 port in C1 and C2. http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01 We are still investigating the need of these shared changes: http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000011-pass_PC_to_retAddrOffset.patch http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000016-constant_table_offset.patch And finally the patch with the s390x-only platform files. We are still editing these to get them into OpenJdk style and shape. Hotspot passes most jck, jtreg and spec tests with these. http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000101-zFiles.patch top-level repository: =============== The following is just adding some s390x specific compiler flags to flags.m4 8166800: [s390] Top-level build changes required for Linux/s390x https://bugs.openjdk.java.net/browse/JDK-8166800 jdk repository: ============ This one just adds a new jvm.cfg file for s390x 8166801: [s390] Add jvm.cfg file for Linux/s390x https://bugs.openjdk.java.net/browse/JDK-8166801 And finally we plan to do one more change which fixes the jtreg test on Linux/s390x. But this is mainly for the correct detection of the platform and for excluding the tests which are not appropriate for s390x. Thank you and best regards, Volker From volker.simonis at gmail.com Tue Sep 27 17:49:26 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 Sep 2016 19:49:26 +0200 Subject: RFR(M): 8166560: [s390] Basic enablement of s390 port. In-Reply-To: <903643bb-9a78-5254-fd0e-108da29802bd@oracle.com> References: <903643bb-9a78-5254-fd0e-108da29802bd@oracle.com> Message-ID: Hi Alan, I've created a JEP. You can find it here: https://bugs.openjdk.java.net/browse/JDK-8166730 I've also just sent an RFR for the JEP to the various list with some more detailed information. It would be great if you could review it for the class library. The changes to the jdk-repo are really minimal - just adding a jvm.cfg file for s390x. Thank you and best regards, Volker On Sat, Sep 24, 2016 at 12:08 PM, Alan Bateman wrote: > On 23/09/2016 06:52, Lindenmaier, Goetz wrote: > >> Hi, >> >> This change is part of the s390 port. It contains some basic adaptions >> needed for a full hotspot port for linux s390x. >> >> > Out of curiosity, is there is JEP for the Linux/S390 port? There were JEPs > for the Linux/AArch64 and PowerPC/AIX ports and just wondering if there is > one coming for the S390 port too? > > -Alan From volker.simonis at gmail.com Tue Sep 27 17:57:53 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 Sep 2016 19:57:53 +0200 Subject: RFR(M): 8166560: [s390] Basic enablement of s390 port. In-Reply-To: References: Message-ID: On Fri, Sep 23, 2016 at 8:11 AM, David Holmes wrote: > Hi Goetz, > > I see a change not related directly to S390 ie change from ARM to ARM32 in > src/os/linux/vm/os_linux.cpp > The change looks a little confusing because Goetz reordered the ifdef cascades alphabetically (which I think is good). Besides that, the only real change not related to s390 is indeed the change from ARM to ARM32 which happend two times in the file. @Goetz: have you done this intentionally? > It will be a while before I can go through this in any detail. > > David > > > On 23/09/2016 3:52 PM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> This change is part of the s390 port. It contains some basic adaptions >> needed for a full hotspot port for linux s390x. >> >> It defines the required macros, platform names and includes. >> >> The s390 port calles CodeCache::contains() in current_frame(), which is >> used in NMT. As NMT already collects stack traces before the CodeCache is >> initialized, contains() needs a check for this. >> >> Wherever a row of platforms are listed, I sorted them alphabetically. >> >> The jdk requires the file jvm.cfg. >> >> Please review. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/ >> http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/jdk.wr01/ >> >> Best regards, >> Goetz. >> > From brent.christian at oracle.com Tue Sep 27 18:07:46 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 27 Sep 2016 11:07:46 -0700 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> Message-ID: <73b5761e-b658-d1bb-8ee0-f15518ba87c0@oracle.com> Thanks for making some improvements to these intermittent RMI tests. I agree with Roger that I don't think we want to add the id to the @bug of every test. Also, it looks like there's an indentation change in JavaVM.java: 53 public static final long POLLTIME_MS = 100L; (I believe running webrev with '-b' will include whitespace changes.) Thanks, -Brent On 9/27/16 2:22 AM, Hamlin Li wrote: > Please review the fix for JDK-8085192. The fix checks whether it fails > to launch rmid due to "Port already in use" error, it will launch rmid > again and again(20 times at most) until no such issue. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8085192 > webrev: > http://cr.openjdk.java.net/~mli/8085192/webrev.00/ > > Thank you > -Hamlin From vladimir.kozlov at oracle.com Tue Sep 27 18:15:11 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Sep 2016 11:15:11 -0700 Subject: RFR: JEP draft for Linux/s3990x port In-Reply-To: References: Message-ID: <72ddbd25-c7df-b02a-3827-d431f286c795@oracle.com> On 9/27/16 10:49 AM, Volker Simonis wrote: > Hi, > > can you please review and endorse the following draft JEP for the > integration of the Linux/s390x port into the jkd9 master repository: > > https://bugs.openjdk.java.net/browse/JDK-8166730 Good. Add links to webrevs in a comment. It will help to get umbrella FC extension approval. > > As detailed in the JEP, the Linux/s390x requires very few shared > changes and we therefore don't foresee any impact on the existing > platforms at all. Following you can find a short description of the > planned changes: > > hotspot: > ======= > > Out for review: > 8166560: [s390] Basic enablement of s390 port. > http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/ > > Reviewed: > 8166562: C2: Suppress relocations in scratch emit. > http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01/ > > Will send RFR soon (depends on 8166560): > 8166561: [s390] Adaptions needed for s390 port in C1 and C2. > http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01 Wrong link. Thanks, Vladimir > > We are still investigating the need of these shared changes: > http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000011-pass_PC_to_retAddrOffset.patch > http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000016-constant_table_offset.patch > > And finally the patch with the s390x-only platform files. We are still > editing these to get them into OpenJdk style and shape. > Hotspot passes most jck, jtreg and spec tests with these. > http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000101-zFiles.patch > > top-level repository: > =============== > > The following is just adding some s390x specific compiler flags to flags.m4 > 8166800: [s390] Top-level build changes required for Linux/s390x > https://bugs.openjdk.java.net/browse/JDK-8166800 > > jdk repository: > ============ > > This one just adds a new jvm.cfg file for s390x > 8166801: [s390] Add jvm.cfg file for Linux/s390x > https://bugs.openjdk.java.net/browse/JDK-8166801 > > > And finally we plan to do one more change which fixes the jtreg test > on Linux/s390x. But this is mainly for the correct detection of the > platform and for excluding the tests which are not appropriate for > s390x. > > Thank you and best regards, > Volker > From naoto.sato at oracle.com Tue Sep 27 18:43:49 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 27 Sep 2016 11:43:49 -0700 Subject: [9] RFR: 8166645: Include locales plugin throws InternalError with "*" specified. Message-ID: Hello, Please review the changes for the following issue: https://bugs.openjdk.java.net/browse/JDK-8166645 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8166645/webrev.00/ The fix makes sure that the supported language tags created by the plugin are in the original supported language tags. Naoto From steve.drach at oracle.com Tue Sep 27 19:31:54 2016 From: steve.drach at oracle.com (Steve Drach) Date: Tue, 27 Sep 2016 12:31:54 -0700 Subject: RFR: 8165944 jar utility doesn't process more than one -C argument In-Reply-To: References: Message-ID: <3EA9BD36-9BFB-4BBF-99F5-F0BB423F113F@oracle.com> After a discussion with Paul Sandoz, I?ve simplified and, hopefully, thus clarified the changeset. The new webrev is http://cr.openjdk.java.net/~sdrach/8165944/webrev.01/ > On Sep 26, 2016, at 12:31 PM, Steve Drach wrote: > > Hi, > > Please review these changes to the jar tool to fix a capability regression I introduced in an earlier revision. The issue is that this > > $ jar -cf test.jar -C test1 . -C test2 . > > only puts the files under test1 in the jar and ignores the files under test2. The DoubleCs test verified the problem and the solution. > > issue: https://bugs.openjdk.java.net/browse/JDK-8165944 > webrev: http://cr.openjdk.java.net/~sdrach/8165944/webrev.00/ > > Thanks, > Steve > From mandy.chung at oracle.com Wed Sep 28 00:58:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 27 Sep 2016 17:58:24 -0700 Subject: Review Request: JDK-8166238 Update jdeps for GNU-style long form options Message-ID: <82C4F2FE-D612-4E79-8594-4C749879DBBB@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166238/webrev.00/index.html This patch renames the following options added in JDK 9 jdeps --gen-module-info => ?generate-module-info -inverse => ?-inverse -requires => ?-require and also adds the long-form option corresponding to a few existing options: ?-api-only ?-dot-output -?jdk-internals ?-package ?-regex -?version Mandy From huaming.li at oracle.com Wed Sep 28 03:22:20 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 28 Sep 2016 11:22:20 +0800 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> Message-ID: Hi Roger, Thank you for reviewing. Please check the new webrev: http://cr.openjdk.java.net/~mli/8085192/webrev.01/, and comments inline below. On 2016/9/27 23:14, Roger Riggs wrote: > Hi Hamlin, > > Marking each test that uses RMID.launch with the bugid does not seem > to be meaningful > since the bug is in the support infrastructure of the test and not > specific to the test itself. > It would be overkill to try to confirm the bug was fixed by running > all those tests. > Putting the bugid on 1 of the tests would be sufficient. Remove all bug ids except of the one in CheckImplClassLoader.java. > > JavaVM.java: > > - 134-138: Why define these private methods if they are not going to > be used in outputContains? > > - 185: Its inefficient to convert the byte array to a string for when > looking for each string. > It would be cleaner for JavaVM to have public outputString and > errorString methods > and check them separately in RMID. > (remove the JavaVM.outputContains method which hides which stream > the string appeared in). Fixed. > (It would be a bigger change to change this to use the test library > ProcessTools and OutputAnalyzer). Thank you suggestion. Yes, you're right, it will be a little bit complicated to use ProcessTools and OutputAnalyzer in this situation, need to modify these classes, because they will block until process terminates. So I prefer to use current implementation, as it's simple and clear. Thank you -Hamlin > > Roger > > > On 9/27/2016 5:22 AM, Hamlin Li wrote: >> Please review the fix for JDK-8085192. The fix checks whether it >> fails to launch rmid due to "Port already in use" error, it will >> launch rmid again and again(20 times at most) until no such issue. >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8085192 >> webrev: >> http://cr.openjdk.java.net/~mli/8085192/webrev.00/ >> >> Thank you >> -Hamlin > From huaming.li at oracle.com Wed Sep 28 03:24:41 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 28 Sep 2016 11:24:41 +0800 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: <73b5761e-b658-d1bb-8ee0-f15518ba87c0@oracle.com> References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> <73b5761e-b658-d1bb-8ee0-f15518ba87c0@oracle.com> Message-ID: Hi Brent, Thank you for reviewing. Please check the new webrev: http://cr.openjdk.java.net/~mli/8085192/webrev.01/, and comments inline below. On 2016/9/28 2:07, Brent Christian wrote: > Thanks for making some improvements to these intermittent RMI tests. > > I agree with Roger that I don't think we want to add the id to the > @bug of every test. Yes, I think it's reasonable too. Fixed. > > Also, it looks like there's an indentation change in JavaVM.java: > > 53 public static final long POLLTIME_MS = 100L; > > (I believe running webrev with '-b' will include whitespace changes.) Fixed, thank you for the tip, new webrev is generated with "-b". :-) Thank you -Hamlin > > Thanks, > -Brent > > On 9/27/16 2:22 AM, Hamlin Li wrote: >> Please review the fix for JDK-8085192. The fix checks whether it fails >> to launch rmid due to "Port already in use" error, it will launch rmid >> again and again(20 times at most) until no such issue. >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8085192 >> webrev: >> http://cr.openjdk.java.net/~mli/8085192/webrev.00/ >> >> Thank you >> -Hamlin From michael.haupt at oracle.com Wed Sep 28 06:20:35 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 28 Sep 2016 08:20:35 +0200 Subject: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API In-Reply-To: <91966279-F402-4A69-B802-E0BC12E458EA@oracle.com> References: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> <7C0D47C4-233E-40CA-BE87-82C0FD6378EE@oracle.com> <3FA2149A-C14D-466D-BF5E-2FCAF958F6D4@oracle.com> <91966279-F402-4A69-B802-E0BC12E458EA@oracle.com> Message-ID: Hello, reviews, please ... ? Thanks, Michael > Am 26.09.2016 um 21:01 schrieb Michael Haupt : > > Hi John, all, > > thank you very much for your reviews - may I ask for a second round? > > The updated webrev is at http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ ; > an accompanying specdiff, at http://cr.openjdk.java.net/~mhaupt/8151179/specdiff.01/ . > > Thanks, > > Michael > >> Am 16.08.2016 um 01:39 schrieb John Rose : >> >> I'm working on this. The javadoc has some re-filling which creates lots of diffs of whitespace only, which makes things go a little slower. >> >> I am trying to like the cleaner, more restricted semantics for the utility methods, but they really do some harm to the use cases. The really notable change is the loss of defaulting behavior of the first parameter to iteratedLoop, which was List::iterator. That was intended to corresponding to the for-each syntax, and it is hard (and probably non-performant) to ask the user to rebuild a MH for Iterable::iterator at each use site for iteratedLoop. >> >> ? John > > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing practices and products that help protect the environment > From john.r.rose at oracle.com Wed Sep 28 06:26:16 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 27 Sep 2016 23:26:16 -0700 Subject: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API In-Reply-To: <91966279-F402-4A69-B802-E0BC12E458EA@oracle.com> References: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> <7C0D47C4-233E-40CA-BE87-82C0FD6378EE@oracle.com> <3FA2149A-C14D-466D-BF5E-2FCAF958F6D4@oracle.com> <91966279-F402-4A69-B802-E0BC12E458EA@oracle.com> Message-ID: <78669666-758C-4B16-A1C6-44EC2042E001@oracle.com> On Sep 26, 2016, at 12:01 PM, Michael Haupt wrote: > > thank you very much for your reviews - may I ask for a second round? > > The updated webrev is at http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ >; > an accompanying specdiff, at http://cr.openjdk.java.net/~mhaupt/8151179/specdiff.01/ >. Reviewed. This is a huge leap forward. A few small comments to consider: In FacLoop, the argument k should be named acc: +- int fin(int i, int k) { return k; } ++ int fin(int i, int acc) { return acc; } This affects *two* files, a JDE.java and MHs.java. Fix awkwardness: s/A similar same example/A similar example I'm really glad to see the FacLoop example, BTW; I think it is often the right pattern to use. There is a redundant phrase in the javadoc which reads oddly: + A non-void value returned from the body (which must also be of type V) But the previous line just defined V as the return value of the body: + If the body handle returns a non-void type V, a leading loop iteration variable of that type is also present. Seems like you can just omit "(which must also be of type V)" or shorten it to "(of type V)" or perhaps "(which is the leading iteration variable)". In any case, the role of "V" is fully described in the bullet item list that follows. The whole section beginning "Example. As a consequence of step 1A above" is kind of fluffy. It doesn't add much, although it is technically correct. You could take it out if you feel the same. (The fact that the "pred" guys are assumed to take no arguments means that it's a pretty useless loop.) I don't mind leaving it in, though, in the interests of converging this review process! Thank you for putting in the extra working examples. That will really help users pick the right patterns. ? John From goetz.lindenmaier at sap.com Wed Sep 28 10:26:47 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 28 Sep 2016 10:26:47 +0000 Subject: RFR(M): 8166560: [s390] Basic enablement of s390 port. In-Reply-To: References: Message-ID: <4c1b77efa5014efc94d31a20e51ae657@DEWDFE13DE50.global.corp.sap> Hi, here a new webrev for this change: http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr02/ I reverted the major reorderings in macros.hpp and os_linux.cpp. David asked me to do so, and I guess it makes reviewing more simple. Also this fixes the issue spotted by David which actually was wrong. The other renaming of ARM to ARM32 was correct, though, as AARCH64 is defined in both ARM 64-bit ports, and is checked before. So the existing case checking ARM is only reached if !LP64. I documented this ... Also I removed the change in mutex.hpp. Maybe we contribute the full change this was part of, but independent of the s390 port. I withdraw the part of the change to jdk introducing jvm.cfg. Volker wants to do a separate change for this. Best regards, Goetz. > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Dienstag, 27. September 2016 19:58 > To: David Holmes > Cc: Lindenmaier, Goetz ; hotspot- > dev at openjdk.java.net; core-libs-dev > Subject: Re: RFR(M): 8166560: [s390] Basic enablement of s390 port. > > On Fri, Sep 23, 2016 at 8:11 AM, David Holmes > wrote: > > Hi Goetz, > > > > I see a change not related directly to S390 ie change from ARM to ARM32 in > > src/os/linux/vm/os_linux.cpp > > > > The change looks a little confusing because Goetz reordered the ifdef > cascades alphabetically (which I think is good). > > Besides that, the only real change not related to s390 is indeed the > change from ARM to ARM32 which happend two times in the file. > > @Goetz: have you done this intentionally? > > > It will be a while before I can go through this in any detail. > > > > David > > > > > > On 23/09/2016 3:52 PM, Lindenmaier, Goetz wrote: > >> > >> Hi, > >> > >> This change is part of the s390 port. It contains some basic adaptions > >> needed for a full hotspot port for linux s390x. > >> > >> It defines the required macros, platform names and includes. > >> > >> The s390 port calles CodeCache::contains() in current_frame(), which is > >> used in NMT. As NMT already collects stack traces before the CodeCache > is > >> initialized, contains() needs a check for this. > >> > >> Wherever a row of platforms are listed, I sorted them alphabetically. > >> > >> The jdk requires the file jvm.cfg. > >> > >> Please review. I please need a sponsor. > >> http://cr.openjdk.java.net/~goetz/wr16/8166560- > basic_s390/hotspot.wr01/ > >> http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/jdk.wr01/ > >> > >> Best regards, > >> Goetz. > >> > > From claes.redestad at oracle.com Wed Sep 28 10:56:36 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Sep 2016 12:56:36 +0200 Subject: RFR: 8166287: MultiReleaseJarAPI.isMultiReleaseJar(): failure java.nio.file.AccessDeniedException: custom-mr.jar Message-ID: Hi, recently added test cases to MultiReleaseJarAPI can cause an AccessDeniedException on some Windows systems, and using a distinct name of the jar generated for each test should avoid this. webrev: http://cr.openjdk.java.net/~redestad/8166287/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8166287 Since the only hosts I've found where the stars align to cause this issue are some used in our nightly hotspot testing, I intend to push this to jdk9/hs - unless anyone objects. Thanks! /Claes From michael.haupt at oracle.com Wed Sep 28 11:46:08 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 28 Sep 2016 13:46:08 +0200 Subject: RFR: 8166287: MultiReleaseJarAPI.isMultiReleaseJar(): failure java.nio.file.AccessDeniedException: custom-mr.jar In-Reply-To: References: Message-ID: Hi Claes, thumbs up. Best, Michael > Am 28.09.2016 um 12:56 schrieb Claes Redestad : > > Hi, > > recently added test cases to MultiReleaseJarAPI can cause an AccessDeniedException on some Windows systems, and using a distinct name of the jar generated for each test should avoid this. > > webrev: http://cr.openjdk.java.net/~redestad/8166287/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8166287 > > Since the only hosts I've found where the stars align to cause this issue are some used in our nightly hotspot testing, I intend to push this to jdk9/hs - unless anyone objects. > > Thanks! > > /Claes -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From claes.redestad at oracle.com Wed Sep 28 11:48:37 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Sep 2016 13:48:37 +0200 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining Message-ID: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> Hi, as discussed recently on hotspot-compiler-dev[1], having a private class with no default constructor can lead to C2 failing to inline, due to the synthetic bridge constructor using a dummy argument of an uninitialized class. This is really a problem in C2, as well as something which could ultimately be resolved by nestmates... However, there is an easy workaround in adding an empty package-private constructor. In the most recently found case - a microbenchmark stressing MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead to a 2.5-3x speedup. This is me asking nicely to do a quick-fix for this in java.util.ArrayList$Itr now: Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ Thanks! /Claes [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html From michael.haupt at oracle.com Wed Sep 28 11:51:18 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 28 Sep 2016 13:51:18 +0200 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> Message-ID: Hi Claes, yes please. Thumbs up. :-) Best, Michael > Am 28.09.2016 um 13:48 schrieb Claes Redestad : > > Hi, > > as discussed recently on hotspot-compiler-dev[1], having a private class with no default constructor can lead to C2 failing to inline, due to the synthetic bridge constructor using a dummy argument of an uninitialized class. This is really a problem in C2, as well as something which could ultimately be resolved by nestmates... > > However, there is an easy workaround in adding an empty package-private constructor. In the most recently found case - a microbenchmark stressing MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead to a 2.5-3x speedup. > > This is me asking nicely to do a quick-fix for this in java.util.ArrayList$Itr now: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 > Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ > > Thanks! > > /Claes > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Wed Sep 28 11:58:12 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 28 Sep 2016 13:58:12 +0200 Subject: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API In-Reply-To: <78669666-758C-4B16-A1C6-44EC2042E001@oracle.com> References: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> <7C0D47C4-233E-40CA-BE87-82C0FD6378EE@oracle.com> <3FA2149A-C14D-466D-BF5E-2FCAF958F6D4@oracle.com> <91966279-F402-4A69-B802-E0BC12E458EA@oracle.com> <78669666-758C-4B16-A1C6-44EC2042E001@oracle.com> Message-ID: Hi John, thank you very much - some comments are inlined below. > Am 28.09.2016 um 08:26 schrieb John Rose : > > Reviewed. This is a huge leap forward. > > A few small comments to consider: > > In FacLoop, the argument k should be named acc: > +- int fin(int i, int k) { return k; } > ++ int fin(int i, int acc) { return acc; } > > This affects *two* files, a JDE.java and MHs.java. Fixed. > Fix awkwardness: s/A similar same example/A similar example Fixed. > I'm really glad to see the FacLoop example, BTW; I think it is often the right pattern to use. > > There is a redundant phrase in the javadoc which reads oddly: > > + A non-void value returned from the body (which must also be of type V) > > But the previous line just defined V as the return value of the body: > + If the body handle returns a non-void type V, a leading loop iteration variable of that type is also present. > > Seems like you can just omit "(which must also be of type V)" or shorten it to "(of type V)" or perhaps "(which is the leading iteration variable)". In any case, the role of "V" is fully described in the bullet item list that follows. Right; I've changed this to "(of type V)". > The whole section beginning "Example. As a consequence of step 1A above" is kind of fluffy. It doesn't add much, although it is technically correct. You could take it out if you feel the same. (The fact that the "pred" guys are assumed to take no arguments means that it's a pretty useless loop.) I don't mind leaving it in, though, in the interests of converging this review process! I'd rather leave it in; I think I added it at some point in response to a clarification request from JCK. > Thank you for putting in the extra working examples. That will really help users pick the right patterns. Yes. It's interesting new API that deserves some examples. ;-) I'll push shortly, with the aforementioned modifications. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Alan.Bateman at oracle.com Wed Sep 28 12:03:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Sep 2016 13:03:53 +0100 Subject: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies In-Reply-To: References: <82b6c2e5-d8d5-f0e2-c8e3-b0f96e33021e@oracle.com> <6683b09e-8d13-c3e3-4d15-483f8d342876@oracle.com> <8a56f878-ee4b-0996-1d68-543d0aff90fe@oracle.com> <6ab8113e-9e34-5192-ed03-26e2eb272be3@oracle.com> <3ae62448-9d2c-ba7f-3d1d-a54a91ef5725@oracle.com> <422cf7fd-6975-d195-8ea7-aeae9f1f1a65@oracle.com> <2e3bb0dd-4e10-4bb4-1917-c2b8c2312034@oracle.com> Message-ID: <7196686a-b489-9d33-039b-3a8004405ccc@oracle.com> On 27/09/2016 16:03, Sergei Kovalev wrote: > Hi Alan, > > Looks like the root cause is jtreg issue. I'm going to close the CR as > "Not an issue". Do you agree? I agree, esp. since this is jtreg bug is already fixed and so the issue will go away once a new version is released/promoted. -Alan From Alan.Bateman at oracle.com Wed Sep 28 12:10:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Sep 2016 13:10:02 +0100 Subject: RFR: 8166287: MultiReleaseJarAPI.isMultiReleaseJar(): failure java.nio.file.AccessDeniedException: custom-mr.jar In-Reply-To: References: Message-ID: On 28/09/2016 11:56, Claes Redestad wrote: > Hi, > > recently added test cases to MultiReleaseJarAPI can cause an > AccessDeniedException on some Windows systems, and using a distinct > name of the jar generated for each test should avoid this. > > webrev: http://cr.openjdk.java.net/~redestad/8166287/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8166287 > > Since the only hosts I've found where the stars align to cause this > issue are some used in our nightly hotspot testing, I intend to push > this to jdk9/hs - unless anyone objects. This looks good. I assume if you push it to jdk9/dev then it will be pull down to jdk9/hs quickly. -Alan From forax at univ-mlv.fr Wed Sep 28 12:14:17 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 28 Sep 2016 12:14:17 +0000 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> Message-ID: <4F4C205E-C96C-47B1-A147-7B284758B499@univ-mlv.fr> yes, thumb up. R?mi On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt wrote: >Hi Claes, > >yes please. Thumbs up. :-) > >Best, > >Michael > >> Am 28.09.2016 um 13:48 schrieb Claes Redestad >: >> >> Hi, >> >> as discussed recently on hotspot-compiler-dev[1], having a private >class with no default constructor can lead to C2 failing to inline, due >to the synthetic bridge constructor using a dummy argument of an >uninitialized class. This is really a problem in C2, as well as >something which could ultimately be resolved by nestmates... >> >> However, there is an easy workaround in adding an empty >package-private constructor. In the most recently found case - a >microbenchmark stressing MethodHandles.iteratedLoop - adding this to >ArrayList$Itr lead to a 2.5-3x speedup. >> >> This is me asking nicely to do a quick-fix for this in >java.util.ArrayList$Itr now: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 >> Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ >> >> Thanks! >> >> /Claes >> >> [1] >http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html > >-- > > >Dr. Michael Haupt | Principal Member of Technical Staff >Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >Oracle Java Platform Group | LangTools Team | Nashorn >Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, >Germany > >ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, >D-80992 M?nchen >Registergericht: Amtsgericht M?nchen, HRA 95603 > >Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering >163/167, 3543 AS Utrecht, Niederlande >Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 >Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing >practices and products that help protect the environment -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From sergei.kovalev at oracle.com Wed Sep 28 12:16:21 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 28 Sep 2016 15:16:21 +0300 Subject: RFR(s): 8166841: Unused import causes test failure on compilation in java.text tests Message-ID: Hi Team, Could you please review very small fix? BugID: https://bugs.openjdk.java.net/browse/JDK-8166841 WebRev: http://cr.openjdk.java.net/~skovalev/8166841/webrev.00/ Issue: In case of usage command line option "--limit-modules java.base" for javac two tests fail on compilation. Root cause: unused import java.awt.*. Solution: Organize imports. Tested locally using jtreg test suite. -- With best regards, Sergei From claes.redestad at oracle.com Wed Sep 28 12:20:44 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Sep 2016 14:20:44 +0200 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: <4F4C205E-C96C-47B1-A147-7B284758B499@univ-mlv.fr> References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> <4F4C205E-C96C-47B1-A147-7B284758B499@univ-mlv.fr> Message-ID: Thanks for the quick reviews! /Claes On 2016-09-28 14:14, Remi Forax wrote: > yes, > thumb up. > > R?mi > > > On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt wrote: >> Hi Claes, >> >> yes please. Thumbs up. :-) >> >> Best, >> >> Michael >> >>> Am 28.09.2016 um 13:48 schrieb Claes Redestad >> : >>> Hi, >>> >>> as discussed recently on hotspot-compiler-dev[1], having a private >> class with no default constructor can lead to C2 failing to inline, due >> to the synthetic bridge constructor using a dummy argument of an >> uninitialized class. This is really a problem in C2, as well as >> something which could ultimately be resolved by nestmates... >>> However, there is an easy workaround in adding an empty >> package-private constructor. In the most recently found case - a >> microbenchmark stressing MethodHandles.iteratedLoop - adding this to >> ArrayList$Itr lead to a 2.5-3x speedup. >>> This is me asking nicely to do a quick-fix for this in >> java.util.ArrayList$Itr now: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 >>> Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html >> >> -- >> >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Java Platform Group | LangTools Team | Nashorn >> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, >> Germany >> >> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, >> D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering >> 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher >> Oracle is committed to developing >> practices and products that help protect the environment From ivan.gerasimov at oracle.com Wed Sep 28 12:29:47 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 28 Sep 2016 15:29:47 +0300 Subject: RFR(s): 8166841: Unused import causes test failure on compilation in java.text tests In-Reply-To: References: Message-ID: <9186667f-5d79-a8fa-5220-fb7b9a698aee@oracle.com> This looks good! With kind regards, Ivan On 28.09.2016 15:16, Sergei Kovalev wrote: > Hi Team, > > Could you please review very small fix? > > BugID: https://bugs.openjdk.java.net/browse/JDK-8166841 > WebRev: http://cr.openjdk.java.net/~skovalev/8166841/webrev.00/ > > Issue: In case of usage command line option "--limit-modules > java.base" for javac two tests fail on compilation. > Root cause: unused import java.awt.*. > Solution: Organize imports. > Tested locally using jtreg test suite. > From claes.redestad at oracle.com Wed Sep 28 12:30:20 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Sep 2016 14:30:20 +0200 Subject: RFR(s): 8166841: Unused import causes test failure on compilation in java.text tests In-Reply-To: References: Message-ID: <08f6339e-dba1-e211-e077-6426bfb7019c@oracle.com> +1 /Claes On 2016-09-28 14:16, Sergei Kovalev wrote: > Hi Team, > > Could you please review very small fix? > > BugID: https://bugs.openjdk.java.net/browse/JDK-8166841 > WebRev: http://cr.openjdk.java.net/~skovalev/8166841/webrev.00/ > > Issue: In case of usage command line option "--limit-modules > java.base" for javac two tests fail on compilation. > Root cause: unused import java.awt.*. > Solution: Organize imports. > Tested locally using jtreg test suite. > From claes.redestad at oracle.com Wed Sep 28 12:31:47 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Sep 2016 14:31:47 +0200 Subject: RFR: 8166287: MultiReleaseJarAPI.isMultiReleaseJar(): failure java.nio.file.AccessDeniedException: custom-mr.jar In-Reply-To: References: Message-ID: <1cf33e28-abc2-e874-2ce0-bdb52c6bcb38@oracle.com> Michael, Alan, thanks for reviewing. Sure, might as well push to jdk9/dev /Claes On 2016-09-28 14:10, Alan Bateman wrote: > On 28/09/2016 11:56, Claes Redestad wrote: > >> Hi, >> >> recently added test cases to MultiReleaseJarAPI can cause an >> AccessDeniedException on some Windows systems, and using a distinct >> name of the jar generated for each test should avoid this. >> >> webrev: http://cr.openjdk.java.net/~redestad/8166287/webrev.01/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8166287 >> >> Since the only hosts I've found where the stars align to cause this >> issue are some used in our nightly hotspot testing, I intend to push >> this to jdk9/hs - unless anyone objects. > This looks good. I assume if you push it to jdk9/dev then it will be > pull down to jdk9/hs quickly. > > -Alan From peter.levart at gmail.com Wed Sep 28 12:44:10 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 28 Sep 2016 14:44:10 +0200 Subject: RFR: 8166842: String.hashCode() has a non-benign data race Message-ID: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> Hi, According to discussion here: http://cs.oswego.edu/pipermail/concurrency-interest/2016-September/015414.html it seems compact strings introduced (at least theoretical) non-benign data race into String.hasCode() method. Here is a proposed patch: http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ For the bug: https://bugs.openjdk.java.net/browse/JDK-8166842 JDK 8 did not have this problem, so no back-porting necessary. Regards, Peter From shade at redhat.com Wed Sep 28 12:47:35 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 28 Sep 2016 14:47:35 +0200 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> Message-ID: <75d3cb1c-5aa9-2abf-d243-18f84bb43e4a@redhat.com> On 09/28/2016 02:44 PM, Peter Levart wrote: > http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ +1, thanks. This is partially my fault for not spotting it earlier during the Compact Strings work. -Aleksey From kumar.x.srinivasan at oracle.com Wed Sep 28 13:03:22 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 28 Sep 2016 06:03:22 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> Message-ID: <57EBBF9A.6010103@oracle.com> Hello Thomas, Volker, > > Hi Kumar, > > > On 9/16/2016 10:34 AM, Volker Simonis wrote: > > Hi Christoph, > > I think your change is fine as a quick-fix to fix the build. But > you're completely right that this should be reworked in the > long term. > I hate to see that we now have the third version of these > routines in > the OpenJDK. Unfortunately a clean solution is not trivial. > > libjli is not linked against libjvm because libjli is actually > used to > load libjvm. So we can not put the dladdr routines for AIX > there. But > I think we should at least consolidate the two versions which > will be > in the class library after your change. Initially I > intentionally put > porting_aix.{c,h} into jdk/aix/porting with the intent to make it > available to ALL jdk native libraries. > > Unfortunately, with the source code reorganization due to the > modular > changes, the common, top-level aix repository had to go away > and the > code was moved to > src/java.desktop/aix/native/libawt/porting_aix.c. > With the reorganized, modularized source code layout and build > system > it is not possible to share code between modules. We somehow > have to > fix this although I currently don't know how. IF somebody has > an idea, > please let me know :) > > > Why doesn't AIX support a Standard C API that most other > *nix based OS'es support ? > > > dladdr() is not Posix, hence it should not be used in code that wants > to be portable across Unix systems. Afaik dladdr() is a propietary > Solaris API that was adapted by the glibc and slowly spread over to > some other Unices, but by no means all of them. > dladdr makes a number of assumptions about the architecture: e.g. that > a C function pointer points into the text segment of the binary > instead of e.g. a PLT, or that a loaded binary is placed continuously > in memory (we only have one dli_fbase in DL_info). So imho it makes > sense to not make this a standard Posix API. > > We (SAP) implemented dladdr atop of loadquery(), and this kind of > works, although we had to add some hacks to handle both real code > addresses and C function pointers. So the code is there, it is "just" > a question of where to place it. I understand your desire to keep AIX pristine and clean, similarly, we should also keep OpenJDK sources clean, having 3 identical dladdr implementation, spread across the OpenJDK does not bode well. So, is it possible to park the sources in hotspot repo, and create a shared shared object, that can be suitably linked to the launchers, awt and hotspot to this library/object ? Thanks Kumar > Kind Regards, Thomas > > Thanks > > Kumar > > > > Regarding your change: > > - can you please move > > +#if defined(_AIX) > +#include "java_md_aix.h" > +#endif > + > > from java_md_common.c to the end of > java.base/unix/native/libjli/java_md.h. It will then be > automatically > included into java_md_common.c trough java.h which includes > java_md.h > > Also, this version of dladdr is inherently not thread safe. I > don't > think that's a problem here, but it would be nice if you could > quickly > check if that's indeed true. > > Besides that, looks good. > > Thanks for fixing, > Volker > > > > > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph > > > wrote: > > Hi, > > the fix for > https://bugs.openjdk.java.net/browse/JDK-8165524 > breaks > the AIX build as function dladdr is not available on AIX. > > There already exist ports of that API in hotspot and awt. > With the proposed change I duplicate the awt port to > libjli. This is maybe only a quick fix - eventually we > should think about consolidating and using the hotspot > port in all places by exporting it from libjvm.so for AIX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 > > Webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ > > > Thanks > Christoph > > > -----Original Message----- > From: core-libs-dev > [mailto:core-libs-dev-bounces at openjdk.java.net > ] On Behalf > Of Kumar Srinivasan > Sent: Montag, 12. September 2016 22:57 > To: core-libs-dev >; Mandy Chung > >; Chris Bensen > > > Subject: RFR: 8165524: Better detect JRE that Linux > JLI will be using > > Hello, > > I am sponsoring this changeset for Chris Bensen of the > java packager > team, please review fix for the launcher to better > locate java.home. > > http://cr.openjdk.java.net/~ksrini/8165524/ > > > Thanks > Kumar > > > From Alan.Bateman at oracle.com Wed Sep 28 13:05:16 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Sep 2016 14:05:16 +0100 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> Message-ID: <7309a4fa-421a-de3a-6d05-03a6ed89b8f8@oracle.com> On 28/09/2016 13:44, Peter Levart wrote: > Hi, > > According to discussion here: > > http://cs.oswego.edu/pipermail/concurrency-interest/2016-September/015414.html > > > it seems compact strings introduced (at least theoretical) non-benign > data race into String.hasCode() method. > > Here is a proposed patch: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ > > > For the bug: > > https://bugs.openjdk.java.net/browse/JDK-8166842 > Looks good to me too. -Alan From david.holmes at oracle.com Wed Sep 28 13:05:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Sep 2016 23:05:22 +1000 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> Message-ID: <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> On 28/09/2016 10:44 PM, Peter Levart wrote: > Hi, > > According to discussion here: > > http://cs.oswego.edu/pipermail/concurrency-interest/2016-September/015414.html > > > it seems compact strings introduced (at least theoretical) non-benign > data race into String.hasCode() method. > > Here is a proposed patch: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ I'm far from convinced that the bug exists - theoretical or otherwise - but the "fix" is harmless. When we were working on JSR-133 one of the conceptual models is that every write to a variable goes into the set of values that a read may potentially return (so no out-of-thin-air for example). happens-before establishes constraints on which value can legally be returned - the most recent. An additional property was that once a value was returned, a later read could not return an earlier value - in essence once a read returns a given value, all earlier written values are removed from the set of potential values that can be read. Your bug requires that the code act as-if written: int temp = hash; if (temp == 0) { hash = ... } return temp; and I do not believe that is allowed. David > > For the bug: > > https://bugs.openjdk.java.net/browse/JDK-8166842 > > > > JDK 8 did not have this problem, so no back-porting necessary. > > Regards, Peter > From peter.levart at gmail.com Wed Sep 28 13:24:29 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 28 Sep 2016 15:24:29 +0200 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: <4d006383-f1ba-8c04-37a5-5436f43aaa78@gmail.com> On 09/28/2016 03:05 PM, David Holmes wrote: > On 28/09/2016 10:44 PM, Peter Levart wrote: >> Hi, >> >> According to discussion here: >> >> http://cs.oswego.edu/pipermail/concurrency-interest/2016-September/015414.html >> >> >> >> it seems compact strings introduced (at least theoretical) non-benign >> data race into String.hasCode() method. >> >> Here is a proposed patch: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ >> > > I'm far from convinced that the bug exists - theoretical or otherwise > - but the "fix" is harmless. > > When we were working on JSR-133 one of the conceptual models is that > every write to a variable goes into the set of values that a read may > potentially return (so no out-of-thin-air for example). happens-before > establishes constraints on which value can legally be returned - the > most recent. An additional property was that once a value was > returned, a later read could not return an earlier value - in essence > once a read returns a given value, all earlier written values are > removed from the set of potential values that can be read. That would be a nice property, yes. > > Your bug requires that the code act as-if written: > > int temp = hash; > if (temp == 0) { > hash = ... > } > return temp; > > and I do not believe that is allowed. > > David Well, I can't find anything like that in JMM description. Could you point me to it? Above example only reads once from hash. The code in question is this: if (hash == 0) { // 1st read hash = ... } return hash; // 2nd read And the bug requires the code to act like: int temp2 = hash; // 2nd read int temp1 = hash; // 1st read if (temp1 == 0) { return (hash = ...); } return temp2; Is this allowed? Regards, Peter > >> >> For the bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8166842 >> >> >> >> JDK 8 did not have this problem, so no back-porting necessary. >> >> Regards, Peter >> From claes.redestad at oracle.com Wed Sep 28 13:25:54 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Sep 2016 15:25:54 +0200 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: <75d3cb1c-5aa9-2abf-d243-18f84bb43e4a@redhat.com> References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <75d3cb1c-5aa9-2abf-d243-18f84bb43e4a@redhat.com> Message-ID: <31d765f0-4777-b0c7-5ed6-18a75e6ee03e@oracle.com> Hi, tangentially, is there any reason the Compact Strings work chose to revert to checking value.length > 0 rather than not writing to hash if the calculated hash code is 0? http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6837759aa403 /Claes On 2016-09-28 14:47, Aleksey Shipilev wrote: > On 09/28/2016 02:44 PM, Peter Levart wrote: >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ > +1, thanks. This is partially my fault for not spotting it earlier > during the Compact Strings work. > > -Aleksey > From shade at redhat.com Wed Sep 28 13:26:15 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 28 Sep 2016 15:26:15 +0200 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: <4d006383-f1ba-8c04-37a5-5436f43aaa78@gmail.com> References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> <4d006383-f1ba-8c04-37a5-5436f43aaa78@gmail.com> Message-ID: Peter, David, Would you mind discussing the theoretical topics on concurrency-interest@, for the benefits of others who don't track high-traffic OpenJDK list? Thanks, -Aleksey On 09/28/2016 03:24 PM, Peter Levart wrote: > > On 09/28/2016 03:05 PM, David Holmes wrote: >> On 28/09/2016 10:44 PM, Peter Levart wrote: >>> Hi, >>> >>> According to discussion here: >>> >>> http://cs.oswego.edu/pipermail/concurrency-interest/2016-September/015414.html >>> >>> >>> >>> it seems compact strings introduced (at least theoretical) non-benign >>> data race into String.hasCode() method. >>> >>> Here is a proposed patch: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ >>> >> >> I'm far from convinced that the bug exists - theoretical or otherwise >> - but the "fix" is harmless. >> >> When we were working on JSR-133 one of the conceptual models is that >> every write to a variable goes into the set of values that a read may >> potentially return (so no out-of-thin-air for example). happens-before >> establishes constraints on which value can legally be returned - the >> most recent. An additional property was that once a value was >> returned, a later read could not return an earlier value - in essence >> once a read returns a given value, all earlier written values are >> removed from the set of potential values that can be read. > > That would be a nice property, yes. > >> >> Your bug requires that the code act as-if written: >> >> int temp = hash; >> if (temp == 0) { >> hash = ... >> } >> return temp; >> >> and I do not believe that is allowed. >> >> David > > Well, I can't find anything like that in JMM description. Could you > point me to it? Above example only reads once from hash. The code in > question is this: > > if (hash == 0) { // 1st read > hash = ... > } > return hash; // 2nd read > > And the bug requires the code to act like: > > int temp2 = hash; // 2nd read > int temp1 = hash; // 1st read > if (temp1 == 0) { > return (hash = ...); > } > return temp2; > > > Is this allowed? > > Regards, Peter > >> >>> >>> For the bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8166842 >>> >>> >>> >>> JDK 8 did not have this problem, so no back-porting necessary. >>> >>> Regards, Peter >>> > From vitalyd at gmail.com Wed Sep 28 14:13:03 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 28 Sep 2016 10:13:03 -0400 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: On Wednesday, September 28, 2016, David Holmes wrote: > On 28/09/2016 10:44 PM, Peter Levart wrote: > >> Hi, >> >> According to discussion here: >> >> http://cs.oswego.edu/pipermail/concurrency-interest/2016- >> September/015414.html >> >> >> it seems compact strings introduced (at least theoretical) non-benign >> data race into String.hasCode() method. >> >> Here is a proposed patch: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String. >> hashCode/webrev.01/ >> > > I'm far from convinced that the bug exists - theoretical or otherwise - > but the "fix" is harmless. > > When we were working on JSR-133 one of the conceptual models is that every > write to a variable goes into the set of values that a read may potentially > return (so no out-of-thin-air for example). happens-before establishes > constraints on which value can legally be returned - the most recent. An > additional property was that once a value was returned, a later read could > not return an earlier value - in essence once a read returns a given value, > all earlier written values are removed from the set of potential values > that can be read. > > Your bug requires that the code act as-if written: > > int temp = hash; > if (temp == 0) { > hash = ... > } > return temp; It's the other way I think: int temp = hash; // read 0 if (hash == 0) // reread a non 0 hash = temp = ... return temp // return 0 It's unlikely but what prohibits that? > > and I do not believe that is allowed. > > David > > >> For the bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8166842 >> >> >> >> JDK 8 did not have this problem, so no back-porting necessary. >> >> Regards, Peter >> >> -- Sent from my phone From vitalyd at gmail.com Wed Sep 28 14:27:14 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 28 Sep 2016 10:27:14 -0400 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> <4F4C205E-C96C-47B1-A147-7B284758B499@univ-mlv.fr> Message-ID: Thanks Claes - this is an annoying one! Will it be backported to 8? On Wednesday, September 28, 2016, Claes Redestad wrote: > Thanks for the quick reviews! > > /Claes > > On 2016-09-28 14:14, Remi Forax wrote: > >> yes, >> thumb up. >> >> R?mi >> >> >> On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt < >> michael.haupt at oracle.com> wrote: >> >>> Hi Claes, >>> >>> yes please. Thumbs up. :-) >>> >>> Best, >>> >>> Michael >>> >>> Am 28.09.2016 um 13:48 schrieb Claes Redestad >>>> >>> : >>> >>>> Hi, >>>> >>>> as discussed recently on hotspot-compiler-dev[1], having a private >>>> >>> class with no default constructor can lead to C2 failing to inline, due >>> to the synthetic bridge constructor using a dummy argument of an >>> uninitialized class. This is really a problem in C2, as well as >>> something which could ultimately be resolved by nestmates... >>> >>>> However, there is an easy workaround in adding an empty >>>> >>> package-private constructor. In the most recently found case - a >>> microbenchmark stressing MethodHandles.iteratedLoop - adding this to >>> ArrayList$Itr lead to a 2.5-3x speedup. >>> >>>> This is me asking nicely to do a quick-fix for this in >>>> >>> java.util.ArrayList$Itr now: >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 >>>> Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ >>>> >>>> Thanks! >>>> >>>> /Claes >>>> >>>> [1] >>>> >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/ >>> 2016-September/024407.html >>> >>> -- >>> >>> >>> Dr. Michael Haupt | Principal Member of Technical Staff >>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >>> Oracle Java Platform Group | LangTools Team | Nashorn >>> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, >>> Germany >>> >>> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, >>> D-80992 M?nchen >>> Registergericht: Amtsgericht M?nchen, HRA 95603 >>> >>> Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering >>> 163/167, 3543 AS Utrecht, Niederlande >>> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 >>> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher >>> Oracle is committed to >>> developing >>> practices and products that help protect the environment >>> >> > -- Sent from my phone From claes.redestad at oracle.com Wed Sep 28 14:37:28 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Sep 2016 16:37:28 +0200 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> <4F4C205E-C96C-47B1-A147-7B284758B499@univ-mlv.fr> Message-ID: I dealt with this in isolation deliberately to ease backporting, but I don't have the 8u committer rights to do it myself. /Claes On 2016-09-28 16:27, Vitaly Davidovich wrote: > Thanks Claes - this is an annoying one! > > Will it be backported to 8? > > On Wednesday, September 28, 2016, Claes Redestad > > wrote: > > Thanks for the quick reviews! > > /Claes > > On 2016-09-28 14:14, Remi Forax wrote: > > yes, > thumb up. > > R?mi > > > On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt > wrote: > > Hi Claes, > > yes please. Thumbs up. :-) > > Best, > > Michael > > Am 28.09.2016 um 13:48 schrieb Claes Redestad > > : > > Hi, > > as discussed recently on hotspot-compiler-dev[1], > having a private > > class with no default constructor can lead to C2 failing > to inline, due > to the synthetic bridge constructor using a dummy argument > of an > uninitialized class. This is really a problem in C2, as > well as > something which could ultimately be resolved by nestmates... > > However, there is an easy workaround in adding an empty > > package-private constructor. In the most recently found > case - a > microbenchmark stressing MethodHandles.iteratedLoop - > adding this to > ArrayList$Itr lead to a 2.5-3x speedup. > > This is me asking nicely to do a quick-fix for this in > > java.util.ArrayList$Itr now: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 > > Webrev: > http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ > > > Thanks! > > /Claes > > [1] > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html > > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | > 14467 Potsdam, > Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: > Riesstra?e 25, > D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | > Hertogswetering > 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. > 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, > Val Maher > > Oracle is > committed to developing > practices and products that help protect the environment > > > > > -- > Sent from my phone From rednaxelafx at gmail.com Wed Sep 28 14:40:09 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 28 Sep 2016 07:40:09 -0700 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> Message-ID: Hi Claes, For this particular case, this JDK-side change looks good to me. Let me post out the HotSpot version of the change and let you guys decide whether or not you guys want to take that version (which will take care of the ArrayList$1 case without the JDK-side change). Thanks, Kris On Wed, Sep 28, 2016 at 4:48 AM, Claes Redestad wrote: > Hi, > > as discussed recently on hotspot-compiler-dev[1], having a private class > with no default constructor can lead to C2 failing to inline, due to the > synthetic bridge constructor using a dummy argument of an uninitialized > class. This is really a problem in C2, as well as something which could > ultimately be resolved by nestmates... > > However, there is an easy workaround in adding an empty package-private > constructor. In the most recently found case - a microbenchmark stressing > MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead to a 2.5-3x > speedup. > > This is me asking nicely to do a quick-fix for this in > java.util.ArrayList$Itr now: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 > Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ > > Thanks! > > /Claes > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/ > 2016-September/024407.html > From vladimir.x.ivanov at oracle.com Wed Sep 28 14:46:17 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 28 Sep 2016 17:46:17 +0300 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> Message-ID: <3e7e243c-dd58-ca7c-ba82-c23e2e3f7db3@oracle.com> Looks good. Best regards, Vladimir Ivanov On 9/28/16 2:48 PM, Claes Redestad wrote: > Hi, > > as discussed recently on hotspot-compiler-dev[1], having a private class > with no default constructor can lead to C2 failing to inline, due to the > synthetic bridge constructor using a dummy argument of an uninitialized > class. This is really a problem in C2, as well as something which could > ultimately be resolved by nestmates... > > However, there is an easy workaround in adding an empty package-private > constructor. In the most recently found case - a microbenchmark > stressing MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead > to a 2.5-3x speedup. > > This is me asking nicely to do a quick-fix for this in > java.util.ArrayList$Itr now: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 > Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ > > Thanks! > > /Claes > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html > From vitalyd at gmail.com Wed Sep 28 14:50:49 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 28 Sep 2016 10:50:49 -0400 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> <4F4C205E-C96C-47B1-A147-7B284758B499@univ-mlv.fr> Message-ID: On Wed, Sep 28, 2016 at 10:37 AM, Claes Redestad wrote: > I dealt with this in isolation deliberately to ease backporting, but I > don't have the 8u committer rights to do it myself. > Right. The change seems trivial enough that backporting would be easy. Who could make the decision on that? > > /Claes Thanks > > > On 2016-09-28 16:27, Vitaly Davidovich wrote: > >> Thanks Claes - this is an annoying one! >> >> Will it be backported to 8? >> >> On Wednesday, September 28, 2016, Claes Redestad < >> claes.redestad at oracle.com > wrote: >> >> Thanks for the quick reviews! >> >> /Claes >> >> On 2016-09-28 14:14, Remi Forax wrote: >> >> yes, >> thumb up. >> >> R?mi >> >> >> On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt >> wrote: >> >> Hi Claes, >> >> yes please. Thumbs up. :-) >> >> Best, >> >> Michael >> >> Am 28.09.2016 um 13:48 schrieb Claes Redestad >> >> : >> >> Hi, >> >> as discussed recently on hotspot-compiler-dev[1], >> having a private >> >> class with no default constructor can lead to C2 failing >> to inline, due >> to the synthetic bridge constructor using a dummy argument >> of an >> uninitialized class. This is really a problem in C2, as >> well as >> something which could ultimately be resolved by nestmates... >> >> However, there is an easy workaround in adding an empty >> >> package-private constructor. In the most recently found >> case - a >> microbenchmark stressing MethodHandles.iteratedLoop - >> adding this to >> ArrayList$Itr lead to a 2.5-3x speedup. >> >> This is me asking nicely to do a quick-fix for this in >> >> java.util.ArrayList$Itr now: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 >> >> Webrev: >> http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ >> > Eredestad/8166840/webrev.01/> >> >> >> Thanks! >> >> /Claes >> >> [1] >> >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/ >> 2016-September/024407.html >> > /2016-September/024407.html> >> >> -- >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Java Platform Group | LangTools Team | Nashorn >> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | >> 14467 Potsdam, >> Germany >> >> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: >> Riesstra?e 25, >> D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. | >> Hertogswetering >> 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Nederland, Nr. >> 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, >> Val Maher >> > > Oracle is >> committed to developing >> practices and products that help protect the environment >> >> >> >> >> -- >> Sent from my phone >> > > From claes.redestad at oracle.com Wed Sep 28 14:52:36 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Sep 2016 16:52:36 +0200 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> Message-ID: <36699c8c-ea9c-cbb4-cda0-a0ea43834c52@oracle.com> Hi Kris, right, I don't intend to meander away on a micro-optimization spree and chase down every case where we're hurt by this corner case in the JDK and elsewhere (I did check that other core collection classes aren't affected, though ;-)), but to get this simple and possibly high-impact quick fix out of the way to unblock other work I'm doing, specifically JDK-8161210 I think everyone would be very happy to get the root issue in HotSpot fixed! Thanks! /Claes On 2016-09-28 16:40, Krystal Mok wrote: > Hi Claes, > > For this particular case, this JDK-side change looks good to me. > > Let me post out the HotSpot version of the change and let you guys > decide whether or not you guys want to take that version (which will > take care of the ArrayList$1 case without the JDK-side change). > > Thanks, > Kris > > On Wed, Sep 28, 2016 at 4:48 AM, Claes Redestad > > wrote: > > Hi, > > as discussed recently on hotspot-compiler-dev[1], having a private > class with no default constructor can lead to C2 failing to > inline, due to the synthetic bridge constructor using a dummy > argument of an uninitialized class. This is really a problem in > C2, as well as something which could ultimately be resolved by > nestmates... > > However, there is an easy workaround in adding an empty > package-private constructor. In the most recently found case - a > microbenchmark stressing MethodHandles.iteratedLoop - adding this > to ArrayList$Itr lead to a 2.5-3x speedup. > > This is me asking nicely to do a quick-fix for this in > java.util.ArrayList$Itr now: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 > > Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ > > > Thanks! > > /Claes > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html > > > From ivan.gerasimov at oracle.com Wed Sep 28 16:00:15 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 28 Sep 2016 19:00:15 +0300 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> <4F4C205E-C96C-47B1-A147-7B284758B499@univ-mlv.fr> Message-ID: Hi Claes! I can handle the backport. With kind regards, Ivan On 28.09.2016 17:37, Claes Redestad wrote: > I dealt with this in isolation deliberately to ease backporting, but I > don't have the 8u committer rights to do it myself. > > /Claes > > On 2016-09-28 16:27, Vitaly Davidovich wrote: >> Thanks Claes - this is an annoying one! >> >> Will it be backported to 8? >> >> On Wednesday, September 28, 2016, Claes Redestad >> > wrote: >> >> Thanks for the quick reviews! >> >> /Claes >> >> On 2016-09-28 14:14, Remi Forax wrote: >> >> yes, >> thumb up. >> >> R?mi >> >> >> On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt >> wrote: >> >> Hi Claes, >> >> yes please. Thumbs up. :-) >> >> Best, >> >> Michael >> >> Am 28.09.2016 um 13:48 schrieb Claes Redestad >> >> : >> >> Hi, >> >> as discussed recently on hotspot-compiler-dev[1], >> having a private >> >> class with no default constructor can lead to C2 failing >> to inline, due >> to the synthetic bridge constructor using a dummy argument >> of an >> uninitialized class. This is really a problem in C2, as >> well as >> something which could ultimately be resolved by nestmates... >> >> However, there is an easy workaround in adding an empty >> >> package-private constructor. In the most recently found >> case - a >> microbenchmark stressing MethodHandles.iteratedLoop - >> adding this to >> ArrayList$Itr lead to a 2.5-3x speedup. >> >> This is me asking nicely to do a quick-fix for this in >> >> java.util.ArrayList$Itr now: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840 >> >> Webrev: >> http://cr.openjdk.java.net/~redestad/8166840/webrev.01/ >> >> >> Thanks! >> >> /Claes >> >> [1] >> >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html >> >> >> -- >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Java Platform Group | LangTools Team | Nashorn >> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | >> 14467 Potsdam, >> Germany >> >> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: >> Riesstra?e 25, >> D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. | >> Hertogswetering >> 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Nederland, Nr. >> 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, >> Val Maher >> > > Oracle is >> committed to developing >> practices and products that help protect the environment >> >> >> >> >> -- >> Sent from my phone > > From volker.simonis at gmail.com Wed Sep 28 16:33:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 28 Sep 2016 18:33:05 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57EBBF9A.6010103@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: On Wed, Sep 28, 2016 at 3:03 PM, Kumar Srinivasan wrote: > > Hello Thomas, Volker, > > > Hi Kumar, > >> >> On 9/16/2016 10:34 AM, Volker Simonis wrote: >>> >>> Hi Christoph, >>> >>> I think your change is fine as a quick-fix to fix the build. But >>> you're completely right that this should be reworked in the long term. >>> I hate to see that we now have the third version of these routines in >>> the OpenJDK. Unfortunately a clean solution is not trivial. >>> >>> libjli is not linked against libjvm because libjli is actually used to >>> load libjvm. So we can not put the dladdr routines for AIX there. But >>> I think we should at least consolidate the two versions which will be >>> in the class library after your change. Initially I intentionally put >>> porting_aix.{c,h} into jdk/aix/porting with the intent to make it >>> available to ALL jdk native libraries. >>> >>> Unfortunately, with the source code reorganization due to the modular >>> changes, the common, top-level aix repository had to go away and the >>> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. >>> With the reorganized, modularized source code layout and build system >>> it is not possible to share code between modules. We somehow have to >>> fix this although I currently don't know how. IF somebody has an idea, >>> please let me know :) >> >> >> Why doesn't AIX support a Standard C API that most other >> *nix based OS'es support ? >> > > dladdr() is not Posix, hence it should not be used in code that wants to be > portable across Unix systems. Afaik dladdr() is a propietary Solaris API > that was adapted by the glibc and slowly spread over to some other Unices, > but by no means all of them. > > dladdr makes a number of assumptions about the architecture: e.g. that a C > function pointer points into the text segment of the binary instead of e.g. > a PLT, or that a loaded binary is placed continuously in memory (we only > have one dli_fbase in DL_info). So imho it makes sense to not make this a > standard Posix API. > > We (SAP) implemented dladdr atop of loadquery(), and this kind of works, > although we had to add some hacks to handle both real code addresses and C > function pointers. So the code is there, it is "just" a question of where to > place it. > > > I understand your desire to keep AIX pristine and clean, similarly, > we should also keep OpenJDK sources clean, having 3 identical > dladdr implementation, spread across the OpenJDK does not > bode well. > > So, is it possible to park the sources in hotspot repo, and create a > shared shared object, that can be suitably linked to the launchers, > awt and hotspot to this library/object ? I don't think this can be easily done with the current build system. Remember for example that even such a sensitive part like jni.h is still duplicated between the hotspot and the jdk repository: hotspot/src/share/vm/prims/jni.h jdk/src/java.base/share/native/include/jni.h So before we envision a solution for the various dladdr implementations for AIX we should really come up with a general way to share code between hotspot and jdk. I've cc'ed build-dev because I think this is to a big part a build/infrastructure issue. If somebody has a good idea, please let me know :) Regards, Volker > > Thanks > Kumar > > > > > Kind Regards, Thomas > >> Thanks >> >> Kumar >> >> >>> >>> Regarding your change: >>> >>> - can you please move >>> >>> +#if defined(_AIX) >>> +#include "java_md_aix.h" >>> +#endif >>> + >>> >>> from java_md_common.c to the end of >>> java.base/unix/native/libjli/java_md.h. It will then be automatically >>> included into java_md_common.c trough java.h which includes java_md.h >>> >>> Also, this version of dladdr is inherently not thread safe. I don't >>> think that's a problem here, but it would be nice if you could quickly >>> check if that's indeed true. >>> >>> Besides that, looks good. >>> >>> Thanks for fixing, >>> Volker >>> >>> >>> >>> >>> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >>> wrote: >>>> >>>> Hi, >>>> >>>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the >>>> AIX build as function dladdr is not available on AIX. >>>> >>>> There already exist ports of that API in hotspot and awt. With the >>>> proposed change I duplicate the awt port to libjli. This is maybe only a >>>> quick fix - eventually we should think about consolidating and using the >>>> hotspot port in all places by exporting it from libjvm.so for AIX. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >>>> >>>> Thanks >>>> Christoph >>>> >>>> >>>>> -----Original Message----- >>>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >>>>> Behalf >>>>> Of Kumar Srinivasan >>>>> Sent: Montag, 12. September 2016 22:57 >>>>> To: core-libs-dev ; Mandy Chung >>>>> ; Chris Bensen >>>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>>>> >>>>> Hello, >>>>> >>>>> I am sponsoring this changeset for Chris Bensen of the java packager >>>>> team, please review fix for the launcher to better locate java.home. >>>>> >>>>> http://cr.openjdk.java.net/~ksrini/8165524/ >>>>> >>>>> Thanks >>>>> Kumar >> >> > > From kumar.x.srinivasan at oracle.com Wed Sep 28 17:13:51 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 28 Sep 2016 10:13:51 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57EBBF9A.6010103@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: <57EBFA4F.9010401@oracle.com> One thing I missed to mention, the fix for 8165524 is primarily to assist the packager tool, which deploys client side/JavaFX based applications. If this tool is not relevant and does not exist on AIX. Then at a minimum the dladdr call can either be dynamically located/invoked using dlsym, or simply have the AIX version of dladdr return JNI_FALSE always, only for the launcher of course. Thanks Kumar > > Hello Thomas, Volker, > >> >> Hi Kumar, >> >> >> On 9/16/2016 10:34 AM, Volker Simonis wrote: >> >> Hi Christoph, >> >> I think your change is fine as a quick-fix to fix the build. But >> you're completely right that this should be reworked in the >> long term. >> I hate to see that we now have the third version of these >> routines in >> the OpenJDK. Unfortunately a clean solution is not trivial. >> >> libjli is not linked against libjvm because libjli is actually >> used to >> load libjvm. So we can not put the dladdr routines for AIX >> there. But >> I think we should at least consolidate the two versions which >> will be >> in the class library after your change. Initially I >> intentionally put >> porting_aix.{c,h} into jdk/aix/porting with the intent to >> make it >> available to ALL jdk native libraries. >> >> Unfortunately, with the source code reorganization due to the >> modular >> changes, the common, top-level aix repository had to go away >> and the >> code was moved to >> src/java.desktop/aix/native/libawt/porting_aix.c. >> With the reorganized, modularized source code layout and build >> system >> it is not possible to share code between modules. We somehow >> have to >> fix this although I currently don't know how. IF somebody has >> an idea, >> please let me know :) >> >> >> Why doesn't AIX support a Standard C API that most other >> *nix based OS'es support ? >> >> >> dladdr() is not Posix, hence it should not be used in code that wants >> to be portable across Unix systems. Afaik dladdr() is a propietary >> Solaris API that was adapted by the glibc and slowly spread over to >> some other Unices, but by no means all of them. >> dladdr makes a number of assumptions about the architecture: e.g. >> that a C function pointer points into the text segment of the binary >> instead of e.g. a PLT, or that a loaded binary is placed continuously >> in memory (we only have one dli_fbase in DL_info). So imho it makes >> sense to not make this a standard Posix API. >> >> We (SAP) implemented dladdr atop of loadquery(), and this kind of >> works, although we had to add some hacks to handle both real code >> addresses and C function pointers. So the code is there, it is "just" >> a question of where to place it. > > I understand your desire to keep AIX pristine and clean, similarly, > we should also keep OpenJDK sources clean, having 3 identical > dladdr implementation, spread across the OpenJDK does not > bode well. > > So, is it possible to park the sources in hotspot repo, and create a > shared shared object, that can be suitably linked to the launchers, > awt and hotspot to this library/object ? > > Thanks > Kumar > > > >> Kind Regards, Thomas >> >> Thanks >> >> Kumar >> >> >> >> Regarding your change: >> >> - can you please move >> >> +#if defined(_AIX) >> +#include "java_md_aix.h" >> +#endif >> + >> >> from java_md_common.c to the end of >> java.base/unix/native/libjli/java_md.h. It will then be >> automatically >> included into java_md_common.c trough java.h which includes >> java_md.h >> >> Also, this version of dladdr is inherently not thread safe. I >> don't >> think that's a problem here, but it would be nice if you could >> quickly >> check if that's indeed true. >> >> Besides that, looks good. >> >> Thanks for fixing, >> Volker >> >> >> >> >> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >> > >> wrote: >> >> Hi, >> >> the fix for >> https://bugs.openjdk.java.net/browse/JDK-8165524 >> breaks >> the AIX build as function dladdr is not available on AIX. >> >> There already exist ports of that API in hotspot and awt. >> With the proposed change I duplicate the awt port to >> libjli. This is maybe only a quick fix - eventually we >> should think about consolidating and using the hotspot >> port in all places by exporting it from libjvm.so for AIX. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >> >> Webrev: >> http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >> >> >> Thanks >> Christoph >> >> >> -----Original Message----- >> From: core-libs-dev >> [mailto:core-libs-dev-bounces at openjdk.java.net >> ] On Behalf >> Of Kumar Srinivasan >> Sent: Montag, 12. September 2016 22:57 >> To: core-libs-dev > >; Mandy Chung >> > >; Chris Bensen >> > > >> Subject: RFR: 8165524: Better detect JRE that Linux >> JLI will be using >> >> Hello, >> >> I am sponsoring this changeset for Chris Bensen of the >> java packager >> team, please review fix for the launcher to better >> locate java.home. >> >> http://cr.openjdk.java.net/~ksrini/8165524/ >> >> >> Thanks >> Kumar >> >> >> > From john.r.rose at oracle.com Wed Sep 28 17:31:22 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 28 Sep 2016 10:31:22 -0700 Subject: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining In-Reply-To: References: <8454a098-c8f1-bec7-8131-20ce8686080c@oracle.com> Message-ID: <1A7D384A-B94D-41B0-88DA-32284102A0FF@oracle.com> On Sep 28, 2016, at 7:40 AM, Krystal Mok wrote: > > Let me post out the HotSpot version of the change and let you guys decide > whether or not you guys want to take that version (which will take care of > the ArrayList$1 case without the JDK-side change). My advice is: Both/and. IMO the presence of a constant null should unblock an inline blocked by an unloaded parameter class. But that will take more effort to do right in the JVM. In general, constants should have weight with the inlining heuristic. And, nestmate access at JVM level may be coming also but that's not back-portable. Tech. debt from 1997, yum. ? John From martinrb at google.com Wed Sep 28 17:33:04 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Sep 2016 10:33:04 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis wrote: > > I don't think this can be easily done with the current build system. > Remember for example that even such a sensitive part like jni.h is > still duplicated between the hotspot and the jdk repository: > > hotspot/src/share/vm/prims/jni.h > jdk/src/java.base/share/native/include/jni.h > It's one of the frustrating aspects of openjdk development that it's hard to share C level infrastructure among different components. Components sometimes grow their own local C infrastructure, but when another component has the same problem, one often resorts to copy-paste as the most expedient way to get code reuse. In part, the mercurial repo organization reinforces this - there is one top-level repo with fan-out, but there is nothing at the bottom with fan-in. One code sharing mechanism that does get used is seen in ClassLoader::load_zip_library() where code from the jdk repo is packaged into a shared object and invoked from hotspot, dynamically. From cvarming at twitter.com Wed Sep 28 17:44:17 2016 From: cvarming at twitter.com (Carsten Varming) Date: Wed, 28 Sep 2016 13:44:17 -0400 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: Dear Vitaly and David, Looking at your webrev the original code is: public int hashCode() { if (hash == 0 && value.length > 0) { hash = isLatin1() ? StringLatin1.hashCode(value) } return hash; } There is a constructor: public String(String original) { this.value = original.value; this.coder = original.coder; this.hash = original.hash; } that might write zero to the mutable field "hash". The object created by this constructor might be shared using plain reads and writes between two threads[1] and the write of 0 in the constructor might be interleaved with the reads and write in hashCode. Does this capture the problem? [1]: Meaning the is no happens-before relationship established between object construction and another thread calling hashCode on the object. Carsten On Wed, Sep 28, 2016 at 10:13 AM, Vitaly Davidovich wrote: > On Wednesday, September 28, 2016, David Holmes > wrote: > > > On 28/09/2016 10:44 PM, Peter Levart wrote: > > > >> Hi, > >> > >> According to discussion here: > >> > >> http://cs.oswego.edu/pipermail/concurrency-interest/2016- > >> September/015414.html > >> > >> > >> it seems compact strings introduced (at least theoretical) non-benign > >> data race into String.hasCode() method. > >> > >> Here is a proposed patch: > >> > >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String. > >> hashCode/webrev.01/ > >> > > > > I'm far from convinced that the bug exists - theoretical or otherwise - > > but the "fix" is harmless. > > > > When we were working on JSR-133 one of the conceptual models is that > every > > write to a variable goes into the set of values that a read may > potentially > > return (so no out-of-thin-air for example). happens-before establishes > > constraints on which value can legally be returned - the most recent. An > > additional property was that once a value was returned, a later read > could > > not return an earlier value - in essence once a read returns a given > value, > > all earlier written values are removed from the set of potential values > > that can be read. > > > > Your bug requires that the code act as-if written: > > > > int temp = hash; > > if (temp == 0) { > > hash = ... > > } > > return temp; > > It's the other way I think: > > int temp = hash; // read 0 > if (hash == 0) // reread a non 0 > hash = temp = ... > return temp // return 0 > > It's unlikely but what prohibits that? > > > > > and I do not believe that is allowed. > > > > David > > > > > >> For the bug: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8166842 > >> > >> > >> > >> JDK 8 did not have this problem, so no back-porting necessary. > >> > >> Regards, Peter > >> > >> > > -- > Sent from my phone > From vitalyd at gmail.com Wed Sep 28 18:32:20 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 28 Sep 2016 14:32:20 -0400 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: On Wednesday, September 28, 2016, Carsten Varming wrote: > Dear Vitaly and David, > > Looking at your webrev the original code is: > > public int hashCode() { > if (hash == 0 && value.length > 0) { > hash = isLatin1() ? StringLatin1.hashCode(value) > } > return hash; > } > > There is a constructor: > > public String(String original) { > this.value = original.value; > this.coder = original.coder; > this.hash = original.hash; > } > > that might write zero to the mutable field "hash". > > The object created by this constructor might be shared using plain reads > and writes between two threads[1] and the write of 0 in the constructor > might be interleaved with the reads and write in hashCode. Does this > capture the problem? > > [1]: Meaning the is no happens-before relationship established between > object construction and another thread calling hashCode on the object. > I think the issue is more fundamental - multiple threads calling hashCode on the same instance. AFAIK, Java prohibits replacing an explicit local with a (re-) read of the underlying field. But, otherwise I believe compiler has latitude to schedule loads and reloads as it pleases. But I think this may need to be clarified since this aspect has been brought up. > > Carsten > > On Wed, Sep 28, 2016 at 10:13 AM, Vitaly Davidovich > wrote: > >> On Wednesday, September 28, 2016, David Holmes > > >> wrote: >> >> > On 28/09/2016 10:44 PM, Peter Levart wrote: >> > >> >> Hi, >> >> >> >> According to discussion here: >> >> >> >> http://cs.oswego.edu/pipermail/concurrency-interest/2016- >> >> September/015414.html >> >> >> >> >> >> it seems compact strings introduced (at least theoretical) non-benign >> >> data race into String.hasCode() method. >> >> >> >> Here is a proposed patch: >> >> >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String. >> >> hashCode/webrev.01/ >> >> >> > >> > I'm far from convinced that the bug exists - theoretical or otherwise - >> > but the "fix" is harmless. >> > >> > When we were working on JSR-133 one of the conceptual models is that >> every >> > write to a variable goes into the set of values that a read may >> potentially >> > return (so no out-of-thin-air for example). happens-before establishes >> > constraints on which value can legally be returned - the most recent. An >> > additional property was that once a value was returned, a later read >> could >> > not return an earlier value - in essence once a read returns a given >> value, >> > all earlier written values are removed from the set of potential values >> > that can be read. >> > >> > Your bug requires that the code act as-if written: >> > >> > int temp = hash; >> > if (temp == 0) { >> > hash = ... >> > } >> > return temp; >> >> It's the other way I think: >> >> int temp = hash; // read 0 >> if (hash == 0) // reread a non 0 >> hash = temp = ... >> return temp // return 0 >> >> It's unlikely but what prohibits that? >> >> > >> > and I do not believe that is allowed. >> > >> > David >> > >> > >> >> For the bug: >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8166842 >> >> >> >> >> >> >> >> JDK 8 did not have this problem, so no back-porting necessary. >> >> >> >> Regards, Peter >> >> >> >> >> >> -- >> Sent from my phone >> > > -- Sent from my phone From thomas.stuefe at gmail.com Wed Sep 28 18:50:24 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Sep 2016 20:50:24 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz wrote: > On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis > wrote: > > > > > I don't think this can be easily done with the current build system. > > Remember for example that even such a sensitive part like jni.h is > > still duplicated between the hotspot and the jdk repository: > > > > hotspot/src/share/vm/prims/jni.h > > jdk/src/java.base/share/native/include/jni.h > > > > It's one of the frustrating aspects of openjdk development that it's hard > to share C level infrastructure among different components. Components > sometimes grow their own local C infrastructure, but when another component > has the same problem, one often resorts to copy-paste as the most expedient > way to get code reuse. In part, the mercurial repo organization reinforces > this - there is one top-level repo with fan-out, but there is nothing at > the bottom with fan-in. > At SAP, we often solve this by moving code to the hotspot and exporting it from there, the hotspot being the central part which (almost) has to be loaded from the very beginning. I think we did this for dladdr() too. But that is an ugly hack too, because it bloats the hotspot and forces us to add -ljvm to a lot of makefiles or to resolve those functions dynamically. Another solution for us on AIX could be to put this stuff into an own library and provide it independently from the OpenJDK build system, just declare it to be a build dependency, similar to Apples JavaRuntimeServices. As we need dladdr() in both hotspot and JDK, maybe that would be the best option. > One code sharing mechanism that does get used is seen in > ClassLoader::load_zip_library() > where code from the jdk repo is packaged into a shared object and invoked > from hotspot, dynamically. > From chris.bensen at oracle.com Wed Sep 28 18:54:17 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 28 Sep 2016 11:54:17 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> > On Sep 28, 2016, at 11:50 AM, Thomas St?fe wrote: > > > > On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz > wrote: > On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis > > wrote: > > > > > I don't think this can be easily done with the current build system. > > Remember for example that even such a sensitive part like jni.h is > > still duplicated between the hotspot and the jdk repository: > > > > hotspot/src/share/vm/prims/jni.h > > jdk/src/java.base/share/native/include/jni.h > > > > It's one of the frustrating aspects of openjdk development that it's hard > to share C level infrastructure among different components. Components > sometimes grow their own local C infrastructure, but when another component > has the same problem, one often resorts to copy-paste as the most expedient > way to get code reuse. In part, the mercurial repo organization reinforces > this - there is one top-level repo with fan-out, but there is nothing at > the bottom with fan-in. > > At SAP, we often solve this by moving code to the hotspot and exporting it from there, the hotspot being the central part which (almost) has to be loaded from the very beginning. I think we did this for dladdr() too. > > But that is an ugly hack too, because it bloats the hotspot and forces us to add -ljvm to a lot of makefiles or to resolve those functions dynamically. > > Another solution for us on AIX could be to put this stuff into an own library and provide it independently from the OpenJDK build system, just declare it to be a build dependency, similar to Apples JavaRuntimeServices. > > As we need dladdr() in both hotspot and JDK, maybe that would be the best option. That sounds like a reasonable solution to me. Chris > > > > One code sharing mechanism that does get used is seen in > ClassLoader::load_zip_library() > where code from the jdk repo is packaged into a shared object and invoked > from hotspot, dynamically. > From thomas.stuefe at gmail.com Wed Sep 28 18:56:05 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Sep 2016 20:56:05 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <57EBBF9A.6010103@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> Message-ID: Hi Kumar, On Wed, Sep 28, 2016 at 3:03 PM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote: > > Hello Thomas, Volker, > > > Hi Kumar, > > >> On 9/16/2016 10:34 AM, Volker Simonis wrote: >> >>> Hi Christoph, >>> >>> I think your change is fine as a quick-fix to fix the build. But >>> you're completely right that this should be reworked in the long term. >>> I hate to see that we now have the third version of these routines in >>> the OpenJDK. Unfortunately a clean solution is not trivial. >>> >>> libjli is not linked against libjvm because libjli is actually used to >>> load libjvm. So we can not put the dladdr routines for AIX there. But >>> I think we should at least consolidate the two versions which will be >>> in the class library after your change. Initially I intentionally put >>> porting_aix.{c,h} into jdk/aix/porting with the intent to make it >>> available to ALL jdk native libraries. >>> >>> Unfortunately, with the source code reorganization due to the modular >>> changes, the common, top-level aix repository had to go away and the >>> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c. >>> With the reorganized, modularized source code layout and build system >>> it is not possible to share code between modules. We somehow have to >>> fix this although I currently don't know how. IF somebody has an idea, >>> please let me know :) >>> >> >> Why doesn't AIX support a Standard C API that most other >> *nix based OS'es support ? >> >> > dladdr() is not Posix, hence it should not be used in code that wants to > be portable across Unix systems. Afaik dladdr() is a propietary Solaris API > that was adapted by the glibc and slowly spread over to some other Unices, > but by no means all of them. > > dladdr makes a number of assumptions about the architecture: e.g. that a C > function pointer points into the text segment of the binary instead of e.g. > a PLT, or that a loaded binary is placed continuously in memory (we only > have one dli_fbase in DL_info). So imho it makes sense to not make this a > standard Posix API. > > We (SAP) implemented dladdr atop of loadquery(), and this kind of works, > although we had to add some hacks to handle both real code addresses and C > function pointers. So the code is there, it is "just" a question of where > to place it. > > > I understand your desire to keep AIX pristine and clean, similarly, > we should also keep OpenJDK sources clean, having 3 identical > dladdr implementation, spread across the OpenJDK does not > bode well. > > I'm not IBM :) and have therefore no strong emotions about keeping AIX pristine. I only did argue that dladdr() is not POSIX and therefore that it would have been nice if OpenJDK would have refrained from using this API (so much). Kind Regards, Thomas So, is it possible to park the sources in hotspot repo, and create a > shared shared object, that can be suitably linked to the launchers, > awt and hotspot to this library/object ? > > Thanks > Kumar > > > > > Kind Regards, Thomas > > Thanks >> >> Kumar >> >> >> >>> Regarding your change: >>> >>> - can you please move >>> >>> +#if defined(_AIX) >>> +#include "java_md_aix.h" >>> +#endif >>> + >>> >>> from java_md_common.c to the end of >>> java.base/unix/native/libjli/java_md.h. It will then be automatically >>> included into java_md_common.c trough java.h which includes java_md.h >>> >>> Also, this version of dladdr is inherently not thread safe. I don't >>> think that's a problem here, but it would be nice if you could quickly >>> check if that's indeed true. >>> >>> Besides that, looks good. >>> >>> Thanks for fixing, >>> Volker >>> >>> >>> >>> >>> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph >>> wrote: >>> >>>> Hi, >>>> >>>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks >>>> the AIX build as function dladdr is not available on AIX. >>>> >>>> There already exist ports of that API in hotspot and awt. With the >>>> proposed change I duplicate the awt port to libjli. This is maybe only a >>>> quick fix - eventually we should think about consolidating and using the >>>> hotspot port in all places by exporting it from libjvm.so for AIX. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189 >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/ >>>> >>>> Thanks >>>> Christoph >>>> >>>> >>>> -----Original Message----- >>>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] >>>>> On Behalf >>>>> Of Kumar Srinivasan >>>>> Sent: Montag, 12. September 2016 22:57 >>>>> To: core-libs-dev ; Mandy Chung >>>>> ; Chris Bensen >>>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using >>>>> >>>>> Hello, >>>>> >>>>> I am sponsoring this changeset for Chris Bensen of the java packager >>>>> team, please review fix for the launcher to better locate java.home. >>>>> >>>>> http://cr.openjdk.java.net/~ksrini/8165524/ >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>> >> > > From gergg at cox.net Wed Sep 28 15:05:35 2016 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 28 Sep 2016 10:05:35 -0500 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: References: Message-ID: <96D342D8-8820-49F3-A80A-07EAFCC8AC16@cox.net> The completely less thread consuming alternative is call backs. VMS used/uses Asynchronous System Traps (ASTs) for everything in the 1980s. It was a very performant and friendly way to allow small software modules to be written to do one thing and used as the call back for asynchronous system behaviors. I wrote several symbionts which did serial connection scripting for connecting to printers remotely, process management for process reuse on PMDF to speed up mail flow through the queue, and other things interactive with the kernel to alter process priorities to provide longer term scheduling on a heavily loaded 750. It was like heaven to have such a small amount of code (lots of functions, some global data). I am just suggesting that this kind of thing was a major part of more than one programming environment. Having 100?s of threads blocked on various locks adds considerably to the overhead of scheduling but also complicates cache use and burdens the developer with looping and waiting in ways that increase bugs in code that should not exist. I really feel that the kind of thing that CompletionStage provides to the developer is something that should of been more prevalent from the start. It inverts programatic logic in some cases, but call backs really are the best way to react to asynchronous eventing in software. Gregg Wonderly > On Sep 21, 2016, at 4:25 PM, Benjamin Manes wrote: > > My limited understanding is that the original API was only CompletableFuture and that CompletionStage introduced as a compromise. It did not appear to be an attempt to strictly follow an interface-implementation separation, e.g. collections. As you said #toCompletableFuture() may throw an UOE, which means some use-cases can't rely on CompletionState which limits its usefulness. In my case that would be an AsyncLoadingCache with a synchronous LoadingCache view. I think having to code that the resulting implementation would be worse if it called toCompletableFuture, caught the exception, and then adapted as you said. > > When the new future class was introduced it was stated, > > "In other words, we (j.u.c) are not now in a position to dictate a common interface for all SettableFuture, FutureValue, Promise, ListenableFuture, etc like APIs. And as we've seen, different audiences want/need different subsets of this API exposed as interfaces for their usages, and are in any case unlikely to want change all their existing interfaces. However, what we can do is provide a common underlying implementation that is as fast, scalable, space-conserving, carefully-specified, and reliable as possible. It should then be easy and attractive for others creating or reworking higher-level APIs to relay all functionality to the CompletableFuture implementation." - Doug Lea, '12 > > I've gradually come to terms using CF as part of an API and haven't experienced a downside yet. > > On Wed, Sep 21, 2016 at 1:43 PM, Martin Buchholz > wrote: > (Sorry to re-open this discussion) > > The separation of a read-only CompletionStage from CompletableFuture is great. I'm a fan of the scala style Promise/Future split as described in http://docs.scala-lang.org/overviews/core/futures.html , but: we need to re-add (safe, read-only) blocking methods like join. Java is not Node.js, where there are no threads but there is a universal event loop. Java programmers are used to Future, where the *only* way to use a future's value is to block waiting for it. The existing CompletionStage methods are a better scaling alternative to blocking all the time, but blocking is almost always eventually necessary in Java. For example, junit test methods that start any asynchronous computation need to block until the computation is done, before returning. > > As Viktor has pointed out, users can always implement blocking themselves by writing > > static CompletableFuture toCompletableFuture(CompletionStage stage) { > CompletableFuture f = new CompletableFuture<>(); > stage.handle((T t, Throwable ex) -> { > if (ex != null) f.completeExceptionally(ex); > else f.complete(t); > return null; > }); > return f; > } > > static T join(CompletionStage stage) { > return toCompletableFuture(stage).join(); > } > > but unlike Viktor, I think it's unreasonable to not provide this for users (especially when we can do so more efficiently). What is happening instead is API providers not using CompletionStage as return values in public APIs because of the lack of convenient blocking, and instead returning CompletableFuture, which is a tragic software engineering failure. > > Re-adding join is easy. We discourage CompletionStage.toCompletableFuture from throwing UnsupportedOperationException, and implement join as: > > public default T join() { return toCompletableFuture().join(); } > > There is a risk of multiple-inheritance conflict with Future if we add e.g. isDone(), but there are no current plans to turn those Future methods into default methods, and even if we did in some future release, it would be only a source, not binary incompatibility, so far less serious. > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest From kirk at kodewerk.com Wed Sep 28 15:15:43 2016 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Wed, 28 Sep 2016 17:15:43 +0200 Subject: [concurrency-interest] We need to add blocking methods to CompletionStage! In-Reply-To: <96D342D8-8820-49F3-A80A-07EAFCC8AC16@cox.net> References: <96D342D8-8820-49F3-A80A-07EAFCC8AC16@cox.net> Message-ID: > On Sep 28, 2016, at 5:05 PM, Gregg Wonderly wrote: > > The completely less thread consuming alternative is call backs. This is a technique that we commonly used in a system that a group of use built in the 90s. The system had many variants on a number of different data flows through the system. It could take days for a number of the services to complete so synchronous calls simply were not a practical solution. async turned out to be so simple that it was used all over. Regards, Kirk From david.holmes at oracle.com Wed Sep 28 23:47:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Sep 2016 09:47:15 +1000 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: On 29/09/2016 3:44 AM, Carsten Varming wrote: > Dear Vitaly and David, > > Looking at your webrev the original code is: > > public int hashCode() { > if (hash == 0 && value.length > 0) { > hash = isLatin1() ? StringLatin1.hashCode(value) > } > return hash; > } > > There is a constructor: > > public String(String original) { > this.value = original.value; > this.coder = original.coder; > this.hash = original.hash; > } > > that might write zero to the mutable field "hash". > > The object created by this constructor might be shared using plain reads > and writes between two threads[1] and the write of 0 in the constructor > might be interleaved with the reads and write in hashCode. Does this > capture the problem? Because String has final fields there is a freeze action at the end of construction so that String instances are always safely published even if not "safely published". David > [1]: Meaning the is no happens-before relationship established between > object construction and another thread calling hashCode on the object. > > Carsten > > On Wed, Sep 28, 2016 at 10:13 AM, Vitaly Davidovich > wrote: > > On Wednesday, September 28, 2016, David Holmes > > > wrote: > > > On 28/09/2016 10:44 PM, Peter Levart wrote: > > > >> Hi, > >> > >> According to discussion here: > >> > >> http://cs.oswego.edu/pipermail/concurrency-interest/2016- > > >> September/015414.html > >> > >> > >> it seems compact strings introduced (at least theoretical) non-benign > >> data race into String.hasCode() method. > >> > >> Here is a proposed patch: > >> > >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String > . > >> hashCode/webrev.01/ > >> > > > > I'm far from convinced that the bug exists - theoretical or > otherwise - > > but the "fix" is harmless. > > > > When we were working on JSR-133 one of the conceptual models is > that every > > write to a variable goes into the set of values that a read may > potentially > > return (so no out-of-thin-air for example). happens-before establishes > > constraints on which value can legally be returned - the most > recent. An > > additional property was that once a value was returned, a later > read could > > not return an earlier value - in essence once a read returns a > given value, > > all earlier written values are removed from the set of potential > values > > that can be read. > > > > Your bug requires that the code act as-if written: > > > > int temp = hash; > > if (temp == 0) { > > hash = ... > > } > > return temp; > > It's the other way I think: > > int temp = hash; // read 0 > if (hash == 0) // reread a non 0 > hash = temp = ... > return temp // return 0 > > It's unlikely but what prohibits that? > > > > > and I do not believe that is allowed. > > > > David > > > > > >> For the bug: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8166842 > > >> > >> > >> > >> JDK 8 did not have this problem, so no back-porting necessary. > >> > >> Regards, Peter > >> > >> > > -- > Sent from my phone > > From david.holmes at oracle.com Wed Sep 28 23:48:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Sep 2016 09:48:05 +1000 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> <4d006383-f1ba-8c04-37a5-5436f43aaa78@gmail.com> Message-ID: <8d4cdf04-1992-0508-85f4-bd0678ed2e12@oracle.com> On 28/09/2016 11:26 PM, Aleksey Shipilev wrote: > Peter, David, > > Would you mind discussing the theoretical topics on > concurrency-interest@, for the benefits of others who don't track > high-traffic OpenJDK list? Well, noone responded to my comment on c-i, and I didn't expect a patch to appear on core-libs-dev so quickly. David > Thanks, > -Aleksey > > On 09/28/2016 03:24 PM, Peter Levart wrote: >> >> On 09/28/2016 03:05 PM, David Holmes wrote: >>> On 28/09/2016 10:44 PM, Peter Levart wrote: >>>> Hi, >>>> >>>> According to discussion here: >>>> >>>> http://cs.oswego.edu/pipermail/concurrency-interest/2016-September/015414.html >>>> >>>> >>>> >>>> it seems compact strings introduced (at least theoretical) non-benign >>>> data race into String.hasCode() method. >>>> >>>> Here is a proposed patch: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ >>>> >>> >>> I'm far from convinced that the bug exists - theoretical or otherwise >>> - but the "fix" is harmless. >>> >>> When we were working on JSR-133 one of the conceptual models is that >>> every write to a variable goes into the set of values that a read may >>> potentially return (so no out-of-thin-air for example). happens-before >>> establishes constraints on which value can legally be returned - the >>> most recent. An additional property was that once a value was >>> returned, a later read could not return an earlier value - in essence >>> once a read returns a given value, all earlier written values are >>> removed from the set of potential values that can be read. >> >> That would be a nice property, yes. >> >>> >>> Your bug requires that the code act as-if written: >>> >>> int temp = hash; >>> if (temp == 0) { >>> hash = ... >>> } >>> return temp; >>> >>> and I do not believe that is allowed. >>> >>> David >> >> Well, I can't find anything like that in JMM description. Could you >> point me to it? Above example only reads once from hash. The code in >> question is this: >> >> if (hash == 0) { // 1st read >> hash = ... >> } >> return hash; // 2nd read >> >> And the bug requires the code to act like: >> >> int temp2 = hash; // 2nd read >> int temp1 = hash; // 1st read >> if (temp1 == 0) { >> return (hash = ...); >> } >> return temp2; >> >> >> Is this allowed? >> >> Regards, Peter >> >>> >>>> >>>> For the bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8166842 >>>> >>>> >>>> >>>> JDK 8 did not have this problem, so no back-porting necessary. >>>> >>>> Regards, Peter >>>> >> > From david.holmes at oracle.com Thu Sep 29 00:42:04 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Sep 2016 10:42:04 +1000 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: <4d006383-f1ba-8c04-37a5-5436f43aaa78@gmail.com> References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> <4d006383-f1ba-8c04-37a5-5436f43aaa78@gmail.com> Message-ID: On 28/09/2016 11:24 PM, Peter Levart wrote: > > On 09/28/2016 03:05 PM, David Holmes wrote: >> On 28/09/2016 10:44 PM, Peter Levart wrote: >>> Hi, >>> >>> According to discussion here: >>> >>> http://cs.oswego.edu/pipermail/concurrency-interest/2016-September/015414.html >>> >>> it seems compact strings introduced (at least theoretical) non-benign >>> data race into String.hasCode() method. >>> >>> Here is a proposed patch: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ >>> >> >> I'm far from convinced that the bug exists - theoretical or otherwise >> - but the "fix" is harmless. >> >> When we were working on JSR-133 one of the conceptual models is that >> every write to a variable goes into the set of values that a read may >> potentially return (so no out-of-thin-air for example). happens-before >> establishes constraints on which value can legally be returned - the >> most recent. An additional property was that once a value was >> returned, a later read could not return an earlier value - in essence >> once a read returns a given value, all earlier written values are >> removed from the set of potential values that can be read. > > That would be a nice property, yes. > >> >> Your bug requires that the code act as-if written: >> >> int temp = hash; >> if (temp == 0) { >> hash = ... >> } >> return temp; >> >> and I do not believe that is allowed. >> >> David > > Well, I can't find anything like that in JMM description. Could you > point me to it? Above example only reads once from hash. The code in > question is this: > > if (hash == 0) { // 1st read > hash = ... > } > return hash; // 2nd read > > And the bug requires the code to act like: > > int temp2 = hash; // 2nd read > int temp1 = hash; // 1st read > if (temp1 == 0) { > return (hash = ...); > } > return temp2; Given hash is not a volatile field there is nothing that requires the compiler to emit code that reads it twice - of course javac will issue getfields as per the source code. So the compiler is of course allowed to read it twice, but you then want it to reorder those reads such that the second use uses the value of the first read, and the first use uses the value of the second read. I recall discussions of such perverse compiler behaviour in the past. :( > Is this allowed? Sadly yes. What we ended up with in JLS Ch17 permits this - it is a variation of the aliasing example in 17.4. There are places where the formalization of the JMM "threw the baby out with the bath water" IMHO. Some of the less formal descriptions made far more sense - like the notion of there being a set of values a read may return, and how happens-before constrains that, and how once a value is returned you cant then "read" an earlier value. Thanks, David > Regards, Peter > >> >>> >>> For the bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8166842 >>> >>> >>> >>> JDK 8 did not have this problem, so no back-porting necessary. >>> >>> Regards, Peter >>> > From cvarming at twitter.com Thu Sep 29 00:49:57 2016 From: cvarming at twitter.com (Carsten Varming) Date: Wed, 28 Sep 2016 20:49:57 -0400 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: Dear David, See inline. On Wed, Sep 28, 2016 at 7:47 PM, David Holmes wrote: > On 29/09/2016 3:44 AM, Carsten Varming wrote: > >> Dear Vitaly and David, >> >> Looking at your webrev the original code is: >> >> public int hashCode() { >> if (hash == 0 && value.length > 0) { >> hash = isLatin1() ? StringLatin1.hashCode(value) >> } >> return hash; >> } >> >> There is a constructor: >> >> public String(String original) { >> this.value = original.value; >> this.coder = original.coder; >> this.hash = original.hash; >> } >> >> that might write zero to the mutable field "hash". >> >> The object created by this constructor might be shared using plain reads >> and writes between two threads[1] and the write of 0 in the constructor >> might be interleaved with the reads and write in hashCode. Does this >> capture the problem? >> > > Because String has final fields there is a freeze action at the end of > construction so that String instances are always safely published even if > not "safely published". > I always thought that the freeze action only freezes final fields. The hash field in String is not final and example 17.5-1 is applicable as far as I can see ( https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5). Has the memory model changed in JDK9 to invalidate example 17.5-1 or I am missing something about String. Carsten > David > > > [1]: Meaning the is no happens-before relationship established between >> object construction and another thread calling hashCode on the object. >> >> Carsten >> >> On Wed, Sep 28, 2016 at 10:13 AM, Vitaly Davidovich > > wrote: >> >> On Wednesday, September 28, 2016, David Holmes >> > >> wrote: >> >> > On 28/09/2016 10:44 PM, Peter Levart wrote: >> > >> >> Hi, >> >> >> >> According to discussion here: >> >> >> >> http://cs.oswego.edu/pipermail/concurrency-interest/2016- >> >> >> September/015414.html >> >> >> >> >> >> it seems compact strings introduced (at least theoretical) >> non-benign >> >> data race into String.hasCode() method. >> >> >> >> Here is a proposed patch: >> >> >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String >> . >> >> >> hashCode/webrev.01/ >> >> >> > >> > I'm far from convinced that the bug exists - theoretical or >> otherwise - >> > but the "fix" is harmless. >> > >> > When we were working on JSR-133 one of the conceptual models is >> that every >> > write to a variable goes into the set of values that a read may >> potentially >> > return (so no out-of-thin-air for example). happens-before >> establishes >> > constraints on which value can legally be returned - the most >> recent. An >> > additional property was that once a value was returned, a later >> read could >> > not return an earlier value - in essence once a read returns a >> given value, >> > all earlier written values are removed from the set of potential >> values >> > that can be read. >> > >> > Your bug requires that the code act as-if written: >> > >> > int temp = hash; >> > if (temp == 0) { >> > hash = ... >> > } >> > return temp; >> >> It's the other way I think: >> >> int temp = hash; // read 0 >> if (hash == 0) // reread a non 0 >> hash = temp = ... >> return temp // return 0 >> >> It's unlikely but what prohibits that? >> >> > >> > and I do not believe that is allowed. >> > >> > David >> > >> > >> >> For the bug: >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8166842 >> >> >> >> >> >> >> >> >> JDK 8 did not have this problem, so no back-porting necessary. >> >> >> >> Regards, Peter >> >> >> >> >> >> -- >> Sent from my phone >> >> >> From vitalyd at gmail.com Thu Sep 29 00:58:26 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 28 Sep 2016 20:58:26 -0400 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: On Wednesday, September 28, 2016, Carsten Varming wrote: > Dear David, > > See inline. > > On Wed, Sep 28, 2016 at 7:47 PM, David Holmes > wrote: > >> On 29/09/2016 3:44 AM, Carsten Varming wrote: >> >>> Dear Vitaly and David, >>> >>> Looking at your webrev the original code is: >>> >>> public int hashCode() { >>> if (hash == 0 && value.length > 0) { >>> hash = isLatin1() ? StringLatin1.hashCode(value) >>> } >>> return hash; >>> } >>> >>> There is a constructor: >>> >>> public String(String original) { >>> this.value = original.value; >>> this.coder = original.coder; >>> this.hash = original.hash; >>> } >>> >>> that might write zero to the mutable field "hash". >>> >>> The object created by this constructor might be shared using plain reads >>> and writes between two threads[1] and the write of 0 in the constructor >>> might be interleaved with the reads and write in hashCode. Does this >>> capture the problem? >>> >> >> Because String has final fields there is a freeze action at the end of >> construction so that String instances are always safely published even if >> not "safely published". >> > > I always thought that the freeze action only freezes final fields. The > hash field in String is not final and example 17.5-1 is applicable as far > as I can see (https://docs.oracle.com/javase/specs/jls/se8/html/jls- > 17.html#jls-17.5). Has the memory model changed in JDK9 to invalidate > example 17.5-1 or I am missing something about String. > Right - the spec only talks about final fields being ok in such cases. In practice, compilers put a freeze action at the end of the constructor and non-final fields come along for the ride, AFAIK. However, I'm not sure this example is all that interesting. Suppose you published a String copied from another, but the hash value was reordered and didn't appear to the reader. That ought to be fine because hashCode is supposed to recompute it. At worst, you perform the same computation "unnecessarily". The possible compiler reordering, as discussed in this thread, within hashCode itself is problematic because it can, theoretically, yield 0 erroneously. > > Carsten > > >> David >> >> >> [1]: Meaning the is no happens-before relationship established between >>> object construction and another thread calling hashCode on the object. >>> >>> Carsten >>> >>> On Wed, Sep 28, 2016 at 10:13 AM, Vitaly Davidovich >> >>> >> >> wrote: >>> >>> On Wednesday, September 28, 2016, David Holmes >>> >> >> david.holmes at oracle.com >>> >> >>> wrote: >>> >>> > On 28/09/2016 10:44 PM, Peter Levart wrote: >>> > >>> >> Hi, >>> >> >>> >> According to discussion here: >>> >> >>> >> http://cs.oswego.edu/pipermail/concurrency-interest/2016- >>> >>> >> September/015414.html >>> >> >>> >> >>> >> it seems compact strings introduced (at least theoretical) >>> non-benign >>> >> data race into String.hasCode() method. >>> >> >>> >> Here is a proposed patch: >>> >> >>> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String >>> . >>> >>> >> hashCode/webrev.01/ >>> >> >>> > >>> > I'm far from convinced that the bug exists - theoretical or >>> otherwise - >>> > but the "fix" is harmless. >>> > >>> > When we were working on JSR-133 one of the conceptual models is >>> that every >>> > write to a variable goes into the set of values that a read may >>> potentially >>> > return (so no out-of-thin-air for example). happens-before >>> establishes >>> > constraints on which value can legally be returned - the most >>> recent. An >>> > additional property was that once a value was returned, a later >>> read could >>> > not return an earlier value - in essence once a read returns a >>> given value, >>> > all earlier written values are removed from the set of potential >>> values >>> > that can be read. >>> > >>> > Your bug requires that the code act as-if written: >>> > >>> > int temp = hash; >>> > if (temp == 0) { >>> > hash = ... >>> > } >>> > return temp; >>> >>> It's the other way I think: >>> >>> int temp = hash; // read 0 >>> if (hash == 0) // reread a non 0 >>> hash = temp = ... >>> return temp // return 0 >>> >>> It's unlikely but what prohibits that? >>> >>> > >>> > and I do not believe that is allowed. >>> > >>> > David >>> > >>> > >>> >> For the bug: >>> >> >>> >> https://bugs.openjdk.java.net/browse/JDK-8166842 >>> >>> >> >>> >> >>> >> >>> >> JDK 8 did not have this problem, so no back-porting necessary. >>> >> >>> >> Regards, Peter >>> >> >>> >> >>> >>> -- >>> Sent from my phone >>> >>> >>> > -- Sent from my phone From vitalyd at gmail.com Thu Sep 29 01:05:32 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 28 Sep 2016 21:05:32 -0400 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> <4d006383-f1ba-8c04-37a5-5436f43aaa78@gmail.com> Message-ID: On Wednesday, September 28, 2016, David Holmes wrote: > On 28/09/2016 11:24 PM, Peter Levart wrote: > >> >> On 09/28/2016 03:05 PM, David Holmes wrote: >> >>> On 28/09/2016 10:44 PM, Peter Levart wrote: >>> >>>> Hi, >>>> >>>> According to discussion here: >>>> >>>> http://cs.oswego.edu/pipermail/concurrency-interest/2016- >>>> September/015414.html >>>> >>>> it seems compact strings introduced (at least theoretical) non-benign >>>> data race into String.hasCode() method. >>>> >>>> Here is a proposed patch: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String. >>>> hashCode/webrev.01/ >>>> >>>> >>> I'm far from convinced that the bug exists - theoretical or otherwise >>> - but the "fix" is harmless. >>> >>> When we were working on JSR-133 one of the conceptual models is that >>> every write to a variable goes into the set of values that a read may >>> potentially return (so no out-of-thin-air for example). happens-before >>> establishes constraints on which value can legally be returned - the >>> most recent. An additional property was that once a value was >>> returned, a later read could not return an earlier value - in essence >>> once a read returns a given value, all earlier written values are >>> removed from the set of potential values that can be read. >>> >> >> That would be a nice property, yes. >> >> >>> Your bug requires that the code act as-if written: >>> >>> int temp = hash; >>> if (temp == 0) { >>> hash = ... >>> } >>> return temp; >>> >>> and I do not believe that is allowed. >>> >>> David >>> >> >> Well, I can't find anything like that in JMM description. Could you >> point me to it? Above example only reads once from hash. The code in >> question is this: >> >> if (hash == 0) { // 1st read >> hash = ... >> } >> return hash; // 2nd read >> >> And the bug requires the code to act like: >> >> int temp2 = hash; // 2nd read >> int temp1 = hash; // 1st read >> if (temp1 == 0) { >> return (hash = ...); >> } >> return temp2; >> > > Given hash is not a volatile field there is nothing that requires the > compiler to emit code that reads it twice - of course javac will issue > getfields as per the source code. I don't think there's anything preventing it from reading it any number of times so long as intra-thread semantics are preserved. > > So the compiler is of course allowed to read it twice, but you then want > it to reorder those reads such that the second use uses the value of the > first read, and the first use uses the value of the second read. I gave a pseudo example upthread. It would be weird codegen but allowed. > > I recall discussions of such perverse compiler behaviour in the past. :( Be thankful that at least an explicit read into a local is preserved - C++ compilers are allowed to reload in that case too unless the local is marked volatile. None of this is an issue when not using data races. If you choose to engage in a data race, gotta play by the rules :). > > Is this allowed? >> > > Sadly yes. What we ended up with in JLS Ch17 permits this - it is a > variation of the aliasing example in 17.4. > > There are places where the formalization of the JMM "threw the baby out > with the bath water" IMHO. Some of the less formal descriptions made far > more sense - like the notion of there being a set of values a read may > return, and how happens-before constrains that, and how once a value is > returned you cant then "read" an earlier value. > > Thanks, > David > > Regards, Peter >> >> >>> >>>> For the bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8166842 >>>> >>>> >>>> >>>> JDK 8 did not have this problem, so no back-porting necessary. >>>> >>>> Regards, Peter >>>> >>>> >> -- Sent from my phone From hboehm at google.com Thu Sep 29 03:55:16 2016 From: hboehm at google.com (Hans Boehm) Date: Wed, 28 Sep 2016 20:55:16 -0700 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> <4d006383-f1ba-8c04-37a5-5436f43aaa78@gmail.com> Message-ID: There are of course good reasons for allowing reordering of reads from the same location, at least for ordinary fields: 1. Otherwise the compiler wouldn't be able to combine the two reads of a.x in r1 = a.x; r2 = b.x; r3 = a.x unless it could prove that a and b refer to different objects. It typically can't. (This was Bill Pugh's "reads kill" observation that helped motivate the 2005 memory model revision.) 2. One or two machines actually don't enforce ordering of ordinary loads from the same location, perhaps for similar reasons. The canonical example is Itanium. Note that these arguments are much weaker for C++ memory_order_relaxed, because we expect those accesses to be involved in races. Hence memory_order_relaxed is willing to accept the cost and prohibit this. (C++ compilers are not allowed to repeat an atomic memory_order_relaxed load, but they may indeed do so for ordinary loads. Which follows for the fact that data races are unambiguously bugs in C++.) On Wed, Sep 28, 2016 at 6:05 PM, Vitaly Davidovich wrote: > On Wednesday, September 28, 2016, David Holmes > wrote: > > > On 28/09/2016 11:24 PM, Peter Levart wrote: > > > >> > >> On 09/28/2016 03:05 PM, David Holmes wrote: > >> > >>> On 28/09/2016 10:44 PM, Peter Levart wrote: > >>> > >>>> Hi, > >>>> > >>>> According to discussion here: > >>>> > >>>> http://cs.oswego.edu/pipermail/concurrency-interest/2016- > >>>> September/015414.html > >>>> > >>>> it seems compact strings introduced (at least theoretical) non-benign > >>>> data race into String.hasCode() method. > >>>> > >>>> Here is a proposed patch: > >>>> > >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String. > >>>> hashCode/webrev.01/ > >>>> > >>>> > >>> I'm far from convinced that the bug exists - theoretical or otherwise > >>> - but the "fix" is harmless. > >>> > >>> When we were working on JSR-133 one of the conceptual models is that > >>> every write to a variable goes into the set of values that a read may > >>> potentially return (so no out-of-thin-air for example). happens-before > >>> establishes constraints on which value can legally be returned - the > >>> most recent. An additional property was that once a value was > >>> returned, a later read could not return an earlier value - in essence > >>> once a read returns a given value, all earlier written values are > >>> removed from the set of potential values that can be read. > >>> > >> > >> That would be a nice property, yes. > >> > >> > >>> Your bug requires that the code act as-if written: > >>> > >>> int temp = hash; > >>> if (temp == 0) { > >>> hash = ... > >>> } > >>> return temp; > >>> > >>> and I do not believe that is allowed. > >>> > >>> David > >>> > >> > >> Well, I can't find anything like that in JMM description. Could you > >> point me to it? Above example only reads once from hash. The code in > >> question is this: > >> > >> if (hash == 0) { // 1st read > >> hash = ... > >> } > >> return hash; // 2nd read > >> > >> And the bug requires the code to act like: > >> > >> int temp2 = hash; // 2nd read > >> int temp1 = hash; // 1st read > >> if (temp1 == 0) { > >> return (hash = ...); > >> } > >> return temp2; > >> > > > > Given hash is not a volatile field there is nothing that requires the > > compiler to emit code that reads it twice - of course javac will issue > > getfields as per the source code. > > I don't think there's anything preventing it from reading it any number of > times so long as intra-thread semantics are preserved. > > > > > So the compiler is of course allowed to read it twice, but you then want > > it to reorder those reads such that the second use uses the value of the > > first read, and the first use uses the value of the second read. > > I gave a pseudo example upthread. It would be weird codegen but allowed. > > > > > I recall discussions of such perverse compiler behaviour in the past. :( > > Be thankful that at least an explicit read into a local is preserved - C++ > compilers are allowed to reload in that case too unless the local is marked > volatile. > > None of this is an issue when not using data races. If you choose to > engage in a data race, gotta play by the rules :). > > > > > Is this allowed? > >> > > > > Sadly yes. What we ended up with in JLS Ch17 permits this - it is a > > variation of the aliasing example in 17.4. > > > > There are places where the formalization of the JMM "threw the baby out > > with the bath water" IMHO. Some of the less formal descriptions made far > > more sense - like the notion of there being a set of values a read may > > return, and how happens-before constrains that, and how once a value is > > returned you cant then "read" an earlier value. > > > > Thanks, > > David > > > > Regards, Peter > >> > >> > >>> > >>>> For the bug: > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8166842 > >>>> > >>>> > >>>> > >>>> JDK 8 did not have this problem, so no back-porting necessary. > >>>> > >>>> Regards, Peter > >>>> > >>>> > >> > > -- > Sent from my phone > From david.holmes at oracle.com Thu Sep 29 04:31:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Sep 2016 14:31:01 +1000 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: On 29/09/2016 10:49 AM, Carsten Varming wrote: > Dear David, > > See inline. > > On Wed, Sep 28, 2016 at 7:47 PM, David Holmes > wrote: > > On 29/09/2016 3:44 AM, Carsten Varming wrote: > > Dear Vitaly and David, > > Looking at your webrev the original code is: > > public int hashCode() { > if (hash == 0 && value.length > 0) { > hash = isLatin1() ? StringLatin1.hashCode(value) > } > return hash; > } > > There is a constructor: > > public String(String original) { > this.value = original.value; > this.coder = original.coder; > this.hash = original.hash; > } > > that might write zero to the mutable field "hash". > > The object created by this constructor might be shared using > plain reads > and writes between two threads[1] and the write of 0 in the > constructor > might be interleaved with the reads and write in hashCode. Does this > capture the problem? > > > Because String has final fields there is a freeze action at the end > of construction so that String instances are always safely published > even if not "safely published". > > > I always thought that the freeze action only freezes final fields. The > hash field in String is not final and example 17.5-1 is applicable as > far as I can see > (https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5). Has > the memory model changed in JDK9 to invalidate example 17.5-1 or I am > missing something about String. Sorry - I was confusing what the spec says versus what the VM actually does - as Vitaly pointed out. David > > Carsten > > > David > > > [1]: Meaning the is no happens-before relationship established > between > object construction and another thread calling hashCode on the > object. > > Carsten > > On Wed, Sep 28, 2016 at 10:13 AM, Vitaly Davidovich > > >> wrote: > > On Wednesday, September 28, 2016, David Holmes > > >> > wrote: > > > On 28/09/2016 10:44 PM, Peter Levart wrote: > > > >> Hi, > >> > >> According to discussion here: > >> > >> http://cs.oswego.edu/pipermail/concurrency-interest/2016- > > > > >> September/015414.html > >> > >> > >> it seems compact strings introduced (at least > theoretical) non-benign > >> data race into String.hasCode() method. > >> > >> Here is a proposed patch: > >> > >> > http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String > > >. > > >> hashCode/webrev.01/ > >> > > > > I'm far from convinced that the bug exists - theoretical or > otherwise - > > but the "fix" is harmless. > > > > When we were working on JSR-133 one of the conceptual > models is > that every > > write to a variable goes into the set of values that a > read may > potentially > > return (so no out-of-thin-air for example). happens-before > establishes > > constraints on which value can legally be returned - the most > recent. An > > additional property was that once a value was returned, a > later > read could > > not return an earlier value - in essence once a read returns a > given value, > > all earlier written values are removed from the set of > potential > values > > that can be read. > > > > Your bug requires that the code act as-if written: > > > > int temp = hash; > > if (temp == 0) { > > hash = ... > > } > > return temp; > > It's the other way I think: > > int temp = hash; // read 0 > if (hash == 0) // reread a non 0 > hash = temp = ... > return temp // return 0 > > It's unlikely but what prohibits that? > > > > > and I do not believe that is allowed. > > > > David > > > > > >> For the bug: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8166842 > > > > >> > >> > >> > >> JDK 8 did not have this problem, so no back-porting > necessary. > >> > >> Regards, Peter > >> > >> > > -- > Sent from my phone > > > From Alan.Bateman at oracle.com Thu Sep 29 06:54:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Sep 2016 07:54:56 +0100 Subject: Review Request: JDK-8166238 Update jdeps for GNU-style long form options In-Reply-To: <82C4F2FE-D612-4E79-8594-4C749879DBBB@oracle.com> References: <82C4F2FE-D612-4E79-8594-4C749879DBBB@oracle.com> Message-ID: On 28/09/2016 01:58, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166238/webrev.00/index.html > > This patch renames the following options added in JDK 9 jdeps > --gen-module-info => ?generate-module-info > -inverse => ?-inverse > -requires => ?-require > > and also adds the long-form option corresponding to a few existing options: > ?-api-only > ?-dot-output > -?jdk-internals > ?-package > ?-regex > -?version > This looks okay. In passing, the usage message uses "dependencies" in some places, "dependences" in others - we should check those. -Alan From volker.simonis at gmail.com Thu Sep 29 07:03:07 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 29 Sep 2016 09:03:07 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> Message-ID: On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen wrote: > > On Sep 28, 2016, at 11:50 AM, Thomas St?fe wrote: > > > > On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz > wrote: >> >> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis >> wrote: >> >> > >> > I don't think this can be easily done with the current build system. >> > Remember for example that even such a sensitive part like jni.h is >> > still duplicated between the hotspot and the jdk repository: >> > >> > hotspot/src/share/vm/prims/jni.h >> > jdk/src/java.base/share/native/include/jni.h >> > >> >> It's one of the frustrating aspects of openjdk development that it's hard >> to share C level infrastructure among different components. Components >> sometimes grow their own local C infrastructure, but when another >> component >> has the same problem, one often resorts to copy-paste as the most >> expedient >> way to get code reuse. In part, the mercurial repo organization >> reinforces >> this - there is one top-level repo with fan-out, but there is nothing at >> the bottom with fan-in. > > > At SAP, we often solve this by moving code to the hotspot and exporting it > from there, the hotspot being the central part which (almost) has to be > loaded from the very beginning. I think we did this for dladdr() too. > As I said before, this obviously can't work for libjli which is used to dynamically load the libjvm. > But that is an ugly hack too, because it bloats the hotspot and forces us to > add -ljvm to a lot of makefiles or to resolve those functions dynamically. > > Another solution for us on AIX could be to put this stuff into an own > library and provide it independently from the OpenJDK build system, just > declare it to be a build dependency, similar to Apples JavaRuntimeServices. > > As we need dladdr() in both hotspot and JDK, maybe that would be the best > option. > > > That sounds like a reasonable solution to me. > Sorry, but that doesn't sound like a solution to me at all. I think we should keep the OpenJDK sources self-contained. I don't want to depend on yet another non-standard, third party library which doesn't even exist now. The solution proposed by Martin could work, but it is not great from a software engineering perspective either because it doesn't allow sharing of header files. What would be actually needed would be a new top-level repository/directory (call it 'base' or 'porting' or whatsoever) which should be organized like for example jdk/java.base/src (i.e. have 'share/', 'unix/', 'windows/', etc. subdirectories. The artifacts from this new directory would be build as the very first step of the build process (if necessary) and the results, as well as the source directories themselves would have to be made available to all the other build steps (in particular to. hotspot and jdk). In fact I had implemented a similar solution for the jdk repository in order to stay with a single copy of dladdr on AIX (i.e. jdk/src/aix/porting). But this solution had to go away when the sources were modularized because the new schema doesn't allow sharing of files between modules anymore :( However, I'm not sure if we want to start such a project right now? > Chris > > > > >> >> One code sharing mechanism that does get used is seen in >> ClassLoader::load_zip_library() >> where code from the jdk repo is packaged into a shared object and invoked >> from hotspot, dynamically. > > > From aph at redhat.com Thu Sep 29 08:59:30 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Sep 2016 09:59:30 +0100 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: <393fd631-4525-1c52-5b5e-7eb862e01e21@redhat.com> On 29/09/16 05:31, David Holmes wrote: > > On 29/09/2016 10:49 AM, Carsten Varming wrote: >> Because String has final fields there is a freeze action at the end >> of construction so that String instances are always safely published >> even if not "safely published". >> >> >> I always thought that the freeze action only freezes final fields. The >> hash field in String is not final and example 17.5-1 is applicable as >> far as I can see >> (https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5). Has >> the memory model changed in JDK9 to invalidate example 17.5-1 or I am >> missing something about String. > > Sorry - I was confusing what the spec says versus what the VM actually > does - as Vitaly pointed out. A HotSpot back end could rewrite the constructor so that the last final field to be written used a store release instruction. Whether it should is another matter: I suppose it would be rather risky. Andrew. From erik.joelsson at oracle.com Thu Sep 29 09:06:02 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 29 Sep 2016 11:06:02 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> Message-ID: <08b8536e-ce14-f0d5-295f-37df2286806f@oracle.com> Hello, From my point of view, now that I better understand what aix/porting actually was/is, I would say go for it. Put something together the way you would like it. I doubt there will ever be much code needed in this new entity so it can go in the top level repo without problems. There is already a common/src you can sort it into. I assume you will want to build a static lib that is easily picked up by other libraries and provide an include directory. Put a new makefile in /make that builds this, create a new top level target in /make/Main.gmk that calls it. Build it into /support/native/. Since this is only for AIX now, surround it with proper ifeqs. Doesn't really seem that complicated to me. :) Neither hotspot nor JDK is buildable on their own now, so there is no problem putting dependencies on either at the top level. /Erik On 2016-09-29 09:03, Volker Simonis wrote: > On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen wrote: >> On Sep 28, 2016, at 11:50 AM, Thomas St?fe wrote: >> >> >> >> On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz >> wrote: >>> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis >>> wrote: >>> >>>> I don't think this can be easily done with the current build system. >>>> Remember for example that even such a sensitive part like jni.h is >>>> still duplicated between the hotspot and the jdk repository: >>>> >>>> hotspot/src/share/vm/prims/jni.h >>>> jdk/src/java.base/share/native/include/jni.h >>>> >>> It's one of the frustrating aspects of openjdk development that it's hard >>> to share C level infrastructure among different components. Components >>> sometimes grow their own local C infrastructure, but when another >>> component >>> has the same problem, one often resorts to copy-paste as the most >>> expedient >>> way to get code reuse. In part, the mercurial repo organization >>> reinforces >>> this - there is one top-level repo with fan-out, but there is nothing at >>> the bottom with fan-in. >> >> At SAP, we often solve this by moving code to the hotspot and exporting it >> from there, the hotspot being the central part which (almost) has to be >> loaded from the very beginning. I think we did this for dladdr() too. >> > As I said before, this obviously can't work for libjli which is used > to dynamically load the libjvm. > >> But that is an ugly hack too, because it bloats the hotspot and forces us to >> add -ljvm to a lot of makefiles or to resolve those functions dynamically. >> >> Another solution for us on AIX could be to put this stuff into an own >> library and provide it independently from the OpenJDK build system, just >> declare it to be a build dependency, similar to Apples JavaRuntimeServices. >> >> As we need dladdr() in both hotspot and JDK, maybe that would be the best >> option. >> >> >> That sounds like a reasonable solution to me. >> > Sorry, but that doesn't sound like a solution to me at all. I think we > should keep the OpenJDK sources self-contained. I don't want to depend > on yet another non-standard, third party library which doesn't even > exist now. > > The solution proposed by Martin could work, but it is not great from a > software engineering perspective either because it doesn't allow > sharing of header files. > > What would be actually needed would be a new top-level > repository/directory (call it 'base' or 'porting' or whatsoever) which > should be organized like for example jdk/java.base/src (i.e. have > 'share/', 'unix/', 'windows/', etc. subdirectories. > > The artifacts from this new directory would be build as the very first > step of the build process (if necessary) and the results, as well as > the source directories themselves would have to be made available to > all the other build steps (in particular to. hotspot and jdk). In fact > I had implemented a similar solution for the jdk repository in order > to stay with a single copy of dladdr on AIX (i.e. > jdk/src/aix/porting). But this solution had to go away when the > sources were modularized because the new schema doesn't allow sharing > of files between modules anymore :( > > However, I'm not sure if we want to start such a project right now? > >> Chris >> >> >> >> >>> One code sharing mechanism that does get used is seen in >>> ClassLoader::load_zip_library() >>> where code from the jdk repo is packaged into a shared object and invoked >>> from hotspot, dynamically. >> >> From peter.levart at gmail.com Thu Sep 29 09:31:30 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 29 Sep 2016 11:31:30 +0200 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: On 09/29/2016 02:58 AM, Vitaly Davidovich wrote: > On Wednesday, September 28, 2016, Carsten Varming > wrote: > >> Dear David, >> >> See inline. >> >> On Wed, Sep 28, 2016 at 7:47 PM, David Holmes > > wrote: >> >>> On 29/09/2016 3:44 AM, Carsten Varming wrote: >>> >>>> Dear Vitaly and David, >>>> >>>> Looking at your webrev the original code is: >>>> >>>> public int hashCode() { >>>> if (hash == 0 && value.length > 0) { >>>> hash = isLatin1() ? StringLatin1.hashCode(value) >>>> } >>>> return hash; >>>> } >>>> >>>> There is a constructor: >>>> >>>> public String(String original) { >>>> this.value = original.value; >>>> this.coder = original.coder; >>>> this.hash = original.hash; >>>> } >>>> >>>> that might write zero to the mutable field "hash". >>>> >>>> The object created by this constructor might be shared using plain reads >>>> and writes between two threads[1] and the write of 0 in the constructor >>>> might be interleaved with the reads and write in hashCode. Does this >>>> capture the problem? >>>> >>> Because String has final fields there is a freeze action at the end of >>> construction so that String instances are always safely published even if >>> not "safely published". >>> >> I always thought that the freeze action only freezes final fields. The >> hash field in String is not final and example 17.5-1 is applicable as far >> as I can see (https://docs.oracle.com/javase/specs/jls/se8/html/jls- >> 17.html#jls-17.5). Has the memory model changed in JDK9 to invalidate >> example 17.5-1 or I am missing something about String. >> > Right - the spec only talks about final fields being ok in such cases. In > practice, compilers put a freeze action at the end of the constructor and > non-final fields come along for the ride, AFAIK. > > However, I'm not sure this example is all that interesting. Suppose you > published a String copied from another, but the hash value was reordered > and didn't appear to the reader. That ought to be fine because hashCode is > supposed to recompute it. At worst, you perform the same computation > "unnecessarily". > > The possible compiler reordering, as discussed in this thread, within > hashCode itself is problematic because it can, theoretically, yield 0 > erroneously. I think Carsten has a point. If we bring this constructor to the picture: public String(String original) { this.value = original.value; this.coder = original.coder; this.hash = original.hash; } and combine it with the hashCode implementation: public int hashCode() { if (hash == 0 && value.length > 0) { hash = isLatin1() ? ... } return hash; } ...then we can get an erroneous result of 0 from hashCode() even without compiler (or hardware) reordering reads in hashCode(): Possible execution: Thread 3: hash = isLatin1() ? ....; // write non-zero Thread 1: if (hash == 0 && ...) // false, skip assignment Thread 2: this.hash = original.hash; // zero (hash not computed yet in original) Thread 1: return hash; // returns zero This would of course require the reference to String constructed by Thread 2 to be unsafely published to Thread 1 & 3 before this.hash in constructor is written, meaning that "freeze" action for final fields would have to be performed immediately after the write of last final field (coder). And that's another possibility that JMM allows. I think that this is enough to apply the fix, thanks. Regards, Peter >> Carsten >> >> >>> David >>> >>> >>> [1]: Meaning the is no happens-before relationship established between >>>> object construction and another thread calling hashCode on the object. >>>> >>>> Carsten >>>> >>>> On Wed, Sep 28, 2016 at 10:13 AM, Vitaly Davidovich >>> >>>> >>> >> wrote: >>>> >>>> On Wednesday, September 28, 2016, David Holmes >>>> >>> >>> david.holmes at oracle.com >>>> >> >>>> wrote: >>>> >>>> > On 28/09/2016 10:44 PM, Peter Levart wrote: >>>> > >>>> >> Hi, >>>> >> >>>> >> According to discussion here: >>>> >> >>>> >> http://cs.oswego.edu/pipermail/concurrency-interest/2016- >>>> >>>> >> September/015414.html >>>> >> >>>> >> >>>> >> it seems compact strings introduced (at least theoretical) >>>> non-benign >>>> >> data race into String.hasCode() method. >>>> >> >>>> >> Here is a proposed patch: >>>> >> >>>> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String >>>> . >>>> >>>> >> hashCode/webrev.01/ >>>> >> >>>> > >>>> > I'm far from convinced that the bug exists - theoretical or >>>> otherwise - >>>> > but the "fix" is harmless. >>>> > >>>> > When we were working on JSR-133 one of the conceptual models is >>>> that every >>>> > write to a variable goes into the set of values that a read may >>>> potentially >>>> > return (so no out-of-thin-air for example). happens-before >>>> establishes >>>> > constraints on which value can legally be returned - the most >>>> recent. An >>>> > additional property was that once a value was returned, a later >>>> read could >>>> > not return an earlier value - in essence once a read returns a >>>> given value, >>>> > all earlier written values are removed from the set of potential >>>> values >>>> > that can be read. >>>> > >>>> > Your bug requires that the code act as-if written: >>>> > >>>> > int temp = hash; >>>> > if (temp == 0) { >>>> > hash = ... >>>> > } >>>> > return temp; >>>> >>>> It's the other way I think: >>>> >>>> int temp = hash; // read 0 >>>> if (hash == 0) // reread a non 0 >>>> hash = temp = ... >>>> return temp // return 0 >>>> >>>> It's unlikely but what prohibits that? >>>> >>>> > >>>> > and I do not believe that is allowed. >>>> > >>>> > David >>>> > >>>> > >>>> >> For the bug: >>>> >> >>>> >> https://bugs.openjdk.java.net/browse/JDK-8166842 >>>> >>>> >> >>>> >> >>>> >> >>>> >> JDK 8 did not have this problem, so no back-porting necessary. >>>> >> >>>> >> Regards, Peter >>>> >> >>>> >> >>>> >>>> -- >>>> Sent from my phone >>>> >>>> >>>> From Roger.Riggs at Oracle.com Thu Sep 29 13:55:11 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 29 Sep 2016 09:55:11 -0400 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> Message-ID: <02147682-541f-9746-b6da-2cc2800165b5@Oracle.com> Hi Hamlin, One more suggested improvement. Instead of two copy/paste copies of the launch with options code, it would cleaner to create a separate RMID.launch(String[] options) method that would be passed the extra arguments. Use it in forceLogSnapshot.java and ShutdownGracefully.java. The (current) no-arg version could call the version with args with an empty array(or null). There would be only 1 copy of the launch algorithm. Roger On 9/27/2016 11:22 PM, Hamlin Li wrote: > Hi Roger, > > Thank you for reviewing. > Please check the new webrev: > http://cr.openjdk.java.net/~mli/8085192/webrev.01/, and comments > inline below. > > On 2016/9/27 23:14, Roger Riggs wrote: >> Hi Hamlin, >> >> Marking each test that uses RMID.launch with the bugid does not seem >> to be meaningful >> since the bug is in the support infrastructure of the test and not >> specific to the test itself. >> It would be overkill to try to confirm the bug was fixed by running >> all those tests. >> Putting the bugid on 1 of the tests would be sufficient. > Remove all bug ids except of the one in CheckImplClassLoader.java. >> >> JavaVM.java: >> >> - 134-138: Why define these private methods if they are not going >> to be used in outputContains? >> >> - 185: Its inefficient to convert the byte array to a string for >> when looking for each string. >> It would be cleaner for JavaVM to have public outputString and >> errorString methods >> and check them separately in RMID. >> (remove the JavaVM.outputContains method which hides which stream >> the string appeared in). > Fixed. >> (It would be a bigger change to change this to use the test library >> ProcessTools and OutputAnalyzer). > Thank you suggestion. Yes, you're right, it will be a little bit > complicated to use ProcessTools and OutputAnalyzer in this situation, > need to modify these classes, because they will block until process > terminates. So I prefer to use current implementation, as it's simple > and clear. > > Thank you > -Hamlin >> >> Roger >> >> >> On 9/27/2016 5:22 AM, Hamlin Li wrote: >>> Please review the fix for JDK-8085192. The fix checks whether it >>> fails to launch rmid due to "Port already in use" error, it will >>> launch rmid again and again(20 times at most) until no such issue. >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8085192 >>> webrev: >>> http://cr.openjdk.java.net/~mli/8085192/webrev.00/ >>> >>> Thank you >>> -Hamlin >> > From Alan.Burlison at oracle.com Thu Sep 29 14:54:28 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 29 Sep 2016 15:54:28 +0100 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> Message-ID: <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> On 29/09/2016 08:03, Volker Simonis wrote: > Sorry, but that doesn't sound like a solution to me at all. I think we > should keep the OpenJDK sources self-contained. I don't want to depend > on yet another non-standard, third party library which doesn't even > exist now. Unless I'm completely misunderstanding, that's not what is being proposed. What is being proposed is refactoring code that's currently duplicated across the JVM & JDK into a common library. Such a library would be a standard Java component, not non-standard and not third-party. I can't see what the problem is, to be honest. -- Alan Burlison -- From chris.hegarty at oracle.com Thu Sep 29 15:25:10 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Sep 2016 16:25:10 +0100 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: <02147682-541f-9746-b6da-2cc2800165b5@Oracle.com> References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> <02147682-541f-9746-b6da-2cc2800165b5@Oracle.com> Message-ID: <3E39A1E9-0764-404D-9824-85CFB75113FF@oracle.com> I have asked Hamlin to hold off on this for a day or so. I have an alternative proposal that eliminates the free port anti-pattern. -Chris. > On 29 Sep 2016, at 14:55, Roger Riggs wrote: > > Hi Hamlin, > > One more suggested improvement. Instead of two copy/paste copies of the launch with options code, > it would cleaner to create a separate RMID.launch(String[] options) method that would be passed the extra arguments. > Use it in forceLogSnapshot.java and ShutdownGracefully.java. > > The (current) no-arg version could call the version with args with an empty array(or null). > There would be only 1 copy of the launch algorithm. > > Roger > > > > On 9/27/2016 11:22 PM, Hamlin Li wrote: >> Hi Roger, >> >> Thank you for reviewing. >> Please check the new webrev: http://cr.openjdk.java.net/~mli/8085192/webrev.01/, and comments inline below. >> >> On 2016/9/27 23:14, Roger Riggs wrote: >>> Hi Hamlin, >>> >>> Marking each test that uses RMID.launch with the bugid does not seem to be meaningful >>> since the bug is in the support infrastructure of the test and not specific to the test itself. >>> It would be overkill to try to confirm the bug was fixed by running all those tests. >>> Putting the bugid on 1 of the tests would be sufficient. >> Remove all bug ids except of the one in CheckImplClassLoader.java. >>> >>> JavaVM.java: >>> >>> - 134-138: Why define these private methods if they are not going to be used in outputContains? >>> >>> - 185: Its inefficient to convert the byte array to a string for when looking for each string. >>> It would be cleaner for JavaVM to have public outputString and errorString methods >>> and check them separately in RMID. >>> (remove the JavaVM.outputContains method which hides which stream the string appeared in). >> Fixed. >>> (It would be a bigger change to change this to use the test library ProcessTools and OutputAnalyzer). >> Thank you suggestion. Yes, you're right, it will be a little bit complicated to use ProcessTools and OutputAnalyzer in this situation, need to modify these classes, because they will block until process terminates. So I prefer to use current implementation, as it's simple and clear. >> >> Thank you >> -Hamlin >>> >>> Roger >>> >>> >>> On 9/27/2016 5:22 AM, Hamlin Li wrote: >>>> Please review the fix for JDK-8085192. The fix checks whether it fails to launch rmid due to "Port already in use" error, it will launch rmid again and again(20 times at most) until no such issue. >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8085192 >>>> webrev: >>>> http://cr.openjdk.java.net/~mli/8085192/webrev.00/ >>>> >>>> Thank you >>>> -Hamlin >>> >> > From erik.joelsson at oracle.com Thu Sep 29 15:25:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 29 Sep 2016 17:25:54 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> Message-ID: On 2016-09-29 16:54, Alan Burlison wrote: > On 29/09/2016 08:03, Volker Simonis wrote: > >> Sorry, but that doesn't sound like a solution to me at all. I think we >> should keep the OpenJDK sources self-contained. I don't want to depend >> on yet another non-standard, third party library which doesn't even >> exist now. > > Unless I'm completely misunderstanding, that's not what is being > proposed. What is being proposed is refactoring code that's currently > duplicated across the JVM & JDK into a common library. Such a library > would be a standard Java component, not non-standard and not > third-party. I can't see what the problem is, to be honest. > Volker's comment above was directed at the suggestion of taking the problematic AIX specific code out of the OpenJDK repositories and create a separate library with a separate lifecycle somewhere else that OpenJDK for AIX would then need to depend on. Volker was instead proposing what you describe. /Erik From chris.bensen at oracle.com Thu Sep 29 15:47:41 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 29 Sep 2016 08:47:41 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> Message-ID: <98A61D7A-D64A-4BE7-BEB8-6927C31BCF50@oracle.com> A lot of ideas have been thrown around so solve the problem of duplicated code in this situation. And there are other cases that are nearly identical so we need a general solution. The fact is this code should be moved to a common location. Since OpenJDK depends on Posix, Windows API and a few other non standard things that are mostly standard such as dladdr, it has been suggested by me and others that a library that doesn?t depend on anything else be created containing these methods to backfill the API that OpenJDK depends on if that API is not present on that platform. If that is a library outside OpenJDK or inside I?m not sure if that matters. Fact is there should be a library that contains method such as dladdr in cases such as AIX that do not have that method. Personally I?m not sure if the hack implementation of dladdr for AIX should be located in OpenJDK. Chris > On Sep 29, 2016, at 8:25 AM, Erik Joelsson wrote: > > > > On 2016-09-29 16:54, Alan Burlison wrote: >> On 29/09/2016 08:03, Volker Simonis wrote: >> >>> Sorry, but that doesn't sound like a solution to me at all. I think we >>> should keep the OpenJDK sources self-contained. I don't want to depend >>> on yet another non-standard, third party library which doesn't even >>> exist now. >> >> Unless I'm completely misunderstanding, that's not what is being proposed. What is being proposed is refactoring code that's currently duplicated across the JVM & JDK into a common library. Such a library would be a standard Java component, not non-standard and not third-party. I can't see what the problem is, to be honest. >> > Volker's comment above was directed at the suggestion of taking the problematic AIX specific code out of the OpenJDK repositories and create a separate library with a separate lifecycle somewhere else that OpenJDK for AIX would then need to depend on. Volker was instead proposing what you describe. > > /Erik From volker.simonis at gmail.com Thu Sep 29 16:55:21 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 29 Sep 2016 18:55:21 +0200 Subject: RFR: JEP draft for Linux/s3990x port In-Reply-To: <72ddbd25-c7df-b02a-3827-d431f286c795@oracle.com> References: <72ddbd25-c7df-b02a-3827-d431f286c795@oracle.com> Message-ID: Hi Vladimir, thanks a lot for reviewing and endorsing the JEP. I've linked all the relevant issues to the JEP (they all have a link to a webrev) and change the state to "Submitted". There's just one more small shared change we need for the port for which we haven't opened a bug now because we are still working on simplifying it. The current version looks as follows: http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/9000016-constant_table_offset.patch What are the next steps? Should I add a "jdk9-fc-request" label to t he JEP and add a corresponding "FC Extension Request" comment to it? Or will this be done automatically once I move it to "Candidate"? Is there anything left to do before I can move it to "Candidate" state? Thanks a lot and best regards, Volker On Tue, Sep 27, 2016 at 8:15 PM, Vladimir Kozlov wrote: > On 9/27/16 10:49 AM, Volker Simonis wrote: >> >> Hi, >> >> can you please review and endorse the following draft JEP for the >> integration of the Linux/s390x port into the jkd9 master repository: >> >> https://bugs.openjdk.java.net/browse/JDK-8166730 > > > Good. > Add links to webrevs in a comment. It will help to get umbrella FC extension > approval. > >> >> As detailed in the JEP, the Linux/s390x requires very few shared >> changes and we therefore don't foresee any impact on the existing >> platforms at all. Following you can find a short description of the >> planned changes: >> >> hotspot: >> ======= >> >> Out for review: >> 8166560: [s390] Basic enablement of s390 port. >> http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/ >> >> Reviewed: >> 8166562: C2: Suppress relocations in scratch emit. >> http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01/ >> >> Will send RFR soon (depends on 8166560): >> 8166561: [s390] Adaptions needed for s390 port in C1 and C2. >> http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01 > > > Wrong link. > > Thanks, > Vladimir > > >> >> We are still investigating the need of these shared changes: >> >> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000011-pass_PC_to_retAddrOffset.patch >> >> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000016-constant_table_offset.patch >> >> And finally the patch with the s390x-only platform files. We are still >> editing these to get them into OpenJdk style and shape. >> Hotspot passes most jck, jtreg and spec tests with these. >> >> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000101-zFiles.patch >> >> top-level repository: >> =============== >> >> The following is just adding some s390x specific compiler flags to >> flags.m4 >> 8166800: [s390] Top-level build changes required for Linux/s390x >> https://bugs.openjdk.java.net/browse/JDK-8166800 >> >> jdk repository: >> ============ >> >> This one just adds a new jvm.cfg file for s390x >> 8166801: [s390] Add jvm.cfg file for Linux/s390x >> https://bugs.openjdk.java.net/browse/JDK-8166801 >> >> >> And finally we plan to do one more change which fixes the jtreg test >> on Linux/s390x. But this is mainly for the correct detection of the >> platform and for excluding the tests which are not appropriate for >> s390x. >> >> Thank you and best regards, >> Volker >> > From volker.simonis at gmail.com Thu Sep 29 16:59:20 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 29 Sep 2016 18:59:20 +0200 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> Message-ID: On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson wrote: > > > On 2016-09-29 16:54, Alan Burlison wrote: >> >> On 29/09/2016 08:03, Volker Simonis wrote: >> >>> Sorry, but that doesn't sound like a solution to me at all. I think we >>> should keep the OpenJDK sources self-contained. I don't want to depend >>> on yet another non-standard, third party library which doesn't even >>> exist now. >> >> >> Unless I'm completely misunderstanding, that's not what is being proposed. >> What is being proposed is refactoring code that's currently duplicated >> across the JVM & JDK into a common library. Such a library would be a >> standard Java component, not non-standard and not third-party. I can't see >> what the problem is, to be honest. >> > Volker's comment above was directed at the suggestion of taking the > problematic AIX specific code out of the OpenJDK repositories and create a > separate library with a separate lifecycle somewhere else that OpenJDK for > AIX would then need to depend on. Volker was instead proposing what you > describe. > Thanks Erik, this is exactly what I meant :) And I think the solution you ssketched in your previous mail is the right way to address this problem. Regards, Volker > /Erik From Alan.Burlison at oracle.com Thu Sep 29 17:43:30 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 29 Sep 2016 18:43:30 +0100 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> Message-ID: <53928416-7072-eb17-4527-9b2252e3c080@oracle.com> On 29/09/2016 16:25, Erik Joelsson wrote: > Volker's comment above was directed at the suggestion of taking the > problematic AIX specific code out of the OpenJDK repositories and create > a separate library with a separate lifecycle somewhere else that OpenJDK > for AIX would then need to depend on. Volker was instead proposing what > you describe. Ah right, in which case we are in violent agreement ;-) -- Alan Burlison -- From kumar.x.srinivasan at oracle.com Thu Sep 29 17:48:59 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 29 Sep 2016 10:48:59 -0700 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <53928416-7072-eb17-4527-9b2252e3c080@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> <53928416-7072-eb17-4527-9b2252e3c080@oracle.com> Message-ID: <57ED540B.9010906@oracle.com> +1. Kumar > On 29/09/2016 16:25, Erik Joelsson wrote: > >> Volker's comment above was directed at the suggestion of taking the >> problematic AIX specific code out of the OpenJDK repositories and create >> a separate library with a separate lifecycle somewhere else that OpenJDK >> for AIX would then need to depend on. Volker was instead proposing what >> you describe. > > Ah right, in which case we are in violent agreement ;-) > From rafael.wth at gmail.com Thu Sep 29 17:50:18 2016 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Thu, 29 Sep 2016 19:50:18 +0200 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM Message-ID: Hello, I want to propose adding a method to the instrumentation API to receive an instance of the current VM's instrumentation API. Currently, many applications "self-attach" to gain such access. Unfortunately, this only works on JDK-VMs but I believe that this approach will grow in popularity with Java 9 where the Attach API is also part of any regular VM. Currently, such self-attachment is a rather flaky procedure: 1. Locate the "tools.jar" relatively to the Java Home. 2. Create a new URLClassLoader for this jar. 3. Locate the VirtualMachine type. 4. Parse the process Id from the JMX ManagementBean. 5. Load an agent that stores the instrumentation instance in a public field. 6. Locate this type from the class loader and read the field to receive the instance. I maintain a library offering an API for such self-attach and we can do some amazing things with it. For example, the Mockito library (ca. 400k downloads/month) now allows for mocking of final methods and types by inlining the mocking logic into a class what avoids class creation to create mocks by a subclass with virtual method overrides. Or cache libraries can call the objectSize method to limit memory usage by a given number in byte. Due to the need of publicly exposing the instrumentation API in a public field when using the above approach, this is however also a security risk and the procedure is also less stable as it should be as it needs I/O. In Java 9, this improves as there is an API for reading the current process id and for accessing the classes of tools.jar but the situation is still far from ideal. Within any library that uses for example EhCache, the instance can be stolen by any application on the class path by simple (public) reflection what then allows instrumenting the security manager to gain all privileges. Therefore I want to propose adding a static method to the Instrumentation interface: interface Instrumentation { static Instrumentation getInstance(boolean redefine, boolean retransform, boolean nativePrefix) { // security manager check return getInstance0(redefine, retransform, nativePrefix); } } This would increase security as the instance is only available aftrer a check and does not need to be exposed. Also, it would speed up the attachment process and avoid the I/O involved. Finally, it would make convenience APIs like the one I implemented unneccessary. What do you think of this? Thank you for considering my proposal. Best regards, Rafael From vladimir.kozlov at oracle.com Thu Sep 29 18:25:29 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Sep 2016 11:25:29 -0700 Subject: RFR: JEP draft for Linux/s3990x port In-Reply-To: References: <72ddbd25-c7df-b02a-3827-d431f286c795@oracle.com> Message-ID: <6261447a-fc39-4ea6-2ccf-3f0dcc396a36@oracle.com> You need to wait when Mark (OpenJDK Lead) move it to Candidate (or other) state: http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html Vladimir On 9/29/16 9:55 AM, Volker Simonis wrote: > Hi Vladimir, > > thanks a lot for reviewing and endorsing the JEP. > > I've linked all the relevant issues to the JEP (they all have a link > to a webrev) and change the state to "Submitted". > > There's just one more small shared change we need for the port for > which we haven't opened a bug now because we are still working on > simplifying it. The current version looks as follows: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/9000016-constant_table_offset.patch > > What are the next steps? Should I add a "jdk9-fc-request" label to t > he JEP and add a corresponding "FC Extension Request" comment to it? > Or will this be done automatically once I move it to "Candidate"? > > Is there anything left to do before I can move it to "Candidate" state? > > Thanks a lot and best regards, > Volker > > > > > On Tue, Sep 27, 2016 at 8:15 PM, Vladimir Kozlov > wrote: >> On 9/27/16 10:49 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> can you please review and endorse the following draft JEP for the >>> integration of the Linux/s390x port into the jkd9 master repository: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8166730 >> >> >> Good. >> Add links to webrevs in a comment. It will help to get umbrella FC extension >> approval. >> >>> >>> As detailed in the JEP, the Linux/s390x requires very few shared >>> changes and we therefore don't foresee any impact on the existing >>> platforms at all. Following you can find a short description of the >>> planned changes: >>> >>> hotspot: >>> ======= >>> >>> Out for review: >>> 8166560: [s390] Basic enablement of s390 port. >>> http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/ >>> >>> Reviewed: >>> 8166562: C2: Suppress relocations in scratch emit. >>> http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01/ >>> >>> Will send RFR soon (depends on 8166560): >>> 8166561: [s390] Adaptions needed for s390 port in C1 and C2. >>> http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01 >> >> >> Wrong link. >> >> Thanks, >> Vladimir >> >> >>> >>> We are still investigating the need of these shared changes: >>> >>> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000011-pass_PC_to_retAddrOffset.patch >>> >>> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000016-constant_table_offset.patch >>> >>> And finally the patch with the s390x-only platform files. We are still >>> editing these to get them into OpenJdk style and shape. >>> Hotspot passes most jck, jtreg and spec tests with these. >>> >>> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000101-zFiles.patch >>> >>> top-level repository: >>> =============== >>> >>> The following is just adding some s390x specific compiler flags to >>> flags.m4 >>> 8166800: [s390] Top-level build changes required for Linux/s390x >>> https://bugs.openjdk.java.net/browse/JDK-8166800 >>> >>> jdk repository: >>> ============ >>> >>> This one just adds a new jvm.cfg file for s390x >>> 8166801: [s390] Add jvm.cfg file for Linux/s390x >>> https://bugs.openjdk.java.net/browse/JDK-8166801 >>> >>> >>> And finally we plan to do one more change which fixes the jtreg test >>> on Linux/s390x. But this is mainly for the correct detection of the >>> platform and for excluding the tests which are not appropriate for >>> s390x. >>> >>> Thank you and best regards, >>> Volker >>> >> From shade at redhat.com Thu Sep 29 18:43:03 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 29 Sep 2016 20:43:03 +0200 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: Message-ID: <3ad03f40-47e6-1b74-eb24-214ae3975c54@redhat.com> On 09/29/2016 07:50 PM, Rafael Winterhalter wrote: > I want to propose adding a method to the instrumentation API to receive an > instance of the current VM's instrumentation API. Currently, many > applications "self-attach" to gain such access. Unfortunately, this only > works on JDK-VMs but I believe that this approach will grow in popularity > with Java 9 where the Attach API is also part of any regular VM. > interface Instrumentation { > static Instrumentation getInstance(boolean redefine, boolean retransform, > boolean nativePrefix) { > // security manager check > return getInstance0(redefine, retransform, nativePrefix); > } > } I would like to second this proposal. Our very own JOL [1] uses self-attach [2] to get Instrumentation instance for carefully polling Object instance sizes. Self-attach enables JOL usage as the library dependency without requiring command line tweaks. Thanks, -Aleksey [1] http://openjdk.java.net/projects/code-tools/jol/ [2] http://hg.openjdk.java.net/code-tools/jol/file/b5653b56d154/jol-core/src/main/java/org/openjdk/jol/vm/InstrumentationSupport.java From Alan.Bateman at oracle.com Thu Sep 29 19:06:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Sep 2016 20:06:12 +0100 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: Message-ID: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> On 29/09/2016 18:50, Rafael Winterhalter wrote: > : > > Therefore I want to propose adding a static method to the Instrumentation > interface: > > interface Instrumentation { > static Instrumentation getInstance(boolean redefine, boolean retransform, > boolean nativePrefix) { > // security manager check > return getInstance0(redefine, retransform, nativePrefix); > } > } > The original intention, back in JSR 163, was that java.lang.instrument be for instrumentation agents, not applications. This is why the API deliberately does not include a method to get the Instrumentation object along the lines you have propose. Sure, you can leak it from an agent started on the command line or attached at runtime but that is not the original intention. So I think introducing this method is a very significant change that would require a lot of consideration (previous requests to provide a way for applications to get the Instrumentation object without an agent in the picture were resisted). Separately, introducing this method creates a complication for runtimes that do not have JVM TI support (the JPLIS agent is based on JVM TI). As things stand then it's possible to create a runtime that does not have a means to start agents from the command-line (the spec allows this) and so there is no need to have the implementation support for this API. So if a method like this is every introduced then it would either have to be optional or it would require changes to the JVM TI spec to make it non-optional (or is based on an alternative JPLIS implementation that doesn't use JVM TI). -Alan From chris.hegarty at oracle.com Thu Sep 29 19:09:43 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Sep 2016 20:09:43 +0100 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: <3E39A1E9-0764-404D-9824-85CFB75113FF@oracle.com> References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> <02147682-541f-9746-b6da-2cc2800165b5@Oracle.com> <3E39A1E9-0764-404D-9824-85CFB75113FF@oracle.com> Message-ID: On 29 Sep 2016, at 16:25, Chris Hegarty wrote: > > I have asked Hamlin to hold off on this for a day or so. I have an > alternative proposal that eliminates the free port anti-pattern. It is possible to use the inheritedChannel mechanism to have the rmid process create the server channel on an ephemeral port and report it back to the test, i.e. remove the free port pattern. http://cr.openjdk.java.net/~chegar/8085192_webrev/ 1) The port number is reported from rmid to the test over stdout. 2) All tests pass except CheckAnnotations.java, which looks for stderr ( see 3 below ). I think the stderr check can be removed, and the just check stdout. 3) rmid, when using inheritChannel, redirects stderr to a tmp file, so it is not possible to get the processes stderr over the processes stderr pipe. I did?t find that this was an issue when testing ( other than having to clear out /tmp ) 4) This could be expanded to other tests, outside of activation, to remove more usages of free port. This is not yet complete, I just want to share the idea to see if it is a runner, or not. -Chris. From forax at univ-mlv.fr Thu Sep 29 19:22:10 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 29 Sep 2016 19:22:10 +0000 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> Message-ID: On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman wrote: >On 29/09/2016 18:50, Rafael Winterhalter wrote: > >> : >> >> Therefore I want to propose adding a static method to the >Instrumentation >> interface: >> >> interface Instrumentation { >> static Instrumentation getInstance(boolean redefine, boolean >retransform, >> boolean nativePrefix) { >> // security manager check >> return getInstance0(redefine, retransform, nativePrefix); >> } >> } >> I've a code that also does that for implementing a Repl like JShell. >The original intention, back in JSR 163, was that java.lang.instrument >be for instrumentation agents, not applications. This is why the API >deliberately does not include a method to get the Instrumentation >object >along the lines you have propose. Sure, you can leak it from an agent >started on the command line or attached at runtime but that is not the >original intention. So I think introducing this method is a very >significant change that would require a lot of consideration (previous >requests to provide a way for applications to get the Instrumentation >object without an agent in the picture were resisted). > >Separately, introducing this method creates a complication for runtimes > >that do not have JVM TI support (the JPLIS agent is based on JVM TI). >As >things stand then it's possible to create a runtime that does not have >a >means to start agents from the command-line (the spec allows this) and >so there is no need to have the implementation support for this API. So > >if a method like this is every introduced then it would either have to >be optional or it would require changes to the JVM TI spec to make it >non-optional (or is based on an alternative JPLIS implementation that >doesn't use JVM TI). Having it optional seams fine. Perhaps it has to be activated by a command line argument too. > >-Alan R?mi -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rafael.wth at gmail.com Thu Sep 29 19:37:00 2016 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Thu, 29 Sep 2016 21:37:00 +0200 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> Message-ID: It would be perfectly fine, in my opinion, to throw an unsupported operation exception, if the feature was unsupported. The method would primarily be used by testing code and tools. In Mockito, we simply do not offer inline mocks (but subclass mocks) if the runtime attachment fails. EhCache or JOL also fall back to not offering the related feature. Adding the method would simply add convenience and security to something that is already done by many libraries and tools out there. Also, all major VMs do support it as of today as far as I know. (The exception being J9 which currently has an unfortunate bug that triggers an internal assertion error upon retransformation.) Am 29.09.2016 9:22 nachm. schrieb "Remi Forax" : > > > On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman < > Alan.Bateman at oracle.com> wrote: > >On 29/09/2016 18:50, Rafael Winterhalter wrote: > > > >> : > >> > >> Therefore I want to propose adding a static method to the > >Instrumentation > >> interface: > >> > >> interface Instrumentation { > >> static Instrumentation getInstance(boolean redefine, boolean > >retransform, > >> boolean nativePrefix) { > >> // security manager check > >> return getInstance0(redefine, retransform, nativePrefix); > >> } > >> } > >> > > I've a code that also does that for implementing a Repl like JShell. > > >The original intention, back in JSR 163, was that java.lang.instrument > >be for instrumentation agents, not applications. This is why the API > >deliberately does not include a method to get the Instrumentation > >object > >along the lines you have propose. Sure, you can leak it from an agent > >started on the command line or attached at runtime but that is not the > >original intention. So I think introducing this method is a very > >significant change that would require a lot of consideration (previous > >requests to provide a way for applications to get the Instrumentation > >object without an agent in the picture were resisted). > > > >Separately, introducing this method creates a complication for runtimes > > > >that do not have JVM TI support (the JPLIS agent is based on JVM TI). > >As > >things stand then it's possible to create a runtime that does not have > >a > >means to start agents from the command-line (the spec allows this) and > >so there is no need to have the implementation support for this API. So > > > >if a method like this is every introduced then it would either have to > >be optional or it would require changes to the JVM TI spec to make it > >non-optional (or is based on an alternative JPLIS implementation that > >doesn't use JVM TI). > > Having it optional seams fine. > Perhaps it has to be activated by a command line argument too. > > > > >-Alan > > R?mi > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > From steve.drach at oracle.com Thu Sep 29 21:27:28 2016 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 29 Sep 2016 14:27:28 -0700 Subject: RFR: 8165944 jar utility doesn't process more than one -C argument In-Reply-To: <3EA9BD36-9BFB-4BBF-99F5-F0BB423F113F@oracle.com> References: <3EA9BD36-9BFB-4BBF-99F5-F0BB423F113F@oracle.com> Message-ID: We discovered that the last webrev subtly changed the behavior of jar tool with respect to the JDK 8 jar tool, so that was fixed, along with some more simplification, and additional test cases were added to demonstrate consistent behavior across releases. Here is the newest webrev. http://cr.openjdk.java.net/~sdrach/8165944/webrev.06/ > On Sep 27, 2016, at 12:31 PM, Steve Drach wrote: > > After a discussion with Paul Sandoz, I?ve simplified and, hopefully, thus clarified the changeset. The new webrev is > > http://cr.openjdk.java.net/~sdrach/8165944/webrev.01/ > >> On Sep 26, 2016, at 12:31 PM, Steve Drach > wrote: >> >> Hi, >> >> Please review these changes to the jar tool to fix a capability regression I introduced in an earlier revision. The issue is that this >> >> $ jar -cf test.jar -C test1 . -C test2 . >> >> only puts the files under test1 in the jar and ignores the files under test2. The DoubleCs test verified the problem and the solution. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8165944 > >> webrev: http://cr.openjdk.java.net/~sdrach/8165944/webrev.00/ > >> >> Thanks, >> Steve >> > From joe.darcy at oracle.com Thu Sep 29 23:13:06 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 29 Sep 2016 16:13:06 -0700 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> <02147682-541f-9746-b6da-2cc2800165b5@Oracle.com> <3E39A1E9-0764-404D-9824-85CFB75113FF@oracle.com> Message-ID: <57EDA002.8010705@oracle.com> Hello, Without commenting on the particulars, I'm happy to see work being done to address this issue in running the RMI tests. A fix here should greatly increase the reliability of the JDK test suite! Thanks, -Joe On 9/29/2016 12:09 PM, Chris Hegarty wrote: > On 29 Sep 2016, at 16:25, Chris Hegarty wrote: >> I have asked Hamlin to hold off on this for a day or so. I have an >> alternative proposal that eliminates the free port anti-pattern. > It is possible to use the inheritedChannel mechanism to have the rmid > process create the server channel on an ephemeral port and report it > back to the test, i.e. remove the free port pattern. > > http://cr.openjdk.java.net/~chegar/8085192_webrev/ > > 1) The port number is reported from rmid to the test over stdout. > > 2) All tests pass except CheckAnnotations.java, which looks for stderr > ( see 3 below ). I think the stderr check can be removed, and the > just check stdout. > > 3) rmid, when using inheritChannel, redirects stderr to a tmp file, so > it is not possible to get the processes stderr over the processes > stderr pipe. I did?t find that this was an issue when testing ( other > than having to clear out /tmp ) > > 4) This could be expanded to other tests, outside of activation, to > remove more usages of free port. > > This is not yet complete, I just want to share the idea to see if it is a > runner, or not. > > -Chris. > From joe.darcy at oracle.com Thu Sep 29 23:14:37 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 29 Sep 2016 16:14:37 -0700 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: <02147682-541f-9746-b6da-2cc2800165b5@Oracle.com> References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> <02147682-541f-9746-b6da-2cc2800165b5@Oracle.com> Message-ID: <57EDA05D.9020702@oracle.com> If Hamlin's approach is taken in the end, I think having a smaller retry count (5 or 10 rather than 20) would be more appropriate to avoid making the worst-case running time longer than necessary. Cheers, -Joe On 9/29/2016 6:55 AM, Roger Riggs wrote: > Hi Hamlin, > > One more suggested improvement. Instead of two copy/paste copies of > the launch with options code, > it would cleaner to create a separate RMID.launch(String[] options) > method that would be passed the extra arguments. > Use it in forceLogSnapshot.java and ShutdownGracefully.java. > > The (current) no-arg version could call the version with args with an > empty array(or null). > There would be only 1 copy of the launch algorithm. > > Roger > From stuart.marks at oracle.com Fri Sep 30 02:13:23 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 29 Sep 2016 19:13:23 -0700 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> <95429a179c85cae087303afb969b35bd@reini.net> <8c206fe5-6caa-bc5b-c073-dcc38fb3d0a0@oracle.com> Message-ID: Hi Jonathan, all, I've started to look at this changeset. I'm looking at the one Patrick Reinhart posted a couple weeks ago (! sorry): http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01/ I looked at only a few files and I'm already starting to have questions. Not because anybody did anything wrong, but because there are some subtle issues that hadn't been raised. 1) ModuleFinder.java static ModuleFinder compose(ModuleFinder... finders) { - final List finderList = Arrays.asList(finders); - finderList.forEach(Objects::requireNonNull); + final List finderList = List.of(finders); return new ModuleFinder() { ... It's important to note that Arrays.asList() wraps a list around an array, whereas List.of() has copying semantics. Initially I thought that copying here is unnecessary, but after further analysis I've come to believe it's necessary. The compose() method is public in the ModuleFinder interface, and the list is captured by the ModuleFinder anonymous inner class below, which is returned to the caller. Therefore, if Arrays.asList() is used, the caller can mutate the array argument and cause the ModuleFinder instance to misbehave. This is a TOCTOU problem. Oddly, TOCTOU wasn't discussed with respect to this change, though it was with another. In any case switching to the copying semantics of List.of() in this case is correct and prevents TOCTOU problems. 2) CookieManager.java The old code created a HashMap and wrapped it in a Collections.unmodifiableMap() and returned it to the caller. The new code returns some instance created by Map.of(). This is a public API. While both versions conform to the specification (it says an "immutable" Map is returned) certain behavioral differences are visible. In particular, the different objects will serialize differently. It's a Map>, and it looks like the values are instances of ArrayList, so the whole thing will be serializable. It's conceivable that applications might take this thing and serialize it. This potentially exposes applications to serial interoperability problems if they wanted to exchange serial data containing this object between Java 8 and 9. My hunch is that this problem is fairly unlikely to occur, but I think it would be good idea to do some searching to see how often this API is used. If it's used rarely, or the typical usages don't involve storing the result somewhere (e.g., iterating over the values), then we can proceed. I use grepcode.com for code searches. I'd be interested in hearing about alternative code search engines as well. 3) FileTreeIterator.java Here's the one where a comment was added describing the copying semantics of List.of in order to prevent TOCTOU problems. The options array is passed from the outside and thus can be mutated by the caller. But the only time it's used is within FileTreeWalker, and there it's iterated over once and never used again. This differs from case (1) above where (in the old code) the array reference is captured by a long-lived object. Anyway, in this case, I don't think the copying is necessary, so the old Arrays.asList() code is probably fine. 4) Not a specific change, but I saw mention upthread of some change that caused one of the java.time tests to fail, something about 'resolverFields' containing null. Which change was this, and what's its status in the current webrev? I note that Stephen Colebourne said that the changes seem "reasonable" but I don't know if he saw the mention of the java.time test failure, or whether the changeset he reviewed included a change that would have caused it. * * * I still need to look at the other changes. If we end up getting hung up on one or two, it might make sense to break up the changeset and push part of it. It might also make sense to split out the java.time changes, since they're a logical chunk, and they potentially have different reviewers. But no need to do anything on that just yet. s'marks On 9/15/16 12:36 PM, Jonathan Bluett-Duncan wrote: > Hi all, > > Stuart, thank you very much for your thorough response. > > Regarding serializability concerns, I've just checked my changes and all > non-test code in the JDK which calls it, and it doesn't seem to me that they > affect any fields in `Serializable` classes or the return values of methods > which either return instances of `Serializable` classes or whose javadoc > mention that the returned object is serializable. So I'm somewhat certain that > my changes are serialization-compatible, but only somewhat, because I'm not > that familiar with the intricacies of serialization... > > Considering how busy Stuart is, would anyone else be happy to sponsor this change? > > Kind regards, > Jonathan > > On 15 September 2016 at 18:20, Stuart Marks > wrote: > > Hi all, > > Unfortunately I don't have time to work on any of this at the moment, > because of JavaOne preparation, and JavaOne next week. > > Jonathan, thanks for pushing forward with this. I'm glad that others have > picked it up. > > Patrick, thanks for posting the changeset on Jonathan's behalf. This is > very helpful. > > A few comments regarding issues raised up-thread. > > Regarding the (non)singleton-ness of the empty collections, this is covered by > > https://bugs.openjdk.java.net/browse/JDK-8156079 > > consider making empty instances singletons > > It wasn't a design decision to make them not singletons. The spec > requirement is only that the returned instance satisfy the requirements of > the interfaces it implements (e.g., List) and nothing more. Certainly > there is no spec requirement regarding object identity. > > Making the empty collections singletons is the "obvious" thing to do, but > it's often the case that the "obvious" thing isn't the right thing. That > said, it may still be the right thing to make them singletons. Given the > proposed extension to the JDK 9 schedule, it might be possible to change > this in JDK 9. > > Note that List.of() should be functionally equivalent to > Collections.emptyList() -- and correspondingly for Set and Map -- but they > do differ. In particular, they have different serialization formats. > > Also on this topic, please note comments that Daniel Fuchs and I have added to > > https://bugs.openjdk.java.net/browse/JDK-8134373 > > > regarding serialization compatibility. Reviewers should take care that > updating code to use these new collection factories doesn't change any > serialization formats. Unfortunately I am not confident that we have > sufficient tests for serialization compatibility. > > s'marks > > > > On 9/15/16 7:02 AM, Jonathan Bluett-Duncan wrote: > > Wow, lots of discussion went on since I was busy doing other stuff! > > Thanks Patrick for doing the work of creating a new webrev for me. Really > appreciated! > > Pavel already mentioned it, but I think List.of instead of > Collections.emptyList in ZoneOffsetTransition is the right thing to do for > visual and behavioural consistency. If it turns out that we need to revert > to Collections.empty* and Collections.unmodifiable* for e.g. > serializability or class loading concerns, then I'd be happy to revert > both > of the lines I touched. Otherwise I believe that List.of should be used > consistently. > > I think Stuart made List.of() non-singleton because there wasn't any > evidence that it made List.of() more memory- or time-intensive than > Collections.emptyList(), but I might be wrong on this. I'm sure he can > explain more or correct me in this case. > > Kind regards, > Jonathan > > > On 15 September 2016 at 13:33, Patrick Reinhart > wrote: > > Hello together, > > I tried to process all suggested change input into the following new > webrev: > > http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01 > > > Give me feedback if something is missing/wrong > > -Patrick > > > On 2016-09-15 13:48, Pavel Rappo wrote: > > Daniel, Claes, > > List.of() and Collections.emptyList() are not the same. The > behaviours are > different. Moreover, immutable static factory methods return > instances > which are > value-based. I believe it also means we are not tied with > unconditional > instantiation, and in case of empty collections/maps could > probably > return the > same object every time. > > We should ask Stuart why it has been done like that in the > first place. > Maybe > out of concern people might synchronize of those objects? I > don't know. > Let's > say for now it's an implementation-specific detail. > > On 15 Sep 2016, at 12:35, Claes Redestad > > > > wrote: > > +1 > > I don't mind List.of() aesthetically, but there are places > where > startup/footprint is important where Collections.emptyList() > is simply superior, e.g., constituting permanent data > structures > such as the module graph during early bootstrap. > > > From huaming.li at oracle.com Fri Sep 30 03:56:15 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 30 Sep 2016 11:56:15 +0800 Subject: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use" In-Reply-To: <57EDA05D.9020702@oracle.com> References: <3c0bdf63-f55c-5b93-6d74-58e26916cb3b@oracle.com> <02147682-541f-9746-b6da-2cc2800165b5@Oracle.com> <57EDA05D.9020702@oracle.com> Message-ID: Hi Joe, Roger, Modified based on your latest comments, please check the new webrev: http://cr.openjdk.java.net/~mli/8085192/webrev.02/ At the same time, I think Chris's idea is great. Thank you -Hamlin On 2016/9/30 7:14, Joseph D. Darcy wrote: > If Hamlin's approach is taken in the end, I think having a smaller > retry count (5 or 10 rather than 20) would be more appropriate to > avoid making the worst-case running time longer than necessary. > > Cheers, > > -Joe > > On 9/29/2016 6:55 AM, Roger Riggs wrote: >> Hi Hamlin, >> >> One more suggested improvement. Instead of two copy/paste copies of >> the launch with options code, >> it would cleaner to create a separate RMID.launch(String[] options) >> method that would be passed the extra arguments. >> Use it in forceLogSnapshot.java and ShutdownGracefully.java. >> >> The (current) no-arg version could call the version with args with an >> empty array(or null). >> There would be only 1 copy of the launch algorithm. >> >> Roger >> > From matcdac at gmail.com Fri Sep 30 04:24:16 2016 From: matcdac at gmail.com (Prakhar Makhija) Date: Fri, 30 Sep 2016 09:54:16 +0530 Subject: ParallelStream Vs Stream Digest, Vol 113, Issue 94 Message-ID: Hi everyone, I have started using both Stream and ParallelStream, for Set List and Entry of Map. What I can't understand is why Stream is taking lesser time than ParallelStream. Shouldnt ParallelStream be giving better performance than Stream in terms of Time Complexity? On Sep 30, 2016 12:53 AM, wrote: > Send core-libs-dev mailing list submissions to > core-libs-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > or, via email, send a message with subject or body 'help' to > core-libs-dev-request at openjdk.java.net > > You can reach the person managing the list at > core-libs-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core-libs-dev digest..." > > > Today's Topics: > > 1. Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > (Kumar Srinivasan) > 2. Proposal to introduce method "Instrumentation.getInstance()" > to instrument the current VM (Rafael Winterhalter) > 3. Re: RFR: JEP draft for Linux/s3990x port (Vladimir Kozlov) > 4. Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > (Aleksey Shipilev) > 5. Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > (Alan Bateman) > 6. Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable > tests fail intermittently due to "Port already in use" (Chris > Hegarty) > 7. Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > (Remi Forax) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 29 Sep 2016 10:48:59 -0700 > From: Kumar Srinivasan > To: Alan Burlison , Volker Simonis > > Cc: "Lindenmaier, Goetz" , build-dev > , "ppc-aix-port-dev at openjdk.java.net > " > , Chris Bensen > , core-libs-dev > > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build > Message-ID: <57ED540B.9010906 at oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > +1. > > Kumar > > > On 29/09/2016 16:25, Erik Joelsson wrote: > > > >> Volker's comment above was directed at the suggestion of taking the > >> problematic AIX specific code out of the OpenJDK repositories and create > >> a separate library with a separate lifecycle somewhere else that OpenJDK > >> for AIX would then need to depend on. Volker was instead proposing what > >> you describe. > > > > Ah right, in which case we are in violent agreement ;-) > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 29 Sep 2016 19:50:18 +0200 > From: Rafael Winterhalter > To: core-libs-dev at openjdk.java.net > Subject: Proposal to introduce method "Instrumentation.getInstance()" > to instrument the current VM > Message-ID: > com> > Content-Type: text/plain; charset=UTF-8 > > Hello, > > I want to propose adding a method to the instrumentation API to receive an > instance of the current VM's instrumentation API. Currently, many > applications "self-attach" to gain such access. Unfortunately, this only > works on JDK-VMs but I believe that this approach will grow in popularity > with Java 9 where the Attach API is also part of any regular VM. > > Currently, such self-attachment is a rather flaky procedure: > > 1. Locate the "tools.jar" relatively to the Java Home. > 2. Create a new URLClassLoader for this jar. > 3. Locate the VirtualMachine type. > 4. Parse the process Id from the JMX ManagementBean. > 5. Load an agent that stores the instrumentation instance in a public > field. > 6. Locate this type from the class loader and read the field to receive the > instance. > > I maintain a library offering an API for such self-attach and we can do > some amazing things with it. For example, the Mockito library (ca. 400k > downloads/month) now allows for mocking of final methods and types by > inlining the mocking logic into a class what avoids class creation to > create mocks by a subclass with virtual method overrides. Or cache > libraries can call the objectSize method to limit memory usage by a given > number in byte. > > Due to the need of publicly exposing the instrumentation API in a public > field when using the above approach, this is however also a security risk > and the procedure is also less stable as it should be as it needs I/O. In > Java 9, this improves as there is an API for reading the current process id > and for accessing the classes of tools.jar but the situation is still far > from ideal. Within any library that uses for example EhCache, the instance > can be stolen by any application on the class path by simple (public) > reflection what then allows instrumenting the security manager to gain all > privileges. > > Therefore I want to propose adding a static method to the Instrumentation > interface: > > interface Instrumentation { > static Instrumentation getInstance(boolean redefine, boolean retransform, > boolean nativePrefix) { > // security manager check > return getInstance0(redefine, retransform, nativePrefix); > } > } > > This would increase security as the instance is only available aftrer a > check and does not need to be exposed. Also, it would speed up the > attachment process and avoid the I/O involved. Finally, it would make > convenience APIs like the one I implemented unneccessary. > > What do you think of this? > > Thank you for considering my proposal. > Best regards, Rafael > > > ------------------------------ > > Message: 3 > Date: Thu, 29 Sep 2016 11:25:29 -0700 > From: Vladimir Kozlov > To: Volker Simonis > Cc: s390x-port-dev at openjdk.java.net, porters-dev at openjdk.java.net, > build-dev , HotSpot Open Source > Developers > , Java Core Libs > > Subject: Re: RFR: JEP draft for Linux/s3990x port > Message-ID: <6261447a-fc39-4ea6-2ccf-3f0dcc396a36 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > You need to wait when Mark (OpenJDK Lead) move it to Candidate (or > other) state: > > http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > > Vladimir > > On 9/29/16 9:55 AM, Volker Simonis wrote: > > Hi Vladimir, > > > > thanks a lot for reviewing and endorsing the JEP. > > > > I've linked all the relevant issues to the JEP (they all have a link > > to a webrev) and change the state to "Submitted". > > > > There's just one more small shared change we need for the port for > > which we haven't opened a bug now because we are still working on > > simplifying it. The current version looks as follows: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/ > 9000016-constant_table_offset.patch > > > > What are the next steps? Should I add a "jdk9-fc-request" label to t > > he JEP and add a corresponding "FC Extension Request" comment to it? > > Or will this be done automatically once I move it to "Candidate"? > > > > Is there anything left to do before I can move it to "Candidate" state? > > > > Thanks a lot and best regards, > > Volker > > > > > > > > > > On Tue, Sep 27, 2016 at 8:15 PM, Vladimir Kozlov > > wrote: > >> On 9/27/16 10:49 AM, Volker Simonis wrote: > >>> > >>> Hi, > >>> > >>> can you please review and endorse the following draft JEP for the > >>> integration of the Linux/s390x port into the jkd9 master repository: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8166730 > >> > >> > >> Good. > >> Add links to webrevs in a comment. It will help to get umbrella FC > extension > >> approval. > >> > >>> > >>> As detailed in the JEP, the Linux/s390x requires very few shared > >>> changes and we therefore don't foresee any impact on the existing > >>> platforms at all. Following you can find a short description of the > >>> planned changes: > >>> > >>> hotspot: > >>> ======= > >>> > >>> Out for review: > >>> 8166560: [s390] Basic enablement of s390 port. > >>> http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/ > hotspot.wr01/ > >>> > >>> Reviewed: > >>> 8166562: C2: Suppress relocations in scratch emit. > >>> http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01/ > >>> > >>> Will send RFR soon (depends on 8166560): > >>> 8166561: [s390] Adaptions needed for s390 port in C1 and C2. > >>> http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01 > >> > >> > >> Wrong link. > >> > >> Thanks, > >> Vladimir > >> > >> > >>> > >>> We are still investigating the need of these shared changes: > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/ > hotspot/9000011-pass_PC_to_retAddrOffset.patch > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/ > hotspot/9000016-constant_table_offset.patch > >>> > >>> And finally the patch with the s390x-only platform files. We are still > >>> editing these to get them into OpenJdk style and shape. > >>> Hotspot passes most jck, jtreg and spec tests with these. > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/ > hotspot/9000101-zFiles.patch > >>> > >>> top-level repository: > >>> =============== > >>> > >>> The following is just adding some s390x specific compiler flags to > >>> flags.m4 > >>> 8166800: [s390] Top-level build changes required for Linux/s390x > >>> https://bugs.openjdk.java.net/browse/JDK-8166800 > >>> > >>> jdk repository: > >>> ============ > >>> > >>> This one just adds a new jvm.cfg file for s390x > >>> 8166801: [s390] Add jvm.cfg file for Linux/s390x > >>> https://bugs.openjdk.java.net/browse/JDK-8166801 > >>> > >>> > >>> And finally we plan to do one more change which fixes the jtreg test > >>> on Linux/s390x. But this is mainly for the correct detection of the > >>> platform and for excluding the tests which are not appropriate for > >>> s390x. > >>> > >>> Thank you and best regards, > >>> Volker > >>> > >> > > > ------------------------------ > > Message: 4 > Date: Thu, 29 Sep 2016 20:43:03 +0200 > From: Aleksey Shipilev > To: Rafael Winterhalter , > core-libs-dev at openjdk.java.net > Subject: Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > Message-ID: <3ad03f40-47e6-1b74-eb24-214ae3975c54 at redhat.com> > Content-Type: text/plain; charset=utf-8 > > On 09/29/2016 07:50 PM, Rafael Winterhalter wrote: > > I want to propose adding a method to the instrumentation API to receive > an > > instance of the current VM's instrumentation API. Currently, many > > applications "self-attach" to gain such access. Unfortunately, this only > > works on JDK-VMs but I believe that this approach will grow in popularity > > with Java 9 where the Attach API is also part of any regular VM. > > > interface Instrumentation { > > static Instrumentation getInstance(boolean redefine, boolean > retransform, > > boolean nativePrefix) { > > // security manager check > > return getInstance0(redefine, retransform, nativePrefix); > > } > > } > > I would like to second this proposal. > > Our very own JOL [1] uses self-attach [2] to get Instrumentation > instance for carefully polling Object instance sizes. Self-attach > enables JOL usage as the library dependency without requiring command > line tweaks. > > Thanks, > -Aleksey > > [1] http://openjdk.java.net/projects/code-tools/jol/ > [2] > http://hg.openjdk.java.net/code-tools/jol/file/b5653b56d154/jol-core/src/ > main/java/org/openjdk/jol/vm/InstrumentationSupport.java > > > > ------------------------------ > > Message: 5 > Date: Thu, 29 Sep 2016 20:06:12 +0100 > From: Alan Bateman > To: Rafael Winterhalter , > core-libs-dev at openjdk.java.net > Subject: Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > Message-ID: <8235b50a-7f93-a60a-10b1-c661d9638bc9 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 29/09/2016 18:50, Rafael Winterhalter wrote: > > > : > > > > Therefore I want to propose adding a static method to the Instrumentation > > interface: > > > > interface Instrumentation { > > static Instrumentation getInstance(boolean redefine, boolean > retransform, > > boolean nativePrefix) { > > // security manager check > > return getInstance0(redefine, retransform, nativePrefix); > > } > > } > > > The original intention, back in JSR 163, was that java.lang.instrument > be for instrumentation agents, not applications. This is why the API > deliberately does not include a method to get the Instrumentation object > along the lines you have propose. Sure, you can leak it from an agent > started on the command line or attached at runtime but that is not the > original intention. So I think introducing this method is a very > significant change that would require a lot of consideration (previous > requests to provide a way for applications to get the Instrumentation > object without an agent in the picture were resisted). > > Separately, introducing this method creates a complication for runtimes > that do not have JVM TI support (the JPLIS agent is based on JVM TI). As > things stand then it's possible to create a runtime that does not have a > means to start agents from the command-line (the spec allows this) and > so there is no need to have the implementation support for this API. So > if a method like this is every introduced then it would either have to > be optional or it would require changes to the JVM TI spec to make it > non-optional (or is based on an alternative JPLIS implementation that > doesn't use JVM TI). > > -Alan > > > ------------------------------ > > Message: 6 > Date: Thu, 29 Sep 2016 20:09:43 +0100 > From: Chris Hegarty > To: Hamlin Li , core-libs-dev > > Subject: Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable > tests fail intermittently due to "Port already in use" > Message-ID: > Content-Type: text/plain; charset=utf-8 > > On 29 Sep 2016, at 16:25, Chris Hegarty wrote: > > > > I have asked Hamlin to hold off on this for a day or so. I have an > > alternative proposal that eliminates the free port anti-pattern. > > It is possible to use the inheritedChannel mechanism to have the rmid > process create the server channel on an ephemeral port and report it > back to the test, i.e. remove the free port pattern. > > http://cr.openjdk.java.net/~chegar/8085192_webrev/ > > 1) The port number is reported from rmid to the test over stdout. > > 2) All tests pass except CheckAnnotations.java, which looks for stderr > ( see 3 below ). I think the stderr check can be removed, and the > just check stdout. > > 3) rmid, when using inheritChannel, redirects stderr to a tmp file, so > it is not possible to get the processes stderr over the processes > stderr pipe. I did?t find that this was an issue when testing ( other > than having to clear out /tmp ) > > 4) This could be expanded to other tests, outside of activation, to > remove more usages of free port. > > This is not yet complete, I just want to share the idea to see if it is a > runner, or not. > > -Chris. > > > > ------------------------------ > > Message: 7 > Date: Thu, 29 Sep 2016 19:22:10 +0000 > From: Remi Forax > To: Alan Bateman , Rafael Winterhalter > , core-libs-dev at openjdk.java.net > Subject: Re: Proposal to introduce method > "Instrumentation.getInstance()" to instrument the current VM > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > > > On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman < > Alan.Bateman at oracle.com> wrote: > >On 29/09/2016 18:50, Rafael Winterhalter wrote: > > > >> : > >> > >> Therefore I want to propose adding a static method to the > >Instrumentation > >> interface: > >> > >> interface Instrumentation { > >> static Instrumentation getInstance(boolean redefine, boolean > >retransform, > >> boolean nativePrefix) { > >> // security manager check > >> return getInstance0(redefine, retransform, nativePrefix); > >> } > >> } > >> > > I've a code that also does that for implementing a Repl like JShell. > > >The original intention, back in JSR 163, was that java.lang.instrument > >be for instrumentation agents, not applications. This is why the API > >deliberately does not include a method to get the Instrumentation > >object > >along the lines you have propose. Sure, you can leak it from an agent > >started on the command line or attached at runtime but that is not the > >original intention. So I think introducing this method is a very > >significant change that would require a lot of consideration (previous > >requests to provide a way for applications to get the Instrumentation > >object without an agent in the picture were resisted). > > > >Separately, introducing this method creates a complication for runtimes > > > >that do not have JVM TI support (the JPLIS agent is based on JVM TI). > >As > >things stand then it's possible to create a runtime that does not have > >a > >means to start agents from the command-line (the spec allows this) and > >so there is no need to have the implementation support for this API. So > > > >if a method like this is every introduced then it would either have to > >be optional or it would require changes to the JVM TI spec to make it > >non-optional (or is based on an alternative JPLIS implementation that > >doesn't use JVM TI). > > Having it optional seams fine. > Perhaps it has to be activated by a command line argument too. > > > > >-Alan > > R?mi > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > End of core-libs-dev Digest, Vol 113, Issue 94 > ********************************************** > From david.holmes at oracle.com Fri Sep 30 04:37:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Sep 2016 14:37:55 +1000 Subject: ParallelStream Vs Stream Digest, Vol 113, Issue 94 In-Reply-To: References: Message-ID: <93fb0f8d-54a9-a2ba-5799-32c2cd7edf2e@oracle.com> On 30/09/2016 2:24 PM, Prakhar Makhija wrote: > Hi everyone, > > I have started using both Stream and ParallelStream, for Set List and Entry > of Map. > > What I can't understand is why Stream is taking lesser time than > ParallelStream. > > Shouldnt ParallelStream be giving better performance than Stream in terms > of Time Complexity? Depends on the data set size and your hardware, and what exactly you are trying to do in parallel. David From matcdac at gmail.com Fri Sep 30 05:07:36 2016 From: matcdac at gmail.com (Prakhar Makhija) Date: Fri, 30 Sep 2016 10:37:36 +0530 Subject: ParallelStream Vs Stream Digest, Vol 113, Issue 94 In-Reply-To: <93fb0f8d-54a9-a2ba-5799-32c2cd7edf2e@oracle.com> References: <93fb0f8d-54a9-a2ba-5799-32c2cd7edf2e@oracle.com> Message-ID: The application makes a hit to a core object over and over again. I have to copy this object, i.e. make a clone of it using the Cloneable interface, so that the original object cannot be modified. But since the references of the old object and clone object would be intact, inside the clone method I am explicitly copying the List Map and Set using parrallelStream/stream. The hardware is i3 processor with 8GB RAM and 1TB hard disk. So you mean to say, Parallel Stream is good for large data set? On Sep 30, 2016 10:08 AM, "David Holmes" wrote: > On 30/09/2016 2:24 PM, Prakhar Makhija wrote: > >> Hi everyone, >> >> I have started using both Stream and ParallelStream, for Set List and >> Entry >> of Map. >> >> What I can't understand is why Stream is taking lesser time than >> ParallelStream. >> >> Shouldnt ParallelStream be giving better performance than Stream in terms >> of Time Complexity? >> > > Depends on the data set size and your hardware, and what exactly you are > trying to do in parallel. > > David > From david.holmes at oracle.com Fri Sep 30 05:57:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Sep 2016 15:57:05 +1000 Subject: ParallelStream Vs Stream Digest, Vol 113, Issue 94 In-Reply-To: References: <93fb0f8d-54a9-a2ba-5799-32c2cd7edf2e@oracle.com> Message-ID: On 30/09/2016 3:07 PM, Prakhar Makhija wrote: > The application makes a hit to a core object over and over again. I have > to copy this object, i.e. make a clone of it using the Cloneable > interface, so that the original object cannot be modified. But since the > references of the old object and clone object would be intact, inside > the clone method I am explicitly copying the List Map and Set using > parrallelStream/stream. > > The hardware is i3 processor with 8GB RAM and 1TB hard disk. You only have two cores on an i3, with hyper-threading so you have very limited speedup potential to begin with > So you mean to say, Parallel Stream is good for large data set? What I mean is that if the data set is too small then the overhead of parallelizing the work will outweigh the work itself. David ----- > On Sep 30, 2016 10:08 AM, "David Holmes" > wrote: > > On 30/09/2016 2:24 PM, Prakhar Makhija wrote: > > Hi everyone, > > I have started using both Stream and ParallelStream, for Set > List and Entry > of Map. > > What I can't understand is why Stream is taking lesser time than > ParallelStream. > > Shouldnt ParallelStream be giving better performance than Stream > in terms > of Time Complexity? > > > Depends on the data set size and your hardware, and what exactly you > are trying to do in parallel. > > David > From wasserman.louis at gmail.com Fri Sep 30 06:39:53 2016 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Fri, 30 Sep 2016 06:39:53 +0000 Subject: ParallelStream Vs Stream Digest, Vol 113, Issue 94 In-Reply-To: References: <93fb0f8d-54a9-a2ba-5799-32c2cd7edf2e@oracle.com> Message-ID: You should absolutely not assume parallel streams are faster than sequential streams. http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html is pretty much the iconic document on that subject, and explains circumstances under which parallelism is good, and when it is likely to be harmful. On Thu, Sep 29, 2016 at 10:07 PM Prakhar Makhija wrote: > The application makes a hit to a core object over and over again. I have to > copy this object, i.e. make a clone of it using the Cloneable interface, so > that the original object cannot be modified. But since the references of > the old object and clone object would be intact, inside the clone method I > am explicitly copying the List Map and Set using parrallelStream/stream. > > The hardware is i3 processor with 8GB RAM and 1TB hard disk. > > So you mean to say, Parallel Stream is good for large data set? > On Sep 30, 2016 10:08 AM, "David Holmes" wrote: > > > On 30/09/2016 2:24 PM, Prakhar Makhija wrote: > > > >> Hi everyone, > >> > >> I have started using both Stream and ParallelStream, for Set List and > >> Entry > >> of Map. > >> > >> What I can't understand is why Stream is taking lesser time than > >> ParallelStream. > >> > >> Shouldnt ParallelStream be giving better performance than Stream in > terms > >> of Time Complexity? > >> > > > > Depends on the data set size and your hardware, and what exactly you are > > trying to do in parallel. > > > > David > > > From Alan.Bateman at oracle.com Fri Sep 30 08:31:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Sep 2016 09:31:56 +0100 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> Message-ID: On 29/09/2016 20:37, Rafael Winterhalter wrote: > It would be perfectly fine, in my opinion, to throw an unsupported > operation exception, if the feature was unsupported. The method would > primarily be used by testing code and tools. > Right, but it essentially means that anything that use Instrumentation.getInstance(...) can dynamically extend the class path, add to the boot class loader search, redefine any class or module, ... Assume the common case where there is no security manager and not using JDK-specific APIs. So I think this requires a lot of consideration before going any further - the original intention with this API is that it was for tool agents and this is why a method like the proposal method has been kept out of the API. -Alan From rafael.wth at gmail.com Fri Sep 30 08:39:46 2016 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 30 Sep 2016 10:39:46 +0200 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> Message-ID: I agree that this should be considered carefully. However, without a security manager, it is already possible to get such an instance for most environments. And starting with Java 9, this will extend to non JDK-VMs as the former tools.jar is now a module. I think by adding such a method, security would improve as current solutions often use their privileged access to read such an instance but often leave this instance exposed in a public field reachable via the system class loader. I think by including such a method, one could avoid the spreading of custom libraries (like mine) that do self-attachment and properly secure the access via a security manager. Thank you for considering this! Best regards, Rafael 2016-09-30 10:31 GMT+02:00 Alan Bateman : > On 29/09/2016 20:37, Rafael Winterhalter wrote: > > It would be perfectly fine, in my opinion, to throw an unsupported >> operation exception, if the feature was unsupported. The method would >> primarily be used by testing code and tools. >> >> Right, but it essentially means that anything that use > Instrumentation.getInstance(...) can dynamically extend the class path, > add to the boot class loader search, redefine any class or module, ... > Assume the common case where there is no security manager and not using > JDK-specific APIs. So I think this requires a lot of consideration before > going any further - the original intention with this API is that it was for > tool agents and this is why a method like the proposal method has been kept > out of the API. > > -Alan > From Alan.Bateman at oracle.com Fri Sep 30 09:37:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Sep 2016 10:37:05 +0100 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> Message-ID: <66ea493e-b26d-d2f4-f8cd-ebedf63a9724@oracle.com> On 30/09/2016 09:39, Rafael Winterhalter wrote: > I agree that this should be considered carefully. > > However, without a security manager, it is already possible to get > such an instance for most environments. And starting with Java 9, this > will extend to non JDK-VMs as the former tools.jar is now a module. Assuming you mean the jdk.attach module then it's JDK-specific. It's not linked into the runtime image that is the JRE for example. In any case, this proposal is a significant concern as it is exposing capabilities in the standard API that were intended for tool agents. The implications are huge. -Alan From adinn at redhat.com Fri Sep 30 11:51:59 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 30 Sep 2016 12:51:59 +0100 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: <66ea493e-b26d-d2f4-f8cd-ebedf63a9724@oracle.com> References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> <66ea493e-b26d-d2f4-f8cd-ebedf63a9724@oracle.com> Message-ID: On 30/09/16 10:37, Alan Bateman wrote: > On 30/09/2016 09:39, Rafael Winterhalter wrote: > >> I agree that this should be considered carefully. >> >> However, without a security manager, it is already possible to get >> such an instance for most environments. And starting with Java 9, this >> will extend to non JDK-VMs as the former tools.jar is now a module. > Assuming you mean the jdk.attach module then it's JDK-specific. It's not > linked into the runtime image that is the JRE for example. > > In any case, this proposal is a significant concern as it is exposing > capabilities in the standard API that were intended for tool agents. The > implications are huge. I agree with all Alan's concerns here. Also, although many developers have used the attach API to self-hoist an agent into a JVM (Byteman also does this when used with JUnit/TestNG) and have, perhaps, re-implemented the same wheel to do so I don't think fixing that circumstance really merits a JVM change. A couple of small library jars could address this problem, shrink-wrapping the necessary functionality into a common API. The first jar could provide a class with a getInstrumentation() method which drives the attach API, loading the 2nd agent jar (which it can locate from the classpath). The agent jar can securely hand over the Instrumentation instance to the API class provided in the first jar allowing it to be returned to the caller. If these 2 jars were posted for common use (e.g. to Maven Central) then the functionality can be made available simply by adding the required jars to the classpath and calling the getInstrumentation() method. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From rafael.wth at gmail.com Fri Sep 30 12:15:24 2016 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 30 Sep 2016 14:15:24 +0200 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> <66ea493e-b26d-d2f4-f8cd-ebedf63a9724@oracle.com> Message-ID: Such a library exists already: http://mvnrepository.com/search?q=byte-buddy-agent I do however not share your point of view on this: if there is a valid use case for self-attachment - Aleksey, you and I already named several such use cases - why not add convenience, security and performance to the API? Right now, a library can already self-attach when there is no security manager but will always expose the Instrumentation instance accessibly on the system class loader. It is my opinion that adding such an API would only improve the situation compared to today. In this light, calling ByteBuddyAgent.install() is a less secure way of calling the proposed Instrumentation.getInstance(). I understand that this needs to be assesed thoroughly but I still hope this proposal is not dismissed prematurely. Best regards, Rafael Best regards, Rafael 2016-09-30 13:51 GMT+02:00 Andrew Dinn : > On 30/09/16 10:37, Alan Bateman wrote: > > On 30/09/2016 09:39, Rafael Winterhalter wrote: > > > >> I agree that this should be considered carefully. > >> > >> However, without a security manager, it is already possible to get > >> such an instance for most environments. And starting with Java 9, this > >> will extend to non JDK-VMs as the former tools.jar is now a module. > > Assuming you mean the jdk.attach module then it's JDK-specific. It's not > > linked into the runtime image that is the JRE for example. > > > > In any case, this proposal is a significant concern as it is exposing > > capabilities in the standard API that were intended for tool agents. The > > implications are huge. > > I agree with all Alan's concerns here. > > Also, although many developers have used the attach API to self-hoist > an agent into a JVM (Byteman also does this when used with JUnit/TestNG) > and have, perhaps, re-implemented the same wheel to do so I don't think > fixing that circumstance really merits a JVM change. A couple of small > library jars could address this problem, shrink-wrapping the necessary > functionality into a common API. > > The first jar could provide a class with a getInstrumentation() method > which drives the attach API, loading the 2nd agent jar (which it can > locate from the classpath). > > The agent jar can securely hand over the Instrumentation instance to the > API class provided in the first jar allowing it to be returned to the > caller. > > If these 2 jars were posted for common use (e.g. to Maven Central) then > the functionality can be made available simply by adding the required > jars to the classpath and calling the getInstrumentation() method. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From adinn at redhat.com Fri Sep 30 13:14:55 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 30 Sep 2016 14:14:55 +0100 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> <66ea493e-b26d-d2f4-f8cd-ebedf63a9724@oracle.com> Message-ID: <57ca785c-f463-9bb9-cb48-766055908958@redhat.com> On 30/09/16 13:15, Rafael Winterhalter wrote: > Such a library exists already: > http://mvnrepository.com/search?q=byte-buddy-agent Ok, so problem solved :-) > I do however not share your point of view on this: if there is a valid > use case for self-attachment - Aleksey, you and I already named several > such use cases - why not add convenience, security and performance to > the API? Right now, a library can already self-attach when there is no > security manager but will always expose the Instrumentation instance > accessibly on the system class loader. I am not really sure what you mean by "will always expose the Instrumentation instance accessibly on the system class loader". Are you talking about reflective access from classes loaded by the system class loader? or do you mean something else? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From rafael.wth at gmail.com Fri Sep 30 13:27:28 2016 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 30 Sep 2016 15:27:28 +0200 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: <57ca785c-f463-9bb9-cb48-766055908958@redhat.com> References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> <66ea493e-b26d-d2f4-f8cd-ebedf63a9724@oracle.com> <57ca785c-f463-9bb9-cb48-766055908958@redhat.com> Message-ID: A Java agent ends up on the class path. The Byte Buddy agent (or any similar library) basically adds a single class: package net.bytebuddy.agent; public class Installer { public static volatile Instrumentation instrumentation; public static void agentMain(String argument, Instrumentation instrumentation) { Agent.instrumentation = instrumentation } } Since the class is added using self-attachment, the agentmain method is called by the VM and the field value is set. In order to keep the field accessible, it needs to be public such that any class loader can call: Instrumentation instrumentation = (Instrumentation) Class.forName("net.bytebuddy.agent.Installer", false, ClassLoader.getSystemClassLoader()).getDeclaredField("instrumentation").get(null); Any library on the class path can now also call the above code without requiring any priviledges as the Instrumentation instance is exposed without constraints. Adding a proper method for reading an instance of Instrumentation would prevent this. 2016-09-30 15:14 GMT+02:00 Andrew Dinn : > On 30/09/16 13:15, Rafael Winterhalter wrote: > > Such a library exists already: > > http://mvnrepository.com/search?q=byte-buddy-agent > > Ok, so problem solved :-) > > > I do however not share your point of view on this: if there is a valid > > use case for self-attachment - Aleksey, you and I already named several > > such use cases - why not add convenience, security and performance to > > the API? Right now, a library can already self-attach when there is no > > security manager but will always expose the Instrumentation instance > > accessibly on the system class loader. > > I am not really sure what you mean by "will always expose the > Instrumentation instance accessibly on the system class loader". Are you > talking about reflective access from classes loaded by the system class > loader? or do you mean something else? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From adinn at redhat.com Fri Sep 30 13:51:06 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 30 Sep 2016 14:51:06 +0100 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> <66ea493e-b26d-d2f4-f8cd-ebedf63a9724@oracle.com> <57ca785c-f463-9bb9-cb48-766055908958@redhat.com> Message-ID: <8fdbd1a0-cacf-9dc0-bd8e-3f14fd12823c@redhat.com> On 30/09/16 14:27, Rafael Winterhalter wrote: > A Java agent ends up on the class path. The Byte Buddy agent (or any > similar library) basically adds a single class: > > package net.bytebuddy.agent; > public class Installer { > public static volatile Instrumentation instrumentation; > public static void agentMain(String argument, Instrumentation > instrumentation) { > Agent.instrumentation = instrumentation > } > } > > Since the class is added using self-attachment, the agentmain method is > called by the VM and the field value is set. In order to keep the field > accessible, it needs to be public such that any class loader can call: > > Instrumentation instrumentation = (Instrumentation) > Class.forName("net.bytebuddy.agent.Installer", false, > ClassLoader.getSystemClassLoader()).getDeclaredField("instrumentation").get(null); > > Any library on the class path can now also call the above code without > requiring any priviledges as the Instrumentation instance is exposed > without constraints. Adding a proper method for reading an instance of > Instrumentation would prevent this. Well, that's easily fixed. Make the agent push the Instrumentation instance to the class which loaded the agent. For example, provide the name of the class and name of a public setter method as arguments to agentMain (and, if you want, a shared key to validate the set). Then get the agent to locate the class, lookup the setter method and hand over the instance. regards, Andrew Dinn ----------- From rafael.wth at gmail.com Fri Sep 30 13:55:07 2016 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 30 Sep 2016 15:55:07 +0200 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: <8fdbd1a0-cacf-9dc0-bd8e-3f14fd12823c@redhat.com> References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> <66ea493e-b26d-d2f4-f8cd-ebedf63a9724@oracle.com> <57ca785c-f463-9bb9-cb48-766055908958@redhat.com> <8fdbd1a0-cacf-9dc0-bd8e-3f14fd12823c@redhat.com> Message-ID: That does not work in the general case but only if the initiating class is also on the class path. A class can only be identified uniquely as a pair of name and class loader. I experimented with this and ended up iterating over Instrumentation.getAllLoadedClasses which resulted in rather poor performance and ambiguity if there exist classes with the same name on different class loaders. Again, I argue that this problem is therefore worth addressing. Best regards, Rafael 2016-09-30 15:51 GMT+02:00 Andrew Dinn : > On 30/09/16 14:27, Rafael Winterhalter wrote: > > A Java agent ends up on the class path. The Byte Buddy agent (or any > > similar library) basically adds a single class: > > > > package net.bytebuddy.agent; > > public class Installer { > > public static volatile Instrumentation instrumentation; > > public static void agentMain(String argument, Instrumentation > > instrumentation) { > > Agent.instrumentation = instrumentation > > } > > } > > > > Since the class is added using self-attachment, the agentmain method is > > called by the VM and the field value is set. In order to keep the field > > accessible, it needs to be public such that any class loader can call: > > > > Instrumentation instrumentation = (Instrumentation) > > Class.forName("net.bytebuddy.agent.Installer", false, > > ClassLoader.getSystemClassLoader()).getDeclaredField(" > instrumentation").get(null); > > > > Any library on the class path can now also call the above code without > > requiring any priviledges as the Instrumentation instance is exposed > > without constraints. Adding a proper method for reading an instance of > > Instrumentation would prevent this. > > Well, that's easily fixed. Make the agent push the Instrumentation > instance to the class which loaded the agent. > > For example, provide the name of the class and name of a public setter > method as arguments to agentMain (and, if you want, a shared key to > validate the set). Then get the agent to locate the class, lookup the > setter method and hand over the instance. > > regards, > > > Andrew Dinn > ----------- > > From jbluettduncan at gmail.com Fri Sep 30 13:57:44 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Fri, 30 Sep 2016 14:57:44 +0100 Subject: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK In-Reply-To: References: <100bf463-ca7d-f0fd-dc6e-4433b5e483e0@oracle.com> <2F084007-7660-4B2F-8B11-7B99EC0B9718@reini.net> <9BBC10F6-B4AE-400F-B202-8A7F2DD550C3@reini.net> <26095be3-04df-3576-b41b-b7a199eaa854@oracle.com> <009bf30d-37ea-2362-fd9b-53a26d21fe03@oracle.com> <312895EC-5916-491C-AB16-26307CDC362F@oracle.com> <95429a179c85cae087303afb969b35bd@reini.net> <8c206fe5-6caa-bc5b-c073-dcc38fb3d0a0@oracle.com> Message-ID: Hi Stuart, Thanks for doing such a thorough review of the parts you've managed to look at so far. I see you had a number of questions in your numbered bullet points, so I'll do my best to answer them below. 1) It actually didn't occur to me that there was a potential TOCTOU problem in ModuleFinder.compose, despite the fact that I found a potential problem in FileTreeIterator - it completely missed me, so thank you for finding it! I'll see if I can put a similar comment there to what I wrote in FileTreeIterator. 2) I seem to remember doing an at least semi-thorough search of the JDK codebase, and coming to the conclusion that none of the code I touched was being serialized by the JDK itself. I think I mentioned this is a previous email, but I also remember saying that I wasn't sure if I took everything into account, as I'm not that familiar with serialization. So I decided just now to do a search on Grepcode for usages of CookieManager.get and CookieHandler.get , and curiously it looks like they're only used in sun classes in the JDK. So this change seems safe to me, unless I've missed something? Regarding code search engines, I know of sourcegraph.com, but I think it requires an account to use their service, and I don't know which repositories they index apart from GitHub. 3) In my local copy of jdk9, I've removed the TOCTOU comment in FileTreeIterator and changed List.of back to Arrays.asList, as your explanation regarding FileTreeWalker has convinced me that TOCTOU is not a real problem here, and I don't know if future memory improvements to List.of(T...) (like returning an ImmutableCollections.List1 when there's only 1 element) are worth the extra time spent copying into a new list. 4) The 'resolverFields' problem/comment was regarding DateTimeFormatter (see this part of latest webrev ), where I realised I couldn't use Set.of instead of Collections.unmodifiableSet(new HashSet<>(Arrays.asList(*))), because I noticed that one of the java.time tests was testing whether DateTimeFormatter.withResolverFields(TemporalField...) could accept null parameters, which made using Set.of impossible since it's null-hostile (as in it throws NullPointerException upon being constructed with null element(s)). So I never did submit a change with that bit of code replaced with Set.of. Instead I wrote a comment in the method explaining why one can't use Set.of. I don't really know if Stephen Colebourne saw that comment, though. Stephen Colebourne, are you still fine with all the changes I've made to the java.time classes? http://cr.openjdk.java.net/~reinhapa/reviews/8134373/ webrev.01/ Kind regards, Jonathan P.S. I'll wait until everything's reviewed before asking for a new webrev. From martinrb at google.com Fri Sep 30 14:45:05 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 30 Sep 2016 07:45:05 -0700 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: On Thu, Sep 29, 2016 at 2:31 AM, Peter Levart wrote: > > I think that this is enough to apply the fix, thanks. > I think general concurent software hygiene considerations are enough to commit this fix. Don't re-read fields, especially ones that are involved in a race! Finding an actual bug is awesome, but it's not necessary to get approval, at least from this reviewer! From cvarming at twitter.com Fri Sep 30 14:58:40 2016 From: cvarming at twitter.com (Carsten Varming) Date: Fri, 30 Sep 2016 10:58:40 -0400 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: Dear Peter, On Thu, Sep 29, 2016 at 5:31 AM, Peter Levart wrote: > I think Carsten has a point. > I think that this is enough to apply the fix, thanks. > You are welcome. I added my thoughts to the jira ticket. Carsten From adinn at redhat.com Fri Sep 30 15:02:11 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 30 Sep 2016 16:02:11 +0100 Subject: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM In-Reply-To: References: <8235b50a-7f93-a60a-10b1-c661d9638bc9@oracle.com> <66ea493e-b26d-d2f4-f8cd-ebedf63a9724@oracle.com> <57ca785c-f463-9bb9-cb48-766055908958@redhat.com> <8fdbd1a0-cacf-9dc0-bd8e-3f14fd12823c@redhat.com> Message-ID: <9a64d4b7-4f93-9641-148b-4068ddcd828b@redhat.com> On 30/09/16 14:55, Rafael Winterhalter wrote: > That does not work in the general case but only if the initiating class > is also on the class path. A class can only be identified uniquely as a > pair of name and class loader. > > I experimented with this and ended up iterating over > Instrumentation.getAllLoadedClasses which resulted in rather poor > performance and ambiguity if there exist classes with the same name on > different class loaders. Yeah but don't you still have your ByteBuddy API class, the one which initiates the load in the class path? Your agent can still push the instance to that class by calling a setter it provides and it can hand the instance out to classes which are allowed to use it. So, then you would have to stop any old clients from calling your API to retrieve an Instrumentation instance, for example by setting up a security manager. Otherwise it makes no difference whether the Instrumentation instance is accessible via a public static field or is handed out on demand by your API. You have set up this circumstance by providing a library which hands out an Instrumentation instance on demand. What I don't understand is why you think migrating this into the JDK changes things. You suggested that this would also need a security manager to control access. If that's needed to safeguard the API on Instrumentation then why is i tnot good enough to use the same mechanism to restrict access to your ByteBuddy API class? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From peter.levart at gmail.com Fri Sep 30 15:42:45 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 30 Sep 2016 17:42:45 +0200 Subject: RFR: 8166842: String.hashCode() has a non-benign data race In-Reply-To: References: <308e3b89-7de5-ea24-2df4-a4c529de36a5@gmail.com> <091c3433-c878-91b4-5568-04f8105e698c@oracle.com> Message-ID: <81dc6019-344f-24a2-c121-00979259a52f@gmail.com> Hi, Thank you all for reviews and comments, especially instructive was Hans Boehm's explanation about why JMM must allow reordering of plain reads from the same location. The fix is now pushed. Regards, Peter From Sergey.Bylokhov at oracle.com Fri Sep 30 15:45:39 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Sep 2016 18:45:39 +0300 Subject: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK Message-ID: Hello. Please review the fix for jdk9. This is request to deprecate the obsolete flags inside InputEvent. This constants were marked as obsolete in jdk1.4 and were replaced by the new one. In jdk1.4 the documentation were update with notion that the new constants should be used. And this bug is about official deprecation of them. We can replace old constants by the new one in the whole jdk, but I updated only the code in InputEvent to make change smaller and safer. So at least the new code in jdk and the code in applications will start to use the new constants. The changes in jconsole are necessary to fix deprecation warning. jprt build passed, no new issues were found by jck/jtreg tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8143077 Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00 -- Best regards, Sergey. From mandy.chung at oracle.com Fri Sep 30 16:01:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Sep 2016 09:01:41 -0700 Subject: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK In-Reply-To: References: Message-ID: <38FC8343-B900-4D18-86AA-D882DD9B9F43@oracle.com> The jconsole change looks fine. I?m including serviceability-dev and bcc core-libs-dev as serviceability-dev is the right mailing list for jconsole change. Mandy > On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov wrote: > > Hello. > > Please review the fix for jdk9. > > This is request to deprecate the obsolete flags inside InputEvent. This constants were marked as obsolete in jdk1.4 and were replaced by the new one. In jdk1.4 the documentation were update with notion that the new constants should be used. And this bug is about official deprecation of them. > > We can replace old constants by the new one in the whole jdk, but I updated only the code in InputEvent to make change smaller and safer. So at least the new code in jdk and the code in applications will start to use the new constants. > > The changes in jconsole are necessary to fix deprecation warning. > > jprt build passed, no new issues were found by jck/jtreg tests. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143077 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00 > > -- > Best regards, Sergey. From jbluettduncan at gmail.com Fri Sep 30 16:08:58 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Fri, 30 Sep 2016 17:08:58 +0100 Subject: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK In-Reply-To: References: Message-ID: Hi Sergey, I'm not a reviewer, but after reading the deprecation messages in Event.java * @deprecated It is recommended that {@code AWTEvent} class and its > subclasses > * be used instead. I get the impression they would read better without the redundant "class" in the middle, like so. * @deprecated It is recommended that {@code AWTEvent} and its subclasses > * be used instead. Kind regards, Jonathan On 30 September 2016 at 16:45, Sergey Bylokhov wrote: > Hello. > > Please review the fix for jdk9. > > This is request to deprecate the obsolete flags inside InputEvent. This > constants were marked as obsolete in jdk1.4 and were replaced by the new > one. In jdk1.4 the documentation were update with notion that the new > constants should be used. And this bug is about official deprecation of > them. > > We can replace old constants by the new one in the whole jdk, but I > updated only the code in InputEvent to make change smaller and safer. So at > least the new code in jdk and the code in applications will start to use > the new constants. > > The changes in jconsole are necessary to fix deprecation warning. > > jprt build passed, no new issues were found by jck/jtreg tests. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143077 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00 > > -- > Best regards, Sergey. > From yingqi.lu at intel.com Fri Sep 30 16:55:04 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 30 Sep 2016 16:55:04 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> Hi All, Please find the most recent version of the patch available at http://cr.openjdk.java.net/~igraves/8164900-2/ In this version, we have following two changes: 1. Move O_DIRECT flag from StandardOpenOption to ExtendedOpenOption 2. Move the checks of O_DIRECT from native code to Java code. Please let us know your feedback. Thanks, Lucy -----Original Message----- From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Lu, Yingqi Sent: Tuesday, September 27, 2016 9:57 AM To: Alan Bateman ; core-libs-dev at openjdk.java.net Cc: nio-dev at openjdk.java.net Subject: RE: Proposal for adding O_DIRECT support into JDK 9 Alan, Thank you for the explanation, we will modify the code accordingly and send it out soon for review. Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, September 27, 2016 8:45 AM To: Lu, Yingqi ; core-libs-dev at openjdk.java.net Cc: nio-dev at openjdk.java.net Subject: Re: Proposal for adding O_DIRECT support into JDK 9 On 26/09/2016 19:50, Lu, Yingqi wrote: > Alan, you mean readv0/write0 or read0/write0? I just want to make sure > :-) Apologies, I meant each of the native methods where the decision to use direct I/O or not would be a lot more maintainable in Java. You'll see that there are already code paths for direct vs. heap buffers. > > Anyone else has other opinions on where is the best home for O_DIRECT flag? The flags under jdk.unsupported will eventually be removed in the future JDK release? > > If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify that for sure. > I think ExtendedOpenOption is the right place. It's still TDB as to whether to put these extensions but that should be transparent to anyone using this when on the class path. -Alan From Roger.Riggs at Oracle.com Fri Sep 30 19:00:52 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 30 Sep 2016 15:00:52 -0400 Subject: RFR 9: 8155760 Implement Serialization Filtering - revised for extensibility In-Reply-To: References: <7a1bd8d7-1bf6-7357-6fcd-b7c83b08e52b@Oracle.com> <3ce4aef4-e0fc-4d4f-dfd6-484e12f89e2a@Oracle.com> <9666c25e-ef9c-8ea2-6175-019801b2e75f@Oracle.com> <58bbd16f-f6d4-f51d-1073-5dd7ee7a1f04@oracle.com> <8f483d12-aa78-a1d8-69fd-88c19e7ca7ea@Oracle.com> <64af9c79-6d69-d619-de5b-4ae7d6107247@Oracle.com> <466883E6-60CC-4CE5-BE2F-A29AE5EA4C04@oracle.com> <435b73b8-e87c-9042-18a3-293aea0062e7@Oracle.com> Message-ID: Converging on a final version. The ObjectInputFilter.FilterInfo.getClazz method was renamed to serialClass to improve readability and reduce ambiguity with getClass. A few other editorial improvements have been made in the docs of the FilterInfo interface for arrays, depth(), references(), and streamBytes() with respect to the initial values. Any additional review comments? Complete webrev supporting Serialization Filtering: http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ The specdiff of changes supporting evolving the API more easily: http://cr.openjdk.java.net/~rriggs/filter-diffs-8166739/overview-summary.html Javadoc (subset) http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html Thanks, Roger From john.r.rose at oracle.com Fri Sep 30 19:41:05 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 30 Sep 2016 12:41:05 -0700 Subject: ParallelStream Vs Stream Digest, Vol 113, Issue 94 In-Reply-To: References: <93fb0f8d-54a9-a2ba-5799-32c2cd7edf2e@oracle.com> Message-ID: On Sep 29, 2016, at 11:39 PM, Louis Wasserman wrote: > > You should absolutely not assume parallel streams are faster than > sequential streams. > http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html is pretty much > the iconic document on that subject, and explains circumstances under which > parallelism is good, and when it is likely to be harmful. Stuart Marks and Brian Goetz gave an excellent talk on this at JavaOne last week. You can view it here. The talk is called "Thinking in Parallel". https://youtu.be/WSxKI5S8j90?t=8h51m34s InfoQ wrote a useful summary of the talk, for those with no time for video: https://www.infoq.com/news/2016/09/JavaOne-2016-parallel-streams But the video is very enjoyable, even if you think you know what they are going to say. ? John P.S. One influence of this year's presentation is an epic manifesto by Guy Steele in 2010. https://www.infoq.com/presentations/Thinking-Parallel-Programming From peter.levart at gmail.com Fri Sep 30 22:20:20 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 1 Oct 2016 00:20:20 +0200 Subject: =?UTF-8?Q?RFR:_6378384_=28reflect=29_subclass_can=e2=80=99t_access_?= =?UTF-8?Q?superclass=e2=80=99s_protected_fields_and_methods_by_reflection?= Message-ID: <629c397e-2813-15be-cccf-6436a7376289@gmail.com> Hi, I have a fix for a 10 year old bug (JDK-6378384 ). It was marked as a duplicate of a 19 year old bug (JDK-4032740 ) which is marked as a duplicate of a 17 year old bug (JDK-4283544 ) which is still open. But this bug is not a strict duplicate. This bug only concerns reflective access to protected members. Here's a proposed fix: http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.01/ The bug manifests itself as not being able to access protected static methods or fields from a subclass located in a different package. Instance protected methods and fields can be accessed, and using an undocumented trick, also static methods and fields, but the trick is very subtle. The specification for Field.get/set and Method.invoke says, respectively: *

    If the underlying field is a static field, the {@code obj} argument * is ignored; it may be null. and: *

    If the underlying method is static, then the specified {@code obj} * argument is ignored. It may be null. Well, it is not exactly so! The obj argument is used as a 'target' even for protected static members and it is ensured that its class is equal or a subclass of the class that accesses the member. So if you pass an instance of a subclass of the protected method's declaring class into the get/set/invoke, you can access the static protected member. If you pass 'null', you get IllegalAccessException. The problem is in the design of jdk.internal.reflect.Reflection#ensureMemberAccess method which is used to check reflective access. It takes an Object 'target' argument, which is supposed to be null when accessing static methods/fields and it is null also when accessing constructors. Because of constructors and the method's API, it has to be overly restrictive as it must only allow calling protected constructors from within the constructor's declaring class itself or same package, while protected static methods could be called from any subclass. By redesigning the API of this method, replacing Object 'target' parameter with Class 'targetClass' parameter and by passing the constructor's declaring class into this method instead of null, reflective checks suddenly start to look more like JLS dictates (but still a long way from it, unfortunately). As a bonus, sun.reflect.misc.ReflectUtil#ensureMemberAccess method (used from AtomicXXXFieldUpdater classes) does not need the following comment any more: * Reflection.ensureMemberAccess is overly-restrictive * due to a bug. We awkwardly work around it for now. ...as it can now delegate straight to Reflection.ensureMemberAccess without invoking it twice with different modified member access modifiers and performing part of the check itself. java.lang.reflect.AccessibleObject#checkAccess delegates to Reflection.ensureMemberAccess and caches the result, so it had to be modified too. Constructor now passes it's declaring class to the 'targetClass' parameter and Filed/Method obey the spec and REALLY IGNORE 'obj' parameter in get/set/invoke on a static member. All java/lang/reflect and java/util/concurrent/atomic tests pass with this patch applied except the following: java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java: Test java.lang.reflect.AccessibleObject with modules java/lang/reflect/Generics/TestBadSignatures.java: Test bad signatures get a GenericSignatureFormatError thrown. java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java: Reflection support for private methods in interfaces java/lang/reflect/Module/AddExportsTest.java: Test Module isExported methods with exports changed by -AddExportsTest java/lang/reflect/Proxy/ProxyModuleMapping.java: Basic test of proxy module mapping and the access to Proxy class java/lang/reflect/WeakPairMap/Driver.java: Functional test for WeakPairMap ...which all fail because of: javac: invalid flag: -XaddExports:java.base/jdk.internal.... Regards, Peter From stuart.marks at oracle.com Fri Sep 30 23:51:05 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 30 Sep 2016 16:51:05 -0700 Subject: ParallelStream Vs Stream Digest, Vol 113, Issue 94 In-Reply-To: References: <93fb0f8d-54a9-a2ba-5799-32c2cd7edf2e@oracle.com> Message-ID: <236b4ffe-91de-f6ad-534b-e084d4914f53@oracle.com> On 9/30/16 12:41 PM, John Rose wrote: > On Sep 29, 2016, at 11:39 PM, Louis Wasserman wrote: >> >> You should absolutely not assume parallel streams are faster than >> sequential streams. >> http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html is pretty much >> the iconic document on that subject, and explains circumstances under which >> parallelism is good, and when it is likely to be harmful. > > Stuart Marks and Brian Goetz gave an excellent talk on this at JavaOne last week. > > You can view it here. The talk is called "Thinking in Parallel". > https://youtu.be/WSxKI5S8j90?t=8h51m34s > > InfoQ wrote a useful summary of the talk, for those with no time for video: > https://www.infoq.com/news/2016/09/JavaOne-2016-parallel-streams > > But the video is very enjoyable, even if you think you know what they are going to say. > > ? John > > P.S. One influence of this year's presentation is an epic manifesto by Guy Steele in 2010. > https://www.infoq.com/presentations/Thinking-Parallel-Programming John, thanks for the plug! If you just want to look at the slides, they're linked from this post on my blog: https://stuartmarks.wordpress.com/2016/09/23/javaone-2016-sessions/ s'marks