From huizhe.wang at oracle.com Thu Nov 1 00:02:37 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Oct 2018 17:02:37 -0700 Subject: RFR(JDK12/java.xml) 8212871: Broken links give 401-Unauthorized Message-ID: <5BDA429D.8070603@oracle.com> Hi, Please review a fix for the broken links, replacing: http://www.w3.org/2002/08/WD-DOM-Level-3-XPath-20020820 with: https://www.w3.org/TR/DOM-Level-3-XPath/ The former on which the jdk.xml.dom package was based is no longer publicly available. The later is current. The only difference between the two was noted in the package info ( src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/package-info.java), and also in XPathException.java in this webrev. JBS: https://bugs.openjdk.java.net/browse/JDK-8212871 webrev: http://cr.openjdk.java.net/~joehw/jdk12/8212871/webrev/ Thanks, Joe From lance.andersen at oracle.com Thu Nov 1 00:09:17 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 31 Oct 2018 20:09:17 -0400 Subject: RFR(JDK12/java.xml) 8212871: Broken links give 401-Unauthorized In-Reply-To: <5BDA429D.8070603@oracle.com> References: <5BDA429D.8070603@oracle.com> Message-ID: Hi Joe, I see the update as https://www.w3.org/TR/DOM-Level-3-XPath/ and https://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/ Was that intentional? > On Oct 31, 2018, at 8:02 PM, Joe Wang wrote: > > Hi, > > Please review a fix for the broken links, replacing: > http://www.w3.org/2002/08/WD-DOM-Level-3-XPath-20020820 > with: > https://www.w3.org/TR/DOM-Level-3-XPath/ > > The former on which the jdk.xml.dom package was based is no longer publicly available. The later is current. The only difference between the two was noted in the package info ( src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/package-info.java), and also in XPathException.java in this webrev. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8212871 > webrev: http://cr.openjdk.java.net/~joehw/jdk12/8212871/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 dean.long at oracle.com Thu Nov 1 00:13:09 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 17:13:09 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> Message-ID: <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> On 10/31/18 4:06 PM, David Holmes wrote: > Hi Dean, > > Looking only at the hotspot changes. The removal of the DoPrivileged > and related privileged_stack code seems okay. I have a few related > comments: > > src/hotspot/share/classfile/systemDictionary.hpp > > You added the java_security_AccessController class after > java_security_AccessControlContext. Did you actually verify where in > the load/initialization order the AccessController class appears > today, and where it appears after your change? (Note the comments at > the start of WK_KLASSES_DO). Changes to the initialization order would > be my biggest concern with this patch. > No, I did not notice that comment and assumed alphabetical order was OK here.? However, these classes appear to be only resolved, not initialized (and AccessController does not have a static initializer), so could you explain how the order in this list can affect initialization order? I only need this in JVM_GetStackAccessControlContext, which is a static JNI method, so I could get the klass* from the incoming jclass instead of using a well-known class entry. > --- > > I'm unclear about the change to the test: > > test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm > > as it still refers to the now non-existent JVM_DoPrivileged in the > summary. Does this test still make sense? Should it be moved to the > Java side now it doesn't actually test anything in the VM? > I think these tests still make sense, unless we have similar coverage somewhere else.? How about if I fix the reference to JVM_DoPrivileged for now and file a separate bug about moving or removing these tests? > --- > > There may be further dead code to remove now: > > vmSymbols.hpp: codesource_permissioncollection_signature is now > unreferenced and can be removed. > > javaClasses.*: > ? - java_lang_System::has_security_manager > ? - java_security_AccessControlContext::is_authorized > > ./share/memory/universe.hpp:? static Method* > protection_domain_implies_method() > Good catches!? I have uploaded a new webrev: http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental diff) dl > --- > > Thanks, > David > > > On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project >> Loom by removing the Java --> native --> Java transition.? One reason >> doPrivileged has historically been in native is because of the need >> to guarantee the cleanup of the privileged context when doPrivileged >> returns.? To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk.? This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method >> returns. >> >> Tested with tier1-tier3 hotspot and jdk tests and JCK >> api/java_security tests.? For the first few rounds of testing, I kept >> the old native privileged stack and compared the results of the old >> and new implementations for each getContext call, which did catch >> some early bugs.? The changes were also examined by internal security >> experts and run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is >> approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here >> [2]. >> >> dl >> >> [1] >> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >> >> From lance.andersen at oracle.com Thu Nov 1 00:14:10 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 31 Oct 2018 20:14:10 -0400 Subject: RFR(JDK12/java.xml) 8212871: Broken links give 401-Unauthorized In-Reply-To: References: <5BDA429D.8070603@oracle.com> Message-ID: <4AC28A52-9BE9-4945-9001-C269A9E6ED75@oracle.com> BTW This seems to only be for: --- old/src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/XPathNamespace.java 2018-10-31 16:49:00.265127157 -0700 +++ new/src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/XPathNamespace.java 2018-10-31 16:48:59.861089532 -0700 @@ -74,7 +74,7 @@ * future versions of the XPath specification, the definition of a namespace * node may be changed incomatibly, in which case incompatible changes to * field values may be required to implement versions beyond XPath 1.0. - *

See also the Document Object Model (DOM) Level 3 XPath Specification. + *

See also the Document Object Model (DOM) Level 3 XPath Specification. */ > On Oct 31, 2018, at 8:09 PM, Lance Andersen wrote: > > Hi Joe, > > I see the update as > > https://www.w3.org/TR/DOM-Level-3-XPath/ > and > > https://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/ > > Was that intentional? > > >> On Oct 31, 2018, at 8:02 PM, Joe Wang wrote: >> >> Hi, >> >> Please review a fix for the broken links, replacing: >> http://www.w3.org/2002/08/WD-DOM-Level-3-XPath-20020820 >> with: >> https://www.w3.org/TR/DOM-Level-3-XPath/ >> >> The former on which the jdk.xml.dom package was based is no longer publicly available. The later is current. The only difference between the two was noted in the package info ( src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/package-info.java), and also in XPathException.java in this webrev. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8212871 >> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8212871/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 > > > 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 david.holmes at oracle.com Thu Nov 1 00:54:58 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Nov 2018 10:54:58 +1000 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> Message-ID: <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> Hi Dean, On 1/11/2018 10:13 AM, dean.long at oracle.com wrote: > On 10/31/18 4:06 PM, David Holmes wrote: >> Hi Dean, >> >> Looking only at the hotspot changes. The removal of the DoPrivileged >> and related privileged_stack code seems okay. I have a few related >> comments: >> >> src/hotspot/share/classfile/systemDictionary.hpp >> >> You added the java_security_AccessController class after >> java_security_AccessControlContext. Did you actually verify where in >> the load/initialization order the AccessController class appears >> today, and where it appears after your change? (Note the comments at >> the start of WK_KLASSES_DO). Changes to the initialization order would >> be my biggest concern with this patch. >> > > No, I did not notice that comment and assumed alphabetical order was OK > here.? However, these classes appear to be only resolved, not > initialized (and AccessController does not have a static initializer), > so could you explain how the order in this list can affect > initialization order? You're right it doesn't. There are a couple of comments that refer to "initialization" but it's not static initialization of these classes. I'm unclear how the resolution order in that list may interact with other parts of the startup sequence. > I only need this in JVM_GetStackAccessControlContext, which is a static > JNI method, so I could get the klass* from the incoming jclass instead > of using a well-known class entry. I think it's okay given we have AccessControlContext there anyway. >> --- >> >> I'm unclear about the change to the test: >> >> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >> >> as it still refers to the now non-existent JVM_DoPrivileged in the >> summary. Does this test still make sense? Should it be moved to the >> Java side now it doesn't actually test anything in the VM? >> > > I think these tests still make sense, unless we have similar coverage > somewhere else.? How about if I fix the reference to JVM_DoPrivileged > for now and file a separate bug about moving or removing these tests? Yep that's fine. >> --- >> >> There may be further dead code to remove now: >> >> vmSymbols.hpp: codesource_permissioncollection_signature is now >> unreferenced and can be removed. >> >> javaClasses.*: >> ? - java_lang_System::has_security_manager >> ? - java_security_AccessControlContext::is_authorized >> >> ./share/memory/universe.hpp:? static Method* >> protection_domain_implies_method() >> > > Good catches!? I have uploaded a new webrev: > > http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ > http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental diff) Updates all look fine. Thanks, David ----- > dl > >> --- >> >> Thanks, >> David >> >> >> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>> >>> This change implements AccessController.doPrivileged in Java. This >>> gives a performance improvement while also being useful to Project >>> Loom by removing the Java --> native --> Java transition.? One reason >>> doPrivileged has historically been in native is because of the need >>> to guarantee the cleanup of the privileged context when doPrivileged >>> returns.? To do that in Java, the information that >>> AccessController.getContext needs is pushed onto the Java stack as >>> arguments to a method that getContext will recognize during its stack >>> walk.? This allows us to remove the native privileged stack while >>> guaranteeing that the privileged context goes away when the method >>> returns. >>> >>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>> api/java_security tests.? For the first few rounds of testing, I kept >>> the old native privileged stack and compared the results of the old >>> and new implementations for each getContext call, which did catch >>> some early bugs.? The changes were also examined by internal security >>> experts and run through additional internal security tests. >>> >>> The improvement on this [1] doPrivileged microbenchmark is >>> approximate 50x. >>> >>> There is no attempt to optimize getContext() or security permission >>> checks in this change, however, this is intended to be a first step >>> towards other possible improvements, for example those proposed here >>> [2]. >>> >>> dl >>> >>> [1] >>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>> >>> > From ioi.lam at oracle.com Thu Nov 1 01:01:35 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 31 Oct 2018 18:01:35 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> Message-ID: <920b1841-53cf-23c1-1f35-365518935ee0@oracle.com> On 10/31/18 5:13 PM, dean.long at oracle.com wrote: > On 10/31/18 4:06 PM, David Holmes wrote: >> Hi Dean, >> >> Looking only at the hotspot changes. The removal of the DoPrivileged >> and related privileged_stack code seems okay. I have a few related >> comments: >> >> src/hotspot/share/classfile/systemDictionary.hpp >> >> You added the java_security_AccessController class after >> java_security_AccessControlContext. Did you actually verify where in >> the load/initialization order the AccessController class appears >> today, and where it appears after your change? (Note the comments at >> the start of WK_KLASSES_DO). Changes to the initialization order >> would be my biggest concern with this patch. >> > > No, I did not notice that comment and assumed alphabetical order was > OK here.? However, these classes appear to be only resolved, not > initialized (and AccessController does not have a static initializer), > so could you explain how the order in this list can affect > initialization order? > > I only need this in JVM_GetStackAccessControlContext, which is a > static JNI method, so I could get the klass* from the incoming jclass > instead of using a well-known class entry. Hi Dean, You're correct that those classes are only resolved, and not initialized. So the order shouldn't matter too much. However, the order of the first few classes is important, as the creation of Object, Serializable, Cloneable, String, etc, has to be done in a certain order. I'm not sure whether the order of the reference classes, 292 classes, and box classes are important. I'll experiment of getting rid of the separate phases after the call to Universe::fixup_mirrors(). This might be relics from old days where the classes were once indeed initialized in SystemDictionary::initialize_well_known_classes, which was the old name for SystemDictionary::resolve_well_known_classes. (-XX:+TraceBytecodes shows no Java code is executed before resolve_well_known_classes returns). I filed https://bugs.openjdk.java.net/browse/JDK-8213230 For the time being, I think as long as you put the new AccessController class near the existing class AccessControlContext, you should be OK. Thanks - Ioi > >> --- >> >> I'm unclear about the change to the test: >> >> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >> >> as it still refers to the now non-existent JVM_DoPrivileged in the >> summary. Does this test still make sense? Should it be moved to the >> Java side now it doesn't actually test anything in the VM? >> > > I think these tests still make sense, unless we have similar coverage > somewhere else.? How about if I fix the reference to JVM_DoPrivileged > for now and file a separate bug about moving or removing these tests? > >> --- >> >> There may be further dead code to remove now: >> >> vmSymbols.hpp: codesource_permissioncollection_signature is now >> unreferenced and can be removed. >> >> javaClasses.*: >> ? - java_lang_System::has_security_manager >> ? - java_security_AccessControlContext::is_authorized >> >> ./share/memory/universe.hpp:? static Method* >> protection_domain_implies_method() >> > > Good catches!? I have uploaded a new webrev: > > http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ > http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental > diff) > > dl > >> --- >> >> Thanks, >> David >> >> >> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>> >>> This change implements AccessController.doPrivileged in Java. This >>> gives a performance improvement while also being useful to Project >>> Loom by removing the Java --> native --> Java transition.? One >>> reason doPrivileged has historically been in native is because of >>> the need to guarantee the cleanup of the privileged context when >>> doPrivileged returns.? To do that in Java, the information that >>> AccessController.getContext needs is pushed onto the Java stack as >>> arguments to a method that getContext will recognize during its >>> stack walk.? This allows us to remove the native privileged stack >>> while guaranteeing that the privileged context goes away when the >>> method returns. >>> >>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>> api/java_security tests.? For the first few rounds of testing, I >>> kept the old native privileged stack and compared the results of the >>> old and new implementations for each getContext call, which did >>> catch some early bugs.? The changes were also examined by internal >>> security experts and run through additional internal security tests. >>> >>> The improvement on this [1] doPrivileged microbenchmark is >>> approximate 50x. >>> >>> There is no attempt to optimize getContext() or security permission >>> checks in this change, however, this is intended to be a first step >>> towards other possible improvements, for example those proposed here >>> [2]. >>> >>> dl >>> >>> [1] >>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>> >>> > From vladimir.x.ivanov at oracle.com Thu Nov 1 01:11:11 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2018 18:11:11 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Dean, src/java.base/share/classes/java/security/AccessController.java: + /** + * Internal marker for hidden implementation frames. + */ + /*non-public*/ + @Target(ElementType.METHOD) + @Retention(RetentionPolicy.RUNTIME) + @interface Hidden { + } You declare @Hidden, but then map it to _method_Hidden along with @Hidden from java.lang.invoke.LambdaForm. What do you think about moving LambdaForm.Hidden to jdk.internal.vm.annotation instead and share among all usages? Best regards, Vladimir Ivanov On 31/10/2018 15:23, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java.? This > gives a performance improvement while also being useful to Project Loom > by removing the Java --> native --> Java transition.? One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns.? To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk.? This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method returns. > > Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security > tests.? For the first few rounds of testing, I kept the old native > privileged stack and compared the results of the old and new > implementations for each getContext call, which did catch some early > bugs.? The changes were also examined by internal security experts and > run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > > dl > > [1] > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html > > From dean.long at oracle.com Thu Nov 1 03:57:54 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 20:57:54 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> Message-ID: Thanks David. dl On 10/31/18 5:54 PM, David Holmes wrote: > Hi Dean, > > On 1/11/2018 10:13 AM, dean.long at oracle.com wrote: >> On 10/31/18 4:06 PM, David Holmes wrote: >>> Hi Dean, >>> >>> Looking only at the hotspot changes. The removal of the DoPrivileged >>> and related privileged_stack code seems okay. I have a few related >>> comments: >>> >>> src/hotspot/share/classfile/systemDictionary.hpp >>> >>> You added the java_security_AccessController class after >>> java_security_AccessControlContext. Did you actually verify where in >>> the load/initialization order the AccessController class appears >>> today, and where it appears after your change? (Note the comments at >>> the start of WK_KLASSES_DO). Changes to the initialization order >>> would be my biggest concern with this patch. >>> >> >> No, I did not notice that comment and assumed alphabetical order was >> OK here.? However, these classes appear to be only resolved, not >> initialized (and AccessController does not have a static >> initializer), so could you explain how the order in this list can >> affect initialization order? > > You're right it doesn't. There are a couple of comments that refer to > "initialization" but it's not static initialization of these classes. > > I'm unclear how the resolution order in that list may interact with > other parts of the startup sequence. > >> I only need this in JVM_GetStackAccessControlContext, which is a >> static JNI method, so I could get the klass* from the incoming jclass >> instead of using a well-known class entry. > > I think it's okay given we have AccessControlContext there anyway. > >>> --- >>> >>> I'm unclear about the change to the test: >>> >>> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >>> >>> as it still refers to the now non-existent JVM_DoPrivileged in the >>> summary. Does this test still make sense? Should it be moved to the >>> Java side now it doesn't actually test anything in the VM? >>> >> >> I think these tests still make sense, unless we have similar coverage >> somewhere else.? How about if I fix the reference to JVM_DoPrivileged >> for now and file a separate bug about moving or removing these tests? > > Yep that's fine. > >>> --- >>> >>> There may be further dead code to remove now: >>> >>> vmSymbols.hpp: codesource_permissioncollection_signature is now >>> unreferenced and can be removed. >>> >>> javaClasses.*: >>> ? - java_lang_System::has_security_manager >>> ? - java_security_AccessControlContext::is_authorized >>> >>> ./share/memory/universe.hpp:? static Method* >>> protection_domain_implies_method() >>> >> >> Good catches!? I have uploaded a new webrev: >> >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental >> diff) > > Updates all look fine. > > Thanks, > David > ----- > >> dl >> >>> --- >>> >>> Thanks, >>> David >>> >>> >>> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>> >>>> This change implements AccessController.doPrivileged in Java. This >>>> gives a performance improvement while also being useful to Project >>>> Loom by removing the Java --> native --> Java transition.? One >>>> reason doPrivileged has historically been in native is because of >>>> the need to guarantee the cleanup of the privileged context when >>>> doPrivileged returns.? To do that in Java, the information that >>>> AccessController.getContext needs is pushed onto the Java stack as >>>> arguments to a method that getContext will recognize during its >>>> stack walk.? This allows us to remove the native privileged stack >>>> while guaranteeing that the privileged context goes away when the >>>> method returns. >>>> >>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>> api/java_security tests.? For the first few rounds of testing, I >>>> kept the old native privileged stack and compared the results of >>>> the old and new implementations for each getContext call, which did >>>> catch some early bugs.? The changes were also examined by internal >>>> security experts and run through additional internal security tests. >>>> >>>> The improvement on this [1] doPrivileged microbenchmark is >>>> approximate 50x. >>>> >>>> There is no attempt to optimize getContext() or security permission >>>> checks in this change, however, this is intended to be a first step >>>> towards other possible improvements, for example those proposed >>>> here [2]. >>>> >>>> dl >>>> >>>> [1] >>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>> >>>> >> From dean.long at oracle.com Thu Nov 1 03:59:12 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 20:59:12 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <920b1841-53cf-23c1-1f35-365518935ee0@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> <920b1841-53cf-23c1-1f35-365518935ee0@oracle.com> Message-ID: Thanks Ioi. dl On 10/31/18 6:01 PM, Ioi Lam wrote: > > > On 10/31/18 5:13 PM, dean.long at oracle.com wrote: >> On 10/31/18 4:06 PM, David Holmes wrote: >>> Hi Dean, >>> >>> Looking only at the hotspot changes. The removal of the DoPrivileged >>> and related privileged_stack code seems okay. I have a few related >>> comments: >>> >>> src/hotspot/share/classfile/systemDictionary.hpp >>> >>> You added the java_security_AccessController class after >>> java_security_AccessControlContext. Did you actually verify where in >>> the load/initialization order the AccessController class appears >>> today, and where it appears after your change? (Note the comments at >>> the start of WK_KLASSES_DO). Changes to the initialization order >>> would be my biggest concern with this patch. >>> >> >> No, I did not notice that comment and assumed alphabetical order was >> OK here.? However, these classes appear to be only resolved, not >> initialized (and AccessController does not have a static >> initializer), so could you explain how the order in this list can >> affect initialization order? >> >> I only need this in JVM_GetStackAccessControlContext, which is a >> static JNI method, so I could get the klass* from the incoming jclass >> instead of using a well-known class entry. > > Hi Dean, > > You're correct that those classes are only resolved, and not > initialized. So the order shouldn't matter too much. However, the > order of the first few classes is important, as the creation of > Object, Serializable, Cloneable, String, etc, has to be done in a > certain order. > > I'm not sure whether the order of the reference classes, 292 classes, > and box classes are important. I'll experiment of getting rid of the > separate phases after the call to Universe::fixup_mirrors(). This > might be relics from old days where the classes were once indeed > initialized in SystemDictionary::initialize_well_known_classes, which > was the old name for SystemDictionary::resolve_well_known_classes. > > (-XX:+TraceBytecodes shows no Java code is executed before > resolve_well_known_classes returns). > > I filed https://bugs.openjdk.java.net/browse/JDK-8213230 > > For the time being, I think as long as you put the new > AccessController class near the existing class AccessControlContext, > you should be OK. > > Thanks > - Ioi >> >>> --- >>> >>> I'm unclear about the change to the test: >>> >>> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >>> >>> as it still refers to the now non-existent JVM_DoPrivileged in the >>> summary. Does this test still make sense? Should it be moved to the >>> Java side now it doesn't actually test anything in the VM? >>> >> >> I think these tests still make sense, unless we have similar coverage >> somewhere else.? How about if I fix the reference to JVM_DoPrivileged >> for now and file a separate bug about moving or removing these tests? >> >>> --- >>> >>> There may be further dead code to remove now: >>> >>> vmSymbols.hpp: codesource_permissioncollection_signature is now >>> unreferenced and can be removed. >>> >>> javaClasses.*: >>> ? - java_lang_System::has_security_manager >>> ? - java_security_AccessControlContext::is_authorized >>> >>> ./share/memory/universe.hpp:? static Method* >>> protection_domain_implies_method() >>> >> >> Good catches!? I have uploaded a new webrev: >> >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental >> diff) >> >> dl >> >>> --- >>> >>> Thanks, >>> David >>> >>> >>> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>> >>>> This change implements AccessController.doPrivileged in Java. This >>>> gives a performance improvement while also being useful to Project >>>> Loom by removing the Java --> native --> Java transition.? One >>>> reason doPrivileged has historically been in native is because of >>>> the need to guarantee the cleanup of the privileged context when >>>> doPrivileged returns.? To do that in Java, the information that >>>> AccessController.getContext needs is pushed onto the Java stack as >>>> arguments to a method that getContext will recognize during its >>>> stack walk.? This allows us to remove the native privileged stack >>>> while guaranteeing that the privileged context goes away when the >>>> method returns. >>>> >>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>> api/java_security tests.? For the first few rounds of testing, I >>>> kept the old native privileged stack and compared the results of >>>> the old and new implementations for each getContext call, which did >>>> catch some early bugs.? The changes were also examined by internal >>>> security experts and run through additional internal security tests. >>>> >>>> The improvement on this [1] doPrivileged microbenchmark is >>>> approximate 50x. >>>> >>>> There is no attempt to optimize getContext() or security permission >>>> checks in this change, however, this is intended to be a first step >>>> towards other possible improvements, for example those proposed >>>> here [2]. >>>> >>>> dl >>>> >>>> [1] >>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>> >>>> >> > From dean.long at oracle.com Thu Nov 1 04:06:22 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 21:06:22 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Message-ID: <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> I think it's a good idea, but I believe it would require a CSR request.? Do you mind if I file a separate issue for jdk.internal.vm.annotation.Hidden? dl On 10/31/18 6:11 PM, Vladimir Ivanov wrote: > Dean, > > src/java.base/share/classes/java/security/AccessController.java: > +??? /** > +???? * Internal marker for hidden implementation frames. > +???? */ > +??? /*non-public*/ > +??? @Target(ElementType.METHOD) > +??? @Retention(RetentionPolicy.RUNTIME) > +??? @interface Hidden { > +??? } > > You declare @Hidden, but then map it to _method_Hidden along with > @Hidden from java.lang.invoke.LambdaForm. > > What do you think about moving LambdaForm.Hidden to > jdk.internal.vm.annotation instead and share among all usages? > > Best regards, > Vladimir Ivanov > > On 31/10/2018 15:23, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project >> Loom by removing the Java --> native --> Java transition.? One reason >> doPrivileged has historically been in native is because of the need >> to guarantee the cleanup of the privileged context when doPrivileged >> returns.? To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk.? This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method >> returns. >> >> Tested with tier1-tier3 hotspot and jdk tests and JCK >> api/java_security tests.? For the first few rounds of testing, I kept >> the old native privileged stack and compared the results of the old >> and new implementations for each getContext call, which did catch >> some early bugs.? The changes were also examined by internal security >> experts and run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is >> approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here >> [2]. >> >> dl >> >> [1] >> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >> >> From ecki at zusammenkunft.net Thu Nov 1 04:39:08 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 1 Nov 2018 04:39:08 +0000 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com>, <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Message-ID: http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html In checkContext should the security manager be null checked first instead of last to optimize for the typical case? (If the side effects in that expression are desired it should be documented) I find the tail call optimization comment in wrapException adds only confusion to an otherwise clear helper. But maybe it?s just me who does not understand it. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Vladimir Ivanov Gesendet: Donnerstag, November 1, 2018 5:11 AM An: dean.long at oracle.com; security-dev at openjdk.java.net; core-libs-dev Libs; hotspot-dev developers Betreff: Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged Dean, src/java.base/share/classes/java/security/AccessController.java: + /** + * Internal marker for hidden implementation frames. + */ + /*non-public*/ + @Target(ElementType.METHOD) + @Retention(RetentionPolicy.RUNTIME) + @interface Hidden { + } You declare @Hidden, but then map it to _method_Hidden along with @Hidden from java.lang.invoke.LambdaForm. What do you think about moving LambdaForm.Hidden to jdk.internal.vm.annotation instead and share among all usages? Best regards, Vladimir Ivanov On 31/10/2018 15:23, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java. This > gives a performance improvement while also being useful to Project Loom > by removing the Java --> native --> Java transition. One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns. To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk. This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method returns. > > Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security > tests. For the first few rounds of testing, I kept the old native > privileged stack and compared the results of the old and new > implementations for each getContext call, which did catch some early > bugs. The changes were also examined by internal security experts and > run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > > dl > > [1] > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html > > From huizhe.wang at oracle.com Thu Nov 1 04:45:00 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Oct 2018 21:45:00 -0700 Subject: RFR(JDK12/java.xml) 8212871: Broken links give 401-Unauthorized In-Reply-To: <4AC28A52-9BE9-4945-9001-C269A9E6ED75@oracle.com> References: <5BDA429D.8070603@oracle.com> <4AC28A52-9BE9-4945-9001-C269A9E6ED75@oracle.com> Message-ID: <5BDA84CC.3080600@oracle.com> Thanks Lance! I somehow copied the wrong link. Although they point to the same document, the shorter version (without the prefix and date) is better. Fixed now in the webrev: webrev: http://cr.openjdk.java.net/~joehw/jdk12/8212871/webrev/ Thanks, Joe On 10/31/18, 5:14 PM, Lance Andersen wrote: > BTW > > This seems to only be for: > > --- old/src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/XPathNamespace.java 2018-10-31 16:49:00.265127157 -0700 > +++ new/src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/XPathNamespace.java 2018-10-31 16:48:59.861089532 -0700 > @@ -74,7 +74,7 @@ > * future versions of the XPath specification, the definition of a namespace > * node may be changed incomatibly, in which case incompatible changes to > * field values may be required to implement versions beyond XPath 1.0. > - *

See also theDocument Object Model (DOM) Level 3 XPath Specification. > + *

