From mandy.chung at oracle.com Wed Apr 1 03:01:10 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2020 20:01:10 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> Thanks to the review feedbacks. Updated webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ Delta between webrev.03 and webrev.04: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ Summary of changes is: 1. Update javac to retain the previous behavior when compiling to target release <= 14 where lambda proxy class is not a nestmate 2. Rename Class::isHiddenClass to Class::isHidden 3. Address Joe's feedback on the CSR to document the behavior of the relevant methods in java.lang.Class for hidden classes 4. Add test case for unloadable class with nest host error 5. Add test cases for hidden classes with different kinds of class or interface 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class" 7. Small changes in response to Remi, Coleen, Paul's review comments 8. Fix copyright headers 9. Fix @modules in tests Most of the changes above have also been reviewed as separate patches. Thanks Mandy On 3/26/20 4:57 PM, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From Alan.Bateman at oracle.com Wed Apr 1 14:26:08 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Apr 2020 15:26:08 +0100 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <940c6907-612e-8744-376c-5362991d4a42@oracle.com> Message-ID: On 31/03/2020 20:25, Mandy Chung wrote: > Alex's feedback:? rename isHiddenClass to isHidden as it can be a > hidden class or interface. > > `isLocalClass` and `sAnonymousClass` are correct because the Java > language only has local classes and anon classes, not local interfaces > or anon. interfaces.? `isHidden` is like `isSynthetic`, it could be a > class or interface. > > Although isHiddenClass seems clearer, I'm okay to rename it to > `isHidden`. I went through the java.base changes in webrev.03-delta. The rename to isHidden and the updated javadoc looks good. There are a few additional drive-by updates to the javadoc, including isSynthetic, they all look good too. Maybe I missed it going by, but why is the isHidden check in the field offset methods on sun.misc.Unsafe rather than the internal Unsafe? -Alan. From mandy.chung at oracle.com Wed Apr 1 17:42:57 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Apr 2020 10:42:57 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <940c6907-612e-8744-376c-5362991d4a42@oracle.com> Message-ID: On 4/1/20 7:26 AM, Alan Bateman wrote: > Maybe I missed it going by, but why is the isHidden check in the field > offset methods on sun.misc.Unsafe rather than the internal Unsafe? The reflection and VarHandle implementation uses jdk.internal.misc.Unsafe to do field access (both read and write). For fields of a hidden declaring class, Field::get works on final and non-final fields.? Field::set will work on non-final fields and throw IAE on final fields.?? That's why no change to the internal Unsafe to support reflective field access. The check in the field offset methods in `sun.misc.Unsafe` intends to constrain the existing use of jdk.unsupported unsafe field offset methods to existing classes but not hidden classes (perhaps same to apply to inline classes) moving toward "trusted non-instance finals". Mandy From mandy.chung at oracle.com Thu Apr 2 00:09:00 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Apr 2020 17:09:00 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? Message-ID: Hi Brian, et al, Class is a Constable.? So a Class object for a hidden class can be asked to yield a ConstantDesc for the hidden class via Class::describeConstable.? It can also be asked to get the type descriptor string for the hidden class via Class:descriptorString. A hidden class has no binary name. It cannot be referenced by other classes nominally. So hidden classes are not the kind of run-time entities of interest to the bytecode readers and writers.? I propose no ClassDesc for hidden classes. The relevant APIs need update for hidden classes are: 1. ClassDesc::ofDescriptor The current spec already specifies to throw IAE if the given name is not a binary name. 2. Class::describeConstable There should be no ClassDesc for hidden classes.ClassDesc::ofDescriptor returns an empty Optional if it's a hidden class. 3. Class::descriptorString (inherited method fromTypeDescriptor) Three options: a) throws an exception b) returns null c) returns `La/b/C.0x1234;` `Lookup:defineHiddenClass` specifies the name derived from the `class` file in the form of: ? ? `N` + "." + where N is the binary name indicated by the `class` file and is an unqualified name that is guaranteed to be unique during this execution of the JVM. But this is not a valid binary name; so not a field descriptor. This has a bigger impact to java.lang.constant. None of the options is ideal.? I lean toward (b).? It's rare that a compiler or other tools using java.lang.constant API will use it on a hidden class. Please advise. Thanks Mandy [1] http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...) From john.r.rose at oracle.com Thu Apr 2 00:38:44 2020 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Apr 2020 17:38:44 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: References: Message-ID: Thanks for catching this. Brian will probably observe that the ClassDesc is not enough to recover the class, since it needs a ClassLoader also. A class whose CL is hard to deduce might be called an ?elusive class?. The practical difference between a hidden class and an elusive class is that hidden classes are completely elusive: You cannot find a CL that will produce one. Treating the Constable API differently in these cases amounts to differentiating between ?partially elusive or well known? vs. ?completely elusive? (aka hidden). This kind of argues me into the position that there?s not a big advantage (and perhaps some disadvantage) to error-checking the constable description of a HC. Thus, I think I prefer the regularity which lumps HCs with other elusive classes, with this option: > c) returns `La/b/C.0x1234;` This bit is slightly surprising to me: > is an unqualified name that is guaranteed to be unique during this execution of the JVM It started out as an identity hash code, so it was usually but not guaranteed unique. Is there a cost to this guarantee? Do we just have a 64-bit atomic counter? What if that overflows? I would prefer not to guarantee uniqueness because that?s extra work and it tempts users to misuse it (as a secret namespace). ? John From mandy.chung at oracle.com Thu Apr 2 01:19:29 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Apr 2020 18:19:29 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: References: Message-ID: On 4/1/20 5:38 PM, John Rose wrote: >> is an unqualified name that is guaranteed to be unique during this execution of the JVM > It started out as an identity hash code, so it was usually but not guaranteed > unique. Is there a cost to this guarantee? Do we just have a 64-bit atomic > counter? What if that overflows? I would prefer not to guarantee uniqueness > because that?s extra work and it tempts users to misuse it (as a secret > namespace). I started with an unique name within the namespace of a class loader and later proposed as during the execution of JVM. ? The implementation is using a pointer address in the VM (not a counter).?? Making the uniqueness as a quarantee during the execution of JVM is flaw as you point out. What about: The hidden class's name `N + "/" + ` is guaranteed to be unique among live classes at runtime. The unique names among the classes would help the diagnosability. (we want hidden classes untie with class loaders and so uniqueness among live classes rather than classes defined by the same class loader). I file https://bugs.openjdk.java.net/browse/JDK-8242012 to track this issue. Mandy From john.r.rose at oracle.com Thu Apr 2 02:34:37 2020 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Apr 2020 19:34:37 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: References: Message-ID: On Apr 1, 2020, at 6:19 PM, Mandy Chung wrote: > > I started with an unique name within the namespace of a class loader and later proposed as during the execution of JVM. The implementation is using a pointer address in the VM (not a counter). Making the uniqueness as a quarantee during the execution of JVM is flaw as you point out. > > What about: > The hidden class's name `N + "/" + ` is guaranteed to be unique among live classes at runtime. > > The unique names among the classes would help the diagnosability. (we want hidden classes untie with class loaders and so uniqueness among live classes rather than classes defined by the same class loader). > > I file https://bugs.openjdk.java.net/browse/JDK-8242012 to track this issue. I would prefer to say that the suffix is simply an unspecified simple name. Then leave it open for implementations to make it more or less unpredictable, as a matter of QoS. The standard of quality we should aim at is that of System.identityHashCode?nothing much more than that is desirable, and it?s easy to get at least that much quality. The java doc for Object.hashCode says this about the QoS I want here: > * As far as is reasonably practical, the {@code hashCode} method defined > * by class {@code Object} returns distinct integers for distinct objects. So, the behavior I would like to keep open is something that cannot readily be distinguished from functions like these? static String nextSuffix1() { return new Integer.toHexString(Object().hashCode()); } static String nextSuffix2() { return new Integer.toUnsignedString(Object().hashCode(), 36); } static String nextSuffix3() { return nextSuffix1()+nextSuffix2(); } ?and many others. And I would settle for nextSuffix1, which (after all) is also a suffix of the already specified value of new Object().toString(). To me, the result of HC.toString() (where HC is a hidden class) should not be more deeply informative than new Object().toString(). Also, the behavior currently coded (in mangle_hidden_class_name) is consistent with nextSuffix1. (Observation: The JVM has no reason to choose this suffix, beyond the simple reason that it is the first party to peek into the byte[] array of the classfile image. It would be nice if the JDK platform code could take responsibility for generating that extra suffix; it would make QoS adjustments easier down the road. We could even go all the way and guarantee that all such suffixes are truly unique; it would be a page of Java code but several pages of HotSpot code. But, that?s inconvenient, so I don?t recommend that now.) A parting shot: Yes, technically the implementation of the suffix choosing (mangle_hidden_class_name) probably upholds almost the full guarantee. (Although, it can fail if the JVM unloads and reloads a HC of the same name at the same metadata address.) But if we make the full guarantee part of the API, we set ourselves up to maintain that strong behavior even if we move to another implementation in which metadata pointers are allowed to change. I know we don?t want to do that, but this is an example of how an overly strong guarantee that seems easy to do in *one* JVM implementation can create headaches for *other* JVM implementations. What?s easy to do in our implementation is *often* close to the right primitive to specify, but we have a responsibility to remove unnecessary promises and other implementation artifacts from our specification. ? John From david.holmes at oracle.com Thu Apr 2 04:52:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 14:52:54 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> Message-ID: <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Hi Mandy, On 1/04/2020 1:01 pm, Mandy Chung wrote: > Thanks to the review feedbacks. > > Updated webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ I've had a good look through all the hotspot related changes. All looks good. A few minor comments: src/hotspot/share/ci/ciField.cpp // Trust VM hidden and unsafe anonymous classes. should say // Trust hidden and VM unsafe anonymous classes. // the private API (jdk.internal.misc.Unsafe) s/the/a/ or else change the () to commas or perhaps even better: // the private jdk.internal.misc.Unsafe API, --- src/hotspot/share/ci/ciInstanceKlass.cpp // VM weak hidden and unsafe anonymous classes should say // weak hidden and VM unsafe anonymous classes --- src/hotspot/share/classfile/classLoaderData.hpp ! // the CLDs lifecycle. For example, a non-strong hidden class or an ... ! // Used for weak hidden classes, unsafe anonymous classes and the There is an inconsistency in terminology, so far most code comments refer to "weak hidden" but now you are using "non-strong hidden". ! for an weak hidden s/an/a/ multiple locations --- src/hotspot/share/interpreter/linkResolver.cpp Can you fix one of my comments please (in two places) :) + // For private access check if there was a problem with nest host would read better as: + // For private access see if there was a problem with nest host --- Thanks, David ------ > Delta between webrev.03 and webrev.04: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ > > Summary of changes is: > 1. Update javac to retain the previous behavior when compiling to target > release <= 14 where lambda proxy class is not a nestmate > 2. Rename Class::isHiddenClass to Class::isHidden > 3. Address Joe's feedback on the CSR to document the behavior of the > relevant methods in java.lang.Class for hidden classes > 4. Add test case for unloadable class with nest host error > 5. Add test cases for hidden classes with different kinds of class or > interface > 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class" > 7. Small changes in response to Remi, Coleen, Paul's review comments > 8. Fix copyright headers > 9. Fix @modules in tests > > Most of the changes above have also been reviewed as separate patches. > > Thanks > Mandy > > On 3/26/20 4:57 PM, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of Class::isHiddenClass), >> JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized >> state (see specdiff and javadoc below for reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From mandy.chung at oracle.com Thu Apr 2 05:17:09 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 05:17:09 +0000 (UTC) Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: Hi David, Thanks for the edits to the comments.?? "weak hidden" were missed to be changed to "non-strong hidden".? Here is the patch fixing the comments. diff --git a/src/hotspot/share/ci/ciField.cpp b/src/hotspot/share/ci/ciField.cpp --- a/src/hotspot/share/ci/ciField.cpp +++ b/src/hotspot/share/ci/ciField.cpp @@ -223,8 +223,8 @@ ?????? holder->is_in_package("jdk/internal/foreign") || holder->is_in_package("jdk/incubator/foreign") || ?????? holder->is_in_package("java/lang")) ???? return true; -? // Trust VM hidden and unsafe anonymous classes. They are created via Lookup.defineClass or -? // the private API (jdk.internal.misc.Unsafe) and can't be serialized, so there is no hacking +? // Trust hidden and VM unsafe anonymous classes. They are created via Lookup.defineClass or +? // the private jdk.internal.misc.Unsafe API and can't be serialized, so there is no hacking ?? // of finals going on with them. ?? if (holder->is_hidden() || holder->is_unsafe_anonymous()) ???? return true; diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp b/src/hotspot/share/ci/ciInstanceKlass.cpp --- a/src/hotspot/share/ci/ciInstanceKlass.cpp +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp @@ -76,7 +76,7 @@ ?? oop holder = ik->klass_holder(); ?? if (ik->class_loader_data()->has_class_mirror_holder()) { ???? // Though ciInstanceKlass records class loader oop, it's not enough to keep -??? // VM weak hidden and unsafe anonymous classes alive (loader == NULL). Klass holder should +??? // non-strong hidden class and VM unsafe anonymous classes alive (loader == NULL). Klass holder should ???? // be used instead. It is enough to record a ciObject, since cached elements are never removed ???? // during ciObjectFactory lifetime. ciObjectFactory itself is created for ???? // every compilation and lives for the whole duration of the compilation. diff --git a/src/hotspot/share/classfile/classLoaderData.hpp b/src/hotspot/share/classfile/classLoaderData.hpp --- a/src/hotspot/share/classfile/classLoaderData.hpp +++ b/src/hotspot/share/classfile/classLoaderData.hpp @@ -127,9 +127,10 @@ ?? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS support) ?? int _keep_alive;???????? // if this CLD is kept alive. -?????????????????????????? // Used for weak hidden classes, unsafe anonymous classes and the +?????????????????????????? // Used for non-strong hidden classes, unsafe anonymous classes and the ??????????????????????????? // boot class loader. _keep_alive does not need to be volatile or -?????????????????????????? // atomic since there is one unique CLD per weak hidden or unsafe anonymous class. +?????????????????????????? // atomic since there is one unique CLD per non-strong hidden class +?????????????????????????? // or unsafe anonymous class. ?? volatile int _claim; // non-zero if claimed, for example during GC traces. ??????????????????????? // To avoid applying oop closure more than once. @@ -242,15 +243,15 @@ ?? } ?? // Returns true if this class loader data is for the system class loader. -? // (Note that the class loader data may be for an weak hidden or unsafe anonymous class) +? // (Note that the class loader data may be for a non-strong hidden class or unsafe anonymous class) ?? bool is_system_class_loader_data() const; ?? // Returns true if this class loader data is for the platform class loader. -? // (Note that the class loader data may be for an weak hidden or unsafe anonymous class) +? // (Note that the class loader data may be for a non-strong hidden class or unsafe anonymous class) ?? bool is_platform_class_loader_data() const; ?? // Returns true if this class loader data is for the boot class loader. -? // (Note that the class loader data may be for an weak hidden unsafe anonymous class) +? // (Note that the class loader data may be for a non-strong hidden class or unsafe anonymous class) ?? inline bool is_boot_class_loader_data() const; ?? bool is_builtin_class_loader_data() const; @@ -271,7 +272,7 @@ ???? return _unloading; ?? } -? // Used to refcount an weak hidden or unsafe anonymous class's CLD in order to +? // Used to refcount a non-strong hidden class's or unsafe anonymous class's CLD in order to ?? // indicate their aliveness. ?? void inc_keep_alive(); ?? void dec_keep_alive(); diff --git a/src/hotspot/share/interpreter/linkResolver.cpp b/src/hotspot/share/interpreter/linkResolver.cpp --- a/src/hotspot/share/interpreter/linkResolver.cpp +++ b/src/hotspot/share/interpreter/linkResolver.cpp @@ -611,7 +611,7 @@ ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() ????????????? ); -??? // For private access check if there was a problem with nest host +??? // For private access see if there was a problem with nest host ???? // resolution, and if so report that as part of the message. ???? if (sel_method->is_private()) { ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); @@ -951,7 +951,7 @@ ????????????? (same_module) ? "" : "; ", ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() ????????????? ); -??? // For private access check if there was a problem with nest host +??? // For private access see if there was a problem with nest host ???? // resolution, and if so report that as part of the message. ???? if (fd.is_private()) { ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); Mandy On 4/1/20 9:52 PM, David Holmes wrote: > Hi Mandy, > > On 1/04/2020 1:01 pm, Mandy Chung wrote: >> Thanks to the review feedbacks. >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >> > > I've had a good look through all the hotspot related changes. All > looks good. > > A few minor comments: > > src/hotspot/share/ci/ciField.cpp > > ?? // Trust VM hidden and unsafe anonymous classes. > > should say > > ?? // Trust hidden and VM unsafe anonymous classes. > > > ? // the private API (jdk.internal.misc.Unsafe) > > s/the/a/? or else change the () to commas or perhaps even better: > > ? // the private jdk.internal.misc.Unsafe API, > > --- > > src/hotspot/share/ci/ciInstanceKlass.cpp > > ? // VM weak hidden and unsafe anonymous classes > > should say > > ? // weak hidden and VM unsafe anonymous classes > > --- > > src/hotspot/share/classfile/classLoaderData.hpp > > !? // the CLDs lifecycle.? For example, a non-strong hidden class or an > ... > !? // Used for weak hidden classes, unsafe anonymous classes and the > > There is an inconsistency in terminology, so far most code comments > refer to "weak hidden" but now you are using "non-strong hidden". > > ! for an weak hidden > > s/an/a/?? multiple locations > > --- > > src/hotspot/share/interpreter/linkResolver.cpp > > Can you fix one of my comments please (in two places) :) > > +???? // For private access check if there was a problem with nest host > > would read better as: > > +???? // For private access see if there was a problem with nest host > > --- > > Thanks, > David > From david.holmes at oracle.com Thu Apr 2 06:21:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 16:21:10 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: Hi Mandy, On 2/04/2020 3:17 pm, Mandy Chung wrote: > Hi David, > > Thanks for the edits to the comments.?? "weak hidden" were missed to be > changed to "non-strong hidden".? Here is the patch fixing the comments. There are 33 cases of "weak hidden" in the patch I reviewed and also some "hidden weak". Should they all be "non-strong hidden" now? In some cases it also appears in variables and associated logic ie.: src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp + _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), I'm not clear how far this terminology change needs to extend ?? Otherwise patch below seems fine. Thanks, David ----- > diff --git a/src/hotspot/share/ci/ciField.cpp > b/src/hotspot/share/ci/ciField.cpp > --- a/src/hotspot/share/ci/ciField.cpp > +++ b/src/hotspot/share/ci/ciField.cpp > @@ -223,8 +223,8 @@ > ?????? holder->is_in_package("jdk/internal/foreign") || > holder->is_in_package("jdk/incubator/foreign") || > ?????? holder->is_in_package("java/lang")) > ???? return true; > -? // Trust VM hidden and unsafe anonymous classes. They are created via > Lookup.defineClass or > -? // the private API (jdk.internal.misc.Unsafe) and can't be > serialized, so there is no hacking > +? // Trust hidden and VM unsafe anonymous classes. They are created via > Lookup.defineClass or > +? // the private jdk.internal.misc.Unsafe API and can't be serialized, > so there is no hacking > ?? // of finals going on with them. > ?? if (holder->is_hidden() || holder->is_unsafe_anonymous()) > ???? return true; > diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp > b/src/hotspot/share/ci/ciInstanceKlass.cpp > --- a/src/hotspot/share/ci/ciInstanceKlass.cpp > +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp > @@ -76,7 +76,7 @@ > ?? oop holder = ik->klass_holder(); > ?? if (ik->class_loader_data()->has_class_mirror_holder()) { > ???? // Though ciInstanceKlass records class loader oop, it's not > enough to keep > -??? // VM weak hidden and unsafe anonymous classes alive (loader == > NULL). Klass holder should > +??? // non-strong hidden class and VM unsafe anonymous classes alive > (loader == NULL). Klass holder should > ???? // be used instead. It is enough to record a ciObject, since > cached elements are never removed > ???? // during ciObjectFactory lifetime. ciObjectFactory itself is > created for > ???? // every compilation and lives for the whole duration of the > compilation. > diff --git a/src/hotspot/share/classfile/classLoaderData.hpp > b/src/hotspot/share/classfile/classLoaderData.hpp > --- a/src/hotspot/share/classfile/classLoaderData.hpp > +++ b/src/hotspot/share/classfile/classLoaderData.hpp > @@ -127,9 +127,10 @@ > ?? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS support) > > ?? int _keep_alive;???????? // if this CLD is kept alive. > -?????????????????????????? // Used for weak hidden classes, unsafe > anonymous classes and the > +?????????????????????????? // Used for non-strong hidden classes, > unsafe anonymous classes and the > ??????????????????????????? // boot class loader. _keep_alive does not > need to be volatile or > -?????????????????????????? // atomic since there is one unique CLD per > weak hidden or unsafe anonymous class. > +?????????????????????????? // atomic since there is one unique CLD per > non-strong hidden class > +?????????????????????????? // or unsafe anonymous class. > > ?? volatile int _claim; // non-zero if claimed, for example during GC > traces. > ??????????????????????? // To avoid applying oop closure more than once. > @@ -242,15 +243,15 @@ > ?? } > > ?? // Returns true if this class loader data is for the system class > loader. > -? // (Note that the class loader data may be for an weak hidden or > unsafe anonymous class) > +? // (Note that the class loader data may be for a non-strong hidden > class or unsafe anonymous class) > ?? bool is_system_class_loader_data() const; > > ?? // Returns true if this class loader data is for the platform class > loader. > -? // (Note that the class loader data may be for an weak hidden or > unsafe anonymous class) > +? // (Note that the class loader data may be for a non-strong hidden > class or unsafe anonymous class) > ?? bool is_platform_class_loader_data() const; > > ?? // Returns true if this class loader data is for the boot class loader. > -? // (Note that the class loader data may be for an weak hidden unsafe > anonymous class) > +? // (Note that the class loader data may be for a non-strong hidden > class or unsafe anonymous class) > ?? inline bool is_boot_class_loader_data() const; > > ?? bool is_builtin_class_loader_data() const; > @@ -271,7 +272,7 @@ > ???? return _unloading; > ?? } > > -? // Used to refcount an weak hidden or unsafe anonymous class's CLD in > order to > +? // Used to refcount a non-strong hidden class's or unsafe anonymous > class's CLD in order to > ?? // indicate their aliveness. > ?? void inc_keep_alive(); > ?? void dec_keep_alive(); > > diff --git a/src/hotspot/share/interpreter/linkResolver.cpp > b/src/hotspot/share/interpreter/linkResolver.cpp > --- a/src/hotspot/share/interpreter/linkResolver.cpp > +++ b/src/hotspot/share/interpreter/linkResolver.cpp > @@ -611,7 +611,7 @@ > ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() > ????????????? ); > > -??? // For private access check if there was a problem with nest host > +??? // For private access see if there was a problem with nest host > ???? // resolution, and if so report that as part of the message. > ???? if (sel_method->is_private()) { > ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); > @@ -951,7 +951,7 @@ > ????????????? (same_module) ? "" : "; ", > ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() > ????????????? ); > -??? // For private access check if there was a problem with nest host > +??? // For private access see if there was a problem with nest host > ???? // resolution, and if so report that as part of the message. > ???? if (fd.is_private()) { > ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); > > Mandy > > On 4/1/20 9:52 PM, David Holmes wrote: >> Hi Mandy, >> >> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>> Thanks to the review feedbacks. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>> >> >> I've had a good look through all the hotspot related changes. All >> looks good. >> >> A few minor comments: >> >> src/hotspot/share/ci/ciField.cpp >> >> ?? // Trust VM hidden and unsafe anonymous classes. >> >> should say >> >> ?? // Trust hidden and VM unsafe anonymous classes. >> >> >> ? // the private API (jdk.internal.misc.Unsafe) >> >> s/the/a/? or else change the () to commas or perhaps even better: >> >> ? // the private jdk.internal.misc.Unsafe API, >> >> --- >> >> src/hotspot/share/ci/ciInstanceKlass.cpp >> >> ? // VM weak hidden and unsafe anonymous classes >> >> should say >> >> ? // weak hidden and VM unsafe anonymous classes >> >> --- >> >> src/hotspot/share/classfile/classLoaderData.hpp >> >> !? // the CLDs lifecycle.? For example, a non-strong hidden class or an >> ... >> !? // Used for weak hidden classes, unsafe anonymous classes and the >> >> There is an inconsistency in terminology, so far most code comments >> refer to "weak hidden" but now you are using "non-strong hidden". >> >> ! for an weak hidden >> >> s/an/a/?? multiple locations >> >> --- >> >> src/hotspot/share/interpreter/linkResolver.cpp >> >> Can you fix one of my comments please (in two places) :) >> >> +???? // For private access check if there was a problem with nest host >> >> would read better as: >> >> +???? // For private access see if there was a problem with nest host >> >> --- >> >> Thanks, >> David >> > From thartmann at openjdk.java.net Thu Apr 2 14:38:05 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 2 Apr 2020 14:38:05 GMT Subject: [lworld] RFR: 8241764: [lworld] TestC2CCalls fails with SIGSEGV in frame::sender_for_compiled_frame Message-ID: Problem: We crash during frame walking because the return address on the stack is incorrect. The stack slot containing the return address was accidentally overwritten when packing value type arguments in the scalarized entry of C1 compiled code. The problem is that even after extending the stack, the same slot that contains the return address might be used for an argument and is therefore overwritten. C2 has "reserved entries" to account for that. Solution: C1 does not have a reserved stack slot for the return address and we therefore shouldn't reuse the callers frame when packing. Always extend the stack enough for packing to have its "own" stack space to lay out arguments. This wastes some stack space but is much simpler than the "reserved entries" solution applied by C2. I've modified the C2CCalls test to reliable reproduce this issue by sometimes only compiling some methods with C1. Also did lots of refactoring in preparation of "Calling Convention 2.0". One goal is to get rid of "reserved entries" in C2 as well. ------------- Commit messages: - 8241764: [lworld] TestC2CCalls fails with SIGSEGV in frame::sender_for_compiled_frame Changes: https://git.openjdk.java.net/valhalla/pull/12/files Webrev: https://webrevs.openjdk.java.net/valhalla/12/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241764 Stats: 156 lines in 11 files changed: 45 ins; 41 del; 70 mod Patch: https://git.openjdk.java.net/valhalla/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/12/head:pull/12 PR: https://git.openjdk.java.net/valhalla/pull/12 From brian.goetz at oracle.com Thu Apr 2 16:35:05 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 2 Apr 2020 12:35:05 -0400 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: References: Message-ID: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> That a Constable object might be unable to construct a symbolic descriptor is the reason that the `describeConstable` method returns an Optional.? From the spec of Constable: * Represents a type which is constable. A constable type is one whose * values are constants that can be represented in the constant pool of a Java * classfile as described in JVMS 4.4, and whose instances can describe themselves * nominally as a {@link ConstantDesc}. Hidden classes are not representable in the constant pool of any class other than the hidden class itself.? Its instances can arguably describe themselves nominally, but those nominal descriptions are of limited usefulness, since they can't be resolved with the aid of a Lookup. [1] I believe, then, that the right choice is to return an empty Optional, rather than return null or throw an exception. [1] Is this correct?? I believe even the Lookup for the hidden class itself cannot resolve the name foo.Bar/0x1234? On 4/1/2020 8:09 PM, Mandy Chung wrote: > Hi Brian, et al, > > Class is a Constable.? So a Class object for a hidden class can be > asked to yield a ConstantDesc for the hidden class via > Class::describeConstable.? It can also be asked to get the type > descriptor string for the hidden class via Class:descriptorString. > > A hidden class has no binary name. It cannot be referenced by other > classes nominally. So hidden classes are not the kind of run-time > entities of interest to the bytecode readers and writers.? I propose > no ClassDesc for hidden classes. > > The relevant APIs need update for hidden classes are: > 1. ClassDesc::ofDescriptor > > The current spec already specifies to throw IAE if the given name is > not a binary name. > > 2. Class::describeConstable > > There should be no ClassDesc for hidden > classes.ClassDesc::ofDescriptor returns an empty Optional if it's a > hidden class. > > 3. Class::descriptorString (inherited method fromTypeDescriptor) > > Three options: > a) throws an exception > b) returns null > c) returns `La/b/C.0x1234;` > > `Lookup:defineHiddenClass` specifies the name derived from the `class` > file in the form of: > ? ? `N` + "." + > > where N is the binary name indicated by the `class` file and > is an unqualified name that is guaranteed to be unique during this > execution of the JVM. > > But this is not a valid binary name; so not a field descriptor. This > has a bigger impact to java.lang.constant. > > None of the options is ideal.? I lean toward (b).? It's rare that a > compiler or other tools using java.lang.constant API will use it on a > hidden class. > > Please advise. > > Thanks > Mandy > [1] > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...) From john.r.rose at oracle.com Thu Apr 2 17:10:14 2020 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 Apr 2020 10:10:14 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> Message-ID: <7A8BF6EA-8F6E-4DD2-87C0-B177639D55D2@oracle.com> On Apr 2, 2020, at 9:35 AM, Brian Goetz wrote: > > Hidden classes are not representable in the constant pool of any class other than the hidden class itself. Its instances can arguably describe themselves nominally, but those nominal descriptions are of limited usefulness, since they can't be resolved with the aid of a Lookup. [1] > > I believe, then, that the right choice is to return an empty Optional, rather than return null or throw an exception. I?m fine with that reasoning too. We are pushing irregularities around here, hopefully into the least important corner. > [1] Is this correct? I believe even the Lookup for the hidden class itself cannot resolve the name foo.Bar/0x1234? That is correct. The string name of a HC is (by design) absolutely useless for any resolution operation. The self-reference of a HC to itself, within CP of its own classfile, is not distinguished by the spelling of the CP entry, but rather by the special relation of the ClassInfo.this_class index to the HC itself. That special CP entry is (necessarily) pre-resolved to the live HC itself. There is never a by-name symbolic lookup of an HC at any time. Any reference to a HC inside a CP would have to use a condy-flavored ConstantDesc, not a ClassDesc. So I think returning an empty Optional doesn?t hinder legitimate creation of CP entries that point to HCs. ? John From brian.goetz at oracle.com Thu Apr 2 17:29:41 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 2 Apr 2020 13:29:41 -0400 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <7A8BF6EA-8F6E-4DD2-87C0-B177639D55D2@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <7A8BF6EA-8F6E-4DD2-87C0-B177639D55D2@oracle.com> Message-ID: <9179df2c-aa28-7a65-8529-460188f14e64@oracle.com> >> I believe, then, that the right choice is to return an empty >> Optional, rather than return null or throw an exception. > > I?m fine with that reasoning too. ?We are pushing irregularities > around here, hopefully into the least important corner. The idea is that consumers of Constable must already be prepared to have one of them say "sorry, no ConstantDesc for you", and deal accordingly.? The use of Optional signals this, and makes this less messy than null/exception.? The downside is we lose the information of "why didn't it blend?" From mandy.chung at oracle.com Thu Apr 2 17:58:26 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 10:58:26 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> Message-ID: On 4/2/20 9:35 AM, Brian Goetz wrote: > That a Constable object might be unable to construct a symbolic > descriptor is the reason that the `describeConstable` method returns > an Optional.? From the spec of Constable: > > * Represents a type which is constable. A constable type is > one whose * values are constants that can be represented in the > constant pool of a Java * classfile as described in JVMS 4.4, and > whose instances can describe themselves * nominally as a {@link > ConstantDesc}. > > Hidden classes are not representable in the constant pool of any class > other than the hidden class itself.? Its instances can arguably > describe themselves nominally, but those nominal descriptions are of > limited usefulness, since they can't be resolved with the aid of a > Lookup. [1] > > I believe, then, that the right choice is to return an empty Optional, > rather than return null or throw an exception. > There are two relevant methods in Class: 1.? public Optional describeConstable() ????? Returns a nominal descriptor for this instance, if one can be constructed, or an empty Optional if one cannot be. No issue with this. 2. public String descriptorString() ??? Returns the type descriptor string for this class. This method returns String, *not* an Optional.? This is the main method in question what to do with hidden class. > Three options: > a) throws an exception > b) returns null > c) returns `La/b/C.0x1234;` Any other options to handle Class::descriptorString()? Mandy > > [1] Is this correct?? I believe even the Lookup for the hidden class > itself cannot resolve the name foo.Bar/0x1234? > > On 4/1/2020 8:09 PM, Mandy Chung wrote: >> Hi Brian, et al, >> >> Class is a Constable.? So a Class object for a hidden class can be >> asked to yield a ConstantDesc for the hidden class via >> Class::describeConstable.? It can also be asked to get the type >> descriptor string for the hidden class via Class:descriptorString. >> >> A hidden class has no binary name. It cannot be referenced by other >> classes nominally. So hidden classes are not the kind of run-time >> entities of interest to the bytecode readers and writers.? I propose >> no ClassDesc for hidden classes. >> >> The relevant APIs need update for hidden classes are: >> 1. ClassDesc::ofDescriptor >> >> The current spec already specifies to throw IAE if the given name is >> not a binary name. >> >> 2. Class::describeConstable >> >> There should be no ClassDesc for hidden >> classes.ClassDesc::ofDescriptor returns an empty Optional if it's a >> hidden class. >> >> 3. Class::descriptorString (inherited method fromTypeDescriptor) >> >> Three options: >> a) throws an exception >> b) returns null >> c) returns `La/b/C.0x1234;` >> >> `Lookup:defineHiddenClass` specifies the name derived from the >> `class` file in the form of: >> ? ? `N` + "." + >> >> where N is the binary name indicated by the `class` file and >> is an unqualified name that is guaranteed to be unique during this >> execution of the JVM. >> >> But this is not a valid binary name; so not a field descriptor.? This >> has a bigger impact to java.lang.constant. >> >> None of the options is ideal.? I lean toward (b).? It's rare that a >> compiler or other tools using java.lang.constant API will use it on a >> hidden class. >> >> Please advise. >> >> Thanks >> Mandy >> [1] >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...) > From brian.goetz at oracle.com Thu Apr 2 18:11:47 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 2 Apr 2020 14:11:47 -0400 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> Message-ID: <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> > > 2. public String descriptorString() > ??? Returns the type descriptor string for this class. > > This method returns String, *not* an Optional.? This is the main > method in question what to do with hidden class. >> Three options: >> a) throws an exception >> b) returns null >> c) returns `La/b/C.0x1234;` > > Any other options to handle Class::descriptorString()? > In this case, (c) seems reasonable; the TypeDescriptor.OfField interface does not say anything about suitability for embedding in a constant pool, resolution with class loaders, etc. From brian.goetz at oracle.com Thu Apr 2 18:34:31 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 2 Apr 2020 14:34:31 -0400 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> Message-ID: <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> Mandy reminded me that descriptorString() is specified to return a JLS 4.2.3 field descriptor, and so (c) would violate that spec.? I think this tilts the table away from (c), even though this string is arguably useful (though not clear to whom.) While the spec for TypeDescriptor doesn't explicitly say "for use in a classfile" or "for reflective instantiation", its hard to imagine use cases that don't terminate in one of these situations, at which point, we're going to fail.? So it is not clear whether we do anyone favors by having Class::descriptorString() return something "helpful" that is not really helpful. Given the choice between (a) and (b), well, both are going to result in user surprises (though, the spec for TD::descriptorString doesn't prohibit returning null.)? Taken together, I think (b) is less awful than (a), so I revise my answer to (b). On 4/2/2020 2:11 PM, Brian Goetz wrote: > >> >> 2. public String descriptorString() >> ??? Returns the type descriptor string for this class. >> >> This method returns String, *not* an Optional.? This is the main >> method in question what to do with hidden class. >>> Three options: >>> a) throws an exception >>> b) returns null >>> c) returns `La/b/C.0x1234;` >> >> Any other options to handle Class::descriptorString()? >> > > In this case, (c) seems reasonable; the TypeDescriptor.OfField > interface does not say anything about suitability for embedding in a > constant pool, resolution with class loaders, etc. From mandy.chung at oracle.com Thu Apr 2 18:56:47 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 11:56:47 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: Hi David, Thank you for checking thoroughly.?? I now grep on src/hotspot and clean all of them. Updated delta webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/ On 4/1/20 11:21 PM, David Holmes wrote: > Hi Mandy, > > On 2/04/2020 3:17 pm, Mandy Chung wrote: >> Hi David, >> >> Thanks for the edits to the comments.?? "weak hidden" were missed to >> be changed to "non-strong hidden".? Here is the patch fixing the >> comments. > > There are 33 cases of "weak hidden" in the patch I reviewed and also > some "hidden weak". Should they all be "non-strong hidden" now? yes, supposed to.?? All should be fixed in webrev.04-delta. > In some cases it also appears in variables and associated logic ie.: > > src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp > > +????? _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), > Are you reading webrev.03???? This has been fixed in webrev.04. I found Klass::is_hidden_weak that should have been renamed too. > I'm not clear how far this terminology change needs to extend ?? > I hope consistently used in the source. > Otherwise patch below seems fine. > Revised the patch. Thanks Mandy > Thanks, > David > ----- > > >> diff --git a/src/hotspot/share/ci/ciField.cpp >> b/src/hotspot/share/ci/ciField.cpp >> --- a/src/hotspot/share/ci/ciField.cpp >> +++ b/src/hotspot/share/ci/ciField.cpp >> @@ -223,8 +223,8 @@ >> ??????? holder->is_in_package("jdk/internal/foreign") || >> holder->is_in_package("jdk/incubator/foreign") || >> ??????? holder->is_in_package("java/lang")) >> ????? return true; >> -? // Trust VM hidden and unsafe anonymous classes. They are created >> via Lookup.defineClass or >> -? // the private API (jdk.internal.misc.Unsafe) and can't be >> serialized, so there is no hacking >> +? // Trust hidden and VM unsafe anonymous classes. They are created >> via Lookup.defineClass or >> +? // the private jdk.internal.misc.Unsafe API and can't be >> serialized, so there is no hacking >> ??? // of finals going on with them. >> ??? if (holder->is_hidden() || holder->is_unsafe_anonymous()) >> ????? return true; >> diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp >> b/src/hotspot/share/ci/ciInstanceKlass.cpp >> --- a/src/hotspot/share/ci/ciInstanceKlass.cpp >> +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp >> @@ -76,7 +76,7 @@ >> ??? oop holder = ik->klass_holder(); >> ??? if (ik->class_loader_data()->has_class_mirror_holder()) { >> ????? // Though ciInstanceKlass records class loader oop, it's not >> enough to keep >> -??? // VM weak hidden and unsafe anonymous classes alive (loader == >> NULL). Klass holder should >> +??? // non-strong hidden class and VM unsafe anonymous classes alive >> (loader == NULL). Klass holder should >> ????? // be used instead. It is enough to record a ciObject, since >> cached elements are never removed >> ????? // during ciObjectFactory lifetime. ciObjectFactory itself is >> created for >> ????? // every compilation and lives for the whole duration of the >> compilation. >> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp >> b/src/hotspot/share/classfile/classLoaderData.hpp >> --- a/src/hotspot/share/classfile/classLoaderData.hpp >> +++ b/src/hotspot/share/classfile/classLoaderData.hpp >> @@ -127,9 +127,10 @@ >> ??? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS >> support) >> >> ??? int _keep_alive;???????? // if this CLD is kept alive. >> -?????????????????????????? // Used for weak hidden classes, unsafe >> anonymous classes and the >> +?????????????????????????? // Used for non-strong hidden classes, >> unsafe anonymous classes and the >> ???????????????????????????? // boot class loader. _keep_alive does >> not need to be volatile or >> -?????????????????????????? // atomic since there is one unique CLD >> per weak hidden or unsafe anonymous class. >> +?????????????????????????? // atomic since there is one unique CLD >> per non-strong hidden class >> +?????????????????????????? // or unsafe anonymous class. >> >> ??? volatile int _claim; // non-zero if claimed, for example during >> GC traces. >> ???????????????????????? // To avoid applying oop closure more than >> once. >> @@ -242,15 +243,15 @@ >> ??? } >> >> ??? // Returns true if this class loader data is for the system class >> loader. >> -? // (Note that the class loader data may be for an weak hidden or >> unsafe anonymous class) >> +? // (Note that the class loader data may be for a non-strong hidden >> class or unsafe anonymous class) >> ??? bool is_system_class_loader_data() const; >> >> ??? // Returns true if this class loader data is for the platform >> class loader. >> -? // (Note that the class loader data may be for an weak hidden or >> unsafe anonymous class) >> +? // (Note that the class loader data may be for a non-strong hidden >> class or unsafe anonymous class) >> ??? bool is_platform_class_loader_data() const; >> >> ??? // Returns true if this class loader data is for the boot class >> loader. >> -? // (Note that the class loader data may be for an weak hidden >> unsafe anonymous class) >> +? // (Note that the class loader data may be for a non-strong hidden >> class or unsafe anonymous class) >> ??? inline bool is_boot_class_loader_data() const; >> >> ??? bool is_builtin_class_loader_data() const; >> @@ -271,7 +272,7 @@ >> ????? return _unloading; >> ??? } >> >> -? // Used to refcount an weak hidden or unsafe anonymous class's CLD >> in order to >> +? // Used to refcount a non-strong hidden class's or unsafe >> anonymous class's CLD in order to >> ??? // indicate their aliveness. >> ??? void inc_keep_alive(); >> ??? void dec_keep_alive(); >> >> diff --git a/src/hotspot/share/interpreter/linkResolver.cpp >> b/src/hotspot/share/interpreter/linkResolver.cpp >> --- a/src/hotspot/share/interpreter/linkResolver.cpp >> +++ b/src/hotspot/share/interpreter/linkResolver.cpp >> @@ -611,7 +611,7 @@ >> ?????????????? (same_module) ? "" : >> sel_klass->class_in_module_of_loader() >> ?????????????? ); >> >> -??? // For private access check if there was a problem with nest host >> +??? // For private access see if there was a problem with nest host >> ????? // resolution, and if so report that as part of the message. >> ????? if (sel_method->is_private()) { >> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >> @@ -951,7 +951,7 @@ >> ?????????????? (same_module) ? "" : "; ", >> ?????????????? (same_module) ? "" : >> sel_klass->class_in_module_of_loader() >> ?????????????? ); >> -??? // For private access check if there was a problem with nest host >> +??? // For private access see if there was a problem with nest host >> ????? // resolution, and if so report that as part of the message. >> ????? if (fd.is_private()) { >> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >> >> Mandy >> >> On 4/1/20 9:52 PM, David Holmes wrote: >>> Hi Mandy, >>> >>> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>>> Thanks to the review feedbacks. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>> >>> >>> I've had a good look through all the hotspot related changes. All >>> looks good. >>> >>> A few minor comments: >>> >>> src/hotspot/share/ci/ciField.cpp >>> >>> ?? // Trust VM hidden and unsafe anonymous classes. >>> >>> should say >>> >>> ?? // Trust hidden and VM unsafe anonymous classes. >>> >>> >>> ? // the private API (jdk.internal.misc.Unsafe) >>> >>> s/the/a/? or else change the () to commas or perhaps even better: >>> >>> ? // the private jdk.internal.misc.Unsafe API, >>> >>> --- >>> >>> src/hotspot/share/ci/ciInstanceKlass.cpp >>> >>> ? // VM weak hidden and unsafe anonymous classes >>> >>> should say >>> >>> ? // weak hidden and VM unsafe anonymous classes >>> >>> --- >>> >>> src/hotspot/share/classfile/classLoaderData.hpp >>> >>> !? // the CLDs lifecycle.? For example, a non-strong hidden class or an >>> ... >>> !? // Used for weak hidden classes, unsafe anonymous classes and the >>> >>> There is an inconsistency in terminology, so far most code comments >>> refer to "weak hidden" but now you are using "non-strong hidden". >>> >>> ! for an weak hidden >>> >>> s/an/a/?? multiple locations >>> >>> --- >>> >>> src/hotspot/share/interpreter/linkResolver.cpp >>> >>> Can you fix one of my comments please (in two places) :) >>> >>> +???? // For private access check if there was a problem with nest host >>> >>> would read better as: >>> >>> +???? // For private access see if there was a problem with nest host >>> >>> --- >>> >>> Thanks, >>> David >>> >> From forax at univ-mlv.fr Thu Apr 2 19:03:21 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 2 Apr 2020 21:03:21 +0200 (CEST) Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> Message-ID: <1532364659.623601.1585854201058.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "mandy chung" , "John Rose" > Cc: "valhalla-dev" > Envoy?: Jeudi 2 Avril 2020 20:34:31 > Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? > Mandy reminded me that descriptorString() is specified to return a JLS > 4.2.3 field descriptor, and so (c) would violate that spec.? I think > this tilts the table away from (c), even though this string is arguably > useful (though not clear to whom.) > > While the spec for TypeDescriptor doesn't explicitly say "for use in a > classfile" or "for reflective instantiation", its hard to imagine use > cases that don't terminate in one of these situations, at which point, > we're going to fail.? So it is not clear whether we do anyone favors by > having Class::descriptorString() return something "helpful" that is not > really helpful. > > Given the choice between (a) and (b), well, both are going to result in > user surprises (though, the spec for TD::descriptorString doesn't > prohibit returning null.)? Taken together, I think (b) is less awful > than (a), so I revise my answer to (b). (a) and (b) are incompatible changes. returning null is equivalent of throwing a NPE because at least the existing callers will not expect null, so i think (a) is better because you can have a proper error message. And the javadoc can explain that testing myClass.isHidden() upfront is the right way to avoid the exception. R?mi > > On 4/2/2020 2:11 PM, Brian Goetz wrote: >> >>> >>> 2. public String descriptorString() >>> ??? Returns the type descriptor string for this class. >>> >>> This method returns String, *not* an Optional.? This is the main >>> method in question what to do with hidden class. >>>> Three options: >>>> a) throws an exception >>>> b) returns null >>>> c) returns `La/b/C.0x1234;` >>> >>> Any other options to handle Class::descriptorString()? >>> >> >> In this case, (c) seems reasonable; the TypeDescriptor.OfField >> interface does not say anything about suitability for embedding in a > > constant pool, resolution with class loaders, etc. From mandy.chung at oracle.com Thu Apr 2 19:58:29 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 12:58:29 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <1532364659.623601.1585854201058.JavaMail.zimbra@u-pem.fr> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> <1532364659.623601.1585854201058.JavaMail.zimbra@u-pem.fr> Message-ID: <40c3143a-495c-c38c-9874-5d419433d0c4@oracle.com> On 4/2/20 12:03 PM, Remi Forax wrote: > ----- Mail original ----- >> De: "Brian Goetz" >> ?: "mandy chung" , "John Rose" >> Cc: "valhalla-dev" >> Envoy?: Jeudi 2 Avril 2020 20:34:31 >> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? >> Mandy reminded me that descriptorString() is specified to return a JLS >> 4.2.3 field descriptor, and so (c) would violate that spec.? I think >> this tilts the table away from (c), even though this string is arguably >> useful (though not clear to whom.) >> >> While the spec for TypeDescriptor doesn't explicitly say "for use in a >> classfile" or "for reflective instantiation", its hard to imagine use >> cases that don't terminate in one of these situations, at which point, >> we're going to fail.? So it is not clear whether we do anyone favors by >> having Class::descriptorString() return something "helpful" that is not >> really helpful. >> >> Given the choice between (a) and (b), well, both are going to result in >> user surprises (though, the spec for TD::descriptorString doesn't >> prohibit returning null.)? Taken together, I think (b) is less awful >> than (a), so I revise my answer to (b). > (a) and (b) are incompatible changes. > returning null is equivalent of throwing a NPE because at least the existing callers will not expect null, so i think (a) is better because you can have a proper error message. > And the javadoc can explain that testing myClass.isHidden() upfront is the right way to avoid the exception. What exception would you propose to throw for this "not a valid type descriptor runtime entity"? ?? If it throws an exception, it may be better to define a new exception type in `java.lang.constant` - would it seem a little overkill?? The clients would need to be updated to handle hidden classes if they expect Class::descriptorType invoked on any class.? I consider a helpful error message is nice while returning null indicates this class does not have a valid field descriptor. Mandy From forax at univ-mlv.fr Thu Apr 2 20:18:55 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 2 Apr 2020 22:18:55 +0200 (CEST) Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <40c3143a-495c-c38c-9874-5d419433d0c4@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> <1532364659.623601.1585854201058.JavaMail.zimbra@u-pem.fr> <40c3143a-495c-c38c-9874-5d419433d0c4@oracle.com> Message-ID: <105602372.653661.1585858735790.JavaMail.zimbra@u-pem.fr> > De: "mandy chung" > ?: "Remi Forax" , "Brian Goetz" > Cc: "John Rose" , "valhalla-dev" > > Envoy?: Jeudi 2 Avril 2020 21:58:29 > Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? > On 4/2/20 12:03 PM, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Brian Goetz" [ mailto:brian.goetz at oracle.com | ] >>> ?: "mandy chung" [ mailto:mandy.chung at oracle.com | ] , >>> "John Rose" [ mailto:john.r.rose at oracle.com | ] Cc: >>> "valhalla-dev" [ mailto:valhalla-dev at openjdk.java.net | >>> ] Envoy?: Jeudi 2 Avril 2020 20:34:31 >>> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? >>> Mandy reminded me that descriptorString() is specified to return a JLS >>> 4.2.3 field descriptor, and so (c) would violate that spec.? I think >>> this tilts the table away from (c), even though this string is arguably >>> useful (though not clear to whom.) >>> While the spec for TypeDescriptor doesn't explicitly say "for use in a >>> classfile" or "for reflective instantiation", its hard to imagine use >>> cases that don't terminate in one of these situations, at which point, >>> we're going to fail.? So it is not clear whether we do anyone favors by >>> having Class::descriptorString() return something "helpful" that is not >>> really helpful. >>> Given the choice between (a) and (b), well, both are going to result in >>> user surprises (though, the spec for TD::descriptorString doesn't >>> prohibit returning null.)? Taken together, I think (b) is less awful >>> than (a), so I revise my answer to (b). >> (a) and (b) are incompatible changes. >> returning null is equivalent of throwing a NPE because at least the existing >> callers will not expect null, so i think (a) is better because you can have a >> proper error message. >> And the javadoc can explain that testing myClass.isHidden() upfront is the right >> way to avoid the exception. > What exception would you propose to throw for this "not a valid type descriptor > runtime entity"? If it throws an exception, it may be better to define a new > exception type in `java.lang.constant` - would it seem a little overkill? The > clients would need to be updated to handle hidden classes if they expect > Class::descriptorType invoked on any class. I consider a helpful error message > is nice while returning null indicates this class does not have a valid field > descriptor. Hidden class is not something we want every developers to know, only the ones that write frameworks. So it's a secondary feature, that's why you ask if creating a new runtime exception worth the cost or not ? I have no strong feeling, i'm fine with IllegalStateException but having an exception in java.lang.constant is fine too. > Mandy R?mi From lois.foltan at oracle.com Thu Apr 2 20:28:07 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 2 Apr 2020 16:28:07 -0400 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: <333b05fb-65c6-e8ef-a804-b624c2da56c5@oracle.com> On 4/2/2020 2:56 PM, Mandy Chung wrote: > Hi David, > > Thank you for checking thoroughly.?? I now grep on src/hotspot and > clean all of them. > > Updated delta webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/ > Patch looks good Mandy. Lois > > On 4/1/20 11:21 PM, David Holmes wrote: >> Hi Mandy, >> >> On 2/04/2020 3:17 pm, Mandy Chung wrote: >>> Hi David, >>> >>> Thanks for the edits to the comments.?? "weak hidden" were missed to >>> be changed to "non-strong hidden".? Here is the patch fixing the >>> comments. >> >> There are 33 cases of "weak hidden" in the patch I reviewed and also >> some "hidden weak". Should they all be "non-strong hidden" now? > > yes, supposed to.?? All should be fixed in webrev.04-delta. > >> In some cases it also appears in variables and associated logic ie.: >> >> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp >> >> +????? _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), >> > > Are you reading webrev.03???? This has been fixed in webrev.04. > > I found Klass::is_hidden_weak that should have been renamed too. > >> I'm not clear how far this terminology change needs to extend ?? >> > > I hope consistently used in the source. > >> Otherwise patch below seems fine. >> > > Revised the patch. > > Thanks > Mandy >> Thanks, >> David >> ----- >> >> >>> diff --git a/src/hotspot/share/ci/ciField.cpp >>> b/src/hotspot/share/ci/ciField.cpp >>> --- a/src/hotspot/share/ci/ciField.cpp >>> +++ b/src/hotspot/share/ci/ciField.cpp >>> @@ -223,8 +223,8 @@ >>> ??????? holder->is_in_package("jdk/internal/foreign") || >>> holder->is_in_package("jdk/incubator/foreign") || >>> ??????? holder->is_in_package("java/lang")) >>> ????? return true; >>> -? // Trust VM hidden and unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> -? // the private API (jdk.internal.misc.Unsafe) and can't be >>> serialized, so there is no hacking >>> +? // Trust hidden and VM unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> +? // the private jdk.internal.misc.Unsafe API and can't be >>> serialized, so there is no hacking >>> ??? // of finals going on with them. >>> ??? if (holder->is_hidden() || holder->is_unsafe_anonymous()) >>> ????? return true; >>> diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> --- a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> @@ -76,7 +76,7 @@ >>> ??? oop holder = ik->klass_holder(); >>> ??? if (ik->class_loader_data()->has_class_mirror_holder()) { >>> ????? // Though ciInstanceKlass records class loader oop, it's not >>> enough to keep >>> -??? // VM weak hidden and unsafe anonymous classes alive (loader == >>> NULL). Klass holder should >>> +??? // non-strong hidden class and VM unsafe anonymous classes >>> alive (loader == NULL). Klass holder should >>> ????? // be used instead. It is enough to record a ciObject, since >>> cached elements are never removed >>> ????? // during ciObjectFactory lifetime. ciObjectFactory itself is >>> created for >>> ????? // every compilation and lives for the whole duration of the >>> compilation. >>> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp >>> b/src/hotspot/share/classfile/classLoaderData.hpp >>> --- a/src/hotspot/share/classfile/classLoaderData.hpp >>> +++ b/src/hotspot/share/classfile/classLoaderData.hpp >>> @@ -127,9 +127,10 @@ >>> ??? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS >>> support) >>> >>> ??? int _keep_alive;???????? // if this CLD is kept alive. >>> -?????????????????????????? // Used for weak hidden classes, unsafe >>> anonymous classes and the >>> +?????????????????????????? // Used for non-strong hidden classes, >>> unsafe anonymous classes and the >>> ???????????????????????????? // boot class loader. _keep_alive does >>> not need to be volatile or >>> -?????????????????????????? // atomic since there is one unique CLD >>> per weak hidden or unsafe anonymous class. >>> +?????????????????????????? // atomic since there is one unique CLD >>> per non-strong hidden class >>> +?????????????????????????? // or unsafe anonymous class. >>> >>> ??? volatile int _claim; // non-zero if claimed, for example during >>> GC traces. >>> ???????????????????????? // To avoid applying oop closure more than >>> once. >>> @@ -242,15 +243,15 @@ >>> ??? } >>> >>> ??? // Returns true if this class loader data is for the system >>> class loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong >>> hidden class or unsafe anonymous class) >>> ??? bool is_system_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the platform >>> class loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong >>> hidden class or unsafe anonymous class) >>> ??? bool is_platform_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the boot class >>> loader. >>> -? // (Note that the class loader data may be for an weak hidden >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong >>> hidden class or unsafe anonymous class) >>> ??? inline bool is_boot_class_loader_data() const; >>> >>> ??? bool is_builtin_class_loader_data() const; >>> @@ -271,7 +272,7 @@ >>> ????? return _unloading; >>> ??? } >>> >>> -? // Used to refcount an weak hidden or unsafe anonymous class's >>> CLD in order to >>> +? // Used to refcount a non-strong hidden class's or unsafe >>> anonymous class's CLD in order to >>> ??? // indicate their aliveness. >>> ??? void inc_keep_alive(); >>> ??? void dec_keep_alive(); >>> >>> diff --git a/src/hotspot/share/interpreter/linkResolver.cpp >>> b/src/hotspot/share/interpreter/linkResolver.cpp >>> --- a/src/hotspot/share/interpreter/linkResolver.cpp >>> +++ b/src/hotspot/share/interpreter/linkResolver.cpp >>> @@ -611,7 +611,7 @@ >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (sel_method->is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> @@ -951,7 +951,7 @@ >>> ?????????????? (same_module) ? "" : "; ", >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (fd.is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> >>> Mandy >>> >>> On 4/1/20 9:52 PM, David Holmes wrote: >>>> Hi Mandy, >>>> >>>> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>>>> Thanks to the review feedbacks. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>>> >>>> >>>> I've had a good look through all the hotspot related changes. All >>>> looks good. >>>> >>>> A few minor comments: >>>> >>>> src/hotspot/share/ci/ciField.cpp >>>> >>>> ?? // Trust VM hidden and unsafe anonymous classes. >>>> >>>> should say >>>> >>>> ?? // Trust hidden and VM unsafe anonymous classes. >>>> >>>> >>>> ? // the private API (jdk.internal.misc.Unsafe) >>>> >>>> s/the/a/? or else change the () to commas or perhaps even better: >>>> >>>> ? // the private jdk.internal.misc.Unsafe API, >>>> >>>> --- >>>> >>>> src/hotspot/share/ci/ciInstanceKlass.cpp >>>> >>>> ? // VM weak hidden and unsafe anonymous classes >>>> >>>> should say >>>> >>>> ? // weak hidden and VM unsafe anonymous classes >>>> >>>> --- >>>> >>>> src/hotspot/share/classfile/classLoaderData.hpp >>>> >>>> !? // the CLDs lifecycle.? For example, a non-strong hidden class >>>> or an >>>> ... >>>> !? // Used for weak hidden classes, unsafe anonymous classes and the >>>> >>>> There is an inconsistency in terminology, so far most code comments >>>> refer to "weak hidden" but now you are using "non-strong hidden". >>>> >>>> ! for an weak hidden >>>> >>>> s/an/a/?? multiple locations >>>> >>>> --- >>>> >>>> src/hotspot/share/interpreter/linkResolver.cpp >>>> >>>> Can you fix one of my comments please (in two places) :) >>>> >>>> +???? // For private access check if there was a problem with nest >>>> host >>>> >>>> would read better as: >>>> >>>> +???? // For private access see if there was a problem with nest host >>>> >>>> --- >>>> >>>> Thanks, >>>> David >>>> >>> > From mandy.chung at oracle.com Thu Apr 2 20:35:12 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 13:35:12 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <105602372.653661.1585858735790.JavaMail.zimbra@u-pem.fr> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> <1532364659.623601.1585854201058.JavaMail.zimbra@u-pem.fr> <40c3143a-495c-c38c-9874-5d419433d0c4@oracle.com> <105602372.653661.1585858735790.JavaMail.zimbra@u-pem.fr> Message-ID: <90fc2de5-260b-619f-1d2d-7bd638179e9a@oracle.com> On 4/2/20 1:18 PM, forax at univ-mlv.fr wrote: > > > ------------------------------------------------------------------------ > > *De: *"mandy chung" > *?: *"Remi Forax" , "Brian Goetz" > > *Cc: *"John Rose" , "valhalla-dev" > > *Envoy?: *Jeudi 2 Avril 2020 21:58:29 > *Objet: *Re: java.lang.constant.ClassDesc and TypeDescriptor for > hidden class?? > > > > On 4/2/20 12:03 PM, Remi Forax wrote: > > ----- Mail original ----- > > De: "Brian Goetz" > ?: "mandy chung", "John Rose" > Cc: "valhalla-dev" > Envoy?: Jeudi 2 Avril 2020 20:34:31 > Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? > > Mandy reminded me that descriptorString() is specified to return a JLS > 4.2.3 field descriptor, and so (c) would violate that spec.? I think > this tilts the table away from (c), even though this string is arguably > useful (though not clear to whom.) > > While the spec for TypeDescriptor doesn't explicitly say "for use in a > classfile" or "for reflective instantiation", its hard to imagine use > cases that don't terminate in one of these situations, at which point, > we're going to fail.? So it is not clear whether we do anyone favors by > having Class::descriptorString() return something "helpful" that is not > really helpful. > > Given the choice between (a) and (b), well, both are going to result in > user surprises (though, the spec for TD::descriptorString doesn't > prohibit returning null.)? Taken together, I think (b) is less awful > than (a), so I revise my answer to (b). > > (a) and (b) are incompatible changes. > returning null is equivalent of throwing a NPE because at least the existing callers will not expect null, so i think (a) is better because you can have a proper error message. > And the javadoc can explain that testing myClass.isHidden() upfront is the right way to avoid the exception. > > > What exception would you propose to throw for this "not a valid > type descriptor runtime entity"? ?? If it throws an exception, it > may be better to define a new exception type in > `java.lang.constant` - would it seem a little overkill? The > clients would need to be updated to handle hidden classes if they > expect Class::descriptorType invoked on any class.? I consider a > helpful error message is nice while returning null indicates this > class does not have a valid field descriptor. > > > Hidden class is not something we want every developers to know, only > the ones that write frameworks. So it's a secondary feature, that's > why you ask if creating a new runtime exception worth the cost or not ? Exactly and explain the reason I propose (b) to return null than throwing an exception. Mandy > I have no strong feeling, i'm fine with IllegalStateException but > having an exception in java.lang.constant is fine too. > From brian.goetz at oracle.com Thu Apr 2 21:33:21 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 2 Apr 2020 17:33:21 -0400 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <1532364659.623601.1585854201058.JavaMail.zimbra@u-pem.fr> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> <1532364659.623601.1585854201058.JavaMail.zimbra@u-pem.fr> Message-ID: <4b610928-e132-7563-76f1-4b151f241152@oracle.com> >> Given the choice between (a) and (b), well, both are going to result in >> user surprises (though, the spec for TD::descriptorString doesn't >> prohibit returning null.)? Taken together, I think (b) is less awful >> than (a), so I revise my answer to (b). > (a) and (b) are incompatible changes. > returning null is equivalent of throwing a NPE because at least the existing callers will not expect null, so i think (a) is better because you can have a proper error message. This is a pretty tenuous line of argument. I think what you mean is: "a and b are bad."? And that's true. Also, c is bad. So the game here is to find the least bad choice... > And the javadoc can explain that testing myClass.isHidden() upfront is the right way to avoid the exception. That's true for all of a, b, and c.? THe problem is, as you say, no one will think to do this, until they've been bitten once.? Hence, all the options are bad. From forax at univ-mlv.fr Thu Apr 2 21:53:10 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 2 Apr 2020 23:53:10 +0200 (CEST) Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <90fc2de5-260b-619f-1d2d-7bd638179e9a@oracle.com> References: <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> <1532364659.623601.1585854201058.JavaMail.zimbra@u-pem.fr> <40c3143a-495c-c38c-9874-5d419433d0c4@oracle.com> <105602372.653661.1585858735790.JavaMail.zimbra@u-pem.fr> <90fc2de5-260b-619f-1d2d-7bd638179e9a@oracle.com> Message-ID: <63178217.672905.1585864390589.JavaMail.zimbra@u-pem.fr> > De: "mandy chung" > ?: "Remi Forax" > Cc: "Brian Goetz" , "John Rose" > , "valhalla-dev" > Envoy?: Jeudi 2 Avril 2020 22:35:12 > Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? > On 4/2/20 1:18 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote: >>> De: "mandy chung" [ mailto:mandy.chung at oracle.com | ] >>> ?: "Remi Forax" [ mailto:forax at univ-mlv.fr | ] , "Brian >>> Goetz" [ mailto:brian.goetz at oracle.com | ] >>> Cc: "John Rose" [ mailto:john.r.rose at oracle.com | ] , >>> "valhalla-dev" [ mailto:valhalla-dev at openjdk.java.net | >>> ] >>> Envoy?: Jeudi 2 Avril 2020 21:58:29 >>> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? >>> On 4/2/20 12:03 PM, Remi Forax wrote: >>>> ----- Mail original ----- >>>>> De: "Brian Goetz" [ mailto:brian.goetz at oracle.com | ] >>>>> ?: "mandy chung" [ mailto:mandy.chung at oracle.com | ] , >>>>> "John Rose" [ mailto:john.r.rose at oracle.com | ] Cc: >>>>> "valhalla-dev" [ mailto:valhalla-dev at openjdk.java.net | >>>>> ] Envoy?: Jeudi 2 Avril 2020 20:34:31 >>>>> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? >>>>> Mandy reminded me that descriptorString() is specified to return a JLS >>>>> 4.2.3 field descriptor, and so (c) would violate that spec.? I think >>>>> this tilts the table away from (c), even though this string is arguably >>>>> useful (though not clear to whom.) >>>>> While the spec for TypeDescriptor doesn't explicitly say "for use in a >>>>> classfile" or "for reflective instantiation", its hard to imagine use >>>>> cases that don't terminate in one of these situations, at which point, >>>>> we're going to fail.? So it is not clear whether we do anyone favors by >>>>> having Class::descriptorString() return something "helpful" that is not >>>>> really helpful. >>>>> Given the choice between (a) and (b), well, both are going to result in >>>>> user surprises (though, the spec for TD::descriptorString doesn't >>>>> prohibit returning null.)? Taken together, I think (b) is less awful >>>>> than (a), so I revise my answer to (b). >>>> (a) and (b) are incompatible changes. >>>> returning null is equivalent of throwing a NPE because at least the existing >>>> callers will not expect null, so i think (a) is better because you can have a >>>> proper error message. >>>> And the javadoc can explain that testing myClass.isHidden() upfront is the right >>>> way to avoid the exception. >>> What exception would you propose to throw for this "not a valid type descriptor >>> runtime entity"? If it throws an exception, it may be better to define a new >>> exception type in `java.lang.constant` - would it seem a little overkill? The >>> clients would need to be updated to handle hidden classes if they expect >>> Class::descriptorType invoked on any class. I consider a helpful error message >>> is nice while returning null indicates this class does not have a valid field >>> descriptor. >> Hidden class is not something we want every developers to know, only the ones >> that write frameworks. So it's a secondary feature, that's why you ask if >> creating a new runtime exception worth the cost or not ? > Exactly and explain the reason I propose (b) to return null than throwing an > exception. The method already exist, so for an existing program if you are lucky returning null will raise a NPE immediately on the next instruction, if your not, it will wreck havoc several hundreds of instructions later. As a user, i'm for an ISE with a nice error message. > Mandy R?mi >> I have no strong feeling, i'm fine with IllegalStateException but having an >> exception in java.lang.constant is fine too. From forax at univ-mlv.fr Thu Apr 2 21:55:38 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 2 Apr 2020 23:55:38 +0200 (CEST) Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <4b610928-e132-7563-76f1-4b151f241152@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> <1532364659.623601.1585854201058.JavaMail.zimbra@u-pem.fr> <4b610928-e132-7563-76f1-4b151f241152@oracle.com> Message-ID: <1335751410.673246.1585864538135.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "Remi Forax" > Cc: "mandy chung" , "John Rose" , "valhalla-dev" > > Envoy?: Jeudi 2 Avril 2020 23:33:21 > Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? >>> Given the choice between (a) and (b), well, both are going to result in >>> user surprises (though, the spec for TD::descriptorString doesn't >>> prohibit returning null.)? Taken together, I think (b) is less awful >>> than (a), so I revise my answer to (b). >> (a) and (b) are incompatible changes. >> returning null is equivalent of throwing a NPE because at least the existing >> callers will not expect null, so i think (a) is better because you can have a >> proper error message. > > This is a pretty tenuous line of argument. > > I think what you mean is: "a and b are bad."? And that's true. Also, c > is bad. So the game here is to find the least bad choice... > >> And the javadoc can explain that testing myClass.isHidden() upfront is the right >> way to avoid the exception. > > That's true for all of a, b, and c.? THe problem is, as you say, no one > will think to do this, until they've been bitten once.? Hence, all the > options are bad. The first thing my students do when they get an exception is to read the javadoc, jokingly I say to them that Java should have only one exception, RTFMException. R?mi From david.holmes at oracle.com Fri Apr 3 01:36:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Apr 2020 11:36:03 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: <10e51a8a-6d69-db08-d4f9-f578ec591ee2@oracle.com> Hi Mandy, Update seems fine. Thanks, David On 3/04/2020 4:56 am, Mandy Chung wrote: > Hi David, > > Thank you for checking thoroughly.?? I now grep on src/hotspot and clean > all of them. > > Updated delta webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/ > > On 4/1/20 11:21 PM, David Holmes wrote: >> Hi Mandy, >> >> On 2/04/2020 3:17 pm, Mandy Chung wrote: >>> Hi David, >>> >>> Thanks for the edits to the comments.?? "weak hidden" were missed to >>> be changed to "non-strong hidden".? Here is the patch fixing the >>> comments. >> >> There are 33 cases of "weak hidden" in the patch I reviewed and also >> some "hidden weak". Should they all be "non-strong hidden" now? > > yes, supposed to.?? All should be fixed in webrev.04-delta. > >> In some cases it also appears in variables and associated logic ie.: >> >> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp >> >> +????? _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), >> > > Are you reading webrev.03???? This has been fixed in webrev.04. > > I found Klass::is_hidden_weak that should have been renamed too. > >> I'm not clear how far this terminology change needs to extend ?? >> > > I hope consistently used in the source. > >> Otherwise patch below seems fine. >> > > Revised the patch. > > Thanks > Mandy >> Thanks, >> David >> ----- >> >> >>> diff --git a/src/hotspot/share/ci/ciField.cpp >>> b/src/hotspot/share/ci/ciField.cpp >>> --- a/src/hotspot/share/ci/ciField.cpp >>> +++ b/src/hotspot/share/ci/ciField.cpp >>> @@ -223,8 +223,8 @@ >>> ??????? holder->is_in_package("jdk/internal/foreign") || >>> holder->is_in_package("jdk/incubator/foreign") || >>> ??????? holder->is_in_package("java/lang")) >>> ????? return true; >>> -? // Trust VM hidden and unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> -? // the private API (jdk.internal.misc.Unsafe) and can't be >>> serialized, so there is no hacking >>> +? // Trust hidden and VM unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> +? // the private jdk.internal.misc.Unsafe API and can't be >>> serialized, so there is no hacking >>> ??? // of finals going on with them. >>> ??? if (holder->is_hidden() || holder->is_unsafe_anonymous()) >>> ????? return true; >>> diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> --- a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> @@ -76,7 +76,7 @@ >>> ??? oop holder = ik->klass_holder(); >>> ??? if (ik->class_loader_data()->has_class_mirror_holder()) { >>> ????? // Though ciInstanceKlass records class loader oop, it's not >>> enough to keep >>> -??? // VM weak hidden and unsafe anonymous classes alive (loader == >>> NULL). Klass holder should >>> +??? // non-strong hidden class and VM unsafe anonymous classes alive >>> (loader == NULL). Klass holder should >>> ????? // be used instead. It is enough to record a ciObject, since >>> cached elements are never removed >>> ????? // during ciObjectFactory lifetime. ciObjectFactory itself is >>> created for >>> ????? // every compilation and lives for the whole duration of the >>> compilation. >>> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp >>> b/src/hotspot/share/classfile/classLoaderData.hpp >>> --- a/src/hotspot/share/classfile/classLoaderData.hpp >>> +++ b/src/hotspot/share/classfile/classLoaderData.hpp >>> @@ -127,9 +127,10 @@ >>> ??? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS >>> support) >>> >>> ??? int _keep_alive;???????? // if this CLD is kept alive. >>> -?????????????????????????? // Used for weak hidden classes, unsafe >>> anonymous classes and the >>> +?????????????????????????? // Used for non-strong hidden classes, >>> unsafe anonymous classes and the >>> ???????????????????????????? // boot class loader. _keep_alive does >>> not need to be volatile or >>> -?????????????????????????? // atomic since there is one unique CLD >>> per weak hidden or unsafe anonymous class. >>> +?????????????????????????? // atomic since there is one unique CLD >>> per non-strong hidden class >>> +?????????????????????????? // or unsafe anonymous class. >>> >>> ??? volatile int _claim; // non-zero if claimed, for example during >>> GC traces. >>> ???????????????????????? // To avoid applying oop closure more than >>> once. >>> @@ -242,15 +243,15 @@ >>> ??? } >>> >>> ??? // Returns true if this class loader data is for the system class >>> loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong hidden >>> class or unsafe anonymous class) >>> ??? bool is_system_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the platform >>> class loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong hidden >>> class or unsafe anonymous class) >>> ??? bool is_platform_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the boot class >>> loader. >>> -? // (Note that the class loader data may be for an weak hidden >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong hidden >>> class or unsafe anonymous class) >>> ??? inline bool is_boot_class_loader_data() const; >>> >>> ??? bool is_builtin_class_loader_data() const; >>> @@ -271,7 +272,7 @@ >>> ????? return _unloading; >>> ??? } >>> >>> -? // Used to refcount an weak hidden or unsafe anonymous class's CLD >>> in order to >>> +? // Used to refcount a non-strong hidden class's or unsafe >>> anonymous class's CLD in order to >>> ??? // indicate their aliveness. >>> ??? void inc_keep_alive(); >>> ??? void dec_keep_alive(); >>> >>> diff --git a/src/hotspot/share/interpreter/linkResolver.cpp >>> b/src/hotspot/share/interpreter/linkResolver.cpp >>> --- a/src/hotspot/share/interpreter/linkResolver.cpp >>> +++ b/src/hotspot/share/interpreter/linkResolver.cpp >>> @@ -611,7 +611,7 @@ >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (sel_method->is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> @@ -951,7 +951,7 @@ >>> ?????????????? (same_module) ? "" : "; ", >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (fd.is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> >>> Mandy >>> >>> On 4/1/20 9:52 PM, David Holmes wrote: >>>> Hi Mandy, >>>> >>>> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>>>> Thanks to the review feedbacks. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>>> >>>> >>>> I've had a good look through all the hotspot related changes. All >>>> looks good. >>>> >>>> A few minor comments: >>>> >>>> src/hotspot/share/ci/ciField.cpp >>>> >>>> ?? // Trust VM hidden and unsafe anonymous classes. >>>> >>>> should say >>>> >>>> ?? // Trust hidden and VM unsafe anonymous classes. >>>> >>>> >>>> ? // the private API (jdk.internal.misc.Unsafe) >>>> >>>> s/the/a/? or else change the () to commas or perhaps even better: >>>> >>>> ? // the private jdk.internal.misc.Unsafe API, >>>> >>>> --- >>>> >>>> src/hotspot/share/ci/ciInstanceKlass.cpp >>>> >>>> ? // VM weak hidden and unsafe anonymous classes >>>> >>>> should say >>>> >>>> ? // weak hidden and VM unsafe anonymous classes >>>> >>>> --- >>>> >>>> src/hotspot/share/classfile/classLoaderData.hpp >>>> >>>> !? // the CLDs lifecycle.? For example, a non-strong hidden class or an >>>> ... >>>> !? // Used for weak hidden classes, unsafe anonymous classes and the >>>> >>>> There is an inconsistency in terminology, so far most code comments >>>> refer to "weak hidden" but now you are using "non-strong hidden". >>>> >>>> ! for an weak hidden >>>> >>>> s/an/a/?? multiple locations >>>> >>>> --- >>>> >>>> src/hotspot/share/interpreter/linkResolver.cpp >>>> >>>> Can you fix one of my comments please (in two places) :) >>>> >>>> +???? // For private access check if there was a problem with nest host >>>> >>>> would read better as: >>>> >>>> +???? // For private access see if there was a problem with nest host >>>> >>>> --- >>>> >>>> Thanks, >>>> David >>>> >>> > From john.r.rose at oracle.com Fri Apr 3 05:03:09 2020 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 Apr 2020 22:03:09 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> Message-ID: <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com> On Apr 2, 2020, at 11:34 AM, Brian Goetz wrote: > > Mandy reminded me that descriptorString() is specified to return a JLS 4.2.3 field descriptor, and so (c) would violate that spec. I think this tilts the table away from (c), even though this string is arguably useful (though not clear to whom.) > Here?s a compromise that almost makes sense on its own: (d) return the field descriptor string for the hidden class, minus the ?.X? suffix, appropriately wrapped. First of all, it?s a valid descriptor. (Though probably not resolvable to a class, still its valid.) Second, it?s arguably how the HC?s descriptor *would* be spelled as a field descriptor, if it could. The CONSTANT_Class entry of the original ClassInfo.this_class of the HC has that class name, sans added ?.X?. But, I think the best compromise is to admit that, just as Class::getName returns an intentionally invalid though suggestive class name (rather than null or an exception), so Class::descriptorString should return the intentionally invalid though suggestive field descriptor which is regularly derived from said Class::getName. This provides consistency in string-valued outputs; in the absence of an argument why their treatment should be inconsistent, consistency is less confusing and should win. The validity checking in the constructor of ReferenceClassDescImpl already ensures that such a HC descriptor string cannot be mistaken for a well-formed field descriptor, since it excludes dots ?.? in the input. I think *that* is the right place to put the error check, and it?s no accident (this time) that the prototype code behaves this way, because complicating the spec. with extra validity checks would also require more validity checks for the affected method (Class::descriptorString). Under this theory, the code needs one more validity check: @Override public Optional describeConstable() { + if (isHidden()) return Optional.empty(); return Optional.of(ClassDesc.ofDescriptor(descriptorString())); } If that validity check is missing, then ClassDesc.of would throw (in the constructor referred to above), violating the convention 0f using Optional.empty(). ? John From rwestrel at redhat.com Fri Apr 3 07:56:05 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 03 Apr 2020 09:56:05 +0200 Subject: [lworld] RFR: 8241764: [lworld] TestC2CCalls fails with SIGSEGV in frame::sender_for_compiled_frame In-Reply-To: References: Message-ID: <87blo9c8a2.fsf@redhat.com> > Webrev: https://webrevs.openjdk.java.net/valhalla/12/webrev.00 Ok. Roland. From peter.levart at gmail.com Fri Apr 3 09:11:04 2020 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 3 Apr 2020 11:11:04 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: Hi Mandy, Good work. I'm trying to find out which language use-case is covered by the InnerClassLambdaMetafactory needing to inject method handle into the generated proxy class to be invoked instead of proxy class directly invoking the method: ??????? useImplMethodHandle = !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) ??????????????????????????????? && !Modifier.isPublic(implInfo.getModifiers()); If I check what implClass and implInfo get resolved to in AbstractValidatingLambdaMetafactory, there are several cases: ??????? this.implInfo = caller.revealDirect(implMethod); ??????? switch (implInfo.getReferenceKind()) { ??????????? case REF_invokeVirtual: ??????????? case REF_invokeInterface: ??????????????? this.implClass = implMethodType.parameterType(0); ??????????????? // reference kind reported by implInfo may not match implMethodType's first param ??????????????? // Example: implMethodType is (Cloneable)String, implInfo is for Object.toString ??????????????? this.implKind = implClass.isInterface() ? REF_invokeInterface : REF_invokeVirtual; ??????????????? this.implIsInstanceMethod = true; ??????????????? break; ??????????? case REF_invokeSpecial: ??????????????? // JDK-8172817: should use referenced class here, but we don't know what it was ??????????????? this.implClass = implInfo.getDeclaringClass(); ??????????????? this.implIsInstanceMethod = true; ??????????????? // Classes compiled prior to dynamic nestmate support invokes a private instance ??????????????? // method with REF_invokeSpecial. ??????????????? // ??????????????? // invokespecial should only be used to invoke private nestmate constructors. ??????????????? // The lambda proxy class will be defined as a nestmate of targetClass. ??????????????? // If the method to be invoked is an instance method of targetClass, then ??????????????? // convert to use invokevirtual or invokeinterface. ??????????????? if (targetClass == implClass && !implInfo.getName().equals("")) { ??????????????????? this.implKind = implClass.isInterface() ? REF_invokeInterface : REF_invokeVirtual; ??????????????? } else { ??????????????????? this.implKind = REF_invokeSpecial; ??????????????? } ??????????????? break; ??????????? case REF_invokeStatic: ??????????? case REF_newInvokeSpecial: ??????????????? // JDK-8172817: should use referenced class here for invokestatic, but we don't know what it was ??????????????? this.implClass = implInfo.getDeclaringClass(); ??????????????? this.implKind = implInfo.getReferenceKind(); ??????????????? this.implIsInstanceMethod = false; ??????????????? break; ??????????? default: ??????????????? throw new LambdaConversionException(String.format("Unsupported MethodHandle kind: %s", implInfo)); ??????? } For majority of cases (REF_invokeSpecial, REF_invokeStatic, REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass(); Only REF_invokeVirtual and REF_invokeInterface are possible kandidates, right? So when does the implMethod type of parameter 0 differ from the declaring class of the MethodHandleInfo cracked from that same implMethod and in addition those two types leave in different packages? Regards, Peter On 3/27/20 12:57 AM, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered > in any dictionary. > - A hidden class has a name containing an illegal character > `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` > returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or > retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final".? The value of final > fields cannot be overriden via reflection.? setAccessible(true) can > still be called on reflected objects representing final fields in a > hidden class and its access check will be suppressed but only have > read-access (i.e. can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a > hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for > Lookup::defineClass > ?? and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed.? There is one > primary CLD > ?? that holds the classes strongly referenced by its defining loader.? > There > ?? can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access > control > ?? check no longer throws LinkageError but instead it will throw IAE with > ?? a clear message if a class fails to resolve/validate the nest host > declared > ?? in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > ?? and generate a bridge method to desuger a method reference to a > protected > ?? method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and > LambdaForms > to use hidden classes.? The webrev includes changes in nashorn to > hidden class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation > in 14 > does not link the class.? A separate CSR [2] proposes to update the > implementation to match the spec.? This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3].? This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden > classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From tobias.hartmann at oracle.com Fri Apr 3 09:14:04 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 3 Apr 2020 02:14:04 -0700 (PDT) Subject: [lworld] RFR: 8241764: [lworld] TestC2CCalls fails with SIGSEGV in frame::sender_for_compiled_frame In-Reply-To: <87blo9c8a2.fsf@redhat.com> References: <87blo9c8a2.fsf@redhat.com> Message-ID: Thanks Roland! Best regards, Tobias On 03.04.20 09:56, Roland Westrelin wrote: > >> Webrev: https://webrevs.openjdk.java.net/valhalla/12/webrev.00 > > Ok. > > Roland. > From thartmann at openjdk.java.net Fri Apr 3 10:18:13 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 3 Apr 2020 10:18:13 GMT Subject: [Integrated] [lworld] RFR: 8241764: [lworld] TestC2CCalls fails with SIGSEGV in frame::sender_for_compiled_frame In-Reply-To: References: Message-ID: <66ac51e8-c875-455b-9c39-016b2d715d32@openjdk.org> Changeset: a264ae9a Author: Tobias Hartmann Date: 2020-04-03 10:17:04 +0000 URL: https://git.openjdk.java.net/valhalla/commit/a264ae9a 8241764: [lworld] TestC2CCalls fails with SIGSEGV in frame::sender_for_compiled_frame ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/asm/macroAssembler_common.cpp ! src/hotspot/share/asm/macroAssembler_common.hpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_MacroAssembler.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestC2CCalls.java From peter.levart at gmail.com Fri Apr 3 11:40:54 2020 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 3 Apr 2020 13:40:54 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> Ok, I think I found one such use-case. In the following example: package test; public class LambdaTest { ??? protected void m() { ??? } } package test.sub; public class LambdaTestSub extends test.LambdaTest { ??? public void test() { ??????? Runnable r = this::m; ??????? r.run(); ??? } } ...when compiled with JDK 14 javac. In this case the implClass is test.sub.LambdaTestSub while implInfo is "invokeVirtual test.LambdaTest.m:()void" and the method is not public. Anyway, the name of the proxy class is derived from the targetClass (and therefore shares the same package with targetClass) which is caller's lookup class. Is targetClass always the same as implClass in the invokeVirtual/invokeInterface case? I also noticed that JDK 15 patched javac transforms method reference in above code into a lambda method. But looking at the javac changes in the patch, I don't quite see where this distinction between JDK 14 and patched JDK 15 javac comes from. From the changes to method com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: ??????????? final boolean needsConversionToLambda() { ??????????????? return interfaceParameterIsIntersectionOrUnionType() || ??????????????????????? isSuper || ??????????????????????? needsVarArgsConversion() || ??????????????????????? isArrayOp() || #??????????????????????? isPrivateInOtherClass() || isProtectedInSuperClassOfEnclosingClassInOtherPackage() || ??????????????????????? !receiverAccessible() || ??????????????????????? (tree.getMode() == ReferenceMode.NEW && ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && ????????????????????????? (tree.sym.owner.isLocal() || tree.sym.owner.isInner())); ??????????? } ...I would draw the conclusion that conversion to lambda is performed in less cases not in more. Hm. Regards, Peter On 4/3/20 11:11 AM, Peter Levart wrote: > Hi Mandy, > > Good work. > > I'm trying to find out which language use-case is covered by the > InnerClassLambdaMetafactory needing to inject method handle into the > generated proxy class to be invoked instead of proxy class directly > invoking the method: > > ??????? useImplMethodHandle = > !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) > ??????????????????????????????? && > !Modifier.isPublic(implInfo.getModifiers()); > > If I check what implClass and implInfo get resolved to in > AbstractValidatingLambdaMetafactory, there are several cases: > > ??????? this.implInfo = caller.revealDirect(implMethod); > ??????? switch (implInfo.getReferenceKind()) { > ??????????? case REF_invokeVirtual: > ??????????? case REF_invokeInterface: > ??????????????? this.implClass = implMethodType.parameterType(0); > ??????????????? // reference kind reported by implInfo may not match > implMethodType's first param > ??????????????? // Example: implMethodType is (Cloneable)String, > implInfo is for Object.toString > ??????????????? this.implKind = implClass.isInterface() ? > REF_invokeInterface : REF_invokeVirtual; > ??????????????? this.implIsInstanceMethod = true; > ??????????????? break; > ??????????? case REF_invokeSpecial: > ??????????????? // JDK-8172817: should use referenced class here, but > we don't know what it was > ??????????????? this.implClass = implInfo.getDeclaringClass(); > ??????????????? this.implIsInstanceMethod = true; > > ??????????????? // Classes compiled prior to dynamic nestmate support > invokes a private instance > ??????????????? // method with REF_invokeSpecial. > ??????????????? // > ??????????????? // invokespecial should only be used to invoke private > nestmate constructors. > ??????????????? // The lambda proxy class will be defined as a > nestmate of targetClass. > ??????????????? // If the method to be invoked is an instance method > of targetClass, then > ??????????????? // convert to use invokevirtual or invokeinterface. > ??????????????? if (targetClass == implClass && > !implInfo.getName().equals("")) { > ??????????????????? this.implKind = implClass.isInterface() ? > REF_invokeInterface : REF_invokeVirtual; > ??????????????? } else { > ??????????????????? this.implKind = REF_invokeSpecial; > ??????????????? } > ??????????????? break; > ??????????? case REF_invokeStatic: > ??????????? case REF_newInvokeSpecial: > ??????????????? // JDK-8172817: should use referenced class here for > invokestatic, but we don't know what it was > ??????????????? this.implClass = implInfo.getDeclaringClass(); > ??????????????? this.implKind = implInfo.getReferenceKind(); > ??????????????? this.implIsInstanceMethod = false; > ??????????????? break; > ??????????? default: > ??????????????? throw new > LambdaConversionException(String.format("Unsupported MethodHandle > kind: %s", implInfo)); > ??????? } > > > For majority of cases (REF_invokeSpecial, REF_invokeStatic, > REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass(); > > Only REF_invokeVirtual and REF_invokeInterface are possible > kandidates, right? > > So when does the implMethod type of parameter 0 differ from the > declaring class of the MethodHandleInfo cracked from that same > implMethod and in addition those two types leave in different packages? > > Regards, Peter > > > On 3/27/20 12:57 AM, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of >> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >> and is in the finalized state (see specdiff and javadoc below for >> reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >> point >> of view, a hidden class is a normal class except the following: >> >> - A hidden class has no initiating class loader and is not registered >> in any dictionary. >> - A hidden class has a name containing an illegal character >> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >> returns "Lp/Foo.0x1234;". >> - A hidden class is not modifiable, i.e. cannot be redefined or >> retransformed. JVM TI IsModifableClass returns false on a hidden. >> - Final fields in a hidden class is "final".? The value of final >> fields cannot be overriden via reflection.? setAccessible(true) can >> still be called on reflected objects representing final fields in a >> hidden class and its access check will be suppressed but only have >> read-access (i.e. can do Field::getXXX but not setXXX). >> >> Brief summary of this patch: >> >> 1. A new Lookup::defineHiddenClass method is the API to create a >> hidden class. >> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >> option that >> ?? can be specified when creating a hidden class. >> 3. A new Class::isHiddenClass method tests if a class is a hidden class. >> 4. Field::setXXX method will throw IAE on a final field of a hidden >> class >> ?? regardless of the value of the accessible flag. >> 5. JVM_LookupDefineClass is the new JVM entry point for >> Lookup::defineClass >> ?? and defineHiddenClass to create a class from the given bytes. >> 6. ClassLoaderData implementation is not changed.? There is one >> primary CLD >> ?? that holds the classes strongly referenced by its defining >> loader.? There >> ?? can be zero or more additional CLDs - one per weak class. >> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >> control >> ?? check no longer throws LinkageError but instead it will throw IAE >> with >> ?? a clear message if a class fails to resolve/validate the nest host >> declared >> ?? in NestHost/NestMembers attribute. >> 8. JFR, jcmd, JDI are updated to support hidden classes. >> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >> ?? and generate a bridge method to desuger a method reference to a >> protected >> ?? method in its supertype in a different package >> >> This patch also updates StringConcatFactory, LambdaMetaFactory, and >> LambdaForms >> to use hidden classes.? The webrev includes changes in nashorn to >> hidden class >> and I will update the webrev if JEP 372 removes it any time soon. >> >> We uncovered a bug in Lookup::defineClass spec throws LinkageError >> and intends >> to have the newly created class linked.? However, the implementation >> in 14 >> does not link the class.? A separate CSR [2] proposes to update the >> implementation to match the spec.? This patch fixes the implementation. >> >> The spec update on JVM TI, JDI and Instrumentation will be done as >> a separate RFE [3].? This patch includes new tests for JVM TI and >> java.instrument that validates how the existing APIs work for hidden >> classes. >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From mandy.chung at oracle.com Fri Apr 3 18:45:44 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 3 Apr 2020 11:45:44 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com> Message-ID: <0742b4d4-6556-b22e-e160-504c9a6b3b51@oracle.com> On 4/2/20 10:03 PM, John Rose wrote: > On Apr 2, 2020, at 11:34 AM, Brian Goetz wrote: >> Mandy reminded me that descriptorString() is specified to return a JLS 4.2.3 field descriptor, and so (c) would violate that spec. I think this tilts the table away from (c), even though this string is arguably useful (though not clear to whom.) >> > Here?s a compromise that almost makes sense on its own: > > (d) return the field descriptor string for the hidden class, > minus the ?.X? suffix, appropriately wrapped. > > First of all, it?s a valid descriptor. (Though probably not > resolvable to a class, still its valid.) Second, it?s arguably > how the HC?s descriptor *would* be spelled as a field > descriptor, if it could. The CONSTANT_Class entry of > the original ClassInfo.this_class of the HC has that > class name, sans added ?.X?. > > But, I think the best compromise is to admit that, just > as Class::getName returns an intentionally invalid > though suggestive class name (rather than null or an > exception), so Class::descriptorString should return > the intentionally invalid though suggestive field > descriptor which is regularly derived from said > Class::getName. This provides consistency in > string-valued outputs; in the absence of an argument > why their treatment should be inconsistent, > consistency is less confusing and should win. This give consistency in the type descriptor returned by Class::descriptorString for all classes. However, inconsistency among the factory methods that produce ClassDesc: ?? ClassDesc.ofDescriptor(HC.descriptorString()) - returns a ClassDesc ?? ClassDesc.ofDescriptor(HC.getName()) - IAE thrown ?? ClassDesc.of(HC.getPackageName(), HC.getSimpleName()) - IAE thrown ?? Class::describeConstable - returns an empty optional. (I am not close to java.lang.constant and the above calls may not be expected.) We should also consider MethodType.? One can create a MethodType with a hidden class as a parameter type or return type via the factory methods.? In practice no one would need to create such a MethodType as a hidden class can't be resolved by name.?? If MT(HC) is used to lookup a method handle, NoSuchMethodException will be thrown. If MT(HC).toMethodDescriptorString() and MT(HC)::descriptorString drop `.X` suffix, the return descriptor is a valid method descriptor ??? MT(HC).descriptorString() - returns "(La/b/C;)V" ??? MT(HC).toMethodDescriptorString() - returns "(La/b/C;)V" ??? MethodType.fromMethodDescriptorString(MT(HC).descriptorString(), loader) - if the loader happens to find class "a.b.C", it will produce a MethodType with a.b.C as its return type. ??? MT(HC).describeConstable() - returns an empty optional I'm starting to think throwing a TypeDescriptorNotPresentException would be consistent all these relevant APIs. > The validity checking in the constructor of > ReferenceClassDescImpl already ensures that such > a HC descriptor string cannot be mistaken for a > well-formed field descriptor, since it excludes dots ?.? > in the input. I think *that* is the right place to > put the error check, and it?s no accident (this time) > that the prototype code behaves this way, because > complicating the spec. with extra validity checks > would also require more validity checks for the > affected method (Class::descriptorString). > > Under this theory, the code needs one more validity > check: > > @Override > public Optional describeConstable() { > + if (isHidden()) return Optional.empty(); > return Optional.of(ClassDesc.ofDescriptor(descriptorString())); > } > > If that validity check is missing, then ClassDesc.of would > throw (in the constructor referred to above), violating > the convention 0f using Optional.empty(). Yes, that validity check is in needed and in my local patch. Mandy From mandy.chung at oracle.com Fri Apr 3 21:32:48 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 3 Apr 2020 14:32:48 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> Message-ID: <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Hi Peter, I added a JBS comment [1] to describe this special case trying to put the story together (let me know if it needs more explanation). More comment inline below. On 4/3/20 4:40 AM, Peter Levart wrote: > Ok, I think I found one such use-case. In the following example: > > package test; > public class LambdaTest { > ??? protected void m() { > ??? } > } > > package test.sub; > public class LambdaTestSub extends test.LambdaTest { > ??? public void test() { > ??????? Runnable r = this::m; > ??????? r.run(); > ??? } > } Yes. This is specific for binary compatibility.?? the invocation of a protected method inherited from its supertype in a different package. The lambda proxy is in the same package as the target class (`test.sub` in the example above) but it has no access to `test.LambdaTest::m`. > > ...when compiled with JDK 14 javac. In this case the implClass is > test.sub.LambdaTestSub while implInfo is "invokeVirtual > test.LambdaTest.m:()void" and the method is not public. > In JDK 14, a lambda proxy `test.sub.LambdaTestSub$Lambda$$1234` is VM anonymous class which has a special powerful access as if the host class.?? This proxy class, even though it's not an instance of `test.LambdaTest`, can invoke? the protected`test.LambdaTest.m:()void` member. > Anyway, the name of the proxy class is derived from the targetClass > (and therefore shares the same package with targetClass) which is > caller's lookup class. Is targetClass always the same as implClass in > the invokeVirtual/invokeInterface case? > implMethod is the direct method handle describing the implementation method resolved by the VM.?? So it depends. In the above example, it's `test.LambdaTest.m:()void` and implClass is test.LambdaTest.? The targetClass is test.sub.LambdaTestSub which is *NOT* the same as implClass.? That's why we change if they are in the same package. It can be invoking a method in targetClass or a method in another class in the same package with package access, then implClass may or may not be the same as targetClass. > I also noticed that JDK 15 patched javac transforms method reference > in above code into a lambda method. But looking at the javac changes > in the patch, I don't quite see where this distinction between JDK 14 > and patched JDK 15 javac comes from. javac has been changed in JDK 14 to synthesize a bridge method if it's a method reference to access a protected member in a remote supertype? (JDK-8234729). BTW, the new tests relevant to this scenario are under test/jdk/java/lang/invoke/lambda/superProtectedMethod. > From the changes to method > com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: > > ??????????? final boolean needsConversionToLambda() { > ??????????????? return interfaceParameterIsIntersectionOrUnionType() || > ??????????????????????? isSuper || > ??????????????????????? needsVarArgsConversion() || > ??????????????????????? isArrayOp() || > #??????????????????????? isPrivateInOtherClass() || > isProtectedInSuperClassOfEnclosingClassInOtherPackage() || > ??????????????????????? !receiverAccessible() || > ??????????????????????? (tree.getMode() == ReferenceMode.NEW && > ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && > ????????????????????????? (tree.sym.owner.isLocal() || > tree.sym.owner.isInner())); > ??????????? } > > ...I would draw the conclusion that conversion to lambda is performed > in less cases not in more. Jan and Srikanath may be able to explain this further. > Hm. > > Regards, Peter > > On 4/3/20 11:11 AM, Peter Levart wrote: >> Hi Mandy, >> >> Good work. >> >> I'm trying to find out which language use-case is covered by the >> InnerClassLambdaMetafactory needing to inject method handle into the >> generated proxy class to be invoked instead of proxy class directly >> invoking the method: >> >> ??????? useImplMethodHandle = >> !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) >> ??????????????????????????????? && >> !Modifier.isPublic(implInfo.getModifiers()); >> >> If I check what implClass and implInfo get resolved to in >> AbstractValidatingLambdaMetafactory, there are several cases: >> >> ??????? this.implInfo = caller.revealDirect(implMethod); >> ??????? switch (implInfo.getReferenceKind()) { >> ??????????? case REF_invokeVirtual: >> ??????????? case REF_invokeInterface: >> ??????????????? this.implClass = implMethodType.parameterType(0); >> ??????????????? // reference kind reported by implInfo may not match >> implMethodType's first param >> ??????????????? // Example: implMethodType is (Cloneable)String, >> implInfo is for Object.toString >> ??????????????? this.implKind = implClass.isInterface() ? >> REF_invokeInterface : REF_invokeVirtual; >> ??????????????? this.implIsInstanceMethod = true; >> ??????????????? break; >> ??????????? case REF_invokeSpecial: >> ??????????????? // JDK-8172817: should use referenced class here, but >> we don't know what it was >> ??????????????? this.implClass = implInfo.getDeclaringClass(); >> ??????????????? this.implIsInstanceMethod = true; >> >> ??????????????? // Classes compiled prior to dynamic nestmate support >> invokes a private instance >> ??????????????? // method with REF_invokeSpecial. >> ??????????????? // >> ??????????????? // invokespecial should only be used to invoke >> private nestmate constructors. >> ??????????????? // The lambda proxy class will be defined as a >> nestmate of targetClass. >> ??????????????? // If the method to be invoked is an instance method >> of targetClass, then >> ??????????????? // convert to use invokevirtual or invokeinterface. >> ??????????????? if (targetClass == implClass && >> !implInfo.getName().equals("")) { >> ??????????????????? this.implKind = implClass.isInterface() ? >> REF_invokeInterface : REF_invokeVirtual; >> ??????????????? } else { >> ??????????????????? this.implKind = REF_invokeSpecial; >> ??????????????? } >> ??????????????? break; >> ??????????? case REF_invokeStatic: >> ??????????? case REF_newInvokeSpecial: >> ??????????????? // JDK-8172817: should use referenced class here for >> invokestatic, but we don't know what it was >> ??????????????? this.implClass = implInfo.getDeclaringClass(); >> ??????????????? this.implKind = implInfo.getReferenceKind(); >> ??????????????? this.implIsInstanceMethod = false; >> ??????????????? break; >> ??????????? default: >> ??????????????? throw new >> LambdaConversionException(String.format("Unsupported MethodHandle >> kind: %s", implInfo)); >> ??????? } >> >> >> For majority of cases (REF_invokeSpecial, REF_invokeStatic, >> REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass(); >> >> Only REF_invokeVirtual and REF_invokeInterface are possible >> kandidates, right? >> >> So when does the implMethod type of parameter 0 differ from the >> declaring class of the MethodHandleInfo cracked from that same >> implMethod and in addition those two types leave in different packages? >> This is concerning the instance method and so parameter 0 is what it wants to look at. >> Regards, Peter >> Hope this helps. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14328369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328369 From peter.levart at gmail.com Sat Apr 4 10:58:15 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 4 Apr 2020 12:58:15 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Message-ID: Hi Mandy, On 4/3/20 11:32 PM, Mandy Chung wrote: > Hi Peter, > > I added a JBS comment [1] to describe this special case trying to put > the story together (let me know if it needs more explanation). ? More > comment inline below. Thanks, this helps in establishing the historical context. > > On 4/3/20 4:40 AM, Peter Levart wrote: >> Ok, I think I found one such use-case. In the following example: >> >> package test; >> public class LambdaTest { >> ??? protected void m() { >> ??? } >> } >> >> package test.sub; >> public class LambdaTestSub extends test.LambdaTest { >> ??? public void test() { >> ??????? Runnable r = this::m; >> ??????? r.run(); >> ??? } >> } > > Yes. > > This is specific for binary compatibility.?? the invocation of a > protected method inherited from its supertype in a different package. > > The lambda proxy is in the same package as the target class > (`test.sub` in the example above) but it has no access to > `test.LambdaTest::m`. > >> >> ...when compiled with JDK 14 javac. In this case the implClass is >> test.sub.LambdaTestSub while implInfo is "invokeVirtual >> test.LambdaTest.m:()void" and the method is not public. >> > > In JDK 14, a lambda proxy `test.sub.LambdaTestSub$Lambda$$1234` is VM > anonymous class which has a special powerful access as if the host > class.?? This proxy class, even though it's not an instance of > `test.LambdaTest`, can invoke? the protected`test.LambdaTest.m:()void` > member. Right, the VM anonymous class "inherits" all access rights from the host class, which in above example is the subclass of test.LambdaTes. > >> Anyway, the name of the proxy class is derived from the targetClass >> (and therefore shares the same package with targetClass) which is >> caller's lookup class. Is targetClass always the same as implClass in >> the invokeVirtual/invokeInterface case? >> > > implMethod is the direct method handle describing the implementation > method resolved by the VM.?? So it depends. > > In the above example, it's `test.LambdaTest.m:()void` and implClass is > test.LambdaTest. Here I think, you are not quite right. First I need to clarify that we are talking about the case where the method reference in above example is not converted to lambda by javac, so the proxy class needs to invoke the superclass method directly (without the help of lambda bridge). I did an experiment and compiled the example with JDK 13 javac, where the patch for (JDK-8234729) is not applied yet. What I get from this compilation is the following metafactory bootstrap method invocation: ? 0: #35 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; ??? Method arguments: ????? #42 ()V ????? #43 REF_invokeVirtual test/LambdaTest.m:()V ????? #42 ()V The #43 is the implMethod method handle and it is the following: ? #43 = MethodHandle?????? 5:#44????????? // REF_invokeVirtual test/LambdaTest.m:()V ? #44 = Methodref????????? #2.#45???????? // test/LambdaTest.m:()V ? #45 = NameAndType??????? #46:#6???????? // m:()V ? #46 = Utf8?????????????? m ?? #2 = Class????????????? #4???????????? // test/LambdaTest ?? #4 = Utf8?????????????? test/LambdaTest *BUT* the class that looks up this MH from the constant pool is the subclass (test.sub.LambdaTestSub) which is equivalent to the following programmatic lookup: ??????? var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, "m", MethodType.methodType(void.class)); ??????? System.out.println(mh.type()); and this results in a method handle of the following type: (LambdaTestSub)void which is correct since the method handle *MUST* check that the passed in instance (this) is of type LambdaTestSub or subtype or else the "protected" access would be violated. And since the ref type is REF_invokeVirtual, the AbstractValidatingLambdaMetafactory assigns the following to the implClass: ??????? this.implMethodType = implMethod.type(); ??????? this.implInfo = caller.revealDirect(implMethod); ??????? switch (implInfo.getReferenceKind()) { ??????????? case REF_invokeVirtual: ??????????? case REF_invokeInterface: ??????????????? this.implClass = implMethodType.parameterType(0); ...which makes the implClass be LambdaTestSub in this case. Which is correct again since we want InnerClassLambdaMetafactory to decide that this is the special case for proxy to invoke the method via method handle: ??????? useImplMethodHandle = !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) ??????????????????????????????? && !Modifier.isPublic(implInfo.getModifiers()); If implClass was test.LambdaTest as you said above, this condition would evaluate to false, since implInfo is "invokeVirtual test.LambdaTest.m:()void" in above case. So everything is OK, but my original question was the following: The name of the generated proxy class is derived from the targetClass which is the caller's lookup class. In this example the caller is LambdaTestSub and this is the same as implClass in this case. Would those two classes always be the same in the case where the evaluation of the above `useImplMethodHandle` boolean matters? I mean, the decision about whether to base the proxy invocation strategy on method handle or direct bytecode invocation is based on one class (implClass), but the actual package of the proxy class which effectively influences the bytecode invocation rights is taken from another class (targetClass). On one hand the package of the proxy class has to be the same as targetClass if the proxy wants to be the nestmate of the targetClass (for example to have private access to the members of the nest). But OTOH it needs to be the same package also with implClass so that the above decision of the proxy invocation strategy is correct. I have a feeling that for protected virtual methods, this is true, because the type of the 0-argument of such method handle is always the lookup class. But am I right? What do you think of another alternative to invoking the super protected method in other package: What if the LMF would decide to base the name of the proxy class on the implInfo.getDeclaringClass() in such case? It would not have to be a nestmate of any class, just in the same package with the method's declaring class. Consequently it would be in the same module as the declaring class and loaded by the same class loader. Therefore it would have to be WEAKLY referenced from the class loader. And the Lookup instance passed to bootstrap LMF method would not be enough for defining such class. But LMF could obtain special powers since it is JDK internal class... Well, I don't know for myself. Is this situation rare enough so that invoking via method handle is not a drawback? It only happens when running JDK 13- compiled classes with JDK 15+ and in addition the method reference must point to protected method in a distant class. > The targetClass is test.sub.LambdaTestSub which is *NOT* the same as > implClass.? That's why we change if they are in the same package. > > It can be invoking a method in targetClass or a method in another > class in the same package with package access, then implClass may or > may not be the same as targetClass. > >> I also noticed that JDK 15 patched javac transforms method reference >> in above code into a lambda method. But looking at the javac changes >> in the patch, I don't quite see where this distinction between JDK 14 >> and patched JDK 15 javac comes from. > > javac has been changed in JDK 14 to synthesize a bridge method if it's > a method reference to access a protected member in a remote supertype? > (JDK-8234729). Ah, that was the reason I haven't seen the change in your patch. I used the JDK 13 javac and thought it would be the same as JDK 14 javac. My mistake. So this answers the question below... Regards, Peter > > BTW, the new tests relevant to this scenario are under > test/jdk/java/lang/invoke/lambda/superProtectedMethod. > >> From the changes to method >> com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: >> >> ??????????? final boolean needsConversionToLambda() { >> ??????????????? return interfaceParameterIsIntersectionOrUnionType() || >> ??????????????????????? isSuper || >> ??????????????????????? needsVarArgsConversion() || >> ??????????????????????? isArrayOp() || >> #??????????????????????? isPrivateInOtherClass() || >> isProtectedInSuperClassOfEnclosingClassInOtherPackage() || >> ??????????????????????? !receiverAccessible() || >> ??????????????????????? (tree.getMode() == ReferenceMode.NEW && >> ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && >> ????????????????????????? (tree.sym.owner.isLocal() || >> tree.sym.owner.isInner())); >> ??????????? } >> >> ...I would draw the conclusion that conversion to lambda is performed >> in less cases not in more. > > Jan and Srikanath may be able to explain this further. > >> Hm. >> >> Regards, Peter >> >> On 4/3/20 11:11 AM, Peter Levart wrote: >>> Hi Mandy, >>> >>> Good work. >>> >>> I'm trying to find out which language use-case is covered by the >>> InnerClassLambdaMetafactory needing to inject method handle into the >>> generated proxy class to be invoked instead of proxy class directly >>> invoking the method: >>> >>> ??????? useImplMethodHandle = >>> !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) >>> ??????????????????????????????? && >>> !Modifier.isPublic(implInfo.getModifiers()); >>> >>> If I check what implClass and implInfo get resolved to in >>> AbstractValidatingLambdaMetafactory, there are several cases: >>> >>> ??????? this.implInfo = caller.revealDirect(implMethod); >>> ??????? switch (implInfo.getReferenceKind()) { >>> ??????????? case REF_invokeVirtual: >>> ??????????? case REF_invokeInterface: >>> ??????????????? this.implClass = implMethodType.parameterType(0); >>> ??????????????? // reference kind reported by implInfo may not match >>> implMethodType's first param >>> ??????????????? // Example: implMethodType is (Cloneable)String, >>> implInfo is for Object.toString >>> ??????????????? this.implKind = implClass.isInterface() ? >>> REF_invokeInterface : REF_invokeVirtual; >>> ??????????????? this.implIsInstanceMethod = true; >>> ??????????????? break; >>> ??????????? case REF_invokeSpecial: >>> ??????????????? // JDK-8172817: should use referenced class here, >>> but we don't know what it was >>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>> ??????????????? this.implIsInstanceMethod = true; >>> >>> ??????????????? // Classes compiled prior to dynamic nestmate >>> support invokes a private instance >>> ??????????????? // method with REF_invokeSpecial. >>> ??????????????? // >>> ??????????????? // invokespecial should only be used to invoke >>> private nestmate constructors. >>> ??????????????? // The lambda proxy class will be defined as a >>> nestmate of targetClass. >>> ??????????????? // If the method to be invoked is an instance method >>> of targetClass, then >>> ??????????????? // convert to use invokevirtual or invokeinterface. >>> ??????????????? if (targetClass == implClass && >>> !implInfo.getName().equals("")) { >>> ??????????????????? this.implKind = implClass.isInterface() ? >>> REF_invokeInterface : REF_invokeVirtual; >>> ??????????????? } else { >>> ??????????????????? this.implKind = REF_invokeSpecial; >>> ??????????????? } >>> ??????????????? break; >>> ??????????? case REF_invokeStatic: >>> ??????????? case REF_newInvokeSpecial: >>> ??????????????? // JDK-8172817: should use referenced class here for >>> invokestatic, but we don't know what it was >>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>> ??????????????? this.implKind = implInfo.getReferenceKind(); >>> ??????????????? this.implIsInstanceMethod = false; >>> ??????????????? break; >>> ??????????? default: >>> ??????????????? throw new >>> LambdaConversionException(String.format("Unsupported MethodHandle >>> kind: %s", implInfo)); >>> ??????? } >>> >>> >>> For majority of cases (REF_invokeSpecial, REF_invokeStatic, >>> REF_newInvokeSpecial) the this.implClass = >>> implInfo.getDeclaringClass(); >>> >>> Only REF_invokeVirtual and REF_invokeInterface are possible >>> kandidates, right? >>> >>> So when does the implMethod type of parameter 0 differ from the >>> declaring class of the MethodHandleInfo cracked from that same >>> implMethod and in addition those two types leave in different packages? >>> > > This is concerning the instance method and so parameter 0 is what it > wants to look at. > >>> Regards, Peter >>> > > Hope this helps. > Mandy > [1] > https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14328369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328369 > > From peter.levart at gmail.com Sat Apr 4 16:16:15 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 4 Apr 2020 18:16:15 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Message-ID: <60700e61-11da-164c-c192-eb8bb5ee71bb@gmail.com> Hi Mandy, Just another observation of the code in InnerClassLambdaMetafactory... For the useImplMethodHandle case you generate the protectedImplMethod static field to hold the MH and a static setter method: ??????????? mv = cw.visitMethod(ACC_PRIVATE + ACC_STATIC, ??????????????????????????????? "setImplMethod", DESCR_SET_IMPL_METHOD, ??????????????????????????????? null, null); ...but then later after you define the class you inject the MH via a "staticSetter" method handle: ??????????????? MethodHandle mh = lookup.findStaticSetter(lookup.lookupClass(), NAME_FIELD_IMPL_METHOD, MethodHandle.class); ??????????????? mh.invokeExact(implMethod); So you don't invoke the generated setter method but set the field via special kind of method handle (equivalent to putstatic bytecode). You can remove the setImplMethod method generation code. Regards, Peter On 4/4/20 12:58 PM, Peter Levart wrote: > Hi Mandy, > > On 4/3/20 11:32 PM, Mandy Chung wrote: >> Hi Peter, >> >> I added a JBS comment [1] to describe this special case trying to put >> the story together (let me know if it needs more explanation). ? More >> comment inline below. > > Thanks, this helps in establishing the historical context. > >> >> On 4/3/20 4:40 AM, Peter Levart wrote: >>> Ok, I think I found one such use-case. In the following example: >>> >>> package test; >>> public class LambdaTest { >>> ??? protected void m() { >>> ??? } >>> } >>> >>> package test.sub; >>> public class LambdaTestSub extends test.LambdaTest { >>> ??? public void test() { >>> ??????? Runnable r = this::m; >>> ??????? r.run(); >>> ??? } >>> } >> >> Yes. >> >> This is specific for binary compatibility.?? the invocation of a >> protected method inherited from its supertype in a different package. >> >> The lambda proxy is in the same package as the target class >> (`test.sub` in the example above) but it has no access to >> `test.LambdaTest::m`. >> >>> >>> ...when compiled with JDK 14 javac. In this case the implClass is >>> test.sub.LambdaTestSub while implInfo is "invokeVirtual >>> test.LambdaTest.m:()void" and the method is not public. >>> >> >> In JDK 14, a lambda proxy `test.sub.LambdaTestSub$Lambda$$1234` is VM >> anonymous class which has a special powerful access as if the host >> class.?? This proxy class, even though it's not an instance of >> `test.LambdaTest`, can invoke? the >> protected`test.LambdaTest.m:()void` member. > > Right, the VM anonymous class "inherits" all access rights from the > host class, which in above example is the subclass of test.LambdaTes. > >> >>> Anyway, the name of the proxy class is derived from the targetClass >>> (and therefore shares the same package with targetClass) which is >>> caller's lookup class. Is targetClass always the same as implClass >>> in the invokeVirtual/invokeInterface case? >>> >> >> implMethod is the direct method handle describing the implementation >> method resolved by the VM.?? So it depends. >> >> In the above example, it's `test.LambdaTest.m:()void` and implClass >> is test.LambdaTest. > > Here I think, you are not quite right. First I need to clarify that we > are talking about the case where the method reference in above example > is not converted to lambda by javac, so the proxy class needs to > invoke the superclass method directly (without the help of lambda > bridge). I did an experiment and compiled the example with JDK 13 > javac, where the patch for (JDK-8234729) is not applied yet. What I > get from this compilation is the following metafactory bootstrap > method invocation: > > ? 0: #35 REF_invokeStatic > java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > ??? Method arguments: > ????? #42 ()V > ????? #43 REF_invokeVirtual test/LambdaTest.m:()V > ????? #42 ()V > > The #43 is the implMethod method handle and it is the following: > > ? #43 = MethodHandle?????? 5:#44????????? // REF_invokeVirtual > test/LambdaTest.m:()V > ? #44 = Methodref????????? #2.#45???????? // test/LambdaTest.m:()V > ? #45 = NameAndType??????? #46:#6???????? // m:()V > ? #46 = Utf8?????????????? m > ?? #2 = Class????????????? #4???????????? // test/LambdaTest > ?? #4 = Utf8?????????????? test/LambdaTest > > *BUT* the class that looks up this MH from the constant pool is the > subclass (test.sub.LambdaTestSub) which is equivalent to the following > programmatic lookup: > > ??????? var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, > "m", MethodType.methodType(void.class)); > ??????? System.out.println(mh.type()); > > and this results in a method handle of the following type: > (LambdaTestSub)void > > which is correct since the method handle *MUST* check that the passed > in instance (this) is of type LambdaTestSub or subtype or else the > "protected" access would be violated. > > And since the ref type is REF_invokeVirtual, the > AbstractValidatingLambdaMetafactory assigns the following to the > implClass: > > ??????? this.implMethodType = implMethod.type(); > ??????? this.implInfo = caller.revealDirect(implMethod); > ??????? switch (implInfo.getReferenceKind()) { > ??????????? case REF_invokeVirtual: > ??????????? case REF_invokeInterface: > ??????????????? this.implClass = implMethodType.parameterType(0); > > ...which makes the implClass be LambdaTestSub in this case. Which is > correct again since we want InnerClassLambdaMetafactory to decide that > this is the special case for proxy to invoke the method via method > handle: > > ??????? useImplMethodHandle = > !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) > ??????????????????????????????? && > !Modifier.isPublic(implInfo.getModifiers()); > > If implClass was test.LambdaTest as you said above, this condition > would evaluate to false, since implInfo is "invokeVirtual > test.LambdaTest.m:()void" in above case. > > So everything is OK, but my original question was the following: The > name of the generated proxy class is derived from the targetClass > which is the caller's lookup class. In this example the caller is > LambdaTestSub and this is the same as implClass in this case. Would > those two classes always be the same in the case where the evaluation > of the above `useImplMethodHandle` boolean matters? I mean, the > decision about whether to base the proxy invocation strategy on method > handle or direct bytecode invocation is based on one class > (implClass), but the actual package of the proxy class which > effectively influences the bytecode invocation rights is taken from > another class (targetClass). > > On one hand the package of the proxy class has to be the same as > targetClass if the proxy wants to be the nestmate of the targetClass > (for example to have private access to the members of the nest). But > OTOH it needs to be the same package also with implClass so that the > above decision of the proxy invocation strategy is correct. I have a > feeling that for protected virtual methods, this is true, because the > type of the 0-argument of such method handle is always the lookup > class. But am I right? > > What do you think of another alternative to invoking the super > protected method in other package: What if the LMF would decide to > base the name of the proxy class on the implInfo.getDeclaringClass() > in such case? It would not have to be a nestmate of any class, just in > the same package with the method's declaring class. Consequently it > would be in the same module as the declaring class and loaded by the > same class loader. Therefore it would have to be WEAKLY referenced > from the class loader. And the Lookup instance passed to bootstrap LMF > method would not be enough for defining such class. But LMF could > obtain special powers since it is JDK internal class... > > Well, I don't know for myself. Is this situation rare enough so that > invoking via method handle is not a drawback? It only happens when > running JDK 13- compiled classes with JDK 15+ and in addition the > method reference must point to protected method in a distant class. > >> The targetClass is test.sub.LambdaTestSub which is *NOT* the same as >> implClass.? That's why we change if they are in the same package. >> >> It can be invoking a method in targetClass or a method in another >> class in the same package with package access, then implClass may or >> may not be the same as targetClass. >> >>> I also noticed that JDK 15 patched javac transforms method reference >>> in above code into a lambda method. But looking at the javac changes >>> in the patch, I don't quite see where this distinction between JDK >>> 14 and patched JDK 15 javac comes from. >> >> javac has been changed in JDK 14 to synthesize a bridge method if >> it's a method reference to access a protected member in a remote >> supertype? (JDK-8234729). > > Ah, that was the reason I haven't seen the change in your patch. I > used the JDK 13 javac and thought it would be the same as JDK 14 > javac. My mistake. > > So this answers the question below... > > > Regards, Peter > >> >> BTW, the new tests relevant to this scenario are under >> test/jdk/java/lang/invoke/lambda/superProtectedMethod. >> >>> From the changes to method >>> com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: >>> >>> ??????????? final boolean needsConversionToLambda() { >>> ??????????????? return interfaceParameterIsIntersectionOrUnionType() || >>> ??????????????????????? isSuper || >>> ??????????????????????? needsVarArgsConversion() || >>> ??????????????????????? isArrayOp() || >>> #??????????????????????? isPrivateInOtherClass() || >>> isProtectedInSuperClassOfEnclosingClassInOtherPackage() || >>> ??????????????????????? !receiverAccessible() || >>> ??????????????????????? (tree.getMode() == ReferenceMode.NEW && >>> ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && >>> ????????????????????????? (tree.sym.owner.isLocal() || >>> tree.sym.owner.isInner())); >>> ??????????? } >>> >>> ...I would draw the conclusion that conversion to lambda is >>> performed in less cases not in more. >> >> Jan and Srikanath may be able to explain this further. >> >>> Hm. >>> >>> Regards, Peter >>> >>> On 4/3/20 11:11 AM, Peter Levart wrote: >>>> Hi Mandy, >>>> >>>> Good work. >>>> >>>> I'm trying to find out which language use-case is covered by the >>>> InnerClassLambdaMetafactory needing to inject method handle into >>>> the generated proxy class to be invoked instead of proxy class >>>> directly invoking the method: >>>> >>>> ??????? useImplMethodHandle = >>>> !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) >>>> ??????????????????????????????? && >>>> !Modifier.isPublic(implInfo.getModifiers()); >>>> >>>> If I check what implClass and implInfo get resolved to in >>>> AbstractValidatingLambdaMetafactory, there are several cases: >>>> >>>> ??????? this.implInfo = caller.revealDirect(implMethod); >>>> ??????? switch (implInfo.getReferenceKind()) { >>>> ??????????? case REF_invokeVirtual: >>>> ??????????? case REF_invokeInterface: >>>> ??????????????? this.implClass = implMethodType.parameterType(0); >>>> ??????????????? // reference kind reported by implInfo may not >>>> match implMethodType's first param >>>> ??????????????? // Example: implMethodType is (Cloneable)String, >>>> implInfo is for Object.toString >>>> ??????????????? this.implKind = implClass.isInterface() ? >>>> REF_invokeInterface : REF_invokeVirtual; >>>> ??????????????? this.implIsInstanceMethod = true; >>>> ??????????????? break; >>>> ??????????? case REF_invokeSpecial: >>>> ??????????????? // JDK-8172817: should use referenced class here, >>>> but we don't know what it was >>>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>>> ??????????????? this.implIsInstanceMethod = true; >>>> >>>> ??????????????? // Classes compiled prior to dynamic nestmate >>>> support invokes a private instance >>>> ??????????????? // method with REF_invokeSpecial. >>>> ??????????????? // >>>> ??????????????? // invokespecial should only be used to invoke >>>> private nestmate constructors. >>>> ??????????????? // The lambda proxy class will be defined as a >>>> nestmate of targetClass. >>>> ??????????????? // If the method to be invoked is an instance >>>> method of targetClass, then >>>> ??????????????? // convert to use invokevirtual or invokeinterface. >>>> ??????????????? if (targetClass == implClass && >>>> !implInfo.getName().equals("")) { >>>> ??????????????????? this.implKind = implClass.isInterface() ? >>>> REF_invokeInterface : REF_invokeVirtual; >>>> ??????????????? } else { >>>> ??????????????????? this.implKind = REF_invokeSpecial; >>>> ??????????????? } >>>> ??????????????? break; >>>> ??????????? case REF_invokeStatic: >>>> ??????????? case REF_newInvokeSpecial: >>>> ??????????????? // JDK-8172817: should use referenced class here >>>> for invokestatic, but we don't know what it was >>>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>>> ??????????????? this.implKind = implInfo.getReferenceKind(); >>>> ??????????????? this.implIsInstanceMethod = false; >>>> ??????????????? break; >>>> ??????????? default: >>>> ??????????????? throw new >>>> LambdaConversionException(String.format("Unsupported MethodHandle >>>> kind: %s", implInfo)); >>>> ??????? } >>>> >>>> >>>> For majority of cases (REF_invokeSpecial, REF_invokeStatic, >>>> REF_newInvokeSpecial) the this.implClass = >>>> implInfo.getDeclaringClass(); >>>> >>>> Only REF_invokeVirtual and REF_invokeInterface are possible >>>> kandidates, right? >>>> >>>> So when does the implMethod type of parameter 0 differ from the >>>> declaring class of the MethodHandleInfo cracked from that same >>>> implMethod and in addition those two types leave in different >>>> packages? >>>> >> >> This is concerning the instance method and so parameter 0 is what it >> wants to look at. >> >>>> Regards, Peter >>>> >> >> Hope this helps. >> Mandy >> [1] >> https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14328369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328369 >> >> > From mandy.chung at oracle.com Sat Apr 4 16:45:20 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 4 Apr 2020 09:45:20 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <60700e61-11da-164c-c192-eb8bb5ee71bb@gmail.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> <60700e61-11da-164c-c192-eb8bb5ee71bb@gmail.com> Message-ID: <53d28cd4-8e4e-b1bb-f218-a9f382ea9df6@oracle.com> On 4/4/20 9:16 AM, Peter Levart wrote: > Hi Mandy, > > Just another observation of the code in InnerClassLambdaMetafactory... > > For the useImplMethodHandle case you generate the protectedImplMethod > static field to hold the MH and a static setter method: > > ??????????? mv = cw.visitMethod(ACC_PRIVATE + ACC_STATIC, > ??????????????????????????????? "setImplMethod", DESCR_SET_IMPL_METHOD, > ??????????????????????????????? null, null); > > ...but then later after you define the class you inject the MH via a > "staticSetter" method handle: > > ??????????????? MethodHandle mh = > lookup.findStaticSetter(lookup.lookupClass(), NAME_FIELD_IMPL_METHOD, > MethodHandle.class); > ??????????????? mh.invokeExact(implMethod); > > So you don't invoke the generated setter method but set the field via > special kind of method handle (equivalent to putstatic bytecode). > You can remove the setImplMethod method generation code. > Good catch.?? Removed the unused method. Mandy > Regards, Peter From mandy.chung at oracle.com Sat Apr 4 18:15:14 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 4 Apr 2020 11:15:14 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Message-ID: <5fb01f1d-7d4d-b024-095a-4f429b2a06af@oracle.com> Hi Peter, On 4/4/20 3:58 AM, Peter Levart wrote: > > Here I think, you are not quite right. First I need to clarify that we > are talking about the case where the method reference in above example > is not converted to lambda by javac, so the proxy class needs to > invoke the superclass method directly (without the help of lambda > bridge). I did an experiment and compiled the example with JDK 13 > javac, where the patch for (JDK-8234729) is not applied yet. What I > get from this compilation is the following metafactory bootstrap > method invocation: > > ? 0: #35 REF_invokeStatic > java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > ??? Method arguments: > ????? #42 ()V > ????? #43 REF_invokeVirtual test/LambdaTest.m:()V > ????? #42 ()V > > The #43 is the implMethod method handle and it is the following: > > ? #43 = MethodHandle?????? 5:#44????????? // REF_invokeVirtual > test/LambdaTest.m:()V > ? #44 = Methodref????????? #2.#45???????? // test/LambdaTest.m:()V > ? #45 = NameAndType??????? #46:#6???????? // m:()V > ? #46 = Utf8?????????????? m > ?? #2 = Class????????????? #4???????????? // test/LambdaTest > ?? #4 = Utf8?????????????? test/LambdaTest > > *BUT* the class that looks up this MH from the constant pool is the > subclass (test.sub.LambdaTestSub) which is equivalent to the following > programmatic lookup: > > ??????? var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, > "m", MethodType.methodType(void.class)); > ??????? System.out.println(mh.type()); > > and this results in a method handle of the following type: > (LambdaTestSub)void > > which is correct since the method handle *MUST* check that the passed > in instance (this) is of type LambdaTestSub or subtype or else the > "protected" access would be violated. > > And since the ref type is REF_invokeVirtual, the > AbstractValidatingLambdaMetafactory assigns the following to the > implClass: > > ??????? this.implMethodType = implMethod.type(); > ??????? this.implInfo = caller.revealDirect(implMethod); > ??????? switch (implInfo.getReferenceKind()) { > ??????????? case REF_invokeVirtual: > ??????????? case REF_invokeInterface: > ??????????????? this.implClass = implMethodType.parameterType(0); > > ...which makes the implClass be LambdaTestSub in this case. Which is > correct again since we want InnerClassLambdaMetafactory to decide that > this is the special case for proxy to invoke the method via method > handle: > > ??????? useImplMethodHandle = > !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) > ??????????????????????????????? && > !Modifier.isPublic(implInfo.getModifiers()); > > If implClass was test.LambdaTest as you said above, this condition > would evaluate to false, since implInfo is "invokeVirtual > test.LambdaTest.m:()void" in above case. > My bad.? I mixed up with implClass and implInfo cracked from implMethod in your question. implInfo::getDeclaringClass() returns the declaring class of the resolved method, which is the superclass (which is what I have been thinking for test.LambdaTest). implClass is the target type of the method reference. AbstractValidatingLambdaMetafactory has clear comment: ??? final MethodType implMethodType;? // Type of the implMethod MethodHandle "(CC,int)String" ??? final Class implClass;???????????????? // Class for referencing the implementation method "class CC" > So everything is OK, but my original question was the following: The > name of the generated proxy class is derived from the targetClass > which is the caller's lookup class. In this example the caller is > LambdaTestSub and this is the same as implClass in this case. Yes. > Would those two classes always be the same in the case where the > evaluation of the above `useImplMethodHandle` boolean matters? I mean, > the decision about whether to base the proxy invocation strategy on > method handle or direct bytecode invocation is based on one class > (implClass), but the actual package of the proxy class which > effectively influences the bytecode invocation rights is taken from > another class (targetClass). > > On one hand the package of the proxy class has to be the same as > targetClass if the proxy wants to be the nestmate of the targetClass > (for example to have private access to the members of the nest). But > OTOH it needs to be the same package also with implClass so that the > above decision of the proxy invocation strategy is correct. I have a > feeling that for protected virtual methods, this is true, because the > type of the 0-argument of such method handle is always the lookup > class. But am I right? > > What do you think of another alternative to invoking the super > protected method in other package: What if the LMF would decide to > base the name of the proxy class on the implInfo.getDeclaringClass() > in such case? It would not have to be a nestmate of any class, just in > the same package with the method's declaring class. Consequently it > would be in the same module as the declaring class and loaded by the > same class loader. Therefore it would have to be WEAKLY referenced > from the class loader. And the Lookup instance passed to bootstrap LMF > method would not be enough for defining such class. But LMF could > obtain special powers since it is JDK internal class... > The implementation of the method reference invocation is logical part of the caller class.? I don't think spinning the proxy class in a remote package is the desirable thing to do (injecting a class from package A to package B). > Well, I don't know for myself. Is this situation rare enough so that > invoking via method handle is not a drawback? It only happens when > running JDK 13- compiled classes with JDK 15+ and in addition the > method reference must point to protected method in a distant class. There are other alternatives we considered.? This implementation is a just short term solution.? We plan to follow up some future enhancements that are the possible longer-term solutions for this issue. 1. JDK-8239580 evaluate the performance of direct method handle invocation rather than bytecode invocation for ALL cases Direct invocation of the `implMethod` method handle by the lambda proxy was explored in JDK 8 lambda development time. It is time to remeasure the performance of direct method handle invocation and re-evaluate that approach. 2.? JDK-8230501 class data support.? The live MethodHandle can be passed to the hidden class to replace the current implementation to set the implMethod in a static field of proxy class after it's defined. 3. JDK-8199386 enhance Lookup::in to support nestmates Hope this helps. Mandy From mandy.chung at oracle.com Mon Apr 6 18:54:11 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 6 Apr 2020 11:54:11 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> Message-ID: On 4/6/20 9:56 AM, serguei.spitsyn at oracle.com wrote: > > The suggested fix is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/ > This patch looks okay. I'll include in my local patch. On 4/6/20 11:00 AM, Chris Plummer wrote: > > I think that's fine but I don't think it should be done in the context > of this Vahalla webrev since it has nothing to do with Vahalla. I'd > suggest filing an RFE and pushing it to jdk/jdk. Easier to track that > way if there are issues down the road. > I am okay to follow up as a separate RFE. thanks Mandy From serguei.spitsyn at oracle.com Mon Apr 6 19:08:46 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 12:08:46 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> Message-ID: On 4/6/20 11:54, Mandy Chung wrote: > On 4/6/20 9:56 AM, serguei.spitsyn at oracle.com wrote: >> >> The suggested fix is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/ >> > > This patch looks okay. I'll include in my local patch. > > On 4/6/20 11:00 AM, Chris Plummer wrote: >> >> I think that's fine but I don't think it should be done in the >> context of this Vahalla webrev since it has nothing to do with >> Vahalla. I'd suggest filing an RFE and pushing it to jdk/jdk. Easier >> to track that way if there are issues down the road. >> > > I am okay to follow up as a separate RFE. Filed RFE: ? https://bugs.openjdk.java.net/browse/JDK-8242241 ??? add assert to ClassUnloadEventImpl::className Thanks, Serguei > > thanks > Mandy From john.r.rose at oracle.com Tue Apr 7 00:21:04 2020 From: john.r.rose at oracle.com (John Rose) Date: Mon, 6 Apr 2020 17:21:04 -0700 Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class?? In-Reply-To: <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com> References: <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com> <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com> <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com> <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com> Message-ID: On Apr 2, 2020, at 10:03 PM, John Rose wrote: > > But, I think the best compromise is to admit that, just > as Class::getName returns an intentionally invalid > though suggestive class name (rather than null or an > exception), so Class::descriptorString should return > the intentionally invalid though suggestive field > descriptor which is regularly derived from said > Class::getName. This provides consistency in > string-valued outputs; in the absence of an argument > why their treatment should be inconsistent, > consistency is less confusing and should win. My previous Email was confusing because it gave two conflicting answers both incomplete. Let me start again. (Thanks Mandy for querying me on Slack.) First of all, it should *never* be the case that a `ClassDesc` should represent a symbol which is not well formed at the descriptor level. Since there is no well formed descriptor for a HC, it followed that `Class::describeConstable` should never return a non-empty value. Second of all, associated with the constable interface for `Class`, but independent, are three API points that produce useful reflective representations of type `String`. There is the old `getName` and `getSimpleName`, and the new `descriptorString`. In order to allow HCs to be printed they must be named. Thus, HCs must produce names. (And simple-names, for places like the `toString` method of `MethodType`.) These names are dual-use, for human reading and for resolution by recycling them through `Class::toName` and related API points. The first use does not require well-formed class names, and for HC?s (for the first time) we *forbid* `toName` to produce a well-formed class name. This ensures that a HC?s name can be printed for humans to read, but cannot accidentally be resolved. I suggest that `descriptorString` be *also* regarded as a dual-use API point. This means that (a) a HC?s descriptor string should be unsurprising to a human reader, and (b) it must be unacceptable as an input for a resolving API point. A corollary of (b) and of my earlier point is that a HC?s descriptor string *also* must be unacceptable to the factory methods for `ClassDesc` and `MethodTypeDesc`. Let me suggest a specific way to do this. A HC?s name is of the form `N + S`, where N is a valid class name, derived from the HC?s classfile, and S is a suffix added by the platform. To prevent confusion with other names, the suffix starts with slash ?/? and is otherwise a valid unqualified name. In order to create a dual-use (human readable but *not* resolvable) descriptor for a HC, define it as the valid descriptor for a class whose name is `N`, with a suffix `S`. I think this meets all relevant use cases and requirements. For example, a HC with original name `foo.Bar` and suffix `/123` would have a descriptor string of `Lfoo/Bar;/123`. This is simple and unsurprising. Yes, it would be even simpler to throw an exception from `Class::descriptorString` if the class is a HC. But I think that?s *too simple*, because it makes `descriptorString` useless as an input to any class?s `toString` method. I think that would be a mistake, in the long run. String producing methods are very useful for user output and having them throw (or return null which is about as surprising) is a sharp edge for anybody using them for user output. I could be wrong about that, and if the rest of y?all are sure I?m wrong about that, go ahead and throw an exception. I?ll reserve the right to say ?I told you so? when the appropriate time comes. ? John From thartmann at openjdk.java.net Tue Apr 7 16:22:54 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 7 Apr 2020 16:22:54 GMT Subject: [lworld] RFR: 8242210: [lworld] TestCallingConvention::test36 spuriously fails Message-ID: Problems: - G1 pre- and post-barriers used when (un-)packing arguments for the calling convention can call into the runtime which screws up argument registers. Save all registers until JDK-8232094 is fixed in mainline (it's the slow path anyway). - SignatureStream::as_value_klass triggers a SystemDictionary lookup which acquires the ProtectionDomainSet_lock. When used from fieldDescriptor::print_on_for when some debug printing flags are enabled, this conflicts with the tty_lock. We should simply use get_value_field_klass instead. Also, we should handle null as a vale for non-flattened fields. TraceDeoptimization needs to handle re-allocation of the inline type return value. I've also added a new StressCC option to the ValueTypeTest suite to randomly restrict some compilation to C1 and thereby stress test the calling convention. ------------- Commit messages: - 8242210: [lworld] TestCallingConvention::test36 spuriously fails Changes: https://git.openjdk.java.net/valhalla/pull/13/files Webrev: https://webrevs.openjdk.java.net/valhalla/13/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242210 Stats: 130 lines in 10 files changed: 26 ins; 52 del; 52 mod Patch: https://git.openjdk.java.net/valhalla/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/13/head:pull/13 PR: https://git.openjdk.java.net/valhalla/pull/13 From fparain at openjdk.java.net Tue Apr 7 17:14:15 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 7 Apr 2020 17:14:15 GMT Subject: [lworld] RFR: 8242210: [lworld] TestCallingConvention::test36 spuriously fails In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 16:17:19 GMT, Tobias Hartmann wrote: > Problems: > - G1 pre- and post-barriers used when (un-)packing arguments for the calling convention can call into the runtime which > screws up argument registers. Save all registers until JDK-8232094 is fixed in mainline (it's the slow path anyway). > - SignatureStream::as_value_klass triggers a SystemDictionary lookup which acquires the ProtectionDomainSet_lock. When > used from fieldDescriptor::print_on_for when some debug printing flags are enabled, this conflicts with the tty_lock. > We should simply use get_value_field_klass instead. Also, we should handle null as a vale for non-flattened fields. > TraceDeoptimization needs to handle re-allocation of the inline type return value. > > I've also added a new StressCC option to the ValueTypeTest suite to randomly restrict some compilation to C1 and > thereby stress test the calling convention. Looks good to me, however, I haven't reviewed the tests. ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/valhalla/pull/13 From mandy.chung at oracle.com Tue Apr 7 17:25:50 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 7 Apr 2020 10:25:50 -0700 Subject: Review Request: 8242012: Drop the uniqueness guarantee from the suffix of the name of a hidden class In-Reply-To: References: Message-ID: On 4/1/20 7:34 PM, John Rose wrote: > On Apr 1, 2020, at 6:19 PM, Mandy Chung > wrote: >> >> I filehttps://bugs.openjdk.java.net/browse/JDK-8242012to track this >> issue. > > I would prefer to say that the suffix is simply an unspecified > simple name. ?Then leave it open for implementations to make it more > or less unpredictable, as a matter of QoS. > The standard of quality we > should aim at is that of System.identityHashCode?nothing much more > than that is desirable, and it?s easy to get at least that much quality. > > The java doc for Object.hashCode says this about the QoS I want here: > >> ? ? ?* As far as is reasonably practical, the {@code hashCode} method >> defined >> ? ? ?* by class {@code Object} returns distinct integers for distinct >> objects. > > So, the behavior I would like to keep open is something that cannot > readily be distinguished from functions like these? > > static String nextSuffix1() { return new > Integer.toHexString(Object().hashCode()); } > static String nextSuffix2() { return new > Integer.toUnsignedString(Object().hashCode(), 36); } > static String nextSuffix3() { return nextSuffix1()+nextSuffix2(); } > > ?and many others. > > And I would settle for nextSuffix1, which (after all) is also a suffix of > the already specified value of new Object().toString(). ?To me, the result > of HC.toString() (where HC is a hidden class) should not be more deeply > informative than new Object().toString(). ?Also, the behavior currently > coded (in mangle_hidden_class_name) is consistent with nextSuffix1. > > (Observation: ?The JVM has no reason to choose this suffix, beyond the > simple reason that it is the first party to peek into the byte[] array of > the classfile image. ?It would be nice if the JDK platform code could > take responsibility for generating that extra suffix; it would make QoS > adjustments easier down the road. ?We could even go all the way and > guarantee that all such suffixes are truly unique; it would be a page of > Java code but several pages of HotSpot code. ?But, that?s inconvenient, > so I don?t recommend that now.) > > A parting shot: ?Yes, technically the implementation of the suffix > choosing (mangle_hidden_class_name) probably upholds almost the full > guarantee. ?(Although, it can fail if the JVM unloads and reloads a HC > of the same name at the same metadata address.) ?But if we make the > full guarantee part of the API, we set ourselves up to maintain that > strong > behavior even if we move to another implementation in which metadata > pointers are allowed to change. ?I know we don?t want to do that, but > this is an example of how an overly strong guarantee that seems easy > to do in *one* JVM implementation can create headaches for *other* > JVM implementations. ?What?s easy to do in our implementation is > *often* close to the right primitive to specify, but we have a > responsibility > to remove unnecessary promises and other implementation artifacts > from our specification. > > ? John Thanks John for this. This is the spec update.?? I leave the mangle_hidden_class_name as is.? We can move out the suffix assignment from the VM to the library code as a future cleanup. diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java +++ b/src/java.base/share/classes/java/lang/Class.java @@ -799,8 +799,7 @@ ????? *????? where {@code N} is the binary name ????? *????? indicated by the {@code class} file passed to ????? *????? {@link java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, MethodHandles.Lookup.ClassOption...) -???? *????? Lookup::defineHiddenClass} and {@code } is an unqualified name -???? *????? that is guaranteed to be unique during this execution of the JVM. +???? *????? Lookup::defineHiddenClass}, and {@code } is an unqualified name. ????? * ????? * ????? *

If this {@code Class} object represents an array class, then diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java @@ -1781,8 +1781,7 @@ ????????? * denote a class or interface in the same package as the lookup class. ????????? * ????????? *

  • Let {@code CN} be the string {@code N + "." + }, -???????? * where {@code } is an unqualified name that is guaranteed to be unique -???????? * during this execution of the JVM. +???????? * where {@code } is an unqualified name. ????????? * ????????? *

    Let {@code newBytes} be the {@code ClassFile} structure given by ????????? * {@code bytes} with an additional entry in the {@code constant_pool} table, thanks Mandy From john.r.rose at oracle.com Wed Apr 8 02:47:18 2020 From: john.r.rose at oracle.com (John Rose) Date: Tue, 7 Apr 2020 19:47:18 -0700 (PDT) Subject: Review Request: 8242012: Drop the uniqueness guarantee from the suffix of the name of a hidden class In-Reply-To: References: Message-ID: <30705628-9779-4537-8DBE-C84D783B9F60@oracle.com> Thank you for fixing that. It looks good to me. > On Apr 7, 2020, at 10:25 AM, Mandy Chung wrote: > > On 4/1/20 7:34 PM, John Rose wrote: >> On Apr 1, 2020, at 6:19 PM, Mandy Chung > wrote: >>> >>> I file https://bugs.openjdk.java.net/browse/JDK-8242012 to track this issue. >> >> I would prefer to say that the suffix is simply an unspecified >> simple name. Then leave it open for implementations to make it more >> or less unpredictable, as a matter of QoS. >> The standard of quality we >> should aim at is that of System.identityHashCode?nothing much more >> than that is desirable, and it?s easy to get at least that much quality. >> >> The java doc for Object.hashCode says this about the QoS I want here: >> >>> * As far as is reasonably practical, the {@code hashCode} method defined >>> * by class {@code Object} returns distinct integers for distinct objects. >> >> So, the behavior I would like to keep open is something that cannot >> readily be distinguished from functions like these? >> >> static String nextSuffix1() { return new Integer.toHexString(Object().hashCode()); } >> static String nextSuffix2() { return new Integer.toUnsignedString(Object().hashCode(), 36); } >> static String nextSuffix3() { return nextSuffix1()+nextSuffix2(); } >> >> ?and many others. >> >> And I would settle for nextSuffix1, which (after all) is also a suffix of >> the already specified value of new Object().toString(). To me, the result >> of HC.toString() (where HC is a hidden class) should not be more deeply >> informative than new Object().toString(). Also, the behavior currently >> coded (in mangle_hidden_class_name) is consistent with nextSuffix1. >> >> (Observation: The JVM has no reason to choose this suffix, beyond the >> simple reason that it is the first party to peek into the byte[] array of >> the classfile image. It would be nice if the JDK platform code could >> take responsibility for generating that extra suffix; it would make QoS >> adjustments easier down the road. We could even go all the way and >> guarantee that all such suffixes are truly unique; it would be a page of >> Java code but several pages of HotSpot code. But, that?s inconvenient, >> so I don?t recommend that now.) >> >> A parting shot: Yes, technically the implementation of the suffix >> choosing (mangle_hidden_class_name) probably upholds almost the full >> guarantee. (Although, it can fail if the JVM unloads and reloads a HC >> of the same name at the same metadata address.) But if we make the >> full guarantee part of the API, we set ourselves up to maintain that strong >> behavior even if we move to another implementation in which metadata >> pointers are allowed to change. I know we don?t want to do that, but >> this is an example of how an overly strong guarantee that seems easy >> to do in *one* JVM implementation can create headaches for *other* >> JVM implementations. What?s easy to do in our implementation is >> *often* close to the right primitive to specify, but we have a responsibility >> to remove unnecessary promises and other implementation artifacts >> from our specification. >> >> ? John > > Thanks John for this. > > This is the spec update. I leave the mangle_hidden_class_name as is. We can move out the suffix assignment from the VM to the library code as a future cleanup. > > diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java > --- a/src/java.base/share/classes/java/lang/Class.java > +++ b/src/java.base/share/classes/java/lang/Class.java > @@ -799,8 +799,7 @@ > * where {@code N} is the binary name > * indicated by the {@code class} file passed to > * {@link java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, MethodHandles.Lookup.ClassOption...) > - * Lookup::defineHiddenClass} and {@code } is an unqualified name > - * that is guaranteed to be unique during this execution of the JVM. > + * Lookup::defineHiddenClass}, and {@code } is an unqualified name. > * > * > *

    If this {@code Class} object represents an array class, then > diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > @@ -1781,8 +1781,7 @@ > * denote a class or interface in the same package as the lookup class.

    • > * > *
  • Let {@code CN} be the string {@code N + "." + }, > - * where {@code } is an unqualified name that is guaranteed to be unique > - * during this execution of the JVM. > + * where {@code } is an unqualified name. > * > *

    Let {@code newBytes} be the {@code ClassFile} structure given by > * {@code bytes} with an additional entry in the {@code constant_pool} table, > > thanks > Mandy From thartmann at openjdk.java.net Wed Apr 8 05:57:52 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 8 Apr 2020 05:57:52 GMT Subject: [lworld] RFR: 8242210: [lworld] TestCallingConvention::test36 spuriously fails In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 17:11:50 GMT, Frederic Parain wrote: >> Problems: >> - G1 pre- and post-barriers used when (un-)packing arguments for the calling convention can call into the runtime which >> screws up argument registers. Save all registers until JDK-8232094 is fixed in mainline (it's the slow path anyway). >> - SignatureStream::as_value_klass triggers a SystemDictionary lookup which acquires the ProtectionDomainSet_lock. When >> used from fieldDescriptor::print_on_for when some debug printing flags are enabled, this conflicts with the tty_lock. >> We should simply use get_value_field_klass instead. Also, we should handle null as a vale for non-flattened fields. >> TraceDeoptimization needs to handle re-allocation of the inline type return value. >> >> I've also added a new StressCC option to the ValueTypeTest suite to randomly restrict some compilation to C1 and >> thereby stress test the calling convention. > > Looks good to me, however, I haven't reviewed the tests. Thanks, Frederic! ------------- PR: https://git.openjdk.java.net/valhalla/pull/13 From dsimms at openjdk.java.net Wed Apr 8 07:52:08 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 8 Apr 2020 07:52:08 GMT Subject: git: openjdk/valhalla: lworld: 8242344: [lworld] JDK-8236522 class_list_match_sane() introduced strncpy truncation warnings Message-ID: Changeset: 1aea5d2e Author: David Simms Date: 2020-04-08 07:51:20 +0000 URL: https://git.openjdk.java.net/valhalla/commit/1aea5d2e 8242344: [lworld] JDK-8236522 class_list_match_sane() introduced strncpy truncation warnings ! src/hotspot/share/utilities/stringUtils.cpp From dsimms at openjdk.java.net Wed Apr 8 07:56:03 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 8 Apr 2020 07:56:03 GMT Subject: [lworld] FYI: 8242344: [lworld] JDK-8236522 class_list_match_sane() introduced strncpy truncation warnings Message-ID: Removed testing code causing strncpy truncation warnings. Need a new bug to reintroduce testing via gtest instead. ------------- Commit messages: - 8242344: [lworld] JDK-8236522 class_list_match_sane() introduced strncpy truncation warnings Changes: https://git.openjdk.java.net/valhalla/pull/14/files Webrev: https://webrevs.openjdk.java.net/valhalla/14/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242344 Stats: 67 lines in 1 file changed: 0 ins; 67 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/14/head:pull/14 PR: https://git.openjdk.java.net/valhalla/pull/14 From dsimms at openjdk.java.net Wed Apr 8 15:04:11 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 8 Apr 2020 15:04:11 GMT Subject: [lworld] RFR: Merge openjdk/jdk:master Message-ID: <9v_Nzt6AEhWCSHWLXToKDPonVNRO4mP61zzxnSY5l38=.10c4838a-3088-4a6d-82bc-41039ff12eb5@github.com> Merge jdk-15+16 from master ------------- Commit messages: - Remove whitespace/tabs - Merge branch 'lworld' into lworld_merge - Discovered merge issue JDK-8242269 - All done merging master - 8241727: Typos: empty lines in javadoc, inconsistent indents, etc. (core-libs only) - 8232846: ProcessHandle.Info command with non-English shows question marks - 8241771: Remove dead code in SparsePRT - 8241789: Make citations of JLS and JVMS consistent in java.lang.Class - 8241765: Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier - 8241721: Change to GCC 9.2 for building on Linux at Oracle - 8241631: PropertyGetterTaglet, PropertySetterTaglet may be removed - 8239563: Reduce public exports in dynamic libraries built from JDK static libraries - 8241750: x86_32 build failure after JDK-8227269 - 8193210: [JVMCI/Graal] add JFR compiler phase/inlining events - 8241400: [macos] jpackageapplauncher/main.m built using CXXFLAGS_JDKEXE - 8241748: Shenandoah: inline MarkingContext TAMS methods - 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap - 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() - 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved - 8241660: Add virtualization information output to hs_err file on macOS - 8241336: Some java.net tests failed with NoRouteToHostException on MacOS with special network configuration - 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier - 8241597: x86: Remove MMX support - 8241434: x86: Fix Assembler::emit_operand asserts for XMM registers - 8241436: C2: Factor out C2-specific code from MacroAssembler - 8227269: Slow class loading when running with JDWP - 8241586: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64 - 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java - 8240676: Meet not symmetric failure when running lucene on jdk8 - 8238855: Move G1ConcurrentMark flag sanity checks to g1Arguments - 8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624 - 8241723: Build error after 8241581 - 8241581: Add BitMap::count_one_bits variant for arbitrary lengths - 8129841: Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr - 8241470: HtmlStyle: group and document members: description, flex, signature - 8241696: ProblemList gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java due to JDK-8241293 - 8236975: compiler/graalunit tests fails with --illegal-access=deny - 8241673: Shenandoah: refactor anti-false-sharing padding - 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace - 8233093: Move CDS heap oopmaps into new MetaspaceShared::bm region - 8240634: event/runtime/TestMetaspaceAllocationFailure.java times out - 8196751: Add jhsdb option to specify debug server RMI connector port - 8241596: ZGC: Shorten runtime of gc/z/TestUncommit.java - 8241674: Fix incorrect jtreg option in FilePublisherPermsTest - 8172485: [TESTBUG] RedefineLeak.java runs out of metaspace memory - 8241595: Fix missing debug_orig information in Ideal Graph Visualizer - 8235459: HttpRequest.BodyPublishers::ofFile assumes the default file system - Added tag jdk-15+16 for changeset 5c7ec21f5d13 - 8241649: Optimize Character.toString - 8241365: Define Unique_Node_List::contains() to prevent usage by mistake - 8240335: C2: assert(found_sfpt) failed: no node in loop that's not input to safepoint - 8241491: Problem list jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java on aix - 8241419: Remove unused InterfaceSupport::_number_of_calls - 8241482: AArch64: Fix a potential issue after JDK-8239549 - 8241427: Coarsen locking in Modules::add_module_exports - 8237977: Further update javax/net/ssl/compatibility/Compatibility.java - 8241544: update stylesheet for *-page CSS class rename and hyphenated naming - 8237219: Disable native SunEC implementation by default - 8241311: Move some charset mapping tests from closed to open - 8241583: Shenandoah: turn heap lock asserts into macros - 8237599: Greedy matching against supplementary chars fails to respect the region - 8237859: C2: Crash when loads float above range check - 8241584: Remove unused classLoader perf counters - 8241500: FieldLayout/OldLayoutCheck.java fails in 32-bit VMs - 8241433: x86: Add VBMI CPU feature detection - 8241458: [JVMCI] add mark value to expose CodeOffsets::Frame_Complete - 8241545: Shenandoah: purge root work overwrites counters after JDK-8228818 - 8241445: Fix copyright in test/jdk/tools/launcher/ArgFileSyntax.java - 8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays - 8241534: Shenandoah: region status should include update watermark - 8241520: Shenandoah: simplify region sequence numbers handling - 8241395: Factor out platform independent code for os::xxx_memory_special() - 8241532: ProblemList tests from 8241530 on OSX - 8240905: assert(mem == (Node*)1 || mem == mem2) failed: multiple Memories being matched at once? - 8237497: vmStructs_jvmci.cpp does not check that the correct field type is specified - 8241144: Javadoc is not generated for new module jdk.nio.mapmode - 8241067: Shenandoah: improve ShenandoahNMethod::has_cset_oops arguments - 8241371: Refactor and consolidate package_from_name - 8241292: Interactive Search results are not highlighted as they used to be - 8241244: CDS dynamic dump asserts in ArchivePtrBitmapCleaner::do_bit - 8241190: Fix name clash for constants-summary CSS class - 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation - 8241435: Shenandoah: avoid disabling pacing with "aggressive" - 8241351: Shenandoah: fragmentation metrics overhaul - 8231779: crash HeapWord*ParallelScavengeHeap::failed_mem_allocate - 8240248: Extend superword reduction optimizations for x86 - 8240975: Extend NativeLibraries to support explicit unloading - 8241443: Problem list some java.net tests failing with NoRouteToHostException on macOS with special network configuration - 8241068: Shenandoah: improve ShenandoahTraversalGC constructor arguments - 8241271: Make hotspot build reproducible - 8241310: Fix warnings in jdk buildtools - 8241091: AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction" - 8215712: Parsing extension failure may alert decode_error - Merge - 8232634: Problem List ICMColorDataTest.java - 8241291: JCK test javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails - 8241319: WB_GetCodeBlob doesn't have ResourceMark - 8241014: Miscellaneous typos in documentation comments - 8240921: Minor correction to HttpResponse.BodySubscribers example - 8241009: CommandLineFlagComboNegative.java fails after JDK-8240563 - 8219989: Retire the com.sun.net.ssl.internal.ssl.Provider name - 8241039: Retire the deprecated SSLSession.getPeerCertificateChain() method - Merge - 8240786: [TESTBUG] The test java/awt/Window/GetScreenLocation/GetScreenLocationTest.java fails on HiDPI screen - 8241296: Segfault in JNIHandleBlock::oops_do() - 8237894: CTW: C1 compilation fails with assert(x->type()->tag() == f->type()->tag()) failed: should have same type - 8241320: The ClassLoaderData::_is_unsafe_anonymous field is unused in the SA - 8240222: [TESTBUG] gtest/jfr/test_networkUtilization.cpp failed when the number of tests is greater than or equal to 2 - 8240590: Add MemRegion::destroy_array to complement introduced create_array - 8241123: Refactor vmTestbase stress framework to use j.u.c and make creation of threads more flexible - 8241001: Improve logging in the ConcurrentGCBreakpoint mechanism - 8241335: ProblemList serviceability/sa/ClhsdbPstack.java due to JDK-8240956 - 8241130: com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException - 8240902: JDI shared memory connector can use already closed Handles - 8139652: Mutator refinement processing should take the oldest dirty card buffer - 8241231: Update Graal - 8241073: Pre-generated Stubs for javax.management, Activation, Naming - 8241233: Typo in problem listing of UIDefaultKeySizeTest.java - 8241078: OOM error parsing HTML with large 

     Tag text
 - 8226230: Test javax/swing/JInternalFrame/8020708/bug8020708.java fails on Ubuntu
 - 8241229: Problem list jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java
 - 8146330: [macosx] UIDefaults.keys() different size than UIDefaults.keySet()
 - 8223935: PIT: java/awt/font/WindowsIndicFonts.java fails on windows10
 - 8168304: Make all of DependencyContext_test available in product mode
 - 8240476: SystemPropertiesWriter does not conform to standard page layout
 - 8240543: Update problem list entry for serviceability/sa/TestRevPtrsForInvokeDynamic.java to reference JDK-8241235
 - 8241254: Simplify usage of UTIL_DEPRECATED_ARG_ENABLE
 - 8241263: JFR: Bump native events limit
 - 8240818: Remove colon from "JFR: Shutdown Hook" thread name
 - 8240819: Assign a name to the JfrThreadSampler thread
 - 8240773: JFR: Non-Java threads are not serialized
 - 8226806: [macOS 10.14] Methods of Java Robot should be called from appropriate thread
 - 8236635: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT
 - 8226253: JAWS reports wrong number of radio buttons when buttons are hidden
 - 8161558: ListIterator should not discard cause on exception
 - 8240604: Rewrite sun/management/jmxremote/bootstrap/CustomLauncherTest.java test to make binaries from source file
 - 8240795: [REDO] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found"
 - 8240977: ProblemList failing jtreg tests on macos
 - 8240633: Memory leaks in the implementations of FileChooserUI
 - 8238075: [OGL] Delete unused properties
 - 8237746: Fixing compiler warnings in src/demo/share/jfc
 - 8040630: Popup menus and tooltips flicker with previous popup contents when first shown
 - 8233573: Toolkit.getScreenInsets(GraphicsConfiguration) may throw ClassCastException
 - 6532025: GIF reader throws misleading exception with truncated images
 - 8240518: Incorrect JNU_ReleaseStringPlatformChars in Windows Print
 - 8176040: Documentation of java.awt.Rectangle.add(java.awt.Point) is wrong
 - 8219578: No associated icon for the leaf node of JTree
 - 8241095: x86: Improve prefix handling in Assembler
 - 8240227: Loop predicates should be copied to unswitched loops
 - 8241232: -XX:+BootstrapJVMCI is not compatible with TieredStopAtLevel < CompLevel_full_optimization
 - 8241064: JFR related tests TestMetaspaceAllocationFailure.java and TestEventInstrumentation.java miss requires tag
 - 8230290: [JVMCI] Remove unused API entry points
 - 8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset
 - Added tag jdk-15+15 for changeset 82b7c62cf4cc
 - 8235908: omit ThreadPriorityPolicy warning when value is set from image
 - 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings
 - 8202469: (ann) Type annotations on type variable bounds that are also type variables are lost
 - Merge
 - 8241162: ProblemList serviceability/sa/TestHeapDumpForInvokeDynamic.java on OSX
 - 8241030: rename HtmlTag to TagName
 - 8236285: [JVMCI] improve TranslatedException traces
 - 8240970: Some tests fail when run with JCov
 - 8241128: x86_32 build failure after JDK-8241042
 - 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:"
 - 8227340: Modify problem list entry for javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java
 - 8240906: Update ZGC ProblemList for serviceability/sa/TestJmapCoreMetaspace.java
 - 8241033: Create test library utility for getting JFR streaming repository
 - 8239497: SEGV in EdgeUtils::field_name_symbol(Edge const&)
 - Merge
 - Added tag jdk-14-ga for changeset bc54620a3848
 - 8232161: Align some one-way conversion in MS950 charset with Windows
 - 8214245: Case insensitive matching doesn't work correctly for some character classes
 - 8241093: Shenandoah: editorial changes in flag descriptions
 - 8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version
 - 8186143: keytool -ext option doesn't accept wildcards for DNS subject alternative names
 - 8238268: Many SA tests are not running on OSX because they do not attempt to use sudo when available
 - 8241124: Aarch64 build broken by JDK-8239593
 - 8239593: Bogus warning "Re-registering of platform native method" for a JVMTI agent
 - 8241122: Remove unimplemented InlineTree constructor definition from parse.hpp
 - 8237045: JVM uses excessive memory with -XX:+EnableJVMCI -XX:JVMCICounterSize=2147483648
 - 8241042: x86_64: Improve Assembler generation
 - 8240976: [JVMCI] MethodProfileWidth flag is broken
 - Merge
 - 8241081: Shenandoah: Do not modify update-watermark concurrently
 - 8241077: x86_64: Minor Assembler improvements
 - 8240824: enhance print_full_memory_info on Linux by THP related information
 - 8241018: 32-bit integer log2 functions return the wrong value for negative arguments on 64-bit machines
 - 8240626: Some of the java.time.chrono.Eras return empty display name for some styles and locales
 - 8241034: Fix a configuring error with "-Xmx2048M: command not found"
 - 8240363: Refactor Compile::Output() to its own Phase
 - 8240964: Compilation error thrown when long literal used with yield
 - 8241043: Expand assertions to identify thread with errant _stack_base
 - 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1
 - 8235339: test TargetAnnoCombo.java is failing after new target RECORD_COMPONENT was added
 - 8240130: Improve and update discussion of visitor evolution warnings
 - 8239825: G1: Simplify threshold test for mutator refinement
 - 8217441: Failure of ::realloc() should be handled correctly in sawindbg.cpp
 - 8240982: Incorrect copyright header in BCEL 6.4.1 sources
 - 8240916: Convert to using hyphenated naming for CSS classes
 - 8241010: Unnecessarily resolving some well-known classes
 - 8241006: Cleanup TemplateInterpreter initialization
 - 8239447: compiler error for annotations applied to record components with target METHOD
 - 8240714: ZGC: TestSmallHeap.java failed due to OutOfMemoryError
 - 8240983: Incorrect copyright header in Apache Santuario files
 - 8231668: Remove ForceDynamicNumberOfGCThreads
 - 8240591: G1HeapSizingPolicy attempts to compute expansion_amount even when at full capacity
 - 8240980: Backout JDK-8240261
 - 8240854: [REDO] some jaotc failures of fastdebug build with specific flags
 - 8240846: Zero VM is broken after JDK-8238681: UseSSE not defined
 - 8238000: Crash in ClassLoader::record_result while dynamic dumping netty
 - 8238566: java.security.Provider$Service.supportsParameter() is racy
 - 8240555: Using env of JAVA_TOOL_OPTIONS and _JAVA_OPTIONS breaks QuietOption.java test
 - 8240971: Fix CSS styles in some doc comments
 - 8240972: macOS codesign fail on macOS 10.13.5 or older
 - 8240242: improve the javadoc for Lookup::dropLookupModes w.r.t. dropping UNCONDITIONAL
 - 8228336: Refactor native library loading implementation
 - 8240950: Missing AC_SUBST after JDK-82408
 - 8149110: Introduce DISABLED_WARNINGS for Java compilation
 - 8240947: Change conflicting JVM features from warning to error
 - 8059309: network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root"
 - 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868
 - Merge
 - 8240917: Shenandoah: Avoid scanning thread code roots twice in all root scanner
 - 8239355: (dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)
 - 8240873: Shenandoah: Short-cut arraycopy barriers
 - 8240872: Shenandoah: Avoid updating new regions from start of evacuation
 - 8240563: [TESTBUG] WB_IsCDSIncludedInVmBuild should support uncompressed oops/klasses
 - 8240957: Clarify BadAttributeValueExpException readObject method
 - 8240704: CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent."
 - 8216332: Grapheme regex does not work with emoji sequences
 - 8231042: [macos] JFileChooser creates new folder on ESC
 - 8239902: Remove direct usage of JSlider, JProgressBar classes in CAccessible class
 - 8204161: [TESTBUG] auto failed with the "Applet thread threw exception: java.lang.UnsupportedOperationException" exception
 - Merge
 - Merge
 - 8238936: The crash in XRobotPeer when the custom GraphicsDevice is used
 - 8238676: jni crashes on accessing it from process exit hook
 - 8235153: [TESTBUG] [macos 10.15] java/awt/Graphics/DrawImageBG/SystemBgColorTest.java fails
 - 8236938: [TESTBUG] JFR event MetaspaceAllocationFailure is not tested
 - 8239149: Cleanups in SunFontManager.java and TrueTypeFont.java
 - 8240246: Avoid cast_to_oop from char*
 - 8237766: Enhance signature API to include ResolvingSignatureStream
 - 8234812: Add micros for DatagramChannel send/receive
 - 8239568: [TESTBUG] LoadLibraryTest.java fails with RuntimeException
 - Merge
 - 8240267: VM fails to start with CDS enabled but JVMTI disabled
 - 8240202: A few client tests leave mouse buttons pressed
 - 8239583: [AIX] simplify the native references in X input methods
 - 8239915: Zero VM crashes when handling dynamic constant
 - 8239916: SA: delete dead code in jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
 - 8240258: SystemDictionary::quick_resolve need guarded by INCLUDE_CDS
 - 8240254: Build is broken when cds is disabled after JDK-8236604
 - 8236604: Optimize SystemDictionary::resolve_well_known_classes for CDS
 - 8203239: [TESTBUG] remove vmTestbase/vm/gc/kind/parOld test
 - 8240136: Cleanup/simplify HTML/CSS for definition lists
 - 8240226: DeflateIn_InflateOut.java test incorrectly assumes size of compressed file
 - 8240217: Shenandoah: remove ShenandoahEvacAssist
 - 8240216: Shenandoah: remove ShenandoahTerminationTrace
 - 8240215: Shenandoah: remove ShenandoahAllocationTrace
 - 8239931: [win][x86] vtable stub generation: assert failure (code size estimate) follow-up
 - 8240231: Build failure on illumos after 8238988
 - 8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed
 - 8239799: Cross-compilation ARM32/AARCH clientvm builds fails after JDK-8239450
 - 8240193: loadLibrary("osxsecurity") should not be removed
 - 8193237: SA: ClhsdbLauncher should show the command being executed
 - 8239379: ProblemList serviceability/sa/sadebugd/DebugdConnectTest.java on OSX
 - 8240142: Fix copyright in ThreadGroupReferenceImpl.h
 - 8239804: Cleanup/simplify HTML/CSS for general block tags
 - 8239815: Update ECC legal file
 - 8225495: Note whether returned annotations are declaration annotations or type annotations
 - 8239354: Shenandoah: minor enhancements to traversal GC
 - 8239873: [TESTBUG] FieldLayout/OldLayoutCheck.java fails after the fix for JDK-8239503
 - 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR
 - 8235225: Replace CHECK_0 with CHECK_NULL for non-integer returning methods
 - 8239878: Bug in PrintEliminateAllocations code causes TestClhsdbJstackLock.java to fail
 - 8235995: Remove src/jdk.internal.vm.compiler/.mx.graal directory
 - 8235147: Release HDC from passiveDCList sooner
 - 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata
 - 8241074: JDK-8240363 broke the build on AArch64
 - 8239785: Cgroups: Incorrect detection logic on old systems in hotspot
 - 8238696: x86: Enumerate all detected CPU features in VM_Version feature string
 - 8240915: Shenandoah: Remove unused fields in init mark tasks
 - 8240831: [JVMCI] Export missing vmStructs entries used by JVMCI compilers
 - 8240669: Devirtualize Relocation::type
 - 8240772: x86_64: Pre-generate Assembler::popa, pusha and vzeroupper
 - 8234146: compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
 - 8240261: Use make/templates/gpl-cp-header in FieldGen.java
 - 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah
 - 8240548: [TESTBUG] CDS NoClassToArchive.java fails with Graal
 - Added tag jdk-15+14 for changeset 1d6ceb13e142
 - 8234624: jstack mixed mode should refer DWARF
 - 8240138: Cleanup HtmlTree
 - 8240866: Typo in JDK-8240820 messes up configure --help
 - 8240340: java/lang/management/ThreadMXBean/Locks.java is buggy
 - 8240881: [BACKOUT] 8222489 jcmd VM.system_properties gives unusable paths on Windows
 - 8239487: Better links generation for system properties found in HTML files
 - 8230117: Remove unused JAR tool classes
 - 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException
 - Merge
 - 8240868: Shenandoah: remove CM-with-UR piggybacking cycles
 - 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
 - 8240829: Use a fast O(1) algorithm for exact_log2
 - 8240615: is_power_of_2() has Undefined Behaviour and is inconsistent
 - 8240532: heap inspection prints trailing @ after name of module without version
 - 8240529: CheckUnhandledOops breaks NULL check in Modules::define_module
 - 8240530: CheckUnhandledOops breaks BacktraceBuilder::set_has_hidden_top_frame
 - 8237566: FindTests.gmk should only include existing TEST.ROOT files
 - 8240820: Replace AC_ARG_ENABLE with UTIL_ARG_ENABLE
 - 8240725: Some functions might not work with CJK character
 - 8239928: ec/ECDSAJavaVerify.java failed due to timeout
 - 8222489: jcmd VM.system_properties gives unusable paths on Windows
 - 8235216: typo in test filename
 - 8240697: convert builders to high-level Content blocks
 - 8240830: [BACKOUT] 8240195: some jaotc failures of fastdebug build with specific flags
 - 8240840: Rollback whitebox.cpp in push 8240691
 - 8240610: [JVMCI] Export VMVersion::_has_intel_jcc_erratum to JVMCI compiler
 - 8240691: ClhsdbCDSJstackPrintAll incorrectly thinks CDS is in use
 - 8239009: C2: Don't use PSHUF to load scalars from memory on x86
 - 8239008: C2: Simplify Replicate support for sub-word types on x86
 - 8238681: Make -XX:UseSSE flag x86-specific
 - 8240778: JFR: Create timer task lazily
 - 8240195: some jaotc failures of fastdebug build with specific flags
 - 8240734: ModuleHashes attribute not reproducible between builds
 - 8238180: RunThese30M failed "assert(t->jfr_thread_local()->shelved_buffer() == __null) failed: invariant"
 - 8238740: java/net/httpclient/whitebox/FlowTestDriver.java would not specify a TLS protocol
 - 8240668: G1 list of all PerRegionTable does not have to be a double linkedlist any more
 - 8240794: [BACKOUT] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found"
 - 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts
 - 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker
 - 8240749: Shenandoah: refactor ShenandoahUtils
 - 8239584: EventStream::close should state that stream will be stopped
 - 8222000: JFR: Process start event
 - 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity
 - 8240754: Instrument FlowTest.java to provide more debug traces
 - 8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk
 - 8240576: JVM crashes after transformation in C2 IdealLoopTree::merge_many_backedges
 - 8240738: nested comment in JVM.java and other minor formatting errors
 - 8240295: hs_err elapsed time in seconds is not accurate enough
 - 8220503: Move ShenandoahTerminatorTerminator::should_exit_termination out of header
 - 8239335: C2: assert((Value(phase) == t) || (t != TypeInt::CC_GT && t != TypeInt::CC_EQ)) failed: missing Value() optimization
 - 8240722: [BACKOUT] G1DirtyCardQueue destructor has useless flush
 - 8240686: 70 security tests are failing on Windows due to "Fetch artifact failed"
 - 8240613: InstanceKlass::set_init_state failed with assert(good_state || state == allocated)
 - 8240133: G1DirtyCardQueue destructor has useless flush
 - 8239965: XMLEncoder/Test4625418.java fails due to "Error: Cp943 - can't read properly"
 - 8239514: Build for arm-linux-gnueabihf fails with undefined reference read_polling_page
 - 8238579: HttpsURLConnection drops the timeout and hangs forever in read
 - 8240695: Build is broken when cds is disabled after JDK-8232081
 - 8240137: Support chained use of Content.add
 - 8240535: Add additional linux-aarch64 jib profiles
 - 8240239: Replace ConcurrentGCPhaseManager
 - 8232081: Try to link all classes during dynamic CDS dump
 - 8240315: Shenandoah: Rename ShLBN::get_barrier_strength()
 - 8239893: Windows handle Leak when starting processes using ProcessBuilder
 - 4617266: (se spec) SelectionKey.OP_READ/OP_WRITE documentation errors
 - 8240684: ProblemList 70 security tests that are failing on Windows due to "Fetch artifact failed"
 - 8240671: Shenandoah: refactor ShenandoahPhaseTimings
 - 8240189: [TESTBUG] Some cgroup tests are failing after JDK-8231111
 - 8240440: Implement get_safepoint_workers() for parallel GC
 - 8240592: HeapRegionManager::rebuild_free_list logs 0s for the estimated free regions before
 - 8236981: Remove ShenandoahTraversalUpdateRefsClosure
 - 8240589: OtherRegionsTable::_num_occupied not updated correctly
 - 8239856: [ntintel] asserts about copying unaligned array element
 - 8240603: Windows 32bit compile error after 8238676
 - 8153430: jdk regression test MletParserLocaleTest, ParserInfiniteLoopTest reduce default timeout
 - 8240538: [JVMCI] add test for JVMCI ConstantPool class
 - 8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 attribute
 - 8240454: incorrect error message: as of release 13, 'record' is a restricted type name
 - 8211917: Zip FS should add META-INF/MANIFEST.FS  at the start of the Zip/JAR
 - 8240241: Add support for JCov DiffCoverage to make files
 - 8239376: JFR: assert(!cld->is_unsafe_anonymous()) failed: invariant
 - 8240528: OopMap cleanup
 - 8240370: Provide Intel JCC Erratum opt-out
 - 8240197: Cannot start JVM when $JAVA_HOME includes CJK characters
 - 8183369: RFC unconformity of HttpURLConnection with proxy
 - 8240286: [TESTBUG] Test command error in hotspot/jtreg/compiler/loopopts/superword/SumRedAbsNeg_Float.java
 - 8240244: Avoid calling resolve_super_or_fail in SystemDictionary::load_shared_class
 - 8240546: runtime/cds/appcds/TestZGCWithCDS.java fails with Graal
 - Added tag jdk-15+13 for changeset 1c06a8ee8aca
 - 8240481: Remove CDS usage of InstanceKlass::is_in_error_state
 - 8239817: Eliminate use of contentContainer and friends
 - 8240534: Shenandoah: ditch debug safepoint timeout adjustment
 - 8240333: jmod incorrectly updates .jar and .jmod files during hashing
 - 8238692: MacOS runtime Installer issue
 - 8237966: Creating runtime pkg requires --mac-package-identifier
 - 8237967: No proper error message when --runtime-image points to non-existent path
 - 8234896: Tab completion does not work for method references in jshell
 - 8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW
 - 8239575: javadoc triggers javac AssertionError for annos on modules
 - 8240511: Shenandoah: parallel safepoint workers count should be ParallelGCThreads
 - 8239787: AArch64: String.indexOf may incorrectly handle empty strings
 - 8238985: [TESTBUG] The arrow image is blue instead of green
 - 8153090: TAB key cannot change input focus after the radio button in the Color Selection dialog
 - 8216329: Cannot resize  CheckBoxItemMenu in Synth L&F with setHorizontalTextPosition
 - 8238384: CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found"
 - 8239367: RunThese30M.java failed due to "assert(false) failed: graph should be schedulable"
 - 8233619: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3
 - 8235206: JFR TestCrossProcessStreaming - validate that data can be consumed while it is being produced
 - 8239055: Wrong implementation of VMState.hasListener
 - 8225760: oop::raw_set_obj isn't needed
 - 8240324: Improve is_boot_class_loader_data() by adding simple check
 - 8240263: Assertion-only call in Method::link_method affecting product builds
 - 8240302: x64: Assembler::reachable redundantly call Relocation::type() more than once
 - 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly
 - 8238759: Clones should always keep the base pointer
 - 8239334: Tab Size does not work correctly in JTextArea with setLineWrap on
 - 8237221: [macos] java/awt/MenuBar/SeparatorsNavigation/SeparatorsNavigation.java fails
 - 8239091: Reversed arguments in call to strstr in freetype "debug" code
 - 8238942: Rendering artifacts with LCD text and fractional metrics
 - 8233827: Enable screenshots in the enhanced failure handler on Linux/macOS
 - 8238741: java.awt.Robot(GraphicsDevice) constructor does not follow the spec
 - 8221823: Requested JDialog width is ignored
 - 8238738: AudioSystem.getMixerInfo() takes about 30 sec to report a gone audio device
 - 8238842: AIOOBE in GIFImageReader.initializeStringTable
 - 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB
 - 8240223: Use consistent predicate order in and with PhaseIdealLoop::find_predicate
 - 8240220: IdealLoopTree::dump_head predicate printing is broken
 - 8238438: SuperWord::co_locate_pack picks memory state of first instead of last load
 - 8196334: Optimize UUID#fromString
 - 8225130: Add exception for expiring Comodo roots to VerifyCACerts test

Changes: https://git.openjdk.java.net/valhalla/pull/15/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/15/webrev.00
  Stats: 801291 lines in 1612 files changed: 766050 ins; 24160 del; 11081 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/15.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/15/head:pull/15

PR: https://git.openjdk.java.net/valhalla/pull/15

From mandy.chung at oracle.com  Wed Apr  8 21:46:41 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Apr 2020 14:46:41 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: 
References: 
 <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com>
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
Message-ID: 



On 4/6/20 5:21 PM, John Rose wrote:
> On Apr 2, 2020, at 10:03 PM, John Rose  wrote:
>> But, I think the best compromise is to admit that, just
>> as Class::getName returns an intentionally invalid
>> though suggestive class name (rather than null or an
>> exception), so Class::descriptorString should return
>> the intentionally invalid though suggestive field
>> descriptor which is regularly derived from said
>> Class::getName.  This provides consistency in
>> string-valued outputs; in the absence of an argument
>> why their treatment should be inconsistent,
>> consistency is less confusing and should win.
> My previous Email was confusing because it gave
> two conflicting answers both incomplete.  Let me
> start again.  (Thanks Mandy for querying me on
> Slack.)
>
> First of all, it should *never* be the case that a
> `ClassDesc` should represent a symbol which is
> not well formed at the descriptor level.  Since
> there is no well formed descriptor for a HC,
> it followed that `Class::describeConstable`
> should never return a non-empty value.
>
> Second of all, associated with the constable
> interface for `Class`, but independent, are three
> API points that produce useful reflective
> representations of type `String`.  There
> is the old `getName` and `getSimpleName`,
> and the new `descriptorString`.
>
> In order to allow HCs to be printed they must
> be named.  Thus, HCs must produce names.
> (And simple-names, for places like the `toString`
> method of `MethodType`.)  These names are
> dual-use, for human reading and for resolution
> by recycling them through `Class::toName` and
> related API points.  The first use does not require
> well-formed class names, and for HC?s (for the first
> time) we *forbid* `toName` to produce a well-formed
> class name.  This ensures that a HC?s name can be
> printed for humans to read, but cannot accidentally
> be resolved.
>
> I suggest that `descriptorString` be *also* regarded
> as a dual-use API point.  This means that (a) a HC?s
> descriptor string should be unsurprising to a human
> reader, and (b) it must be unacceptable as an input
> for a resolving API point.  A corollary of (b) and of
> my earlier point is that a HC?s descriptor string *also*
> must be unacceptable to the factory methods for
> `ClassDesc` and `MethodTypeDesc`.
>
> Let me suggest a specific way to do this.  A HC?s name
> is of the form `N + S`, where N is a valid class name,
> derived from the HC?s classfile, and S is a suffix added
> by the platform.  To prevent confusion with other names,
> the suffix starts with slash ?/? and is otherwise a valid
> unqualified name.  In order to create a dual-use
> (human readable but *not* resolvable) descriptor
> for a HC, define it as the valid descriptor for a class
> whose name is `N`, with a suffix `S`.  I think this
> meets all relevant use cases and requirements.
>
> For example, a HC with original name `foo.Bar` and
> suffix `/123` would have a descriptor string of
> `Lfoo/Bar;/123`.  This is simple and unsurprising.

Let's call this option c' as it's a modification to option c.? I want to 
use `123Z` as a suffix example to indicate the significance of the 
location of ';'.

Option c:? `Lfoo/Bar.123Z;`
Option c': `Lfoo/Bar;/123Z`

If someone creates a MethodType with parameter types of a hidden class, 
boolean and int, descriptorString() produces:
 ? ? `(Lfoo/Bar;/123ZZI)V`
vs
 ??? `(Lfoo/Bar.123Z;ZI)V`

';' can help splitting the parameter descriptors properly in option c 
that may benefit any error reporting whereas any error message to report 
for option c' will have to include the entire string.

Option c' has the nice property to retain the type descriptor of the 
original bytes by appending a suffix.? On the other hand option c may 
produce a human readable string that can be parsed easily e.g. to 
indicate how many parameter types in this descriptor string.

I'm uncertain of the impact of migration if any tool assumes ';' is the 
end character for a reference type (JVM TI agents may be impacted 
because JVM TI GetClassSignature returns a type descriptor).

What are other benefits of c' over c?

I'm currently leaning toward option c as the result string of a method 
type is easier to parse and one fewer form of names (i.e. type 
descriptor is "L" + CN + ";") where CN is N + "." + S and it's 
`this_class` name of `newBytes` from which the hidden class is derived.

> Yes, it would be even simpler to throw an exception from
> `Class::descriptorString` if the class is a HC.  But I think
> that?s *too simple*, because it makes `descriptorString`
> useless as an input to any class?s `toString` method.
> I think that would be a mistake, in the long run.  String
> producing methods are very useful for user output and
> having them throw (or return null which is about as
> surprising) is a sharp edge for anybody using them for
> user output.  I could be wrong about that, and if the rest
> of y?all are sure I?m wrong about that, go ahead and
> throw an exception.  I?ll reserve the right to say ?I told
> you so? when the appropriate time comes.
>
> ? John

OK.?? I take the first pass on the spec. 
`java.lang.invoke.TypeDescriptor::descriptorString` may produce an 
invalid descriptor string.? This version implements option c but it's 
very easy to switch to option c' (2-line change).

http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/specdiff/overview-summary.html

webrev:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/webrev.01/

Class::getName ??? ??? ??? `foo.Bar/123Z`

Option c:
 ? Class::descriptorString? `Lfoo/Bar.123Z;`
 ? MethodType::descriptorString? `(Lfoo/Bar.123Z;ZI)V`

If we choose option c', then:
 ? Class::descriptorString? `Lfoo/Bar;/123Z`
MethodType::descriptorString? `(Lfoo/Bar;/123ZZI)V`


Mandy

From john.r.rose at oracle.com  Wed Apr  8 22:31:35 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 8 Apr 2020 15:31:35 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: 
References: 
 <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com>
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
Message-ID: 

On Apr 8, 2020, at 2:46 PM, Mandy Chung  wrote:
> 
> Option c:  `Lfoo/Bar.123Z;`
> Option c': `Lfoo/Bar;/123Z`

I?m OK with either; both satisfy the proposed dual-use criterion.

I put forward c? because it seems slightly easier to specify, and
because, choosing between the two options, the sort of error
that might happen seems to be slightly friendlier in the case
of c?.  ?Slightly? in both cases.

In the case of c an error could happen if the user blindly mapped
slash to dot after stripping the L; envelope.  (I hear they do these
sorts of things.)  In that case, the illegality of the HC would be
lost, replacing it by foo/Bar/123Z, which the JVM thinks is just
fine.

In the case of c? an error could happen if the user blindly takes
everything up to the semicolon, again replacing foo/Bar.123Z
by foo/Bar which again looks good to both the JVM and the
language also.

In both c and c? there will probably be a cascading failure
if the name foo/Bar/123Z or foo/Bar is resolved.  In c? there
is an additional cascading failure when the user that was
parsing the signature goes back for more parameters and
finds a slash (instead of LZBHCIJFD[).  The thing that tipped
me over to c? is that extra diagnostic: Even though it happens
after the user picked up the bad descriptor, it happens closer
to the place where the error has its root cause, which is that
somebody is trying to parse an (intentionally) illegal descriptor.

? John

From john.r.rose at oracle.com  Wed Apr  8 22:35:07 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 8 Apr 2020 15:35:07 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: 
References: 
 <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com>
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 
Message-ID: <82F1D053-984A-4D0B-B5C2-6A3CCBFA4C20@oracle.com>

On Apr 8, 2020, at 3:31 PM, John Rose  wrote:
> 
> In both c and c? there will probably be a cascading failure
> if the name foo/Bar/123Z or foo/Bar is resolved.  In c? there
> is an additional cascading failure when the user that was
> parsing the signature goes back for more parameters and
> finds a slash (instead of LZBHCIJFD[).  The thing that tipped
> me over to c? is that extra diagnostic: Even though it happens
> after the user picked up the bad descriptor, it happens closer
> to the place where the error has its root cause, which is that
> somebody is trying to parse an (intentionally) illegal descriptor.

P.S. Having the slash+suffix *outside* the L; envelope basically
rubs any parser?s nose in the fact that there?s something illegal
here.  Putting it inside the envelope hides the error from the
parser?which may be a good thing sometimes!  But it means
that the odd name foo/Bar.123Z will float somewhere else
and may or may not be misinterpreted.  If it?s handed to
Class.forName you can bet that the dot will change its meaning.
On balance, I slightly prefer the fail-fast properties of c?.

From dsimms at openjdk.java.net  Thu Apr  9 08:43:58 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 9 Apr 2020 08:43:58 GMT
Subject: [lworld] RFR: Merge openjdk/jdk:master
In-Reply-To: <9v_Nzt6AEhWCSHWLXToKDPonVNRO4mP61zzxnSY5l38=.10c4838a-3088-4a6d-82bc-41039ff12eb5@github.com>
References: <9v_Nzt6AEhWCSHWLXToKDPonVNRO4mP61zzxnSY5l38=.10c4838a-3088-4a6d-82bc-41039ff12eb5@github.com>
Message-ID: 

On Wed, 8 Apr 2020 12:06:00 GMT, David Simms  wrote:

> Merge jdk-15+16 from master

/integrate

-------------

PR: https://git.openjdk.java.net/valhalla/pull/15

From dsimms at openjdk.java.net  Thu Apr  9 12:01:25 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 9 Apr 2020 12:01:25 GMT
Subject: [lworld] [Rev 01] RFR: Merge openjdk/jdk:master
In-Reply-To: <9v_Nzt6AEhWCSHWLXToKDPonVNRO4mP61zzxnSY5l38=.10c4838a-3088-4a6d-82bc-41039ff12eb5@github.com>
References: <9v_Nzt6AEhWCSHWLXToKDPonVNRO4mP61zzxnSY5l38=.10c4838a-3088-4a6d-82bc-41039ff12eb5@github.com>
Message-ID: 

> Merge jdk-15+16 from master

David Simms has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase.

This pull request has been closed without being integrated.

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/15/files
  - new: https://git.openjdk.java.net/valhalla/pull/15/files/0c52cfec..0c52cfec

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/15/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/15/webrev.00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/15.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/15/head:pull/15

PR: https://git.openjdk.java.net/valhalla/pull/15

From thartmann at openjdk.java.net  Thu Apr  9 12:26:29 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Apr 2020 12:26:29 GMT
Subject: git: openjdk/valhalla: lworld: 8242454: [lworld] TestLWorld::test63
 fails with "no exception thrown"
Message-ID: <0f08dba3-a50d-465d-8809-7ca54ee438af@openjdk.org>

Changeset: 09623039
Author:    Tobias Hartmann 
Date:      2020-04-09 12:21:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/09623039

8242454: [lworld] TestLWorld::test63 fails with "no exception thrown"

! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp


From thartmann at openjdk.java.net  Thu Apr  9 12:26:59 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Apr 2020 12:26:59 GMT
Subject: [lworld] FYI: 8242454: [lworld] TestLWorld::test63 fails with "no
 exception thrown"
Message-ID: <3RJwwgYSBz7tKYslXX8pKDf1d67AGlj0vV6L76b_n4M=.e0c31583-ab19-4f02-ab9d-7cb66f7ad603@github.com>

The merge from mainline that moved the fast_lock method accidentally removed a Valhalla specific change.

-------------

Commit messages:
 - 8242454: [lworld] TestLWorld::test63 fails with "no exception thrown"

Changes: https://git.openjdk.java.net/valhalla/pull/16/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/16/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242454
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/16.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/16/head:pull/16

PR: https://git.openjdk.java.net/valhalla/pull/16

From thartmann at openjdk.java.net  Thu Apr  9 12:28:51 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Apr 2020 12:28:51 GMT
Subject: git: openjdk/valhalla: lworld: 8242455: [lworld] C1 compilation fails
 with assert "should have same type"
Message-ID: 

Changeset: d87d47db
Author:    Tobias Hartmann 
Date:      2020-04-09 12:28:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d87d47db

8242455: [lworld] C1 compilation fails with assert "should have same type"

! src/hotspot/share/c1/c1_Instruction.hpp


From thartmann at openjdk.java.net  Thu Apr  9 12:39:25 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Apr 2020 12:39:25 GMT
Subject: [lworld] FYI: 8242455: [lworld] C1 compilation fails with assert
 "should have same type"
Message-ID: 

Merge from mainline accidentally reverted the fix for JDK-8237894.

-------------

Commit messages:
 - 8242455: [lworld] C1 compilation fails with assert "should have same type"

Changes: https://git.openjdk.java.net/valhalla/pull/17/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/17/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242455
  Stats: 20 lines in 1 file changed: 16 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/17.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/17/head:pull/17

PR: https://git.openjdk.java.net/valhalla/pull/17

From thartmann at openjdk.java.net  Thu Apr  9 12:41:55 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Apr 2020 12:41:55 GMT
Subject: git: openjdk/valhalla: lworld: 8242457: [lworld] Cherry pick and
 adjust JDK-8241997 for Valhalla
Message-ID: <2b8058ce-6dbd-4854-b4d6-fa178395d9b0@openjdk.org>

Changeset: a1c89db7
Author:    Tobias Hartmann 
Date:      2020-04-09 12:41:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a1c89db7

8242457: [lworld] Cherry pick and adjust JDK-8241997 for Valhalla

! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/memnode.cpp


From thartmann at openjdk.java.net  Thu Apr  9 12:43:51 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Apr 2020 12:43:51 GMT
Subject: [Integrated] [lworld] RFR: 8242210: [lworld]
 TestCallingConvention::test36 spuriously fails
In-Reply-To: 
References: 
Message-ID: 

Changeset: d9f3aaa9
Author:    Tobias Hartmann 
Date:      2020-04-09 12:43:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d9f3aaa9

8242210: [lworld] TestCallingConvention::test36 spuriously fails

Reviewed-by: fparain

! src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
! src/hotspot/share/ci/ciReplay.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/deoptimization.hpp
! src/hotspot/share/runtime/fieldDescriptor.cpp
! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestArrays.java
! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorld.java
! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorldProfiling.java
! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableArrays.java
! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java

From thartmann at openjdk.java.net  Thu Apr  9 12:46:47 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Apr 2020 12:46:47 GMT
Subject: [lworld] FYI: 8242457: [lworld] Cherry pick and adjust JDK-8241997
 for Valhalla
Message-ID: 

Without the fix, several tests fail. Also it needs adjustment for inline types anyway.

-------------

Commit messages:
 - 8242457: [lworld] Cherry pick and adjust JDK-8241997 for Valhalla

Changes: https://git.openjdk.java.net/valhalla/pull/18/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/18/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242457
  Stats: 57 lines in 2 files changed: 12 ins; 18 del; 27 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/18.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/18/head:pull/18

PR: https://git.openjdk.java.net/valhalla/pull/18

From thartmann at openjdk.java.net  Thu Apr  9 12:59:55 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Apr 2020 12:59:55 GMT
Subject: git: openjdk/valhalla: lworld: 8242443: [lworld] Disabling
 scalarization fails with assert "incorrect depth prediction"
Message-ID: 

Changeset: 7fa3ff52
Author:    Tobias Hartmann 
Date:      2020-04-09 12:58:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7fa3ff52

8242443: [lworld] Disabling scalarization fails with assert "incorrect depth prediction"

! src/hotspot/share/opto/parseHelper.cpp


From thartmann at openjdk.java.net  Thu Apr  9 13:01:16 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Apr 2020 13:01:16 GMT
Subject: [lworld] RFR: 8242443: [lworld] Disabling scalarization fails with
 assert "incorrect depth prediction"
Message-ID: 

Withfield implementation should push result outside of PreserveReexecuteState (line 395).

-------------

Commit messages:
 - 8242443: [lworld] Disabling scalarization fails with assert "incorrect depth prediction"

Changes: https://git.openjdk.java.net/valhalla/pull/19/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/19/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242443
  Stats: 15 lines in 1 file changed: 3 ins; 3 del; 9 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/19/head:pull/19

PR: https://git.openjdk.java.net/valhalla/pull/19

From david.simms at oracle.com  Thu Apr  9 12:17:37 2020
From: david.simms at oracle.com (David Simms)
Date: Thu, 9 Apr 2020 12:17:37 GMT
Subject: git: openjdk/valhalla: lworld: 420 new changesets
Message-ID: <260ab24b-ec7d-42e2-9bfd-8bfb602fa049@oracle.com>

Changeset: ff55c490
Author:    Phil Race 
Date:      2020-02-12 14:45:10 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ff55c490

8238842: AIOOBE in GIFImageReader.initializeStringTable

Reviewed-by: serb, bpb

! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
+ test/jdk/javax/imageio/plugins/gif/GIFCodeSizeTest.java

Changeset: 7af366a7
Author:    Sergey Bylokhov 
Date:      2020-02-13 13:17:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7af366a7

8238738: AudioSystem.getMixerInfo() takes about 30 sec to report a gone audio device

Reviewed-by: prr

! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_DirectSound.cpp

Changeset: 8d2aa62b
Author:    Sergey Bylokhov 
Date:      2020-02-13 13:19:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8d2aa62b

8221823: Requested JDialog width is ignored

Reviewed-by: aivanov

! src/java.desktop/windows/classes/sun/awt/windows/WDialogPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WFramePeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java
! src/java.desktop/windows/native/libawt/windows/awt_Window.cpp
! test/jdk/ProblemList.txt
! test/jdk/java/awt/Mixing/AWT_Mixing/HierarchyBoundsListenerMixingTest.java
! test/jdk/java/awt/Mixing/AWT_Mixing/MixingFrameResizing.java
! test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java
+ test/jdk/java/awt/Window/MinimumSizeDPIVariation/MinimumSizeDPIVariation.java

Changeset: 784e5751
Author:    Sergey Bylokhov 
Date:      2020-02-13 13:21:21 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/784e5751

8238741: java.awt.Robot(GraphicsDevice) constructor does not follow the spec

Reviewed-by: aivanov

! src/java.desktop/share/classes/java/awt/Robot.java
+ test/jdk/java/awt/Headless/HeadlessRobot.java

Changeset: 5705a551
Author:    Sergey Bylokhov 
Date:      2020-02-13 13:23:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5705a551

8233827: Enable screenshots in the enhanced failure handler on Linux/macOS

Reviewed-by: iignatyev

! test/failure_handler/src/share/conf/linux.properties
! test/failure_handler/src/share/conf/mac.properties

Changeset: e6915ff1
Author:    Phil Race 
Date:      2020-02-14 09:10:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e6915ff1

8238942: Rendering artifacts with LCD text and fractional metrics

Reviewed-by: serb, jdv

! src/java.desktop/share/native/libfontmanager/freetypeScaler.c

Changeset: 80f5a47b
Author:    Phil Race 
Date:      2020-02-14 10:44:30 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/80f5a47b

8239091: Reversed arguments in call to strstr in freetype "debug" code

Reviewed-by: bpb

! src/java.desktop/share/native/libfontmanager/freetypeScaler.c

Changeset: c6e9d209
Author:    Alexander Zuev 
Date:      2020-02-17 20:04:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c6e9d209

8237221: [macos] java/awt/MenuBar/SeparatorsNavigation/SeparatorsNavigation.java fails

Reviewed-by: serb

+ test/jdk/java/awt/MenuBar/SeparatorsNavigation/SeparatorsNavigation.java

Changeset: 3c720426
Author:    Prasanta Sadhukhan 
Date:      2020-02-20 14:49:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3c720426

8239334: Tab Size does not work correctly in JTextArea with setLineWrap on

Reviewed-by: serb, pbansal

! src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java
+ test/jdk/javax/swing/JTextArea/TestTabSizeWithLineWrap.java

Changeset: b5fdcb08
Author:    Pankaj Bansal 
Date:      2020-02-21 16:31:45 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b5fdcb08

8216329: Cannot resize  CheckBoxItemMenu in Synth L&F with setHorizontalTextPosition

Reviewed-by: serb, psadhukhan

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java
+ test/jdk/javax/swing/plaf/synth/SynthCheckBoxMenuItem/Check_Icon.png
+ test/jdk/javax/swing/plaf/synth/SynthCheckBoxMenuItem/MenuItem_Selected.png
+ test/jdk/javax/swing/plaf/synth/SynthCheckBoxMenuItem/TestJCheckBoxMenuItem.java

Changeset: b5e16220
Author:    Pankaj Bansal 
Date:      2020-02-21 17:00:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b5e16220

8153090: TAB key cannot change input focus after the radio button in the Color Selection dialog

Reviewed-by: serb, psadhukhan

! src/java.desktop/share/classes/javax/swing/colorchooser/ColorPanel.java

Changeset: f916df3b
Author:    Pankaj Bansal 
Date:      2020-02-21 17:09:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f916df3b

8238985: [TESTBUG] The arrow image is blue instead of green

Reviewed-by: serb, psadhukhan

! test/jdk/javax/swing/JTextPane/TestJTextPaneHTMLRendering.java

Changeset: fa7f53ee
Author:    Alexey Ivanov 
Date:      2020-02-25 20:00:24 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/fa7f53ee

8235147: Release HDC from passiveDCList sooner

Reviewed-by: serb, jdv

! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
! src/java.desktop/windows/native/libawt/windows/awt_Component.h

Changeset: 55768aa4
Author:    Sergey Bylokhov 
Date:      2020-02-27 09:49:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/55768aa4

8239583: [AIX] simplify the native references in X input methods

Reviewed-by: clanger, itakiguchi

! src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c
! src/java.desktop/unix/native/common/awt/awt_p.h
! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c

Changeset: 5e912fbe
Author:    Sergey Bylokhov 
Date:      2020-02-28 16:49:10 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5e912fbe

8240202: A few client tests leave mouse buttons pressed

Reviewed-by: prr

! test/jdk/ProblemList.txt
! test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java
! test/jdk/javax/swing/JButton/PressedButtonRightClickTest.java

Changeset: c8ed0128
Author:    Rahul Raghavan 
Date:      2020-02-27 16:06:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c8ed0128

8235995: Remove src/jdk.internal.vm.compiler/.mx.graal directory

Removed src/jdk.internal.vm.compiler/.mx.graal directory and files

Reviewed-by: dlong

- src/jdk.internal.vm.compiler/.mx.graal/.project
- src/jdk.internal.vm.compiler/.mx.graal/.pydevproject
- src/jdk.internal.vm.compiler/.mx.graal/eclipse-settings/org.eclipse.jdt.core.prefs
- src/jdk.internal.vm.compiler/.mx.graal/mx_graal.py
- src/jdk.internal.vm.compiler/.mx.graal/mx_graal_9.py
- src/jdk.internal.vm.compiler/.mx.graal/mx_graal_bench.py
- src/jdk.internal.vm.compiler/.mx.graal/outputparser.py
- src/jdk.internal.vm.compiler/.mx.graal/sanitycheck.py
- src/jdk.internal.vm.compiler/.mx.graal/suite.py

Changeset: 2ba0575c
Author:    Nils Eliasson 
Date:      2020-02-27 13:11:06 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2ba0575c

8239878: Bug in PrintEliminateAllocations code causes TestClhsdbJstackLock.java to fail

Reviewed-by: shade

! src/hotspot/share/opto/macro.cpp

Changeset: a1e93283
Author:    Harold Seigel 
Date:      2020-02-27 13:00:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a1e93283

8235225: Replace CHECK_0 with CHECK_NULL for non-integer returning methods

Change CHECK_0 to CHECK_NULL and CHECK_false where appropriate

Reviewed-by: mikael, dholmes, coleenp

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classListParser.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/oops/arrayKlass.cpp
! src/hotspot/share/oops/objArrayKlass.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/services/management.cpp
! src/hotspot/share/services/memoryManager.cpp

Changeset: 5551d3d8
Author:    Zhengyu Gu 
Date:      2020-02-26 15:32:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5551d3d8

8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR

Reviewed-by: shade, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahForwarding.hpp
! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp

Changeset: 882633a7
Author:    Daniel D. Daugherty 
Date:      2020-02-27 11:34:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/882633a7

8239873: [TESTBUG] FieldLayout/OldLayoutCheck.java fails after the fix for JDK-8239503

Don't run the test with -XX:-UseCompressedOops.

Reviewed-by: fparain, hseigel

! test/hotspot/jtreg/runtime/FieldLayout/OldLayoutCheck.java

Changeset: efdc0037
Author:    Zhengyu Gu 
Date:      2020-02-27 12:17:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/efdc0037

8239354: Shenandoah: minor enhancements to traversal GC

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp

Changeset: ed620249
Author:    Joe Darcy 
Date:      2020-02-27 10:30:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ed620249

8225495: Note whether returned annotations are declaration annotations or type annotations

Reviewed-by: jjg

! src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/java.compiler/share/classes/javax/lang/model/element/Element.java
! src/java.compiler/share/classes/javax/lang/model/type/TypeMirror.java
! src/java.compiler/share/classes/javax/lang/model/util/Elements.java

Changeset: 4a951001
Author:    Bradford Wetmore 
Date:      2020-02-27 11:48:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4a951001

8239815: Update ECC legal file

Reviewed-by: mullan

! src/jdk.crypto.ec/share/legal/ecc.md

Changeset: 39d75e89
Author:    Jonathan Gibbons 
Date:      2020-02-27 12:16:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/39d75e89

8239804: Cleanup/simplify HTML/CSS for general block tags

Reviewed-by: prappo, hannesw

! make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
! make/jdk/src/classes/build/tools/taglet/ToolGuide.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialMethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ParamTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java
! test/langtools/jdk/javadoc/doclet/AuthorDD/AuthorDD.java
! test/langtools/jdk/javadoc/doclet/testAuthor/TestAuthor.java
! test/langtools/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java
! test/langtools/jdk/javadoc/doclet/testConstructorIndent/TestConstructorIndent.java
! test/langtools/jdk/javadoc/doclet/testConstructors/TestConstructors.java
! test/langtools/jdk/javadoc/doclet/testCopyFiles/TestCopyFiles.java
+ test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverriddenMethod.java
- test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java
! test/langtools/jdk/javadoc/doclet/testHiddenMembers/TestHiddenMembers.java
! test/langtools/jdk/javadoc/doclet/testHref/TestHref.java
! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/langtools/jdk/javadoc/doclet/testHtmlStrongTag/TestHtmlStrongTag.java
! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java
! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java
! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestMultiInheritance.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenMethodDocCopy.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethods.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPackageFlag.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPrivateFlag.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg1/BaseClass.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg1/SubClass.java
! test/langtools/jdk/javadoc/doclet/testParamTaglet/TestParamTaglet.java
! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java
! test/langtools/jdk/javadoc/doclet/testPrivateClasses/pkg/PrivateParent.java
! test/langtools/jdk/javadoc/doclet/testPrivateClasses/pkg/PublicChild.java
! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java
! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java
! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java
! test/langtools/jdk/javadoc/doclet/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java
! test/langtools/jdk/javadoc/doclet/testSimpleTag/TestSimpleTag.java
! test/langtools/jdk/javadoc/doclet/testSimpleTagInherit/TestSimpleTagInherit.java
! test/langtools/jdk/javadoc/doclet/testSinceTag/TestSinceTag.java
! test/langtools/jdk/javadoc/doclet/testThrowsHead/TestThrowsHead.java
! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTag.java
! test/langtools/jdk/javadoc/doclet/testVersionTag/TestVersionTag.java

Changeset: 518f1f9a
Author:    Chris Plummer 
Date:      2020-02-27 13:51:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/518f1f9a

8240142: Fix copyright in ThreadGroupReferenceImpl.h

Reviewed-by: dholmes

! src/jdk.jdwp.agent/share/native/libjdwp/ThreadGroupReferenceImpl.h

Changeset: 3a5ee7b4
Author:    Chris Plummer 
Date:      2020-02-27 13:52:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3a5ee7b4

8239379: ProblemList serviceability/sa/sadebugd/DebugdConnectTest.java on OSX

Reviewed-by: sspitsyn

! test/hotspot/jtreg/ProblemList.txt

Changeset: 51150104
Author:    Chris Plummer 
Date:      2020-02-27 13:57:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/51150104

8193237: SA: ClhsdbLauncher should show the command being executed

Reviewed-by: sspitsyn, amenkov

! test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java

Changeset: 0ab5b968
Author:    Xue-Lei Andrew Fan 
Date:      2020-02-27 21:14:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0ab5b968

8240193: loadLibrary("osxsecurity") should not be removed

Reviewed-by: ascarpino

! src/java.base/macosx/classes/apple/security/KeychainStore.java

Changeset: 290c21f0
Author:    Magnus Ihse Bursie 
Date:      2020-02-28 09:53:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/290c21f0

8239799: Cross-compilation ARM32/AARCH clientvm builds fails after JDK-8239450

Reviewed-by: erikj

! make/autoconf/buildjdk-spec.gmk.in

Changeset: bd25c0e0
Author:    Christian Hagedorn 
Date:      2020-02-28 15:33:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/bd25c0e0

8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed

Remove an assertion which was too strong for some valid IRs when running with -XX:+VerifyGraphEdges

Reviewed-by: neliasso, thartmann

! src/hotspot/share/opto/gcm.cpp

Changeset: 0cd6d13b
Author:    Peter Tribble 
Committer: Daniel D. Daugherty 
Date:      2020-02-28 10:16:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0cd6d13b

8240231: Build failure on illumos after 8238988

Add missing cast

Reviewed-by: dcubed, shade

! src/hotspot/os_cpu/solaris_x86/thread_solaris_x86.cpp

Changeset: 637795e0
Author:    Lutz Schmidt 
Date:      2020-02-28 16:36:47 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/637795e0

8239931: [win][x86] vtable stub generation: assert failure (code size estimate) follow-up

Reviewed-by: mdoerr

! src/hotspot/cpu/x86/vtableStubs_x86_32.cpp

Changeset: 5afeeed5
Author:    Aleksey Shipilev 
Date:      2020-02-28 17:59:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5afeeed5

8240215: Shenandoah: remove ShenandoahAllocationTrace

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: 6ad1db40
Author:    Aleksey Shipilev 
Date:      2020-02-28 17:59:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6ad1db40

8240216: Shenandoah: remove ShenandoahTerminationTrace

Reviewed-by: zgu

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: 8a79f267
Author:    Aleksey Shipilev 
Date:      2020-02-28 17:59:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8a79f267

8240217: Shenandoah: remove ShenandoahEvacAssist

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: b38f3cf3
Author:    Volker Simonis 
Date:      2020-02-28 19:49:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b38f3cf3

8240226: DeflateIn_InflateOut.java test incorrectly assumes size of compressed file

Reviewed-by: martin, alanb

! test/jdk/java/util/zip/DeflateIn_InflateOut.java

Changeset: 1be89d96
Author:    Jonathan Gibbons 
Date:      2020-02-28 12:46:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1be89d96

8240136: Cleanup/simplify HTML/CSS for definition lists

Reviewed-by: prappo

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialMethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
= test/langtools/jdk/javadoc/doclet/testExternalOverriddenMethod/TestExternalOverriddenMethod.java
= test/langtools/jdk/javadoc/doclet/testExternalOverriddenMethod/package-list
+ test/langtools/jdk/javadoc/doclet/testExternalOverriddenMethod/pkg/XReader.java
- test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java
! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/langtools/jdk/javadoc/doclet/testIndex/TestIndex.java
! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java
! test/langtools/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java
! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/langtools/jdk/javadoc/doclet/testPackageHtml/TestPackageHtml.java
! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java
! test/langtools/jdk/javadoc/doclet/testSummaryTag/TestSummaryTag.java

Changeset: b247e6d9
Author:    Leonid Mesnik 
Date:      2020-02-28 13:21:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b247e6d9

8203239: [TESTBUG] remove vmTestbase/vm/gc/kind/parOld test

Reviewed-by: lkorinth, shade

! test/hotspot/jtreg/TEST.quick-groups
- test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java
- test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh

Changeset: add146cc
Author:    Yumin Qi 
Date:      2020-02-28 15:30:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/add146cc

8236604: Optimize SystemDictionary::resolve_well_known_classes for CDS

Serialize SystemDictionary::_well_known_classes into CDS and quickly resolve them at runtime in vm startup stage.

Reviewed-by: iklam, coleenp

! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp

Changeset: f176fae8
Author:    Jie Fu 
Date:      2020-02-29 09:38:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f176fae8

8240254: Build is broken when cds is disabled after JDK-8236604

Reviewed-by: redestad

! src/hotspot/share/classfile/systemDictionary.hpp

Changeset: 5bfb8146
Author:    Yumin Qi 
Date:      2020-02-28 19:29:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5bfb8146

8240258: SystemDictionary::quick_resolve need guarded by INCLUDE_CDS

Supplemental fix for 8236604 to guard SystemDictionary::quick_resolve with CDS

Reviewed-by: iklam, ccheung

! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp

Changeset: 0a820d6d
Author:    Lin Zang 
Date:      2020-02-29 14:43:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0a820d6d

8239916: SA: delete dead code in jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java

Reviewed-by: stefank

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java

Changeset: 742bdf00
Author:    Kun Wang 
Committer: Fei Yang 
Date:      2020-02-26 17:32:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/742bdf00

8239915: Zero VM crashes when handling dynamic constant

Reviewed-by: dholmes

! src/hotspot/share/interpreter/bytecodeInterpreter.cpp
+ test/hotspot/jtreg/runtime/invokedynamic/DynamicConstantHelper.jasm
+ test/hotspot/jtreg/runtime/invokedynamic/TestDynamicConstant.java

Changeset: 0532bd23
Author:    Ioi Lam 
Date:      2020-03-01 17:36:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0532bd23

8240267: VM fails to start with CDS enabled but JVMTI disabled

Reviewed-by: dholmes

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: 65bf6185
Author:    Prasanta Sadhukhan 
Date:      2020-03-02 10:50:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/65bf6185

Merge

! test/jdk/ProblemList.txt
! test/jdk/ProblemList.txt

Changeset: 78d35f14
Author:    Christoph Langer 
Date:      2020-03-02 21:04:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/78d35f14

8239149: Cleanups in SunFontManager.java and TrueTypeFont.java

Reviewed-by: prr

! src/java.desktop/share/classes/sun/font/SunFontManager.java
! src/java.desktop/share/classes/sun/font/TrueTypeFont.java

Changeset: 70e2c013
Author:    Sergey Bylokhov 
Date:      2020-03-02 23:35:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/70e2c013

8235153: [TESTBUG] [macos 10.15] java/awt/Graphics/DrawImageBG/SystemBgColorTest.java fails

Reviewed-by: aivanov

! test/jdk/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java

Changeset: 9d0a4875
Author:    Sergey Bylokhov 
Date:      2020-03-03 03:46:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9d0a4875

8238936: The crash in XRobotPeer when the custom GraphicsDevice is used

Reviewed-by: kizune

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CRobot.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/java.desktop/share/classes/java/awt/Robot.java
! src/java.desktop/share/classes/sun/awt/ComponentFactory.java
! src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java
! src/java.desktop/windows/classes/sun/awt/windows/WRobotPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java
+ test/jdk/java/awt/Robot/CreateRobotCustomGC/CreateRobotCustomGC.java

Changeset: 751de037
Author:    Rajan Halade 
Date:      2020-03-01 23:04:02 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/751de037

8225130: Add exception for expiring Comodo roots to VerifyCACerts test

Reviewed-by: weijun

! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: ebadfaeb
Author:    Claes Redestad 
Date:      2020-03-02 08:22:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ebadfaeb

8196334: Optimize UUID#fromString

Co-authored-by: Andriy Plokhotnyuk 
Co-authored-by: Jon Chambers 
Reviewed-by: igerasim, alanb

! src/java.base/share/classes/java/util/UUID.java
! test/jdk/java/util/UUID/UUIDTest.java
+ test/micro/org/openjdk/bench/java/util/UUIDBench.java

Changeset: d7b122ed
Author:    Christian Hagedorn 
Date:      2020-03-02 10:23:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d7b122ed

8238438: SuperWord::co_locate_pack picks memory state of first instead of last load

Fix selection of first and last memory state in SuperWord::co_locate_pack

Reviewed-by: thartmann, kvn

! src/hotspot/share/opto/superword.cpp
! src/hotspot/share/opto/superword.hpp
+ test/hotspot/jtreg/compiler/loopopts/superword/CoLocatePackMemoryState.java

Changeset: ac60e4b9
Author:    Stefan Karlsson 
Date:      2020-03-02 12:30:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ac60e4b9

8240220: IdealLoopTree::dump_head predicate printing is broken

Reviewed-by: thartmann, neliasso, chagedorn

! src/hotspot/share/opto/loopnode.cpp

Changeset: 14913407
Author:    Stefan Karlsson 
Date:      2020-03-02 12:30:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/14913407

8240223: Use consistent predicate order in and with PhaseIdealLoop::find_predicate

Reviewed-by: thartmann, neliasso, chagedorn

! src/hotspot/share/opto/loopUnswitch.cpp
! src/hotspot/share/opto/loopnode.cpp

Changeset: 84f3e867
Author:    Martin Balao 
Date:      2020-02-05 12:20:36 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/84f3e867

8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB

Reviewed-by: mullan, valeriep

! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java

Changeset: 6bb05362
Author:    Harold Seigel 
Date:      2020-03-02 16:10:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6bb05362

8239568: [TESTBUG] LoadLibraryTest.java fails with RuntimeException

Throw jtreg.SkippedException instead of failing if shared library isn't unloaded

Reviewed-by: coleenp, lmesnik

- test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibrary.java
! test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibraryTest.java
! test/hotspot/jtreg/runtime/logging/loadLibraryTest/libLoadLibraryClass.c

Changeset: e455d382
Author:    Patrick Concannon 
Date:      2020-03-02 16:47:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e455d382

8234812: Add micros for DatagramChannel send/receive

Benchmarks for the DatagramChannel::send and DatagramChannel::receive methods

Reviewed-by: alanb, chegar

+ test/micro/org/openjdk/bench/java/nio/DatagramChannelSendReceive.java

Changeset: c280d98e
Author:    Lois Foltan 
Date:      2020-03-02 18:42:22 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c280d98e

8237766: Enhance signature API to include ResolvingSignatureStream

New ResolvingSignatureStream class provides the capability to easily walk through the differing parts of a signature while resolving or querying its underlying types.

Co-authored-by: John Rose 
Reviewed-by: coleenp, fparain, hseigel

! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/runtime/reflection.cpp
! src/hotspot/share/runtime/signature.cpp
! src/hotspot/share/runtime/signature.hpp

Changeset: 96b61b8f
Author:    Kim Barrett 
Date:      2020-03-02 14:45:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/96b61b8f

8240246: Avoid cast_to_oop from char*

Change type of gtest object from char[] to unsigned char[].

Reviewed-by: dholmes

! test/hotspot/gtest/oops/test_oop.cpp

Changeset: 35ee1cb2
Author:    Mikhailo Seledtsov 
Date:      2020-03-02 12:16:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/35ee1cb2

8236938: [TESTBUG] JFR event MetaspaceAllocationFailure is not tested

New test for MetaspaceAllocationFailure

Reviewed-by: hseigel, stuefe

! test/hotspot/jtreg/runtime/Metaspace/FragmentMetaspace.java
- test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java
+ test/jdk/jdk/jfr/event/runtime/TestMetaspaceAllocationFailure.java
+ test/lib/jdk/test/lib/classloader/GeneratingCompilingClassLoader.java

Changeset: c42de933
Author:    David Holmes 
Date:      2020-03-02 19:49:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c42de933

8238676: jni crashes on accessing it from process exit hook

Reviewed-by: fparain, gziemski

! make/test/JtregNativeHotspot.gmk
! src/hotspot/share/prims/jni.cpp
+ test/hotspot/jtreg/runtime/jni/atExit/TestAtExit.java
+ test/hotspot/jtreg/runtime/jni/atExit/libatExit.c

Changeset: 26a7b0dd
Author:    Prasanta Sadhukhan 
Date:      2020-03-03 13:31:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/26a7b0dd

Merge


Changeset: 6b455049
Author:    Prasanta Sadhukhan 
Date:      2020-03-03 14:45:47 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6b455049

Merge


Changeset: c2867d65
Author:    Pankaj Bansal 
Date:      2020-03-03 17:37:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c2867d65

8204161: [TESTBUG] auto failed with the "Applet thread threw exception: java.lang.UnsupportedOperationException" exception

Reviewed-by: serb

- test/jdk/java/awt/TrayIcon/AddPopupAfterShowTest/AddPopupAfterShowTest.html
! test/jdk/java/awt/TrayIcon/AddPopupAfterShowTest/AddPopupAfterShowTest.java
+ test/jdk/java/awt/TrayIcon/MiddleButtonEventTest/MiddleButtonEventTest.java

Changeset: 23def435
Author:    Pankaj Bansal 
Date:      2020-03-03 17:49:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/23def435

8239902: Remove direct usage of JSlider, JProgressBar classes in CAccessible class

Reviewed-by: serb

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java

Changeset: e70ee3dc
Author:    Pankaj Bansal 
Date:      2020-03-03 18:26:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e70ee3dc

8231042: [macos] JFileChooser creates new folder on ESC

Reviewed-by: serb, psadhukhan

! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java
+ test/jdk/javax/swing/JFileChooser/TestJFileChooserNewFolderAction.java

Changeset: bce81496
Author:    Sergey Bylokhov 
Date:      2020-03-06 14:41:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/bce81496

8219578: No associated icon for the leaf node of JTree

Reviewed-by: prr, jdv

! src/java.desktop/share/classes/module-info.java

Changeset: 315635ea
Author:    Alexander Zuev 
Date:      2020-03-09 00:18:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/315635ea

8176040: Documentation of java.awt.Rectangle.add(java.awt.Point) is wrong

Reviewed-by: serb, prr

! src/java.desktop/share/classes/java/awt/Rectangle.java

Changeset: 15a838d3
Author:    Toshio Nakamura 
Date:      2020-03-09 15:07:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/15a838d3

8240518: Incorrect JNU_ReleaseStringPlatformChars in Windows Print

Reviewed-by: serb, pbansal, psadhukhan

! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
! src/java.desktop/windows/native/libawt/windows/awt_PrintControl.cpp

Changeset: bd78beae
Author:    Jayathirth D V 
Date:      2020-03-10 16:07:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/bd78beae

6532025: GIF reader throws misleading exception with truncated images

Reviewed-by: prr, bpb

! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
+ test/jdk/javax/imageio/plugins/gif/TruncatedGIFTest.java

Changeset: 40f6d697
Author:    Sergey Bylokhov 
Date:      2020-03-10 11:30:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/40f6d697

8233573: Toolkit.getScreenInsets(GraphicsConfiguration) may throw ClassCastException

Reviewed-by: prr, jdv

! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java
! src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java
+ test/jdk/java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java

Changeset: f3ef9726
Author:    Sergey Bylokhov 
Date:      2020-03-10 13:58:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f3ef9726

8040630: Popup menus and tooltips flicker with previous popup contents when first shown

Reviewed-by: kizune, pbansal

! src/java.desktop/share/classes/javax/swing/Popup.java

Changeset: afe70e69
Author:    Marc Hoffmann 
Committer: Sergey Bylokhov 
Date:      2020-03-12 03:26:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/afe70e69

8237746: Fixing compiler warnings in src/demo/share/jfc

Reviewed-by: kizune, aivanov

! src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java
! src/demo/share/jfc/Font2DTest/Font2DTest.java
- src/demo/share/jfc/Font2DTest/Font2DTestApplet.java
! src/demo/share/jfc/Font2DTest/FontPanel.java
! src/demo/share/jfc/Font2DTest/RangeMenu.java
! src/demo/share/jfc/J2Ddemo/java2d/DemoPanel.java
! src/demo/share/jfc/J2Ddemo/java2d/GlobalControls.java
! src/demo/share/jfc/J2Ddemo/java2d/Tools.java
! src/demo/share/jfc/J2Ddemo/java2d/demos/Clipping/Areas.java
! src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/Tree.java
! src/demo/share/jfc/J2Ddemo/java2d/demos/Images/ImageOps.java
! src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/Balls.java
! src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/BezierScroller.java
! src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/GradAnim.java
! src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/TextureAnim.java
! src/demo/share/jfc/Metalworks/MetalworksPrefs.java
! src/demo/share/jfc/Notepad/ElementTreePanel.java
! src/demo/share/jfc/Stylepad/Stylepad.java
! src/demo/share/jfc/SwingSet2/ButtonDemo.java
! src/demo/share/jfc/SwingSet2/ColorChooserDemo.java
! src/demo/share/jfc/SwingSet2/ComboBoxDemo.java
! src/demo/share/jfc/SwingSet2/DemoModule.java
! src/demo/share/jfc/SwingSet2/DirectionPanel.java
! src/demo/share/jfc/SwingSet2/ExampleFileView.java
! src/demo/share/jfc/SwingSet2/FileChooserDemo.java
! src/demo/share/jfc/SwingSet2/InternalFrameDemo.java
! src/demo/share/jfc/SwingSet2/LayoutControlPanel.java
! src/demo/share/jfc/SwingSet2/ListDemo.java
! src/demo/share/jfc/SwingSet2/OptionPaneDemo.java
! src/demo/share/jfc/SwingSet2/SliderDemo.java
! src/demo/share/jfc/SwingSet2/SplitPaneDemo.java
! src/demo/share/jfc/SwingSet2/SwingSet2.java
- src/demo/share/jfc/SwingSet2/SwingSet2Applet.java
! src/demo/share/jfc/SwingSet2/TableDemo.java
! src/demo/share/jfc/TableExample/JDBCAdapter.java
! src/demo/share/jfc/TableExample/OldJTable.java
! src/demo/share/jfc/TableExample/TableExample3.java
! src/demo/share/jfc/TableExample/TableExample4.java
! src/demo/share/jfc/TableExample/TableMap.java
! src/demo/share/jfc/TableExample/TableSorter.java

Changeset: 4f1fabd8
Author:    Sergey Bylokhov 
Date:      2020-03-11 21:58:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4f1fabd8

8238075: [OGL] Delete unused properties

Reviewed-by: kizune

! src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java
! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.h
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m

Changeset: b4863f9d
Author:    Sergey Bylokhov 
Date:      2020-03-12 10:00:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b4863f9d

8240633: Memory leaks in the implementations of FileChooserUI

Reviewed-by: pbansal, psadhukhan

! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java
+ test/jdk/javax/swing/JFileChooser/FileChooserListenerLeak.java

Changeset: 23fda7e4
Author:    Phil Race 
Date:      2020-03-12 17:53:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/23fda7e4

8240977: ProblemList failing jtreg tests on macos

Reviewed-by: serb

! test/jdk/ProblemList.txt

Changeset: 3a7389f5
Author:    Ambarish Rapte 
Date:      2020-03-15 00:43:54 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3a7389f5

8226253: JAWS reports wrong number of radio buttons when buttons are hidden

Reviewed-by: kizune, pbansal

! src/java.desktop/share/classes/javax/swing/JList.java
! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java

Changeset: bca2465c
Author:    Prasanta Sadhukhan 
Date:      2020-03-16 12:49:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/bca2465c

8236635: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT

Reviewed-by: serb, pbansal

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JTabbedPane/TabProb.java

Changeset: 72b251d3
Author:    Sergey Bylokhov 
Date:      2020-03-16 17:33:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/72b251d3

8226806: [macOS 10.14] Methods of Java Robot should be called from appropriate thread

Reviewed-by: psadhukhan, prr

! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m
+ test/jdk/java/awt/Robot/NonEmptyErrorStream.java

Changeset: c1f7fa2e
Author:    Phil Race 
Date:      2020-03-17 17:38:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c1f7fa2e

8223935: PIT: java/awt/font/WindowsIndicFonts.java fails on windows10

Reviewed-by: serb, jdv

! test/jdk/java/awt/font/WindowsIndicFonts.java

Changeset: 1e217e7b
Author:    Tejpal Rebari 
Date:      2020-03-18 11:38:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1e217e7b

8146330: [macosx] UIDefaults.keys() different size than UIDefaults.keySet()

Reviewed-by: pbansal, serb, jdv

! src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java
+ test/jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java

Changeset: 9874e698
Author:    Phil Race 
Date:      2020-03-18 15:48:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9874e698

8241229: Problem list jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java

Reviewed-by: aivanov, serb

! test/jdk/ProblemList.txt

Changeset: 3340e6f9
Author:    Prasanta Sadhukhan 
Date:      2020-03-19 09:20:06 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3340e6f9

8226230: Test javax/swing/JInternalFrame/8020708/bug8020708.java fails on Ubuntu

Reviewed-by: serb

! test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java

Changeset: 7143a9c5
Author:    Prasanta Sadhukhan 
Date:      2020-03-19 09:22:37 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7143a9c5

8241078: OOM error parsing HTML with large 
     Tag text

Reviewed-by: serb, aivanov

! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java
+ test/jdk/javax/swing/text/html/TestOOMWithLargePreTag.java

Changeset: 0f7f181d
Author:    Phil Race 
Date:      2020-03-18 22:27:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0f7f181d

8241233: Typo in problem listing of UIDefaultKeySizeTest.java

Reviewed-by: jdv

! test/jdk/ProblemList.txt

Changeset: b4a3809e
Author:    Sergey Bylokhov 
Date:      2020-03-19 22:22:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b4a3809e

8240786: [TESTBUG] The test java/awt/Window/GetScreenLocation/GetScreenLocationTest.java fails on HiDPI screen

Reviewed-by: jdv, pbansal

! test/jdk/java/awt/Window/GetScreenLocation/GetScreenLocationTest.java

Changeset: 672f3a18
Author:    Prasanta Sadhukhan 
Date:      2020-03-21 09:46:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/672f3a18

8241291: JCK test javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails

Reviewed-by: prr

! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java
- test/jdk/javax/swing/text/html/TestOOMWithLargePreTag.java

Changeset: 602d98a7
Author:    Phil Race 
Date:      2020-03-20 22:52:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/602d98a7

8232634: Problem List ICMColorDataTest.java

Reviewed-by: serb, psadhukhan

! test/jdk/ProblemList.txt

Changeset: 908a9331
Author:    Nils Eliasson 
Date:      2020-03-03 10:29:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/908a9331

8238759: Clones should always keep the base pointer

Reviewed-by: rkennke, thartmann

! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
! src/hotspot/share/opto/arraycopynode.cpp
! test/hotspot/jtreg/compiler/arguments/TestStressReflectiveCode.java

Changeset: 2a791467
Author:    Volker Simonis 
Date:      2020-03-03 11:24:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2a791467

8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly

Reviewed-by: martin, clanger, lancea

! test/lib/jdk/test/lib/util/JarUtils.java

Changeset: 3fdf26d8
Author:    Claes Redestad 
Date:      2020-03-03 11:40:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3fdf26d8

8240302: x64: Assembler::reachable redundantly call Relocation::type() more than once

Reviewed-by: kvn, iklam, thartmann

! src/hotspot/cpu/x86/assembler_x86.cpp

Changeset: 52cfd292
Author:    Claes Redestad 
Date:      2020-03-03 12:41:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/52cfd292

8240263: Assertion-only call in Method::link_method affecting product builds

Reviewed-by: shade, dcubed, iklam

! src/hotspot/share/oops/method.cpp

Changeset: cf89ff7a
Author:    Harold Seigel 
Date:      2020-03-03 15:50:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cf89ff7a

8240324: Improve is_boot_class_loader_data() by adding simple check

Check if cld is the null_cld before looking at the class loader oop

Reviewed-by: coleenp

! src/hotspot/share/classfile/classLoaderData.inline.hpp

Changeset: 3ca275fb
Author:    Coleen Phillimore 
Date:      2020-03-03 11:19:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3ca275fb

8225760: oop::raw_set_obj isn't needed

Reviewed-by: hseigel, rkennke

! src/hotspot/share/oops/oopsHierarchy.hpp

Changeset: ea55699f
Author:    Fairoz Matte 
Date:      2020-02-27 19:33:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ea55699f

8239055: Wrong implementation of VMState.hasListener

Correct the VMState.hasListener implementation to return WeakReference type

Reviewed-by: sspitsyn, poonam

! src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java

Changeset: 467ee78a
Author:    Mikhailo Seledtsov 
Date:      2020-03-03 12:43:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/467ee78a

8235206: JFR TestCrossProcessStreaming - validate that data can be consumed while it is being produced

Updated test to validate concurrent produce/consume

Reviewed-by: egahlin

! test/jdk/jdk/jfr/api/consumer/streaming/TestCrossProcessStreaming.java

Changeset: 89448a83
Author:    Xue-Lei Andrew Fan 
Date:      2020-03-03 15:57:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/89448a83

8233619: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3

Reviewed-by: jnimeh

! src/java.base/share/classes/sun/security/ssl/Finished.java
! src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java
! src/java.base/share/classes/sun/security/ssl/PostHandshakeContext.java
+ test/jdk/javax/net/ssl/SSLEngine/FinishedPresent.java

Changeset: 1e796eae
Author:    Roland Westrelin 
Date:      2020-02-21 15:01:22 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1e796eae

8239367: RunThese30M.java failed due to "assert(false) failed: graph should be schedulable"

Reviewed-by: thartmann, vlivanov, neliasso

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/graphKit.cpp
+ test/hotspot/jtreg/compiler/types/TestSubTypeCheckMacroNodeWrongMem.java

Changeset: 86ad1950
Author:    Roland Westrelin 
Date:      2020-02-20 16:41:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/86ad1950

8238384: CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found"

Reviewed-by: vlivanov, thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/gcm.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/macro.hpp
! src/hotspot/share/opto/macroArrayCopy.cpp
! src/hotspot/share/opto/type.hpp
+ test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java

Changeset: 8e74ed46
Author:    Alexey Bakhtin 
Committer: Andrew Brygin 
Date:      2020-03-03 13:06:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8e74ed46

8239787: AArch64: String.indexOf may incorrectly handle empty strings

Reviewed-by: aph, lmesnik, yan

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
+ test/hotspot/jtreg/runtime/StringIntrinsic/StringIndexOfChar.java

Changeset: b3666b94
Author:    Aleksey Shipilev 
Date:      2020-03-04 11:50:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b3666b94

8240511: Shenandoah: parallel safepoint workers count should be ParallelGCThreads

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
- test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java

Changeset: 9d57eefe
Author:    Jan Lahoda 
Date:      2020-03-04 13:43:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9d57eefe

8239575: javadoc triggers javac AssertionError for annos on modules

Ensure ModuleSymbols are implicitly loaded only once in the javadoc context.

Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java
! test/langtools/jdk/javadoc/tool/modules/Modules.java

Changeset: 0c998388
Author:    Jan Lahoda 
Date:      2020-03-04 13:43:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0c998388

8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW

Avoiding parsing of compound assignment as a type.

Reviewed-by: jjg, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/langtools/tools/javac/parser/JavacParserTest.java

Changeset: e44dcf09
Author:    Jan Lahoda 
Date:      2020-03-04 13:43:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e44dcf09

8234896: Tab completion does not work for method references in jshell

Reviewed-by: rfield

! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
! test/langtools/jdk/jshell/CompletionSuggestionTest.java

Changeset: aa547959
Author:    Andy Herrick 
Date:      2020-03-03 17:58:41 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/aa547959

8237967: No proper error message when --runtime-image points to non-existent path

Reviewed-by: kizune, asemenyuk, almatvee

! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/DeployParams.java
! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources.properties
! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources_ja.properties
! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources_zh_CN.properties
! test/jdk/tools/jpackage/share/InvalidArgTest.java

Changeset: ef4053ee
Author:    Andy Herrick 
Date:      2020-03-03 18:07:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ef4053ee

8237966: Creating runtime pkg requires --mac-package-identifier

Reviewed-by: kizune, asemenyuk, almatvee

! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacPkgBundler.java

Changeset: 128f0833
Author:    Andy Herrick 
Date:      2020-03-03 18:10:15 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/128f0833

8238692: MacOS runtime Installer issue

Reviewed-by: kizune, asemenyuk, almatvee

! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java
! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacPkgBundler.java
! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties

Changeset: ff843fab
Author:    Volker Simonis 
Date:      2020-03-04 14:55:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ff843fab

8240333: jmod incorrectly updates .jar and .jmod files during hashing

Reviewed-by: martin, alanb, lancea

! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java

Changeset: 01ef6d79
Author:    Aleksey Shipilev 
Date:      2020-03-04 19:23:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/01ef6d79

8240534: Shenandoah: ditch debug safepoint timeout adjustment

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp

Changeset: edb59b58
Author:    Jonathan Gibbons 
Date:      2020-03-04 12:58:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/edb59b58

8239817: Eliminate use of contentContainer and friends

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractOverviewIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandlerImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java
! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java
! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! test/langtools/jdk/javadoc/doclet/testOverview/TestOverview.java

Changeset: 5229896f
Author:    Calvin Cheung 
Date:      2020-03-04 15:34:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5229896f

8240481: Remove CDS usage of InstanceKlass::is_in_error_state

Track the classes which fail verification during CDS dumping in DumpTimeSharedClassInfo.

Reviewed-by: iklam, minqi

! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp

Changeset: 10b09c79
Author:    Jesper Wilhelmsson 
Date:      2020-03-05 02:02:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/10b09c79

Added tag jdk-15+13 for changeset 1c06a8ee8aca

! .hgtags

Changeset: 6cb2e02a
Author:    Yumin Qi 
Date:      2020-03-04 21:29:14 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6cb2e02a

8240546: runtime/cds/appcds/TestZGCWithCDS.java fails with Graal

Test failed since Graal does not work with ZGC, fixed in test to skip Graal if ZGC.

Reviewed-by: ccheung

! test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java

Changeset: 7ba18fc0
Author:    Ioi Lam 
Date:      2020-03-04 22:26:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7ba18fc0

8240244: Avoid calling resolve_super_or_fail in SystemDictionary::load_shared_class

Reviewed-by: redestad, lfoltan, minqi

! src/hotspot/share/classfile/classListParser.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoaderExt.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp

Changeset: d1818942
Author:    Qi Feng 
Committer: Ningsheng Jian 
Date:      2020-03-05 14:51:41 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d1818942

8240286: [TESTBUG] Test command error in hotspot/jtreg/compiler/loopopts/superword/SumRedAbsNeg_Float.java

Reviewed-by: kvn, thartmann

! test/hotspot/jtreg/compiler/loopopts/superword/SumRedAbsNeg_Float.java

Changeset: b2f1f73e
Author:    Ravi Reddy 
Committer: David Buck 
Date:      2020-03-05 03:27:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b2f1f73e

8183369: RFC unconformity of HttpURLConnection with proxy

HttpURLConnection retried with proxy if the connection fails on first attempt as per RFC

Reviewed-by: chegar, dfuchs, vtewari

! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java

Changeset: 3490262a
Author:    Yasumasa Suenaga 
Date:      2020-03-05 19:46:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3490262a

8240197: Cannot start JVM when $JAVA_HOME includes CJK characters

Reviewed-by: iklam, stuefe, rschmelter

! src/hotspot/os/windows/os_windows.cpp

Changeset: 3ddd7b86
Author:    Erik ?sterlund 
Date:      2020-03-05 11:12:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3ddd7b86

8240370: Provide Intel JCC Erratum opt-out

Reviewed-by: redestad, vlivanov, thartmann

! src/hotspot/cpu/x86/globals_x86.hpp
! src/hotspot/cpu/x86/vm_version_x86.cpp

Changeset: 78982f7c
Author:    Claes Redestad 
Date:      2020-03-05 13:14:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/78982f7c

8240528: OopMap cleanup

Reviewed-by: kvn, thartmann

! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/share/compiler/oopMap.cpp
! src/hotspot/share/compiler/oopMap.hpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/runtime/vmStructs.cpp

Changeset: d75e62e1
Author:    Markus Gr?nlund 
Date:      2020-03-05 17:55:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d75e62e1

8239376: JFR: assert(!cld->is_unsafe_anonymous()) failed: invariant

Reviewed-by: coleenp, lfoltan, hseigel

! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp

Changeset: db91be2e
Author:    Alexandre Iline 
Date:      2020-03-05 09:51:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/db91be2e

8240241: Add support for JCov DiffCoverage to make files

Reviewed-by: erikj, ihse

! doc/testing.html
! doc/testing.md
! make/RunTests.gmk

Changeset: 3607ddd5
Author:    Lance Andersen 
Date:      2020-03-05 13:56:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3607ddd5

8211917: Zip FS should add META-INF/MANIFEST.FS  at the start of the Zip/JAR

Reviewed-by: clanger, jpai

! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
+ test/jdk/jdk/nio/zipfs/testng/TEST.properties
+ test/jdk/jdk/nio/zipfs/testng/test/ManifestOrderTest.java
+ test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java

Changeset: 4a32eda4
Author:    Vicente Romero 
Date:      2020-03-05 16:46:24 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4a32eda4

8240454: incorrect error message: as of release 13, 'record' is a restricted type name

Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java
! test/langtools/lib/combo/tools/javac/combo/Diagnostics.java
! test/langtools/lib/combo/tools/javac/combo/JavacTemplateTestBase.java
! test/langtools/tools/javac/records/RecordCompilationTests.java
! test/langtools/tools/javac/switchexpr/WrongYieldTest.out

Changeset: 001b8056
Author:    Joe Darcy 
Date:      2020-03-05 15:07:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/001b8056

8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 attribute

Reviewed-by: bpb

! src/java.base/share/classes/java/math/RoundingMode.java

Changeset: f456f151
Author:    Doug Simon 
Date:      2020-03-05 16:32:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f456f151

8240538: [JVMCI] add test for JVMCI ConstantPool class

Reviewed-by: kvn, iignatyev

+ test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantPoolTest.java

Changeset: 9c6a7696
Author:    Ramkumar Sunderbabu 
Committer: Ramkumar Sunderbabu 
Date:      2020-03-06 10:27:24 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9c6a7696

8153430: jdk regression test MletParserLocaleTest, ParserInfiniteLoopTest reduce default timeout

Removed timeout=5 from the tests so that default timeout is used

Reviewed-by: cjplummer

! test/jdk/javax/management/loading/MletParserLocaleTest.java
! test/jdk/javax/management/loading/ParserInfiniteLoopTest.java

Changeset: f10fd7a7
Author:    Matthias Baesken 
Date:      2020-03-05 13:12:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f10fd7a7

8240603: Windows 32bit compile error after 8238676

Reviewed-by: clanger, dholmes

! test/hotspot/jtreg/runtime/jni/atExit/libatExit.c

Changeset: 3adad5a6
Author:    Martin Doerr 
Date:      2020-03-06 11:04:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3adad5a6

8239856: [ntintel] asserts about copying unaligned array element

Reviewed-by: stuefe, sspitsyn

! src/jdk.jdwp.agent/share/native/libjdwp/ArrayReferenceImpl.c

Changeset: 25d2db06
Author:    Ivan Walulya 
Date:      2020-03-06 11:40:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/25d2db06

8240589: OtherRegionsTable::_num_occupied not updated correctly

Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/g1/heapRegionRemSet.cpp

Changeset: 95a497ae
Author:    Aditya Mandaleeka 
Committer: Roman Kennke 
Date:      2020-03-06 13:41:14 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/95a497ae

8236981: Remove ShenandoahTraversalUpdateRefsClosure

Reviewed-by: shade, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp
! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp

Changeset: f0cd9dd5
Author:    Ivan Walulya 
Date:      2020-03-06 14:10:41 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f0cd9dd5

8240592: HeapRegionManager::rebuild_free_list logs 0s for the estimated free regions before

Reviewed-by: sjohanss, kbarrett

! src/hotspot/share/gc/g1/heapRegionManager.cpp

Changeset: 14c09861
Author:    Ralf Schmelter 
Date:      2020-03-06 16:19:32 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/14c09861

8240440: Implement get_safepoint_workers() for parallel GC

Reviewed-by: tschatzl, kbarrett

! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp

Changeset: c92adf41
Author:    Severin Gehwolf 
Date:      2020-02-24 19:03:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c92adf41

8240189: [TESTBUG] Some cgroup tests are failing after JDK-8231111

Reviewed-by: mbaesken, bobv

! test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java
! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java
! test/lib/jdk/test/lib/containers/cgroup/CgroupMetricsTester.java
! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java
! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java

Changeset: d8bded6f
Author:    Aleksey Shipilev 
Date:      2020-03-06 17:03:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d8bded6f

8240671: Shenandoah: refactor ShenandoahPhaseTimings

Reviewed-by: rkennke, zgu

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp
- src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp
- src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp

Changeset: f87ebd9e
Author:    Sean Mullan 
Date:      2020-03-06 13:17:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f87ebd9e

8240684: ProblemList 70 security tests that are failing on Windows due to "Fetch artifact failed"

Reviewed-by: xuelei, stsmirno, dcubed

! test/jdk/ProblemList.txt

Changeset: e2f43191
Author:    Brian Burkhalter 
Date:      2020-03-06 10:34:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e2f43191

4617266: (se spec) SelectionKey.OP_READ/OP_WRITE documentation errors

Reviewed-by: lancea, alanb, darcy

! src/java.base/share/classes/java/nio/channels/SelectionKey.java

Changeset: 375d0c13
Author:    Roger Riggs 
Date:      2020-03-06 13:52:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/375d0c13

8239893: Windows handle Leak when starting processes using ProcessBuilder

Reviewed-by: bpb, naoto

! src/java.base/windows/classes/java/lang/ProcessImpl.java
+ test/jdk/java/lang/ProcessBuilder/checkHandles/CheckHandles.java
+ test/jdk/java/lang/ProcessBuilder/checkHandles/libCheckHandles.c

Changeset: 8c1204de
Author:    Roman Kennke 
Date:      2020-03-06 21:51:32 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8c1204de

8240315: Shenandoah: Rename ShLBN::get_barrier_strength()

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp

Changeset: 9e2ab1e3
Author:    Calvin Cheung 
Date:      2020-03-06 15:33:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9e2ab1e3

8232081: Try to link all classes during dynamic CDS dump

During CDS dynamic dump, link all classes loaded by the builtin class loaders in JVM_BeforeHalt() and JavaThread::invoke_shutdown_hooks().

Reviewed-by: iklam, dholmes

! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/thread.cpp
+ test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LinkClassTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/LinkClassApp.java

Changeset: 9f334a16
Author:    Kim Barrett 
Date:      2020-03-06 18:42:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9f334a16

8240239: Replace ConcurrentGCPhaseManager

Replace ConcurrentGCPhaseManager with ConcurrentGCBreakpoints

Co-authored-by: Per Liden 
Reviewed-by: kbarrett, pliden, sangheki

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp
! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1VMOperations.cpp
! src/hotspot/share/gc/g1/g1VMOperations.hpp
! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
+ src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp
+ src/hotspot/share/gc/shared/concurrentGCBreakpoints.hpp
- src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp
- src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp
! src/hotspot/share/gc/shared/gcCause.cpp
! src/hotspot/share/gc/shared/gcCause.hpp
+ src/hotspot/share/gc/z/zBreakpoint.cpp
+ src/hotspot/share/gc/z/zBreakpoint.hpp
! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/gc/z/zCollectedHeap.hpp
! src/hotspot/share/gc/z/zDriver.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
+ test/hotspot/jtreg/gc/TestConcurrentGCBreakpoints.java
+ test/hotspot/jtreg/gc/TestJNIWeak/TestJNIWeak.java
+ test/hotspot/jtreg/gc/TestJNIWeak/libTestJNIWeak.c
- test/hotspot/jtreg/gc/concurrent_phase_control/CheckControl.java
- test/hotspot/jtreg/gc/concurrent_phase_control/CheckSupported.java
- test/hotspot/jtreg/gc/concurrent_phase_control/CheckUnsupported.java
- test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1.java
- test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlG1Basics.java
- test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlParallel.java
- test/hotspot/jtreg/gc/concurrent_phase_control/TestConcurrentPhaseControlSerial.java
- test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java
- test/hotspot/jtreg/gc/g1/TestJNIWeakG1/libTestJNIWeakG1.c
! test/lib/sun/hotspot/WhiteBox.java

Changeset: c203cebc
Author:    Mikael Vidstedt 
Date:      2020-03-06 17:33:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c203cebc

8240535: Add additional linux-aarch64 jib profiles

Reviewed-by: erikj

! make/conf/jib-profiles.js

Changeset: c46623d0
Author:    Jonathan Gibbons 
Date:      2020-03-06 18:03:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c46623d0

8240137: Support chained use of Content.add

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Comment.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Entity.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/FixedStringContent.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Script.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/StringContent.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Content.java

Changeset: f222cb8b
Author:    Jie Fu 
Date:      2020-03-07 14:42:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f222cb8b

8240695: Build is broken when cds is disabled after JDK-8232081

Reviewed-by: iklam

! src/hotspot/share/memory/metaspaceShared.hpp

Changeset: ff8e7d40
Author:    Vyom Tewari 
Date:      2020-03-07 18:35:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ff8e7d40

8238579: HttpsURLConnection drops the timeout and hangs forever in read

HttpsURLConnection drops the timeout and hangs forever in read

Reviewed-by: dfuchs

! src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java

Changeset: d0e44e5b
Author:    Boris Ulasevich 
Date:      2020-03-07 16:27:00 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d0e44e5b

8239514: Build for arm-linux-gnueabihf fails with undefined reference read_polling_page

Reviewed-by: dsamersoff, dholmes

! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/arm/macroAssembler_arm.cpp

Changeset: 3d9dddd6
Author:    Ichiroh Takiguchi 
Date:      2020-03-08 15:15:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3d9dddd6

8239965: XMLEncoder/Test4625418.java fails due to "Error: Cp943 - can't read properly"

Cp943 and x-IBM943 should skip on XMLEncoder/Test4625418.java

Reviewed-by: naoto

! test/jdk/ProblemList.txt
! test/jdk/java/beans/XMLEncoder/Test4625418.java

Changeset: 7806ca14
Author:    Kim Barrett 
Date:      2020-03-08 17:33:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7806ca14

8240133: G1DirtyCardQueue destructor has useless flush

Removed useless call to flush.

Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp

Changeset: 046dcdc0
Author:    Ioi Lam 
Date:      2020-03-08 15:06:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/046dcdc0

8240613: InstanceKlass::set_init_state failed with assert(good_state || state == allocated)

Reviewed-by: dcubed

! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: ba2e4178
Author:    Rajan Halade 
Date:      2020-03-09 00:45:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ba2e4178

8240686: 70 security tests are failing on Windows due to "Fetch artifact failed"

Reviewed-by: xuelei

! test/jdk/ProblemList.txt

Changeset: 1c1fb44a
Author:    Kim Barrett 
Date:      2020-03-09 04:06:37 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1c1fb44a

8240722: [BACKOUT] G1DirtyCardQueue destructor has useless flush

Backout JDK-8240133

Reviewed-by: sjohanss

! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp

Changeset: b58c8601
Author:    Roland Westrelin 
Date:      2020-03-05 15:56:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b58c8601

8239335: C2: assert((Value(phase) == t) || (t != TypeInt::CC_GT && t != TypeInt::CC_EQ)) failed: missing Value() optimization

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/subtypenode.cpp
+ test/hotspot/jtreg/compiler/types/TestIntArraySubTypeOfCloneableDoesnotFold.java

Changeset: 3ff8eff8
Author:    Aditya Mandaleeka 
Committer: Roman Kennke 
Date:      2020-03-09 12:29:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3ff8eff8

8220503: Move ShenandoahTerminatorTerminator::should_exit_termination out of header

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp

Changeset: a11912ca
Author:    Kevin Walls 
Date:      2020-03-09 12:54:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a11912ca

8240295: hs_err elapsed time in seconds is not accurate enough

Reviewed-by: dholmes, sspitsyn

! src/hotspot/share/runtime/os.cpp

Changeset: e0fec43a
Author:    Mario Torre 
Date:      2020-03-09 14:57:41 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e0fec43a

8240738: nested comment in JVM.java and other minor formatting errors

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java

Changeset: aa2be114
Author:    Dongbo He 
Committer: Fei Yang 
Date:      2020-03-09 22:31:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/aa2be114

8240576: JVM crashes after transformation in C2 IdealLoopTree::merge_many_backedges

Reviewed-by: kvn

! src/hotspot/share/opto/loopnode.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestBeautifyLoops.java

Changeset: dc178218
Author:    Henry Jen 
Date:      2020-03-06 13:48:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/dc178218

8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk

Reviewed-by: alanb, mchung

! src/java.base/share/native/libjli/args.c
! test/jdk/tools/launcher/ArgFileSyntax.java

Changeset: 5c8f9356
Author:    Daniel Fuchs 
Date:      2020-03-09 17:48:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5c8f9356

8240754: Instrument FlowTest.java to provide more debug traces

Reviewed-by: chegar

! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java

Changeset: 123ac070
Author:    Naoto Sato 
Date:      2020-03-09 13:20:45 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/123ac070

8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity

Reviewed-by: rriggs, joehw, scolebourne

! src/java.base/share/classes/java/time/zone/ZoneRules.java
! test/jdk/java/time/test/java/time/zone/TestZoneRules.java

Changeset: 672992f6
Author:    Erik Gahlin 
Date:      2020-03-09 21:25:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/672992f6

8222000: JFR: Process start event

Reviewed-by: mgronlun, rriggs

! src/java.base/share/classes/java/lang/ProcessBuilder.java
+ src/java.base/share/classes/jdk/internal/event/ProcessStartEvent.java
+ src/jdk.jfr/share/classes/jdk/jfr/events/ProcessStartEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java
! src/jdk.jfr/share/conf/jfr/default.jfc
! src/jdk.jfr/share/conf/jfr/profile.jfc
! test/jdk/jdk/jfr/event/metadata/TestDefaultConfigurations.java
+ test/jdk/jdk/jfr/event/os/TestProcessStart.java
! test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java
! test/lib/jdk/test/lib/jfr/EventNames.java

Changeset: f09cda2c
Author:    Erik Gahlin 
Date:      2020-03-09 21:43:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f09cda2c

8239584: EventStream::close should state that stream will be stopped

Reviewed-by: mgronlun, mseledtsov

! src/jdk.jfr/share/classes/jdk/jfr/consumer/EventStream.java
! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java

Changeset: 2ba5ed53
Author:    Aleksey Shipilev 
Date:      2020-03-09 22:40:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2ba5ed53

8240749: Shenandoah: refactor ShenandoahUtils

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp

Changeset: 9722dfc9
Author:    Aleksey Shipilev 
Date:      2020-03-09 22:41:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9722dfc9

8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker

Reviewed-by: rkennke

- src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp
- src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp

Changeset: d112950b
Author:    Aditya Mandaleeka 
Committer: Aleksey Shipilev 
Date:      2020-03-09 22:41:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d112950b

8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.inline.hpp

Changeset: 43e0165e
Author:    Roland Westrelin 
Date:      2020-03-10 10:45:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/43e0165e

8240794: [BACKOUT] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found"

Reviewed-by: thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/gcm.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/macro.hpp
! src/hotspot/share/opto/macroArrayCopy.cpp
! src/hotspot/share/opto/type.hpp
- test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java

Changeset: d49eb0d9
Author:    Ivan Walulya 
Date:      2020-03-10 10:19:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d49eb0d9

8240668: G1 list of all PerRegionTable does not have to be a double linkedlist any more

Reviewed-by: kbarrett, tschatzl

! src/hotspot/share/gc/g1/heapRegionRemSet.cpp
! src/hotspot/share/gc/g1/heapRegionRemSet.hpp
! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp

Changeset: edaf548b
Author:    John Jiang 
Date:      2020-03-10 21:43:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/edaf548b

8238740: java/net/httpclient/whitebox/FlowTestDriver.java would not specify a TLS protocol

Reviewed-by: dfuchs

! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java

Changeset: aac5b27b
Author:    Markus Gr?nlund 
Date:      2020-03-10 15:44:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/aac5b27b

8238180: RunThese30M failed "assert(t->jfr_thread_local()->shelved_buffer() == __null) failed: invariant"

Reviewed-by: egahlin

! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp

Changeset: f4b54881
Author:    Dongbo He 
Committer: Fei Yang 
Date:      2020-03-09 18:21:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f4b54881

8240734: ModuleHashes attribute not reproducible between builds

Reviewed-by: alanb

! src/java.base/share/classes/jdk/internal/module/ModuleHashes.java
! src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java

Changeset: 42ff13ab
Author:    Roland Westrelin 
Date:      2020-03-09 09:42:30 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/42ff13ab

8240195: some jaotc failures of fastdebug build with specific flags

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/subtypenode.cpp
+ test/hotspot/jtreg/compiler/types/TestSubTypeOfAsbtractClassWrongResult.java

Changeset: 8208b9ce
Author:    Erik Gahlin 
Date:      2020-03-10 18:39:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8208b9ce

8240778: JFR: Create timer task lazily

Reviewed-by: mgronlun, mseledtsov

! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java

Changeset: 072cfd2e
Author:    Vladimir Ivanov 
Date:      2020-03-10 20:51:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/072cfd2e

8238681: Make -XX:UseSSE flag x86-specific

Reviewed-by: dholmes, kvn

! src/hotspot/cpu/ppc/vm_version_ppc.cpp
! src/hotspot/cpu/sparc/vm_version_sparc.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp
! src/hotspot/cpu/x86/globals_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/c1/c1_LinearScan.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/compiler/c1/Test6579789.java
! test/hotspot/jtreg/compiler/c1/Test6855215.java

Changeset: 1dcd3d2c
Author:    Vladimir Ivanov 
Date:      2020-03-10 20:51:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1dcd3d2c

8239008: C2: Simplify Replicate support for sub-word types on x86

Reviewed-by: kvn

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/x86.ad

Changeset: 02916dbb
Author:    Vladimir Ivanov 
Date:      2020-03-10 20:51:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/02916dbb

8239009: C2: Don't use PSHUF to load scalars from memory on x86

Reviewed-by: kvn, dlong

! src/hotspot/cpu/x86/x86.ad

Changeset: 0e3529ad
Author:    Yumin Qi 
Date:      2020-03-10 11:52:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0e3529ad

8240691: ClhsdbCDSJstackPrintAll incorrectly thinks CDS is in use

Fix by checking "UseSharedSpaces = false" for CDS enabled.

Reviewed-by: iklam

! src/hotspot/share/prims/whitebox.cpp
! test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbCDSJstackPrintAll.java

Changeset: 75632a6d
Author:    Yudi Zheng 
Committer: Doug Simon 
Date:      2020-03-10 21:48:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/75632a6d

8240610: [JVMCI] Export VMVersion::_has_intel_jcc_erratum to JVMCI compiler

Reviewed-by: kvn, thartmann

! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: 53c6887a
Author:    Yumin Qi 
Date:      2020-03-10 14:37:37 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/53c6887a

8240840: Rollback whitebox.cpp in push 8240691

Whitebox.cpp should not change in 8240691, which is accidentally included.

Reviewed-by: iklam, ccheung

! src/hotspot/share/prims/whitebox.cpp

Changeset: 39ab0731
Author:    Vladimir Kozlov 
Date:      2020-03-10 14:39:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/39ab0731

8240830: [BACKOUT] 8240195: some jaotc failures of fastdebug build with specific flags

Reviewed-by: dcubed

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/subtypenode.cpp
- test/hotspot/jtreg/compiler/types/TestSubTypeOfAsbtractClassWrongResult.java

Changeset: 0fd2ac70
Author:    Jonathan Gibbons 
Date:      2020-03-10 14:46:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0fd2ac70

8240697: convert builders to high-level Content blocks

Reviewed-by: prappo

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractOverviewIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandlerImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/BodyContents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/TableHeader.java

Changeset: 5eef59d2
Author:    Adam Sotona 
Date:      2020-03-10 17:33:37 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5eef59d2

8235216: typo in test filename

Renamed MutliReleaseModuleInfoTest.java to MultiReleaseModuleInfoTest.java

Reviewed-by: jjg

+ test/langtools/tools/javac/file/MultiReleaseJar/MultiReleaseModuleInfoTest.java
- test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java

Changeset: 08c3b1fc
Author:    Chihiro Ito 
Date:      2020-03-07 23:08:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/08c3b1fc

8222489: jcmd VM.system_properties gives unusable paths on Windows

Reviewed-by: sspitsyn, ysuenaga

! src/java.base/share/classes/jdk/internal/vm/VMSupport.java
+ test/jdk/sun/tools/jcmd/TestVM.java

Changeset: 80ca356e
Author:    Weijun Wang 
Date:      2020-03-11 10:33:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/80ca356e

8239928: ec/ECDSAJavaVerify.java failed due to timeout

Reviewed-by: valeriep

! test/jdk/sun/security/ec/ECDSAJavaVerify.java

Changeset: 99b28daf
Author:    Yasumasa Suenaga 
Date:      2020-03-11 13:14:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/99b28daf

8240725: Some functions might not work with CJK character

Reviewed-by: naoto

! src/java.base/share/native/libzip/zip_util.c
! src/java.base/windows/native/libjava/canonicalize_md.c
! src/java.base/windows/native/libjli/java_md.c
! src/jdk.incubator.jpackage/windows/native/libapplauncher/WindowsPlatform.cpp

Changeset: 441e16e2
Author:    Magnus Ihse Bursie 
Date:      2020-03-11 08:34:14 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/441e16e2

8240820: Replace AC_ARG_ENABLE with UTIL_ARG_ENABLE

Reviewed-by: erikj

! make/autoconf/build-performance.m4
! make/autoconf/flags-cflags.m4
! make/autoconf/hotspot.m4
! make/autoconf/jdk-options.m4
! make/autoconf/lib-ffi.m4
! make/autoconf/platform.m4
! make/autoconf/util.m4
! test/make/autoconf/test.m4

Changeset: 1c1acb47
Author:    Erik Helin 
Date:      2020-03-10 16:58:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1c1acb47

8237566: FindTests.gmk should only include existing TEST.ROOT files

Reviewed-by: erikj

! make/common/FindTests.gmk

Changeset: 593a05c9
Author:    Stefan Karlsson 
Date:      2020-03-04 15:50:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/593a05c9

8240530: CheckUnhandledOops breaks BacktraceBuilder::set_has_hidden_top_frame

Reviewed-by: coleenp, dholmes

! src/hotspot/share/classfile/javaClasses.cpp

Changeset: 43e0fc04
Author:    Stefan Karlsson 
Date:      2020-03-04 15:50:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/43e0fc04

8240529: CheckUnhandledOops breaks NULL check in Modules::define_module

Reviewed-by: coleenp, lfoltan, hseigel

! src/hotspot/share/classfile/modules.cpp

Changeset: 534331f0
Author:    Stefan Karlsson 
Date:      2020-03-04 18:08:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/534331f0

8240532: heap inspection prints trailing @ after name of module without version

Reviewed-by: lfoltan

! src/hotspot/share/memory/heapInspection.cpp
! test/hotspot/jtreg/serviceability/dcmd/gc/ClassHistogramTest.java

Changeset: 661c0735
Author:    Andrew Haley 
Date:      2020-03-10 10:49:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/661c0735

8240615: is_power_of_2() has Undefined Behaviour and is inconsistent

Reviewed-by: jrose, redestad

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/utilities/powerOfTwo.hpp
! test/hotspot/gtest/utilities/test_powerOfTwo.cpp

Changeset: 0992e17b
Author:    Andrew Haley 
Date:      2020-03-11 12:38:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0992e17b

8240829: Use a fast O(1) algorithm for exact_log2

Reviewed-by: jrose, redestad

! src/hotspot/share/utilities/powerOfTwo.hpp
! test/hotspot/gtest/utilities/test_powerOfTwo.cpp

Changeset: d7780973
Author:    Vipin Sharma 
Committer: Christoph Langer 
Date:      2020-03-11 13:50:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d7780973

8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java

Reviewed-by: clanger, vtewari

! test/jdk/java/lang/Boolean/GetBoolean.java
! test/jdk/java/lang/Boolean/MakeBooleanComparable.java
! test/jdk/java/lang/Boolean/ParseBoolean.java

Changeset: eb974fad
Author:    Aleksey Shipilev 
Date:      2020-03-11 14:17:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/eb974fad

8240868: Shenandoah: remove CM-with-UR piggybacking cycles

Reviewed-by: rkennke, zgu

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! src/hotspot/share/runtime/vmOperations.hpp
! test/hotspot/jtreg/gc/shenandoah/TestStringDedupStress.java

Changeset: 6275aee6
Author:    Andrew Haley 
Date:      2020-03-11 15:02:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6275aee6

Merge


Changeset: 14e37ba3
Author:    Alexey Bakhtin 
Committer: Andrew Brygin 
Date:      2020-03-11 19:14:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/14e37ba3

8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException

Reviewed-by: xuelei

! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java
! src/java.base/share/classes/sun/security/ssl/SSLTransport.java
! test/jdk/sun/security/ssl/SSLSocketImpl/ClientTimeout.java
! test/jdk/sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java

Changeset: 5b323a86
Author:    Adam Sotona 
Committer: Lance Andersen 
Date:      2020-03-11 12:30:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5b323a86

8230117: Remove unused JAR tool classes

Reviewed-by: lancea, clanger

- src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java
- src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java

Changeset: 8c6649de
Author:    Pavel Rappo 
Date:      2020-03-11 17:09:10 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8c6649de

8239487: Better links generation for system properties found in HTML files
8239485: Define behavior of the System Properties page when no system properties are available

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandlerImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchIndexItem.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchIndexItems.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/DocFileElement.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java
! test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/TestSystemPropertyPage.java
+ test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/overview.html
+ test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg1/A.java
+ test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg1/doc-files/WithEmptyTitle.html
+ test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg1/doc-files/WithTitle.html
+ test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg1/doc-files/WithoutTitle.html
+ test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src1/pkg2/B.java
+ test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/src2/pkg1/A.java
! test/langtools/jdk/javadoc/doclet/testSystemPropertyTaglet/TestSystemPropertyTaglet.java
! test/langtools/jdk/javadoc/tool/api/basic/APITest.java

Changeset: db69852a
Author:    Serguei Spitsyn 
Date:      2020-03-11 20:28:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/db69852a

8240881: [BACKOUT] 8222489 jcmd VM.system_properties gives unusable paths on Windows

Undo the 8222489 changeset

Reviewed-by: dcubed, iklam

! src/java.base/share/classes/jdk/internal/vm/VMSupport.java
- test/jdk/sun/tools/jcmd/TestVM.java

Changeset: 5531199d
Author:    Alex Menkov 
Date:      2020-03-11 13:39:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5531199d

8240340: java/lang/management/ThreadMXBean/Locks.java is buggy

Reviewed-by: dholmes, sspitsyn

! test/jdk/java/lang/management/ThreadMXBean/Locks.java
! test/lib/jdk/test/lib/LockFreeLogger.java

Changeset: 6b487c3c
Author:    Magnus Ihse Bursie 
Date:      2020-03-11 22:25:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6b487c3c

8240866: Typo in JDK-8240820 messes up configure --help

Reviewed-by: erikj

! make/autoconf/flags-cflags.m4
! make/autoconf/hotspot.m4

Changeset: 5b9a09cb
Author:    Jonathan Gibbons 
Date:      2020-03-11 15:46:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5b9a09cb

8240138: Cleanup HtmlTree

Reviewed-by: prappo

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Comment.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTag.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Content.java

Changeset: 069d9e79
Author:    Yasumasa Suenaga 
Date:      2020-03-12 09:23:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/069d9e79

8234624: jstack mixed mode should refer DWARF

Reviewed-by: sspitsyn, kevinw

+ src/jdk.hotspot.agent/linux/native/libsaproc/DwarfParser.cpp
! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp
+ src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp
+ src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.hpp
! src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h
! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c
! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.h
! src/jdk.hotspot.agent/linux/native/libsaproc/salibelf.c
! src/jdk.hotspot.agent/linux/native/libsaproc/salibelf.h
! src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java
+ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/DwarfParser.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java

Changeset: 92686e1a
Author:    Jesper Wilhelmsson 
Date:      2020-03-12 03:10:32 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/92686e1a

Added tag jdk-15+14 for changeset 1d6ceb13e142

! .hgtags

Changeset: b0f32c44
Author:    Ioi Lam 
Date:      2020-03-11 21:37:45 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b0f32c44

8240548: [TESTBUG] CDS NoClassToArchive.java fails with Graal

Reviewed-by: dholmes, mchung

! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NoClassToArchive.java

Changeset: 19e02810
Author:    Kelvin Nilsen 
Committer: Aleksey Shipilev 
Date:      2020-03-12 06:47:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/19e02810

8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/gc/logging/TestMetaSpaceLog.java

Changeset: 0368e41c
Author:    Weijun Wang 
Date:      2020-03-12 18:21:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0368e41c

8240261: Use make/templates/gpl-cp-header in FieldGen.java

Reviewed-by: erikj

! make/gensrc/Gensrc-java.base.gmk
! make/jdk/src/classes/build/tools/intpoly/FieldGen.java
- make/jdk/src/classes/build/tools/intpoly/header.txt
+ make/jdk/src/classes/build/tools/util/Header.java

Changeset: c5bd0d79
Author:    Richard Reingruber 
Date:      2020-03-12 11:51:00 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c5bd0d79

8234146: compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC

Reviewed-by: vlivanov, thartmann

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/jsr292/ContinuousCallSiteTargetChange.java

Changeset: 7fe46b24
Author:    Claes Redestad 
Date:      2020-03-12 13:07:21 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7fe46b24

8240772: x86_64: Pre-generate Assembler::popa, pusha and vzeroupper

Reviewed-by: iklam, kvn

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/vm_version_x86.cpp

Changeset: d49cf17d
Author:    Claes Redestad 
Date:      2020-03-05 16:07:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d49cf17d

8240669: Devirtualize Relocation::type

Reviewed-by: rbackman, thartmann

! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/code/relocInfo.hpp

Changeset: 21d3eaf5
Author:    Yudi Zheng 
Committer: Doug Simon 
Date:      2020-03-12 13:20:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/21d3eaf5

8240831: [JVMCI] Export missing vmStructs entries used by JVMCI compilers

Reviewed-by: kvn, thartmann

! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: 1f189228
Author:    Zhengyu Gu 
Date:      2020-03-12 09:25:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1f189228

8240915: Shenandoah: Remove unused fields in init mark tasks

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp

Changeset: 48c48b7a
Author:    Vladimir Ivanov 
Date:      2020-03-12 16:42:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/48c48b7a

8238696: x86: Enumerate all detected CPU features in VM_Version feature string

Reviewed-by: dholmes, kvn

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp
! src/hotspot/cpu/x86/x86.ad
+ test/jdk/lib/testlibrary/CPUInfoTest.java

Changeset: add18914
Author:    Severin Gehwolf 
Date:      2020-02-25 12:17:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/add18914

8239785: Cgroups: Incorrect detection logic on old systems in hotspot

Return NULL subsystem if no cgroup controllers are mounted.

Reviewed-by: bobv, mbaesken

! src/hotspot/os/linux/cgroupSubsystem_linux.cpp
! src/hotspot/os/linux/cgroupSubsystem_linux.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/prims/whitebox.hpp
+ test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java
! test/lib/sun/hotspot/WhiteBox.java

Changeset: eeaafbe1
Author:    Naoto Sato 
Date:      2020-03-12 08:31:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/eeaafbe1

8216332: Grapheme regex does not work with emoji sequences

Reviewed-by: rriggs

! src/java.base/share/classes/java/util/regex/Grapheme.java
+ test/jdk/java/util/regex/GraphemeTestCases.txt
! test/jdk/java/util/regex/RegExTest.java

Changeset: fee69bab
Author:    Roger Riggs 
Date:      2020-03-12 11:54:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/fee69bab

8240704: CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent."

Reviewed-by: dfuchs

! test/jdk/java/lang/ProcessBuilder/checkHandles/CheckHandles.java

Changeset: c68e15c0
Author:    Roger Riggs 
Date:      2020-03-12 11:57:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c68e15c0

8240957: Clarify BadAttributeValueExpException readObject method

Reviewed-by: bpb

! src/java.management/share/classes/javax/management/BadAttributeValueExpException.java

Changeset: 90a39195
Author:    Yumin Qi 
Date:      2020-03-12 09:07:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/90a39195

8240563: [TESTBUG] WB_IsCDSIncludedInVmBuild should support uncompressed oops/klasses

With 8232069, CDS works with uncompressed oops/kalsses, detecting CDS code no longer bases on the two flags.

Reviewed-by: iklam

! src/hotspot/share/prims/whitebox.cpp
! test/hotspot/jtreg/ProblemList-zgc.txt
! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagComboNegative.java
! test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java

Changeset: 70e730fd
Author:    Roman Kennke 
Date:      2020-03-12 17:52:10 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/70e730fd

8240872: Shenandoah: Avoid updating new regions from start of evacuation

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp

Changeset: e5ab7011
Author:    Roman Kennke 
Date:      2020-03-12 17:52:47 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e5ab7011

8240873: Shenandoah: Short-cut arraycopy barriers

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp

Changeset: 0ed44d0a
Author:    Patrick Concannon 
Date:      2020-03-12 17:08:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0ed44d0a

8239355: (dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)

Updates DatagramChannel so that the SO_SNDBUF is set to a minimum value of 65527 for IPv6 sockets and 65507 for IPv4 sockets on macOS.

Reviewed-by: alanb, dfuchs

! src/java.base/unix/native/libnio/ch/Net.c
! test/jdk/java/net/IPSupport/MinimumPermissions.policy
+ test/jdk/java/nio/channels/DatagramChannel/MinSendBufferSize.java
! test/lib/jdk/test/lib/net/IPSupport.java

Changeset: 71e1277f
Author:    Zhengyu Gu 
Date:      2020-03-12 13:08:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/71e1277f

8240917: Shenandoah: Avoid scanning thread code roots twice in all root scanner

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp

Changeset: de5208e3
Author:    Patrick Concannon 
Date:      2020-03-12 17:20:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/de5208e3

Merge


Changeset: 3ee99ca1
Author:    Aleksey Shipilev 
Date:      2020-03-12 18:50:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3ee99ca1

8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

Changeset: 58337b12
Author:    Daniel Fuchs 
Date:      2020-03-12 18:31:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/58337b12

8059309: network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root"

The solaris specific code is changed to use the fallback mechanism if the DLPI interface returns an error indicating that the operation is unsupported. In addition, NetworkInterface::getHardwareAddress is changed to always return null for the loopback interface.

Reviewed-by: alanb

! src/java.base/share/classes/java/net/NetworkInterface.java
! src/java.base/unix/native/libnet/NetworkInterface.c
+ test/jdk/java/net/NetworkInterface/NullMacAddress.java

Changeset: 3aceb74a
Author:    Magnus Ihse Bursie 
Date:      2020-03-12 19:40:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3aceb74a

8240947: Change conflicting JVM features from warning to error

Reviewed-by: erikj

! make/autoconf/jvm-features.m4

Changeset: ed8c11e0
Author:    Magnus Ihse Bursie 
Date:      2020-03-12 19:42:06 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ed8c11e0

8149110: Introduce DISABLED_WARNINGS for Java compilation

Reviewed-by: erikj

! make/CompileDemos.gmk
! make/CompileInterimLangtools.gmk
! make/CompileInterimRmic.gmk
! make/CompileJavaModules.gmk
! make/CompileModuleTools.gmk
! make/CompileToolsJdk.gmk
! make/common/JavaCompilation.gmk
! make/common/SetupJavaCompilers.gmk
! make/hotspot/gensrc/GensrcJfr.gmk
! make/hotspot/gensrc/GensrcJvmti.gmk
! make/hotspot/ide/CreateVSProject.gmk
! make/test/BuildFailureHandler.gmk
! make/test/BuildMicrobenchmark.gmk
! make/test/JtregGraalUnit.gmk

Changeset: 36fac8c3
Author:    Magnus Ihse Bursie 
Date:      2020-03-12 19:43:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/36fac8c3

8240950: Missing AC_SUBST after JDK-82408

Reviewed-by: erikj

! make/autoconf/build-performance.m4

Changeset: d5d6dc0c
Author:    Mandy Chung 
Date:      2020-03-12 11:54:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d5d6dc0c

8228336: Refactor native library loading implementation

Reviewed-by: alanb, dholmes

! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/nativeLookup.cpp
- src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java
+ src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/Runtime.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/loader/BootLoader.java
+ src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java
+ src/java.base/share/classes/jdk/internal/loader/NativeLibrary.java
! src/java.base/share/native/libjava/ClassLoader.c
+ src/java.base/share/native/libjava/NativeLibraries.c
- src/java.base/unix/classes/java/lang/ClassLoaderHelper.java
+ src/java.base/unix/classes/jdk/internal/loader/ClassLoaderHelper.java
= src/java.base/windows/classes/jdk/internal/loader/ClassLoaderHelper.java
! test/jdk/java/lang/ClassLoader/LibraryPathProperty.java

Changeset: e9494f21
Author:    Mandy Chung 
Date:      2020-03-12 11:56:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e9494f21

8240242: improve the javadoc for Lookup::dropLookupModes w.r.t. dropping UNCONDITIONAL

Reviewed-by: chegar, rriggs

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java

Changeset: e30b89e1
Author:    Junyuan Zheng 
Committer: Erik Joelsson 
Date:      2020-03-12 12:55:19 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e30b89e1

8240972: macOS codesign fail on macOS 10.13.5 or older

Reviewed-by: erikj, ihse

! make/autoconf/basic_tools.m4

Changeset: 5bc78c43
Author:    Jonathan Gibbons 
Date:      2020-03-12 13:56:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5bc78c43

8240971: Fix CSS styles in some doc comments

Reviewed-by: mchung

! src/java.base/share/classes/module-info.java
! src/java.management.rmi/share/classes/module-info.java
! src/java.se/share/classes/module-info.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! src/jdk.jconsole/share/classes/module-info.java

Changeset: 2eaeb206
Author:    Jonathan Gibbons 
Date:      2020-03-12 14:14:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2eaeb206

8240555: Using env of JAVA_TOOL_OPTIONS and _JAVA_OPTIONS breaks QuietOption.java test

Reviewed-by: shurailine, prappo

! test/langtools/jdk/javadoc/tool/QuietOption.java

Changeset: 0610992a
Author:    Valerie Peng 
Date:      2020-03-12 22:11:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0610992a

8238566: java.security.Provider$Service.supportsParameter() is racy

Use double-checked-locking pattern inside the hasKeyAttributes() method

Reviewed-by: xuelei

! src/java.base/share/classes/java/security/Provider.java

Changeset: 38940d16
Author:    Calvin Cheung 
Date:      2020-03-12 16:05:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/38940d16

8238000: Crash in ClassLoader::record_result while dynamic dumping netty

Make a copy of the _shared_path_table for use during dynamic CDS dump.

Reviewed-by: iklam, minqi

! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/filemap.hpp
! src/hotspot/share/memory/metaspaceShared.cpp

Changeset: a8b48018
Author:    Jie Fu 
Date:      2020-03-13 17:01:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a8b48018

8240846: Zero VM is broken after JDK-8238681: UseSSE not defined

Reviewed-by: shade, rehn, vlivanov

! src/hotspot/share/compiler/compileBroker.cpp

Changeset: 2a35bc5a
Author:    Roland Westrelin 
Date:      2020-03-11 10:32:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2a35bc5a

8240854: [REDO] some jaotc failures of fastdebug build with specific flags

Reviewed-by: vlivanov, kvn, thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/subtypenode.cpp
+ test/hotspot/jtreg/compiler/types/TestSubTypeOfAsbtractClassWrongResult.java

Changeset: 05c539c9
Author:    Weijun Wang 
Date:      2020-03-13 17:45:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/05c539c9

8240980: Backout JDK-8240261

Reviewed-by: dholmes

! make/gensrc/Gensrc-java.base.gmk
! make/jdk/src/classes/build/tools/intpoly/FieldGen.java
+ make/jdk/src/classes/build/tools/intpoly/header.txt
- make/jdk/src/classes/build/tools/util/Header.java

Changeset: 5a68ba13
Author:    Ivan Walulya 
Date:      2020-03-13 11:54:47 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5a68ba13

8240591: G1HeapSizingPolicy attempts to compute expansion_amount even when at full capacity

Reviewed-by: sjohanss, tschatzl

! src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp

Changeset: 5ed80778
Author:    Aditya Mandaleeka 
Committer: Aleksey Shipilev 
Date:      2020-03-13 13:22:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5ed80778

8231668: Remove ForceDynamicNumberOfGCThreads

Reviewed-by: shade, tschatzl

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shared/workerPolicy.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! test/hotspot/jtreg/gc/ergonomics/TestDynamicNumberOfGCThreads.java
! test/hotspot/jtreg/gc/shenandoah/TestGCThreadGroups.java

Changeset: 9d502f64
Author:    Weijun Wang 
Date:      2020-03-13 21:32:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9d502f64

8240983: Incorrect copyright header in Apache Santuario files

Reviewed-by: mullan

! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java
! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java
! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java
! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java
! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java

Changeset: 9e945720
Author:    Per Lid?n 
Date:      2020-03-13 14:26:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9e945720

8240714: ZGC: TestSmallHeap.java failed due to OutOfMemoryError

Reviewed-by: eosterlund

! test/hotspot/jtreg/gc/z/TestSmallHeap.java

Changeset: afbe2286
Author:    Vicente Romero 
Date:      2020-03-13 10:29:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/afbe2286

8239447: compiler error for annotations applied to record components with target METHOD

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/langtools/tools/javac/processing/model/element/ErrorOnAnnoWithTargetMethod.java

Changeset: 37629673
Author:    Claes Redestad 
Date:      2020-03-13 15:59:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/37629673

8241006: Cleanup TemplateInterpreter initialization

Reviewed-by: coleenp

! src/hotspot/share/interpreter/abstractInterpreter.cpp
! src/hotspot/share/interpreter/templateInterpreter.cpp
! src/hotspot/share/interpreter/templateTable.cpp
! src/hotspot/share/interpreter/templateTable.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/runtime/init.cpp

Changeset: 2b465b1e
Author:    Claes Redestad 
Date:      2020-03-13 18:43:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2b465b1e

8241010: Unnecessarily resolving some well-known classes

Reviewed-by: coleenp

! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/prims/stackwalk.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/services/diagnosticCommand.cpp

Changeset: afa54b7e
Author:    Jonathan Gibbons 
Date:      2020-03-13 10:57:41 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/afa54b7e

8240916: Convert to using hyphenated naming for CSS classes

Reviewed-by: hannesw

! make/jdk/src/classes/build/tools/taglet/ModuleGraph.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java
! test/langtools/jdk/javadoc/doclet/constantValues/TestConstantValuesDriver.java
! test/langtools/jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java
! test/langtools/jdk/javadoc/doclet/testAnchorNames/TestAnchorNames.java
! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java
! test/langtools/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java
! test/langtools/jdk/javadoc/doclet/testClassLinks/TestClassLinks.java
! test/langtools/jdk/javadoc/doclet/testClassTree/TestClassTree.java
! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/langtools/jdk/javadoc/doclet/testDocRootInlineTag/TestDocRootInlineTag.java
! test/langtools/jdk/javadoc/doclet/testExternalOverriddenMethod/TestExternalOverriddenMethod.java
! test/langtools/jdk/javadoc/doclet/testGroupName/TestGroupName.java
! test/langtools/jdk/javadoc/doclet/testHeadings/TestHeadings.java
! test/langtools/jdk/javadoc/doclet/testHiddenTag/TestHiddenTag.java
! test/langtools/jdk/javadoc/doclet/testHref/TestHref.java
! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java
! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java
! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java
! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java
! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java
! test/langtools/jdk/javadoc/doclet/testIndentation/TestIndentation.java
! test/langtools/jdk/javadoc/doclet/testIndex/TestIndex.java
! test/langtools/jdk/javadoc/doclet/testIndexInDocFiles/TestIndexInDocFiles.java
! test/langtools/jdk/javadoc/doclet/testIndexInPackageFiles/TestIndexInPackageFiles.java
! test/langtools/jdk/javadoc/doclet/testIndexTaglet/TestIndexTaglet.java
! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java
! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java
! test/langtools/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithAutomaticModule.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithModule.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestOptionOrder.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java
! test/langtools/jdk/javadoc/doclet/testLinkToSerialForm/TestLinkToSerialForm.java
! test/langtools/jdk/javadoc/doclet/testLinksWithNoDeprecatedOption/TestLinksWithNoDeprecatedOption.java
! test/langtools/jdk/javadoc/doclet/testLiteralCodeInPre/TestLiteralCodeInPre.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java
! test/langtools/jdk/javadoc/doclet/testMethodSignature/TestMethodSignature.java
! test/langtools/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java
! test/langtools/jdk/javadoc/doclet/testModifierEx/TestModifierEx.java
! test/langtools/jdk/javadoc/doclet/testModules/TestIndirectExportsOpens.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModulePackages.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServices.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java
! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java
! test/langtools/jdk/javadoc/doclet/testOrdering/TestOrdering.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestBadOverride.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenDeprecatedMethods.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenMethodDocCopy.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java
! test/langtools/jdk/javadoc/doclet/testPackageAnnotation/TestPackageAnnotation.java
! test/langtools/jdk/javadoc/doclet/testPackageDeprecation/TestPackageDeprecation.java
! test/langtools/jdk/javadoc/doclet/testPackageDescription/TestPackageDescription.java
! test/langtools/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java
! test/langtools/jdk/javadoc/doclet/testPackageSummary/TestPackageSummary.java
! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java
! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java
! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java
! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java
! test/langtools/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java
! test/langtools/jdk/javadoc/doclet/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java
! test/langtools/jdk/javadoc/doclet/testSerializedFormWithClassFile/TestSerializedFormWithClassFile.java
! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java
! test/langtools/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java
! test/langtools/jdk/javadoc/doclet/testSummaryTag/TestSummaryTag.java
! test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/TestSystemPropertyPage.java
! test/langtools/jdk/javadoc/doclet/testSystemPropertyTaglet/TestSystemPropertyTaglet.java
! test/langtools/jdk/javadoc/doclet/testTagOutput/TestTagOutput.java
! test/langtools/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java
! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java
! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java
! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java
! test/langtools/jdk/javadoc/doclet/testUseOption/TestUseOption.java
! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTagInModule.java
! test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java

Changeset: c7e4b2af
Author:    Joe Wang 
Date:      2020-03-13 19:15:32 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c7e4b2af

8240982: Incorrect copyright header in BCEL 6.4.1 sources

Reviewed-by: naoto, lancea

! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java
! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java
! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java

Changeset: 3aeb2d1a
Author:    Alex Menkov 
Date:      2020-03-13 12:25:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3aeb2d1a

8217441: Failure of ::realloc() should be handled correctly in sawindbg.cpp

Reviewed-by: cjplummer, sspitsyn

! src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp

Changeset: 6ead9056
Author:    Kim Barrett 
Date:      2020-03-13 15:36:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6ead9056

8239825: G1: Simplify threshold test for mutator refinement

Compute refinement threshold when values change, not on each use.

Reviewed-by: tschatzl, sangheki

! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp

Changeset: b0194692
Author:    Joe Darcy 
Date:      2020-03-14 09:53:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b0194692

8240130: Improve and update discussion of visitor evolution warnings

Reviewed-by: jjg

! src/java.compiler/share/classes/javax/lang/model/element/AnnotationValueVisitor.java
! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java
! src/java.compiler/share/classes/javax/lang/model/type/TypeVisitor.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor8.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor8.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner6.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner7.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner8.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor8.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor8.java
! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java

Changeset: f819e417
Author:    Vicente Romero 
Date:      2020-03-14 17:08:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f819e417

8235339: test TargetAnnoCombo.java is failing after new target RECORD_COMPONENT was added

Reviewed-by: darcy

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! test/langtools/ProblemList.txt
! test/langtools/tools/javac/annotations/repeatingAnnotations/combo/Helper.java
! test/langtools/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java

Changeset: 4b978533
Author:    Nick Gasson 
Date:      2020-03-16 10:51:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4b978533

8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1

Reviewed-by: aph

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp

Changeset: 95898e86
Author:    David Holmes 
Date:      2020-03-16 02:16:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/95898e86

8241043: Expand assertions to identify thread with errant _stack_base

Reviewed-by: mikael

! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: 6ddb0f2b
Author:    Jan Lahoda 
Date:      2020-03-16 13:06:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6ddb0f2b

8240964: Compilation error thrown when long literal used with yield

Ensuring yield followed by a long literal is recognized as a yield statement.

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/langtools/tools/javac/switchexpr/ExpressionSwitch.java

Changeset: 21cd75cb
Author:    Erik ?sterlund 
Date:      2020-03-16 12:27:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/21cd75cb

8240363: Refactor Compile::Output() to its own Phase

Reviewed-by: kvn, vlivanov

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/s390/compiledIC_s390.cpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/sparc/sparc.ad
! src/hotspot/cpu/x86/c2_intelJccErratum_x86.cpp
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/adlparse.cpp
! src/hotspot/share/adlc/main.cpp
! src/hotspot/share/adlc/output_c.cpp
! src/hotspot/share/compiler/compileBroker.hpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
! src/hotspot/share/opto/buildOopMap.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/chaitin.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
+ src/hotspot/share/opto/constantTable.cpp
+ src/hotspot/share/opto/constantTable.hpp
! src/hotspot/share/opto/machnode.cpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/output.hpp
! src/hotspot/share/opto/phase.hpp
! src/hotspot/share/opto/runtime.cpp

Changeset: e746891f
Author:    Jie Fu 
Date:      2020-03-16 22:43:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e746891f

8241034: Fix a configuring error with "-Xmx2048M: command not found"

Reviewed-by: mikael, erikj

! make/autoconf/build-performance.m4

Changeset: 2b4b3d9e
Author:    Naoto Sato 
Date:      2020-03-16 09:26:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2b4b3d9e

8240626: Some of the java.time.chrono.Eras return empty display name for some styles and locales

Reviewed-by: joehw

! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java
! test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java

Changeset: 19536121
Author:    Andrew Haley 
Date:      2020-03-16 17:10:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/19536121

8241018: 32-bit integer log2 functions return the wrong value for negative arguments on 64-bit machines

Reviewed-by: kvn

! src/hotspot/share/utilities/globalDefinitions.hpp
! test/hotspot/gtest/utilities/test_globalDefinitions.cpp

Changeset: 8b739002
Author:    Erik ?sterlund 
Date:      2020-03-16 17:13:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8b739002

8241074: JDK-8240363 broke the build on AArch64

Reviewed-by: shade

! src/hotspot/share/opto/constantTable.cpp

Changeset: b4ff6abe
Author:    Zhengyu Gu 
Date:      2020-02-25 12:01:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b4ff6abe

8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata

Reviewed-by: rkennke, shade

! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp

Changeset: 6f7a103a
Author:    Matthias Baesken 
Date:      2020-03-17 08:53:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6f7a103a

8240824: enhance print_full_memory_info on Linux by THP related information

Reviewed-by: dholmes, stuefe

! src/hotspot/os/linux/os_linux.cpp

Changeset: dbd0f0dc
Author:    Claes Redestad 
Date:      2020-03-17 09:36:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/dbd0f0dc

8241077: x86_64: Minor Assembler improvements

Reviewed-by: kvn

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp

Changeset: 035100cc
Author:    Roman Kennke 
Date:      2020-03-17 11:49:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/035100cc

8241081: Shenandoah: Do not modify update-watermark concurrently

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp

Changeset: 1a099598
Author:    Andrew Haley 
Date:      2020-03-17 14:13:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1a099598

Merge


Changeset: ec5bd021
Author:    Vladimir Kozlov 
Date:      2020-03-17 10:38:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ec5bd021

8240976: [JVMCI] MethodProfileWidth flag is broken

Remove JVMCI code which is not used

Reviewed-by: thartmann, redestad

! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/sparc/interp_masm_sparc.cpp
! src/hotspot/cpu/sparc/interp_masm_sparc.hpp
! src/hotspot/cpu/sparc/templateTable_sparc.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.hpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/jvmci_globals.cpp
! src/hotspot/share/jvmci/jvmci_globals.hpp
! src/hotspot/share/oops/methodData.cpp
! src/hotspot/share/oops/methodData.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java

Changeset: 17619249
Author:    Claes Redestad 
Date:      2020-03-05 16:07:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/17619249

8241042: x86_64: Improve Assembler generation

Reviewed-by: vlivanov, kvn

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/share/asm/assembler.hpp
! src/hotspot/share/asm/codeBuffer.hpp

Changeset: 6083173f
Author:    Vladimir Kozlov 
Date:      2020-03-17 12:42:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6083173f

8237045: JVM uses excessive memory with -XX:+EnableJVMCI -XX:JVMCICounterSize=2147483648

Limit JVMCICounterSize flag's value range to 1M

Reviewed-by: thartmann, redestad

! src/hotspot/share/jvmci/jvmci_globals.hpp
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java

Changeset: c003fffd
Author:    Charlie Gracie 
Committer: Vladimir Kozlov 
Date:      2020-03-17 14:05:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c003fffd

8241122: Remove unimplemented InlineTree constructor definition from parse.hpp

Reviewed-by: kvn

! src/hotspot/share/opto/parse.hpp

Changeset: f959b012
Author:    David Holmes 
Date:      2020-03-17 19:57:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f959b012

8239593: Bogus warning "Re-registering of platform native method" for a JVMTI agent

Reviewed-by: dcubed, alanb, hseigel

! src/hotspot/share/prims/jni.cpp

Changeset: 94a6149d
Author:    David Holmes 
Date:      2020-03-17 20:54:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/94a6149d

8241124: Aarch64 build broken by JDK-8239593

Reviewed-by: mikael

! src/hotspot/share/prims/jni.cpp

Changeset: a1476361
Author:    Chris Plummer 
Date:      2020-03-17 18:04:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a1476361

8238268: Many SA tests are not running on OSX because they do not attempt to use sudo when available

Reviewed-by: sspitsyn, iignatyev

! test/hotspot/jtreg/TEST.ROOT
! test/hotspot/jtreg/compiler/ciReplay/TestSAClient.java
! test/hotspot/jtreg/compiler/ciReplay/TestSAServer.java
! test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java
! test/hotspot/jtreg/resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java
! test/hotspot/jtreg/serviceability/sa/CDSJMapClstats.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbJstackXcompStress.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java
! test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java
! test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java
! test/hotspot/jtreg/serviceability/sa/TestClassDump.java
! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java
! test/hotspot/jtreg/serviceability/sa/TestCpoolForInvokeDynamic.java
! test/hotspot/jtreg/serviceability/sa/TestDefaultMethods.java
! test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java
! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java
! test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSize.java
! test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSizeForInterface.java
! test/hotspot/jtreg/serviceability/sa/TestIntConstant.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java
! test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java
! test/hotspot/jtreg/serviceability/sa/TestRevPtrsForInvokeDynamic.java
! test/hotspot/jtreg/serviceability/sa/TestType.java
! test/hotspot/jtreg/serviceability/sa/TestUniverse.java
! test/hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java
! test/hotspot/jtreg/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java
! test/jdk/TEST.ROOT
! test/jdk/sun/tools/jhsdb/BasicLauncherTest.java
! test/jdk/sun/tools/jhsdb/HeapDumpTest.java
! test/jdk/sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
! test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java
! test/jdk/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java
! test/jdk/sun/tools/jhsdb/heapconfig/TmtoolTestScenario.java
! test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
! test/jtreg-ext/requires/VMProps.java
! test/lib/jdk/test/lib/Platform.java
! test/lib/jdk/test/lib/SA/SATestUtils.java

Changeset: 0c9f8e47
Author:    Hai-May Chao 
Committer: Weijun Wang 
Date:      2020-03-18 09:23:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0c9f8e47

8186143: keytool -ext option doesn't accept wildcards for DNS subject alternative names

Reviewed-by: jnimeh, weijun, mullan

! src/java.base/share/classes/sun/security/tools/keytool/Main.java
! src/java.base/share/classes/sun/security/x509/DNSName.java
! test/jdk/sun/security/x509/GeneralName/DNSNameTest.java

Changeset: e5e24ad0
Author:    Naoto Sato 
Date:      2020-03-17 19:11:10 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e5e24ad0

8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version

Reviewed-by: joehw

! make/data/lsrdata/language-subtag-registry.txt
! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java
! test/jdk/java/util/Locale/Bug8040211.java

Changeset: e827f4ae
Author:    Aleksey Shipilev 
Date:      2020-03-18 06:28:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e827f4ae

8241093: Shenandoah: editorial changes in flag descriptions

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: 1d4a4fed
Author:    Ivan Gerasimov 
Date:      2020-03-18 01:04:22 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1d4a4fed

8214245: Case insensitive matching doesn't work correctly for some character classes

Reviewed-by: rriggs, darcy

! src/java.base/share/classes/java/util/regex/CharPredicates.java
! src/java.base/share/classes/java/util/regex/Pattern.java
! test/jdk/java/util/regex/RegExTest.java

Changeset: d76b0cf7
Author:    Ichiroh Takiguchi 
Date:      2020-03-18 18:04:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d76b0cf7

8232161: Align some one-way conversion in MS950 charset with Windows

MS950 charset encoder's conversion table is changed

Reviewed-by: naoto

! make/data/charsetmapping/MS950.map
! make/data/charsetmapping/MS950.nr
+ test/jdk/sun/nio/cs/TestMS950.java

Changeset: abc56193
Author:    Jesper Wilhelmsson 
Date:      2020-03-18 10:34:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/abc56193

Added tag jdk-14-ga for changeset bc54620a3848

! .hgtags

Changeset: efb25e51
Author:    Jesper Wilhelmsson 
Date:      2020-03-18 10:41:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/efb25e51

Merge

! .hgtags
! .hgtags

Changeset: f2fb5c54
Author:    Tony Printezis 
Committer: Markus Gr?nlund 
Date:      2020-03-18 12:00:19 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f2fb5c54

8239497: SEGV in EdgeUtils::field_name_symbol(Edge const&)

Reviewed-by: egahlin, tonyp

! src/hotspot/share/jfr/leakprofiler/chains/edge.cpp
! src/hotspot/share/jfr/leakprofiler/chains/edge.hpp
! src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp
! src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.hpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp
! src/hotspot/share/oops/instanceMirrorKlass.hpp

Changeset: 0ee74979
Author:    Mikhailo Seledtsov 
Date:      2020-03-18 09:45:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0ee74979

8241033: Create test library utility for getting JFR streaming repository

New method to get JFR streaming repo path

Reviewed-by: egahlin, mgronlun

! test/jdk/jdk/jfr/api/consumer/streaming/TestCrossProcessStreaming.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestProcess.java
+ test/lib/jdk/test/lib/jfr/StreamingUtils.java

Changeset: 1170981e
Author:    Chris Plummer 
Date:      2020-03-18 10:14:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1170981e

8240906: Update ZGC ProblemList for serviceability/sa/TestJmapCoreMetaspace.java

Reviewed-by: stefank

! test/hotspot/jtreg/ProblemList-zgc.txt

Changeset: c6cec8a8
Author:    Chris Plummer 
Date:      2020-03-18 10:42:32 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c6cec8a8

8227340: Modify problem list entry for javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java

Reviewed-by: dholmes

! test/jdk/ProblemList.txt

Changeset: b70ef0d2
Author:    Daniil Titov 
Date:      2020-03-18 11:05:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b70ef0d2

8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:"

Reviewed-by: amenkov

! test/jdk/sun/tools/jstatd/JstatdTest.java

Changeset: 700f50f2
Author:    Aleksey Shipilev 
Date:      2020-03-18 19:24:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/700f50f2

8241128: x86_32 build failure after JDK-8241042

Reviewed-by: redestad, kvn

! src/hotspot/cpu/x86/assembler_x86.cpp

Changeset: bf54c474
Author:    Vicente Romero 
Date:      2020-03-18 14:33:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/bf54c474

8240970: Some tests fail when run with JCov

Reviewed-by: jjg

! test/langtools/tools/javac/EarlyAssertWrapper.java
! test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java
! test/langtools/tools/javac/launcher/SourceLauncherTest.java
! test/langtools/tools/javac/modules/RequiresStaticTest.java
! test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java
! test/langtools/tools/javac/platform/PlatformProviderTest.java
! test/langtools/tools/jdeps/modules/CheckModuleTest.java

Changeset: 34b9ac22
Author:    Doug Simon 
Date:      2020-03-18 13:11:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/34b9ac22

8236285: [JVMCI] improve TranslatedException traces

Reviewed-by: never, kvn

! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/TranslatedException.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/TestTranslatedException.java

Changeset: ea367322
Author:    Jonathan Gibbons 
Date:      2020-03-18 13:20:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ea367322

8241030: rename HtmlTag to TagName

Reviewed-by: prappo

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Headings.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialMethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTag.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Script.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/TableHeader.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/TagName.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/package-info.java
! test/langtools/jdk/javadoc/doclet/testHtmlDocument/TestHtmlDocument.java

Changeset: 9fe762d3
Author:    Chris Plummer 
Date:      2020-03-18 13:24:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9fe762d3

8241162: ProblemList serviceability/sa/TestHeapDumpForInvokeDynamic.java on OSX

Reviewed-by: dcubed

! test/hotspot/jtreg/ProblemList.txt

Changeset: af28093e
Author:    Jonathan Gibbons 
Date:      2020-03-18 13:29:02 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/af28093e

Merge


Changeset: 9d7f8bc9
Author:    Rafael Winterhalter 
Date:      2020-03-18 17:07:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9d7f8bc9

8202469: (ann) Type annotations on type variable bounds that are also type variables are lost

Reviewed-by: jfranck

! src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java
+ test/jdk/java/lang/annotation/typeAnnotations/ParameterizedBoundIndex.java

Changeset: 44eca823
Author:    Andrew M Leonard 
Committer: Andrew Leonard 
Date:      2020-03-17 14:14:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/44eca823

8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings

Reviewed-by: bpb, bchristi

! test/jdk/java/math/BigInteger/largeMemory/SymmetricRangeTests.java

Changeset: 99546049
Author:    Matthias Neugschwandtner 
Date:      2020-03-18 15:59:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/99546049

8235908: omit ThreadPriorityPolicy warning when value is set from image

Reviewed-by: dholmes, clanger, kvn

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/share/runtime/flags/jvmFlag.cpp
! src/hotspot/share/runtime/flags/jvmFlag.hpp
! src/hotspot/share/runtime/globals_extension.hpp

Changeset: c7c8623e
Author:    Jesper Wilhelmsson 
Date:      2020-03-19 03:03:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c7c8623e

Added tag jdk-15+15 for changeset 82b7c62cf4cc

! .hgtags

Changeset: 599af2ac
Author:    Chris Yin 
Date:      2020-03-19 11:07:36 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/599af2ac

8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset

Reviewed-by: dfuchs, vtewari

! test/jdk/com/sun/jndi/ldap/RemoveNamingListenerTest.java

Changeset: f1c919f2
Author:    Igor Veresov 
Date:      2020-03-18 21:49:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f1c919f2

8230290: [JVMCI] Remove unused API entry points

Remove VirtualObject.setIsAutoBox()

Reviewed-by: kvn

! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualObject.java

Changeset: cadfc3d5
Author:    Matthias Baesken 
Date:      2020-03-16 15:11:02 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cadfc3d5

8241064: JFR related tests TestMetaspaceAllocationFailure.java and TestEventInstrumentation.java miss requires tag

Reviewed-by: mseledtsov, mgronlun

! test/jdk/jdk/jfr/event/runtime/TestMetaspaceAllocationFailure.java
! test/jdk/jdk/jfr/javaagent/TestEventInstrumentation.java

Changeset: dd63eec6
Author:    Jie Fu 
Date:      2020-03-19 16:34:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/dd63eec6

8241232: -XX:+BootstrapJVMCI is not compatible with TieredStopAtLevel < CompLevel_full_optimization

Reviewed-by: kvn, thartmann

! src/hotspot/share/jvmci/jvmci_globals.cpp
+ test/hotspot/jtreg/compiler/jvmci/errors/TestInvalidTieredStopAtLevel.java

Changeset: a51dd58f
Author:    Christian Hagedorn 
Date:      2020-03-19 10:15:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a51dd58f

8240227: Loop predicates should be copied to unswitched loops

Copy loop range check predicates to unswitched loops and update their control edges.

Reviewed-by: kvn, neliasso, thartmann, roland

! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/idealKit.cpp
! src/hotspot/share/opto/loopPredicate.cpp
! src/hotspot/share/opto/loopUnswitch.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/phaseX.hpp
! src/hotspot/share/opto/stringopts.cpp
! test/hotspot/jtreg/compiler/loopopts/PartialPeelingUnswitch.java
+ test/hotspot/jtreg/compiler/loopopts/TestUnswitchOverunrolling.java

Changeset: cc9470ec
Author:    Claes Redestad 
Date:      2020-03-05 16:07:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cc9470ec

8241095: x86: Improve prefix handling in Assembler

Reviewed-by: kvn, thartmann

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp

Changeset: cd7d1750
Author:    Alexander Scherbatiy 
Date:      2020-03-19 14:58:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cd7d1750

8240604: Rewrite sun/management/jmxremote/bootstrap/CustomLauncherTest.java test to make binaries from source file

Reviewed-by: iignatyev

! make/test/JtregNativeJdk.gmk
! test/jdk/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
- test/jdk/sun/management/jmxremote/bootstrap/Makefile
+ test/jdk/sun/management/jmxremote/bootstrap/exelauncher.c
- test/jdk/sun/management/jmxremote/bootstrap/launcher.c
- test/jdk/sun/management/jmxremote/bootstrap/linux-amd64/launcher
- test/jdk/sun/management/jmxremote/bootstrap/linux-i586/launcher
- test/jdk/sun/management/jmxremote/bootstrap/solaris-amd64/launcher
- test/jdk/sun/management/jmxremote/bootstrap/solaris-sparcv9/launcher

Changeset: fa069be2
Author:    Kiran Sidhartha Ravikumar 
Date:      2020-03-13 18:38:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/fa069be2

8161558: ListIterator should not discard cause on exception

Reviewed-by: smarks

! src/java.base/share/classes/java/util/AbstractList.java
! src/java.base/share/classes/java/util/NoSuchElementException.java
+ test/jdk/java/util/AbstractList/CheckForIndexOutOfBoundsException.java

Changeset: e2947fe9
Author:    Stefan Karlsson 
Date:      2020-03-19 14:15:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e2947fe9

8240773: JFR: Non-Java threads are not serialized

Reviewed-by: mgronlun

! src/hotspot/share/jfr/utilities/jfrThreadIterator.cpp

Changeset: b4e85913
Author:    Stefan Karlsson 
Date:      2020-03-19 14:16:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b4e85913

8240819: Assign a name to the JfrThreadSampler thread

Reviewed-by: mgronlun

! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp

Changeset: 5695e59a
Author:    Stefan Karlsson 
Date:      2020-03-19 14:17:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5695e59a

8240818: Remove colon from "JFR: Shutdown Hook" thread name

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java

Changeset: d3bf9150
Author:    Stefan Karlsson 
Date:      2020-03-19 14:18:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d3bf9150

8241263: JFR: Bump native events limit

Reviewed-by: mgronlun, egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java

Changeset: 9dc15f17
Author:    Magnus Ihse Bursie 
Date:      2020-03-19 17:17:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9dc15f17

8241254: Simplify usage of UTIL_DEPRECATED_ARG_ENABLE

Reviewed-by: erikj

! make/autoconf/util.m4

Changeset: 029fea43
Author:    Chris Plummer 
Date:      2020-03-19 10:20:45 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/029fea43

8240543: Update problem list entry for serviceability/sa/TestRevPtrsForInvokeDynamic.java to reference JDK-8241235

Reviewed-by: dholmes

! test/hotspot/jtreg/ProblemList.txt

Changeset: 32cba672
Author:    Jonathan Gibbons 
Date:      2020-03-19 11:25:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/32cba672

8240476: SystemPropertiesWriter does not conform to standard page layout

Reviewed-by: prappo

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java
! test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/TestSystemPropertyPage.java

Changeset: 66c8794c
Author:    Evgeny Nikitin 
Committer: Igor Ignatyev 
Date:      2020-03-17 21:35:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/66c8794c

8168304: Make all of DependencyContext_test available in product mode

Enable the utility inspection function `DependencyContext::is_dependent_method` and therefore the test in the product mode.

Reviewed-by: eosterlund, thartmann

! src/hotspot/share/code/dependencyContext.cpp
! src/hotspot/share/code/dependencyContext.hpp
! test/hotspot/gtest/code/test_dependencyContext.cpp

Changeset: caa08844
Author:    Roger Riggs 
Date:      2020-03-19 15:34:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/caa08844

8241073: Pre-generated Stubs for javax.management, Activation, Naming

Reviewed-by: erikj, ihse, alanb, dfuchs

- make/CompileInterimRmic.gmk
! make/Docs.gmk
! make/Global.gmk
! make/Main.gmk
! make/ZipSource.gmk
! make/autoconf/spec.gmk.in
- make/common/RMICompilation.gmk
! make/jdk/netbeans/jmx/build.xml
- make/rmic/Rmic-java.management.rmi.gmk
- make/rmic/Rmic-java.rmi.gmk
- make/rmic/Rmic-jdk.naming.rmi.gmk
- make/rmic/RmicCommon.gmk
+ src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.java
+ src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIServerImpl_Stub.java
+ src/java.rmi/share/classes/java/rmi/activation/ActivationGroup_Stub.java
+ src/java.rmi/share/classes/sun/rmi/server/Activation$ActivationSystemImpl_Stub.java
- src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.java
+ src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/ReferenceWrapper_Stub.java

Changeset: 4f629193
Author:    Dean Long 
Date:      2020-03-19 12:29:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4f629193

8241231: Update Graal

Reviewed-by: kvn

! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CallInfo.java
! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MarkId.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.sparc/src/org/graalvm/compiler/asm/sparc/SPARCAssembler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64LIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/Fields.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CheckGraalInvariants.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/OptionsVerifierTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/LIRGenerationPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/NodeLIRBuilder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/Node.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeClass.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackend.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackendFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLoweringProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotBackendFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotLoweringProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotPatchReturnAddressOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotBackendFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotLoweringProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompilationWrapperTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/NodeCostDumpUtil.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotReplacementsImpl.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/SymbolicSnippetEncoder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotPlatformConfigurationProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/EndLockScopeNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/UnsafeCopyMemoryNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/UnsafeLoadSnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/LambdaUtils.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/hotspot/Test6196102.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/hotspot/Test6753639.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/hotspot/Test6823354.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/hotspot/Test6850611.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/hotspot/Test7005594.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64FrameMap.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/CompositeValueClass.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/LIRInstructionClass.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/LIRIntrospection.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/framemap/FrameMap.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/LIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/LIRGeneratorTool.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/MemoryProxyNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ProxyNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/StructuredGraph.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ValueNodeUtil.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/BytecodeExceptionNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/MonitorExit.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/gc/BarrierSet.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/gc/CardTableBarrierSet.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/gc/G1BarrierSet.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/UnsafeCompareAndSwapNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/FixedAccessNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/FloatingReadNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryAccess.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryAnchorNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryKill.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryMap.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryMapNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryPhiNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MultiMemoryKill.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/SingleMemoryKill.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/MemoryEdgeProxy.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/MemoryProxy.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/NodeLIRBuilderTool.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionDescriptorsMap.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionValues.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/FloatingReadPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/LoweringPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/ScheduleVerification.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64ArrayIndexOfDispatchNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64ArrayIndexOfNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64StringLatin1InflateNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64StringUTF16CompressNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/SubstitutionsTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/DefaultJavaLoweringProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/SnippetLowerableMemoryNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/SnippetTemplate.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyCallNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopySnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ArrayCompareToNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ArrayEqualsNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ArrayRegionEqualsNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/BasicArrayCopyNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ReadRegisterNode.java

Changeset: b8a2b201
Author:    Kim Barrett 
Date:      2020-03-19 18:11:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b8a2b201

8139652: Mutator refinement processing should take the oldest dirty card buffer

Changed mutator refinement to take from queue rather than in-place and reuse.

Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp

Changeset: 3f698242
Author:    Patricio Chilano Mateo 
Date:      2020-03-20 00:32:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3f698242

8240902: JDI shared memory connector can use already closed Handles

Add refcount to keep track of connection access

Reviewed-by: dholmes, dcubed, sspitsyn

! src/jdk.jdi/share/native/libdt_shmem/shmemBase.c

Changeset: 7ded8b1e
Author:    Chris Yin 
Date:      2020-03-20 10:24:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7ded8b1e

8241130: com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException

Reviewed-by: dfuchs

! src/java.naming/share/classes/com/sun/jndi/ldap/EventSupport.java
! test/jdk/com/sun/jndi/ldap/RemoveNamingListenerTest.java

Changeset: 104927e5
Author:    Chris Plummer 
Date:      2020-03-19 21:32:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/104927e5

8241335: ProblemList serviceability/sa/ClhsdbPstack.java due to JDK-8240956

Reviewed-by: mikael

! test/hotspot/jtreg/ProblemList.txt

Changeset: 333a832c
Author:    Kim Barrett 
Date:      2020-03-20 01:20:37 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/333a832c

8241001: Improve logging in the ConcurrentGCBreakpoint mechanism

Demoted most breakpoint logging to trace level.

Reviewed-by: pliden, sjohanss

! src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp
! src/hotspot/share/logging/logPrefix.hpp

Changeset: e7204cbc
Author:    Leonid Mesnik 
Date:      2020-03-20 00:24:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e7204cbc

8241123: Refactor vmTestbase stress framework to use j.u.c and make creation of threads more flexible

Reviewed-by: iignatyev, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects003/referringObjects003a.java
! test/hotspot/jtreg/vmTestbase/nsk/share/Wicket.java
! test/hotspot/jtreg/vmTestbase/nsk/share/runner/ThreadsRunner.java

Changeset: cc83c455
Author:    Thomas Schatzl 
Date:      2020-03-20 11:17:45 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cc83c455

8240590: Add MemRegion::destroy_array to complement introduced create_array

Reviewed-by: lkorinth, sjohanss

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/shared/cardTable.cpp
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/memRegion.cpp
! src/hotspot/share/memory/memRegion.hpp

Changeset: 95d28303
Author:    Jia Huang 
Date:      2020-03-20 18:52:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/95d28303

8240222: [TESTBUG] gtest/jfr/test_networkUtilization.cpp failed when the number of tests is greater than or equal to 2

Reviewed-by: egahlin, mgronlun

! test/hotspot/gtest/jfr/test_networkUtilization.cpp

Changeset: 6dffcf75
Author:    Coleen Phillimore 
Date:      2020-03-20 07:30:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6dffcf75

8241320: The ClassLoaderData::_is_unsafe_anonymous field is unused in the SA

Remove unused code that is changing in Hotspot for hidden classes.

Reviewed-by: lfoltan, dholmes, sspitsyn

! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java

Changeset: 136a1574
Author:    Jamsheed Mohammed C M 
Date:      2020-03-20 05:19:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/136a1574

8237894: CTW: C1 compilation fails with assert(x->type()->tag() == f->type()->tag()) failed: should have same type

Field access instructions hash decalred_type in addition, indexed access instructions hash value type of the instruction in addition.

Reviewed-by: thartmann, shade

! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_Instruction.hpp
+ test/hotspot/jtreg/compiler/c1/TestValueNumberingNullObject.java

Changeset: 34ae46e2
Author:    Andrew Haley 
Date:      2020-03-19 14:53:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/34ae46e2

8241296: Segfault in JNIHandleBlock::oops_do()

Reviewed-by: stefank

! src/hotspot/share/runtime/thread.cpp

Changeset: c9faf88c
Author:    Roland Westrelin 
Date:      2020-03-13 16:32:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c9faf88c

8240795: [REDO] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found"

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/gcm.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/type.hpp
+ test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java

Changeset: 2288788e
Author:    Andrew Haley 
Date:      2020-03-20 13:08:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2288788e

Merge


Changeset: d243e40f
Author:    Xue-Lei Andrew Fan 
Date:      2020-03-20 09:15:00 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d243e40f

8241039: Retire the deprecated SSLSession.getPeerCertificateChain() method

Reviewed-by: mullan, alanb, dfuchs

- src/java.base/share/classes/com/sun/security/cert/internal/x509/X509V1CertImpl.java
! src/java.base/share/classes/javax/net/ssl/HandshakeCompletedEvent.java
! src/java.base/share/classes/javax/net/ssl/SSLSession.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/java.net.http/share/classes/jdk/internal/net/http/common/ImmutableExtendedSSLSession.java
! src/java.net.http/share/classes/jdk/internal/net/http/common/ImmutableSSLSession.java
! test/jdk/sun/security/ssl/GenSSLConfigs/main.java

Changeset: f67868d9
Author:    Xue-Lei Andrew Fan 
Date:      2020-03-20 09:27:06 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f67868d9

8219989: Retire the com.sun.net.ssl.internal.ssl.Provider name

Remove the provider name in JDK

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/jca/ProviderConfig.java

Changeset: 37b7a233
Author:    Yumin Qi 
Date:      2020-03-20 09:40:30 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/37b7a233

8241009: CommandLineFlagComboNegative.java fails after JDK-8240563

Jtreg turned off UseCompressedOops and messed up vm flag options of children processes.

Reviewed-by: dholmes, stefank

! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagComboNegative.java

Changeset: c5a74908
Author:    Rahul Yadav 
Committer: Patrick Concannon 
Date:      2020-03-20 20:16:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c5a74908

8240921: Minor correction to HttpResponse.BodySubscribers example

The fix updates the incorrect example of the usage of the class java.net.http.HttpResponse.BodySubscribers.

Reviewed-by: chegar, dfuchs, jboes, pconcannon

! src/java.net.http/share/classes/java/net/http/HttpResponse.java
! test/jdk/java/net/httpclient/examples/JavadocExamples.java

Changeset: 17ff85d4
Author:    Pavel Rappo 
Date:      2020-03-20 20:54:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/17ff85d4

8241014: Miscellaneous typos in documentation comments

Reviewed-by: igerasim, prappo, psandoz, rriggs, weijun

! src/java.base/share/classes/java/io/FilePermission.java
! src/java.base/share/classes/java/io/Reader.java
! src/java.base/share/classes/java/lang/Character.java
! src/java.base/share/classes/java/lang/ProcessHandleImpl.java
! src/java.base/share/classes/java/lang/Runtime.java
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDescImpl.java
! src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java
! src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java
! src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
! src/java.base/share/classes/java/lang/constant/ReferenceClassDescImpl.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/java/math/BigDecimal.java
! src/java.base/share/classes/java/net/HttpCookie.java
! src/java.base/share/classes/java/net/MulticastSocket.java
! src/java.base/share/classes/java/nio/file/DirectoryStream.java
! src/java.base/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java
! src/java.base/share/classes/java/security/PKCS12Attribute.java
! src/java.base/share/classes/java/security/SignatureSpi.java
! src/java.base/share/classes/java/text/BreakIterator.java
! src/java.base/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/java.base/share/classes/java/time/chrono/package-info.java
! src/java.base/share/classes/java/time/temporal/TemporalAccessor.java
! src/java.base/share/classes/java/util/Arrays.java
! src/java.base/share/classes/java/util/BitSet.java
! src/java.base/share/classes/java/util/Enumeration.java
! src/java.base/share/classes/java/util/Map.java
! src/java.base/share/classes/java/util/StringJoiner.java
! src/java.base/share/classes/java/util/regex/Pattern.java
! src/java.base/share/classes/java/util/stream/Stream.java
! src/java.base/share/classes/java/util/stream/package-info.java
! src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java
! src/java.base/share/classes/javax/security/cert/X509Certificate.java
! src/java.base/share/classes/jdk/internal/icu/util/VersionInfo.java
! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
! src/java.base/share/classes/sun/security/provider/AbstractDrbg.java
! src/java.base/share/classes/sun/security/provider/PolicyFile.java
! src/java.compiler/share/classes/javax/tools/JavaFileManager.java

Changeset: f778ad2f
Author:    Leonid Mesnik 
Date:      2020-03-20 17:37:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f778ad2f

8241319: WB_GetCodeBlob doesn't have ResourceMark

Reviewed-by: iignatyev, thartmann

! src/hotspot/share/prims/whitebox.cpp

Changeset: ef335c75
Author:    Prasanta Sadhukhan 
Date:      2020-03-22 09:46:15 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ef335c75

Merge

! test/jdk/ProblemList.txt
! test/jdk/ProblemList.txt

Changeset: 36af90ac
Author:    Xue-Lei Andrew Fan 
Date:      2020-03-22 09:30:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/36af90ac

8215712: Parsing extension failure may alert decode_error

Reviewed-by: jnimeh

! src/java.base/share/classes/sun/security/ssl/AlpnExtension.java
! src/java.base/share/classes/sun/security/ssl/CertSignAlgsExtension.java
! src/java.base/share/classes/sun/security/ssl/CertStatusExtension.java
! src/java.base/share/classes/sun/security/ssl/CookieExtension.java
! src/java.base/share/classes/sun/security/ssl/ECPointFormatsExtension.java
! src/java.base/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java
! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java
! src/java.base/share/classes/sun/security/ssl/MaxFragExtension.java
! src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java
! src/java.base/share/classes/sun/security/ssl/PskKeyExchangeModesExtension.java
! src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLExtensions.java
! src/java.base/share/classes/sun/security/ssl/SSLStringizer.java
! src/java.base/share/classes/sun/security/ssl/ServerHello.java
! src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java
! src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java
! src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
! src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java
! src/java.base/share/classes/sun/security/ssl/SupportedVersionsExtension.java
! src/java.base/share/classes/sun/security/ssl/TransportContext.java

Changeset: 618bacec
Author:    Pengfei Li 
Date:      2020-03-23 08:37:45 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/618bacec

8241091: AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction"

Reviewed-by: aph

! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp

Changeset: e04080bd
Author:    Magnus Ihse Bursie 
Date:      2020-03-23 10:26:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e04080bd

8241310: Fix warnings in jdk buildtools

Reviewed-by: erikj, forax

! make/CompileToolsJdk.gmk
! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java
! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
! make/jdk/src/classes/build/tools/cldrconverter/PluralsParseHandler.java
! make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java
! make/jdk/src/classes/build/tools/dtdbuilder/DTDInputStream.java
! make/jdk/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
! make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
! make/jdk/src/classes/build/tools/generatecharacter/CharacterName.java
! make/jdk/src/classes/build/tools/generatecharacter/CharacterScript.java
! make/jdk/src/classes/build/tools/generatecharacter/PrintCharacterRanges.java
! make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java
! make/jdk/src/classes/build/tools/jdwpgen/Parse.java
! make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java
! make/jdk/src/classes/build/tools/x11wrappergen/WrapperGenerator.java

Changeset: 90102935
Author:    Magnus Ihse Bursie 
Date:      2020-03-23 10:29:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/90102935

8241271: Make hotspot build reproducible

Reviewed-by: erikj, stefank, jwilhelm

! make/autoconf/compare.sh.in
! make/autoconf/hotspot.m4
! make/autoconf/spec.gmk.in
! make/conf/jib-profiles.js
! make/hotspot/lib/CompileJvm.gmk
! make/scripts/compare_exceptions.sh.incl
! src/hotspot/share/runtime/abstract_vm_version.cpp

Changeset: ed28a274
Author:    Kelvin Nilsen 
Committer: Aleksey Shipilev 
Date:      2020-03-23 10:37:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ed28a274

8241068: Shenandoah: improve ShenandoahTraversalGC constructor arguments

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.hpp

Changeset: b66c6808
Author:    Daniel Fuchs 
Date:      2020-03-23 14:22:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b66c6808

8241443: Problem list some java.net tests failing with NoRouteToHostException on macOS with special network configuration

Reviewed-by: alanb

! test/jdk/ProblemList.txt

Changeset: 75a8b7fa
Author:    Mandy Chung 
Date:      2020-03-23 09:05:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/75a8b7fa

8240975: Extend NativeLibraries to support explicit unloading

Reviewed-by: alanb, mcimadamore

! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/jdk/internal/loader/BootLoader.java
! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java
! src/java.base/share/classes/jdk/internal/loader/NativeLibrary.java
! src/java.base/share/native/libjava/NativeLibraries.c
+ test/jdk/jdk/internal/loader/NativeLibraries/Main.java
+ test/jdk/jdk/internal/loader/NativeLibraries/java.base/jdk/internal/loader/NativeLibrariesTest.java
+ test/jdk/jdk/internal/loader/NativeLibraries/libnativeLibrariesTest.c
+ test/jdk/jdk/internal/loader/NativeLibraries/p/Test.java

Changeset: 398ce294
Author:    Sandhya Viswanathan 
Date:      2020-03-23 10:26:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/398ce294

8240248: Extend superword reduction optimizations for x86

Add support for and, or, xor reduction

Co-authored-by: Shravya Rukmannagari 
Reviewed-by: vlivanov, thartmann

! make/devkit/createJMHBundle.sh
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/vectornode.cpp
! src/hotspot/share/opto/vectornode.hpp
! src/hotspot/share/runtime/vmStructs.cpp
+ test/hotspot/jtreg/compiler/loopopts/superword/RedTest_int.java
+ test/hotspot/jtreg/compiler/loopopts/superword/RedTest_long.java
+ test/micro/org/openjdk/bench/vm/compiler/VectorReduction.java

Changeset: edb6783a
Author:    Poonam Bajaj 
Date:      2020-03-23 17:57:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/edb6783a

8231779: crash HeapWord*ParallelScavengeHeap::failed_mem_allocate

Reviewed-by: dlong, tschatzl, pliden

! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp

Changeset: f37149b1
Author:    Aleksey Shipilev 
Date:      2020-03-23 19:14:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f37149b1

8241351: Shenandoah: fragmentation metrics overhaul

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMetrics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMetrics.hpp

Changeset: fe533725
Author:    Aleksey Shipilev 
Date:      2020-03-23 19:14:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/fe533725

8241435: Shenandoah: avoid disabling pacing with "aggressive"

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp

Changeset: b6783320
Author:    Aleksey Shipilev 
Date:      2020-03-23 19:14:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b6783320

8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.hpp

Changeset: f0ba0dc6
Author:    Jonathan Gibbons 
Date:      2020-03-23 12:48:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f0ba0dc6

8241190: Fix name clash for constants-summary CSS class

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! test/langtools/jdk/javadoc/doclet/JavascriptWinTitle/JavascriptWinTitle.java
! test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java

Changeset: 81353a56
Author:    Ioi Lam 
Date:      2020-03-23 13:27:22 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/81353a56

8241244: CDS dynamic dump asserts in ArchivePtrBitmapCleaner::do_bit

Reviewed-by: minqi, coleenp

! src/hotspot/share/classfile/systemDictionaryShared.cpp

Changeset: 7dc952ec
Author:    Jonathan Gibbons 
Date:      2020-03-23 14:11:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7dc952ec

8241292: Interactive Search results are not highlighted as they used to be

Reviewed-by: prappo

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js
! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java

Changeset: 23d6a788
Author:    Claes Redestad 
Date:      2020-03-23 23:18:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/23d6a788

8241371: Refactor and consolidate package_from_name

Reviewed-by: iklam, lfoltan

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoader.hpp
! src/hotspot/share/classfile/klassFactory.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/utilities/utf8.cpp
! src/hotspot/share/utilities/utf8.hpp
! test/hotspot/gtest/oops/test_instanceKlass.cpp
! test/hotspot/gtest/runtime/test_classLoader.cpp

Changeset: 32d49650
Author:    Aditya Mandaleeka 
Committer: Aditya Mandaleeka 
Date:      2020-03-24 06:13:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/32d49650

8241067: Shenandoah: improve ShenandoahNMethod::has_cset_oops arguments

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp

Changeset: 5110de6c
Author:    Andrew Dinn 
Date:      2020-03-19 17:26:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5110de6c

8241144: Javadoc is not generated for new module jdk.nio.mapmode

Jdk.nio.mapmode is not present in DOCS_MODULES defined by Modules.gmk

Reviewed-by: erikj, ihse

! make/common/Modules.gmk

Changeset: d01f6719
Author:    Vladimir Kozlov 
Date:      2020-03-24 09:34:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d01f6719

8237497: vmStructs_jvmci.cpp does not check that the correct field type is specified

Add missed checks for declarations in vmStructs_jvmci.cpp

Reviewed-by: iklam, thartmann

! src/hotspot/share/jvmci/jvmci.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.hpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/runtime/vmStructs.hpp
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java

Changeset: ca855006
Author:    Tobias Hartmann 
Date:      2020-03-24 17:39:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ca855006

8240905: assert(mem == (Node*)1 || mem == mem2) failed: multiple Memories being matched at once?

Stop recursion if there are multiple loads with different memory inputs in the tree.

Reviewed-by: kvn, vlivanov

! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
+ test/hotspot/jtreg/compiler/codegen/TestMultiMemInstructionMatching.java

Changeset: b5897fe4
Author:    Daniel D. Daugherty 
Date:      2020-03-24 13:08:54 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b5897fe4

8241532: ProblemList tests from 8241530 on OSX

Reviewed-by: ctornqvi

! test/jdk/ProblemList.txt

Changeset: 40173c50
Author:    Thomas Stuefe 
Date:      2020-03-24 18:41:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/40173c50

8241395: Factor out platform independent code for os::xxx_memory_special()

Reviewed-by: mbaesken, mdoerr, lucy

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/solaris/os_solaris.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp

Changeset: cb1632e8
Author:    Aleksey Shipilev 
Date:      2020-03-24 18:46:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cb1632e8

8241520: Shenandoah: simplify region sequence numbers handling

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

Changeset: 643f5b53
Author:    Aleksey Shipilev 
Date:      2020-03-24 18:46:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/643f5b53

8241534: Shenandoah: region status should include update watermark

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp

Changeset: 6694402d
Author:    Aleksey Shipilev 
Date:      2020-03-24 18:46:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6694402d

8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays

Reviewed-by: alanb, sgehwolf

! src/jdk.jlink/linux/classes/jdk/tools/jlink/internal/plugins/StripNativeDebugSymbolsPlugin.java

Changeset: 7afa57a3
Author:    Aleksey Shipilev 
Date:      2020-03-24 18:46:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7afa57a3

8241445: Fix copyright in test/jdk/tools/launcher/ArgFileSyntax.java

Reviewed-by: psandoz

! src/java.base/share/native/libjli/args.c
! test/jdk/tools/launcher/ArgFileSyntax.java

Changeset: 3059f593
Author:    Aleksey Shipilev 
Date:      2020-03-24 20:18:45 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3059f593

8241545: Shenandoah: purge root work overwrites counters after JDK-8228818

Reviewed-by: zgu

! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp

Changeset: d7435182
Author:    Tom Rodriguez 
Date:      2020-03-24 13:12:19 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d7435182

8241458: [JVMCI] add mark value to expose CodeOffsets::Frame_Complete

Reviewed-by: kvn

! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: 77534229
Author:    Vladimir Ivanov 
Date:      2020-03-25 00:10:22 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/77534229

8241433: x86: Add VBMI CPU feature detection

Reviewed-by: kvn

! src/hotspot/cpu/x86/vmStructs_x86.hpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: 27ef185b
Author:    Aleksey Shipilev 
Date:      2020-03-25 07:58:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/27ef185b

8241500: FieldLayout/OldLayoutCheck.java fails in 32-bit VMs

Reviewed-by: fparain, dholmes

! test/hotspot/jtreg/runtime/FieldLayout/OldLayoutCheck.java

Changeset: 9a6038fb
Author:    Claes Redestad 
Date:      2020-03-25 13:38:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9a6038fb

8241584: Remove unused classLoader perf counters

Reviewed-by: hseigel

! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoader.hpp

Changeset: c01e986c
Author:    Christian Hagedorn 
Date:      2020-03-25 14:41:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c01e986c

8237859: C2: Crash when loads float above range check

Fix control edges of predicates to data nodes when creating pre/main/post loops.

Reviewed-by: neliasso, thartmann, roland

! src/hotspot/share/opto/loopPredicate.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/loopnode.hpp
+ test/hotspot/jtreg/compiler/loopopts/TestRangeCheckPredicatesControl.java

Changeset: d1b50659
Author:    Ivan Gerasimov 
Date:      2020-03-25 08:46:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d1b50659

8237599: Greedy matching against supplementary chars fails to respect the region

Reviewed-by: rriggs

! src/java.base/share/classes/java/util/regex/Pattern.java
! test/jdk/java/util/regex/RegExTest.java

Changeset: 7fc31ead
Author:    Aleksey Shipilev 
Date:      2020-03-25 17:20:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7fc31ead

8241583: Shenandoah: turn heap lock asserts into macros

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahLock.hpp

Changeset: b8f2b326
Author:    Naoto Sato 
Date:      2020-03-25 09:21:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b8f2b326

8241311: Move some charset mapping tests from closed to open

Reviewed-by: iris, joehw, itakiguchi, amlu

! test/jdk/sun/nio/cs/TestCharsetMapping.java
+ test/jdk/sun/nio/cs/mapping/Big5.b2c
= test/jdk/sun/nio/cs/mapping/Big5.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/Big5_HKSCS.b2c
+ test/jdk/sun/nio/cs/mapping/Big5_HKSCS.b2c-irreversible
= test/jdk/sun/nio/cs/mapping/Big5_HKSCS.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Big5_HKSCS_2001.b2c
+ test/jdk/sun/nio/cs/mapping/Big5_HKSCS_2001.c2b-irreversible
= test/jdk/sun/nio/cs/mapping/Big5_Solaris.b2c
+ test/jdk/sun/nio/cs/mapping/CoderTest.java
+ test/jdk/sun/nio/cs/mapping/ConverterTest.java
+ test/jdk/sun/nio/cs/mapping/Cp037.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1006.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1025.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1026.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1046.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1047.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1097.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1098.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1112.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1122.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1123.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1124.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1250.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1251.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1252.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1253.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1254.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1255.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1256.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1257.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1258.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1364.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1364.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp1381.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1381.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp1383.b2c
+ test/jdk/sun/nio/cs/mapping/Cp1383.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp273.b2c
+ test/jdk/sun/nio/cs/mapping/Cp277.b2c
+ test/jdk/sun/nio/cs/mapping/Cp278.b2c
+ test/jdk/sun/nio/cs/mapping/Cp280.b2c
+ test/jdk/sun/nio/cs/mapping/Cp284.b2c
+ test/jdk/sun/nio/cs/mapping/Cp285.b2c
+ test/jdk/sun/nio/cs/mapping/Cp290.b2c
+ test/jdk/sun/nio/cs/mapping/Cp290.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp297.b2c
+ test/jdk/sun/nio/cs/mapping/Cp300.b2c
= test/jdk/sun/nio/cs/mapping/Cp300.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp33722.b2c
+ test/jdk/sun/nio/cs/mapping/Cp420.b2c
+ test/jdk/sun/nio/cs/mapping/Cp420.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp420.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp424.b2c
+ test/jdk/sun/nio/cs/mapping/Cp437.b2c
+ test/jdk/sun/nio/cs/mapping/Cp500.b2c
+ test/jdk/sun/nio/cs/mapping/Cp737.b2c
+ test/jdk/sun/nio/cs/mapping/Cp775.b2c
+ test/jdk/sun/nio/cs/mapping/Cp833.b2c
+ test/jdk/sun/nio/cs/mapping/Cp833.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp834.b2c
+ test/jdk/sun/nio/cs/mapping/Cp834.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp838.b2c
+ test/jdk/sun/nio/cs/mapping/Cp850.b2c
+ test/jdk/sun/nio/cs/mapping/Cp852.b2c
+ test/jdk/sun/nio/cs/mapping/Cp855.b2c
+ test/jdk/sun/nio/cs/mapping/Cp856.b2c
+ test/jdk/sun/nio/cs/mapping/Cp857.b2c
+ test/jdk/sun/nio/cs/mapping/Cp860.b2c
+ test/jdk/sun/nio/cs/mapping/Cp861.b2c
+ test/jdk/sun/nio/cs/mapping/Cp862.b2c
+ test/jdk/sun/nio/cs/mapping/Cp863.b2c
+ test/jdk/sun/nio/cs/mapping/Cp864.b2c
+ test/jdk/sun/nio/cs/mapping/Cp865.b2c
+ test/jdk/sun/nio/cs/mapping/Cp866.b2c
+ test/jdk/sun/nio/cs/mapping/Cp868.b2c
+ test/jdk/sun/nio/cs/mapping/Cp869.b2c
+ test/jdk/sun/nio/cs/mapping/Cp870.b2c
+ test/jdk/sun/nio/cs/mapping/Cp871.b2c
+ test/jdk/sun/nio/cs/mapping/Cp874.b2c
+ test/jdk/sun/nio/cs/mapping/Cp874.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp875.b2c
+ test/jdk/sun/nio/cs/mapping/Cp918.b2c
+ test/jdk/sun/nio/cs/mapping/Cp921.b2c
+ test/jdk/sun/nio/cs/mapping/Cp922.b2c
+ test/jdk/sun/nio/cs/mapping/Cp930.b2c
+ test/jdk/sun/nio/cs/mapping/Cp933.b2c
+ test/jdk/sun/nio/cs/mapping/Cp935.b2c
+ test/jdk/sun/nio/cs/mapping/Cp937.b2c
+ test/jdk/sun/nio/cs/mapping/Cp937.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp939.b2c
+ test/jdk/sun/nio/cs/mapping/Cp942.b2c
+ test/jdk/sun/nio/cs/mapping/Cp943.b2c
+ test/jdk/sun/nio/cs/mapping/Cp948.b2c
+ test/jdk/sun/nio/cs/mapping/Cp948.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp948.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp949.b2c
+ test/jdk/sun/nio/cs/mapping/Cp950.b2c
+ test/jdk/sun/nio/cs/mapping/Cp950.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp950.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp964.b2c
+ test/jdk/sun/nio/cs/mapping/Cp964.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/Cp970.b2c
+ test/jdk/sun/nio/cs/mapping/Cp970.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/EUC_CN.b2c
+ test/jdk/sun/nio/cs/mapping/EUC_JP.b2c
+ test/jdk/sun/nio/cs/mapping/EUC_JP_LINUX.b2c
+ test/jdk/sun/nio/cs/mapping/EUC_JP_Solaris.b2c
+ test/jdk/sun/nio/cs/mapping/EUC_KR.b2c
+ test/jdk/sun/nio/cs/mapping/EUC_TW.b2c
+ test/jdk/sun/nio/cs/mapping/GB18030.b2c
+ test/jdk/sun/nio/cs/mapping/GBK.b2c
+ test/jdk/sun/nio/cs/mapping/ISO8859_11.b2c
+ test/jdk/sun/nio/cs/mapping/ISO8859_2.b2c
+ test/jdk/sun/nio/cs/mapping/ISO8859_3.b2c
+ test/jdk/sun/nio/cs/mapping/ISO8859_4.b2c
+ test/jdk/sun/nio/cs/mapping/ISO8859_5.b2c
+ test/jdk/sun/nio/cs/mapping/ISO8859_6.b2c
+ test/jdk/sun/nio/cs/mapping/ISO8859_7.b2c
+ test/jdk/sun/nio/cs/mapping/ISO8859_8.b2c
+ test/jdk/sun/nio/cs/mapping/ISO8859_9.b2c
+ test/jdk/sun/nio/cs/mapping/JIS0201.b2c.private
+ test/jdk/sun/nio/cs/mapping/JIS0208.b2c.private
+ test/jdk/sun/nio/cs/mapping/JIS0212.b2c.private
+ test/jdk/sun/nio/cs/mapping/Johab.b2c
+ test/jdk/sun/nio/cs/mapping/KOI8_R.b2c
+ test/jdk/sun/nio/cs/mapping/KOI8_U.b2c
+ test/jdk/sun/nio/cs/mapping/MS50221_0208.b2c
+ test/jdk/sun/nio/cs/mapping/MS50221_0212.b2c
+ test/jdk/sun/nio/cs/mapping/MS874.b2c
+ test/jdk/sun/nio/cs/mapping/MS932.b2c.private
+ test/jdk/sun/nio/cs/mapping/MS932DB.b2c.private
+ test/jdk/sun/nio/cs/mapping/MS932DB.c2b.private
+ test/jdk/sun/nio/cs/mapping/MS932_0208.b2c
+ test/jdk/sun/nio/cs/mapping/MS936.b2c
+ test/jdk/sun/nio/cs/mapping/MS949.b2c
+ test/jdk/sun/nio/cs/mapping/MS950.b2c
+ test/jdk/sun/nio/cs/mapping/MS950.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/MS950.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/MS950_HKSCS.b2c
+ test/jdk/sun/nio/cs/mapping/MS950_HKSCS.c2b-irreversible
+ test/jdk/sun/nio/cs/mapping/MS950_HKSCS_XP.b2c
+ test/jdk/sun/nio/cs/mapping/MSCP932.b2c.abigail
+ test/jdk/sun/nio/cs/mapping/MacArabic.b2c
+ test/jdk/sun/nio/cs/mapping/MacCentralEurope.b2c
+ test/jdk/sun/nio/cs/mapping/MacCroatian.b2c
+ test/jdk/sun/nio/cs/mapping/MacCyrillic.b2c
+ test/jdk/sun/nio/cs/mapping/MacDingbat.b2c
+ test/jdk/sun/nio/cs/mapping/MacGreek.b2c
+ test/jdk/sun/nio/cs/mapping/MacHebrew.b2c
+ test/jdk/sun/nio/cs/mapping/MacIceland.b2c
+ test/jdk/sun/nio/cs/mapping/MacRoman.b2c
+ test/jdk/sun/nio/cs/mapping/MacRomania.b2c
+ test/jdk/sun/nio/cs/mapping/MacSymbol.b2c
+ test/jdk/sun/nio/cs/mapping/MacThai.b2c
+ test/jdk/sun/nio/cs/mapping/MacTurkish.b2c
+ test/jdk/sun/nio/cs/mapping/MacUkraine.b2c
+ test/jdk/sun/nio/cs/mapping/PCK.b2c
+ test/jdk/sun/nio/cs/mapping/PCK.b2c-irreversible
+ test/jdk/sun/nio/cs/mapping/SJIS.b2c
+ test/jdk/sun/nio/cs/mapping/SJIS_0213.b2c
+ test/jdk/sun/nio/cs/mapping/TIS620.b2c
+ test/jdk/sun/nio/cs/mapping/TestConv.java
+ test/jdk/sun/nio/cs/mapping/TestFmwk.java
+ test/jdk/sun/nio/cs/mapping/untested/X11SunUnicode_0.b2c
+ test/jdk/sun/nio/cs/mapping/untested/gb18030_0.b2c
+ test/jdk/sun/nio/cs/mapping/untested/gb18030_1.b2c

Changeset: b0245c2b
Author:    Anthony Scarpino 
Date:      2020-03-25 12:41:14 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b0245c2b

8237219: Disable native SunEC implementation by default

Reviewed-by: weijun, mullan

! src/java.base/share/classes/module-info.java
! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java
! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSASignature.java
! src/jdk.crypto.ec/share/classes/sun/security/ec/ECKeyPairGenerator.java
! src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java
! test/jdk/java/security/KeyAgreement/KeyAgreementTest.java
! test/jdk/java/security/KeyAgreement/KeySizeTest.java
! test/jdk/jdk/security/jarsigner/Spec.java
! test/jdk/sun/security/ec/ECDSAJavaVerify.java
! test/jdk/sun/security/ec/InvalidCurve.java
! test/jdk/sun/security/ec/SignatureDigestTruncate.java
! test/jdk/sun/security/ec/TestEC.java
! test/jdk/sun/security/pkcs11/ec/ReadPKCS12.java
! test/jdk/sun/security/tools/keytool/GroupName.java
! test/jdk/sun/security/tools/keytool/KeyAlg.java
! test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java

Changeset: ffe5e846
Author:    Jonathan Gibbons 
Date:      2020-03-25 15:03:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ffe5e846

8241544: update stylesheet for *-page CSS class rename and hyphenated naming

Reviewed-by: prappo, hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java

Changeset: 60fae779
Author:    John Jiang 
Date:      2020-03-26 07:09:36 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/60fae779

8237977: Further update javax/net/ssl/compatibility/Compatibility.java

Reviewed-by: rhalade

! test/jdk/javax/net/ssl/TLSCommon/CipherSuite.java
! test/jdk/javax/net/ssl/compatibility/Cert.java
! test/jdk/javax/net/ssl/compatibility/Compatibility.java
! test/jdk/javax/net/ssl/compatibility/JdkInfo.java
! test/jdk/javax/net/ssl/compatibility/JdkUtils.java
! test/jdk/javax/net/ssl/compatibility/Server.java
! test/jdk/javax/net/ssl/compatibility/TestCase.java
! test/jdk/javax/net/ssl/compatibility/UseCase.java
! test/jdk/javax/net/ssl/compatibility/Utils.java

Changeset: 0d22ad64
Author:    Claes Redestad 
Date:      2020-03-26 00:02:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0d22ad64

8241427: Coarsen locking in Modules::add_module_exports

Reviewed-by: lfoltan, hseigel

! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/classfile/modules.hpp
! src/hotspot/share/classfile/packageEntry.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! test/hotspot/jtreg/runtime/modules/AccessCheckAllUnnamed.java
! test/hotspot/jtreg/runtime/modules/JVMAddModuleExportsToAll.java

Changeset: c659b637
Author:    Pengfei Li 
Date:      2020-03-26 10:10:37 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c659b637

8241482: AArch64: Fix a potential issue after JDK-8239549

Reviewed-by: aph

! src/hotspot/cpu/aarch64/aarch64.ad

Changeset: 913a0ff0
Author:    Jie He 
Committer: Yang Zhang 
Date:      2020-03-26 14:46:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/913a0ff0

8241419: Remove unused InterfaceSupport::_number_of_calls

Reviewed-by: dholmes

! src/hotspot/share/runtime/interfaceSupport.cpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp

Changeset: c4f25e51
Author:    Matthias Baesken 
Date:      2020-03-24 15:26:10 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c4f25e51

8241491: Problem list jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java on aix

Reviewed-by: clanger

! test/jdk/ProblemList.txt

Changeset: eb003a73
Author:    Roland Westrelin 
Date:      2020-03-20 13:56:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/eb003a73

8240335: C2: assert(found_sfpt) failed: no node in loop that's not input to safepoint

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/cfgnode.hpp
+ test/hotspot/jtreg/compiler/loopstripmining/TestCastIIAfterUnrollingInOuterLoop.java

Changeset: b8f8dea9
Author:    Roland Westrelin 
Date:      2020-03-20 13:58:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b8f8dea9

8241365: Define Unique_Node_List::contains() to prevent usage by mistake

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/node.hpp

Changeset: b35032dc
Author:    Sergei Tsypanov 
Committer: Claes Redestad 
Date:      2020-03-26 10:02:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b35032dc

8241649: Optimize Character.toString

Reviewed-by: redestad, rriggs

! src/java.base/share/classes/java/lang/Character.java

Changeset: f930d466
Author:    Jesper Wilhelmsson 
Date:      2020-03-26 03:15:02 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f930d466

Added tag jdk-15+16 for changeset 5c7ec21f5d13

! .hgtags

Changeset: d882d528
Author:    Julia Boes 
Date:      2020-03-26 11:52:15 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d882d528

8235459: HttpRequest.BodyPublishers::ofFile assumes the default file system

Add support for non-default file systems to HttpRequest.BodyPublishers::ofFile

Reviewed-by: chegar, dfuchs, amlu

! src/java.net.http/share/classes/java/net/http/HttpRequest.java
! src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java
+ test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java
+ test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest1.policy
+ test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest2.policy
+ test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest3.policy
+ test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.java
+ test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.policy
+ test/jdk/java/net/httpclient/FilePublisher/SecureZipFSProvider.java

Changeset: 307b376a
Author:    Christian Hagedorn 
Date:      2020-03-26 13:43:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/307b376a

8241595: Fix missing debug_orig information in Ideal Graph Visualizer

Show missing debug_orig information for nodes in Ideal Graph Visualizer.

Reviewed-by: kvn, neliasso

! src/hotspot/share/opto/idealGraphPrinter.cpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp

Changeset: d77c52b2
Author:    Coleen Phillimore 
Date:      2020-03-26 10:29:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d77c52b2

8172485: [TESTBUG] RedefineLeak.java runs out of metaspace memory

Check for zero exit value.

Reviewed-by: lfoltan

! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeak.java

Changeset: eb7c80a3
Author:    Julia Boes 
Date:      2020-03-26 14:58:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/eb7c80a3

8241674: Fix incorrect jtreg option in FilePublisherPermsTest

Replace jtreg option 'policy' with 'java.security.policy' to extend rather than replace policy

Reviewed-by: chegar, dfuchs

! test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java

Changeset: e11ab6a4
Author:    Per Lid?n 
Date:      2020-03-26 16:56:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e11ab6a4

8241596: ZGC: Shorten runtime of gc/z/TestUncommit.java

Reviewed-by: tschatzl, sjohanss

! test/hotspot/jtreg/gc/z/TestUncommit.java

Changeset: 54e2c6fe
Author:    Daniil Titov 
Date:      2020-03-26 09:03:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/54e2c6fe

8196751: Add jhsdb option to specify debug server RMI connector port

Reviewed-by: sspitsyn, ysuenaga

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotAgent.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java
! test/lib/jdk/test/lib/Utils.java

Changeset: 098b48b7
Author:    Mikhailo Seledtsov 
Date:      2020-03-26 10:03:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/098b48b7

8240634: event/runtime/TestMetaspaceAllocationFailure.java times out

Limit number of iterations

Reviewed-by: egahlin, stuefe

! test/jdk/jdk/jfr/event/runtime/TestMetaspaceAllocationFailure.java

Changeset: e509368f
Author:    Calvin Cheung 
Date:      2020-03-26 10:14:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e509368f

8233093: Move CDS heap oopmaps into new MetaspaceShared::bm region

Moved the _closed_archive_heap_oopmaps and _open_archive_heap_oopmaps from the ro to the bm region.

Reviewed-by: iklam, minqi

! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/filemap.hpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/memory/metaspaceShared.hpp

Changeset: 8c5531b6
Author:    Aleksey Shipilev 
Date:      2020-03-26 19:08:30 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8c5531b6

8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/vmStructs_shenandoah.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeapRegion.java

Changeset: 6be46f8e
Author:    Aleksey Shipilev 
Date:      2020-03-26 19:09:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6be46f8e

8241673: Shenandoah: refactor anti-false-sharing padding

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp
! src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahLock.hpp
! src/hotspot/share/gc/shenandoah/shenandoahNMethod.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahPadding.hpp
! src/hotspot/share/gc/shenandoah/shenandoahSharedVariables.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp

Changeset: ebdb70fe
Author:    Ekaterina Pavlova 
Date:      2020-03-26 14:24:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ebdb70fe

8236975: compiler/graalunit tests fails with --illegal-access=deny

Reviewed-by: iignatyev, kvn, alanb

! test/hotspot/jtreg/compiler/graalunit/CoreTest.java
! test/hotspot/jtreg/compiler/graalunit/GraphTest.java
! test/hotspot/jtreg/compiler/graalunit/HotspotJdk9Test.java
! test/hotspot/jtreg/compiler/graalunit/HotspotSparcTest.java
! test/hotspot/jtreg/compiler/graalunit/ReplacementsTest.java
! test/hotspot/jtreg/compiler/graalunit/TestPackages.txt
! test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java
! test/hotspot/jtreg/compiler/graalunit/generateTests.sh

Changeset: 5f1636b2
Author:    Chris Plummer 
Date:      2020-03-26 15:13:21 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5f1636b2

8241696: ProblemList gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java due to JDK-8241293

Reviewed-by: dcubed, ctornqvi

! test/hotspot/jtreg/ProblemList.txt

Changeset: 87805d92
Author:    Jonathan Gibbons 
Date:      2020-03-26 20:36:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/87805d92

8241470: HtmlStyle: group and document members: description, flex, signature

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/testIndentation/TestIndentation.java
! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testMethodSignature/TestMethodSignature.java
! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java
! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java
! test/langtools/jdk/javadoc/doclet/testSerializedFormWithClassFile/TestSerializedFormWithClassFile.java
! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java

Changeset: 2bc4308d
Author:    Vipin M V 
Committer: Vyom Tewari 
Date:      2020-03-27 11:34:45 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2bc4308d

8129841: Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr

Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr

Reviewed-by: vtewari, alanb

! src/java.base/unix/native/libnet/Inet4AddressImpl.c
! src/java.base/unix/native/libnet/Inet6AddressImpl.c
! src/java.base/windows/native/libnet/Inet4AddressImpl.c
! src/java.base/windows/native/libnet/Inet6AddressImpl.c

Changeset: cc8715d8
Author:    Thomas Stuefe 
Date:      2020-03-27 07:16:22 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cc8715d8

8241581: Add BitMap::count_one_bits variant for arbitrary lengths

Reviewed-by: redestad, kbarrett

! src/hotspot/share/utilities/bitMap.cpp
! src/hotspot/share/utilities/bitMap.hpp
+ test/hotspot/gtest/utilities/test_bitMap_popcnt.cpp

Changeset: 83f7ee14
Author:    Thomas Stuefe 
Date:      2020-03-27 08:45:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/83f7ee14

8241723: Build error after 8241581

Reviewed-by: kbarrett, clanger

- test/hotspot/gtest/utilities/test_bitMap_popcnt.cpp

Changeset: 67cf35ee
Author:    Yasumasa Suenaga 
Date:      2020-03-27 17:07:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/67cf35ee

8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624

Reviewed-by: sspitsyn, kevinw

! src/jdk.hotspot.agent/linux/native/libsaproc/dwarf.cpp
! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c
! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.h
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java
! test/hotspot/jtreg/ProblemList.txt

Changeset: 7048684c
Author:    Thomas Schatzl 
Date:      2020-03-27 09:44:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7048684c

8238855: Move G1ConcurrentMark flag sanity checks to g1Arguments

Reviewed-by: sjohanss, kbarrett

! src/hotspot/share/gc/g1/g1Arguments.cpp
! src/hotspot/share/gc/g1/g1Arguments.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp
+ test/hotspot/jtreg/gc/g1/TestMarkStackSizes.java

Changeset: 5ff2d7ba
Author:    Roland Westrelin 
Date:      2020-03-24 11:06:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5ff2d7ba

8240676: Meet not symmetric failure when running lucene on jdk8

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp
+ test/hotspot/jtreg/compiler/types/TestArrayMeetNotSymmetrical.java

Changeset: 85d5048c
Author:    Roland Westrelin 
Date:      2020-03-24 10:31:37 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/85d5048c

8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp

Changeset: c9f5004b
Author:    Matthias Baesken 
Date:      2020-03-25 13:05:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c9f5004b

8241586: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64

Reviewed-by: clanger

! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp

Changeset: 1dd60a35
Author:    Roman Kennke 
Date:      2020-01-22 15:55:02 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1dd60a35

8227269: Slow class loading when running with JDWP

Reviewed-by: sspitsyn, cjplummer

! src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c
! src/jdk.jdwp.agent/share/native/libjdwp/classTrack.h
! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.h

Changeset: 536e062a
Author:    Vladimir Ivanov 
Date:      2020-03-27 13:42:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/536e062a

8241436: C2: Factor out C2-specific code from MacroAssembler

Reviewed-by: mdoerr, kvn, adinn

! src/hotspot/cpu/aarch64/aarch64.ad
+ src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
+ src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/arm/arm.ad
+ src/hotspot/cpu/arm/c2_MacroAssembler_arm.cpp
+ src/hotspot/cpu/arm/c2_MacroAssembler_arm.hpp
! src/hotspot/cpu/arm/macroAssembler_arm.cpp
! src/hotspot/cpu/arm/macroAssembler_arm.hpp
+ src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp
+ src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
+ src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
+ src/hotspot/cpu/s390/c2_MacroAssembler_s390.hpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.hpp
! src/hotspot/cpu/s390/s390.ad
+ src/hotspot/cpu/sparc/c2_MacroAssembler_sparc.cpp
+ src/hotspot/cpu/sparc/c2_MacroAssembler_sparc.hpp
! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp
! src/hotspot/cpu/sparc/macroAssembler_sparc.hpp
! src/hotspot/cpu/sparc/sparc.ad
+ src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
+ src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/adlc/adlparse.cpp
! src/hotspot/share/adlc/main.cpp
+ src/hotspot/share/opto/c2_MacroAssembler.hpp

Changeset: d0a67229
Author:    Vladimir Ivanov 
Date:      2020-03-27 13:42:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d0a67229

8241434: x86: Fix Assembler::emit_operand asserts for XMM registers

Reviewed-by: kvn, redestad

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp

Changeset: 2df18266
Author:    Vladimir Ivanov 
Date:      2020-03-27 13:42:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2df18266

8241597: x86: Remove MMX support

Reviewed-by: kvn, redestad

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/register_definitions_x86.cpp
! src/hotspot/cpu/x86/register_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp

Changeset: bb7a8f64
Author:    Roman Kennke 
Date:      2020-03-27 12:47:36 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/bb7a8f64

8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahNormalMode.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPassiveMode.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalMode.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java
! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java

Changeset: 5ddbcb7a
Author:    Daniel Fuchs 
Date:      2020-03-27 12:42:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5ddbcb7a

8241336: Some java.net tests failed with NoRouteToHostException on MacOS with special network configuration

NetworkConfiguration updated to skip interfaces that have only IPv6 link local addresses.

Reviewed-by: alanb, chegar

! test/jdk/ProblemList.txt
! test/jdk/java/net/MulticastSocket/Promiscuous.java
! test/jdk/java/net/MulticastSocket/SetOutgoingIf.java
! test/jdk/java/nio/channels/DatagramChannel/AdaptorMulticasting.java
! test/lib/jdk/test/lib/NetworkConfiguration.java

Changeset: a45889dc
Author:    Matthias Baesken 
Date:      2020-03-26 10:38:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a45889dc

8241660: Add virtualization information output to hs_err file on macOS

Reviewed-by: clanger, mdoerr

! src/hotspot/os/bsd/os_bsd.cpp

Changeset: 7056b968
Author:    Aleksey Shipilev 
Date:      2020-03-27 15:33:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7056b968

8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved

Reviewed-by: zgu, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp

Changeset: 0861f3f7
Author:    Aleksey Shipilev 
Date:      2020-03-27 15:33:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0861f3f7

8241743: Shenandoah: refactor and inline ShenandoahHeap::heap()

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMonitoringSupport.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

Changeset: 92d854f5
Author:    Aleksey Shipilev 
Date:      2020-03-27 15:33:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/92d854f5

8241740: Shenandoah: remove ShenandoahHeapRegion::_heap

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp

Changeset: 6e580b38
Author:    Aleksey Shipilev 
Date:      2020-03-27 15:33:24 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6e580b38

8241748: Shenandoah: inline MarkingContext TAMS methods

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp

Changeset: bfa3ad91
Author:    Andy Herrick 
Date:      2020-03-27 11:43:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/bfa3ad91

8241400: [macos] jpackageapplauncher/main.m built using CXXFLAGS_JDKEXE

Reviewed-by: erikj

! make/lib/Lib-jdk.incubator.jpackage.gmk

Changeset: 211e5293
Author:    Jamsheed Mohammed C M 
Date:      2020-03-27 09:47:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/211e5293

8193210: [JVMCI/Graal] add JFR compiler phase/inlining events

C++ EventCompilerPhase/EventCompilerInlining definitions are extended for JVMCI use.

Reviewed-by: dnsimon, egahlin, kvn, mgronlun, thartmann

! make/hotspot/lib/JvmFeatures.gmk
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/compiler/compileBroker.cpp
+ src/hotspot/share/compiler/compilerEvent.cpp
+ src/hotspot/share/compiler/compilerEvent.hpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.hpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/opto/bytecodeInfo.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/utilities/macros.hpp
! src/hotspot/share/utilities/ticks.hpp
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
+ src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/JFR.java
! test/jdk/jdk/jfr/event/compiler/TestDeoptimization.java
! test/jdk/jdk/jfr/jvm/TestJfrJavaBase.java

Changeset: 9e9f110d
Author:    Aleksey Shipilev 
Date:      2020-03-27 19:05:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9e9f110d

8241750: x86_32 build failure after JDK-8227269

Reviewed-by: rkennke, cjplummer

! src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c

Changeset: c17ed6a5
Author:    Bob Vandette 
Date:      2020-02-27 11:36:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c17ed6a5

8239563: Reduce public exports in dynamic libraries built from JDK static libraries

Reviewed-by: dholmes, ihse

! make/autoconf/flags-cflags.m4
! src/java.base/unix/native/include/jni_md.h
! src/java.base/windows/native/include/jni_md.h

Changeset: ccc69960
Author:    Jonathan Gibbons 
Date:      2020-03-27 11:24:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ccc69960

8241631: PropertyGetterTaglet, PropertySetterTaglet may be removed

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/BasePropertyTaglet.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/PropertyGetterTaglet.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/PropertySetterTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java
! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java
! test/langtools/jdk/javadoc/doclet/testJavaFX/pkg1/C.java
! test/langtools/jdk/javadoc/doclet/testSearch/pkgfx/C.java
! test/langtools/jdk/javadoc/doclet/testTaglets/TestTaglets.out
! test/langtools/jdk/javadoc/tool/sampleapi/lib/sampleapi/generator/DocCommentGenerator.java

Changeset: fee15cac
Author:    Mikael Vidstedt 
Date:      2020-03-27 12:50:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/fee15cac

8241721: Change to GCC 9.2 for building on Linux at Oracle

Reviewed-by: erikj

! doc/building.html
! doc/building.md
! make/conf/jib-profiles.js
! make/devkit/Tools.gmk

Changeset: 6b6c5bd6
Author:    Zhengyu Gu 
Date:      2020-03-28 11:00:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6b6c5bd6

8241765: Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier

Reviewed-by: rkennke, smonteith, aph

! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp

Changeset: 98e6be7c
Author:    Joe Darcy 
Date:      2020-03-28 13:01:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/98e6be7c

8241789: Make citations of JLS and JVMS consistent in java.lang.Class

Reviewed-by: jjg

! src/java.base/share/classes/java/lang/Class.java

Changeset: 253ccad5
Author:    Claes Redestad 
Date:      2020-03-28 21:08:32 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/253ccad5

8241771: Remove dead code in SparsePRT

Reviewed-by: sjohanss, tschatzl

! src/hotspot/share/gc/g1/sparsePRT.cpp
! src/hotspot/share/gc/g1/sparsePRT.hpp

Changeset: 7f8d7850
Author:    Toshio Nakamura 
Date:      2020-03-28 16:47:21 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7f8d7850

8232846: ProcessHandle.Info command with non-English shows question marks

Reviewed-by: stuefe, ysuenaga, rriggs

! src/java.base/windows/native/libjava/ProcessHandleImpl_win.c

Changeset: b0e1ee4b
Author:    Ivan Gerasimov 
Date:      2020-03-28 21:07:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b0e1ee4b

8241727: Typos: empty lines in javadoc, inconsistent indents, etc. (core-libs only)

Reviewed-by: prappo

! src/java.base/share/classes/java/io/FileInputStream.java
! src/java.base/share/classes/java/io/ObjectInputStream.java
! src/java.base/share/classes/java/io/PipedReader.java
! src/java.base/share/classes/java/io/RandomAccessFile.java
! src/java.base/share/classes/java/lang/Boolean.java
! src/java.base/share/classes/java/lang/Character.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/Float.java
! src/java.base/share/classes/java/lang/Package.java
! src/java.base/share/classes/java/lang/ProcessBuilder.java
! src/java.base/share/classes/java/lang/ProcessHandleImpl.java
! src/java.base/share/classes/java/lang/RuntimePermission.java
! src/java.base/share/classes/java/lang/StrictMath.java
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/Thread.java
! src/java.base/share/classes/java/lang/annotation/Annotation.java
! src/java.base/share/classes/java/lang/invoke/ConstantGroup.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/MethodHandle.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/package-info.java
! src/java.base/share/classes/java/lang/module/package-info.java
! src/java.base/share/classes/java/lang/reflect/AnnotatedElement.java
! src/java.base/share/classes/java/lang/reflect/InvocationTargetException.java
! src/java.base/share/classes/java/math/BigDecimal.java
! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/math/MutableBigInteger.java
! src/java.base/share/classes/java/math/SignedMutableBigInteger.java
! src/java.base/share/classes/java/text/DateFormat.java
! src/java.base/share/classes/java/text/DateFormatSymbols.java
! src/java.base/share/classes/java/text/MessageFormat.java
! src/java.base/share/classes/java/text/NumberFormat.java
! src/java.base/share/classes/java/text/RBCollationTables.java
! src/java.base/share/classes/java/text/RuleBasedCollator.java
! src/java.base/share/classes/java/util/BitSet.java
! src/java.base/share/classes/java/util/Calendar.java
! src/java.base/share/classes/java/util/Collections.java
! src/java.base/share/classes/java/util/Comparator.java
! src/java.base/share/classes/java/util/Currency.java
! src/java.base/share/classes/java/util/EnumMap.java
! src/java.base/share/classes/java/util/GregorianCalendar.java
! src/java.base/share/classes/java/util/Scanner.java
! src/java.base/share/classes/java/util/ServiceLoader.java
! src/java.base/share/classes/java/util/SimpleTimeZone.java
! src/java.base/share/classes/java/util/regex/Matcher.java
! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java
! src/java.base/share/classes/java/util/stream/DoubleStream.java
! src/java.base/share/classes/java/util/stream/package-info.java
! src/java.base/share/classes/jdk/internal/icu/impl/CharTrie.java
! src/java.base/share/classes/jdk/internal/icu/impl/ICUBinary.java
! src/java.base/share/classes/jdk/internal/icu/impl/StringPrepDataReader.java
! src/java.base/share/classes/jdk/internal/icu/impl/Trie.java
! src/java.base/share/classes/jdk/internal/icu/impl/Trie2.java
! src/java.base/share/classes/jdk/internal/icu/impl/UCharacterProperty.java
! src/java.base/share/classes/jdk/internal/icu/lang/UCharacterEnums.java
! src/java.base/share/classes/jdk/internal/icu/text/UCharacterIterator.java
! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java
! src/java.base/share/classes/jdk/internal/logger/LoggerWrapper.java
! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
! src/java.base/share/classes/jdk/internal/util/Preconditions.java
! src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java
! src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java
! src/java.base/share/classes/sun/reflect/generics/repository/ClassRepository.java
! src/java.base/share/classes/sun/reflect/generics/repository/ConstructorRepository.java
! src/java.base/share/classes/sun/reflect/generics/repository/FieldRepository.java
! src/java.base/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
! src/java.base/share/classes/sun/text/BreakDictionary.java
! src/java.base/share/classes/sun/text/CompactByteArray.java
! src/java.base/share/classes/sun/util/calendar/ZoneInfo.java

Changeset: f0298241
Author:    David Simms 
Date:      2020-04-03 09:27:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f0298241

All done merging master

! .hgtags
! make/CompileJavaModules.gmk
! make/Docs.gmk
! make/autoconf/hotspot.m4
! make/conf/jib-profiles.js
! make/test/BuildMicrobenchmark.gmk
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/sparc/interp_masm_sparc.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp
! src/hotspot/cpu/x86/globals_x86.hpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/adlc/main.cpp
! src/hotspot/share/asm/codeBuffer.hpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_Instruction.hpp
! src/hotspot/share/c1/c1_LinearScan.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classListParser.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/oopMap.cpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/interpreter/templateInterpreter.cpp
! src/hotspot/share/interpreter/templateTable.cpp
! src/hotspot/share/interpreter/templateTable.hpp
! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/heapInspection.cpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/arrayKlass.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/methodData.cpp
! src/hotspot/share/oops/methodData.hpp
! src/hotspot/share/oops/objArrayKlass.cpp
! src/hotspot/share/oops/oopsHierarchy.hpp
! src/hotspot/share/opto/arraycopynode.cpp
! src/hotspot/share/opto/buildOopMap.cpp
! src/hotspot/share/opto/bytecodeInfo.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/cfgnode.hpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/idealKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopUnswitch.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/machnode.cpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/output.hpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/phaseX.hpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/stringopts.cpp
! src/hotspot/share/opto/subtypenode.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/reflection.cpp
! src/hotspot/share/runtime/signature.cpp
! src/hotspot/share/runtime/signature.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/services/diagnosticCommand.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/powerOfTwo.hpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
! src/java.base/share/classes/module-info.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! src/jdk.jdwp.agent/share/native/libjdwp/ArrayReferenceImpl.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.c
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/TEST.groups
! test/jtreg-ext/requires/VMProps.java
! test/langtools/jdk/javadoc/doclet/testClassTree/TestClassTree.java
! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/langtools/jdk/javadoc/doclet/testHiddenTag/TestHiddenTag.java
! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java
! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java
! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java
! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java
! test/lib/sun/hotspot/WhiteBox.java
! .hgtags
! make/CompileJavaModules.gmk
! make/Docs.gmk
! make/autoconf/hotspot.m4
! make/conf/jib-profiles.js
! make/test/BuildMicrobenchmark.gmk
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/sparc/interp_masm_sparc.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp
! src/hotspot/cpu/x86/globals_x86.hpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/adlc/main.cpp
! src/hotspot/share/asm/codeBuffer.hpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_Instruction.hpp
! src/hotspot/share/c1/c1_LinearScan.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classListParser.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/oopMap.cpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/interpreter/templateInterpreter.cpp
! src/hotspot/share/interpreter/templateTable.cpp
! src/hotspot/share/interpreter/templateTable.hpp
! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/heapInspection.cpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/arrayKlass.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/methodData.cpp
! src/hotspot/share/oops/methodData.hpp
! src/hotspot/share/oops/objArrayKlass.cpp
! src/hotspot/share/oops/oopsHierarchy.hpp
! src/hotspot/share/opto/arraycopynode.cpp
! src/hotspot/share/opto/buildOopMap.cpp
! src/hotspot/share/opto/bytecodeInfo.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/cfgnode.hpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/idealKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopUnswitch.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/machnode.cpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/output.hpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/phaseX.hpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/stringopts.cpp
! src/hotspot/share/opto/subtypenode.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/reflection.cpp
! src/hotspot/share/runtime/signature.cpp
! src/hotspot/share/runtime/signature.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/services/diagnosticCommand.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/powerOfTwo.hpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
! src/java.base/share/classes/module-info.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! src/jdk.jdwp.agent/share/native/libjdwp/ArrayReferenceImpl.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.c
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/TEST.groups
! test/jtreg-ext/requires/VMProps.java
! test/langtools/jdk/javadoc/doclet/testClassTree/TestClassTree.java
! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/langtools/jdk/javadoc/doclet/testHiddenTag/TestHiddenTag.java
! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java
! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java
! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java
! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java
! test/lib/sun/hotspot/WhiteBox.java

Changeset: ddfee9a7
Author:    David Simms 
Date:      2020-04-07 11:09:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ddfee9a7

Discovered merge issue JDK-8242269

! src/hotspot/share/opto/type.cpp

Changeset: ae1135cf
Author:    David Simms 
Date:      2020-04-08 12:14:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ae1135cf

Merge branch 'lworld' into lworld_merge

# Conflicts:
#	src/hotspot/cpu/x86/macroAssembler_x86.cpp
#	src/hotspot/cpu/x86/x86_64.ad

! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: 0c52cfec
Author:    David Simms 
Date:      2020-04-08 14:55:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0c52cfec

Remove whitespace/tabs

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp
! src/jdk.jdwp.agent/share/native/libjdwp/ArrayReferenceImpl.c


From roland at openjdk.java.net  Thu Apr  9 16:11:56 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 9 Apr 2020 16:11:56 GMT
Subject: [lworld] RFR: 8242269: [lworld] C2 compilation fails with assert
 "meet not symmetric"
Message-ID: 

This tweaks the type system to fix error triggered by the recent merge.

-------------

Commit messages:
 - Fix meet not symmetric errors following merge of 8240676

Changes: https://git.openjdk.java.net/valhalla/pull/20/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/20/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242269
  Stats: 45 lines in 1 file changed: 17 ins; 15 del; 13 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/20/head:pull/20

PR: https://git.openjdk.java.net/valhalla/pull/20

From fparain at openjdk.java.net  Fri Apr 10 16:58:06 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 10 Apr 2020 16:58:06 GMT
Subject: [lworld] RFR: 8242496 [lworld] new and defaultvalue don't perform
 checks on class to instantiate
Message-ID: 

The new and defaultvalue bytecodes currently lack a check to ensure that the class to instantiate is of the right kind.

These changes add checks in both slow and fast path of the interpreter.

Testing:
  - unit test added
  - mach5 tier 1 (all failures were pre-existing)

-------------

Commit messages:
 - Fix tabs and trailing whitespaces
 - Add type checks to new and defaultvalue

Changes: https://git.openjdk.java.net/valhalla/pull/21/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/21/webrev.00
  Stats: 155 lines in 5 files changed: 155 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/21.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/21/head:pull/21

PR: https://git.openjdk.java.net/valhalla/pull/21

From hseigel at openjdk.java.net  Fri Apr 10 18:59:47 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 10 Apr 2020 18:59:47 GMT
Subject: [lworld] RFR: Change exception messages to say 'Inline type' instead
 of 'Value type'
Message-ID: 

This changes the inline type related exception messages in classFileParser.cpp to use 'inline type' instead of 'value
type'.

-------------

Commit messages:
 - Change exception messages to say 'Inline type' instead of 'Value type'

Changes: https://git.openjdk.java.net/valhalla/pull/22/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/22/webrev.00
  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/22.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/22/head:pull/22

PR: https://git.openjdk.java.net/valhalla/pull/22

From fparain at openjdk.java.net  Fri Apr 10 19:32:01 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 10 Apr 2020 19:32:01 GMT
Subject: [lworld] RFR: Change exception messages to say 'Inline type'
 instead of 'Value type'
In-Reply-To: 
References: 
Message-ID: 

On Fri, 10 Apr 2020 18:53:09 GMT, Harold Seigel  wrote:

> This changes the inline type related exception messages in classFileParser.cpp to use 'inline type' instead of 'value
> type'.

Looks good to me.
The fix does what the title says. There're still many other places where the term "value type" is used (variable name,
function name, assertion message) but those will probably fixed in a future big renaming game over the whole source
base.

-------------

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/22

From mandy.chung at oracle.com  Sun Apr 12 03:13:07 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 11 Apr 2020 20:13:07 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
Message-ID: 

Please review the delta patch:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/

Incremental specdiff:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html
This is to follow a discussion [1] on Class::descriptorString and 
MethodType::descriptorString for hidden classes.?? The proposal is to 
define the descriptor string for a hidden class of this form:
 ??? "L" + N + ";" + "/" + 

The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and 
`MethodType::descriptorString` are updated to return the descriptor of 
this form for a hidden class.?? To support hidden class, 
`java.lang.invoke.TypeDescriptor` spec is revised such that a 
`TypeDescriptor` object can represent an entity that may not be 
described in nominal form. ??? This change affects JVM TI, JDWP and 
JDI.??? The spec change includes a couple other JVM TI and 
java.instrument spec clarification w.r.t. hidden classes that Serguei 
has been working on.



Mandy
[1] 
https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html

----------------
As a record, the above patch is applied on the top:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/

webrev.06 includes the following changes that have been reviewed:
1. rename "weak hidden" and Klass::is_hidden_weak to is_non_strong_hidden
2. remove unused `setImplMethod` method from lambda proxy class
3. include Serguei's patch to fix JDK-8242166: regression in JDI 
ClassUnload events
4. drop the uniqueness guarantee of the suffix of the hidden class's name

On 3/31/20 8:01 PM, Mandy Chung wrote:
> Thanks to the review feedbacks.
>
> Updated webrev:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ 
>
> Delta between webrev.03 and webrev.04:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ 
>
>
> Summary of changes is:
> 1. Update javac to retain the previous behavior when compiling to 
> target release <= 14 where lambda proxy class is not a nestmate
> 2. Rename Class::isHiddenClass to Class::isHidden
> 3. Address Joe's feedback on the CSR to document the behavior of the 
> relevant methods in java.lang.Class for hidden classes
> 4. Add test case for unloadable class with nest host error
> 5. Add test cases for hidden classes with different kinds of class or 
> interface
> 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class"
> 7. Small changes in response to Remi, Coleen, Paul's review comments
> 8. Fix copyright headers
> 9. Fix @modules in tests
>
> Most of the changes above have also been reviewed as separate patches.
>
> Thanks
> Mandy
>
> On 3/26/20 4:57 PM, Mandy Chung wrote:
>> Please review the implementation of JEP 371: Hidden Classes. The main 
>> changes are in core-libs and hotspot runtime area.? Small changes are 
>> made in javac, VM compiler (intrinsification of 
>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed 
>> and is in the finalized state (see specdiff and javadoc below for 
>> reference).
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 
>>
>>
>> javadoc/specdiff
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ 
>>
>>
>> JVMS 5.4.4 change:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf 
>>
>>
>> CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8238359
>>
>> Thanks
>> Mandy
>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359
>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338
>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502
>


From mandy.chung at oracle.com  Sun Apr 12 03:35:45 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 11 Apr 2020 20:35:45 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <82F1D053-984A-4D0B-B5C2-6A3CCBFA4C20@oracle.com>
References: 
 <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com>
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 
 <82F1D053-984A-4D0B-B5C2-6A3CCBFA4C20@oracle.com>
Message-ID: <5a9055d9-f553-716e-78b3-18b11128ad1a@oracle.com>



On 4/8/20 3:35 PM, John Rose wrote:
> On Apr 8, 2020, at 3:31 PM, John Rose  > wrote:
>>
>> In both c and c? there will probably be a cascading failure
>> if the name foo/Bar/123Z or foo/Bar is resolved. ?In c? there
>> is an additional cascading failure when the user that was
>> parsing the signature goes back for more parameters and
>> finds a slash (instead of LZBHCIJFD[). ?The thing that tipped
>> me over to c? is that extra diagnostic: Even though it happens
>> after the user picked up the bad descriptor, it happens closer
>> to the place where the error has its root cause, which is that
>> somebody is trying to parse an (intentionally) illegal descriptor.
>
> P.S. Having the slash+suffix *outside* the L; envelope basically
> rubs any parser?s nose in the fact that there?s something illegal
> here. ?Putting it inside the envelope hides the error from the
> parser?which may be a good thing sometimes! ?But it means
> that the odd name foo/Bar.123Z will float somewhere else
> and may or may not be misinterpreted. ?If it?s handed to
> Class.forName you can bet that the dot will change its meaning.
> On balance, I slightly prefer the fail-fast properties of c?.

Thanks John.

I have implemented to define the descriptor string for a hidden class of 
this form:
 ???? "L" + N + ";" + "/" + 

Please see [1] for the review thread.

For your reference, the webrev is:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/

Specdiff:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html

The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and
`MethodType::descriptorString` are updated to return the descriptor of
this form for a hidden class.?? To support hidden class,
`java.lang.invoke.TypeDescriptor` spec is revised such that a
`TypeDescriptor` object can represent an entity that may not be
described in nominal form.?? The serviceability APIs that return a type
descriptor are updated.? This webrev includes a couple other JVM TI and
java.instrument spec clarification w.r.t. hidden classes.

Mandy
[1] 
https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007121.html

From peter.levart at gmail.com  Sun Apr 12 08:28:06 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 12 Apr 2020 10:28:06 +0200
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <5a9055d9-f553-716e-78b3-18b11128ad1a@oracle.com>
References: 
 <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com>
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 
 <82F1D053-984A-4D0B-B5C2-6A3CCBFA4C20@oracle.com>
 <5a9055d9-f553-716e-78b3-18b11128ad1a@oracle.com>
Message-ID: 

Hi,

Are '.' and '/' the only characters on the table? The problems with 
those are that both are used as hierarchical name delimiters in one way 
or another and code exists that converts one to another. If there was a 
3rd character chosen such that:

- it would make the descriptor "invalid" for resolving
- otherwise not be unexpected in parsing logic

...then such composition would be ideal. I think that there could event 
be a place for such names in the specification: syntactically valid but 
unresolvable names.

The problem is that it is hard to find such a character isn't it? But 
let's try...

What about character '\' - backslash ? It seems very unlikely that this 
character would appear in the name of a class. In Java language it is 
not allowed, but even in other languages it is probably treated as some 
kind of delimiter and therefore unlikely to be part of the derived class 
name. Would it be too much to declare that it must not appear in the 
name of the class?

Even if it was not forbidden, it would be very unlikely to appear in 
practice. By analogy: Java anonymous classes are kind of "hidden", just 
on another level - in the language. They do use valid class names 
though, even valid in Java language, but there's no problem with that in 
practice. Why? Because the outer class typically controls the 
"namespace" where they appear in. With java modules, there is additional 
control that is imposed on the package namespace.

Regards, Peter


On 4/12/20 5:35 AM, Mandy Chung wrote:
>
>
> On 4/8/20 3:35 PM, John Rose wrote:
>> On Apr 8, 2020, at 3:31 PM, John Rose > > wrote:
>>>
>>> In both c and c? there will probably be a cascading failure
>>> if the name foo/Bar/123Z or foo/Bar is resolved. ?In c? there
>>> is an additional cascading failure when the user that was
>>> parsing the signature goes back for more parameters and
>>> finds a slash (instead of LZBHCIJFD[). ?The thing that tipped
>>> me over to c? is that extra diagnostic: Even though it happens
>>> after the user picked up the bad descriptor, it happens closer
>>> to the place where the error has its root cause, which is that
>>> somebody is trying to parse an (intentionally) illegal descriptor.
>>
>> P.S. Having the slash+suffix *outside* the L; envelope basically
>> rubs any parser?s nose in the fact that there?s something illegal
>> here. ?Putting it inside the envelope hides the error from the
>> parser?which may be a good thing sometimes! ?But it means
>> that the odd name foo/Bar.123Z will float somewhere else
>> and may or may not be misinterpreted. ?If it?s handed to
>> Class.forName you can bet that the dot will change its meaning.
>> On balance, I slightly prefer the fail-fast properties of c?.
>
> Thanks John.
>
> I have implemented to define the descriptor string for a hidden class 
> of this form:
> ???? "L" + N + ";" + "/" + 
>
> Please see [1] for the review thread.
>
> For your reference, the webrev is:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/ 
>
>
> Specdiff:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html 
>
>
> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and
> `MethodType::descriptorString` are updated to return the descriptor of
> this form for a hidden class.?? To support hidden class,
> `java.lang.invoke.TypeDescriptor` spec is revised such that a
> `TypeDescriptor` object can represent an entity that may not be
> described in nominal form.?? The serviceability APIs that return a type
> descriptor are updated.? This webrev includes a couple other JVM TI and
> java.instrument spec clarification w.r.t. hidden classes.
>
> Mandy
> [1] 
> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007121.html


From peter.levart at gmail.com  Sun Apr 12 09:26:20 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 12 Apr 2020 11:26:20 +0200
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: 
References: 
 <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com>
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 
 <82F1D053-984A-4D0B-B5C2-6A3CCBFA4C20@oracle.com>
 <5a9055d9-f553-716e-78b3-18b11128ad1a@oracle.com>
 
Message-ID: <37a34cbe-7ba1-2e2f-4160-0c03afc38b0b@gmail.com>

Just an illustration of why '\' - backslash might be a good choice... I 
created the following experiment:

package test;
public class BackslashTest {
 ??? public static void main(String[] args) throws Exception {
 ??????? Class.forName("test.Name\\suffix");
 ??? }
}

...when this is run by itself, it throws ClassNotFoundException as 
expected. Then if I do the following in the compiled classes directory:

touch 'test/Name\suffix.class'

...and re-run the program, I get "ClassFormatError: Truncated class 
file", again as expected. But I did that on my Linux box. I then packed 
the classes directory into a .jar file:

META-INF/
META-INF/MANIFEST.MF
test/
test/BackslashTest.class
test/Name\suffix.class

... and extracted that jar on the Windows PC. What I get there is the 
following extracted file structure:

 ?Directory of C:\Users\peter\tmp\test

04/12/2020? 10:55 AM??? ????????? .
04/12/2020? 10:55 AM??? ????????? ..
04/12/2020? 10:44 AM?????????????? 553 BackslashTest.class
04/12/2020? 11:58 AM??? ????????? Name
 ?????????????? 1 File(s)??????????? 553 bytes

 ?Directory of C:\Users\peter\tmp\test\Name

04/12/2020? 11:58 AM??? ????????? .
04/12/2020? 11:58 AM??? ????????? ..
04/12/2020? 10:46 AM???????????????? 0 suffix.class
 ?????????????? 1 File(s)????????????? 0 bytes

 ???? Total Files Listed:
 ?????????????? 2 File(s)??????????? 553 bytes
 ?????????????? 5 Dir(s)?? 9,659,174,912 bytes free

...if I run this with:

java -cp . test.BackslashTest

I again get "ClassFormatError: Truncated class file", which exposes a 
strange implementation detail about mapping "valid" class name to the 
path where .class file is found. At first this seems just that - 
implementation detail, but this means that this mapping is not 
bijective. There could be two class names that would map to the same 
.class file. What I'm trying to say is that there are characters that 
are valid in class names, but are unlikely to be chosen in practice by a 
programming language because they are unfriendly to some practical 
environment. In this respect `\` is such a character and therefore could 
be used in the "name" of the hidden class as delimiter between the name 
as it appears in the .class bytes and suffix. To play safe, classloader 
should also be made to reject names where '\' appears in the name of a 
class or package.

WDYT?

Regards, Peter

On 4/12/20 10:28 AM, Peter Levart wrote:
> Hi,
>
> Are '.' and '/' the only characters on the table? The problems with 
> those are that both are used as hierarchical name delimiters in one 
> way or another and code exists that converts one to another. If there 
> was a 3rd character chosen such that:
>
> - it would make the descriptor "invalid" for resolving
> - otherwise not be unexpected in parsing logic
>
> ...then such composition would be ideal. I think that there could 
> event be a place for such names in the specification: syntactically 
> valid but unresolvable names.
>
> The problem is that it is hard to find such a character isn't it? But 
> let's try...
>
> What about character '\' - backslash ? It seems very unlikely that 
> this character would appear in the name of a class. In Java language 
> it is not allowed, but even in other languages it is probably treated 
> as some kind of delimiter and therefore unlikely to be part of the 
> derived class name. Would it be too much to declare that it must not 
> appear in the name of the class?
>
> Even if it was not forbidden, it would be very unlikely to appear in 
> practice. By analogy: Java anonymous classes are kind of "hidden", 
> just on another level - in the language. They do use valid class names 
> though, even valid in Java language, but there's no problem with that 
> in practice. Why? Because the outer class typically controls the 
> "namespace" where they appear in. With java modules, there is 
> additional control that is imposed on the package namespace.
>
> Regards, Peter
>
>
> On 4/12/20 5:35 AM, Mandy Chung wrote:
>>
>>
>> On 4/8/20 3:35 PM, John Rose wrote:
>>> On Apr 8, 2020, at 3:31 PM, John Rose >> > wrote:
>>>>
>>>> In both c and c? there will probably be a cascading failure
>>>> if the name foo/Bar/123Z or foo/Bar is resolved. ?In c? there
>>>> is an additional cascading failure when the user that was
>>>> parsing the signature goes back for more parameters and
>>>> finds a slash (instead of LZBHCIJFD[). ?The thing that tipped
>>>> me over to c? is that extra diagnostic: Even though it happens
>>>> after the user picked up the bad descriptor, it happens closer
>>>> to the place where the error has its root cause, which is that
>>>> somebody is trying to parse an (intentionally) illegal descriptor.
>>>
>>> P.S. Having the slash+suffix *outside* the L; envelope basically
>>> rubs any parser?s nose in the fact that there?s something illegal
>>> here. ?Putting it inside the envelope hides the error from the
>>> parser?which may be a good thing sometimes! ?But it means
>>> that the odd name foo/Bar.123Z will float somewhere else
>>> and may or may not be misinterpreted. ?If it?s handed to
>>> Class.forName you can bet that the dot will change its meaning.
>>> On balance, I slightly prefer the fail-fast properties of c?.
>>
>> Thanks John.
>>
>> I have implemented to define the descriptor string for a hidden class 
>> of this form:
>> ???? "L" + N + ";" + "/" + 
>>
>> Please see [1] for the review thread.
>>
>> For your reference, the webrev is:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/ 
>>
>>
>> Specdiff:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html 
>>
>>
>> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and
>> `MethodType::descriptorString` are updated to return the descriptor of
>> this form for a hidden class.?? To support hidden class,
>> `java.lang.invoke.TypeDescriptor` spec is revised such that a
>> `TypeDescriptor` object can represent an entity that may not be
>> described in nominal form.?? The serviceability APIs that return a type
>> descriptor are updated.? This webrev includes a couple other JVM TI and
>> java.instrument spec clarification w.r.t. hidden classes.
>>
>> Mandy
>> [1] 
>> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007121.html
>


From peter.levart at gmail.com  Sun Apr 12 10:17:38 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 12 Apr 2020 12:17:38 +0200
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <37a34cbe-7ba1-2e2f-4160-0c03afc38b0b@gmail.com>
References: 
 <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com>
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 
 <82F1D053-984A-4D0B-B5C2-6A3CCBFA4C20@oracle.com>
 <5a9055d9-f553-716e-78b3-18b11128ad1a@oracle.com>
 
 <37a34cbe-7ba1-2e2f-4160-0c03afc38b0b@gmail.com>
Message-ID: <4063abfe-2571-9365-2a6b-730ea922e3b7@gmail.com>

Sorry to bother again, but I just realized something...

What Mandy is proposing as 'c' is probably the best choice. Why? 
Descriptors of the form "Lpac/kage/Name.suffix;" could safely be 
rejected by class loader, because they can't be derived from a valid 
fully qualified class name. When fully qualified class name is converted 
to descriptor, '.' are converted to '/'. Therefore a class can not 
contain '.' in simple name. There's no public API that would allow 
resolving such a class (I think). If you call:

Class.forName("pac.kage.Name.suffix");

It is interpreted as class with simple name "suffix" in package 
"pac.kage.Name". So Mandy's 'c' choice is a good choice. It has a 
bi-directional mapping:

Lpac/kage/Name.suffix; <-> pac.kage.Name/suffix

and doesn't need a sacrifice of a special character (like backslash).

So if class loader is made to reject names that contain '.' in them, 
nothing is sacrificed. Such class loader will still be able to load 
every class present today.

The problem is just that there is code out there that doesn't expect '/' 
in the FQN of the class or '.' in the descriptor and blindly just 
replaces one character with another. But would that really present a 
problem in practice? How often would such code meet a hidden class? JDK 
internal code could be changed to swap the 2 characters and 3rd party 
code would typically not see a hidden class.

Regards, Peter

On 4/12/20 11:26 AM, Peter Levart wrote:
> Just an illustration of why '\' - backslash might be a good choice... 
> I created the following experiment:
>
> package test;
> public class BackslashTest {
> ??? public static void main(String[] args) throws Exception {
> ??????? Class.forName("test.Name\\suffix");
> ??? }
> }
>
> ...when this is run by itself, it throws ClassNotFoundException as 
> expected. Then if I do the following in the compiled classes directory:
>
> touch 'test/Name\suffix.class'
>
> ...and re-run the program, I get "ClassFormatError: Truncated class 
> file", again as expected. But I did that on my Linux box. I then 
> packed the classes directory into a .jar file:
>
> META-INF/
> META-INF/MANIFEST.MF
> test/
> test/BackslashTest.class
> test/Name\suffix.class
>
> ... and extracted that jar on the Windows PC. What I get there is the 
> following extracted file structure:
>
> ?Directory of C:\Users\peter\tmp\test
>
> 04/12/2020? 10:55 AM??? ????????? .
> 04/12/2020? 10:55 AM??? ????????? ..
> 04/12/2020? 10:44 AM?????????????? 553 BackslashTest.class
> 04/12/2020? 11:58 AM??? ????????? Name
> ?????????????? 1 File(s)??????????? 553 bytes
>
> ?Directory of C:\Users\peter\tmp\test\Name
>
> 04/12/2020? 11:58 AM??? ????????? .
> 04/12/2020? 11:58 AM??? ????????? ..
> 04/12/2020? 10:46 AM???????????????? 0 suffix.class
> ?????????????? 1 File(s)????????????? 0 bytes
>
> ???? Total Files Listed:
> ?????????????? 2 File(s)??????????? 553 bytes
> ?????????????? 5 Dir(s)?? 9,659,174,912 bytes free
>
> ...if I run this with:
>
> java -cp . test.BackslashTest
>
> I again get "ClassFormatError: Truncated class file", which exposes a 
> strange implementation detail about mapping "valid" class name to the 
> path where .class file is found. At first this seems just that - 
> implementation detail, but this means that this mapping is not 
> bijective. There could be two class names that would map to the same 
> .class file. What I'm trying to say is that there are characters that 
> are valid in class names, but are unlikely to be chosen in practice by 
> a programming language because they are unfriendly to some practical 
> environment. In this respect `\` is such a character and therefore 
> could be used in the "name" of the hidden class as delimiter between 
> the name as it appears in the .class bytes and suffix. To play safe, 
> classloader should also be made to reject names where '\' appears in 
> the name of a class or package.
>
> WDYT?
>
> Regards, Peter
>
> On 4/12/20 10:28 AM, Peter Levart wrote:
>> Hi,
>>
>> Are '.' and '/' the only characters on the table? The problems with 
>> those are that both are used as hierarchical name delimiters in one 
>> way or another and code exists that converts one to another. If there 
>> was a 3rd character chosen such that:
>>
>> - it would make the descriptor "invalid" for resolving
>> - otherwise not be unexpected in parsing logic
>>
>> ...then such composition would be ideal. I think that there could 
>> event be a place for such names in the specification: syntactically 
>> valid but unresolvable names.
>>
>> The problem is that it is hard to find such a character isn't it? But 
>> let's try...
>>
>> What about character '\' - backslash ? It seems very unlikely that 
>> this character would appear in the name of a class. In Java language 
>> it is not allowed, but even in other languages it is probably treated 
>> as some kind of delimiter and therefore unlikely to be part of the 
>> derived class name. Would it be too much to declare that it must not 
>> appear in the name of the class?
>>
>> Even if it was not forbidden, it would be very unlikely to appear in 
>> practice. By analogy: Java anonymous classes are kind of "hidden", 
>> just on another level - in the language. They do use valid class 
>> names though, even valid in Java language, but there's no problem 
>> with that in practice. Why? Because the outer class typically 
>> controls the "namespace" where they appear in. With java modules, 
>> there is additional control that is imposed on the package namespace.
>>
>> Regards, Peter
>>
>>
>> On 4/12/20 5:35 AM, Mandy Chung wrote:
>>>
>>>
>>> On 4/8/20 3:35 PM, John Rose wrote:
>>>> On Apr 8, 2020, at 3:31 PM, John Rose >>> > wrote:
>>>>>
>>>>> In both c and c? there will probably be a cascading failure
>>>>> if the name foo/Bar/123Z or foo/Bar is resolved. ?In c? there
>>>>> is an additional cascading failure when the user that was
>>>>> parsing the signature goes back for more parameters and
>>>>> finds a slash (instead of LZBHCIJFD[). ?The thing that tipped
>>>>> me over to c? is that extra diagnostic: Even though it happens
>>>>> after the user picked up the bad descriptor, it happens closer
>>>>> to the place where the error has its root cause, which is that
>>>>> somebody is trying to parse an (intentionally) illegal descriptor.
>>>>
>>>> P.S. Having the slash+suffix *outside* the L; envelope basically
>>>> rubs any parser?s nose in the fact that there?s something illegal
>>>> here. ?Putting it inside the envelope hides the error from the
>>>> parser?which may be a good thing sometimes! ?But it means
>>>> that the odd name foo/Bar.123Z will float somewhere else
>>>> and may or may not be misinterpreted. ?If it?s handed to
>>>> Class.forName you can bet that the dot will change its meaning.
>>>> On balance, I slightly prefer the fail-fast properties of c?.
>>>
>>> Thanks John.
>>>
>>> I have implemented to define the descriptor string for a hidden 
>>> class of this form:
>>> ???? "L" + N + ";" + "/" + 
>>>
>>> Please see [1] for the review thread.
>>>
>>> For your reference, the webrev is:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/ 
>>>
>>>
>>> Specdiff:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html 
>>>
>>>
>>> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and
>>> `MethodType::descriptorString` are updated to return the descriptor of
>>> this form for a hidden class.?? To support hidden class,
>>> `java.lang.invoke.TypeDescriptor` spec is revised such that a
>>> `TypeDescriptor` object can represent an entity that may not be
>>> described in nominal form.?? The serviceability APIs that return a type
>>> descriptor are updated.? This webrev includes a couple other JVM TI and
>>> java.instrument spec clarification w.r.t. hidden classes.
>>>
>>> Mandy
>>> [1] 
>>> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007121.html
>>
>


From peter.levart at gmail.com  Sun Apr 12 11:13:28 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 12 Apr 2020 13:13:28 +0200
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <82F1D053-984A-4D0B-B5C2-6A3CCBFA4C20@oracle.com>
References: 
 <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com>
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 
 <82F1D053-984A-4D0B-B5C2-6A3CCBFA4C20@oracle.com>
Message-ID: <180061b8-0507-ca1e-5790-5076cd9b10d3@gmail.com>



On 4/9/20 12:35 AM, John Rose wrote:
> On Apr 8, 2020, at 3:31 PM, John Rose  wrote:
>> In both c and c? there will probably be a cascading failure
>> if the name foo/Bar/123Z or foo/Bar is resolved.  In c? there
>> is an additional cascading failure when the user that was
>> parsing the signature goes back for more parameters and
>> finds a slash (instead of LZBHCIJFD[).  The thing that tipped
>> me over to c? is that extra diagnostic: Even though it happens
>> after the user picked up the bad descriptor, it happens closer
>> to the place where the error has its root cause, which is that
>> somebody is trying to parse an (intentionally) illegal descriptor.
> P.S. Having the slash+suffix *outside* the L; envelope basically
> rubs any parser?s nose in the fact that there?s something illegal
> here.  Putting it inside the envelope hides the error from the
> parser?which may be a good thing sometimes!  But it means
> that the odd name foo/Bar.123Z will float somewhere else
> and may or may not be misinterpreted.  If it?s handed to
> Class.forName you can bet that the dot will change its meaning.
> On balance, I slightly prefer the fail-fast properties of c?.

The problem I see is that some "parsers" might only be concerned about 
for example counting the number of parameters in the method type 
descriptor. Suddenly the syntax for doing so has changed very much. With 
'c' there is no such problem. L; has long been the "envelope" and now it 
won't be any more.

I think that:

Class.forName("Ljava/lang/Object;");

or

Class.forName("java/lang/Object");

or

classLoader.loadClass("Ljava/lang/Object;");

or

classLoader.loadClass("java/lang/Object");

...are not valid (were some of them valid at some time in the past?).

So there's no problem of confusingly misinterpreting names of the form 
"foo/Bar.suffix" or "foo.Bar/suffix" in the public APIs.

I think it would be less problematic to adopt 'c' than 'c`' ...


Regards, Peter


From peter.levart at gmail.com  Sun Apr 12 11:37:17 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 12 Apr 2020 13:37:17 +0200
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: 
References: 
 <51580e39-f5f5-9759-2d4f-3b172bbef0ab@oracle.com>
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
Message-ID: <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>



On 4/8/20 11:46 PM, Mandy Chung wrote:
>
> Let's call this option c' as it's a modification to option c.? I want 
> to use `123Z` as a suffix example to indicate the significance of the 
> location of ';'.
>
> Option c:? `Lfoo/Bar.123Z;`
> Option c': `Lfoo/Bar;/123Z`
>
> If someone creates a MethodType with parameter types of a hidden 
> class, boolean and int, descriptorString() produces:
> ? ? `(Lfoo/Bar;/123ZZI)V`
> vs
> ??? `(Lfoo/Bar.123Z;ZI)V`
>
> ';' can help splitting the parameter descriptors properly in option c 
> that may benefit any error reporting whereas any error message to 
> report for option c' will have to include the entire string.
>
> Option c' has the nice property to retain the type descriptor of the 
> original bytes by appending a suffix.? On the other hand option c may 
> produce a human readable string that can be parsed easily e.g. to 
> indicate how many parameter types in this descriptor string.
>
> I'm uncertain of the impact of migration if any tool assumes ';' is 
> the end character for a reference type (JVM TI agents may be impacted 
> because JVM TI GetClassSignature returns a type descriptor).
>
> What are other benefits of c' over c?
>
> I'm currently leaning toward option c as the result string of a method 
> type is easier to parse and one fewer form of names (i.e. type 
> descriptor is "L" + CN + ";") where CN is N + "." + S and it's 
> `this_class` name of `newBytes` from which the hidden class is derived.

The problem is not that 'c' is easier to parse, but that 'c`' is not 
parsable at all. Do we really want unparsable method descriptors?

If the problem is preventing resolving of hidden class names or 
descriptors, then it seems that making the method descriptors unparsable 
is not the right place to do that.

Regards, Peter

>
>> Yes, it would be even simpler to throw an exception from
>> `Class::descriptorString` if the class is a HC.? But I think
>> that?s *too simple*, because it makes `descriptorString`
>> useless as an input to any class?s `toString` method.
>> I think that would be a mistake, in the long run.? String
>> producing methods are very useful for user output and
>> having them throw (or return null which is about as
>> surprising) is a sharp edge for anybody using them for
>> user output.? I could be wrong about that, and if the rest
>> of y?all are sure I?m wrong about that, go ahead and
>> throw an exception.? I?ll reserve the right to say ?I told
>> you so? when the appropriate time comes.
>>
>> ? John
>
> OK.?? I take the first pass on the spec. 
> `java.lang.invoke.TypeDescriptor::descriptorString` may produce an 
> invalid descriptor string.? This version implements option c but it's 
> very easy to switch to option c' (2-line change).
>
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/specdiff/overview-summary.html 
>
>
> webrev:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/webrev.01/ 
>
>
> Class::getName ??? ??? ??? `foo.Bar/123Z`
>
> Option c:
> ? Class::descriptorString? `Lfoo/Bar.123Z;`
> ? MethodType::descriptorString? `(Lfoo/Bar.123Z;ZI)V`
>
> If we choose option c', then:
> ? Class::descriptorString? `Lfoo/Bar;/123Z`
> MethodType::descriptorString? `(Lfoo/Bar;/123ZZI)V`
>
>
> Mandy


From forax at univ-mlv.fr  Sun Apr 12 12:14:44 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 12 Apr 2020 14:14:44 +0200 (CEST)
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
References: 
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
Message-ID: <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Peter Levart" 
> ?: "mandy chung" , "John Rose" , "Brian Goetz" 
> Cc: "valhalla-dev" 
> Envoy?: Dimanche 12 Avril 2020 13:37:17
> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??

> On 4/8/20 11:46 PM, Mandy Chung wrote:
>>
>> Let's call this option c' as it's a modification to option c.? I want
>> to use `123Z` as a suffix example to indicate the significance of the
>> location of ';'.
>>
>> Option c:? `Lfoo/Bar.123Z;`
>> Option c': `Lfoo/Bar;/123Z`
>>
>> If someone creates a MethodType with parameter types of a hidden
>> class, boolean and int, descriptorString() produces:
>> ? ? `(Lfoo/Bar;/123ZZI)V`
>> vs
>> ??? `(Lfoo/Bar.123Z;ZI)V`
>>
>> ';' can help splitting the parameter descriptors properly in option c
>> that may benefit any error reporting whereas any error message to
>> report for option c' will have to include the entire string.
>>
>> Option c' has the nice property to retain the type descriptor of the
>> original bytes by appending a suffix.? On the other hand option c may
>> produce a human readable string that can be parsed easily e.g. to
>> indicate how many parameter types in this descriptor string.
>>
>> I'm uncertain of the impact of migration if any tool assumes ';' is
>> the end character for a reference type (JVM TI agents may be impacted
>> because JVM TI GetClassSignature returns a type descriptor).
>>
>> What are other benefits of c' over c?
>>
>> I'm currently leaning toward option c as the result string of a method
>> type is easier to parse and one fewer form of names (i.e. type
>> descriptor is "L" + CN + ";") where CN is N + "." + S and it's
>> `this_class` name of `newBytes` from which the hidden class is derived.
> 
> The problem is not that 'c' is easier to parse, but that 'c`' is not
> parsable at all. Do we really want unparsable method descriptors?
> 
> If the problem is preventing resolving of hidden class names or
> descriptors, then it seems that making the method descriptors unparsable
> is not the right place to do that.

I agree with Peter,
throwing an exception is better, there is no way to encode a hidden class in a descriptor because a hidden class has no name you can lookup,
if the API return an unparsable method descriptor, the user code will throw an exception anyway.

> 
> Regards, Peter
> 

R?mi

>>
>>> Yes, it would be even simpler to throw an exception from
>>> `Class::descriptorString` if the class is a HC.? But I think
>>> that?s *too simple*, because it makes `descriptorString`
>>> useless as an input to any class?s `toString` method.
>>> I think that would be a mistake, in the long run.? String
>>> producing methods are very useful for user output and
>>> having them throw (or return null which is about as
>>> surprising) is a sharp edge for anybody using them for
>>> user output.? I could be wrong about that, and if the rest
>>> of y?all are sure I?m wrong about that, go ahead and
>>> throw an exception.? I?ll reserve the right to say ?I told
>>> you so? when the appropriate time comes.
>>>
>>> ? John
>>
>> OK.?? I take the first pass on the spec.
>> `java.lang.invoke.TypeDescriptor::descriptorString` may produce an
>> invalid descriptor string.? This version implements option c but it's
>> very easy to switch to option c' (2-line change).
>>
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/specdiff/overview-summary.html
>>
>>
>> webrev:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/webrev.01/
>>
>>
>> Class::getName ??? ??? ??? `foo.Bar/123Z`
>>
>> Option c:
>> ? Class::descriptorString? `Lfoo/Bar.123Z;`
>> ? MethodType::descriptorString? `(Lfoo/Bar.123Z;ZI)V`
>>
>> If we choose option c', then:
>> ? Class::descriptorString? `Lfoo/Bar;/123Z`
>> MethodType::descriptorString? `(Lfoo/Bar;/123ZZI)V`
>>
>>
> > Mandy

From brian.goetz at oracle.com  Sun Apr 12 16:15:29 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 12 Apr 2020 12:15:29 -0400
Subject: Fwd: Will lambdas be inline?
In-Reply-To: 
References: 
Message-ID: <3dcb2343-a86a-e0c3-e241-fa20efdf612b@oracle.com>

The below was received on the -comments list.

Short answer: Yes, this is very much under consideration; the identity 
of a lambda is irrelevant, and JLS 15.27.4 makes this clear:

> ??? This implies that the identity of the result of evaluating a 
> lambda expression (or, of serializing and deserializing a lambda 
> expression) is unpredictable, and therefore identity-sensitive 
> operations (such as reference equality (?15.21.3), object locking 
> (?14.19), and the System.identityHashCode method) may produce 
> different results in different implementations of the Java programming 
> language, or even upon different lambda expression evaluations in the 
> same implementation.
>

It is likely that this change will expose more opportunities for escape 
analysis, though it would likely not expose significant flatness/density 
optimizations since field descriptors / array components would never 
name the inline proxy directly.? Still, this is exactly the sort of 
optimization we had in mind when we penned the above flexibility in 15.27.4.

As to accidental behavioral compatibility concerns, this change will 
make _more_ lambdas equal to each other, since `==` on two lambda 
instances would no longer be an identity comparison, but a comparison of 
all the state of the lambda, so two otherwise-identical but separately 
constructed lambda proxies would be `==` if they were inline but might 
not be under the current situation, but it is unlikely to go in the 
other direction.

On the other hand, it will make `==` operations on lambdas slower.

Overall I'd like to see this change made, but we have to work through 
the details to ensure that it is not excessively surprising.


-------- Forwarded Message --------
Subject: 	Will lambdas be inline?
Date: 	Sat, 11 Apr 2020 21:14:22 -0700
From: 	Steven Stewart-Gallus 
To: 	valhalla-spec-comments at openjdk.java.net



Hi

I was curious if lambdas will be inline?
I feel this is pretty natural.
You're already not really supposed to be doing these kinds of things with
lambdas.
Technically you could spin both depending on the situation.

Correct me if I'm wrong but under the current plan you'd need to use
InlineCont for the best performance.

interface Cont {
Cont next();
}

interface InlineCont extends InlineObject {
InlineCont next();
}

interface IdentityCont extends IdentityObject {
IdentityCont next();
}

Slightly unfortunate because I think it's highly unlikely many interfaces
will break compat for a slight perf boost.

And if lambdas are inline than would IdentityCont not be a functional
interface?
Thanks
Steven Stewart-Gallus

From forax at univ-mlv.fr  Sun Apr 12 17:52:44 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 12 Apr 2020 19:52:44 +0200 (CEST)
Subject: Will lambdas be inline?
In-Reply-To: <3dcb2343-a86a-e0c3-e241-fa20efdf612b@oracle.com>
References: 
 <3dcb2343-a86a-e0c3-e241-fa20efdf612b@oracle.com>
Message-ID: <19950676.1243296.1586713964514.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Brian Goetz" 
> ?: "valhalla-dev" 
> Cc: stevenselectronicmail at gmail.com
> Envoy?: Dimanche 12 Avril 2020 18:15:29
> Objet: Fwd: Will lambdas be inline?

> The below was received on the -comments list.
> 
> Short answer: Yes, this is very much under consideration; the identity
> of a lambda is irrelevant, and JLS 15.27.4 makes this clear:
> 
>> ??? This implies that the identity of the result of evaluating a
>> lambda expression (or, of serializing and deserializing a lambda
>> expression) is unpredictable, and therefore identity-sensitive
>> operations (such as reference equality (?15.21.3), object locking
>> (?14.19), and the System.identityHashCode method) may produce
>> different results in different implementations of the Java programming
>> language, or even upon different lambda expression evaluations in the
>> same implementation.
>>
> 
> It is likely that this change will expose more opportunities for escape
> analysis, though it would likely not expose significant flatness/density
> optimizations since field descriptors / array components would never
> name the inline proxy directly.? Still, this is exactly the sort of
> optimization we had in mind when we penned the above flexibility in 15.27.4.
> 
> As to accidental behavioral compatibility concerns, this change will
> make _more_ lambdas equal to each other, since `==` on two lambda
> instances would no longer be an identity comparison, but a comparison of
> all the state of the lambda, so two otherwise-identical but separately
> constructed lambda proxies would be `==` if they were inline but might
> not be under the current situation, but it is unlikely to go in the
> other direction.
> 
> On the other hand, it will make `==` operations on lambdas slower.

I wanted to test the perf again, but it seems that currently == is broken :(

If i run
https://github.com/forax/valuetype-lworld/blob/master/src/main/java/fr.umlv.valuetype/fr/umlv/valuetype/StackOverflowACMP.java

It prints true.


> 
> Overall I'd like to see this change made, but we have to work through
> the details to ensure that it is not excessively surprising.

R?mi

> 
> 
> -------- Forwarded Message --------
> Subject: 	Will lambdas be inline?
> Date: 	Sat, 11 Apr 2020 21:14:22 -0700
> From: 	Steven Stewart-Gallus 
> To: 	valhalla-spec-comments at openjdk.java.net
> 
> 
> 
> Hi
> 
> I was curious if lambdas will be inline?
> I feel this is pretty natural.
> You're already not really supposed to be doing these kinds of things with
> lambdas.
> Technically you could spin both depending on the situation.
> 
> Correct me if I'm wrong but under the current plan you'd need to use
> InlineCont for the best performance.
> 
> interface Cont {
> Cont next();
> }
> 
> interface InlineCont extends InlineObject {
> InlineCont next();
> }
> 
> interface IdentityCont extends IdentityObject {
> IdentityCont next();
> }
> 
> Slightly unfortunate because I think it's highly unlikely many interfaces
> will break compat for a slight perf boost.
> 
> And if lambdas are inline than would IdentityCont not be a functional
> interface?
> Thanks
> Steven Stewart-Gallus

From hseigel at openjdk.java.net  Mon Apr 13 15:01:54 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 13 Apr 2020 15:01:54 GMT
Subject: [Integrated] [lworld] RFR: Change exception messages to say
 'Inline type' instead of 'Value type'
In-Reply-To: 
References: 
Message-ID: <20a01541-ce5f-4c0a-8706-c342cee8a92e@openjdk.org>

Changeset: aee9550c
Author:    Harold Seigel 
Date:      2020-04-13 15:01:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/aee9550c

Change exception messages to say 'Inline type' instead of 'Value type'

Reviewed-by: fparain

! src/hotspot/share/classfile/classFileParser.cpp
! test/hotspot/jtreg/runtime/valhalla/valuetypes/classfileparser/BadValueTypes.java

From mandy.chung at oracle.com  Mon Apr 13 19:09:25 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 13 Apr 2020 12:09:25 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
References: 
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
Message-ID: <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>



On 4/12/20 5:14 AM, Remi Forax wrote:
>> The problem is not that 'c' is easier to parse, but that 'c`' is not
>> parsable at all. Do we really want unparsable method descriptors?
>>
>> If the problem is preventing resolving of hidden class names or
>> descriptors, then it seems that making the method descriptors unparsable
>> is not the right place to do that.
> I agree with Peter,
> throwing an exception is better, there is no way to encode a hidden class in a descriptor because a hidden class has no name you can lookup,
> if the API return an unparsable method descriptor, the user code will throw an exception anyway.
>

Several points that are noteworthy:

1. A resolved method never has a hidden class in its signature as a 
hidden class cannot be discovered by any class loader.

2. When VM fails to resolve a symbolic reference to a hidden class, it 
might print its name or descriptor string in the error message. Lois and 
Harold can confirm if this should or should not cause any issue (I can't 
see how it would cause any issue yet).

3. The only way to get a method descriptor with a hidden class in it is 
by constructing `MethodType` with a `Class` object representing a hidden 
class.

4. `Class::descriptorString` on a hidden class is human-readable but not 
a valid descriptor (both option c and c')

5. The special character chosen by option c and c' is an illegal 
character for an unqualified name ("."? ";" "[" "/" see JVMS 4.2.2).? 
This way loading a class of the name of a hidden class will always get 
CNFE via bytecode linkage or Class::forName etc (either from 
Class::getName or mapped from Class::descriptorString).

For existing tools that map a descriptor string by trimming "L;" 
envelope and/or replacing "/" with ".",? "Lfoo/Foo;/123Z" (option c') 
may be mapped to "foo.Foo" and ".123Z" (if used ";" as a separator) or 
"foo.Foo/123Z" which are invalid name whereas "Lfoo/Foo.123Z;" (option 
c) may have higher chance be mapped to "foo.Foo.123Z" which is a valid 
binary name.

";" and "[" are already used for descriptor.? The remaining ones are "." 
and "/".

JDWP and JDI are examples of existing tools that obtain the type 
descriptor by calling JVM TI `GetClassSignature` and then trims the "L;" 
envelope and replace "/" with ".".??? Option c produces "foo.Foo.123Z" 
as the resulting string which might make it harder

6. Throwing an exception (option a) may make existing libraries to catch 
issues very early on.? I see the consistency that John made about 
dual-use APIs that prints a human-readable but not resolvable 
descriptor.? I got convinced that option c and c' have the benefit over 
option a.

7. Existing tools or scripts that parse the descriptor string have to be 
updated in both option c and c' to properly handle hidden classes.? 
Option c may just hide the problem which is bad if it's left unnoticed 
but happens in customer environments.

My only concern is the compatibility risk on existing agents that assume 
JVM TI `GetClassSignature` returns a valid type descriptor and use it to 
resolution. ? Both option c and c' return an invalid descriptor string 
and so I consider the impact is about the same. JDI and JDWP have to be 
updated to work with either new form.?? As John noted, option c' has the 
fail-fast properties that may help existing code to diagnose issues 
during migration.

That's my summary why I went with option c'.??? The preference is 
"slightly".

Any other thought?

Mandy
[1] 
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/

From forax at univ-mlv.fr  Mon Apr 13 20:05:04 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 13 Apr 2020 22:05:04 +0200 (CEST)
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
References: 
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
Message-ID: <1323487324.209768.1586808304566.JavaMail.zimbra@u-pem.fr>

> De: "mandy chung" 
> ?: "Remi Forax" , "Peter Levart" 
> Cc: "John Rose" , "Brian Goetz"
> , "valhalla-dev" 
> Envoy?: Lundi 13 Avril 2020 21:09:25
> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??

> On 4/12/20 5:14 AM, Remi Forax wrote:

>>> The problem is not that 'c' is easier to parse, but that 'c`' is not
>>> parsable at all. Do we really want unparsable method descriptors?

>>> If the problem is preventing resolving of hidden class names or
>>> descriptors, then it seems that making the method descriptors unparsable
>>> is not the right place to do that.

>> I agree with Peter,
>> throwing an exception is better, there is no way to encode a hidden class in a
>> descriptor because a hidden class has no name you can lookup,
>> if the API return an unparsable method descriptor, the user code will throw an
>> exception anyway.

> Several points that are noteworthy:

> 1. A resolved method never has a hidden class in its signature as a hidden class
> cannot be discovered by any class loader.

> 2. When VM fails to resolve a symbolic reference to a hidden class, it might
> print its name or descriptor string in the error message. Lois and Harold can
> confirm if this should or should not cause any issue (I can't see how it would
> cause any issue yet).

> 3. The only way to get a method descriptor with a hidden class in it is by
> constructing `MethodType` with a `Class` object representing a hidden class.

> 4. `Class::descriptorString` on a hidden class is human-readable but not a valid
> descriptor (both option c and c')

> 5. The special character chosen by option c and c' is an illegal character for
> an unqualified name ("." ";" "[" "/" see JVMS 4.2.2). This way loading a class
> of the name of a hidden class will always get CNFE via bytecode linkage or
> Class::forName etc (either from Class::getName or mapped from
> Class::descriptorString).

> For existing tools that map a descriptor string by trimming "L;" envelope and/or
> replacing "/" with ".", "Lfoo/Foo;/123Z" (option c') may be mapped to "foo.Foo"
> and ".123Z" (if used ";" as a separator) or "foo.Foo/123Z" which are invalid
> name whereas "Lfoo/Foo.123Z;" (option c) may have higher chance be mapped to
> "foo.Foo.123Z" which is a valid binary name.

> ";" and "[" are already used for descriptor. The remaining ones are "." and "/".

> JDWP and JDI are examples of existing tools that obtain the type descriptor by
> calling JVM TI `GetClassSignature` and then trims the "L;" envelope and replace
> "/" with ".". Option c produces "foo.Foo.123Z" as the resulting string which
> might make it harder

> 6. Throwing an exception (option a) may make existing libraries to catch issues
> very early on. I see the consistency that John made about dual-use APIs that
> prints a human-readable but not resolvable descriptor. I got convinced that
> option c and c' have the benefit over option a.

> 7. Existing tools or scripts that parse the descriptor string have to be updated
> in both option c and c' to properly handle hidden classes. Option c may just
> hide the problem which is bad if it's left unnoticed but happens in customer
> environments.

> My only concern is the compatibility risk on existing agents that assume JVM TI
> `GetClassSignature` returns a valid type descriptor and use it to resolution.
> Both option c and c' return an invalid descriptor string and so I consider the
> impact is about the same. JDI and JDWP have to be updated to work with either
> new form. As John noted, option c' has the fail-fast properties that may help
> existing code to diagnose issues during migration.

> That's my summary why I went with option c'. The preference is "slightly".

> Any other thought?
I think c' is good for GetClassSignature where throwing an exception is not something you can do, but for the Java side, Class.descriptorString(), i prefer to follow the adage "the blow early, blow often" because we can throw an exception as fast as we detect an error. Consistency between C and Java is a great ideal but not at the price of delaying the error reporting on the Java side. 

> Mandy
> [1] [
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/
> |
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/
> ]

R?mi 

From mandy.chung at oracle.com  Mon Apr 13 20:18:45 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 13 Apr 2020 13:18:45 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
References: 
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
Message-ID: 



On 4/13/20 12:09 PM, Mandy Chung wrote:
>
>
> On 4/12/20 5:14 AM, Remi Forax wrote:
>>> The problem is not that 'c' is easier to parse, but that 'c`' is not
>>> parsable at all. Do we really want unparsable method descriptors?
>>>
>>> If the problem is preventing resolving of hidden class names or
>>> descriptors, then it seems that making the method descriptors 
>>> unparsable
>>> is not the right place to do that.
>> I agree with Peter,
>> throwing an exception is better, there is no way to encode a hidden 
>> class in a descriptor because a hidden class has no name you can lookup,
>> if the API return an unparsable method descriptor, the user code will 
>> throw an exception anyway.
>>
>
> Several points that are noteworthy:
>
> 1. A resolved method never has a hidden class in its signature as a 
> hidden class cannot be discovered by any class loader.
>
> 2. When VM fails to resolve a symbolic reference to a hidden class, it 
> might print its name or descriptor string in the error message. Lois 
> and Harold can confirm if this should or should not cause any issue (I 
> can't see how it would cause any issue yet).
>
> 3. The only way to get a method descriptor with a hidden class in it 
> is by constructing `MethodType` with a `Class` object representing a 
> hidden class.
>
> 4. `Class::descriptorString` on a hidden class is human-readable but 
> not a valid descriptor (both option c and c')
>
> 5. The special character chosen by option c and c' is an illegal 
> character for an unqualified name ("."? ";" "[" "/" see JVMS 4.2.2).? 
> This way loading a class of the name of a hidden class will always get 
> CNFE via bytecode linkage or Class::forName etc (either from 
> Class::getName or mapped from Class::descriptorString).
>
> For existing tools that map a descriptor string by trimming "L;" 
> envelope and/or replacing "/" with ".",? "Lfoo/Foo;/123Z" (option c') 
> may be mapped to "foo.Foo" and ".123Z" (if used ";" as a separator) or 
> "foo.Foo/123Z" which are invalid name whereas "Lfoo/Foo.123Z;" (option 
> c) may have higher chance be mapped to "foo.Foo.123Z" which is a valid 
> binary name.
>
> ";" and "[" are already used for descriptor.? The remaining ones are 
> "." and "/".
>
> JDWP and JDI are examples of existing tools that obtain the type 
> descriptor by calling JVM TI `GetClassSignature` and then trims the 
> "L;" envelope and replace "/" with ".".??? Option c produces 
> "foo.Foo.123Z" as the resulting string which might make it harder
>
> 6. Throwing an exception (option a) may make existing libraries to 
> catch issues very early on.? I see the consistency that John made 
> about dual-use APIs that prints a human-readable but not resolvable 
> descriptor.? I got convinced that option c and c' have the benefit 
> over option a.
>
> 7. Existing tools or scripts that parse the descriptor string have to 
> be updated in both option c and c' to properly handle hidden classes.? 
> Option c may just hide the problem which is bad if it's left unnoticed 
> but happens in customer environments.
>
> My only concern is the compatibility risk on existing agents that 
> assume JVM TI `GetClassSignature` returns a valid type descriptor and 
> use it to resolution. ? Both option c and c' return an invalid 
> descriptor string and so I consider the impact is about the same. JDI 
> and JDWP have to be updated to work with either new form.?? As John 
> noted, option c' has the fail-fast properties that may help existing 
> code to diagnose issues during migration.
>
> That's my summary why I went with option c'.??? The preference is 
> "slightly".
> Any other thought?

Another consideration:
 ?? The name of an array class with a hidden class as its element type.

Option c -
 ?? `Class::getName` returns "[Lfoo.Foo/123Z;" and 
`Class::descriptorString` returns "[Lfoo/Foo.123Z;"

The name of array class for `HC[]` is "[" + "L" +  + ";"
The descriptor of array class for `HC[]` is "[" + 

Option c' -? what should `Class::getName` return?
(i) `Class::getName` "[Lfoo.Foo/123Z;" and `Class::descriptorString` 
returns "[Lfoo/Foo;/123Z"

The name of array class for `HC[]` is "[" + "L" +  + ";"
The descriptor of array class for `HC[]` is "[" + 

It is not trivially obvious to tell from the resulting name and 
descriptor string represent the same array class of HC[].
(ii) `Class::getName` "[Lfoo.Foo;/123Z" and `Class::descriptorString` 
returns "[Lfoo/Foo;/123Z"

"foo.Foo/123Z" is HC's class name and "[Lfoo.Foo;/123Z" isn't quite 
right to be the name of array class of HC.?? (i) is less awful.

Mandy

>
> Mandy
> [1] 
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/


From peter.levart at gmail.com  Tue Apr 14 09:16:51 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 14 Apr 2020 11:16:51 +0200
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
References: 
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
Message-ID: <05d1225a-bea8-9c01-e67c-262ff22008e0@gmail.com>



On 4/13/20 9:09 PM, Mandy Chung wrote:
>
>
> On 4/12/20 5:14 AM, Remi Forax wrote:
>>> The problem is not that 'c' is easier to parse, but that 'c`' is not
>>> parsable at all. Do we really want unparsable method descriptors?
>>>
>>> If the problem is preventing resolving of hidden class names or
>>> descriptors, then it seems that making the method descriptors unparsable
>>> is not the right place to do that.
>> I agree with Peter,
>> throwing an exception is better, there is no way to encode a hidden class in a descriptor because a hidden class has no name you can lookup,
>> if the API return an unparsable method descriptor, the user code will throw an exception anyway.
>>
>
> Several points that are noteworthy:
>
> 1. A resolved method never has a hidden class in its signature as a 
> hidden class cannot be discovered by any class loader.

Right.

>
> 2. When VM fails to resolve a symbolic reference to a hidden class, it 
> might print its name or descriptor string in the error message.? Lois 
> and Harold can confirm if this should or should not cause any issue (I 
> can't see how it would cause any issue yet).
>
> 3. The only way to get a method descriptor with a hidden class in it 
> is by constructing `MethodType` with a `Class` object representing a 
> hidden class.

Or by custom code that manipulates class descriptors using String 
operations. Suppose there's code that doesn't want to eagerly resolve 
types and just manipulates Strings. Surely a class descriptor of a HC 
can only be obtained when there *is* a HC already present, but ... never 
underestimate programmers' imagination when (s)he is combining 
information from various sources, some of them might be resolvable 
types, some might be just descriptors, etc...

>
> 4. `Class::descriptorString` on a hidden class is human-readable but 
> not a valid descriptor (both option c and c')
>
> 5. The special character chosen by option c and c' is an illegal 
> character for an unqualified name ("."? ";" "[" "/" see JVMS 4.2.2).? 
> This way loading a class of the name of a hidden class will always get 
> CNFE via bytecode linkage or Class::forName etc (either from 
> Class::getName or mapped from Class::descriptorString).

Right. The JVMS may remain unchanged. But that doesn't mean that 
Class.descriptorString() couldn't be specified to return a JVMS valid 
descriptor for classical named types, while for HCs (or derived types 
like arrays) it would return a special unresolvable descriptor with 
carefully specified syntax. Such a syntax that would play well when 
composed into the syntax of higher-level descriptors like method type 
descriptor. Why would we want that? Because by that we get a more 
predictable failure mode. We only fail when/if the type described by 
such descriptor tries to be resolved.

In this respect, both variants 'c' and 'c`' as you said, violate JVMS 
spec for valid class descriptor, but 'c' has a more carefully chosen syntax.

>
> For existing tools that map a descriptor string by trimming "L;" 
> envelope and/or replacing "/" with ".",? "Lfoo/Foo;/123Z" (option c') 
> may be mapped to "foo.Foo" and ".123Z" (if used ";" as a separator)...

I would say that for existing tools that treat a single class descriptor 
at once, with option 'c`' they won't treat ';' as a separator between 
multiple elements. I would say that existing code that tries to trim 
'L;' would either:

- remove the 'L' prefix and strip the string of ';' character wherever 
it is, which would produce "foo/Foo/123Z" and consequently 
"foo.Foo.123Z" (a valid binary name)
- grok and fail (for example because something that starts with 'L' does 
not end with ';')
- if the code is "hackish" it might blindly trim the last character if 
the 1st is '[', so we would end up with "foo/Foo;/123" and consequently 
with "foo.Foo;.123" (not a valid binary name)
- something else that neither of us can imagine now

> or "foo.Foo/123Z" which are invalid name whereas "Lfoo/Foo.123Z;" 
> (option c) may have higher chance be mapped to "foo.Foo.123Z" which is 
> a valid binary name.

Right, but neither is 'c`' immune to that interpretation. At least the 
failure mode of 'c' is more predictable.

>
> ";" and "[" are already used for descriptor.? The remaining ones are 
> "." and "/".
>
> JDWP and JDI are examples of existing tools that obtain the type 
> descriptor by calling JVM TI `GetClassSignature` and then trims the 
> "L;" envelope and replace "/" with ".".??? Option c produces 
> "foo.Foo.123Z" as the resulting string which might make it harder

And what does option 'c`' produce?

Existing JDK tools could be updated from day 0. Existing 3rd party tools 
would have to be updated too in either case. Typical failure mode for 
option 'c' would be that class "foo.Foo.123Z" can't be found. Who knows 
what kind of failure modes would option 'c`' produce if parsing was done 
in C for example. Are crashes excluded?

>
> 6. Throwing an exception (option a) may make existing libraries to 
> catch issues very early on.? I see the consistency that John made 
> about dual-use APIs that prints a human-readable but not resolvable 
> descriptor.? I got convinced that option c and c' have the benefit 
> over option a.
>
> 7. Existing tools or scripts that parse the descriptor string have to 
> be updated in both option c and c' to properly handle hidden classes.? 
> Option c may just hide the problem which is bad if it's left unnoticed 
> but happens in customer environments.

I doubt that the problem would be hidden with option 'c'. Either the 
code would just work (because it needs not resolve the descriptor of HC) 
or it would grok on trying to resolve it. In theory the binary name 
"foo.Foo.123Z" could be resolved into a real class, but that's hardly 
possible in practice unless you specifically construct such case. And 
option 'c`' is not immune to that as well. So I don't think that we 
would suddenly see a bunch of wrong resolvings where "foo.Foo.123Z" 
would actually be resolved successfully. You have a say in how the 
suffix in "foo.Foo/suffix" is constructed and by using something that is 
not a usual name the chances can be minimized.

>
> My only concern is the compatibility risk on existing agents that 
> assume JVM TI `GetClassSignature` returns a valid type descriptor and 
> use it to resolution. ? Both option c and c' return an invalid 
> descriptor string and so I consider the impact is about the same. ?? 
> JDI and JDWP have to be updated to work with either new form. As John 
> noted, option c' has the fail-fast properties that may help existing 
> code to diagnose issues during migration.
>
> That's my summary why I went with option c'.??? The preference is 
> "slightly".
>
> Any other thought?

I think that it is easier to debug a more predictable failure even if it 
happens a little later (when resolving the descriptor) than it is to 
debug an unpredictable (unimagined) failure which supposedly happens a 
little earlier. In that respect, option 'a' is most predictable, but it 
might be "to early" (for example, what if some code just wants to log 
the descriptor). And 'c`' seems a little scary to me, because I can't 
imagine all the possible failures.

Regards, Peter

>
> Mandy
> [1] 
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/


From peter.levart at gmail.com  Tue Apr 14 09:28:52 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 14 Apr 2020 11:28:52 +0200
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <1323487324.209768.1586808304566.JavaMail.zimbra@u-pem.fr>
References: 
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <1323487324.209768.1586808304566.JavaMail.zimbra@u-pem.fr>
Message-ID: 



On 4/13/20 10:05 PM, forax at univ-mlv.fr wrote:
>
>     That's my summary why I went with option c'.??? The preference is
>     "slightly".
>
>     Any other thought?
>
>
> I think c' is good for GetClassSignature where throwing an exception 
> is not something you can do, but for the Java side, 
> Class.descriptorString(), i prefer to follow the adage "the blow 
> early, blow often" because we can throw an exception as fast as we 
> detect an error.

But what if there was no error? I find conservative API helpful only as 
long as it doesn't prevent me from doing valid things or make me jump 
through hoops to achieve them.

> Consistency between C and Java is a great ideal but not at the price 
> of delaying the error reporting on the Java side.

You punish the programmer before (s)he even made an error on the 
assumption that (s)he probably would have made it.

This feels like "Minority Report".


Regards, Peter


From forax at univ-mlv.fr  Tue Apr 14 09:59:07 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 14 Apr 2020 11:59:07 +0200 (CEST)
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: 
References: 
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <1323487324.209768.1586808304566.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <1126887013.482765.1586858347955.JavaMail.zimbra@u-pem.fr>

> De: "Peter Levart" 
> ?: "Remi Forax" , "mandy chung" 
> Cc: "John Rose" , "Brian Goetz"
> , "valhalla-dev" 
> Envoy?: Mardi 14 Avril 2020 11:28:52
> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??

> On 4/13/20 10:05 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>> That's my summary why I went with option c'. The preference is "slightly".

>>> Any other thought?
>> I think c' is good for GetClassSignature where throwing an exception is not
>> something you can do, but for the Java side, Class.descriptorString(), i prefer
>> to follow the adage "the blow early, blow often" because we can throw an
>> exception as fast as we detect an error.

> But what if there was no error? I find conservative API helpful only as long as
> it doesn't prevent me from doing valid things or make me jump through hoops to
> achieve them.

>> Consistency between C and Java is a great ideal but not at the price of delaying
>> the error reporting on the Java side.

> You punish the programmer before (s)he even made an error on the assumption that
> (s)he probably would have made it.

> This feels like "Minority Report".
:) 

I think part of the issue here is that we don't agree about what descriptorString() is, 
The javadoc of TypeDescriptor.descriptorString() said that 
"[it] ... must be either a field type descriptor (JVMS 4.3.2) or method type descriptor (JVMS 4.3.3)" 

So it should be a *valid* descriptor, the problem with option c' is not valid because it changes the semantics of descriptorString(). 

Moreover, the javadoc of Class.descriptorString() explicitly reference Class.forName() and said that descriptorString() that is an incomplete dual of Class.forName(), 
so again, returning a non valid descriptor to have it to fail to resolve later is in my opinion non conform to the described semantics. 

So yes, you can print a non valid descriptor but that's not the point, the point is that there is no valid descriptor for a hidden class because you can not resolve a hidden class back to an equivalent runtime class. 

> Regards, Peter

regards, 
R?mi 

From peter.levart at gmail.com  Tue Apr 14 10:00:49 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 14 Apr 2020 12:00:49 +0200
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: 
References: 
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 
Message-ID: <11c38432-341f-de73-5747-c64f54445493@gmail.com>



On 4/13/20 10:18 PM, Mandy Chung wrote:
> Another consideration:
> ?? The name of an array class with a hidden class as its element type.
>
> Option c -
> ?? `Class::getName` returns "[Lfoo.Foo/123Z;" and 
> `Class::descriptorString` returns "[Lfoo/Foo.123Z;"
>
> The name of array class for `HC[]` is "[" + "L" +  + ";"
> The descriptor of array class for `HC[]` is "[" + 

See, higher-level descriptors still work.

>
> Option c' -? what should `Class::getName` return?
> (i) `Class::getName` "[Lfoo.Foo/123Z;" and `Class::descriptorString` 
> returns "[Lfoo/Foo;/123Z"
>
> The name of array class for `HC[]` is "[" + "L" +  + ";"
> The descriptor of array class for `HC[]` is "[" + 
>
> It is not trivially obvious to tell from the resulting name and 
> descriptor string represent the same array class of HC[].
> (ii) `Class::getName` "[Lfoo.Foo;/123Z" and `Class::descriptorString` 
> returns "[Lfoo/Foo;/123Z"
>
> "foo.Foo/123Z" is HC's class name and "[Lfoo.Foo;/123Z" isn't quite 
> right to be the name of array class of HC.?? (i) is less awful.

Another irregularity. How would one go from binary name to descriptor or 
back? Logic becomes complicated.

Peter

>
> Mandy


From dsimms at openjdk.java.net  Tue Apr 14 12:39:18 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 14 Apr 2020 12:39:18 GMT
Subject: [lworld] RFR: 8242496: [lworld] new and defaultvalue don't
 perform checks on class to instantiate
In-Reply-To: 
References: 
Message-ID: 

On Fri, 10 Apr 2020 16:37:27 GMT, Frederic Parain  wrote:

> The new and defaultvalue bytecodes currently lack a check to ensure that the class to instantiate is of the right kind.
> 
> These changes add checks in both slow and fast path of the interpreter.
> 
> Testing:
>   - unit test added
>   - mach5 tier 1 (all failures were pre-existing)

Looks good !

-------------

PR: https://git.openjdk.java.net/valhalla/pull/21

From dsimms at openjdk.java.net  Tue Apr 14 12:45:14 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 14 Apr 2020 12:45:14 GMT
Subject: [lworld] RFR: 8242496: [lworld] new and defaultvalue don't
 perform checks on class to instantiate
In-Reply-To: 
References: 
Message-ID: 

On Fri, 10 Apr 2020 16:37:27 GMT, Frederic Parain  wrote:

> The new and defaultvalue bytecodes currently lack a check to ensure that the class to instantiate is of the right kind.
> 
> These changes add checks in both slow and fast path of the interpreter.
> 
> Testing:
>   - unit test added
>   - mach5 tier 1 (all failures were pre-existing)

Looks good !

Marked as reviewed by dsimms (Committer).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/21

From frederic.parain at oracle.com  Tue Apr 14 13:31:00 2020
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 14 Apr 2020 09:31:00 -0400
Subject: [lworld] RFR: 8242496: [lworld] new and defaultvalue don't
 perform checks on class to instantiate
In-Reply-To: 
References: 
 
Message-ID: <2A76B9B5-B367-441E-8E7A-964D407FB3E1@oracle.com>

Thank you David.

Fred


> On Apr 14, 2020, at 08:45, David Simms  wrote:
> 
> On Fri, 10 Apr 2020 16:37:27 GMT, Frederic Parain  wrote:
> 
>> The new and defaultvalue bytecodes currently lack a check to ensure that the class to instantiate is of the right kind.
>> 
>> These changes add checks in both slow and fast path of the interpreter.
>> 
>> Testing:
>>  - unit test added
>>  - mach5 tier 1 (all failures were pre-existing)
> 
> Looks good !
> 
> Marked as reviewed by dsimms (Committer).
> 
> -------------
> 
> PR: https://git.openjdk.java.net/valhalla/pull/21


From fparain at openjdk.java.net  Tue Apr 14 13:34:31 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 14 Apr 2020 13:34:31 GMT
Subject: [Integrated] [lworld] RFR: 8242496 [lworld] new and defaultvalue
 don't perform checks on class to instantiate
In-Reply-To: 
References: 
Message-ID: <844a55c2-df97-477f-ac4a-a8ded0cabd61@openjdk.org>

Changeset: acffd197
Author:    Frederic Parain 
Date:      2020-04-14 13:33:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/acffd197

8242496: [lworld] new and defaultvalue don't perform checks on class to instantiate

Reviewed-by: dsimms

! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/interpreter/interpreterRuntime.hpp
! src/hotspot/share/oops/instanceKlass.hpp
+ test/hotspot/jtreg/runtime/valhalla/valuetypes/CreationErrorTest.java

From paul.sandoz at oracle.com  Tue Apr 14 18:51:44 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Apr 2020 11:51:44 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
 
Message-ID: <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>

Looks good to me (not familiar with all the code areas.

Minor suggestion:

MethodHandles.java

1811          * ASCII periods. For the instance of {@link java.lang.Class} representing {@code C}:
1812          * 
      
1813          * 
    •  {@link Class#getName()} returns the string {@code GN + "/" + },
1814          *      even though this is not a valid binary class or interface name.
      • 
1815          * 
    •  {@link Class#descriptorString()} returns the string
1816          *      {@code "L" + N + ";" + "/" +  },
1817          *      even though this is not a valid type descriptor name.
      • 
1818          * 
    

Add another bullet:

?
even though this is not a valid type descriptor name; and

- therefore {@link Class#describeConstable} returns an empty {@code Optional}.
?

?

Paul.

> On Apr 11, 2020, at 8:13 PM, Mandy Chung  wrote:
> 
> Please review the delta patch:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/
> 
> Incremental specdiff:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html
> This is to follow a discussion [1] on Class::descriptorString and MethodType::descriptorString for hidden classes.   The proposal is to define the descriptor string for a hidden class of this form:
>     "L" + N + ";" + "/" + 
> 
> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and `MethodType::descriptorString` are updated to return the descriptor of this form for a hidden class.   To support hidden class, `java.lang.invoke.TypeDescriptor` spec is revised such that a `TypeDescriptor` object can represent an entity that may not be described in nominal form.     This change affects JVM TI, JDWP and JDI.    The spec change includes a couple other JVM TI and java.instrument spec clarification w.r.t. hidden classes that Serguei has been working on.
> 
> 
> 
> Mandy
> [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html
> 
> ----------------
> As a record, the above patch is applied on the top:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/
> 
> webrev.06 includes the following changes that have been reviewed:
> 1. rename "weak hidden" and Klass::is_hidden_weak to is_non_strong_hidden
> 2. remove unused `setImplMethod` method from lambda proxy class
> 3. include Serguei's patch to fix JDK-8242166: regression in JDI ClassUnload events
> 4. drop the uniqueness guarantee of the suffix of the hidden class's name
> 
> On 3/31/20 8:01 PM, Mandy Chung wrote:
>> Thanks to the review feedbacks.
>> 
>> Updated webrev:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ 
>> Delta between webrev.03 and webrev.04:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ 
>> 
>> Summary of changes is:
>> 1. Update javac to retain the previous behavior when compiling to target release <= 14 where lambda proxy class is not a nestmate
>> 2. Rename Class::isHiddenClass to Class::isHidden
>> 3. Address Joe's feedback on the CSR to document the behavior of the relevant methods in java.lang.Class for hidden classes
>> 4. Add test case for unloadable class with nest host error
>> 5. Add test cases for hidden classes with different kinds of class or interface
>> 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class"
>> 7. Small changes in response to Remi, Coleen, Paul's review comments
>> 8. Fix copyright headers
>> 9. Fix @modules in tests
>> 
>> Most of the changes above have also been reviewed as separate patches.
>> 
>> Thanks
>> Mandy
>> 
>> On 3/26/20 4:57 PM, Mandy Chung wrote:
>>> Please review the implementation of JEP 371: Hidden Classes. The main changes are in core-libs and hotspot runtime area.  Small changes are made in javac, VM compiler (intrinsification of Class::isHiddenClass), JFR, JDI, and jcmd.  CSR [1]has been reviewed and is in the finalized state (see specdiff and javadoc below for reference).
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 
>>> 
>>> javadoc/specdiff
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ 
>>> 
>>> JVMS 5.4.4 change:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf 
>>> 
>>> CSR:
>>> https://bugs.openjdk.java.net/browse/JDK-8238359
>>> 
>>> Thanks
>>> Mandy
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502
>> 
> 


From mandy.chung at oracle.com  Tue Apr 14 23:45:04 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 14 Apr 2020 16:45:04 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <1126887013.482765.1586858347955.JavaMail.zimbra@u-pem.fr>
References: 
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <1323487324.209768.1586808304566.JavaMail.zimbra@u-pem.fr>
 
 <1126887013.482765.1586858347955.JavaMail.zimbra@u-pem.fr>
Message-ID: <75b3d2ef-dd80-b0d7-6186-322141121614@oracle.com>



On 4/14/20 2:59 AM, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"Peter Levart" 
>     *?: *"Remi Forax" , "mandy chung"
>     
>     *Cc: *"John Rose" , "Brian Goetz"
>     , "valhalla-dev"
>     
>     *Envoy?: *Mardi 14 Avril 2020 11:28:52
>     *Objet: *Re: java.lang.constant.ClassDesc and TypeDescriptor for
>     hidden class??
>
>
>
>     On 4/13/20 10:05 PM, forax at univ-mlv.fr wrote:
>
>             That's my summary why I went with option c'.??? The
>             preference is "slightly".
>
>             Any other thought?
>
>
>         I think c' is good for GetClassSignature where throwing an
>         exception is not something you can do, but for the Java side,
>         Class.descriptorString(), i prefer to follow the adage "the
>         blow early, blow often" because we can throw an exception as
>         fast as we detect an error.
>
>

A hidden class is like a normal class from JVM's perspective.? JVM TI 
class loading events are sent for hidden classes.? It's not surprised 
that existing agents may call GetClassSignature on hidden classes. ??? 
JDI also has APIs to return class signature.

If JVM TI GetClassSignature returns an error for hidden classes, it 
probably has higher compatibility impact.

With the descriptor string for a hidden class defined, 
`Class:descriptorString`, JVM TI `GetClassSignature` and? JDI signature 
related APIs should return the descriptor string consistently? (see 
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html)

The most important property is that the result string is not 
resolvable.? It will "blow early, blow often" when it attempts to get a 
ClassDesc from the result string.

>     But what if there was no error? I find conservative API helpful
>     only as long as it doesn't prevent me from doing valid things or
>     make me jump through hoops to achieve them.
>
>         Consistency between C and Java is a great ideal but not at the
>         price of delaying the error reporting on the Java side.
>
>
>     You punish the programmer before (s)he even made an error on the
>     assumption that (s)he probably would have made it.
>
>     This feels like "Minority Report".
>
>
> :)
>
> I think part of the issue here is that we don't agree about what 
> descriptorString() is,
> The javadoc of TypeDescriptor.descriptorString() said that
> "[it] ... must be either a field type descriptor (JVMS 4.3.2) or 
> method type descriptor (JVMS 4.3.3)"
>
> So it should be a *valid* descriptor, the problem with option c' is 
> not valid because it changes the semantics of descriptorString().
>
> Moreover, the javadoc of Class.descriptorString() explicitly reference 
> Class.forName() and said that descriptorString() that is an incomplete 
> dual of Class.forName(),
> so again, returning a non valid descriptor to have it to fail to 
> resolve later is in my opinion non conform to the described semantics.
>

For option c and c', `TypeDescriptor::descriptorString` and 
`Class:descriptorString` needs spec change to allow the returned string 
be an invalid type descriptor if it cannot be described nominally (see 
the proposed spec change [1]).

The key is that no spec change on `java.lang.constant` APIs.

> So yes, you can print a non valid descriptor but that's not the point, 
> the point is that there is no valid descriptor for a hidden class 
> because you can not resolve a hidden class back to an equivalent 
> runtime class.

Mandy
[1] 
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/specdiff/overview-summary.html

From dsimms at openjdk.java.net  Wed Apr 15 09:18:27 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 15 Apr 2020 09:18:27 GMT
Subject: [lworld] RFR: 8242269: [lworld] C2 compilation fails with assert
 "meet not symmetric"
In-Reply-To: <1M_5EHw99s-g3BwMRRiEQRlvwOawVr_pLttDVwmC2lU=.5d8673f9-946c-4c81-9448-b08cc6f692e5@github.com>
References: 
 <1M_5EHw99s-g3BwMRRiEQRlvwOawVr_pLttDVwmC2lU=.5d8673f9-946c-4c81-9448-b08cc6f692e5@github.com>
Message-ID: 

On Wed, 15 Apr 2020 09:14:01 GMT, David Simms  wrote:

>> This tweaks the type system to fix error triggered by the recent merge.
>
> Tested, works fine. Tobias talked last week about a fix from you Roland. Thanks for cleaning up.

Hit integrate if you are done (Tobias is out this week I think, if you were waiting on him)

-------------

PR: https://git.openjdk.java.net/valhalla/pull/20

From dsimms at openjdk.java.net  Wed Apr 15 09:18:27 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 15 Apr 2020 09:18:27 GMT
Subject: [lworld] RFR: 8242269: [lworld] C2 compilation fails with assert
 "meet not symmetric"
In-Reply-To: 
References: 
Message-ID: <1M_5EHw99s-g3BwMRRiEQRlvwOawVr_pLttDVwmC2lU=.5d8673f9-946c-4c81-9448-b08cc6f692e5@github.com>

On Thu, 9 Apr 2020 15:48:36 GMT, Roland Westrelin  wrote:

> This tweaks the type system to fix error triggered by the recent merge.

Tested, works fine. Tobias talked last week about a fix from you Roland. Thanks for cleaning up.

-------------

Marked as reviewed by dsimms (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/20

From roland at openjdk.java.net  Wed Apr 15 09:23:57 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 15 Apr 2020 09:23:57 GMT
Subject: [lworld] RFR: 8242269: [lworld] C2 compilation fails with assert
 "meet not symmetric"
In-Reply-To: 
References: 
 <1M_5EHw99s-g3BwMRRiEQRlvwOawVr_pLttDVwmC2lU=.5d8673f9-946c-4c81-9448-b08cc6f692e5@github.com>
 
Message-ID: 

On Wed, 15 Apr 2020 09:16:05 GMT, David Simms  wrote:

>> Tested, works fine. Tobias talked last week about a fix from you Roland. Thanks for cleaning up.
>
> Hit integrate if you are done (Tobias is out this week I think, if you were waiting on him)

I'd like Tobias to take a look at this. Integrating this is not urgent. Tobias disabled the new verification code that
triggered the failures. This fixes the failures that that verification code uncovered. They are not new failures. We
were just unaware of them.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/20

From dsimms at openjdk.java.net  Wed Apr 15 09:32:54 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 15 Apr 2020 09:32:54 GMT
Subject: [lworld] RFR: 8242269: [lworld] C2 compilation fails with assert
 "meet not symmetric"
In-Reply-To: 
References: 
 <1M_5EHw99s-g3BwMRRiEQRlvwOawVr_pLttDVwmC2lU=.5d8673f9-946c-4c81-9448-b08cc6f692e5@github.com>
 
 
Message-ID: 

On Wed, 15 Apr 2020 09:21:40 GMT, Roland Westrelin  wrote:

> I'd like Tobias to take a look at this. Integrating this is not urgent.

Fair enough, thank you !

-------------

PR: https://git.openjdk.java.net/valhalla/pull/20

From forax at univ-mlv.fr  Wed Apr 15 10:37:44 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 15 Apr 2020 12:37:44 +0200 (CEST)
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <75b3d2ef-dd80-b0d7-6186-322141121614@oracle.com>
References: 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <1323487324.209768.1586808304566.JavaMail.zimbra@u-pem.fr>
 
 <1126887013.482765.1586858347955.JavaMail.zimbra@u-pem.fr>
 <75b3d2ef-dd80-b0d7-6186-322141121614@oracle.com>
Message-ID: <1374271764.1061356.1586947064867.JavaMail.zimbra@u-pem.fr>

> De: "mandy chung" 
> ?: "Remi Forax" , "Peter Levart" 
> Cc: "John Rose" , "Brian Goetz"
> , "valhalla-dev" 
> Envoy?: Mercredi 15 Avril 2020 01:45:04
> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??

> On 4/14/20 2:59 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>> De: "Peter Levart" [ mailto:peter.levart at gmail.com |  ]
>>> ?: "Remi Forax" [ mailto:forax at univ-mlv.fr |  ] , "mandy
>>> chung" [ mailto:mandy.chung at oracle.com |  ]
>>> Cc: "John Rose" [ mailto:john.r.rose at oracle.com |  ] ,
>>> "Brian Goetz" [ mailto:brian.goetz at oracle.com |  ] ,
>>> "valhalla-dev" [ mailto:valhalla-dev at openjdk.java.net |
>>>  ]
>>> Envoy?: Mardi 14 Avril 2020 11:28:52
>>> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??

>>> On 4/13/20 10:05 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>>>> That's my summary why I went with option c'. The preference is "slightly".

>>>>> Any other thought?
>>>> I think c' is good for GetClassSignature where throwing an exception is not
>>>> something you can do, but for the Java side, Class.descriptorString(), i prefer
>>>> to follow the adage "the blow early, blow often" because we can throw an
>>>> exception as fast as we detect an error.

> A hidden class is like a normal class from JVM's perspective. JVM TI class
> loading events are sent for hidden classes. It's not surprised that existing
> agents may call GetClassSignature on hidden classes. JDI also has APIs to
> return class signature.

> If JVM TI GetClassSignature returns an error for hidden classes, it probably has
> higher compatibility impact.

> With the descriptor string for a hidden class defined, `Class:descriptorString`,
> JVM TI `GetClassSignature` and JDI signature related APIs should return the
> descriptor string consistently (see [
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html
> |
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html
> ] )

yes, that the consistency argument, all these methods should behave the same, i get that. 

> The most important property is that the result string is not resolvable. It will
> "blow early, blow often" when it attempts to get a ClassDesc from the result
> string.
Given that it's a field descriptor, it that can be passed to a library like ASM and the bug will be "hidden" until you get a VerifyError far from where the problem has occurred and with an error message people will not understand because it's not described in the JVMS. 
The class descriptor of an hidden class doesn't exist from the JVM spec POV. 

Moreover, i don't like the consistency argument because it hides the people part of the issue, JVM TI and JDI methods will never be used as often as Class::descriptorString and not by the same kind of people, 
Providing consistency to two mostly separate population (JVM engineer doesn't count, there are too few of them) is not very useful. 

I think it's important for Java people that are using/will use Class::descriptorString to have a Java experience (blow early) more than a C experience (the doc says you should not do that). 

>>> But what if there was no error? I find conservative API helpful only as long as
>>> it doesn't prevent me from doing valid things or make me jump through hoops to
>>> achieve them.

>>>> Consistency between C and Java is a great ideal but not at the price of delaying
>>>> the error reporting on the Java side.

>>> You punish the programmer before (s)he even made an error on the assumption that
>>> (s)he probably would have made it.

>>> This feels like "Minority Report".
>> :)

>> I think part of the issue here is that we don't agree about what
>> descriptorString() is,
>> The javadoc of TypeDescriptor.descriptorString() said that
>> "[it] ... must be either a field type descriptor (JVMS 4.3.2) or method type
>> descriptor (JVMS 4.3.3)"

>> So it should be a *valid* descriptor, the problem with option c' is not valid
>> because it changes the semantics of descriptorString().

>> Moreover, the javadoc of Class.descriptorString() explicitly reference
>> Class.forName() and said that descriptorString() that is an incomplete dual of
>> Class.forName(),
>> so again, returning a non valid descriptor to have it to fail to resolve later
>> is in my opinion non conform to the described semantics.

> For option c and c', `TypeDescriptor::descriptorString` and
> `Class:descriptorString` needs spec change to allow the returned string be an
> invalid type descriptor if it cannot be described nominally (see the proposed
> spec change [1]).
yes, but it's not a compatible spec change apart if the JVMS is changed too. 

> The key is that no spec change on `java.lang.constant` APIs.
I think you implicitly believe that usage of Class:descriptorString and ClassDesc are colocated. You can use TypeDescriptor to represent field descriptor at runtime to dynamically generate classes. In this kind of scenario, the `java.lang.constant` API is not in the picture. 

R?mi 

> Mandy
> [1] [
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/specdiff/overview-summary.html
> |
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/specdiff/overview-summary.html
> ]

From forax at univ-mlv.fr  Wed Apr 15 12:41:14 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 15 Apr 2020 14:41:14 +0200 (CEST)
Subject: Lookup.findStatic() triggers verification of nestmates attribute
 too early ?
Message-ID: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>

Hi all,
i've discovered that using Lookup.findStatic() triggers the verification that the attributes NestHost and the NestMembers are compatible.

I believe it's a bug, the equivalent code using bytecodes will no trigger this early verification, the verification is done lazily when a private member of a class of the nest is accessed the first time.

java.lang.IncompatibleClassChangeError: Type jdk.incubator.vector.Cell$VectorizedBackend$Template/0x0000000800457840 (loader: 'bootstrap') is not a nest member of jdk.incubator.vector.IntVector (loader: 'bootstrap'): current type is not listed as a nest member
       java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method)
       java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1084)
       java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1111)
       [...]

regards,
R?mi

From harold.seigel at oracle.com  Wed Apr 15 13:12:30 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Wed, 15 Apr 2020 09:12:30 -0400
Subject: Lookup.findStatic() triggers verification of nestmates attribute
 too early ?
In-Reply-To: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>
References: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>
Message-ID: <4209b6be-5ab1-4146-8462-f0703130f593@oracle.com>

Hi Remi,

Can you provide us with your failing test?

Also, did the failure occur with inline types or on a different repo?

Thanks, Harold

On 4/15/2020 8:41 AM, Remi Forax wrote:
> Hi all,
> i've discovered that using Lookup.findStatic() triggers the verification that the attributes NestHost and the NestMembers are compatible.
>
> I believe it's a bug, the equivalent code using bytecodes will no trigger this early verification, the verification is done lazily when a private member of a class of the nest is accessed the first time.
>
> java.lang.IncompatibleClassChangeError: Type jdk.incubator.vector.Cell$VectorizedBackend$Template/0x0000000800457840 (loader: 'bootstrap') is not a nest member of jdk.incubator.vector.IntVector (loader: 'bootstrap'): current type is not listed as a nest member
>         java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method)
>         java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1084)
>         java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1111)
>         [...]
>
> regards,
> R?mi

From forax at univ-mlv.fr  Wed Apr 15 13:27:00 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 15 Apr 2020 15:27:00 +0200 (CEST)
Subject: Lookup.findStatic() triggers verification of nestmates
 attribute too early ?
In-Reply-To: <4209b6be-5ab1-4146-8462-f0703130f593@oracle.com>
References: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>
 <4209b6be-5ab1-4146-8462-f0703130f593@oracle.com>
Message-ID: <2126213958.1136844.1586957220613.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Harold David Seigel" 
> ?: "valhalla-dev" 
> Envoy?: Mercredi 15 Avril 2020 15:12:30
> Objet: Re: Lookup.findStatic() triggers verification of nestmates attribute too early ?

> Hi Remi,
> 
> Can you provide us with your failing test?

I will create a reproducer, but it involves generating bytecodes using ASM,
i can generate the faulty class and base64 encode it as a String ?

> 
> Also, did the failure occur with inline types or on a different repo?

It's more for the nestmate branch, but it's a jdk15 issue,
may be i should have reported that issue on core-dev ?

> 
> Thanks, Harold

R?mi

> 
> On 4/15/2020 8:41 AM, Remi Forax wrote:
>> Hi all,
>> i've discovered that using Lookup.findStatic() triggers the verification that
>> the attributes NestHost and the NestMembers are compatible.
>>
>> I believe it's a bug, the equivalent code using bytecodes will no trigger this
>> early verification, the verification is done lazily when a private member of a
>> class of the nest is accessed the first time.
>>
>> java.lang.IncompatibleClassChangeError: Type
>> jdk.incubator.vector.Cell$VectorizedBackend$Template/0x0000000800457840
>> (loader: 'bootstrap') is not a nest member of jdk.incubator.vector.IntVector
>> (loader: 'bootstrap'): current type is not listed as a nest member
>>         java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method)
>>         java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1084)
>>         java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1111)
>>         [...]
>>
>> regards,
> > R?mi

From harold.seigel at oracle.com  Wed Apr 15 13:34:43 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Wed, 15 Apr 2020 09:34:43 -0400
Subject: Lookup.findStatic() triggers verification of nestmates attribute
 too early ?
In-Reply-To: <2126213958.1136844.1586957220613.JavaMail.zimbra@u-pem.fr>
References: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>
 <4209b6be-5ab1-4146-8462-f0703130f593@oracle.com>
 <2126213958.1136844.1586957220613.JavaMail.zimbra@u-pem.fr>
Message-ID: 

Hi Remi,

An ASM example would be fine.

This is a hotspot issue, not core-dev.

Thanks, Harold

On 4/15/2020 9:27 AM, Remi Forax wrote:
> ----- Mail original -----
>> De: "Harold David Seigel" 
>> ?: "valhalla-dev" 
>> Envoy?: Mercredi 15 Avril 2020 15:12:30
>> Objet: Re: Lookup.findStatic() triggers verification of nestmates attribute too early ?
>> Hi Remi,
>>
>> Can you provide us with your failing test?
> I will create a reproducer, but it involves generating bytecodes using ASM,
> i can generate the faulty class and base64 encode it as a String ?
>
>> Also, did the failure occur with inline types or on a different repo?
> It's more for the nestmate branch, but it's a jdk15 issue,
> may be i should have reported that issue on core-dev ?
>
>> Thanks, Harold
> R?mi
>
>> On 4/15/2020 8:41 AM, Remi Forax wrote:
>>> Hi all,
>>> i've discovered that using Lookup.findStatic() triggers the verification that
>>> the attributes NestHost and the NestMembers are compatible.
>>>
>>> I believe it's a bug, the equivalent code using bytecodes will no trigger this
>>> early verification, the verification is done lazily when a private member of a
>>> class of the nest is accessed the first time.
>>>
>>> java.lang.IncompatibleClassChangeError: Type
>>> jdk.incubator.vector.Cell$VectorizedBackend$Template/0x0000000800457840
>>> (loader: 'bootstrap') is not a nest member of jdk.incubator.vector.IntVector
>>> (loader: 'bootstrap'): current type is not listed as a nest member
>>>          java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method)
>>>          java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1084)
>>>          java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1111)
>>>          [...]
>>>
>>> regards,
>>> R?mi

From mandy.chung at oracle.com  Wed Apr 15 16:53:32 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 15 Apr 2020 09:53:32 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <1374271764.1061356.1586947064867.JavaMail.zimbra@u-pem.fr>
References: 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <1323487324.209768.1586808304566.JavaMail.zimbra@u-pem.fr>
 
 <1126887013.482765.1586858347955.JavaMail.zimbra@u-pem.fr>
 <75b3d2ef-dd80-b0d7-6186-322141121614@oracle.com>
 <1374271764.1061356.1586947064867.JavaMail.zimbra@u-pem.fr>
Message-ID: <6d661a88-b693-5a8f-3e7b-5f54beccd99c@oracle.com>



On 4/15/20 3:37 AM, forax at univ-mlv.fr wrote:
>
> Given that it's a field descriptor, it that can be passed to a library 
> like ASM and the bug will be "hidden" until you get a VerifyError far 
> from where the problem has occurred and with an error message people 
> will not understand because it's not described in the JVMS.
> The class descriptor of an hidden class doesn't exist from the JVM 
> spec POV.

BTW, the result string is *not* a field descriptor but rather a human 
readable string.??? The proposal is to change `TypeDescriptor` say that 
it has a field/method descriptor iff it can be described nominally.?? 
There may have `TypeDescriptor` objects that cannot be described 
nominally and in which case `descriptorString` produces a human-readable 
but unresolvable string.? This does not propose to change JVMS nor 
define a valid type descriptor for hidden class.

The only unpleasant property for this proposal is that `Class` 
implements TypeDescriptor and TypeDescriptor.OfField but not all `Class` 
objects have field descriptors.

Existing libraries that have the assumption that Class always has a type 
descriptor will need update to support hidden classes in any of the 
options.? Option (a) just saves the effort for the libraries as JDK does 
it for them but only applicable to the library that depends on 
`Class::descriptorString` which I expect not many such existing libraries.

OTOH I expect that ASM should never return a Type object for a hidden 
class.? For example Type::getType(Class c) may simply throw an 
exception if c is a hidden class.

I assume that Type::getObjectType and Type::getType(String 
typeDescriptor) and Type::getMethodType(String methodDescriptor) already 
validates if the given descriptor string is a valid field/method 
descriptor and throws IAE?

Indeed ASM will need some update to support hidden classes as its name 
cannot be referenced in the bytecode.?? Similarly for other libraries.

Mandy

From mandy.chung at oracle.com  Wed Apr 15 18:40:48 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 15 Apr 2020 11:40:48 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <05d1225a-bea8-9c01-e67c-262ff22008e0@gmail.com>
References: 
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <05d1225a-bea8-9c01-e67c-262ff22008e0@gmail.com>
Message-ID: <450d1483-2e24-d350-bbfa-1feed57a6659@oracle.com>

Hi Peter, Remi,

Lois and Harold have given further feedback.?? They are concerned with 
option c's impact to JVM implementations due to this new form of 
signature whose name is outside the "[;"] envelope? whereas signatures 
are always inside the "[;]" envelopes since day 1. Option c'? appears to 
have a higher compatibility risk not only in existing libraries but 
probably also VM implementations.

Option c has a low compatibility risk while existing code still needs to 
be updated to support hidden classes.? As John advices [1], it would be 
a mistake for `Class::descriptorString` to throw an exception in the 
long run.? We have exhausted the differences among these options.

Spec change proposal is:
- extend TypeDescriptor for entities that cannot be described 
nominally.? If it can be described nominally, 
TypeDescriptor::descriptorString returns a field/method descriptor 
conforming to JVMS 4.3.? If it cannot be described nominally, the result 
string is not a type descriptor.? No nominal descriptor can be produced.
- specify in the javadoc for Class::descriptorString and 
MethodType::descriptorString that the result string when it can be 
described nominally conforming to JVMS 4.3 or when it cannot be 
described nominally.
- No JVMS change

Here is the updated specdiff and webrev:
Specdiff:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-descriptor-string/overview-summary.html

Webrev:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/

Please review.
Thanks
Mandy
[1] 
https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html

On 4/14/20 2:16 AM, Peter Levart wrote:
>
>
> On 4/13/20 9:09 PM, Mandy Chung wrote:
>>
>>
>> On 4/12/20 5:14 AM, Remi Forax wrote:
>>>> The problem is not that 'c' is easier to parse, but that 'c`' is not
>>>> parsable at all. Do we really want unparsable method descriptors?
>>>>
>>>> If the problem is preventing resolving of hidden class names or
>>>> descriptors, then it seems that making the method descriptors 
>>>> unparsable
>>>> is not the right place to do that.
>>> I agree with Peter,
>>> throwing an exception is better, there is no way to encode a hidden 
>>> class in a descriptor because a hidden class has no name you can 
>>> lookup,
>>> if the API return an unparsable method descriptor, the user code 
>>> will throw an exception anyway.
>>>
>>
>> Several points that are noteworthy:
>>
>> 1. A resolved method never has a hidden class in its signature as a 
>> hidden class cannot be discovered by any class loader.
>
> Right.
>
>>
>> 2. When VM fails to resolve a symbolic reference to a hidden class, 
>> it might print its name or descriptor string in the error message.? 
>> Lois and Harold can confirm if this should or should not cause any 
>> issue (I can't see how it would cause any issue yet).
>>
>> 3. The only way to get a method descriptor with a hidden class in it 
>> is by constructing `MethodType` with a `Class` object representing a 
>> hidden class.
>
> Or by custom code that manipulates class descriptors using String 
> operations. Suppose there's code that doesn't want to eagerly resolve 
> types and just manipulates Strings. Surely a class descriptor of a HC 
> can only be obtained when there *is* a HC already present, but ... 
> never underestimate programmers' imagination when (s)he is combining 
> information from various sources, some of them might be resolvable 
> types, some might be just descriptors, etc...
>

True.? Our imagination is powerful!

The main thing is that a bad method descriptor will fail to resolve.

>>
>> 4. `Class::descriptorString` on a hidden class is human-readable but 
>> not a valid descriptor (both option c and c')
>>
>> 5. The special character chosen by option c and c' is an illegal 
>> character for an unqualified name ("."? ";" "[" "/" see JVMS 4.2.2).? 
>> This way loading a class of the name of a hidden class will always 
>> get CNFE via bytecode linkage or Class::forName etc (either from 
>> Class::getName or mapped from Class::descriptorString).
>
> Right. The JVMS may remain unchanged. But that doesn't mean that 
> Class.descriptorString() couldn't be specified to return a JVMS valid 
> descriptor for classical named types, while for HCs (or derived types 
> like arrays) it would return a special unresolvable descriptor with 
> carefully specified syntax. Such a syntax that would play well when 
> composed into the syntax of higher-level descriptors like method type 
> descriptor. Why would we want that? Because by that we get a more 
> predictable failure mode. We only fail when/if the type described by 
> such descriptor tries to be resolved.
>
> In this respect, both variants 'c' and 'c`' as you said, violate JVMS 
> spec for valid class descriptor, but 'c' has a more carefully chosen 
> syntax.
>

'c' keeps the "[;" envelope which is the long-standing format.

I would say putting the name inside the "[;" envelope may not break 
existing tools (for example if they never use the name to find the 
class) whereas putting the suffix following ';' is harder to predict how 
existing tools are impacted.

>>
>> For existing tools that map a descriptor string by trimming "L;" 
>> envelope and/or replacing "/" with ".",? "Lfoo/Foo;/123Z" (option c') 
>> may be mapped to "foo.Foo" and ".123Z" (if used ";" as a separator)...
>
> I would say that for existing tools that treat a single class 
> descriptor at once, with option 'c`' they won't treat ';' as a 
> separator between multiple elements. I would say that existing code 
> that tries to trim 'L;' would either:
>
> - remove the 'L' prefix and strip the string of ';' character wherever 
> it is, which would produce "foo/Foo/123Z" and consequently 
> "foo.Foo.123Z" (a valid binary name)
> - grok and fail (for example because something that starts with 'L' 
> does not end with ';')
> - if the code is "hackish" it might blindly trim the last character if 
> the 1st is '[', so we would end up with "foo/Foo;/123" and 
> consequently with "foo.Foo;.123" (not a valid binary name)
> - something else that neither of us can imagine now
>
>> or "foo.Foo/123Z" which are invalid name whereas "Lfoo/Foo.123Z;" 
>> (option c) may have higher chance be mapped to "foo.Foo.123Z" which 
>> is a valid binary name.
>
> Right, but neither is 'c`' immune to that interpretation. At least the 
> failure mode of 'c' is more predictable.
>
>>
>> ";" and "[" are already used for descriptor.? The remaining ones are 
>> "." and "/".
>>
>> JDWP and JDI are examples of existing tools that obtain the type 
>> descriptor by calling JVM TI `GetClassSignature` and then trims the 
>> "L;" envelope and replace "/" with ".".??? Option c produces 
>> "foo.Foo.123Z" as the resulting string which might make it harder
>
> And what does option 'c`' produce?
>
> Existing JDK tools could be updated from day 0. Existing 3rd party 
> tools would have to be updated too in either case. Typical failure 
> mode for option 'c' would be that class "foo.Foo.123Z" can't be found. 
> Who knows what kind of failure modes would option 'c`' produce if 
> parsing was done in C for example. Are crashes excluded?
>
>>
>> 6. Throwing an exception (option a) may make existing libraries to 
>> catch issues very early on.? I see the consistency that John made 
>> about dual-use APIs that prints a human-readable but not resolvable 
>> descriptor.? I got convinced that option c and c' have the benefit 
>> over option a.
>>
>> 7. Existing tools or scripts that parse the descriptor string have to 
>> be updated in both option c and c' to properly handle hidden 
>> classes.? Option c may just hide the problem which is bad if it's 
>> left unnoticed but happens in customer environments.
>
> I doubt that the problem would be hidden with option 'c'. Either the 
> code would just work (because it needs not resolve the descriptor of 
> HC) or it would grok on trying to resolve it. In theory the binary 
> name "foo.Foo.123Z" could be resolved into a real class, but that's 
> hardly possible in practice unless you specifically construct such 
> case. And option 'c`' is not immune to that as well. So I don't think 
> that we would suddenly see a bunch of wrong resolvings where 
> "foo.Foo.123Z" would actually be resolved successfully. You have a say 
> in how the suffix in "foo.Foo/suffix" is constructed and by using 
> something that is not a usual name the chances can be minimized.
>
>>
>> My only concern is the compatibility risk on existing agents that 
>> assume JVM TI `GetClassSignature` returns a valid type descriptor and 
>> use it to resolution. ? Both option c and c' return an invalid 
>> descriptor string and so I consider the impact is about the same. ?? 
>> JDI and JDWP have to be updated to work with either new form. As John 
>> noted, option c' has the fail-fast properties that may help existing 
>> code to diagnose issues during migration.
>>
>> That's my summary why I went with option c'.??? The preference is 
>> "slightly".
>>
>> Any other thought?
>
> I think that it is easier to debug a more predictable failure even if 
> it happens a little later (when resolving the descriptor) than it is 
> to debug an unpredictable (unimagined) failure which supposedly 
> happens a little earlier. In that respect, option 'a' is most 
> predictable, but it might be "to early" (for example, what if some 
> code just wants to log the descriptor). And 'c`' seems a little scary 
> to me, because I can't imagine all the possible failures.
> Regards, Peter

From david.holmes at oracle.com  Wed Apr 15 22:48:49 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Apr 2020 08:48:49 +1000
Subject: Lookup.findStatic() triggers verification of nestmates attribute
 too early ?
In-Reply-To: 
References: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>
 <4209b6be-5ab1-4146-8462-f0703130f593@oracle.com>
 <2126213958.1136844.1586957220613.JavaMail.zimbra@u-pem.fr>
 
Message-ID: 

On 15/04/2020 11:34 pm, Harold Seigel wrote:
> Hi Remi,
> 
> An ASM example would be fine.
> 
> This is a hotspot issue, not core-dev.

Depends what part of the code is triggering a nestmate access check.

David

> Thanks, Harold
> 
> On 4/15/2020 9:27 AM, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "Harold David Seigel" 
>>> ?: "valhalla-dev" 
>>> Envoy?: Mercredi 15 Avril 2020 15:12:30
>>> Objet: Re: Lookup.findStatic() triggers verification of nestmates 
>>> attribute too early ?
>>> Hi Remi,
>>>
>>> Can you provide us with your failing test?
>> I will create a reproducer, but it involves generating bytecodes using 
>> ASM,
>> i can generate the faulty class and base64 encode it as a String ?
>>
>>> Also, did the failure occur with inline types or on a different repo?
>> It's more for the nestmate branch, but it's a jdk15 issue,
>> may be i should have reported that issue on core-dev ?
>>
>>> Thanks, Harold
>> R?mi
>>
>>> On 4/15/2020 8:41 AM, Remi Forax wrote:
>>>> Hi all,
>>>> i've discovered that using Lookup.findStatic() triggers the 
>>>> verification that
>>>> the attributes NestHost and the NestMembers are compatible.
>>>>
>>>> I believe it's a bug, the equivalent code using bytecodes will no 
>>>> trigger this
>>>> early verification, the verification is done lazily when a private 
>>>> member of a
>>>> class of the nest is accessed the first time.
>>>>
>>>> java.lang.IncompatibleClassChangeError: Type
>>>> jdk.incubator.vector.Cell$VectorizedBackend$Template/0x0000000800457840
>>>> (loader: 'bootstrap') is not a nest member of 
>>>> jdk.incubator.vector.IntVector
>>>> (loader: 'bootstrap'): current type is not listed as a nest member
>>>>          
>>>> java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method)
>>>>          
>>>> java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1084) 
>>>>
>>>>          
>>>> java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1111) 
>>>>
>>>> ???????? [...]
>>>>
>>>> regards,
>>>> R?mi

From forax at univ-mlv.fr  Thu Apr 16 09:34:28 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 16 Apr 2020 11:34:28 +0200 (CEST)
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <450d1483-2e24-d350-bbfa-1feed57a6659@oracle.com>
References: 
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <05d1225a-bea8-9c01-e67c-262ff22008e0@gmail.com>
 <450d1483-2e24-d350-bbfa-1feed57a6659@oracle.com>
Message-ID: <1541470761.167586.1587029668585.JavaMail.zimbra@u-pem.fr>

Hi Mandy, 

We have forgotten MethodType.toMethodDescriptorString() [1], it has to be updated too. 

I still disagree with John, it's fine to use the scheme c' has a name for the Hidden Class. I still think the Java methods that says in their spec that they return a descriptor should return a valid descriptor thus throw an exception if there is a hidden class somewhere in the descriptor so a user has to decide how to handle Hidden Class before calling those methods. 
Anyway, we should move on that, the patch is fine for me if the javadoc of toMethodDescriptorString is updated too, so let's record that i disagree and move on. 

And for ASM, we have already talked to deprecate any methods that takes a live object in Type (j.l.Class and j.l.r.Method) because it causes surprising classloading loop when ASM is used in a classloader or in an agent, hidden class not having a proper name is another data point in that direction. 

regards, 
R?mi 

[1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/invoke/MethodType.html#toMethodDescriptorString() 

> De: "mandy chung" 
> ?: "Peter Levart" , "Remi Forax" 
> Cc: "John Rose" , "Brian Goetz"
> , "valhalla-dev" 
> Envoy?: Mercredi 15 Avril 2020 20:40:48
> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??

> Hi Peter, Remi,

> Lois and Harold have given further feedback. They are concerned with option c's
> impact to JVM implementations due to this new form of signature whose name is
> outside the "[;"] envelope whereas signatures are always inside the "[;]"
> envelopes since day 1. Option c' appears to have a higher compatibility risk
> not only in existing libraries but probably also VM implementations.

> Option c has a low compatibility risk while existing code still needs to be
> updated to support hidden classes. As John advices [1], it would be a mistake
> for `Class::descriptorString` to throw an exception in the long run. We have
> exhausted the differences among these options.

> Spec change proposal is:
> - extend TypeDescriptor for entities that cannot be described nominally. If it
> can be described nominally, TypeDescriptor::descriptorString returns a
> field/method descriptor conforming to JVMS 4.3. If it cannot be described
> nominally, the result string is not a type descriptor. No nominal descriptor
> can be produced.
> - specify in the javadoc for Class::descriptorString and
> MethodType::descriptorString that the result string when it can be described
> nominally conforming to JVMS 4.3 or when it cannot be described nominally.
> - No JVMS change

> Here is the updated specdiff and webrev:
> Specdiff:
> [
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-descriptor-string/overview-summary.html
> |
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-descriptor-string/overview-summary.html
> ]

> Webrev:
> [
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/
> |
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/
> ]

> Please review.
> Thanks
> Mandy
> [1] [
> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html |
> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html ]

> On 4/14/20 2:16 AM, Peter Levart wrote:

>> On 4/13/20 9:09 PM, Mandy Chung wrote:

>>> On 4/12/20 5:14 AM, Remi Forax wrote:

>>>>> The problem is not that 'c' is easier to parse, but that 'c`' is not
>>>>> parsable at all. Do we really want unparsable method descriptors?

>>>>> If the problem is preventing resolving of hidden class names or
>>>>> descriptors, then it seems that making the method descriptors unparsable
>>>>> is not the right place to do that.

>>>> I agree with Peter,
>>>> throwing an exception is better, there is no way to encode a hidden class in a
>>>> descriptor because a hidden class has no name you can lookup,
>>>> if the API return an unparsable method descriptor, the user code will throw an
>>>> exception anyway.

>>> Several points that are noteworthy:

>>> 1. A resolved method never has a hidden class in its signature as a hidden class
>>> cannot be discovered by any class loader.

>> Right.

>>> 2. When VM fails to resolve a symbolic reference to a hidden class, it might
>>> print its name or descriptor string in the error message. Lois and Harold can
>>> confirm if this should or should not cause any issue (I can't see how it would
>>> cause any issue yet).

>>> 3. The only way to get a method descriptor with a hidden class in it is by
>>> constructing `MethodType` with a `Class` object representing a hidden class.

>> Or by custom code that manipulates class descriptors using String operations.
>> Suppose there's code that doesn't want to eagerly resolve types and just
>> manipulates Strings. Surely a class descriptor of a HC can only be obtained
>> when there *is* a HC already present, but ... never underestimate programmers'
>> imagination when (s)he is combining information from various sources, some of
>> them might be resolvable types, some might be just descriptors, etc...

> True. Our imagination is powerful!

> The main thing is that a bad method descriptor will fail to resolve.

>>> 4. `Class::descriptorString` on a hidden class is human-readable but not a valid
>>> descriptor (both option c and c')

>>> 5. The special character chosen by option c and c' is an illegal character for
>>> an unqualified name ("." ";" "[" "/" see JVMS 4.2.2). This way loading a class
>>> of the name of a hidden class will always get CNFE via bytecode linkage or
>>> Class::forName etc (either from Class::getName or mapped from
>>> Class::descriptorString).

>> Right. The JVMS may remain unchanged. But that doesn't mean that
>> Class.descriptorString() couldn't be specified to return a JVMS valid
>> descriptor for classical named types, while for HCs (or derived types like
>> arrays) it would return a special unresolvable descriptor with carefully
>> specified syntax. Such a syntax that would play well when composed into the
>> syntax of higher-level descriptors like method type descriptor. Why would we
>> want that? Because by that we get a more predictable failure mode. We only fail
>> when/if the type described by such descriptor tries to be resolved.

>> In this respect, both variants 'c' and 'c`' as you said, violate JVMS spec for
>> valid class descriptor, but 'c' has a more carefully chosen syntax.

> 'c' keeps the "[;" envelope which is the long-standing format.

> I would say putting the name inside the "[;" envelope may not break existing
> tools (for example if they never use the name to find the class) whereas
> putting the suffix following ';' is harder to predict how existing tools are
> impacted.

>>> For existing tools that map a descriptor string by trimming "L;" envelope and/or
>>> replacing "/" with ".", "Lfoo/Foo;/123Z" (option c') may be mapped to "foo.Foo"
>>> and ".123Z" (if used ";" as a separator)...

>> I would say that for existing tools that treat a single class descriptor at
>> once, with option 'c`' they won't treat ';' as a separator between multiple
>> elements. I would say that existing code that tries to trim 'L;' would either:

>> - remove the 'L' prefix and strip the string of ';' character wherever it is,
>> which would produce "foo/Foo/123Z" and consequently "foo.Foo.123Z" (a valid
>> binary name)
>> - grok and fail (for example because something that starts with 'L' does not end
>> with ';')
>> - if the code is "hackish" it might blindly trim the last character if the 1st
>> is '[', so we would end up with "foo/Foo;/123" and consequently with
>> "foo.Foo;.123" (not a valid binary name)
>> - something else that neither of us can imagine now

>>> or "foo.Foo/123Z" which are invalid name whereas "Lfoo/Foo.123Z;" (option c) may
>>> have higher chance be mapped to "foo.Foo.123Z" which is a valid binary name.

>> Right, but neither is 'c`' immune to that interpretation. At least the failure
>> mode of 'c' is more predictable.

>>> ";" and "[" are already used for descriptor. The remaining ones are "." and "/".

>>> JDWP and JDI are examples of existing tools that obtain the type descriptor by
>>> calling JVM TI `GetClassSignature` and then trims the "L;" envelope and replace
>>> "/" with ".". Option c produces "foo.Foo.123Z" as the resulting string which
>>> might make it harder

>> And what does option 'c`' produce?

>> Existing JDK tools could be updated from day 0. Existing 3rd party tools would
>> have to be updated too in either case. Typical failure mode for option 'c'
>> would be that class "foo.Foo.123Z" can't be found. Who knows what kind of
>> failure modes would option 'c`' produce if parsing was done in C for example.
>> Are crashes excluded?

>>> 6. Throwing an exception (option a) may make existing libraries to catch issues
>>> very early on. I see the consistency that John made about dual-use APIs that
>>> prints a human-readable but not resolvable descriptor. I got convinced that
>>> option c and c' have the benefit over option a.

>>> 7. Existing tools or scripts that parse the descriptor string have to be updated
>>> in both option c and c' to properly handle hidden classes. Option c may just
>>> hide the problem which is bad if it's left unnoticed but happens in customer
>>> environments.

>> I doubt that the problem would be hidden with option 'c'. Either the code would
>> just work (because it needs not resolve the descriptor of HC) or it would grok
>> on trying to resolve it. In theory the binary name "foo.Foo.123Z" could be
>> resolved into a real class, but that's hardly possible in practice unless you
>> specifically construct such case. And option 'c`' is not immune to that as
>> well. So I don't think that we would suddenly see a bunch of wrong resolvings
>> where "foo.Foo.123Z" would actually be resolved successfully. You have a say in
>> how the suffix in "foo.Foo/suffix" is constructed and by using something that
>> is not a usual name the chances can be minimized.

>>> My only concern is the compatibility risk on existing agents that assume JVM TI
>>> `GetClassSignature` returns a valid type descriptor and use it to resolution.
>>> Both option c and c' return an invalid descriptor string and so I consider the
>>> impact is about the same. JDI and JDWP have to be updated to work with either
>>> new form. As John noted, option c' has the fail-fast properties that may help
>>> existing code to diagnose issues during migration.

>>> That's my summary why I went with option c'. The preference is "slightly".

>>> Any other thought?

>> I think that it is easier to debug a more predictable failure even if it happens
>> a little later (when resolving the descriptor) than it is to debug an
>> unpredictable (unimagined) failure which supposedly happens a little earlier.
>> In that respect, option 'a' is most predictable, but it might be "to early"
>> (for example, what if some code just wants to log the descriptor). And 'c`'
>> seems a little scary to me, because I can't imagine all the possible failures.

>> Regards, Peter

From sadayapalam at openjdk.java.net  Thu Apr 16 11:53:18 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 16 Apr 2020 11:53:18 GMT
Subject: [lworld] RFR: 8242900: [lworld] Allow an inline type to declare a
 superclass that meets specified restrictions
Message-ID: 

Here is a change set that implements the changes for

     https://bugs.openjdk.java.net/browse/JDK-8242900 ([lworld] Allow an inline type to declare a superclass that meets
     specified restrictions)
and its prerequisite blocker:
    https://bugs.openjdk.java.net/browse/JDK-8242912 (Abstract classes should not implement IdentityObject)

Here is a roadmap that would make it easier for you to review:

    - Go over to the JBS tickets above and read up the description of the tasks
    - Start with the new tests to understand what is being implemented and tested:
       
            test/langtools/tools/javac/valhalla/lworld-values/BinarySuperclassConstraints.java
            test/langtools/tools/javac/valhalla/lworld-values/BinarySuperclassConstraints.out
            test/langtools/tools/javac/valhalla/lworld-values/SuperclassCollections.java
            test/langtools/tools/javac/valhalla/lworld-values/SuperclassConstraints.java
            test/langtools/tools/javac/valhalla/lworld-values/SuperclassConstraints.out

     - Review of source files is best taken up in this order:
            Flags.java: defines two new flags to decorate classes with initializer blocks and empty no-arg constructor as being
            such. Attr.java:    During attribution flag classes that have initializer blocks and constructors that are empty no-arg
            constructors.
                              Arrange to check for constraints of a super class of an inline class.
            Check.java: Check the superclass's constraints when asked by the attributor.
            ClassReader.java: When reading class files, flags constructors that are empty no-arg constructors (save for chaining to
            super's no-arg ctor) compiler.properties: new errors.
            TransValues.java: In earlier versions, Inline types implicitly extended jlO, so any super() chaining call must be jlO's
            ctor. This is no longer the case. So remove the assertion. TreeInfo.java: Tweak to a utility method to make it more
            general and suitable for our present needs. TypeEnter.java: Earlier specs forbid an inline type declaration to have an
            extends clause. This is no longer illegal. So we don't error anymore. Abstract types should not implement the new top
            interface (IdentityObject)

    - These changes are simply rolling back prior changes made at the time of injection of new top interfaces. Because we
      don't inject them anymore for abstract classes, we should not encode them in "golden" files:
            test/jdk/java/lang/annotation/TypeAnnotationReflection.java
            test/jdk/java/lang/reflect/Generics/TestC1.java
            test/jdk/java/lang/reflect/Generics/TestC2.java
            test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations_2.out
            test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations_3.out
            test/langtools/tools/javap/AnnoTest.java

    - To shut up CheckExamples.java from spuriously failing, for the time being add the new compiler message keys to the
      white list:
            test/langtools/tools/javac/diags/examples.not-yet.txt

    - Other minorly modified tests that you may want to eyeball: (The diagnostics change a little bit since "extends" clause
      is no longer illegal. I have added -XDallowEmptyValues in some cases to exercise different code paths and elicit
      different diagnostics)

            test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.java
            test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.out
            test/langtools/tools/javac/valhalla/lworld-values/IllegalByValueTest2.out
            test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationTest.java
            test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationTest.out
            test/langtools/tools/javac/valhalla/lworld-values/ValueAnnotationTest.out
            test/langtools/tools/javac/valhalla/lworld-values/ValueModifierTest.out

    - This one is an odd man out: (Earlier Number implemented IdentityObject, but not anymore since it is abstract, so it is
      injected deeper now and surfaces - but this whole express injection is a temporary thing and will go away with
      JDK-8242612
        test/langtools/tools/javac/varargs/6806876/T6806876.out

-------------

Commit messages:
 - 8242900: Fix training white spaces
 - 8242900: Tests for supertypes constraints for inline types
 - 8242900: [lworld] Allow an inline type to declare a superclass that meets specified restrictions

Changes: https://git.openjdk.java.net/valhalla/pull/23/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/23/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242900
  Stats: 448 lines in 28 files changed: 397 ins; 11 del; 40 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/23.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/23/head:pull/23

PR: https://git.openjdk.java.net/valhalla/pull/23

From srikanth.adayapalam at oracle.com  Thu Apr 16 11:59:03 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Thu, 16 Apr 2020 17:29:03 +0530
Subject: [lworld] RFR: 8242900: [lworld] Allow an inline type to declare a
 superclass that meets specified restrictions
In-Reply-To: 
References: 
Message-ID: 


Hi Jim,

May I request you to please review this change ?? TIA. See below for a 
detailed instructions.

(I changed my mind: Rather than throw a large patch that implements the 
entire kitchen sink at the reviewers, I will divide it up into 3-4 
manageable chunks. Here is first set of changes)

Regards,
Srikanth

On 16/04/20 5:23 pm, Srikanth Adayapalam wrote:
> Here is a change set that implements the changes for
>
>       https://bugs.openjdk.java.net/browse/JDK-8242900 ([lworld] Allow an inline type to declare a superclass that meets
>       specified restrictions)
> and its prerequisite blocker:
>      https://bugs.openjdk.java.net/browse/JDK-8242912 (Abstract classes should not implement IdentityObject)
>
> Here is a roadmap that would make it easier for you to review:
>
>      - Go over to the JBS tickets above and read up the description of the tasks
>      - Start with the new tests to understand what is being implemented and tested:
>         
>              test/langtools/tools/javac/valhalla/lworld-values/BinarySuperclassConstraints.java
>              test/langtools/tools/javac/valhalla/lworld-values/BinarySuperclassConstraints.out
>              test/langtools/tools/javac/valhalla/lworld-values/SuperclassCollections.java
>              test/langtools/tools/javac/valhalla/lworld-values/SuperclassConstraints.java
>              test/langtools/tools/javac/valhalla/lworld-values/SuperclassConstraints.out
>
>       - Review of source files is best taken up in this order:
>              Flags.java: defines two new flags to decorate classes with initializer blocks and empty no-arg constructor as being
>              such. Attr.java:    During attribution flag classes that have initializer blocks and constructors that are empty no-arg
>              constructors.
>                                Arrange to check for constraints of a super class of an inline class.
>              Check.java: Check the superclass's constraints when asked by the attributor.
>              ClassReader.java: When reading class files, flags constructors that are empty no-arg constructors (save for chaining to
>              super's no-arg ctor) compiler.properties: new errors.
>              TransValues.java: In earlier versions, Inline types implicitly extended jlO, so any super() chaining call must be jlO's
>              ctor. This is no longer the case. So remove the assertion. TreeInfo.java: Tweak to a utility method to make it more
>              general and suitable for our present needs. TypeEnter.java: Earlier specs forbid an inline type declaration to have an
>              extends clause. This is no longer illegal. So we don't error anymore. Abstract types should not implement the new top
>              interface (IdentityObject)
>
>      - These changes are simply rolling back prior changes made at the time of injection of new top interfaces. Because we
>        don't inject them anymore for abstract classes, we should not encode them in "golden" files:
>              test/jdk/java/lang/annotation/TypeAnnotationReflection.java
>              test/jdk/java/lang/reflect/Generics/TestC1.java
>              test/jdk/java/lang/reflect/Generics/TestC2.java
>              test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations_2.out
>              test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations_3.out
>              test/langtools/tools/javap/AnnoTest.java
>
>      - To shut up CheckExamples.java from spuriously failing, for the time being add the new compiler message keys to the
>        white list:
>              test/langtools/tools/javac/diags/examples.not-yet.txt
>
>      - Other minorly modified tests that you may want to eyeball: (The diagnostics change a little bit since "extends" clause
>        is no longer illegal. I have added -XDallowEmptyValues in some cases to exercise different code paths and elicit
>        different diagnostics)
>
>              test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.java
>              test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.out
>              test/langtools/tools/javac/valhalla/lworld-values/IllegalByValueTest2.out
>              test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationTest.java
>              test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationTest.out
>              test/langtools/tools/javac/valhalla/lworld-values/ValueAnnotationTest.out
>              test/langtools/tools/javac/valhalla/lworld-values/ValueModifierTest.out
>
>      - This one is an odd man out: (Earlier Number implemented IdentityObject, but not anymore since it is abstract, so it is
>        injected deeper now and surfaces - but this whole express injection is a temporary thing and will go away with
>        JDK-8242612
>          test/langtools/tools/javac/varargs/6806876/T6806876.out
>
> -------------
>
> Commit messages:
>   - 8242900: Fix training white spaces
>   - 8242900: Tests for supertypes constraints for inline types
>   - 8242900: [lworld] Allow an inline type to declare a superclass that meets specified restrictions
>
> Changes: https://git.openjdk.java.net/valhalla/pull/23/files
>   Webrev: https://webrevs.openjdk.java.net/valhalla/23/webrev.00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8242900
>    Stats: 448 lines in 28 files changed: 397 ins; 11 del; 40 mod
>    Patch: https://git.openjdk.java.net/valhalla/pull/23.diff
>    Fetch: git fetch https://git.openjdk.java.net/valhalla pull/23/head:pull/23
>
> PR: https://git.openjdk.java.net/valhalla/pull/23


From mandy.chung at oracle.com  Thu Apr 16 16:33:16 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 16 Apr 2020 09:33:16 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <1541470761.167586.1587029668585.JavaMail.zimbra@u-pem.fr>
References: 
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <05d1225a-bea8-9c01-e67c-262ff22008e0@gmail.com>
 <450d1483-2e24-d350-bbfa-1feed57a6659@oracle.com>
 <1541470761.167586.1587029668585.JavaMail.zimbra@u-pem.fr>
Message-ID: 



On 4/16/20 2:34 AM, forax at univ-mlv.fr wrote:
> Hi Mandy,
>
> We have forgotten MethodType.toMethodDescriptorString() [1], it has to 
> be updated too.
>

It's not forgotten (I only didn't list it explicitly in the summary):

http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-descriptor-string/java.base/java/lang/invoke/MethodType.html


> I still disagree with John, it's fine to use the scheme c' has a name 
> for the Hidden Class. I still think the Java methods that says in 
> their spec that they return a descriptor should return a valid 
> descriptor thus throw an exception if there is a hidden class 
> somewhere in the descriptor so a user has to decide how to handle 
> Hidden Class before calling those methods.
> Anyway, we should move on that, the patch is fine for me if the 
> javadoc of toMethodDescriptorString is updated too, so let's record 
> that i disagree and move on.
>

It was updated:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/src/java.base/share/classes/java/lang/invoke/MethodType.java.sdiff.html

> And for ASM, we have already talked to deprecate any methods that 
> takes a live object in Type (j.l.Class and j.l.r.Method) because it 
> causes surprising classloading loop when ASM is used in a classloader 
> or in an agent, hidden class not having a proper name is another data 
> point in that direction.
>

Thanks.
Mandy

> regards,
> R?mi
>
> [1] 
> https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/invoke/MethodType.html#toMethodDescriptorString()
>
> ------------------------------------------------------------------------
>
>     *De: *"mandy chung" 
>     *?: *"Peter Levart" , "Remi Forax"
>     
>     *Cc: *"John Rose" , "Brian Goetz"
>     , "valhalla-dev"
>     
>     *Envoy?: *Mercredi 15 Avril 2020 20:40:48
>     *Objet: *Re: java.lang.constant.ClassDesc and TypeDescriptor for
>     hidden class??
>
>     Hi Peter, Remi,
>
>     Lois and Harold have given further feedback.?? They are concerned
>     with option c's impact to JVM implementations due to this new form
>     of signature whose name is outside the "[;"] envelope? whereas
>     signatures are always inside the "[;]" envelopes since day 1.??
>     Option c'? appears to have a higher compatibility risk not only in
>     existing libraries but probably also VM implementations.
>
>     Option c has a low compatibility risk while existing code still
>     needs to be updated to support hidden classes.? As John advices
>     [1], it would be a mistake for `Class::descriptorString` to throw
>     an exception in the long run.? We have exhausted the differences
>     among these options.
>
>     Spec change proposal is:
>     - extend TypeDescriptor for entities that cannot be described
>     nominally.? If it can be described nominally,
>     TypeDescriptor::descriptorString returns a field/method descriptor
>     conforming to JVMS 4.3.? If it cannot be described nominally, the
>     result string is not a type descriptor.? No nominal descriptor can
>     be produced.
>     - specify in the javadoc for Class::descriptorString and
>     MethodType::descriptorString that the result string when it can be
>     described nominally conforming to JVMS 4.3 or when it cannot be
>     described nominally.
>     - No JVMS change
>
>     Here is the updated specdiff and webrev:
>     Specdiff:
>     http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-descriptor-string/overview-summary.html
>
>     Webrev:
>     http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/
>
>     Please review.
>     Thanks
>     Mandy
>     [1]
>     https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html
>
>     On 4/14/20 2:16 AM, Peter Levart wrote:
>
>
>
>         On 4/13/20 9:09 PM, Mandy Chung wrote:
>
>
>
>             On 4/12/20 5:14 AM, Remi Forax wrote:
>
>                     The problem is not that 'c' is easier to parse,
>                     but that 'c`' is not
>                     parsable at all. Do we really want unparsable
>                     method descriptors?
>
>                     If the problem is preventing resolving of hidden
>                     class names or
>                     descriptors, then it seems that making the method
>                     descriptors unparsable
>                     is not the right place to do that.
>
>                 I agree with Peter,
>                 throwing an exception is better, there is no way to
>                 encode a hidden class in a descriptor because a hidden
>                 class has no name you can lookup,
>                 if the API return an unparsable method descriptor, the
>                 user code will throw an exception anyway.
>
>
>             Several points that are noteworthy:
>
>             1. A resolved method never has a hidden class in its
>             signature as a hidden class cannot be discovered by any
>             class loader.
>
>
>         Right.
>
>
>             2. When VM fails to resolve a symbolic reference to a
>             hidden class, it might print its name or descriptor string
>             in the error message.? Lois and Harold can confirm if this
>             should or should not cause any issue (I can't see how it
>             would cause any issue yet).
>
>             3. The only way to get a method descriptor with a hidden
>             class in it is by constructing `MethodType` with a `Class`
>             object representing a hidden class.
>
>
>         Or by custom code that manipulates class descriptors using
>         String operations. Suppose there's code that doesn't want to
>         eagerly resolve types and just manipulates Strings. Surely a
>         class descriptor of a HC can only be obtained when there *is*
>         a HC already present, but ... never underestimate programmers'
>         imagination when (s)he is combining information from various
>         sources, some of them might be resolvable types, some might be
>         just descriptors, etc...
>
>
>     True.? Our imagination is powerful!
>
>     The main thing is that a bad method descriptor will fail to resolve.
>
>
>             4. `Class::descriptorString` on a hidden class is
>             human-readable but not a valid descriptor (both option c
>             and c')
>
>             5. The special character chosen by option c and c' is an
>             illegal character for an unqualified name ("."? ";" "["
>             "/" see JVMS 4.2.2).? This way loading a class of the name
>             of a hidden class will always get CNFE via bytecode
>             linkage or Class::forName etc (either from Class::getName
>             or mapped from Class::descriptorString).
>
>
>         Right. The JVMS may remain unchanged. But that doesn't mean
>         that Class.descriptorString() couldn't be specified to return
>         a JVMS valid descriptor for classical named types, while for
>         HCs (or derived types like arrays) it would return a special
>         unresolvable descriptor with carefully specified syntax. Such
>         a syntax that would play well when composed into the syntax of
>         higher-level descriptors like method type descriptor. Why
>         would we want that? Because by that we get a more predictable
>         failure mode. We only fail when/if the type described by such
>         descriptor tries to be resolved.
>
>         In this respect, both variants 'c' and 'c`' as you said,
>         violate JVMS spec for valid class descriptor, but 'c' has a
>         more carefully chosen syntax.
>
>
>     'c' keeps the "[;" envelope which is the long-standing format.
>
>     I would say putting the name inside the "[;" envelope may not
>     break existing tools (for example if they never use the name to
>     find the class) whereas putting the suffix following ';' is harder
>     to predict how existing tools are impacted.
>
>
>             For existing tools that map a descriptor string by
>             trimming "L;" envelope and/or replacing "/" with ".",
>             "Lfoo/Foo;/123Z" (option c') may be mapped to "foo.Foo"
>             and ".123Z" (if used ";" as a separator)...
>
>
>         I would say that for existing tools that treat a single class
>         descriptor at once, with option 'c`' they won't treat ';' as a
>         separator between multiple elements. I would say that existing
>         code that tries to trim 'L;' would either:
>
>         - remove the 'L' prefix and strip the string of ';' character
>         wherever it is, which would produce "foo/Foo/123Z" and
>         consequently "foo.Foo.123Z" (a valid binary name)
>         - grok and fail (for example because something that starts
>         with 'L' does not end with ';')
>         - if the code is "hackish" it might blindly trim the last
>         character if the 1st is '[', so we would end up with
>         "foo/Foo;/123" and consequently with "foo.Foo;.123" (not a
>         valid binary name)
>         - something else that neither of us can imagine now
>
>             or "foo.Foo/123Z" which are invalid name whereas
>             "Lfoo/Foo.123Z;" (option c) may have higher chance be
>             mapped to "foo.Foo.123Z" which is a valid binary name.
>
>
>         Right, but neither is 'c`' immune to that interpretation. At
>         least the failure mode of 'c' is more predictable.
>
>
>             ";" and "[" are already used for descriptor.? The
>             remaining ones are "." and "/".
>
>             JDWP and JDI are examples of existing tools that obtain
>             the type descriptor by calling JVM TI `GetClassSignature`
>             and then trims the "L;" envelope and replace "/" with
>             ".".??? Option c produces "foo.Foo.123Z" as the resulting
>             string which might make it harder
>
>
>         And what does option 'c`' produce?
>
>         Existing JDK tools could be updated from day 0. Existing 3rd
>         party tools would have to be updated too in either case.
>         Typical failure mode for option 'c' would be that class
>         "foo.Foo.123Z" can't be found. Who knows what kind of failure
>         modes would option 'c`' produce if parsing was done in C for
>         example. Are crashes excluded?
>
>
>             6. Throwing an exception (option a) may make existing
>             libraries to catch issues very early on.? I see the
>             consistency that John made about dual-use APIs that prints
>             a human-readable but not resolvable descriptor. I got
>             convinced that option c and c' have the benefit over
>             option a.
>
>             7. Existing tools or scripts that parse the descriptor
>             string have to be updated in both option c and c' to
>             properly handle hidden classes.? Option c may just hide
>             the problem which is bad if it's left unnoticed but
>             happens in customer environments.
>
>
>         I doubt that the problem would be hidden with option 'c'.
>         Either the code would just work (because it needs not resolve
>         the descriptor of HC) or it would grok on trying to resolve
>         it. In theory the binary name "foo.Foo.123Z" could be resolved
>         into a real class, but that's hardly possible in practice
>         unless you specifically construct such case. And option 'c`'
>         is not immune to that as well. So I don't think that we would
>         suddenly see a bunch of wrong resolvings where "foo.Foo.123Z"
>         would actually be resolved successfully. You have a say in how
>         the suffix in "foo.Foo/suffix" is constructed and by using
>         something that is not a usual name the chances can be minimized.
>
>
>             My only concern is the compatibility risk on existing
>             agents that assume JVM TI `GetClassSignature` returns a
>             valid type descriptor and use it to resolution. ? Both
>             option c and c' return an invalid descriptor string and so
>             I consider the impact is about the same. ?? JDI and JDWP
>             have to be updated to work with either new form. As John
>             noted, option c' has the fail-fast properties that may
>             help existing code to diagnose issues during migration.
>
>             That's my summary why I went with option c'.??? The
>             preference is "slightly".
>
>             Any other thought?
>
>
>         I think that it is easier to debug a more predictable failure
>         even if it happens a little later (when resolving the
>         descriptor) than it is to debug an unpredictable (unimagined)
>         failure which supposedly happens a little earlier. In that
>         respect, option 'a' is most predictable, but it might be "to
>         early" (for example, what if some code just wants to log the
>         descriptor). And 'c`' seems a little scary to me, because I
>         can't imagine all the possible failures.
>
>         Regards, Peter
>
>


From mandy.chung at oracle.com  Thu Apr 16 16:45:27 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 16 Apr 2020 09:45:27 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
 
 <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>
Message-ID: <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com>

On 4/14/20 11:51 AM, Paul Sandoz wrote:
> Looks good to me (not familiar with all the code areas.
>
> Minor suggestion:
>
> MethodHandles.java
>
> 1811          * ASCII periods. For the instance of {@link java.lang.Class} representing {@code C}:
> 1812          * 
      
> 1813          * 
    •  {@link Class#getName()} returns the string {@code GN + "/" + },
> 1814          *      even though this is not a valid binary class or interface name.
      • 
> 1815          * 
    •  {@link Class#descriptorString()} returns the string
> 1816          *      {@code "L" + N + ";" + "/" +  },
> 1817          *      even though this is not a valid type descriptor name.
      • 
> 1818          * 
    
>
> Add another bullet:
>
> ?
> even though this is not a valid type descriptor name; and
>
> - therefore {@link Class#describeConstable} returns an empty {@code Optional}.
> ?
>
> ?

OK.?? I add this bullet:

- Class.describeConstable() returns an empty optional as C cannot be 
described in nominal form.

The webrev and spec was updated [1] for descriptor string to be of the 
form "Lfoo/Foo.1234;" to mitigate the compatibility risk.? Th

Specdiff with serviceability spec change:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/
Specdiff without svc spec change:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-descriptor-string/overview-summary.html

Webrev:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/

Svc spec change webrev:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/

thanks
Mandy
[1] 
https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007155.html


>
> Paul.
>
>> On Apr 11, 2020, at 8:13 PM, Mandy Chung  wrote:
>>
>> Please review the delta patch:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/
>>
>> Incremental specdiff:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html
>> This is to follow a discussion [1] on Class::descriptorString and MethodType::descriptorString for hidden classes.   The proposal is to define the descriptor string for a hidden class of this form:
>>      "L" + N + ";" + "/" + 
>>
>> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and `MethodType::descriptorString` are updated to return the descriptor of this form for a hidden class.   To support hidden class, `java.lang.invoke.TypeDescriptor` spec is revised such that a `TypeDescriptor` object can represent an entity that may not be described in nominal form.     This change affects JVM TI, JDWP and JDI.    The spec change includes a couple other JVM TI and java.instrument spec clarification w.r.t. hidden classes that Serguei has been working on.
>>
>>
>>
>> Mandy
>> [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html
>>
>> ----------------
>> As a record, the above patch is applied on the top:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/
>>
>> webrev.06 includes the following changes that have been reviewed:
>> 1. rename "weak hidden" and Klass::is_hidden_weak to is_non_strong_hidden
>> 2. remove unused `setImplMethod` method from lambda proxy class
>> 3. include Serguei's patch to fix JDK-8242166: regression in JDI ClassUnload events
>> 4. drop the uniqueness guarantee of the suffix of the hidden class's name
>>
>> On 3/31/20 8:01 PM, Mandy Chung wrote:
>>> Thanks to the review feedbacks.
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/
>>> Delta between webrev.03 and webrev.04:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/
>>>
>>> Summary of changes is:
>>> 1. Update javac to retain the previous behavior when compiling to target release <= 14 where lambda proxy class is not a nestmate
>>> 2. Rename Class::isHiddenClass to Class::isHidden
>>> 3. Address Joe's feedback on the CSR to document the behavior of the relevant methods in java.lang.Class for hidden classes
>>> 4. Add test case for unloadable class with nest host error
>>> 5. Add test cases for hidden classes with different kinds of class or interface
>>> 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class"
>>> 7. Small changes in response to Remi, Coleen, Paul's review comments
>>> 8. Fix copyright headers
>>> 9. Fix @modules in tests
>>>
>>> Most of the changes above have also been reviewed as separate patches.
>>>
>>> Thanks
>>> Mandy
>>>
>>> On 3/26/20 4:57 PM, Mandy Chung wrote:
>>>> Please review the implementation of JEP 371: Hidden Classes. The main changes are in core-libs and hotspot runtime area.  Small changes are made in javac, VM compiler (intrinsification of Class::isHiddenClass), JFR, JDI, and jcmd.  CSR [1]has been reviewed and is in the finalized state (see specdiff and javadoc below for reference).
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03
>>>>
>>>> javadoc/specdiff
>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/
>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/
>>>>
>>>> JVMS 5.4.4 change:
>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf
>>>>
>>>> CSR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8238359
>>>>
>>>> Thanks
>>>> Mandy
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502


From mandy.chung at oracle.com  Thu Apr 16 18:48:41 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 16 Apr 2020 11:48:41 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <330b7f12-4357-5f2f-7fa3-7896a1c3415e@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
 
 <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>
 <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com>
 <330b7f12-4357-5f2f-7fa3-7896a1c3415e@oracle.com>
Message-ID: 



On 4/16/20 11:42 AM, serguei.spitsyn at oracle.com wrote:
> Hi Mandy,
>
> I have a couple of minor comments on the Serviceability spec update.
>
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java.udiff.html
>
> ?Replace: "The returned name is the same form as ..." => "The returned 
> name is of the same form as ..."
>
>
> Example is:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/src/jdk.jdi/share/classes/com/sun/jdi/Type.java.udiff.html
>
> ? + * Returns the name of this type. The result is of the same form as
>
>
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java.udiff.html
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java.udiff.html
>
> Both files above have this: "a `class` file representation".
> It feels like something is wrong with the `class` part.
> Should it say `class file` or maybe use some other formatting?
>
> Otherwise, the Serviceability spec update looks great.
> I'll look at the non-Serviceability spec changes too.

Thanks for catching these typo/format issue.? I have fixed them in my 
local repo:

diff --git 
a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java 
b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
--- 
a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
+++ 
b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
@@ -391,7 +391,7 @@
 ????? * 
    
 ????? * A class or interface creation can be triggered by one of the 
following:
 ????? * 
      
-???? * 
    • by loading and deriving a class from a `class` file 
representation
+???? * 
    • by loading and deriving a class from a {@code class} file 
representation
 ????? *???? using class loader (see JVMS {@jvms 5.3}).
 ????? * 
    • by invoking {@link 
java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, 
java.lang.invoke.MethodHandles.Lookup.ClassOption...)
 ????? *???? Lookup::defineHiddenClass} that creates a {@link Class#isHidden
diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java 
b/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java
--- a/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java
+++ b/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java
@@ -85,7 +85,7 @@
 ?{
 ???? /**
 ????? * Returns the name of this {@code ReferenceType} object.
-???? * The returned name is the same form as the name returned by
+???? * The returned name is of the same form as the name returned by
 ????? * {@link Class#getName()}.
 ????? *
 ????? * @return a string containing the type name.
diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java 
b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
--- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
+++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
@@ -137,7 +137,7 @@
 ????? * 
      
 ????? * A class or interface creation can be triggered by one of the 
following:
 ????? * 
        
-???? * 
      • by loading and deriving a class from a `class` file 
representation
+???? * 
      • by loading and deriving a class from a {@code class} file 
representation
 ????? *???? using class loader (see JVMS {@jvms 5.3}).
 ????? * 
      • by invoking {@link 
java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, 
java.lang.invoke.MethodHandles.Lookup.ClassOption...)
 ????? *???? Lookup::defineHiddenClass} that creates a {@link Class#isHidden

Mandy

From john.r.rose at oracle.com  Thu Apr 16 21:58:40 2020
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 16 Apr 2020 14:58:40 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <450d1483-2e24-d350-bbfa-1feed57a6659@oracle.com>
References: 
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <05d1225a-bea8-9c01-e67c-262ff22008e0@gmail.com>
 <450d1483-2e24-d350-bbfa-1feed57a6659@oracle.com>
Message-ID: <37BC1E55-F5A6-4558-995D-2C172EBE9195@oracle.com>

On Apr 15, 2020, at 11:40 AM, Mandy Chung  wrote:
> 
> Hi Peter, Remi,

FTR, I am fine with either c or c?.  I suppose I weigh the risks slightly
differently, leading to a slight preference for c? over c, but I?m very
happy with either, because they allow descriptorString to be dual
use just as Class.getName is dual use.  Adjusting the API docs to make
the distinction between nominally described entities and others
is an excellent step.

In fact, it might be a nice idea (not required though) to link the javadoc
for Class.getName to Class.descriptorString, and note that Class.getName
returns a resolvable name (via Class.forName) when Class.descriptorString
is a valid descriptor?except (oops) for primitives.  This could be a followup
change.

(BTW, are there test cases that cover arrays of hidden-classes, and their
Class.descriptorString and Class.getName?)

> Lois and Harold have given further feedback.   They are concerned with option c's impact to JVM implementations due to this new form of signature whose name is outside the "[;"] envelope  whereas signatures are always inside the "[;]" envelopes since day 1.   Option c'  appears to have a higher compatibility risk not only in existing libraries but probably also VM implementations.

Adopting c over c? pushes the risk around, out of the JVM and into
user-written code in places like ASM.  The risk is small, so it?s probably
easy to tolerate.  Specifically, if the user-written code calls String.replace
to change ?/? to ?.? then the distinction of the last dot will be lost.
Such is life.  The resulting spurious class name will almost certainly
not resolve, right?  And it?s the responsibility of the user-written code
to decide (a) whether HC?s are possible inputs, and (b) what policy to
take toward such inputs.

? John

From john.r.rose at oracle.com  Thu Apr 16 22:05:34 2020
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 16 Apr 2020 15:05:34 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <1541470761.167586.1587029668585.JavaMail.zimbra@u-pem.fr>
References: 
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <05d1225a-bea8-9c01-e67c-262ff22008e0@gmail.com>
 <450d1483-2e24-d350-bbfa-1feed57a6659@oracle.com>
 <1541470761.167586.1587029668585.JavaMail.zimbra@u-pem.fr>
Message-ID: 

On Apr 16, 2020, at 2:34 AM, forax at univ-mlv.fr wrote:
> 
> We have forgotten MethodType.toMethodDescriptorString() [1], it has to be updated too.

Good catch.

> I still disagree with John, it's fine to use the scheme c' has a name for the Hidden Class. I still think the Java methods that says in their spec that they return a descriptor should return a valid descriptor thus throw an exception if there is a hidden class somewhere in the descriptor so a user has to decide how to handle Hidden Class before calling those methods.

We disagree mainly because I think Class::getName returning a specious but
informative name is a solid precedent, and that it applies to the present case.
There?s always going to be a crack or two in the scheme when (a) unchecked
strings are translated into resolvable names, and even more when (b) unresolvable
entities have to state their names.  The point here is to move the cracks where
fewer people will stumble over them, and those who stumble can recover easily.
Since that?s a judgement call, it?s not surprising there are varieties of opinion.

> Anyway, we should move on that, the patch is fine for me if the javadoc of toMethodDescriptorString is updated too, so let's record that i disagree and move on.

Thank you.

> And for ASM, we have already talked to deprecate any methods that takes a live object in Type (j.l.Class and j.l.r.Method) because it causes surprising classloading loop when ASM is used in a classloader or in an agent, hidden class not having a proper name is another data point in that direction.


Good point.  That?s an example of what I said in the previous email,
about library authors having to make their own choices regarding
HC inputs.

I?m glad we are moving towards better documentation of Class and
MethodType instances which do not have nominal descriptions.
That is a very good side effect of these picky discussions.

? John

From mandy.chung at oracle.com  Thu Apr 16 22:23:03 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 16 Apr 2020 15:23:03 -0700
Subject: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
In-Reply-To: <37BC1E55-F5A6-4558-995D-2C172EBE9195@oracle.com>
References: 
 
 <1ade2ac8-c61a-54aa-4a8c-7ad0513524e4@oracle.com>
 <167a2e8c-e524-e58d-01cd-bf5f9d353ba0@oracle.com>
 <5093A49E-14BE-4662-8F8A-F0E8B1E0C146@oracle.com>
 
 
 <6b8340ae-475a-1021-93c3-ffa2009e1725@gmail.com>
 <291757203.1208792.1586693684801.JavaMail.zimbra@u-pem.fr>
 <1165154b-a5d4-0569-5dbe-18cec27374d1@oracle.com>
 <05d1225a-bea8-9c01-e67c-262ff22008e0@gmail.com>
 <450d1483-2e24-d350-bbfa-1feed57a6659@oracle.com>
 <37BC1E55-F5A6-4558-995D-2C172EBE9195@oracle.com>
Message-ID: 



On 4/16/20 2:58 PM, John Rose wrote:
> (BTW, are there test cases that cover arrays of hidden-classes, and their
> Class.descriptorString and Class.getName?)

Yes there are.

http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java.sdiff.html

thanks
Mandy

From chris.plummer at oracle.com  Fri Apr 17 22:51:41 2020
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 17 Apr 2020 15:51:41 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
 
 <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>
 <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com>
Message-ID: <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com>

On 4/16/20 9:45 AM, Mandy Chung wrote:
> On 4/14/20 11:51 AM, Paul Sandoz wrote:
>> Looks good to me (not familiar with all the code areas.
>>
>> Minor suggestion:
>>
>> MethodHandles.java
>>
>> 1811????????? * ASCII periods. For the instance of {@link 
>> java.lang.Class} representing {@code C}:
>> 1812????????? * 
          
>> 1813????????? * 
        •  {@link Class#getName()} returns the string 
>> {@code GN + "/" + },
>> 1814????????? *????? even though this is not a valid binary class or 
>> interface name.
          • 
>> 1815????????? * 
        •  {@link Class#descriptorString()} returns the string
>> 1816????????? *????? {@code "L" + N + ";" + "/" +  },
>> 1817????????? *????? even though this is not a valid type descriptor 
>> name.
          • 
>> 1818????????? * 
        
>>
>> Add another bullet:
>>
>> ?
>> even though this is not a valid type descriptor name; and
>>
>> - therefore {@link Class#describeConstable} returns an empty {@code 
>> Optional}.
>> ?
>>
>> ?
>
> OK.?? I add this bullet:
>
> - Class.describeConstable() returns an empty optional as C cannot be 
> described in nominal form.
>
> The webrev and spec was updated [1] for descriptor string to be of the 
> form "Lfoo/Foo.1234;" to mitigate the compatibility risk.? Th
>
> Specdiff with serviceability spec change:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/ 
>
> Specdiff without svc spec change:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-descriptor-string/overview-summary.html 
>
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/ 
>
>
> Svc spec change webrev:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/ 
>
>
> thanks
> Mandy
> [1] 
> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007155.html

Hi Mandy,

Thanks for updating the svc specs. Some comments below:


In the JDWP spec update, you changed "JNI signature" to "type signature" 
in one place, but left it as "JNI signature" everywhere else. Should 
they all be changed?


In the JDWP spec for ClassLoaderReference.VisibleClasses:

 ?"That is, this class loader has been recorded as an initiating 
loader of the returned classes." -> "That is, all classes for which this 
class loader has been recorded as an initiating loader."

This seems like too much detail to be put here. Basically the term 
"initiating ClassLoader" has turned into a short essay. Is it possible 
that all this detail could be put elsewhere and referenced? Aren't there 
other places in other specs where a similar clarification of "initiating 
ClassLoader" is needed (I see now that ClassLoaderClasses in the JVMTI 
spec, ClassLoaderReference,visibleClasses in the JDI spec, and 
Instrumentation.getInitiatedClasses are all dealing with this, but not 
all in the exact same way).


In the JVMTI spec for GetLoadedClasses:

This suffers in a way similar to ClassLoaderReference.VisibleClasses in 
the JDWP spec, although not as badly. A simple concept ends up with a 
complex description, and it seems that description should really be in a 
more centralized place. I would also suggest a bit of cleanup of these 
lines:

6866???????? An array class is created directly by Java virtual 
machine.? An array class
6867???????? creation can be triggered by using class loaders or by 
invoking methods in certain
6868???????? Java SE Platform API such as reflection.

"Created by [the] Java virtual machine" (add "the")

Change "An array class creation" to "The creation" since your are 
repeating "An array class" from the previous sentence.


In the JVMTI spec ClassLoaderClasses section:

"That is, initiating_loader has been recorded as an initiating loader of 
the returned classes." -> "That is, all classes for which 
initiating_loader has been recorded as an initiating loader."


In the JVMTI spec GetClassSignature section:

"If the class indicated by klass is ..." -> "If the class ..." (you just 
finished the previous sentence with "class indicated by Klass").

"the returned name is [the] JNI type signature" (add "the"). Also, is 
"JNI type signature" formally defined somewhere? This relates to my JDWP 
spec comment above.

" where N is the binary name encoded in internal form indicated by the 
class file". Is "binary name encoded in internal form" explained 
somewhere? Also, can you add an example of a returned hidden class 
signature?


In the JVMTI spec ClassLoad section:

"representation using [a] class loader" (add "a")

"By invoking Lookup::defineHiddenClass, that creates ..."? -> "By 
invoking Lookup::defineHiddenClass to create ..."

"certain Java SE Platform API" -> Should be "APIs"


In JDI ClassLoaderReference.definedClasses()

"loaded at least to the point of preparation and types ..." -> "loaded 
at least to the point of preparation, and types ..." (Note, this not a 
new issue with your edits)


In Instrumentation.getAllLoadedClasses:

The reference to `class` did not format properly.

"by invoking Lookup::defineHiddenClass that creates" -> "by invoking 
Lookup::defineHiddenClass, which creates"

"An array class is created directly by Java virtual machine. An array 
class creation can be triggered ..." ->"An array class is created 
directly by the Java virtual machine. Array class creation can be 
triggered ..."


In Instrumentation.getInitiatedClasses:

"That is, loader has been recorded as an initiating loader of these 
classes." -> "That is, all classes for which loader has been recorded as 
an initiating loader."

thanks,

Chris
>
>
>>
>> Paul.
>>
>>> On Apr 11, 2020, at 8:13 PM, Mandy Chung  
>>> wrote:
>>>
>>> Please review the delta patch:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/ 
>>>
>>>
>>> Incremental specdiff:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html 
>>>
>>> This is to follow a discussion [1] on Class::descriptorString and 
>>> MethodType::descriptorString for hidden classes.?? The proposal is 
>>> to define the descriptor string for a hidden class of this form:
>>> ???? "L" + N + ";" + "/" + 
>>>
>>> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` 
>>> and `MethodType::descriptorString` are updated to return the 
>>> descriptor of this form for a hidden class.?? To support hidden 
>>> class, `java.lang.invoke.TypeDescriptor` spec is revised such that a 
>>> `TypeDescriptor` object can represent an entity that may not be 
>>> described in nominal form.???? This change affects JVM TI, JDWP and 
>>> JDI.??? The spec change includes a couple other JVM TI and 
>>> java.instrument spec clarification w.r.t. hidden classes that 
>>> Serguei has been working on.
>>>
>>>
>>>
>>> Mandy
>>> [1] 
>>> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html
>>>
>>> ----------------
>>> As a record, the above patch is applied on the top:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/ 
>>>
>>>
>>> webrev.06 includes the following changes that have been reviewed:
>>> 1. rename "weak hidden" and Klass::is_hidden_weak to 
>>> is_non_strong_hidden
>>> 2. remove unused `setImplMethod` method from lambda proxy class
>>> 3. include Serguei's patch to fix JDK-8242166: regression in JDI 
>>> ClassUnload events
>>> 4. drop the uniqueness guarantee of the suffix of the hidden class's 
>>> name
>>>
>>> On 3/31/20 8:01 PM, Mandy Chung wrote:
>>>> Thanks to the review feedbacks.
>>>>
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ 
>>>>
>>>> Delta between webrev.03 and webrev.04:
>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ 
>>>>
>>>>
>>>> Summary of changes is:
>>>> 1. Update javac to retain the previous behavior when compiling to 
>>>> target release <= 14 where lambda proxy class is not a nestmate
>>>> 2. Rename Class::isHiddenClass to Class::isHidden
>>>> 3. Address Joe's feedback on the CSR to document the behavior of 
>>>> the relevant methods in java.lang.Class for hidden classes
>>>> 4. Add test case for unloadable class with nest host error
>>>> 5. Add test cases for hidden classes with different kinds of class 
>>>> or interface
>>>> 6. Update dcmd to drop "weak hidden class" and refer it as "hidden 
>>>> class"
>>>> 7. Small changes in response to Remi, Coleen, Paul's review comments
>>>> 8. Fix copyright headers
>>>> 9. Fix @modules in tests
>>>>
>>>> Most of the changes above have also been reviewed as separate patches.
>>>>
>>>> Thanks
>>>> Mandy
>>>>
>>>> On 3/26/20 4:57 PM, Mandy Chung wrote:
>>>>> Please review the implementation of JEP 371: Hidden Classes. The 
>>>>> main changes are in core-libs and hotspot runtime area.? Small 
>>>>> changes are made in javac, VM compiler (intrinsification of 
>>>>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been 
>>>>> reviewed and is in the finalized state (see specdiff and javadoc 
>>>>> below for reference).
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 
>>>>>
>>>>>
>>>>> javadoc/specdiff
>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ 
>>>>>
>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ 
>>>>>
>>>>>
>>>>> JVMS 5.4.4 change:
>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf 
>>>>>
>>>>>
>>>>> CSR:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8238359
>>>>>
>>>>> Thanks
>>>>> Mandy
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359
>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338
>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502
>



From mandy.chung at oracle.com  Fri Apr 17 23:52:09 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 17 Apr 2020 16:52:09 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
 
 <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>
 <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com>
 <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com>
Message-ID: <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com>



On 4/17/20 3:51 PM, Chris Plummer wrote:
> Hi Mandy,
>
> Thanks for updating the svc specs. Some comments below:
>
>
> In the JDWP spec update, you changed "JNI signature" to "type 
> signature" in one place, but left it as "JNI signature" everywhere 
> else. Should they all be changed?
>

JDWP signature is changed because there is no JNI signature representing 
a hidden class.??? I leave other references to JNI signature as is since 
those only apply for normal classes as I wanted to keep this change 
specifically due to hidden classes.? I think it's good to file a JBS 
issue to follow up on JDWP and JDI to determine if the spec should be 
upgraded to reference the new TypeDescriptor API.

>
> In the JDWP spec for ClassLoaderReference.VisibleClasses:
>
> ?"That is, this class loader has been recorded as an initiating 
> loader of the returned classes." -> "That is, all classes for which 
> this class loader has been recorded as an initiating loader."
>
> This seems like too much detail to be put here. Basically the term 
> "initiating ClassLoader" has turned into a short essay. Is it possible 
> that all this detail could be put elsewhere and referenced? 

Any suggestion??? We attempted to place those description in JVM TI 
Class section or ClassLoad event.?? However, that's not ideal place 
since that's needed by JDWP, JDI and Instrumentation.?? I found inlining 
this description is not ideal but it provides adequate clarification.

> Aren't there other places in other specs where a similar clarification 
> of "initiating ClassLoader" is needed (I see now that 
> ClassLoaderClasses in the JVMTI spec, 
> ClassLoaderReference,visibleClasses in the JDI spec, and 
> Instrumentation.getInitiatedClasses are all dealing with this, but not 
> all in the exact same way).
>

I took the conservative side and make sure the clarification is in place 
for all APIs.? I'm open to any suggestion for example having JDWP and 
JDI to link to JVM TI spec if you think appropriate.

>
> In the JVMTI spec for GetLoadedClasses:
>
> This suffers in a way similar to ClassLoaderReference.VisibleClasses 
> in the JDWP spec, although not as badly. A simple concept ends up with 
> a complex description, and it seems that description should really be 
> in a more centralized place.? I would also suggest a bit of cleanup of 
> these lines:
>
> 6866???????? An array class is created directly by Java virtual 
> machine.? An array class
> 6867???????? creation can be triggered by using class loaders or by 
> invoking methods in certain
> 6868???????? Java SE Platform API such as reflection.
>
> "Created by [the] Java virtual machine" (add "the")
> Change "An array class creation" to "The creation" since your are 
> repeating "An array class" from the previous sentence.
>
>
> In the JVMTI spec ClassLoaderClasses section:
>
> "That is, initiating_loader has been recorded as an initiating loader 
> of the returned classes." -> "That is, all classes for which 
> initiating_loader has been recorded as an initiating loader."
>
>
> In the JVMTI spec GetClassSignature section:
>
> "If the class indicated by klass is ..." -> "If the class ..." (you 
> just finished the previous sentence with "class indicated by Klass").
>
> "the returned name is [the] JNI type signature" (add "the"). Also, is 
> "JNI type signature" formally defined somewhere? This relates to my 
> JDWP spec comment above.
>

It's a link to 
https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. 
This is how the current JVM TI spec defines.

> " where N is the binary name encoded in internal form indicated by the 
> class file". Is "binary name encoded in internal form" explained 
> somewhere? 

JVMS 4.2.1

https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.2.1

> Also, can you add an example of a returned hidden class signature?
>
OK

>
> In the JVMTI spec ClassLoad section:
>
> "representation using [a] class loader" (add "a")
>
> "By invoking Lookup::defineHiddenClass, that creates ..."? -> "By 
> invoking Lookup::defineHiddenClass to create ..."
>
> "certain Java SE Platform API" -> Should be "APIs"
>
>
> In JDI ClassLoaderReference.definedClasses()
>
> "loaded at least to the point of preparation and types ..." -> "loaded 
> at least to the point of preparation, and types ..." (Note, this not a 
> new issue with your edits)
>
>
> In Instrumentation.getAllLoadedClasses:
>
> The reference to `class` did not format properly.
>

Serguei caught that one too.? I fixed it in my local repo.

> "by invoking Lookup::defineHiddenClass that creates" -> "by invoking 
> Lookup::defineHiddenClass, which creates"
>
> "An array class is created directly by Java virtual machine. An array 
> class creation can be triggered ..." ->"An array class is created 
> directly by the Java virtual machine. Array class creation can be 
> triggered ..."
>
>
> In Instrumentation.getInitiatedClasses:
>
> "That is, loader has been recorded as an initiating loader of these 
> classes." -> "That is, all classes for which loader has been recorded 
> as an initiating loader."
>
> thanks,
>
> Chris

Thanks for the review.?? See this patch of the editorial fixes.

diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec
--- a/make/data/jdwp/jdwp.spec
+++ b/make/data/jdwp/jdwp.spec
@@ -2265,8 +2265,8 @@
 ???????? "Returns a list of all classes which this class loader can find "
 ???????? "by name via ClassLoader::loadClass, "
 ???????? "Class::forName and bytecode linkage. That is, "
-??????? "this class loader has been recorded as an initiating "
-??????? "loader of the returned classes. The list contains each
+??????? "all classes for which this class loader has been recorded as an "
+??????? "initiating loader. The list contains each "
 ???????? "reference type created by this loader and any types for which "
 ???????? "loading was delegated by this class loader to another class 
loader. "
 ???????? "The list does not include hidden classes or interfaces 
created by "
diff --git a/src/hotspot/share/prims/jvmti.xml 
b/src/hotspot/share/prims/jvmti.xml
--- a/src/hotspot/share/prims/jvmti.xml
+++ b/src/hotspot/share/prims/jvmti.xml
@@ -6857,15 +6857,15 @@
 ???????? A class or interface creation can be triggered by one of the 
following:
 ???????? 
          
 ???????? 
        • By loading and deriving a class from a class 
file representation
-??????????? using class loader (see ).
          • 
+??????????? using a class loader (see ).
 ???????? 
        • By invoking Lookup::defineHiddenClass
 ???????????? that creates a hidden class or interface from a 
class file representation.
          • 
-??????? 
        • By invoking methods in certain Java SE Platform API such as 
reflection.
          • 
+??????? 
        • By invoking methods in certain Java SE Platform APIs such 
as reflection.
          • 
 ????????? 
        
 ???????? 
        
-??????? An array class is created directly by Java virtual machine.? An 
array class
-??????? creation can be triggered by using class loaders or by invoking 
methods in certain
-??????? Java SE Platform API such as reflection.
+??????? An array class is created directly by the Java virtual 
machine.? The creation
+??????? can be triggered by using class loaders or by invoking methods 
in certain
+??????? Java SE Platform APIs such as reflection.
 ???????? 
        
 ???????? The returned list includes all classes and interfaces, including
 ???????? 
@@ -6904,8 +6904,8 @@
 ???????? can find by name via
 ???????? ClassLoader::loadClass,
 ???????? Class::forName 
and bytecode linkage.
-??????? That is, initiating_loader
-??????? has been recorded as an initiating loader of the returned classes.
+??????? That is, all classes for which initiating_loader
+??????? has been recorded as an initiating loader.
 ???????? Each class in the returned array was created by this class loader,
 ???????? either by defining it directly or by delegation to another 
class loader.
 ???????? See .
@@ -6964,21 +6964,22 @@
 ?????? 
 ???????? Return the name and the generic signature of the class 
indicated by klass.
 ???????? 
        
-??????? If the class indicated by klass is a class or 
interface, then:
+??????? If the class is a class or interface, then:
 ???????? 
          
 ???????? 
        • If the class or interface is not hi
dden,
-????????? then the returned name is 
+????????? then the returned name is the 
 ?????????? JNI type signature.
 ?????????? For example, java.util.List is "Ljava/util/List;"
 ???????? 
          • 
 ???????? 
        • If the class or interface is hidden
,
 ?????????? then the returned name is a string of the form:
 ?????????? "L" + N + "." +? S + ";"
-????????? where N is the binary name encoded in internal form
+????????? where N is the binary name encoded in internal 
form (JVMS 4.2.1)
 ?????????? indicated by the class file passed to
 ?????????? Lookup::defineHiddenClass,
 ?????????? and S is an unqualified name.
-????????? The returned name is not a valid type descriptor.
+????????? The returned name is not a type descriptor and does not 
conform to JVMS 4.3.2.
+????????? For example, com.foo.Foo/AnySuffix is "Lcom/foo/Foo.AnySuffix;"
 ???????? 
          • 
 ???????? 
        
 ???????? 
        
@@ -12768,10 +12769,10 @@
 ?????? A class or interface is created by one of the following:
 ?????? 
          
 ?????? 
        • By loading and deriving a class from a class 
file representation
-????????? using class loader.
          • 
+????????? using a class loader.
 ?????? 
        • By invoking Lookup::defineHiddenClass,
 ?????????? that creates a hidden class or interface from a 
class file representation.
          • 
-????? 
        • By invoking methods in certain Java SE Platform API such as 
reflection.
          • 
+????? 
        • By invoking methods in certain Java SE Platform APIs such as 
reflection.
          • 
 ?????? 
        
 ?????? 
        
 ?????? Array class creation does not generate a class load event.
diff --git 
a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java 
b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
--- 
a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
+++ 
b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
@@ -392,15 +392,15 @@
 ????? * A class or interface creation can be triggered by one of the 
following:
 ????? * 
          
 ????? * 
        • by loading and deriving a class from a {@code class} file 
representation
-???? *???? using class loader (see JVMS {@jvms 5.3}).
+???? *???? using a class loader (see JVMS {@jvms 5.3}).
 ????? * 
        • by invoking {@link 
java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, 
java.lang.invoke.MethodHandles.Lookup.ClassOption...)
-???? *???? Lookup::defineHiddenClass} that creates a {@link Class#isHidden
+???? *???? Lookup::defineHiddenClass}, which creates a {@link 
Class#isHidden
 ????? *???? hidden class or interface} from a {@code class} file 
representation.
 ????? * 
        • by invoking methods in certain reflection APIs such as
 ????? *???? {@link Class#forName(String) Class::forName}.
 ????? * 
        
 ????? * 
        
-???? * An array class is created directly by Java virtual machine. An array
+???? * An array class is created directly by the Java virtual machine.? 
Array
 ????? * class creation can be triggered by using class loaders or by 
invoking
 ????? * methods in certain reflection APIs such as
 ????? * {@link java.lang.reflect.Array#newInstance(Class, int) 
Array::newInstance}
@@ -420,8 +420,8 @@
 ????? * Returns an array of all classes which {@code loader} can find 
by name
 ????? * via {@link ClassLoader#loadClass(String, boolean) 
ClassLoader::loadClass},
 ????? * {@link Class#forName(String) Class::forName} and bytecode linkage.
-???? * That is, {@code loader} has been recorded as an initiating loader
-???? * of these classes. If the supplied {@code loader} is {@code null},
+???? * That is, all classes for which {@code loader} has been recorded as
+???? * an initiating loader. If the supplied {@code loader} is {@code 
null},
 ????? * classes that the bootstrap class loader can find by name are 
returned.
 ????? *
 ????? * 
        
diff --git 
a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java 
b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
--- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
+++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
@@ -46,7 +46,7 @@
 ????? * No ordering of this list guaranteed.
 ????? * The returned list will include all reference types, including
 ????? * {@link Class#isHidden hidden classes or interfaces}, loaded
-???? * at least to the point of preparation and types (like array)
+???? * at least to the point of preparation, and types (like array)
 ????? * for which preparation is not defined.
 ????? *
 ????? * @return a {@code List} of {@link ReferenceType} objects 
mirroring types
@@ -59,8 +59,8 @@
 ????? * Returns a list of all classes which this class loader
 ????? * can find by name via {@link ClassLoader#loadClass(String, boolean)
 ????? * ClassLoader::loadClass}, {@link Class#forName(String) 
Class::forName}
-???? * and bytecode linkage in the target VM.? That is, this class loader
-???? * has been recorded as an initiating loader of these classes.
+???? * and bytecode linkage in the target VM.? That is, all classes for
+???? * which this class loader has been recorded as an initiating loader.
 ????? * 
        
 ????? * Each class in the returned list was created by this class loader
 ????? * either by defining it directly or by delegation to another 
class loader
diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java 
b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
--- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
+++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
@@ -138,9 +138,9 @@
 ????? * A class or interface creation can be triggered by one of the 
following:
 ????? * 
          
 ????? * 
        • by loading and deriving a class from a {@code class} file 
representation
-???? *???? using class loader (see JVMS {@jvms 5.3}).
+???? *???? using a class loader (see JVMS {@jvms 5.3}).
 ????? * 
        • by invoking {@link 
java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, 
java.lang.invoke.MethodHandles.Lookup.ClassOption...)
-???? *???? Lookup::defineHiddenClass} that creates a {@link Class#isHidden
+???? *???? Lookup::defineHiddenClass}, which creates a {@link 
Class#isHidden
 ????? *???? hidden class or interface} from a {@code class} file 
representation.
 ????? * 
        • by invoking methods in certain reflection APIs such as
 ????? *???? {@link Class#forName(String) Class::forName}.

Mandy



From serguei.spitsyn at oracle.com  Sat Apr 18 04:37:21 2020
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 17 Apr 2020 21:37:21 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
 
 <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>
 <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com>
 <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com>
 <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com>
Message-ID: 

On 4/17/20 16:52, Mandy Chung wrote:
>
>
> On 4/17/20 3:51 PM, Chris Plummer wrote:
>> Hi Mandy,
>>
>> Thanks for updating the svc specs. Some comments below:
>>
>>
>> In the JDWP spec update, you changed "JNI signature" to "type 
>> signature" in one place, but left it as "JNI signature" everywhere 
>> else. Should they all be changed?
>>
>
> JDWP signature is changed because there is no JNI signature 
> representing a hidden class.??? I leave other references to JNI 
> signature as is since those only apply for normal classes as I wanted 
> to keep this change specifically due to hidden classes.? I think it's 
> good to file a JBS issue to follow up on JDWP and JDI to determine if 
> the spec should be upgraded to reference the new TypeDescriptor API.
>
>>
>> In the JDWP spec for ClassLoaderReference.VisibleClasses:
>>
>> ?"That is, this class loader has been recorded as an 
>> initiating loader of the returned classes." -> "That is, all 
>> classes for which this class loader has been recorded as an 
>> initiating loader."
>>
>> This seems like too much detail to be put here. Basically the term 
>> "initiating ClassLoader" has turned into a short essay. Is it 
>> possible that all this detail could be put elsewhere and referenced? 
>
> Any suggestion??? We attempted to place those description in JVM TI 
> Class section or ClassLoad event.?? However, that's not ideal place 
> since that's needed by JDWP, JDI and Instrumentation.?? I found 
> inlining this description is not ideal but it provides adequate 
> clarification.

The JDI (transitively via JDWP), JDWP and Instrumentation 
implementations are based on the JVMTI.
I've tried to suggest once to link these API's to the JVMTI.
The problem is there was no such practice in the specs of these API's 
before but we can make a step to introduce it now.
Placing this description either in JVM TI Class section or ClassLoad 
event would be good enough.

An alternative approach is to make JVMTI/JDI/JDWP/Instrument to refer to 
the java.lang.Class spec for
general information about class loading and classes defined and 
initiated by class loaders.

Thanks,
Serguei

>> Aren't there other places in other specs where a similar 
>> clarification of "initiating ClassLoader" is needed (I see now that 
>> ClassLoaderClasses in the JVMTI spec, 
>> ClassLoaderReference,visibleClasses in the JDI spec, and 
>> Instrumentation.getInitiatedClasses are all dealing with this, but 
>> not all in the exact same way).
>>
>
> I took the conservative side and make sure the clarification is in 
> place for all APIs.? I'm open to any suggestion for example having 
> JDWP and JDI to link to JVM TI spec if you think appropriate.
>
>>
>> In the JVMTI spec for GetLoadedClasses:
>>
>> This suffers in a way similar to ClassLoaderReference.VisibleClasses 
>> in the JDWP spec, although not as badly. A simple concept ends up 
>> with a complex description, and it seems that description should 
>> really be in a more centralized place.? I would also suggest a bit of 
>> cleanup of these lines:
>>
>> 6866???????? An array class is created directly by Java virtual 
>> machine.? An array class
>> 6867???????? creation can be triggered by using class loaders or by 
>> invoking methods in certain
>> 6868???????? Java SE Platform API such as reflection.
>>
>> "Created by [the] Java virtual machine" (add "the")
>> Change "An array class creation" to "The creation" since your are 
>> repeating "An array class" from the previous sentence.
>>
>>
>> In the JVMTI spec ClassLoaderClasses section:
>>
>> "That is, initiating_loader has been recorded as an initiating loader 
>> of the returned classes." -> "That is, all classes for which 
>> initiating_loader has been recorded as an initiating loader."
>>
>>
>> In the JVMTI spec GetClassSignature section:
>>
>> "If the class indicated by klass is ..." -> "If the class ..." (you 
>> just finished the previous sentence with "class indicated by Klass").
>>
>> "the returned name is [the] JNI type signature" (add "the"). Also, is 
>> "JNI type signature" formally defined somewhere? This relates to my 
>> JDWP spec comment above.
>>
>
> It's a link to 
> https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. 
> This is how the current JVM TI spec defines.
>
>> " where N is the binary name encoded in internal form indicated by 
>> the class file". Is "binary name encoded in internal form" explained 
>> somewhere? 
>
> JVMS 4.2.1
>
> https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.2.1 
>
>
>> Also, can you add an example of a returned hidden class signature?
>>
> OK
>
>>
>> In the JVMTI spec ClassLoad section:
>>
>> "representation using [a] class loader" (add "a")
>>
>> "By invoking Lookup::defineHiddenClass, that creates ..."? -> "By 
>> invoking Lookup::defineHiddenClass to create ..."
>>
>> "certain Java SE Platform API" -> Should be "APIs"
>>
>>
>> In JDI ClassLoaderReference.definedClasses()
>>
>> "loaded at least to the point of preparation and types ..." -> 
>> "loaded at least to the point of preparation, and types ..." (Note, 
>> this not a new issue with your edits)
>>
>>
>> In Instrumentation.getAllLoadedClasses:
>>
>> The reference to `class` did not format properly.
>>
>
> Serguei caught that one too.? I fixed it in my local repo.
>
>> "by invoking Lookup::defineHiddenClass that creates" -> "by invoking 
>> Lookup::defineHiddenClass, which creates"
>>
>> "An array class is created directly by Java virtual machine. An array 
>> class creation can be triggered ..." ->"An array class is created 
>> directly by the Java virtual machine. Array class creation can be 
>> triggered ..."
>>
>>
>> In Instrumentation.getInitiatedClasses:
>>
>> "That is, loader has been recorded as an initiating loader of these 
>> classes." -> "That is, all classes for which loader has been recorded 
>> as an initiating loader."
>>
>> thanks,
>>
>> Chris
>
> Thanks for the review.?? See this patch of the editorial fixes.
>
> diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec
> --- a/make/data/jdwp/jdwp.spec
> +++ b/make/data/jdwp/jdwp.spec
> @@ -2265,8 +2265,8 @@
> ???????? "Returns a list of all classes which this class loader can 
> find "
> ???????? "by name via ClassLoader::loadClass, "
> ???????? "Class::forName and bytecode linkage. That is, "
> -??????? "this class loader has been recorded as an initiating "
> -??????? "loader of the returned classes. The list contains each
> +??????? "all classes for which this class loader has been recorded as 
> an "
> +??????? "initiating loader. The list contains each "
> ???????? "reference type created by this loader and any types for which "
> ???????? "loading was delegated by this class loader to another class 
> loader. "
> ???????? "The list does not include hidden classes or interfaces 
> created by "
> diff --git a/src/hotspot/share/prims/jvmti.xml 
> b/src/hotspot/share/prims/jvmti.xml
> --- a/src/hotspot/share/prims/jvmti.xml
> +++ b/src/hotspot/share/prims/jvmti.xml
> @@ -6857,15 +6857,15 @@
> ???????? A class or interface creation can be triggered by one of the 
> following:
> ???????? 
            
> ???????? 
          • By loading and deriving a class from a class 
> file representation
> -??????????? using class loader (see ).
            • 
> +??????????? using a class loader (see ).
> ???????? 
          • By invoking  id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass
> ???????????? that creates a hidden class or interface from a 
> class file representation.
            • 
> -??????? 
          • By invoking methods in certain Java SE Platform API such 
> as reflection.
            • 
> +??????? 
          • By invoking methods in certain Java SE Platform APIs such 
> as reflection.
            • 
> ????????? 
          
> ???????? 
          
> -??????? An array class is created directly by Java virtual machine.? 
> An array class
> -??????? creation can be triggered by using class loaders or by 
> invoking methods in certain
> -??????? Java SE Platform API such as reflection.
> +??????? An array class is created directly by the Java virtual 
> machine.? The creation
> +??????? can be triggered by using class loaders or by invoking 
> methods in certain
> +??????? Java SE Platform APIs such as reflection.
> ???????? 
          
> ???????? The returned list includes all classes and interfaces, including
> ????????  id="../api/java.base/java/lang/Class.html#isHidden()">
> @@ -6904,8 +6904,8 @@
> ???????? can find by name via
> ????????  id="../api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)">ClassLoader::loadClass,
> ????????  id="../api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)">Class::forName 
> and bytecode linkage.
> -??????? That is, initiating_loader
> -??????? has been recorded as an initiating loader of the returned 
> classes.
> +??????? That is, all classes for which initiating_loader
> +??????? has been recorded as an initiating loader.
> ???????? Each class in the returned array was created by this class 
> loader,
> ???????? either by defining it directly or by delegation to another 
> class loader.
> ???????? See .
> @@ -6964,21 +6964,22 @@
> ?????? 
> ???????? Return the name and the generic signature of the class 
> indicated by klass.
> ???????? 
          
> -??????? If the class indicated by klass is a class or 
> interface, then:
> +??????? If the class is a class or interface, then:
> ???????? 
            
> ???????? 
          • If the class or interface is not  id="../api/java.base/java/lang/Class.html#isHidden()">hi
> dden,
> -????????? then the returned name is  id="jni/types.html#type-signatures">
> +????????? then the returned name is the  id="jni/types.html#type-signatures">
> ?????????? JNI type signature.
> ?????????? For example, java.util.List is "Ljava/util/List;"
> ???????? 
            • 
> ???????? 
          • If the class or interface is  id="../api/java.base/java/lang/Class.html#isHidden()">hidden
> ,
> ?????????? then the returned name is a string of the form:
> ?????????? "L" + N + "." +? S + ";"
> -????????? where N is the binary name encoded in internal 
> form
> +????????? where N is the binary name encoded in internal 
> form (JVMS 4.2.1)
> ?????????? indicated by the class file passed to
> ??????????  id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass,
> ?????????? and S is an unqualified name.
> -????????? The returned name is not a valid type descriptor.
> +????????? The returned name is not a type descriptor and does not 
> conform to JVMS 4.3.2.
> +????????? For example, com.foo.Foo/AnySuffix is 
> "Lcom/foo/Foo.AnySuffix;"
> ???????? 
            • 
> ???????? 
          
> ???????? 
          
> @@ -12768,10 +12769,10 @@
> ?????? A class or interface is created by one of the following:
> ?????? 
            
> ?????? 
          • By loading and deriving a class from a class 
> file representation
> -????????? using class loader.
            • 
> +????????? using a class loader.
> ?????? 
          • By invoking  id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass,
> ?????????? that creates a hidden class or interface from a 
> class file representation.
            • 
> -????? 
          • By invoking methods in certain Java SE Platform API such as 
> reflection.
            • 
> +????? 
          • By invoking methods in certain Java SE Platform APIs such 
> as reflection.
            • 
> ?????? 
          
> ?????? 
          
> ?????? Array class creation does not generate a class load event.
> diff --git 
> a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java 
> b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java 
>
> --- 
> a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
> +++ 
> b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
> @@ -392,15 +392,15 @@
> ????? * A class or interface creation can be triggered by one of the 
> following:
> ????? * 
            
> ????? * 
          • by loading and deriving a class from a {@code class} file 
> representation
> -???? *???? using class loader (see JVMS {@jvms 5.3}).
> +???? *???? using a class loader (see JVMS {@jvms 5.3}).
> ????? * 
          • by invoking {@link 
> java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], 
> boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...)
> -???? *???? Lookup::defineHiddenClass} that creates a {@link 
> Class#isHidden
> +???? *???? Lookup::defineHiddenClass}, which creates a {@link 
> Class#isHidden
> ????? *???? hidden class or interface} from a {@code class} file 
> representation.
> ????? * 
          • by invoking methods in certain reflection APIs such as
> ????? *???? {@link Class#forName(String) Class::forName}.
> ????? * 
          
> ????? * 
          
> -???? * An array class is created directly by Java virtual machine. An 
> array
> +???? * An array class is created directly by the Java virtual 
> machine.? Array
> ????? * class creation can be triggered by using class loaders or by 
> invoking
> ????? * methods in certain reflection APIs such as
> ????? * {@link java.lang.reflect.Array#newInstance(Class, int) 
> Array::newInstance}
> @@ -420,8 +420,8 @@
> ????? * Returns an array of all classes which {@code loader} can find 
> by name
> ????? * via {@link ClassLoader#loadClass(String, boolean) 
> ClassLoader::loadClass},
> ????? * {@link Class#forName(String) Class::forName} and bytecode 
> linkage.
> -???? * That is, {@code loader} has been recorded as an initiating loader
> -???? * of these classes. If the supplied {@code loader} is {@code null},
> +???? * That is, all classes for which {@code loader} has been 
> recorded as
> +???? * an initiating loader. If the supplied {@code loader} is {@code 
> null},
> ????? * classes that the bootstrap class loader can find by name are 
> returned.
> ????? *
> ????? * 
          
> diff --git 
> a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java 
> b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
> --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
> +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
> @@ -46,7 +46,7 @@
> ????? * No ordering of this list guaranteed.
> ????? * The returned list will include all reference types, including
> ????? * {@link Class#isHidden hidden classes or interfaces}, loaded
> -???? * at least to the point of preparation and types (like array)
> +???? * at least to the point of preparation, and types (like array)
> ????? * for which preparation is not defined.
> ????? *
> ????? * @return a {@code List} of {@link ReferenceType} objects 
> mirroring types
> @@ -59,8 +59,8 @@
> ????? * Returns a list of all classes which this class loader
> ????? * can find by name via {@link ClassLoader#loadClass(String, 
> boolean)
> ????? * ClassLoader::loadClass}, {@link Class#forName(String) 
> Class::forName}
> -???? * and bytecode linkage in the target VM.? That is, this class 
> loader
> -???? * has been recorded as an initiating loader of these classes.
> +???? * and bytecode linkage in the target VM.? That is, all classes for
> +???? * which this class loader has been recorded as an initiating 
> loader.
> ????? * 
          
> ????? * Each class in the returned list was created by this class loader
> ????? * either by defining it directly or by delegation to another 
> class loader
> diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java 
> b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
> --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
> +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
> @@ -138,9 +138,9 @@
> ????? * A class or interface creation can be triggered by one of the 
> following:
> ????? * 
            
> ????? * 
          • by loading and deriving a class from a {@code class} file 
> representation
> -???? *???? using class loader (see JVMS {@jvms 5.3}).
> +???? *???? using a class loader (see JVMS {@jvms 5.3}).
> ????? * 
          • by invoking {@link 
> java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], 
> boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...)
> -???? *???? Lookup::defineHiddenClass} that creates a {@link 
> Class#isHidden
> +???? *???? Lookup::defineHiddenClass}, which creates a {@link 
> Class#isHidden
> ????? *???? hidden class or interface} from a {@code class} file 
> representation.
> ????? * 
          • by invoking methods in certain reflection APIs such as
> ????? *???? {@link Class#forName(String) Class::forName}.
>
> Mandy
>
>


From chris.plummer at oracle.com  Sat Apr 18 07:18:59 2020
From: chris.plummer at oracle.com (Chris Plummer)
Date: Sat, 18 Apr 2020 00:18:59 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
 
 <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>
 <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com>
 <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com>
 <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com>
 
Message-ID: <9b74fc5f-0cb0-e0f5-6a36-969db3deff0a@oracle.com>

On 4/17/20 9:37 PM, serguei.spitsyn at oracle.com wrote:
> On 4/17/20 16:52, Mandy Chung wrote:
>>
>>
>> On 4/17/20 3:51 PM, Chris Plummer wrote:
>>> Hi Mandy,
>>>
>>> Thanks for updating the svc specs. Some comments below:
>>>
>>>
>>> In the JDWP spec update, you changed "JNI signature" to "type 
>>> signature" in one place, but left it as "JNI signature" everywhere 
>>> else. Should they all be changed?
>>>
>>
>> JDWP signature is changed because there is no JNI signature 
>> representing a hidden class.??? I leave other references to JNI 
>> signature as is since those only apply for normal classes as I wanted 
>> to keep this change specifically due to hidden classes. I think it's 
>> good to file a JBS issue to follow up on JDWP and JDI to determine if 
>> the spec should be upgraded to reference the new TypeDescriptor API.
>>
>>>
>>> In the JDWP spec for ClassLoaderReference.VisibleClasses:
>>>
>>> ?"That is, this class loader has been recorded as an 
>>> initiating loader of the returned classes." -> "That is, all 
>>> classes for which this class loader has been recorded as an 
>>> initiating loader."
>>>
>>> This seems like too much detail to be put here. Basically the term 
>>> "initiating ClassLoader" has turned into a short essay. Is it 
>>> possible that all this detail could be put elsewhere and referenced? 
>>
>> Any suggestion??? We attempted to place those description in JVM TI 
>> Class section or ClassLoad event.?? However, that's not ideal place 
>> since that's needed by JDWP, JDI and Instrumentation.?? I found 
>> inlining this description is not ideal but it provides adequate 
>> clarification.
>
> The JDI (transitively via JDWP), JDWP and Instrumentation 
> implementations are based on the JVMTI.
> I've tried to suggest once to link these API's to the JVMTI.
> The problem is there was no such practice in the specs of these API's 
> before but we can make a step to introduce it now.
> Placing this description either in JVM TI Class section or ClassLoad 
> event would be good enough.
>
> An alternative approach is to make JVMTI/JDI/JDWP/Instrument to refer 
> to the java.lang.Class spec for
> general information about class loading and classes defined and 
> initiated by class loaders.
I'd first like to clarify on my comment above just in case there was any 
confusion. At the last minute I re-ordered the two paragraph and now I 
see it makes it seem like I was only referring to to the one sentence 
about initiating loaders. I was referring to pretty much all the changes 
that were made in this section and other similar APIs in the other specs.

Yes. I'd like to see all this as part of the Class/Classloading spec in 
some sort of section that gives an overview of all these topics, but 
mostly clarifies what an initiating loader is, and the (non) 
relationship to hidden classes.

thanks,

Chris
>
> Thanks,
> Serguei
>
>>> Aren't there other places in other specs where a similar 
>>> clarification of "initiating ClassLoader" is needed (I see now that 
>>> ClassLoaderClasses in the JVMTI spec, 
>>> ClassLoaderReference,visibleClasses in the JDI spec, and 
>>> Instrumentation.getInitiatedClasses are all dealing with this, but 
>>> not all in the exact same way).
>>>
>>
>> I took the conservative side and make sure the clarification is in 
>> place for all APIs.? I'm open to any suggestion for example having 
>> JDWP and JDI to link to JVM TI spec if you think appropriate.
>>
>>>
>>> In the JVMTI spec for GetLoadedClasses:
>>>
>>> This suffers in a way similar to ClassLoaderReference.VisibleClasses 
>>> in the JDWP spec, although not as badly. A simple concept ends up 
>>> with a complex description, and it seems that description should 
>>> really be in a more centralized place.? I would also suggest a bit 
>>> of cleanup of these lines:
>>>
>>> 6866???????? An array class is created directly by Java virtual 
>>> machine.? An array class
>>> 6867???????? creation can be triggered by using class loaders or by 
>>> invoking methods in certain
>>> 6868???????? Java SE Platform API such as reflection.
>>>
>>> "Created by [the] Java virtual machine" (add "the")
>>> Change "An array class creation" to "The creation" since your are 
>>> repeating "An array class" from the previous sentence.
>>>
>>>
>>> In the JVMTI spec ClassLoaderClasses section:
>>>
>>> "That is, initiating_loader has been recorded as an initiating 
>>> loader of the returned classes." -> "That is, all classes for which 
>>> initiating_loader has been recorded as an initiating loader."
>>>
>>>
>>> In the JVMTI spec GetClassSignature section:
>>>
>>> "If the class indicated by klass is ..." -> "If the class ..." (you 
>>> just finished the previous sentence with "class indicated by Klass").
>>>
>>> "the returned name is [the] JNI type signature" (add "the"). Also, 
>>> is "JNI type signature" formally defined somewhere? This relates to 
>>> my JDWP spec comment above.
>>>
>>
>> It's a link to 
>> https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. 
>> This is how the current JVM TI spec defines.
>>
>>> " where N is the binary name encoded in internal form indicated by 
>>> the class file". Is "binary name encoded in internal form" explained 
>>> somewhere? 
>>
>> JVMS 4.2.1
>>
>> https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.2.1 
>>
>>
>>> Also, can you add an example of a returned hidden class signature?
>>>
>> OK
>>
>>>
>>> In the JVMTI spec ClassLoad section:
>>>
>>> "representation using [a] class loader" (add "a")
>>>
>>> "By invoking Lookup::defineHiddenClass, that creates ..." -> "By 
>>> invoking Lookup::defineHiddenClass to create ..."
>>>
>>> "certain Java SE Platform API" -> Should be "APIs"
>>>
>>>
>>> In JDI ClassLoaderReference.definedClasses()
>>>
>>> "loaded at least to the point of preparation and types ..." -> 
>>> "loaded at least to the point of preparation, and types ..." (Note, 
>>> this not a new issue with your edits)
>>>
>>>
>>> In Instrumentation.getAllLoadedClasses:
>>>
>>> The reference to `class` did not format properly.
>>>
>>
>> Serguei caught that one too.? I fixed it in my local repo.
>>
>>> "by invoking Lookup::defineHiddenClass that creates" -> "by invoking 
>>> Lookup::defineHiddenClass, which creates"
>>>
>>> "An array class is created directly by Java virtual machine. An 
>>> array class creation can be triggered ..." ->"An array class is 
>>> created directly by the Java virtual machine. Array class creation 
>>> can be triggered ..."
>>>
>>>
>>> In Instrumentation.getInitiatedClasses:
>>>
>>> "That is, loader has been recorded as an initiating loader of these 
>>> classes." -> "That is, all classes for which loader has been 
>>> recorded as an initiating loader."
>>>
>>> thanks,
>>>
>>> Chris
>>
>> Thanks for the review.?? See this patch of the editorial fixes.
>>
>> diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec
>> --- a/make/data/jdwp/jdwp.spec
>> +++ b/make/data/jdwp/jdwp.spec
>> @@ -2265,8 +2265,8 @@
>> ???????? "Returns a list of all classes which this class loader can 
>> find "
>> ???????? "by name via ClassLoader::loadClass, "
>> ???????? "Class::forName and bytecode linkage. That is, "
>> -??????? "this class loader has been recorded as an initiating "
>> -??????? "loader of the returned classes. The list contains each
>> +??????? "all classes for which this class loader has been recorded 
>> as an "
>> +??????? "initiating loader. The list contains each "
>> ???????? "reference type created by this loader and any types for 
>> which "
>> ???????? "loading was delegated by this class loader to another class 
>> loader. "
>> ???????? "The list does not include hidden classes or interfaces 
>> created by "
>> diff --git a/src/hotspot/share/prims/jvmti.xml 
>> b/src/hotspot/share/prims/jvmti.xml
>> --- a/src/hotspot/share/prims/jvmti.xml
>> +++ b/src/hotspot/share/prims/jvmti.xml
>> @@ -6857,15 +6857,15 @@
>> ???????? A class or interface creation can be triggered by one of the 
>> following:
>> ???????? 
              
>> ???????? 
            • By loading and deriving a class from a 
>> class file representation
>> -??????????? using class loader (see ).
              • 
>> +??????????? using a class loader (see ).
>> ???????? 
            • By invoking > id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass
>> ???????????? that creates a hidden class or interface from a 
>> class file representation.
              • 
>> -??????? 
            • By invoking methods in certain Java SE Platform API such 
>> as reflection.
              • 
>> +??????? 
            • By invoking methods in certain Java SE Platform APIs 
>> such as reflection.
              • 
>> ????????? 
            
>> ???????? 
            
>> -??????? An array class is created directly by Java virtual machine.? 
>> An array class
>> -??????? creation can be triggered by using class loaders or by 
>> invoking methods in certain
>> -??????? Java SE Platform API such as reflection.
>> +??????? An array class is created directly by the Java virtual 
>> machine.? The creation
>> +??????? can be triggered by using class loaders or by invoking 
>> methods in certain
>> +??????? Java SE Platform APIs such as reflection.
>> ???????? 
            
>> ???????? The returned list includes all classes and interfaces, 
>> including
>> ???????? > id="../api/java.base/java/lang/Class.html#isHidden()">
>> @@ -6904,8 +6904,8 @@
>> ???????? can find by name via
>> ???????? > id="../api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)">ClassLoader::loadClass,
>> ???????? > id="../api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)">Class::forName 
>> and bytecode linkage.
>> -??????? That is, initiating_loader
>> -??????? has been recorded as an initiating loader of the returned 
>> classes.
>> +??????? That is, all classes for which initiating_loader
>> +??????? has been recorded as an initiating loader.
>> ???????? Each class in the returned array was created by this class 
>> loader,
>> ???????? either by defining it directly or by delegation to another 
>> class loader.
>> ???????? See .
>> @@ -6964,21 +6964,22 @@
>> ?????? 
>> ???????? Return the name and the generic signature of the class 
>> indicated by klass.
>> ???????? 
            
>> -??????? If the class indicated by klass is a class or 
>> interface, then:
>> +??????? If the class is a class or interface, then:
>> ???????? 
              
>> ???????? 
            • If the class or interface is not > id="../api/java.base/java/lang/Class.html#isHidden()">hi
>> dden,
>> -????????? then the returned name is > id="jni/types.html#type-signatures">
>> +????????? then the returned name is the > id="jni/types.html#type-signatures">
>> ?????????? JNI type signature.
>> ?????????? For example, java.util.List is "Ljava/util/List;"
>> ???????? 
              • 
>> ???????? 
            • If the class or interface is > id="../api/java.base/java/lang/Class.html#isHidden()">hidden
>> ,
>> ?????????? then the returned name is a string of the form:
>> ?????????? "L" + N + "." +? S + ";"
>> -????????? where N is the binary name encoded in 
>> internal form
>> +????????? where N is the binary name encoded in 
>> internal form (JVMS 4.2.1)
>> ?????????? indicated by the class file passed to
>> ?????????? > id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass,
>> ?????????? and S is an unqualified name.
>> -????????? The returned name is not a valid type descriptor.
>> +????????? The returned name is not a type descriptor and does not 
>> conform to JVMS 4.3.2.
>> +????????? For example, com.foo.Foo/AnySuffix is 
>> "Lcom/foo/Foo.AnySuffix;"
>> ???????? 
              • 
>> ???????? 
            
>> ???????? 
            
>> @@ -12768,10 +12769,10 @@
>> ?????? A class or interface is created by one of the following:
>> ?????? 
              
>> ?????? 
            • By loading and deriving a class from a class 
>> file representation
>> -????????? using class loader.
              • 
>> +????????? using a class loader.
>> ?????? 
            • By invoking > id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass,
>> ?????????? that creates a hidden class or interface from a 
>> class file representation.
              • 
>> -????? 
            • By invoking methods in certain Java SE Platform API such 
>> as reflection.
              • 
>> +????? 
            • By invoking methods in certain Java SE Platform APIs such 
>> as reflection.
              • 
>> ?????? 
            
>> ?????? 
            
>> ?????? Array class creation does not generate a class load event.
>> diff --git 
>> a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java 
>> b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java 
>>
>> --- 
>> a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
>> +++ 
>> b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
>> @@ -392,15 +392,15 @@
>> ????? * A class or interface creation can be triggered by one of the 
>> following:
>> ????? * 
              
>> ????? * 
            • by loading and deriving a class from a {@code class} file 
>> representation
>> -???? *???? using class loader (see JVMS {@jvms 5.3}).
>> +???? *???? using a class loader (see JVMS {@jvms 5.3}).
>> ????? * 
            • by invoking {@link 
>> java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], 
>> boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...)
>> -???? *???? Lookup::defineHiddenClass} that creates a {@link 
>> Class#isHidden
>> +???? *???? Lookup::defineHiddenClass}, which creates a {@link 
>> Class#isHidden
>> ????? *???? hidden class or interface} from a {@code class} file 
>> representation.
>> ????? * 
            • by invoking methods in certain reflection APIs such as
>> ????? *???? {@link Class#forName(String) Class::forName}.
>> ????? * 
            
>> ????? * 
            
>> -???? * An array class is created directly by Java virtual machine. 
>> An array
>> +???? * An array class is created directly by the Java virtual 
>> machine.? Array
>> ????? * class creation can be triggered by using class loaders or by 
>> invoking
>> ????? * methods in certain reflection APIs such as
>> ????? * {@link java.lang.reflect.Array#newInstance(Class, int) 
>> Array::newInstance}
>> @@ -420,8 +420,8 @@
>> ????? * Returns an array of all classes which {@code loader} can find 
>> by name
>> ????? * via {@link ClassLoader#loadClass(String, boolean) 
>> ClassLoader::loadClass},
>> ????? * {@link Class#forName(String) Class::forName} and bytecode 
>> linkage.
>> -???? * That is, {@code loader} has been recorded as an initiating 
>> loader
>> -???? * of these classes. If the supplied {@code loader} is {@code 
>> null},
>> +???? * That is, all classes for which {@code loader} has been 
>> recorded as
>> +???? * an initiating loader. If the supplied {@code loader} is 
>> {@code null},
>> ????? * classes that the bootstrap class loader can find by name are 
>> returned.
>> ????? *
>> ????? * 
            
>> diff --git 
>> a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java 
>> b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
>> --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
>> +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
>> @@ -46,7 +46,7 @@
>> ????? * No ordering of this list guaranteed.
>> ????? * The returned list will include all reference types, including
>> ????? * {@link Class#isHidden hidden classes or interfaces}, loaded
>> -???? * at least to the point of preparation and types (like array)
>> +???? * at least to the point of preparation, and types (like array)
>> ????? * for which preparation is not defined.
>> ????? *
>> ????? * @return a {@code List} of {@link ReferenceType} objects 
>> mirroring types
>> @@ -59,8 +59,8 @@
>> ????? * Returns a list of all classes which this class loader
>> ????? * can find by name via {@link ClassLoader#loadClass(String, 
>> boolean)
>> ????? * ClassLoader::loadClass}, {@link Class#forName(String) 
>> Class::forName}
>> -???? * and bytecode linkage in the target VM.? That is, this class 
>> loader
>> -???? * has been recorded as an initiating loader of these classes.
>> +???? * and bytecode linkage in the target VM.? That is, all classes for
>> +???? * which this class loader has been recorded as an initiating 
>> loader.
>> ????? * 
            
>> ????? * Each class in the returned list was created by this class loader
>> ????? * either by defining it directly or by delegation to another 
>> class loader
>> diff --git 
>> a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java 
>> b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
>> --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
>> +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
>> @@ -138,9 +138,9 @@
>> ????? * A class or interface creation can be triggered by one of the 
>> following:
>> ????? * 
              
>> ????? * 
            • by loading and deriving a class from a {@code class} file 
>> representation
>> -???? *???? using class loader (see JVMS {@jvms 5.3}).
>> +???? *???? using a class loader (see JVMS {@jvms 5.3}).
>> ????? * 
            • by invoking {@link 
>> java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], 
>> boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...)
>> -???? *???? Lookup::defineHiddenClass} that creates a {@link 
>> Class#isHidden
>> +???? *???? Lookup::defineHiddenClass}, which creates a {@link 
>> Class#isHidden
>> ????? *???? hidden class or interface} from a {@code class} file 
>> representation.
>> ????? * 
            • by invoking methods in certain reflection APIs such as
>> ????? *???? {@link Class#forName(String) Class::forName}.
>>
>> Mandy
>>
>>
>


From chris.plummer at oracle.com  Sat Apr 18 07:47:20 2020
From: chris.plummer at oracle.com (Chris Plummer)
Date: Sat, 18 Apr 2020 00:47:20 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
 
 <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>
 <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com>
 <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com>
 <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com>
Message-ID: 

Hi Mandy,

Comments inline.

On 4/17/20 4:52 PM, Mandy Chung wrote:
>
>
> On 4/17/20 3:51 PM, Chris Plummer wrote:
>> Hi Mandy,
>>
>> Thanks for updating the svc specs. Some comments below:
>>
>>
>> In the JDWP spec update, you changed "JNI signature" to "type 
>> signature" in one place, but left it as "JNI signature" everywhere 
>> else. Should they all be changed?
>>
>
> JDWP signature is changed because there is no JNI signature 
> representing a hidden class.??? I leave other references to JNI 
> signature as is since those only apply for normal classes as I wanted 
> to keep this change specifically due to hidden classes.? I think it's 
> good to file a JBS issue to follow up on JDWP and JDI to determine if 
> the spec should be upgraded to reference the new TypeDescriptor API.
>
>>
>> In the JDWP spec for ClassLoaderReference.VisibleClasses:
>>
>> ?"That is, this class loader has been recorded as an 
>> initiating loader of the returned classes." -> "That is, all 
>> classes for which this class loader has been recorded as an 
>> initiating loader."
>>
>> This seems like too much detail to be put here. Basically the term 
>> "initiating ClassLoader" has turned into a short essay. Is it 
>> possible that all this detail could be put elsewhere and referenced? 
>
> Any suggestion??? We attempted to place those description in JVM TI 
> Class section or ClassLoad event.?? However, that's not ideal place 
> since that's needed by JDWP, JDI and Instrumentation.?? I found 
> inlining this description is not ideal but it provides adequate 
> clarification.
See other thread.
>
>> Aren't there other places in other specs where a similar 
>> clarification of "initiating ClassLoader" is needed (I see now that 
>> ClassLoaderClasses in the JVMTI spec, 
>> ClassLoaderReference,visibleClasses in the JDI spec, and 
>> Instrumentation.getInitiatedClasses are all dealing with this, but 
>> not all in the exact same way).
>>
>
> I took the conservative side and make sure the clarification is in 
> place for all APIs.? I'm open to any suggestion for example having 
> JDWP and JDI to link to JVM TI spec if you think appropriate.
>
>>
>> In the JVMTI spec for GetLoadedClasses:
>>
>> This suffers in a way similar to ClassLoaderReference.VisibleClasses 
>> in the JDWP spec, although not as badly. A simple concept ends up 
>> with a complex description, and it seems that description should 
>> really be in a more centralized place.? I would also suggest a bit of 
>> cleanup of these lines:
>>
>> 6866???????? An array class is created directly by Java virtual 
>> machine.? An array class
>> 6867???????? creation can be triggered by using class loaders or by 
>> invoking methods in certain
>> 6868???????? Java SE Platform API such as reflection.
>>
>> "Created by [the] Java virtual machine" (add "the")
>> Change "An array class creation" to "The creation" since your are 
>> repeating "An array class" from the previous sentence.
>>
>>
>> In the JVMTI spec ClassLoaderClasses section:
>>
>> "That is, initiating_loader has been recorded as an initiating loader 
>> of the returned classes." -> "That is, all classes for which 
>> initiating_loader has been recorded as an initiating loader."
>>
>>
>> In the JVMTI spec GetClassSignature section:
>>
>> "If the class indicated by klass is ..." -> "If the class ..." (you 
>> just finished the previous sentence with "class indicated by Klass").
>>
>> "the returned name is [the] JNI type signature" (add "the"). Also, is 
>> "JNI type signature" formally defined somewhere? This relates to my 
>> JDWP spec comment above.
>>
>
> It's a link to 
> https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. 
> This is how the current JVM TI spec defines.
Since it looks like this reference was present before your changes, I 
guess it's ok to leave it, but like JDWP maybe a bug should be filed to 
clean it up.

Regarding your JNI spec reference, it say "The JNI uses the Java VM?s 
representation of type signatures" and then has a table called "Java VM 
Type Signatures". No where in the JNI spec do you see "JNI Signature" or 
"JNI Type Signature". It seems we should always just use "Type Signature"?

Even the JVMTI spec is not consistent. It has a couple of references to 
JNI Type Signature as links to the JNI spec, but also says "type 
signatures" in a couple of places, including for GetLocalVariableTable() 
which refers the the JVMS: "The local variable's type signature, encoded 
as a modified UTF-8 string. The signature format is the same as that 
defined in The Java? Virtual Machine Specification, Chapter 4.3.2. "

>
>> " where N is the binary name encoded in internal form indicated by 
>> the class file". Is "binary name encoded in internal form" explained 
>> somewhere? 
>
> JVMS 4.2.1
>
> https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.2.1
Thanks. I see you've also added a reference in your edits below.
>
>> Also, can you add an example of a returned hidden class signature?
>>
> OK
>
>>
>> In the JVMTI spec ClassLoad section:
>>
>> "representation using [a] class loader" (add "a")
>>
>> "By invoking Lookup::defineHiddenClass, that creates ..."? -> "By 
>> invoking Lookup::defineHiddenClass to create ..."
>>
>> "certain Java SE Platform API" -> Should be "APIs"
>>
>>
>> In JDI ClassLoaderReference.definedClasses()
>>
>> "loaded at least to the point of preparation and types ..." -> 
>> "loaded at least to the point of preparation, and types ..." (Note, 
>> this not a new issue with your edits)
>>
>>
>> In Instrumentation.getAllLoadedClasses:
>>
>> The reference to `class` did not format properly.
>>
>
> Serguei caught that one too.? I fixed it in my local repo.
>
>> "by invoking Lookup::defineHiddenClass that creates" -> "by invoking 
>> Lookup::defineHiddenClass, which creates"
>>
>> "An array class is created directly by Java virtual machine. An array 
>> class creation can be triggered ..." ->"An array class is created 
>> directly by the Java virtual machine. Array class creation can be 
>> triggered ..."
>>
>>
>> In Instrumentation.getInitiatedClasses:
>>
>> "That is, loader has been recorded as an initiating loader of these 
>> classes." -> "That is, all classes for which loader has been recorded 
>> as an initiating loader."
>>
>> thanks,
>>
>> Chris
>
> Thanks for the review.?? See this patch of the editorial fixes.
>
> diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec
> --- a/make/data/jdwp/jdwp.spec
> +++ b/make/data/jdwp/jdwp.spec
> @@ -2265,8 +2265,8 @@
> ???????? "Returns a list of all classes which this class loader can find "
> ???????? "by name via ClassLoader::loadClass, "
> ???????? "Class::forName and bytecode linkage. That is, "
> -??????? "this class loader has been recorded as an initiating "
> -??????? "loader of the returned classes. The list contains each
> +??????? "all classes for which this class loader has been recorded as 
> an "
> +??????? "initiating loader. The list contains each "
> ???????? "reference type created by this loader and any types for which "
> ???????? "loading was delegated by this class loader to another class 
> loader. "
> ???????? "The list does not include hidden classes or interfaces 
> created by "
> diff --git a/src/hotspot/share/prims/jvmti.xml 
> b/src/hotspot/share/prims/jvmti.xml
> --- a/src/hotspot/share/prims/jvmti.xml
> +++ b/src/hotspot/share/prims/jvmti.xml
> @@ -6857,15 +6857,15 @@
> ???????? A class or interface creation can be triggered by one of the 
> following:
> ???????? 
                
> ???????? 
              • By loading and deriving a class from a class 
> file representation
> -??????????? using class loader (see ).
                • 
> +??????????? using a class loader (see ).
> ???????? 
              • By invoking  id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass
> ???????????? that creates a hidden class or interface from a 
> class file representation.
                • 
> -??????? 
              • By invoking methods in certain Java SE Platform API such 
> as reflection.
                • 
> +??????? 
              • By invoking methods in certain Java SE Platform APIs such 
> as reflection.
                • 
> ????????? 
              
> ???????? 
              
> -??????? An array class is created directly by Java virtual machine.? 
> An array class
> -??????? creation can be triggered by using class loaders or by 
> invoking methods in certain
> -??????? Java SE Platform API such as reflection.
> +??????? An array class is created directly by the Java virtual 
> machine.? The creation
> +??????? can be triggered by using class loaders or by invoking 
> methods in certain
> +??????? Java SE Platform APIs such as reflection.
> ???????? 
              
> ???????? The returned list includes all classes and interfaces, including
> ????????  id="../api/java.base/java/lang/Class.html#isHidden()">
> @@ -6904,8 +6904,8 @@
> ???????? can find by name via
> ????????  id="../api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)">ClassLoader::loadClass,
> ????????  id="../api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)">Class::forName 
> and bytecode linkage.
> -??????? That is, initiating_loader
> -??????? has been recorded as an initiating loader of the returned 
> classes.
> +??????? That is, all classes for which initiating_loader
> +??????? has been recorded as an initiating loader.
> ???????? Each class in the returned array was created by this class 
> loader,
> ???????? either by defining it directly or by delegation to another 
> class loader.
> ???????? See .
> @@ -6964,21 +6964,22 @@
> ?????? 
> ???????? Return the name and the generic signature of the class 
> indicated by klass.
> ???????? 
              
> -??????? If the class indicated by klass is a class or 
> interface, then:
> +??????? If the class is a class or interface, then:
> ???????? 
                
> ???????? 
              • If the class or interface is not  id="../api/java.base/java/lang/Class.html#isHidden()">hi
> dden,
> -????????? then the returned name is  id="jni/types.html#type-signatures">
> +????????? then the returned name is the  id="jni/types.html#type-signatures">
> ?????????? JNI type signature.
> ?????????? For example, java.util.List is "Ljava/util/List;"
> ???????? 
                • 
> ???????? 
              • If the class or interface is  id="../api/java.base/java/lang/Class.html#isHidden()">hidden
> ,
> ?????????? then the returned name is a string of the form:
> ?????????? "L" + N + "." +? S + ";"
> -????????? where N is the binary name encoded in internal 
> form
> +????????? where N is the binary name encoded in internal 
> form (JVMS 4.2.1)
> ?????????? indicated by the class file passed to
> ??????????  id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass,
> ?????????? and S is an unqualified name.
> -????????? The returned name is not a valid type descriptor.
> +????????? The returned name is not a type descriptor and does not 
> conform to JVMS 4.3.2.
> +????????? For example, com.foo.Foo/AnySuffix is "Lcom/foo/Foo.AnySuffix;"
> ???????? 
                • 
> ???????? 
              
> ???????? 
              
> @@ -12768,10 +12769,10 @@
> ?????? A class or interface is created by one of the following:
> ?????? 
                
> ?????? 
              • By loading and deriving a class from a class 
> file representation
> -????????? using class loader.
                • 
> +????????? using a class loader.
> ?????? 
              • By invoking  id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass,
> ?????????? that creates a hidden class or interface from a 
> class file representation.
                • 
> -????? 
              • By invoking methods in certain Java SE Platform API such as 
> reflection.
                • 
> +????? 
              • By invoking methods in certain Java SE Platform APIs such 
> as reflection.
                • 
> ?????? 
              
> ?????? 
              
> ?????? Array class creation does not generate a class load event.
> diff --git 
> a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java 
> b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
> --- 
> a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
> +++ 
> b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
> @@ -392,15 +392,15 @@
> ????? * A class or interface creation can be triggered by one of the 
> following:
> ????? * 
                
> ????? * 
              • by loading and deriving a class from a {@code class} file 
> representation
> -???? *???? using class loader (see JVMS {@jvms 5.3}).
> +???? *???? using a class loader (see JVMS {@jvms 5.3}).
> ????? * 
              • by invoking {@link 
> java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], 
> boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...)
> -???? *???? Lookup::defineHiddenClass} that creates a {@link 
> Class#isHidden
> +???? *???? Lookup::defineHiddenClass}, which creates a {@link 
> Class#isHidden
> ????? *???? hidden class or interface} from a {@code class} file 
> representation.
> ????? * 
              • by invoking methods in certain reflection APIs such as
> ????? *???? {@link Class#forName(String) Class::forName}.
> ????? * 
              
> ????? * 
              
> -???? * An array class is created directly by Java virtual machine.? 
> An array
> +???? * An array class is created directly by the Java virtual 
> machine.? Array
> ????? * class creation can be triggered by using class loaders or by 
> invoking
> ????? * methods in certain reflection APIs such as
> ????? * {@link java.lang.reflect.Array#newInstance(Class, int) 
> Array::newInstance}
> @@ -420,8 +420,8 @@
> ????? * Returns an array of all classes which {@code loader} can find 
> by name
> ????? * via {@link ClassLoader#loadClass(String, boolean) 
> ClassLoader::loadClass},
> ????? * {@link Class#forName(String) Class::forName} and bytecode linkage.
> -???? * That is, {@code loader} has been recorded as an initiating loader
> -???? * of these classes. If the supplied {@code loader} is {@code null},
> +???? * That is, all classes for which {@code loader} has been recorded as
> +???? * an initiating loader. If the supplied {@code loader} is {@code 
> null},
> ????? * classes that the bootstrap class loader can find by name are 
> returned.
> ????? *
> ????? * 
              
> diff --git 
> a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java 
> b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
> --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
> +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
> @@ -46,7 +46,7 @@
> ????? * No ordering of this list guaranteed.
> ????? * The returned list will include all reference types, including
> ????? * {@link Class#isHidden hidden classes or interfaces}, loaded
> -???? * at least to the point of preparation and types (like array)
> +???? * at least to the point of preparation, and types (like array)
> ????? * for which preparation is not defined.
> ????? *
> ????? * @return a {@code List} of {@link ReferenceType} objects 
> mirroring types
> @@ -59,8 +59,8 @@
> ????? * Returns a list of all classes which this class loader
> ????? * can find by name via {@link ClassLoader#loadClass(String, boolean)
> ????? * ClassLoader::loadClass}, {@link Class#forName(String) 
> Class::forName}
> -???? * and bytecode linkage in the target VM.? That is, this class loader
> -???? * has been recorded as an initiating loader of these classes.
> +???? * and bytecode linkage in the target VM.? That is, all classes for
> +???? * which this class loader has been recorded as an initiating loader.
> ????? * 
              
> ????? * Each class in the returned list was created by this class loader
> ????? * either by defining it directly or by delegation to another 
> class loader
> diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java 
> b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
> --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
> +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
> @@ -138,9 +138,9 @@
> ????? * A class or interface creation can be triggered by one of the 
> following:
> ????? * 
                
> ????? * 
              • by loading and deriving a class from a {@code class} file 
> representation
> -???? *???? using class loader (see JVMS {@jvms 5.3}).
> +???? *???? using a class loader (see JVMS {@jvms 5.3}).
> ????? * 
              • by invoking {@link 
> java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], 
> boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...)
> -???? *???? Lookup::defineHiddenClass} that creates a {@link 
> Class#isHidden
> +???? *???? Lookup::defineHiddenClass}, which creates a {@link 
> Class#isHidden
> ????? *???? hidden class or interface} from a {@code class} file 
> representation.
> ????? * 
              • by invoking methods in certain reflection APIs such as
> ????? *???? {@link Class#forName(String) Class::forName}.
>
Above changes all look good.

thanks,

Chris
> Mandy
>
>


From john.r.rose at oracle.com  Sat Apr 18 08:04:38 2020
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 18 Apr 2020 01:04:38 -0700
Subject: Lookup.findStatic() triggers verification of nestmates attribute
 too early ?
In-Reply-To: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>
References: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>
Message-ID: 

On Apr 15, 2020, at 5:41 AM, Remi Forax  wrote:
> 
> i've discovered that using Lookup.findStatic() triggers the verification that the attributes NestHost and the NestMembers are compatible.
> 
> I believe it's a bug, the equivalent code using bytecodes will no trigger this early verification, the verification is done lazily when a private member of a class of the nest is accessed the first time.

I don?t think it?s a bug, if the JVMS fine print says what I think it says.
Nestmate checking is done when a nominal bytecode is resolved, not as
part of its post-resolution semantics.  The rules that say a class is initialized
lazily on first static access (call or variable access or instance creation)
are not organized as part of the resolution semantics of those instructions,
but as part of their run-time semantics.  Meanwhile, all relevant resolution
work is done in Lookup::findX calls, before those calls return.  It?s not right
for the invocation of a method handle *ever* to throw a resolution error;
all those checks must be done before the MH is created.  But nest mate
checking is done for resolution (as part of JVMS 5.4) not initialization
(JVMS 5.5).

As a matter of design, any error which is documented as a ?Linking
Exception? in the JVMS (chapter 6) must be completed before the Lookup
API call returns a MH.  Any error documented as a ?Run-time Exception?
must be performed after the MH is invoked.  Those run-time exceptions
include any which arise from lazy initialization of classes that are targeted
by Xstatic bytecodes.

https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.invokestatic

So, yes the Lookup.findStatic call needs to explore nestmate relations.
And no it cannot defer those until the first call of the resulting MH,
analogously to lazy  execution.  Was that what you were expecting,
or did I misread your report?

? John

From forax at univ-mlv.fr  Sat Apr 18 11:47:13 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sat, 18 Apr 2020 13:47:13 +0200 (CEST)
Subject: Lookup.findStatic() triggers verification of nestmates
 attribute too early ?
In-Reply-To: 
References: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <1866770942.1265770.1587210433201.JavaMail.zimbra@u-pem.fr>

> De: "John Rose" 
> ?: "Remi Forax" 
> Cc: "valhalla-dev" 
> Envoy?: Samedi 18 Avril 2020 10:04:38
> Objet: Re: Lookup.findStatic() triggers verification of nestmates attribute too
> early ?

> On Apr 15, 2020, at 5:41 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> i've discovered that using Lookup.findStatic() triggers the verification that
>> the attributes NestHost and the NestMembers are compatible.

>> I believe it's a bug, the equivalent code using bytecodes will no trigger this
>> early verification, the verification is done lazily when a private member of a
>> class of the nest is accessed the first time.

> I don?t think it?s a bug, if the JVMS fine print says what I think it says.
> Nestmate checking is done when a nominal bytecode is resolved, not as
> part of its post-resolution semantics. The rules that say a class is initialized
> lazily on first static access (call or variable access or instance creation)
> are not organized as part of the resolution semantics of those instructions,
> but as part of their run-time semantics. Meanwhile, all relevant resolution
> work is done in Lookup::findX calls, before those calls return. It?s not right
> for the invocation of a method handle *ever* to throw a resolution error;
> all those checks must be done before the MH is created. But nest mate
> checking is done for resolution (as part of JVMS 5.4) not initialization
> (JVMS 5.5).

> As a matter of design, any error which is documented as a ?Linking
> Exception? in the JVMS (chapter 6) must be completed before the Lookup
> API call returns a MH. Any error documented as a ?Run-time Exception?
> must be performed after the MH is invoked. Those run-time exceptions
> include any which arise from lazy initialization of classes that are targeted
> by Xstatic bytecodes.

> [
> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.invokestatic
> |
> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.invokestatic
> ]

> So, yes the Lookup.findStatic call needs to explore nestmate relations.
> And no it cannot defer those until the first call of the resulting MH,
> analogously to lazy  execution. Was that what you were expecting,
> or did I misread your report?

no, you're fully right, 
I was me trying to find an escape hatch instead of seeing the reality in face, my runtime creates some method handle adapters too early and i've to change that. 

> ? John

R?mi 

From john.r.rose at oracle.com  Sat Apr 18 19:23:13 2020
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 18 Apr 2020 12:23:13 -0700
Subject: Lookup.findStatic() triggers verification of nestmates attribute
 too early ?
In-Reply-To: <1866770942.1265770.1587210433201.JavaMail.zimbra@u-pem.fr>
References: <1955070648.1111684.1586954474076.JavaMail.zimbra@u-pem.fr>
 
 <1866770942.1265770.1587210433201.JavaMail.zimbra@u-pem.fr>
Message-ID: 

On Apr 18, 2020, at 4:47 AM, forax at univ-mlv.fr wrote:
> 
> 
> 
> De: "John Rose" 
> ?: "Remi Forax" 
> Cc: "valhalla-dev" 
> Envoy?: Samedi 18 Avril 2020 10:04:38
> Objet: Re: Lookup.findStatic() triggers verification of nestmates attribute too early ?
> On Apr 15, 2020, at 5:41 AM, Remi Forax  wrote:
> 
> i've discovered that using Lookup.findStatic() triggers the verification that the attributes NestHost and the NestMembers are compatible.
> 
> I believe it's a bug, the equivalent code using bytecodes will no trigger this early verification, the verification is done lazily when a private member of a class of the nest is accessed the first time.
> 
> I don?t think it?s a bug, if the JVMS fine print says what I think it says.
> Nestmate checking is done when a nominal bytecode is resolved, not as
> part of its post-resolution semantics.  The rules that say a class is initialized
> lazily on first static access (call or variable access or instance creation)
> are not organized as part of the resolution semantics of those instructions,
> but as part of their run-time semantics.  Meanwhile, all relevant resolution
> work is done in Lookup::findX calls, before those calls return.  It?s not right
> for the invocation of a method handle *ever* to throw a resolution error;
> all those checks must be done before the MH is created.  But nest mate
> checking is done for resolution (as part of JVMS 5.4) not initialization
> (JVMS 5.5).
> 
> As a matter of design, any error which is documented as a ?Linking
> Exception? in the JVMS (chapter 6) must be completed before the Lookup
> API call returns a MH.  Any error documented as a ?Run-time Exception?
> must be performed after the MH is invoked.  Those run-time exceptions
> include any which arise from lazy initialization of classes that are targeted
> by Xstatic bytecodes.
> 
> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.invokestatic
> 
> So, yes the Lookup.findStatic call needs to explore nestmate relations.
> And no it cannot defer those until the first call of the resulting MH,
> analogously to lazy  execution.  Was that what you were expecting,
> or did I misread your report?
> 
> no, you're fully right,
> I was me trying to find an escape hatch instead of seeing the reality in face, my runtime creates some method handle adapters too early and i've to change that.

OK, that?s a relief.  Well, we made a teaching moment about
?Linking Exception? vs. ?Run-time Exception?, and its interaction
with MH design, which we talked about in the JSR 292 EG, but
probably wasn?t documented anywhere.

? John

From mandy.chung at oracle.com  Sat Apr 18 21:09:57 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 18 Apr 2020 14:09:57 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
 
 <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>
 <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com>
 <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com>
 <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com>
 
Message-ID: <4f9a5a74-3b10-3dee-e055-feef32191c5d@oracle.com>



On 4/18/20 12:47 AM, Chris Plummer wrote:
>>
>> It's a link to 
>> https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. 
>> This is how the current JVM TI spec defines.
> Since it looks like this reference was present before your changes, I 
> guess it's ok to leave it, but like JDWP maybe a bug should be filed 
> to clean it up.
>

Right, they are existing reference.? I'll let Serguei to file a JBS 
issue to follow up.

> Regarding your JNI spec reference, it say "The JNI uses the Java VM?s 
> representation of type signatures" and then has a table called "Java 
> VM Type Signatures". No where in the JNI spec do you see "JNI 
> Signature" or "JNI Type Signature". It seems we should always just use 
> "Type Signature"?
>

I agree that the svc specs should be examined and use the terminologies 
consistently.

> Even the JVMTI spec is not consistent. It has a couple of references 
> to JNI Type Signature as links to the JNI spec, but also says "type 
> signatures" in a couple of places, including for 
> GetLocalVariableTable() which refers the the JVMS: "The local 
> variable's type signature, encoded as a modified UTF-8 string. The 
> signature format is the same as that defined in The Java? Virtual 
> Machine Specification, Chapter 4.3.2. "

Mandy

From thartmann at openjdk.java.net  Mon Apr 20 07:41:35 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 20 Apr 2020 07:41:35 GMT
Subject: [lworld] RFR: 8242269: [lworld] C2 compilation fails with assert
 "meet not symmetric"
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Apr 2020 15:48:36 GMT, Roland Westrelin  wrote:

> This tweaks the type system to fix error triggered by the recent merge.

Looks good to me!

-------------

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/20

From roland at openjdk.java.net  Mon Apr 20 08:33:36 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 20 Apr 2020 08:33:36 GMT
Subject: [Integrated] [lworld] RFR: 8242269: [lworld] C2 compilation fails
 with assert "meet not symmetric"
In-Reply-To: 
References: 
Message-ID: <75f2b4ce-cf38-452a-92f5-33beddd21c27@openjdk.org>

Changeset: ff1b435e
Author:    Roland Westrelin 
Date:      2020-04-20 08:32:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ff1b435e

8242269: [lworld] C2 compilation fails with assert "meet not symmetric"

Reviewed-by: dsimms, thartmann

! src/hotspot/share/opto/type.cpp

From hseigel at openjdk.java.net  Mon Apr 20 19:42:28 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 20 Apr 2020 19:42:28 GMT
Subject: [lworld] RFR: allow inline classes to have abstract supers
Message-ID: 

Plesae review this change to allow inline classes to have super classes that are abstract classes.  This fix does not
test that the abstract classes are 'special'.  That will be done in a future release.

Also, fix verification issue with assigning an inline type to an object of one of its super classes.

Tests will be added once javac support for inline types having abstract classes is merged in.

Thanks, Harold

-------------

Commit messages:
 - allow inline classes to have abstract supers

Changes: https://git.openjdk.java.net/valhalla/pull/24/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/24/webrev.00
  Stats: 21 lines in 3 files changed: 14 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/24.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/24/head:pull/24

PR: https://git.openjdk.java.net/valhalla/pull/24

From fparain at openjdk.java.net  Mon Apr 20 20:11:17 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 20 Apr 2020 20:11:17 GMT
Subject: [lworld] RFR: allow inline classes to have abstract supers
In-Reply-To: 
References: 
Message-ID: 

On Mon, 20 Apr 2020 19:34:04 GMT, Harold Seigel  wrote:

> Plesae review this change to allow inline classes to have super classes that are abstract classes.  This fix does not
> test that the abstract classes are 'special'.  That will be done in a future release.
> Also, fix verification issue with assigning an inline type to an object of one of its super classes.
> 
> Tests will be added once javac support for inline types having abstract classes is merged in.
> 
> Thanks, Harold

Looks good to me.
Have you already created the follow-up CR to implement the support for inline friendly abstract classes?
Do you have an idea if changes lines 179-181 of verificationTypes.cpp will trigger more class loading then today? If
yes, could this become an issue?

Fred

-------------

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/24

From hseigel at openjdk.java.net  Mon Apr 20 20:28:59 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 20 Apr 2020 20:28:59 GMT
Subject: [Integrated] [lworld] RFR: allow inline classes to have abstract
 supers
In-Reply-To: 
References: 
Message-ID: 

Changeset: e4e93d77
Author:    Harold Seigel 
Date:      2020-04-20 20:28:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e4e93d77

allow inline classes to have abstract supers

Reviewed-by: fparain

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/verificationType.cpp
! test/hotspot/jtreg/runtime/valhalla/valuetypes/classfileparser/BadValueTypes.java

From hseigel at openjdk.java.net  Mon Apr 20 20:31:34 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 20 Apr 2020 20:31:34 GMT
Subject: [lworld] RFR: allow inline classes to have abstract supers
In-Reply-To: 
References: 
 
Message-ID: <7u1Bd7ZwaEVYrT7EjXZHdNjrxdXuM0I1lipbTvVQ2J8=.23ce2adc-35dc-4642-ac25-3bcdd082d8f0@github.com>

On Mon, 20 Apr 2020 20:08:58 GMT, Frederic Parain  wrote:

>> Plesae review this change to allow inline classes to have super classes that are abstract classes.  This fix does not
>> test that the abstract classes are 'special'.  That will be done in a future release.
>> Also, fix verification issue with assigning an inline type to an object of one of its super classes.
>> 
>> Tests will be added once javac support for inline types having abstract classes is merged in.
>> 
>> Thanks, Harold
>
> Looks good to me.
> Have you already created the follow-up CR to implement the support for inline friendly abstract classes?
> Do you have an idea if changes lines 179-181 of verificationTypes.cpp will trigger more class loading then today? If
> yes, could this become an issue?
> Fred

Hi Fred,

Thanks for reviewing this change.

I have not created the new CR, but will shortly.

The changes to lines 179-181 should not trigger more class loading than
today.? Whenever the verifier needs to check if type A is assignable to
type B, it has to load both types, unless they are the same, or type B
is java.lang.Object or an interface. However, this load would not be
needed if the only valid super class for an inline type was
java.lang.Object.

Thanks, Harold

On 4/20/2020 4:09 PM, Frederic Parain wrote:
>
> *@fparain* approved this pull request.
>
> Looks good to me.
> Have you already created the follow-up CR to implement the support for
> inline friendly abstract classes?
> Do you have an idea if changes lines 179-181 of verificationTypes.cpp
> will trigger more class loading then today? If yes, could this become
> an issue?
>
> Fred
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> .
>

-------------

PR: https://git.openjdk.java.net/valhalla/pull/24

From fparain at openjdk.java.net  Mon Apr 20 20:31:34 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 20 Apr 2020 20:31:34 GMT
Subject: [lworld] RFR: allow inline classes to have abstract supers
In-Reply-To: <7u1Bd7ZwaEVYrT7EjXZHdNjrxdXuM0I1lipbTvVQ2J8=.23ce2adc-35dc-4642-ac25-3bcdd082d8f0@github.com>
References: 
 
 <7u1Bd7ZwaEVYrT7EjXZHdNjrxdXuM0I1lipbTvVQ2J8=.23ce2adc-35dc-4642-ac25-3bcdd082d8f0@github.com>
Message-ID: 

On Mon, 20 Apr 2020 20:27:12 GMT, Harold Seigel  wrote:

>> Looks good to me.
>> Have you already created the follow-up CR to implement the support for inline friendly abstract classes?
>> Do you have an idea if changes lines 179-181 of verificationTypes.cpp will trigger more class loading then today? If
>> yes, could this become an issue?
>> Fred
>
> Hi Fred,
> 
> Thanks for reviewing this change.
> 
> I have not created the new CR, but will shortly.
> 
> The changes to lines 179-181 should not trigger more class loading than
> today.? Whenever the verifier needs to check if type A is assignable to
> type B, it has to load both types, unless they are the same, or type B
> is java.lang.Object or an interface. However, this load would not be
> needed if the only valid super class for an inline type was
> java.lang.Object.
> 
> Thanks, Harold
> 
> On 4/20/2020 4:09 PM, Frederic Parain wrote:
>>
>> *@fparain* approved this pull request.
>>
>> Looks good to me.
>> Have you already created the follow-up CR to implement the support for
>> inline friendly abstract classes?
>> Do you have an idea if changes lines 179-181 of verificationTypes.cpp
>> will trigger more class loading then today? If yes, could this become
>> an issue?
>>
>> Fred
>>
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> ,
>> or unsubscribe
>> .
>>

Harold,

Thank you for the clarifications.

Fred

-------------

PR: https://git.openjdk.java.net/valhalla/pull/24

From dsimms at openjdk.java.net  Thu Apr 23 07:39:10 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 23 Apr 2020 07:39:10 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: 

Merge jdk-15+18

-------------

Commit messages:
 - Trailing Whitespace
 - Merge tag 'jdk-15+18' into lworld_merge
 - Merge commit '6405d75070301465824784cfdcee017095525a27' into lworld_merge
 - Merge compile fix for classesBySignature
 - Merge commit '6b7a466f7469d539159dc6dbd6b2ac945227e450' into lworld_merge
 - Merge commit '67fd181eb8e0013d4f6ad2f0862ab1f15c0d0189' into lworld_merge
 - Merge commit 'd8539a51efe379cacee4093995100bf7fe23a312' into lworld_merge
 - Merge commit 'ccd2a16c5818c1b3fdf1dc251a3c5c8ebff2c6d2' into lworld_merge
 - Merge commit '9fb91b4e9c46be4acf2e879afcb4bc189cff5b1f' into lworld_merge
 - Merge commit '25642dd30317e77bc15d36d5fa512da5fb54dad9' into lworld_merge
 - ...omitting 260 further commits.

The webrevs contain only the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/valhalla/25/webrev.00.0
 - jdk: https://webrevs.openjdk.java.net/valhalla/25/webrev.00.1

Changes: https://git.openjdk.java.net/valhalla/pull/25/files
  Stats: 73955 lines in 1024 files changed: 12219 ins; 58054 del; 3682 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/25.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/25/head:pull/25

PR: https://git.openjdk.java.net/valhalla/pull/25

From dsimms at openjdk.java.net  Thu Apr 23 07:56:22 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 23 Apr 2020 07:56:22 GMT
Subject: [Integrated] [lworld] RFR: Merge jdk
In-Reply-To: 
References: 
Message-ID: 

Changeset: e2f1a5fa
Author:    David Simms 
Date:      2020-04-23 07:46:24 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e2f1a5fa

Merge jdk

! .hgtags
! make/CompileJavaModules.gmk
! make/conf/jib-profiles.js
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/frame_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/sparc/interp_masm_sparc.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/frame_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/c1/c1_LIR.cpp
! src/hotspot/share/c1/c1_LIR.hpp
! src/hotspot/share/c1/c1_LIRAssembler.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/code/compiledMethod.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/arrayKlass.hpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/valueKlass.cpp
! src/hotspot/share/oops/valueKlass.hpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/loopUnswitch.cpp
! src/hotspot/share/opto/machnode.cpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/output.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/subtypenode.cpp
! src/hotspot/share/runtime/biasedLocking.cpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/System.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java
! test/hotspot/jtreg/ProblemList.txt
! test/jdk/TEST.groups
! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! .hgtags
! make/CompileJavaModules.gmk
! make/conf/jib-profiles.js
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/frame_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/sparc/interp_masm_sparc.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/frame_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/c1/c1_LIR.cpp
! src/hotspot/share/c1/c1_LIR.hpp
! src/hotspot/share/c1/c1_LIRAssembler.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/code/compiledMethod.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/arrayKlass.hpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/klass.hpp
+ src/hotspot/share/oops/valueKlass.cpp
+ src/hotspot/share/oops/valueKlass.hpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/loopUnswitch.cpp
! src/hotspot/share/opto/machnode.cpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/output.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/subtypenode.cpp
! src/hotspot/share/runtime/biasedLocking.cpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/System.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java
! test/hotspot/jtreg/ProblemList.txt
! test/jdk/TEST.groups
! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java

From cjplummer at openjdk.java.net  Thu Apr 23 07:56:22 2020
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 23 Apr 2020 07:56:22 GMT
Subject: git: openjdk/valhalla: lworld: 146 new changesets
Message-ID: 

Changeset: 8cb76353
Author:    Andrew Dinn 
Date:      2020-03-26 15:26:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8cb76353

8241665: Configuring --with-jvm-features=-compiler2 fails to build on AArch64

Build config --with-jvm-features=-compiler2 fails on AArch64 because JVMCI path includes opto and ad headers

Reviewed-by: kvn, aph

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp

Changeset: af15605b
Author:    Aleksey Shipilev 
Date:      2020-03-30 19:37:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/af15605b

8241838: Shenandoah: no need to trash cset during final mark

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp

Changeset: a8a9fb95
Author:    Aleksey Shipilev 
Date:      2020-03-30 19:37:37 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a8a9fb95

8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp

Changeset: 87396af7
Author:    Aleksey Shipilev 
Date:      2020-03-30 19:38:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/87396af7

8241842: Shenandoah: inline ShenandoahHeapRegion::region_number

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp

Changeset: 6df23701
Author:    Aleksey Shipilev 
Date:      2020-03-30 19:38:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6df23701

8241844: Shenandoah: rename ShenandoahHeapRegion::region_number

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp
! src/hotspot/share/gc/shenandoah/vmStructs_shenandoah.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahBitMap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeapRegion.java

Changeset: b7439a8a
Author:    Stefan Karlsson 
Date:      2020-03-27 15:28:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b7439a8a

8241361: ZGC: Implement memory related JFR events

Co-authored-by: Per Liden 
Reviewed-by: pliden, eosterlund

! src/hotspot/share/gc/z/zPageAllocator.cpp
! src/hotspot/share/gc/z/zPageAllocator.hpp
! src/hotspot/share/gc/z/zRelocationSetSelector.cpp
! src/hotspot/share/gc/z/zRelocationSetSelector.hpp
! src/hotspot/share/gc/z/zRelocationSetSelector.inline.hpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zTracer.cpp
! src/hotspot/share/gc/z/zTracer.hpp
! src/hotspot/share/gc/z/zTracer.inline.hpp
! src/hotspot/share/jfr/metadata/metadata.xml
! src/jdk.jfr/share/conf/jfr/default.jfc
! src/jdk.jfr/share/conf/jfr/profile.jfc

Changeset: 916f00ac
Author:    Joe Darcy 
Date:      2020-03-30 13:49:02 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/916f00ac

8241374: add Math.absExact

Reviewed-by: smarks, chegar, bpb

! src/java.base/share/classes/java/lang/Math.java
! src/java.base/share/classes/java/lang/StrictMath.java
+ test/jdk/java/lang/Math/AbsTests.java

Changeset: 53b2368d
Author:    Ivan Gerasimov 
Date:      2020-03-30 13:59:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/53b2368d

8241760: Typos: empty lines in javadoc, inconsistent indents, etc. (net and nio)

Reviewed-by: alanb, prappo, dfuchs

! src/java.base/share/classes/java/net/HttpURLConnection.java
! src/java.base/share/classes/java/net/Inet4Address.java
! src/java.base/share/classes/java/net/NetPermission.java
! src/java.base/share/classes/java/net/Proxy.java
! src/java.base/share/classes/java/net/SecureCacheResponse.java
! src/java.base/share/classes/java/net/Socket.java
! src/java.base/share/classes/java/net/SocketImpl.java
! src/java.base/share/classes/java/net/URL.java
! src/java.base/share/classes/java/net/URLConnection.java
! src/java.base/share/classes/java/nio/channels/AsynchronousChannelGroup.java
! src/java.base/share/classes/java/nio/channels/SelectionKey.java
! src/java.base/share/classes/java/nio/charset/Charset.java
! src/java.base/share/classes/java/nio/file/FileStore.java
! src/java.base/share/classes/java/nio/file/attribute/BasicFileAttributeView.java
! src/java.base/share/classes/sun/net/www/URLConnection.java
! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java
! src/java.base/share/classes/sun/nio/ByteBuffered.java
! src/java.base/share/classes/sun/nio/ch/IOVecWrapper.java
! src/java.base/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/java.base/windows/classes/sun/nio/fs/WindowsPathParser.java
! src/jdk.charsets/share/classes/sun/nio/cs/ext/ISCII91.java
! src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022_JP.java
! src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java
! src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java

Changeset: 83a9afaf
Author:    Claes Redestad 
Date:      2020-03-30 23:55:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/83a9afaf

8241852: Cleanup error message generation in LinkResolver::resolve_field

Reviewed-by: dcubed

! src/hotspot/share/interpreter/linkResolver.cpp

Changeset: de7ea8db
Author:    Aleksey Shipilev 
Date:      2020-03-31 08:42:00 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/de7ea8db

8241845: Shenandoah: align ShenandoahHeapRegions to cache lines

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPadding.hpp

Changeset: 2bc86911
Author:    Christoph Langer 
Date:      2020-03-31 09:10:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2bc86911

8241568: (fs) UserPrincipalLookupService.lookupXXX failure with IOE "Operation not permitted"

Reviewed-by: alanb

! src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c

Changeset: 6a4e93bb
Author:    Stefan Johansson 
Date:      2020-03-31 11:45:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6a4e93bb

8241666: Enhance log messages in ReferenceProcessor

Reviewed-by: tschatzl, sangheki

! src/hotspot/share/gc/shared/referenceProcessor.cpp
! test/hotspot/jtreg/gc/logging/TestPrintReferences.java

Changeset: 4b4633d9
Author:    Ravi Reddy 
Committer: Ravi Reddy 
Date:      2020-03-31 14:07:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4b4633d9

8240988: Incorrect copyright header in CertificateValidation.java

Reviewed-by: pkoppula, coffeys

! test/jdk/sun/security/x509/X509CertImpl/CertificateValidation.java

Changeset: 16df851e
Author:    Stefan Karlsson 
Date:      2020-03-18 17:28:41 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/16df851e

8241160: Concurrent class unloading reports GCTraceTime events as JFR pause sub-phase events

Reviewed-by: eosterlund, kbarrett

! src/hotspot/share/gc/g1/g1VMOperations.cpp
! src/hotspot/share/gc/shared/gcTimer.cpp
! src/hotspot/share/gc/shared/gcTimer.hpp
! src/hotspot/share/gc/shared/gcTraceSend.cpp
! src/hotspot/share/gc/shared/gcTraceTime.cpp
! src/hotspot/share/gc/shared/gcTraceTime.hpp
! src/hotspot/share/gc/shared/gcTraceTime.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/jfr/metadata/metadata.xml
! src/hotspot/share/utilities/ticks.hpp
! src/jdk.jfr/share/conf/jfr/default.jfc
! src/jdk.jfr/share/conf/jfr/profile.jfc
! test/hotspot/gtest/gc/shared/test_gcTimer.cpp

Changeset: 75849a5c
Author:    Magnus Ihse Bursie 
Date:      2020-03-31 14:58:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/75849a5c

8241421: Cleanup handling of jtreg

Reviewed-by: erikj

! make/autoconf/spec.gmk.in
! make/autoconf/toolchain.m4
! make/conf/jib-profiles.js
! make/test/BuildFailureHandler.gmk

Changeset: 8fdf2925
Author:    Stefan Karlsson 
Date:      2020-03-31 14:57:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8fdf2925

8241827: JFR: TestVMInfoEvent.java requires SerialGC

Reviewed-by: mseledtsov

! test/jdk/jdk/jfr/event/runtime/TestVMInfoEvent.java

Changeset: b31bea8a
Author:    Claes Redestad 
Date:      2020-03-31 16:09:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b31bea8a

8241830: Simplify commit error messages in G1PageBasedVirtualSpace

Reviewed-by: sjohanss, lkorinth, kbarrett

! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp

Changeset: 931af126
Author:    Leonid Mesnik 
Date:      2020-03-31 13:35:21 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/931af126

8241478: vmTestbase/gc/gctests/Steal/steal001/steal001.java fails with OOME

Reviewed-by: tschatzl, kbarrett

- test/hotspot/jtreg/vmTestbase/gc/gctests/Steal/steal001/TEST.properties
- test/hotspot/jtreg/vmTestbase/gc/gctests/Steal/steal001/steal001.java
- test/hotspot/jtreg/vmTestbase/gc/gctests/Steal/steal002/TEST.properties
- test/hotspot/jtreg/vmTestbase/gc/gctests/Steal/steal002/steal002.java

Changeset: 8cb3cc01
Author:    Jonathan Gibbons 
Date:      2020-03-31 13:47:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8cb3cc01

8241693: The paragraphs in the help page should not be in a 
                  

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/testHelpFile/TestHelpFile.java

Changeset: 6d44ff7d
Author:    Martin Buchholz 
Date:      2020-03-31 14:15:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6d44ff7d

8186780: clang fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

Reviewed-by: jiangli

! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp

Changeset: 35f4df51
Author:    Jonathan Gibbons 
Date:      2020-03-31 14:47:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/35f4df51

8241625: use new "member-list" CSS class instead of general "block-list" for list of members

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialMethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeFieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeRequiredMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ConstructorWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/EnumConstantWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/FieldWriter.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/MemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/MethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PropertyWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeFieldBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java
! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java
! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java
+ test/langtools/jdk/javadoc/doclet/testLists/TestLists.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! test/langtools/jdk/javadoc/doclet/testUseOption/TestUseOption.java

Changeset: aba017fa
Author:    Chris Yin 
Date:      2020-04-01 10:11:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/aba017fa

8214694: cleanup rawtypes warnings in open jndi tests

Reviewed-by: darcy, vtewari

! test/jdk/com/sun/jndi/dns/CheckAccess.java
! test/jdk/com/sun/jndi/dns/EnvTests/AddInherited.java
! test/jdk/com/sun/jndi/dns/EnvTests/GetEnv.java
! test/jdk/com/sun/jndi/dns/EnvTests/RemoveInherited.java
! test/jdk/com/sun/jndi/dns/EnvTests/SubcontextAdd.java
! test/jdk/com/sun/jndi/dns/EnvTests/SubcontextRemove.java
! test/jdk/com/sun/jndi/dns/FactoryTests/TestDnsObject.java
! test/jdk/com/sun/jndi/dns/FedTests/ListFedBase.java
! test/jdk/com/sun/jndi/dns/FedTests/ListNns.java
! test/jdk/com/sun/jndi/dns/FedTests/ListSubInterior.java
! test/jdk/com/sun/jndi/dns/FedTests/ListSubLeaf.java
! test/jdk/com/sun/jndi/dns/ListTests/ListBindingsInteriorNotFound.java
! test/jdk/com/sun/jndi/dns/ListTests/ListBindingsLeafNotFound.java
! test/jdk/com/sun/jndi/dns/ListTests/ListInteriorNotFound.java
! test/jdk/com/sun/jndi/dns/ListTests/ListLeafNotFound.java
! test/jdk/com/sun/jndi/ldap/BalancedParentheses.java
! test/jdk/com/sun/jndi/ldap/Base64Test.java
! test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java
! test/jdk/com/sun/jndi/ldap/InvalidLdapFilters.java
! test/jdk/com/sun/jndi/ldap/LdapName/EmptyNameSearch.java
! test/jdk/com/sun/jndi/ldap/NoWaitForReplyTest.java
! test/jdk/com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java
! test/jdk/javax/naming/InitialContext/EnvClone.java
! test/jdk/javax/naming/ldap/LdapName/CompareToEqualsTests.java
! test/jdk/javax/naming/ldap/LdapName/LdapNameConstruction.java
! test/jdk/javax/naming/ldap/LdapName/NameTests.java
! test/jdk/javax/naming/spi/DirectoryManager/DummyContext.java
! test/jdk/javax/naming/spi/DirectoryManager/GetContDirCtx.java
! test/jdk/javax/naming/spi/DummyContextFactory.java
! test/jdk/javax/naming/spi/DummyContextFactory2.java

Changeset: 5700a934
Author:    Mandy Chung 
Date:      2020-03-31 19:18:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5700a934

8241964: Clean up java.lang.Class javadoc

Reviewed-by: darcy

! src/java.base/share/classes/java/lang/Class.java

Changeset: 990a11e4
Author:    Tobias Hartmann 
Date:      2020-04-01 10:06:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/990a11e4

8241909: Remove useless code cache lookup in frame::patch_pc

Removed useless code cache lookup.

Reviewed-by: kvn, dlong

! src/hotspot/cpu/aarch64/frame_aarch64.cpp
! src/hotspot/cpu/arm/frame_arm.cpp
! src/hotspot/cpu/ppc/frame_ppc.cpp
! src/hotspot/cpu/s390/frame_s390.cpp
! src/hotspot/cpu/sparc/frame_sparc.cpp
! src/hotspot/cpu/x86/frame_x86.cpp
! src/hotspot/cpu/zero/frame_zero.cpp

Changeset: c8b1f966
Author:    Stefan Karlsson 
Date:      2020-04-01 12:37:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c8b1f966

8241976: Add test for GCPhaseConcurrentLevel1 JFR event

Reviewed-by: pliden, eosterlund

+ test/jdk/jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
! test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java
! test/lib/jdk/test/lib/jfr/EventNames.java

Changeset: f1ef83b0
Author:    Jan Lahoda 
Date:      2020-04-01 13:12:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f1ef83b0

8241598: Upgrade JLine to 3.14.0

Upgrading to JLine 3.14.0

Reviewed-by: psandoz, rfield

! src/jdk.internal.le/share/classes/jdk/internal/org/jline/keymap/BindingReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Candidate.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/ConfigurationPath.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/EOFError.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Editor.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Highlighter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/History.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/LineReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Parser.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/ScriptEngine.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/DefaultHighlighter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/DefaultParser.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/completer/ArgumentCompleter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/completer/StringsCompleter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/history/DefaultHistory.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/TerminalBuilder.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractPosixTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractPty.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractWindowsTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ExternalTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/LineDisciplineTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/PosixPtyTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/PosixSysTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Display.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/InfoCmp.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingInputStream.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingPumpReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingReaderImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Status.java
= src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/dumb-color.caps
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/windows-256color.caps
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/windows-conemu.caps
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/windows-vtp.caps
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/windows.caps
! src/jdk.internal.le/share/legal/jline.md
! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/JnaSupportImpl.java

Changeset: 6c9d6507
Author:    Per Lid?n 
Date:      2020-04-01 13:44:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6c9d6507

8241881: ZGC: Add tests for JFR events

Reviewed-by: stefank, eosterlund, egahlin

+ test/jdk/jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java
+ test/jdk/jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java
+ test/jdk/jdk/jfr/event/gc/detailed/TestZPageCacheFlushEvent.java
+ test/jdk/jdk/jfr/event/gc/detailed/TestZRelocationSetEvent.java
+ test/jdk/jdk/jfr/event/gc/detailed/TestZRelocationSetGroupEvent.java
+ test/jdk/jdk/jfr/event/gc/detailed/TestZUncommitEvent.java
! test/lib/jdk/test/lib/jfr/EventNames.java

Changeset: 8d84cf5a
Author:    Claes Redestad 
Date:      2020-04-01 14:35:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8d84cf5a

8241837: Cleanup stringStream usage in ObjectSynchronizer

Reviewed-by: dcubed, dholmes

! src/hotspot/share/runtime/synchronizer.cpp

Changeset: bf41f548
Author:    Robbin Ehn 
Date:      2020-04-01 14:54:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/bf41f548

8220051: Remove global safepoint code

Reviewed-by: mdoerr, dcubed, eosterlund, bulasevich, coleenp

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/arm/globalDefinitions_arm.hpp
! src/hotspot/cpu/arm/interp_masm_arm.cpp
! src/hotspot/cpu/arm/macroAssembler_arm.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/ppc/globalDefinitions_ppc.hpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp
! src/hotspot/cpu/ppc/nativeInst_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
! src/hotspot/cpu/s390/globalDefinitions_s390.hpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp
! src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp
! src/hotspot/cpu/sparc/interp_masm_sparc.cpp
! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp
! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp
! src/hotspot/cpu/sparc/sparc.ad
! src/hotspot/cpu/sparc/templateTable_sparc.cpp
! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/globalDefinitions_x86.hpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/nativeInst_x86.hpp
! src/hotspot/cpu/x86/relocInfo_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/cpu/zero/globalDefinitions_zero.hpp
! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/aix/safepointMechanism_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/solaris/os_solaris.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp
! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp
! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp
! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp
! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp
! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp
! src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp
! src/hotspot/os_cpu/solaris_sparc/os_solaris_sparc.cpp
! src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp
! src/hotspot/share/aot/aotCodeHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/z/zMark.cpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/machnode.cpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/runtime/biasedLocking.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/safepointMechanism.cpp
! src/hotspot/share/runtime/safepointMechanism.hpp
! src/hotspot/share/runtime/safepointMechanism.inline.hpp
! src/hotspot/share/runtime/sweeper.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/utilities/vmError.cpp
! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java
! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MarkProcessor.java

Changeset: 15c3d76a
Author:    Lutz Schmidt 
Date:      2020-04-01 14:51:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/15c3d76a

8241101: [s390] jtreg test failure after JDK-8238696: not conformant features string

Reviewed-by: stuefe, mdoerr, clanger

! src/hotspot/cpu/s390/vm_version_s390.cpp

Changeset: fc806b67
Author:    Matthias Baesken 
Date:      2020-03-31 17:11:30 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/fc806b67

8241948: enhance list of environment variables printed in hs_err file

Reviewed-by: dholmes, hseigel

! src/hotspot/share/utilities/vmError.cpp

Changeset: 6af855fd
Author:    Aleksey Shipilev 
Date:      2020-04-01 19:50:10 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6af855fd

8241926: Shenandoah: only print heap changes for operations that directly affect it

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 961c1d6a
Author:    Aleksey Shipilev 
Date:      2020-04-01 19:50:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/961c1d6a

8241985: Shenandoah: simplify collectable garbage logging

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp

Changeset: 25b2118b
Author:    Aleksey Shipilev 
Date:      2020-04-01 19:50:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/25b2118b

8241983: Shenandoah: simplify FreeSet logging

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp

Changeset: e08f25a9
Author:    Claes Redestad 
Date:      2020-04-01 20:53:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e08f25a9

8242003: Remove CallInfo::_selected_klass

Reviewed-by: lfoltan, dcubed, coleenp

! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp

Changeset: 13af7bb9
Author:    Leonid Mesnik 
Date:      2020-04-01 16:27:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/13af7bb9

8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified

Reviewed-by: iignatyev, iklam, cjplummer

! test/hotspot/jtreg/ProblemList-aot.txt
! test/hotspot/jtreg/ProblemList-zgc.txt
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
! test/hotspot/jtreg/resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbJstack.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java
! test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java
! test/hotspot/jtreg/serviceability/sa/TestCpoolForInvokeDynamic.java
! test/hotspot/jtreg/serviceability/sa/TestDefaultMethods.java
! test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java
! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java
! test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSize.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java
! test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java
! test/hotspot/jtreg/serviceability/sa/TestRevPtrsForInvokeDynamic.java
! test/jdk/sun/jvmstat/monitor/MonitoredVm/TestPollingInterval.java
! test/jdk/sun/tools/jhsdb/heapconfig/TmtoolTestScenario.java
! test/jdk/sun/tools/jinfo/JInfoTest.java
! test/lib/jdk/test/lib/apps/LingeredApp.java

Changeset: cc25927f
Author:    Jesper Wilhelmsson 
Date:      2020-04-02 03:04:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cc25927f

Added tag jdk-15+17 for changeset dd5198db2e5b

! .hgtags

Changeset: 3790e580
Author:    Ivan Gerasimov 
Date:      2020-04-01 18:38:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3790e580

8241761: Typos: empty lines in javadoc, inconsistent indents, etc. (security-libs only)

Reviewed-by: weijun

! src/java.base/macosx/classes/apple/security/KeychainStore.java
! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Poly1305Parameters.java
! src/java.base/share/classes/com/sun/crypto/provider/FeedbackCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java
! src/java.base/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java
! src/java.base/share/classes/java/security/BasicPermission.java
! src/java.base/share/classes/java/security/KeyFactorySpi.java
! src/java.base/share/classes/java/security/KeyManagementException.java
! src/java.base/share/classes/java/security/KeyPair.java
! src/java.base/share/classes/java/security/PrivateKey.java
! src/java.base/share/classes/java/security/Provider.java
! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/classes/java/security/SecurityPermission.java
! src/java.base/share/classes/java/security/Signer.java
! src/java.base/share/classes/java/security/cert/CRLException.java
! src/java.base/share/classes/java/security/cert/PKIXParameters.java
! src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java
! src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java
! src/java.base/share/classes/java/security/spec/RSAPrivateCrtKeySpec.java
! src/java.base/share/classes/javax/crypto/ExemptionMechanism.java
! src/java.base/share/classes/javax/crypto/spec/RC2ParameterSpec.java
! src/java.base/share/classes/javax/crypto/spec/RC5ParameterSpec.java
! src/java.base/share/classes/javax/crypto/spec/SecretKeySpec.java
! src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java
! src/java.base/share/classes/javax/security/auth/x500/X500PrivateCredential.java
! src/java.base/share/classes/sun/security/provider/SunEntries.java
! src/java.base/share/classes/sun/security/provider/certpath/CertId.java
! src/java.base/share/classes/sun/security/ssl/CertificateVerify.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/java.base/share/classes/sun/security/x509/AlgorithmId.java
! src/java.base/share/classes/sun/security/x509/DNSName.java
! src/java.base/share/classes/sun/security/x509/DeltaCRLIndicatorExtension.java
! src/java.base/share/classes/sun/security/x509/ExtendedKeyUsageExtension.java
! src/java.base/share/classes/sun/security/x509/FreshestCRLExtension.java
! src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java
! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java
! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddress.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddresses.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/ClientFactoryImpl.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/CramMD5Base.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/CramMD5Client.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/CramMD5Server.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/ExternalClient.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/PlainClient.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/ServerFactoryImpl.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/FactoryImpl.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/SecurityCtx.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java
! src/java.security.sasl/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/java.security.sasl/share/classes/javax/security/sasl/AuthorizeCallback.java
! src/java.security.sasl/share/classes/javax/security/sasl/RealmCallback.java
! src/java.security.sasl/share/classes/javax/security/sasl/RealmChoiceCallback.java
! src/java.security.sasl/share/classes/javax/security/sasl/SaslClient.java
! src/java.security.sasl/share/classes/javax/security/sasl/SaslServer.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/jdk.security.auth/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java
! src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/FactoryImpl.java
! src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java
! src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java

Changeset: 0386b7d0
Author:    Tagir F. Valeev 
Date:      2020-04-02 05:44:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0386b7d0

8176894: Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap

Co-authored-by: Sergey Kuksenko 
Reviewed-by: martin, stuefe, rriggs

! src/java.base/share/classes/java/util/TreeMap.java
! test/jdk/java/util/Map/FunctionalCMEs.java
! test/jdk/java/util/Map/InPlaceOpsCollisions.java
+ test/micro/org/openjdk/bench/java/util/TreeMapUpdate.java

Changeset: 2718bcd0
Author:    Stefan Karlsson 
Date:      2020-04-02 12:52:24 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2718bcd0

8242031: TestLookForUntestedEvents.java fails because newly added test tests experimental events

Reviewed-by: eosterlund, pliden

! test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java

Changeset: 15fcf274
Author:    Christoph Langer 
Date:      2020-04-02 13:06:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/15fcf274

8241947: Minor comment fixes for system property handling

Reviewed-by: ihse, mchung, alanb

! make/autoconf/spec.gmk.in
! src/java.base/share/classes/java/lang/System.java

Changeset: c6b22388
Author:    Chris Hegarty 
Date:      2020-04-02 12:33:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c6b22388

8241921: Remove leftover diagnostic from test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java

Reviewed-by: lancea

! test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java

Changeset: 73ddea76
Author:    Roland Westrelin 
Date:      2020-03-24 17:56:15 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/73ddea76

8241492: Strip mining not working for test/hotspot/jtreg/compiler/c2/Test6850611.java

Reviewed-by: mdoerr, thartmann, neliasso

! src/hotspot/share/opto/loopnode.cpp
! test/hotspot/jtreg/compiler/loopstripmining/CheckLoopStripMining.java

Changeset: ea56776e
Author:    Roland Westrelin 
Date:      2020-03-31 10:40:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ea56776e

8239072: subtype check macro node causes node budget to be exhausted

Reviewed-by: vlivanov, kvn

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/macro.cpp

Changeset: fb56759d
Author:    Claes Redestad 
Date:      2020-04-02 18:22:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/fb56759d

8242027: Clean up LinkResolver::check_klass_accessability

Reviewed-by: dholmes

! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/oops/constantPool.cpp

Changeset: 5532b27d
Author:    Jatin Bhateja 
Date:      2020-04-02 22:38:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5532b27d

8241040: Support for AVX-512 Ternary Logic Instruction

A new pass has been added which folds expression tree involving vector boolean logic operations into a MacroLogic node.

Reviewed-by: vlivanov, neliasso

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/vectornode.cpp
! src/hotspot/share/opto/vectornode.hpp
+ test/hotspot/jtreg/compiler/vectorization/TestMacroLogicVector.java
+ test/micro/org/openjdk/bench/vm/compiler/MacroLogicOpt.java

Changeset: 6570425d
Author:    Aleksey Shipilev 
Date:      2020-04-02 20:10:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6570425d

8242040: Shenandoah: print allocation failure type

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahAllocRequest.hpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 487070cc
Author:    Aleksey Shipilev 
Date:      2020-04-02 20:11:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/487070cc

8242041: Shenandoah: adaptive heuristics should account evac reserve in free target

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp

Changeset: 3ae56fdf
Author:    Tom Rodriguez 
Date:      2020-04-02 11:20:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3ae56fdf

8191930: [Graal] emits unparseable XML into compile log

Reviewed-by: kvn

! src/hotspot/share/compiler/compileTask.cpp

Changeset: 80b86444
Author:    Stefan Johansson 
Date:      2020-04-02 21:33:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/80b86444

8241670: Enhance heap region size ergonomics to improve OOTB performance

Reviewed-by: redestad, tschatzl

! src/hotspot/share/gc/g1/g1Arguments.cpp
! src/hotspot/share/gc/g1/heapRegion.cpp
! src/hotspot/share/gc/g1/heapRegion.hpp
! src/hotspot/share/gc/g1/heapRegionBounds.hpp
! test/hotspot/jtreg/gc/arguments/TestG1HeapRegionSize.java

Changeset: cf22d444
Author:    David Holmes 
Date:      2020-04-02 19:13:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cf22d444

8239895: assert(_stack_base != 0LL) failed: Sanity check

Reviewed-by: dcubed, stuefe

! src/hotspot/cpu/aarch64/frame_aarch64.cpp
! src/hotspot/cpu/arm/frame_arm.cpp
! src/hotspot/cpu/ppc/frame_ppc.cpp
! src/hotspot/cpu/s390/frame_s390.cpp
! src/hotspot/cpu/x86/frame_x86.cpp
! src/hotspot/os_cpu/solaris_sparc/os_solaris_sparc.cpp
! src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: a76f0f78
Author:    Leonid Mesnik 
Date:      2020-04-02 17:30:21 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a76f0f78

8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization

Reviewed-by: dholmes, iignatyev

! test/hotspot/jtreg/vmTestbase/nsk/share/Wicket.java
! test/hotspot/jtreg/vmTestbase/nsk/share/runner/ThreadsRunner.java

Changeset: 61940fe4
Author:    Chris Hegarty 
Date:      2020-04-03 07:16:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/61940fe4

8241988: DatagramSocket incorrectly caches the first set of socket options

Reviewed-by: msheppar, dfuchs, alanb

! src/java.base/share/classes/java/net/DatagramSocket.java
! src/java.base/share/classes/java/net/MulticastSocket.java
+ test/jdk/java/net/SocketOption/CachedImplOptions.java

Changeset: 9a69bb80
Author:    Chris Hegarty 
Date:      2020-04-03 07:27:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9a69bb80

8242044: Add basic HTTP/1.1 support to the HTTP/2 Test Server

Reviewed-by: dfuchs, michaelm

+ test/jdk/java/net/httpclient/HttpVersionsTest.java
! test/jdk/java/net/httpclient/http2/server/Http2TestServer.java
! test/jdk/java/net/httpclient/http2/server/Http2TestServerConnection.java

Changeset: 934b8a98
Author:    Man Cao 
Date:      2020-04-03 02:00:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/934b8a98

8241556: Memory leak if -XX:CompileCommand is set

Reviewed-by: rasbold, thartmann, neliasso

! src/hotspot/share/compiler/compilerDirectives.cpp
! src/hotspot/share/compiler/compilerDirectives.hpp

Changeset: a21c4fb0
Author:    Pengfei Li 
Date:      2020-04-03 17:06:14 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a21c4fb0

8241475: AArch64: Add missing support for PopCountVI node

Reviewed-by: aph, njian

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp

Changeset: f82e44cc
Author:    Aleksey Shipilev 
Date:      2020-04-03 11:33:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f82e44cc

8242073: x86_32 build failure after JDK-8241040

Reviewed-by: vlivanov

! src/hotspot/cpu/x86/x86_32.ad

Changeset: 62b7404b
Author:    Aleksey Shipilev 
Date:      2020-04-03 11:33:30 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/62b7404b

8242042: Shenandoah: tune down ShenandoahGarbageThreshold

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: cd76575d
Author:    Aleksey Shipilev 
Date:      2020-04-03 11:33:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cd76575d

8242075: Shenandoah: rename ShenandoahHeapRegionSize flag

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! test/hotspot/jtreg/gc/TestHumongousReferenceObject.java
! test/hotspot/jtreg/gc/shenandoah/options/TestRegionSizeArgs.java

Changeset: 218d0f71
Author:    Matthias Baesken 
Date:      2020-04-02 12:44:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/218d0f71

8242000: clean up list of environment variables printed in hs_err file

Reviewed-by: redestad, stuefe

! src/hotspot/share/utilities/vmError.cpp

Changeset: 21d5f88f
Author:    Aleksey Shipilev 
Date:      2020-04-03 13:58:32 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/21d5f88f

8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp

Changeset: c09b0a77
Author:    Aleksey Shipilev 
Date:      2020-04-03 13:58:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c09b0a77

8242089: Shenandoah: per-worker stats should be summed up, not averaged

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp

Changeset: 553ea1e8
Author:    Roman Kennke 
Date:      2020-04-03 15:06:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/553ea1e8

8242082: Shenandoah: Purge Traversal mode

Reviewed-by: shade

! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/share/gc/shared/gcCause.cpp
! src/hotspot/share/gc/shared/gcCause.hpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
- src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.cpp
- src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.hpp
- src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp
- src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentRoots.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp
! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
- src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp
- src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.hpp
- src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.inline.hpp
- src/hotspot/share/gc/shenandoah/shenandoahTraversalMode.cpp
- src/hotspot/share/gc/shenandoah/shenandoahTraversalMode.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.hpp
! src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp
! src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! src/hotspot/share/runtime/vmOperations.hpp
! test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java
! test/hotspot/jtreg/gc/CriticalNativeArgs.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocHumongousFragment.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocIntArrays.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocObjectArrays.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocObjects.java
! test/hotspot/jtreg/gc/shenandoah/TestGCThreadGroups.java
! test/hotspot/jtreg/gc/shenandoah/TestHeapUncommit.java
! test/hotspot/jtreg/gc/shenandoah/TestLotsOfCycles.java
! test/hotspot/jtreg/gc/shenandoah/TestObjItrWithHeapDump.java
! test/hotspot/jtreg/gc/shenandoah/TestPeriodicGC.java
! test/hotspot/jtreg/gc/shenandoah/TestRefprocSanity.java
! test/hotspot/jtreg/gc/shenandoah/TestRegionSampling.java
! test/hotspot/jtreg/gc/shenandoah/TestRetainObjects.java
! test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java
! test/hotspot/jtreg/gc/shenandoah/TestStringDedup.java
! test/hotspot/jtreg/gc/shenandoah/TestStringDedupStress.java
! test/hotspot/jtreg/gc/shenandoah/TestStringInternCleanup.java
! test/hotspot/jtreg/gc/shenandoah/TestVerifyJCStress.java
! test/hotspot/jtreg/gc/shenandoah/TestWrongArrayMember.java
! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java
! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java
! test/hotspot/jtreg/gc/shenandoah/oom/TestClassLoaderLeak.java
! test/hotspot/jtreg/gc/shenandoah/options/TestExplicitGC.java
! test/hotspot/jtreg/gc/shenandoah/options/TestHeuristicsUnlock.java
! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java
! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java
! test/hotspot/jtreg/gc/stress/CriticalNativeStress.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithShenandoah.java
! test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java
! test/hotspot/jtreg/gc/stress/systemgc/TestSystemGCWithShenandoah.java

Changeset: f541970b
Author:    Daniel Fuchs 
Date:      2020-04-03 14:27:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f541970b

8241786: Improve heuristic to determine default network interface on macOS

DefaultInetrface.getDefault is updated to prefer interfaces that have non link-local addresses. NetworkConfiguration is updated to skip interface that have only link-local addresses, whether IPv4 or IPv6, for multicasting.

Reviewed-by: chegar, alanb

! src/java.base/macosx/classes/java/net/DefaultInterface.java
! test/jdk/java/net/MulticastSocket/SetLoopbackMode.java
! test/jdk/java/net/MulticastSocket/SetLoopbackModeIPv4.java
! test/jdk/java/net/MulticastSocket/SetOutgoingIf.java
! test/jdk/java/nio/channels/DatagramChannel/AdaptorMulticasting.java
! test/jdk/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java
! test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java
! test/lib/jdk/test/lib/NetworkConfiguration.java

Changeset: 746d28d1
Author:    Christoph Langer 
Date:      2020-04-03 15:40:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/746d28d1

8242030: Wrong package declarations in jline classes after JDK-8241598

Reviewed-by: jlahoda

! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/ConfigurationPath.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/ScriptEngine.java

Changeset: fe2a8203
Author:    Aleksey Shipilev 
Date:      2020-04-03 16:13:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/fe2a8203

8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp

Changeset: a3090460
Author:    Claes Redestad 
Date:      2020-04-03 17:20:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a3090460

8241585: Remove unused _recursion_counter facility from PerfTraceTime
8241705: Tune PerfData collections

Reviewed-by: iklam, dholmes

! src/hotspot/share/runtime/perfData.cpp
! src/hotspot/share/runtime/perfData.hpp
! src/hotspot/share/runtime/perfData.inline.hpp

Changeset: 59af1c2a
Author:    Jaikiran Pai 
Date:      2020-03-24 15:47:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/59af1c2a

8241138: http.nonProxyHosts=* causes StringIndexOutOfBoundsException in DefaultProxySelector

Reviewed-by: dfuchs, chegar

! src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
! test/jdk/java/net/ProxySelector/B8035158.java

Changeset: ff34c4cd
Author:    Roman Kennke 
Date:      2020-04-03 19:33:06 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ff34c4cd

8242107: Shenandoah: Fix aarch64 build after JDK-8242082

Reviewed-by: shade

! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp

Changeset: acafdb3f
Author:    Joe Wang 
Date:      2020-04-03 17:34:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/acafdb3f

8238183: SAX2StAXStreamWriter cannot deal with comments prior to the root element

Reviewed-by: naoto, lancea

! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXBaseWriter.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXEventWriter.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXStreamWriter.java
+ test/jaxp/javax/xml/jaxp/unittest/transform/ResultTest.java

Changeset: 965404dd
Author:    Chris Plummer 
Date:      2020-04-03 12:58:15 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/965404dd

8240989: convert clhsdb "dumpheap" command from javascript to java

Reviewed-by: amenkov, ysuenaga

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
! test/hotspot/jtreg/ProblemList-zgc.txt
! test/hotspot/jtreg/ProblemList.txt
+ test/hotspot/jtreg/serviceability/sa/ClhsdbDumpheap.java

Changeset: 512644de
Author:    Calvin Cheung 
Date:      2020-04-03 14:26:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/512644de

8240205: Avoid PackageEntry lookup when loading shared classes

Do the PackageEntry lookup at one place and then pass it along to the subsequently called functions which need it.

Reviewed-by: redestad, lfoltan

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/arrayKlass.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/klass.hpp

Changeset: 76d53498
Author:    Alexey Bakhtin 
Date:      2020-04-03 22:39:00 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/76d53498

8241960: The SHA3 message digests impl of SUN provider are not thread safe after cloned

Fix sun.security.provider.SHA3 class to correctly clone its lanes field

Reviewed-by: valeriep

! src/java.base/share/classes/sun/security/provider/SHA3.java
+ test/jdk/java/security/MessageDigest/ThreadSafetyTest.java

Changeset: 2e478341
Author:    Per Lid?n 
Date:      2020-04-03 23:40:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2e478341

8240745: Implementation: JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)

Reviewed-by: stefank, eosterlund

! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/z/z_globals.hpp
! src/hotspot/share/jfr/metadata/metadata.xml
! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java
! test/hotspot/jtreg/compiler/loopopts/TestRangeCheckPredicatesControl.java
! test/hotspot/jtreg/gc/arguments/TestDisableDefaultGC.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java
! test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithZ.java
! test/hotspot/jtreg/gc/z/TestAllocateHeapAt.java
! test/hotspot/jtreg/gc/z/TestAlwaysPreTouch.java
! test/hotspot/jtreg/gc/z/TestHighUsage.java
! test/hotspot/jtreg/gc/z/TestSmallHeap.java
! test/hotspot/jtreg/gc/z/TestUncommit.java
! test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java
! test/jdk/java/lang/management/MemoryMXBean/MemoryTestZGC.sh
! test/jdk/jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestZPageCacheFlushEvent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestZRelocationSetEvent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestZRelocationSetGroupEvent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestZUncommitEvent.java
! test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java

Changeset: a6b990f7
Author:    Chris Plummer 
Date:      2020-04-04 09:24:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a6b990f7

8242153: ProblemList serviceability/sa/ClhsdbDumpheap.java on OSX

Reviewed-by: dcubed

! test/hotspot/jtreg/ProblemList.txt

Changeset: ed008731
Author:    Xue-Lei Andrew Fan 
Date:      2020-04-05 20:17:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ed008731

8215711: Missing key_share extension for (EC)DHE key exchange should alert missing_extension

Reviewed-by: ascarpino

! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java
! src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLExtension.java
! src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java

Changeset: fc9389c1
Author:    Matthias Baesken 
Date:      2020-04-02 09:07:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/fc9389c1

8241996: on linux set full relro in the linker flags

Reviewed-by: erikj, redestad

! make/autoconf/flags-ldflags.m4

Changeset: 048c5c0d
Author:    Roland Westrelin 
Date:      2020-03-23 10:06:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/048c5c0d

8241041: C2: "assert((Value(phase) == t) || (t != TypeInt::CC_GT && t != TypeInt::CC_EQ)) failed: missing Value() optimization" still happens after fix for 8239335

Reviewed-by: thartmann, neliasso

! src/hotspot/share/opto/subtypenode.cpp
+ test/hotspot/jtreg/compiler/types/TestSubTypeCheckNewObjectNotConstant.java

Changeset: 3d36ef14
Author:    Tobias Hartmann 
Date:      2020-04-06 09:52:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3d36ef14

8241997: Scalar replacement of cloned array is broken after JDK-8238759

Replacement code still expected ArrayCopyNode::Dest to be an AddPNode.

Reviewed-by: roland, neliasso

! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/memnode.cpp

Changeset: 5aed2164
Author:    Thomas Stuefe 
Date:      2020-04-06 10:19:28 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5aed2164

8241726: Re-enable gtest for BitMap::count_one_bits()

Reviewed-by: mdoerr, clanger

+ test/hotspot/gtest/utilities/test_bitMap_popcnt.cpp

Changeset: b73460b3
Author:    Aleksey Shipilev 
Date:      2020-04-06 10:31:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b73460b3

8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp

Changeset: 722a18d3
Author:    Tobias Hartmann 
Date:      2020-04-06 12:09:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/722a18d3

8242090: Remove dead code from c1_LIR

Removed dead code.

Reviewed-by: redestad

! src/hotspot/share/c1/c1_LIR.cpp
! src/hotspot/share/c1/c1_LIR.hpp
! src/hotspot/share/c1/c1_LIRAssembler.cpp

Changeset: e9adf7bb
Author:    Christoph Dreis 
Committer: Claes Redestad 
Date:      2020-04-06 13:44:54 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e9adf7bb

8242186: Reduce allocations in URLStreamHandler.parseURL for some cases

Reviewed-by: redestad, chegar

! src/java.base/share/classes/java/net/URLStreamHandler.java

Changeset: 08b90285
Author:    Christoph Dreis 
Committer: Claes Redestad 
Date:      2020-04-06 13:46:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/08b90285

8242208: Use Method.getParameterCount where applicable

Reviewed-by: redestad, chegar

! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/java.base/share/classes/java/lang/reflect/Executable.java
! src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java

Changeset: ec5ccb8d
Author:    Roman Kennke 
Date:      2020-04-06 13:45:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ec5ccb8d

8242130: Shenandoah: Simplify arraycopy-barrier dispatching

Reviewed-by: shade

! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp

Changeset: 843a8621
Author:    Roman Kennke 
Date:      2020-04-06 16:29:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/843a8621

8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMode.hpp
! src/hotspot/share/gc/shenandoah/shenandoahNormalMode.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPassiveMode.hpp

Changeset: ba26538c
Author:    Daniil Titov 
Date:      2020-04-06 07:39:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ba26538c

8241530: com/sun/jdi tests fail due to network issues on OSX 10.15

Reviewed-by: amenkov, sspitsyn

! test/jdk/ProblemList.txt
! test/jdk/com/sun/jdi/JdwpAttachTest.java
! test/jdk/com/sun/jdi/JdwpListenTest.java
! test/lib/jdk/test/lib/Utils.java

Changeset: c4d01f8c
Author:    Roman Kennke 
Date:      2020-04-06 17:08:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c4d01f8c

8242054: Shenandoah: New incremental-update mode

Reviewed-by: shade

! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahIUMode.cpp
+ src/hotspot/share/gc/shenandoah/shenandoahIUMode.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java
! test/hotspot/jtreg/gc/CriticalNativeArgs.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocHumongousFragment.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocIntArrays.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocObjectArrays.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocObjects.java
! test/hotspot/jtreg/gc/shenandoah/TestGCThreadGroups.java
! test/hotspot/jtreg/gc/shenandoah/TestHeapUncommit.java
! test/hotspot/jtreg/gc/shenandoah/TestLotsOfCycles.java
! test/hotspot/jtreg/gc/shenandoah/TestObjItrWithHeapDump.java
! test/hotspot/jtreg/gc/shenandoah/TestPeriodicGC.java
! test/hotspot/jtreg/gc/shenandoah/TestRefprocSanity.java
! test/hotspot/jtreg/gc/shenandoah/TestRegionSampling.java
! test/hotspot/jtreg/gc/shenandoah/TestRetainObjects.java
! test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java
! test/hotspot/jtreg/gc/shenandoah/TestStringDedup.java
! test/hotspot/jtreg/gc/shenandoah/TestStringDedupStress.java
! test/hotspot/jtreg/gc/shenandoah/TestStringInternCleanup.java
! test/hotspot/jtreg/gc/shenandoah/TestVerifyJCStress.java
! test/hotspot/jtreg/gc/shenandoah/TestWrongArrayMember.java
! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java
! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java
! test/hotspot/jtreg/gc/shenandoah/oom/TestClassLoaderLeak.java
! test/hotspot/jtreg/gc/shenandoah/options/TestExplicitGC.java
! test/hotspot/jtreg/gc/shenandoah/options/TestHeuristicsUnlock.java
! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java
! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java
! test/hotspot/jtreg/gc/stress/CriticalNativeStress.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithShenandoah.java
! test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java
! test/hotspot/jtreg/gc/stress/systemgc/TestSystemGCWithShenandoah.java

Changeset: 185f3721
Author:    Aleksey Shipilev 
Date:      2020-04-06 20:35:19 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/185f3721

8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp

Changeset: 1d687b35
Author:    Aleksey Shipilev 
Date:      2020-04-06 20:35:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1d687b35

8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp

Changeset: 59f28e56
Author:    Aleksey Shipilev 
Date:      2020-04-06 20:35:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/59f28e56

8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp

Changeset: 0d1e636a
Author:    Aleksey Shipilev 
Date:      2020-04-06 20:35:36 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0d1e636a

8242227: Shenandoah: transit regions to cset state when adding to collection set

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp

Changeset: e3aae42d
Author:    Aleksey Shipilev 
Date:      2020-04-06 20:35:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e3aae42d

8242228: Shenandoah: remove unused ShenandoahCollectionSet methods

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp

Changeset: c1016d5d
Author:    Aleksey Shipilev 
Date:      2020-04-06 20:35:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c1016d5d

8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

Changeset: 3aa216ec
Author:    Alexey Semenyuk 
Date:      2020-04-04 07:09:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3aa216ec

8241713: Linux desktop shortcuts with spaces make postinst/prerm fail

Reviewed-by: almatvee, herrick

! src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/DesktopIntegration.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java
! test/jdk/tools/jpackage/linux/ShortcutHintTest.java

Changeset: e18d6617
Author:    Alex Menkov 
Date:      2020-04-06 12:51:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e18d6617

8237572: Combine the two LingeredApp classes

Reviewed-by: cjplummer, lmesnik

- test/jdk/sun/tools/jps/LingeredApp.java
! test/jdk/sun/tools/jps/LingeredAppForJps.java
! test/jdk/sun/tools/jps/TestJps.java
! test/lib/jdk/test/lib/apps/LingeredApp.java

Changeset: b317d0ee
Author:    Lin Zang 
Committer: Henry Jen 
Date:      2020-04-07 03:25:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b317d0ee

8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set

Reviewed-by: alanb, dholmes

! make/launcher/LauncherCommon.gmk
! src/java.base/macosx/native/libjli/java_md_macosx.m
! src/java.base/share/native/libjli/java.c
! src/java.base/unix/native/libjli/java_md_solinux.c
! src/java.base/unix/native/libjli/java_md_solinux.h

Changeset: edc4ffe5
Author:    John Paul Adrian Glaubitz 
Date:      2020-04-07 08:45:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/edc4ffe5

8199138: Add RISC-V support to Zero

Reviewed-by: erikj, stuefe

! make/autoconf/platform.m4
! src/hotspot/os/linux/os_linux.cpp

Changeset: f5a728af
Author:    Ralf Schmelter 
Date:      2020-04-07 09:06:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f5a728af

8238289: Use _byteswap_ functions to implenent Bytes::swap_uX on Windows

Reviewed-by: minqi, dholmes

! src/hotspot/os_cpu/windows_x86/bytes_windows_x86.inline.hpp

Changeset: 76b1119f
Author:    Egor Ushakov 
Date:      2020-04-07 07:24:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/76b1119f

8241958: Slow ClassLoaderReferenceImpl.findType

Optimize ClassLoaderReferenceImpl.findType

Reviewed-by: cjplummer, sspitsyn

! src/jdk.jdi/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java
! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java

Changeset: 5fff119d
Author:    Aleksey Shipilev 
Date:      2020-04-07 13:18:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5fff119d

8242271: Shenandoah: add test to verify GC mode unlock

Reviewed-by: rkennke

+ test/hotspot/jtreg/gc/shenandoah/options/TestModeUnlock.java

Changeset: 951cda8d
Author:    Aleksey Shipilev 
Date:      2020-04-07 13:18:47 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/951cda8d

8242273: Shenandoah: accept either SATB or IU barriers, but not both

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahIUMode.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMode.hpp
! src/hotspot/share/gc/shenandoah/shenandoahNormalMode.cpp
! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java
+ test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierEnable.java

Changeset: 9743ec80
Author:    Denghui Dong 
Date:      2020-04-07 21:18:24 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9743ec80

8240360: NativeLibraryEvent has wrong library name on Linux

Reviewed-by: ysuenaga, clanger

! src/hotspot/os/linux/os_linux.cpp

Changeset: 9ba424ee
Author:    Aleksey Shipilev 
Date:      2020-04-07 14:32:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9ba424ee

8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity()

Reviewed-by: rkennke, stuefe

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 6351f95b
Author:    Lance Andersen 
Date:      2020-04-07 09:03:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6351f95b

8242006: (zipfs)  Improve Zip FS  FileChannel and SeekableByteChannel test coverage

Reviewed-by: clanger

+ test/jdk/jdk/nio/zipfs/testng/test/ChannelTests.java
! test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java

Changeset: 1a40b793
Author:    Mikhailo Seledtsov 
Date:      2020-04-07 07:21:41 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1a40b793

8241695: JFR TestCrossProcessStreaming.java child process exited with SIGQUIT (131)

Waiting for child's main() to start before attaching

Reviewed-by: egahlin

! test/jdk/jdk/jfr/api/consumer/streaming/TestCrossProcessStreaming.java

Changeset: e53ae5ae
Author:    Zhengyu Gu 
Date:      2020-04-07 10:43:15 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e53ae5ae

8242216: ObjectSampler::weak_oops_do() should not trigger barrier

Reviewed-by: rkennke, eosterlund

! src/hotspot/share/jfr/leakprofiler/sampling/objectSample.cpp
! src/hotspot/share/jfr/leakprofiler/sampling/objectSample.hpp
! src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp

Changeset: 378aef32
Author:    Patrick Concannon 
Date:      2020-04-07 16:21:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/378aef32

8240533: Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0

Fix adds checks for port == 0 to the send and connect methods in DatagramSocket and DatagramChannelImpl

Reviewed-by: alanb, chegar, dfuchs, lancea

! src/java.base/share/classes/java/net/DatagramSocket.java
! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java
+ test/jdk/java/net/DatagramSocket/ConnectPortZero.java
+ test/jdk/java/net/DatagramSocket/SendPortZero.java
+ test/jdk/java/nio/channels/DatagramChannel/ConnectPortZero.java
+ test/jdk/java/nio/channels/DatagramChannel/SendPortZero.java

Changeset: cceee2c6
Author:    Chris Plummer 
Date:      2020-04-07 09:36:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cceee2c6

8242168: ClhsdbFindPC.java failed due to "RuntimeException: 'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr"

Reviewed-by: lmesnik, iignatyev

! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbJstackXcompStress.java

Changeset: 8523e37f
Author:    Jonathan Gibbons 
Date:      2020-04-07 09:50:36 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8523e37f

8242056: Merge support for AnnotationType builders/writers into support for other types

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SectionName.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeFieldWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeBuilder.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeFieldBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java
! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java
! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java

Changeset: 7ac64b81
Author:    Jonathan Gibbons 
Date:      2020-04-07 12:41:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7ac64b81

8241895: use new "details-list" CSS class instead of general "block-list" for list of details sections

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ClassWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java
! test/langtools/jdk/javadoc/doclet/testLists/TestLists.java

Changeset: 2b42382e
Author:    Roman Kennke 
Date:      2020-04-07 22:31:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2b42382e

8242301: Shenandoah: Inline LRB runtime call

Reviewed-by: zgu

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp

Changeset: a40ef7e4
Author:    Chris Plummer 
Date:      2020-04-07 13:56:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a40ef7e4

8242235: Disable SA testing on Solaris. Remove JDK-8193639 entries from ProblemList.txt

Reviewed-by: dcubed, amenkov

! test/hotspot/jtreg/ProblemList.txt
! test/jdk/ProblemList.txt
! test/lib/jdk/test/lib/Platform.java

Changeset: 25642dd3
Author:    Liam Miller-Cushon 
Date:      2020-04-06 15:40:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/25642dd3

8035787: SourcePositions are wrong for Strings concatenated with '+' operator

Reviewed-by: jlahoda

+ test/langtools/tools/javac/parser/StringFoldingPosTest.java

Changeset: 9fb91b4e
Author:    Chris Plummer 
Date:      2020-04-07 16:31:46 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9fb91b4e

8242142: convert clhsdb "class" and "classes" commands from javascript to java

Reviewed-by: sspitsyn, amenkov

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
! test/hotspot/jtreg/ProblemList-zgc.txt
+ test/hotspot/jtreg/serviceability/sa/ClhsdbClasses.java

Changeset: ccd2a16c
Author:    Chris Plummer 
Date:      2020-04-07 18:32:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ccd2a16c

8242165: SA sysprops support fails to dump all system properties

Reviewed-by: sspitsyn, ysuenaga

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/ObjectReader.java
! test/hotspot/jtreg/ProblemList-zgc.txt
+ test/hotspot/jtreg/serviceability/sa/LingeredAppSysProps.java
+ test/hotspot/jtreg/serviceability/sa/TestSysProps.java

Changeset: d8539a51
Author:    Weijun Wang 
Date:      2020-04-08 10:13:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d8539a51

8242184: CRL generation error with RSASSA-PSS

Reviewed-by: xuelei

! src/java.base/share/classes/sun/security/x509/AlgorithmId.java
! src/java.base/share/classes/sun/security/x509/X509CRLImpl.java
! src/java.base/share/classes/sun/security/x509/X509CertImpl.java
+ test/jdk/sun/security/tools/keytool/GenerateAll.java

Changeset: 67fd181e
Author:    Nick Gasson 
Date:      2020-04-08 14:03:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/67fd181e

8242029: AArch64: skip G1 array copy pre-barrier if marking not active

Reviewed-by: aph

! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp

Changeset: 6b7a466f
Author:    Jamil Nimeh 
Date:      2020-04-08 00:03:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6b7a466f

8242294: JSSE Client does not throw SSLException when an alert occurs during handshaking

Reviewed-by: xuelei

! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
+ test/jdk/javax/net/ssl/SSLSocket/ClientExcOnAlert.java

Changeset: 6405d750
Author:    Roland Westrelin 
Date:      2020-04-02 15:03:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6405d750

8241900: Loop unswitching may cause dependence on null check to be lost

Reviewed-by: thartmann, kvn

! src/hotspot/share/opto/loopUnswitch.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestLoopUnswitchingLostCastDependency.java

Changeset: 05c26d8b
Author:    Erik Gahlin 
Date:      2020-04-08 10:43:16 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/05c26d8b

8241828: JFR: Some streaming tests require a larger heap size with ZGC

Reviewed-by: stefank

! test/jdk/jdk/jfr/api/consumer/streaming/TestChunkGap.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestFilledChunks.java

Changeset: 343f7603
Author:    Roman Kennke 
Date:      2020-04-08 11:26:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/343f7603

8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry

Reviewed-by: zgu, shade

! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp

Changeset: 59684e10
Author:    David M Lloyd 
Committer: Alan Bateman 
Date:      2020-04-08 10:31:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/59684e10

8242356: (se) epoll Selector should use epoll_create1 instead of epoll_create

Reviewed-by: alanb, stuefe

! src/java.base/linux/native/libnio/ch/EPoll.c

Changeset: 4c4271f2
Author:    Pavel Rappo 
Date:      2020-04-08 11:16:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4c4271f2

8242230: Whitespace typos, relaxed javadoc, formatting

Reviewed-by: darcy, igerasim

! src/java.base/share/classes/java/io/DataOutput.java
! src/java.base/share/classes/java/lang/Character.java
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/FdLibm.java
! src/java.base/share/classes/java/lang/Runtime.java
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/annotation/ElementType.java
! src/java.base/share/classes/java/lang/annotation/Target.java
! src/java.base/share/classes/java/lang/reflect/Parameter.java
! src/java.base/share/classes/java/math/BigDecimal.java
! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/net/MulticastSocket.java
! src/java.base/share/classes/java/text/DecimalFormatSymbols.java
! src/java.base/share/classes/java/util/Calendar.java
! src/java.base/share/classes/java/util/Formatter.java
! src/java.base/share/classes/jdk/internal/reflect/Reflection.java
! src/java.compiler/share/classes/javax/lang/model/util/Elements.java
! src/java.logging/share/classes/java/util/logging/Formatter.java

Changeset: 7b870e70
Author:    Aleksey Shipilev 
Date:      2020-04-08 13:44:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7b870e70

8242353: Shenandoah: micro-optimize region liveness handling

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 64aee56a
Author:    Aleksey Shipilev 
Date:      2020-04-08 13:44:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/64aee56a

8242365: Shenandoah: use uint16_t instead of jushort for liveness cache

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp

Changeset: 9292b400
Author:    Zhengyu Gu 
Date:      2020-04-08 08:13:22 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9292b400

8241984: Shenandoah: enhance GCTimer and JFR support

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp

Changeset: c2efd224
Author:    Adam Sotona 
Date:      2020-04-08 15:00:39 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c2efd224

8239544: Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS

JavaCompiler patch fixing its response to should-stop.ifNoError= option for PARSE, ENTER and PROCESS compiler states + new T8239544.java matrix regression test

Reviewed-by: jlaskey, jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/langtools/tools/javac/main/T8239544.java

Changeset: 50ed5307
Author:    Roger Riggs 
Date:      2020-04-08 09:22:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/50ed5307

8225319: Remove rmic from the set of supported tools

Reviewed-by: erikj, alanb, lancea, jjg, amlu

! make/CompileJavaModules.gmk
! make/common/Modules.gmk
- make/launcher/Launcher-jdk.rmic.gmk
! make/nashorn/element-list
! src/java.rmi/share/classes/java/rmi/server/Operation.java
! src/java.rmi/share/classes/java/rmi/server/Skeleton.java
! src/java.rmi/share/classes/java/rmi/server/SkeletonMismatchException.java
! src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java
! src/java.rmi/share/classes/java/rmi/server/package-info.java
- src/jdk.rmic/share/classes/module-info.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/BatchEnvironment.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/Constants.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/Generator.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/IndentingWriter.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/Main.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/Names.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/RMIConstants.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/RMIGenerator.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/RemoteClass.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/Util.java
- src/jdk.rmic/share/classes/sun/rmi/rmic/resources/rmic.properties
- src/jdk.rmic/share/classes/sun/rmi/rmic/resources/rmic_ja.properties
- src/jdk.rmic/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties
- src/jdk.rmic/share/classes/sun/tools/asm/ArrayData.java
- src/jdk.rmic/share/classes/sun/tools/asm/Assembler.java
- src/jdk.rmic/share/classes/sun/tools/asm/CatchData.java
- src/jdk.rmic/share/classes/sun/tools/asm/ClassConstantData.java
- src/jdk.rmic/share/classes/sun/tools/asm/ConstantPool.java
- src/jdk.rmic/share/classes/sun/tools/asm/ConstantPoolData.java
- src/jdk.rmic/share/classes/sun/tools/asm/Cover.java
- src/jdk.rmic/share/classes/sun/tools/asm/FieldConstantData.java
- src/jdk.rmic/share/classes/sun/tools/asm/Instruction.java
- src/jdk.rmic/share/classes/sun/tools/asm/Label.java
- src/jdk.rmic/share/classes/sun/tools/asm/LocalVariable.java
- src/jdk.rmic/share/classes/sun/tools/asm/LocalVariableTable.java
- src/jdk.rmic/share/classes/sun/tools/asm/NameAndTypeConstantData.java
- src/jdk.rmic/share/classes/sun/tools/asm/NameAndTypeData.java
- src/jdk.rmic/share/classes/sun/tools/asm/NumberConstantData.java
- src/jdk.rmic/share/classes/sun/tools/asm/StringConstantData.java
- src/jdk.rmic/share/classes/sun/tools/asm/StringExpressionConstantData.java
- src/jdk.rmic/share/classes/sun/tools/asm/SwitchData.java
- src/jdk.rmic/share/classes/sun/tools/asm/TryData.java
- src/jdk.rmic/share/classes/sun/tools/java/AmbiguousClass.java
- src/jdk.rmic/share/classes/sun/tools/java/AmbiguousMember.java
- src/jdk.rmic/share/classes/sun/tools/java/ArrayType.java
- src/jdk.rmic/share/classes/sun/tools/java/BinaryAttribute.java
- src/jdk.rmic/share/classes/sun/tools/java/BinaryClass.java
- src/jdk.rmic/share/classes/sun/tools/java/BinaryCode.java
- src/jdk.rmic/share/classes/sun/tools/java/BinaryConstantPool.java
- src/jdk.rmic/share/classes/sun/tools/java/BinaryExceptionHandler.java
- src/jdk.rmic/share/classes/sun/tools/java/BinaryMember.java
- src/jdk.rmic/share/classes/sun/tools/java/ClassDeclaration.java
- src/jdk.rmic/share/classes/sun/tools/java/ClassDefinition.java
- src/jdk.rmic/share/classes/sun/tools/java/ClassFile.java
- src/jdk.rmic/share/classes/sun/tools/java/ClassNotFound.java
- src/jdk.rmic/share/classes/sun/tools/java/ClassPath.java
- src/jdk.rmic/share/classes/sun/tools/java/ClassType.java
- src/jdk.rmic/share/classes/sun/tools/java/CompilerError.java
- src/jdk.rmic/share/classes/sun/tools/java/Constants.java
- src/jdk.rmic/share/classes/sun/tools/java/Environment.java
- src/jdk.rmic/share/classes/sun/tools/java/FileClassFile.java
- src/jdk.rmic/share/classes/sun/tools/java/Identifier.java
- src/jdk.rmic/share/classes/sun/tools/java/IdentifierToken.java
- src/jdk.rmic/share/classes/sun/tools/java/Imports.java
- src/jdk.rmic/share/classes/sun/tools/java/MemberDefinition.java
- src/jdk.rmic/share/classes/sun/tools/java/MethodSet.java
- src/jdk.rmic/share/classes/sun/tools/java/MethodType.java
- src/jdk.rmic/share/classes/sun/tools/java/Package.java
- src/jdk.rmic/share/classes/sun/tools/java/Parser.java
- src/jdk.rmic/share/classes/sun/tools/java/ParserActions.java
- src/jdk.rmic/share/classes/sun/tools/java/PathClassFile.java
- src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java
- src/jdk.rmic/share/classes/sun/tools/java/Scanner.java
- src/jdk.rmic/share/classes/sun/tools/java/ScannerInputReader.java
- src/jdk.rmic/share/classes/sun/tools/java/SyntaxError.java
- src/jdk.rmic/share/classes/sun/tools/java/Type.java
- src/jdk.rmic/share/classes/sun/tools/java/ZipClassFile.java
- src/jdk.rmic/share/classes/sun/tools/javac/BatchEnvironment.java
- src/jdk.rmic/share/classes/sun/tools/javac/BatchParser.java
- src/jdk.rmic/share/classes/sun/tools/javac/CompilerMember.java
- src/jdk.rmic/share/classes/sun/tools/javac/ErrorConsumer.java
- src/jdk.rmic/share/classes/sun/tools/javac/ErrorMessage.java
- src/jdk.rmic/share/classes/sun/tools/javac/Main.java
- src/jdk.rmic/share/classes/sun/tools/javac/SourceClass.java
- src/jdk.rmic/share/classes/sun/tools/javac/SourceMember.java
- src/jdk.rmic/share/classes/sun/tools/javac/resources/javac.properties
- src/jdk.rmic/share/classes/sun/tools/javac/resources/javac_ja.properties
- src/jdk.rmic/share/classes/sun/tools/javac/resources/javac_zh_CN.properties
- src/jdk.rmic/share/classes/sun/tools/tree/AddExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AndExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ArrayAccessExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ArrayExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignAddExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignBitAndExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignBitOrExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignBitXorExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignDivideExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignMultiplyExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignOpExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignRemainderExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignShiftLeftExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignShiftRightExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignSubtractExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/AssignUnsignedShiftRightExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BinaryArithmeticExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BinaryAssignExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BinaryBitExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BinaryCompareExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BinaryEqualityExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BinaryExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BinaryLogicalExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BinaryShiftExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BitAndExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BitNotExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BitOrExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BitXorExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BooleanExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/BreakStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/ByteExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/CaseStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/CastExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/CatchStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/CharExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/CheckContext.java
- src/jdk.rmic/share/classes/sun/tools/tree/CodeContext.java
- src/jdk.rmic/share/classes/sun/tools/tree/CommaExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/CompoundStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/ConditionVars.java
- src/jdk.rmic/share/classes/sun/tools/tree/ConditionalExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ConstantExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/Context.java
- src/jdk.rmic/share/classes/sun/tools/tree/ContinueStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/ConvertExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/DeclarationStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/DivRemExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/DivideExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/DoStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/DoubleExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/EqualExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ExprExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/Expression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ExpressionStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/FieldExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/FieldUpdater.java
- src/jdk.rmic/share/classes/sun/tools/tree/FinallyStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/FloatExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ForStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/GreaterExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/GreaterOrEqualExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/IdentifierExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/IfStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/IncDecExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/InlineMethodExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/InlineNewInstanceExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/InlineReturnStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/InstanceOfExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/IntExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/IntegerExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/LengthExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/LessExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/LessOrEqualExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/LocalMember.java
- src/jdk.rmic/share/classes/sun/tools/tree/LongExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/MethodExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/MultiplyExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/NaryExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/NegativeExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/NewArrayExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/NewInstanceExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/Node.java
- src/jdk.rmic/share/classes/sun/tools/tree/NotEqualExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/NotExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/NullExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/OrExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/PositiveExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/PostDecExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/PostIncExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/PreDecExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/PreIncExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/RemainderExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ReturnStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/ShiftLeftExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ShiftRightExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ShortExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/Statement.java
- src/jdk.rmic/share/classes/sun/tools/tree/StringExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/SubtractExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/SuperExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/SwitchStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/SynchronizedStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/ThisExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/ThrowStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/TryStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/TypeExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/UnaryExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/UnsignedShiftRightExpression.java
- src/jdk.rmic/share/classes/sun/tools/tree/UplevelReference.java
- src/jdk.rmic/share/classes/sun/tools/tree/VarDeclarationStatement.java
- src/jdk.rmic/share/classes/sun/tools/tree/Vset.java
- src/jdk.rmic/share/classes/sun/tools/tree/WhileStatement.java
- src/jdk.rmic/share/classes/sun/tools/util/CommandLine.java
- src/jdk.rmic/share/classes/sun/tools/util/ModifierFilter.java
- src/jdk.rmic/share/man/rmic.1
! test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile
! test/jdk/java/rmi/testlibrary/README.jcov
- test/jdk/sun/rmi/rmic/RMIGenerator/RmicDefault.java
- test/jdk/sun/rmi/rmic/RMIGenerator/packagedir/AppletServer.java
- test/jdk/sun/rmi/rmic/RMIGenerator/packagedir/RmicMeImpl.java
- test/jdk/sun/rmi/rmic/RMIGenerator/packagedir/RmicMeInterface.java
- test/jdk/sun/rmi/rmic/classFileVersion/G1.java
- test/jdk/sun/rmi/rmic/classFileVersion/G1Impl.java
- test/jdk/sun/rmi/rmic/classFileVersion/run.sh
- test/jdk/sun/rmi/rmic/classpath/RMICClassPathTest.java
- test/jdk/sun/rmi/rmic/covariantReturns/G2.java
- test/jdk/sun/rmi/rmic/covariantReturns/G2Impl.java
- test/jdk/sun/rmi/rmic/covariantReturns/G5.java
- test/jdk/sun/rmi/rmic/covariantReturns/G5Impl.java
- test/jdk/sun/rmi/rmic/covariantReturns/run.sh
- test/jdk/sun/rmi/rmic/defaultStubVersion/G1.java
- test/jdk/sun/rmi/rmic/defaultStubVersion/G1Impl.java
- test/jdk/sun/rmi/rmic/defaultStubVersion/run.sh
- test/jdk/sun/rmi/rmic/extraCompilation/run.sh
- test/jdk/sun/rmi/rmic/manifestClassPath/Util.sh
- test/jdk/sun/rmi/rmic/manifestClassPath/run.sh
- test/jdk/sun/rmi/rmic/minimizeWrapperInstances/P.java
- test/jdk/sun/rmi/rmic/minimizeWrapperInstances/PImpl.java
- test/jdk/sun/rmi/rmic/minimizeWrapperInstances/Test.java
- test/jdk/sun/rmi/rmic/minimizeWrapperInstances/run.sh
- test/jdk/sun/rmi/rmic/oldjavacRemoved/Foo.java
- test/jdk/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh
- test/jdk/sun/tools/java/CFCTest.java
! test/jdk/tools/launcher/HelpFlagsTest.java
! test/jdk/tools/launcher/VersionCheck.java

Changeset: 1cca0e48
Author:    Andy Herrick 
Date:      2020-04-08 09:44:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1cca0e48

8237490: [macos] Add support notarizing jpackage app-image and dmg

Reviewed-by: asemenyuk, almatvee

! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java
! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppStoreBundler.java
- src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacAppStore.entitlements
- src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacAppStore_Inherit.entitlements
! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties
! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources_ja.properties
! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources_zh_CN.properties
+ src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/entitlements.plist
! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/Arguments.java
! src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/ValidOptions.java
! test/jdk/tools/jpackage/macosx/base/SigningBase.java

Changeset: 1c651455
Author:    Martin Balao 
Date:      2020-04-02 18:18:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1c651455

8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/validator/PKIXValidator.java
! src/java.base/share/conf/security/java.security

Changeset: 29b0912b
Author:    Zhengyu Gu 
Date:      2020-04-08 11:21:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/29b0912b

8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods

Reviewed-by: shade, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp

Changeset: 6c1f8e1d
Author:    Zhengyu Gu 
Date:      2020-04-08 11:33:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6c1f8e1d

8242370: Enable JFR TestGCPhaseConcurrent test for Shenandoah

Reviewed-by: stefank

! test/jdk/jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java

Changeset: 76a8557d
Author:    Erik ?sterlund 
Date:      2020-04-08 15:34:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/76a8557d

8241438: Move IntelJccErratum mitigation code to platform-specific code

Reviewed-by: vlivanov, kvn

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/sparc/sparc.ad
! src/hotspot/cpu/x86/c2_intelJccErratum_x86.cpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/output.hpp

Changeset: a5b81d97
Author:    Erik ?sterlund 
Date:      2020-04-08 15:34:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a5b81d97

8240693: Sweeper should not examine dying metadata in is_unloading() nmethod during static call stub cleaning

Reviewed-by: kvn, coleenp, pliden

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/compiledMethod.cpp

Changeset: 0ffbbc82
Author:    Roger Riggs 
Date:      2020-04-08 11:43:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0ffbbc82

8242382: test/jdk/TEST.groups cleanup of sun/tools/java

Reviewed-by: lancea, dfuchs

! test/jdk/TEST.groups

Changeset: dd4e04d6
Author:    Calvin Cheung 
Date:      2020-04-08 08:56:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/dd4e04d6

8242134: Consolidate the get_package_entry() in SystemDictionaryShared and ClassLoader

Keep the version in ClassLoader.

Reviewed-by: hseigel, redestad, lfoltan

! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoader.hpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp

Changeset: 52ea4802
Author:    Stefan Johansson 
Date:      2020-04-08 18:38:31 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/52ea4802

8241141: Restructure humongous object allocation in G1

Reviewed-by: tschatzl, kbarrett

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/heapRegionManager.cpp
! src/hotspot/share/gc/g1/heapRegionManager.hpp
! src/hotspot/share/gc/g1/heapRegionManager.inline.hpp
! src/hotspot/share/gc/g1/heapRegionSet.hpp
! src/hotspot/share/gc/g1/heterogeneousHeapRegionManager.cpp
! src/hotspot/share/gc/g1/heterogeneousHeapRegionManager.hpp

Changeset: 51a5e9ca
Author:    Naoto Sato 
Date:      2020-04-08 09:50:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/51a5e9ca

8242010: Upgrade IANA Language Subtag Registry to Version 2020-04-01

Reviewed-by: rriggs, joehw

! make/data/lsrdata/language-subtag-registry.txt
! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java
! test/jdk/java/util/Locale/Bug7069824.java
! test/jdk/java/util/Locale/Bug8040211.java
! test/jdk/java/util/Locale/LSRDataTest.java

Changeset: 89a33e69
Author:    Patricio Chilano Mateo 
Date:      2020-04-08 18:32:21 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/89a33e69

8240918: [REDO] Allow direct handshakes without VMThread intervention

REDO of 8230594

Reviewed-by: dholmes, rehn, mdoerr, coleenp, dcubed

! src/hotspot/share/runtime/biasedLocking.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/handshake.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/safepointMechanism.inline.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/threadSMR.hpp
+ test/hotspot/jtreg/runtime/handshake/HandshakeDirectTest.java

Changeset: 62060fc2
Author:    Naoto Sato 
Date:      2020-04-08 11:40:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/62060fc2

8242337: javadoc typo in NumberFormat::setMinimumFractionDigits

Reviewed-by: lancea, martin

! src/java.base/share/classes/java/text/NumberFormat.java

Changeset: 64957a17
Author:    Chris Plummer 
Date:      2020-04-08 12:03:02 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/64957a17

8242265: serviceability/sa/ClhsdbScanOops.java fails due to bad @requires expression

Reviewed-by: sspitsyn, lmesnik

! test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java

Changeset: cdb379e5
Author:    Hannes Walln?fer 
Date:      2020-04-08 21:28:14 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cdb379e5

8237383: Members inherited from non-public types are not included in index

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchIndexItems.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstantsSummaryBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ClassTree.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ClassUseMapper.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Comparators.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Group.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexBuilder.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexItem.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/TypeElementCatalog.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/pkg2/UndocumentedGenericParent.java

Changeset: ac8d4208
Author:    Hannes Walln?fer 
Date:      2020-04-08 22:04:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ac8d4208

8240169: javadoc fails to link to non-modular api docs

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java
! test/langtools/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithModule.java

Changeset: 3a6249d0
Author:    Leonid Mesnik 
Date:      2020-04-08 13:14:19 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3a6249d0

8242295: Change ThreadMBean in vmTestbase/nsk/monitoring to ThreadMXBean

Reviewed-by: iignatyev

- test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMBean/findMonitorDeadlockedThreads/find001.java
- test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMBean/isCurrentThreadCpuTimeSupported/curthcputime001.java
- test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMBean/isThreadContentionMonitoringSupported/thcontmonitor001.java
- test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMBean/isThreadCpuTimeSupported/thcputime001.java
- test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMBean/resetPeakThreadCount/reset001.java
+ test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find005/TestDescription.java
+ test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime005/TestDescription.java
+ test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadContentionMonitoringSupported/thcontmonitor001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadContentionMonitoringSupported/thcontmonitor001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadContentionMonitoringSupported/thcontmonitor002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadContentionMonitoringSupported/thcontmonitor003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadContentionMonitoringSupported/thcontmonitor004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadContentionMonitoringSupported/thcontmonitor005/TestDescription.java
+ test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadCpuTimeSupported/thcputime001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadCpuTimeSupported/thcputime001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadCpuTimeSupported/thcputime002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadCpuTimeSupported/thcputime003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadCpuTimeSupported/thcputime004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isThreadCpuTimeSupported/thcputime005/TestDescription.java
+ test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/resetPeakThreadCount/reset001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/resetPeakThreadCount/reset001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/resetPeakThreadCount/reset002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/resetPeakThreadCount/reset003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/resetPeakThreadCount/reset004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/resetPeakThreadCount/reset005/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace010.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace010/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace011/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace012/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace013/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace014/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace015/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace016/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace017/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace018/TestDescription.java

Changeset: 82dfec76
Author:    Chris Plummer 
Date:      2020-04-08 14:11:06 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/82dfec76

8242384: sa/TestSysProps.java failed due to "RuntimeException: Could not find property in jinfo output: [0.058s][info][cds] Archive was created with UseCompressedOops"

Reviewed-by: dcubed

! test/hotspot/jtreg/serviceability/sa/TestSysProps.java


From dsimms at openjdk.java.net  Thu Apr 23 08:38:34 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 23 Apr 2020 08:38:34 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <78LI7kJz1Vpjbf4z8BozksdZegWQktHVIvTcYpIBMAc=.5317c923-a55b-4524-be1c-9e8913d3e37a@github.com>

Merged jdk-15+19

-------------

Commit messages:
 - Merge tag 'jdk-15+19' into lworld_merge_jdk_15_19
 - 8242366: Fix JavaDoc warnings
 - 8242842: Avoid reallocating name when checking for trailing slash in ZipFile.getEntryPos
 - 8242629: Remove references to deprecated java.util.Observer and Observable
 - 8242597: Remove GenericTaskQueue<>::push_slow
 - 8241618: Fix trivial unchecked warnings for jdk.hotspot.agent
 - 8242485: Null _file checking in fileStream::flush()
 - 8242643: Shenandoah: split concurrent weak and strong root processing
 - 8242602: Shenandoah: allow earlier recycle of trashed regions during concurrent root processing
 - Merge
 - ...omitting 100 further commits.

The webrevs contain only the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/valhalla/26/webrev.00.0
 - jdk: https://webrevs.openjdk.java.net/valhalla/26/webrev.00.1

Changes: https://git.openjdk.java.net/valhalla/pull/26/files
  Stats: 98590 lines in 895 files changed: 5101 ins; 91295 del; 2194 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/26.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/26/head:pull/26

PR: https://git.openjdk.java.net/valhalla/pull/26

From dsimms at openjdk.java.net  Thu Apr 23 09:08:40 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 23 Apr 2020 09:08:40 GMT
Subject: [Integrated] [lworld] RFR: Merge jdk
In-Reply-To: <78LI7kJz1Vpjbf4z8BozksdZegWQktHVIvTcYpIBMAc=.5317c923-a55b-4524-be1c-9e8913d3e37a@github.com>
References: <78LI7kJz1Vpjbf4z8BozksdZegWQktHVIvTcYpIBMAc=.5317c923-a55b-4524-be1c-9e8913d3e37a@github.com>
Message-ID: <94f63fb6-ffab-4d9f-ab7d-dbd3fc65cfaf@openjdk.org>

Changeset: d4828d74
Author:    David Simms 
Date:      2020-04-23 09:01:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d4828d74

Merge jdk

! .hgtags
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
! src/java.base/share/classes/java/io/ObjectStreamClass.java
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java
! src/java.base/share/classes/java/lang/reflect/Constructor.java
! src/java.base/share/classes/java/lang/reflect/Field.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.base/share/classes/java/lang/reflect/Modifier.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! test/hotspot/jtreg/ProblemList.txt
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! .hgtags
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
! src/java.base/share/classes/java/io/ObjectStreamClass.java
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java
! src/java.base/share/classes/java/lang/reflect/Constructor.java
! src/java.base/share/classes/java/lang/reflect/Field.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.base/share/classes/java/lang/reflect/Modifier.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! test/hotspot/jtreg/ProblemList.txt
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java

From prappo at openjdk.java.net  Thu Apr 23 09:08:40 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 23 Apr 2020 09:08:40 GMT
Subject: git: openjdk/valhalla: lworld: 109 new changesets
Message-ID: <2f6ff78f-d769-4d46-8438-c589adfac1b2@openjdk.org>

Changeset: 54564388
Author:    Yasumasa Suenaga 
Date:      2020-03-23 15:43:55 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/54564388

8241087: Build failure with VS 2019 (16.5.0) due to C2039 and C2873

Reviewed-by: serb

! src/java.desktop/windows/native/libawt/windows/awt_DCHolder.cpp
! src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp
! src/java.desktop/windows/native/libawt/windows/awt_ole.h

Changeset: 40e667c1
Author:    Prasanta Sadhukhan 
Date:      2020-03-26 10:18:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/40e667c1

8239312: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

Reviewed-by: serb

! test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

Changeset: 3399842d
Author:    Sergey Bylokhov 
Date:      2020-03-25 16:48:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3399842d

8240690: Race condition between EDT and BasicDirectoryModel.FilesLoader.run0()

Reviewed-by: psadhukhan

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java
! src/java.desktop/share/classes/javax/swing/JFileChooser.java
! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java
! src/java.desktop/share/classes/sun/swing/FilePane.java
+ test/jdk/javax/swing/JFileChooser/4966171/bug4966171.java

Changeset: cf22b4e7
Author:    Sergey Bylokhov 
Date:      2020-03-25 16:55:00 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cf22b4e7

8238719: [macOS] Delete the property which use deprecated prefix "com.apple.macos."

Reviewed-by: psadhukhan, jdv, prr

! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBarUI.java

Changeset: 1ef1131a
Author:    Pankaj Bansal 
Date:      2020-03-30 12:06:06 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1ef1131a

8241791: [TESTBUG] Test failing with exception "java.lang.UnsupportedOperationException"

Reviewed-by: serb

! test/jdk/java/awt/image/multiresolution/MultiResolutionTrayIconTest/MultiResolutionTrayIconTest.java

Changeset: 978120f4
Author:    Sergey Bylokhov 
Date:      2020-03-31 19:19:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/978120f4

8241808: [TESTBUG] The JDK-8039467 bug appeared on macOS

Reviewed-by: kizune, pbansal

! test/jdk/java/awt/Choice/UnfocusableToplevel/UnfocusableToplevel.java

Changeset: 3c937001
Author:    Sergey Bylokhov 
Date:      2020-03-31 19:56:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3c937001

8241797: Add some tests to the problem list

Reviewed-by: jdv, prr, pbansal

! test/jdk/ProblemList.txt

Changeset: 38716935
Author:    Phil Race 
Date:      2020-04-03 15:00:41 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/38716935

8240342: Custom composite is ignored when printing an opaque image to a page

Reviewed-by: serb, psadhukhan

! src/java.desktop/share/classes/sun/print/PSPathGraphics.java
! src/java.desktop/share/classes/sun/print/PathGraphics.java
! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java
+ test/jdk/java/awt/print/PrinterJob/CustomCompositePrintTest.java

Changeset: 5a5e4bbf
Author:    Phil Race 
Date:      2020-04-06 12:01:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5a5e4bbf

8220150: macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs

Reviewed-by: serb, kcr

! src/java.desktop/share/classes/sun/font/FontStrikeDesc.java
! src/java.desktop/share/classes/sun/font/FontUtilities.java
! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java
! src/java.desktop/share/classes/sun/java2d/SurfaceData.java
! test/jdk/ProblemList.txt
! test/jdk/sun/java2d/loops/RenderToCustomBufferTest.java

Changeset: ead83e6b
Author:    Sergey Bylokhov 
Date:      2020-02-06 16:15:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ead83e6b

8239124: Minimize the usage of AwtGraphicsConfigDataPtr in native

Reviewed-by: pbansal

! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
! src/java.desktop/unix/native/common/awt/X11Color.c
! src/java.desktop/unix/native/common/awt/awt_p.h
! src/java.desktop/unix/native/libawt_xawt/xawt/XWindow.c

Changeset: 8eb7c3ef
Author:    Sergey Bylokhov 
Date:      2020-04-06 20:27:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8eb7c3ef

8196019: java/awt/Window/Grab/GrabTest.java fails on Windows

Reviewed-by: prr, jdv

! test/jdk/ProblemList.txt
! test/jdk/java/awt/Window/Grab/GrabTest.java

Changeset: 84fc4850
Author:    Sergey Bylokhov 
Date:      2020-04-07 21:56:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/84fc4850

7105119: [TEST_BUG] [macosx] In test UIDefaults.toString() must be called with the invokeLater()

Reviewed-by: prr, psadhukhan

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/MultiUIDefaults/4300666/bug4300666.java

Changeset: a62b24f5
Author:    Sergey Bylokhov 
Date:      2020-04-08 02:03:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a62b24f5

8241829: Cleanup the code for PrinterJob on windows

Reviewed-by: prr, aivanov

! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java
! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
+ test/jdk/java/awt/print/PrintServicesSecurityManager.java

Changeset: f67e6088
Author:    Sergey Bylokhov 
Date:      2020-04-08 02:36:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f67e6088

8238567: SoftMainMixer.processAudioBuffers(): Wrong handling of stoppedMixers

Reviewed-by: prr

! src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java

Changeset: a6678d2e
Author:    Prasanta Sadhukhan 
Date:      2020-04-08 16:29:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a6678d2e

8240877: NPE at javax.swing.text.html.FormView.appendBuffer with null option values

Reviewed-by: serb

! src/java.desktop/share/classes/javax/swing/text/html/FormView.java
+ test/jdk/javax/swing/text/html/TestFormViewNPE.java

Changeset: 10ca4873
Author:    Sergey Bylokhov 
Date:      2020-04-08 02:53:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/10ca4873

8239819: XToolkit: Misread of screen information memory

Reviewed-by: prr

! src/java.desktop/unix/classes/sun/awt/X11/XIconWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java
! src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c

Changeset: 64365fb9
Author:    Phil Race 
Date:      2020-04-08 13:19:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/64365fb9

8223090: Clean up obsolete logic & reference to Amble fonts

Reviewed-by: serb, psadhukhan

! src/java.desktop/share/classes/sun/font/FileFontStrike.java
! src/java.desktop/share/classes/sun/font/FontScaler.java
! src/java.desktop/share/classes/sun/font/FreetypeFontScaler.java
! src/java.desktop/share/classes/sun/font/NullFontScaler.java

Changeset: 3850f28e
Author:    Phil Race 
Date:      2020-04-08 16:55:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3850f28e

8242325: Remove VIS version of medialib

Reviewed-by: serb, bpb, erikj

! make/lib/Awt2dLibraries.gmk
! src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.c
! src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.h
- src/java.desktop/share/native/libawt/java2d/loops/MapAccelFunc.c
- src/java.desktop/unix/native/common/awt/medialib/mlib_v_ImageCopy_f.c
- src/java.desktop/unix/native/common/awt/medialib/mlib_v_ImageCopy_f.h
- src/java.desktop/unix/native/common/awt/medialib/vis_proto.h
! src/java.desktop/unix/native/libawt/awt/awt_Mlib.c
- src/java.desktop/unix/native/libawt/java2d/loops/java2d_Mlib.c
- src/java.desktop/unix/native/libawt/java2d/loops/java2d_Mlib.h
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_ImageCopy.h
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_ImageLogic_proto.h
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_ImageZoom.h
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_ImageZoom_NN.c
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_v_ImageClear.c
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_v_ImageClear_f.c
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_v_ImageClear_f.h
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_v_ImageConstLogic.h
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_v_ImageConstXor.c
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_v_ImageLogic.h
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_v_ImageLogic_proto.h
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_v_ImageXor.c
- src/java.desktop/unix/native/libawt/java2d/loops/mlib_v_ImageZoom_NN_f.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_AlphaMacros.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_AlphaMacros.h
- src/java.desktop/unix/native/libawt/java2d/loops/vis_AlphaMaskBlit.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_AlphaMaskFill.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_ByteGray.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_ByteGray_FromRgb.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_ByteGray_Mask.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_ByteIndexed.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_DrawLine.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_FourByteAbgr.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_FourByteAbgrPre.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_FuncArray.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_GlyphList.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_GlyphListXor.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_IntArgb.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_IntArgbBm.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_IntArgbPre.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_IntArgbPre_Mask.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_IntBgr.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_IntRgb.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_IntRgbx.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_Interp.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_SrcMaskFill.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_SrcOverMaskBlit.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_SrcOverMaskFill.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_ThreeByteBgr.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_UshortGray.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_UshortGray_FromRgb.c
- src/java.desktop/unix/native/libawt/java2d/loops/vis_XorBlit.c
- src/java.desktop/unix/native/libmlib_image/mlib_ImageConvCopyEdge_Fp.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BC.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BC_S16.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BC_U16.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BL.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BL_S16.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BL_S16.h
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BL_U16.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_NN.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract.h
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract_1.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract_43.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelInsert.h
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelInsert_1.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConv.h
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConvClearEdge.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConvCopyEdge.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConvMxN_8.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConvMxN_8ext.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConvVersion.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConv_8nw.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageFilters.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageFilters.h
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUp.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpFunc.h
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpS16S16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpS16S32Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpS16U16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpS16U8Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpS32S16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpS32S32Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpS32U16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpS32U8Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIS16S16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIS16S32Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIS16U16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIS16U8Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIS32S16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIS32S32Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIS32U16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIS32U8Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIU16S16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIU16S32Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIU16U16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIU16U8Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIU8S16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIU8S32Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIU8U16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpSIU8U8Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpU16S16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpU16S32Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpU16U16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpU16U8Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpU8S16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpU8S32Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpU8U16Func.c
- src/java.desktop/unix/native/libmlib_image/mlib_v_ImageLookUpU8U8Func.c
- src/java.desktop/unix/native/libmlib_image/vis_32.il
- src/java.desktop/unix/native/libmlib_image/vis_64.il

Changeset: 3487361a
Author:    Jie Fu 
Date:      2020-04-09 09:20:18 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3487361a

8242379: [TESTBUG] compiler/loopopts/TestLoopUnswitchingLostCastDependency.java fails with release VMs

Reviewed-by: roland, kvn

! test/hotspot/jtreg/compiler/loopopts/TestLoopUnswitchingLostCastDependency.java

Changeset: 16f8c294
Author:    Jesper Wilhelmsson 
Date:      2020-04-09 05:28:47 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/16f8c294

Added tag jdk-15+18 for changeset 44aef192b488

! .hgtags

Changeset: cd8be04b
Author:    Joe Wang 
Date:      2020-04-09 03:51:32 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cd8be04b

8237187: Obsolete references to java.sun.com

Reviewed-by: lancea, naoto

! src/java.base/share/classes/jdk/internal/util/xml/impl/ParserSAX.java

Changeset: d1091364
Author:    Chris Plummer 
Date:      2020-04-08 21:01:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d1091364

8240990: convert clhsdb "dumpclass" command from javascript to java

Reviewed-by: sspitsyn, ysuenaga

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
+ test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java

Changeset: 0eb72d4e
Author:    Igor Ignatyev 
Date:      2020-04-08 22:54:35 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0eb72d4e

8241707: introduce randomness k/w to hotspot test suite

Reviewed-by: kvn, mseledtsov

! test/hotspot/jtreg/TEST.ROOT
! test/hotspot/jtreg/testlibrary_tests/RandomGeneratorTest.java

Changeset: 7c351405
Author:    Igor Ignatyev 
Date:      2020-04-08 22:58:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7c351405

8242310: use reproducible random in hotspot compiler tests

Reviewed-by: kvn, thartmann

! test/hotspot/jtreg/compiler/c2/PolynomialRoot.java
! test/hotspot/jtreg/compiler/c2/Test6661247.java
! test/hotspot/jtreg/compiler/c2/Test7047069.java
! test/hotspot/jtreg/compiler/c2/Test7160610.java
! test/hotspot/jtreg/compiler/c2/Test7177917.java
! test/hotspot/jtreg/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java
! test/hotspot/jtreg/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java
! test/hotspot/jtreg/compiler/codecache/stress/Helper.java
! test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java
! test/hotspot/jtreg/compiler/codecache/stress/RandomAllocationTest.java
! test/hotspot/jtreg/compiler/codecache/stress/UnexpectedDeoptimizationTest.java
! test/hotspot/jtreg/compiler/codegen/Test6896617.java
! test/hotspot/jtreg/compiler/codegen/Test7100757.java
! test/hotspot/jtreg/compiler/codegen/TestTrichotomyExpressions.java
! test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java
! test/hotspot/jtreg/compiler/codegen/aes/TestCipherBlockChainingEncrypt.java
! test/hotspot/jtreg/compiler/compilercontrol/commandfile/CompileOnlyTest.java
! test/hotspot/jtreg/compiler/compilercontrol/commandfile/ExcludeTest.java
! test/hotspot/jtreg/compiler/compilercontrol/commandfile/LogTest.java
! test/hotspot/jtreg/compiler/compilercontrol/commandfile/PrintTest.java
! test/hotspot/jtreg/compiler/compilercontrol/commands/CompileOnlyTest.java
! test/hotspot/jtreg/compiler/compilercontrol/commands/ExcludeTest.java
! test/hotspot/jtreg/compiler/compilercontrol/commands/LogTest.java
! test/hotspot/jtreg/compiler/compilercontrol/commands/PrintTest.java
! test/hotspot/jtreg/compiler/compilercontrol/directives/CompileOnlyTest.java
! test/hotspot/jtreg/compiler/compilercontrol/directives/ExcludeTest.java
! test/hotspot/jtreg/compiler/compilercontrol/directives/LogTest.java
! test/hotspot/jtreg/compiler/compilercontrol/directives/PrintTest.java
! test/hotspot/jtreg/compiler/compilercontrol/jcmd/AddAndRemoveTest.java
! test/hotspot/jtreg/compiler/compilercontrol/jcmd/AddCompileOnlyTest.java
! test/hotspot/jtreg/compiler/compilercontrol/jcmd/AddExcludeTest.java
! test/hotspot/jtreg/compiler/compilercontrol/jcmd/AddLogTest.java
! test/hotspot/jtreg/compiler/compilercontrol/jcmd/AddPrintAssemblyTest.java
! test/hotspot/jtreg/compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java
! test/hotspot/jtreg/compiler/compilercontrol/jcmd/ClearDirectivesStackTest.java
! test/hotspot/jtreg/compiler/compilercontrol/jcmd/PrintDirectivesTest.java
! test/hotspot/jtreg/compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java
! test/hotspot/jtreg/compiler/compilercontrol/matcher/MethodMatcherTest.java
! test/hotspot/jtreg/compiler/compilercontrol/mixed/RandomCommandsTest.java
! test/hotspot/jtreg/compiler/compilercontrol/mixed/RandomValidCommandsTest.java
! test/hotspot/jtreg/compiler/compilercontrol/parser/DirectiveStressTest.java
! test/hotspot/jtreg/compiler/compilercontrol/parser/HugeDirectiveUtil.java
! test/hotspot/jtreg/compiler/escapeAnalysis/TestSelfArrayCopy.java
! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java
! test/hotspot/jtreg/compiler/interpreter/DisableOSRTest.java
! test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/MontgomeryMultiplyTest.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestMulAdd.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestMultiplyToLen.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestShift.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestSquareToLen.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestAndnI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestAndnL.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestBlsiI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestBlsiL.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestBlsmskI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestBlsmskL.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestBlsrI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestBlsrL.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestLzcntI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestLzcntL.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestTzcntI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/TestTzcntL.java
! test/hotspot/jtreg/compiler/intrinsics/math/TestFpMinMaxIntrinsics.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/AddExactILoadTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/AddExactINonConstantTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/AddExactIRepeatTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactILoadTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactINonConstantTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactIRepeatTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/NegExactILoadTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/NegExactINonConstantTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/SubExactILoadTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/SubExactINonConstantTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/SubExactIRepeatTest.java
! test/hotspot/jtreg/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java
! test/hotspot/jtreg/compiler/intrinsics/unsafe/DirectByteBufferTest.java
! test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java
! test/hotspot/jtreg/compiler/jsr292/ConcurrentClassLoadingTest.java
! test/hotspot/jtreg/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java
! test/hotspot/jtreg/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java
! test/hotspot/jtreg/compiler/loopopts/superword/Vec_MulAddS2I.java
! test/hotspot/jtreg/compiler/types/correctness/OffTest.java
! test/hotspot/jtreg/compiler/unsafe/UnsafeRaw.java
! test/hotspot/jtreg/compiler/unsafe/UnsafeSmallOffsetBooleanAccessTest.java
! test/hotspot/jtreg/compiler/whitebox/BlockingCompilation.java

Changeset: cdfe841d
Author:    Claes Redestad 
Date:      2020-04-09 13:04:10 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cdfe841d

8242038: G1: Lazily initialize RSHashTables

Reviewed-by: kbarrett, sjohanss, tschatzl

! src/hotspot/share/gc/g1/sparsePRT.cpp
! src/hotspot/share/gc/g1/sparsePRT.hpp

Changeset: 13645057
Author:    Zhengyu Gu 
Date:      2020-04-09 08:43:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/13645057

8242400: Shenandoah: Restore logging to pre-jdk8241984 format

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp

Changeset: 36f22938
Author:    Claes Redestad 
Date:      2020-04-09 14:59:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/36f22938

8241920: G1: Lazily initialize OtherRegionsTable::_coarse_map

Reviewed-by: tschatzl, eosterlund

! src/hotspot/share/gc/g1/heapRegionRemSet.cpp
! src/hotspot/share/gc/g1/heapRegionRemSet.hpp

Changeset: d9bf9348
Author:    Jim Laskey 
Date:      2020-04-09 10:55:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d9bf9348

8241742: Remove the preview status for methods introduced for Text Blocks

Reviewed-by: psandoz, chegar, alanb

! src/java.base/share/classes/java/lang/String.java
! test/jdk/java/lang/String/Formatted.java
! test/jdk/java/lang/String/StripIndent.java
! test/jdk/java/lang/String/TranslateEscapes.java

Changeset: ef8537ec
Author:    Jim Laskey 
Date:      2020-04-09 10:55:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ef8537ec

8241741: Implement Text Blocks as a standard feature in javac

Reviewed-by: jlahoda

! src/java.base/share/classes/jdk/internal/PreviewFeature.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! test/langtools/tools/javac/TextBlockAPI.java
! test/langtools/tools/javac/TextBlockIllegalEscape.java
! test/langtools/tools/javac/TextBlockIllegalEscape.out
! test/langtools/tools/javac/TextBlockLang.java
! test/langtools/tools/javac/diags/examples/TextBlockCloseDelimiter.java
! test/langtools/tools/javac/diags/examples/TextBlockOpenDelimiter.java
+ test/langtools/tools/javac/diags/examples/TextBlockSource.java
! test/langtools/tools/javac/diags/examples/TextBlockWhitespace.java

Changeset: e0a75ed0
Author:    Chris Plummer 
Date:      2020-04-09 07:13:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e0a75ed0

8242162: convert clhsdb "sysprops" command from javascript to java

Reviewed-by: sspitsyn, ysuenaga

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
! test/hotspot/jtreg/serviceability/sa/LingeredAppSysProps.java
! test/hotspot/jtreg/serviceability/sa/TestSysProps.java

Changeset: 1d7dee9a
Author:    Vladimir Ivanov 
Date:      2020-04-09 21:29:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1d7dee9a

8242289: C2: Support platform-specific node cloning in Matcher

Reviewed-by: kvn

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/sparc/sparc.ad
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp

Changeset: b7d5172b
Author:    Jim Laskey 
Date:      2020-04-09 16:32:22 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b7d5172b

8242472: Comment for unused PreviewFeature.Feature.TEXT_BLOCKS enum

Reviewed-by: abuckley

! src/java.base/share/classes/jdk/internal/PreviewFeature.java

Changeset: 455d2e7c
Author:    Joe Darcy 
Date:      2020-04-09 14:16:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/455d2e7c

8225540: In core reflection note whether returned annotations are declaration or type annotations

Reviewed-by: alanb, prappo

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/Module.java
! src/java.base/share/classes/java/lang/Package.java
! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java
! src/java.base/share/classes/java/lang/reflect/AnnotatedElement.java
! src/java.base/share/classes/java/lang/reflect/AnnotatedType.java
! src/java.base/share/classes/java/lang/reflect/Constructor.java
! src/java.base/share/classes/java/lang/reflect/Executable.java
! src/java.base/share/classes/java/lang/reflect/Field.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.base/share/classes/java/lang/reflect/Modifier.java
! src/java.base/share/classes/java/lang/reflect/Parameter.java
! src/java.base/share/classes/java/lang/reflect/RecordComponent.java

Changeset: ca46bba5
Author:    Stuart Monteith 
Date:      2020-04-10 09:41:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ca46bba5

8241587: Aarch64: remove x86 specifics from os_linux.cpp/hpp/inline.hpp

Reviewed-by: dholmes

! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp
! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.inline.hpp

Changeset: 6b0b851a
Author:    Prasanta Sadhukhan 
Date:      2020-04-10 11:47:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6b0b851a

Merge

! test/jdk/ProblemList.txt
! test/jdk/ProblemList.txt

Changeset: 592b9a95
Author:    Yang Zhang 
Date:      2020-04-10 05:43:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/592b9a95

8241911: AArch64: Fix a potential register clash issue in reduce_add2I

Reviewed-by: aph

! src/hotspot/cpu/aarch64/aarch64.ad

Changeset: 502d4595
Author:    Weijun Wang 
Date:      2020-04-10 15:05:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/502d4595

8240848: ArrayIndexOutOfBoundsException buf for TextCallbackHandler

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/util/ConsoleCallbackHandler.java
! test/jdk/com/sun/security/auth/callback/TextCallbackHandler/Confirm.java

Changeset: 86722cb0
Author:    Rahul Yadav 
Committer: Patrick Concannon 
Date:      2020-04-10 10:05:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/86722cb0

8239594: jdk.tls.client.protocols is not respected
8239595: ssl context version is not respected

The java.net.HttpClient is updated to no longer override any default selected protocols in the SSLContext, in the absence of  any SSLParameters explicitly supplied to the HttpClient.builder.

Reviewed-by: chegar, dfuchs

! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java
+ test/jdk/java/net/httpclient/TlsContextTest.java
+ test/jdk/java/net/httpclient/ssltest/TlsVersionTest.java
! test/lib/jdk/test/lib/net/SimpleSSLContext.java

Changeset: 5ad5aa49
Author:    Daniil Titov 
Date:      2020-04-10 08:46:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5ad5aa49

8242430: Correct links in javadoc of OperatingSystemMXBean

Reviewed-by: dholmes

! src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java

Changeset: 8ace9207
Author:    Joe Wang 
Date:      2020-04-10 17:00:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8ace9207

8242470: Update Xerces to Version 2.12.1

Reviewed-by: lancea, naoto

! src/java.xml/share/legal/xerces.md

Changeset: f11d4628
Author:    Alex Menkov 
Date:      2020-04-10 10:52:26 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f11d4628

8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572

Reviewed-by: dcubed, cjplummer

! test/jdk/sun/tools/jps/LingeredAppForJps.java
! test/jdk/sun/tools/jps/TestJps.java

Changeset: 93831d4e
Author:    Lance Andersen 
Date:      2020-04-10 14:00:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/93831d4e

8241883: (zipfs) SeekableByteChannel:close followed by SeekableByteChannel:close will throw an NPE coverage

Reviewed-by: clanger, alanb

! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java
! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
! test/jdk/jdk/nio/zipfs/testng/test/ChannelTests.java

Changeset: 3cf922b3
Author:    Roger Riggs 
Date:      2020-04-10 16:33:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3cf922b3

8242462: Residual Cleanup of rmic removal

Reviewed-by: jjg, amlu, erikj, iignatyev, mseledtsov

! bin/unshuffle_list.txt
! doc/building.html
! doc/building.md
- test/hotspot/jtreg/applications/ctw/modules/jdk_rmic.java
! test/hotspot/jtreg/runtime/cds/appcds/ProtectionDomain.java
! test/hotspot/jtreg/runtime/cds/appcds/SharedPackages.java
! test/hotspot/jtreg/runtime/cds/appcds/test-classes/JimageClassPackage.java
! test/hotspot/jtreg/runtime/cds/appcds/test-classes/JimageClassProtDomain.java
! test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list
! test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk11/element-list
! test/langtools/tools/jdeps/modules/InverseDeps.java

Changeset: 3a0a3d21
Author:    Chris Plummer 
Date:      2020-04-10 14:00:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3a0a3d21

8184249: SA: clhsdb 'intConstant' throws a NullPointerException when not attached to a VM

Reviewed-by: amenkov

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java

Changeset: 4895a19d
Author:    Liam Miller-Cushon 
Date:      2020-03-28 16:15:52 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4895a19d

8241798: Allow enums to have more constants

Reviewed-by: mcimadamore, briangoetz, forax

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! test/langtools/tools/javac/MethodParameters/EnumTest.out
! test/langtools/tools/javac/classfiles/attributes/Synthetic/EnumTest.java
+ test/langtools/tools/javac/enum/BigEnum.java

Changeset: efba976c
Author:    Prasanta Sadhukhan 
Date:      2020-04-11 10:32:17 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/efba976c

Merge


Changeset: 83a1d70f
Author:    Andy Herrick 
Date:      2020-04-10 16:21:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/83a1d70f

8242155: Enhance automated macos signing tests

Reviewed-by: asemenyuk, almatvee

! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/macosx/base/SigningBase.java

Changeset: 447d6499
Author:    Brian Burkhalter 
Date:      2020-04-13 10:16:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/447d6499

8242292: (fs) FileSystems.getFileSystem(URI) should throw IAE if the URI scheme is null

Reviewed-by: lancea, alanb

! src/java.base/share/classes/java/nio/file/FileSystems.java
! test/jdk/java/nio/file/FileSystem/Basic.java

Changeset: ea36a53b
Author:    Brian Burkhalter 
Date:      2020-04-13 10:17:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ea36a53b

8241952: (fs) FileChannel.write(ByteBuffer src, long position) does not check for the FileChannel being closed first

Reviewed-by: lancea, alanb

! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java

Changeset: 7a608f40
Author:    Jonathan Gibbons 
Date:      2020-04-13 10:54:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7a608f40

8242326: use new "summary-list" CSS class instead of general "block-list" for list of summary sections

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MarkerComments.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ClassWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/MemberSummaryWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ModuleSummaryWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PackageSummaryWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PackageSummaryBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java
! test/langtools/jdk/javadoc/doclet/testLists/TestLists.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java

Changeset: 68e0e49b
Author:    Serguei Spitsyn 
Date:      2020-04-13 18:02:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/68e0e49b

8242241: add assert to ClassUnloadEventImpl::className

Add assert

Reviewed-by: cjplummer, dcubed

! src/jdk.jdi/share/classes/com/sun/tools/jdi/EventSetImpl.java

Changeset: 15464b36
Author:    Igor Ignatyev 
Date:      2020-04-13 12:30:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/15464b36

8242471: remove "temporarily" restrictions of nsk/jdi/Argument/value/value004

Reviewed-by: amenkov, cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/value/value004.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/value/value004/TestDescription.java

Changeset: 116fe806
Author:    Igor Ignatyev 
Date:      2020-04-13 12:31:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/116fe806

8242313: use reproducible random in hotspot svc tests

Reviewed-by: cjplummer

! test/hotspot/jtreg/serviceability/sa/LingeredAppWithNativeMethod.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java
! test/hotspot/jtreg/serviceability/threads/TestFalseDeadLock.java

Changeset: c73934d8
Author:    Igor Ignatyev 
Date:      2020-04-13 12:32:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c73934d8

8242311: use reproducible random in hotspot runtime tests

Reviewed-by: iklam, mseledtsov

! test/hotspot/jtreg/runtime/NMT/HugeArenaTracking.java
! test/hotspot/jtreg/runtime/NMT/MallocStressTest.java
! test/hotspot/jtreg/runtime/NMT/MallocTrackingVerify.java
! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/GCStressApp.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/GCStressTest.java
! test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerExceptionTest.java

Changeset: 77041dc4
Author:    Chris Plummer 
Date:      2020-04-13 13:21:56 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/77041dc4

8235220: ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException

Reviewed-by: amenkov, iklam

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java
! test/hotspot/jtreg/ProblemList.txt

Changeset: 99a6b6b8
Author:    Evgeny Nikitin 
Committer: Igor Ignatyev 
Date:      2020-03-24 15:21:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/99a6b6b8

8174768: Make ProcessTools print executed process output into a separate file

Reviewed-by: dholmes, iignatyev

! test/lib/jdk/test/lib/process/ProcessTools.java

Changeset: a46f4bfa
Author:    Stuart Marks 
Date:      2020-04-13 14:37:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a46f4bfa

8242327: List spec should state that unmodifiable lists implement RandomAccess

Reviewed-by: lancea

! src/java.base/share/classes/java/util/List.java

Changeset: 4a09f31e
Author:    Chris Plummer 
Date:      2020-04-13 16:30:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4a09f31e

8237250: pmap and pstack should do a better of making it clear that they are not supported on Mac OS X

Reviewed-by: amenkov, sspitsyn

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPmap.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java

Changeset: d34f732b
Author:    Yasumasa Suenaga 
Date:      2020-04-14 09:03:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d34f732b

8242283: Can't start JVM when java home path includes non-ASCII character

Reviewed-by: naoto, hseigel

! src/hotspot/os/windows/os_windows.cpp
! src/java.base/share/native/libzip/zip_util.c
! src/java.base/windows/native/libjava/canonicalize_md.c
! src/java.base/windows/native/libjli/java_md.c
! src/jdk.incubator.jpackage/windows/native/libapplauncher/WindowsPlatform.cpp

Changeset: 8cd92414
Author:    Weijun Wang 
Date:      2020-04-14 10:04:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8cd92414

8242330: Arrays should be cloned in several JAAS Callback classes

Reviewed-by: mullan

! src/java.base/share/classes/javax/security/auth/callback/ChoiceCallback.java
! src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java
+ test/jdk/javax/security/auth/callback/Mutability.java

Changeset: 5dca7ec6
Author:    Magnus Ihse Bursie 
Date:      2020-04-14 14:58:24 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5dca7ec6

8231572: Use -lobjc instead of -fobjc-link-runtime in libosxsecurity

Reviewed-by: erikj

! make/lib/Lib-java.base.gmk

Changeset: b18e006b
Author:    Stefan Johansson 
Date:      2020-04-14 15:18:22 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b18e006b

8242448: Change HeapRegionManager::guarantee_contiguous_range to be assert_contiguous_range

Reviewed-by: tschatzl, kbarrett

! src/hotspot/share/gc/g1/heapRegionManager.cpp
! src/hotspot/share/gc/g1/heapRegionManager.hpp

Changeset: e0ccd776
Author:    Aleksey Shipilev 
Date:      2020-04-14 15:33:00 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e0ccd776

8242625: Shenandoah: restore heap logging for Degenerated/Full cycles

Reviewed-by: rkennke, zgu

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp

Changeset: b812e8ba
Author:    Aleksey Shipilev 
Date:      2020-04-14 15:33:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b812e8ba

8242638: Shenandoah: restore heap logging for uncommit

Reviewed-by: zgu

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: aadc7c7c
Author:    Prasadrao Koppula 
Date:      2020-04-14 14:16:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/aadc7c7c

8237474: Default SSLEngine should create in server role

Reviewed-by: xuelei, coffeys

! src/java.base/share/classes/javax/net/ssl/SSLContext.java
! src/java.base/share/classes/javax/net/ssl/SSLContextSpi.java
! src/java.base/share/classes/javax/net/ssl/SSLEngine.java
! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java
! src/java.base/share/classes/sun/security/ssl/TransportContext.java
! test/jdk/sun/security/ssl/SSLContextImpl/CustomizedDTLSDefaultProtocols.java
! test/jdk/sun/security/ssl/SSLContextImpl/CustomizedDTLSServerDefaultProtocols.java
! test/jdk/sun/security/ssl/SSLContextImpl/DefaultDTLSEnabledProtocols.java
! test/jdk/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java

Changeset: 416f4ed7
Author:    Erik Joelsson 
Date:      2020-04-14 07:54:54 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/416f4ed7

8242463: ProcessTools.createNativeTestProcessBuilder() in testlib needs jdk/bin on PATH on Windows

Reviewed-by: iignatyev, mseledtsov, tbell

! test/lib/jdk/test/lib/Platform.java
! test/lib/jdk/test/lib/process/ProcessTools.java

Changeset: 165fa245
Author:    Erik Joelsson 
Date:      2020-04-14 07:58:08 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/165fa245

8242468: VS2019 build missing vcruntime140_1.dll

Reviewed-by: tbell, ihse

! make/CreateJmods.gmk
! make/autoconf/basic.m4
! make/autoconf/spec.gmk.in
! make/autoconf/toolchain_windows.m4
! make/copy/Copy-java.base.gmk
! make/devkit/createWindowsDevkit2019.sh
! make/hotspot/test/GtestImage.gmk
! make/lib/CoreLibraries.gmk
! src/java.base/windows/native/libjli/java_md.c

Changeset: 1cc71b41
Author:    Hannes Walln?fer 
Date:      2020-04-14 19:22:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1cc71b41

8241982: Make TestSearchScript.java run with GraalJS

Reviewed-by: sundar, jjg

! test/langtools/jdk/javadoc/doclet/testSearchScript/TestSearchScript.java

Changeset: a62a0e52
Author:    Denghui Dong 
Date:      2020-04-14 20:36:33 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/a62a0e52

8238665: Add JFR event for direct memory statistics

Reviewed-by: egahlin, alanb

! src/java.base/share/classes/java/nio/Bits.java
! src/java.base/share/classes/java/nio/Buffer.java
! src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
! src/java.base/share/classes/jdk/internal/misc/VM.java
! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java
! src/java.management/share/classes/sun/management/ManagementFactoryHelper.java
+ src/jdk.jfr/share/classes/jdk/jfr/events/AbstractBufferStatisticsEvent.java
+ src/jdk.jfr/share/classes/jdk/jfr/events/DirectBufferStatisticsEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java
! src/jdk.jfr/share/conf/jfr/default.jfc
! src/jdk.jfr/share/conf/jfr/profile.jfc
+ test/jdk/jdk/jfr/event/runtime/TestDirectBufferStatisticsEvent.java
! test/lib/jdk/test/lib/jfr/EventNames.java

Changeset: e969c158
Author:    Aditya Mandaleeka 
Committer: Aleksey Shipilev 
Date:      2020-04-14 21:17:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e969c158

8241142: Shenandoah: should not use parallel reference processing with single GC thread

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 36021864
Author:    Christoph Langer 
Date:      2020-04-14 21:43:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/36021864

8242039: Improve jlink VersionPropsPlugin

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/VersionProps.java.template
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VersionPropsPlugin.java

Changeset: b98e863f
Author:    Aleksey Shipilev 
Date:      2020-04-14 22:18:37 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b98e863f

8242641: Shenandoah: clear live data and update TAMS optimistically

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 4694da31
Author:    Kim Barrett 
Date:      2020-04-14 17:31:53 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4694da31

8242078: G1: Improve concurrent refinement analytics and logging

Unify data collection and reporting.

Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/g1/g1Analytics.cpp
! src/hotspot/share/gc/g1/g1Analytics.hpp
! src/hotspot/share/gc/g1/g1BarrierSet.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp
+ src/hotspot/share/gc/g1/g1ConcurrentRefineStats.cpp
+ src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp
! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1Policy.hpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1RemSetSummary.cpp
! src/hotspot/share/gc/g1/g1RemSetSummary.hpp
! src/hotspot/share/logging/logPrefix.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java
! test/hotspot/jtreg/gc/g1/TestRemsetLoggingTools.java

Changeset: 4c7d85b6
Author:    Valerie Peng 
Date:      2020-04-14 22:12:13 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4c7d85b6

8242556: Cannot load RSASSA-PSS public key with non-null params from byte array

Update AlgorithmId to use alg name before oid str when parsing DER bytes

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/x509/AlgorithmId.java
! test/jdk/sun/security/rsa/pss/PSSParametersTest.java
! test/jdk/sun/security/rsa/pss/TestPSSKeySupport.java

Changeset: 7bce9a91
Author:    Valerie Peng 
Date:      2020-04-14 22:31:54 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7bce9a91

8172680: Support SHA-3 based Hmac algorithms

Enhanced SunJCE provider with Hmac with SHA3 digests

Reviewed-by: weijun

! src/java.base/share/classes/com/sun/crypto/provider/HmacCore.java
! src/java.base/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java
! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java
! test/jdk/com/sun/crypto/provider/Mac/MacKAT.java

Changeset: 9efd3d7f
Author:    Sean Mullan 
Date:      2019-10-15 08:18:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/9efd3d7f

8231415: Better signatures in XML

Reviewed-by: weijun, mschoene, rhalade

! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java
! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java

Changeset: 123febeb
Author:    Xue-Lei Andrew Fan 
Date:      2019-10-20 13:42:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/123febeb

8229733: TLS message handling improvements

Reviewed-by: jnimeh, rhalade, ahgross

! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java
! src/java.base/share/classes/sun/security/ssl/PostHandshakeContext.java
! src/java.base/share/classes/sun/security/ssl/TransportContext.java

Changeset: 6c16f55f
Author:    Ivan Gerasimov 
Date:      2019-10-23 17:03:07 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/6c16f55f

8231785: Improved socket permissions

Reviewed-by: ahgross, chegar, mullan, rhalade

! src/java.base/share/classes/java/net/SocketPermission.java
! test/jdk/java/net/SocketPermission/SocketPermissionCollection.java

Changeset: e6304dca
Author:    Xue-Lei Andrew Fan 
Date:      2019-10-28 10:43:58 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e6304dca

8232424: More constrained algorithms

Reviewed-by: jnimeh, rhalade, ahgross

! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java
! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

Changeset: 740e70ba
Author:    Jamil Nimeh 
Date:      2019-10-30 13:15:21 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/740e70ba

8232581: Improve TLS verification

Reviewed-by: xuelei, rhalade, mschoene

! src/java.base/share/classes/sun/security/ssl/Alert.java
! src/java.base/share/classes/sun/security/ssl/ClientKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/Finished.java

Changeset: 0e4b718a
Author:    Hannes Walln?fer 
Date:      2019-11-06 17:13:21 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0e4b718a

8223898: Forward references to Nashorn

Reviewed-by: sundar, mschoene, rhalade

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java

Changeset: 3bbc499f
Author:    Alex Menkov 
Date:      2019-11-14 15:06:11 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3bbc499f

8227542: Manifest improved jar headers

Reviewed-by: sspitsyn, mschoene

! src/java.instrument/share/classes/java/lang/instrument/package-info.java
! src/java.instrument/share/native/libinstrument/InvocationAdapter.c

Changeset: 3dd1fd29
Author:    Hannes Walln?fer 
Date:      2019-11-15 19:10:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3dd1fd29

8223904: Improve Nashorn matching

Reviewed-by: jlaskey, sundar, mschoene, rhalade

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Parser.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java

Changeset: 72c7b49b
Author:    Xue-Lei Andrew Fan 
Date:      2019-11-25 09:50:30 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/72c7b49b

8234408: Improve TLS session handling

Reviewed-by: ascarpino, jjiang, ahgross, ssahoo, mullan

! src/java.base/share/classes/sun/security/ssl/ClientHello.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/ssl/TransportContext.java

Changeset: 2ea157fe
Author:    Vladimir Ivanov 
Date:      2019-12-03 19:31:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2ea157fe

8227467: Better class method invocations

Reviewed-by: thartmann, dholmes, ahgross

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/oops/instanceKlass.hpp

Changeset: ad098130
Author:    Daniel Fuchs 
Date:      2019-12-09 20:33:15 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ad098130

8233245: More adaptive sockets

Reviewed-by: chegar, igerasim, alanb, skoivu, rhalade

! src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
+ test/jdk/java/net/DatagramSocket/GetLocalAddress.java

Changeset: c182379f
Author:    Weijun Wang 
Date:      2019-12-11 16:35:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/c182379f

8234027: Better JCEKS key support

Reviewed-by: ahgross, mullan, rriggs, rhalade

! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java
! src/java.base/share/classes/com/sun/crypto/provider/KeyProtector.java
! src/java.base/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java

Changeset: 0a73d5b7
Author:    Erik Joelsson 
Date:      2019-12-12 15:38:36 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0a73d5b7

8233410: Better Build Scripting

Reviewed-by: tbell, jwilhelm

! make/autoconf/flags-cflags.m4
! make/autoconf/flags-ldflags.m4
! make/launcher/LauncherCommon.gmk

Changeset: 4df99aa7
Author:    Erik Joelsson 
Date:      2019-12-13 08:27:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/4df99aa7

8226346: Build better binary builders

Reviewed-by: tbell

! make/TestImage.gmk
! make/autoconf/basic.m4
! make/autoconf/configure.ac
! make/autoconf/flags-cflags.m4
! make/autoconf/flags-ldflags.m4
! make/autoconf/jdk-options.m4
! make/autoconf/spec.gmk.in
! make/common/NativeCompilation.gmk
! make/gensrc/GensrcCharacterData.gmk
! make/gensrc/GensrcModuleInfo.gmk
! make/hotspot/gensrc/GensrcAdlc.gmk
! make/hotspot/gensrc/GensrcDtrace.gmk
! make/hotspot/lib/CompileDtraceLibraries.gmk
! make/hotspot/lib/CompileGtest.gmk
! make/hotspot/lib/CompileJvm.gmk
! make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java
! make/jdk/src/classes/build/tools/module/GenModuleInfoSource.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m
! src/java.desktop/macosx/native/libawt_lwawt/font/AWTStrike.m
! src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiOut.c
! src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c
! src/java.desktop/macosx/native/libosxui/ScreenMenu.m
! src/java.desktop/share/native/common/awt/debug/debug_assert.h
! src/java.desktop/share/native/common/awt/debug/debug_mem.c
! src/java.desktop/share/native/common/awt/debug/debug_trace.h
! src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipeline.h
! src/java.desktop/windows/native/libawt/windows/alloc.h
! src/java.desktop/windows/native/libawt/windows/awt_Debug.h
! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h
! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiIn.cpp
! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiOut.c
! src/java.instrument/share/native/libinstrument/JPLISAssert.h
! src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h
! src/jdk.jdi/share/native/libdt_shmem/shmemBase.h
! src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c
! src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h
! src/jdk.jdwp.agent/share/native/libjdwp/log_messages.h
+ test/jdk/build/AbsPathsInImage.java

Changeset: 2309ac52
Author:    Roger Riggs 
Date:      2019-12-13 11:23:50 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2309ac52

8235274: Enhance typing of methods

Reviewed-by: jrose, psandoz, skoivu

! src/java.base/share/classes/java/lang/invoke/MethodType.java

Changeset: 8e5af263
Author:    Michael McMahon 
Date:      2019-12-16 15:13:19 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8e5af263

8234825: Better Headings for HTTP Servers

Reviewed-by: chegar, dfuchs, igerasim

! src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java

Changeset: f4761381
Author:    Xue-Lei Andrew Fan 
Date:      2019-12-17 12:55:36 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f4761381

8235691: Enhance TLS connectivity

Reviewed-by: jnimeh, rhalade, ahgross

! src/java.base/share/classes/sun/security/ssl/SSLTransport.java

Changeset: f711ce40
Author:    Brian Burkhalter 
Date:      2019-12-18 07:21:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f711ce40

8234841: Enhance buffering of byte buffers

Reviewed-by: alanb, ahgross, rhalade, psandoz

! src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template
! src/java.base/share/classes/java/nio/StringCharBuffer.java

Changeset: e4f4e8ed
Author:    Anton Litvinov 
Date:      2020-01-16 15:08:19 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/e4f4e8ed

8233250: Better X11 rendering

Reviewed-by: prr, rhalade, mschoene, serb

! src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c
! src/java.desktop/unix/native/common/java2d/x11/X11PMBlitLoops.c
! src/java.desktop/unix/native/common/java2d/x11/X11TextRenderer_md.c
! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c
! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c
! src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c
! src/java.desktop/unix/native/libawt_xawt/java2d/x11/XRBackendNative.c

Changeset: d7136cd4
Author:    Brent Christian 
Date:      2020-01-21 10:56:30 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d7136cd4

8224541: Better mapping of serial ENUMs

Reviewed-by: mschoene, rhalade, robm, rriggs, smarks

! src/java.base/share/classes/java/io/ObjectInputStream.java
! src/java.base/share/classes/java/io/ObjectStreamClass.java

Changeset: 14c0c195
Author:    Stuart Marks 
Date:      2020-01-21 16:53:01 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/14c0c195

8224549: Less Blocking Array Queues

Reviewed-by: bchristi, rhalade, rriggs, mschoene, robm

! src/java.base/share/classes/java/io/ObjectStreamClass.java

Changeset: 833a3897
Author:    Brian Burkhalter 
Date:      2019-10-29 14:07:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/833a3897

8225603: Enhancement for big integers

Reviewed-by: darcy, ahgross, rhalade

! src/java.base/share/classes/java/math/MutableBigInteger.java
! src/jdk.crypto.ec/share/native/libsunec/impl/mpi.c
+ test/jdk/java/math/BigInteger/ModInvTime.java

Changeset: f77016b9
Author:    Ivan Gerasimov 
Date:      2020-01-29 20:01:34 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f77016b9

8236201: Better Scanner conversions

Reviewed-by: ahgross, rhalade, rriggs, skoivu, smarks

! src/java.base/share/classes/java/util/Scanner.java

Changeset: 5fff0506
Author:    Erik Joelsson 
Date:      2020-02-20 09:09:25 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/5fff0506

8239429: AbsPathsInImage.java fails in JDK 11u and 14u on Windows

Reviewed-by: tbell

! test/jdk/build/AbsPathsInImage.java

Changeset: 7e20cf75
Author:    Erik Joelsson 
Date:      2020-02-20 14:05:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7e20cf75

8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap

Reviewed-by: ihse, tbell, ahgross, jwilhelm

! make/autoconf/flags-ldflags.m4

Changeset: 0278846e
Author:    Henry Jen 
Date:      2020-04-14 23:11:49 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0278846e

Merge

! make/autoconf/basic.m4
! make/autoconf/spec.gmk.in
! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/ssl/TransportContext.java
! src/java.security.jgss/share/classes/sun/security/krb5/Checksum.java
! make/autoconf/basic.m4
! make/autoconf/spec.gmk.in
! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/ssl/TransportContext.java
! src/java.security.jgss/share/classes/sun/security/krb5/Checksum.java

Changeset: 346d09e7
Author:    Zhengyu Gu 
Date:      2020-04-14 20:03:29 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/346d09e7

8242602: Shenandoah: allow earlier recycle of trashed regions during concurrent root processing

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp

Changeset: 23709c83
Author:    Zhengyu Gu 
Date:      2020-04-14 21:08:15 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/23709c83

8242643: Shenandoah: split concurrent weak and strong root processing

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp

Changeset: 919027a9
Author:    Denghui Dong 
Date:      2020-04-14 16:37:36 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/919027a9

8242485: Null _file checking in fileStream::flush()

Reviewed-by: dholmes, ysuenaga, iklam

! src/hotspot/share/utilities/ostream.cpp
! src/hotspot/share/utilities/ostream.hpp

Changeset: b0d709cc
Author:    Magnus Ihse Bursie 
Date:      2020-04-15 08:58:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/b0d709cc

8241618: Fix trivial unchecked warnings for jdk.hotspot.agent

Reviewed-by: cjplummer, sspitsyn

! src/jdk.hotspot.agent/share/classes/com/sun/java/swing/action/ActionManager.java
! src/jdk.hotspot.agent/share/classes/com/sun/java/swing/ui/CommonUI.java
! src/jdk.hotspot.agent/share/classes/com/sun/java/swing/ui/TabsDlg.java
! src/jdk.hotspot.agent/share/classes/com/sun/java/swing/ui/WizardDlg.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotAgent.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/ObjectValue.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/StubQueue.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/Debugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/CDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/LoadObjectComparator.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/TemplateType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/BasicBlockSym.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/BasicCDebugInfoDataBase.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/BasicCompoundType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/BasicEnumType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/BasicFunctionType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/BasicLineNumberMapping.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/BasicType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/dummy/DummyDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc/ProcCDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/win32/coff/COFFFileParser.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugInfoBuilder.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/BytecodeDisassembler.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/OopMapForCacheEntry.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/Dictionary.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/Universe.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/CellTypeStateList.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHistogram.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/VirtualCallTypeData.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/InlineTree.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Node.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ConcurrentLocksPrinter.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/DeadlockDetector.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/StackValueCollection.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VirtualBaseConstructor.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/PackageNameFilter.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/basic/BasicType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/basic/BasicVtblAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/AnnotatedMemoryPanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/Annotation.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/FindInHeapPanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/HighPrecisionJScrollBar.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/HistoryComboBox.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/ObjectHistogramPanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/ProcessListPanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/SAPanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/SourceCodePanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/tree/CTypeTreeNodeAdapter.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/tree/RevPtrsTreeNodeAdapter.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/tree/SimpleTreeGroupNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/tree/SimpleTreeModel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CStringUtilities.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/FindObjectByType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/Hashtable.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/Interval.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/IntervalNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/IntervalTree.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/LivenessAnalysis.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/LivenessPath.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/LivenessPathList.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/MessageQueueBackend.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/ObjectReader.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/RBTree.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/ReversePtrs.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/StreamMonitor.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactoryImpl.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaField.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFrame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaInstanceKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaMethod.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaThread.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaVM.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/MapScriptObject.java

Changeset: 7bd2cd0b
Author:    Kim Barrett 
Date:      2020-04-15 03:05:30 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/7bd2cd0b

8242597: Remove GenericTaskQueue<>::push_slow

Remove push_slow and comment invariants.

Reviewed-by: tschatzl, iwalulya

! src/hotspot/share/gc/shared/taskqueue.hpp
! src/hotspot/share/gc/shared/taskqueue.inline.hpp

Changeset: d983fa6c
Author:    Magnus Ihse Bursie 
Date:      2020-04-15 09:35:27 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d983fa6c

8242629: Remove references to deprecated java.util.Observer and Observable

Reviewed-by: erikj, cjplummer, sspitsyn

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/asm/Disassembler.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/c1/Runtime1.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciBaseObject.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciConstant.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciEnv.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciField.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciInstance.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciMetadata.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciMethod.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciMethodData.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciObject.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciSymbol.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/classfile/ClassLoaderDataGraph.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/AdapterBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/BufferBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CompiledMethod.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/DeoptimizationBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/ExceptionBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/Location.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/MethodHandlesAdapterBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/PCDesc.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/RuntimeBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/RuntimeStub.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/SafepointBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/SingletonBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/StubQueue.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/UncommonTrapBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/VMRegImpl.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/compiler/CompileTask.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/compiler/ImmutableOopMap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/compiler/ImmutableOopMapPair.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/compiler/ImmutableOopMapSet.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/epsilon/EpsilonHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionTable.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1MonitoringSupport.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionSetBase.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ImmutableSpace.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/MutableSpace.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/PSOldGen.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/PSYoungGen.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ParallelScavengeHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/serial/DefNewGeneration.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/serial/TenuredGeneration.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/CollectedHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/CompactibleSpace.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/ContiguousSpace.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenCollectedHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/Generation.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenerationFactory.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenerationSpec.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/OopStorage.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/Space.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeapRegion.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/Interpreter.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/InterpreterCodelet.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/CodeHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/Dictionary.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FreeChunk.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/HeapBlock.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/MemRegion.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/MetaspaceObj.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/Universe.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/VirtualSpace.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Array.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/BreakpointInfo.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/CheckedExceptionElement.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/CompiledICHolder.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/CompressedKlassPointers.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/CompressedOops.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstMethod.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheEntry.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ExceptionTableElement.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Instance.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceClassLoaderKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceRefKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Klass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/LocalVariableTableElement.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Mark.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Method.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjArray.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjArrayKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/OopUtilities.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Symbol.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/TypeArray.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/TypeArrayKlass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Block.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Block_Array.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Block_List.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Compile.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/HaltNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/InlineTree.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/JVMState.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/LoopNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/MachCallNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/MachIfNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/MachNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/MultiNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Node.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Node_Array.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Node_List.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Phase.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/PhiNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/ProjNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/RegionNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/RootNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/SafePointNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/TypeNode.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Arguments.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicLock.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicObjectLock.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicTypeSize.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/CompilerThread.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JNIHandleBlock.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JNIHandles.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaCallWrapper.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/OSThread.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectSynchronizer.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/PerfDataEntry.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/PerfDataPrologue.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/PerfMemory.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/RegisterMap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/StubRoutines.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMReg.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64JavaCallWrapper.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64JavaCallWrapper.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/bsd_x86/BsdX86JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux_aarch64/LinuxAARCH64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux_amd64/LinuxAMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux_sparc/LinuxSPARCJavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux_x86/LinuxX86JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/solaris_amd64/SolarisAMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/solaris_sparc/SolarisSPARCJavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/solaris_x86/SolarisX86JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRegisterMap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/vmSymbols.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/win32_x86/Win32X86JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86JavaCallWrapper.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/GenericArray.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/Hashtable.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/IntArray.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/KlassArray.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/MethodArray.java
+ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/Observable.java
+ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/Observer.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/U1Array.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/U2Array.java

Changeset: 941bb3bc
Author:    Claes Redestad 
Date:      2020-04-15 19:03:59 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/941bb3bc

8242842: Avoid reallocating name when checking for trailing slash in ZipFile.getEntryPos

Co-authored-by: Eirik Bj?rsn?s 
Reviewed-by: alanb, lancea

! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: cc05419e
Author:    Vipin Sharma 
Committer: Pavel Rappo 
Date:      2020-04-15 20:42:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cc05419e

8242366: Fix JavaDoc warnings

Reviewed-by: dfuchs, mullan, prappo, weijun

! src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java
! src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java
! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
! src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java
! src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java
! src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java
! src/java.base/share/classes/com/sun/crypto/provider/Padding.java
! src/java.base/share/classes/com/sun/crypto/provider/SymmetricCipher.java
! src/java.base/share/classes/java/lang/ProcessBuilder.java
! src/java.base/share/classes/java/util/GregorianCalendar.java
! src/java.base/share/classes/sun/net/util/IPAddressUtil.java
! src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java
! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java
! src/java.base/share/classes/sun/security/jca/ProviderConfig.java
! src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java
! src/java.base/share/classes/sun/security/provider/certpath/Builder.java
! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java
! src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java
! src/java.base/share/classes/sun/security/timestamp/TSResponse.java
! src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java


From github.com+63007666+JimLaskey at openjdk.java.net  Thu Apr 23 13:06:28 2020
From: github.com+63007666+JimLaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 23 Apr 2020 13:06:28 GMT
Subject: [lworld] RFR: 8242900: [lworld] Allow an inline type to declare a
 superclass that meets specified restrictions
In-Reply-To: 
References: 
Message-ID: <4xWenffLJ0La_Hyg8wqtPI6-62om9LuXKMeYuARKrHc=.27b9bce8-7b86-419e-a7b7-0ef1efc72a44@github.com>

On Thu, 16 Apr 2020 11:29:18 GMT, Srikanth Adayapalam  wrote:

> Here is a change set that implements the changes for
> 
>      https://bugs.openjdk.java.net/browse/JDK-8242900 ([lworld] Allow an inline type to declare a superclass that meets
>      specified restrictions)
> and its prerequisite blocker:
>     https://bugs.openjdk.java.net/browse/JDK-8242912 (Abstract classes should not implement IdentityObject)
> 
> Here is a roadmap that would make it easier for you to review:
> 
>     - Go over to the JBS tickets above and read up the description of the tasks
>     - Start with the new tests to understand what is being implemented and tested:
>        
>             test/langtools/tools/javac/valhalla/lworld-values/BinarySuperclassConstraints.java
>             test/langtools/tools/javac/valhalla/lworld-values/BinarySuperclassConstraints.out
>             test/langtools/tools/javac/valhalla/lworld-values/SuperclassCollections.java
>             test/langtools/tools/javac/valhalla/lworld-values/SuperclassConstraints.java
>             test/langtools/tools/javac/valhalla/lworld-values/SuperclassConstraints.out
> 
>      - Review of source files is best taken up in this order:
>             Flags.java: defines two new flags to decorate classes with initializer blocks and empty no-arg constructor as being
>             such. Attr.java:    During attribution flag classes that have initializer blocks and constructors that are empty no-arg
>             constructors.
>                               Arrange to check for constraints of a super class of an inline class.
>             Check.java: Check the superclass's constraints when asked by the attributor.
>             ClassReader.java: When reading class files, flags constructors that are empty no-arg constructors (save for chaining to
>             super's no-arg ctor) compiler.properties: new errors.
>             TransValues.java: In earlier versions, Inline types implicitly extended jlO, so any super() chaining call must be jlO's
>             ctor. This is no longer the case. So remove the assertion. TreeInfo.java: Tweak to a utility method to make it more
>             general and suitable for our present needs. TypeEnter.java: Earlier specs forbid an inline type declaration to have an
>             extends clause. This is no longer illegal. So we don't error anymore. Abstract types should not implement the new top
>             interface (IdentityObject)
> 
>     - These changes are simply rolling back prior changes made at the time of injection of new top interfaces. Because we
>       don't inject them anymore for abstract classes, we should not encode them in "golden" files:
>             test/jdk/java/lang/annotation/TypeAnnotationReflection.java
>             test/jdk/java/lang/reflect/Generics/TestC1.java
>             test/jdk/java/lang/reflect/Generics/TestC2.java
>             test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations_2.out
>             test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations_3.out
>             test/langtools/tools/javap/AnnoTest.java
> 
>     - To shut up CheckExamples.java from spuriously failing, for the time being add the new compiler message keys to the
>       white list:
>             test/langtools/tools/javac/diags/examples.not-yet.txt
> 
>     - Other minorly modified tests that you may want to eyeball: (The diagnostics change a little bit since "extends" clause
>       is no longer illegal. I have added -XDallowEmptyValues in some cases to exercise different code paths and elicit
>       different diagnostics)
> 
>             test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.java
>             test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.out
>             test/langtools/tools/javac/valhalla/lworld-values/IllegalByValueTest2.out
>             test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationTest.java
>             test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationTest.out
>             test/langtools/tools/javac/valhalla/lworld-values/ValueAnnotationTest.out
>             test/langtools/tools/javac/valhalla/lworld-values/ValueModifierTest.out
> 
>     - This one is an odd man out: (Earlier Number implemented IdentityObject, but not anymore since it is abstract, so it is
>       injected deeper now and surfaces - but this whole express injection is a temporary thing and will go away with
>       JDK-8242612
>         test/langtools/tools/javac/varargs/6806876/T6806876.out

Marked as reviewed by JimLaskey at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/23

From sadayapalam at openjdk.java.net  Thu Apr 23 14:52:02 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 23 Apr 2020 14:52:02 GMT
Subject: [Integrated] [lworld] RFR: 8242900: [lworld] Allow an inline type
 to declare a superclass that meets specified restrictions
In-Reply-To: 
References: 
Message-ID: 

Changeset: 21a4dae7
Author:    Srikanth Adayapalam 
Date:      2020-04-23 14:51:32 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/21a4dae7

8242900: [lworld] Allow an inline type to declare a superclass that meets specified restrictions

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/TransValues.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! test/jdk/java/lang/annotation/TypeAnnotationReflection.java
! test/jdk/java/lang/reflect/Generics/TestC1.java
! test/jdk/java/lang/reflect/Generics/TestC2.java
! test/langtools/tools/javac/diags/examples.not-yet.txt
! test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations_2.out
! test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations_3.out
+ test/langtools/tools/javac/valhalla/lworld-values/BinarySuperclassConstraints.java
+ test/langtools/tools/javac/valhalla/lworld-values/BinarySuperclassConstraints.out
! test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.java
! test/langtools/tools/javac/valhalla/lworld-values/CheckExtends.out
! test/langtools/tools/javac/valhalla/lworld-values/IllegalByValueTest2.out
! test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationTest.java
! test/langtools/tools/javac/valhalla/lworld-values/InlineAnnotationTest.out
+ test/langtools/tools/javac/valhalla/lworld-values/SuperclassCollections.java
+ test/langtools/tools/javac/valhalla/lworld-values/SuperclassConstraints.java
+ test/langtools/tools/javac/valhalla/lworld-values/SuperclassConstraints.out
! test/langtools/tools/javac/valhalla/lworld-values/ValueAnnotationTest.out
! test/langtools/tools/javac/valhalla/lworld-values/ValueModifierTest.out
! test/langtools/tools/javac/varargs/6806876/T6806876.out
! test/langtools/tools/javap/AnnoTest.java

From sadayapalam at openjdk.java.net  Mon Apr 27 04:23:08 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 27 Apr 2020 04:23:08 GMT
Subject: [lworld] RFR: 8243627: [lworld] Co-evolve jdk-valhalla tests along
 with JDK-8237072
Message-ID: 

Mandy,

May I request you to review these changes to jdk-valhalla tests ?

JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
refer to the reference projection of a value type V and its value projection.
The old syntax of V? is withdrawn. This change also has class file implications
where the descriptor/signature encodings will now start mentioning $ref in the
class pool entries. Also every inline type results in two class files now
one for each projection - with the reference projection class being the superclass
of the inline class.

I'll push them after your review and *after* JDK-8237072 itself is pushed.
Thanks in advance.

-------------

Commit messages:
 - 8243627: [lworld] Co-evolve jdk-valhalla tests along with JDK-8237072

Changes: https://git.openjdk.java.net/valhalla/pull/27/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/27/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243627
  Stats: 52 lines in 11 files changed: 1 ins; 0 del; 51 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/27/head:pull/27

PR: https://git.openjdk.java.net/valhalla/pull/27

From sadayapalam at openjdk.java.net  Mon Apr 27 04:33:03 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 27 Apr 2020 04:33:03 GMT
Subject: [lworld] RFR: 8243626: [lworld] Co-evolve hotspot-runtime tests along
 with JDK-8237072
Message-ID: <0Hi0qA2PXH8q4y4O2vc1QFN6AkxFGFC0CYKlBtX0jjE=.e2c7c703-afac-4181-ac0e-ab851ff1ce19@github.com>

Frederic,

May I request you to review these changes to hotspot runtime tests ?

JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
refer to the reference projection of a value type V and its value projection.
The old syntax of V? is withdrawn. This change also has class file implications
where the descriptor/signature encodings will now start mentioning $ref in the
class pool entries. Also every inline type results in two class files now
one for each projection - with the reference projection class being the superclass
of the inline class.

I'll push them after your review and after JDK-8237072 itself is pushed.
Thanks in advance.

-------------

Commit messages:
 - 8243626: [lworld] Co-evolve hotspot-runtime tests along with JDK-8237072

Changes: https://git.openjdk.java.net/valhalla/pull/28/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/28/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243626
  Stats: 57 lines in 12 files changed: 2 ins; 0 del; 55 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/28.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/28/head:pull/28

PR: https://git.openjdk.java.net/valhalla/pull/28

From sadayapalam at openjdk.java.net  Mon Apr 27 04:47:26 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 27 Apr 2020 04:47:26 GMT
Subject: [lworld] RFR: 8243623: [lworld] Syntax and other mechanical changes
 in langtools tests for JDK-8237072
Message-ID: 

Jim,

May I request you to review these changes to langtools tests that anticipate and
align with JDK-8237072 ? These changes are mechanical in nature and I decided it
is best to separate them from the RFR for JDK-8237072 itself to help create sharper
focus on the important pieces there. (Non-mechanical meaningful test changes with
be included in that RFR itself)

JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
refer to the reference projection of a value type V and its value projection.
The old syntax of V? is withdrawn. This change also has class file implications
where the descriptor/signature encodings will now start mentioning $ref in the
class pool entries. Also every inline type results in two class files now
one for each projection - with the reference projection class being the superclass
of the inline class.

I'll push them after your review and after JDK-8237072 itself is pushed.
Thanks in advance.

-------------

Commit messages:
 - 8243623: [lworld] Syntax and other mechanical changes in langtools tests for JDK-8237072

Changes: https://git.openjdk.java.net/valhalla/pull/29/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/29/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243623
  Stats: 90 lines in 26 files changed: 0 ins; 0 del; 90 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/29/head:pull/29

PR: https://git.openjdk.java.net/valhalla/pull/29

From sadayapalam at openjdk.java.net  Mon Apr 27 04:59:25 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 27 Apr 2020 04:59:25 GMT
Subject: [lworld] RFR: 8243625: [lworld] Co-evolve hotspot-compiler tests
 along with JDK-8237072
Message-ID: <2jYS17UipWQiTMk13r-p6vALummTyBPG_sVhjQZODUw=.9dd3d917-37c8-45fd-9542-0102609b285f@github.com>

Tobias,

May I request you to review these changes to hotspot-compiler tests that anticipate
and align with JDK-8237072 ? These changes are mechanical in nature and I decided it
is best to separate them from the RFR for JDK-8237072 itself to help create sharper
focus on the important pieces there.

JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
refer to the reference projection of a value type V and its value projection.
The old syntax of V? is withdrawn. This change also has class file implications
where the descriptor/signature encodings will now start mentioning $ref in the
class pool entries. Also every inline type results in two class files now
one for each projection - with the reference projection class being the superclass
of the inline class.

I'll push them after your review and after JDK-8237072 itself is pushed.
Thanks in advance.

-------------

Commit messages:
 - 8243625: [lworld] Co-evolve hotspot-compiler tests along with JDK-8237072

Changes: https://git.openjdk.java.net/valhalla/pull/30/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/30/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243625
  Stats: 470 lines in 15 files changed: 0 ins; 0 del; 470 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/30.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/30/head:pull/30

PR: https://git.openjdk.java.net/valhalla/pull/30

From thartmann at openjdk.java.net  Mon Apr 27 06:18:36 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 27 Apr 2020 06:18:36 GMT
Subject: [lworld] RFR: 8243625: [lworld] Co-evolve hotspot-compiler tests
 along with JDK-8237072
In-Reply-To: <2jYS17UipWQiTMk13r-p6vALummTyBPG_sVhjQZODUw=.9dd3d917-37c8-45fd-9542-0102609b285f@github.com>
References: <2jYS17UipWQiTMk13r-p6vALummTyBPG_sVhjQZODUw=.9dd3d917-37c8-45fd-9542-0102609b285f@github.com>
Message-ID: 

On Mon, 27 Apr 2020 04:54:07 GMT, Srikanth Adayapalam  wrote:

> Tobias,
> 
> May I request you to review these changes to hotspot-compiler tests that anticipate
> and align with JDK-8237072 ? These changes are mechanical in nature and I decided it
> is best to separate them from the RFR for JDK-8237072 itself to help create sharper
> focus on the important pieces there.
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and after JDK-8237072 itself is pushed.
> Thanks in advance.

Thanks for fixing. Looks good to me!

-------------

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/30

From sarma.swaranga at gmail.com  Mon Apr 27 07:44:44 2020
From: sarma.swaranga at gmail.com (Swaranga Sarma)
Date: Mon, 27 Apr 2020 00:44:44 -0700
Subject: Memory layout benefits of inline classes
Message-ID: 

The examples of the benefits of inline classes that I have seen in demos
are things like high allocation of data classes in a tight loop. I was
trying to understand how some of our existing code may benefit by using
inline classes which is different from the examples seen. I have the
following questions:

1. Optional: If we have a nullable members in a class, we would like to
return an Optional in the accessor for that member unless we have a
reason to reduce the allocation. I recall somewhere that Optional might be
an inline type in the future and this concern may no longer be valid. Is my
understanding correct?

2. CompletableFuture: Similar to Optional, is this a candidate for
potentially turning into an inline type?

3. Regular data classes: In a lot of our code bases, we have data classes
that look like:
class Identifier {
  final @NonNull Name name;
  final @NonNull Id id;
}

class Name {
  final @NonNull String value;
}

class Id {
  final @NonNull String value;
}

We create instances like these and pass these around to other methods.
Those methods access the necessary values using the access methods like
identifier.name().value() or identifier.id().value(). These classes are
probably good candidates for migrating to records. But I was also
interested to understand if we also made them inline classes what memory
layout benefits would we get. Would the pointer de-referencing problem go
away in such cases?

To put it in another way, most of our data classes boil down to Strings,
and assuming String will not become an inline type, would there be any
memory-layout benefits of making such classes inline?

Regards
Swaranga

From fparain at openjdk.java.net  Mon Apr 27 12:37:12 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 27 Apr 2020 12:37:12 GMT
Subject: [lworld] RFR: 8243626: [lworld] Co-evolve hotspot-runtime tests
 along with JDK-8237072
In-Reply-To: <0Hi0qA2PXH8q4y4O2vc1QFN6AkxFGFC0CYKlBtX0jjE=.e2c7c703-afac-4181-ac0e-ab851ff1ce19@github.com>
References: <0Hi0qA2PXH8q4y4O2vc1QFN6AkxFGFC0CYKlBtX0jjE=.e2c7c703-afac-4181-ac0e-ab851ff1ce19@github.com>
Message-ID: <-LgAfX847CzaPophBVb0NXnwQvdaewPXqzkeWs0JgZg=.4d8a5599-165d-4464-a17c-d223a54c8ec5@github.com>

On Mon, 27 Apr 2020 04:28:52 GMT, Srikanth Adayapalam  wrote:

> Frederic,
> 
> May I request you to review these changes to hotspot runtime tests ?
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and after JDK-8237072 itself is pushed.
> Thanks in advance.

Looks good to me.
Thank you Srikanth for fixing these tests.

Fred

-------------

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/28

From mchung at openjdk.java.net  Mon Apr 27 23:21:43 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 27 Apr 2020 23:21:43 GMT
Subject: [lworld] RFR: 8243627: [lworld] Co-evolve jdk-valhalla tests
 along with JDK-8237072
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Apr 2020 04:17:49 GMT, Srikanth Adayapalam  wrote:

> Mandy,
> 
> May I request you to review these changes to jdk-valhalla tests ?
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and *after* JDK-8237072 itself is pushed.
> Thanks in advance.

Looks good to me.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/27

From mchung at openjdk.java.net  Mon Apr 27 23:43:13 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 27 Apr 2020 23:43:13 GMT
Subject: [lworld] RFR: 8243627: [lworld] Co-evolve jdk-valhalla tests
 along with JDK-8237072
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Apr 2020 04:17:49 GMT, Srikanth Adayapalam  wrote:

> Mandy,
> 
> May I request you to review these changes to jdk-valhalla tests ?
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and *after* JDK-8237072 itself is pushed.
> Thanks in advance.

Marked as reviewed by mchung (Committer).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/27

From dsimms at openjdk.java.net  Tue Apr 28 12:03:40 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 28 Apr 2020 12:03:40 GMT
Subject: [Integrated] [lworld] RFR: Merge openjdk/jdk:master
In-Reply-To: <9v_Nzt6AEhWCSHWLXToKDPonVNRO4mP61zzxnSY5l38=.10c4838a-3088-4a6d-82bc-41039ff12eb5@github.com>
References: <9v_Nzt6AEhWCSHWLXToKDPonVNRO4mP61zzxnSY5l38=.10c4838a-3088-4a6d-82bc-41039ff12eb5@github.com>
Message-ID: 

On Wed, 8 Apr 2020 12:06:00 GMT, David Simms  wrote:

> Merge jdk-15+16 from master

This pull request has now been integrated.

Changeset: 0c52cfec
Author:    David Simms 
URL:       https://git.openjdk.java.net/valhalla/commit/0c52cfec
Stats:     8 lines in 3 files changed: 0 ins; 0 del; 8 mod

Remove whitespace/tabs

-------------

PR: https://git.openjdk.java.net/valhalla/pull/15

From thartmann at openjdk.java.net  Wed Apr 29 11:16:58 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 29 Apr 2020 11:16:58 GMT
Subject: [lworld] RFR: 8244092: [lworld] TestC2CCalls segfaults in
 frame::sender_for_compiled_frame with ZGC
Message-ID: <5lVvMNu9tI7C9uBtoBUxX4sY08N7kd0tP1VF264WGDk=.4a7c72a0-341f-472d-a56f-232dcdb383a8@github.com>

Stack slot containing real_frame_size is trashed by ZCG barrier code in scalarized entry of C1 compiled code. As a
result, we crash during stack walking. We should re-set it before jumping to the verified entry. Also refactored the
related code and added an assert to catch this.

-------------

Commit messages:
 - 8244092: [lworld] TestC2CCalls segfaults in frame::sender_for_compiled_frame with ZGC

Changes: https://git.openjdk.java.net/valhalla/pull/31/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/31/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244092
  Stats: 73 lines in 3 files changed: 28 ins; 40 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/31/head:pull/31

PR: https://git.openjdk.java.net/valhalla/pull/31

From sadayapalam at openjdk.java.net  Thu Apr 30 04:45:23 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 30 Apr 2020 04:45:23 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and deriving
 the reference projection
Message-ID: 

Hello Maurizio & Jim,

    May I request you to please review this patch for valhalla inline types support
under the new scheme ? TIA.

I.   What does this patch do?
II.  What can be skipped in the review?
III. Recommended order for review.
IV.  Known problems, limitations and deferred tasks.
V.   Report to language designers on open problems.

I. What does this patch do:

    - From every inline class declaration V, derive two classes V and V.ref
    - These two are subtypes at the VM level, but are related (only) by inline
      widening conversion and narrowing conversion at the language level.
    - The two types have the same fields and methods with the same shape and
      accessibility rules.
    - Add source level support for V.ref and V.val notation.
    - Get rid of the experimental support for generics over values. Until we
      figure out the full story with generics and inlines, carrying along this
      experimental support is becoming untenable/unsustainable.
    - Get rid of the experimental support added for noncovariant value arrays
    - Get rid of LW2's "Nullable Projections" including the V? syntax

II. These files can be skipped as they simply revert change and align
    with origin/master: (roll back V and V? nullable projections of LW2)

    JavacParser.java
    AttrContext.java
    JCTree.java
    Pretty.java
    Printer.java
    RichDiagnosticsFormatter.java
    TaskFactory.java
    TreeCopier.java
    TypePrinter.java

III. Recommended order for review:

    - Type.java, Symbol.java

            Look at the new internal APIs to query/compute various projections.
            Every class type, class symbol, method and field support an API
            to return the "other" projection i.e its doppleganger in the alternate
            universe.

            Most crucially ClassSymbol.referenceProjection()

    - Attr.java:

            Source support for .ref/.val

    - MemberEnter.java:
    - TypeEnter.java:
    - TransTypes.java:

            Co-evolve V.val and V.ref in lock step (also TransValues.java)

    - TransValues.java:

            Fold all V.ref.member accesses to ((V) V.ref).member access.

    - Resolve.java:

            Changes to make sure method look up works OK in a world where values are islands.

    - Types.java:
  
            Implement inline widening/narrowing relationship.

    - ProjectionRelationsTest.java:

            Verify all relationships between V and V.ref and V[] and V.ref[]

    - ClassWriter.java:
            
            Dual class generation scheme with subtyping relationship at the binary/VM level.

    - ClassReader.java:

            Merge the dual classes back, sever the subtyping relationship and make
            them operate as a pair of classes that can convert to each other.

    - New tests:
    
            Most importantly ProjectionRelationsTest.java

    - Other files.

 
IV. There are many known issues that have been deliberately deferred to a later iteration:

    - With Brian's consent I am using a simpler translation strategy than what is
      outlined in the SoV documents. These are good enough for now, but when
      VBC migration is undertaken, will have to enhanced.
    - No support for ref-default and val-default classes yet.
    - No support for class hierarchy sealing.
    - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
    - Handling of .ref and .val is quick and dirty; Need revisit.
    - The nest mate related attributes are not fully properly emitted as of now
    - Need to verify that attributes from V are not carried over inadvertantly to
      V$ref.class
    - Class hierarchy walking in a world where inline types are islands calls for
      a type switch. I have done this only in places uncovered by existing tests.
      We need to go through various utility methods (similar to what is done in
      Symbol.java and Resolve.java) to make sure these changes are consistently
      applied.
    - Diamond inference with value classes crashes now (implementation creates factory
      methods, projections are missing and need to be created)


V. Problems in the interplay of inlines types with generics and inference:

    Removing the experimental support for generics over values results in several
constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
not compiling anymore.

    These expose some issues that feed into the language design. We need to evolve
a short term answer (so that the JDK components tests that are impacted don't get
blocked) and a long term one (the real solution)

Here is a snippet that captures these problems:

import java.util.Arrays;

interface I {}

public inline class X implements I {

    int x = 10;

    void problem_01() {
        X [] a1 = new X[0];
        X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
      
/*
error: incompatible types: inference variable T has incompatible bounds
        X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
                                         ^
    lower bounds: X,Object
    lower bounds: X$ref
  where T,U are type-variables:
    T extends Object declared in method copyOf(U[],int,Class)
    U extends Object declared in method copyOf(U[],int,Class)
1 error
*/
    }

    void foo(Class p) {}

    void problem_02() {
        foo(X.class);
/*
error: incompatible types: Class cannot be converted to Class
        foo(X.class);
*/
    }

    String data() {
        return null;
    }

    // Problem: 3, we infer a stream of X.ref's causing
    // the method reference to not type check.
    void unbound_lookup_with_projected_receiver() {
        X [] a = new X[0];
        Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
/*
error: incompatible types: invalid method reference
        Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
                             ^
    method data in class X cannot be applied to given types
      required: no arguments
      found:    X$ref
      reason: actual and formal argument lists differ in length
*/
    }

    void problem_04() {
/*
    test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
    Unsafe has been deprecated and marked for removal
            U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
             ^
/home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
valueHeaderSize in class Unsafe cannot be applied to given types;
            U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
                                         ^
  required: Class
  found:    Class
  reason: inference variable V has incompatible bounds
    equality constraints: Value2
    lower bounds: Object
  where V is a type-variable:
    V extends Object declared in method valueHeaderSize(Class)
*/
    }

    void problem_05() {
/*
test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class and
Class
        boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
                                                                         ^
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
*/
    }

    public static void main(String [] args) {
    }
}

-------------

Commit messages:
 - Fix trailing white spaces
 - 8237072: [lworld] Add support for denoting and deriving the reference projection
 - 8237072: [lworld] Add support for denoting and deriving the reference projection

Changes: https://git.openjdk.java.net/valhalla/pull/32/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/32/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8237072
  Stats: 1405 lines in 53 files changed: 1003 ins; 253 del; 149 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/32/head:pull/32

PR: https://git.openjdk.java.net/valhalla/pull/32

From sadayapalam at openjdk.java.net  Thu Apr 30 07:40:34 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 30 Apr 2020 07:40:34 GMT
Subject: [lworld] [Rev 01] RFR: 8243623: [lworld] Syntax and other
 mechanical changes in langtools tests for JDK-8237072
In-Reply-To: 
References: 
Message-ID: 

> Jim,
> 
> May I request you to review these changes to langtools tests that anticipate and
> align with JDK-8237072 ? These changes are mechanical in nature and I decided it
> is best to separate them from the RFR for JDK-8237072 itself to help create sharper
> focus on the important pieces there. (Non-mechanical meaningful test changes with
> be included in that RFR itself)
> 
> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
> refer to the reference projection of a value type V and its value projection.
> The old syntax of V? is withdrawn. This change also has class file implications
> where the descriptor/signature encodings will now start mentioning $ref in the
> class pool entries. Also every inline type results in two class files now
> one for each projection - with the reference projection class being the superclass
> of the inline class.
> 
> I'll push them after your review and after JDK-8237072 itself is pushed.
> Thanks in advance.

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Incorporated review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/29/files
  - new: https://git.openjdk.java.net/valhalla/pull/29/files/b9ef3d73..686b791e

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/29/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/29/webrev.00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/29/head:pull/29

PR: https://git.openjdk.java.net/valhalla/pull/29

From rwestrel at redhat.com  Thu Apr 30 07:57:52 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 30 Apr 2020 09:57:52 +0200
Subject: [lworld] RFR: 8244092: [lworld] TestC2CCalls segfaults in
 frame::sender_for_compiled_frame with ZGC
In-Reply-To: <5lVvMNu9tI7C9uBtoBUxX4sY08N7kd0tP1VF264WGDk=.4a7c72a0-341f-472d-a56f-232dcdb383a8@github.com>
References: <5lVvMNu9tI7C9uBtoBUxX4sY08N7kd0tP1VF264WGDk=.4a7c72a0-341f-472d-a56f-232dcdb383a8@github.com>
Message-ID: <87ftcl8kxr.fsf@redhat.com>


> Stack slot containing real_frame_size is trashed by ZCG barrier code in scalarized entry of C1 compiled code. As a
> result, we crash during stack walking. We should re-set it before jumping to the verified entry. Also refactored the
> related code and added an assert to catch this.

Ok.

Roland.


From tobias.hartmann at oracle.com  Thu Apr 30 08:01:44 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 30 Apr 2020 10:01:44 +0200
Subject: [lworld] RFR: 8244092: [lworld] TestC2CCalls segfaults in
 frame::sender_for_compiled_frame with ZGC
In-Reply-To: <87ftcl8kxr.fsf@redhat.com>
References: <5lVvMNu9tI7C9uBtoBUxX4sY08N7kd0tP1VF264WGDk=.4a7c72a0-341f-472d-a56f-232dcdb383a8@github.com>
 <87ftcl8kxr.fsf@redhat.com>
Message-ID: <8ffe3a27-ac04-ad2a-97b6-3dc97cf9db75@oracle.com>

Thanks Roland!

Best regards,
Tobias

On 30.04.20 09:57, Roland Westrelin wrote:
> 
>> Stack slot containing real_frame_size is trashed by ZCG barrier code in scalarized entry of C1 compiled code. As a
>> result, we crash during stack walking. We should re-set it before jumping to the verified entry. Also refactored the
>> related code and added an assert to catch this.
> 
> Ok.
> 
> Roland.
> 

From thartmann at openjdk.java.net  Thu Apr 30 08:13:26 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 30 Apr 2020 08:13:26 GMT
Subject: [Integrated] [lworld] RFR: 8244092: [lworld] TestC2CCalls
 segfaults in frame::sender_for_compiled_frame with ZGC
In-Reply-To: <5lVvMNu9tI7C9uBtoBUxX4sY08N7kd0tP1VF264WGDk=.4a7c72a0-341f-472d-a56f-232dcdb383a8@github.com>
References: <5lVvMNu9tI7C9uBtoBUxX4sY08N7kd0tP1VF264WGDk=.4a7c72a0-341f-472d-a56f-232dcdb383a8@github.com>
Message-ID: 

On Wed, 29 Apr 2020 11:10:51 GMT, Tobias Hartmann  wrote:

> Stack slot containing real_frame_size is trashed by ZCG barrier code in scalarized entry of C1 compiled code. As a
> result, we crash during stack walking. We should re-set it before jumping to the verified entry. Also refactored the
> related code and added an assert to catch this.

This pull request has now been integrated.

Changeset: 75027977
Author:    Tobias Hartmann 
URL:       https://git.openjdk.java.net/valhalla/commit/75027977
Stats:     70 lines in 3 files changed: 37 ins; 25 del; 8 mod

8244092: [lworld] TestC2CCalls segfaults in frame::sender_for_compiled_frame with ZGC

-------------

PR: https://git.openjdk.java.net/valhalla/pull/31

From thartmann at openjdk.java.net  Thu Apr 30 16:09:33 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 30 Apr 2020 16:09:33 GMT
Subject: [lworld] RFR: 8243625: [lworld] Co-evolve hotspot-compiler tests
 along with JDK-8237072
In-Reply-To: 
References: <2jYS17UipWQiTMk13r-p6vALummTyBPG_sVhjQZODUw=.9dd3d917-37c8-45fd-9542-0102609b285f@github.com>
 
Message-ID: 

On Mon, 27 Apr 2020 06:16:15 GMT, Tobias Hartmann  wrote:

>> Tobias,
>> 
>> May I request you to review these changes to hotspot-compiler tests that anticipate
>> and align with JDK-8237072 ? These changes are mechanical in nature and I decided it
>> is best to separate them from the RFR for JDK-8237072 itself to help create sharper
>> focus on the important pieces there.
>> 
>> JDK-8237072 adds supports for the new syntax notation of V.ref and V.val to
>> refer to the reference projection of a value type V and its value projection.
>> The old syntax of V? is withdrawn. This change also has class file implications
>> where the descriptor/signature encodings will now start mentioning $ref in the
>> class pool entries. Also every inline type results in two class files now
>> one for each projection - with the reference projection class being the superclass
>> of the inline class.
>> 
>> I'll push them after your review and after JDK-8237072 itself is pushed.
>> Thanks in advance.
>
> Thanks for fixing. Looks good to me!

Here are some more adjustments needed:
[compilerTestFixes.txt](https://github.com/openjdk/valhalla/files/4558969/compilerTestFixes.txt)

All the remaining failures are JIT bugs. I'll work on them next.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/30

From mcimadamore at openjdk.java.net  Thu Apr 30 17:10:52 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 30 Apr 2020 17:10:52 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Apr 2020 04:27:10 GMT, Srikanth Adayapalam  wrote:

> Hello Maurizio & Jim,
> 
>     May I request you to please review this patch for valhalla inline types support
> under the new scheme ? TIA.
> 
> I.   What does this patch do?
> II.  What can be skipped in the review?
> III. Recommended order for review.
> IV.  Known problems, limitations and deferred tasks.
> V.   Report to language designers on open problems.
> 
> I. What does this patch do:
> 
>     - From every inline class declaration V, derive two classes V and V.ref
>     - These two are subtypes at the VM level, but are related (only) by inline
>       widening conversion and narrowing conversion at the language level.
>     - The two types have the same fields and methods with the same shape and
>       accessibility rules.
>     - Add source level support for V.ref and V.val notation.
>     - Get rid of the experimental support for generics over values. Until we
>       figure out the full story with generics and inlines, carrying along this
>       experimental support is becoming untenable/unsustainable.
>     - Get rid of the experimental support added for noncovariant value arrays
>     - Get rid of LW2's "Nullable Projections" including the V? syntax
> 
> II. These files can be skipped as they simply revert change and align
>     with origin/master: (roll back V and V? nullable projections of LW2)
> 
>     JavacParser.java
>     AttrContext.java
>     JCTree.java
>     Pretty.java
>     Printer.java
>     RichDiagnosticsFormatter.java
>     TaskFactory.java
>     TreeCopier.java
>     TypePrinter.java
> 
> III. Recommended order for review:
> 
>     - Type.java, Symbol.java
> 
>             Look at the new internal APIs to query/compute various projections.
>             Every class type, class symbol, method and field support an API
>             to return the "other" projection i.e its doppleganger in the alternate
>             universe.
> 
>             Most crucially ClassSymbol.referenceProjection()
> 
>     - Attr.java:
> 
>             Source support for .ref/.val
> 
>     - MemberEnter.java:
>     - TypeEnter.java:
>     - TransTypes.java:
> 
>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
> 
>     - TransValues.java:
> 
>             Fold all V.ref.member accesses to ((V) V.ref).member access.
> 
>     - Resolve.java:
> 
>             Changes to make sure method look up works OK in a world where values are islands.
> 
>     - Types.java:
>   
>             Implement inline widening/narrowing relationship.
> 
>     - ProjectionRelationsTest.java:
> 
>             Verify all relationships between V and V.ref and V[] and V.ref[]
> 
>     - ClassWriter.java:
>             
>             Dual class generation scheme with subtyping relationship at the binary/VM level.
> 
>     - ClassReader.java:
> 
>             Merge the dual classes back, sever the subtyping relationship and make
>             them operate as a pair of classes that can convert to each other.
> 
>     - New tests:
>     
>             Most importantly ProjectionRelationsTest.java
> 
>     - Other files.
> 
>  
> IV. There are many known issues that have been deliberately deferred to a later iteration:
> 
>     - With Brian's consent I am using a simpler translation strategy than what is
>       outlined in the SoV documents. These are good enough for now, but when
>       VBC migration is undertaken, will have to enhanced.
>     - No support for ref-default and val-default classes yet.
>     - No support for class hierarchy sealing.
>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>     - Handling of .ref and .val is quick and dirty; Need revisit.
>     - The nest mate related attributes are not fully properly emitted as of now
>     - Need to verify that attributes from V are not carried over inadvertantly to
>       V$ref.class
>     - Class hierarchy walking in a world where inline types are islands calls for
>       a type switch. I have done this only in places uncovered by existing tests.
>       We need to go through various utility methods (similar to what is done in
>       Symbol.java and Resolve.java) to make sure these changes are consistently
>       applied.
>     - Diamond inference with value classes crashes now (implementation creates factory
>       methods, projections are missing and need to be created)
> 
> 
> V. Problems in the interplay of inlines types with generics and inference:
> 
>     Removing the experimental support for generics over values results in several
> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
> not compiling anymore.
> 
>     These expose some issues that feed into the language design. We need to evolve
> a short term answer (so that the JDK components tests that are impacted don't get
> blocked) and a long term one (the real solution)
> 
> Here is a snippet that captures these problems:
> import java.util.Arrays;
> 
> interface I {}
> 
> public inline class X implements I {
> 
>     int x = 10;
> 
>     void problem_01() {
>         X [] a1 = new X[0];
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>       
> /*
> error: incompatible types: inference variable T has incompatible bounds
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>                                          ^
>     lower bounds: X,Object
>     lower bounds: X$ref
>   where T,U are type-variables:
>     T extends Object declared in method copyOf(U[],int,Class)
>     U extends Object declared in method copyOf(U[],int,Class)
> 1 error
> */
>     }
> 
>     void foo(Class p) {}
> 
>     void problem_02() {
>         foo(X.class);
> /*
> error: incompatible types: Class cannot be converted to Class
>         foo(X.class);
> */
>     }
> 
>     String data() {
>         return null;
>     }
> 
>     // Problem: 3, we infer a stream of X.ref's causing
>     // the method reference to not type check.
>     void unbound_lookup_with_projected_receiver() {
>         X [] a = new X[0];
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
> /*
> error: incompatible types: invalid method reference
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>                              ^
>     method data in class X cannot be applied to given types
>       required: no arguments
>       found:    X$ref
>       reason: actual and formal argument lists differ in length
> */
>     }
> 
>     void problem_04() {
> /*
>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>     Unsafe has been deprecated and marked for removal
>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>              ^
> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
> valueHeaderSize in class Unsafe cannot be applied to given types;
>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>                                          ^
>   required: Class
>   found:    Class
>   reason: inference variable V has incompatible bounds
>     equality constraints: Value2
>     lower bounds: Object
>   where V is a type-variable:
>     V extends Object declared in method valueHeaderSize(Class)
> */
>     }
> 
>     void problem_05() {
> /*
> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class and
> Class
>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>                                                                          ^
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
> */
>     }
> 
>     public static void main(String [] args) {
>     }
> }

Overall this looks very good. Note that changes to dot apply cleanly on latest lworld branch, so you might need some
rebasing.

I'm impressed at how much we could get done with relatively small set of changes in the core classes. As discussed
offline, my mine gripe with the proposed implementation approach is that, I think, it distorts the user model view a
little. In my mental model:

* there is ONE class in the langauge; the class might be `inline` or not. If it's inline, might be ref-default or not.
* Every type defines a reference projection. If a type is a type that comes from an ordinary class, then the reference
  projection of that type is the type itself.
* inline classes do not give birth to a single type (like normal classes do - e.g. think of` j.l.String`). But they can
  give birth to two distinct type (pretty much like a generic class can give birth to an infinite set of types)
* to help translation, a single inline class will be translated into a ref/val  classes pair - which means a single
  inline class will give rise to *two* runtime types

In other words, I think that appealing with symmetry with the generic use case, where a single declared class give rise
to many types might be cleaner in the long run than having two declared classes (as in the proposed implementation).

This choice surfaces up in a bunch of places where we have relationship which are seemingly defined on symbols (e.g.
`Symbol::outermostClass`, and friends) in which we have to always ask first whether the class symbol we are dealing
with is a *reference* class symbol, and, if not, go back to that. This choice also backfires when it comes to keep the
members of the two fictional symbols in sync - so there's a number of places where we have to update the scope of one
class in the same way we update the scope of the other class.

Note: all these things are not blockers - but to me they might be signs that some alternate implementation might be
possible.

The current approach will require adjustments in places where symbols are expected, but something like `V.ref` is
found - for instance I put together this fictional example:

package a;

import a.V.ref;

inline class V {
   int x = 0;
}

and I got this:

error: import requires canonical name for V$ref
import a.V.ref;
          ^
which seems a bit confusing (more generally I note that the compiler is often emitting V$ref and V$val which should be
normalized to the syntax used by developers - e.g. dropping the dollar sign).

I'm afraid that when the time will come and we will start looking at the annotation processing machinery, the choice of
having two symbols (hence two `Elements`) for the `val` and `ref` projection might become untenable (since at that
point I believe the annotation processor user would expect to get two different `TypeMirror`s for the projections which
point to the same underlying declared `Element`). Since `Element` is 1-1 with `Symbol`, this might become a problem.

On a different topic, I noted something on name resolution:

inline class V {
   int y = 52;

   static class ref {
       int x;
   }

   void m(V.ref vref) {
       vref.x = 12;
   }
}
Which gives:

error: cannot find symbol
       vref.x = 12;
           ^
  symbol:   variable x
  location: variable vref of type V$ref
In other words, the compiler is always resolving `.ref` to a projection - which is fine for now, but there's a deeper
question as to whether we're ok with this behavior and if we want to even allow defining a nested class called `ref` or
`val` inside an inline class.

Another thing I noted when playing with ref projection is that we don't seem to be getting NPE at runtime when passing
nulls back and forth:

static inline class V {
    int y = 52;
}

static void m(V.ref vr) {
    V v = vr;
}

public static void main(String[] args) {
     m(null);
}

This compiles and runs correctly, while I'd expect an NPE to be thrown inside `m`. I've inspected the bytecode:

         0: aload_0
         1: checkcast     #7                  // class "QV;"
         4: astore_1
         5: return
So, this might  be an issue with the VM not doing the right thing with the cast (e.g. not ruling nulls out) - and
ultimately related to this discussion:

https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001288.html

We should check as to whether this behavior is expected, and if it should be rectified; or whether we should add an NPE
check on our side.

This is all I have for now.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32

From mcimadamore at openjdk.java.net  Thu Apr 30 17:36:09 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 30 Apr 2020 17:36:09 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Apr 2020 04:27:10 GMT, Srikanth Adayapalam  wrote:

> Hello Maurizio & Jim,
> 
>     May I request you to please review this patch for valhalla inline types support
> under the new scheme ? TIA.
> 
> I.   What does this patch do?
> II.  What can be skipped in the review?
> III. Recommended order for review.
> IV.  Known problems, limitations and deferred tasks.
> V.   Report to language designers on open problems.
> 
> I. What does this patch do:
> 
>     - From every inline class declaration V, derive two classes V and V.ref
>     - These two are subtypes at the VM level, but are related (only) by inline
>       widening conversion and narrowing conversion at the language level.
>     - The two types have the same fields and methods with the same shape and
>       accessibility rules.
>     - Add source level support for V.ref and V.val notation.
>     - Get rid of the experimental support for generics over values. Until we
>       figure out the full story with generics and inlines, carrying along this
>       experimental support is becoming untenable/unsustainable.
>     - Get rid of the experimental support added for noncovariant value arrays
>     - Get rid of LW2's "Nullable Projections" including the V? syntax
> 
> II. These files can be skipped as they simply revert change and align
>     with origin/master: (roll back V and V? nullable projections of LW2)
> 
>     JavacParser.java
>     AttrContext.java
>     JCTree.java
>     Pretty.java
>     Printer.java
>     RichDiagnosticsFormatter.java
>     TaskFactory.java
>     TreeCopier.java
>     TypePrinter.java
> 
> III. Recommended order for review:
> 
>     - Type.java, Symbol.java
> 
>             Look at the new internal APIs to query/compute various projections.
>             Every class type, class symbol, method and field support an API
>             to return the "other" projection i.e its doppleganger in the alternate
>             universe.
> 
>             Most crucially ClassSymbol.referenceProjection()
> 
>     - Attr.java:
> 
>             Source support for .ref/.val
> 
>     - MemberEnter.java:
>     - TypeEnter.java:
>     - TransTypes.java:
> 
>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
> 
>     - TransValues.java:
> 
>             Fold all V.ref.member accesses to ((V) V.ref).member access.
> 
>     - Resolve.java:
> 
>             Changes to make sure method look up works OK in a world where values are islands.
> 
>     - Types.java:
>   
>             Implement inline widening/narrowing relationship.
> 
>     - ProjectionRelationsTest.java:
> 
>             Verify all relationships between V and V.ref and V[] and V.ref[]
> 
>     - ClassWriter.java:
>             
>             Dual class generation scheme with subtyping relationship at the binary/VM level.
> 
>     - ClassReader.java:
> 
>             Merge the dual classes back, sever the subtyping relationship and make
>             them operate as a pair of classes that can convert to each other.
> 
>     - New tests:
>     
>             Most importantly ProjectionRelationsTest.java
> 
>     - Other files.
> 
>  
> IV. There are many known issues that have been deliberately deferred to a later iteration:
> 
>     - With Brian's consent I am using a simpler translation strategy than what is
>       outlined in the SoV documents. These are good enough for now, but when
>       VBC migration is undertaken, will have to enhanced.
>     - No support for ref-default and val-default classes yet.
>     - No support for class hierarchy sealing.
>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>     - Handling of .ref and .val is quick and dirty; Need revisit.
>     - The nest mate related attributes are not fully properly emitted as of now
>     - Need to verify that attributes from V are not carried over inadvertantly to
>       V$ref.class
>     - Class hierarchy walking in a world where inline types are islands calls for
>       a type switch. I have done this only in places uncovered by existing tests.
>       We need to go through various utility methods (similar to what is done in
>       Symbol.java and Resolve.java) to make sure these changes are consistently
>       applied.
>     - Diamond inference with value classes crashes now (implementation creates factory
>       methods, projections are missing and need to be created)
> 
> 
> V. Problems in the interplay of inlines types with generics and inference:
> 
>     Removing the experimental support for generics over values results in several
> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
> not compiling anymore.
> 
>     These expose some issues that feed into the language design. We need to evolve
> a short term answer (so that the JDK components tests that are impacted don't get
> blocked) and a long term one (the real solution)
> 
> Here is a snippet that captures these problems:
> import java.util.Arrays;
> 
> interface I {}
> 
> public inline class X implements I {
> 
>     int x = 10;
> 
>     void problem_01() {
>         X [] a1 = new X[0];
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>       
> /*
> error: incompatible types: inference variable T has incompatible bounds
>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>                                          ^
>     lower bounds: X,Object
>     lower bounds: X$ref
>   where T,U are type-variables:
>     T extends Object declared in method copyOf(U[],int,Class)
>     U extends Object declared in method copyOf(U[],int,Class)
> 1 error
> */
>     }
> 
>     void foo(Class p) {}
> 
>     void problem_02() {
>         foo(X.class);
> /*
> error: incompatible types: Class cannot be converted to Class
>         foo(X.class);
> */
>     }
> 
>     String data() {
>         return null;
>     }
> 
>     // Problem: 3, we infer a stream of X.ref's causing
>     // the method reference to not type check.
>     void unbound_lookup_with_projected_receiver() {
>         X [] a = new X[0];
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
> /*
> error: incompatible types: invalid method reference
>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>                              ^
>     method data in class X cannot be applied to given types
>       required: no arguments
>       found:    X$ref
>       reason: actual and formal argument lists differ in length
> */
>     }
> 
>     void problem_04() {
> /*
>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>     Unsafe has been deprecated and marked for removal
>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>              ^
> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
> valueHeaderSize in class Unsafe cannot be applied to given types;
>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>                                          ^
>   required: Class
>   found:    Class
>   reason: inference variable V has incompatible bounds
>     equality constraints: Value2
>     lower bounds: Object
>   where V is a type-variable:
>     V extends Object declared in method valueHeaderSize(Class)
> */
>     }
> 
>     void problem_05() {
> /*
> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class and
> Class
>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>                                                                          ^
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
> */
>     }
> 
>     public static void main(String [] args) {
>     }
> }

Added some specific file comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 441:

> 440:     public Symbol referenceProjection() {
> 441:         return null;
> 442:     }

How much would it help to have this return `this` ? It seems to me that there a lot of `if  ...
referenceProjection()` going around.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1197:

> 1196:         public Type valueProjection() {
> 1197:             if (!isReferenceProjection() || projection !=  null)
> 1198:                 return projection;

Question here - since you have two symbols, getting a reference projection and value projection shouldn't be as simple
as doing `tsym.XYZprojection().type` ? Why do we need to create new types here?

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1760:

> 1759:                     if (isValue(t)) {
> 1760:                         // (s) Value ? == (s) Value.ref
> 1761:                         t = t.referenceProjection();

I didn't get these comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2194:

> 2193:
> 2194:                // No man may be an island, but the bell tolls for a value.
> 2195:                 if (isValue(t))

:-)

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 2605:

> 2604:         readClassFileInternal(c);
> 2605:         if (c.isValue()) {
> 2606:             /* http://cr.openjdk.java.net/~briangoetz/valhalla/sov/04-translation.html

This approach leads to very compact code - but in javac-land it's a bit odd that we have to prune away members at this
late stage. I wonder if some of the pruning could happen earlier (e.g. in TransValues?)

test/langtools/tools/javac/valhalla/lworld-values/InferredValueParameterizationTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

The golden file seems to still be there  - even though this is now a positive test

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3704:

> 3703: compiler.err.generic.parameterization.with.value.type=\
> 3704:     Inferred type {0} involves generic parameterization by an inline type
> 3705:

Do you have examples when this can happen? Or is this a leftover (in which case I think Check.java could be cleaned up
a bit)

test/langtools/tools/javac/valhalla/lworld-values/ProjectionRelationsTest.java line 1:

> 1: /*
> 2:  * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.

You might want to look at this test framework:

test/langtools/tools/lib/types/TypeHarness.java

An example of such a test is:

test/langtools/tools/javac/types/PrimitiveConversionTest.java

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32

From fparain at openjdk.java.net  Thu Apr 30 18:05:29 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 30 Apr 2020 18:05:29 GMT
Subject: [lworld] RFR: 8237072: [lworld] Add support for denoting and
 deriving the reference projection
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Apr 2020 17:32:59 GMT, Maurizio Cimadamore  wrote:

>> Hello Maurizio & Jim,
>> 
>>     May I request you to please review this patch for valhalla inline types support
>> under the new scheme ? TIA.
>> 
>> I.   What does this patch do?
>> II.  What can be skipped in the review?
>> III. Recommended order for review.
>> IV.  Known problems, limitations and deferred tasks.
>> V.   Report to language designers on open problems.
>> 
>> I. What does this patch do:
>> 
>>     - From every inline class declaration V, derive two classes V and V.ref
>>     - These two are subtypes at the VM level, but are related (only) by inline
>>       widening conversion and narrowing conversion at the language level.
>>     - The two types have the same fields and methods with the same shape and
>>       accessibility rules.
>>     - Add source level support for V.ref and V.val notation.
>>     - Get rid of the experimental support for generics over values. Until we
>>       figure out the full story with generics and inlines, carrying along this
>>       experimental support is becoming untenable/unsustainable.
>>     - Get rid of the experimental support added for noncovariant value arrays
>>     - Get rid of LW2's "Nullable Projections" including the V? syntax
>> 
>> II. These files can be skipped as they simply revert change and align
>>     with origin/master: (roll back V and V? nullable projections of LW2)
>> 
>>     JavacParser.java
>>     AttrContext.java
>>     JCTree.java
>>     Pretty.java
>>     Printer.java
>>     RichDiagnosticsFormatter.java
>>     TaskFactory.java
>>     TreeCopier.java
>>     TypePrinter.java
>> 
>> III. Recommended order for review:
>> 
>>     - Type.java, Symbol.java
>> 
>>             Look at the new internal APIs to query/compute various projections.
>>             Every class type, class symbol, method and field support an API
>>             to return the "other" projection i.e its doppleganger in the alternate
>>             universe.
>> 
>>             Most crucially ClassSymbol.referenceProjection()
>> 
>>     - Attr.java:
>> 
>>             Source support for .ref/.val
>> 
>>     - MemberEnter.java:
>>     - TypeEnter.java:
>>     - TransTypes.java:
>> 
>>             Co-evolve V.val and V.ref in lock step (also TransValues.java)
>> 
>>     - TransValues.java:
>> 
>>             Fold all V.ref.member accesses to ((V) V.ref).member access.
>> 
>>     - Resolve.java:
>> 
>>             Changes to make sure method look up works OK in a world where values are islands.
>> 
>>     - Types.java:
>>   
>>             Implement inline widening/narrowing relationship.
>> 
>>     - ProjectionRelationsTest.java:
>> 
>>             Verify all relationships between V and V.ref and V[] and V.ref[]
>> 
>>     - ClassWriter.java:
>>             
>>             Dual class generation scheme with subtyping relationship at the binary/VM level.
>> 
>>     - ClassReader.java:
>> 
>>             Merge the dual classes back, sever the subtyping relationship and make
>>             them operate as a pair of classes that can convert to each other.
>> 
>>     - New tests:
>>     
>>             Most importantly ProjectionRelationsTest.java
>> 
>>     - Other files.
>> 
>>  
>> IV. There are many known issues that have been deliberately deferred to a later iteration:
>> 
>>     - With Brian's consent I am using a simpler translation strategy than what is
>>       outlined in the SoV documents. These are good enough for now, but when
>>       VBC migration is undertaken, will have to enhanced.
>>     - No support for ref-default and val-default classes yet.
>>     - No support for class hierarchy sealing.
>>     - You can't do new V.ref() (V.ref is abstract) although SoV calls for it.
>>     - Handling of .ref and .val is quick and dirty; Need revisit.
>>     - The nest mate related attributes are not fully properly emitted as of now
>>     - Need to verify that attributes from V are not carried over inadvertantly to
>>       V$ref.class
>>     - Class hierarchy walking in a world where inline types are islands calls for
>>       a type switch. I have done this only in places uncovered by existing tests.
>>       We need to go through various utility methods (similar to what is done in
>>       Symbol.java and Resolve.java) to make sure these changes are consistently
>>       applied.
>>     - Diamond inference with value classes crashes now (implementation creates factory
>>       methods, projections are missing and need to be created)
>> 
>> 
>> V. Problems in the interplay of inlines types with generics and inference:
>> 
>>     Removing the experimental support for generics over values results in several
>> constructs that used to compile earlier (albeit only with -XDallowGenericsOverValues)
>> not compiling anymore.
>> 
>>     These expose some issues that feed into the language design. We need to evolve
>> a short term answer (so that the JDK components tests that are impacted don't get
>> blocked) and a long term one (the real solution)
>> 
>> Here is a snippet that captures these problems:
>> import java.util.Arrays;
>> 
>> interface I {}
>> 
>> public inline class X implements I {
>> 
>>     int x = 10;
>> 
>>     void problem_01() {
>>         X [] a1 = new X[0];
>>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>>       
>> /*
>> error: incompatible types: inference variable T has incompatible bounds
>>         X [] a2 = Arrays.copyOf(a1, a2.length, X[].class);
>>                                          ^
>>     lower bounds: X,Object
>>     lower bounds: X$ref
>>   where T,U are type-variables:
>>     T extends Object declared in method copyOf(U[],int,Class)
>>     U extends Object declared in method copyOf(U[],int,Class)
>> 1 error
>> */
>>     }
>> 
>>     void foo(Class p) {}
>> 
>>     void problem_02() {
>>         foo(X.class);
>> /*
>> error: incompatible types: Class cannot be converted to Class
>>         foo(X.class);
>> */
>>     }
>> 
>>     String data() {
>>         return null;
>>     }
>> 
>>     // Problem: 3, we infer a stream of X.ref's causing
>>     // the method reference to not type check.
>>     void unbound_lookup_with_projected_receiver() {
>>         X [] a = new X[0];
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>> /*
>> error: incompatible types: invalid method reference
>>         Arrays.stream(a).map(X::data).filter(p -> p != null).forEach(System.out::println);
>>                              ^
>>     method data in class X cannot be applied to given types
>>       required: no arguments
>>       found:    X$ref
>>       reason: actual and formal argument lists differ in length
>> */
>>     }
>> 
>>     void problem_04() {
>> /*
>>     test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:125: warning: [removal] putObject(Object,long,Object) in
>>     Unsafe has been deprecated and marked for removal
>>             U.putObject(v, off_o, List.of("Value1", "Value2", "Value3"));
>>              ^
>> /home/srikanth/valhalla/test/valhalla/test/hotspot/jtreg/runtime/valhalla/valuetypes/UnsafeTest.java:127: error: method
>> valueHeaderSize in class Unsafe cannot be applied to given types;
>>             U.putInt(v, off_v + off_i - U.valueHeaderSize(Value2.class), 999);
>>                                          ^
>>   required: Class
>>   found:    Class
>>   reason: inference variable V has incompatible bounds
>>     equality constraints: Value2
>>     lower bounds: Object
>>   where V is a type-variable:
>>     V extends Object declared in method valueHeaderSize(Class)
>> */
>>     }
>> 
>>     void problem_05() {
>> /*
>> test/hotspot/jtreg/compiler/valhalla/valuetypes/TestIntrinsics.java:119: error: incomparable types: Class and
>> Class
>>         boolean check2 = MyValue1.class.asIndirectType().getSuperclass() == MyValue1.ref.class;
>>                                                                          ^
>>   where CAP#1 is a fresh type-variable:
>>     CAP#1 extends Object super: MyValue1 from capture of ? super MyValue1
>> */
>>     }
>> 
>>     public static void main(String [] args) {
>>     }
>> }
>
> Added some specific file comments

I've tried to reproduce the checkcast issue mentioned by Mauricio with this code:
public class Test2 {
    static inline class V {
	int y = 52;
    }

    static void m(V.ref vr) {
	V v = vr;
    }

    public static void main(String[] args) {
	m(null);
    }
}
But I got an NPE where is was expected:
$ ./build/pull32/jdk/bin/java Test2
Exception in thread "main" java.lang.NullPointerException
	at Test2.m(Test2.java:7)
	at Test2.main(Test2.java:11)

-------------

PR: https://git.openjdk.java.net/valhalla/pull/32