See also theDocument Object Model (DOM) Level 3 XPath Specification. > */ > >> On Oct 31, 2018, at 8:09 PM, Lance Andersen >> > wrote: >> >> Hi Joe, >> >> I see the update as >> >> https://www.w3.org/TR/DOM-Level-3-XPath/ >> and >> >> https://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/ >> >> >> Was that intentional? >> >> >>> On Oct 31, 2018, at 8:02 PM, Joe Wang wrote: >>> >>> Hi, >>> >>> Please review a fix for the broken links, replacing: >>> http://www.w3.org/2002/08/WD-DOM-Level-3-XPath-20020820 >>> with: >>> https://www.w3.org/TR/DOM-Level-3-XPath/ >>> >>> The former on which the jdk.xml.dom package was based is no longer >>> publicly available. The later is current. The only difference >>> between the two was noted in the package info ( >>> src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/package-info.java), >>> and also in XPathException.java in this webrev. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212871 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8212871/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 >> >> >> > > > > 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 dean.long at oracle.com Thu Nov 1 05:29:24 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 22:29:24 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Message-ID: <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> Hi Bernd, On 10/31/18 9:39 PM, Bernd Eckenfels wrote: > http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html > > In checkContext should the security manager be null checked first instead of last to optimize for the typical case? (If the side effects in that expression are desired it should be documented) I was following the example of createWrapper.? The side-effects of getInnocuousAcc() will only happen once, so the order shouldn't matter here, except for performance reasons.? I don't have a strong opinion about the order, but it looks like the typical case for createWrapper would also be the typical case for checkContext, so maybe they both should be changed, if indeed a null security manager is the more typical case. > I find the tail call optimization comment in wrapException adds only confusion to an otherwise clear helper. But maybe it?s just me who does not understand it. OK, I'm happy to remove it if it's confusing or not helpful.? The reason for the other @ForceInline and @ReservedStackAccess annotations is to reduce that chance of getting a StackOverflowError, and tail call elimination would also help with that.? Let's see if anyone else finds the comment helpful or confusing. dl > Gruss > Bernd > -- > http://bernd.eckenfels.net > > ________________________________ > Von: core-libs-dev im Auftrag von Vladimir Ivanov > Gesendet: Donnerstag, November 1, 2018 5:11 AM > An: dean.long at oracle.com; security-dev at openjdk.java.net; core-libs-dev Libs; hotspot-dev developers > Betreff: Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged > > Dean, > > src/java.base/share/classes/java/security/AccessController.java: > + /** > + * Internal marker for hidden implementation frames. > + */ > + /*non-public*/ > + @Target(ElementType.METHOD) > + @Retention(RetentionPolicy.RUNTIME) > + @interface Hidden { > + } > > You declare @Hidden, but then map it to _method_Hidden along with > @Hidden from java.lang.invoke.LambdaForm. > > What do you think about moving LambdaForm.Hidden to > jdk.internal.vm.annotation instead and share among all usages? > > Best regards, > Vladimir Ivanov > > On 31/10/2018 15:23, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project Loom >> by removing the Java --> native --> Java transition. One reason >> doPrivileged has historically been in native is because of the need to >> guarantee the cleanup of the privileged context when doPrivileged >> returns. To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk. This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method returns. >> >> Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security >> tests. For the first few rounds of testing, I kept the old native >> privileged stack and compared the results of the old and new >> implementations for each getContext call, which did catch some early >> bugs. The changes were also examined by internal security experts and >> run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here [2]. >> >> dl >> >> [1] >> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >> >> From Alan.Bateman at oracle.com Thu Nov 1 08:11:03 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Nov 2018 08:11:03 +0000 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <8926843e-d351-0d63-a7c7-9aa344233e11@oracle.com> References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> <143e4553-dba0-64ee-946e-311ca710be87@oracle.com> <8435fba7-a6fa-4d27-6ad8-ffd20ce5468e@oracle.com> <8926843e-d351-0d63-a7c7-9aa344233e11@oracle.com> Message-ID: On 31/10/2018 13:45, Roger Riggs wrote: > Hi Thomas, > > The webrev looks fine. > > Please remove the @author tag in the Linux (2nd) test block in Basic.java. > Author tags are losing favor and there's no need to repeat it. I agree, no need to repeat it here. The webrev otherwise looks good to me too and I see Roger's issue to looking at switching the default. -Alan From vladimir.x.ivanov at oracle.com Thu Nov 1 08:18:37 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 1 Nov 2018 01:18:37 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> Message-ID: <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> > I think it's a good idea, but I believe it would require a CSR request. > Do you mind if I file a separate issue for > jdk.internal.vm.annotation.Hidden? Sure. Most of the annotations in jdk.internal.vm.annotation were originally located in java.lang.invoke. Not sure CSR will be required in this particular case. Best regards, Vladimir Ivanov > On 10/31/18 6:11 PM, Vladimir Ivanov wrote: >> Dean, >> >> src/java.base/share/classes/java/security/AccessController.java: >> +??? /** >> +???? * Internal marker for hidden implementation frames. >> +???? */ >> +??? /*non-public*/ >> +??? @Target(ElementType.METHOD) >> +??? @Retention(RetentionPolicy.RUNTIME) >> +??? @interface Hidden { >> +??? } >> >> You declare @Hidden, but then map it to _method_Hidden along with >> @Hidden from java.lang.invoke.LambdaForm. >> >> What do you think about moving LambdaForm.Hidden to >> jdk.internal.vm.annotation instead and share among all usages? >> >> Best regards, >> Vladimir Ivanov >> >> On 31/10/2018 15:23, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>> >>> This change implements AccessController.doPrivileged in Java. This >>> gives a performance improvement while also being useful to Project >>> Loom by removing the Java --> native --> Java transition.? One reason >>> doPrivileged has historically been in native is because of the need >>> to guarantee the cleanup of the privileged context when doPrivileged >>> returns.? To do that in Java, the information that >>> AccessController.getContext needs is pushed onto the Java stack as >>> arguments to a method that getContext will recognize during its stack >>> walk.? This allows us to remove the native privileged stack while >>> guaranteeing that the privileged context goes away when the method >>> returns. >>> >>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>> api/java_security tests.? For the first few rounds of testing, I kept >>> the old native privileged stack and compared the results of the old >>> and new implementations for each getContext call, which did catch >>> some early bugs.? The changes were also examined by internal security >>> experts and run through additional internal security tests. >>> >>> The improvement on this [1] doPrivileged microbenchmark is >>> approximate 50x. >>> >>> There is no attempt to optimize getContext() or security permission >>> checks in this change, however, this is intended to be a first step >>> towards other possible improvements, for example those proposed here >>> [2]. >>> >>> dl >>> >>> [1] >>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>> >>> > From thomas.stuefe at gmail.com Thu Nov 1 08:28:06 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Nov 2018 09:28:06 +0100 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> <143e4553-dba0-64ee-946e-311ca710be87@oracle.com> <8435fba7-a6fa-4d27-6ad8-ffd20ce5468e@oracle.com> <8926843e-d351-0d63-a7c7-9aa344233e11@oracle.com> Message-ID: Thank you all. I just pushed. I set David as contributor since he provided the original patch. Cheers, Thomas On Thu, Nov 1, 2018 at 9:11 AM Alan Bateman wrote: > > On 31/10/2018 13:45, Roger Riggs wrote: > > Hi Thomas, > > > > The webrev looks fine. > > > > Please remove the @author tag in the Linux (2nd) test block in Basic.java. > > Author tags are losing favor and there's no need to repeat it. > I agree, no need to repeat it here. > > The webrev otherwise looks good to me too and I see Roger's issue to > looking at switching the default. > > -Alan From lance.andersen at oracle.com Thu Nov 1 10:40:27 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Nov 2018 06:40:27 -0400 Subject: RFR(JDK12/java.xml) 8212871: Broken links give 401-Unauthorized In-Reply-To: <5BDA84CC.3080600@oracle.com> References: <5BDA429D.8070603@oracle.com> <4AC28A52-9BE9-4945-9001-C269A9E6ED75@oracle.com> <5BDA84CC.3080600@oracle.com> Message-ID: <81403D11-552B-42D4-A634-6A667E34F454@oracle.com> Looks fine Joe. > On Nov 1, 2018, at 12:45 AM, Joe Wang wrote: > > Thanks Lance! I somehow copied the wrong link. Although they point to the same document, the shorter version (without the prefix and date) is better. Yes saw that. Best to change though unless that is a temporary URL > Fixed now in the webrev: > webrev: http://cr.openjdk.java.net/~joehw/jdk12/8212871/webrev/ > > Thanks, > Joe > > On 10/31/18, 5:14 PM, Lance Andersen wrote: >> >> BTW >> >> This seems to only be for: >> >> --- old/src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/XPathNamespace.java 2018-10-31 16:49:00.265127157 -0700 >> +++ new/src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/XPathNamespace.java 2018-10-31 16:48:59.861089532 -0700 >> @@ -74,7 +74,7 @@ >> * future versions of the XPath specification, the definition of a namespace >> * node may be changed incomatibly, in which case incompatible changes to >> * field values may be required to implement versions beyond XPath 1.0. >> - *

See also the Document Object Model (DOM) Level 3 XPath Specification. >> + *

See also the Document Object Model (DOM) Level 3 XPath Specification. >> */ >> >>> On Oct 31, 2018, at 8:09 PM, Lance Andersen > wrote: >>> >>> Hi Joe, >>> >>> I see the update as >>> >>> https://www.w3.org/TR/DOM-Level-3-XPath/ >>> and >>> >>> https://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/ >>> >>> Was that intentional? >>> >>> >>>> On Oct 31, 2018, at 8:02 PM, Joe Wang wrote: >>>> >>>> Hi, >>>> >>>> Please review a fix for the broken links, replacing: >>>> http://www.w3.org/2002/08/WD-DOM-Level-3-XPath-20020820 >>>> with: >>>> https://www.w3.org/TR/DOM-Level-3-XPath/ >>>> >>>> The former on which the jdk.xml.dom package was based is no longer publicly available. The later is current. The only difference between the two was noted in the package info ( src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/package-info.java), and also in XPathException.java in this webrev. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212871 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8212871/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 >>> >>> >>> >> >> >> >> 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 magnus.ihse.bursie at oracle.com Thu Nov 1 12:05:54 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 1 Nov 2018 13:05:54 +0100 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <756780e6-78ab-5759-7f7a-63f00f1e3feb@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <756780e6-78ab-5759-7f7a-63f00f1e3feb@oracle.com> Message-ID: <4db10545-ca8b-6eeb-e4e3-516271abdc60@oracle.com> On 2018-10-24 19:18, Erik Joelsson wrote: > Hello, > > Nice to see this finally happening! > > Are we actually adding a new demo? I thought we were working towards > getting rid of the demos completely. > > CompileJavaModules.gmk: > > The jdk.packager_CLEAN_FILES could be replaced with a simple > "jdk.packager_CLEAN := .properties" unless you actually need to add > all the platform specific files to builds for all platforms (which I > doubt?). To clarify, the current patch will add all linux, windows and > mac properties to builds of all OSes. Is that intended? > > Modules.gmk: > > I would rather have the filter be conditional on an inclusive list of > platforms. Other OpenJDK contributors are building for other OSes like > AIX and we don't want to have to keep track of all those. The list of > OSes that jpackager supports is well defined, so better check for > those explicitly. > > src/jdk.jlink/share/classes/module-info.java: > > I believe the qualified export needs to be put in a > module-info.java.extra file since we filter out the target module on > unsupported platforms. > > Launcher-jdk.packager.gmk: > > * Please use $$(call FindExecutableDirForModule, $$(MODULE)) for the > DEST dir in the copy. > * Please adjust the indentation of the big windows/else blocks. We > indent everything with 2 spaces in conditional blocks. > * A minor style nit on the copy-and-chmod macro, since it's meant to > be used as a recipe, we usually indent those with tabs to indicate > that they are recipe lines, in this case, one tab is enough even > though the surrounding define should be indented with 2 spaces (don't > combine tab and spaces here). > * The (new) SetupJdkExecutable macro handles VERSIONINFO_RESOURCE > automatically for you unless you have specific needs. This looks like > the defaults should be fine. > * Since this is just for windows, the TOOLCHAIN_LINK_CXX should not > make any difference. (It's only needed for GCC to force linking with > g++ instead of gcc) So please remove. > * You could consider using FindSrcDirsForComponent for the src dir. > > Lib-jdk.packager.gmk: > > * The native source files are not organized according to the standards > introduced with JEP 201. If they were, most of these SetupJdkLibrary > calls would automatically find the correct sources. I realize there is > a special case for the windows papplauncherc executable as it's built > from the same sources as papplauncher, so that will need a special > case. Building of the executables should be moved to > Launcher-jdk.packager.gmk however. > * Why are you changing the build output dir and copying debuginfo > files around? We have a standard way of building and places where > files are put. If that is not working for you, we need to fix it on a > global level. Having each native library being built differently is > not good for maintainability. > * VERSIONINFO_RESOURCE is handled automatically so does not need to be > specified. > * Please indent the full contents of logic blocks with 2 spaces. Not > having proper indents makes it much harder to read the code. > * Several lines are too long for future side by side comparisons, > please break them up. You can use the # lines as a soft guidance. On top of Erik's comments, I also have the following to add from a build perspective: * In make/CompileJavaModules.gmk: Do you really need to use GENERATE_JDKBYTECODE_NOWARNINGS? When you add new code to OpenJDK, it really *should* be able to build without warnings. This has previously only been used for legacy code that has not yet been brought up to OpenJDK standards. Introducing new code with warnings silenced feels like a step in the wrong direction. * In make/launcher/Launcher-jdk.packager.gmk: The setup of BUILD_JPACKAGEREXE is only done for windows, but you have "DISABLED_WARNINGS_gcc := unused-result implicit-fallthrough". This does not make sense. The CFLAGS listed look redundant. At the very least I know that -nologo is already present in CXXFLAGS_JDKEXE; I believe the same goes for the rest (or most of the rest) of the flags. Please only add flags if you really need them, since all special configuration/combinations is a potential cause for trouble in the future. This same applies to LDFLAGS. * In src/jdk.packager/unix/scripts/jpackager: This file? resides in a non-standard directory. We have a small list of directories that are supposed to come after the $MODULE/share|$OS/ part of the path, and "scripts" is not one of them. While there is no rule "forbidding" new kinds of directories, I strongly recommend against this. Looking more closely at the file, I wonder if you really need it? It's sole purpose seems to be to launch java -m jdk.packager/jdk.packager.main.Main. For that, we have a much better solution. Just change make/launcher/Launcher-jdk.packager.gmk to include the following contents: $(eval $(call SetupBuildLauncher, jpackager, \ ??? MAIN_CLASS := jdk.packager.main.Main, \ )) It will create a "jpackager" binary. Which works for Windows too, so maybe you won't even need that Windows executable, if that too is just a launcher? * In make/lib/Lib-jdk.packager.gmk: The same reservations as for BUILD_JPACKAGEREXE that the CFLAGS and LDFLAGS look redundant. Is there a difference between PACKAGERAPPLAUNCHEREXE_SRC and PACKAGERAPPLAUNCHERCEXE_SRC? I fail to spot it, if so. Are you just compiling the same source twice? Also, the names are *confusingly* similar. Please rename so that the difference is clearer! You don't have to have the PACKAGER or BUILD_PACKAGER prefix. It's just convenience to make sure we don't get name collisions. APP_LAUNCHER and APP_LAUNCHER_CLIENT would work fine. /Magnus > > /Erik > > > > On 2018-10-24 07:22, Alan Bateman wrote: >> On 23/10/2018 16:49, Andy Herrick wrote: >>> This patch implements the Java Packager Tool (jpackager) as >>> described in JEP 343: Packaging Tool >>> >>> >>> jpackager is a simple packaging tool, based on the JavaFX >>> |javapackager| tool, that: >>> >>> ?* Supports native packaging formats to give the end user a natural >>> ?? installation experience. These formats include |msi| and |exe| on >>> ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. >>> ?* Allows launch-time parameters to be specified at packaging time. >>> ?* Can be invoked directly, from the command line, or programmatically, >>> ?? via the |ToolProvider| API. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ >>> >> cc'ing build-dev as it's important to get it reviewed there. >> >> What is the plan for tests to go with this tool? I see there is one >> test in the webrev to do some argument validation but I don't see >> anything else right now. >> >> What is the status of the JNLPConverter tool? I see it is included as >> a "demo" but maybe it would be better to host somewhere else as this >> is for developers migrating Java Web Start applications. >> >> Would it be possible to update the JEP with all the CLI options? That >> would be useful for review and also useful for those invoking it with >> the ToolProvider API. >> >> If I read the webrev correctly then it adds two modules, one with the >> jpackager tool and the other with an API. It would be useful to get a >> bit more information on the split. Also I think the name of the API >> module and the package that it exports needs discussion to make sure >> that the right names are chosen. >> >> -Alan > From swpalmer at gmail.com Thu Nov 1 15:30:51 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 1 Nov 2018 11:30:51 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> Message-ID: On Oct 30, 2018, at 1:10 PM, Andy Herrick wrote: > > On 10/30/2018 12:09 PM, Alan Bateman wrote: >>> ... >> Alex has suggested jdk.jpackager to avoid giving the impression that it's the "JDK packager". Also several existing tool modules have the tool name in the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...). > This seems reasonable, jdk.packager -> jdk.jpackager > still leaves the question of jdk.packager.services -> jdk.jpackager.services (or jdk.jpackager.runtime) or something else ? I prefer jdk.jpackager.runtime. I think it makes more sense given the likely future functions that will be implemented there. User JVM args support and single instance support don?t seem to fit the ?services? name. I?m also hoping that the service daemon support will make it into the JDK 12 deliverable. Is that out of the question at this point? Regards, Scott From sean.mullan at oracle.com Thu Nov 1 16:48:57 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 12:48:57 -0400 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> Message-ID: <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> On 11/1/18 1:29 AM, dean.long at oracle.com wrote: > On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html >> >> >> In checkContext should the security manager be null checked first >> instead of last to optimize for the typical case? (If the side effects >> in that expression are desired it should be documented) > > I was following the example of createWrapper.? The side-effects of > getInnocuousAcc() will only happen once, so the order shouldn't matter > here, except for performance reasons.? I don't have a strong opinion > about the order, but it looks like the typical case for createWrapper > would also be the typical case for checkContext, so maybe they both > should be changed, if indeed a null security manager is the more typical > case. A null SM should be the more common case. I am ok with changing the order so the SM is checked first, but it should be done in both the createWrapper and checkContext methods. Alternatively, we could see if they could be combined to eliminate the duplicate code but that might not be practical from looking at them. --Sean From vicente.romero at oracle.com Thu Nov 1 16:50:25 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 1 Nov 2018 12:50:25 -0400 Subject: JDK 12 RFR of JDK-6304578: (reflect) toGenericString fails to print bounds of type variables on generic methods In-Reply-To: <2e31be3b-202f-14b1-b33d-fd9fe4d03fd6@oracle.com> References: <644c9465-3ea9-cc1b-689a-cbeca90463dc@oracle.com> <2e31be3b-202f-14b1-b33d-fd9fe4d03fd6@oracle.com> Message-ID: <132ea8a3-56d5-4b8f-68cf-7e8db00c57d5@oracle.com> last iteration looks good to me, Vicente On 10/25/18 5:47 PM, joe darcy wrote: > Hi Peter, > > Coming back to this review after my Code One activities this year have > run their course... > > > On 10/17/2018 3:07 PM, Peter Levart wrote: >> Hi Joe, >> >> On 10/17/2018 09:16 PM, joe darcy wrote: >>> PS In response to some off-list feedback, an updated webrev uses a >>> stream-ier implementation: >>> >>> http://cr.openjdk.java.net/~darcy/6304578.1/ >> >> I suggest further niceing: >> >> - if you make typeVarBounds() static, you could use it in >> Stream.map() as a method reference. >> - in Class.java line 285, you could also use Type::getTypeName method >> reference >> - in Class.java line 269, wouldn't the output be nicer if the >> delimiter in joining collector was ", " instead of "," (with a space >> after comma)? >> >> The same for Executable. >> > > Revised webrev generally taking those suggestions up at: > > ??? http://cr.openjdk.java.net/~darcy/6304578.2/ > > Diff of relevant parts of prior version below (screening out unrelated > changes to Class made in the interim). > > The behavior with respect to using a comma as a separator is part of > the spec of these methods and I don't want to alter that as part of > this change. > > Thanks, > > -Joe > > diff -r 6304578.1/raw_files/new/? 6304578.2/raw_files/new/ > diff -r > 6304578.1/raw_files/new/src/java.base/share/classes/java/lang/Class.java > 6304578.2/raw_files/new/src/java.base/share/classes/java/lang/Class.java > 268c268 > typeVarBounds(t)). > --- > > sb.append(Stream.of(typeparms).map(Class::typeVarBounds). > 279c279 > typeVar) { > --- > >???? static String typeVarBounds(TypeVariable typeVar) { > 285c285 > e.getTypeName()). > --- > >???????? Stream.of(bounds).map(Type::getTypeName). > 3413c3413,3414 > name + "(", ")"); > --- > >???????? StringBuilder sb = new StringBuilder(); > >???? sb.append(getName() + "." + name + "("); > 3415,3420c3416,3420 > c = argTypes[i]; > --- > >???????? Stream.of(argTypes).map(c -> {return (c == null) ? "null" : > c.getName();}). > >???????? collect(Collectors.joining(",")); > >???? } > >???? sb.append(")"); > >???????? return sb.toString(); > diff -r > 6304578.1/raw_files/new/src/java.base/share/classes/java/lang/reflect/Executable.java > 6304578.2/raw_files/new/src/java.base/share/classes/java/lang/reflect/Executable.java > > 116c116 > p.getTypeName()). > --- > > sb.append(Stream.of(parameterTypes).map(Type::getTypeName). > 122c122 > e.getTypeName()). > --- > > sb.append(Stream.of(exceptionTypes).map(Type::getTypeName). > 137c137 > typeVar) { > --- > >???? static String typeVarBounds(TypeVariable typeVar) { > 143c143 > e.getTypeName()). > --- > >???????? Stream.of(bounds).map(Type::getTypeName). > 156c156 > typeVarBounds(t)). > --- > > sb.append(Stream.of(typeparms).map(Executable::typeVarBounds). > 176,180c176,177 > ", ""); > --- > > sb.append(Stream.of(exceptionTypes).map(Type::getTypeName). > >?????????????? collect(Collectors.joining(",", " throws ", ""))); > > From sean.mullan at oracle.com Thu Nov 1 17:01:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 13:01:26 -0400 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: <670ff93f-e8e0-d7a0-d410-daa42b5a9a32@oracle.com> Some of the copyrights need to be updated to 2018. All else looks good to me as I had reviewed an earlier version of this before. We have talked about doing this for a while now, so I am finally glad we and are able to pretty much eliminate one of the more common SecurityManager related hot-spots and give a performance boost to applications that don't use the SM as well. --Sean On 10/31/18 6:23 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java.? This > gives a performance improvement while also being useful to Project Loom > by removing the Java --> native --> Java transition.? One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns.? To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk.? This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method returns. > > Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security > tests.? For the first few rounds of testing, I kept the old native > privileged stack and compared the results of the old and new > implementations for each getContext call, which did catch some early > bugs.? The changes were also examined by internal security experts and > run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > > dl > > [1] > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html > > From naoto.sato at oracle.com Thu Nov 1 18:11:50 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 1 Nov 2018 11:11:50 -0700 Subject: [12] RFR: 8213046: Define Japanese new Era character Message-ID: <384430af-6edd-e499-e004-622db81a7011@oracle.com> Hello, Please review a javadoc fix to this issue: https://bugs.openjdk.java.net/browse/JDK-8213046 The proposed change is located at: http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ This is to clarify the previously pushed change (8211398) in the javadoc of Character class. Naoto From lance.andersen at oracle.com Thu Nov 1 18:26:14 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Nov 2018 14:26:14 -0400 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: <384430af-6edd-e499-e004-622db81a7011@oracle.com> References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> Message-ID: <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> Hi Naoto + * The code point, U+32FF, is reserved by the Unicode Consortium + * to represent the Japanese square character for the new era that begins + * from May, 2019. Relevant methods in the Character class return the same + * properties as for the existing Japanese era characters (e.g., U+337E for + * "Meizi"). For the details of the code point, refer to + * + * http://blog.unicode.org/2018/09/new-japanese-era.html Is ?from? needed in the the above or could it be ? era that begins May, 2019 ? Also is there a change that the URL for the blog could disappear or are they typically a constant and do not change > On Nov 1, 2018, at 2:11 PM, Naoto Sato wrote: > > Hello, > > Please review a javadoc fix to this issue: > > https://bugs.openjdk.java.net/browse/JDK-8213046 > > The proposed change is located at: > > http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ > > This is to clarify the previously pushed change (8211398) in the javadoc of Character class. > > Naoto 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 Thu Nov 1 18:31:00 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 1 Nov 2018 11:31:00 -0700 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> Message-ID: Hi Lance, On 11/1/18 11:26 AM, Lance Andersen wrote: > Hi Naoto > > + * The code point, U+32FF, is reserved by the Unicode Consortium > + * to represent the Japanese square character for the new era that begins > + **from* May, 2019. Relevant methods in the Character class return the same > + * properties as for the existing Japanese era characters (e.g., U+337E for > + * "Meizi"). For the details of the code point, refer to > + * > + *http://blog.unicode.org/2018/09/new-japanese-era.html > > > > > Is ?from? needed in the the above or could it be > > ? era that begins May, 2019 ? OK, will remove that "from". > > > Also is there a change that the URL for the blog could disappear or are > they typically a constant and do not change That blog is an official one from Unicode Consortium. The subtitle of it reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES FROM THE UNICODE CONSORTIUM", so I don't expect the entry to disappear without any apparent reason. Naoto > > >> On Nov 1, 2018, at 2:11 PM, Naoto Sato > > wrote: >> >> Hello, >> >> Please review a javadoc fix to this issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8213046 >> >> The proposed change is located at: >> >> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >> >> This is to clarify the previously pushed change (8211398) in the >> javadoc of Character class. >> >> Naoto > > > > 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 dean.long at oracle.com Thu Nov 1 19:11:02 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 1 Nov 2018 12:11:02 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <670ff93f-e8e0-d7a0-d410-daa42b5a9a32@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <670ff93f-e8e0-d7a0-d410-daa42b5a9a32@oracle.com> Message-ID: <1a5cf1b4-d0ef-1b25-4d69-ecc9f4725c77@oracle.com> On 11/1/18 10:01 AM, Sean Mullan wrote: > Some of the copyrights need to be updated to 2018. > Fixed. > All else looks good to me as I had reviewed an earlier version of this > before. We have talked about doing this for a while now, so I am > finally glad we and are able to pretty much eliminate one of the more > common SecurityManager related hot-spots and give a performance boost > to applications that don't use the SM as well. > Thanks Sean. dl > --Sean > > On 10/31/18 6:23 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project >> Loom by removing the Java --> native --> Java transition.? One reason >> doPrivileged has historically been in native is because of the need >> to guarantee the cleanup of the privileged context when doPrivileged >> returns.? To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk.? This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method >> returns. >> >> Tested with tier1-tier3 hotspot and jdk tests and JCK >> api/java_security tests.? For the first few rounds of testing, I kept >> the old native privileged stack and compared the results of the old >> and new implementations for each getContext call, which did catch >> some early bugs.? The changes were also examined by internal security >> experts and run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is >> approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here >> [2]. >> >> dl >> >> [1] >> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >> >> From dean.long at oracle.com Thu Nov 1 19:21:07 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 1 Nov 2018 12:21:07 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> Message-ID: <8a485f73-e942-12e8-9c7d-0944ff0af2de@oracle.com> On 11/1/18 9:48 AM, Sean Mullan wrote: > On 11/1/18 1:29 AM, dean.long at oracle.com wrote: >> On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html >>> >>> >>> In checkContext should the security manager be null checked first >>> instead of last to optimize for the typical case? (If the side >>> effects in that expression are desired it should be documented) >> >> I was following the example of createWrapper.? The side-effects of >> getInnocuousAcc() will only happen once, so the order shouldn't >> matter here, except for performance reasons.? I don't have a strong >> opinion about the order, but it looks like the typical case for >> createWrapper would also be the typical case for checkContext, so >> maybe they both should be changed, if indeed a null security manager >> is the more typical case. > > A null SM should be the more common case. I am ok with changing the > order so the SM is checked first, but it should be done in both the > createWrapper and checkContext methods. Alternatively, we could see if > they could be combined to eliminate the duplicate code but that might > not be practical from looking at them. > I don't see a way to do it without using a lambda or doing extra work in one version, so I just changed the order for now.? I also replaced getCallerPD with the faster getProtectionDomain and removed a stale comment about impliesCreateAccessControlContext being called by the VM.? It should be safe to remove now, but I left it in to minimize changes. http://cr.openjdk.java.net/~dlong/8212605/webrev.3.incr/ http://cr.openjdk.java.net/~dlong/8212605/webrev.3/ dl > --Sean From sean.mullan at oracle.com Thu Nov 1 19:39:41 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 15:39:41 -0400 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <8a485f73-e942-12e8-9c7d-0944ff0af2de@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> <8a485f73-e942-12e8-9c7d-0944ff0af2de@oracle.com> Message-ID: <72357551-9393-d3e5-ced1-98452354ae9b@oracle.com> On 11/1/18 3:21 PM, dean.long at oracle.com wrote: > On 11/1/18 9:48 AM, Sean Mullan wrote: >> On 11/1/18 1:29 AM, dean.long at oracle.com wrote: >>> On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html >>>> >>>> >>>> In checkContext should the security manager be null checked first >>>> instead of last to optimize for the typical case? (If the side >>>> effects in that expression are desired it should be documented) >>> >>> I was following the example of createWrapper.? The side-effects of >>> getInnocuousAcc() will only happen once, so the order shouldn't >>> matter here, except for performance reasons.? I don't have a strong >>> opinion about the order, but it looks like the typical case for >>> createWrapper would also be the typical case for checkContext, so >>> maybe they both should be changed, if indeed a null security manager >>> is the more typical case. >> >> A null SM should be the more common case. I am ok with changing the >> order so the SM is checked first, but it should be done in both the >> createWrapper and checkContext methods. Alternatively, we could see if >> they could be combined to eliminate the duplicate code but that might >> not be practical from looking at them. >> > > I don't see a way to do it without using a lambda or doing extra work in > one version, so I just changed the order for now. Yes, I was thinking about using a lambda too, but I'm a bit wary of using lambdas in the security checking code. Best to keep the methods separate for now. > I also replaced > getCallerPD with the faster getProtectionDomain and removed a stale > comment about impliesCreateAccessControlContext being called by the VM. > It should be safe to remove now, but I left it in to minimize changes. I would just remove it, so we don't forget about it later. Looks good otherwise. --Sean > http://cr.openjdk.java.net/~dlong/8212605/webrev.3.incr/ > http://cr.openjdk.java.net/~dlong/8212605/webrev.3/ > > dl > >> --Sean > From naoto.sato at oracle.com Thu Nov 1 19:53:51 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 1 Nov 2018 12:53:51 -0700 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> Message-ID: Updated the webrev. Dropped the "," after "May" too. http://cr.openjdk.java.net/~naoto/8213046/webrev.01/ Naoto On 11/1/18 11:31 AM, Naoto Sato wrote: > Hi Lance, > > On 11/1/18 11:26 AM, Lance Andersen wrote: >> Hi Naoto >> >> + * The code point, U+32FF, is reserved by the Unicode Consortium >> + * to represent the Japanese square character for the new era that >> begins >> + **from*? May, 2019. Relevant methods in the Character class return >> the same >> + * properties as for the existing Japanese era characters (e.g., >> U+337E for >> + * "Meizi"). For the details of the code point, refer to >> + * >> + *http://blog.unicode.org/2018/09/new-japanese-era.html >> >> >> >> >> Is ?from? needed in the the above or could it be >> >> ? era that begins May, 2019 ? > > OK, will remove that "from". > >> >> >> Also is there a change that the URL for the blog could disappear or >> are they typically a constant and do not change > > That blog is an official one from Unicode Consortium. The subtitle of it > reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES FROM THE > UNICODE CONSORTIUM", so I don't expect the entry to disappear without > any apparent reason. > > Naoto > >> >> >>> On Nov 1, 2018, at 2:11 PM, Naoto Sato >> > wrote: >>> >>> Hello, >>> >>> Please review a javadoc fix to this issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8213046 >>> >>> The proposed change is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >>> >>> This is to clarify the previously pushed change (8211398) in the >>> javadoc of Character class. >>> >>> Naoto >> >> >> >> >> 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 Thu Nov 1 20:03:22 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Nov 2018 16:03:22 -0400 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> Message-ID: <2CACDC2C-DD65-4FD3-9D8B-5089C7121026@oracle.com> Looks better. Unless it is my eyes, the period seems missing after the blog URL. > On Nov 1, 2018, at 3:53 PM, Naoto Sato wrote: > > Updated the webrev. Dropped the "," after "May" too. > > http://cr.openjdk.java.net/~naoto/8213046/webrev.01/ > > Naoto > > On 11/1/18 11:31 AM, Naoto Sato wrote: >> Hi Lance, >> On 11/1/18 11:26 AM, Lance Andersen wrote: >>> Hi Naoto >>> >>> + * The code point, U+32FF, is reserved by the Unicode Consortium >>> + * to represent the Japanese square character for the new era that begins >>> + **from* May, 2019. Relevant methods in the Character class return the same >>> + * properties as for the existing Japanese era characters (e.g., U+337E for >>> + * "Meizi"). For the details of the code point, refer to >>> + * >>> + *http://blog.unicode.org/2018/09/new-japanese-era.html >>> >>> >>> >>> Is ?from? needed in the the above or could it be >>> >>> ? era that begins May, 2019 ? >> OK, will remove that "from". >>> >>> >>> Also is there a change that the URL for the blog could disappear or are they typically a constant and do not change >> That blog is an official one from Unicode Consortium. The subtitle of it reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES FROM THE UNICODE CONSORTIUM", so I don't expect the entry to disappear without any apparent reason. >> Naoto >>> >>> >>>> On Nov 1, 2018, at 2:11 PM, Naoto Sato > wrote: >>>> >>>> Hello, >>>> >>>> Please review a javadoc fix to this issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8213046 >>>> >>>> The proposed change is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >>>> >>>> This is to clarify the previously pushed change (8211398) in the javadoc of Character class. >>>> >>>> Naoto >>> >>> >>> >>> 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 pavel.rappo at oracle.com Thu Nov 1 20:04:12 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 1 Nov 2018 20:04:12 +0000 Subject: PipedInputStream improvement In-Reply-To: References: Message-ID: > On 29 Oct 2018, at 19:33, Ilya Gazman wrote: > > Hey guys, > > I created a more efficient version of java.io.PipedStream. I would like to > have a conversation with you about my implementation and how we can test > and benched marked it and eventually maybe even submit it for the next Java > release. > > Where's the implementation? Was it stripped by this mailing list? You can send me your code and I will post it to the http://cr.openjdk.java.net/ so we could bootstrap the discussion. From mandy.chung at oracle.com Thu Nov 1 20:45:37 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Nov 2018 13:45:37 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> Message-ID: On 11/1/18 1:18 AM, Vladimir Ivanov wrote: > >> I think it's a good idea, but I believe it would require a CSR >> request. Do you mind if I file a separate issue for >> jdk.internal.vm.annotation.Hidden? > > Sure. > > Most of the annotations in jdk.internal.vm.annotation were originally > located in java.lang.invoke. Not sure CSR will be required in this > particular case. > @Hidden is internal and no CSR is needed. FYI.? JDK-8212620 is the RFE to consider providing a standard mechanism to hide frames from stack trace. Mandy > Best regards, > Vladimir Ivanov > >> On 10/31/18 6:11 PM, Vladimir Ivanov wrote: >>> Dean, >>> >>> src/java.base/share/classes/java/security/AccessController.java: >>> +??? /** >>> +???? * Internal marker for hidden implementation frames. >>> +???? */ >>> +??? /*non-public*/ >>> +??? @Target(ElementType.METHOD) >>> +??? @Retention(RetentionPolicy.RUNTIME) >>> +??? @interface Hidden { >>> +??? } >>> >>> You declare @Hidden, but then map it to _method_Hidden along with >>> @Hidden from java.lang.invoke.LambdaForm. >>> >>> What do you think about moving LambdaForm.Hidden to >>> jdk.internal.vm.annotation instead and share among all usages? >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 31/10/2018 15:23, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>> >>>> This change implements AccessController.doPrivileged in Java. This >>>> gives a performance improvement while also being useful to Project >>>> Loom by removing the Java --> native --> Java transition.? One >>>> reason doPrivileged has historically been in native is because of >>>> the need to guarantee the cleanup of the privileged context when >>>> doPrivileged returns.? To do that in Java, the information that >>>> AccessController.getContext needs is pushed onto the Java stack as >>>> arguments to a method that getContext will recognize during its >>>> stack walk.? This allows us to remove the native privileged stack >>>> while guaranteeing that the privileged context goes away when the >>>> method returns. >>>> >>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>> api/java_security tests.? For the first few rounds of testing, I >>>> kept the old native privileged stack and compared the results of >>>> the old and new implementations for each getContext call, which did >>>> catch some early bugs.? The changes were also examined by internal >>>> security experts and run through additional internal security tests. >>>> >>>> The improvement on this [1] doPrivileged microbenchmark is >>>> approximate 50x. >>>> >>>> There is no attempt to optimize getContext() or security permission >>>> checks in this change, however, this is intended to be a first step >>>> towards other possible improvements, for example those proposed >>>> here [2]. >>>> >>>> dl >>>> >>>> [1] >>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>> >>>> >> From naoto.sato at oracle.com Thu Nov 1 20:51:19 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 1 Nov 2018 13:51:19 -0700 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: <2CACDC2C-DD65-4FD3-9D8B-5089C7121026@oracle.com> References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> <2CACDC2C-DD65-4FD3-9D8B-5089C7121026@oracle.com> Message-ID: Indeed. Added the period. http://cr.openjdk.java.net/~naoto/8213046/webrev.02/ Naoto On 11/1/18 1:03 PM, Lance Andersen wrote: > Looks better. ?Unless it is my eyes, the period seems missing after the > blog URL. > > >> On Nov 1, 2018, at 3:53 PM, Naoto Sato > > wrote: >> >> Updated the webrev. Dropped the "," after "May" too. >> >> http://cr.openjdk.java.net/~naoto/8213046/webrev.01/ >> >> >> Naoto >> >> On 11/1/18 11:31 AM, Naoto Sato wrote: >>> Hi Lance, >>> On 11/1/18 11:26 AM, Lance Andersen wrote: >>>> Hi Naoto >>>> >>>> + * The code point, U+32FF, is reserved by the Unicode Consortium >>>> + * to represent the Japanese square character for the new era that >>>> begins >>>> + **from*? May, 2019. Relevant methods in the Character class return >>>> the same >>>> + * properties as for the existing Japanese era characters (e.g., >>>> U+337E for >>>> + * "Meizi"). For the details of the code point, refer to >>>> + * >>>> + *http://blog.unicode.org/2018/09/new-japanese-era.html >>>> >>>> >>>> >>>> >>>> Is ?from? needed in the the above or could it be >>>> >>>> ? era that begins May, 2019 ? >>> OK, will remove that "from". >>>> >>>> >>>> Also is there a change that the URL for the blog could disappear or >>>> are they typically a constant and do not change >>> That blog is an official one from Unicode Consortium. The subtitle of >>> it reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES >>> FROM THE UNICODE CONSORTIUM", so I don't expect the entry to >>> disappear without any apparent reason. >>> Naoto >>>> >>>> >>>>> On Nov 1, 2018, at 2:11 PM, Naoto Sato >>>> > wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review a javadoc fix to this issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8213046 >>>>> >>>>> The proposed change is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >>>>> >>>>> This is to clarify the previously pushed change (8211398) in the >>>>> javadoc of Character class. >>>>> >>>>> Naoto >>>> >>>> >>>> >>>> >>>> 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 Thu Nov 1 20:55:14 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Nov 2018 16:55:14 -0400 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> <2CACDC2C-DD65-4FD3-9D8B-5089C7121026@oracle.com> Message-ID: <841AB14C-603F-47A0-8823-E865FA712794@oracle.com> ship it :-) > On Nov 1, 2018, at 4:51 PM, Naoto Sato wrote: > > Indeed. Added the period. > > http://cr.openjdk.java.net/~naoto/8213046/webrev.02/ > > Naoto > > On 11/1/18 1:03 PM, Lance Andersen wrote: >> Looks better. Unless it is my eyes, the period seems missing after the blog URL. >>> On Nov 1, 2018, at 3:53 PM, Naoto Sato > wrote: >>> >>> Updated the webrev. Dropped the "," after "May" too. >>> >>> http://cr.openjdk.java.net/~naoto/8213046/webrev.01/ >>> >>> Naoto >>> >>> On 11/1/18 11:31 AM, Naoto Sato wrote: >>>> Hi Lance, >>>> On 11/1/18 11:26 AM, Lance Andersen wrote: >>>>> Hi Naoto >>>>> >>>>> + * The code point, U+32FF, is reserved by the Unicode Consortium >>>>> + * to represent the Japanese square character for the new era that begins >>>>> + **from* May, 2019. Relevant methods in the Character class return the same >>>>> + * properties as for the existing Japanese era characters (e.g., U+337E for >>>>> + * "Meizi"). For the details of the code point, refer to >>>>> + * >>>>> + *http://blog.unicode.org/2018/09/new-japanese-era.html >>>>> >>>>> >>>>> >>>>> Is ?from? needed in the the above or could it be >>>>> >>>>> ? era that begins May, 2019 ? >>>> OK, will remove that "from". >>>>> >>>>> >>>>> Also is there a change that the URL for the blog could disappear or are they typically a constant and do not change >>>> That blog is an official one from Unicode Consortium. The subtitle of it reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES FROM THE UNICODE CONSORTIUM", so I don't expect the entry to disappear without any apparent reason. >>>> Naoto >>>>> >>>>> >>>>>> On Nov 1, 2018, at 2:11 PM, Naoto Sato > wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Please review a javadoc fix to this issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213046 >>>>>> >>>>>> The proposed change is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >>>>>> >>>>>> This is to clarify the previously pushed change (8211398) in the javadoc of Character class. >>>>>> >>>>>> Naoto >>>>> >>>>> >>>>> >>>>> 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 jonathan.gibbons at oracle.com Thu Nov 1 21:07:46 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 1 Nov 2018 14:07:46 -0700 Subject: PipedInputStream improvement In-Reply-To: References: Message-ID: <624fe1cf-ee3a-82c7-1860-731a39b9e7ed@oracle.com> You need to sign the Oracle Contributors Agreement (OCA) before contributing code. See https://openjdk.java.net/contribute/ -- Jon On 11/01/2018 01:04 PM, Pavel Rappo wrote: >> On 29 Oct 2018, at 19:33, Ilya Gazman wrote: >> >> Hey guys, >> >> I created a more efficient version of java.io.PipedStream. I would like to >> have a conversation with you about my implementation and how we can test >> and benched marked it and eventually maybe even submit it for the next Java >> release. >> >> > Where's the implementation? Was it stripped by this mailing list? You can send > me your code and I will post it to the http://cr.openjdk.java.net/ so we could > bootstrap the discussion. > From dean.long at oracle.com Thu Nov 1 21:34:33 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 1 Nov 2018 14:34:33 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> Message-ID: <4452ed95-c282-0ba7-340a-4566cfbb0095@oracle.com> On 11/1/18 1:45 PM, Mandy Chung wrote: > > > On 11/1/18 1:18 AM, Vladimir Ivanov wrote: >> >>> I think it's a good idea, but I believe it would require a CSR >>> request. Do you mind if I file a separate issue for >>> jdk.internal.vm.annotation.Hidden? >> >> Sure. >> >> Most of the annotations in jdk.internal.vm.annotation were originally >> located in java.lang.invoke. Not sure CSR will be required in this >> particular case. >> > > @Hidden is internal and no CSR is needed. > > FYI.? JDK-8212620 is the RFE to consider providing a standard > mechanism to hide frames from stack trace. > OK, I already filed JDK-8213234 but I think I should just close it as a duplicate of JDK-8212620. dl > Mandy > >> Best regards, >> Vladimir Ivanov >> >>> On 10/31/18 6:11 PM, Vladimir Ivanov wrote: >>>> Dean, >>>> >>>> src/java.base/share/classes/java/security/AccessController.java: >>>> +??? /** >>>> +???? * Internal marker for hidden implementation frames. >>>> +???? */ >>>> +??? /*non-public*/ >>>> +??? @Target(ElementType.METHOD) >>>> +??? @Retention(RetentionPolicy.RUNTIME) >>>> +??? @interface Hidden { >>>> +??? } >>>> >>>> You declare @Hidden, but then map it to _method_Hidden along with >>>> @Hidden from java.lang.invoke.LambdaForm. >>>> >>>> What do you think about moving LambdaForm.Hidden to >>>> jdk.internal.vm.annotation instead and share among all usages? >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 31/10/2018 15:23, dean.long at oracle.com wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>>> >>>>> This change implements AccessController.doPrivileged in Java. This >>>>> gives a performance improvement while also being useful to Project >>>>> Loom by removing the Java --> native --> Java transition.? One >>>>> reason doPrivileged has historically been in native is because of >>>>> the need to guarantee the cleanup of the privileged context when >>>>> doPrivileged returns.? To do that in Java, the information that >>>>> AccessController.getContext needs is pushed onto the Java stack as >>>>> arguments to a method that getContext will recognize during its >>>>> stack walk.? This allows us to remove the native privileged stack >>>>> while guaranteeing that the privileged context goes away when the >>>>> method returns. >>>>> >>>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>>> api/java_security tests.? For the first few rounds of testing, I >>>>> kept the old native privileged stack and compared the results of >>>>> the old and new implementations for each getContext call, which >>>>> did catch some early bugs.? The changes were also examined by >>>>> internal security experts and run through additional internal >>>>> security tests. >>>>> >>>>> The improvement on this [1] doPrivileged microbenchmark is >>>>> approximate 50x. >>>>> >>>>> There is no attempt to optimize getContext() or security >>>>> permission checks in this change, however, this is intended to be >>>>> a first step towards other possible improvements, for example >>>>> those proposed here [2]. >>>>> >>>>> dl >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>>> >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>>> >>>>> >>> > From mandy.chung at oracle.com Thu Nov 1 21:42:45 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Nov 2018 14:42:45 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <4452ed95-c282-0ba7-340a-4566cfbb0095@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> <4452ed95-c282-0ba7-340a-4566cfbb0095@oracle.com> Message-ID: <595b46eb-bd26-7207-77a7-c76c5fc9719f@oracle.com> On 11/1/18 2:34 PM, dean.long at oracle.com wrote: > >> @Hidden is internal and no CSR is needed. >> >> FYI.? JDK-8212620 is the RFE to consider providing a standard >> mechanism to hide frames from stack trace. >> > > OK, I already filed JDK-8213234 but I think I should just close it as > a duplicate of JDK-8212620. > JDK-8212620 likely does not make JDK 12.? I assume Vladimir suggests to do the rename with your fix (or a follow up). Mandy From pavel.rappo at oracle.com Thu Nov 1 21:42:04 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 1 Nov 2018 21:42:04 +0000 Subject: PipedInputStream improvement In-Reply-To: <624fe1cf-ee3a-82c7-1860-731a39b9e7ed@oracle.com> References: <624fe1cf-ee3a-82c7-1860-731a39b9e7ed@oracle.com> Message-ID: <74A649D7-B08D-4D18-A375-93DD2C26F3BE@oracle.com> Jonathan, Roger told Ilya yesterday about that. But I guess the point is we cannot proceed even with discussion until the OCA has been signed. Is that right? > On 1 Nov 2018, at 21:07, Jonathan Gibbons wrote: > > You need to sign the Oracle Contributors Agreement (OCA) before contributing code. > > See https://openjdk.java.net/contribute/ > > -- Jon > > > On 11/01/2018 01:04 PM, Pavel Rappo wrote: >>> On 29 Oct 2018, at 19:33, Ilya Gazman wrote: >>> >>> Hey guys, >>> >>> I created a more efficient version of java.io.PipedStream. I would like to >>> have a conversation with you about my implementation and how we can test >>> and benched marked it and eventually maybe even submit it for the next Java >>> release. >>> >>> >> Where's the implementation? Was it stripped by this mailing list? You can send >> me your code and I will post it to the http://cr.openjdk.java.net/ so we could >> bootstrap the discussion. From Roger.Riggs at oracle.com Thu Nov 1 21:43:23 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 1 Nov 2018 17:43:23 -0400 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: <841AB14C-603F-47A0-8823-E865FA712794@oracle.com> References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> <2CACDC2C-DD65-4FD3-9D8B-5089C7121026@oracle.com> <841AB14C-603F-47A0-8823-E865FA712794@oracle.com> Message-ID: +1 On 11/01/2018 04:55 PM, Lance Andersen wrote: > ship it :-) >> On Nov 1, 2018, at 4:51 PM, Naoto Sato wrote: >> >> Indeed. Added the period. >> >> http://cr.openjdk.java.net/~naoto/8213046/webrev.02/ >> >> Naoto >> >> On 11/1/18 1:03 PM, Lance Andersen wrote: >>> Looks better. Unless it is my eyes, the period seems missing after the blog URL. >>>> On Nov 1, 2018, at 3:53 PM, Naoto Sato > wrote: >>>> >>>> Updated the webrev. Dropped the "," after "May" too. >>>> >>>> http://cr.openjdk.java.net/~naoto/8213046/webrev.01/ >>>> >>>> Naoto >>>> >>>> On 11/1/18 11:31 AM, Naoto Sato wrote: >>>>> Hi Lance, >>>>> On 11/1/18 11:26 AM, Lance Andersen wrote: >>>>>> Hi Naoto >>>>>> >>>>>> + * The code point, U+32FF, is reserved by the Unicode Consortium >>>>>> + * to represent the Japanese square character for the new era that begins >>>>>> + **from* May, 2019. Relevant methods in the Character class return the same >>>>>> + * properties as for the existing Japanese era characters (e.g., U+337E for >>>>>> + * "Meizi"). For the details of the code point, refer to >>>>>> + * >>>>>> + *http://blog.unicode.org/2018/09/new-japanese-era.html >>>>>> >>>>>> >>>>>> >>>>>> Is ?from? needed in the the above or could it be >>>>>> >>>>>> ? era that begins May, 2019 ? >>>>> OK, will remove that "from". >>>>>> >>>>>> Also is there a change that the URL for the blog could disappear or are they typically a constant and do not change >>>>> That blog is an official one from Unicode Consortium. The subtitle of it reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES FROM THE UNICODE CONSORTIUM", so I don't expect the entry to disappear without any apparent reason. >>>>> Naoto >>>>>> >>>>>>> On Nov 1, 2018, at 2:11 PM, Naoto Sato > wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review a javadoc fix to this issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213046 >>>>>>> >>>>>>> The proposed change is located at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >>>>>>> >>>>>>> This is to clarify the previously pushed change (8211398) in the javadoc of Character class. >>>>>>> >>>>>>> Naoto >>>>>> >>>>>> >>>>>> 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 dean.long at oracle.com Thu Nov 1 21:52:05 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 1 Nov 2018 14:52:05 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <72357551-9393-d3e5-ced1-98452354ae9b@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> <8a485f73-e942-12e8-9c7d-0944ff0af2de@oracle.com> <72357551-9393-d3e5-ced1-98452354ae9b@oracle.com> Message-ID: On 11/1/18 12:39 PM, Sean Mullan wrote: >> I also replaced getCallerPD with the faster getProtectionDomain and >> removed a stale comment about impliesCreateAccessControlContext being >> called by the VM. It should be safe to remove now, but I left it in >> to minimize changes. > > I would just remove it, so we don't forget about it later. OK, I removed it: http://cr.openjdk.java.net/~dlong/8212605/webrev.4.incr/ dl From brian.burkhalter at oracle.com Thu Nov 1 22:24:52 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Nov 2018 15:24:52 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <78433376-a509-f430-e65b-f895b3e39555@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> <78433376-a509-f430-e65b-f895b3e39555@oracle.com> Message-ID: <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> Let?s try this again: http://cr.openjdk.java.net/~bpb/6516099/webrev.04/ The method skipNBytes(long) is now defined in terms of the skip(n) and read(n) with the behavior for negative n being left open for subclasses. Thanks, Brian > On Oct 25, 2018, at 7:15 AM, Roger Riggs wrote: > > The FIS skipping past of end of file is puzzling. > If the 'were beyond EOF' was considering the possibility that the file was being > extended concurrently with the skip operation then it would not be random, > just a normal writer/reader race. The return value from skip would be accurate > and still usable for skipNBytes. > > If the spec for skipNBytes describes its behavior in terms of the normal behaviors > of skip(n) and read(n) then it will not making promises it can't keep regardless of the subclass behavior. > > FIS also says it can do negative seeks which seems in conflict with InputStream. > The FIS.skip(-n) behavior raises the question about whether InputStream.skipNBytes should > allow -n? From stuart.marks at oracle.com Fri Nov 2 01:57:10 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 1 Nov 2018 18:57:10 -0700 Subject: [PATCH] improve javadoc in TreeSet#add api documentation In-Reply-To: References: Message-ID: <0bca8737-208c-3fb6-7ff8-6a867bbfc4cb@oracle.com> Hi Kishor, This is indeed an issue with the documentation. The root of the issue is that the implementations of the SortedSet and SortMap interfaces do not use the equals() method to determine set or map membership. Instead they use a comparison method (a Comparator, if provided, or the object's compareTo method, if Comparable). This is a subtle semantic difference, which IMHO isn't adequately explained in this section of the specification. There has been some discussion of this before; see https://bugs.openjdk.java.net/browse/JDK-8190545 Although that bug discusses the contains() method, the same semantic issue is present in the add() method and in several other methods. The general issue is explained in the SortedSet class doc, though it's rather buried in the discussion about the concept of "consistent with equals". This issue shows up in the add() and contains() method, and in other methods such as remove() -- and possibly others -- because the text has been copied from Set interface. (Probably erroneously.) Instead of patching individual methods of TreeSet, I think a more comprehensive approach is necessary. The SortedSet class doc should be clarified regarding use of the comparison method for set membership, and it should provide method doc -- possibly by adding overrides -- for all the methods for which set membership is significant. Then, implementations such as TreeSet should inherit the method text from the SortedSet methods, using {@inheritDoc} if possible. I don't think NavigableSet will be affected, but it should get a close look to make sure. The j.u.c.ConcurrentSkipListSet docs will probably also need to be looked at. (And all of the foregoing applies to SortMap and friends.) This is rather larger than a simple doc change to a single method -- are you up for it? :-) s'marks On 10/22/18 9:31 PM, Kishor Gollapalliwar wrote: > Hello Martin and Everyone, > > @Martin : Thank you for the response. > > I have attached the PATCH file to this email. > > Request you to sponsor this change. > > Please find file extract in case my attachment stripped out. > > diff -r ebe635565ff3 src/share/classes/java/util/TreeSet.java > --- a/src/share/classes/java/util/TreeSet.java Fri Oct 19 10:30:26 2018 > -0700 > +++ b/src/share/classes/java/util/TreeSet.java Tue Oct 23 09:44:44 2018 > +0530 > @@ -235,14 +235,19 @@ > } > > /** > - * Adds the specified element to this set if it is not already present. > - * More formally, adds the specified element {@code e} to this set if > - * the set contains no element {@code e2} such that > - * (e==null ? e2==null : e.equals(e2)). > - * If this set already contains the element, the call leaves the set > - * unchanged and returns {@code false}. > + * Adds the specified {@code newElement} to this set, if and only if > following conditions are met. > + *

    > + *
  1. The {@code newElement} is NOT {@code null} (unless, > {@link Comparator} > + * which supports/permits {@code null} comparison was provided at set > creation time.
    2. > + *
  2. AND there is no {@code setElement}, such that {@code > newElement.compareTo(setElement)==0} > + * ({@link Comparator#compare} {@code (newElement, setElement)==0}, > + * in case {@link Comparator} was provided at set creation time.)
    3. > + *
> + * > + *

If any of above conditions are NOT met, it will be > interpreted as > + * set already contains the element, hence call leaves the set > unchanged and returns {@code false}.

> * > - * @param e element to be added to this set > + * @param newElement, the element to be added to this set > * @return {@code true} if this set did not already contain the > specified > * element > * @throws ClassCastException if the specified object cannot be > compared > @@ -251,8 +256,8 @@ > * and this set uses natural ordering, or its comparator > * does not permit null elements > */ > - public boolean add(E e) { > - return m.put(e, PRESENT)==null; > + public boolean add(E newElement) { > + return m.put(newElement, PRESENT)==null; > } > > /** > Please revert in case of any queries. > > Thanks & Regards, > *Kishor Golapelliwar,* > The ability to convert ideas to things is the secret to outward success. > > On Mon, Oct 22, 2018 at 6:07 AM Martin Buchholz wrote: > >> Hi Kishor, >> >> I think your attachment was stripped out - standard policy for this >> mailing list, I think. >> For a small patch like this, you should just include the patch inline in >> text form. >> >> >> On Thu, Oct 18, 2018 at 2:21 AM, Kishor Gollapalliwar < >> kishor.gollapalliwar at gmail.com> wrote: >> >>> Hi Team, >>> >>> Please provide your approval to update TreeSet#add method as it's >>> documentation and behavior are not consistent. >>> >>> For more information, please refer my mail below and attachment. >>> >>> Thanks & Regards, >>> *Kishor Golapelliwar,* >>> The ability to convert ideas to things is the secret to outward success. >>> >>> ---------- Forwarded message --------- >>> From: Kishor Gollapalliwar >>> Date: Mon, Oct 15, 2018 at 11:40 AM >>> Subject: Re: Inconsistencies in TreeSet Interface >>> To: >>> Cc: >>> >>> >>> Hello Everyone, >>> >>> This is the first time I am writing mail to this group, hence please >>> ignore >>> my nuisance and guide me towards right direction. >>> >>> As suggested by Martin, I believe documentation need to be updated. >>> I would happy to update the documentation, please provide your inputs. >>> I have attache the .java file for more details. >>> >>> @Martin : I really appreciate your advice and help, thank you. >>> >>> Thank you, >>> Kishor Gollapalliwar >>> >>> On Sat, Oct 13, 2018 at 11:40 PM Martin Buchholz >>> wrote: >>> >>>> core-libs-dev is the right mailing list. >>>> >>>> The documentation could be improved, but it's nuanced - consider using a >>>> TreeSet with a Comparator that accepts null. >>>> >>>> On Sat, Oct 13, 2018 at 7:26 AM, Kishor Gollapalliwar < >>>> kishor.gollapalliwar at gmail.com> wrote: >>>> >>>>> Hello Everyone, >>>>> >>>>> Introduction : I?m an enthusiast java developer. I?m a newbie in this >>>>> group, hence please ignore my nuisance and guide me towards right >>>>> direction. >>>>> >>>>> ## Problems Statement >>>>> >>>>> Treeset#add method documentations : ?adds the specified element e to >>> this >>>>> set if the set contains no element e2 such that (e==null ? e2==null : >>>>> e.equals(e2))? >>>>> >>>>> Inconsistencies: >>>>> >>>>>> If we try to add ?null? value, it will throws NullPointerException, >>>>> hence >>>>>> e and e2 can not be null. >>>>> >>>>> >>>>> >>>>>> And e.compareTo(e2) ==0 || compare(e, e2)==0, it will not add to >>>>>> collection. >>>>> >>>>> >>>>> Request you to help me understand if behavior of Treeset#add method is >>> as >>>>> expected, and differ with set interface documentation. We may have to >>>>> consider to update method documentations, if behavior is expected. >>>>> >>>>> For more details I have attached the sample java application. >>>>> >>>>> I?ve tested the behavior on Orack JDK 8u181 (64 bit) and Open JDK >>> 8u181. >>>>> >>>>> Thanks & Regards, >>>>> *Kishor Golapelliwar,* >>>>> The ability to convert ideas to things is the secret to outward >>> success. >>>>> >>>> >>>> >>> >> >> From kishor.gollapalliwar at gmail.com Fri Nov 2 03:12:09 2018 From: kishor.gollapalliwar at gmail.com (Kishor Gollapalliwar) Date: Fri, 2 Nov 2018 08:42:09 +0530 Subject: [PATCH] improve javadoc in TreeSet#add api documentation In-Reply-To: <0bca8737-208c-3fb6-7ff8-6a867bbfc4cb@oracle.com> References: <0bca8737-208c-3fb6-7ff8-6a867bbfc4cb@oracle.com> Message-ID: Hello Stuart, Thank you for providing this opportunity. I'm up for this challenge and I'd love to take this task. The only huddle would be, how to proceed, ie planning things step by step, as this is my first time. If you can help me with the planning, I'll do the rest and fix these issues. Thank, Kishor Gollapalliwar On Fri 2 Nov, 2018, 07:27 Stuart Marks Hi Kishor, > > This is indeed an issue with the documentation. The root of the issue is > that > the implementations of the SortedSet and SortMap interfaces do not use the > equals() method to determine set or map membership. Instead they use a > comparison method (a Comparator, if provided, or the object's compareTo > method, > if Comparable). This is a subtle semantic difference, which IMHO isn't > adequately explained in this section of the specification. > > There has been some discussion of this before; see > > https://bugs.openjdk.java.net/browse/JDK-8190545 > > Although that bug discusses the contains() method, the same semantic issue > is > present in the add() method and in several other methods. The general > issue is > explained in the SortedSet class doc, though it's rather buried in the > discussion about the concept of "consistent with equals". > > This issue shows up in the add() and contains() method, and in other > methods > such as remove() -- and possibly others -- because the text has been > copied from > Set interface. (Probably erroneously.) > > Instead of patching individual methods of TreeSet, I think a more > comprehensive > approach is necessary. The SortedSet class doc should be clarified > regarding use > of the comparison method for set membership, and it should provide method > doc -- > possibly by adding overrides -- for all the methods for which set > membership is > significant. Then, implementations such as TreeSet should inherit the > method > text from the SortedSet methods, using {@inheritDoc} if possible. I don't > think > NavigableSet will be affected, but it should get a close look to make > sure. The > j.u.c.ConcurrentSkipListSet docs will probably also need to be looked at. > > (And all of the foregoing applies to SortMap and friends.) > > This is rather larger than a simple doc change to a single method -- are > you up > for it? :-) > > s'marks > > > On 10/22/18 9:31 PM, Kishor Gollapalliwar wrote: > > Hello Martin and Everyone, > > > > @Martin : Thank you for the response. > > > > I have attached the PATCH file to this email. > > > > Request you to sponsor this change. > > > > Please find file extract in case my attachment stripped out. > > > > diff -r ebe635565ff3 src/share/classes/java/util/TreeSet.java > > --- a/src/share/classes/java/util/TreeSet.java Fri Oct 19 10:30:26 > 2018 > > -0700 > > +++ b/src/share/classes/java/util/TreeSet.java Tue Oct 23 09:44:44 > 2018 > > +0530 > > @@ -235,14 +235,19 @@ > > } > > > > /** > > - * Adds the specified element to this set if it is not already > present. > > - * More formally, adds the specified element {@code e} to this set > if > > - * the set contains no element {@code e2} such that > > - * (e==null ? e2==null : e.equals(e2)). > > - * If this set already contains the element, the call leaves the set > > - * unchanged and returns {@code false}. > > + * Adds the specified {@code newElement} to this set, if and only if > > following conditions are met. > > + *
    > > + *
  1. The {@code newElement} is NOT {@code null} (unless, > > {@link Comparator} > > + * which supports/permits {@code null} comparison was provided at > set > > creation time.
    2. > > + *
  2. AND there is no {@code setElement}, such that {@code > > newElement.compareTo(setElement)==0} > > + * ({@link Comparator#compare} {@code (newElement, setElement)==0}, > > + * in case {@link Comparator} was provided at set creation > time.)
    3. > > + *
> > + * > > + *

If any of above conditions are NOT met, it will be > > interpreted as > > + * set already contains the element, hence call leaves the set > > unchanged and returns {@code false}.

> > * > > - * @param e element to be added to this set > > + * @param newElement, the element to be added to this set > > * @return {@code true} if this set did not already contain the > > specified > > * element > > * @throws ClassCastException if the specified object cannot be > > compared > > @@ -251,8 +256,8 @@ > > * and this set uses natural ordering, or its comparator > > * does not permit null elements > > */ > > - public boolean add(E e) { > > - return m.put(e, PRESENT)==null; > > + public boolean add(E newElement) { > > + return m.put(newElement, PRESENT)==null; > > } > > > > /** > > Please revert in case of any queries. > > > > Thanks & Regards, > > *Kishor Golapelliwar,* > > The ability to convert ideas to things is the secret to outward success. > > > > On Mon, Oct 22, 2018 at 6:07 AM Martin Buchholz > wrote: > > > >> Hi Kishor, > >> > >> I think your attachment was stripped out - standard policy for this > >> mailing list, I think. > >> For a small patch like this, you should just include the patch inline in > >> text form. > >> > >> > >> On Thu, Oct 18, 2018 at 2:21 AM, Kishor Gollapalliwar < > >> kishor.gollapalliwar at gmail.com> wrote: > >> > >>> Hi Team, > >>> > >>> Please provide your approval to update TreeSet#add method as it's > >>> documentation and behavior are not consistent. > >>> > >>> For more information, please refer my mail below and attachment. > >>> > >>> Thanks & Regards, > >>> *Kishor Golapelliwar,* > >>> The ability to convert ideas to things is the secret to outward > success. > >>> > >>> ---------- Forwarded message --------- > >>> From: Kishor Gollapalliwar > >>> Date: Mon, Oct 15, 2018 at 11:40 AM > >>> Subject: Re: Inconsistencies in TreeSet Interface > >>> To: > >>> Cc: > >>> > >>> > >>> Hello Everyone, > >>> > >>> This is the first time I am writing mail to this group, hence please > >>> ignore > >>> my nuisance and guide me towards right direction. > >>> > >>> As suggested by Martin, I believe documentation need to be updated. > >>> I would happy to update the documentation, please provide your inputs. > >>> I have attache the .java file for more details. > >>> > >>> @Martin : I really appreciate your advice and help, thank you. > >>> > >>> Thank you, > >>> Kishor Gollapalliwar > >>> > >>> On Sat, Oct 13, 2018 at 11:40 PM Martin Buchholz > >>> wrote: > >>> > >>>> core-libs-dev is the right mailing list. > >>>> > >>>> The documentation could be improved, but it's nuanced - consider > using a > >>>> TreeSet with a Comparator that accepts null. > >>>> > >>>> On Sat, Oct 13, 2018 at 7:26 AM, Kishor Gollapalliwar < > >>>> kishor.gollapalliwar at gmail.com> wrote: > >>>> > >>>>> Hello Everyone, > >>>>> > >>>>> Introduction : I?m an enthusiast java developer. I?m a newbie in this > >>>>> group, hence please ignore my nuisance and guide me towards right > >>>>> direction. > >>>>> > >>>>> ## Problems Statement > >>>>> > >>>>> Treeset#add method documentations : ?adds the specified element e to > >>> this > >>>>> set if the set contains no element e2 such that (e==null ? e2==null : > >>>>> e.equals(e2))? > >>>>> > >>>>> Inconsistencies: > >>>>> > >>>>>> If we try to add ?null? value, it will throws NullPointerException, > >>>>> hence > >>>>>> e and e2 can not be null. > >>>>> > >>>>> > >>>>> > >>>>>> And e.compareTo(e2) ==0 || compare(e, e2)==0, it will not add to > >>>>>> collection. > >>>>> > >>>>> > >>>>> Request you to help me understand if behavior of Treeset#add method > is > >>> as > >>>>> expected, and differ with set interface documentation. We may have to > >>>>> consider to update method documentations, if behavior is expected. > >>>>> > >>>>> For more details I have attached the sample java application. > >>>>> > >>>>> I?ve tested the behavior on Orack JDK 8u181 (64 bit) and Open JDK > >>> 8u181. > >>>>> > >>>>> Thanks & Regards, > >>>>> *Kishor Golapelliwar,* > >>>>> The ability to convert ideas to things is the secret to outward > >>> success. > >>>>> > >>>> > >>>> > >>> > >> > >> > From mandy.chung at oracle.com Fri Nov 2 04:16:32 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Nov 2018 21:16:32 -0700 Subject: Review request: JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported Message-ID: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> This patch includes the following changes that will reduce the number of internal classes made accessible to jdk.unsupported module via qualified exports. 1. move shared secrets to a new jdk.internal.access package. jdk.internal.misc package has been a dumping ground for various kinds of internal APIs and many of which were moved to an appropriate package. This is a follow-up clean up that moves the shared secrets and JavaXXXAccess interfaces to jdk.internal.access package. 2. add a wrapper class jdk.internal.misc.FileSystemOption to expose sun.nio.fs.ExtendedOptions for com.sun.nio.file to access This eliminates the qualified exports of sun.nio.fs to jdk.unsupported. 3. Refactor the implementation of sun.misc.Unsafe::invokeCleaner to jdk.internal.misc.Unsafe. This eliminates the qualified exports of jdk.internal.ref and sun.nio.ch to jdk.unsupported. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02 The change is straight forward although quite many files are modified. Majority of the changes is import statement change or test @modules change due to the rename. I ran hs-tier1-3 and jdk-tier1-3 tests. We considered the alternative to define a wrapper class for everything that jdk.unsupported module depends on in a dedicated package e.g. jdk.internal.unsupported.? It would need a wrapper for Unsafe, Signal, SignalHandler and ExtendedOptions.? It means that it would have 3 classes of each - two similar/duplicated implementations (one in sun.misc and one in jdk.internal.unsupported) and one in jdk.internal.misc ([1] is the prototype).? Only a limited number of files are touched but I think the proposed approach is cleaner. Thanks Mandy [1] http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.01/ From daniel.fuchs at oracle.com Fri Nov 2 10:18:18 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 2 Nov 2018 10:18:18 +0000 Subject: Review request: JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported In-Reply-To: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> References: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> Message-ID: <050a45ec-5074-477f-b3c4-b6e1f1814444@oracle.com> Hi Mandy, I won't comment on the approach, though [1] looks more cryptic to me as it includes suspicious native code changes. I skimmed through the patch file at http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02/open.patch and haven't noticed anything wrong at first sight. The changes to java.util.logging & associated tests look fine. best regards, -- daniel On 02/11/2018 04:16, Mandy Chung wrote: > This patch includes the following changes that will reduce the > number of internal classes made accessible to jdk.unsupported > module via qualified exports. > > 1. move shared secrets to a new jdk.internal.access package. > > jdk.internal.misc package has been a dumping ground for various > kinds of internal APIs and many of which were moved to an appropriate > package. This is a follow-up clean up that moves the shared secrets > and JavaXXXAccess interfaces to jdk.internal.access package. > > 2. add a wrapper class jdk.internal.misc.FileSystemOption to expose > sun.nio.fs.ExtendedOptions for com.sun.nio.file to access > > This eliminates the qualified exports of sun.nio.fs to jdk.unsupported. > > 3. Refactor the implementation of sun.misc.Unsafe::invokeCleaner > to jdk.internal.misc.Unsafe. > > This eliminates the qualified exports of jdk.internal.ref and > sun.nio.ch to jdk.unsupported. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02 > > The change is straight forward although quite many files are modified. > Majority of the changes is import statement change or test @modules > change due to the rename. > > I ran hs-tier1-3 and jdk-tier1-3 tests. > > We considered the alternative to define a wrapper class for everything > that jdk.unsupported module depends on in a dedicated package > e.g. jdk.internal.unsupported.? It would need a wrapper for Unsafe, > Signal, SignalHandler and ExtendedOptions.? It means that it would > have 3 classes of each - two similar/duplicated implementations > (one in sun.misc and one in jdk.internal.unsupported) and one > in jdk.internal.misc ([1] is the prototype).? Only a limited number > of files are touched but I think the proposed approach is cleaner. > > Thanks > Mandy > [1] http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.01/ From daniel.fuchs at oracle.com Fri Nov 2 10:40:51 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 2 Nov 2018 10:40:51 +0000 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> <78433376-a509-f430-e65b-f895b3e39555@oracle.com> <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> Message-ID: <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> Hi Brian, If skip(n) returns a negative number, e.g. -1, then you might end up skipping more than n bytes (unless skip returning -1 indicates that EOF was reached). Basically, I don't think you can make any guarantee of how many bytes will be skipped if a subclass has an implementation of skip that misbehave by returning -1 (or any other negative value). Maybe there should be some @implSpec note to say that no guarantee is made if a subclass implementation of skip() returns non-positive (or non accurate) results? best regards, -- daniel On 01/11/2018 22:24, Brian Burkhalter wrote: > Let?s try this again: > > http://cr.openjdk.java.net/~bpb/6516099/webrev.04/ > > The method skipNBytes(long) is now defined in terms of the skip(n) and read(n) with the behavior for negative n being left open for subclasses. > > Thanks, > > Brian > >> On Oct 25, 2018, at 7:15 AM, Roger Riggs wrote: >> >> The FIS skipping past of end of file is puzzling. >> If the 'were beyond EOF' was considering the possibility that the file was being >> extended concurrently with the skip operation then it would not be random, >> just a normal writer/reader race. The return value from skip would be accurate >> and still usable for skipNBytes. >> >> If the spec for skipNBytes describes its behavior in terms of the normal behaviors >> of skip(n) and read(n) then it will not making promises it can't keep regardless of the subclass behavior. >> >> FIS also says it can do negative seeks which seems in conflict with InputStream. >> The FIS.skip(-n) behavior raises the question about whether InputStream.skipNBytes should >> allow -n? > From Roger.Riggs at oracle.com Fri Nov 2 15:03:24 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 2 Nov 2018 11:03:24 -0400 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> <78433376-a509-f430-e65b-f895b3e39555@oracle.com> <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> Message-ID: <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> Hi Brian, The description of this implementation ("the default implementation...") can be put in an @implSpec tag, since it specifies the behavior of this method, and is not normative for all subclasses.? That will make the 'normal' behavior of the method easier to understand. As Daniel points out, the code should probably be a bit careful about the return value from skip(n) and add a disclaimer (also in the implSpec). Roger On 11/02/2018 06:40 AM, Daniel Fuchs wrote: > Hi Brian, > > If skip(n) returns a negative number, e.g. -1, then you might > end up skipping more than n bytes (unless skip returning > -1 indicates that EOF was reached). > > Basically, I don't think you can make any guarantee of how > many bytes will be skipped if a subclass has an implementation > of skip that misbehave by returning -1 (or any other negative > value). > > Maybe there should be some @implSpec note to say that > no guarantee is made if a subclass implementation of > skip() returns non-positive (or non accurate) results? > > best regards, > > -- daniel > > On 01/11/2018 22:24, Brian Burkhalter wrote: >> Let?s try this again: >> >> http://cr.openjdk.java.net/~bpb/6516099/webrev.04/ >> >> >> The method skipNBytes(long) is now defined in terms of the skip(n) >> and read(n) with the behavior for negative n being left open for >> subclasses. >> >> Thanks, >> >> Brian >> >>> On Oct 25, 2018, at 7:15 AM, Roger Riggs >>> wrote: >>> >>> The FIS skipping past of end of file is puzzling. >>> If the? 'were beyond EOF' was considering the possibility that the >>> file was being >>> extended concurrently with the skip operation then it would not be >>> random, >>> just a normal writer/reader race.? The return value from skip would >>> be accurate >>> and still usable for skipNBytes. >>> >>> If the spec for skipNBytes describes its behavior in terms of the >>> normal behaviors >>> of skip(n) and read(n) then it will not making promises it can't >>> keep regardless of the subclass behavior. >>> >>> FIS also says it can do negative seeks which seems in conflict with >>> InputStream. >>> The FIS.skip(-n) behavior raises the question about whether >>> InputStream.skipNBytes should >>> allow -n? >> > From daniel.fuchs at oracle.com Fri Nov 2 15:38:59 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 2 Nov 2018 15:38:59 +0000 Subject: [12] RFR: 8213301 - Fix legal headers in jdk logging tests Message-ID: <53aca5c7-bc45-aa97-2a1e-17f7c80caf2b@oracle.com> Hi, Following Chris's lead in the network area, and Jon?s lead in the langtools area, here is a change to remove the "Classpath exception? from several test in the test/jdk logging area. 8213301: Fix legal headers in jdk logging tests https://bugs.openjdk.java.net/browse/JDK-8213301 http://cr.openjdk.java.net/~dfuchs/webrev_8213301/webrev/index.html best regards, -- daniel From mandy.chung at oracle.com Fri Nov 2 15:44:20 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 2 Nov 2018 08:44:20 -0700 Subject: Review request: JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported In-Reply-To: <050a45ec-5074-477f-b3c4-b6e1f1814444@oracle.com> References: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> <050a45ec-5074-477f-b3c4-b6e1f1814444@oracle.com> Message-ID: On 11/2/18 3:18 AM, Daniel Fuchs wrote: > Hi Mandy, > > I won't comment on the approach, though [1] looks more > cryptic to me as it includes suspicious native code > changes. > The native code change should have been separated from this fix.? It attempts to remove jdk.internal.misc.Unsafe::getLoadAvg.? I cleaned up and update webrev.01 in place (please reload to check out). > I skimmed through the patch file at > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02/open.patch > > and haven't noticed anything wrong at first sight. > > The changes to java.util.logging & associated tests look fine. > Thanks Mandy > best regards, > > -- daniel > > On 02/11/2018 04:16, Mandy Chung wrote: >> This patch includes the following changes that will reduce the >> number of internal classes made accessible to jdk.unsupported >> module via qualified exports. >> >> 1. move shared secrets to a new jdk.internal.access package. >> >> jdk.internal.misc package has been a dumping ground for various >> kinds of internal APIs and many of which were moved to an appropriate >> package. This is a follow-up clean up that moves the shared secrets >> and JavaXXXAccess interfaces to jdk.internal.access package. >> >> 2. add a wrapper class jdk.internal.misc.FileSystemOption to expose >> sun.nio.fs.ExtendedOptions for com.sun.nio.file to access >> >> This eliminates the qualified exports of sun.nio.fs to jdk.unsupported. >> >> 3. Refactor the implementation of sun.misc.Unsafe::invokeCleaner >> to jdk.internal.misc.Unsafe. >> >> This eliminates the qualified exports of jdk.internal.ref and >> sun.nio.ch to jdk.unsupported. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02 >> >> The change is straight forward although quite many files are modified. >> Majority of the changes is import statement change or test @modules >> change due to the rename. >> >> I ran hs-tier1-3 and jdk-tier1-3 tests. >> >> We considered the alternative to define a wrapper class for everything >> that jdk.unsupported module depends on in a dedicated package >> e.g. jdk.internal.unsupported.? It would need a wrapper for Unsafe, >> Signal, SignalHandler and ExtendedOptions.? It means that it would >> have 3 classes of each - two similar/duplicated implementations >> (one in sun.misc and one in jdk.internal.unsupported) and one >> in jdk.internal.misc ([1] is the prototype).? Only a limited number >> of files are touched but I think the proposed approach is cleaner. >> >> Thanks >> Mandy >> [1] http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.01/ > From chris.hegarty at oracle.com Fri Nov 2 15:56:20 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 2 Nov 2018 15:56:20 +0000 Subject: [12] RFR: 8213301 - Fix legal headers in jdk logging tests In-Reply-To: <53aca5c7-bc45-aa97-2a1e-17f7c80caf2b@oracle.com> References: <53aca5c7-bc45-aa97-2a1e-17f7c80caf2b@oracle.com> Message-ID: <6ADC7F6E-FE66-4DCC-8297-C3B88CFC8C86@oracle.com> > On 2 Nov 2018, at 15:38, Daniel Fuchs wrote: > > Hi, > > Following Chris's lead in the network area, and Jon?s lead > in the langtools area, here is a change to remove the > "Classpath exception? from several test in the > test/jdk logging area. > > 8213301: Fix legal headers in jdk logging tests > https://bugs.openjdk.java.net/browse/JDK-8213301 > > http://cr.openjdk.java.net/~dfuchs/webrev_8213301/webrev/index.html Looks good. -Chris. From Alan.Bateman at oracle.com Fri Nov 2 16:16:07 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Nov 2018 16:16:07 +0000 Subject: Review request: JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported In-Reply-To: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> References: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> Message-ID: On 02/11/2018 04:16, Mandy Chung wrote: > This patch includes the following changes that will reduce the > number of internal classes made accessible to jdk.unsupported > module via qualified exports. > > 1. move shared secrets to a new jdk.internal.access package. > > jdk.internal.misc package has been a dumping ground for various > kinds of internal APIs and many of which were moved to an appropriate > package. This is a follow-up clean up that moves the shared secrets > and JavaXXXAccess interfaces to jdk.internal.access package. > > 2. add a wrapper class jdk.internal.misc.FileSystemOption to expose > sun.nio.fs.ExtendedOptions for com.sun.nio.file to access > > This eliminates the qualified exports of sun.nio.fs to jdk.unsupported. > > 3. Refactor the implementation of sun.misc.Unsafe::invokeCleaner > to jdk.internal.misc.Unsafe. > > This eliminates the qualified exports of jdk.internal.ref and > sun.nio.ch to jdk.unsupported. I skimmed through the changes and I think they are okay. A minor comment on SharedSecrets is that it might be a bit clearer import Unsafe. Also in FileSystemOption there is a typo in the javadoc for the register method, I assume you mean "register as an OpenOption". -Alan From mandy.chung at oracle.com Fri Nov 2 16:21:09 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 2 Nov 2018 09:21:09 -0700 Subject: [12] RFR: 8213301 - Fix legal headers in jdk logging tests In-Reply-To: <53aca5c7-bc45-aa97-2a1e-17f7c80caf2b@oracle.com> References: <53aca5c7-bc45-aa97-2a1e-17f7c80caf2b@oracle.com> Message-ID: Looks good. Mandy On 11/2/18 8:38 AM, Daniel Fuchs wrote: > Hi, > > Following Chris's lead in the network area, and Jon?s lead > in the langtools area, here is a change to remove the > "Classpath exception? from several test in the > test/jdk logging area. > > 8213301: Fix legal headers in jdk logging tests > https://bugs.openjdk.java.net/browse/JDK-8213301 > > http://cr.openjdk.java.net/~dfuchs/webrev_8213301/webrev/index.html > > best regards, > > -- daniel From mandy.chung at oracle.com Fri Nov 2 16:23:47 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 2 Nov 2018 09:23:47 -0700 Subject: Review request: JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported In-Reply-To: References: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> Message-ID: On 11/2/18 9:16 AM, Alan Bateman wrote: > On 02/11/2018 04:16, Mandy Chung wrote: >> This patch includes the following changes that will reduce the >> number of internal classes made accessible to jdk.unsupported >> module via qualified exports. >> >> 1. move shared secrets to a new jdk.internal.access package. >> >> jdk.internal.misc package has been a dumping ground for various >> kinds of internal APIs and many of which were moved to an appropriate >> package. This is a follow-up clean up that moves the shared secrets >> and JavaXXXAccess interfaces to jdk.internal.access package. >> >> 2. add a wrapper class jdk.internal.misc.FileSystemOption to expose >> sun.nio.fs.ExtendedOptions for com.sun.nio.file to access >> >> This eliminates the qualified exports of sun.nio.fs to jdk.unsupported. >> >> 3. Refactor the implementation of sun.misc.Unsafe::invokeCleaner >> to jdk.internal.misc.Unsafe. >> >> This eliminates the qualified exports of jdk.internal.ref and >> sun.nio.ch to jdk.unsupported. > I skimmed through the changes and I think they are okay. > > A minor comment on SharedSecrets is that it might be a bit clearer > import Unsafe. Also in FileSystemOption there is a typo in the javadoc > for the register method, I assume you mean "register as an OpenOption". Fixed in my local repo. Thanks for the review. Mandy From brian.burkhalter at oracle.com Fri Nov 2 16:29:05 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Nov 2018 09:29:05 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> <78433376-a509-f430-e65b-f895b3e39555@oracle.com> <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> Message-ID: <225F4AB3-CB18-47E8-8C5E-19D04B986285@oracle.com> Hi Daniel, > On Nov 2, 2018, at 3:40 AM, Daniel Fuchs wrote: > > If skip(n) returns a negative number, e.g. -1, then you might > end up skipping more than n bytes (unless skip returning > -1 indicates that EOF was reached). I suppose you mean line 571: 571 if (n > 0 && (n -= skip(n)) > 0) { I was assuming that if n > 0, then skip(n) will (usually) return a value in [0,n] although given the weird specification of FIS it might return something in [0,m] where m > n. Perhaps that assumption is wrong. > Basically, I don't think you can make any guarantee of how > many bytes will be skipped if a subclass has an implementation > of skip that misbehave by returning -1 (or any other negative > value). If skip(n) for n > 0 returned a negative value then I would think that would be a subclass bug but then it would still be a problem ... > Maybe there should be some @implSpec note to say that > no guarantee is made if a subclass implementation of > skip() returns non-positive (or non accurate) results? Agreed. Thanks, Brian From brian.burkhalter at oracle.com Fri Nov 2 16:29:42 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Nov 2018 09:29:42 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> <78433376-a509-f430-e65b-f895b3e39555@oracle.com> <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> Message-ID: <24AED235-0964-46C6-9DCE-F25FA4C10B0B@oracle.com> Hi Roger, > On Nov 2, 2018, at 8:03 AM, Roger Riggs wrote: > > The description of this implementation ("the default implementation...") > can be put in an @implSpec tag, since it specifies the behavior of this > method, and is not normative for all subclasses. That will make the 'normal' > behavior of the method easier to understand. Will change. > As Daniel points out, the code should probably be a bit careful about > the return value from skip(n) and add a disclaimer (also in the implSpec). Will change this as well. Thanks, Brian From brian.burkhalter at oracle.com Fri Nov 2 16:53:08 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Nov 2018 09:53:08 -0700 Subject: 8213305: Fix legal headers in test/java/math Message-ID: https://bugs.openjdk.java.net/browse/JDK-8213305 --- a/test/jdk/java/math/BigInteger/PrimeTest.java Fri Nov 02 16:11:29 2018 +0000 +++ b/test/jdk/java/math/BigInteger/PrimeTest.java Fri Nov 02 09:49:34 2018 -0700 @@ -4,9 +4,7 @@ * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. Oracle designates this - * particular file as subject to the "Classpath" exception as provided - * by Oracle in the LICENSE file that accompanied this code. + * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or Thanks, Brian From joe.darcy at oracle.com Fri Nov 2 16:53:57 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 2 Nov 2018 09:53:57 -0700 Subject: 8213305: Fix legal headers in test/java/math In-Reply-To: References: Message-ID: +1 Thanks, -Joe On 11/2/2018 9:53 AM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8213305 > > --- a/test/jdk/java/math/BigInteger/PrimeTest.java Fri Nov 02 16:11:29 2018 +0000 > +++ b/test/jdk/java/math/BigInteger/PrimeTest.java Fri Nov 02 09:49:34 2018 -0700 > @@ -4,9 +4,7 @@ > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > - * published by the Free Software Foundation. Oracle designates this > - * particular file as subject to the "Classpath" exception as provided > - * by Oracle in the LICENSE file that accompanied this code. > + * published by the Free Software Foundation. > * > * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > Thanks, > > Brian From jiangli.zhou at oracle.com Fri Nov 2 17:57:39 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 2 Nov 2018 10:57:39 -0700 Subject: RFR: 8212995: Consider placing the Integer.IntegerCache and cached Integer objects in the closed archive heap region In-Reply-To: <0DF1D50A-CEEF-47FE-ADF2-31E3C2BDBCEC@oracle.com> References: <52c86204-7696-3366-2670-55c097a2397a@oracle.com> <29c6c769-a3bd-b561-bbfd-e3fbaaab6f1b@oracle.com> <87cbf22f-84c8-0b84-b82b-dea27355f9ad@oracle.com> <109ee4a8-9cc1-af39-5c9c-ac3f3e91519e@oracle.com> <7505a5d7-f31f-6dd3-fe96-fb74366579c1@oracle.com> <0DF1D50A-CEEF-47FE-ADF2-31E3C2BDBCEC@oracle.com> Message-ID: Hi Ioi, Here is the updated webrev with the warning message below for the Integer cache. ? http://cr.openjdk.java.net/~jiangli/8212995/webrev.03/ ?995????? * ?996????? * WARNING: The cache is archived with CDS and reloaded from the shared ?997????? * archive at runtime. The archived cache (Integer[]) and Integer objects ?998????? * reside in the closed archive heap regions. Care should be taken when ?999????? * changing the implementation and the cache array should not be assigned 1000????? * with new Integer object(s) after initialization. Including core-lib-dev mailing list since the change now touches the core library file. Thanks, Jiangli On 11/1/18 10:58 PM, Jiangli Zhou wrote: > Hi Ioi, > > >> On Nov 1, 2018, at 9:37 PM, Ioi Lam wrote: >> >> Hi Jiangli, >> >> 576 void HeapShared::check_closed_archive_heap_region_object(InstanceKlass* k, >> 577 Thread* THREAD) { >> 578 // Check fields in the object >> 579 for (JavaFieldStream fs(k); !fs.done(); fs.next()) { >> 580 if (!fs.access_flags().is_static()) { >> 581 BasicType ft = fs.field_descriptor().field_type(); >> 582 if (!fs.access_flags().is_final() && (ft == T_ARRAY || T_OBJECT)) { >> 583 ResourceMark rm(THREAD); >> 584 log_warning(cds, heap)( >> 585 "Please check reference field in %s instance in closed archive heap region: %s %s", >> 586 k->external_name(), (fs.name())->as_C_string(), >> 587 (fs.signature())->as_C_string()); >> 588 } >> 589 } >> 590 } >> 591 } >> >> Checking that all static fields of the affected class (IntegerCache in this case) are final is not enough. The elements of a final array can be modified. > Just to clarify, the above checks all instance fields (non-static fields) in non-array objects. Static fields are not checked as mirrors are not in the closed archive heap region. In the IntegerCache subgraph case, it makes sure there is no non-final reference instance field in cached Integer objects (for future proof). > >> JLS requires that >> https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7 >> If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (?3.10.1), or the boolean literal true or false (?3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (?3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b. >> However, there's no requirement that all these special literal values must be created at system bootstrap time. So it's conceivable that IntegerCache may be rewritten to create the object dynamically: >> >> public static Integer valueOf(int i) { >> if (i >= IntegerCache.low && i <= IntegerCache.high) { >> + if (IntegerCache.cache[i + (-IntegerCache.low)] == null) { >> + IntegerCache.cache[i + (-IntegerCache.low)] = new Integer(i); >> + } >> return IntegerCache.cache[i + (-IntegerCache.low)]; >> } >> return new Integer(i); >> } >> >> Now, is this likely to happen? Probably not. However, in HotSpot, we should not assume that the library will always stay the same, and that the library writer knows what HotSpot requires. > So your suggestion was to add warnings specifically for Integer cache array. Looks like I?ve given it a much deeper interpretation. > > I?ll add a warning about the cache. Will send new webrev tomorrow. > > Thanks, > Jiangli > > >> Thanks >> - Ioi >> >> >> >>> On 11/1/18 3:47 PM, Jiangli Zhou wrote: >>> Hi Ioi, >>> >>> Thanks for the review. I renamed both fields as suggested and added a warning for closed_archive_subgraph_entry_fields. A standalone warning message in Integer.java could be overlooked, so I added HeapShared::check_closed_archive_heap_region_object() for checking the instances being included in the closed archive heap regions at dump time. >>> >>> http://cr.openjdk.java.net/~jiangli/8212995/webrev.02/ >>> >>> Thanks, >>> >>> Jiangli >>> >>> >>>> On 10/31/18 8:52 PM, Ioi Lam wrote: >>>> Hi Jiangli, >>>> >>>> static ArchivableStaticFieldInfo shareable_subgraph_entry_fields[] = {...} >>>> static ArchivableStaticFieldInfo subgraph_entry_fields[] = {...} >>>> >>>> Maybe these should be renamed to {open/closed}_archive_subgraph_entry_fields? >>>> >>>> Also, I think we should add a strong warning about what objects can be placed in closed_archive_subgraph_entry_fields[]. Any references stored in these objects must not be modified at run time (or else we could have a pointer that from the closed region to the outside, violating the properties of the closed region. >>>> >>>> Maybe we should also add a warning in Integer.java, something akin to "if you modify this class, check to see if it can still meet the requirements in heapShared.cpp"? >>>> >>>> The rest of the code seems OK to me. >>>> >>>> As a future improvement, for all the objects whose fields are all non-reference, final fields, maybe we can automatically put them in the closed archive region? For example, all archived primitive box objects are in this category. >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> On 10/31/18 12:45 PM, Jiangli Zhou wrote: >>>>> On 10/31/18 12:08 PM, Jiangli Zhou wrote: >>>>> >>>>>> Hi Ioi, >>>>>> >>>>>> Here is an updated webrev with renaming of the 'is_shared' argument. I decided to go with your suggestion, 'is_closed_archive'. >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/8212995/webrev.01/ >>>>> BTW, in above webrev, I also included a typo fix for the following warning that Mandy found (thanks Mandy!) >>>>> >>>>> @@ -1324,11 +1329,11 @@ >>>>> // header data >>>>> const char* prop = Arguments::get_property("java.system.class.loader"); >>>>> if (prop != NULL) { >>>>> warning("Archived non-system classes are disabled because the " >>>>> "java.system.class.loader property is specified (value = \"%s\"). " >>>>> - "To use archived non-system classes, this property must be not be set", prop); >>>>> + "To use archived non-system classes, this property must not be set", prop); >>>>> _has_platform_or_app_classes = false; >>>>> } >>>>> >>>>> Thanks, >>>>> Jiangli >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>>>> >>>>>>> On 10/30/18 4:19 PM, Jiangli Zhou wrote: >>>>>>> Hi Ioi, >>>>>>> >>>>>>> On 10/30/18 3:00 PM, Ioi Lam wrote: >>>>>>> >>>>>>>> Hi Jiangli, >>>>>>>> >>>>>>>> This looks promising. >>>>>>>> >>>>>>>> Now a full review yet, but I am wondering about the name of the is_shared parameter >>>>>>>> >>>>>>>> void add_subgraph_entry_field(int static_field_offset, oop v, bool is_shared); >>>>>>>> >>>>>>>> Since this is part of "heapShared", everything is "shared" in some sense of the word. It could be confusing to say something is more shared than other things which also shared ... >>>>>>>> >>>>>>>> How "is_closed_archive" instead? >>>>>>> Yes, our 'shared' has broader meaning. "is_closed_archive" or "is_closed_space" sounds good to me. I'll rename. >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>>> Thanks >>>>>>>> - Ioi >>>>>>>> >>>>>>>> >>>>>>>>> On 10/30/2018 01:57 PM, Jiangli Zhou wrote: >>>>>>>>> Please review the following change for moving the archived Integer.IntegerCache and it's cached Integer objects (256) to the closed archiving heap region. The IntegerCache subgraph does not contain any reference that's changed at runtime (good candidate for sharing). Moving the whole subgraph into the closed archive heap region allows the memory to be shared by different JVM instances at runtime. The saving is 4K per JVM instance running the same or different java application simultaneously. Although 4K is not significant, in a larger picture the saving is much bigger (4k * (JVM_instance_num - 1) * host_num). >>>>>>>>> >>>>>>>>> As part of the change, I also restructured the code to allow us to plug in more shareable subgraphs in the closed archive heap region for runtime footprint saving in the future. >>>>>>>>> >>>>>>>>> The 'st' space is renamed to 'ca' (closed archive) space since it now contains other types of objects besides j.l.Strings. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8212995/webrev.00/ >>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8212995 >>>>>>>>> >>>>>>>>> Before: >>>>>>>>> >>>>>>>>> mc space: 8416 [ 0.0% of total] out of 12288 bytes [ 68.5% used] at 0x0000000800000000 >>>>>>>>> rw space: 3946640 [ 21.4% of total] out of 3948544 bytes [100.0% used] at 0x0000000800003000 >>>>>>>>> ro space: 7319328 [ 39.6% of total] out of 7319552 bytes [100.0% used] at 0x00000008003c7000 >>>>>>>>> md space: 2416 [ 0.0% of total] out of 4096 bytes [ 59.0% used] at 0x0000000800ac2000 >>>>>>>>> od space: 6475944 [ 35.0% of total] out of 6479872 bytes [ 99.9% used] at 0x0000000800ac3000 >>>>>>>>> st0 space: 438272 [ 2.4% of total] out of 438272 bytes [100.0% used] at 0x00000007ffc00000 <<<<<<<<<< >>>>>>>>> oa0 space: 282624 [ 1.5% of total] out of 282624 bytes [100.0% used] at 0x00000007ff800000 <<<<<<<<<< >>>>>>>>> total : 18473640 [100.0% of total] out of 18485248 bytes [ 99.9% used] >>>>>>>>> >>>>>>>>> After: >>>>>>>>> >>>>>>>>> mc space: 8416 [ 0.0% of total] out of 12288 bytes [ 68.5% used] at 0x0000000800000000 >>>>>>>>> rw space: 3946640 [ 21.4% of total] out of 3948544 bytes [100.0% used] at 0x0000000800003000 >>>>>>>>> ro space: 7319304 [ 39.6% of total] out of 7319552 bytes [100.0% used] at 0x00000008003c7000 >>>>>>>>> md space: 2416 [ 0.0% of total] out of 4096 bytes [ 59.0% used] at 0x0000000800ac2000 >>>>>>>>> od space: 6475920 [ 35.0% of total] out of 6479872 bytes [ 99.9% used] at 0x0000000800ac3000 >>>>>>>>> ca0 space: 442368 [ 2.4% of total] out of 442368 bytes [100.0% used] at 0x00000007ffc00000 <<<<<<<<<< >>>>>>>>> oa0 space: 278528 [ 1.5% of total] out of 278528 bytes [100.0% used] at 0x00000007ff800000 <<<<<<<<<< >>>>>>>>> total : 18473592 [100.0% of total] out of 18485248 bytes [ 99.9% used] >>>>>>>>> >>>>>>>>> Tested with appcds tests on linux-x64 locally. Running tier1-teir4 tests. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Jiangli From huizhe.wang at oracle.com Fri Nov 2 19:13:22 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 02 Nov 2018 12:13:22 -0700 Subject: 8213321: Fix legal headers in test/jaxp Message-ID: <5BDCA1D2.1050307@oracle.com> Hi, Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8213321 Changes: --- a/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java +++ b/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java @@ -4,9 +4,7 @@ * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. Oracle designates this - * particular file as subject to the "Classpath" exception as provided - * by Oracle in the LICENSE file that accompanied this code. + * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or Thanks, Joe From joe.darcy at oracle.com Fri Nov 2 19:16:54 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 02 Nov 2018 12:16:54 -0700 Subject: 8213321: Fix legal headers in test/jaxp In-Reply-To: <5BDCA1D2.1050307@oracle.com> References: <5BDCA1D2.1050307@oracle.com> Message-ID: <5BDCA2A6.5040900@oracle.com> +1 Cheers, -Joe On 11/2/2018 12:13 PM, Joe Wang wrote: > Hi, > > Please review: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213321 > > Changes: > --- > a/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java > +++ > b/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java > @@ -4,9 +4,7 @@ > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > - * published by the Free Software Foundation. Oracle designates this > - * particular file as subject to the "Classpath" exception as provided > - * by Oracle in the LICENSE file that accompanied this code. > + * published by the Free Software Foundation. > * > * This code is distributed in the hope that it will be useful, but > WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > Thanks, > Joe From jonathan.gibbons at oracle.com Fri Nov 2 19:17:02 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 2 Nov 2018 12:17:02 -0700 Subject: 8213321: Fix legal headers in test/jaxp In-Reply-To: <5BDCA1D2.1050307@oracle.com> References: <5BDCA1D2.1050307@oracle.com> Message-ID: +1 On 11/02/2018 12:13 PM, Joe Wang wrote: > Hi, > > Please review: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213321 > > Changes: > --- > a/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java > +++ > b/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java > @@ -4,9 +4,7 @@ > ? * > ? * This code is free software; you can redistribute it and/or modify it > ? * under the terms of the GNU General Public License version 2 only, as > - * published by the Free Software Foundation.? Oracle designates this > - * particular file as subject to the "Classpath" exception as provided > - * by Oracle in the LICENSE file that accompanied this code. > + * published by the Free Software Foundation. > ? * > ? * This code is distributed in the hope that it will be useful, but > WITHOUT > ? * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > Thanks, > Joe From Lance.Andersen at oracle.com Fri Nov 2 19:17:59 2018 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Fri, 2 Nov 2018 15:17:59 -0400 Subject: 8213321: Fix legal headers in test/jaxp In-Reply-To: <5BDCA1D2.1050307@oracle.com> References: <5BDCA1D2.1050307@oracle.com> Message-ID: +1 -- 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 Sent from my iPhone > On Nov 2, 2018, at 3:13 PM, Joe Wang wrote: > > Hi, > > Please review: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213321 > > Changes: > --- a/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java > +++ b/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java > @@ -4,9 +4,7 @@ > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > - * published by the Free Software Foundation. Oracle designates this > - * particular file as subject to the "Classpath" exception as provided > - * by Oracle in the LICENSE file that accompanied this code. > + * published by the Free Software Foundation. > * > * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > Thanks, > Joe From huizhe.wang at oracle.com Fri Nov 2 19:39:50 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 02 Nov 2018 12:39:50 -0700 Subject: 8213321: Fix legal headers in test/jaxp In-Reply-To: References: <5BDCA1D2.1050307@oracle.com> Message-ID: <5BDCA806.8070601@oracle.com> Thanks all! On 11/2/18, 12:17 PM, Lance Andersen wrote: > +1 > > -- > > 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 > > Sent from my iPhone > > On Nov 2, 2018, at 3:13 PM, Joe Wang > wrote: > >> Hi, >> >> Please review: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8213321 >> >> Changes: >> --- >> a/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java >> +++ >> b/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java >> @@ -4,9 +4,7 @@ >> * >> * This code is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License version 2 only, as >> - * published by the Free Software Foundation. Oracle designates this >> - * particular file as subject to the "Classpath" exception as provided >> - * by Oracle in the LICENSE file that accompanied this code. >> + * published by the Free Software Foundation. >> * >> * This code is distributed in the hope that it will be useful, but >> WITHOUT >> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> >> Thanks, >> Joe From mandy.chung at oracle.com Fri Nov 2 20:55:29 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 2 Nov 2018 13:55:29 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: Hi Dean, I reviewed webrev.4 version.? It looks good.? Happy to see moving the doPrivileged support to Java and the performance improvement. On 10/31/18 3:23 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java. This > gives a performance improvement while also being useful to Project > Loom by removing the Java --> native --> Java transition.? One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns.? To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk.? This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method > returns. > Tested with tier1-tier3 hotspot and jdk tests and JCK > api/java_security tests.? For the first few rounds of testing, I kept > the old native privileged stack and compared the results of the old > and new implementations for each getContext call, which did catch some > early bugs.? The changes were also examined by internal security > experts and run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate > 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > FYI.? Sean and I also did some experiment to replace JVM_GetStackAccessControlContext with StackWalker some time ago. Another potential area to move the code from VM to Java for the future as David explored and probably involves? performance work in the stack walker. Mandy From dean.long at oracle.com Fri Nov 2 21:09:45 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 2 Nov 2018 14:09:45 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: Thanks Mandy.? I also appreciate you noticing (off-list) that I can remove the extra space in "Class " in several places.? I have updated webrev.4 in place. dl On 11/2/18 1:55 PM, Mandy Chung wrote: > Hi Dean, > > I reviewed webrev.4 version.? It looks good.? Happy to see moving the > doPrivileged support to Java and the performance improvement. > > On 10/31/18 3:23 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project >> Loom by removing the Java --> native --> Java transition.? One reason >> doPrivileged has historically been in native is because of the need >> to guarantee the cleanup of the privileged context when doPrivileged >> returns.? To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk.? This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method >> returns. >> Tested with tier1-tier3 hotspot and jdk tests and JCK >> api/java_security tests.? For the first few rounds of testing, I kept >> the old native privileged stack and compared the results of the old >> and new implementations for each getContext call, which did catch >> some early bugs.? The changes were also examined by internal security >> experts and run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is >> approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here >> [2]. >> > > FYI.? Sean and I also did some experiment to replace > JVM_GetStackAccessControlContext with StackWalker some time ago. > Another potential area to move the code from VM to Java for the future > as David explored and probably involves? performance work in the stack > walker. > > Mandy From naoto.sato at oracle.com Sat Nov 3 00:10:17 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 2 Nov 2018 17:10:17 -0700 Subject: [12] RFR: 8213330: Fix legal headers in i18n tests Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8213330 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8213330/webrev.00/ It is to remove "Classpath exception" copyright phrase from i18n related test files. Naoto From ioi.lam at oracle.com Sat Nov 3 00:15:52 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 2 Nov 2018 17:15:52 -0700 Subject: RFR: 8212995: Consider placing the Integer.IntegerCache and cached Integer objects in the closed archive heap region In-Reply-To: References: <52c86204-7696-3366-2670-55c097a2397a@oracle.com> <29c6c769-a3bd-b561-bbfd-e3fbaaab6f1b@oracle.com> <87cbf22f-84c8-0b84-b82b-dea27355f9ad@oracle.com> <109ee4a8-9cc1-af39-5c9c-ac3f3e91519e@oracle.com> <7505a5d7-f31f-6dd3-fe96-fb74366579c1@oracle.com> <0DF1D50A-CEEF-47FE-ADF2-31E3C2BDBCEC@oracle.com> Message-ID: <9fc108f6-dbc1-4ee0-0488-46614cd38ca2@oracle.com> Hi Jiangli, This looks good to me. Ship it! Thanks - Ioi On 11/2/18 10:57 AM, Jiangli Zhou wrote: > Hi Ioi, > > Here is the updated webrev with the warning message below for the > Integer cache. > > ? http://cr.openjdk.java.net/~jiangli/8212995/webrev.03/ > > ?995????? * > ?996????? * WARNING: The cache is archived with CDS and reloaded from > the shared > ?997????? * archive at runtime. The archived cache (Integer[]) and > Integer objects > ?998????? * reside in the closed archive heap regions. Care should be > taken when > ?999????? * changing the implementation and the cache array should not > be assigned > 1000????? * with new Integer object(s) after initialization. > > Including core-lib-dev mailing list since the change now touches the > core library file. > > Thanks, > Jiangli > > > On 11/1/18 10:58 PM, Jiangli Zhou wrote: >> Hi Ioi, >> >> >>> On Nov 1, 2018, at 9:37 PM, Ioi Lam wrote: >>> >>> Hi Jiangli, >>> >>> ? 576 void >>> HeapShared::check_closed_archive_heap_region_object(InstanceKlass* k, >>> ? 577 Thread* THREAD) { >>> ? 578?? // Check fields in the object >>> ? 579?? for (JavaFieldStream fs(k); !fs.done(); fs.next()) { >>> ? 580???? if (!fs.access_flags().is_static()) { >>> ? 581?????? BasicType ft = fs.field_descriptor().field_type(); >>> ? 582?????? if (!fs.access_flags().is_final() && (ft == T_ARRAY || >>> T_OBJECT)) { >>> ? 583???????? ResourceMark rm(THREAD); >>> ? 584???????? log_warning(cds, heap)( >>> ? 585?????????? "Please check reference field in %s instance in >>> closed archive heap region: %s %s", >>> ? 586?????????? k->external_name(), (fs.name())->as_C_string(), >>> ? 587?????????? (fs.signature())->as_C_string()); >>> ? 588?????? } >>> ? 589???? } >>> ? 590?? } >>> ? 591 } >>> >>> Checking that all static fields of the affected class (IntegerCache >>> in this case) are final is not enough. The elements of a final array >>> can be modified. >> Just to clarify, the above checks all instance fields (non-static >> fields) in non-array objects. Static fields are not checked as >> mirrors are not in the closed archive heap region. In the >> IntegerCache subgraph case, it makes sure there is no non-final >> reference instance field in cached Integer objects (for future proof). >>> JLS requires that >>> https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7 >>> If the value p being boxed is an integer literal of type int between >>> -128 and 127 inclusive (?3.10.1), or the boolean literal true or >>> false (?3.10.3), or a character literal between '\u0000' and >>> '\u007f' inclusive (?3.10.4), then let a and b be the results of any >>> two boxing conversions of p. It is always the case that a == b. >>> However, there's no requirement that all these special literal >>> values must be created at system bootstrap time. So it's conceivable >>> that IntegerCache may be rewritten to create the object dynamically: >>> >>> ?? public static Integer valueOf(int i) { >>> ?????? if (i >= IntegerCache.low && i <= IntegerCache.high) { >>> +?????? if (IntegerCache.cache[i + (-IntegerCache.low)] == null) { >>> +???????? IntegerCache.cache[i + (-IntegerCache.low)] = new Integer(i); >>> +?????? } >>> ???????? return IntegerCache.cache[i + (-IntegerCache.low)]; >>> ?????? } >>> ?????? return new Integer(i); >>> ?? } >>> >>> Now, is this likely to happen? Probably not. However, in HotSpot, we >>> should not assume that the library will always stay the same, and >>> that the library writer knows what HotSpot requires. >> So your suggestion was to add warnings specifically for Integer cache >> array. Looks like I?ve given it a much deeper interpretation. >> >> I?ll add a warning about the cache. Will send new webrev tomorrow. >> >> Thanks, >> Jiangli >> >> >>> Thanks >>> - Ioi >>> >>> >>> >>>> On 11/1/18 3:47 PM, Jiangli Zhou wrote: >>>> Hi Ioi, >>>> >>>> Thanks for the review. I renamed both fields as suggested and added >>>> a warning for closed_archive_subgraph_entry_fields. A standalone >>>> warning message in Integer.java could be overlooked, so I added >>>> HeapShared::check_closed_archive_heap_region_object() for checking >>>> the instances being included in the closed archive heap regions at >>>> dump time. >>>> >>>> http://cr.openjdk.java.net/~jiangli/8212995/webrev.02/ >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>>> >>>>> On 10/31/18 8:52 PM, Ioi Lam wrote: >>>>> Hi Jiangli, >>>>> >>>>> static ArchivableStaticFieldInfo shareable_subgraph_entry_fields[] >>>>> = {...} >>>>> static ArchivableStaticFieldInfo subgraph_entry_fields[] = {...} >>>>> >>>>> Maybe these should be renamed to >>>>> {open/closed}_archive_subgraph_entry_fields? >>>>> >>>>> Also, I think we should add a strong warning about what objects >>>>> can be placed in closed_archive_subgraph_entry_fields[]. Any >>>>> references stored in these objects must not be modified at run >>>>> time (or else we could have a pointer that from the closed region >>>>> to the outside, violating the properties of the closed region. >>>>> >>>>> Maybe we should also add a warning in Integer.java, something akin >>>>> to "if you modify this class, check to see if it can still meet >>>>> the requirements in heapShared.cpp"? >>>>> >>>>> The rest of the code seems OK to me. >>>>> >>>>> As a future improvement, for all the objects whose fields are all >>>>> non-reference, final fields, maybe we can automatically put them >>>>> in the closed archive region? For example, all archived primitive >>>>> box objects are in this category. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>>> On 10/31/18 12:45 PM, Jiangli Zhou wrote: >>>>>> On 10/31/18 12:08 PM, Jiangli Zhou wrote: >>>>>> >>>>>>> Hi Ioi, >>>>>>> >>>>>>> Here is an updated webrev with renaming of the 'is_shared' >>>>>>> argument. I decided to go with your suggestion, >>>>>>> 'is_closed_archive'. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jiangli/8212995/webrev.01/ >>>>>> BTW, in above webrev, I also included a typo fix for the >>>>>> following warning that Mandy found (thanks Mandy!) >>>>>> >>>>>> @@ -1324,11 +1329,11 @@ >>>>>> ??? // header data >>>>>> ??? const char* prop = >>>>>> Arguments::get_property("java.system.class.loader"); >>>>>> ??? if (prop != NULL) { >>>>>> ????? warning("Archived non-system classes are disabled because >>>>>> the " >>>>>> ????????????? "java.system.class.loader property is specified >>>>>> (value = \"%s\"). " >>>>>> -??????????? "To use archived non-system classes, this property >>>>>> must be not be set", prop); >>>>>> +??????????? "To use archived non-system classes, this property >>>>>> must not be set", prop); >>>>>> ????? _has_platform_or_app_classes = false; >>>>>> ??? } >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>>> Thanks, >>>>>>> >>>>>>> Jiangli >>>>>>> >>>>>>> >>>>>>>> On 10/30/18 4:19 PM, Jiangli Zhou wrote: >>>>>>>> Hi Ioi, >>>>>>>> >>>>>>>> On 10/30/18 3:00 PM, Ioi Lam wrote: >>>>>>>> >>>>>>>>> Hi Jiangli, >>>>>>>>> >>>>>>>>> This looks promising. >>>>>>>>> >>>>>>>>> Now a full review yet, but I am wondering about the name of >>>>>>>>> the is_shared parameter >>>>>>>>> >>>>>>>>> ?? void add_subgraph_entry_field(int static_field_offset, oop >>>>>>>>> v, bool is_shared); >>>>>>>>> >>>>>>>>> Since this is part of "heapShared", everything is "shared" in >>>>>>>>> some sense of the word. It could be confusing to say something >>>>>>>>> is more shared than other things which also shared ... >>>>>>>>> >>>>>>>>> How "is_closed_archive" instead? >>>>>>>> Yes, our 'shared' has broader meaning. "is_closed_archive" or >>>>>>>> "is_closed_space" sounds good to me. I'll rename. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jiangli >>>>>>>>> Thanks >>>>>>>>> - Ioi >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 10/30/2018 01:57 PM, Jiangli Zhou wrote: >>>>>>>>>> Please review the following change for moving the archived >>>>>>>>>> Integer.IntegerCache and it's cached Integer objects (256) to >>>>>>>>>> the closed archiving heap region. The IntegerCache subgraph >>>>>>>>>> does not contain any reference that's changed at runtime >>>>>>>>>> (good candidate for sharing). Moving the whole subgraph into >>>>>>>>>> the closed archive heap region allows the memory to be shared >>>>>>>>>> by different JVM instances at runtime. The saving is 4K per >>>>>>>>>> JVM instance running the same or different java application >>>>>>>>>> simultaneously. Although 4K is not significant, in a larger >>>>>>>>>> picture the saving is much bigger (4k * (JVM_instance_num - >>>>>>>>>> 1) * host_num). >>>>>>>>>> >>>>>>>>>> As part of the change, I also restructured the code to allow >>>>>>>>>> us to plug in more shareable subgraphs in the closed archive >>>>>>>>>> heap region for runtime footprint saving in the future. >>>>>>>>>> >>>>>>>>>> The 'st' space is renamed to 'ca' (closed archive) space >>>>>>>>>> since it now contains other types of objects besides >>>>>>>>>> j.l.Strings. >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8212995/webrev.00/ >>>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8212995 >>>>>>>>>> >>>>>>>>>> Before: >>>>>>>>>> >>>>>>>>>> mc? space:????? 8416 [? 0.0% of total] out of???? 12288 bytes >>>>>>>>>> [ 68.5% used] at 0x0000000800000000 >>>>>>>>>> rw? space:?? 3946640 [ 21.4% of total] out of 3948544 bytes >>>>>>>>>> [100.0% used] at 0x0000000800003000 >>>>>>>>>> ro? space:?? 7319328 [ 39.6% of total] out of 7319552 bytes >>>>>>>>>> [100.0% used] at 0x00000008003c7000 >>>>>>>>>> md? space:????? 2416 [? 0.0% of total] out of????? 4096 bytes >>>>>>>>>> [ 59.0% used] at 0x0000000800ac2000 >>>>>>>>>> od? space:?? 6475944 [ 35.0% of total] out of 6479872 bytes [ >>>>>>>>>> 99.9% used] at 0x0000000800ac3000 >>>>>>>>>> st0 space:??? 438272 [? 2.4% of total] out of 438272 bytes >>>>>>>>>> [100.0% used] at 0x00000007ffc00000 <<<<<<<<<< >>>>>>>>>> oa0 space:??? 282624 [? 1.5% of total] out of 282624 bytes >>>>>>>>>> [100.0% used] at 0x00000007ff800000 <<<<<<<<<< >>>>>>>>>> total??? :? 18473640 [100.0% of total] out of 18485248 bytes >>>>>>>>>> [ 99.9% used] >>>>>>>>>> >>>>>>>>>> After: >>>>>>>>>> >>>>>>>>>> mc? space:????? 8416 [? 0.0% of total] out of???? 12288 bytes >>>>>>>>>> [ 68.5% used] at 0x0000000800000000 >>>>>>>>>> rw? space:?? 3946640 [ 21.4% of total] out of 3948544 bytes >>>>>>>>>> [100.0% used] at 0x0000000800003000 >>>>>>>>>> ro? space:?? 7319304 [ 39.6% of total] out of 7319552 bytes >>>>>>>>>> [100.0% used] at 0x00000008003c7000 >>>>>>>>>> md? space:????? 2416 [? 0.0% of total] out of????? 4096 bytes >>>>>>>>>> [ 59.0% used] at 0x0000000800ac2000 >>>>>>>>>> od? space:?? 6475920 [ 35.0% of total] out of 6479872 bytes [ >>>>>>>>>> 99.9% used] at 0x0000000800ac3000 >>>>>>>>>> ca0 space:??? 442368 [? 2.4% of total] out of 442368 bytes >>>>>>>>>> [100.0% used] at 0x00000007ffc00000 <<<<<<<<<< >>>>>>>>>> oa0 space:??? 278528 [? 1.5% of total] out of 278528 bytes >>>>>>>>>> [100.0% used] at 0x00000007ff800000 <<<<<<<<<< >>>>>>>>>> total??? :? 18473592 [100.0% of total] out of 18485248 bytes >>>>>>>>>> [ 99.9% used] >>>>>>>>>> >>>>>>>>>> Tested with appcds tests on linux-x64 locally. Running >>>>>>>>>> tier1-teir4 tests. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Jiangli > From jiangli.zhou at oracle.com Sat Nov 3 00:16:46 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 2 Nov 2018 17:16:46 -0700 Subject: RFR: 8212995: Consider placing the Integer.IntegerCache and cached Integer objects in the closed archive heap region In-Reply-To: <9fc108f6-dbc1-4ee0-0488-46614cd38ca2@oracle.com> References: <52c86204-7696-3366-2670-55c097a2397a@oracle.com> <29c6c769-a3bd-b561-bbfd-e3fbaaab6f1b@oracle.com> <87cbf22f-84c8-0b84-b82b-dea27355f9ad@oracle.com> <109ee4a8-9cc1-af39-5c9c-ac3f3e91519e@oracle.com> <7505a5d7-f31f-6dd3-fe96-fb74366579c1@oracle.com> <0DF1D50A-CEEF-47FE-ADF2-31E3C2BDBCEC@oracle.com> <9fc108f6-dbc1-4ee0-0488-46614cd38ca2@oracle.com> Message-ID: <774c5a50-fe99-e8f6-e165-2d3f36b62fb6@oracle.com> Thanks! Jiangli On 11/2/18 5:15 PM, Ioi Lam wrote: > Hi Jiangli, > > This looks good to me. Ship it! > > Thanks > > - Ioi > > > On 11/2/18 10:57 AM, Jiangli Zhou wrote: >> Hi Ioi, >> >> Here is the updated webrev with the warning message below for the >> Integer cache. >> >> ? http://cr.openjdk.java.net/~jiangli/8212995/webrev.03/ >> >> ?995????? * >> ?996????? * WARNING: The cache is archived with CDS and reloaded from >> the shared >> ?997????? * archive at runtime. The archived cache (Integer[]) and >> Integer objects >> ?998????? * reside in the closed archive heap regions. Care should be >> taken when >> ?999????? * changing the implementation and the cache array should >> not be assigned >> 1000????? * with new Integer object(s) after initialization. >> >> Including core-lib-dev mailing list since the change now touches the >> core library file. >> >> Thanks, >> Jiangli >> >> >> On 11/1/18 10:58 PM, Jiangli Zhou wrote: >>> Hi Ioi, >>> >>> >>>> On Nov 1, 2018, at 9:37 PM, Ioi Lam wrote: >>>> >>>> Hi Jiangli, >>>> >>>> ? 576 void >>>> HeapShared::check_closed_archive_heap_region_object(InstanceKlass* k, >>>> ? 577 Thread* THREAD) { >>>> ? 578?? // Check fields in the object >>>> ? 579?? for (JavaFieldStream fs(k); !fs.done(); fs.next()) { >>>> ? 580???? if (!fs.access_flags().is_static()) { >>>> ? 581?????? BasicType ft = fs.field_descriptor().field_type(); >>>> ? 582?????? if (!fs.access_flags().is_final() && (ft == T_ARRAY || >>>> T_OBJECT)) { >>>> ? 583???????? ResourceMark rm(THREAD); >>>> ? 584???????? log_warning(cds, heap)( >>>> ? 585?????????? "Please check reference field in %s instance in >>>> closed archive heap region: %s %s", >>>> ? 586?????????? k->external_name(), (fs.name())->as_C_string(), >>>> ? 587?????????? (fs.signature())->as_C_string()); >>>> ? 588?????? } >>>> ? 589???? } >>>> ? 590?? } >>>> ? 591 } >>>> >>>> Checking that all static fields of the affected class (IntegerCache >>>> in this case) are final is not enough. The elements of a final >>>> array can be modified. >>> Just to clarify, the above checks all instance fields (non-static >>> fields) in non-array objects. Static fields are not checked as >>> mirrors are not in the closed archive heap region. In the >>> IntegerCache subgraph case, it makes sure there is no non-final >>> reference instance field in cached Integer objects (for future proof). >>>> JLS requires that >>>> https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7 >>>> If the value p being boxed is an integer literal of type int >>>> between -128 and 127 inclusive (?3.10.1), or the boolean literal >>>> true or false (?3.10.3), or a character literal between '\u0000' >>>> and '\u007f' inclusive (?3.10.4), then let a and b be the results >>>> of any two boxing conversions of p. It is always the case that a == b. >>>> However, there's no requirement that all these special literal >>>> values must be created at system bootstrap time. So it's >>>> conceivable that IntegerCache may be rewritten to create the object >>>> dynamically: >>>> >>>> ?? public static Integer valueOf(int i) { >>>> ?????? if (i >= IntegerCache.low && i <= IntegerCache.high) { >>>> +?????? if (IntegerCache.cache[i + (-IntegerCache.low)] == null) { >>>> +???????? IntegerCache.cache[i + (-IntegerCache.low)] = new >>>> Integer(i); >>>> +?????? } >>>> ???????? return IntegerCache.cache[i + (-IntegerCache.low)]; >>>> ?????? } >>>> ?????? return new Integer(i); >>>> ?? } >>>> >>>> Now, is this likely to happen? Probably not. However, in HotSpot, >>>> we should not assume that the library will always stay the same, >>>> and that the library writer knows what HotSpot requires. >>> So your suggestion was to add warnings specifically for Integer >>> cache array. Looks like I?ve given it a much deeper interpretation. >>> >>> I?ll add a warning about the cache. Will send new webrev tomorrow. >>> >>> Thanks, >>> Jiangli >>> >>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> >>>>> On 11/1/18 3:47 PM, Jiangli Zhou wrote: >>>>> Hi Ioi, >>>>> >>>>> Thanks for the review. I renamed both fields as suggested and >>>>> added a warning for closed_archive_subgraph_entry_fields. A >>>>> standalone warning message in Integer.java could be overlooked, so >>>>> I added HeapShared::check_closed_archive_heap_region_object() for >>>>> checking the instances being included in the closed archive heap >>>>> regions at dump time. >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/8212995/webrev.02/ >>>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>>>> >>>>> >>>>>> On 10/31/18 8:52 PM, Ioi Lam wrote: >>>>>> Hi Jiangli, >>>>>> >>>>>> static ArchivableStaticFieldInfo >>>>>> shareable_subgraph_entry_fields[] = {...} >>>>>> static ArchivableStaticFieldInfo subgraph_entry_fields[] = {...} >>>>>> >>>>>> Maybe these should be renamed to >>>>>> {open/closed}_archive_subgraph_entry_fields? >>>>>> >>>>>> Also, I think we should add a strong warning about what objects >>>>>> can be placed in closed_archive_subgraph_entry_fields[]. Any >>>>>> references stored in these objects must not be modified at run >>>>>> time (or else we could have a pointer that from the closed region >>>>>> to the outside, violating the properties of the closed region. >>>>>> >>>>>> Maybe we should also add a warning in Integer.java, something >>>>>> akin to "if you modify this class, check to see if it can still >>>>>> meet the requirements in heapShared.cpp"? >>>>>> >>>>>> The rest of the code seems OK to me. >>>>>> >>>>>> As a future improvement, for all the objects whose fields are all >>>>>> non-reference, final fields, maybe we can automatically put them >>>>>> in the closed archive region? For example, all archived primitive >>>>>> box objects are in this category. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>>> On 10/31/18 12:45 PM, Jiangli Zhou wrote: >>>>>>> On 10/31/18 12:08 PM, Jiangli Zhou wrote: >>>>>>> >>>>>>>> Hi Ioi, >>>>>>>> >>>>>>>> Here is an updated webrev with renaming of the 'is_shared' >>>>>>>> argument. I decided to go with your suggestion, >>>>>>>> 'is_closed_archive'. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~jiangli/8212995/webrev.01/ >>>>>>> BTW, in above webrev, I also included a typo fix for the >>>>>>> following warning that Mandy found (thanks Mandy!) >>>>>>> >>>>>>> @@ -1324,11 +1329,11 @@ >>>>>>> ??? // header data >>>>>>> ??? const char* prop = >>>>>>> Arguments::get_property("java.system.class.loader"); >>>>>>> ??? if (prop != NULL) { >>>>>>> ????? warning("Archived non-system classes are disabled because >>>>>>> the " >>>>>>> ????????????? "java.system.class.loader property is specified >>>>>>> (value = \"%s\"). " >>>>>>> -??????????? "To use archived non-system classes, this property >>>>>>> must be not be set", prop); >>>>>>> +??????????? "To use archived non-system classes, this property >>>>>>> must not be set", prop); >>>>>>> ????? _has_platform_or_app_classes = false; >>>>>>> ??? } >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jiangli >>>>>>>> >>>>>>>> >>>>>>>>> On 10/30/18 4:19 PM, Jiangli Zhou wrote: >>>>>>>>> Hi Ioi, >>>>>>>>> >>>>>>>>> On 10/30/18 3:00 PM, Ioi Lam wrote: >>>>>>>>> >>>>>>>>>> Hi Jiangli, >>>>>>>>>> >>>>>>>>>> This looks promising. >>>>>>>>>> >>>>>>>>>> Now a full review yet, but I am wondering about the name of >>>>>>>>>> the is_shared parameter >>>>>>>>>> >>>>>>>>>> ?? void add_subgraph_entry_field(int static_field_offset, oop >>>>>>>>>> v, bool is_shared); >>>>>>>>>> >>>>>>>>>> Since this is part of "heapShared", everything is "shared" in >>>>>>>>>> some sense of the word. It could be confusing to say >>>>>>>>>> something is more shared than other things which also shared ... >>>>>>>>>> >>>>>>>>>> How "is_closed_archive" instead? >>>>>>>>> Yes, our 'shared' has broader meaning. "is_closed_archive" or >>>>>>>>> "is_closed_space" sounds good to me. I'll rename. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jiangli >>>>>>>>>> Thanks >>>>>>>>>> - Ioi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 10/30/2018 01:57 PM, Jiangli Zhou wrote: >>>>>>>>>>> Please review the following change for moving the archived >>>>>>>>>>> Integer.IntegerCache and it's cached Integer objects (256) >>>>>>>>>>> to the closed archiving heap region. The IntegerCache >>>>>>>>>>> subgraph does not contain any reference that's changed at >>>>>>>>>>> runtime (good candidate for sharing). Moving the whole >>>>>>>>>>> subgraph into the closed archive heap region allows the >>>>>>>>>>> memory to be shared by different JVM instances at runtime. >>>>>>>>>>> The saving is 4K per JVM instance running the same or >>>>>>>>>>> different java application simultaneously. Although 4K is >>>>>>>>>>> not significant, in a larger picture the saving is much >>>>>>>>>>> bigger (4k * (JVM_instance_num - 1) * host_num). >>>>>>>>>>> >>>>>>>>>>> As part of the change, I also restructured the code to allow >>>>>>>>>>> us to plug in more shareable subgraphs in the closed archive >>>>>>>>>>> heap region for runtime footprint saving in the future. >>>>>>>>>>> >>>>>>>>>>> The 'st' space is renamed to 'ca' (closed archive) space >>>>>>>>>>> since it now contains other types of objects besides >>>>>>>>>>> j.l.Strings. >>>>>>>>>>> >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8212995/webrev.00/ >>>>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8212995 >>>>>>>>>>> >>>>>>>>>>> Before: >>>>>>>>>>> >>>>>>>>>>> mc? space:????? 8416 [? 0.0% of total] out of???? 12288 >>>>>>>>>>> bytes [ 68.5% used] at 0x0000000800000000 >>>>>>>>>>> rw? space:?? 3946640 [ 21.4% of total] out of 3948544 bytes >>>>>>>>>>> [100.0% used] at 0x0000000800003000 >>>>>>>>>>> ro? space:?? 7319328 [ 39.6% of total] out of 7319552 bytes >>>>>>>>>>> [100.0% used] at 0x00000008003c7000 >>>>>>>>>>> md? space:????? 2416 [? 0.0% of total] out of????? 4096 >>>>>>>>>>> bytes [ 59.0% used] at 0x0000000800ac2000 >>>>>>>>>>> od? space:?? 6475944 [ 35.0% of total] out of 6479872 bytes >>>>>>>>>>> [ 99.9% used] at 0x0000000800ac3000 >>>>>>>>>>> st0 space:??? 438272 [? 2.4% of total] out of 438272 bytes >>>>>>>>>>> [100.0% used] at 0x00000007ffc00000 <<<<<<<<<< >>>>>>>>>>> oa0 space:??? 282624 [? 1.5% of total] out of 282624 bytes >>>>>>>>>>> [100.0% used] at 0x00000007ff800000 <<<<<<<<<< >>>>>>>>>>> total??? :? 18473640 [100.0% of total] out of 18485248 bytes >>>>>>>>>>> [ 99.9% used] >>>>>>>>>>> >>>>>>>>>>> After: >>>>>>>>>>> >>>>>>>>>>> mc? space:????? 8416 [? 0.0% of total] out of???? 12288 >>>>>>>>>>> bytes [ 68.5% used] at 0x0000000800000000 >>>>>>>>>>> rw? space:?? 3946640 [ 21.4% of total] out of 3948544 bytes >>>>>>>>>>> [100.0% used] at 0x0000000800003000 >>>>>>>>>>> ro? space:?? 7319304 [ 39.6% of total] out of 7319552 bytes >>>>>>>>>>> [100.0% used] at 0x00000008003c7000 >>>>>>>>>>> md? space:????? 2416 [? 0.0% of total] out of????? 4096 >>>>>>>>>>> bytes [ 59.0% used] at 0x0000000800ac2000 >>>>>>>>>>> od? space:?? 6475920 [ 35.0% of total] out of 6479872 bytes >>>>>>>>>>> [ 99.9% used] at 0x0000000800ac3000 >>>>>>>>>>> ca0 space:??? 442368 [? 2.4% of total] out of 442368 bytes >>>>>>>>>>> [100.0% used] at 0x00000007ffc00000 <<<<<<<<<< >>>>>>>>>>> oa0 space:??? 278528 [? 1.5% of total] out of 278528 bytes >>>>>>>>>>> [100.0% used] at 0x00000007ff800000 <<<<<<<<<< >>>>>>>>>>> total??? :? 18473592 [100.0% of total] out of 18485248 bytes >>>>>>>>>>> [ 99.9% used] >>>>>>>>>>> >>>>>>>>>>> Tested with appcds tests on linux-x64 locally. Running >>>>>>>>>>> tier1-teir4 tests. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Jiangli >> > From lance.andersen at oracle.com Sat Nov 3 13:12:48 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 3 Nov 2018 09:12:48 -0400 Subject: [12] RFR: 8213330: Fix legal headers in i18n tests In-Reply-To: References: Message-ID: Hi Naoto Looks good over all. One question: I noticed that some of the files had a copyright date and others did not. For example: test/jdk/sun/util/calendar/zi/tzdata/gmt has a copyright test/jdk/sun/util/calendar/zi/tzdata/factory does not If this is not by design, perhaps this should be addressed as part of the put back? Best Lance > On Nov 2, 2018, at 8:10 PM, naoto.sato at oracle.com wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8213330 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8213330/webrev.00/ > > It is to remove "Classpath exception" copyright phrase from i18n related test files. > > Naoto 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 dean.long at oracle.com Sat Nov 3 20:00:30 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sat, 3 Nov 2018 13:00:30 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Message-ID: <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> I made a pass at improving the comments based on feedback I've received.? I updated webrev.4 in place, along with an incremental diff: http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ dl On 10/31/18 9:39 PM, Bernd Eckenfels wrote: > I find the tail call optimization comment in wrapException adds only > confusion to an otherwise clear helper. But maybe it?s just me who > does not understand it. From Alan.Bateman at oracle.com Sun Nov 4 09:03:39 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Nov 2018 09:03:39 +0000 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> Message-ID: <3f15e776-4aae-b3a7-302a-0c451d73a0c1@oracle.com> On 03/11/2018 20:00, dean.long at oracle.com wrote: > I made a pass at improving the comments based on feedback I've > received.? I updated webrev.4 in place, along with an incremental diff: I looked through the updated webrev.4, mostly studying the changes in AccessController.java and jvm.cpp and the changes look good to me. -Alan. From deepak.kejriwal at oracle.com Mon Nov 5 06:26:51 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Sun, 4 Nov 2018 22:26:51 -0800 (PST) Subject: RFR: JDK8U Backport of 8171049: Era.getDisplayName doesn't work with non-IsoChronology Message-ID: Hi all, Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8171049 Webrev: http://cr.openjdk.java.net/~rpatil/8171049/webrev.00/ Master Bug changeset and Review details: JDK Change set: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/965d4dde0086 JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/049037.html New test file "TestEraDisplayName.java" added as part of fix is modified as per jdk 8 release:- . All test written in jdk 10 are written to verify the CLDR resource. Since, in case of jdk 8 "CLDR" is not default locale providers, added Djava.locale.providers=CLDR as JVM parameter to test. . Some resource keys in jdk 8 does not exist in both CLDR and JRE due to which Era.getDisplayName() returns numeric value. Modified such test cases accordingly. Regards, Deepak From christoph.langer at sap.com Mon Nov 5 07:32:50 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Nov 2018 07:32:50 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions Message-ID: Hi, Ping. May I get reviews/substantial feedback on this zipfs enhancement? Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ Thanks Christoph From: Langer, Christoph Sent: Montag, 29. Oktober 2018 15:55 To: 'Alan Bateman' ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen Cc: Volker Simonis ; nio-dev Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) Hi Alan, security guys, I've proposed a CSR for this change now: https://bugs.openjdk.java.net/browse/JDK-8213082. I also updated the webrev, simplifying jdk.nio.zipfs.ZipUtils.permsFromFlags and eliminating the WeakHashMap: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ Since I've decoupled the changes to java.util.zip and jartool from those in jdk.zipfs, we're discussing only jdk.zipfs here. The implication of my change is that when working with files backed by the nio FileSystemProvider (java.nio.file.spi.FileSystemProvider) named "jar", which is the alias for zipfs, the files will support attributes of type java.nio.file.attribute.PosixFilePermissions ("posix:permissions"). It basically means that some methods of java.nio.file.Files that would return null or UnsupportedOperationException before would find an implementation now. Examples: https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getPosixFilePermissions(java.nio.file.Path,java.nio.file.LinkOption...) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#setPosixFilePermissions(java.nio.file.Path,java.util.Set) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#readAttributes(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributes.html https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getFileAttributeView(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributeView.html Thanks in advance for reviewing. Best regards Christoph From: Alan Bateman > Sent: Montag, 29. Oktober 2018 13:06 To: Langer, Christoph >; core-libs-dev >; security-dev at openjdk.java.net; Xueming Shen > Cc: Volker Simonis >; Andrew Luo >; nio-dev > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) On 29/10/2018 09:26, Langer, Christoph wrote: : As per request from Alan, I'm adding security-dev to get a review from security perspective. For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. -Alan From Alan.Bateman at oracle.com Mon Nov 5 10:22:53 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Nov 2018 10:22:53 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: On 05/11/2018 07:32, Langer, Christoph wrote: > > Hi, > > Ping. > > May I get reviews/substantial feedback on this zipfs enhancement? > > It might be bit early to be asking for a code review on just one piece of this. I think the first step on this feature has to be to put all the issues on the table. There are several discussion points around ZIP vs. JAR, the impact on signed JARs, carrying permissions without a file owner, and the impact on tools. I also think that there will need to be discussion on security-dev as some of these issues around this feature have security concerns. -Alan From chris.hegarty at oracle.com Mon Nov 5 12:20:11 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 5 Nov 2018 12:20:11 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> Hi Christoph, On 05/11/18 07:32, Langer, Christoph wrote: > .. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 Can you please add a `Scope` value to the CSR? I can't quite tell, but I assume it should be `JDK` or `Implementation`, right? I want to clarify that there is no impact on Java SE. -Chris. From christoph.langer at sap.com Mon Nov 5 12:54:38 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Nov 2018 12:54:38 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> References: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> Message-ID: <0792cdf7824042bc905e952b80bb8b7b@sap.com> Hi Chris, yes, there's no impact on Java SE with this item. No API is changed. I've set the scope to JDK, as it affects the features that are available with the "jar" filesystem provider from module jdk.zipfs. Best regards Christoph > -----Original Message----- > From: Chris Hegarty > Sent: Montag, 5. November 2018 13:20 > To: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; security-dev at openjdk.java.net > Cc: nio-dev > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > Hi Christoph, > > On 05/11/18 07:32, Langer, Christoph wrote: > > .. > > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > Can you please add a `Scope` value to the CSR? > > I can't quite tell, but I assume it should be `JDK` or > `Implementation`, right? I want to clarify that there is > no impact on Java SE. > > -Chris. From christoph.langer at sap.com Mon Nov 5 13:05:22 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Nov 2018 13:05:22 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: Hi Alan, all, I'd welcome a discussion, for sure. Unfortunately there hasn't been so much participation in this yet. I think this is an item where it's hard to have a clear opinion and where it's difficult to oversee all implications it might have. Who'd be willing to have a look from security perspective? Thanks & Best regards Christoph From: Alan Bateman Sent: Montag, 5. November 2018 11:23 To: Langer, Christoph ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen Cc: Volker Simonis ; nio-dev Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions On 05/11/2018 07:32, Langer, Christoph wrote: Hi, Ping. May I get reviews/substantial feedback on this zipfs enhancement? It might be bit early to be asking for a code review on just one piece of this. I think the first step on this feature has to be to put all the issues on the table. There are several discussion points around ZIP vs. JAR, the impact on signed JARs, carrying permissions without a file owner, and the impact on tools. I also think that there will need to be discussion on security-dev as some of these issues around this feature have security concerns. -Alan From chris.hegarty at oracle.com Mon Nov 5 14:10:52 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 5 Nov 2018 14:10:52 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <0792cdf7824042bc905e952b80bb8b7b@sap.com> References: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> <0792cdf7824042bc905e952b80bb8b7b@sap.com> Message-ID: <47fe2f75-f251-3ac5-463e-972ae5434659@oracle.com> On 05/11/18 12:54, Langer, Christoph wrote: > Hi Chris, > > yes, there's no impact on Java SE with this item. No API is changed. I've set the scope to JDK, as it affects the features that are available with the "jar" filesystem provider from module jdk.zipfs. > ... The reason I asked about the CSR scope clarification is that it was unclear to me what the ultimate intentions are, given that the previous mails ( linked to from the CSR ) did have Java SE API changes ( in the java.util.zip package ). Are you now happy to reduce the scope of the proposal to be confined to the "jar" filesystem provider, or is this more of an initial step towards ultimately adding new Java SE APIs, to zip, to access these permissions ( as was in previous emails )? As well as possibly updating the tools to add such? -Chris. From christoph.langer at sap.com Mon Nov 5 14:23:22 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Nov 2018 14:23:22 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <47fe2f75-f251-3ac5-463e-972ae5434659@oracle.com> References: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> <0792cdf7824042bc905e952b80bb8b7b@sap.com> <47fe2f75-f251-3ac5-463e-972ae5434659@oracle.com> Message-ID: <410f5c58c8934763b3e6e46217efb724@sap.com> Hi Chris > The reason I asked about the CSR scope clarification is that it was > unclear to me what the ultimate intentions are, given that the previous > mails ( linked to from the CSR ) did have Java SE API changes ( in the > java.util.zip package ). > > Are you now happy to reduce the scope of the proposal to be confined to > the "jar" filesystem provider, or is this more of an initial step > towards ultimately adding new Java SE APIs, to zip, to access these > permissions ( as was in previous emails )? As well as possibly updating > the tools to add such? The latter thing is true. I reduced the scope of my initial proposal to the "jar" filesystem provider here with the intention to get in this piece more quickly, if not at all. Maybe changes to java.util.zip and tools aren't feasible - we'll see. Furthermore, assuming changes can be done with JDK12, I consider the jdk.zipfs piece "backportable", at least for our OpenJDK build SapMachine (https://sapmachine.io). So having it separate would definitely ease the backporting into SapMachine 11 - which is the target for a customer of ours. Best Christoph From Alan.Bateman at oracle.com Mon Nov 5 15:59:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Nov 2018 15:59:29 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: On 05/11/2018 13:05, Langer, Christoph wrote: > > Hi Alan, all, > > I?d welcome a discussion, for sure. Unfortunately there hasn?t been so > much participation in this yet. I think this is an item where it?s > hard to have a clear opinion and where it?s difficult to oversee all > implications it might have. > > Who?d be willing to have a look from security perspective? > I think you'll need to do a write-up of the overall proposal so that folks can jump in and point out the implications. It's not easy to do this in a code review of a small piece of the solution. I suspect that security-dev will be interested in the details for signed JARs as I don't think the current proposal prevents tampering of the file permissions. -Alan. From sean.mullan at oracle.com Mon Nov 5 16:00:28 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 5 Nov 2018 11:00:28 -0500 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> Message-ID: 726 * The VM recoginizes this method as special, so any changes to the s/recoginizes/recognizes/ --Sean On 11/3/18 4:00 PM, dean.long at oracle.com wrote: > I made a pass at improving the comments based on feedback I've > received.? I updated webrev.4 in place, along with an incremental diff: > > http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ > > dl > > On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >> I find the tail call optimization comment in wrapException adds only >> confusion to an otherwise clear helper. But maybe it?s just me who >> does not understand it. > From chris.hegarty at oracle.com Mon Nov 5 16:19:05 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 5 Nov 2018 16:19:05 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: <1c5801e0-69d9-859b-c5e7-a1304bbff4d8@oracle.com> On 05/11/18 15:59, Alan Bateman wrote: > On 05/11/2018 13:05, Langer, Christoph wrote: >> >>... >> > I think you'll need to do a write-up of the overall proposal so that > folks can jump in and point out the implications. It's not easy to do > this in a code review of a small piece of the solution. Right, that's the main motivation for my previous questions. It is good to get a *complete* view of what is intended before reviewing the code. ( Sorry, if I've missed some of the previous context ). -Chris. From naoto.sato at oracle.com Mon Nov 5 18:27:44 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 5 Nov 2018 10:27:44 -0800 Subject: RFR: JDK8U Backport of 8171049: Era.getDisplayName doesn't work with non-IsoChronology In-Reply-To: References: Message-ID: <649f938c-e335-a58d-ebbc-f29095d8eb91@oracle.com> Looks good. Since you modified the test case, please add the copyright year 2018 in the test case before you push. Naoto On 11/4/18 10:26 PM, Deepak Kejriwal wrote: > Hi all, > > > > Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8171049 > > Webrev: http://cr.openjdk.java.net/~rpatil/8171049/webrev.00/ > > > > Master Bug changeset and Review details: > > JDK Change set: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/965d4dde0086 > > JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/049037.html > > > > New test file "TestEraDisplayName.java" added as part of fix is modified as per jdk 8 release:- > > > > . All test written in jdk 10 are written to verify the CLDR resource. Since, in case of jdk 8 "CLDR" is not default locale providers, added Djava.locale.providers=CLDR as JVM parameter to test. > > . Some resource keys in jdk 8 does not exist in both CLDR and JRE due to which Era.getDisplayName() returns numeric value. Modified such test cases accordingly. > > > > Regards, > > Deepak > From dean.long at oracle.com Mon Nov 5 18:33:20 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 5 Nov 2018 10:33:20 -0800 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <3f15e776-4aae-b3a7-302a-0c451d73a0c1@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> <3f15e776-4aae-b3a7-302a-0c451d73a0c1@oracle.com> Message-ID: <5c9afc7f-3ada-f95c-1110-db9bbc553536@oracle.com> Thanks Alan. dl On 11/4/18 1:03 AM, Alan Bateman wrote: > On 03/11/2018 20:00, dean.long at oracle.com wrote: >> I made a pass at improving the comments based on feedback I've >> received.? I updated webrev.4 in place, along with an incremental diff: > I looked through the updated webrev.4, mostly studying the changes in > AccessController.java and jvm.cpp and the changes look good to me. > > -Alan. From dean.long at oracle.com Mon Nov 5 18:36:33 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 5 Nov 2018 10:36:33 -0800 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> Message-ID: <38c21603-deab-7f54-c869-f68be3748fa8@oracle.com> Fixed.? Thanks. dl On 11/5/18 8:00 AM, Sean Mullan wrote: > 726 * The VM recoginizes this method as special, so any changes to the > > s/recoginizes/recognizes/ > > --Sean > > On 11/3/18 4:00 PM, dean.long at oracle.com wrote: >> I made a pass at improving the comments based on feedback I've >> received.? I updated webrev.4 in place, along with an incremental diff: >> >> http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ >> >> dl >> >> On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >>> I find the tail call optimization comment in wrapException adds only >>> confusion to an otherwise clear helper. But maybe it?s just me who >>> does not understand it. >> From volker.simonis at gmail.com Mon Nov 5 18:38:42 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Nov 2018 19:38:42 +0100 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: Hi Christoph, in general your change looks good to me. I need some more time to think about the implications mentioned by Alan and Chris but for the time being please find some comments regarding your implementation below: ZipFileAttributeView.java - can you please throw an AssertionError() for the default branch in the switch expression in the "ZipFileAttributeView.name()". ZipFileSystem.java - please also put @Override annotations on the method implementations from ZipFileAttributes (e.g. "compressedSize()", "crc()", etc...) and a comment at the place where the implementation of the "PosixFileAttributes" methods starts. ZipUtils.java - just a question: isn't it possible to reuse sun.nio.fs.UnixFileModeAttribute.toUnixMode() and the corresponding constants from sun.nio.fs.UnixConstants instead of redefining them here? You could export them from java.base to jdk.zipfs but the problem is probably that at least sun.nio.fs.UnixConstants is a generated class which only gets generated on Unix systems, right ? ZipFileAttributes.java - it seems a little odd that you've added "setPermissions()" to ZipFileAttributes. All the attribute classes (i.e. BasicFileAttributes, PosixFileAttributes) have no setters. Isn't it possible to implement "ZipFileAttributeView.setPermissions()" by calling "path.setPermissions()" (as this is done in "ZipFileAttributeView.setTimes()") and handle everything in ZipFileSyste (as this is done with "setTimes()"). Thanks, Volker On Mon, Nov 5, 2018 at 8:32 AM Langer, Christoph wrote: > > Hi, > > > > Ping. > > > > May I get reviews/substantial feedback on this zipfs enhancement? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ > > > > Thanks > > Christoph > > > > From: Langer, Christoph > Sent: Montag, 29. Oktober 2018 15:55 > To: 'Alan Bateman' ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen > Cc: Volker Simonis ; nio-dev > Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) > > > > Hi Alan, security guys, > > > > I?ve proposed a CSR for this change now: https://bugs.openjdk.java.net/browse/JDK-8213082. > > > > I also updated the webrev, simplifying jdk.nio.zipfs.ZipUtils.permsFromFlags and eliminating the WeakHashMap: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ > > > > Since I?ve decoupled the changes to java.util.zip and jartool from those in jdk.zipfs, we?re discussing only jdk.zipfs here. > > > > The implication of my change is that when working with files backed by the nio FileSystemProvider (java.nio.file.spi.FileSystemProvider) named ?jar?, which is the alias for zipfs, the files will support attributes of type java.nio.file.attribute.PosixFilePermissions (?posix:permissions?). > > > > It basically means that some methods of java.nio.file.Files that would return null or UnsupportedOperationException before would find an implementation now. > > > > Examples: > > https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getPosixFilePermissions(java.nio.file.Path,java.nio.file.LinkOption...) > > https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#setPosixFilePermissions(java.nio.file.Path,java.util.Set) > > https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#readAttributes(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) > > With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributes.html > > https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getFileAttributeView(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) > > With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributeView.html > > > > Thanks in advance for reviewing. > > > > Best regards > > Christoph > > > > > > From: Alan Bateman > Sent: Montag, 29. Oktober 2018 13:06 > To: Langer, Christoph ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen > Cc: Volker Simonis ; Andrew Luo ; nio-dev > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) > > > > On 29/10/2018 09:26, Langer, Christoph wrote: > > : > > > > As per request from Alan, I?m adding security-dev to get a review from security perspective. > > > > For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. > > -Alan From huizhe.wang at oracle.com Mon Nov 5 19:10:15 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 05 Nov 2018 11:10:15 -0800 Subject: RFR 8212872: Broken link to http://www.w3.org/XML/xml-names-19990114-errata Message-ID: <5BE09597.6040003@oracle.com> Hi, Please review a correction of the links: 1. the 1st link shall point to the standard "Namespaces in XML", not the inner anchor to the "Qualified Names" section. 2. the 2nd link shall point to the html file "xml-names-19990114-errata.html", not "xml-names-19990114-errata". --- a/src/java.xml/share/classes/javax/xml/namespace/package-info.java +++ b/src/java.xml/share/classes/javax/xml/namespace/package-info.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2018, 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 @@ -35,10 +35,10 @@ *
  • * XML Schema Part2: Datatypes specification *
    • - *
  • + *
  • * Namespaces in XML *
    • - *
  • + *
  • * Namespaces in XML Errata *
    • * Thanks, Joe From naoto.sato at oracle.com Mon Nov 5 19:12:14 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 5 Nov 2018 11:12:14 -0800 Subject: [12] RFR: 8213330: Fix legal headers in i18n tests In-Reply-To: References: Message-ID: <259cc590-9c52-e3fc-d8ff-d8d5f7c9a8b6@oracle.com> Hi Lance, On 11/3/18 6:12 AM, Lance Andersen wrote: > Hi Naoto > > Looks good over all. > > One question: > > * I noticed that some of the files had a copyright date and others did > not. ?For example: > o test/jdk/sun/util/calendar/zi/tzdata/gmt ?has a copyright > o test/jdk/sun/util/calendar/zi/tzdata/factory does not > > If this is not by design, perhaps this?should be addressed as part of > the put ?back? Yes, I noticed that too. I don't know any history of these files, so I left it unmodified, as the initial year is unknown. Naoto > > Best > Lance > >> On Nov 2, 2018, at 8:10 PM, naoto.sato at oracle.com >> wrote: >> >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8213330 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8213330/webrev.00/ >> >> It is to remove "Classpath exception" copyright phrase from i18n >> related test files. >> >> Naoto > > > > 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 Nov 5 19:13:46 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 5 Nov 2018 14:13:46 -0500 Subject: RFR 8212872: Broken link to http://www.w3.org/XML/xml-names-19990114-errata In-Reply-To: <5BE09597.6040003@oracle.com> References: <5BE09597.6040003@oracle.com> Message-ID: +1 > On Nov 5, 2018, at 2:10 PM, Joe Wang wrote: > > Hi, > > Please review a correction of the links: > > 1. the 1st link shall point to the standard "Namespaces in XML", not the inner anchor to the "Qualified Names" section. > 2. the 2nd link shall point to the html file "xml-names-19990114-errata.html", not "xml-names-19990114-errata". > > --- a/src/java.xml/share/classes/javax/xml/namespace/package-info.java > +++ b/src/java.xml/share/classes/javax/xml/namespace/package-info.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2018, 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 > @@ -35,10 +35,10 @@ > *
  • > * XML Schema Part2: Datatypes specification > *
    • > - *
  • > + *
  • > * Namespaces in XML > *
    • > - *
  • > + *
  • > * Namespaces in XML Errata > *
    • > * > > 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 mail.openjdk.java.net at lemmster.de Mon Nov 5 19:49:47 2018 From: mail.openjdk.java.net at lemmster.de (mail.openjdk.java.net at lemmster.de) Date: Mon, 5 Nov 2018 11:49:47 -0800 Subject: Lazy memory initialization for Unsafe (calloc vs. malloc) Message-ID: Hi, lets assume an application A [1] which is optimized for throughput, not latency. Additionally, A reverts to sun.misc.Unsafe to store gigabytes of data on off-heap memory to e.g. improved memory utilization and performance. Due to the fact that Unsafe#allocateMemory returns an uninitialized (malloc) memory region R, app A has to explicitly initialize R by e.g. calling Unsafe#setMemory?. Since app A is optimized for throughput, there is no real need to eagerly allocate R. Instead - on OSes with an optimistic memory allocator such as Linux - app A could benefit from lazy allocation. This would reduce app startup time that - that today is linear in the size of R - to constant time. Assuming Unsafe (or some other API) would expose memory allocation with calloc instead of malloc one would get away without explicitly calling Unsafe#setMemory or implementing (complex) lazy initialization into A itself. To check this idea, I added sun.misc.Unsafe#callocateMemory (notice the "c") to a local jdk12 build. It works as intended. Is this feature a candidate to be added to the JVM, e.g. as part of project Panama or am I better off rolling my own solution via JNI? Thanks Markus ? Lets assume the application logic cannot deal with uninitialized memory. [1] https://github.com/tlaplus/tlaplus From huizhe.wang at oracle.com Mon Nov 5 19:50:33 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 05 Nov 2018 11:50:33 -0800 Subject: RFR 8212872: Broken link to http://www.w3.org/XML/xml-names-19990114-errata In-Reply-To: References: <5BE09597.6040003@oracle.com> Message-ID: <5BE09F09.5060503@oracle.com> Thanks Lance! On 11/5/18, 11:13 AM, Lance Andersen wrote: > +1 >> On Nov 5, 2018, at 2:10 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review a correction of the links: >> >> 1. the 1st link shall point to the standard "Namespaces in XML", not >> the inner anchor to the "Qualified Names" section. >> 2. the 2nd link shall point to the html file >> "xml-names-19990114-errata.html", not "xml-names-19990114-errata". >> >> --- a/src/java.xml/share/classes/javax/xml/namespace/package-info.java >> +++ b/src/java.xml/share/classes/javax/xml/namespace/package-info.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2015, 2018, 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 >> @@ -35,10 +35,10 @@ >> *
  • >> * XML Schema Part2: Datatypes specification >> *
    • >> - *
  • >> + *
  • >> * Namespaces in XML >> *
    • >> - *
  • >> + *
  • >> * Namespaces in XML Errata >> *
    • >> * >> >> 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 huizhe.wang at oracle.com Mon Nov 5 20:24:08 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 05 Nov 2018 12:24:08 -0800 Subject: RFR 8212876: ftp: links for character-sets require a login password Message-ID: <5BE0A6E8.8030104@oracle.com> Hi, Please review a fix for the broken links to IANA-CHARSETS. While we are here, I also updated the link to XML 1.0 since "REC-xml-20040204" was outdated. Both the current and outdated XML 1.0 spec actually referenced the correct iana.org page for the charsets. --- a/src/java.xml/share/classes/org/w3c/dom/ls/LSOutput.java +++ b/src/java.xml/share/classes/org/w3c/dom/ls/LSOutput.java @@ -117,19 +117,19 @@ /** * The character encoding to use for the output. The encoding must be a - * string acceptable for an XML encoding declaration ([XML 1.0] section + * string acceptable for an XML encoding declaration ([XML 1.0] section * 4.3.3 "Character Encoding in Entities"), it is recommended that * character encodings registered (as charsets) with the Internet - * Assigned Numbers Authority [IANA-CHARSETS] + * Assigned Numbers Authority [IANA-CHARSETS] * should be referred to using their registered names. */ public String getEncoding(); /** * The character encoding to use for the output. The encoding must be a - * string acceptable for an XML encoding declaration ([XML 1.0] section + * string acceptable for an XML encoding declaration ([XML 1.0] section * 4.3.3 "Character Encoding in Entities"), it is recommended that * character encodings registered (as charsets) with the Internet - * Assigned Numbers Authority [IANA-CHARSETS] + * Assigned Numbers Authority [IANA-CHARSETS] * should be referred to using their registered names. */ public void setEncoding(String encoding); Thanks, Joe From lance.andersen at oracle.com Mon Nov 5 20:34:10 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 5 Nov 2018 15:34:10 -0500 Subject: RFR 8212876: ftp: links for character-sets require a login password In-Reply-To: <5BE0A6E8.8030104@oracle.com> References: <5BE0A6E8.8030104@oracle.com> Message-ID: <38372D34-619A-46F1-85C9-AFC00F65E0F2@oracle.com> +1 > On Nov 5, 2018, at 3:24 PM, Joe Wang wrote: > > Hi, > > Please review a fix for the broken links to IANA-CHARSETS. While we are here, I also updated the link to XML 1.0 since "REC-xml-20040204" was outdated. Both the current and outdated XML 1.0 spec actually referenced the correct iana.org page for the charsets. > > --- a/src/java.xml/share/classes/org/w3c/dom/ls/LSOutput.java > +++ b/src/java.xml/share/classes/org/w3c/dom/ls/LSOutput.java > @@ -117,19 +117,19 @@ > > /** > * The character encoding to use for the output. The encoding must be a > - * string acceptable for an XML encoding declaration ([XML 1.0] section > + * string acceptable for an XML encoding declaration ([XML 1.0] section > * 4.3.3 "Character Encoding in Entities"), it is recommended that > * character encodings registered (as charsets) with the Internet > - * Assigned Numbers Authority [IANA-CHARSETS] > + * Assigned Numbers Authority [IANA-CHARSETS] > * should be referred to using their registered names. > */ > public String getEncoding(); > /** > * The character encoding to use for the output. The encoding must be a > - * string acceptable for an XML encoding declaration ([XML 1.0] section > + * string acceptable for an XML encoding declaration ([XML 1.0] section > * 4.3.3 "Character Encoding in Entities"), it is recommended that > * character encodings registered (as charsets) with the Internet > - * Assigned Numbers Authority [IANA-CHARSETS] > + * Assigned Numbers Authority [IANA-CHARSETS] > * should be referred to using their registered names. > */ > public void setEncoding(String encoding); > > 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 huizhe.wang at oracle.com Mon Nov 5 21:46:19 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 05 Nov 2018 13:46:19 -0800 Subject: RFR 8212876: ftp: links for character-sets require a login password In-Reply-To: <38372D34-619A-46F1-85C9-AFC00F65E0F2@oracle.com> References: <5BE0A6E8.8030104@oracle.com> <38372D34-619A-46F1-85C9-AFC00F65E0F2@oracle.com> Message-ID: <5BE0BA2B.7040307@oracle.com> Thanks Lance, again :-) On 11/5/18, 12:34 PM, Lance Andersen wrote: > +1 >> On Nov 5, 2018, at 3:24 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review a fix for the broken links to IANA-CHARSETS. While we >> are here, I also updated the link to XML 1.0 since "REC-xml-20040204" >> was outdated. Both the current and outdated XML 1.0 spec actually >> referenced the correct iana.org page for the charsets. >> >> --- a/src/java.xml/share/classes/org/w3c/dom/ls/LSOutput.java >> +++ b/src/java.xml/share/classes/org/w3c/dom/ls/LSOutput.java >> @@ -117,19 +117,19 @@ >> >> /** >> * The character encoding to use for the output. The encoding >> must be a >> - * string acceptable for an XML encoding declaration ([> href='http://www.w3.org/TR/2004/REC-xml-20040204'>XML 1.0] section >> + * string acceptable for an XML encoding declaration ([> href='https://www.w3.org/TR/xml/'>XML 1.0] section >> * 4.3.3 "Character Encoding in Entities"), it is recommended that >> * character encodings registered (as charsets) with the Internet >> - * Assigned Numbers Authority [> href='ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets'>IANA-CHARSETS] >> + * Assigned Numbers Authority [> href='http://www.iana.org/assignments/character-sets/character-sets.xhtml'>IANA-CHARSETS] >> * should be referred to using their registered names. >> */ >> public String getEncoding(); >> /** >> * The character encoding to use for the output. The encoding >> must be a >> - * string acceptable for an XML encoding declaration ([> href='http://www.w3.org/TR/2004/REC-xml-20040204'>XML 1.0] section >> + * string acceptable for an XML encoding declaration ([> href='https://www.w3.org/TR/xml/'>XML 1.0] section >> * 4.3.3 "Character Encoding in Entities"), it is recommended that >> * character encodings registered (as charsets) with the Internet >> - * Assigned Numbers Authority [> href='ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets'>IANA-CHARSETS] >> + * Assigned Numbers Authority [> href='http://www.iana.org/assignments/character-sets/character-sets.xhtml'>IANA-CHARSETS] >> * should be referred to using their registered names. >> */ >> public void setEncoding(String encoding); >> >> 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 kevin.rushforth at oracle.com Tue Nov 6 00:17:38 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 5 Nov 2018 16:17:38 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> Message-ID: <07d97a0c-ee3b-50bb-d726-b9bbbb301dbe@oracle.com> Based on feedback and further discussion, we're going with jdk.jpackager and jdk.jpackager.runtime. > I?m also hoping that the service daemon support will make it into the JDK 12 deliverable. Is that out of the question at this point? It won't make JDK 12, but is near the top of the list for JDK 13. -- Kevin On 11/1/2018 8:30 AM, Scott Palmer wrote: > On Oct 30, 2018, at 1:10 PM, Andy Herrick wrote: >> On 10/30/2018 12:09 PM, Alan Bateman wrote: >>>> ... >>> Alex has suggested jdk.jpackager to avoid giving the impression that it's the "JDK packager". Also several existing tool modules have the tool name in the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...). >> This seems reasonable, jdk.packager -> jdk.jpackager >> still leaves the question of jdk.packager.services -> jdk.jpackager.services (or jdk.jpackager.runtime) or something else ? > > I prefer jdk.jpackager.runtime. I think it makes more sense given the likely future functions that will be implemented there. User JVM args support and single instance support don?t seem to fit the ?services? name. > > I?m also hoping that the service daemon support will make it into the JDK 12 deliverable. Is that out of the question at this point? > > Regards, > > Scott From vladimir.kozlov at oracle.com Tue Nov 6 01:51:03 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Nov 2018 17:51:03 -0800 Subject: Review request: JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported In-Reply-To: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> References: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> Message-ID: <1375f008-56d8-abf4-e073-19b1c0b1d87e@oracle.com> I looked on tests changes in src/jdk.internal.vm.compiler and test/hotspot/jtreg/compiler/jvmci. They look fine. And you ran hotspot tier1-3 which tests AOT, JVMCI and Graal. So your changes should be fine regarding them since you did not get failures. Thanks, Vladimir On 11/1/18 9:16 PM, Mandy Chung wrote: > This patch includes the following changes that will reduce the > number of internal classes made accessible to jdk.unsupported > module via qualified exports. > > 1. move shared secrets to a new jdk.internal.access package. > > jdk.internal.misc package has been a dumping ground for various > kinds of internal APIs and many of which were moved to an appropriate > package. This is a follow-up clean up that moves the shared secrets > and JavaXXXAccess interfaces to jdk.internal.access package. > > 2. add a wrapper class jdk.internal.misc.FileSystemOption to expose > sun.nio.fs.ExtendedOptions for com.sun.nio.file to access > > This eliminates the qualified exports of sun.nio.fs to jdk.unsupported. > > 3. Refactor the implementation of sun.misc.Unsafe::invokeCleaner > to jdk.internal.misc.Unsafe. > > This eliminates the qualified exports of jdk.internal.ref and > sun.nio.ch to jdk.unsupported. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02 > > The change is straight forward although quite many files are modified. > Majority of the changes is import statement change or test @modules > change due to the rename. > > I ran hs-tier1-3 and jdk-tier1-3 tests. > > We considered the alternative to define a wrapper class for everything > that jdk.unsupported module depends on in a dedicated package > e.g. jdk.internal.unsupported.? It would need a wrapper for Unsafe, > Signal, SignalHandler and ExtendedOptions.? It means that it would > have 3 classes of each - two similar/duplicated implementations > (one in sun.misc and one in jdk.internal.unsupported) and one > in jdk.internal.misc ([1] is the prototype).? Only a limited number > of files are touched but I think the proposed approach is cleaner. > > Thanks > Mandy > [1] http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.01/ From mandy.chung at oracle.com Tue Nov 6 01:59:37 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 5 Nov 2018 17:59:37 -0800 Subject: Review request: JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported In-Reply-To: <1375f008-56d8-abf4-e073-19b1c0b1d87e@oracle.com> References: <0892f7bb-5c8e-e36d-544d-76ab05e6049e@oracle.com> <1375f008-56d8-abf4-e073-19b1c0b1d87e@oracle.com> Message-ID: Thanks for the review, Vladimir.? hotspot tier1-3 and jdk tier1-3 all passed. I will submit another test run as sanity tests before I push. Mandy On 11/5/18 5:51 PM, Vladimir Kozlov wrote: > I looked on tests changes in src/jdk.internal.vm.compiler and > test/hotspot/jtreg/compiler/jvmci. They look fine. > > And you ran hotspot tier1-3 which tests AOT, JVMCI and Graal. So your > changes should be fine regarding them since you did not get failures. > > Thanks, > Vladimir > > On 11/1/18 9:16 PM, Mandy Chung wrote: >> This patch includes the following changes that will reduce the >> number of internal classes made accessible to jdk.unsupported >> module via qualified exports. >> >> 1. move shared secrets to a new jdk.internal.access package. >> >> jdk.internal.misc package has been a dumping ground for various >> kinds of internal APIs and many of which were moved to an appropriate >> package. This is a follow-up clean up that moves the shared secrets >> and JavaXXXAccess interfaces to jdk.internal.access package. >> >> 2. add a wrapper class jdk.internal.misc.FileSystemOption to expose >> sun.nio.fs.ExtendedOptions for com.sun.nio.file to access >> >> This eliminates the qualified exports of sun.nio.fs to jdk.unsupported. >> >> 3. Refactor the implementation of sun.misc.Unsafe::invokeCleaner >> to jdk.internal.misc.Unsafe. >> >> This eliminates the qualified exports of jdk.internal.ref and >> sun.nio.ch to jdk.unsupported. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02 >> >> The change is straight forward although quite many files are modified. >> Majority of the changes is import statement change or test @modules >> change due to the rename. >> >> I ran hs-tier1-3 and jdk-tier1-3 tests. >> >> We considered the alternative to define a wrapper class for everything >> that jdk.unsupported module depends on in a dedicated package >> e.g. jdk.internal.unsupported.? It would need a wrapper for Unsafe, >> Signal, SignalHandler and ExtendedOptions.? It means that it would >> have 3 classes of each - two similar/duplicated implementations >> (one in sun.misc and one in jdk.internal.unsupported) and one >> in jdk.internal.misc ([1] is the prototype).? Only a limited number >> of files are touched but I think the proposed approach is cleaner. >> >> Thanks >> Mandy >> [1] http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.01/ From stuart.marks at oracle.com Tue Nov 6 04:27:11 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 5 Nov 2018 20:27:11 -0800 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BCA21B9.7040304@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> <5BCA21B9.7040304@oracle.com> Message-ID: <5cd29d6a-6e57-9d44-3c7c-f717dd304884@oracle.com> On 10/19/18 11:26 AM, Joe Wang wrote: > Current version: > http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/ Hi Joe, Thanks for updating the tests per my comments. Everything looks good now! s'marks From magnus.ihse.bursie at oracle.com Tue Nov 6 08:18:32 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Nov 2018 09:18:32 +0100 Subject: Review Request : JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM In-Reply-To: <195AC878-1B67-43E0-8FF4-D387B916E58A@oracle.com> References: <195AC878-1B67-43E0-8FF4-D387B916E58A@oracle.com> Message-ID: <283A9BC5-973D-488D-BA36-55BFC5D3AF59@oracle.com> I now noticed that this was only sent to build-dev. This is not really a build question. Cc:ing core-libs-dev. /Magnus > 5 nov. 2018 kl. 15:21 skrev Magnus Ihse Bursie : > > Hi, > > Fix looks good, but maybe we should have a regression test of GetJREPath()? > > /Magnus > >> 5 nov. 2018 kl. 12:09 skrev Priyanka Mangal : >> >> Hi, >> >> Please review the minor fix for : >> https://bugs.openjdk.java.net/browse/JDK-8213362 >> http://cr.openjdk.java.net/~pmangal/8213362/webrev.00/ >> >> With the JDK-8210931 libjli has moved from "jli" subdirectory into standard lib directory. >> However `GetJREPath` method in `src/java.base/macosx/native/libjli/java_md_macosx.m` still assumes that `libjli.dylib` should be on `lib/jli/libjli.dylib` path. >> So corrected the same. >> >> Testing: >> mach5 : tier1-3 >> http://java.se.oracle.com:10065/mdash/jobs/fmatte-jdk-20181105-0941-8721?search=result.status:* >> >> Thanks >> Regards >> Priyanka > > From sean.coffey at oracle.com Tue Nov 6 08:46:27 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 6 Nov 2018 08:46:27 +0000 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> Message-ID: <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> With JDK-8203629 now pushed, I've re-based my patch on latest jdk/jdk code. Some modifications also made based on off-thread suggestions : src/java.base/share/classes/java/security/Security.java * Only record JDK security properties for now (i.e. those in java.security conf file) ? - we can consider a new event to record non-JDK security events if demand comes about ? - new event renamed to *Jdk*SecurityPropertyModificationEvent src/java.base/share/classes/sun/security/x509/X509CertImpl.java * Use hashCode() equality test for storing certs in List. Tests updated to capture these changes src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java * Verify that self signed certs exercise the modified code paths I've added new test functionality to test use of self signed cert. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v7/webrev/ Regards, Sean. On 17/10/18 11:25, Se?n Coffey wrote: > I'd like to re-boot this review. I've been working with Erik off > thread who's been helping with code and test design. > > Some of the main changes worthy of highlighting : > > * Separate out the tests for JFR and Logger events > * Rename some events > * Normalize the data view for X509ValidationEvent (old event name : > CertChainEvent) > * Introduce CertificateSerialNumber type to make use of the > @Relational JFR annotation. > * Keep calls for JFR event operations local to call site to optimize > jvm compilation > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/ > > This code is dependent on the JDK-8203629 enhancement being integrated. > > Regards, > Sean. > > On 10/07/18 13:50, Se?n Coffey wrote: >> Erik, >> >> After some trial edits, I'm not so sure if moving the event & logger >> commit code into the class where it's used works too well after all. >> >> In the code you suggested, there's an assumption that calls such as >> EventHelper.certificateChain(..) are low cost. While that might be >> the case here, it's something we can't always assume. It's called >> once for the JFR operation and once for the Logger operation. That >> pattern multiplies itself further in other Events. i.e. set up and >> assign the variables for a JFR event without knowing whether they'll >> be needed again for the Logger call. We could work around it by >> setting up some local variables and re-using them in the Logger code >> but then, we're back to where we were. The current EventHelper design >> eliminates this problem and also helps to abstract the >> recording/logging functionality away from the functionality of the >> class itself. >> >> It also becomes a problem where we record events in multiple >> different classes (e.g. SecurityPropertyEvent). While we could leave >> the code in EventHelper for this case, we then have a mixed design >> pattern. >> >> Are you ok with leaving as is for now? A future wish might be one >> where JFR would handle Logger via its own framework/API in a future >> JDK release. >> >> I've removed the variable names using underscore. Also optimized some >> variable assignments in X509Impl.commitEvent(..) >> >> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ >> >> regards, >> Sean. >> >> On 09/07/2018 18:01, Se?n Coffey wrote: >>> Erik, >>> >>> Thanks for reviewing. Comments inline.. >>> >>> On 09/07/18 17:21, Erik Gahlin wrote: >>>> Thanks Sean. >>>> >>>> Some feedback on the code in the security libraries. >>>> >>>> - We should use camel case naming convention for variables (not >>>> underscore). >>> Sure. I see two offending variable names which I'll fix up. >>>> >>>> - Looking at sun/security/ssl/Finished.java, >>>> >>>> I wonder if it wouldn't be less code and more easy to read, if we >>>> would commit the event in a local private function and then use the >>>> EventHelper class for common functionality. >>> I'm fine with your suggested approach. I figured that tucking the >>> recording/logging logic away in a helper class also had benefits but >>> I'll re-factor to your suggested style unless I hear objections. >>> >>> regards, >>> Sean. >>> >> > From adinn at redhat.com Tue Nov 6 10:17:41 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 6 Nov 2018 10:17:41 +0000 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com> <50ed4716-b76e-6557-1146-03084776c160@redhat.com> <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com> <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> Message-ID: Ping! Is it possible to get a response on this. To summarise: I am happy to rename isPersistent to isSync and/or make it private as well as change the enum tags to use SYNC instyead of PERSISTENT if that is what is needed to get the JEP approved. I'd really like to see this progress towards a release -- preferably jdk12! 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 On 23/10/18 14:58, Andrew Dinn wrote: > Hi Alan, > > Apologies for the 2 week+ delay in replying -- I was away on holiday. > > On 03/10/18 15:24, Alan Bateman wrote: >> On 03/10/2018 10:14, Andrew Dinn wrote: >>> : >>> Sure, I'd be happy to change this. >>> >>> Would READ_ONLY_SYNC and READ_WRITE_SYNC be suitable alternatives? Or do >>> you have something else in mind? >>> >> I think that works but it means looking at the proposed >> MappedByteBuffer::isPersistent too. MappedByteBuffer hasn't needed >> methods to test if the mapping is read-only, read-write or private >> mapping and I wonder if isPersistent is really needed. > That's a good question. I guess isPersistent is not really needed as a > private method since a field lookup would do. It is obviously of no use > as a protected method because MappedByteBuffer sits in a sandwich > between ByteBuffer and DirectByteBuffer and, hence, cannot be > specialized. So, why make it public? > > The immediate intentions here is to use the new MappedByteBuffer API as > a base layer for implementation of a library of classes that provide > equivalent capabilities to the libs that extend Intel's libpmem, > providing various managed persistent data overlays on the raw NVM bytes > such as journals, block array stores etc. As far as that goal is > concerned there is arguably no need to provide isPersistent as a public > API because these client classes would normally only employ a buffer > mapped to NVM. > > However, I am not sure that is always going to be the only desired mode > of operation. It may be, for example, that we want to use these classes > to operate over mapped files as well as mapped NVM. That's very likely > not going to give great performance (although in the case of a block > array store whose block sizes are file page multiples it might not make > that much difference). However, it does allow for compatibility mode > operation when NVM is not available. Even so, I believe those clients > will not actually care what type of buffer they use. > > Other client classes might also need to be able to provide these two > alternative modes of operation -- where the underlying ByteBuffer may or > may not be persistent -- and it is not clear to me that they would not > care about whether the mapping was to NVM or to a conventional file. It > might be that some clients would want to use the buffer in different > ways depending on how it is mapped. Jonathan Halliday (in cc) actually > defined the method as public on the rather liberal assumption that this > might be how it was used but it seems he did not have a specific use > case in mind. > > Of course, a client could always track this information itself. However, > since this datum is i) a property of the ByteBuffer and ii) already > stored in the ByteBuffer I felt it was best to expose the property via a > public getter -- arguably it ought to be final. If you think that is > inappropriate or would prefer to remove it so as to minimize the new API > surface I would be happy to follow your decision. > > 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 rob.mckenna at oracle.com Tue Nov 6 15:52:03 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 6 Nov 2018 15:52:03 +0000 Subject: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider In-Reply-To: <4b152645-3702-272c-b351-5a279573634d@oracle.com> References: <20181025163435.GB4374@vimes> <4b152645-3702-272c-b351-5a279573634d@oracle.com> Message-ID: <20181106155203.GA15048@vimes> Thanks folks, Vyom, I've updated service to be volatile. On 30/10/18 14:25, Daniel Fuchs wrote: > Hi Rob, > > LdapCtxFactory.java > > 187 for (String u : r.getEndpoints()) { > 188 try { > 189 ctx = getLdapCtxFromUrl( > 190 r.getDomainName(), new LdapURL(u), env); > 191 } catch (NamingException e) { > 192 // try the next element > 193 lastException = e; > 194 } > 195 } > > is a break statement missing after line 190? > > If not then can you add a comment explaining why only the last > context is retained (and returned?) > > Alternatively, if a break is indeed missing, these three lines > could be moved into the for loop above: > > 206 // Record the URL that created the context > 207 ctx.setProviderUrl(url); > 208 return ctx; > > and maybe lines 206-207 could be moved into the > getLdapCtxFromUrl() method? > Yes, you're right, we should return the first successful result. > LdapDnsProviderService.java: > > Why is this class non final? If it can be made final then > the protected methods should probably become package. > Good point, fixed. > LdapDnsProvider.java: > > It is strange to see new APIs with Hashtable in the method > signature. I understand that our implementation will need > an Hashtable at some point to call javax.naming.spi.NamingProvider, > but how likely is it that a clean room implementation of > a LdapDnsProvider will need to do that? > > Maybe we could have Map in the signature instead - and > leave the burden to our implementation - somewhere in ServiceLocator, > to adapt back to Hashtable where it needs to? So I've altered the signature of the method to take a Map as proposed. I've added a getLdapService(String domainName, Map environment) method to ServiceLocator which delegates to the existing method after conversion. Hopefully this addresses your concerns. I'll update the CSR accordingly once this review is complete. -Rob > > > best regards, > > -- daniel > > > On 25/10/2018 17:34, Rob McKenna wrote: > > This recently received CSR approval, so it seems like a good time to pick > > the codereview up again: > > > > http://cr.openjdk.java.net/~robm/8160768/webrev.08/ > > > > Referencing: > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050794.html > > > > 1) I'm copying the behaviour from > > LdapCtxFactory.getInitialContext(Hashtable) where an empty String is > > the default value used when the provider url is null. > > > > I don't think HostnameChecker (by way of SNIHostname) will accept either > > empty or null values when doing the comparison. > > > > Somewhat oddly however, LdapCtx.extendedOperation(ExtendedRequest) > > appears to pass the String "null" to > > StartTlsResponseImpl.setConnection(Connection, String), which attempts > > to substitute null values with the Connections host so there may be a bug > > here. > > > > I'm happy to allow null returns here if necessary. Sean, can you > > comment on the distinction between null & "" as far as hostname > > verification is concerned? > > > > 2) In the latest iteration lookupEndpoints() returns an > > Optional. Currently neither getEndpoints() nor > > getDomainName() can be null. (they can be an empty list and/or an empty > > String however) > > > > 3) Corrected. > > > > 4) See https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 > > > > -Rob > > > From Roger.Riggs at oracle.com Tue Nov 6 16:17:03 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 6 Nov 2018 11:17:03 -0500 Subject: RFR 8185496: Improve performance of system properties initialization in initPhase1 Message-ID: <4254eaf0-1967-b9a4-783e-83649d020698@oracle.com> While working to reduce startup time initializing properties, a pair of improvements are proposed. 8185496: Improve performance of system properties initialization in initPhase1 [1] 8213424: VersionProps duplicate initialization [2] 1) The overhead of providing default values in native is reduced by applying the defaults ??? when first used and leaving the properties undefined unless there is ??? an OS supplied value or a -D command line argument 2) Two tests for properties are combined into a more complete test webrev: http://cr.openjdk.java.net/~rriggs/webrev-props-cleanup-8185496/ Issues: [1] https://bugs.openjdk.java.net/browse/JDK-8185496 [2] https://bugs.openjdk.java.net/browse/JDK-8213424 Thanks for any comments and suggestions, Roger From daniel.fuchs at oracle.com Tue Nov 6 16:39:59 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Nov 2018 16:39:59 +0000 Subject: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider In-Reply-To: <20181106155203.GA15048@vimes> References: <20181025163435.GB4374@vimes> <4b152645-3702-272c-b351-5a279573634d@oracle.com> <20181106155203.GA15048@vimes> Message-ID: Hi Rob, Assuming the new webrev is: http://cr.openjdk.java.net/~robm/8160768/webrev.09 then it looks much better to me. I haven't re-reviewed everything in details - just looked at the updates (LdapDnsProviderService, LdapDnsProvider signature change, ServiceLocator) BTW: if I'm not mistaken returning an empty Optional is equivalent, in the end, to returning an Optional containing a LdapDnsProviderResult which returns an empty list of endpoints? I guess that's OK, I don't see any value in preventing an LdapDnsProviderResult to have an empty endpoint list anyway. best regards, -- daniel On 06/11/2018 15:52, Rob McKenna wrote: > Thanks folks, > > Vyom, I've updated service to be volatile. > > On 30/10/18 14:25, Daniel Fuchs wrote: >> Hi Rob, >> >> LdapCtxFactory.java >> >> 187 for (String u : r.getEndpoints()) { >> 188 try { >> 189 ctx = getLdapCtxFromUrl( >> 190 r.getDomainName(), new LdapURL(u), env); >> 191 } catch (NamingException e) { >> 192 // try the next element >> 193 lastException = e; >> 194 } >> 195 } >> >> is a break statement missing after line 190? >> >> If not then can you add a comment explaining why only the last >> context is retained (and returned?) >> >> Alternatively, if a break is indeed missing, these three lines >> could be moved into the for loop above: >> >> 206 // Record the URL that created the context >> 207 ctx.setProviderUrl(url); >> 208 return ctx; >> >> and maybe lines 206-207 could be moved into the >> getLdapCtxFromUrl() method? >> > > Yes, you're right, we should return the first successful result. > >> LdapDnsProviderService.java: >> >> Why is this class non final? If it can be made final then >> the protected methods should probably become package. >> > > Good point, fixed. > >> LdapDnsProvider.java: >> >> It is strange to see new APIs with Hashtable in the method >> signature. I understand that our implementation will need >> an Hashtable at some point to call javax.naming.spi.NamingProvider, >> but how likely is it that a clean room implementation of >> a LdapDnsProvider will need to do that? >> >> Maybe we could have Map in the signature instead - and >> leave the burden to our implementation - somewhere in ServiceLocator, >> to adapt back to Hashtable where it needs to? > > So I've altered the signature of the method to take a Map as > proposed. I've added a getLdapService(String domainName, Map environment) > method to ServiceLocator which delegates to the existing method after > conversion. Hopefully this addresses your concerns. > > I'll update the CSR accordingly once this review is complete. > > -Rob > >> >> >> best regards, >> >> -- daniel >> >> >> On 25/10/2018 17:34, Rob McKenna wrote: >>> This recently received CSR approval, so it seems like a good time to pick >>> the codereview up again: >>> >>> http://cr.openjdk.java.net/~robm/8160768/webrev.08/ >>> >>> Referencing: >>> >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050794.html >>> >>> 1) I'm copying the behaviour from >>> LdapCtxFactory.getInitialContext(Hashtable) where an empty String is >>> the default value used when the provider url is null. >>> >>> I don't think HostnameChecker (by way of SNIHostname) will accept either >>> empty or null values when doing the comparison. >>> >>> Somewhat oddly however, LdapCtx.extendedOperation(ExtendedRequest) >>> appears to pass the String "null" to >>> StartTlsResponseImpl.setConnection(Connection, String), which attempts >>> to substitute null values with the Connections host so there may be a bug >>> here. >>> >>> I'm happy to allow null returns here if necessary. Sean, can you >>> comment on the distinction between null & "" as far as hostname >>> verification is concerned? >>> >>> 2) In the latest iteration lookupEndpoints() returns an >>> Optional. Currently neither getEndpoints() nor >>> getDomainName() can be null. (they can be an empty list and/or an empty >>> String however) >>> >>> 3) Corrected. >>> >>> 4) See https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 >>> >>> -Rob >>> >> From Roger.Riggs at oracle.com Tue Nov 6 16:55:31 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 6 Nov 2018 11:55:31 -0500 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5cd29d6a-6e57-9d44-3c7c-f717dd304884@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> <5BCA21B9.7040304@oracle.com> <5cd29d6a-6e57-9d44-3c7c-f717dd304884@oracle.com> Message-ID: +1 Though with 65 tests, I suspect that there are more cases than strictly needed to cover all the code flows. For example, three cases for testing when it is the same file doesn't seem necessary. Regards, Roger On 11/05/2018 11:27 PM, Stuart Marks wrote: > On 10/19/18 11:26 AM, Joe Wang wrote: >> Current version: >> http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/ > > Hi Joe, > > Thanks for updating the tests per my comments. Everything looks good now! > > s'marks From rob.mckenna at oracle.com Tue Nov 6 17:32:19 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 6 Nov 2018 17:32:19 +0000 Subject: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider In-Reply-To: References: <20181025163435.GB4374@vimes> <4b152645-3702-272c-b351-5a279573634d@oracle.com> <20181106155203.GA15048@vimes> Message-ID: <20181106173219.GB15048@vimes> You've cracked my elabourate webrev naming scheme. Thanks Daniel, On 06/11/18 16:39, Daniel Fuchs wrote: > Hi Rob, > > Assuming the new webrev is: > > http://cr.openjdk.java.net/~robm/8160768/webrev.09 > > then it looks much better to me. > > I haven't re-reviewed everything in details - just looked > at the updates (LdapDnsProviderService, > LdapDnsProvider signature change, ServiceLocator) > Yep, apart from the volatile service nothing else has changed. > BTW: if I'm not mistaken returning an empty Optional is > equivalent, in the end, to returning an Optional containing > a LdapDnsProviderResult which returns an empty list of endpoints? > I guess that's OK, I don't see any value in preventing an > LdapDnsProviderResult to have an empty endpoint list anyway. > Basically, yes. Thanks, -Rob > best regards, > > -- daniel > > > On 06/11/2018 15:52, Rob McKenna wrote: > > Thanks folks, > > > > Vyom, I've updated service to be volatile. > > > > On 30/10/18 14:25, Daniel Fuchs wrote: > > > Hi Rob, > > > > > > LdapCtxFactory.java > > > > > > 187 for (String u : r.getEndpoints()) { > > > 188 try { > > > 189 ctx = getLdapCtxFromUrl( > > > 190 r.getDomainName(), new LdapURL(u), env); > > > 191 } catch (NamingException e) { > > > 192 // try the next element > > > 193 lastException = e; > > > 194 } > > > 195 } > > > > > > is a break statement missing after line 190? > > > > > > If not then can you add a comment explaining why only the last > > > context is retained (and returned?) > > > > > > Alternatively, if a break is indeed missing, these three lines > > > could be moved into the for loop above: > > > > > > 206 // Record the URL that created the context > > > 207 ctx.setProviderUrl(url); > > > 208 return ctx; > > > > > > and maybe lines 206-207 could be moved into the > > > getLdapCtxFromUrl() method? > > > > > > > Yes, you're right, we should return the first successful result. > > > > > LdapDnsProviderService.java: > > > > > > Why is this class non final? If it can be made final then > > > the protected methods should probably become package. > > > > > > > Good point, fixed. > > > > > LdapDnsProvider.java: > > > > > > It is strange to see new APIs with Hashtable in the method > > > signature. I understand that our implementation will need > > > an Hashtable at some point to call javax.naming.spi.NamingProvider, > > > but how likely is it that a clean room implementation of > > > a LdapDnsProvider will need to do that? > > > > > > Maybe we could have Map in the signature instead - and > > > leave the burden to our implementation - somewhere in ServiceLocator, > > > to adapt back to Hashtable where it needs to? > > > > So I've altered the signature of the method to take a Map as > > proposed. I've added a getLdapService(String domainName, Map environment) > > method to ServiceLocator which delegates to the existing method after > > conversion. Hopefully this addresses your concerns. > > > > I'll update the CSR accordingly once this review is complete. > > > > -Rob > > > > > > > > > > > best regards, > > > > > > -- daniel > > > > > > > > > On 25/10/2018 17:34, Rob McKenna wrote: > > > > This recently received CSR approval, so it seems like a good time to pick > > > > the codereview up again: > > > > > > > > http://cr.openjdk.java.net/~robm/8160768/webrev.08/ > > > > > > > > Referencing: > > > > > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050794.html > > > > > > > > 1) I'm copying the behaviour from > > > > LdapCtxFactory.getInitialContext(Hashtable) where an empty String is > > > > the default value used when the provider url is null. > > > > > > > > I don't think HostnameChecker (by way of SNIHostname) will accept either > > > > empty or null values when doing the comparison. > > > > > > > > Somewhat oddly however, LdapCtx.extendedOperation(ExtendedRequest) > > > > appears to pass the String "null" to > > > > StartTlsResponseImpl.setConnection(Connection, String), which attempts > > > > to substitute null values with the Connections host so there may be a bug > > > > here. > > > > > > > > I'm happy to allow null returns here if necessary. Sean, can you > > > > comment on the distinction between null & "" as far as hostname > > > > verification is concerned? > > > > > > > > 2) In the latest iteration lookupEndpoints() returns an > > > > Optional. Currently neither getEndpoints() nor > > > > getDomainName() can be null. (they can be an empty list and/or an empty > > > > String however) > > > > > > > > 3) Corrected. > > > > > > > > 4) See https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 > > > > > > > > -Rob > > > > > > > > From andrewluotechnologies at outlook.com Tue Nov 6 18:27:38 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 6 Nov 2018 18:27:38 +0000 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> <5BCA21B9.7040304@oracle.com> <5cd29d6a-6e57-9d44-3c7c-f717dd304884@oracle.com> Message-ID: I'm not a reviewer, but just wanted to point out that the fully qualified Files.BUFFER_SIZE can be simplified to just BUFFER_SIZE. Searching through the code in Files.java I don't see many other instances of using Files.* (although I do see a few). Thanks Andrew -----Original Message----- From: core-libs-dev On Behalf Of Roger Riggs Sent: Tuesday, November 6, 2018 8:56 AM To: core-libs-dev at openjdk.java.net Subject: Re: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents +1 Though with 65 tests, I suspect that there are more cases than strictly needed to cover all the code flows. For example, three cases for testing when it is the same file doesn't seem necessary. Regards, Roger On 11/05/2018 11:27 PM, Stuart Marks wrote: > On 10/19/18 11:26 AM, Joe Wang wrote: >> Current version: >> http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/ > > Hi Joe, > > Thanks for updating the tests per my comments. Everything looks good now! > > s'marks From kasperni at gmail.com Tue Nov 6 18:48:01 2018 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 6 Nov 2018 18:48:01 +0000 Subject: Problems with ElementType.TYPE_USE and reflection Message-ID: Hi, I'm trying to understand exactly how ElementType.TYPE_USE should work. I'm asking because the following program only prints that s has one 2 annotation. I believe it should either print 3 or be flagged at compilation time. public class TestClass { @X @Y @Z String s; public static void main(String[] args) throws Exception { System.out.println(TestClass.class.getDeclaredField("s").getAnnotations().length); } @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE_USE) @interface X {} @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.FIELD) @interface Y {} @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.FIELD, ElementType.TYPE_USE }) @interface Z {} } ElementType.TYPE_USE alone isn't enough for the annotation information to be retained at runtime. /Kasper From huizhe.wang at oracle.com Tue Nov 6 20:32:24 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 06 Nov 2018 12:32:24 -0800 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5cd29d6a-6e57-9d44-3c7c-f717dd304884@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> <5BCA21B9.7040304@oracle.com> <5cd29d6a-6e57-9d44-3c7c-f717dd304884@oracle.com> Message-ID: <5BE1FA58.3000909@oracle.com> Thanks Stuart! I'm glad it's finally close to the end :-) On 11/5/18, 8:27 PM, Stuart Marks wrote: > On 10/19/18 11:26 AM, Joe Wang wrote: >> Current version: >> http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/ > > Hi Joe, > > Thanks for updating the tests per my comments. Everything looks good now! > > s'marks From huizhe.wang at oracle.com Tue Nov 6 20:51:42 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 06 Nov 2018 12:51:42 -0800 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> <5BCA21B9.7040304@oracle.com> <5cd29d6a-6e57-9d44-3c7c-f717dd304884@oracle.com> Message-ID: <5BE1FEDE.6040405@oracle.com> On 11/6/18, 8:55 AM, Roger Riggs wrote: > +1 > > Though with 65 tests, I suspect that there are more cases than > strictly needed > to cover all the code flows. > For example, three cases for testing when it is the same file doesn't > seem necessary. Removed one of the three cases, leaving one edge case (non-existent) and one normal. Removed all but two that verifies the edge case where one of the file sizes is zero, see line 173 and 174. Removed most of the large files (1MB). The redundancy is not strictly necessary, the ones with 64kb are sufficient for verifying matching after a few iterations. All together, that reduced the tests from 65 to 46. http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v07/ Thanks, Joe > > Regards, Roger > > On 11/05/2018 11:27 PM, Stuart Marks wrote: >> On 10/19/18 11:26 AM, Joe Wang wrote: >>> Current version: >>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/ >> >> Hi Joe, >> >> Thanks for updating the tests per my comments. Everything looks good >> now! >> >> s'marks > From huizhe.wang at oracle.com Tue Nov 6 20:53:49 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 06 Nov 2018 12:53:49 -0800 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> <5BCA21B9.7040304@oracle.com> <5cd29d6a-6e57-9d44-3c7c-f717dd304884@oracle.com> Message-ID: <5BE1FF5D.2040909@oracle.com> Thanks Andrew for pointing that out. It wasn't intentional, a result of copy n paste after removing the support class. It's fixed now: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v07/ -Joe On 11/6/18, 10:27 AM, Andrew Luo wrote: > I'm not a reviewer, but just wanted to point out that the fully qualified Files.BUFFER_SIZE can be simplified to just BUFFER_SIZE. Searching through the code in Files.java I don't see many other instances of using Files.* (although I do see a few). > > Thanks > Andrew > > -----Original Message----- > From: core-libs-dev On Behalf Of Roger Riggs > Sent: Tuesday, November 6, 2018 8:56 AM > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents > > +1 > > Though with 65 tests, I suspect that there are more cases than strictly needed to cover all the code flows. > For example, three cases for testing when it is the same file doesn't seem necessary. > > Regards, Roger > > On 11/05/2018 11:27 PM, Stuart Marks wrote: >> On 10/19/18 11:26 AM, Joe Wang wrote: >>> Current version: >>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/ >> Hi Joe, >> >> Thanks for updating the tests per my comments. Everything looks good now! >> >> s'marks From brian.burkhalter at oracle.com Tue Nov 6 21:30:35 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 6 Nov 2018 13:30:35 -0800 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <24AED235-0964-46C6-9DCE-F25FA4C10B0B@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> <78433376-a509-f430-e65b-f895b3e39555@oracle.com> <335F1219-8FE9-4536-9270-FAE44CAB0703@oracle.com> <7cf3cd94-6790-5382-529c-2bcdec5504b9@oracle.com> <0b0e8445-50f3-01fc-7806-10c849d93594@oracle.com> <24AED235-0964-46C6-9DCE-F25FA4C10B0B@oracle.com> Message-ID: <06EB9C72-8249-4265-9BE9-EBA978F56B43@oracle.com> Hello again, I updated the patch to address the comments made by Roger and Daniel: http://cr.openjdk.java.net/~bpb/6516099/webrev.05/ Specifically, the method is implemented in terms of skip() and read() and attempts to account for the possible behaviors of the former, and most of the specification is moved to an @implSpec block. The tests are intentionally not updated until such time as agreement on the method itself might be achieved. Thanks, Brian From david.holmes at oracle.com Tue Nov 6 21:52:18 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Nov 2018 07:52:18 +1000 Subject: RFR 8185496: Improve performance of system properties initialization in initPhase1 In-Reply-To: <4254eaf0-1967-b9a4-783e-83649d020698@oracle.com> References: <4254eaf0-1967-b9a4-783e-83649d020698@oracle.com> Message-ID: <3279b711-1fb3-de6b-991f-22263482c33f@oracle.com> Hi Roger, On 7/11/2018 2:17 AM, Roger Riggs wrote: > While working to reduce startup time initializing properties, a pair of > improvements are proposed. > > 8185496: Improve performance of system properties initialization in > initPhase1 [1] > 8213424: VersionProps duplicate initialization [2] > > 1) The overhead of providing default values in native is reduced by > applying the defaults > ??? when first used and leaving the properties undefined unless there is > ??? an OS supplied value or a -D command line argument Looking at the hotspot change for setting sun.nio.MaxDirectMemorySize I don't really understand the change. In the current code we will always set the property even if the value -1 means it is "unset". Your change wants to exclude it completely in the default case as an optimisation, yet to do that you have to perform far more work in the VM examining every key to see if we need to skip a -D set value. That seems counter-productive on the surface. What is the actual performance change here? Thanks, David > 2) Two tests for properties are combined into a more complete test > > webrev: > > http://cr.openjdk.java.net/~rriggs/webrev-props-cleanup-8185496/ > > Issues: > [1] https://bugs.openjdk.java.net/browse/JDK-8185496 > [2] https://bugs.openjdk.java.net/browse/JDK-8213424 > > Thanks for any comments and suggestions, Roger > > > From Roger.Riggs at oracle.com Tue Nov 6 22:13:24 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 6 Nov 2018 17:13:24 -0500 Subject: RFR 8185496: Improve performance of system properties initialization in initPhase1 In-Reply-To: <3279b711-1fb3-de6b-991f-22263482c33f@oracle.com> References: <4254eaf0-1967-b9a4-783e-83649d020698@oracle.com> <3279b711-1fb3-de6b-991f-22263482c33f@oracle.com> Message-ID: <71b74e9f-c994-c195-c73e-e65bd20c9b55@oracle.com> Hi David, On 11/06/2018 04:52 PM, David Holmes wrote: > Hi Roger, > > On 7/11/2018 2:17 AM, Roger Riggs wrote: >> While working to reduce startup time initializing properties, a pair >> of improvements are proposed. >> >> 8185496: Improve performance of system properties initialization in >> initPhase1 [1] >> 8213424: VersionProps duplicate initialization [2] >> >> 1) The overhead of providing default values in native is reduced by >> applying the defaults >> ???? when first used and leaving the properties undefined unless >> there is >> ???? an OS supplied value or a -D command line argument > > Looking at the hotspot change for setting sun.nio.MaxDirectMemorySize > I don't really understand the change. In the current code we will > always set the property even if the value -1 means it is "unset". Your > change wants to exclude it completely in the default case as an > optimisation, yet to do that you have to perform far more work in the > VM examining every key to see if we need to skip a -D set value. That > seems counter-productive on the surface. What is the actual > performance change here? The goal is to not have default values assigned in native so they can be handled at the same point where a decision is made in VM.getSavedProperties. If? the property has any value, it has to create the string and invoke Properties.put which is a bunch more instructions than a few strcmp's in native. (though it is proportional to the number of properties.) And it would cleaner still if the MaxDirectMemorySize wasn't passed as a property but that's the current implementation mechanism. Further cleanup is possible. The ignoring of a -D has to be handled somewhere, and it is more efficient to do it early. In retrospect, I would much have preferred that sun.nio.maxDirectMemorySize had just be left as a normal -D property and left all the clever parsing to the java code.? (But I wasn't involved in that). I have a future change to replace the Property.put upcalls, but just dropping any unnecessary properties is a small step. Thanks, Roger > > Thanks, > David > >> 2) Two tests for properties are combined into a more complete test >> >> webrev: >> >> http://cr.openjdk.java.net/~rriggs/webrev-props-cleanup-8185496/ >> >> Issues: >> [1] https://bugs.openjdk.java.net/browse/JDK-8185496 >> [2] https://bugs.openjdk.java.net/browse/JDK-8213424 >> >> Thanks for any comments and suggestions, Roger >> >> >> From joe.darcy at oracle.com Wed Nov 7 00:10:06 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 06 Nov 2018 16:10:06 -0800 Subject: Problems with ElementType.TYPE_USE and reflection In-Reply-To: References: Message-ID: <5BE22D5E.7000804@oracle.com> Hello, To get the type annotations on a field you would have to use field.getAnnotatedType().getAnnotations(); See https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/reflect/Field.html#getAnnotatedType() Calling getAnnotations on a field returns the declaration annotations. HTH, -Joe On 11/6/2018 10:48 AM, Kasper Nielsen wrote: > Hi, > > I'm trying to understand exactly how ElementType.TYPE_USE should work. > > I'm asking because the following program only prints that s has one 2 > annotation. > I believe it should either print 3 or be flagged at compilation time. > > public class TestClass { > > @X > @Y > @Z > String s; > > public static void main(String[] args) throws Exception { > > System.out.println(TestClass.class.getDeclaredField("s").getAnnotations().length); > } > > @Retention(RetentionPolicy.RUNTIME) > @Target(ElementType.TYPE_USE) > @interface X {} > > @Retention(RetentionPolicy.RUNTIME) > @Target(ElementType.FIELD) > @interface Y {} > > @Retention(RetentionPolicy.RUNTIME) > @Target({ ElementType.FIELD, ElementType.TYPE_USE }) > @interface Z {} > } > > ElementType.TYPE_USE alone isn't enough for the annotation information to > be retained at runtime. > > /Kasper From ivan.gerasimov at oracle.com Wed Nov 7 00:21:37 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 6 Nov 2018 16:21:37 -0800 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BE1FF5D.2040909@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> <5BCA21B9.7040304@oracle.com> <5cd29d6a-6e57-9d44-3c7c-f717dd304884@oracle.com> <5BE1FF5D.2040909@oracle.com> Message-ID: Hi Joe! I apologize, if it was already discussed before. Why do you need to have 3 edge cases of nRead1 and nRead2 in lines 1596-1605: Was it to save a call to Arrays.mismatch()? If I'm not mistaken, the code would work equally well, if lines 1596-1615 were replaced with just subrange 1606-1614. With kind regards, Ivan On 11/6/18 12:53 PM, Joe Wang wrote: > Thanks Andrew for pointing that out. It wasn't intentional, a result > of copy n paste after removing the support class. It's fixed now: > http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v07/ > > -Joe > > On 11/6/18, 10:27 AM, Andrew Luo wrote: >> I'm not a reviewer, but just wanted to point out that the fully >> qualified Files.BUFFER_SIZE can be simplified to just BUFFER_SIZE. >> Searching through the code in Files.java I don't see many other >> instances of using Files.* (although I do see a few). >> >> Thanks >> Andrew >> >> -----Original Message----- >> From: core-libs-dev On >> Behalf Of Roger Riggs >> Sent: Tuesday, November 6, 2018 8:56 AM >> To: core-libs-dev at openjdk.java.net >> Subject: Re: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for >> comparing file contents >> >> +1 >> >> Though with 65 tests, I suspect that there are more cases than >> strictly needed to cover all the code flows. >> For example, three cases for testing when it is the same file doesn't >> seem necessary. >> >> Regards, Roger >> >> On 11/05/2018 11:27 PM, Stuart Marks wrote: >>> On 10/19/18 11:26 AM, Joe Wang wrote: >>>> Current version: >>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/ >>> Hi Joe, >>> >>> Thanks for updating the tests per my comments. Everything looks good >>> now! >>> >>> s'marks > -- With kind regards, Ivan Gerasimov From joe.darcy at oracle.com Wed Nov 7 05:59:48 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 6 Nov 2018 21:59:48 -0800 Subject: JDK 12 RFR of JDK-8213444: Missing emphasis for term being defined Message-ID: Hello, Please review the small change to address ??? JDK-8213444: Missing emphasis for term being defined ??? http://cr.openjdk.java.net/~darcy/8213444.0/ Patch below. The emphasis markup is added to the "present" term in symmetry with the other terms being defined. Additionally, the formatting of some text in a {@code } structure is improved. The analogous list of definitions in javax.lang.model.AnnotatedConstruct already use emphasis for all the defined terms. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/reflect/AnnotatedElement.java 2018-11-06 21:55:58.195000000 -0800 +++ new/src/java.base/share/classes/java/lang/reflect/AnnotatedElement.java 2018-11-06 21:55:58.027000000 -0800 @@ -74,7 +74,7 @@ ? * exactly one annotation whose value element contains A and whose ? * type is the containing annotation type of A 's type. ? * - *
  • An annotation A is present on an element E if either: + *
  • An annotation A is present on an element E if either: ? * ? *