From fw at deneb.enyo.de Sun Mar 1 17:18:50 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 01 Mar 2020 18:18:50 +0100 Subject: RFR [lworld] 8239929: Object.newIdentity() replacement for new Object() In-Reply-To: (Roger Riggs's message of "Tue, 25 Feb 2020 14:20:25 -0500") References: Message-ID: <875zfongcl.fsf@mid.deneb.enyo.de> * Roger Riggs: > Please review the static factory of an IdentityObject to replace > "new Object()" as mentioned in [1]. Might it be beneficial to add this method to the Objects class, to reduce the likelyhood of clashes? From tobias.hartmann at oracle.com Mon Mar 2 09:41:30 2020 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 02 Mar 2020 09:41:30 +0000 Subject: hg: valhalla/valhalla: 8240177: [lworld] C2: Use macro nodes for subtype checks Message-ID: <202003020941.0229fUaj026244@aojmv0008.oracle.com> Changeset: 62830cc42bfe Author: thartmann Date: 2020-03-02 10:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/62830cc42bfe 8240177: [lworld] C2: Use macro nodes for subtype checks ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciKlass.hpp ! src/hotspot/share/ci/ciObjArrayKlass.hpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subtypenode.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNullableArrays.java From david.simms at oracle.com Mon Mar 2 15:09:23 2020 From: david.simms at oracle.com (David Simms) Date: Mon, 2 Mar 2020 16:09:23 +0100 Subject: RFR (XS) 8240313: [lworld] valhalla/valuetypes/StaticInitFactoryTest.java NPE after merge Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8240313 Webrev: http://cr.openjdk.java.net/~dsimms/valhalla/8240313/webrev0/ Looks like an issue from merging. Alternative fix might to remove the assert: assert(!MethodHandleNatives.isCallerSensitive(ctor)); // must not be caller-sensitive And use findBoundCallerLookup ? Cheers /Mr. Simms From mandy.chung at oracle.com Mon Mar 2 18:08:50 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 Mar 2020 10:08:50 -0800 Subject: RFR (XS) 8240313: [lworld] valhalla/valuetypes/StaticInitFactoryTest.java NPE after merge In-Reply-To: References: Message-ID: <76b2260f-539e-f681-4928-ab858812fff9@oracle.com> Hi David, On 3/2/20 7:09 AM, David Simms wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240313 > > Webrev: http://cr.openjdk.java.net/~dsimms/valhalla/8240313/webrev0/ > Thanks for looking into this.?? This fix is fine.?? A static init factory should not be caller-sensitive like the object constructor. Mandy From Roger.Riggs at oracle.com Mon Mar 2 20:18:50 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 2 Mar 2020 15:18:50 -0500 Subject: RFR [lworld] 8239929: Object.newIdentity() replacement for new Object() In-Reply-To: <875zfongcl.fsf@mid.deneb.enyo.de> References: <875zfongcl.fsf@mid.deneb.enyo.de> Message-ID: To keep it simple and localized, the factory method is in the IdentityObject interface. The direct replacement is: ??????? "new Object();" -> "IdentityObject.newIdentity();" It may be slightly less convenient than Object.newIdentity but will avoid bleading identity based operations into Object. If/when it is moved to an nested class of object, it won't take much editing and will look like: ??????? "Identity.newIdentity();" // maybe with a specific import Making the change is mostly smooth but there will be issues with bootstrapping in javac and asm. And there's a runtime error to find/fix also: Caused by: java.lang.ClassCastException: Cannot cast java.lang.IdentityObject$1 to java.lang.invoke.BoundMethodHandle$SpeciesData Also spotted are uses with Annonymous inner classes: ???? new Object() {...}; When deprecated, this will be part of the source incompatibile migration. BTW, are there any restrictions on AICs being inline classes or does that just work? Patch below or webrev: http://cr.openjdk.java.net/~rriggs/webrev-object-newinstance-8239929-1/ Thanks, Roger diff a/src/java.base/share/classes/java/lang/IdentityObject.java b/src/java.base/share/classes/java/lang/IdentityObject.java --- a/src/java.base/share/classes/java/lang/IdentityObject.java +++ b/src/java.base/share/classes/java/lang/IdentityObject.java @@ -25,9 +25,22 @@ package java.lang; /** * A restricted interface implemented by all identity objects. - * @since 1.14 + * @since Valhalla */ public interface IdentityObject { + /** + * Returns a new Object implementing the {@code IdentityObject} interface. + * The object is a unique {@link IdentityObject} suitable for all purposes + * for which {@code new Object{}} was used including synchronization, + * mutexes and unique placeholders. + * + * @return a new Object implementing the IdentityObject interface + * @since Valhalla + */ + static IdentityObject newIdentity() { + // Return a new instance of an anonymous inner class. + return new IdentityObject() { }; + } } diff a/src/java.base/share/classes/java/lang/Object.java b/src/java.base/share/classes/java/lang/Object.java --- a/src/java.base/share/classes/java/lang/Object.java +++ b/src/java.base/share/classes/java/lang/Object.java @@ -38,10 +38,12 @@ */ public class Object { /** * Constructs a new object. + * @apiNote {@link IdentityObject#newIdentity new IdentityObject.newIdentity()} + * should be used instead of {@code new Object()}. */ @HotSpotIntrinsicCandidate public Object() {} From harold.seigel at oracle.com Mon Mar 2 20:26:18 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Mon, 02 Mar 2020 20:26:18 +0000 Subject: hg: valhalla/valhalla: Summary: clean up checks if class loader data's loader is the boot loader Message-ID: <202003022026.022KQJ5l011397@aojmv0008.oracle.com> Changeset: 0c8de4cd12e5 Author: hseigel Date: 2020-03-02 20:25 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0c8de4cd12e5 Summary: clean up checks if class loader data's loader is the boot loader Reviewed-by: lfoltan, mchung ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp ! src/hotspot/share/classfile/dictionary.cpp ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/symbolTable.cpp From srikanth.adayapalam at oracle.com Tue Mar 3 07:40:40 2020 From: srikanth.adayapalam at oracle.com (srikanth.adayapalam at oracle.com) Date: Tue, 03 Mar 2020 07:40:40 +0000 Subject: hg: valhalla/valhalla: lworld: Fix for (2 out of 3) test failures resulting from merge. Message-ID: <202003030740.0237efir001636@aojmv0008.oracle.com> Changeset: 773e31502e8b Author: sadayapalam Date: 2020-03-03 13:10 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/773e31502e8b lworld: Fix for (2 out of 3) test failures resulting from merge. ! test/langtools/tools/javac/valhalla/lworld-values/CheckFeatureGate1.out ! test/langtools/tools/javac/valhalla/lworld-values/CheckFeatureGate2.out From david.simms at oracle.com Tue Mar 3 09:41:02 2020 From: david.simms at oracle.com (david.simms at oracle.com) Date: Tue, 03 Mar 2020 09:41:02 +0000 Subject: hg: valhalla/valhalla: 8240313: [lworld] valhalla/valuetypes/StaticInitFactoryTest.java NPE after merge Message-ID: <202003030941.0239f373004857@aojmv0008.oracle.com> Changeset: 1a862a81b589 Author: dsimms Date: 2020-03-03 10:32 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1a862a81b589 8240313: [lworld] valhalla/valuetypes/StaticInitFactoryTest.java NPE after merge ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java From david.simms at oracle.com Tue Mar 3 11:36:56 2020 From: david.simms at oracle.com (david.simms at oracle.com) Date: Tue, 03 Mar 2020 11:36:56 +0000 Subject: hg: valhalla/valhalla: [lworld] Ignore top types from JDK-8237069 Message-ID: <202003031136.023Bavvq008008@aojmv0008.oracle.com> Changeset: 00010b44d679 Author: dsimms Date: 2020-03-03 12:36 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/00010b44d679 [lworld] Ignore top types from JDK-8237069 ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassHierarchyTest.java From harold.seigel at oracle.com Wed Mar 4 16:08:55 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 04 Mar 2020 16:08:55 +0000 Subject: hg: valhalla/valhalla: Summary: fix minor merge issue Message-ID: <202003041608.024G8t67028469@aojmv0008.oracle.com> Changeset: 8cc162bd3671 Author: hseigel Date: 2020-03-04 16:08 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8cc162bd3671 Summary: fix minor merge issue Reviewed-by: lfoltan ! src/hotspot/share/classfile/classLoaderData.cpp From fw at deneb.enyo.de Thu Mar 5 08:25:58 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 05 Mar 2020 09:25:58 +0100 Subject: RFR [lworld] 8239929: Object.newIdentity() replacement for new Object() In-Reply-To: (Roger Riggs's message of "Mon, 2 Mar 2020 15:18:50 -0500") References: <875zfongcl.fsf@mid.deneb.enyo.de> Message-ID: <87o8tbryw9.fsf@mid.deneb.enyo.de> * Roger Riggs: > To keep it simple and localized, the factory method is in the > IdentityObject interface. With this, this does not compile: public class T { public static void main(String[] args) { newIdentity(); } } However, at run time, I assume that all instances of T implement the IdentityObject interface. I find this somewhat jarring. Why don't we expose the class? For example, HashSet has this: // Dummy value to associate with an Object in the backing Map private static final Object PRESENT = new Object(); Wouldn't be nice to be able to write this instead? private static final Marker PRESENT = new Marker(); To make it explicit that this is an instance of a special class? And maybe add another class for the other common usage, a lock? From fw at deneb.enyo.de Thu Mar 5 16:51:06 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 05 Mar 2020 17:51:06 +0100 Subject: Inline classes and the memory model Message-ID: <87k13ypwxx.fsf@mid.deneb.enyo.de> Sorry if this has been brought up before. Consisder this example, which is intended to simmulate a buffer-like class that has a pointer to a backing array, a capacity, and a size (where the size must be no greater than the capacity etc.): import java.util.Random; public class Consistency { public static void main(String[] args) { Holder holder = new Holder(); new Thread() { public void run() { while (true) { Slice slice = holder.slice; if (!slice.consistent()) System.out.println(slice); ++holder.counter; } } }.start(); while (true) { holder.update(); } } static inline class Slice { final long ptr; final int capacity; final int size; Slice(Random random) { capacity = random.nextInt(1 << 20); size = random.nextInt(capacity + 1); // Use the pointer to encode both the capacity and size. ptr = capacity * ((1L << 20) + 1) + size; } boolean consistent() { return ptr == capacity * ((1L << 20) + 1) + size && size <= capacity; } public String toString() { return String.format("ptr=0x%x capacity=%d size=%d", ptr, capacity, size); } } static class Holder { final Random random = new Random(1); Slice slice = new Slice(random); volatile int counter; void update() { slice = new Slice(random); ++counter; } } } If Slice is not an inline class, the barrier at the end of such constructors together with the barrier implied in a pointer load ensures that all created objects are consistent and always observed as such. With the inline keyword added, this is no longer the case. This suggests to me that inline classes cannot protect their invariants. Will that limit their usefulness? If you wonder how Go solves this problem with its built-in slice types, the answer is that it does not. Go is simply not memory-safe if goroutines can execute concurrently on multiple processors. From romanowski.mateusz at gmail.com Thu Mar 5 17:29:24 2020 From: romanowski.mateusz at gmail.com (Mateusz Romanowski) Date: Thu, 5 Mar 2020 17:29:24 +0000 Subject: Inline classes and the memory model In-Reply-To: <87k13ypwxx.fsf@mid.deneb.enyo.de> References: <87k13ypwxx.fsf@mid.deneb.enyo.de> Message-ID: Hi Florian, I believe you might need to use @NonTearable annotation to force inline fields not to tear like long and double ones. The situation is orthogonal to constructor's safe publication, I think. https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-February/006827.html Cheers, Mateusz On Thursday, March 5, 2020, Florian Weimer wrote: > Sorry if this has been brought up before. Consisder this example, > which is intended to simmulate a buffer-like class that has a pointer > to a backing array, a capacity, and a size (where the size must be no > greater than the capacity etc.): > > import java.util.Random; > > public class Consistency { > public static void main(String[] args) { > Holder holder = new Holder(); > > new Thread() { > public void run() { > while (true) { > Slice slice = holder.slice; > if (!slice.consistent()) > System.out.println(slice); > ++holder.counter; > } > } > }.start(); > > while (true) { > holder.update(); > } > } > > static inline class Slice { > final long ptr; > final int capacity; > final int size; > > Slice(Random random) { > capacity = random.nextInt(1 << 20); > size = random.nextInt(capacity + 1); > // Use the pointer to encode both the capacity and size. > ptr = capacity * ((1L << 20) + 1) + size; > } > > boolean consistent() { > return ptr == capacity * ((1L << 20) + 1) + size > && size <= capacity; > } > > public String toString() { > return String.format("ptr=0x%x capacity=%d size=%d", > ptr, capacity, size); > } > } > > static class Holder { > final Random random = new Random(1); > Slice slice = new Slice(random); > volatile int counter; > > void update() { > slice = new Slice(random); > ++counter; > } > } > } > > If Slice is not an inline class, the barrier at the end of such > constructors together with the barrier implied in a pointer load > ensures that all created objects are consistent and always observed as > such. With the inline keyword added, this is no longer the case. > > This suggests to me that inline classes cannot protect their > invariants. Will that limit their usefulness? > > If you wonder how Go solves this problem with its built-in slice > types, the answer is that it does not. Go is simply not memory-safe > if goroutines can execute concurrently on multiple processors. > From fw at deneb.enyo.de Thu Mar 5 17:38:19 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 05 Mar 2020 18:38:19 +0100 Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity In-Reply-To: <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> (John Rose's message of "Fri, 21 Feb 2020 02:23:14 -0800") References: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com> <6f201ace-f9e6-1ed9-6187-1e881c146d56@oracle.com> <83A8E7C7-C2CB-4F3C-A840-F6169C9E6246@oracle.com> <1113acf6-9c46-5e07-ed07-679bca4e3a94@oracle.com> <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> Message-ID: <87ftempur8.fsf@mid.deneb.enyo.de> * John Rose: > http://cr.openjdk.java.net/~jrose/values/atomic-8236522 NonTearable says this: 38 *

An inline instance of multiple components is said to be "torn" 39 * when two racing threads compete to update those components, and one 40 * thread updates some components while another thread updates other 41 * components. The resulting inline value stored in the heap might be I think this description is incorrect: a single writer, single reader scenario (with final fields in the inline class even) can also result in invalid values. See ?Inline classes and the memory model? posted today; failed to spot the relevance of this older thread. I think the actual goal here is to preserve the property that data races cannot observe out-of-thin-air values, like it is impossible with a subset of the primitive types? And also to support some concept of safe publication for inline classes? From mandy.chung at oracle.com Thu Mar 5 17:42:31 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 05 Mar 2020 17:42:31 +0000 Subject: hg: valhalla/valhalla: 8230935: [nestmates] update jdk.vm.ci.runtime.test.TestResolvedJavaType test to verify lambda uses hidden class Message-ID: <202003051742.025HgW3m022764@aojmv0008.oracle.com> Changeset: e624ea4194e9 Author: jcm Date: 2020-03-05 09:41 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e624ea4194e9 8230935: [nestmates] update jdk.vm.ci.runtime.test.TestResolvedJavaType test to verify lambda uses hidden class Reviewed-by: dlong, mchung Contributed-by: jamsheed.c.m at oracle.com ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java From Roger.Riggs at oracle.com Thu Mar 5 18:22:36 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 5 Mar 2020 13:22:36 -0500 Subject: RFR [lworld] 8239929: Object.newIdentity() replacement for new Object() In-Reply-To: <87o8tbryw9.fsf@mid.deneb.enyo.de> References: <875zfongcl.fsf@mid.deneb.enyo.de> <87o8tbryw9.fsf@mid.deneb.enyo.de> Message-ID: Hi Florian, On 3/5/20 3:25 AM, Florian Weimer wrote: > * Roger Riggs: > >> To keep it simple and localized, the factory method is in the >> IdentityObject interface. > With this, this does not compile: > > public class T { > public static void main(String[] args) { > newIdentity(); > } > } > > However, at run time, I assume that all instances of T implement the > IdentityObject interface. I find this somewhat jarring. There are quite a few rough edges yet... My own thinking is that nudging toward being explicit about identity is a good thing. But I expect the language model folks to be more definitive about the tradeoffs. In the use case above, it seems kind of a convenient accident to make newIdentity() implicitly visible as a method of T. There doesn't seem to be any relationship between T and the use of newIdentity(). > > Why don't we expose the class? For example, HashSet has this: > > // Dummy value to associate with an Object in the backing Map > private static final Object PRESENT = new Object(); In the new model, not every "Object" carries identity so its important to be explicit. There's preference for static factories instead of constructors; it provides more flexibility in the way it is implemented. > > Wouldn't be nice to be able to write this instead? > > private static final Marker PRESENT = new Marker(); > > To make it explicit that this is an instance of a special class? > > And maybe add another class for the other common usage, a lock? Application specific types for semantically significant instances is a plus. Is very easy today to create new types for applications , but they typically don't take the trouble. Using 'Object' for all of them is convenient but is kind of sloppy but very convenient. Regards, Roger From fw at deneb.enyo.de Thu Mar 5 18:57:31 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 05 Mar 2020 19:57:31 +0100 Subject: RFR [lworld] 8239929: Object.newIdentity() replacement for new Object() In-Reply-To: (Roger Riggs's message of "Thu, 5 Mar 2020 13:22:36 -0500") References: <875zfongcl.fsf@mid.deneb.enyo.de> <87o8tbryw9.fsf@mid.deneb.enyo.de> Message-ID: <878skepr38.fsf@mid.deneb.enyo.de> * Roger Riggs: > Hi Florian, > > On 3/5/20 3:25 AM, Florian Weimer wrote: >> * Roger Riggs: >> >>> To keep it simple and localized, the factory method is in the >>> IdentityObject interface. >> With this, this does not compile: >> >> public class T { >> public static void main(String[] args) { >> newIdentity(); >> } >> } >> >> However, at run time, I assume that all instances of T implement the >> IdentityObject interface. I find this somewhat jarring. > In the use case above, it seems kind of a convenient accident to > make newIdentity() implicitly visible as a method of T. There > doesn't seem to be any relationship between T and the use of > newIdentity(). Do you mean invisible at the Java language layer, but visible at the JVM layer? (I think the accident goes in the other direction.) I agree that there isn't any relationship with the use of newIdentity(). newIdentity() is useful within both inline and identity classes. I wouldn't like to see a repeat of array.length, but in the other direction. >> Why don't we expose the class? For example, HashSet has this: >> >> // Dummy value to associate with an Object in the backing Map >> private static final Object PRESENT = new Object(); > In the new model, not every "Object" carries identity so its important > to be explicit. > > There's preference for static factories instead of constructors; > it provides more flexibility in the way it is implemented. On the other hand, the constructor conveys that a fresh object is being created, something that a static method does not necessary do. And with records, we stuck to constructors, so the movement to factories is far from universal. >> Wouldn't be nice to be able to write this instead? >> >> private static final Marker PRESENT = new Marker(); >> >> To make it explicit that this is an instance of a special class? >> >> And maybe add another class for the other common usage, a lock? > Application specific types for semantically significant instances is a plus. > Is very easy today to create new types for applications , but they > typically don't take the trouble. > Using 'Object' for all of them is convenient but is kind of sloppy but > very convenient. I think markers are a large enough category that creating a separate class (Marker) for them should be considered. The other category is monitor-style locks. From mandy.chung at oracle.com Thu Mar 5 20:58:10 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 05 Mar 2020 20:58:10 +0000 Subject: hg: valhalla/valhalla: 7 new changesets Message-ID: <202003052058.025KwB3f022116@aojmv0008.oracle.com> Changeset: f5af61b84070 Author: sspitsyn Date: 2020-03-05 11:36 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f5af61b84070 [nestmates] InstanceKlass::signature_name uses '.' as the illegal char for hidden class. Reviewed-by: mchung ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/jdk.jdi/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/JNITypeParser.java - test/hotspot/jtreg/serviceability/jvmti/HiddenClass/MyPackage/HiddenClassSigTest.java + test/hotspot/jtreg/serviceability/jvmti/HiddenClass/P/Q/HiddenClassSigTest.java ! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp Changeset: f533e60bd952 Author: mchung Date: 2020-03-05 11:51 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f533e60bd952 [nestmates] API spec update ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java Changeset: dd33d8bb93d9 Author: mchung Date: 2020-03-05 12:04 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/dd33d8bb93d9 [nestmates] add negative test cases for defineHiddenClass ! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java Changeset: 2574a1a5465e Author: mchung Date: 2020-03-05 12:05 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2574a1a5465e [nestmates] minor cleanup and fix to defineHiddenClass ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 78f0b6ecdef7 Author: mchung Date: 2020-03-05 12:06 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/78f0b6ecdef7 [nestmates] merge fixes ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! test/hotspot/jtreg/ProblemList.txt Changeset: ffa3ed9c5604 Author: mchung Date: 2020-03-05 12:50 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ffa3ed9c5604 [nestmates] minor cleanup Class::getName spec ! src/java.base/share/classes/java/lang/Class.java Changeset: bd02a2b5c018 Author: mchung Date: 2020-03-05 12:57 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/bd02a2b5c018 [nestmates] minor cleanup ClassOption spec ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java From mandy.chung at oracle.com Thu Mar 5 21:04:49 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 05 Mar 2020 21:04:49 +0000 Subject: hg: valhalla/valhalla: 86 new changesets Message-ID: <202003052104.025L4skG024071@aojmv0008.oracle.com> Changeset: 7abee91f0bb5 Author: darcy Date: 2020-02-27 10:30 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7abee91f0bb5 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: 6e9aa02cf215 Author: wetmore Date: 2020-02-27 11:48 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6e9aa02cf215 8239815: Update ECC legal file Reviewed-by: mullan ! src/jdk.crypto.ec/share/legal/ecc.md Changeset: 52367bbd4bd4 Author: jjg Date: 2020-02-27 12:16 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/52367bbd4bd4 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: a30f7d67296e Author: cjplummer Date: 2020-02-27 13:51 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a30f7d67296e 8240142: Fix copyright in ThreadGroupReferenceImpl.h Reviewed-by: dholmes ! src/jdk.jdwp.agent/share/native/libjdwp/ThreadGroupReferenceImpl.h Changeset: 7e846d63ca61 Author: cjplummer Date: 2020-02-27 13:52 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7e846d63ca61 8239379: ProblemList serviceability/sa/sadebugd/DebugdConnectTest.java on OSX Reviewed-by: sspitsyn ! test/hotspot/jtreg/ProblemList.txt Changeset: 04ba72c457f3 Author: cjplummer Date: 2020-02-27 13:57 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/04ba72c457f3 8193237: SA: ClhsdbLauncher should show the command being executed Reviewed-by: sspitsyn, amenkov ! test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java Changeset: 02f6ce8441df Author: xuelei Date: 2020-02-27 21:14 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/02f6ce8441df 8240193: loadLibrary("osxsecurity") should not be removed Reviewed-by: ascarpino ! src/java.base/macosx/classes/apple/security/KeychainStore.java Changeset: 27e301f90b3a Author: ihse Date: 2020-02-28 09:53 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/27e301f90b3a 8239799: Cross-compilation ARM32/AARCH clientvm builds fails after JDK-8239450 Reviewed-by: erikj ! make/autoconf/buildjdk-spec.gmk.in Changeset: 8def7c4e6800 Author: chagedorn Date: 2020-02-28 15:33 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8def7c4e6800 8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed Summary: 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: 1a57db1b936f Author: dcubed Date: 2020-02-28 10:16 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1a57db1b936f 8240231: Build failure on illumos after 8238988 Summary: add missing cast Reviewed-by: dcubed, shade Contributed-by: peter.tribble at gmail.com ! src/hotspot/os_cpu/solaris_x86/thread_solaris_x86.cpp Changeset: ec5e6e8d1ed2 Author: lucy Date: 2020-02-28 16:36 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ec5e6e8d1ed2 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: c838a35b86e9 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c838a35b86e9 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: df9f37c56847 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/df9f37c56847 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: c005ba590219 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c005ba590219 8240217: Shenandoah: remove ShenandoahEvacAssist Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: d1062bce95b9 Author: simonis Date: 2020-02-28 19:49 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d1062bce95b9 8240226: DeflateIn_InflateOut.java test incorrectly assumes size of compressed file Reviewed-by: martin, alanb ! test/jdk/java/util/zip/DeflateIn_InflateOut.java Changeset: 9d59ab73463c Author: jjg Date: 2020-02-28 12:46 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/9d59ab73463c 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/TestExternalOverriddenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - 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: 7b59e4c72006 Author: lmesnik Date: 2020-02-28 13:21 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7b59e4c72006 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: f227e770495f Author: minqi Date: 2020-02-28 15:30 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f227e770495f 8236604: Optimize SystemDictionary::resolve_well_known_classes for CDS Summary: 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: 0569a84a9ec0 Author: jiefu Date: 2020-02-29 09:38 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0569a84a9ec0 8240254: Build is broken when cds is disabled after JDK-8236604 Reviewed-by: redestad ! src/hotspot/share/classfile/systemDictionary.hpp Changeset: f46dfe6b18ac Author: minqi Date: 2020-02-28 19:29 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f46dfe6b18ac 8240258: SystemDictionary::quick_resolve need guarded by INCLUDE_CDS Summary: 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: eeba18e49d0b Author: lzang Date: 2020-02-29 14:43 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/eeba18e49d0b 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: 1e4e7bf0b6f5 Author: fyang Date: 2020-02-26 17:32 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1e4e7bf0b6f5 8239915: Zero VM crashes when handling dynamic constant Reviewed-by: dholmes Contributed-by: wangkun49 at huawei.com ! src/hotspot/share/interpreter/bytecodeInterpreter.cpp + test/hotspot/jtreg/runtime/invokedynamic/DynamicConstantHelper.jasm + test/hotspot/jtreg/runtime/invokedynamic/TestDynamicConstant.java Changeset: 4a5a7dc9d05c Author: iklam Date: 2020-03-01 17:36 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4a5a7dc9d05c 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: 4b9d816b1531 Author: rhalade Date: 2020-03-01 23:04 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4b9d816b1531 8225130: Add exception for expiring Comodo roots to VerifyCACerts test Reviewed-by: weijun ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: acc083236275 Author: redestad Date: 2020-03-02 08:22 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/acc083236275 8196334: Optimize UUID#fromString Reviewed-by: igerasim, alanb Contributed-by: plokhotnyuk at gmail.com, jon.chambers at gmail.com, claes.redestad at oracle.com ! 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: 1d64bd5b34e0 Author: chagedorn Date: 2020-03-02 10:23 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1d64bd5b34e0 8238438: SuperWord::co_locate_pack picks memory state of first instead of last load Summary: 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: 41073408f25e Author: stefank Date: 2020-03-02 12:30 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/41073408f25e 8240220: IdealLoopTree::dump_head predicate printing is broken Reviewed-by: thartmann, neliasso, chagedorn ! src/hotspot/share/opto/loopnode.cpp Changeset: e04746cec89c Author: stefank Date: 2020-03-02 12:30 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e04746cec89c 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: 387369ff21a4 Author: mbalao Date: 2020-02-05 12:20 -0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/387369ff21a4 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: 5f6949a3dbe0 Author: hseigel Date: 2020-03-02 16:10 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5f6949a3dbe0 8239568: [TESTBUG] LoadLibraryTest.java fails with RuntimeException Summary: 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: e826821a469d Author: pconcannon Date: 2020-03-02 16:47 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e826821a469d 8234812: Add micros for DatagramChannel send/receive Summary: Benchmarks for the DatagramChannel::send and DatagramChannel::receive methods Reviewed-by: alanb, chegar + test/micro/org/openjdk/bench/java/nio/DatagramChannelSendReceive.java Changeset: 3a9bd48ecffc Author: lfoltan Date: 2020-03-02 18:42 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3a9bd48ecffc 8237766: Enhance signature API to include ResolvingSignatureStream Summary: New ResolvingSignatureStream class provides the capability to easily walk through the differing parts of a signature while resolving or querying its underlying types. Reviewed-by: coleenp, fparain, hseigel Contributed-by: lois.foltan at oracle.com, john.r.rose at oracle.com ! 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: ac3371755ede Author: kbarrett Date: 2020-03-02 14:45 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ac3371755ede 8240246: Avoid cast_to_oop from char* Summary: Change type of gtest object from char[] to unsigned char[]. Reviewed-by: dholmes ! test/hotspot/gtest/oops/test_oop.cpp Changeset: 83ff8e2fa7ab Author: mseledtsov Date: 2020-03-02 12:16 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/83ff8e2fa7ab 8236938: [TESTBUG] JFR event MetaspaceAllocationFailure is not tested Summary: 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: 80e4a066342d Author: dholmes Date: 2020-03-02 19:49 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/80e4a066342d 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: f3d90cac1c7c Author: prr Date: 2020-02-12 14:45 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f3d90cac1c7c 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: 314f940aaf82 Author: serb Date: 2020-02-13 13:17 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/314f940aaf82 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: 19adbbca4307 Author: serb Date: 2020-02-13 13:19 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/19adbbca4307 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: bdcad73943d5 Author: serb Date: 2020-02-13 13:21 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/bdcad73943d5 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: ece447fa3843 Author: serb Date: 2020-02-13 13:23 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ece447fa3843 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: df45736e03ac Author: prr Date: 2020-02-14 09:10 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/df45736e03ac 8238942: Rendering artifacts with LCD text and fractional metrics Reviewed-by: serb, jdv ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: bc9c585b41e7 Author: prr Date: 2020-02-14 10:44 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/bc9c585b41e7 8239091: Reversed arguments in call to strstr in freetype "debug" code. Reviewed-by: bpb ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: 81bb0384f515 Author: kizune Date: 2020-02-17 20:04 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/81bb0384f515 8237221: [macos] java/awt/MenuBar/SeparatorsNavigation/SeparatorsNavigation.java fails Reviewed-by: serb + test/jdk/java/awt/MenuBar/SeparatorsNavigation/SeparatorsNavigation.java Changeset: 062b36ecf8d7 Author: psadhukhan Date: 2020-02-20 14:49 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/062b36ecf8d7 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: c28ebdb28a8e Author: pbansal Date: 2020-02-21 16:31 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c28ebdb28a8e 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: 427e3df3f0a3 Author: pbansal Date: 2020-02-21 17:00 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/427e3df3f0a3 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: 159f96d0784c Author: pbansal Date: 2020-02-21 17:09 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/159f96d0784c 8238985: [TESTBUG] The arrow image is blue instead of green Reviewed-by: serb, psadhukhan ! test/jdk/javax/swing/JTextPane/TestJTextPaneHTMLRendering.java Changeset: ea4c6da34c1f Author: aivanov Date: 2020-02-25 20:00 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ea4c6da34c1f 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: 965c0a1421e5 Author: serb Date: 2020-02-27 09:49 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/965c0a1421e5 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: 69495f2ee5ba Author: serb Date: 2020-02-28 16:49 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/69495f2ee5ba 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: ed5224c3e044 Author: psadhukhan Date: 2020-03-02 10:50 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ed5224c3e044 Merge - make/CopyInterimCLDRConverter.gmk - make/Help.gmk - make/autoconf/basics.m4 - make/autoconf/basics_windows.m4 - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java - src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java - 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 - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64MacroAssemblerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGCProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/Access.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/GCProvider.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/gc/shenandoah/compiler/TestCommonGCLoads.java - test/hotspot/jtreg/runtime/7116786/Test7116786.java - test/hotspot/jtreg/runtime/7116786/testcases.jar - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/hotspot/jtreg/runtime/EnclosingMethodAttr/enclMethodAttr.jar - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/DuplicateLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/NotFoundLVTT.cod - test/hotspot/jtreg/runtime/LocalVariableTable/testcase.jar - test/hotspot/jtreg/runtime/classFileParserBug/emptynumbootstrapmethods.jar - test/hotspot/jtreg/runtime/classFileParserBug/test.jar - test/hotspot/jtreg/runtime/duplAttributes/test.jar - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh ! test/jdk/ProblemList.txt - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java Changeset: d765d242df98 Author: psadhukhan Date: 2020-03-03 13:31 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d765d242df98 Merge - test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibrary.java - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java Changeset: 370822016750 Author: neliasso Date: 2020-03-03 10:29 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/370822016750 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: 1bc5f223df65 Author: simonis Date: 2020-03-03 11:24 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1bc5f223df65 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly Reviewed-by: martin, clanger, lancea ! test/lib/jdk/test/lib/util/JarUtils.java Changeset: de17bc931bbe Author: redestad Date: 2020-03-03 11:40 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/de17bc931bbe 8240302: x64: Assembler::reachable redundantly call Relocation::type() more than once Reviewed-by: kvn, iklam, thartmann ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: 32e20dcd43eb Author: redestad Date: 2020-03-03 12:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/32e20dcd43eb 8240263: Assertion-only call in Method::link_method affecting product builds Reviewed-by: shade, dcubed, iklam ! src/hotspot/share/oops/method.cpp Changeset: d8dbc734645b Author: hseigel Date: 2020-03-03 15:50 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d8dbc734645b 8240324: Improve is_boot_class_loader_data() by adding simple check Summary: 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: e0e5cbb61e86 Author: coleenp Date: 2020-03-03 11:19 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e0e5cbb61e86 8225760: oop::raw_set_obj isn't needed Reviewed-by: hseigel, rkennke ! src/hotspot/share/oops/oopsHierarchy.hpp Changeset: 06b31c23a9a8 Author: fmatte Date: 2020-02-27 19:33 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/06b31c23a9a8 8239055: Wrong implementation of VMState.hasListener Summary: 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: ef54941dbc95 Author: mseledtsov Date: 2020-03-03 12:43 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ef54941dbc95 8235206: JFR TestCrossProcessStreaming - validate that data can be consumed while it is being produced Summary: Updated test to validate concurrent produce/consume Reviewed-by: egahlin ! test/jdk/jdk/jfr/api/consumer/streaming/TestCrossProcessStreaming.java Changeset: 522f5bb0e92b Author: xuelei Date: 2020-03-03 15:57 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/522f5bb0e92b 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: f6322be85592 Author: roland Date: 2020-02-21 15:01 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f6322be85592 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: 1d4d4c9d03c2 Author: roland Date: 2020-02-20 16:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1d4d4c9d03c2 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: a3a462ce27cd Author: bae Date: 2020-03-03 13:06 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a3a462ce27cd 8239787: AArch64: String.indexOf may incorrectly handle empty strings Reviewed-by: aph, lmesnik, yan Contributed-by: alexey at azul.com ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp + test/hotspot/jtreg/runtime/StringIntrinsic/StringIndexOfChar.java Changeset: 6f709455592a Author: shade Date: 2020-03-04 11:50 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6f709455592a 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: 8797eb1fe3bf Author: jlahoda Date: 2020-03-04 13:43 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8797eb1fe3bf 8239575: javadoc triggers javac AssertionError for annos on modules Summary: 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: d2fc63de7876 Author: jlahoda Date: 2020-03-04 13:43 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d2fc63de7876 8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW Summary: 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: 1c06a8ee8aca Author: jlahoda Date: 2020-03-04 13:43 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1c06a8ee8aca 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: b0d94da54415 Author: herrick Date: 2020-03-03 17:58 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b0d94da54415 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: dffb6122849b Author: herrick Date: 2020-03-03 18:07 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/dffb6122849b 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: b77e4d778eb7 Author: herrick Date: 2020-03-03 18:10 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b77e4d778eb7 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: 707abe6ca3cb Author: simonis Date: 2020-03-04 14:55 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/707abe6ca3cb 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: 2fc917015437 Author: shade Date: 2020-03-04 19:23 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2fc917015437 8240534: Shenandoah: ditch debug safepoint timeout adjustment Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Changeset: d0b769130118 Author: jjg Date: 2020-03-04 12:58 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d0b769130118 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: 67cc6f3948e3 Author: ccheung Date: 2020-03-04 15:34 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/67cc6f3948e3 8240481: Remove CDS usage of InstanceKlass::is_in_error_state Summary: 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: a5cea8e81879 Author: jwilhelm Date: 2020-03-05 02:02 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a5cea8e81879 Added tag jdk-15+13 for changeset 1c06a8ee8aca ! .hgtags Changeset: 501a27fff637 Author: minqi Date: 2020-03-04 21:29 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/501a27fff637 8240546: runtime/cds/appcds/TestZGCWithCDS.java fails with Graal Summary: 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: 3465ed78d670 Author: iklam Date: 2020-03-04 22:26 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3465ed78d670 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: 187b26b1feb2 Author: njian Date: 2020-03-05 14:51 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/187b26b1feb2 8240286: [TESTBUG] Test command error in hotspot/jtreg/compiler/loopopts/superword/SumRedAbsNeg_Float.java Reviewed-by: kvn, thartmann Contributed-by: qi.feng at arm.com ! test/hotspot/jtreg/compiler/loopopts/superword/SumRedAbsNeg_Float.java Changeset: 0ba758a2b6f0 Author: dbuck Date: 2020-03-05 03:27 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0ba758a2b6f0 8183369: RFC unconformity of HttpURLConnection with proxy Summary: HttpURLConnection retried with proxy if the connection fails on first attempt as per RFC Reviewed-by: chegar, dfuchs, vtewari Contributed-by: ravi.k.reddy at oracle.com ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java Changeset: c4dea8e07b84 Author: ysuenaga Date: 2020-03-05 19:46 +0900 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c4dea8e07b84 8240197: Cannot start JVM when $JAVA_HOME includes CJK characters Reviewed-by: iklam, stuefe, rschmelter ! src/hotspot/os/windows/os_windows.cpp Changeset: fcbf0839a86c Author: eosterlund Date: 2020-03-05 11:12 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/fcbf0839a86c 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: 920a6239d61a Author: redestad Date: 2020-03-05 13:14 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/920a6239d61a 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: 4074e3cce261 Author: mgronlun Date: 2020-03-05 17:55 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4074e3cce261 8239376: JFR: assert(!cld->is_unsafe_anonymous()) failed: invariant Reviewed-by: coleenp, lfoltan, hseigel ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp Changeset: fbbcf9125cef Author: shurailine Date: 2020-03-05 09:51 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/fbbcf9125cef 8240241: Add support for JCov DiffCoverage to make files Reviewed-by: erikj, ihse ! doc/testing.html ! doc/testing.md ! make/RunTests.gmk Changeset: 3b6510b005e5 Author: lancea Date: 2020-03-05 13:56 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3b6510b005e5 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 From mandy.chung at oracle.com Thu Mar 5 21:46:31 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 05 Mar 2020 21:46:31 +0000 Subject: hg: valhalla/valhalla: Merge Message-ID: <202003052146.025LkWIu018531@aojmv0008.oracle.com> Changeset: 104a168dd0f3 Author: mchung Date: 2020-03-05 13:09 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/104a168dd0f3 Merge ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! test/hotspot/jtreg/ProblemList.txt - test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java - test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibrary.java - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/gc/kind/parOld/test.sh ! test/jdk/ProblemList.txt - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/package-list - test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod/pkg/XReader.java From david.holmes at oracle.com Fri Mar 6 04:22:51 2020 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 06 Mar 2020 04:22:51 +0000 Subject: hg: valhalla/valhalla: Fixed build failure on Windows: unused local variable 'err' Message-ID: <202003060422.0264MqoR018753@aojmv0008.oracle.com> Changeset: 7da4d5f38f96 Author: dholmes Date: 2020-03-05 23:11 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7da4d5f38f96 Fixed build failure on Windows: unused local variable 'err' Reviewed-by: mchung ! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp From david.holmes at oracle.com Fri Mar 6 05:29:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Mar 2020 15:29:53 +1000 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 Message-ID: webrev: http://cr.openjdk.java.net/~dholmes/8240645/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8240645 JEP-371 (Hidden Classes) is changing a key aspect of nest host resolution and validation compared to what we shipped originally for JEP-181 (Nestmates). Originally, any LinkageErrors during nest host resolution would be propagated, and any validation failures would result in IncompatibleClassChangeError being thrown. Now no LinkageErrors are thrown, but the fact one occurred is remembered for potential use if a private access check fails. Similarly, validation failures don't cause an exception any more. Nest host resolution always succeeds and the nest will be one of: - the successfully resolved nest host as per the NestHost attribute - the class itself if there is no NestHost attribute or there is an error during resolution or validation - the specified nest host explicitly set if this is a hidden class injected into a nest as appropriate. This has a flow on affect to the reflection method Class::getNestMembers() which can also no longer ever fail. To be able to diagnose issues with nest host resolution/validation you can use unified logging to examine what happens: -Xlog:class+nestmates=trace. In addition IllegakAccessErrors thrown by the VM are augmented with information about any nest host resolution/validation errors. For example an original exception: java.lang.IllegalAccessError: class TestNestmateMembership$Caller tried to access private method 'void TestNestmateMembership$TargetSelfHost.m()' (TestNestmateMembership$Caller and TestNestmateMembership$TargetSelfHost are in unnamed module of loader 'app') is now expanded with an additional "()" section which is memoized for use with other access checks: java.lang.IllegalAccessError: class TestNestmateMembership$Caller tried to access private method 'void TestNestmateMembership$TargetSelfHost.m()' (TestNestmateMembership$Caller and TestNestmateMembership$TargetSelfHost are in unnamed module of loader 'app')(Type TestNestmateMembership$TargetSelfHost (loader: 'app') is not a nest member of type TestNestmateMembership$TargetSelfHost (loader: 'app'): current type is not listed as a nest member) These exception messages are very long and unweildy but that seems unavoidable. They appear repetative in that the type names appear in the main message, the module information, and then again in the resolution error section. Unfortunately we can't avoid that as the memoized string has to be complete because it does not know the context of the IllegalAccessError in which it will be used. Please look at the mechanism by which this is done before making suggestions on how to condense. Also note that in the worst case there can be two nest host resolution errors reported, if both the current class and the target class had such errors. Note: the augmented exceptions do not extend to IllegalAccessExceptions thrown by the Java reflection or MethodHandle code. This would require an additional VM call to retrieve the information. This may be considered for a future RFE. Changes in detail: - src/hotspot/share/ci/ciField.cpp - src/hotspot/share/classfile/classFileParser.cpp - src/hotspot/share/runtime/reflection.cpp No longer a possibility of exceptions - src/hotspot/share/interpreter/linkResolver.cpp Expands on the message for IllegalAccessErrors in the private case, to report any nest host resolution/validation errors. - src/hotspot/share/oops/instanceKlass.cpp Implements the new specification for resolving the nest host, and adds the means to memoize the error message. The same message is used for exceptions and logging. Exception handling is changed as needed - no use of CHECK macros. Removed a case in has_nest_member where we would bail out if executing in a compiler thread and encountered an unresolved class entry in the CP. We previously bailed out as a precaution as the compiler thread can't load classes. I was surprised to find that I was hitting this code, and getting runtime failures because of it (not test failures). I don't see how the current changes would cause this. In any case the situation where actual class loading would be needed should be impossible - two classes of the same name within the same loader - so the bail out can be removed. Removed the recently added runtime_nest_host code which is no longer needed. - src/hotspot/share/prims/jvm.cpp Some code simplifies now exceptions are no longer possible. JVM_GetNestMembers has major updates: - as we no longer bail out on error we may end up with holes in the array, so we have to copy across to an array of the exact size before returning. - added logging to aid in debugging - src/hotspot/share/utilities/ostream.cpp Needed to add the ability for stringStream to return a C-Heap allocated buffer so we could use it for the memoized error messages. (This should probably be factored out to a separate RFE for mainline.) - src/java.base/share/classes/java/lang/Class.java Updated the specifications for getNestHost and getNestMembers as per Mandy's proposed spec updates (added missing @jvms links in getNestMembers()). Adjusted the implementation for the fact there are no longer any exceptions from the VM. - test/hotspot/jtreg/runtime/Nestmates/membership/TestNestmateMembership.java Had to change all the LinkageErrors/NoClassDefFoundErrors to be IllegalAccessError or IllegalAccessException and adjust the expected messages to check the underlying failure reasons. Other test adjusted as needed to account for no exceptions, and the changes to Class::getNestMembers(). Testing: all nestmate and hidden class tests under normal conditions. tiers 1 - 3 Thanks, David From scolebourne at joda.org Fri Mar 6 16:53:37 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 6 Mar 2020 16:53:37 +0000 Subject: Oredering of fields in inline types and records Message-ID: In a normal class with multiple fields, my understanding is that the JVM is free to layout the fields in memory however it wishes, potentially to make them better align with the underlying architecture. ie. it is not constrained to lay them out in source code order. Does the JVM still have this flexibility with records? Will the JVM still have this flexibility with inline types? (I don't remember seeing this discussed/answered before, but I could be wrong!) thanks Stephen From brian.goetz at oracle.com Fri Mar 6 16:59:21 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 6 Mar 2020 16:59:21 +0000 Subject: Oredering of fields in inline types and records In-Reply-To: References: Message-ID: <18DC8C90-6B02-4C71-A623-A4A64D687C54@oracle.com> Yes and yes. The VM still has this flexibility. Because the protocol (construction and deconstruction) of records appeals to a canonical ordering of components, we reify this ordering in the Record attribute, and expose it via reflection. But that is the only place the components are guaranteed to appear in the order they did in the source. > On Mar 6, 2020, at 4:53 PM, Stephen Colebourne wrote: > > In a normal class with multiple fields, my understanding is that the > JVM is free to layout the fields in memory however it wishes, > potentially to make them better align with the underlying > architecture. ie. it is not constrained to lay them out in source code > order. > > Does the JVM still have this flexibility with records? > > Will the JVM still have this flexibility with inline types? > > (I don't remember seeing this discussed/answered before, but I could be wrong!) > thanks > Stephen From forax at univ-mlv.fr Fri Mar 6 17:00:40 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 6 Mar 2020 18:00:40 +0100 (CET) Subject: Oredering of fields in inline types and records In-Reply-To: References: Message-ID: <1668471527.1013596.1583514040617.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stephen Colebourne" > ?: "valhalla-dev" > Envoy?: Vendredi 6 Mars 2020 17:53:37 > Objet: Oredering of fields in inline types and records > In a normal class with multiple fields, my understanding is that the > JVM is free to layout the fields in memory however it wishes, > potentially to make them better align with the underlying > architecture. ie. it is not constrained to lay them out in source code > order. > > Does the JVM still have this flexibility with records? yes > > Will the JVM still have this flexibility with inline types? yes > > (I don't remember seeing this discussed/answered before, but I could be wrong!) if as a developer you want to control the layout, yopu can use the foreign memory API of panama. > thanks > Stephen cheers, R?mi From mandy.chung at oracle.com Fri Mar 6 18:23:06 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Mar 2020 10:23:06 -0800 (PST) Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: References: Message-ID: <42767acd-3ce0-bb3c-7132-cb6ce214f5e7@oracle.com> Hi David, On 3/5/20 9:29 PM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8240645/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8240645 > This patch looks good to me. Thanks for the detail below which is very helpful.? It's okay with me that IAE thrown by core reflection and lookup MethodHandle is not extended with the memoized nest host error message in this release. We could improve it in the future. Mandy > JEP-371 (Hidden Classes) is changing a key aspect of nest host > resolution and validation compared to what we shipped originally for > JEP-181 (Nestmates). Originally, any LinkageErrors during nest host > resolution would be propagated, and any validation failures would > result in IncompatibleClassChangeError being thrown. Now no > LinkageErrors are thrown, but the fact one occurred is remembered for > potential use if a private access check fails. Similarly, validation > failures don't cause an exception any more. Nest host resolution > always succeeds and the nest will be one of: > - the successfully resolved nest host as per the NestHost attribute > - the class itself if there is no NestHost attribute or there is an > error during resolution or validation > - the specified nest host explicitly set if this is a hidden class > injected into a nest > > as appropriate. > > This has a flow on affect to the reflection method > Class::getNestMembers() which can also no longer ever fail. > > To be able to diagnose issues with nest host resolution/validation you > can use unified logging to examine what happens: > -Xlog:class+nestmates=trace. > > In addition IllegakAccessErrors thrown by the VM are augmented with > information about any nest host resolution/validation errors. For > example an original exception: > > java.lang.IllegalAccessError: class TestNestmateMembership$Caller > tried to access private method 'void > TestNestmateMembership$TargetSelfHost.m()' > (TestNestmateMembership$Caller and > TestNestmateMembership$TargetSelfHost are in unnamed module of loader > 'app') > > is now expanded with an additional "()" > section which is memoized for use with other access checks: > > java.lang.IllegalAccessError: class TestNestmateMembership$Caller > tried to access private method 'void > TestNestmateMembership$TargetSelfHost.m()' > (TestNestmateMembership$Caller and > TestNestmateMembership$TargetSelfHost are in unnamed module of loader > 'app')(Type TestNestmateMembership$TargetSelfHost (loader: 'app') is > not a nest member of type TestNestmateMembership$TargetSelfHost > (loader: 'app'): current type is not listed as a nest member) > > These exception messages are very long and unweildy but that seems > unavoidable. They appear repetative in that the type names appear in > the main message, the module information, and then again in the > resolution error section. Unfortunately we can't avoid that as the > memoized string has to be complete because it does not know the > context of the IllegalAccessError in which it will be used. Please > look at the mechanism by which this is done before making suggestions > on how to condense. > > Also note that in the worst case there can be two nest host resolution > errors reported, if both the current class and the target class had > such errors. > > Note: the augmented exceptions do not extend to > IllegalAccessExceptions thrown by the Java reflection or MethodHandle > code. This would require an additional VM call to retrieve the > information. This may be considered for a future RFE. > > Changes in detail: > > - src/hotspot/share/ci/ciField.cpp > - src/hotspot/share/classfile/classFileParser.cpp > - src/hotspot/share/runtime/reflection.cpp > > No longer a possibility of exceptions > > -? src/hotspot/share/interpreter/linkResolver.cpp > > Expands on the message for IllegalAccessErrors in the private case, to > report any nest host resolution/validation errors. > > -? src/hotspot/share/oops/instanceKlass.cpp > > Implements the new specification for resolving the nest host, and adds > the means to memoize the error message. The same message is used for > exceptions and logging. > > Exception handling is changed as needed - no use of CHECK macros. > > Removed a case in has_nest_member where we would bail out if executing > in a compiler thread and encountered an unresolved class entry in the > CP. We previously bailed out as a precaution as the compiler thread > can't load classes. I was surprised to find that I was hitting this > code, and getting runtime failures because of it (not test failures). > I don't see how the current changes would cause this. In any case the > situation where actual class loading would be needed should be > impossible - two classes of the same name within the same loader - so > the bail out can be removed. > > Removed the recently added runtime_nest_host code which is no longer > needed. > > -? src/hotspot/share/prims/jvm.cpp > > Some code simplifies now exceptions are no longer possible. > > JVM_GetNestMembers has major updates: > - as we no longer bail out on error we may end up with holes in the > array, so we have to copy across to an array of the exact size before > returning. > - added logging to aid in debugging > > -? src/hotspot/share/utilities/ostream.cpp > > Needed to add the ability for stringStream to return a C-Heap > allocated buffer so we could use it for the memoized error messages. > (This should probably be factored out to a separate RFE for mainline.) > > - src/java.base/share/classes/java/lang/Class.java > > Updated the specifications for getNestHost and getNestMembers as per > Mandy's proposed spec updates (added missing @jvms links in > getNestMembers()). Adjusted the implementation for the fact there are > no longer any exceptions from the VM. > > - > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestmateMembership.java > > Had to change all the LinkageErrors/NoClassDefFoundErrors to be > IllegalAccessError or IllegalAccessException and adjust the expected > messages to check the underlying failure reasons. > > Other test adjusted as needed to account for no exceptions, and the > changes to Class::getNestMembers(). > > Testing: all nestmate and hidden class tests under normal conditions. > ???????? tiers 1 - 3 > > Thanks, > David From john.r.rose at oracle.com Fri Mar 6 20:24:51 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 6 Mar 2020 12:24:51 -0800 Subject: Oredering of fields in inline types and records In-Reply-To: References: Message-ID: <4B3FF504-587F-46B1-9A80-D9893F26FB1E@oracle.com> On Mar 6, 2020, at 8:53 AM, Stephen Colebourne wrote: > > Does the JVM still have this flexibility with records? > > Will the JVM still have this flexibility with inline types? Yes, as others have said. I might as well explain the larger principle, that the JVM controls these things, FTR. The JVM uses this flexibility to sort fields by kind, where ?kinds? are primitive-of-some-size-N (N in {1,2,4,8}), plus reference as a distinct kind. And now ?value struct?. The differing alignments of different primitive kinds means there's an easy win in compactness from putting all the bytes in one place, rather than (say) alternating bytes and longs, with 7 bits of padding for each byte. Doing this for values requires compromises since value structs come in many kinds, but we can roughly classify them by size and alignment, just like C structs. The GC makes use of the fact that references tend to be grouped in object layouts, rather than scattered at random. There?s even some logic to try to put the references from a subclass and a superclass next to each other (deeper hierarchies defeat this). The result is that the GC can use a few fast loops through a contiguous array, rather than some bitmask-driven traversal, for typical objects. Note also that new vector types (when the Vector API starts to use inline classes) might (or not) be given their own ?kinds? under the covers, extending the pattern of byte/short/int/long to larger sizes. (Yes, double and char and boolean and float lose their separate status.) For inline fields, the JVM even reserves the right (in theory) to break up a value and merge its fields into the kind-based sort of the containing object, although this would complicate various parts of the JVM, including the Unsafe API which supports peek and poke of value instances. It is an interesting thought exercise to apply such value field merging to groups of array elements as well, with the goal of avoiding cache line crossing (on platforms where that matters). My point there is that each cache line could be filled with as many values as possible, and then padded out to the next cache line. The array indexing arithmetic is more complicated but not terrible, and affine loops are easy as long as they are unrolled by the right amount. So, yes, the JVM asserts sole authority over the layouts of the data in the managed heap. For primitive data, you can use Panama APIs (or the equivalent) to overlay C-style structs on Java arrays. For structs with managed pointers, there is no way, currently, to direct the JVM what to do in detail. If we ever do what I?ve called ?non-periodic arrays?, then we will need more flexibility in the location of managed pointers, and at that point (if we get there) it will be natural to consider APIs by which the user can direct the JVM about the placement of managed pointers in a larger object. Loom is starting to knock on this door today, since they have a natural need to store stack frames in the heap, and a stack frame is (if you look at it the right way) a non-periodic array. FTR, a non-periodic array is ?worse? than a merely heterogeneous array, because its elements might be of differing sizes. You parse them stream-wise, or if you need to address them with dead-reckoning, you get extra help. ? John From john.r.rose at oracle.com Fri Mar 6 21:45:50 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 6 Mar 2020 13:45:50 -0800 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: References: Message-ID: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> Nice work, very thorough as usual. One nit. The back-to-back parens are bad style. > foo (bar)(baz) https://english.stackexchange.com/questions/19429/should-i-use-adjacent-parentheses-or-a-semicolon-or-something-else https://blog.apastyle.org/apastyle/2013/05/punctuation-junction-parentheses-and-brackets.html There are different ways to handle this in professional text. I think the simplest way is relatively tricky from our perspective. You merge the two parentheticals with an internal semicolon: > foo (bar; baz) A really simple tweak to your code would be to put a comma between. This is less standard but better than back-to-back parens: -+ ss.print("("); ++ ss.print(?, (?); (Two places.) Likewise, in two places: -+ msg = "(stuff?)"; ++ msg = " (stuff?)?; ?to avoid the left paren making hard contact with the preceding text. Klass::_nest_host_res_error is ok. If we ever decide to reduce the footprint there (as part of a larger effort, I think), we could merge both fields by using a tagged pointer, on the observation that you only need one or the other to be non-null. If the res-error is not null, then we can infer that nest-host has been determined to be self, and in that case we don?t need to look at the field, right? You might want to add a comment about the possible states of those two coupled variables, to help maintainers. For example: + // This variable is non-null only if _nest_host is null. Actually, I didn?t follow the logic fully: Can both fields be non-null at the same time? It looks like Klass::nest_host only gets set non-null on error-free paths, while the error string is set only on error paths. It would be reasonable for Klass::nest_host to check for an error string and immediately return ?this? if one is set. I didn?t see this. Maybe the comment should be: + // This variable is non-null only if _nest_host is this or (during a race) null. (And if there?s a race, please do a releasing store of the error string before setting the _nest_host to ?this?. But at-least-one-always-null is a safer convention for managing races. So I like the first comment much better.) Also, let?s talk about VirtualMachineError. After thinking about it a bit, I think you went too far replacing CATCH by THREAD; this makes a fragile assumption that nothing is coming out of the call. It?s fragile because, although we expect LinkageError, there?s usually an additional possibility of VirtualMachineError. Doing a catch-and-clear of VME is risky business, and in this case I only think we need to catch and clear the LE, not the VME. To me, it seems safest to always expect VME, and always pass it on, as a basic convention in our code base, with clear documentation wherever we do something different. Imagine getting an access error later on, with the parenthetical remark that the nest host failed due to SOE or OOME. Those guys should be fail-fast, I think. Or did you come up with a reason they should be muzzled also, along with the LE we intend to muzzle? I see the previous code processed VME differently, and that you removed it, so I know you did this as a considered step. But still it seems off to me. At least add some documentation explaining why it?s safe to drop VM errors. ? John From john.r.rose at oracle.com Sat Mar 7 21:19:23 2020 From: john.r.rose at oracle.com (John Rose) Date: Sat, 7 Mar 2020 13:19:23 -0800 Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity In-Reply-To: <87ftempur8.fsf@mid.deneb.enyo.de> References: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com> <6f201ace-f9e6-1ed9-6187-1e881c146d56@oracle.com> <83A8E7C7-C2CB-4F3C-A840-F6169C9E6246@oracle.com> <1113acf6-9c46-5e07-ed07-679bca4e3a94@oracle.com> <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> <87ftempur8.fsf@mid.deneb.enyo.de> Message-ID: <7E699839-B425-44E6-9662-3641436853DB@oracle.com> On Mar 5, 2020, at 9:38 AM, Florian Weimer wrote: > > * John Rose: > >> http://cr.openjdk.java.net/~jrose/values/atomic-8236522 > > NonTearable says this: > > 38 *

An inline instance of multiple components is said to be "torn" > 39 * when two racing threads compete to update those components, and one > 40 * thread updates some components while another thread updates other > 41 * components. The resulting inline value stored in the heap might be > > I think this description is incorrect: a single writer, single reader > scenario (with final fields in the inline class even) can also result > in invalid values. See ?Inline classes and the memory model? posted > today; failed to spot the relevance of this older thread. Thanks for the comment. The language here is unfortunate, since ?update? seems to suggest that the problem can?t occur when one of the writes is the original initializing write. It can, of course, as you point out. I?ll change ?update? to ?write?. The tearing is observed by a subsequent read. If the two writes race, and/or if the read races with one of the writes (the JMM defines both as races) tearing can occur. > I think the actual goal here is to preserve the property that data > races cannot observe out-of-thin-air values, like it is impossible > with a subset of the primitive types? And also to support some > concept of safe publication for inline classes? Yes, that is the actual goal. Note that OOTA can come from other sources besides tearing (of primitives or structs), so we go with the more specific characterization of the problem with value types. They are like longs, liable to have racing updates to their subparts. As with longs, the experience of the user is ?hey, I didn?t store that value!?. Followed by, ?how am I going to enforce my invariants?? The JVM implements this by applying whatever tactics it already uses for volatile value fields (which like volatile long fields are protected from tearing and hence OOTA). Today these tactics are simply boxing under the covers, so we get back to safe publication, instance by instance. (The identity of the internal boxes continues to be hidden.) In the future we might experiment with more performant techniques, such as putting a seq-lock on the container. A natural place for such a seq-lock is in the containing object header, adjoined to the object?s natural monitor. The effect of implementing NonTearable is to ensure, at the declaration site of the type, that all heap variables of the type, without exception (including in arrays) are implemented with anti-tearing tactics. Non-heap uses of the type are unaffected, so the value can still be passed in registers and optimized without the need for escape analysis. ? John From david.holmes at oracle.com Sun Mar 8 23:09:51 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Mar 2020 09:09:51 +1000 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> Message-ID: Hi John, On 7/03/2020 7:45 am, John Rose wrote: > Nice work, very thorough as usual. Thanks - and thanks for looking at this. > One nit. The back-to-back parens are bad style. > >> foo (bar)(baz) > > https://english.stackexchange.com/questions/19429/should-i-use-adjacent-parentheses-or-a-semicolon-or-something-else > https://blog.apastyle.org/apastyle/2013/05/punctuation-junction-parentheses-and-brackets.html Okay - hadn't realized there was an applicable style here as I was just implementing a multi-part message by a simple concatenation of () delimited segments. > There are different ways to handle this in professional text. > I think the simplest way is relatively tricky from our perspective. > You merge the two parentheticals with an internal semicolon: > >> foo (bar; baz) I think that would make it very hard to spot the changeover. > A really simple tweak to your code would be to put a comma > between. This is less standard but better than back-to-back > parens: > > -+ ss.print("("); > ++ ss.print(?, (?); > > (Two places.) Ok - that works for me. > Likewise, in two places: > > -+ msg = "(stuff?)"; > ++ msg = " (stuff?)?; > > ?to avoid the left paren making hard contact with the preceding text. If this is referring to instanceKlass.cpp: 363 msg = "(the NestHost attribute in the current class is ignored)"; 364 } else if (_nest_members != NULL && _nest_members != Universe::the_empty_short_array()) { 365 msg = "(the NestMembers attribute in the current class is ignored)"; then the space is part of the main formatted string: 367 log_trace(class, nestmates)("Injected type %s into the nest of %s %s", 368 this->external_name(), 369 host->external_name(), 370 msg); > Klass::_nest_host_res_error is ok. If we ever decide to reduce the > footprint there (as part of a larger effort, I think), we could merge > both fields by using a tagged pointer, on the observation that you > only need one or the other to be non-null. If the res-error is not > null, then we can infer that nest-host has been determined to be > self, and in that case we don?t need to look at the field, right? A non-NULL res-err does imply _nest_host == this. But not vice-versa. > You might want to add a comment about the possible states of > those two coupled variables, to help maintainers. For example: > > + // This variable is non-null only if _nest_host is null. > > Actually, I didn?t follow the logic fully: Can both fields be non-null > at the same time? It looks like Klass::nest_host only gets set non-null > on error-free paths, while the error string is set only on error paths. > It would be reasonable for Klass::nest_host to check for an error > string and immediately return ?this? if one is set. I didn?t see this. > > Maybe the comment should be: > > + // This variable is non-null only if _nest_host is this or (during a race) null. > > (And if there?s a race, please do a releasing store of the error string before > setting the _nest_host to ?this?. But at-least-one-always-null is a safer > convention for managing races. So I like the first comment much better.) _nest_host is always set, even when there is an error. So nest_host() does a quick return in all calls other than the first (modulo the rare case where we had to bail out because we are in a compiler thread; or VME occurred): 226 InstanceKlass* InstanceKlass::nest_host(TRAPS) { 227 InstanceKlass* nest_host_k = _nest_host; 228 if (nest_host_k != NULL) { 229 return nest_host_k; 230 } I can't see any way to reduce footprint in this area as we have two very distinct entities we are tracking. > Also, let?s talk about VirtualMachineError. > > After thinking about it a bit, I think you went too far replacing CATCH > by THREAD; this makes a fragile assumption that nothing is coming > out of the call. It?s fragile because, although we expect LinkageError, > there?s usually an additional possibility of VirtualMachineError. > Doing a catch-and-clear of VME is risky business, and in this case > I only think we need to catch and clear the LE, not the VME. > > To me, it seems safest to always expect VME, and always pass it on, > as a basic convention in our code base, with clear documentation > wherever we do something different. > > Imagine getting an access error later on, with the parenthetical > remark that the nest host failed due to SOE or OOME. Those guys > should be fail-fast, I think. Or did you come up with a reason they > should be muzzled also, along with the LE we intend to muzzle? > > I see the previous code processed VME differently, and that you > removed it, so I know you did this as a considered step. But still > it seems off to me. At least add some documentation explaining > why it?s safe to drop VM errors. You are absolutely right, I went too far in clearing ALL pending exceptions. I need to check for VME and do immediate return in that case; and restore the CHECK usage in the callers. Not only should VMEs be fail-fast, but they are also cases where we should be allowed to retry determining the nest host. Updated webrevs: Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ (ciField.cpp and reflection.cpp are simply reverted) Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2/ Thanks, David > ? John > From david.holmes at oracle.com Sun Mar 8 23:10:34 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Mar 2020 09:10:34 +1000 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: <42767acd-3ce0-bb3c-7132-cb6ce214f5e7@oracle.com> References: <42767acd-3ce0-bb3c-7132-cb6ce214f5e7@oracle.com> Message-ID: <7018f7b2-2fc0-f52b-c8e5-91caf6a022d0@oracle.com> Hi Mandy, Thanks for taking a look. Please see response to John for updated webrevs. David On 7/03/2020 4:23 am, Mandy Chung wrote: > > Hi David, > > On 3/5/20 9:29 PM, David Holmes wrote: >> webrev: http://cr.openjdk.java.net/~dholmes/8240645/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8240645 >> > > This patch looks good to me. > > Thanks for the detail below which is very helpful.? It's okay with me > that IAE thrown by core reflection and lookup MethodHandle is not > extended with the memoized nest host error message in this release. We > could improve it in the future. > > Mandy >> JEP-371 (Hidden Classes) is changing a key aspect of nest host >> resolution and validation compared to what we shipped originally for >> JEP-181 (Nestmates). Originally, any LinkageErrors during nest host >> resolution would be propagated, and any validation failures would >> result in IncompatibleClassChangeError being thrown. Now no >> LinkageErrors are thrown, but the fact one occurred is remembered for >> potential use if a private access check fails. Similarly, validation >> failures don't cause an exception any more. Nest host resolution >> always succeeds and the nest will be one of: >> - the successfully resolved nest host as per the NestHost attribute >> - the class itself if there is no NestHost attribute or there is an >> error during resolution or validation >> - the specified nest host explicitly set if this is a hidden class >> injected into a nest >> >> as appropriate. >> >> This has a flow on affect to the reflection method >> Class::getNestMembers() which can also no longer ever fail. >> >> To be able to diagnose issues with nest host resolution/validation you >> can use unified logging to examine what happens: >> -Xlog:class+nestmates=trace. >> >> In addition IllegakAccessErrors thrown by the VM are augmented with >> information about any nest host resolution/validation errors. For >> example an original exception: >> >> java.lang.IllegalAccessError: class TestNestmateMembership$Caller >> tried to access private method 'void >> TestNestmateMembership$TargetSelfHost.m()' >> (TestNestmateMembership$Caller and >> TestNestmateMembership$TargetSelfHost are in unnamed module of loader >> 'app') >> >> is now expanded with an additional "()" >> section which is memoized for use with other access checks: >> >> java.lang.IllegalAccessError: class TestNestmateMembership$Caller >> tried to access private method 'void >> TestNestmateMembership$TargetSelfHost.m()' >> (TestNestmateMembership$Caller and >> TestNestmateMembership$TargetSelfHost are in unnamed module of loader >> 'app')(Type TestNestmateMembership$TargetSelfHost (loader: 'app') is >> not a nest member of type TestNestmateMembership$TargetSelfHost >> (loader: 'app'): current type is not listed as a nest member) >> >> These exception messages are very long and unweildy but that seems >> unavoidable. They appear repetative in that the type names appear in >> the main message, the module information, and then again in the >> resolution error section. Unfortunately we can't avoid that as the >> memoized string has to be complete because it does not know the >> context of the IllegalAccessError in which it will be used. Please >> look at the mechanism by which this is done before making suggestions >> on how to condense. >> >> Also note that in the worst case there can be two nest host resolution >> errors reported, if both the current class and the target class had >> such errors. >> >> Note: the augmented exceptions do not extend to >> IllegalAccessExceptions thrown by the Java reflection or MethodHandle >> code. This would require an additional VM call to retrieve the >> information. This may be considered for a future RFE. >> >> Changes in detail: >> >> - src/hotspot/share/ci/ciField.cpp >> - src/hotspot/share/classfile/classFileParser.cpp >> - src/hotspot/share/runtime/reflection.cpp >> >> No longer a possibility of exceptions >> >> -? src/hotspot/share/interpreter/linkResolver.cpp >> >> Expands on the message for IllegalAccessErrors in the private case, to >> report any nest host resolution/validation errors. >> >> -? src/hotspot/share/oops/instanceKlass.cpp >> >> Implements the new specification for resolving the nest host, and adds >> the means to memoize the error message. The same message is used for >> exceptions and logging. >> >> Exception handling is changed as needed - no use of CHECK macros. >> >> Removed a case in has_nest_member where we would bail out if executing >> in a compiler thread and encountered an unresolved class entry in the >> CP. We previously bailed out as a precaution as the compiler thread >> can't load classes. I was surprised to find that I was hitting this >> code, and getting runtime failures because of it (not test failures). >> I don't see how the current changes would cause this. In any case the >> situation where actual class loading would be needed should be >> impossible - two classes of the same name within the same loader - so >> the bail out can be removed. >> >> Removed the recently added runtime_nest_host code which is no longer >> needed. >> >> -? src/hotspot/share/prims/jvm.cpp >> >> Some code simplifies now exceptions are no longer possible. >> >> JVM_GetNestMembers has major updates: >> - as we no longer bail out on error we may end up with holes in the >> array, so we have to copy across to an array of the exact size before >> returning. >> - added logging to aid in debugging >> >> -? src/hotspot/share/utilities/ostream.cpp >> >> Needed to add the ability for stringStream to return a C-Heap >> allocated buffer so we could use it for the memoized error messages. >> (This should probably be factored out to a separate RFE for mainline.) >> >> - src/java.base/share/classes/java/lang/Class.java >> >> Updated the specifications for getNestHost and getNestMembers as per >> Mandy's proposed spec updates (added missing @jvms links in >> getNestMembers()). Adjusted the implementation for the fact there are >> no longer any exceptions from the VM. >> >> - >> test/hotspot/jtreg/runtime/Nestmates/membership/TestNestmateMembership.java >> >> Had to change all the LinkageErrors/NoClassDefFoundErrors to be >> IllegalAccessError or IllegalAccessException and adjust the expected >> messages to check the underlying failure reasons. >> >> Other test adjusted as needed to account for no exceptions, and the >> changes to Class::getNestMembers(). >> >> Testing: all nestmate and hidden class tests under normal conditions. >> ???????? tiers 1 - 3 >> >> Thanks, >> David > From lois.foltan at oracle.com Mon Mar 9 16:18:43 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 9 Mar 2020 12:18:43 -0400 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> Message-ID: <9f5095ed-2edf-ea47-0056-8e593f83ef91@oracle.com> Hi David, Overall looks good.? I do have a couple of comments on the latest webrev. interpreter/linkResolver.cpp - lines 609-618 and 966-975, the if statements constructing the nest_host_error_1 and nest_host_error2 could be reduced to something like the following: ss.print(", (%s%s%s)", ?????????????? (nest_host_error1 != NULL) ? nest_host_error_1 : "", ?????????????? (nest_host_error1 != NULL && nest_host_error2 != NULL) ? ", " : "", ?????????????? (nest_host_error2 != NULL) ? nest_host_error2 : ""); oops/instanceKlass.cpp -? the error message constructed on line #321, would you consider dropping the "(loader: %s)"? part?? The only contexts that ik->nest_host_resolution_error() is called are in linkResolver.cpp which in both cases already reports the module & loader of each type.? It just seems to be redundant information. Thanks, Lois On 3/8/2020 7:09 PM, David Holmes wrote: > Hi John, > > On 7/03/2020 7:45 am, John Rose wrote: >> Nice work, very thorough as usual. > > Thanks - and thanks for looking at this. > >> One nit.? The back-to-back parens are bad style. >> >>> foo (bar)(baz) >> >> https://english.stackexchange.com/questions/19429/should-i-use-adjacent-parentheses-or-a-semicolon-or-something-else >> >> https://blog.apastyle.org/apastyle/2013/05/punctuation-junction-parentheses-and-brackets.html >> > > Okay - hadn't realized there was an applicable style here as I was > just implementing a multi-part message by a simple concatenation of () > delimited segments. > >> There are different ways to handle this in professional text. >> I think the simplest way is relatively tricky from our perspective. >> You merge the two parentheticals with an internal semicolon: >> >>> foo (bar; baz) > > I think that would make it very hard to spot the changeover. > >> A really simple tweak to your code would be to put a comma >> between.? This is less standard but better than back-to-back >> parens: >> >> -+??????? ss.print("("); >> ++??????? ss.print(?, (?); >> >> (Two places.) > > Ok - that works for me. > >> Likewise, in two places: >> >> -+????? msg = "(stuff?)"; >> ++????? msg = " (stuff?)?; >> >> ?to avoid the left paren making hard contact with the preceding text. > > If this is referring to instanceKlass.cpp: > > ?363?????? msg = "(the NestHost attribute in the current class is > ignored)"; > ?364???? } else if (_nest_members != NULL && _nest_members != > Universe::the_empty_short_array()) { > ?365?????? msg = "(the NestMembers attribute in the current class is > ignored)"; > > then the space is part of the main formatted string: > > ?367???? log_trace(class, nestmates)("Injected type %s into the nest > of %s %s", > ?368???????????????????????????????? this->external_name(), > ?369???????????????????????????????? host->external_name(), > ?370???????????????????????????????? msg); > > >> Klass::_nest_host_res_error is ok.? If we ever decide to reduce the >> footprint there (as part of a larger effort, I think), we could merge >> both fields by using a tagged pointer, on the observation that you >> only need one or the other to be non-null.? If the res-error is not >> null, then we can infer that nest-host has been determined to be >> self, and in that case we don?t need to look at the field, right? > > A non-NULL res-err does imply _nest_host == this. But not vice-versa. > >> You might want to add a comment about the possible states of >> those two coupled variables, to help maintainers.? For example: >> >> + // This variable is non-null only if _nest_host is null. >> >> Actually, I didn?t follow the logic fully:? Can both fields be non-null >> at the same time?? It looks like Klass::nest_host only gets set non-null >> on error-free paths, while the error string is set only on error paths. >> It would be reasonable for Klass::nest_host to check for an error >> string and immediately return ?this? if one is set.? I didn?t see this. >> >> Maybe the comment should be: >> >> + // This variable is non-null only if _nest_host is this or (during >> a race) null. >> >> (And if there?s a race, please do a releasing store of the error >> string before >> setting the _nest_host to ?this?.? But at-least-one-always-null is a >> safer >> convention for managing races.? So I like the first comment much >> better.) > > _nest_host is always set, even when there is an error. So nest_host() > does a quick return in all calls other than the first (modulo the rare > case where we had to bail out because we are in a compiler thread; or > VME occurred): > > ?226 InstanceKlass* InstanceKlass::nest_host(TRAPS) { > ?227?? InstanceKlass* nest_host_k = _nest_host; > ?228?? if (nest_host_k != NULL) { > ?229???? return nest_host_k; > ?230?? } > > I can't see any way to reduce footprint in this area as we have two > very distinct entities we are tracking. > >> Also, let?s talk about VirtualMachineError. >> >> After thinking about it a bit, I think you went too far replacing CATCH >> by THREAD; this makes a fragile assumption that nothing is coming >> out of the call.? It?s fragile because, although we expect LinkageError, >> there?s usually an additional possibility of VirtualMachineError. >> Doing a catch-and-clear of VME is risky business, and in this case >> I only think we need to catch and clear the LE, not the VME. >> >> To me, it seems safest to always expect VME, and always pass it on, >> as a basic convention in our code base, with clear documentation >> wherever we do something different. >> >> Imagine getting an access error later on, with the parenthetical >> remark that the nest host failed due to SOE or OOME.? Those guys >> should be fail-fast, I think.? Or did you come up with a reason they >> should be muzzled also, along with the LE we intend to muzzle? >> >> I see the previous code processed VME differently, and that you >> removed it, so I know you did this as a considered step.? But still >> it seems off to me.? At least add some documentation explaining >> why it?s safe to drop VM errors. > > You are absolutely right, I went too far in clearing ALL pending > exceptions. I need to check for VME and do immediate return in that > case; and restore the CHECK usage in the callers. Not only should VMEs > be fail-fast, but they are also cases where we should be allowed to > retry determining the nest host. > > Updated webrevs: > > Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ > > (ciField.cpp and reflection.cpp are simply reverted) > > Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2/ > > Thanks, > David > >> ? John >> From mandy.chung at oracle.com Mon Mar 9 21:00:57 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Mar 2020 14:00:57 -0700 Subject: CSR review for 8238358: Implementation of JEP 371: Hidden Classes Message-ID: <88406fa9-e363-d514-35c8-3c1829b9f60c@oracle.com> Please review the CSR proposed for JEP 371 Hidden Classes [1]. CSR: ? https://bugs.openjdk.java.net/browse/JDK-8238359 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 A brief summary of the changes: 1. A new Lookup::defineHiddenClass method is the API to create a hidden class. 2. A new Lookup.ClassOption enum class defines NESTMATE and WEAK 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. Class::getNestMembers is updated not to throw any exception when it fails ?? to validate the nest membership.? Instead this method will return all ?? members that are listed in `NestMembers` attribute if present and ?? determined to have the same nest host as this class. 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 proposes to update the implementation to match the spec - please also review: ?? https://bugs.openjdk.java.net/browse/JDK-8240338 This is tracked as a separate JBS issue JDK-8238195 that is fixed in this patch. The code review will be posted separately. Thanks Mandy [1] https://openjdk.java.net/jeps/371 [2] JDK-8230502 Add support in JVM TI and JDI for hidden classes [3] JDK-8219607 Add support in Graal and AOT for hidden and weak class [4] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006872.html From david.holmes at oracle.com Mon Mar 9 22:11:57 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2020 08:11:57 +1000 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: <9f5095ed-2edf-ea47-0056-8e593f83ef91@oracle.com> References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> <9f5095ed-2edf-ea47-0056-8e593f83ef91@oracle.com> Message-ID: <4479c9f1-7784-b49d-1178-d581bd594705@oracle.com> Hi Lois, On 10/03/2020 2:18 am, Lois Foltan wrote: > Hi David, > > Overall looks good.? I do have a couple of comments on the latest webrev. Thanks for taking a look. > interpreter/linkResolver.cpp > - lines 609-618 and 966-975, the if statements constructing the > nest_host_error_1 and nest_host_error2 could be reduced to something > like the following: > > ss.print(", (%s%s%s)", > ?????????????? (nest_host_error1 != NULL) ? nest_host_error_1 : "", > ?????????????? (nest_host_error1 != NULL && nest_host_error2 != NULL) ? > ", " : "", > ?????????????? (nest_host_error2 != NULL) ? nest_host_error2 : ""); Yes that looks much neater - thanks. > oops/instanceKlass.cpp > -? the error message constructed on line #321, would you consider > dropping the "(loader: %s)"? part?? The only contexts that > ik->nest_host_resolution_error() is called are in linkResolver.cpp which > in both cases already reports the module & loader of each type.? It just > seems to be redundant information. It is partially redundant, but that part is not (necessarily) reporting the loader info for the two types involved in the access, but one of those types and its purported nest host. We could potentially drop the loader part for the type (relying on the larger error message to report it earlier) but we would still want that information for the logging output. I was trying to keep the message production uniform for both the exception message and the logging; and using the same general format (arguably we could drop the loader information for all but the "types are in different packages" case). The price of that simplicity/uniformity is some redundancy. Given we don't really expect users to run into these error messages very often it doesn't seem unduly problematic. Thanks, David > Thanks, > Lois > > > > On 3/8/2020 7:09 PM, David Holmes wrote: >> Hi John, >> >> On 7/03/2020 7:45 am, John Rose wrote: >>> Nice work, very thorough as usual. >> >> Thanks - and thanks for looking at this. >> >>> One nit.? The back-to-back parens are bad style. >>> >>>> foo (bar)(baz) >>> >>> https://english.stackexchange.com/questions/19429/should-i-use-adjacent-parentheses-or-a-semicolon-or-something-else >>> >>> https://blog.apastyle.org/apastyle/2013/05/punctuation-junction-parentheses-and-brackets.html >>> >> >> Okay - hadn't realized there was an applicable style here as I was >> just implementing a multi-part message by a simple concatenation of () >> delimited segments. >> >>> There are different ways to handle this in professional text. >>> I think the simplest way is relatively tricky from our perspective. >>> You merge the two parentheticals with an internal semicolon: >>> >>>> foo (bar; baz) >> >> I think that would make it very hard to spot the changeover. >> >>> A really simple tweak to your code would be to put a comma >>> between.? This is less standard but better than back-to-back >>> parens: >>> >>> -+??????? ss.print("("); >>> ++??????? ss.print(?, (?); >>> >>> (Two places.) >> >> Ok - that works for me. >> >>> Likewise, in two places: >>> >>> -+????? msg = "(stuff?)"; >>> ++????? msg = " (stuff?)?; >>> >>> ?to avoid the left paren making hard contact with the preceding text. >> >> If this is referring to instanceKlass.cpp: >> >> ?363?????? msg = "(the NestHost attribute in the current class is >> ignored)"; >> ?364???? } else if (_nest_members != NULL && _nest_members != >> Universe::the_empty_short_array()) { >> ?365?????? msg = "(the NestMembers attribute in the current class is >> ignored)"; >> >> then the space is part of the main formatted string: >> >> ?367???? log_trace(class, nestmates)("Injected type %s into the nest >> of %s %s", >> ?368???????????????????????????????? this->external_name(), >> ?369???????????????????????????????? host->external_name(), >> ?370???????????????????????????????? msg); >> >> >>> Klass::_nest_host_res_error is ok.? If we ever decide to reduce the >>> footprint there (as part of a larger effort, I think), we could merge >>> both fields by using a tagged pointer, on the observation that you >>> only need one or the other to be non-null.? If the res-error is not >>> null, then we can infer that nest-host has been determined to be >>> self, and in that case we don?t need to look at the field, right? >> >> A non-NULL res-err does imply _nest_host == this. But not vice-versa. >> >>> You might want to add a comment about the possible states of >>> those two coupled variables, to help maintainers.? For example: >>> >>> + // This variable is non-null only if _nest_host is null. >>> >>> Actually, I didn?t follow the logic fully:? Can both fields be non-null >>> at the same time?? It looks like Klass::nest_host only gets set non-null >>> on error-free paths, while the error string is set only on error paths. >>> It would be reasonable for Klass::nest_host to check for an error >>> string and immediately return ?this? if one is set.? I didn?t see this. >>> >>> Maybe the comment should be: >>> >>> + // This variable is non-null only if _nest_host is this or (during >>> a race) null. >>> >>> (And if there?s a race, please do a releasing store of the error >>> string before >>> setting the _nest_host to ?this?.? But at-least-one-always-null is a >>> safer >>> convention for managing races.? So I like the first comment much >>> better.) >> >> _nest_host is always set, even when there is an error. So nest_host() >> does a quick return in all calls other than the first (modulo the rare >> case where we had to bail out because we are in a compiler thread; or >> VME occurred): >> >> ?226 InstanceKlass* InstanceKlass::nest_host(TRAPS) { >> ?227?? InstanceKlass* nest_host_k = _nest_host; >> ?228?? if (nest_host_k != NULL) { >> ?229???? return nest_host_k; >> ?230?? } >> >> I can't see any way to reduce footprint in this area as we have two >> very distinct entities we are tracking. >> >>> Also, let?s talk about VirtualMachineError. >>> >>> After thinking about it a bit, I think you went too far replacing CATCH >>> by THREAD; this makes a fragile assumption that nothing is coming >>> out of the call.? It?s fragile because, although we expect LinkageError, >>> there?s usually an additional possibility of VirtualMachineError. >>> Doing a catch-and-clear of VME is risky business, and in this case >>> I only think we need to catch and clear the LE, not the VME. >>> >>> To me, it seems safest to always expect VME, and always pass it on, >>> as a basic convention in our code base, with clear documentation >>> wherever we do something different. >>> >>> Imagine getting an access error later on, with the parenthetical >>> remark that the nest host failed due to SOE or OOME.? Those guys >>> should be fail-fast, I think.? Or did you come up with a reason they >>> should be muzzled also, along with the LE we intend to muzzle? >>> >>> I see the previous code processed VME differently, and that you >>> removed it, so I know you did this as a considered step.? But still >>> it seems off to me.? At least add some documentation explaining >>> why it?s safe to drop VM errors. >> >> You are absolutely right, I went too far in clearing ALL pending >> exceptions. I need to check for VME and do immediate return in that >> case; and restore the CHECK usage in the callers. Not only should VMEs >> be fail-fast, but they are also cases where we should be allowed to >> retry determining the nest host. >> >> Updated webrevs: >> >> Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ >> >> (ciField.cpp and reflection.cpp are simply reverted) >> >> Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2/ >> >> Thanks, >> David >> >>> ? John >>> > From david.simms at oracle.com Tue Mar 10 08:04:03 2020 From: david.simms at oracle.com (David Simms) Date: Tue, 10 Mar 2020 09:04:03 +0100 Subject: Transition project Valhalla to git and GitHub In-Reply-To: <853c9d43-2eb9-3009-e936-aeac70b33afd@oracle.com> References: <853c9d43-2eb9-3009-e936-aeac70b33afd@oracle.com> Message-ID: <3ce15943-2de8-7b04-d086-2e13463e25e5@oracle.com> So there is some delay due to a combination of timezones and a minor technical issue mail notifications (which we prefer to have working)... ...should be a day or two more. During this delay, it is totally okay push to the repository, a notice 10 minutes before the move will go out (even then individual commits can be moved after the fact). Cheers /David Simms On 26/02/20 10:35 am, David Simms wrote: > Hi all, > > You might have heard that there is an OpenJDK project named Skara > evaluating and trialing using Git for OpenJDK and GitHub for hosting > the repositories [1]. We have been asked to try out Git, GitHub and > the Skara tooling, as a means of validating, and to provide feedback > about the Project Skara effort. There is already a number of OpenJDK > projects using Git, GitHub and Skara: > - OpenJFX > - OpenJMC > - Loom > - Mobile > - Panama (the "foreign" branches) > - Skara > > A transition entails switching to Git as an SCM (see the Git manual > [2]), and the repository would be hosted on GitHub [3]. After the > transition, the current Mercurial repository would no longer be > updated. There is currently already a read-only mirror of Valhalla in > place [4], you can it use to try out Git and some of the tooling, > though submitting pull requests and pushing will not work (as it is a > read-only mirror). > > I suggest that project Valhalla transition to git, GitHub and Skara > and that we set the target date for the transition to around 2 weeks > from now. How about Monday the 9th of March? I also suggest we adopt > GitHub's pull request workflow together with the bots from project Skara. > > Adopting pull requests and the Skara bots means that the review > process would work partly through GitHub. In particular, all changes > must start out as pull requests. Skara automatically generates > webrevs, "RFR" emails and supports bi-directional syncing between > mailing lists and GitHub for those that prefer using webrev and the > mailing lists. If you are unfamiliar with GitHub and pull requests, I > suggest checking out GitHub's guide [5]. Note that project Skara also > provides CLI tools for interacting with GitHub for those that prefer > working from a terminal. You can find more info about these tools on > the Skara wiki page [6] or from the Skara README [7]. > > If you have any comments or questions regarding this transition, > please reply to this thread. > > Cheers, > Mr. Simms > > [1] : https://openjdk.java.net/jeps/369 > [2] : https://git-scm.com/docs/user-manual > [3] : https://github.com/ > [4] : https://github.com/openjdk/valhalla > [5] : https://guides.github.com/introduction/flow/ > [6] : https://wiki.openjdk.java.net/display/SKARA/Skara > [7] : https://github.com/openjdk/skara > From david.simms at oracle.com Tue Mar 10 15:28:25 2020 From: david.simms at oracle.com (David Simms) Date: Tue, 10 Mar 2020 16:28:25 +0100 Subject: Transition project Valhalla to git and GitHub In-Reply-To: <3ce15943-2de8-7b04-d086-2e13463e25e5@oracle.com> References: <853c9d43-2eb9-3009-e936-aeac70b33afd@oracle.com> <3ce15943-2de8-7b04-d086-2e13463e25e5@oracle.com> Message-ID: <884ca9ca-34e9-2101-fc4d-d1d5bfc7f6e0@oracle.com> New time: Wednesday March 11 at 07:30 CET Cheers /David Simms On 2020-03-10 09:04, David Simms wrote: > > So there is some delay due to a combination of timezones and a minor > technical issue mail notifications (which we prefer to have working)... > > ...should be a day or two more. > > During this delay, it is totally okay push to the repository, a notice > 10 minutes before the move will go out (even then individual commits > can be moved after the fact). > > Cheers > /David Simms > > > On 26/02/20 10:35 am, David Simms wrote: >> Hi all, >> >> You might have heard that there is an OpenJDK project named Skara >> evaluating and trialing using Git for OpenJDK and GitHub for hosting >> the repositories [1]. We have been asked to try out Git, GitHub and >> the Skara tooling, as a means of validating, and to provide feedback >> about the Project Skara effort. There is already a number of OpenJDK >> projects using Git, GitHub and Skara: >> - OpenJFX >> - OpenJMC >> - Loom >> - Mobile >> - Panama (the "foreign" branches) >> - Skara >> >> A transition entails switching to Git as an SCM (see the Git manual >> [2]), and the repository would be hosted on GitHub [3]. After the >> transition, the current Mercurial repository would no longer be >> updated. There is currently already a read-only mirror of Valhalla in >> place [4], you can it use to try out Git and some of the tooling, >> though submitting pull requests and pushing will not work (as it is a >> read-only mirror). >> >> I suggest that project Valhalla transition to git, GitHub and Skara >> and that we set the target date for the transition to around 2 weeks >> from now. How about Monday the 9th of March? I also suggest we adopt >> GitHub's pull request workflow together with the bots from project >> Skara. >> >> Adopting pull requests and the Skara bots means that the review >> process would work partly through GitHub. In particular, all changes >> must start out as pull requests. Skara automatically generates >> webrevs, "RFR" emails and supports bi-directional syncing between >> mailing lists and GitHub for those that prefer using webrev and the >> mailing lists. If you are unfamiliar with GitHub and pull requests, I >> suggest checking out GitHub's guide [5]. Note that project Skara also >> provides CLI tools for interacting with GitHub for those that prefer >> working from a terminal. You can find more info about these tools on >> the Skara wiki page [6] or from the Skara README [7]. >> >> If you have any comments or questions regarding this transition, >> please reply to this thread. >> >> Cheers, >> Mr. Simms >> >> [1] : https://openjdk.java.net/jeps/369 >> [2] : https://git-scm.com/docs/user-manual >> [3] : https://github.com/ >> [4] : https://github.com/openjdk/valhalla >> [5] : https://guides.github.com/introduction/flow/ >> [6] : https://wiki.openjdk.java.net/display/SKARA/Skara >> [7] : https://github.com/openjdk/skara >> > From mandy.chung at oracle.com Tue Mar 10 20:41:20 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 10 Mar 2020 20:41:20 +0000 Subject: hg: valhalla/valhalla: [nestmates] update defineHiddenClass spec per Dan's feedback Message-ID: <202003102041.02AKfLip027399@aojmv0008.oracle.com> Changeset: fef34a7683d6 Author: mchung Date: 2020-03-10 13:41 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/fef34a7683d6 [nestmates] update defineHiddenClass spec per Dan's feedback ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java From mandy.chung at oracle.com Tue Mar 10 23:28:59 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Mar 2020 16:28:59 -0700 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> Message-ID: <35b179aa-f6da-88ca-bc74-fdb62e3fbd41@oracle.com> On 3/8/20 4:09 PM, David Holmes wrote: > Updated webrevs: > > Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ > The VM change looks okay to me. Mandy From mandy.chung at oracle.com Tue Mar 10 23:55:43 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Mar 2020 16:55:43 -0700 Subject: Weak references to hidden classes - should be the default? In-Reply-To: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> Message-ID: <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> Brian, John, et al, Alex has given his feedback on the weak class feature (attached). Alex recommends to change the default of hidden classes be weak classes and introduce a ClassOption::STRONG option if it wants to ensure that the hidden class is not being reclaimed until the class loader becomes unreachable. See more details below. We tried to keep a hidden class be a normal class from JVM's point of view.? Classes in the VM implementation have the same lifecycle as the defining class loader.? In addition, LambdaForms and Nashorn are the only JDK use of hidden weak classes.? All others such as lambda metafactory and string concat use hidden (strong) classes as they are part of the target class' internal implementation and should be unloaded altogether. Hence strong reference to hidden classes is the default. What's your recommendation? Mandy -------- Forwarded Message -------- Subject: Weak references to hidden classes Date: Tue, 10 Mar 2020 16:16:50 -0700 From: Alex Buckley Organization: Oracle Corporation To: Mandy Chung JEP 371 says that a hidden class may be weakly referenced by its class loader. Which loader? The only loader with any connection to a hidden class is the loader nominated to serve as the defining loader by the API spec of defineHiddenClass. However, that spec doesn't say "The defining loader holds a strong reference to the hidden class" because no spec says anything about how a class loader refers to a class. (The only relationship we do specify is the other way around -- ClassLoader says "Every Class object contains a reference to the ClassLoader that defined it." -- and happily that relationship holds for a hidden class too.) Point is, it's odd for defineHiddenClass to standardize how a class loader refers to a hidden class when, conceptually, class loaders are not meant to "know" about hidden classes. (The connection between a defining loader and a hidden class is a mere accounting trick done to support the hidden class's own code. No class loader, not even that defining loader, knows how to respond to a class load request for the hidden class.) It's especially odd for defineHiddenClass's default to be a strong reference. That default aligns with ClassLoader::defineClass, the API we're trying to avoid, and doesn't align with Unsafe::defineAnonymousClass, the API we're trying to recreate! I understand there are performance reasons to want a loader to use a strong reference rather than a weak reference. Accepting that claim, I recommend having the implementation use a weak reference by default, having the spec allow that, then introducing ClassOption.STRONG to force a strong reference. That is, specify that: "In the absence of an option, the defining loader's relationship with the hidden class is unspecified, and the loader implementation may use a strong reference or a weak reference to keep track of the hidden class. If a hidden class is not strongly referenced by the class loader which is deemed to be its defining loader, then the hidden class can be unloaded when library code no longer refers to it. Library developers who wish to prevent the hidden class from being unloaded must ensure that its Class object is never reclaimed, or else use the ClassOption.STRONG option." I understand there is a concern that developers would not realize / be surprised by getting a weak reference as the default implementation. However, the planet-wide audience for defineHiddenClass is perhaps 500 developers. They already have to know what they're doing because the features of hidden classes are already more limited than the features of VM-anonymous classes., e.g., no constant pool patching. The usual "Java should save developers from making silly mistakes" rule doesn't apply here. Alex From david.holmes at oracle.com Wed Mar 11 03:30:40 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Mar 2020 13:30:40 +1000 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: <35b179aa-f6da-88ca-bc74-fdb62e3fbd41@oracle.com> References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> <35b179aa-f6da-88ca-bc74-fdb62e3fbd41@oracle.com> Message-ID: Thanks Mandy! David On 11/03/2020 9:28 am, Mandy Chung wrote: > > > On 3/8/20 4:09 PM, David Holmes wrote: >> Updated webrevs: >> >> Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ >> > > The VM change looks okay to me. > > Mandy > From john.r.rose at oracle.com Wed Mar 11 04:55:59 2020 From: john.r.rose at oracle.com (John Rose) Date: Tue, 10 Mar 2020 21:55:59 -0700 Subject: Weak references to hidden classes - should be the default? In-Reply-To: <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> Message-ID: <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> I agree with Alex. Class loaders map names to classes. It?s not natural *semantically* for a nameless class to have its lifetime determined by a class loader. It may be more natural *in our JVM implementation* (hence more performant, in the *current* implementation) to have a non-weak link, but let?s do this only if users request it explicitly. On Mar 10, 2020, at 4:55 PM, Mandy Chung wrote: > > Brian, John, et al, > > Alex has given his feedback on the weak class feature (attached). > > Alex recommends to change the default of hidden classes be weak classes and introduce a ClassOption::STRONG option if it wants to ensure that the hidden class is not being reclaimed until the class loader becomes unreachable. See more details below. > > We tried to keep a hidden class be a normal class from JVM's point of view. Classes in the VM implementation have the same lifecycle as the defining class loader. In addition, LambdaForms and Nashorn are the only JDK use of hidden weak classes. All others such as lambda metafactory and string concat use hidden (strong) classes as they are part of the target class' internal implementation and should be unloaded altogether. Hence strong reference to hidden classes is the default. > > What's your recommendation? > > Mandy > > > -------- Forwarded Message -------- > Subject: Weak references to hidden classes > Date: Tue, 10 Mar 2020 16:16:50 -0700 > From: Alex Buckley > Organization: Oracle Corporation > To: Mandy Chung > > JEP 371 says that a hidden class may be weakly referenced by its class loader. Which loader? The only loader with any connection to a hidden class is the loader nominated to serve as the defining loader by the API spec of defineHiddenClass. However, that spec doesn't say "The defining loader holds a strong reference to the hidden class" because no spec says anything about how a class loader refers to a class. > > (The only relationship we do specify is the other way around -- ClassLoader says "Every Class object contains a reference to the ClassLoader that defined it." -- and happily that relationship holds for a hidden class too.) > > Point is, it's odd for defineHiddenClass to standardize how a class loader refers to a hidden class when, conceptually, class loaders are not meant to "know" about hidden classes. > > (The connection between a defining loader and a hidden class is a mere accounting trick done to support the hidden class's own code. No class loader, not even that defining loader, knows how to respond to a class load request for the hidden class.) > > It's especially odd for defineHiddenClass's default to be a strong reference. That default aligns with ClassLoader::defineClass, the API we're trying to avoid, and doesn't align with Unsafe::defineAnonymousClass, the API we're trying to recreate! > > I understand there are performance reasons to want a loader to use a strong reference rather than a weak reference. Accepting that claim, I recommend having the implementation use a weak reference by default, having the spec allow that, then introducing ClassOption.STRONG to force a strong reference. That is, specify that: > > "In the absence of an option, the defining loader's relationship with the hidden class is unspecified, and the loader implementation may use a strong reference or a weak reference to keep track of the hidden class. If a hidden class is not strongly referenced by the class loader which is deemed to be its defining loader, then the hidden class can be unloaded when library code no longer refers to it. Library developers who wish to prevent the hidden class from being unloaded must ensure that its Class object is never reclaimed, or else use the ClassOption.STRONG option." > > I understand there is a concern that developers would not realize / be surprised by getting a weak reference as the default implementation. However, the planet-wide audience for defineHiddenClass is perhaps 500 developers. They already have to know what they're doing because the features of hidden classes are already more limited than the features of VM-anonymous classes., e.g., no constant pool patching. The usual "Java should save developers from making silly mistakes" rule doesn't apply here. > > Alex From david.holmes at oracle.com Wed Mar 11 05:25:47 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Mar 2020 15:25:47 +1000 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> Message-ID: John pointed out to me offline that there are now race conditions possible due to the setting of the error message. I had been lulled into a false sense of security by the overall idempotency of the operation. Simple fix is to introduce storestore barriers in a couple of places to ensure we write the error string, then the _nest_host_res_error field, then the _nest_host field, in that order. Commentary updated as well. This update also includes Lois's suggested cleanup in linkResolver.cpp. Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3-incr/ Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3/ Thanks, David On 9/03/2020 9:09 am, David Holmes wrote: > Hi John, > > On 7/03/2020 7:45 am, John Rose wrote: >> Nice work, very thorough as usual. > > Thanks - and thanks for looking at this. > >> One nit.? The back-to-back parens are bad style. >> >>> foo (bar)(baz) >> >> https://english.stackexchange.com/questions/19429/should-i-use-adjacent-parentheses-or-a-semicolon-or-something-else >> >> https://blog.apastyle.org/apastyle/2013/05/punctuation-junction-parentheses-and-brackets.html >> > > Okay - hadn't realized there was an applicable style here as I was just > implementing a multi-part message by a simple concatenation of () > delimited segments. > >> There are different ways to handle this in professional text. >> I think the simplest way is relatively tricky from our perspective. >> You merge the two parentheticals with an internal semicolon: >> >>> foo (bar; baz) > > I think that would make it very hard to spot the changeover. > >> A really simple tweak to your code would be to put a comma >> between.? This is less standard but better than back-to-back >> parens: >> >> -+??????? ss.print("("); >> ++??????? ss.print(?, (?); >> >> (Two places.) > > Ok - that works for me. > >> Likewise, in two places: >> >> -+????? msg = "(stuff?)"; >> ++????? msg = " (stuff?)?; >> >> ?to avoid the left paren making hard contact with the preceding text. > > If this is referring to instanceKlass.cpp: > > ?363?????? msg = "(the NestHost attribute in the current class is > ignored)"; > ?364???? } else if (_nest_members != NULL && _nest_members != > Universe::the_empty_short_array()) { > ?365?????? msg = "(the NestMembers attribute in the current class is > ignored)"; > > then the space is part of the main formatted string: > > ?367???? log_trace(class, nestmates)("Injected type %s into the nest of > %s %s", > ?368???????????????????????????????? this->external_name(), > ?369???????????????????????????????? host->external_name(), > ?370???????????????????????????????? msg); > > >> Klass::_nest_host_res_error is ok.? If we ever decide to reduce the >> footprint there (as part of a larger effort, I think), we could merge >> both fields by using a tagged pointer, on the observation that you >> only need one or the other to be non-null.? If the res-error is not >> null, then we can infer that nest-host has been determined to be >> self, and in that case we don?t need to look at the field, right? > > A non-NULL res-err does imply _nest_host == this. But not vice-versa. > >> You might want to add a comment about the possible states of >> those two coupled variables, to help maintainers.? For example: >> >> + // This variable is non-null only if _nest_host is null. >> >> Actually, I didn?t follow the logic fully:? Can both fields be non-null >> at the same time?? It looks like Klass::nest_host only gets set non-null >> on error-free paths, while the error string is set only on error paths. >> It would be reasonable for Klass::nest_host to check for an error >> string and immediately return ?this? if one is set.? I didn?t see this. >> >> Maybe the comment should be: >> >> + // This variable is non-null only if _nest_host is this or (during a >> race) null. >> >> (And if there?s a race, please do a releasing store of the error >> string before >> setting the _nest_host to ?this?.? But at-least-one-always-null is a >> safer >> convention for managing races.? So I like the first comment much better.) > > _nest_host is always set, even when there is an error. So nest_host() > does a quick return in all calls other than the first (modulo the rare > case where we had to bail out because we are in a compiler thread; or > VME occurred): > > ?226 InstanceKlass* InstanceKlass::nest_host(TRAPS) { > ?227?? InstanceKlass* nest_host_k = _nest_host; > ?228?? if (nest_host_k != NULL) { > ?229???? return nest_host_k; > ?230?? } > > I can't see any way to reduce footprint in this area as we have two very > distinct entities we are tracking. > >> Also, let?s talk about VirtualMachineError. >> >> After thinking about it a bit, I think you went too far replacing CATCH >> by THREAD; this makes a fragile assumption that nothing is coming >> out of the call.? It?s fragile because, although we expect LinkageError, >> there?s usually an additional possibility of VirtualMachineError. >> Doing a catch-and-clear of VME is risky business, and in this case >> I only think we need to catch and clear the LE, not the VME. >> >> To me, it seems safest to always expect VME, and always pass it on, >> as a basic convention in our code base, with clear documentation >> wherever we do something different. >> >> Imagine getting an access error later on, with the parenthetical >> remark that the nest host failed due to SOE or OOME.? Those guys >> should be fail-fast, I think.? Or did you come up with a reason they >> should be muzzled also, along with the LE we intend to muzzle? >> >> I see the previous code processed VME differently, and that you >> removed it, so I know you did this as a considered step.? But still >> it seems off to me.? At least add some documentation explaining >> why it?s safe to drop VM errors. > > You are absolutely right, I went too far in clearing ALL pending > exceptions. I need to check for VME and do immediate return in that > case; and restore the CHECK usage in the callers. Not only should VMEs > be fail-fast, but they are also cases where we should be allowed to > retry determining the nest host. > > Updated webrevs: > > Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ > > (ciField.cpp and reflection.cpp are simply reverted) > > Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2/ > > Thanks, > David > >> ? John >> From rwestberg at openjdk.java.net Wed Mar 11 09:31:01 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Wed, 11 Mar 2020 09:31:01 GMT Subject: [lworld] RFR: 8240863: Update .jcheck/conf for Valhalla lworld branch Message-ID: <0fERtinTpuYZhGJFjee39-jwlxGHMyuPUun0obu5k3Y=.1db570ad-52c7-4c34-85c9-0aafe37c8040@github.com> Hi all, Please review this change that updates the jcheck configuration to work with the Skara tooling. Best regards, Robin ------------- Commit messages: - Remove control characters - Initial jcheck configuration Changes: https://git.openjdk.java.net/valhalla/pull/1/files Webrev: https://webrevs.openjdk.java.net/valhalla/1/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240863 Stats: 35 lines in 1 file changed: 33 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/1.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/1/head:pull/1 PR: https://git.openjdk.java.net/valhalla/pull/1 From ehelin at openjdk.java.net Wed Mar 11 09:31:01 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Wed, 11 Mar 2020 09:31:01 GMT Subject: [lworld] RFR: 8240863: Update .jcheck/conf for Valhalla lworld branch In-Reply-To: <0fERtinTpuYZhGJFjee39-jwlxGHMyuPUun0obu5k3Y=.1db570ad-52c7-4c34-85c9-0aafe37c8040@github.com> References: <0fERtinTpuYZhGJFjee39-jwlxGHMyuPUun0obu5k3Y=.1db570ad-52c7-4c34-85c9-0aafe37c8040@github.com> Message-ID: On Wed, 11 Mar 2020 08:48:58 GMT, Robin Westberg wrote: > Hi all, > > Please review this change that updates the jcheck configuration to work with the Skara tooling. > > Best regards, > Robin Looks good! ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.java.net/valhalla/pull/1 From david.simms at oracle.com Wed Mar 11 10:05:37 2020 From: david.simms at oracle.com (David Simms) Date: Wed, 11 Mar 2020 11:05:37 +0100 Subject: Transition project Valhalla to git and GitHub In-Reply-To: <884ca9ca-34e9-2101-fc4d-d1d5bfc7f6e0@oracle.com> References: <853c9d43-2eb9-3009-e936-aeac70b33afd@oracle.com> <3ce15943-2de8-7b04-d086-2e13463e25e5@oracle.com> <884ca9ca-34e9-2101-fc4d-d1d5bfc7f6e0@oracle.com> Message-ID: And the transition of "lworld" branch to github is now complete. Current repository(s) status: * Only "lworld" branch has transitioned o "nestmates" remains in mercurial (also happens to be mirrored on github) * "master" (formerly "default" branch under mercurial) is now automatically up-to-date with "jdk mainline" o "lworld" is the "git default", meaning a new clone will have "lworld" branch already checked-out * For information on working on OpenJDK projects in github: o ?https://wiki.openjdk.java.net/display/SKARA * There is a known issue with push notifications, being worked on o ? https://bugs.openjdk.java.net/browse/SKARA-301 * Any Project Skara related issues and questions may be sent here: o skara-dev at openjdk.java.net Thanks to Erik Duveblad and Robin Westberg ! /David Simms On 10/03/20 4:28 pm, David Simms wrote: > > New time: Wednesday March 11 at 07:30 CET > > Cheers > /David Simms > > On 2020-03-10 09:04, David Simms wrote: >> >> So there is some delay due to a combination of timezones and a minor >> technical issue mail notifications (which we prefer to have working)... >> >> ...should be a day or two more. >> >> During this delay, it is totally okay push to the repository, a >> notice 10 minutes before the move will go out (even then individual >> commits can be moved after the fact). >> >> Cheers >> /David Simms >> >> >> On 26/02/20 10:35 am, David Simms wrote: >>> Hi all, >>> >>> You might have heard that there is an OpenJDK project named Skara >>> evaluating and trialing using Git for OpenJDK and GitHub for hosting >>> the repositories [1]. We have been asked to try out Git, GitHub and >>> the Skara tooling, as a means of validating, and to provide feedback >>> about the Project Skara effort. There is already a number of OpenJDK >>> projects using Git, GitHub and Skara: >>> - OpenJFX >>> - OpenJMC >>> - Loom >>> - Mobile >>> - Panama (the "foreign" branches) >>> - Skara >>> >>> A transition entails switching to Git as an SCM (see the Git manual >>> [2]), and the repository would be hosted on GitHub [3]. After the >>> transition, the current Mercurial repository would no longer be >>> updated. There is currently already a read-only mirror of Valhalla >>> in place [4], you can it use to try out Git and some of the tooling, >>> though submitting pull requests and pushing will not work (as it is >>> a read-only mirror). >>> >>> I suggest that project Valhalla transition to git, GitHub and Skara >>> and that we set the target date for the transition to around 2 weeks >>> from now. How about Monday the 9th of March? I also suggest we adopt >>> GitHub's pull request workflow together with the bots from project >>> Skara. >>> >>> Adopting pull requests and the Skara bots means that the review >>> process would work partly through GitHub. In particular, all changes >>> must start out as pull requests. Skara automatically generates >>> webrevs, "RFR" emails and supports bi-directional syncing between >>> mailing lists and GitHub for those that prefer using webrev and the >>> mailing lists. If you are unfamiliar with GitHub and pull requests, >>> I suggest checking out GitHub's guide [5]. Note that project Skara >>> also provides CLI tools for interacting with GitHub for those that >>> prefer working from a terminal. You can find more info about these >>> tools on the Skara wiki page [6] or from the Skara README [7]. >>> >>> If you have any comments or questions regarding this transition, >>> please reply to this thread. >>> >>> Cheers, >>> Mr. Simms >>> >>> [1] : https://openjdk.java.net/jeps/369 >>> [2] : https://git-scm.com/docs/user-manual >>> [3] : https://github.com/ >>> [4] : https://github.com/openjdk/valhalla >>> [5] : https://guides.github.com/introduction/flow/ >>> [6] : https://wiki.openjdk.java.net/display/SKARA/Skara >>> [7] : https://github.com/openjdk/skara >>> >> > From stanislav.smirnov at oracle.com Wed Mar 11 13:30:01 2020 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Wed, 11 Mar 2020 09:30:01 -0400 Subject: Transition project Valhalla to git and GitHub In-Reply-To: References: <853c9d43-2eb9-3009-e936-aeac70b33afd@oracle.com> <3ce15943-2de8-7b04-d086-2e13463e25e5@oracle.com> <884ca9ca-34e9-2101-fc4d-d1d5bfc7f6e0@oracle.com> Message-ID: <4CDC6054-04F9-4D28-A996-C2B807217076@oracle.com> Hi David, Do you want to start using the Git version of the repo in the Mach5 CI pipeline for the lworld branch? Best regards, Stanislav Smirnov > On Mar 11, 2020, at 6:05 AM, David Simms wrote: > > > And the transition of "lworld" branch to github is now complete. > > Current repository(s) status: > > * Only "lworld" branch has transitioned > o "nestmates" remains in mercurial (also happens to be mirrored on > github) > * "master" (formerly "default" branch under mercurial) is now > automatically up-to-date with "jdk mainline" > o "lworld" is the "git default", meaning a new clone will have > "lworld" branch already checked-out > * For information on working on OpenJDK projects in github: > o https://wiki.openjdk.java.net/display/SKARA > * There is a known issue with push notifications, being worked on > o https://bugs.openjdk.java.net/browse/SKARA-301 > * Any Project Skara related issues and questions may be sent here: > o skara-dev at openjdk.java.net > > > Thanks to Erik Duveblad and Robin Westberg ! > > /David Simms > > > On 10/03/20 4:28 pm, David Simms wrote: >> >> New time: Wednesday March 11 at 07:30 CET >> >> Cheers >> /David Simms >> >> On 2020-03-10 09:04, David Simms wrote: >>> >>> So there is some delay due to a combination of timezones and a minor technical issue mail notifications (which we prefer to have working)... >>> >>> ...should be a day or two more. >>> >>> During this delay, it is totally okay push to the repository, a notice 10 minutes before the move will go out (even then individual commits can be moved after the fact). >>> >>> Cheers >>> /David Simms >>> >>> >>> On 26/02/20 10:35 am, David Simms wrote: >>>> Hi all, >>>> >>>> You might have heard that there is an OpenJDK project named Skara evaluating and trialing using Git for OpenJDK and GitHub for hosting the repositories [1]. We have been asked to try out Git, GitHub and the Skara tooling, as a means of validating, and to provide feedback about the Project Skara effort. There is already a number of OpenJDK projects using Git, GitHub and Skara: >>>> - OpenJFX >>>> - OpenJMC >>>> - Loom >>>> - Mobile >>>> - Panama (the "foreign" branches) >>>> - Skara >>>> >>>> A transition entails switching to Git as an SCM (see the Git manual [2]), and the repository would be hosted on GitHub [3]. After the transition, the current Mercurial repository would no longer be updated. There is currently already a read-only mirror of Valhalla in place [4], you can it use to try out Git and some of the tooling, though submitting pull requests and pushing will not work (as it is a read-only mirror). >>>> >>>> I suggest that project Valhalla transition to git, GitHub and Skara and that we set the target date for the transition to around 2 weeks from now. How about Monday the 9th of March? I also suggest we adopt GitHub's pull request workflow together with the bots from project Skara. >>>> >>>> Adopting pull requests and the Skara bots means that the review process would work partly through GitHub. In particular, all changes must start out as pull requests. Skara automatically generates webrevs, "RFR" emails and supports bi-directional syncing between mailing lists and GitHub for those that prefer using webrev and the mailing lists. If you are unfamiliar with GitHub and pull requests, I suggest checking out GitHub's guide [5]. Note that project Skara also provides CLI tools for interacting with GitHub for those that prefer working from a terminal. You can find more info about these tools on the Skara wiki page [6] or from the Skara README [7]. >>>> >>>> If you have any comments or questions regarding this transition, please reply to this thread. >>>> >>>> Cheers, >>>> Mr. Simms >>>> >>>> [1] : https://openjdk.java.net/jeps/369 >>>> [2] : https://git-scm.com/docs/user-manual >>>> [3] : https://github.com/ >>>> [4] : https://github.com/openjdk/valhalla >>>> [5] : https://guides.github.com/introduction/flow/ >>>> [6] : https://wiki.openjdk.java.net/display/SKARA/Skara >>>> [7] : https://github.com/openjdk/skara >>>> >>> >> > From rwestberg at openjdk.java.net Wed Mar 11 16:20:44 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Wed, 11 Mar 2020 16:20:44 GMT Subject: [Integrated] [lworld] RFR: 8240863: Update .jcheck/conf for Valhalla lworld branch In-Reply-To: <0fERtinTpuYZhGJFjee39-jwlxGHMyuPUun0obu5k3Y=.1db570ad-52c7-4c34-85c9-0aafe37c8040@github.com> References: <0fERtinTpuYZhGJFjee39-jwlxGHMyuPUun0obu5k3Y=.1db570ad-52c7-4c34-85c9-0aafe37c8040@github.com> Message-ID: Changeset: 092f6420 Author: Robin Westberg Date: 2020-03-11 09:32:57 +0000 URL: https://git.openjdk.java.net/valhalla/commit/092f6420 8240863: Update .jcheck/conf for Valhalla lworld branch Reviewed-by: ehelin ! .jcheck/conf From mandy.chung at oracle.com Wed Mar 11 22:12:53 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 Mar 2020 15:12:53 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> Message-ID: <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ Alex suggests to keep the default unspecified, which I think it's a great suggestion such that people do not have to rely on the implementation assumption. This patch adds a new ClassOption::STRONG enum constant while keeping ClassOption::WEAK. Mandy On 3/10/20 9:55 PM, John Rose wrote: > I agree with Alex. ?Class loaders map names to classes. ?It?s not > natural *semantically* for a nameless class to have its lifetime > determined by a class loader. ?It may be more natural *in our > JVM implementation* (hence more performant, in the *current* > implementation) to have a non-weak link, but let?s do this only > if users request it explicitly. > > On Mar 10, 2020, at 4:55 PM, Mandy Chung > wrote: >> >> Brian, John, et al, >> >> Alex has given his feedback on the weak class feature (attached). >> >> Alex recommends to change the default of hidden classes be weak >> classes and introduce a ClassOption::STRONG option if it wants to >> ensure that the hidden class is not being reclaimed until the class >> loader becomes unreachable.? See more details below. >> >> We tried to keep a hidden class be a normal class from JVM's point of >> view.? Classes in the VM implementation have the same lifecycle as >> the defining class loader. In addition, LambdaForms and Nashorn are >> the only JDK use of hidden weak classes.? All others such as lambda >> metafactory and string concat use hidden (strong) classes as they are >> part of the target class' internal implementation and should be >> unloaded altogether. Hence strong reference to hidden classes is the >> default. >> >> What's your recommendation? >> >> Mandy >> >> >> -------- Forwarded Message -------- >> Subject: Weak references to hidden classes >> Date: Tue, 10 Mar 2020 16:16:50 -0700 >> From: Alex Buckley >> Organization: Oracle Corporation >> To: Mandy Chung >> >> >> >> JEP 371 says that a hidden class may be weakly referenced by its >> class loader. Which loader? The only loader with any connection to a >> hidden class is the loader nominated to serve as the defining loader >> by the API spec of defineHiddenClass. However, that spec doesn't say >> "The defining loader holds a strong reference to the hidden class" >> because no spec says anything about how a class loader refers to a class. >> >> (The only relationship we do specify is the other way around -- >> ClassLoader says "Every Class object contains a reference to the >> ClassLoader that defined it." -- and happily that relationship holds >> for a hidden class too.) >> >> Point is, it's odd for defineHiddenClass to standardize how a class >> loader refers to a hidden class when, conceptually, class loaders are >> not meant to "know" about hidden classes. >> >> (The connection between a defining loader and a hidden class is a >> mere accounting trick done to support the hidden class's own code. No >> class loader, not even that defining loader, knows how to respond to >> a class load request for the hidden class.) >> >> It's especially odd for defineHiddenClass's default to be a strong >> reference. That default aligns with ClassLoader::defineClass, the API >> we're trying to avoid, and doesn't align with >> Unsafe::defineAnonymousClass, the API we're trying to recreate! >> >> I understand there are performance reasons to want a loader to use a >> strong reference rather than a weak reference. Accepting that claim, >> I recommend having the implementation use a weak reference by >> default, having the spec allow that, then introducing >> ClassOption.STRONG to force a strong reference. That is, specify that: >> >> "In the absence of an option, the defining loader's relationship with >> the hidden class is unspecified, and the loader implementation may >> use a strong reference or a weak reference to keep track of the >> hidden class. If a hidden class is not strongly referenced by the >> class loader which is deemed to be its defining loader, then the >> hidden class can be unloaded when library code no longer refers to >> it. Library developers who wish to prevent the hidden class from >> being unloaded must ensure that its Class object is never reclaimed, >> or else use the ClassOption.STRONG option." >> >> I understand there is a concern that developers would not realize / >> be surprised by getting a weak reference as the default >> implementation. However, the planet-wide audience for >> defineHiddenClass is perhaps 500 developers. They already have to >> know what they're doing because the features of hidden classes are >> already more limited than the features of VM-anonymous classes., >> e.g., no constant pool patching. The usual "Java should save >> developers from making silly mistakes" rule doesn't apply here. >> >> Alex > From david.holmes at oracle.com Wed Mar 11 22:34:16 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2020 08:34:16 +1000 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> Message-ID: <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> Hi Mandy, On 12/03/2020 8:12 am, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ > > > Alex suggests to keep the default unspecified, which I think it's a > great suggestion such that people do not have to rely on the > implementation assumption. I think this is making things unnecessarily awkward. The suggestion from yesterday (as per below) was to change the default to be weak, and allow people to ask for strong. That would involve simply changing all WEAK to STRONG through the existing code. Now we have WEAK and STRONG that are mutually exclusive so have to check for them both being set, and if neither is set then we fall into implementation-specific behaviour. If it is insisted that we have both WEAK and STRONG then we can achieve having the default unspecified by requiring that one of them always be passed in. But I much prefer what was suggested previously: either default is strong and you can ask for weak; or default is weak and you can ask for strong. Sorry. David > This patch adds a new ClassOption::STRONG enum constant while keeping > ClassOption::WEAK. > Mandy > > On 3/10/20 9:55 PM, John Rose wrote: >> I agree with Alex. ?Class loaders map names to classes. ?It?s not >> natural *semantically* for a nameless class to have its lifetime >> determined by a class loader. ?It may be more natural *in our >> JVM implementation* (hence more performant, in the *current* >> implementation) to have a non-weak link, but let?s do this only >> if users request it explicitly. >> >> On Mar 10, 2020, at 4:55 PM, Mandy Chung > > wrote: >>> >>> Brian, John, et al, >>> >>> Alex has given his feedback on the weak class feature (attached). >>> >>> Alex recommends to change the default of hidden classes be weak >>> classes and introduce a ClassOption::STRONG option if it wants to >>> ensure that the hidden class is not being reclaimed until the class >>> loader becomes unreachable.? See more details below. >>> >>> We tried to keep a hidden class be a normal class from JVM's point of >>> view.? Classes in the VM implementation have the same lifecycle as >>> the defining class loader. In addition, LambdaForms and Nashorn are >>> the only JDK use of hidden weak classes.? All others such as lambda >>> metafactory and string concat use hidden (strong) classes as they are >>> part of the target class' internal implementation and should be >>> unloaded altogether. Hence strong reference to hidden classes is the >>> default. >>> >>> What's your recommendation? >>> >>> Mandy >>> >>> >>> -------- Forwarded Message -------- >>> Subject:???? Weak references to hidden classes >>> Date:???? Tue, 10 Mar 2020 16:16:50 -0700 >>> From:???? Alex Buckley >>> Organization:???? Oracle Corporation >>> To:???? Mandy Chung >>> >>> >>> >>> JEP 371 says that a hidden class may be weakly referenced by its >>> class loader. Which loader? The only loader with any connection to a >>> hidden class is the loader nominated to serve as the defining loader >>> by the API spec of defineHiddenClass. However, that spec doesn't say >>> "The defining loader holds a strong reference to the hidden class" >>> because no spec says anything about how a class loader refers to a >>> class. >>> >>> (The only relationship we do specify is the other way around -- >>> ClassLoader says "Every Class object contains a reference to the >>> ClassLoader that defined it." -- and happily that relationship holds >>> for a hidden class too.) >>> >>> Point is, it's odd for defineHiddenClass to standardize how a class >>> loader refers to a hidden class when, conceptually, class loaders are >>> not meant to "know" about hidden classes. >>> >>> (The connection between a defining loader and a hidden class is a >>> mere accounting trick done to support the hidden class's own code. No >>> class loader, not even that defining loader, knows how to respond to >>> a class load request for the hidden class.) >>> >>> It's especially odd for defineHiddenClass's default to be a strong >>> reference. That default aligns with ClassLoader::defineClass, the API >>> we're trying to avoid, and doesn't align with >>> Unsafe::defineAnonymousClass, the API we're trying to recreate! >>> >>> I understand there are performance reasons to want a loader to use a >>> strong reference rather than a weak reference. Accepting that claim, >>> I recommend having the implementation use a weak reference by >>> default, having the spec allow that, then introducing >>> ClassOption.STRONG to force a strong reference. That is, specify that: >>> >>> "In the absence of an option, the defining loader's relationship with >>> the hidden class is unspecified, and the loader implementation may >>> use a strong reference or a weak reference to keep track of the >>> hidden class. If a hidden class is not strongly referenced by the >>> class loader which is deemed to be its defining loader, then the >>> hidden class can be unloaded when library code no longer refers to >>> it. Library developers who wish to prevent the hidden class from >>> being unloaded must ensure that its Class object is never reclaimed, >>> or else use the ClassOption.STRONG option." >>> >>> I understand there is a concern that developers would not realize / >>> be surprised by getting a weak reference as the default >>> implementation. However, the planet-wide audience for >>> defineHiddenClass is perhaps 500 developers. They already have to >>> know what they're doing because the features of hidden classes are >>> already more limited than the features of VM-anonymous classes., >>> e.g., no constant pool patching. The usual "Java should save >>> developers from making silly mistakes" rule doesn't apply here. >>> >>> Alex >> > From mandy.chung at oracle.com Wed Mar 11 23:05:04 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 Mar 2020 16:05:04 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> Message-ID: <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> On 3/11/20 3:34 PM, David Holmes wrote: > Hi Mandy, > > On 12/03/2020 8:12 am, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ >> >> >> Alex suggests to keep the default unspecified, which I think it's a >> great suggestion such that people do not have to rely on the >> implementation assumption. > > I think this is making things unnecessarily awkward. The suggestion > from yesterday (as per below) was to change the default to be weak, > and allow people to ask for strong. That would involve simply changing > all WEAK to STRONG through the existing code. Now we have WEAK and > STRONG that are mutually exclusive so have to check for them both > being set, and if neither is set then we fall into > implementation-specific behaviour. > If it is insisted that we have both WEAK and STRONG then we can > achieve having the default unspecified by requiring that one of them > always be passed in. There are cases that the library code does not care. Note that the main motivation to allow a hidden class be strongly referenced because of our current implementation.?? It creates a ClassLoaderData per weak class that may result in fragmentation and incur bad performance overhead. This is solely implementation detail.? Other VM implementation may favor weak classes.? An implementation-specific default will give flexibility to the developers (not to specify neither strong or weak) to choose whatever performs best when running on a VM implementation. Mandy > But I much prefer what was suggested previously: either default is > strong and you can ask for weak; or default is weak and you can ask > for strong. > > Sorry. > > David > >> This patch adds a new ClassOption::STRONG enum constant while keeping >> ClassOption::WEAK. > >> Mandy >> >> On 3/10/20 9:55 PM, John Rose wrote: >>> I agree with Alex. ?Class loaders map names to classes. ?It?s not >>> natural *semantically* for a nameless class to have its lifetime >>> determined by a class loader. ?It may be more natural *in our >>> JVM implementation* (hence more performant, in the *current* >>> implementation) to have a non-weak link, but let?s do this only >>> if users request it explicitly. >>> >>> On Mar 10, 2020, at 4:55 PM, Mandy Chung >> > wrote: >>>> >>>> Brian, John, et al, >>>> >>>> Alex has given his feedback on the weak class feature (attached). >>>> >>>> Alex recommends to change the default of hidden classes be weak >>>> classes and introduce a ClassOption::STRONG option if it wants to >>>> ensure that the hidden class is not being reclaimed until the class >>>> loader becomes unreachable.? See more details below. >>>> >>>> We tried to keep a hidden class be a normal class from JVM's point >>>> of view.? Classes in the VM implementation have the same lifecycle >>>> as the defining class loader. In addition, LambdaForms and Nashorn >>>> are the only JDK use of hidden weak classes.? All others such as >>>> lambda metafactory and string concat use hidden (strong) classes as >>>> they are part of the target class' internal implementation and >>>> should be unloaded altogether. Hence strong reference to hidden >>>> classes is the default. >>>> >>>> What's your recommendation? >>>> >>>> Mandy >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject:???? Weak references to hidden classes >>>> Date:???? Tue, 10 Mar 2020 16:16:50 -0700 >>>> From:???? Alex Buckley >>>> Organization:???? Oracle Corporation >>>> To:???? Mandy Chung >>>> >>>> >>>> >>>> JEP 371 says that a hidden class may be weakly referenced by its >>>> class loader. Which loader? The only loader with any connection to >>>> a hidden class is the loader nominated to serve as the defining >>>> loader by the API spec of defineHiddenClass. However, that spec >>>> doesn't say "The defining loader holds a strong reference to the >>>> hidden class" because no spec says anything about how a class >>>> loader refers to a class. >>>> >>>> (The only relationship we do specify is the other way around -- >>>> ClassLoader says "Every Class object contains a reference to the >>>> ClassLoader that defined it." -- and happily that relationship >>>> holds for a hidden class too.) >>>> >>>> Point is, it's odd for defineHiddenClass to standardize how a class >>>> loader refers to a hidden class when, conceptually, class loaders >>>> are not meant to "know" about hidden classes. >>>> >>>> (The connection between a defining loader and a hidden class is a >>>> mere accounting trick done to support the hidden class's own code. >>>> No class loader, not even that defining loader, knows how to >>>> respond to a class load request for the hidden class.) >>>> >>>> It's especially odd for defineHiddenClass's default to be a strong >>>> reference. That default aligns with ClassLoader::defineClass, the >>>> API we're trying to avoid, and doesn't align with >>>> Unsafe::defineAnonymousClass, the API we're trying to recreate! >>>> >>>> I understand there are performance reasons to want a loader to use >>>> a strong reference rather than a weak reference. Accepting that >>>> claim, I recommend having the implementation use a weak reference >>>> by default, having the spec allow that, then introducing >>>> ClassOption.STRONG to force a strong reference. That is, specify that: >>>> >>>> "In the absence of an option, the defining loader's relationship >>>> with the hidden class is unspecified, and the loader implementation >>>> may use a strong reference or a weak reference to keep track of the >>>> hidden class. If a hidden class is not strongly referenced by the >>>> class loader which is deemed to be its defining loader, then the >>>> hidden class can be unloaded when library code no longer refers to >>>> it. Library developers who wish to prevent the hidden class from >>>> being unloaded must ensure that its Class object is never >>>> reclaimed, or else use the ClassOption.STRONG option." >>>> >>>> I understand there is a concern that developers would not realize / >>>> be surprised by getting a weak reference as the default >>>> implementation. However, the planet-wide audience for >>>> defineHiddenClass is perhaps 500 developers. They already have to >>>> know what they're doing because the features of hidden classes are >>>> already more limited than the features of VM-anonymous classes., >>>> e.g., no constant pool patching. The usual "Java should save >>>> developers from making silly mistakes" rule doesn't apply here. >>>> >>>> Alex >>> >> From mandy.chung at oracle.com Thu Mar 12 00:01:48 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 Mar 2020 17:01:48 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <5d0822c5-5cc0-913f-2d21-520864e49364@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <5d0822c5-5cc0-913f-2d21-520864e49364@oracle.com> Message-ID: Thanks Alex.? I updated the javadoc per your feedback. Webrev updated in place (please reload): http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ Adding to the "unspecified" default discussion, LambdaMetaFactory and StringConcatFactory want the performant default and they didn't ask for strong or weak while in practice the resolved BSM callsite will keep the hidden class alive. My comment inlined below. Mandy On 3/11/20 4:22 PM, Alex Buckley wrote: > (Responding even though the enum constants are slightly up in the air, > because ultimately we need to be able to characterize unloading of a > hidden class independently of loader implementation.) > > I like how the first paragraph sidesteps how the loader implementation > refers to the hidden class. However, the second paragraph needs to > keep up the good work when no option is given. > > ----- > ***Unloading of the newly created class or interface {@code C} may be > controlled via the {@link ClassOption#WEAK WEAK} and {@link > ClassOption#STRONG STRONG} options.*** If {@code options} has the > {@code WEAK} option, then {@code C} may be unloaded when it [DO WE > MEAN ITS CLASS OBJECT?] Yes > becomes unreachable and is ~~~being~~~ reclaimed by the garbage > collector***,*** regardless of the href="../ref/package.html#reachability">reachability state of > {@code C}'s defining class loader. If {@code options} has ***the*** > {@code STRONG} option, then {@code C} is guaranteed not to be unloaded > when its defining class loader is strongly reachable. > > At most one of the options {@code WEAK} and {@code STRONG} may be > given. If neither is given, then the relationship between the defining > loader's reachability and the hidden class's unloading is unspecified. > In this case, the loader implementation [now we can talk about > references] may use a strong ... > ----- > > > BTW, the items which determine the nest host of C in the NESTMATE case > should look like this: (note the ol): > > ----- >

    > >
  1. If the nest host of the lookup class of this {@code Lookup} has > previously been determined, then ***let*** {@code H} be the nest host > of the lookup class. Otherwise, the nest host of the lookup class is > determined using the algorithm in JVMS 5.4.4, yielding {@code H}.
    2. > >
  2. The nest host of {@code C} is determined to be {@code H}, the nest > host of the lookup class.
    3. > >
> ----- > > Alex > From david.holmes at oracle.com Thu Mar 12 02:26:52 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2020 12:26:52 +1000 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> Message-ID: <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> On 12/03/2020 9:05 am, Mandy Chung wrote: > On 3/11/20 3:34 PM, David Holmes wrote: >> Hi Mandy, >> >> On 12/03/2020 8:12 am, Mandy Chung wrote: >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ >>> >>> >>> Alex suggests to keep the default unspecified, which I think it's a >>> great suggestion such that people do not have to rely on the >>> implementation assumption. >> >> I think this is making things unnecessarily awkward. The suggestion >> from yesterday (as per below) was to change the default to be weak, >> and allow people to ask for strong. That would involve simply changing >> all WEAK to STRONG through the existing code. Now we have WEAK and >> STRONG that are mutually exclusive so have to check for them both >> being set, and if neither is set then we fall into >> implementation-specific behaviour. >> If it is insisted that we have both WEAK and STRONG then we can >> achieve having the default unspecified by requiring that one of them >> always be passed in. > > There are cases that the library code does not care. I am skeptical of that. If you do the analysis and determine that you don't need a strong connection then actually getting a strong connection will work fine but may lead to footprint issues. If you don't need a strong connection I don't see why you would choose to let it default rather than selecting weak. If you select weak and find there is a performance issue then you would switch to strong, comment why, and file a RFE to fix the performance issue. I just don't see "don't care" coming into this. And of course if you need strong then allowing it to default is just broken! > Note that the main motivation to allow a hidden class be strongly > referenced because of our current implementation.?? It creates a > ClassLoaderData per weak class that may result in fragmentation and > incur bad performance overhead. That sounds like a deficiency in the VM that should be addressed. > This is solely implementation detail.? Other VM implementation may favor > weak classes.? An implementation-specific default will give flexibility > to the developers (not to specify neither strong or weak) to choose > whatever performs best when running on a VM implementation. Again I just don't buy that developers will write code that way. No one wants to depend on the performance characteristics of a default that could change on every release. David ----- > Mandy > >> But I much prefer what was suggested previously: either default is >> strong and you can ask for weak; or default is weak and you can ask >> for strong. >> >> Sorry. >> >> David >> >>> This patch adds a new ClassOption::STRONG enum constant while keeping >>> ClassOption::WEAK. >> >>> Mandy >>> >>> On 3/10/20 9:55 PM, John Rose wrote: >>>> I agree with Alex. ?Class loaders map names to classes. ?It?s not >>>> natural *semantically* for a nameless class to have its lifetime >>>> determined by a class loader. ?It may be more natural *in our >>>> JVM implementation* (hence more performant, in the *current* >>>> implementation) to have a non-weak link, but let?s do this only >>>> if users request it explicitly. >>>> >>>> On Mar 10, 2020, at 4:55 PM, Mandy Chung >>> > wrote: >>>>> >>>>> Brian, John, et al, >>>>> >>>>> Alex has given his feedback on the weak class feature (attached). >>>>> >>>>> Alex recommends to change the default of hidden classes be weak >>>>> classes and introduce a ClassOption::STRONG option if it wants to >>>>> ensure that the hidden class is not being reclaimed until the class >>>>> loader becomes unreachable.? See more details below. >>>>> >>>>> We tried to keep a hidden class be a normal class from JVM's point >>>>> of view.? Classes in the VM implementation have the same lifecycle >>>>> as the defining class loader. In addition, LambdaForms and Nashorn >>>>> are the only JDK use of hidden weak classes.? All others such as >>>>> lambda metafactory and string concat use hidden (strong) classes as >>>>> they are part of the target class' internal implementation and >>>>> should be unloaded altogether. Hence strong reference to hidden >>>>> classes is the default. >>>>> >>>>> What's your recommendation? >>>>> >>>>> Mandy >>>>> >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject:???? Weak references to hidden classes >>>>> Date:???? Tue, 10 Mar 2020 16:16:50 -0700 >>>>> From:???? Alex Buckley >>>>> Organization:???? Oracle Corporation >>>>> To:???? Mandy Chung >>>>> >>>>> >>>>> >>>>> JEP 371 says that a hidden class may be weakly referenced by its >>>>> class loader. Which loader? The only loader with any connection to >>>>> a hidden class is the loader nominated to serve as the defining >>>>> loader by the API spec of defineHiddenClass. However, that spec >>>>> doesn't say "The defining loader holds a strong reference to the >>>>> hidden class" because no spec says anything about how a class >>>>> loader refers to a class. >>>>> >>>>> (The only relationship we do specify is the other way around -- >>>>> ClassLoader says "Every Class object contains a reference to the >>>>> ClassLoader that defined it." -- and happily that relationship >>>>> holds for a hidden class too.) >>>>> >>>>> Point is, it's odd for defineHiddenClass to standardize how a class >>>>> loader refers to a hidden class when, conceptually, class loaders >>>>> are not meant to "know" about hidden classes. >>>>> >>>>> (The connection between a defining loader and a hidden class is a >>>>> mere accounting trick done to support the hidden class's own code. >>>>> No class loader, not even that defining loader, knows how to >>>>> respond to a class load request for the hidden class.) >>>>> >>>>> It's especially odd for defineHiddenClass's default to be a strong >>>>> reference. That default aligns with ClassLoader::defineClass, the >>>>> API we're trying to avoid, and doesn't align with >>>>> Unsafe::defineAnonymousClass, the API we're trying to recreate! >>>>> >>>>> I understand there are performance reasons to want a loader to use >>>>> a strong reference rather than a weak reference. Accepting that >>>>> claim, I recommend having the implementation use a weak reference >>>>> by default, having the spec allow that, then introducing >>>>> ClassOption.STRONG to force a strong reference. That is, specify that: >>>>> >>>>> "In the absence of an option, the defining loader's relationship >>>>> with the hidden class is unspecified, and the loader implementation >>>>> may use a strong reference or a weak reference to keep track of the >>>>> hidden class. If a hidden class is not strongly referenced by the >>>>> class loader which is deemed to be its defining loader, then the >>>>> hidden class can be unloaded when library code no longer refers to >>>>> it. Library developers who wish to prevent the hidden class from >>>>> being unloaded must ensure that its Class object is never >>>>> reclaimed, or else use the ClassOption.STRONG option." >>>>> >>>>> I understand there is a concern that developers would not realize / >>>>> be surprised by getting a weak reference as the default >>>>> implementation. However, the planet-wide audience for >>>>> defineHiddenClass is perhaps 500 developers. They already have to >>>>> know what they're doing because the features of hidden classes are >>>>> already more limited than the features of VM-anonymous classes., >>>>> e.g., no constant pool patching. The usual "Java should save >>>>> developers from making silly mistakes" rule doesn't apply here. >>>>> >>>>> Alex >>>> >>> > From mandy.chung at oracle.com Thu Mar 12 03:50:47 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 Mar 2020 20:50:47 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> Message-ID: On 3/11/20 7:26 PM, David Holmes wrote: > On 12/03/2020 9:05 am, Mandy Chung wrote: >> On 3/11/20 3:34 PM, David Holmes wrote: >>> Hi Mandy, >>> >>> On 12/03/2020 8:12 am, Mandy Chung wrote: >>>> Webrev: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ >>>> >>>> >>>> Alex suggests to keep the default unspecified, which I think it's a >>>> great suggestion such that people do not have to rely on the >>>> implementation assumption. >>> >>> I think this is making things unnecessarily awkward. The suggestion >>> from yesterday (as per below) was to change the default to be weak, >>> and allow people to ask for strong. That would involve simply >>> changing all WEAK to STRONG through the existing code. Now we have >>> WEAK and STRONG that are mutually exclusive so have to check for >>> them both being set, and if neither is set then we fall into >>> implementation-specific behaviour. >>> If it is insisted that we have both WEAK and STRONG then we can >>> achieve having the default unspecified by requiring that one of them >>> always be passed in. >> >> There are cases that the library code does not care. > > I am skeptical of that. If you do the analysis and determine that you > don't need a strong connection then actually getting a strong > connection will work fine but may lead to footprint issues. If you > don't need a strong connection I don't see why you would choose to let > it default rather than selecting weak. If you select weak and find > there is a performance issue then you would switch to strong, comment > why, and file a RFE to fix the performance issue. I just don't see > "don't care" coming into this. And of course if you need strong then > allowing it to default is just broken! > I consider LambdaMetaFactory and StringConcatFactory be indifferent to the implementation details because the resolved BSM is a CallSite pointing to a hidden class, i.e. keep the hidden class alive anyway. Are you saying this is wrong for LMF and SCF not to make a deliberate decision whether the hidden class is strong or weak?? Put it in another way, if we chose a default for them, the library developers are forced to consider the performance difference and any other implication between strong and weak - which is what we should avoid. >> Note that the main motivation to allow a hidden class be strongly >> referenced because of our current implementation.?? It creates a >> ClassLoaderData per weak class that may result in fragmentation and >> incur bad performance overhead. > > That sounds like a deficiency in the VM that should be addressed. > I had similar first reaction when I learned that.?? This is implementation detail and specifying the default be unspecified and let the implementation to choose the performant one as the default allows it to switch to different default in different release with no cost on existing code. >> This is solely implementation detail. Other VM implementation may >> favor weak classes.? An implementation-specific default will give >> flexibility to the developers (not to specify neither strong or weak) >> to choose whatever performs best when running on a VM implementation. > > Again I just don't buy that developers will write code that way. No > one wants to depend on the performance characteristics of a default > that could change on every release. > Please share use cases, if any. Mandy > David > ----- > >> Mandy >> >>> But I much prefer what was suggested previously: either default is >>> strong and you can ask for weak; or default is weak and you can ask >>> for strong. >>> >>> Sorry. >>> >>> David >>> >>>> This patch adds a new ClassOption::STRONG enum constant while >>>> keeping ClassOption::WEAK. >>> >>>> Mandy >>>> >>>> On 3/10/20 9:55 PM, John Rose wrote: >>>>> I agree with Alex. ?Class loaders map names to classes. ?It?s not >>>>> natural *semantically* for a nameless class to have its lifetime >>>>> determined by a class loader. ?It may be more natural *in our >>>>> JVM implementation* (hence more performant, in the *current* >>>>> implementation) to have a non-weak link, but let?s do this only >>>>> if users request it explicitly. >>>>> >>>>> On Mar 10, 2020, at 4:55 PM, Mandy Chung >>>> > wrote: >>>>>> >>>>>> Brian, John, et al, >>>>>> >>>>>> Alex has given his feedback on the weak class feature (attached). >>>>>> >>>>>> Alex recommends to change the default of hidden classes be weak >>>>>> classes and introduce a ClassOption::STRONG option if it wants to >>>>>> ensure that the hidden class is not being reclaimed until the >>>>>> class loader becomes unreachable.? See more details below. >>>>>> >>>>>> We tried to keep a hidden class be a normal class from JVM's >>>>>> point of view.? Classes in the VM implementation have the same >>>>>> lifecycle as the defining class loader. In addition, LambdaForms >>>>>> and Nashorn are the only JDK use of hidden weak classes.? All >>>>>> others such as lambda metafactory and string concat use hidden >>>>>> (strong) classes as they are part of the target class' internal >>>>>> implementation and should be unloaded altogether. Hence strong >>>>>> reference to hidden classes is the default. >>>>>> >>>>>> What's your recommendation? >>>>>> >>>>>> Mandy >>>>>> >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject:???? Weak references to hidden classes >>>>>> Date:???? Tue, 10 Mar 2020 16:16:50 -0700 >>>>>> From:???? Alex Buckley >>>>>> Organization:???? Oracle Corporation >>>>>> To:???? Mandy Chung >>>>>> >>>>>> >>>>>> >>>>>> JEP 371 says that a hidden class may be weakly referenced by its >>>>>> class loader. Which loader? The only loader with any connection >>>>>> to a hidden class is the loader nominated to serve as the >>>>>> defining loader by the API spec of defineHiddenClass. However, >>>>>> that spec doesn't say "The defining loader holds a strong >>>>>> reference to the hidden class" because no spec says anything >>>>>> about how a class loader refers to a class. >>>>>> >>>>>> (The only relationship we do specify is the other way around -- >>>>>> ClassLoader says "Every Class object contains a reference to the >>>>>> ClassLoader that defined it." -- and happily that relationship >>>>>> holds for a hidden class too.) >>>>>> >>>>>> Point is, it's odd for defineHiddenClass to standardize how a >>>>>> class loader refers to a hidden class when, conceptually, class >>>>>> loaders are not meant to "know" about hidden classes. >>>>>> >>>>>> (The connection between a defining loader and a hidden class is a >>>>>> mere accounting trick done to support the hidden class's own >>>>>> code. No class loader, not even that defining loader, knows how >>>>>> to respond to a class load request for the hidden class.) >>>>>> >>>>>> It's especially odd for defineHiddenClass's default to be a >>>>>> strong reference. That default aligns with >>>>>> ClassLoader::defineClass, the API we're trying to avoid, and >>>>>> doesn't align with Unsafe::defineAnonymousClass, the API we're >>>>>> trying to recreate! >>>>>> >>>>>> I understand there are performance reasons to want a loader to >>>>>> use a strong reference rather than a weak reference. Accepting >>>>>> that claim, I recommend having the implementation use a weak >>>>>> reference by default, having the spec allow that, then >>>>>> introducing ClassOption.STRONG to force a strong reference. That >>>>>> is, specify that: >>>>>> >>>>>> "In the absence of an option, the defining loader's relationship >>>>>> with the hidden class is unspecified, and the loader >>>>>> implementation may use a strong reference or a weak reference to >>>>>> keep track of the hidden class. If a hidden class is not strongly >>>>>> referenced by the class loader which is deemed to be its defining >>>>>> loader, then the hidden class can be unloaded when library code >>>>>> no longer refers to it. Library developers who wish to prevent >>>>>> the hidden class from being unloaded must ensure that its Class >>>>>> object is never reclaimed, or else use the ClassOption.STRONG >>>>>> option." >>>>>> >>>>>> I understand there is a concern that developers would not realize >>>>>> / be surprised by getting a weak reference as the default >>>>>> implementation. However, the planet-wide audience for >>>>>> defineHiddenClass is perhaps 500 developers. They already have to >>>>>> know what they're doing because the features of hidden classes >>>>>> are already more limited than the features of VM-anonymous >>>>>> classes., e.g., no constant pool patching. The usual "Java should >>>>>> save developers from making silly mistakes" rule doesn't apply here. >>>>>> >>>>>> Alex >>>>> >>>> >> From david.holmes at oracle.com Thu Mar 12 13:08:11 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2020 23:08:11 +1000 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> Message-ID: On 12/03/2020 1:50 pm, Mandy Chung wrote: > > > On 3/11/20 7:26 PM, David Holmes wrote: >> On 12/03/2020 9:05 am, Mandy Chung wrote: >>> On 3/11/20 3:34 PM, David Holmes wrote: >>>> Hi Mandy, >>>> >>>> On 12/03/2020 8:12 am, Mandy Chung wrote: >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ >>>>> >>>>> >>>>> Alex suggests to keep the default unspecified, which I think it's a >>>>> great suggestion such that people do not have to rely on the >>>>> implementation assumption. >>>> >>>> I think this is making things unnecessarily awkward. The suggestion >>>> from yesterday (as per below) was to change the default to be weak, >>>> and allow people to ask for strong. That would involve simply >>>> changing all WEAK to STRONG through the existing code. Now we have >>>> WEAK and STRONG that are mutually exclusive so have to check for >>>> them both being set, and if neither is set then we fall into >>>> implementation-specific behaviour. >>>> If it is insisted that we have both WEAK and STRONG then we can >>>> achieve having the default unspecified by requiring that one of them >>>> always be passed in. >>> >>> There are cases that the library code does not care. >> >> I am skeptical of that. If you do the analysis and determine that you >> don't need a strong connection then actually getting a strong >> connection will work fine but may lead to footprint issues. If you >> don't need a strong connection I don't see why you would choose to let >> it default rather than selecting weak. If you select weak and find >> there is a performance issue then you would switch to strong, comment >> why, and file a RFE to fix the performance issue. I just don't see >> "don't care" coming into this. And of course if you need strong then >> allowing it to default is just broken! >> > > I consider LambdaMetaFactory and StringConcatFactory be indifferent to > the implementation details because the resolved BSM is a CallSite > pointing to a hidden class, i.e. keep the hidden class alive anyway. That isn't indifference - they know they will keep the hidden class alive thus the hidden class can be weak. > Are you saying this is wrong for LMF and SCF not to make a deliberate > decision whether the hidden class is strong or weak?? Put it in another > way, if we chose a default for them, the library developers are forced > to consider the performance difference and any other implication between > strong and weak - which is what we should avoid. If we are going to code based in inside knowledge of VM defaults and the performance thereof then that should be documented in our code where we make those decisions. We certainly should not expect that level of inside knowledge to leak through to external users of the hiddenClass API. >>> Note that the main motivation to allow a hidden class be strongly >>> referenced because of our current implementation.?? It creates a >>> ClassLoaderData per weak class that may result in fragmentation and >>> incur bad performance overhead. >> >> That sounds like a deficiency in the VM that should be addressed. >> > > I had similar first reaction when I learned that.?? This is > implementation detail and specifying the default be unspecified and let > the implementation to choose the performant one as the default allows it > to switch to different default in different release with no cost on > existing code. I can see the appeal in looking at it that way, I just think it is wrong to code things based on implicit defaults that you happen to know the details of. YMMV. David ----- > >>> This is solely implementation detail. Other VM implementation may >>> favor weak classes.? An implementation-specific default will give >>> flexibility to the developers (not to specify neither strong or weak) >>> to choose whatever performs best when running on a VM implementation. >> >> Again I just don't buy that developers will write code that way. No >> one wants to depend on the performance characteristics of a default >> that could change on every release. >> > > Please share use cases, if any. > > Mandy > >> David >> ----- >> >>> Mandy >>> >>>> But I much prefer what was suggested previously: either default is >>>> strong and you can ask for weak; or default is weak and you can ask >>>> for strong. >>>> >>>> Sorry. >>>> >>>> David >>>> >>>>> This patch adds a new ClassOption::STRONG enum constant while >>>>> keeping ClassOption::WEAK. >>>> >>>>> Mandy >>>>> >>>>> On 3/10/20 9:55 PM, John Rose wrote: >>>>>> I agree with Alex. ?Class loaders map names to classes. ?It?s not >>>>>> natural *semantically* for a nameless class to have its lifetime >>>>>> determined by a class loader. ?It may be more natural *in our >>>>>> JVM implementation* (hence more performant, in the *current* >>>>>> implementation) to have a non-weak link, but let?s do this only >>>>>> if users request it explicitly. >>>>>> >>>>>> On Mar 10, 2020, at 4:55 PM, Mandy Chung >>>>> > wrote: >>>>>>> >>>>>>> Brian, John, et al, >>>>>>> >>>>>>> Alex has given his feedback on the weak class feature (attached). >>>>>>> >>>>>>> Alex recommends to change the default of hidden classes be weak >>>>>>> classes and introduce a ClassOption::STRONG option if it wants to >>>>>>> ensure that the hidden class is not being reclaimed until the >>>>>>> class loader becomes unreachable.? See more details below. >>>>>>> >>>>>>> We tried to keep a hidden class be a normal class from JVM's >>>>>>> point of view.? Classes in the VM implementation have the same >>>>>>> lifecycle as the defining class loader. In addition, LambdaForms >>>>>>> and Nashorn are the only JDK use of hidden weak classes.? All >>>>>>> others such as lambda metafactory and string concat use hidden >>>>>>> (strong) classes as they are part of the target class' internal >>>>>>> implementation and should be unloaded altogether. Hence strong >>>>>>> reference to hidden classes is the default. >>>>>>> >>>>>>> What's your recommendation? >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>> >>>>>>> -------- Forwarded Message -------- >>>>>>> Subject:???? Weak references to hidden classes >>>>>>> Date:???? Tue, 10 Mar 2020 16:16:50 -0700 >>>>>>> From:???? Alex Buckley >>>>>>> Organization:???? Oracle Corporation >>>>>>> To:???? Mandy Chung >>>>>>> >>>>>>> >>>>>>> >>>>>>> JEP 371 says that a hidden class may be weakly referenced by its >>>>>>> class loader. Which loader? The only loader with any connection >>>>>>> to a hidden class is the loader nominated to serve as the >>>>>>> defining loader by the API spec of defineHiddenClass. However, >>>>>>> that spec doesn't say "The defining loader holds a strong >>>>>>> reference to the hidden class" because no spec says anything >>>>>>> about how a class loader refers to a class. >>>>>>> >>>>>>> (The only relationship we do specify is the other way around -- >>>>>>> ClassLoader says "Every Class object contains a reference to the >>>>>>> ClassLoader that defined it." -- and happily that relationship >>>>>>> holds for a hidden class too.) >>>>>>> >>>>>>> Point is, it's odd for defineHiddenClass to standardize how a >>>>>>> class loader refers to a hidden class when, conceptually, class >>>>>>> loaders are not meant to "know" about hidden classes. >>>>>>> >>>>>>> (The connection between a defining loader and a hidden class is a >>>>>>> mere accounting trick done to support the hidden class's own >>>>>>> code. No class loader, not even that defining loader, knows how >>>>>>> to respond to a class load request for the hidden class.) >>>>>>> >>>>>>> It's especially odd for defineHiddenClass's default to be a >>>>>>> strong reference. That default aligns with >>>>>>> ClassLoader::defineClass, the API we're trying to avoid, and >>>>>>> doesn't align with Unsafe::defineAnonymousClass, the API we're >>>>>>> trying to recreate! >>>>>>> >>>>>>> I understand there are performance reasons to want a loader to >>>>>>> use a strong reference rather than a weak reference. Accepting >>>>>>> that claim, I recommend having the implementation use a weak >>>>>>> reference by default, having the spec allow that, then >>>>>>> introducing ClassOption.STRONG to force a strong reference. That >>>>>>> is, specify that: >>>>>>> >>>>>>> "In the absence of an option, the defining loader's relationship >>>>>>> with the hidden class is unspecified, and the loader >>>>>>> implementation may use a strong reference or a weak reference to >>>>>>> keep track of the hidden class. If a hidden class is not strongly >>>>>>> referenced by the class loader which is deemed to be its defining >>>>>>> loader, then the hidden class can be unloaded when library code >>>>>>> no longer refers to it. Library developers who wish to prevent >>>>>>> the hidden class from being unloaded must ensure that its Class >>>>>>> object is never reclaimed, or else use the ClassOption.STRONG >>>>>>> option." >>>>>>> >>>>>>> I understand there is a concern that developers would not realize >>>>>>> / be surprised by getting a weak reference as the default >>>>>>> implementation. However, the planet-wide audience for >>>>>>> defineHiddenClass is perhaps 500 developers. They already have to >>>>>>> know what they're doing because the features of hidden classes >>>>>>> are already more limited than the features of VM-anonymous >>>>>>> classes., e.g., no constant pool patching. The usual "Java should >>>>>>> save developers from making silly mistakes" rule doesn't apply here. >>>>>>> >>>>>>> Alex >>>>>> >>>>> >>> > From alex.buckley at oracle.com Wed Mar 11 23:13:34 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 11 Mar 2020 16:13:34 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> Message-ID: On 3/11/2020 3:34 PM, David Holmes wrote: > I think this is making things unnecessarily awkward. The suggestion from > yesterday (as per below) was to change the default to be weak, and allow > people to ask for strong. My suggestion had another component too: to specify that the default is unspecified. That means that the default could be weak in HotSpot 15 and strong in HotSpot 17 and weak in HotSpot 23. Weak is a sensible default for implementations, but if a developer can't guarantee it when they want it, then they'll be mad with us. > If it is insisted that we have both WEAK and STRONG then we can achieve > having the default unspecified by requiring that one of them always be > passed in. But I much prefer what was suggested previously: either > default is strong and you can ask for weak; or default is weak and you > can ask for strong. I was actually careful not to say anything about the WEAK enum constant. I wanted to focus on a bigger story and deal with enum constants later (and here we are). Mandy's compendium of use cases suggests that some libraries want strong and some libraries want weak and some don't care -- with that in mind, I fall into the "default unspecified; allow X or Y to be chosen" camp, rather than the "default specified as X; allow Y to be chosen" camp. I believe the lumping-versus-splitting philosophy can guide us, but I didn't take a guru-level course in it yet, so John's guidance is welcome. Alex From alex.buckley at oracle.com Wed Mar 11 23:22:34 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 11 Mar 2020 16:22:34 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> Message-ID: <5d0822c5-5cc0-913f-2d21-520864e49364@oracle.com> (Responding even though the enum constants are slightly up in the air, because ultimately we need to be able to characterize unloading of a hidden class independently of loader implementation.) I like how the first paragraph sidesteps how the loader implementation refers to the hidden class. However, the second paragraph needs to keep up the good work when no option is given. ----- ***Unloading of the newly created class or interface {@code C} may be controlled via the {@link ClassOption#WEAK WEAK} and {@link ClassOption#STRONG STRONG} options.*** If {@code options} has the {@code WEAK} option, then {@code C} may be unloaded when it [DO WE MEAN ITS CLASS OBJECT?] becomes unreachable and is ~~~being~~~ reclaimed by the garbage collector***,*** regardless of the reachability state of {@code C}'s defining class loader. If {@code options} has ***the*** {@code STRONG} option, then {@code C} is guaranteed not to be unloaded when its defining class loader is strongly reachable. At most one of the options {@code WEAK} and {@code STRONG} may be given. If neither is given, then the relationship between the defining loader's reachability and the hidden class's unloading is unspecified. In this case, the loader implementation [now we can talk about references] may use a strong ... ----- BTW, the items which determine the nest host of C in the NESTMATE case should look like this: (note the ol): -----
  1. If the nest host of the lookup class of this {@code Lookup} has previously been determined, then ***let*** {@code H} be the nest host of the lookup class. Otherwise, the nest host of the lookup class is determined using the algorithm in JVMS 5.4.4, yielding {@code H}.
  2. The nest host of {@code C} is determined to be {@code H}, the nest host of the lookup class.
----- Alex On 3/11/2020 3:12 PM, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ > > Alex suggests to keep the default unspecified, which I think it's a > great suggestion such that people do not have to rely on the > implementation assumption. > > This patch adds a new ClassOption::STRONG enum constant while keeping > ClassOption::WEAK. > > Mandy > > On 3/10/20 9:55 PM, John Rose wrote: >> I agree with Alex. ?Class loaders map names to classes. ?It?s not >> natural *semantically* for a nameless class to have its lifetime >> determined by a class loader. ?It may be more natural *in our >> JVM implementation* (hence more performant, in the *current* >> implementation) to have a non-weak link, but let?s do this only >> if users request it explicitly. >> >> On Mar 10, 2020, at 4:55 PM, Mandy Chung > > wrote: >>> >>> Brian, John, et al, >>> >>> Alex has given his feedback on the weak class feature (attached). >>> >>> Alex recommends to change the default of hidden classes be weak >>> classes and introduce a ClassOption::STRONG option if it wants to >>> ensure that the hidden class is not being reclaimed until the class >>> loader becomes unreachable.? See more details below. >>> >>> We tried to keep a hidden class be a normal class from JVM's point of >>> view.? Classes in the VM implementation have the same lifecycle as >>> the defining class loader. In addition, LambdaForms and Nashorn are >>> the only JDK use of hidden weak classes.? All others such as lambda >>> metafactory and string concat use hidden (strong) classes as they are >>> part of the target class' internal implementation and should be >>> unloaded altogether. Hence strong reference to hidden classes is the >>> default. >>> >>> What's your recommendation? >>> >>> Mandy >>> >>> >>> -------- Forwarded Message -------- >>> Subject: Weak references to hidden classes >>> Date: Tue, 10 Mar 2020 16:16:50 -0700 >>> From: Alex Buckley >>> Organization: Oracle Corporation >>> To: Mandy Chung >>> >>> >>> >>> JEP 371 says that a hidden class may be weakly referenced by its >>> class loader. Which loader? The only loader with any connection to a >>> hidden class is the loader nominated to serve as the defining loader >>> by the API spec of defineHiddenClass. However, that spec doesn't say >>> "The defining loader holds a strong reference to the hidden class" >>> because no spec says anything about how a class loader refers to a class. >>> >>> (The only relationship we do specify is the other way around -- >>> ClassLoader says "Every Class object contains a reference to the >>> ClassLoader that defined it." -- and happily that relationship holds >>> for a hidden class too.) >>> >>> Point is, it's odd for defineHiddenClass to standardize how a class >>> loader refers to a hidden class when, conceptually, class loaders are >>> not meant to "know" about hidden classes. >>> >>> (The connection between a defining loader and a hidden class is a >>> mere accounting trick done to support the hidden class's own code. No >>> class loader, not even that defining loader, knows how to respond to >>> a class load request for the hidden class.) >>> >>> It's especially odd for defineHiddenClass's default to be a strong >>> reference. That default aligns with ClassLoader::defineClass, the API >>> we're trying to avoid, and doesn't align with >>> Unsafe::defineAnonymousClass, the API we're trying to recreate! >>> >>> I understand there are performance reasons to want a loader to use a >>> strong reference rather than a weak reference. Accepting that claim, >>> I recommend having the implementation use a weak reference by >>> default, having the spec allow that, then introducing >>> ClassOption.STRONG to force a strong reference. That is, specify that: >>> >>> "In the absence of an option, the defining loader's relationship with >>> the hidden class is unspecified, and the loader implementation may >>> use a strong reference or a weak reference to keep track of the >>> hidden class. If a hidden class is not strongly referenced by the >>> class loader which is deemed to be its defining loader, then the >>> hidden class can be unloaded when library code no longer refers to >>> it. Library developers who wish to prevent the hidden class from >>> being unloaded must ensure that its Class object is never reclaimed, >>> or else use the ClassOption.STRONG option." >>> >>> I understand there is a concern that developers would not realize / >>> be surprised by getting a weak reference as the default >>> implementation. However, the planet-wide audience for >>> defineHiddenClass is perhaps 500 developers. They already have to >>> know what they're doing because the features of hidden classes are >>> already more limited than the features of VM-anonymous classes., >>> e.g., no constant pool patching. The usual "Java should save >>> developers from making silly mistakes" rule doesn't apply here. >>> >>> Alex >> > From harold.seigel at oracle.com Thu Mar 12 17:11:06 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 12 Mar 2020 13:11:06 -0400 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> Message-ID: Hi David, The changes look good! Can the "TRAPS" argument be removed from InstanceKlass::set_nest_host() ? Thanks, Harold On 3/11/2020 1:25 AM, David Holmes wrote: > John pointed out to me offline that there are now race conditions > possible due to the setting of the error message. I had been lulled > into a false sense of security by the overall idempotency of the > operation. Simple fix is to introduce storestore barriers in a couple > of places to ensure we write the error string, then the > _nest_host_res_error field, then the _nest_host field, in that order. > Commentary updated as well. > > This update also includes Lois's suggested cleanup in linkResolver.cpp. > > Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3-incr/ > > Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3/ > > Thanks, > David > > On 9/03/2020 9:09 am, David Holmes wrote: >> Hi John, >> >> On 7/03/2020 7:45 am, John Rose wrote: >>> Nice work, very thorough as usual. >> >> Thanks - and thanks for looking at this. >> >>> One nit.? The back-to-back parens are bad style. >>> >>>> foo (bar)(baz) >>> >>> https://english.stackexchange.com/questions/19429/should-i-use-adjacent-parentheses-or-a-semicolon-or-something-else >>> >>> https://blog.apastyle.org/apastyle/2013/05/punctuation-junction-parentheses-and-brackets.html >>> >> >> Okay - hadn't realized there was an applicable style here as I was >> just implementing a multi-part message by a simple concatenation of >> () delimited segments. >> >>> There are different ways to handle this in professional text. >>> I think the simplest way is relatively tricky from our perspective. >>> You merge the two parentheticals with an internal semicolon: >>> >>>> foo (bar; baz) >> >> I think that would make it very hard to spot the changeover. >> >>> A really simple tweak to your code would be to put a comma >>> between.? This is less standard but better than back-to-back >>> parens: >>> >>> -+??????? ss.print("("); >>> ++??????? ss.print(?, (?); >>> >>> (Two places.) >> >> Ok - that works for me. >> >>> Likewise, in two places: >>> >>> -+????? msg = "(stuff?)"; >>> ++????? msg = " (stuff?)?; >>> >>> ?to avoid the left paren making hard contact with the preceding text. >> >> If this is referring to instanceKlass.cpp: >> >> ??363?????? msg = "(the NestHost attribute in the current class is >> ignored)"; >> ??364???? } else if (_nest_members != NULL && _nest_members != >> Universe::the_empty_short_array()) { >> ??365?????? msg = "(the NestMembers attribute in the current class is >> ignored)"; >> >> then the space is part of the main formatted string: >> >> ??367???? log_trace(class, nestmates)("Injected type %s into the nest >> of %s %s", >> ??368???????????????????????????????? this->external_name(), >> ??369???????????????????????????????? host->external_name(), >> ??370???????????????????????????????? msg); >> >> >>> Klass::_nest_host_res_error is ok.? If we ever decide to reduce the >>> footprint there (as part of a larger effort, I think), we could merge >>> both fields by using a tagged pointer, on the observation that you >>> only need one or the other to be non-null.? If the res-error is not >>> null, then we can infer that nest-host has been determined to be >>> self, and in that case we don?t need to look at the field, right? >> >> A non-NULL res-err does imply _nest_host == this. But not vice-versa. >> >>> You might want to add a comment about the possible states of >>> those two coupled variables, to help maintainers.? For example: >>> >>> + // This variable is non-null only if _nest_host is null. >>> >>> Actually, I didn?t follow the logic fully:? Can both fields be non-null >>> at the same time?? It looks like Klass::nest_host only gets set >>> non-null >>> on error-free paths, while the error string is set only on error paths. >>> It would be reasonable for Klass::nest_host to check for an error >>> string and immediately return ?this? if one is set.? I didn?t see this. >>> >>> Maybe the comment should be: >>> >>> + // This variable is non-null only if _nest_host is this or (during >>> a race) null. >>> >>> (And if there?s a race, please do a releasing store of the error >>> string before >>> setting the _nest_host to ?this?.? But at-least-one-always-null is a >>> safer >>> convention for managing races.? So I like the first comment much >>> better.) >> >> _nest_host is always set, even when there is an error. So nest_host() >> does a quick return in all calls other than the first (modulo the >> rare case where we had to bail out because we are in a compiler >> thread; or VME occurred): >> >> ??226 InstanceKlass* InstanceKlass::nest_host(TRAPS) { >> ??227?? InstanceKlass* nest_host_k = _nest_host; >> ??228?? if (nest_host_k != NULL) { >> ??229???? return nest_host_k; >> ??230?? } >> >> I can't see any way to reduce footprint in this area as we have two >> very distinct entities we are tracking. >> >>> Also, let?s talk about VirtualMachineError. >>> >>> After thinking about it a bit, I think you went too far replacing CATCH >>> by THREAD; this makes a fragile assumption that nothing is coming >>> out of the call.? It?s fragile because, although we expect >>> LinkageError, >>> there?s usually an additional possibility of VirtualMachineError. >>> Doing a catch-and-clear of VME is risky business, and in this case >>> I only think we need to catch and clear the LE, not the VME. >>> >>> To me, it seems safest to always expect VME, and always pass it on, >>> as a basic convention in our code base, with clear documentation >>> wherever we do something different. >>> >>> Imagine getting an access error later on, with the parenthetical >>> remark that the nest host failed due to SOE or OOME.? Those guys >>> should be fail-fast, I think.? Or did you come up with a reason they >>> should be muzzled also, along with the LE we intend to muzzle? >>> >>> I see the previous code processed VME differently, and that you >>> removed it, so I know you did this as a considered step.? But still >>> it seems off to me.? At least add some documentation explaining >>> why it?s safe to drop VM errors. >> >> You are absolutely right, I went too far in clearing ALL pending >> exceptions. I need to check for VME and do immediate return in that >> case; and restore the CHECK usage in the callers. Not only should >> VMEs be fail-fast, but they are also cases where we should be allowed >> to retry determining the nest host. >> >> Updated webrevs: >> >> Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ >> >> (ciField.cpp and reflection.cpp are simply reverted) >> >> Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2/ >> >> Thanks, >> David >> >>> ? John >>> From lois.foltan at oracle.com Thu Mar 12 18:48:54 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 12 Mar 2020 11:48:54 -0700 (PDT) Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> Message-ID: <90995f28-08cf-6b89-17f7-8e2149a36516@oracle.com> On 3/11/2020 1:25 AM, David Holmes wrote: > John pointed out to me offline that there are now race conditions > possible due to the setting of the error message. I had been lulled > into a false sense of security by the overall idempotency of the > operation. Simple fix is to introduce storestore barriers in a couple > of places to ensure we write the error string, then the > _nest_host_res_error field, then the _nest_host field, in that order. > Commentary updated as well. > > This update also includes Lois's suggested cleanup in linkResolver.cpp. > > Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3-incr/ > > Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3/ Looks good David, thanks for making the ss.print change I suggested. Lois > > Thanks, > David > > On 9/03/2020 9:09 am, David Holmes wrote: >> Hi John, >> >> On 7/03/2020 7:45 am, John Rose wrote: >>> Nice work, very thorough as usual. >> >> Thanks - and thanks for looking at this. >> >>> One nit.? The back-to-back parens are bad style. >>> >>>> foo (bar)(baz) >>> >>> https://english.stackexchange.com/questions/19429/should-i-use-adjacent-parentheses-or-a-semicolon-or-something-else >>> >>> https://blog.apastyle.org/apastyle/2013/05/punctuation-junction-parentheses-and-brackets.html >>> >> >> Okay - hadn't realized there was an applicable style here as I was >> just implementing a multi-part message by a simple concatenation of >> () delimited segments. >> >>> There are different ways to handle this in professional text. >>> I think the simplest way is relatively tricky from our perspective. >>> You merge the two parentheticals with an internal semicolon: >>> >>>> foo (bar; baz) >> >> I think that would make it very hard to spot the changeover. >> >>> A really simple tweak to your code would be to put a comma >>> between.? This is less standard but better than back-to-back >>> parens: >>> >>> -+??????? ss.print("("); >>> ++??????? ss.print(?, (?); >>> >>> (Two places.) >> >> Ok - that works for me. >> >>> Likewise, in two places: >>> >>> -+????? msg = "(stuff?)"; >>> ++????? msg = " (stuff?)?; >>> >>> ?to avoid the left paren making hard contact with the preceding text. >> >> If this is referring to instanceKlass.cpp: >> >> ??363?????? msg = "(the NestHost attribute in the current class is >> ignored)"; >> ??364???? } else if (_nest_members != NULL && _nest_members != >> Universe::the_empty_short_array()) { >> ??365?????? msg = "(the NestMembers attribute in the current class is >> ignored)"; >> >> then the space is part of the main formatted string: >> >> ??367???? log_trace(class, nestmates)("Injected type %s into the nest >> of %s %s", >> ??368???????????????????????????????? this->external_name(), >> ??369???????????????????????????????? host->external_name(), >> ??370???????????????????????????????? msg); >> >> >>> Klass::_nest_host_res_error is ok.? If we ever decide to reduce the >>> footprint there (as part of a larger effort, I think), we could merge >>> both fields by using a tagged pointer, on the observation that you >>> only need one or the other to be non-null.? If the res-error is not >>> null, then we can infer that nest-host has been determined to be >>> self, and in that case we don?t need to look at the field, right? >> >> A non-NULL res-err does imply _nest_host == this. But not vice-versa. >> >>> You might want to add a comment about the possible states of >>> those two coupled variables, to help maintainers.? For example: >>> >>> + // This variable is non-null only if _nest_host is null. >>> >>> Actually, I didn?t follow the logic fully:? Can both fields be non-null >>> at the same time?? It looks like Klass::nest_host only gets set >>> non-null >>> on error-free paths, while the error string is set only on error paths. >>> It would be reasonable for Klass::nest_host to check for an error >>> string and immediately return ?this? if one is set.? I didn?t see this. >>> >>> Maybe the comment should be: >>> >>> + // This variable is non-null only if _nest_host is this or (during >>> a race) null. >>> >>> (And if there?s a race, please do a releasing store of the error >>> string before >>> setting the _nest_host to ?this?.? But at-least-one-always-null is a >>> safer >>> convention for managing races.? So I like the first comment much >>> better.) >> >> _nest_host is always set, even when there is an error. So nest_host() >> does a quick return in all calls other than the first (modulo the >> rare case where we had to bail out because we are in a compiler >> thread; or VME occurred): >> >> ??226 InstanceKlass* InstanceKlass::nest_host(TRAPS) { >> ??227?? InstanceKlass* nest_host_k = _nest_host; >> ??228?? if (nest_host_k != NULL) { >> ??229???? return nest_host_k; >> ??230?? } >> >> I can't see any way to reduce footprint in this area as we have two >> very distinct entities we are tracking. >> >>> Also, let?s talk about VirtualMachineError. >>> >>> After thinking about it a bit, I think you went too far replacing CATCH >>> by THREAD; this makes a fragile assumption that nothing is coming >>> out of the call.? It?s fragile because, although we expect >>> LinkageError, >>> there?s usually an additional possibility of VirtualMachineError. >>> Doing a catch-and-clear of VME is risky business, and in this case >>> I only think we need to catch and clear the LE, not the VME. >>> >>> To me, it seems safest to always expect VME, and always pass it on, >>> as a basic convention in our code base, with clear documentation >>> wherever we do something different. >>> >>> Imagine getting an access error later on, with the parenthetical >>> remark that the nest host failed due to SOE or OOME.? Those guys >>> should be fail-fast, I think.? Or did you come up with a reason they >>> should be muzzled also, along with the LE we intend to muzzle? >>> >>> I see the previous code processed VME differently, and that you >>> removed it, so I know you did this as a considered step.? But still >>> it seems off to me.? At least add some documentation explaining >>> why it?s safe to drop VM errors. >> >> You are absolutely right, I went too far in clearing ALL pending >> exceptions. I need to check for VME and do immediate return in that >> case; and restore the CHECK usage in the callers. Not only should >> VMEs be fail-fast, but they are also cases where we should be allowed >> to retry determining the nest host. >> >> Updated webrevs: >> >> Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ >> >> (ciField.cpp and reflection.cpp are simply reverted) >> >> Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2/ >> >> Thanks, >> David >> >>> ? John >>> From david.holmes at oracle.com Thu Mar 12 22:25:20 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2020 08:25:20 +1000 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> Message-ID: <11bb2e19-e7fa-2573-3399-63efefaf5f29@oracle.com> Hi Harold, On 13/03/2020 3:11 am, Harold Seigel wrote: > Hi David, > > The changes look good! Thanks for looking at them. > Can the "TRAPS" argument be removed from InstanceKlass::set_nest_host() ? It is convenient to keep it to avoid the implicit Thread::current() that would be needed for the ResourceMark otherwise. The caller already has THREAD available to pass in. Thanks, David > Thanks, Harold > > On 3/11/2020 1:25 AM, David Holmes wrote: >> John pointed out to me offline that there are now race conditions >> possible due to the setting of the error message. I had been lulled >> into a false sense of security by the overall idempotency of the >> operation. Simple fix is to introduce storestore barriers in a couple >> of places to ensure we write the error string, then the >> _nest_host_res_error field, then the _nest_host field, in that order. >> Commentary updated as well. >> >> This update also includes Lois's suggested cleanup in linkResolver.cpp. >> >> Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3-incr/ >> >> Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3/ >> >> Thanks, >> David >> >> On 9/03/2020 9:09 am, David Holmes wrote: >>> Hi John, >>> >>> On 7/03/2020 7:45 am, John Rose wrote: >>>> Nice work, very thorough as usual. >>> >>> Thanks - and thanks for looking at this. >>> >>>> One nit.? The back-to-back parens are bad style. >>>> >>>>> foo (bar)(baz) >>>> >>>> https://english.stackexchange.com/questions/19429/should-i-use-adjacent-parentheses-or-a-semicolon-or-something-else >>>> >>>> https://blog.apastyle.org/apastyle/2013/05/punctuation-junction-parentheses-and-brackets.html >>>> >>> >>> Okay - hadn't realized there was an applicable style here as I was >>> just implementing a multi-part message by a simple concatenation of >>> () delimited segments. >>> >>>> There are different ways to handle this in professional text. >>>> I think the simplest way is relatively tricky from our perspective. >>>> You merge the two parentheticals with an internal semicolon: >>>> >>>>> foo (bar; baz) >>> >>> I think that would make it very hard to spot the changeover. >>> >>>> A really simple tweak to your code would be to put a comma >>>> between.? This is less standard but better than back-to-back >>>> parens: >>>> >>>> -+??????? ss.print("("); >>>> ++??????? ss.print(?, (?); >>>> >>>> (Two places.) >>> >>> Ok - that works for me. >>> >>>> Likewise, in two places: >>>> >>>> -+????? msg = "(stuff?)"; >>>> ++????? msg = " (stuff?)?; >>>> >>>> ?to avoid the left paren making hard contact with the preceding text. >>> >>> If this is referring to instanceKlass.cpp: >>> >>> ??363?????? msg = "(the NestHost attribute in the current class is >>> ignored)"; >>> ??364???? } else if (_nest_members != NULL && _nest_members != >>> Universe::the_empty_short_array()) { >>> ??365?????? msg = "(the NestMembers attribute in the current class is >>> ignored)"; >>> >>> then the space is part of the main formatted string: >>> >>> ??367???? log_trace(class, nestmates)("Injected type %s into the nest >>> of %s %s", >>> ??368???????????????????????????????? this->external_name(), >>> ??369???????????????????????????????? host->external_name(), >>> ??370???????????????????????????????? msg); >>> >>> >>>> Klass::_nest_host_res_error is ok.? If we ever decide to reduce the >>>> footprint there (as part of a larger effort, I think), we could merge >>>> both fields by using a tagged pointer, on the observation that you >>>> only need one or the other to be non-null.? If the res-error is not >>>> null, then we can infer that nest-host has been determined to be >>>> self, and in that case we don?t need to look at the field, right? >>> >>> A non-NULL res-err does imply _nest_host == this. But not vice-versa. >>> >>>> You might want to add a comment about the possible states of >>>> those two coupled variables, to help maintainers.? For example: >>>> >>>> + // This variable is non-null only if _nest_host is null. >>>> >>>> Actually, I didn?t follow the logic fully:? Can both fields be non-null >>>> at the same time?? It looks like Klass::nest_host only gets set >>>> non-null >>>> on error-free paths, while the error string is set only on error paths. >>>> It would be reasonable for Klass::nest_host to check for an error >>>> string and immediately return ?this? if one is set.? I didn?t see this. >>>> >>>> Maybe the comment should be: >>>> >>>> + // This variable is non-null only if _nest_host is this or (during >>>> a race) null. >>>> >>>> (And if there?s a race, please do a releasing store of the error >>>> string before >>>> setting the _nest_host to ?this?.? But at-least-one-always-null is a >>>> safer >>>> convention for managing races.? So I like the first comment much >>>> better.) >>> >>> _nest_host is always set, even when there is an error. So nest_host() >>> does a quick return in all calls other than the first (modulo the >>> rare case where we had to bail out because we are in a compiler >>> thread; or VME occurred): >>> >>> ??226 InstanceKlass* InstanceKlass::nest_host(TRAPS) { >>> ??227?? InstanceKlass* nest_host_k = _nest_host; >>> ??228?? if (nest_host_k != NULL) { >>> ??229???? return nest_host_k; >>> ??230?? } >>> >>> I can't see any way to reduce footprint in this area as we have two >>> very distinct entities we are tracking. >>> >>>> Also, let?s talk about VirtualMachineError. >>>> >>>> After thinking about it a bit, I think you went too far replacing CATCH >>>> by THREAD; this makes a fragile assumption that nothing is coming >>>> out of the call.? It?s fragile because, although we expect >>>> LinkageError, >>>> there?s usually an additional possibility of VirtualMachineError. >>>> Doing a catch-and-clear of VME is risky business, and in this case >>>> I only think we need to catch and clear the LE, not the VME. >>>> >>>> To me, it seems safest to always expect VME, and always pass it on, >>>> as a basic convention in our code base, with clear documentation >>>> wherever we do something different. >>>> >>>> Imagine getting an access error later on, with the parenthetical >>>> remark that the nest host failed due to SOE or OOME.? Those guys >>>> should be fail-fast, I think.? Or did you come up with a reason they >>>> should be muzzled also, along with the LE we intend to muzzle? >>>> >>>> I see the previous code processed VME differently, and that you >>>> removed it, so I know you did this as a considered step.? But still >>>> it seems off to me.? At least add some documentation explaining >>>> why it?s safe to drop VM errors. >>> >>> You are absolutely right, I went too far in clearing ALL pending >>> exceptions. I need to check for VME and do immediate return in that >>> case; and restore the CHECK usage in the callers. Not only should >>> VMEs be fail-fast, but they are also cases where we should be allowed >>> to retry determining the nest host. >>> >>> Updated webrevs: >>> >>> Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ >>> >>> (ciField.cpp and reflection.cpp are simply reverted) >>> >>> Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2/ >>> >>> Thanks, >>> David >>> >>>> ? John >>>> From david.holmes at oracle.com Thu Mar 12 22:25:56 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2020 08:25:56 +1000 Subject: (Nestmates) RFR (M): 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 In-Reply-To: <90995f28-08cf-6b89-17f7-8e2149a36516@oracle.com> References: <3419A35C-F164-4DFE-BA06-AA066A45E3BC@oracle.com> <90995f28-08cf-6b89-17f7-8e2149a36516@oracle.com> Message-ID: <7485d825-20fb-4267-5c3a-77e3934c3116@oracle.com> Thanks Lois! I think I can push this now. David On 13/03/2020 4:48 am, Lois Foltan wrote: > On 3/11/2020 1:25 AM, David Holmes wrote: >> John pointed out to me offline that there are now race conditions >> possible due to the setting of the error message. I had been lulled >> into a false sense of security by the overall idempotency of the >> operation. Simple fix is to introduce storestore barriers in a couple >> of places to ensure we write the error string, then the >> _nest_host_res_error field, then the _nest_host field, in that order. >> Commentary updated as well. >> >> This update also includes Lois's suggested cleanup in linkResolver.cpp. >> >> Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3-incr/ >> >> Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v3/ > > Looks good David, thanks for making the ss.print change I suggested. > Lois > >> >> Thanks, >> David >> >> On 9/03/2020 9:09 am, David Holmes wrote: >>> Hi John, >>> >>> On 7/03/2020 7:45 am, John Rose wrote: >>>> Nice work, very thorough as usual. >>> >>> Thanks - and thanks for looking at this. >>> >>>> One nit.? The back-to-back parens are bad style. >>>> >>>>> foo (bar)(baz) >>>> >>>> https://english.stackexchange.com/questions/19429/should-i-use-adjacent-parentheses-or-a-semicolon-or-something-else >>>> >>>> https://blog.apastyle.org/apastyle/2013/05/punctuation-junction-parentheses-and-brackets.html >>>> >>> >>> Okay - hadn't realized there was an applicable style here as I was >>> just implementing a multi-part message by a simple concatenation of >>> () delimited segments. >>> >>>> There are different ways to handle this in professional text. >>>> I think the simplest way is relatively tricky from our perspective. >>>> You merge the two parentheticals with an internal semicolon: >>>> >>>>> foo (bar; baz) >>> >>> I think that would make it very hard to spot the changeover. >>> >>>> A really simple tweak to your code would be to put a comma >>>> between.? This is less standard but better than back-to-back >>>> parens: >>>> >>>> -+??????? ss.print("("); >>>> ++??????? ss.print(?, (?); >>>> >>>> (Two places.) >>> >>> Ok - that works for me. >>> >>>> Likewise, in two places: >>>> >>>> -+????? msg = "(stuff?)"; >>>> ++????? msg = " (stuff?)?; >>>> >>>> ?to avoid the left paren making hard contact with the preceding text. >>> >>> If this is referring to instanceKlass.cpp: >>> >>> ??363?????? msg = "(the NestHost attribute in the current class is >>> ignored)"; >>> ??364???? } else if (_nest_members != NULL && _nest_members != >>> Universe::the_empty_short_array()) { >>> ??365?????? msg = "(the NestMembers attribute in the current class is >>> ignored)"; >>> >>> then the space is part of the main formatted string: >>> >>> ??367???? log_trace(class, nestmates)("Injected type %s into the nest >>> of %s %s", >>> ??368???????????????????????????????? this->external_name(), >>> ??369???????????????????????????????? host->external_name(), >>> ??370???????????????????????????????? msg); >>> >>> >>>> Klass::_nest_host_res_error is ok.? If we ever decide to reduce the >>>> footprint there (as part of a larger effort, I think), we could merge >>>> both fields by using a tagged pointer, on the observation that you >>>> only need one or the other to be non-null.? If the res-error is not >>>> null, then we can infer that nest-host has been determined to be >>>> self, and in that case we don?t need to look at the field, right? >>> >>> A non-NULL res-err does imply _nest_host == this. But not vice-versa. >>> >>>> You might want to add a comment about the possible states of >>>> those two coupled variables, to help maintainers.? For example: >>>> >>>> + // This variable is non-null only if _nest_host is null. >>>> >>>> Actually, I didn?t follow the logic fully:? Can both fields be non-null >>>> at the same time?? It looks like Klass::nest_host only gets set >>>> non-null >>>> on error-free paths, while the error string is set only on error paths. >>>> It would be reasonable for Klass::nest_host to check for an error >>>> string and immediately return ?this? if one is set.? I didn?t see this. >>>> >>>> Maybe the comment should be: >>>> >>>> + // This variable is non-null only if _nest_host is this or (during >>>> a race) null. >>>> >>>> (And if there?s a race, please do a releasing store of the error >>>> string before >>>> setting the _nest_host to ?this?.? But at-least-one-always-null is a >>>> safer >>>> convention for managing races.? So I like the first comment much >>>> better.) >>> >>> _nest_host is always set, even when there is an error. So nest_host() >>> does a quick return in all calls other than the first (modulo the >>> rare case where we had to bail out because we are in a compiler >>> thread; or VME occurred): >>> >>> ??226 InstanceKlass* InstanceKlass::nest_host(TRAPS) { >>> ??227?? InstanceKlass* nest_host_k = _nest_host; >>> ??228?? if (nest_host_k != NULL) { >>> ??229???? return nest_host_k; >>> ??230?? } >>> >>> I can't see any way to reduce footprint in this area as we have two >>> very distinct entities we are tracking. >>> >>>> Also, let?s talk about VirtualMachineError. >>>> >>>> After thinking about it a bit, I think you went too far replacing CATCH >>>> by THREAD; this makes a fragile assumption that nothing is coming >>>> out of the call.? It?s fragile because, although we expect >>>> LinkageError, >>>> there?s usually an additional possibility of VirtualMachineError. >>>> Doing a catch-and-clear of VME is risky business, and in this case >>>> I only think we need to catch and clear the LE, not the VME. >>>> >>>> To me, it seems safest to always expect VME, and always pass it on, >>>> as a basic convention in our code base, with clear documentation >>>> wherever we do something different. >>>> >>>> Imagine getting an access error later on, with the parenthetical >>>> remark that the nest host failed due to SOE or OOME.? Those guys >>>> should be fail-fast, I think.? Or did you come up with a reason they >>>> should be muzzled also, along with the LE we intend to muzzle? >>>> >>>> I see the previous code processed VME differently, and that you >>>> removed it, so I know you did this as a considered step.? But still >>>> it seems off to me.? At least add some documentation explaining >>>> why it?s safe to drop VM errors. >>> >>> You are absolutely right, I went too far in clearing ALL pending >>> exceptions. I need to check for VME and do immediate return in that >>> case; and restore the CHECK usage in the callers. Not only should >>> VMEs be fail-fast, but they are also cases where we should be allowed >>> to retry determining the nest host. >>> >>> Updated webrevs: >>> >>> Incremental: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2-incr/ >>> >>> (ciField.cpp and reflection.cpp are simply reverted) >>> >>> Full: http://cr.openjdk.java.net/~dholmes/8240645/webrev.v2/ >>> >>> Thanks, >>> David >>> >>>> ? John >>>> > From john.r.rose at oracle.com Fri Mar 13 00:35:50 2020 From: john.r.rose at oracle.com (John Rose) Date: Thu, 12 Mar 2020 17:35:50 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> Message-ID: <6B54B71C-28E2-438A-A2FA-8D55D3749216@oracle.com> On Mar 11, 2020, at 3:34 PM, David Holmes wrote: > > But I much prefer what was suggested previously: either default is strong and you can ask for weak; or default is weak and you can ask for strong. I?m less averse to a tri-state option, but I agree it?s awkward. As I said before, WEAK is the natural semantics, which means that it should be the default. STRONG is a special semantics which links the HC to its CL; STRONG is desirable in cases where the creator of the HC has special knowledge that the HC will in fact be ?rooted? (in the GC sense) in some part of a class belonging to the CL. Any use of invokedynamic is like this, since the indy makes a durable reference from the call site to the HC that implements it. But notice this: When a LMF creates a HC for a lambda, there is no way to know that this HC will be linked permanently to an indy instruction, other than asking the author of the LMF. That?s why the author needs to say, ?this HC will be permanently installed where I?m putting it?. And in that case, if the LMF author knows that STRONG gets slightly better footprint, the LMF author should ask for STRONG mode. Here?s a key point: Because WEAK mode is the natural mode for Has, it would be correct (but less efficient) for the LMF author to accept WEAK mode. Setting STRONG model later on would be a compatible change improving performance. Let?s turn that key point around: Suppose you have a very data-driven system (as opposed to a class-driven one) more like Nashorn. In that case, HCs can be used to customize behaviors, but they will typically be stored in lookup tables, not attached to call sites in classes. (Nashorn does both IIRC.) In particular, HCs which are shared between classes, which is a common tactic (in java.lang.invoke, for example!) are stored not in classes but in tables. Which CL should those guys be attached to? There?s no right answer, but HCs don?t care about they; their natural behavior is to go dead as soon as the last client drops a reference to them. Let?s pretend for a moment that the option is a straight-up boolean argument, to back away from ?who gets the good syntax?. Note that there are class-based and data-driven uses of HCs. What are the costs and benefits of setting the switch either way in both cases? use mode correct? performant? class WEAK yes footprint cost class STRONG yes(*) yes data WEAK yes footprint cost data STRONG NO OOME What do we learn from this? The behavior I?m calling ?natural? (WEAK mode) is natural because it is correct in all cases, although some cases, given special advice from the coder, have a more performant option. The unnatural STRONG mode is unnatural because some valid uses of the HC mechanism will fill up the heap with still-loaded, unusable HC bodies until an OOME. The OOME is not because the HCs were used according to spec, it is because the JVM has shirked its duty to get rid of them when they are no longer needed. The star (*) above means, ?yes, this behavior is correct, but only in this very special case??where the programmer promises (correctly) that the HC will be used as long as the LC (or some other CL-based class) is in existence. That?s what I mean by natural. If you use STRONG mode on a HC, you introduce a new failure mode (OOME) not part of the overall HC contract. I suppose you could say ?No, John, HC?s *naturally* accumulate on their LC until OOME, an *that?s* the true natural behavior.? But then WEAK becomes *another* natural behavior, of ?free-range? HCs. The more economical specification here is to say that HCs are normally free-range (managed by the GC and unloaded when all uses disappear), but a special option ties them *additionally* (not *instead*!!) to the CL of their LC. OK, so now how to set the default? The answer should be easy, and here it is: Set the default so that the behavior of the LC is always as correct as possible, given no further contextual information. The non-default will be a setting which can sometimes be the wrong decision, but may provide special benefits in special situations. The old saying for coders is ?first make it work, then make it fast?. WEAK mode *always* makes it work, while STRONG mode *sometimes* makes it fast (and other times makes it wrong). So, get rid of WEAK and add STRONG. And code all of our class-based (indy-serving) metafactories to specify STRONG. I?m glad to get this off my chest. I?ve hated the setting of the default to STRONG ever since this project started, but saw it as a losing battle because folks were looking at the implementation (where the easy setting is STRONG and WEAK is annoying extra work). But I?m the inventor of this thing, and you can trust me to know what are the set of valid use cases (and not just the current ones). ? John From john.r.rose at oracle.com Fri Mar 13 00:43:42 2020 From: john.r.rose at oracle.com (John Rose) Date: Thu, 12 Mar 2020 17:43:42 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> Message-ID: After ?doing the math? (in the previous note) I?m with David being skeptical of ?unspecified?. If a JVM implementation maps ?unspecified? to STRONG that?s a bug, not a feature, because it takes away the ability to unload the HC based on GC liveness. That leads to OOMEs with very difficult workarounds. Only WEAK mode is safe. So the best we could do is say that ?if neither option is specified, then the mode defaults to WEAK?. But at that point, why have WEAK at all? You only need the token for the non-default setting. On Mar 11, 2020, at 7:26 PM, David Holmes wrote: > >> There are cases that the library code does not care. > > I am skeptical of that. If you do the analysis and determine that you don't need a strong connection then actually getting a strong connection will work fine but may lead to footprint issues. If you don't need a strong connection I don't see why you would choose to let it default rather than selecting weak. If you select weak and find there is a performance issue then you would switch to strong, comment why, and file a RFE to fix the performance issue. I just don't see "don't care" coming into this. And of course if you need strong then allowing it to default is just broken! > >> Note that the main motivation to allow a hidden class be strongly referenced because of our current implementation. It creates a ClassLoaderData per weak class that may result in fragmentation and incur bad performance overhead. > > That sounds like a deficiency in the VM that should be addressed. > >> This is solely implementation detail. Other VM implementation may favor weak classes. An implementation-specific default will give flexibility to the developers (not to specify neither strong or weak) to choose whatever performs best when running on a VM implementation. > > Again I just don't buy that developers will write code that way. No one wants to depend on the performance characteristics of a default that could change on every release. > > David From david.holmes at oracle.com Fri Mar 13 01:49:26 2020 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 13 Mar 2020 01:49:26 +0000 Subject: hg: valhalla/valhalla: 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 Message-ID: <202003130149.02D1nR5S023399@aojmv0008.oracle.com> Changeset: 5f2cb0b8962d Author: dholmes Date: 2020-03-12 21:36 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5f2cb0b8962d 8240645: Update nest host determination in line with latest proposed JVMS changes for JEP-371 Reviewed-by: mchung, jrose, hseigel, lfoltan ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! src/java.base/share/classes/java/lang/Class.java ! test/hotspot/jtreg/runtime/Nestmates/membership/TestNestmateMembership.java ! test/hotspot/jtreg/runtime/Nestmates/privateMethods/TestInvokeErrors.java ! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java ! test/jdk/java/lang/reflect/Nestmates/TestReflectionAPI.java From alex.buckley at oracle.com Fri Mar 13 16:09:35 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 13 Mar 2020 09:09:35 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> Message-ID: <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> On 3/12/2020 5:43 PM, John Rose wrote: > After ?doing the math? (in the previous note) I?m with David being > skeptical of ?unspecified?. If a JVM implementation maps > ?unspecified? to STRONG that?s a bug, not a feature ... Only WEAK > mode is safe. So the best we could do is say that ?if neither option > is specified, then the mode defaults to WEAK?. But at that point, > why have WEAK at all? You only need the token for the non-default > setting. Got it: (i) the default is specified to be WEAK; (ii) the API offers a single enum constant, STRONG, to override the default; (iii) both of the previous clauses apply to hidden classes that are nestmates AND to hidden classes that are not nestmates. Thanks for the enjoyable writeup. Zooming out, I recommend that the phrase "weak class" be exorcised from JEP 371. It always bothered me that the JEP introduced a concept which sounds first-class, as if it applies widely (inviting "Excuse me, will Lookup::defineClass be extended to take the WEAK option? Where are weak classes in the JVM Specification?" etc), but then pulled the rug by saying it's limited to hidden classes. I think we should frame a hidden class's loose relationship with its deemed-defining loader as just another superpower that Lookup::defineHiddenClass can arrange, along with (say) a hidden class being able to join a nest without holding an entry ticket (i.e. no NestHost attribute). Similarly, if STRONG is specified, then there's no "strong class" to put on a pedestal -- the hidden class's relationship with its deemed-defining loader is exactly the same as an ordinary class's relationship with its defining loader. Alex From john.r.rose at oracle.com Fri Mar 13 19:31:12 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Mar 2020 12:31:12 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> Message-ID: On Mar 13, 2020, at 9:09 AM, Alex Buckley wrote: > > Got it: (i) the default is specified to be WEAK; (ii) the API offers a single enum constant, STRONG, to override the default; (iii) both of the previous clauses apply to hidden classes that are nestmates AND to hidden classes that are not nestmates. Thanks for the enjoyable writeup. You are welcome. I agree with your following comment that ?weak class? is a fraught concept. One more little clarification: On Mar 12, 2020, at 5:35 PM, John Rose wrote: > > a special option ties them *additionally* (not *instead*!!) > to the CL of their LC. I said ?not instead? because, of course, even if a CL would go dead somehow and wish to take the HC along with it to the junkyard, the HC has to stay alive if some table somewhere has the last remaining reference to that HC, and (via it) to the CL. A HC naturally keeps its CL alive via a strong reference (because it might need the CL to resolve symbols). The CL repays the favor by keeping the HC alive only if the HC was loaded with the STRONG option. We implement this by grouping the HC with the CL?s metadata segment, but from the user?s POV (and in a different implementation) it is as if the CL has an extra little table of pointers to STRONG-mode HCs that it has become acquainted with. ? John From mandy.chung at oracle.com Fri Mar 13 21:49:44 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Mar 2020 14:49:44 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> Message-ID: <9e2888a7-fc78-bc89-cb37-6f94b54bb1c3@oracle.com> On 3/13/20 9:09 AM, Alex Buckley wrote: > On 3/12/2020 5:43 PM, John Rose wrote: >> After ?doing the math? (in the previous note) I?m with David being >> skeptical of ?unspecified?.? If a JVM implementation maps >> ?unspecified? to STRONG that?s a bug, not a feature ... Only WEAK >> mode is safe.? So the best we could do is say that ?if neither option >> is specified, then the mode defaults to WEAK?.? But at that point, >> why have WEAK at all? You only need the token for the non-default >> setting. > > Got it: (i) the default is specified to be WEAK; (ii) the API offers a > single enum constant, STRONG, to override the default; (iii) both of > the previous clauses apply to hidden classes that are nestmates AND to > hidden classes that are not nestmates. Thanks for the enjoyable writeup. > > Zooming out, I recommend that the phrase "weak class" be exorcised > from JEP 371. It always bothered me that the JEP introduced a concept > which sounds first-class, as if it applies widely (inviting "Excuse > me, will Lookup::defineClass be extended to take the WEAK option? > Where are weak classes in the JVM Specification?" etc), but then > pulled the rug by saying it's limited to hidden classes. I think we > should frame a hidden class's loose relationship with its > deemed-defining loader as just another superpower that > Lookup::defineHiddenClass can arrange, along with (say) a hidden class > being able to join a nest without holding an entry ticket (i.e. no > NestHost attribute). Similarly, if STRONG is specified, then there's > no "strong class" to put on a pedestal -- the hidden class's > relationship with its deemed-defining loader is exactly the same as an > ordinary class's relationship with its defining loader. This sounds all good to me. When a hidden class whose relationship with its deemed-defining loader is different than that of an ordinary class, Class::getClassLoader returns its deemed-defining loader and so does JVM TI GetClassLoader.?? No issue with that. From JVM TI perspective, each "loaded" class has one defining loader and N initiating loaders.? N is >= 1 in JDK 14 and with hidden classes, N becomes >= 0. For a hidden class whose has either a loose relationship with its deemed-defining loader, this is arranged by `Lookup::defineHiddenClass`.?? From JVM's perspective, a hidden class is a "normal" class and I think same applies to JVM TI.? We want hidden classes to be debuggable.??? JVM TI and JDI etc assume classes are always "loaded". Now, a class can be: 1. a loaded (ordinary) class 2. a hidden class whose has a loose relationship with its deemed-defining loader 3. a hidden class whose has a strong relationship with its deemed-defining loader - exactly the same as an ordinary class's relationship with its defining loader From tool's perspective, it wants to find all loaded classes or loaded classes initiated & defined by a given loader.?? Tools can determine if a class is a hidden class or ordinary class using Class::isHiddenClass or by its name.?? While hidden classes are not "loaded", having JVM TI to define new API for this new "API-created-class" and making the tools to handle hidden classes using new JVM TI events and new JVM TI APIs seem too high cost with little benefit.?? Do you see this wrong? Mandy From alex.buckley at oracle.com Fri Mar 13 22:07:40 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 13 Mar 2020 15:07:40 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <9e2888a7-fc78-bc89-cb37-6f94b54bb1c3@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <9e2888a7-fc78-bc89-cb37-6f94b54bb1c3@oracle.com> Message-ID: On 3/13/2020 2:49 PM, Mandy Chung wrote: > From JVM's perspective, a hidden class is > a "normal" class and I think same applies to JVM TI.? We want hidden > classes to be debuggable.??? JVM TI and JDI etc assume classes are > always "loaded". Can you point to the JVM TI and JDI specs which speak of "loaded" classes? We may get lucky like we did with the JVM Specification, which has always spoken of "creating" a class (not just "loading" it) and thus offered a hook to introduce classes which are created without being loaded. > From tool's perspective, it wants to find all loaded classes or loaded > classes initiated & defined by a given loader.?? Tools can determine if > a class is a hidden class or ordinary class using Class::isHiddenClass > or by its name.?? While hidden classes are not "loaded", having JVM TI > to define new API for this new "API-created-class" and making the tools > to handle hidden classes using new JVM TI events and new JVM TI APIs > seem too high cost with little benefit.?? Do you see this wrong? I agree we shouldn't double up a bunch of JVM TI methods by introducing return-just-the-hidden-classes variants. Since there was a performance/overhead concern with WEAK, let me ask a similar question here: is there an overhead from making a hidden class debuggable? Might a user of Lookup::defineHiddenClass say "No! I don't want this hidden class to be debuggable if it costs any bytes at all." Alex From john.r.rose at oracle.com Fri Mar 13 22:17:28 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Mar 2020 15:17:28 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <9e2888a7-fc78-bc89-cb37-6f94b54bb1c3@oracle.com> Message-ID: <4BA5FD8B-D436-45A7-B244-EDABE2A9A009@oracle.com> On Mar 13, 2020, at 3:07 PM, Alex Buckley wrote: > > On 3/13/2020 2:49 PM, Mandy Chung wrote: >> From JVM's perspective, a hidden class is a "normal" class and I think same applies to JVM TI. We want hidden classes to be debuggable. JVM TI and JDI etc assume classes are always "loaded". > > Can you point to the JVM TI and JDI specs which speak of "loaded" classes? We may get lucky like we did with the JVM Specification, which has always spoken of "creating" a class (not just "loading" it) and thus offered a hook to introduce classes which are created without being loaded. If we have ?deemed loaders? we can have ?deemed loaded?, perhaps? That would cut this particular knot. From the JVM?s POV, a ?live? class is live regardless of how it got there. Is there any language in the specs. that speaks of ?live?-ness without appealing to a prior loading event (by saying ?loaded?)? If not, ?deemed loaded? would seem to be a reasonable patch on the terminology. (BTW, when I say ?live? here, I mean that the JVM has either prepared, linked, and initialized the class already, or is prepared to on demand, the first time somebody starts to use the class. Normally the step just before all these states is loading.) > From tool's perspective, it wants to find all loaded classes or loaded classes initiated & defined by a given loader. Tools can determine if a class is a hidden class or ordinary class using Class::isHiddenClass or by its name. While hidden classes are not "loaded", having JVM TI to define new API for this new "API-created-class" and making the tools to handle hidden classes using new JVM TI events and new JVM TI APIs seem too high cost with little benefit. Do you see this wrong? > > I agree we shouldn't double up a bunch of JVM TI methods by introducing return-just-the-hidden-classes variants. Since there was a performance/overhead concern with WEAK, let me ask a similar question here: is there an overhead from making a hidden class debuggable? Might a user of Lookup::defineHiddenClass say "No! I don't want this hidden class to be debuggable if it costs any bytes at all.? I don?t anticipate that happening. By the time JVMTI sees a computation involving a HC, all the queries it might do on it will be pretty straightforward. Some TI/DI operations are likely to fail on a HC, such as anything that involves reconstructing and reloading classfile bytes. It?s not clear to me that we are compelled to document all those limitations scrupulously. They will either fail or not in use, and we can retroactively improve the spec if that?s an issue to tool vendors. A similar issue exists today when you reconstruct and reload a class too many times, if it runs out of CP slots. I.e., reconstruction is a ?best effort? operation, and tools can fail on those. ? John From mandy.chung at oracle.com Fri Mar 13 22:26:19 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Mar 2020 15:26:19 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <9e2888a7-fc78-bc89-cb37-6f94b54bb1c3@oracle.com> Message-ID: On 3/13/20 3:07 PM, Alex Buckley wrote: > On 3/13/2020 2:49 PM, Mandy Chung wrote: >> From JVM's perspective, a hidden class is a "normal" class and I >> think same applies to JVM TI.? We want hidden classes to be >> debuggable.??? JVM TI and JDI etc assume classes are always "loaded". > > Can you point to the JVM TI and JDI specs which speak of "loaded" > classes? We may get lucky like we did with the JVM Specification, > which has always spoken of "creating" a class (not just "loading" it) > and thus offered a hook to introduce classes which are created without > being loaded. > https://download.java.net/java/early_access/jdk15/docs/specs/jvmti.html#GetLoadedClasses https://download.java.net/java/early_access/jdk15/docs/specs/jvmti.html#GetClassLoaderClasses https://download.java.net/java/early_access/jdk15/docs/specs/jvmti.html#ClassLoad https://download.java.net/java/early_access/jdk15/docs/api/java.instrument/java/lang/instrument/Instrumentation.html#getAllLoadedClasses() https://download.java.net/java/early_access/jdk15/docs/api/jdk.jdi/com/sun/jdi/VirtualMachine.html#allClasses() https://download.java.net/java/early_access/jdk15/docs/api/java.management/java/lang/management/ClassLoadingMXBean.html#getLoadedClassCount() https://download.java.net/java/early_access/jdk15/docs/api/java.management/java/lang/management/ClassLoadingMXBean.html#getTotalLoadedClassCount() Above are the main ones but not a complete list. >> From tool's perspective, it wants to find all loaded classes or >> loaded classes initiated & defined by a given loader.?? Tools can >> determine if a class is a hidden class or ordinary class using >> Class::isHiddenClass or by its name.?? While hidden classes are not >> "loaded", having JVM TI to define new API for this new >> "API-created-class" and making the tools to handle hidden classes >> using new JVM TI events and new JVM TI APIs seem too high cost with >> little benefit.?? Do you see this wrong? > > I agree we shouldn't double up a bunch of JVM TI methods by > introducing return-just-the-hidden-classes variants. Since there was a > performance/overhead concern with WEAK, let me ask a similar question > here: is there an overhead from making a hidden class debuggable? No, as far as the current JDI implementation goes.? Very small change is made in JDI to get jdb to debug on a hidden class, namely handle the hidden class' name properly (not a binary name). Serguei did the initial work in JDI to get jdb to debug a hidden class (both bytecode level and even source-level when SourceFile attribute is present. Mandy > Might a user of Lookup::defineHiddenClass say "No! I don't want this > hidden class to be debuggable if it costs any bytes at all." > > Alex From mandy.chung at oracle.com Fri Mar 13 22:31:57 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Mar 2020 15:31:57 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <9e2888a7-fc78-bc89-cb37-6f94b54bb1c3@oracle.com> Message-ID: <1a5d8a32-0d32-e798-ecdf-f9107909787e@oracle.com> On 3/13/20 3:26 PM, Mandy Chung wrote: >> I agree we shouldn't double up a bunch of JVM TI methods by >> introducing return-just-the-hidden-classes variants. Since there was >> a performance/overhead concern with WEAK, let me ask a similar >> question here: is there an overhead from making a hidden class >> debuggable? > > No, as far as the current JDI implementation goes.? Very small change > is made in JDI to get jdb to debug on a hidden class, namely handle > the hidden class' name properly (not a binary name). > > Serguei did the initial work in JDI to get jdb to debug a hidden class > (both bytecode level and even source-level when SourceFile attribute > is present. W.r.t. unloading of a hidden class while its defining class loader is alive, Serguei is still investigating its implication and also scheduling a meeting with IntelliJ to discuss that. Mandy From mandy.chung at oracle.com Fri Mar 13 22:37:45 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Mar 2020 15:37:45 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> Message-ID: On 3/13/20 9:09 AM, Alex Buckley wrote: > On 3/12/2020 5:43 PM, John Rose wrote: >> After ?doing the math? (in the previous note) I?m with David being >> skeptical of ?unspecified?.? If a JVM implementation maps >> ?unspecified? to STRONG that?s a bug, not a feature ... Only WEAK >> mode is safe.? So the best we could do is say that ?if neither option >> is specified, then the mode defaults to WEAK?.? But at that point, >> why have WEAK at all? You only need the token for the non-default >> setting. > > Got it: (i) the default is specified to be WEAK; (ii) the API offers a > single enum constant, STRONG, to override the default; (iii) both of > the previous clauses apply to hidden classes that are nestmates AND to > hidden classes that are not nestmates. Thanks for the enjoyable writeup. > Please take a look the `Lookup::defineHiddenClass` spec and `ClassOption`: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ Thanks Mandy From mandy.chung at oracle.com Fri Mar 13 23:03:20 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Mar 2020 16:03:20 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <4BA5FD8B-D436-45A7-B244-EDABE2A9A009@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <9e2888a7-fc78-bc89-cb37-6f94b54bb1c3@oracle.com> <4BA5FD8B-D436-45A7-B244-EDABE2A9A009@oracle.com> Message-ID: <0f8af0c1-9932-15ba-2581-b371ff798a8d@oracle.com> On 3/13/20 3:17 PM, John Rose wrote: > On Mar 13, 2020, at 3:07 PM, Alex Buckley wrote: >> On 3/13/2020 2:49 PM, Mandy Chung wrote: >>> From JVM's perspective, a hidden class is a "normal" class and I think same applies to JVM TI. We want hidden classes to be debuggable. JVM TI and JDI etc assume classes are always "loaded". >> Can you point to the JVM TI and JDI specs which speak of "loaded" classes? We may get lucky like we did with the JVM Specification, which has always spoken of "creating" a class (not just "loading" it) and thus offered a hook to introduce classes which are created without being loaded. > If we have ?deemed loaders? we can have ?deemed loaded?, perhaps? > That would cut this particular knot. From the JVM?s POV, a ?live? > class is live regardless of how it got there. Is there any language > in the specs. that speaks of ?live?-ness without appealing to a > prior loading event (by saying ?loaded?)? If not, ?deemed loaded? > would seem to be a reasonable patch on the terminology. AFAIK, no speak of live-ness as I think it's not mentioned in JVMS neither. JVM TI has ClassLoad event and ClassPrepare event and GetClassStatus API follow the status defined in JVMS 5: loaded, verified, prepared, initialized. > (BTW, when I say ?live? here, I mean that the JVM has either > prepared, linked, and initialized the class already, or is prepared > to on demand, the first time somebody starts to use the class. > Normally the step just before all these states is loading.) Yes.? A "loaded" class can be of any of the above status. >> From tool's perspective, it wants to find all loaded classes or loaded classes initiated & defined by a given loader. Tools can determine if a class is a hidden class or ordinary class using Class::isHiddenClass or by its name. While hidden classes are not "loaded", having JVM TI to define new API for this new "API-created-class" and making the tools to handle hidden classes using new JVM TI events and new JVM TI APIs seem too high cost with little benefit. Do you see this wrong? >> >> I agree we shouldn't double up a bunch of JVM TI methods by introducing return-just-the-hidden-classes variants. Since there was a performance/overhead concern with WEAK, let me ask a similar question here: is there an overhead from making a hidden class debuggable? Might a user of Lookup::defineHiddenClass say "No! I don't want this hidden class to be debuggable if it costs any bytes at all.? > I don?t anticipate that happening. By the time JVMTI sees a > computation involving a HC, all the queries it might do on it > will be pretty straightforward. Some TI/DI operations are likely > to fail on a HC, such as anything that involves reconstructing > and reloading classfile bytes. It?s not clear to me that we are > compelled to document all those limitations scrupulously. > They will either fail or not in use, and we can retroactively > improve the spec if that?s an issue to tool vendors. A similar > issue exists today when you reconstruct and reload a class > too many times, if it runs out of CP slots. I.e., reconstruction > is a ?best effort? operation, and tools can fail on those. > +1.?? JVM TI detects if a given class has been unloaded and returns JVMTI_ERROR_INVALID_CLASS that tools can check and handle in the case of class unloading. Mandy From alex.buckley at oracle.com Fri Mar 13 23:28:39 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 13 Mar 2020 16:28:39 -0700 (PDT) Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> Message-ID: <351c42d7-f81c-c700-3156-af42ae7b0d51@oracle.com> On 3/13/2020 3:37 PM, Mandy Chung wrote: > Please take a look the `Lookup::defineHiddenClass` spec and `ClassOption`: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ We're really writing the JEP here. The API spec should just follow that, with sentences taken out so it boils down to one paragraph. Speak about the "relationship" concept only at the top and bottom of the paragraph, not in the middle where technical statements about reachability and reclaiming exist. Plus, don't start with the behavior embodied by STRONG -- we believe that weak is the natural state of hidden classes. Plus, I want to hold off from saying "loose" if possible -- usually I'm the person demanding that terminology completely covers the design space, but right now I want to leave room for us to spin up text about "weak relationship that may or may not imply weak references". Start by saying "Every class created by a class loader has a strong relationship with that class loader. That is, every `Class` object contains a `reference` to the `ClassLoader` that [defined it](LINK TO CLASS::GETCLASSLOADER). This means that a class created by a class loader may be unloaded if and only if its defining loader is not reachable and thus may be reclaimed by a garbage collector (JLS 12.7)." Continuing: "By default, however, a hidden class may be unloaded even if the class loader that is marked as its defining loader is reachable. This allows <>. Continuing: "In cases where <>, the `STRONG` option may be passed in `options`. This arranges for a hidden class or interface to have the same relationship with the class loader marked as its defining loader, as a normal class or interface has with its own defining loader." Finally: "[A rule about independence of HCs from each other:] The unloading characteristics are set for each hidden class when it is defined, and cannot be changed later. [A note about independence of HCs from CLs] An advantage of allowing hidden classes to be unloaded independently of the loader deemed as their defining loader is that a very large number of hidden classes may be created by an application. In contrast, if STRONG is used, then the JVM may run out of memory, just as if normal classes were created by class loaders." Alex From harold.seigel at oracle.com Mon Mar 16 11:46:03 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Mon, 16 Mar 2020 11:46:03 +0000 Subject: hg: valhalla/valhalla: 8240551: [nestmates] runtime/HiddenClasses/StressHiddenClasses.java timeout with Graal Message-ID: <202003161146.02GBk3kD026467@aojmv0008.oracle.com> Changeset: 186eb4a26b8e Author: hseigel Date: 2020-03-16 11:45 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/186eb4a26b8e 8240551: [nestmates] runtime/HiddenClasses/StressHiddenClasses.java timeout with Graal Summary: Change test to not run when Graal is enabled Reviewed-by: mchung ! test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java From harold.seigel at oracle.com Tue Mar 17 14:32:55 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 17 Mar 2020 14:32:55 +0000 Subject: hg: valhalla/valhalla: 8216581: Add support in JFR for hidden classes Message-ID: <202003171432.02HEWuWI009794@aojmv0008.oracle.com> Changeset: 62a97593094e Author: hseigel Date: 2020-03-17 14:32 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/62a97593094e 8216581: Add support in JFR for hidden classes Summary: add event support and "hidden" field for Java Classes Reviewed-by: coleenp, mgronlun ! src/hotspot/share/classfile/classLoaderStats.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp ! src/hotspot/share/memory/metaspace/printCLDMetaspaceInfoClosure.cpp ! src/hotspot/share/memory/metaspaceTracer.cpp ! src/hotspot/share/oops/klass.hpp ! test/jdk/jdk/jfr/event/runtime/TestClassDefineEvent.java ! test/jdk/jdk/jfr/event/runtime/TestClassLoadEvent.java ! test/jdk/jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java ! test/jdk/jdk/jfr/event/runtime/TestClassLoadingStatisticsEvent.java ! test/jdk/jdk/jfr/event/runtime/TestClassUnloadEvent.java ! test/jdk/jdk/jfr/event/runtime/TestClasses.java ! test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java From mandy.chung at oracle.com Tue Mar 17 18:38:15 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 17 Mar 2020 18:38:15 +0000 Subject: hg: valhalla/valhalla: [nestmates] Change the default of Hidden class to have its own lifecycle independent of its defining loader. Message-ID: <202003171838.02HIcGEK026553@aojmv0008.oracle.com> Changeset: f4f1d5294876 Author: mchung Date: 2020-03-17 11:37 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f4f1d5294876 [nestmates] Change the default of Hidden class to have its own lifecycle independent of its defining loader. Reviewed-by: lfoltan, hseigel Contributed-by: alex.buckley at oracle.com, mandy.chung at oracle.com ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! test/hotspot/jtreg/runtime/HiddenClasses/GCHiddenClass.java ! test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java ! test/hotspot/jtreg/runtime/HiddenClasses/TestHiddenClassUnloading.java ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java ! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java ! test/jdk/java/lang/invoke/defineHiddenClass/DefineClassWithClassData.java ! test/jdk/java/lang/invoke/defineHiddenClass/HiddenNestmateTest.java + test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java + test/jdk/java/lang/invoke/defineHiddenClass/src/LookupHelper.java ! test/jdk/jdk/jfr/event/runtime/TestClasses.java + test/lib/jdk/test/lib/util/ForceGC.java ! test/micro/org/openjdk/bench/java/lang/invoke/LookupDefineClass.java From mandy.chung at oracle.com Tue Mar 17 20:41:43 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 Mar 2020 13:41:43 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <351c42d7-f81c-c700-3156-af42ae7b0d51@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <351c42d7-f81c-c700-3156-af42ae7b0d51@oracle.com> Message-ID: <81c1ce27-3cf2-4b9e-7f32-bc0ef4d3f3a3@oracle.com> The javadoc is updated per offline discussion with Alex. http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ I pushed this version to the sandbox to get the new ClassOption::STRONG in.? We can continue to improve the javadoc per any feedback. Mandy On 3/13/20 4:28 PM, Alex Buckley wrote: > On 3/13/2020 3:37 PM, Mandy Chung wrote: >> Please take a look the `Lookup::defineHiddenClass` spec and >> `ClassOption`: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ >> > > We're really writing the JEP here. The API spec should just follow > that, with sentences taken out so it boils down to one paragraph. > > Speak about the "relationship" concept only at the top and bottom of > the paragraph, not in the middle where technical statements about > reachability and reclaiming exist. Plus, don't start with the behavior > embodied by STRONG -- we believe that weak is the natural state of > hidden classes. Plus, I want to hold off from saying "loose" if > possible -- usually I'm the person demanding that terminology > completely covers the design space, but right now I want to leave room > for us to spin up text about "weak relationship that may or may not > imply weak references". > > Start by saying "Every class created by a class loader has a strong > relationship with that class loader. That is, every `Class` object > contains a `reference` to the `ClassLoader` that [defined it](LINK TO > CLASS::GETCLASSLOADER). This means that a class created by a class > loader may be unloaded if and only if its defining loader is not > reachable and thus may be reclaimed by a garbage collector (JLS 12.7)." > > Continuing: "By default, however, a hidden class may be unloaded even > if the class loader that is marked as its defining loader is > reachable. This allows < about "go dead as soon as the last client drops a reference to them" > -- this text will not be easy to write, but it belongs here -- also > there used to be text about libraries who use WEAK needing to take > care of their Class objects>>. > > Continuing: "In cases where < installed is important>>, the `STRONG` option may be passed in > `options`. This arranges for a hidden class or interface to have the > same relationship with the class loader marked as its defining loader, > as a normal class or interface has with its own defining loader." > > Finally: "[A rule about independence of HCs from each other:] The > unloading characteristics are set for each hidden class when it is > defined, and cannot be changed later. [A note about independence of > HCs from CLs] An advantage of allowing hidden classes to be unloaded > independently of the loader deemed as their defining loader is that a > very large number of hidden classes may be created by an application. > In contrast, if STRONG is used, then the JVM may run out of memory, > just as if normal classes were created by class loaders." > > Alex From mandy.chung at oracle.com Tue Mar 17 20:53:54 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 Mar 2020 13:53:54 -0700 Subject: CSR review for 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <88406fa9-e363-d514-35c8-3c1829b9f60c@oracle.com> References: <88406fa9-e363-d514-35c8-3c1829b9f60c@oracle.com> Message-ID: The javadoc and specdiff have been updated in place to reflect the recent discussion [1][2] to change the default of hidden classes that a hidden class may be unloaded even when the defining loader is reachable unless `ClassOption::STRONG` is specified such that the hidden class has the same strong relationship with its defining loader as the normal class has with its own defining loader. 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 Thanks Mandy [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006889.html [2] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006911.html On 3/9/20 2:00 PM, Mandy Chung wrote: > Please review the CSR proposed for JEP 371 Hidden Classes [1]. > > CSR: > ? https://bugs.openjdk.java.net/browse/JDK-8238359 > > 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 > > > A brief summary of the changes: > > 1. A new Lookup::defineHiddenClass method is the API to create a > hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and WEAK > 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. Class::getNestMembers is updated not to throw any exception when it > fails > ?? to validate the nest membership.? Instead this method will return all > ?? members that are listed in `NestMembers` attribute if present and > ?? determined to have the same nest host as this class. > > 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 proposes to update the > implementation > to match the spec - please also review: > ?? https://bugs.openjdk.java.net/browse/JDK-8240338 > > This is tracked as a separate JBS issue JDK-8238195 that is fixed in > this patch. > > The code review will be posted separately. > > Thanks > Mandy > [1] https://openjdk.java.net/jeps/371 > [2] JDK-8230502 Add support in JVM TI and JDI for hidden classes > [3] JDK-8219607 Add support in Graal and AOT for hidden and weak class > [4] > https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006872.html > From harold.seigel at oracle.com Tue Mar 17 20:47:24 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 17 Mar 2020 20:47:24 +0000 Subject: hg: valhalla/valhalla: Summary: jvmti test cleanup Message-ID: <202003172047.02HKlPre004255@aojmv0008.oracle.com> Changeset: 3fecac4ea9e0 Author: sspitsyn Date: 2020-03-17 20:46 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3fecac4ea9e0 Summary: jvmti test cleanup Reviewed-by: dholmes Contributed-by: serguei.spitsyn at oracle.com ! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/P/Q/HiddenClassSigTest.java ! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp From john.r.rose at oracle.com Wed Mar 18 00:23:51 2020 From: john.r.rose at oracle.com (John Rose) Date: Tue, 17 Mar 2020 17:23:51 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <81c1ce27-3cf2-4b9e-7f32-bc0ef4d3f3a3@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <91bf7ff0-762d-b221-4527-e3ef6d31f2bb@oracle.com> <91E38225-34A9-432D-BA6B-6923C774D46D@oracle.com> <0461348a-9980-ec52-50e6-1b9d058f321d@oracle.com> <0fad5b7f-6e08-68d1-59e5-5face98decfd@oracle.com> <9bb784ed-b9a4-c847-5824-e68b0f0231ad@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <351c42d7-f81c-c700-3156-af42ae7b0d51@oracle.com> <81c1ce27-3cf2-4b9e-7f32-bc0ef4d3f3a3@oracle.com> Message-ID: <4D69744B-19D4-4F83-BF6C-E0AFC7571E86@oracle.com> On Mar 17, 2020, at 1:41 PM, Mandy Chung wrote: > > The javadoc is updated per offline discussion with Alex. > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ > > I pushed this version to the sandbox to get the new ClassOption::STRONG in. We can continue to improve the javadoc per any feedback. At a glance, it looks nice. Love the $64 word ?coterminous?. Good advice about when to use strong vs. non-strong. From forax at univ-mlv.fr Wed Mar 18 08:29:52 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 18 Mar 2020 09:29:52 +0100 (CET) Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <4D69744B-19D4-4F83-BF6C-E0AFC7571E86@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <351c42d7-f81c-c700-3156-af42ae7b0d51@oracle.com> <81c1ce27-3cf2-4b9e-7f32-bc0ef4d3f3a3@oracle.com> <4D69744B-19D4-4F83-BF6C-E0AFC7571E86@oracle.com> Message-ID: <530340487.1553170.1584520192620.JavaMail.zimbra@u-pem.fr> As a non native English reader, i prefer the word "adjacent". otherwise, looks good. R?mi ----- Mail original ----- > De: "John Rose" > ?: "mandy chung" > Cc: "Alex Buckley" , "valhalla-dev" > Envoy?: Mercredi 18 Mars 2020 01:23:51 > Objet: Re: Review Request: Add ClassOption.STRONG and default is unspecified > On Mar 17, 2020, at 1:41 PM, Mandy Chung wrote: >> >> The javadoc is updated per offline discussion with Alex. >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ >> >> I pushed this version to the sandbox to get the new ClassOption::STRONG in. We >> can continue to improve the javadoc per any feedback. > > At a glance, it looks nice. Love the $64 word ?coterminous?. > Good advice about when to use strong vs. non-strong. From mandy.chung at oracle.com Wed Mar 18 17:52:26 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Mar 2020 10:52:26 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <530340487.1553170.1584520192620.JavaMail.zimbra@u-pem.fr> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <351c42d7-f81c-c700-3156-af42ae7b0d51@oracle.com> <81c1ce27-3cf2-4b9e-7f32-bc0ef4d3f3a3@oracle.com> <4D69744B-19D4-4F83-BF6C-E0AFC7571E86@oracle.com> <530340487.1553170.1584520192620.JavaMail.zimbra@u-pem.fr> Message-ID: "adjacent" does not seem having equivalent meaning in this case about the relationship with the class loader.??? ?coterminous? is a new word to me while I got the meaning once I googled it.? It may be okay for non native English speakers. Alex contributes to this spec (big thanks to Alex). Mandy On 3/18/20 1:29 AM, Remi Forax wrote: > As a non native English reader, i prefer the word "adjacent". > > otherwise, looks good. > > R?mi > > ----- Mail original ----- >> De: "John Rose" >> ?: "mandy chung" >> Cc: "Alex Buckley" , "valhalla-dev" >> Envoy?: Mercredi 18 Mars 2020 01:23:51 >> Objet: Re: Review Request: Add ClassOption.STRONG and default is unspecified >> On Mar 17, 2020, at 1:41 PM, Mandy Chung wrote: >>> The javadoc is updated per offline discussion with Alex. >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/ >>> >>> I pushed this version to the sandbox to get the new ClassOption::STRONG in. We >>> can continue to improve the javadoc per any feedback. >> At a glance, it looks nice. Love the $64 word ?coterminous?. >> Good advice about when to use strong vs. non-strong. From john.r.rose at oracle.com Wed Mar 18 21:52:00 2020 From: john.r.rose at oracle.com (John Rose) Date: Wed, 18 Mar 2020 14:52:00 -0700 Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <530340487.1553170.1584520192620.JavaMail.zimbra@u-pem.fr> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <98f6ab06-6523-adc3-ddd9-0e3d8aea66d1@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <351c42d7-f81c-c700-3156-af42ae7b0d51@oracle.com> <81c1ce27-3cf2-4b9e-7f32-bc0ef4d3f3a3@oracle.com> <4D69744B-19D4-4F83-BF6C-E0AFC7571E86@oracle.com> <530340487.1553170.1584520192620.JavaMail.zimbra@u-pem.fr> Message-ID: <4E4C6983-7491-4410-A6CA-4110B1A4DCB3@oracle.com> On Mar 18, 2020, at 1:29 AM, Remi Forax wrote: > > As a non native English reader, i prefer the word "adjacent". YDMV (Your Dictionary May Vary), but both ?adjacent? and ?coterminous? are from Latin, which is common property of technical writing in many modern languages, including the ones you and I use. https://www.etymonline.com/word/coterminous#etymonline_v_28958 https://www.etymonline.com/word/adjacent#etymonline_v_5117 More importantly, adjacent doesn?t have the right meaning. ?Co-terminous? (also, ?conterminous?) literally means ?having a common termination?, which is exactly what Alex is trying to say?the two entities have the same end-of-life. (This happens only when the JVM?s GC sees links pointing both ways between two objects.) That?s why I enjoyed his pick of that word. There are other options, but none as precise: https://www.thesaurus.com/browse/conterminous ? John P.S. Etymonline.com is one of my favorite sites to visit! I confess to using thesaurus.com for the usual guilty reason, of knowing there?s a right word out there, but not having it ready in memory. A distributed shared high-latency cache for vocabulary, I suppose. From mandy.chung at oracle.com Wed Mar 18 22:48:53 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 18 Mar 2020 22:48:53 +0000 Subject: hg: valhalla/valhalla: 2 new changesets Message-ID: <202003182248.02IMmsMi012847@aojmv0008.oracle.com> Changeset: 77788f5a4633 Author: mchung Date: 2020-03-18 15:45 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/77788f5a4633 [nestmates] minor cleanup and improve test documentation ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! test/hotspot/jtreg/runtime/Nestmates/membership/TestDynamicNestmateMembership.java ! test/jdk/java/lang/invoke/defineHiddenClass/HiddenNestmateTest.java ! test/jdk/java/lang/invoke/defineHiddenClass/UnreflectTest.java ! test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenClassThrow.java ! test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java ! test/jdk/java/lang/invoke/defineHiddenClass/src/Outer.java ! test/jdk/java/lang/reflect/AccessibleObject/HiddenClassTest.java Changeset: 76bb96f31be6 Author: mchung Date: 2020-03-18 15:48 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/76bb96f31be6 Merge From forax at univ-mlv.fr Wed Mar 18 23:35:22 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 19 Mar 2020 00:35:22 +0100 (CET) Subject: Review Request: Add ClassOption.STRONG and default is unspecified In-Reply-To: <4E4C6983-7491-4410-A6CA-4110B1A4DCB3@oracle.com> References: <0f0fcea5-46d8-59e4-9712-6e8b5e9e8a9b@oracle.com> <1c9340ca-6947-fc0b-4b22-c2d6686def1d@oracle.com> <351c42d7-f81c-c700-3156-af42ae7b0d51@oracle.com> <81c1ce27-3cf2-4b9e-7f32-bc0ef4d3f3a3@oracle.com> <4D69744B-19D4-4F83-BF6C-E0AFC7571E86@oracle.com> <530340487.1553170.1584520192620.JavaMail.zimbra@u-pem.fr> <4E4C6983-7491-4410-A6CA-4110B1A4DCB3@oracle.com> Message-ID: <46065572.16800.1584574522135.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "Remi Forax" > Cc: "mandy chung" , "Alex Buckley" > , "valhalla-dev" > Envoy?: Mercredi 18 Mars 2020 22:52:00 > Objet: Re: Review Request: Add ClassOption.STRONG and default is unspecified > On Mar 18, 2020, at 1:29 AM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> As a non native English reader, i prefer the word "adjacent". > YDMV (Your Dictionary May Vary), but both ?adjacent? and > ?coterminous? are from Latin, which is common property > of technical writing in many modern languages, including > the ones you and I use. > [ https://www.etymonline.com/word/coterminous#etymonline_v_28958 | > https://www.etymonline.com/word/coterminous#etymonline_v_28958 ] > [ https://www.etymonline.com/word/adjacent#etymonline_v_5117 | > https://www.etymonline.com/word/adjacent#etymonline_v_5117 ] > More importantly, adjacent doesn?t have the right meaning. > ?Co-terminous? (also, ?conterminous?) literally means ?having > a common termination?, which is exactly what Alex is trying to > say?the two entities have the same end-of-life. (This happens > only when the JVM?s GC sees links pointing both ways between > two objects.) That?s why I enjoyed his pick of that word. For a French, conterminous is very like co-terminus, "terminus" is a Latin word which is also used in French to say the end (end of the train line, bus stops, etc), and the prefix co is derived from com, "with" in Latin (compagnon is French means the one you share the bread, com + panem). And the end of life is called "terminal" in French like in English in a "terminal illness". By adjacent, i was thinking about adjacent lifetime, not adjacent alone, even if adjacent is more a spatial property than a time property. Anyway, it's wrong because only the death is at the same time, so adjacent lifetime doesn't work. > There are other options, but none as precise: > [ https://www.thesaurus.com/browse/conterminous | > https://www.thesaurus.com/browse/conterminous ] > ? John R?mi > P.S. [ http://etymonline.com/ | Etymonline.com ] is one of my favorite sites to > visit! > I confess to using [ http://thesaurus.com/ | thesaurus.com ] for the usual > guilty reason, > of knowing there?s a right word out there, but not having > it ready in memory. A distributed shared high-latency > cache for vocabulary, I suppose. From david.holmes at oracle.com Thu Mar 19 07:45:20 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Mar 2020 17:45:20 +1000 Subject: RFR: (valhalla/nestmates) 8241252: Cleanup nest related logging Message-ID: <42aeacf3-0210-4734-2a26-3606eac40631@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8241252/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8241252 Simplification of logging logic as suggested/requested by Coleen. Thanks, David From coleen.phillimore at oracle.com Thu Mar 19 13:40:35 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 19 Mar 2020 09:40:35 -0400 Subject: RFR: (valhalla/nestmates) 8241252: Cleanup nest related logging In-Reply-To: <42aeacf3-0210-4734-2a26-3606eac40631@oracle.com> References: <42aeacf3-0210-4734-2a26-3606eac40631@oracle.com> Message-ID: Yes, this is much nicer. thanks, Coleen On 3/19/20 3:45 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8241252/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8241252 > > Simplification of logging logic as suggested/requested by Coleen. > > Thanks, > David From david.holmes at oracle.com Fri Mar 20 06:25:55 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Mar 2020 16:25:55 +1000 Subject: RFR: (valhalla/nestmates) 8241252: Cleanup nest related logging In-Reply-To: References: <42aeacf3-0210-4734-2a26-3606eac40631@oracle.com> Message-ID: Thanks Coleen. As you suggested offline I also removed the log_is_enabled check in lookupDefineClass in jvm.cpp. Webrev updated in place. David On 19/03/2020 11:40 pm, coleen.phillimore at oracle.com wrote: > > Yes, this is much nicer. > thanks, > Coleen > > On 3/19/20 3:45 AM, David Holmes wrote: >> webrev: http://cr.openjdk.java.net/~dholmes/8241252/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8241252 >> >> Simplification of logging logic as suggested/requested by Coleen. >> >> Thanks, >> David > From coleen.phillimore at oracle.com Fri Mar 20 11:25:18 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 20 Mar 2020 07:25:18 -0400 Subject: RFR: (valhalla/nestmates) 8241252: Cleanup nest related logging In-Reply-To: References: <42aeacf3-0210-4734-2a26-3606eac40631@oracle.com> Message-ID: Thanks, ship it! Coleen On 3/20/20 2:25 AM, David Holmes wrote: > Thanks Coleen. As you suggested offline I also removed the > log_is_enabled check in lookupDefineClass in jvm.cpp. Webrev updated > in place. > > David > > On 19/03/2020 11:40 pm, coleen.phillimore at oracle.com wrote: >> >> Yes, this is much nicer. >> thanks, >> Coleen >> >> On 3/19/20 3:45 AM, David Holmes wrote: >>> webrev: http://cr.openjdk.java.net/~dholmes/8241252/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8241252 >>> >>> Simplification of logging logic as suggested/requested by Coleen. >>> >>> Thanks, >>> David >> From mandy.chung at oracle.com Fri Mar 20 16:38:02 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 20 Mar 2020 16:38:02 +0000 Subject: hg: valhalla/valhalla: [nestmates] Move injected classData to java.lang.Class per Coleen's comment. Message-ID: <202003201638.02KGc2Ie004987@aojmv0008.oracle.com> Changeset: b10a0cd9daf5 Author: mchung Date: 2020-03-20 09:37 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b10a0cd9daf5 [nestmates] Move injected classData to java.lang.Class per Coleen's comment. And also drop Class::nest field. VM will record the nest host dependency to keep it strongly reference. ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/prims/methodHandles.cpp ! 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/MethodHandleNatives.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! test/jdk/jdk/internal/reflect/Reflection/Filtering.java From harold.seigel at oracle.com Fri Mar 20 18:53:07 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Fri, 20 Mar 2020 18:53:07 +0000 Subject: hg: valhalla/valhalla: Summary: Add code to record dependency between a class and its nest host Message-ID: <202003201853.02KIr8q7021938@aojmv0008.oracle.com> Changeset: d259d5fa90a3 Author: hseigel Date: 2020-03-20 18:52 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d259d5fa90a3 Summary: Add code to record dependency between a class and its nest host Reviewed-by: coleenp ! src/hotspot/share/oops/instanceKlass.cpp From harold.seigel at oracle.com Fri Mar 20 19:16:33 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Fri, 20 Mar 2020 19:16:33 +0000 Subject: hg: valhalla/valhalla: Summary: Add code to record dependency between a class and its nest host Message-ID: <202003201916.02KJGYEr003105@aojmv0008.oracle.com> Changeset: 77585cdc8e20 Author: hseigel Date: 2020-03-20 19:15 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/77585cdc8e20 Summary: Add code to record dependency between a class and its nest host Reviewed-by: mchung, coleenp ! src/hotspot/share/oops/instanceKlass.cpp From rriggs at openjdk.java.net Fri Mar 20 20:27:33 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 20 Mar 2020 20:27:33 GMT Subject: [lworld] RFR: Added IdentityObject.newIdentity() Message-ID: Switching to the Skara infra for the GitHub based Valhalla lworld branch... Following the discussion on valhalla-dev https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006867.html Please review and comment. ------------- Commit messages: - Added IdentityObject.newIdentity() Changes: https://git.openjdk.java.net/valhalla/pull/2/files Webrev: https://webrevs.openjdk.java.net/valhalla/2/webrev.00 Stats: 20 lines in 2 files changed: 19 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/2/head:pull/2 PR: https://git.openjdk.java.net/valhalla/pull/2 From rriggs at openjdk.java.net Fri Mar 20 20:34:59 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 20 Mar 2020 20:34:59 GMT Subject: [lworld] [Rev 01] RFR: Added IdentityObject.newIdentity() In-Reply-To: References: Message-ID: > Switching to the Skara infra for the GitHub based Valhalla lworld branch... > > Following the discussion on valhalla-dev > https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006867.html > > Please review and comment. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/2/files - new: https://git.openjdk.java.net/valhalla/pull/2/files/74804264..d17de685 Webrevs: - full: https://webrevs.openjdk.java.net/valhalla/2/webrev.01 - incr: https://webrevs.openjdk.java.net/valhalla/2/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/2/head:pull/2 PR: https://git.openjdk.java.net/valhalla/pull/2 From mandy.chung at oracle.com Fri Mar 20 21:27:10 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 20 Mar 2020 21:27:10 +0000 Subject: hg: valhalla/valhalla: 3 new changesets Message-ID: <202003202127.02KLRBha015191@aojmv0008.oracle.com> Changeset: a04e471a0e87 Author: mchung Date: 2020-03-20 14:24 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a04e471a0e87 [nestmates] update test to add Class::classData to the reflection hidden field list ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java Changeset: bc0cdc243ca0 Author: mchung Date: 2020-03-20 14:25 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/bc0cdc243ca0 [nestmates] Problem list graal tests in ProblemList-graal.txt ! test/hotspot/jtreg/ProblemList-graal.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: 65bc09903227 Author: mchung Date: 2020-03-20 14:26 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/65bc09903227 [nestmates] defineHiddenClassWithClassData always invokes ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! test/jdk/java/lang/invoke/defineHiddenClass/DefineClassWithClassData.java ! test/jdk/java/lang/invoke/nestmates/NestmateTest.java From harold.seigel at oracle.com Mon Mar 23 15:41:53 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 23 Mar 2020 11:41:53 -0400 Subject: RFR: (valhalla/nestmates) 8241252: Cleanup nest related logging In-Reply-To: References: <42aeacf3-0210-4734-2a26-3606eac40631@oracle.com> Message-ID: <0400ca22-defa-75ac-edd0-709d112be7a5@oracle.com> +1 Harold On 3/20/2020 7:25 AM, coleen.phillimore at oracle.com wrote: > Thanks, ship it! > Coleen > > On 3/20/20 2:25 AM, David Holmes wrote: >> Thanks Coleen. As you suggested offline I also removed the >> log_is_enabled check in lookupDefineClass in jvm.cpp. Webrev updated >> in place. >> >> David >> >> On 19/03/2020 11:40 pm, coleen.phillimore at oracle.com wrote: >>> >>> Yes, this is much nicer. >>> thanks, >>> Coleen >>> >>> On 3/19/20 3:45 AM, David Holmes wrote: >>>> webrev: http://cr.openjdk.java.net/~dholmes/8241252/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8241252 >>>> >>>> Simplification of logging logic as suggested/requested by Coleen. >>>> >>>> Thanks, >>>> David >>> > From harold.seigel at oracle.com Mon Mar 23 17:05:32 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Mon, 23 Mar 2020 17:05:32 +0000 Subject: hg: valhalla/valhalla: Summary: Fix symbol count issue in classFileParser.cpp when changing _class_name. Message-ID: <202003231705.02NH5XBE002810@aojmv0008.oracle.com> Changeset: 40c00294e1df Author: hseigel Date: 2020-03-23 17:05 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/40c00294e1df Summary: Fix symbol count issue in classFileParser.cpp when changing _class_name. Reviewed-by: lfoltan, mchung, coleenp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp From harold.seigel at oracle.com Mon Mar 23 20:06:25 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Mon, 23 Mar 2020 20:06:25 +0000 Subject: hg: valhalla/valhalla: Summary: Remove term "weak", mangle hidden class using &ik, change short-lived to has_class_mirror_holder, remove loader arg from JVM_LookupDefineClass(), and other small changes. Message-ID: <202003232006.02NK6QcI017930@aojmv0008.oracle.com> Changeset: 130434292f7a Author: hseigel Date: 2020-03-23 20:05 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/130434292f7a Summary: Remove term "weak", mangle hidden class using &ik, change short-lived to has_class_mirror_holder, remove loader arg from JVM_LookupDefineClass(), and other small changes. Reviewed-by: lfoltan, mchung ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp ! src/hotspot/share/classfile/classLoaderStats.cpp ! src/hotspot/share/classfile/classLoaderStats.hpp ! src/hotspot/share/classfile/dictionary.cpp ! src/hotspot/share/classfile/klassFactory.cpp ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/moduleEntry.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace.hpp ! src/hotspot/share/memory/metaspace/printCLDMetaspaceInfoClosure.cpp ! src/hotspot/share/memory/metaspace/spaceManager.cpp ! src/hotspot/share/memory/metaspaceTracer.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceMirrorKlass.inline.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/native/libjava/ClassLoader.c ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! test/hotspot/gtest/memory/test_metaspace_allocation.cpp ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java ! test/jdk/jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java From david.holmes at oracle.com Mon Mar 23 22:25:14 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Mar 2020 08:25:14 +1000 Subject: RFR: (valhalla/nestmates) 8241252: Cleanup nest related logging In-Reply-To: <0400ca22-defa-75ac-edd0-709d112be7a5@oracle.com> References: <42aeacf3-0210-4734-2a26-3606eac40631@oracle.com> <0400ca22-defa-75ac-edd0-709d112be7a5@oracle.com> Message-ID: Thanks Harold! On 24/03/2020 1:41 am, Harold Seigel wrote: > +1 > > Harold > > On 3/20/2020 7:25 AM, coleen.phillimore at oracle.com wrote: >> Thanks, ship it! >> Coleen >> >> On 3/20/20 2:25 AM, David Holmes wrote: >>> Thanks Coleen. As you suggested offline I also removed the >>> log_is_enabled check in lookupDefineClass in jvm.cpp. Webrev updated >>> in place. >>> >>> David >>> >>> On 19/03/2020 11:40 pm, coleen.phillimore at oracle.com wrote: >>>> >>>> Yes, this is much nicer. >>>> thanks, >>>> Coleen >>>> >>>> On 3/19/20 3:45 AM, David Holmes wrote: >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8241252/webrev/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8241252 >>>>> >>>>> Simplification of logging logic as suggested/requested by Coleen. >>>>> >>>>> Thanks, >>>>> David >>>> >> From david.holmes at oracle.com Mon Mar 23 22:26:13 2020 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 23 Mar 2020 22:26:13 +0000 Subject: hg: valhalla/valhalla: 8241252: Cleanup nest related logging Message-ID: <202003232226.02NMQEn5002825@aojmv0008.oracle.com> Changeset: 0b032112c89e Author: dholmes Date: 2020-03-23 18:26 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0b032112c89e 8241252: Cleanup nest related logging Reviewed-by: coleenp, hseigel ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/prims/jvm.cpp From rriggs at openjdk.java.net Tue Mar 24 13:57:53 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 24 Mar 2020 13:57:53 GMT Subject: [lworld] RFR: Added IdentityObject.newIdentity() In-Reply-To: References: Message-ID: On Fri, 20 Mar 2020 20:21:54 GMT, Roger Riggs wrote: > Switching to the Skara infra for the GitHub based Valhalla lworld branch... > > Following the discussion on valhalla-dev > https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006867.html > > Please review and comment. /solves JDK-8239929 /integrate ------------- PR: https://git.openjdk.java.net/valhalla/pull/2 From rriggs at openjdk.java.net Tue Mar 24 14:19:25 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 24 Mar 2020 14:19:25 GMT Subject: [Integrated] [lworld] RFR: Added IdentityObject.newIdentity() In-Reply-To: References: Message-ID: <031fcc79-8a01-40ad-b8ff-77a2123f4450@openjdk.org> Changeset: 0bca2918 Author: Roger Riggs Date: 2020-03-24 14:18:52 +0000 URL: https://git.openjdk.java.net/valhalla/commit/0bca2918 Added IdentityObject.newIdentity() ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/util/Objects.java From rriggs at openjdk.java.net Tue Mar 24 14:17:37 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 24 Mar 2020 14:17:37 GMT Subject: [lworld] RFR: Added IdentityObject.newIdentity() In-Reply-To: References: Message-ID: On Tue, 24 Mar 2020 13:55:35 GMT, Roger Riggs wrote: >> Switching to the Skara infra for the GitHub based Valhalla lworld branch... >> >> Following the discussion on valhalla-dev >> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006867.html >> >> Please review and comment. > > /solves JDK-8239929 > /integrate /solves 8239929 /integrate ------------- PR: https://git.openjdk.java.net/valhalla/pull/2 From harold.seigel at oracle.com Tue Mar 24 14:37:44 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 24 Mar 2020 14:37:44 +0000 Subject: hg: valhalla/valhalla: Summary: don't allocate an embedded field at the end of the InstanceKlass for hidden classes Message-ID: <202003241437.02OEbjHQ020584@aojmv0008.oracle.com> Changeset: a13281715852 Author: hseigel Date: 2020-03-24 14:37 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a13281715852 Summary: don't allocate an embedded field at the end of the InstanceKlass for hidden classes Reviewed-by: lfoltan, dholmes, coleenp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp From mandy.chung at oracle.com Tue Mar 24 22:10:06 2020 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 24 Mar 2020 22:10:06 +0000 Subject: hg: valhalla/valhalla: [nestmates] minor cleanup Message-ID: <202003242210.02OMA7V1022267@aojmv0008.oracle.com> Changeset: 315478f0a527 Author: mchung Date: 2020-03-24 14:50 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/315478f0a527 [nestmates] minor cleanup ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java From thartmann at openjdk.java.net Wed Mar 25 08:56:00 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 25 Mar 2020 08:56:00 GMT Subject: [lworld] RFR: 8241533: [lworld] PhaseMacroExpand::migrate_outs should be replaced =?UTF-8?B?YuKApg==?= Message-ID: The fix for JDK-8237581 added PhaseMacroExpand::migrate_outs which can be replaced by PhaseIterGVN::replace_in_uses. ------------- Commit messages: - 8241533: [lworld] PhaseMacroExpand::migrate_outs should be replaced by PhaseIterGVN::replace_in_uses Changes: https://git.openjdk.java.net/valhalla/pull/4/files Webrev: https://webrevs.openjdk.java.net/valhalla/4/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241533 Stats: 22 lines in 3 files changed: 2 ins; 13 del; 7 mod Patch: https://git.openjdk.java.net/valhalla/pull/4.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/4/head:pull/4 PR: https://git.openjdk.java.net/valhalla/pull/4 From david.holmes at oracle.com Wed Mar 25 23:11:21 2020 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 25 Mar 2020 23:11:21 +0000 Subject: hg: valhalla/valhalla: 272 new changesets Message-ID: <202003252311.02PNBaIm022362@aojmv0008.oracle.com> Changeset: e804de2e6d4a Author: vromero Date: 2020-03-05 16:46 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e804de2e6d4a 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: 5a58d0939974 Author: darcy Date: 2020-03-05 15:07 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5a58d0939974 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: 104476d44ee0 Author: dnsimon Date: 2020-03-05 16:32 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/104476d44ee0 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: 92cf8efd381d Author: rsunderbabu Date: 2020-03-06 10:27 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/92cf8efd381d 8153430: jdk regression test MletParserLocaleTest, ParserInfiniteLoopTest reduce default timeout Summary: Removed timeout=5 from the tests so that default timeout is used Reviewed-by: cjplummer Contributed-by: ramkumar.sunderbabu at oracle.com ! test/jdk/javax/management/loading/MletParserLocaleTest.java ! test/jdk/javax/management/loading/ParserInfiniteLoopTest.java Changeset: 41f79689c039 Author: mbaesken Date: 2020-03-05 13:12 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/41f79689c039 8240603: Windows 32bit compile error after 8238676 Reviewed-by: clanger, dholmes ! test/hotspot/jtreg/runtime/jni/atExit/libatExit.c Changeset: 571b228bf874 Author: mdoerr Date: 2020-03-06 11:04 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/571b228bf874 8239856: [ntintel] asserts about copying unaligned array element Reviewed-by: stuefe, sspitsyn ! src/jdk.jdwp.agent/share/native/libjdwp/ArrayReferenceImpl.c Changeset: b009dd349913 Author: iwalulya Date: 2020-03-06 11:40 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b009dd349913 8240589: OtherRegionsTable::_num_occupied not updated correctly Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp Changeset: 942c6102590a Author: rkennke Date: 2020-03-06 13:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/942c6102590a 8236981: Remove ShenandoahTraversalUpdateRefsClosure Reviewed-by: shade, rkennke Contributed-by: adityam at microsoft.com ! 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: cc8382a9118c Author: iwalulya Date: 2020-03-06 14:10 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/cc8382a9118c 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: 2b6e1b425f5f Author: rschmelter Date: 2020-03-06 16:19 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2b6e1b425f5f 8240440: Implement get_safepoint_workers() for parallel GC Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp Changeset: 1c40993361d0 Author: sgehwolf Date: 2020-02-24 19:03 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1c40993361d0 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: dffc5585fa99 Author: shade Date: 2020-03-06 17:03 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/dffc5585fa99 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: 90c1d2c1f333 Author: mullan Date: 2020-03-06 13:17 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/90c1d2c1f333 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: d0305db138ee Author: bpb Date: 2020-03-06 10:34 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d0305db138ee 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: c81062051951 Author: rriggs Date: 2020-03-06 13:52 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c81062051951 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: 22e4f0169cab Author: rkennke Date: 2020-03-06 21:51 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/22e4f0169cab 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: f79f4f745f98 Author: ccheung Date: 2020-03-06 15:33 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f79f4f745f98 8232081: Try to link all classes during dynamic CDS dump Summary: 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: ba031902229b Author: kbarrett Date: 2020-03-06 18:42 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ba031902229b 8240239: Replace ConcurrentGCPhaseManager Summary: Replace ConcurrentGCPhaseManager with ConcurrentGCBreakpoints Reviewed-by: kbarrett, pliden, sangheki Contributed-by: kim.barrett at oracle.com, per.liden at oracle.com ! 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: b68736876ab5 Author: mikael Date: 2020-03-06 17:33 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b68736876ab5 8240535: Add additional linux-aarch64 jib profiles Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: 7af6364e1792 Author: jjg Date: 2020-03-06 18:03 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7af6364e1792 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: cb85119495ba Author: jiefu Date: 2020-03-07 14:42 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/cb85119495ba 8240695: Build is broken when cds is disabled after JDK-8232081 Reviewed-by: iklam ! src/hotspot/share/memory/metaspaceShared.hpp Changeset: ca2dcaf37fad Author: vtewari Date: 2020-03-07 18:35 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ca2dcaf37fad 8238579: HttpsURLConnection drops the timeout and hangs forever in read Summary: 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: 4b80c89e76ca Author: bulasevich Date: 2020-03-07 16:27 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4b80c89e76ca 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: e44b68e5bdaf Author: itakiguchi Date: 2020-03-08 15:15 +0900 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e44b68e5bdaf 8239965: XMLEncoder/Test4625418.java fails due to "Error: Cp943 - can't read properly" Summary: 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: 2420daa87866 Author: kbarrett Date: 2020-03-08 17:33 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2420daa87866 8240133: G1DirtyCardQueue destructor has useless flush Summary: Removed useless call to flush. Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp Changeset: 0fe71e38ecc4 Author: iklam Date: 2020-03-08 15:06 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0fe71e38ecc4 8240613: InstanceKlass::set_init_state failed with assert(good_state || state == allocated) Reviewed-by: dcubed ! src/hotspot/share/classfile/systemDictionary.cpp Changeset: 13c54fd3bc8c Author: rhalade Date: 2020-03-09 00:45 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/13c54fd3bc8c 8240686: 70 security tests are failing on Windows due to "Fetch artifact failed" Reviewed-by: xuelei ! test/jdk/ProblemList.txt Changeset: 3437fb6311fd Author: kbarrett Date: 2020-03-09 04:06 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3437fb6311fd 8240722: [BACKOUT] G1DirtyCardQueue destructor has useless flush Summary: Backout JDK-8240133 Reviewed-by: sjohanss ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp Changeset: 8d1e70f7f279 Author: roland Date: 2020-03-05 15:56 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8d1e70f7f279 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: 598ac6de2237 Author: rkennke Date: 2020-03-09 12:29 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/598ac6de2237 8220503: Move ShenandoahTerminatorTerminator::should_exit_termination out of header Reviewed-by: rkennke Contributed-by: adityam at microsoft.com ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp Changeset: 8a14919d365d Author: kevinw Date: 2020-03-09 12:54 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8a14919d365d 8240295: hs_err elapsed time in seconds is not accurate enough Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/runtime/os.cpp Changeset: 666e310e158f Author: neugens Date: 2020-03-09 14:57 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/666e310e158f 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: 0238badf51bc Author: fyang Date: 2020-03-09 22:31 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0238badf51bc 8240576: JVM crashes after transformation in C2 IdealLoopTree::merge_many_backedges Reviewed-by: kvn Contributed-by: hedongbo at huawei.com ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestBeautifyLoops.java Changeset: 79371dab85c2 Author: henryjen Date: 2020-03-06 13:48 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/79371dab85c2 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: 20023740a683 Author: dfuchs Date: 2020-03-09 17:48 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/20023740a683 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: 298b62120b5a Author: naoto Date: 2020-03-09 13:20 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/298b62120b5a 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: b03adcb5dd5f Author: egahlin Date: 2020-03-09 21:25 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b03adcb5dd5f 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: 563d6852da45 Author: egahlin Date: 2020-03-09 21:43 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/563d6852da45 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: a74b7501917d Author: shade Date: 2020-03-09 22:40 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a74b7501917d 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: ffa717c6ffee Author: shade Date: 2020-03-09 22:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ffa717c6ffee 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: 7e741a3fc650 Author: shade Date: 2020-03-09 22:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7e741a3fc650 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts Reviewed-by: shade Contributed-by: Aditya Mandaleeka ! 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: b639fff3fc5a Author: roland Date: 2020-03-10 10:45 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b639fff3fc5a 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: 7c057af653f9 Author: iwalulya Date: 2020-03-10 10:19 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7c057af653f9 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: b760fca91d75 Author: jjiang Date: 2020-03-10 21:43 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b760fca91d75 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: 12b01a07515d Author: mgronlun Date: 2020-03-10 15:44 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/12b01a07515d 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: a611125840f0 Author: fyang Date: 2020-03-09 18:21 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a611125840f0 8240734: ModuleHashes attribute not reproducible between builds Reviewed-by: alanb Contributed-by: hedongbo at huawei.com ! src/java.base/share/classes/jdk/internal/module/ModuleHashes.java ! src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java Changeset: 5474f3ecded4 Author: roland Date: 2020-03-09 09:42 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5474f3ecded4 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: 478dbbe9b422 Author: egahlin Date: 2020-03-10 18:39 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/478dbbe9b422 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: eab1d242c9f6 Author: vlivanov Date: 2020-03-10 20:51 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/eab1d242c9f6 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: e673324c4045 Author: vlivanov Date: 2020-03-10 20:51 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e673324c4045 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: 3f26298f486f Author: vlivanov Date: 2020-03-10 20:51 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3f26298f486f 8239009: C2: Don't use PSHUF to load scalars from memory on x86 Reviewed-by: kvn, dlong ! src/hotspot/cpu/x86/x86.ad Changeset: 8c0b7b88b646 Author: minqi Date: 2020-03-10 11:52 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8c0b7b88b646 8240691: ClhsdbCDSJstackPrintAll incorrectly thinks CDS is in use Summary: 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: 81e8e9394197 Author: dnsimon Date: 2020-03-10 21:48 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/81e8e9394197 8240610: [JVMCI] Export VMVersion::_has_intel_jcc_erratum to JVMCI compiler Reviewed-by: kvn, thartmann Contributed-by: Yudi Zheng ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: a67aa7e073d8 Author: minqi Date: 2020-03-10 14:37 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a67aa7e073d8 8240840: Rollback whitebox.cpp in push 8240691 Summary: whitebox.cpp should not change in 8240691, which is accidentally included. Reviewed-by: iklam, ccheung ! src/hotspot/share/prims/whitebox.cpp Changeset: 18d4d0cc3372 Author: kvn Date: 2020-03-10 14:39 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/18d4d0cc3372 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: 301f91ab1636 Author: jjg Date: 2020-03-10 14:46 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/301f91ab1636 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: 82b0b99acdbb Author: asotona Date: 2020-03-10 17:33 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/82b0b99acdbb 8235216: typo in test filename Summary: 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: faa4916a3379 Author: cito Date: 2020-03-07 23:08 +0900 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/faa4916a3379 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: 8c78138be591 Author: weijun Date: 2020-03-11 10:33 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8c78138be591 8239928: ec/ECDSAJavaVerify.java failed due to timeout Reviewed-by: valeriep ! test/jdk/sun/security/ec/ECDSAJavaVerify.java Changeset: 590ac5a59078 Author: ysuenaga Date: 2020-03-11 13:14 +0900 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/590ac5a59078 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: 8c5697ed51b2 Author: ihse Date: 2020-03-11 08:34 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8c5697ed51b2 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: 1fdd52277cfb Author: ehelin Date: 2020-03-10 16:58 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1fdd52277cfb 8237566: FindTests.gmk should only include existing TEST.ROOT files Reviewed-by: erikj ! make/common/FindTests.gmk Changeset: 719a3cd91e92 Author: stefank Date: 2020-03-04 15:50 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/719a3cd91e92 8240530: CheckUnhandledOops breaks BacktraceBuilder::set_has_hidden_top_frame Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/javaClasses.cpp Changeset: bb44e0d9fe1f Author: stefank Date: 2020-03-04 15:50 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/bb44e0d9fe1f 8240529: CheckUnhandledOops breaks NULL check in Modules::define_module Reviewed-by: coleenp, lfoltan, hseigel ! src/hotspot/share/classfile/modules.cpp Changeset: 12eb1e2087d2 Author: stefank Date: 2020-03-04 18:08 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/12eb1e2087d2 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: e50512f91026 Author: aph Date: 2020-03-10 10:49 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e50512f91026 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: 65f30e209890 Author: clanger Date: 2020-03-11 13:50 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/65f30e209890 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java Reviewed-by: clanger, vtewari Contributed-by: vipinsharma85 at gmail.com ! test/jdk/java/lang/Boolean/GetBoolean.java ! test/jdk/java/lang/Boolean/MakeBooleanComparable.java ! test/jdk/java/lang/Boolean/ParseBoolean.java Changeset: 6cac1afd2a63 Author: shade Date: 2020-03-11 14:17 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6cac1afd2a63 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: d0ff3ee1bf40 Author: aph Date: 2020-03-11 12:38 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d0ff3ee1bf40 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: f9893c227e12 Author: aph Date: 2020-03-11 15:02 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f9893c227e12 Merge Changeset: eb934f0048de Author: bae Date: 2020-03-11 19:14 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/eb934f0048de 8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException Reviewed-by: xuelei Contributed-by: alexey at azul.com ! 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: d9dd1627e074 Author: lancea Date: 2020-03-11 12:30 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d9dd1627e074 8230117: Remove unused JAR tool classes Reviewed-by: lancea, clanger Contributed-by: Adam Sotona - src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java - src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.java Changeset: 3a3ce5f3e2f7 Author: prappo Date: 2020-03-11 17:09 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3a3ce5f3e2f7 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: 055991789807 Author: sspitsyn Date: 2020-03-11 20:28 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/055991789807 8240881: [BACKOUT] 8222489 jcmd VM.system_properties gives unusable paths on Windows Summary: 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: d462f05faa2d Author: amenkov Date: 2020-03-11 13:39 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d462f05faa2d 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: 1d6ceb13e142 Author: ihse Date: 2020-03-11 22:25 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1d6ceb13e142 8240866: Typo in JDK-8240820 messes up configure --help Reviewed-by: erikj ! make/autoconf/flags-cflags.m4 ! make/autoconf/hotspot.m4 Changeset: 5f690d6174b5 Author: jjg Date: 2020-03-11 15:46 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5f690d6174b5 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: a6c70ccaa775 Author: ysuenaga Date: 2020-03-12 09:23 +0900 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a6c70ccaa775 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: e103a5398b54 Author: jwilhelm Date: 2020-03-12 03:10 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e103a5398b54 Added tag jdk-15+14 for changeset 1d6ceb13e142 ! .hgtags Changeset: 91f95b517b0c Author: iklam Date: 2020-03-11 21:37 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/91f95b517b0c 8240548: [TESTBUG] CDS NoClassToArchive.java fails with Graal Reviewed-by: dholmes, mchung ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NoClassToArchive.java Changeset: 4ee517d2e206 Author: shade Date: 2020-03-12 06:47 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4ee517d2e206 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah Reviewed-by: shade Contributed-by: Kelvin Nilsen ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/gc/logging/TestMetaSpaceLog.java Changeset: a744cb5d03d6 Author: weijun Date: 2020-03-12 18:21 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a744cb5d03d6 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: ecc59c31cb10 Author: rrich Date: 2020-03-12 11:51 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ecc59c31cb10 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: 4923c49ba7b5 Author: redestad Date: 2020-03-12 13:07 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4923c49ba7b5 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: fec7d7b39038 Author: redestad Date: 2020-03-05 16:07 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/fec7d7b39038 8240669: Devirtualize Relocation::type Reviewed-by: rbackman, thartmann ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp Changeset: 2d4a9ff1de2e Author: dnsimon Date: 2020-03-12 13:20 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2d4a9ff1de2e 8240831: [JVMCI] Export missing vmStructs entries used by JVMCI compilers Reviewed-by: kvn, thartmann Contributed-by: Yudi Zheng ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 724e0cf52991 Author: zgu Date: 2020-03-12 09:25 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/724e0cf52991 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: a9a78d821f37 Author: vlivanov Date: 2020-03-12 16:42 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a9a78d821f37 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: d527da8f8f9b Author: sgehwolf Date: 2020-02-25 12:17 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d527da8f8f9b 8239785: Cgroups: Incorrect detection logic on old systems in hotspot Summary: 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: 7898edac8a27 Author: naoto Date: 2020-03-12 08:31 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7898edac8a27 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: 910e8900f11d Author: rriggs Date: 2020-03-12 11:54 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/910e8900f11d 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: e713e8a312ea Author: rriggs Date: 2020-03-12 11:57 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e713e8a312ea 8240957: Clarify BadAttributeValueExpException readObject method Reviewed-by: bpb ! src/java.management/share/classes/javax/management/BadAttributeValueExpException.java Changeset: fa70160bcf72 Author: minqi Date: 2020-03-12 09:07 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/fa70160bcf72 8240563: [TESTBUG] WB_IsCDSIncludedInVmBuild should support uncompressed oops/klasses Summary: 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: c0f672668596 Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c0f672668596 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: cc0ffb1d0458 Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/cc0ffb1d0458 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: 67a2ce1f3a0a Author: zgu Date: 2020-03-12 13:08 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/67a2ce1f3a0a 8240917: Shenandoah: Avoid scanning thread code roots twice in all root scanner Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: be3aeb6e766d Author: pconcannon Date: 2020-03-12 17:08 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/be3aeb6e766d 8239355: (dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS) Summary: 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: f2a8072492df Author: pconcannon Date: 2020-03-12 17:20 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f2a8072492df Merge Changeset: 61f6c19d1a56 Author: shade Date: 2020-03-12 18:50 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/61f6c19d1a56 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: 29f4b46a1680 Author: dfuchs Date: 2020-03-12 18:31 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/29f4b46a1680 8059309: network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root" Summary: 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: 222127a06550 Author: ihse Date: 2020-03-12 19:40 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/222127a06550 8240947: Change conflicting JVM features from warning to error Reviewed-by: erikj ! make/autoconf/jvm-features.m4 Changeset: 5edc259054ae Author: ihse Date: 2020-03-12 19:42 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5edc259054ae 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: e594b41c45c4 Author: ihse Date: 2020-03-12 19:43 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e594b41c45c4 8240950: Missing AC_SUBST after JDK-82408 Reviewed-by: erikj ! make/autoconf/build-performance.m4 Changeset: 1ca940d73efc Author: mchung Date: 2020-03-12 11:54 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1ca940d73efc 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/java/lang/ClassLoaderHelper.java + src/java.base/windows/classes/jdk/internal/loader/ClassLoaderHelper.java ! test/jdk/java/lang/ClassLoader/LibraryPathProperty.java Changeset: e287fc5b9e86 Author: mchung Date: 2020-03-12 11:56 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e287fc5b9e86 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: 4253bf176649 Author: erikj Date: 2020-03-12 12:55 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4253bf176649 8240972: macOS codesign fail on macOS 10.13.5 or older Reviewed-by: erikj, ihse Contributed-by: junyuan.zheng at microsoft.com ! make/autoconf/basic_tools.m4 Changeset: b2b9f856b71a Author: jjg Date: 2020-03-12 13:56 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b2b9f856b71a 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: 66c7a7990f69 Author: jjg Date: 2020-03-12 14:14 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/66c7a7990f69 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: 24d5c4ed9bf9 Author: valeriep Date: 2020-03-12 22:11 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/24d5c4ed9bf9 8238566: java.security.Provider$Service.supportsParameter() is racy Summary: Use double-checked-locking pattern inside the hasKeyAttributes() method Reviewed-by: xuelei ! src/java.base/share/classes/java/security/Provider.java Changeset: 15d69d370743 Author: ccheung Date: 2020-03-12 16:05 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/15d69d370743 8238000: Crash in ClassLoader::record_result while dynamic dumping netty Summary: 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: 1c98d63e3ee2 Author: jiefu Date: 2020-03-13 17:01 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1c98d63e3ee2 8240846: Zero VM is broken after JDK-8238681: UseSSE not defined Reviewed-by: shade, rehn, vlivanov ! src/hotspot/share/compiler/compileBroker.cpp Changeset: 3a3bd4ed9584 Author: roland Date: 2020-03-11 10:32 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3a3bd4ed9584 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: 29edf1cb3c02 Author: weijun Date: 2020-03-13 17:45 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/29edf1cb3c02 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: de9c1fe3de60 Author: iwalulya Date: 2020-03-13 11:54 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/de9c1fe3de60 8240591: G1HeapSizingPolicy attempts to compute expansion_amount even when at full capacity Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp Changeset: 367b1f73904c Author: shade Date: 2020-03-13 13:22 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/367b1f73904c 8231668: Remove ForceDynamicNumberOfGCThreads Reviewed-by: shade, tschatzl Contributed-by: Aditya Mandaleeka ! 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: 3179efca4758 Author: weijun Date: 2020-03-13 21:32 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3179efca4758 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: 3ab7a06ba381 Author: pliden Date: 2020-03-13 14:26 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3ab7a06ba381 8240714: ZGC: TestSmallHeap.java failed due to OutOfMemoryError Reviewed-by: eosterlund ! test/hotspot/jtreg/gc/z/TestSmallHeap.java Changeset: 8e9261c404fc Author: vromero Date: 2020-03-13 10:29 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8e9261c404fc 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: 59de2958df85 Author: redestad Date: 2020-03-13 15:59 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/59de2958df85 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: 3ac1c2ef94e2 Author: redestad Date: 2020-03-13 18:43 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3ac1c2ef94e2 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: 5e0d9f0b1029 Author: jjg Date: 2020-03-13 10:57 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5e0d9f0b1029 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: dc1cf3a5d7db Author: joehw Date: 2020-03-13 19:15 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/dc1cf3a5d7db 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: 24d342c838fb Author: amenkov Date: 2020-03-13 12:25 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/24d342c838fb 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: 10f11578b1f4 Author: kbarrett Date: 2020-03-13 15:36 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/10f11578b1f4 8239825: G1: Simplify threshold test for mutator refinement Summary: 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: 332ee3137fb8 Author: darcy Date: 2020-03-14 09:53 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/332ee3137fb8 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: 0d7a66c27369 Author: vromero Date: 2020-03-14 17:08 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0d7a66c27369 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: 981b5a0c43da Author: ngasson Date: 2020-03-16 10:51 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/981b5a0c43da 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: 59b5bd9a7168 Author: dholmes Date: 2020-03-16 02:16 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/59b5bd9a7168 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: 4eaf6922273a Author: jlahoda Date: 2020-03-16 13:06 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4eaf6922273a 8240964: Compilation error thrown when long literal used with yield Summary: 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: 80eaef8e3e60 Author: eosterlund Date: 2020-03-16 12:27 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/80eaef8e3e60 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: d25079af1459 Author: jiefu Date: 2020-03-16 22:43 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d25079af1459 8241034: Fix a configuring error with "-Xmx2048M: command not found" Reviewed-by: mikael, erikj ! make/autoconf/build-performance.m4 Changeset: 500f99ff1921 Author: naoto Date: 2020-03-16 09:26 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/500f99ff1921 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: 42b62267498d Author: eosterlund Date: 2020-03-16 17:13 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/42b62267498d 8241074: JDK-8240363 broke the build on AArch64 Reviewed-by: shade ! src/hotspot/share/opto/constantTable.cpp Changeset: da2fc44fd45f Author: zgu Date: 2020-02-25 12:01 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/da2fc44fd45f 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: cc3c165659bf Author: mbaesken Date: 2020-03-17 08:53 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/cc3c165659bf 8240824: enhance print_full_memory_info on Linux by THP related information Reviewed-by: dholmes, stuefe ! src/hotspot/os/linux/os_linux.cpp Changeset: daed0d4ec02d Author: redestad Date: 2020-03-17 09:36 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/daed0d4ec02d 8241077: x86_64: Minor Assembler improvements Reviewed-by: kvn ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp Changeset: 56e78301b358 Author: rkennke Date: 2020-03-17 11:49 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/56e78301b358 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: a4e2fc916323 Author: aph Date: 2020-03-16 17:10 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a4e2fc916323 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: 0daa6b52ba56 Author: aph Date: 2020-03-17 14:13 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0daa6b52ba56 Merge Changeset: 0a2e12c3e6e3 Author: kvn Date: 2020-03-17 10:38 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0a2e12c3e6e3 8240976: [JVMCI] MethodProfileWidth flag is broken Summary: 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: b5237a11d0dc Author: redestad Date: 2020-03-05 16:07 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b5237a11d0dc 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: 157a7e7033d9 Author: kvn Date: 2020-03-17 12:42 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/157a7e7033d9 8237045: JVM uses excessive memory with -XX:+EnableJVMCI -XX:JVMCICounterSize=2147483648 Summary: 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: 86af236fbd89 Author: kvn Date: 2020-03-17 14:05 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/86af236fbd89 8241122: Remove unimplemented InlineTree constructor definition from parse.hpp Reviewed-by: kvn Contributed-by: Charlie Gracie ! src/hotspot/share/opto/parse.hpp Changeset: 988822b06767 Author: dholmes Date: 2020-03-17 19:57 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/988822b06767 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: dd9eb63b5d3e Author: dholmes Date: 2020-03-17 20:54 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/dd9eb63b5d3e 8241124: Aarch64 build broken by JDK-8239593 Reviewed-by: mikael ! src/hotspot/share/prims/jni.cpp Changeset: d6ae5212211f Author: cjplummer Date: 2020-03-17 18:04 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d6ae5212211f 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: 824e6b7c5bcf Author: weijun Date: 2020-03-18 09:23 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/824e6b7c5bcf 8186143: keytool -ext option doesn't accept wildcards for DNS subject alternative names Reviewed-by: jnimeh, weijun, mullan Contributed-by: Hai-May Chao ! 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: f40aa9beb326 Author: naoto Date: 2020-03-17 19:11 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f40aa9beb326 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: 82d11846109a Author: shade Date: 2020-03-18 06:28 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/82d11846109a 8241093: Shenandoah: editorial changes in flag descriptions Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: 5df90c29762d Author: igerasim Date: 2020-03-18 01:04 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5df90c29762d 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: 5c47c5d72003 Author: itakiguchi Date: 2020-03-18 18:04 +0900 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5c47c5d72003 8232161: Align some one-way conversion in MS950 charset with Windows Summary: 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: 6c954123ee8d Author: jwilhelm Date: 2020-03-18 10:34 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6c954123ee8d Added tag jdk-14-ga for changeset bc54620a3848 ! .hgtags Changeset: dc7e9cde760e Author: jwilhelm Date: 2020-03-18 10:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/dc7e9cde760e Merge ! .hgtags Changeset: 743c9071c317 Author: mgronlun Date: 2020-03-18 12:00 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/743c9071c317 8239497: SEGV in EdgeUtils::field_name_symbol(Edge const&) Reviewed-by: egahlin, tonyp Contributed-by: Tony Printezis ! 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: a6203123a1e2 Author: mseledtsov Date: 2020-03-18 09:45 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a6203123a1e2 8241033: Create test library utility for getting JFR streaming repository Summary: 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: a25184d6d8a5 Author: cjplummer Date: 2020-03-18 10:14 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a25184d6d8a5 8240906: Update ZGC ProblemList for serviceability/sa/TestJmapCoreMetaspace.java Reviewed-by: stefank ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: ed0ecde93aaa Author: cjplummer Date: 2020-03-18 10:42 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ed0ecde93aaa 8227340: Modify problem list entry for javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java Reviewed-by: dholmes ! test/jdk/ProblemList.txt Changeset: 4674b84fc29b Author: dtitov Date: 2020-03-18 11:05 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4674b84fc29b 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:" Reviewed-by: amenkov ! test/jdk/sun/tools/jstatd/JstatdTest.java Changeset: f22610867eb4 Author: shade Date: 2020-03-18 19:24 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f22610867eb4 8241128: x86_32 build failure after JDK-8241042 Reviewed-by: redestad, kvn ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: 79a40801d56f Author: vromero Date: 2020-03-18 14:33 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/79a40801d56f 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: acce42fd27a7 Author: dnsimon Date: 2020-03-18 13:11 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/acce42fd27a7 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: dd555adfac9c Author: cjplummer Date: 2020-03-18 13:24 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/dd555adfac9c 8241162: ProblemList serviceability/sa/TestHeapDumpForInvokeDynamic.java on OSX Reviewed-by: dcubed ! test/hotspot/jtreg/ProblemList.txt Changeset: 5cc3cb873e98 Author: jjg Date: 2020-03-18 13:20 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5cc3cb873e98 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: 82b7c62cf4cc Author: jjg Date: 2020-03-18 13:29 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/82b7c62cf4cc Merge Changeset: 16d304873ab0 Author: winterhalter Date: 2020-03-18 17:07 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/16d304873ab0 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: af221c1b1671 Author: aleonard Date: 2020-03-17 14:14 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/af221c1b1671 8241097: java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings Reviewed-by: bpb, bchristi Contributed-by: andrew_m_leonard at uk.ibm.com ! test/jdk/java/math/BigInteger/largeMemory/SymmetricRangeTests.java Changeset: c1fdb04213e9 Author: mneugschwand Date: 2020-03-18 15:59 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c1fdb04213e9 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: c2f7e63f72c4 Author: jwilhelm Date: 2020-03-19 03:03 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c2f7e63f72c4 Added tag jdk-15+15 for changeset 82b7c62cf4cc ! .hgtags Changeset: df21b8edc4bc Author: xyin Date: 2020-03-19 11:07 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/df21b8edc4bc 8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset Reviewed-by: dfuchs, vtewari ! test/jdk/com/sun/jndi/ldap/RemoveNamingListenerTest.java Changeset: 87a7ff5a3a08 Author: iveresov Date: 2020-03-18 21:49 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/87a7ff5a3a08 8230290: [JVMCI] Remove unused API entry points Summary: 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: e367475aa21c Author: mbaesken Date: 2020-03-16 15:11 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e367475aa21c 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: b66ccad86904 Author: jiefu Date: 2020-03-19 16:34 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b66ccad86904 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: 76058080c621 Author: chagedorn Date: 2020-03-19 10:15 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/76058080c621 8240227: Loop predicates should be copied to unswitched loops Summary: 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: 216eefbbd337 Author: redestad Date: 2020-03-05 16:07 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/216eefbbd337 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: 159b07b8864f Author: alexsch Date: 2020-03-19 14:58 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/159b07b8864f 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: 5fc82780bffd Author: kravikumar Date: 2020-03-13 18:38 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5fc82780bffd 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: 3b798973400b Author: stefank Date: 2020-03-19 14:15 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3b798973400b 8240773: JFR: Non-Java threads are not serialized Reviewed-by: mgronlun ! src/hotspot/share/jfr/utilities/jfrThreadIterator.cpp Changeset: bd58c6e34ccf Author: stefank Date: 2020-03-19 14:16 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/bd58c6e34ccf 8240819: Assign a name to the JfrThreadSampler thread Reviewed-by: mgronlun ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp Changeset: 5404c5f83619 Author: stefank Date: 2020-03-19 14:17 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5404c5f83619 8240818: Remove colon from "JFR: Shutdown Hook" thread name Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java Changeset: 06146be26035 Author: stefank Date: 2020-03-19 14:18 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/06146be26035 8241263: JFR: Bump native events limit Reviewed-by: mgronlun, egahlin ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java Changeset: 4fa5becf6cb3 Author: ihse Date: 2020-03-19 17:17 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4fa5becf6cb3 8241254: Simplify usage of UTIL_DEPRECATED_ARG_ENABLE Reviewed-by: erikj ! make/autoconf/util.m4 Changeset: d780dd664f6c Author: cjplummer Date: 2020-03-19 10:20 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d780dd664f6c 8240543: Update problem list entry for serviceability/sa/TestRevPtrsForInvokeDynamic.java to reference JDK-8241235 Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList.txt Changeset: 5be44a818121 Author: jjg Date: 2020-03-19 11:25 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5be44a818121 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: 84ae4e628639 Author: iignatyev Date: 2020-03-17 21:35 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/84ae4e628639 8168304: Make all of DependencyContext_test available in product mode Summary: Enable the utility inspection function `DependencyContext::is_dependent_method` and therefore the test in the product mode. Reviewed-by: eosterlund, thartmann Contributed-by: Evgeny Nikitin ! src/hotspot/share/code/dependencyContext.cpp ! src/hotspot/share/code/dependencyContext.hpp ! test/hotspot/gtest/code/test_dependencyContext.cpp Changeset: 9d9ce4a87009 Author: rriggs Date: 2020-03-19 15:34 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/9d9ce4a87009 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: 6385879efd46 Author: dlong Date: 2020-03-19 12:29 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6385879efd46 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: 44a909932c7c Author: kbarrett Date: 2020-03-19 18:11 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/44a909932c7c 8139652: Mutator refinement processing should take the oldest dirty card buffer Summary: 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: 0c03ed579379 Author: pchilanomate Date: 2020-03-20 00:32 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0c03ed579379 8240902: JDI shared memory connector can use already closed Handles Summary: Add refcount to keep track of connection access Reviewed-by: dholmes, dcubed, sspitsyn ! src/jdk.jdi/share/native/libdt_shmem/shmemBase.c Changeset: b96911696f71 Author: xyin Date: 2020-03-20 10:24 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b96911696f71 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: eadd3a62ea18 Author: cjplummer Date: 2020-03-19 21:32 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/eadd3a62ea18 8241335: ProblemList serviceability/sa/ClhsdbPstack.java due to JDK-8240956 Reviewed-by: mikael ! test/hotspot/jtreg/ProblemList.txt Changeset: d2bee277e572 Author: kbarrett Date: 2020-03-20 01:20 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d2bee277e572 8241001: Improve logging in the ConcurrentGCBreakpoint mechanism Summary: 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: 1608514a4ce7 Author: lmesnik Date: 2020-03-20 00:24 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1608514a4ce7 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: 89ec93d09e7e Author: tschatzl Date: 2020-03-20 11:17 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/89ec93d09e7e 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: 2c275730b19d Author: jiahuang Date: 2020-03-20 18:52 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2c275730b19d 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: 61badf9448b4 Author: coleenp Date: 2020-03-20 07:30 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/61badf9448b4 8241320: The ClassLoaderData::_is_unsafe_anonymous field is unused in the SA Summary: 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: 7e5a53043493 Author: jcm Date: 2020-03-20 05:19 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7e5a53043493 8237894: CTW: C1 compilation fails with assert(x->type()->tag() == f->type()->tag()) failed: should have same type Summary: 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: 993974f21271 Author: roland Date: 2020-03-13 16:32 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/993974f21271 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: 60a0bfdf44b8 Author: aph Date: 2020-03-19 14:53 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/60a0bfdf44b8 8241296: Segfault in JNIHandleBlock::oops_do() Reviewed-by: stefank ! src/hotspot/share/runtime/thread.cpp Changeset: 132be3e5f9ee Author: aph Date: 2020-03-20 13:08 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/132be3e5f9ee Merge Changeset: 47cea54e6ba1 Author: xuelei Date: 2020-03-20 09:15 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/47cea54e6ba1 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: cb5757c52ca2 Author: xuelei Date: 2020-03-20 09:27 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/cb5757c52ca2 8219989: Retire the com.sun.net.ssl.internal.ssl.Provider name Summary: remove the provider name in JDK Reviewed-by: mullan ! src/java.base/share/classes/sun/security/jca/ProviderConfig.java Changeset: 5bfe8544c794 Author: minqi Date: 2020-03-20 09:40 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5bfe8544c794 8241009: CommandLineFlagComboNegative.java fails after JDK-8240563 Summary: 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: eb151fbfb58f Author: pconcannon Date: 2020-03-20 20:16 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/eb151fbfb58f 8240921: Minor correction to HttpResponse.BodySubscribers example Summary: The fix updates the incorrect example of the usage of the class java.net.http.HttpResponse.BodySubscribers. Reviewed-by: chegar, dfuchs, jboes, pconcannon Contributed-by: Rahul Yadav ! src/java.net.http/share/classes/java/net/http/HttpResponse.java ! test/jdk/java/net/httpclient/examples/JavadocExamples.java Changeset: 8c0c31d419ca Author: prappo Date: 2020-03-20 20:54 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8c0c31d419ca 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: 84215fa115fc Author: lmesnik Date: 2020-03-20 17:37 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/84215fa115fc 8241319: WB_GetCodeBlob doesn't have ResourceMark Reviewed-by: iignatyev, thartmann ! src/hotspot/share/prims/whitebox.cpp Changeset: 5cc32ff976fe Author: clanger Date: 2020-03-02 21:04 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5cc32ff976fe 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: dd263e4c510e Author: serb Date: 2020-03-02 23:35 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/dd263e4c510e 8235153: [TESTBUG] [macos 10.15] java/awt/Graphics/DrawImageBG/SystemBgColorTest.java fails Reviewed-by: aivanov ! test/jdk/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Changeset: 53efe5255d14 Author: serb Date: 2020-03-03 03:46 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/53efe5255d14 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: d9cb148e3998 Author: psadhukhan Date: 2020-03-03 14:45 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d9cb148e3998 Merge - test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibrary.java - test/hotspot/jtreg/runtime/testlibrary/GeneratedClassLoader.java Changeset: 91d6091570eb Author: pbansal Date: 2020-03-03 17:37 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/91d6091570eb 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: 35088e0d500d Author: pbansal Date: 2020-03-03 17:49 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/35088e0d500d 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: c0cd4c457b87 Author: pbansal Date: 2020-03-03 18:26 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c0cd4c457b87 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: beef72877eaa Author: serb Date: 2020-03-06 14:41 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/beef72877eaa 8219578: No associated icon for the leaf node of JTree Reviewed-by: prr, jdv ! src/java.desktop/share/classes/module-info.java Changeset: 7931313ece51 Author: kizune Date: 2020-03-09 00:18 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7931313ece51 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: 401496a02949 Author: tnakamura Date: 2020-03-09 15:07 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/401496a02949 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: c4d580d1305a Author: jdv Date: 2020-03-10 16:07 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c4d580d1305a 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: 392d5e420c73 Author: serb Date: 2020-03-10 11:30 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/392d5e420c73 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: 2f6ba1720303 Author: serb Date: 2020-03-10 13:58 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2f6ba1720303 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: f0242c3b42ab Author: serb Date: 2020-03-12 03:26 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f0242c3b42ab 8237746: Fixing compiler warnings in src/demo/share/jfc Reviewed-by: kizune, aivanov Contributed-by: Marc Hoffmann ! 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: 9d08530858ff Author: serb Date: 2020-03-11 21:58 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/9d08530858ff 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: 45273ef93e6f Author: serb Date: 2020-03-12 10:00 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/45273ef93e6f 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: f60a3b5270bf Author: prr Date: 2020-03-12 17:53 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f60a3b5270bf 8240977: ProblemList failing jtreg tests on macos Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 3ea8a0c5c264 Author: arapte Date: 2020-03-15 00:43 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3ea8a0c5c264 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: 889b4191879c Author: psadhukhan Date: 2020-03-16 12:49 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/889b4191879c 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: 23dc143cca50 Author: serb Date: 2020-03-16 17:33 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/23dc143cca50 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: a9ffedffd435 Author: prr Date: 2020-03-17 17:38 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a9ffedffd435 8223935: PIT: java/awt/font/WindowsIndicFonts.java fails on windows10 Reviewed-by: serb, jdv ! test/jdk/java/awt/font/WindowsIndicFonts.java Changeset: 7a9486869690 Author: trebari Date: 2020-03-18 11:38 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7a9486869690 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: ff66c5acbe68 Author: prr Date: 2020-03-18 15:48 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ff66c5acbe68 8241229: Problem list jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java Reviewed-by: aivanov, serb ! test/jdk/ProblemList.txt Changeset: 27a6f92a0f5f Author: psadhukhan Date: 2020-03-19 09:20 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/27a6f92a0f5f 8226230: Test javax/swing/JInternalFrame/8020708/bug8020708.java fails on Ubuntu Reviewed-by: serb ! test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java Changeset: 44f4d1256298 Author: psadhukhan Date: 2020-03-19 09:22 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/44f4d1256298 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: 39f8c4e79ae2
Author:    prr
Date:      2020-03-18 22:27 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/39f8c4e79ae2

8241233: Typo in problem listing of UIDefaultKeySizeTest.java
Reviewed-by: jdv

! test/jdk/ProblemList.txt

Changeset: 20374b37dd01
Author:    serb
Date:      2020-03-19 22:22 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/20374b37dd01

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: 59035a7fab5d
Author:    psadhukhan
Date:      2020-03-21 09:46 +0530
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/59035a7fab5d

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: 44fa3757eba0
Author:    prr
Date:      2020-03-20 22:52 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/44fa3757eba0

8232634: Problem List ICMColorDataTest.java
Reviewed-by: serb, psadhukhan

! test/jdk/ProblemList.txt

Changeset: 8afeb2188cf8
Author:    psadhukhan
Date:      2020-03-22 09:46 +0530
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/8afeb2188cf8

Merge

- make/CompileInterimRmic.gmk
- make/common/RMICompilation.gmk
! make/jdk/src/classes/build/tools/intpoly/header.txt
- 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/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp
- src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp
- src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp
- src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp
- src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp
- src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp
- src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java
- src/java.base/share/classes/com/sun/security/cert/internal/x509/X509V1CertImpl.java
- src/java.base/unix/classes/java/lang/ClassLoaderHelper.java
- src/java.base/windows/classes/java/lang/ClassLoaderHelper.java
- src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.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.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/spi/MemoryProxy.java
- src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java
- src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.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/Navigation.java
- 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/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java
! test/jdk/ProblemList.txt
- test/jdk/sun/management/jmxremote/bootstrap/Makefile
- 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
- test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java

Changeset: 038989f9361b
Author:    xuelei
Date:      2020-03-22 09:30 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/038989f9361b

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: 3df253feab7b
Author:    pli
Date:      2020-03-23 08:37 +0800
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/3df253feab7b

8241091: AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction"
Reviewed-by: aph

! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp

Changeset: 3ecfa2b80db2
Author:    ihse
Date:      2020-03-23 10:26 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/3ecfa2b80db2

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: f81815820cd5
Author:    ihse
Date:      2020-03-23 10:29 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/f81815820cd5

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: d2d076a7dfc4
Author:    shade
Date:      2020-03-23 10:37 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/d2d076a7dfc4

8241068: Shenandoah: improve ShenandoahTraversalGC constructor arguments
Reviewed-by: shade
Contributed-by: Kelvin Nilsen 

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

Changeset: 973301ba95bb
Author:    dfuchs
Date:      2020-03-23 14:22 +0000
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/973301ba95bb

8241443: Problem list some java.net tests failing with NoRouteToHostException on macOS with special network configuration
Reviewed-by: alanb

! test/jdk/ProblemList.txt

Changeset: ec23fc249e34
Author:    mchung
Date:      2020-03-23 09:05 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/ec23fc249e34

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: c5ad25b322b8
Author:    sviswanathan
Date:      2020-03-23 10:26 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/c5ad25b322b8

8240248: Extend superword reduction optimizations for x86
Summary: Add support for and, or, xor reduction
Reviewed-by: vlivanov, thartmann
Contributed-by: sandhya.viswanathan at intel.com, shravya.rukmannagari at intel.com

! 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: fcbd54a2c2d9
Author:    poonam
Date:      2020-03-23 17:57 +0000
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/fcbd54a2c2d9

8231779: crash HeapWord*ParallelScavengeHeap::failed_mem_allocate
Reviewed-by: dlong, tschatzl, pliden

! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp

Changeset: 31bb8878e42e
Author:    shade
Date:      2020-03-23 19:14 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/31bb8878e42e

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: c9fba77b1507
Author:    shade
Date:      2020-03-23 19:14 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/c9fba77b1507

8241435: Shenandoah: avoid disabling pacing with "aggressive"
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp

Changeset: c456587e7ef4
Author:    shade
Date:      2020-03-23 19:14 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/c456587e7ef4

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: bea08473341c
Author:    jjg
Date:      2020-03-23 12:48 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/bea08473341c

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: 1b6cb377d024
Author:    iklam
Date:      2020-03-23 13:27 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/1b6cb377d024

8241244: CDS dynamic dump asserts in ArchivePtrBitmapCleaner::do_bit
Reviewed-by: minqi, coleenp

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

Changeset: 038518d628e7
Author:    jjg
Date:      2020-03-23 14:11 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/038518d628e7

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: c0dd28941d68
Author:    redestad
Date:      2020-03-23 23:18 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/c0dd28941d68

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: cc739b0abc44
Author:    adityam
Date:      2020-03-24 06:13 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/cc739b0abc44

8241067: Shenandoah: improve ShenandoahNMethod::has_cset_oops arguments
Reviewed-by: shade
Contributed-by: Aditya Mandaleeka 

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

Changeset: 98cfafb96a72
Author:    adinn
Date:      2020-03-19 17:26 +0000
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/98cfafb96a72

8241144: Javadoc is not generated for new module jdk.nio.mapmode
Summary: jdk.nio.mapmode is not present in DOCS_MODULES defined by Modules.gmk
Reviewed-by: erikj, ihse

! make/common/Modules.gmk

Changeset: c5343bb8c596
Author:    kvn
Date:      2020-03-24 09:34 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/c5343bb8c596

8237497: vmStructs_jvmci.cpp does not check that the correct field type is specified
Summary: 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: 23dab0354eb0
Author:    thartmann
Date:      2020-03-24 17:39 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/23dab0354eb0

8240905: assert(mem == (Node*)1 || mem == mem2) failed: multiple Memories being matched at once?
Summary: 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: 6ff2d38ef833
Author:    dcubed
Date:      2020-03-24 13:08 -0400
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/6ff2d38ef833

8241532: ProblemList tests from 8241530 on OSX
Reviewed-by: ctornqvi

! test/jdk/ProblemList.txt

Changeset: 98df5a01d1ee
Author:    stuefe
Date:      2020-03-24 18:41 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/98df5a01d1ee

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: 9517a132eb6d
Author:    shade
Date:      2020-03-24 18:46 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/9517a132eb6d

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: a0826f064eaf
Author:    shade
Date:      2020-03-24 18:46 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/a0826f064eaf

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: 99e2b5918d07
Author:    shade
Date:      2020-03-24 18:46 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/99e2b5918d07

8241462: StripNativeDebugSymbols jlink plugin allocates huge arrays
Reviewed-by: alanb, sgehwolf

! src/jdk.jlink/linux/classes/jdk/tools/jlink/internal/plugins/StripNativeDebugSymbolsPlugin.java

Changeset: 97a3e6ce2652
Author:    shade
Date:      2020-03-24 18:46 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/97a3e6ce2652

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: 2ca9499e1c68
Author:    shade
Date:      2020-03-24 20:18 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/2ca9499e1c68

8241545: Shenandoah: purge root work overwrites counters after JDK-8228818
Reviewed-by: zgu

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

Changeset: b9562cc25fc0
Author:    never
Date:      2020-03-24 13:12 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/b9562cc25fc0

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: 7bbf2c0efac8
Author:    vlivanov
Date:      2020-03-25 00:10 +0300
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/7bbf2c0efac8

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: 9cff5368d25a
Author:    shade
Date:      2020-03-25 07:58 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/9cff5368d25a

8241500: FieldLayout/OldLayoutCheck.java fails in 32-bit VMs
Reviewed-by: fparain, dholmes

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

Changeset: 4bb7d9ea608d
Author:    redestad
Date:      2020-03-25 13:38 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/4bb7d9ea608d

8241584: Remove unused classLoader perf counters
Reviewed-by: hseigel

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

Changeset: 5d3f6f0582fe
Author:    chagedorn
Date:      2020-03-25 14:41 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/5d3f6f0582fe

8237859: C2: Crash when loads float above range check
Summary: 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: ba672c242599
Author:    igerasim
Date:      2020-03-25 08:46 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/ba672c242599

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: ee707e1ced80
Author:    shade
Date:      2020-03-25 17:20 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/ee707e1ced80

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: fb44f597981a
Author:    naoto
Date:      2020-03-25 09:21 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/fb44f597981a

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: 33759bdb2cfc
Author:    ascarpino
Date:      2020-03-25 12:41 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/33759bdb2cfc

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: b65352cf6754
Author:    jjg
Date:      2020-03-25 15:03 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/b65352cf6754

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



From david.holmes at oracle.com  Thu Mar 26 01:36:58 2020
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Thu, 26 Mar 2020 01:36:58 +0000
Subject: hg: valhalla/valhalla: Merge
Message-ID: <202003260136.02Q1awG8029003@aojmv0008.oracle.com>

Changeset: aa67336b5f17
Author:    dholmes
Date:      2020-03-25 21:31 -0400
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/aa67336b5f17

Merge

- make/CompileInterimRmic.gmk
- make/common/RMICompilation.gmk
- 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/demo/share/jfc/Font2DTest/Font2DTestApplet.java
- src/demo/share/jfc/SwingSet2/SwingSet2Applet.java
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/sparc/templateTable_sparc.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/klassFactory.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
- src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp
- src/hotspot/share/gc/shared/concurrentGCPhaseManager.hpp
- src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp
- src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp
- src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp
- src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/vmStructs.cpp
- src/java.base/macosx/classes/java/lang/ClassLoaderHelper.java
- src/java.base/share/classes/com/sun/security/cert/internal/x509/X509V1CertImpl.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
! src/java.base/share/native/libjava/ClassLoader.c
- src/java.base/unix/classes/java/lang/ClassLoaderHelper.java
- src/java.base/windows/classes/java/lang/ClassLoaderHelper.java
- src/java.rmi/share/doc/stub/java/rmi/activation/ActivationGroup_Stub.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.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.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/spi/MemoryProxy.java
- src/jdk.jartool/share/classes/sun/tools/jar/Manifest.java
- src/jdk.jartool/share/classes/sun/tools/jar/SignatureFile.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/Navigation.java
! test/hotspot/jtreg/ProblemList.txt
- 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/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/jdk/ProblemList.txt
- test/jdk/java/awt/TrayIcon/AddPopupAfterShowTest/AddPopupAfterShowTest.html
- test/jdk/sun/management/jmxremote/bootstrap/Makefile
- 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
- test/langtools/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java



From david.holmes at oracle.com  Thu Mar 26 09:19:25 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Mar 2020 19:19:25 +1000
Subject: RFR: 8241562: Rework nest host resolution/validation error support
Message-ID: 

webrev: http://cr.openjdk.java.net/~dholmes/8241562/webrev/

This is (hopefully) the last pre-integration cleanup for JEP-371: Hidden 
classes.

Rather than store the error message in a field of InstanceKlass we 
piggy-back onto the existing ResolutionErrorTable logic and add a new 
field to the ResolutionErrorEntry.

Also factored out the complex error message logic in linkResolver methods.

There's one code path in free_entry not covered by any existing testing 
so I will look at developing a test for that. Otherwise all new code 
paths have been tested.

Thanks,
David


From lois.foltan at oracle.com  Thu Mar 26 11:40:04 2020
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 26 Mar 2020 07:40:04 -0400
Subject: RFR: 8241562: Rework nest host resolution/validation error support
In-Reply-To: 
References: 
Message-ID: <8bd6a6e0-1de7-41f7-5a63-b790b00fafdc@oracle.com>

I've been following the preliminary conversations on this.? I think it 
looks good!
Lois

On 3/26/2020 5:19 AM, David Holmes wrote:
> webrev: http://cr.openjdk.java.net/~dholmes/8241562/webrev/
>
> This is (hopefully) the last pre-integration cleanup for JEP-371: 
> Hidden classes.
>
> Rather than store the error message in a field of InstanceKlass we 
> piggy-back onto the existing ResolutionErrorTable logic and add a new 
> field to the ResolutionErrorEntry.
>
> Also factored out the complex error message logic in linkResolver 
> methods.
>
> There's one code path in free_entry not covered by any existing 
> testing so I will look at developing a test for that. Otherwise all 
> new code paths have been tested.
>
> Thanks,
> David



From harold.seigel at oracle.com  Thu Mar 26 12:44:29 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Thu, 26 Mar 2020 08:44:29 -0400
Subject: RFR: 8241562: Rework nest host resolution/validation error support
In-Reply-To: <8bd6a6e0-1de7-41f7-5a63-b790b00fafdc@oracle.com>
References: 
 <8bd6a6e0-1de7-41f7-5a63-b790b00fafdc@oracle.com>
Message-ID: <38a49a99-5ed3-8e99-040a-662f40781f9d@oracle.com>

+1

Harold

On 3/26/2020 7:40 AM, Lois Foltan wrote:
> I've been following the preliminary conversations on this.? I think it 
> looks good!
> Lois
>
> On 3/26/2020 5:19 AM, David Holmes wrote:
>> webrev: http://cr.openjdk.java.net/~dholmes/8241562/webrev/
>>
>> This is (hopefully) the last pre-integration cleanup for JEP-371: 
>> Hidden classes.
>>
>> Rather than store the error message in a field of InstanceKlass we 
>> piggy-back onto the existing ResolutionErrorTable logic and add a new 
>> field to the ResolutionErrorEntry.
>>
>> Also factored out the complex error message logic in linkResolver 
>> methods.
>>
>> There's one code path in free_entry not covered by any existing 
>> testing so I will look at developing a test for that. Otherwise all 
>> new code paths have been tested.
>>
>> Thanks,
>> David
>


From david.holmes at oracle.com  Thu Mar 26 13:22:57 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Mar 2020 23:22:57 +1000
Subject: RFR: 8241562: Rework nest host resolution/validation error support
In-Reply-To: <8bd6a6e0-1de7-41f7-5a63-b790b00fafdc@oracle.com>
References: 
 <8bd6a6e0-1de7-41f7-5a63-b790b00fafdc@oracle.com>
Message-ID: 

Thanks Lois!

David

On 26/03/2020 9:40 pm, Lois Foltan wrote:
> I've been following the preliminary conversations on this.? I think it 
> looks good!
> Lois
> 
> On 3/26/2020 5:19 AM, David Holmes wrote:
>> webrev: http://cr.openjdk.java.net/~dholmes/8241562/webrev/
>>
>> This is (hopefully) the last pre-integration cleanup for JEP-371: 
>> Hidden classes.
>>
>> Rather than store the error message in a field of InstanceKlass we 
>> piggy-back onto the existing ResolutionErrorTable logic and add a new 
>> field to the ResolutionErrorEntry.
>>
>> Also factored out the complex error message logic in linkResolver 
>> methods.
>>
>> There's one code path in free_entry not covered by any existing 
>> testing so I will look at developing a test for that. Otherwise all 
>> new code paths have been tested.
>>
>> Thanks,
>> David
> 


From david.holmes at oracle.com  Thu Mar 26 13:23:15 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Mar 2020 23:23:15 +1000
Subject: RFR: 8241562: Rework nest host resolution/validation error support
In-Reply-To: <38a49a99-5ed3-8e99-040a-662f40781f9d@oracle.com>
References: 
 <8bd6a6e0-1de7-41f7-5a63-b790b00fafdc@oracle.com>
 <38a49a99-5ed3-8e99-040a-662f40781f9d@oracle.com>
Message-ID: <93bdb43c-45ef-ab18-8ca5-e9bb2e1ae4de@oracle.com>

Thanks Harold!

David

On 26/03/2020 10:44 pm, Harold Seigel wrote:
> +1
> 
> Harold
> 
> On 3/26/2020 7:40 AM, Lois Foltan wrote:
>> I've been following the preliminary conversations on this.? I think it 
>> looks good!
>> Lois
>>
>> On 3/26/2020 5:19 AM, David Holmes wrote:
>>> webrev: http://cr.openjdk.java.net/~dholmes/8241562/webrev/
>>>
>>> This is (hopefully) the last pre-integration cleanup for JEP-371: 
>>> Hidden classes.
>>>
>>> Rather than store the error message in a field of InstanceKlass we 
>>> piggy-back onto the existing ResolutionErrorTable logic and add a new 
>>> field to the ResolutionErrorEntry.
>>>
>>> Also factored out the complex error message logic in linkResolver 
>>> methods.
>>>
>>> There's one code path in free_entry not covered by any existing 
>>> testing so I will look at developing a test for that. Otherwise all 
>>> new code paths have been tested.
>>>
>>> Thanks,
>>> David
>>


From mandy.chung at oracle.com  Thu Mar 26 16:22:45 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Mar 2020 09:22:45 -0700
Subject: RFR: 8241562: Rework nest host resolution/validation error support
In-Reply-To: 
References: 
Message-ID: <6800fc4c-b940-2a87-cca9-7122129a6fce@oracle.com>

Looks good.? I like this approach too.

Mandy

On 3/26/20 2:19 AM, David Holmes wrote:
> webrev: http://cr.openjdk.java.net/~dholmes/8241562/webrev/
>
> This is (hopefully) the last pre-integration cleanup for JEP-371: 
> Hidden classes.
>
> Rather than store the error message in a field of InstanceKlass we 
> piggy-back onto the existing ResolutionErrorTable logic and add a new 
> field to the ResolutionErrorEntry.
>
> Also factored out the complex error message logic in linkResolver 
> methods.
>
> There's one code path in free_entry not covered by any existing 
> testing so I will look at developing a test for that. Otherwise all 
> new code paths have been tested.
>
> Thanks,
> David



From mandy.chung at oracle.com  Thu Mar 26 16:38:15 2020
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 26 Mar 2020 16:38:15 +0000
Subject: hg: valhalla/valhalla: 15 new changesets
Message-ID: <202003261638.02QGcGvo022021@aojmv0008.oracle.com>

Changeset: 5c7ec21f5d13
Author:    jjiang
Date:      2020-03-26 07:09 +0800
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/5c7ec21f5d13

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: 7e710082a8aa
Author:    redestad
Date:      2020-03-26 00:02 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/7e710082a8aa

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: a57bcb71fdaa
Author:    pli
Date:      2020-03-26 10:10 +0800
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/a57bcb71fdaa

8241482: AArch64: Fix a potential issue after JDK-8239549
Reviewed-by: aph

! src/hotspot/cpu/aarch64/aarch64.ad

Changeset: ff19fd7429bd
Author:    yzhang
Date:      2020-03-26 14:46 +0800
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/ff19fd7429bd

8241419: Remove unused InterfaceSupport::_number_of_calls
Reviewed-by: dholmes
Contributed-by: jie.he at arm.com

! src/hotspot/share/runtime/interfaceSupport.cpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp

Changeset: 56b281f37868
Author:    mbaesken
Date:      2020-03-24 15:26 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/56b281f37868

8241491: Problem list jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java on aix
Reviewed-by: clanger

! test/jdk/ProblemList.txt

Changeset: 28fa7b197532
Author:    roland
Date:      2020-03-20 13:56 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/28fa7b197532

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: 7d71520ea148
Author:    roland
Date:      2020-03-20 13:58 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/7d71520ea148

8241365: Define Unique_Node_List::contains() to prevent usage by mistake
Reviewed-by: kvn, thartmann

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

Changeset: bd1f89367b9f
Author:    redestad
Date:      2020-03-26 10:02 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/bd1f89367b9f

8241649: Optimize Character.toString
Reviewed-by: redestad, rriggs
Contributed-by: sergei.tsypanov at yandex.ru

! src/java.base/share/classes/java/lang/Character.java

Changeset: 51acdbbcfea3
Author:    jwilhelm
Date:      2020-03-26 03:15 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/51acdbbcfea3

Added tag jdk-15+16 for changeset 5c7ec21f5d13

! .hgtags

Changeset: 12c874ae6810
Author:    jboes
Date:      2020-03-26 11:52 +0000
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/12c874ae6810

8235459: HttpRequest.BodyPublishers::ofFile assumes the default file system
Summary: 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: c69cdcdb8a88
Author:    chagedorn
Date:      2020-03-26 13:43 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/c69cdcdb8a88

8241595: Fix missing debug_orig information in Ideal Graph Visualizer
Summary: 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: 95b5ae26d526
Author:    coleenp
Date:      2020-03-26 10:29 -0400
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/95b5ae26d526

8172485: [TESTBUG] RedefineLeak.java runs out of metaspace memory
Summary: Check for zero exit value.
Reviewed-by: lfoltan

! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeak.java

Changeset: 229c46cc80da
Author:    jboes
Date:      2020-03-26 14:58 +0000
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/229c46cc80da

8241674: Fix incorrect jtreg option in FilePublisherPermsTest
Summary: 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: 04ac1d775349
Author:    pliden
Date:      2020-03-26 16:56 +0100
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/04ac1d775349

8241596: ZGC: Shorten runtime of gc/z/TestUncommit.java
Reviewed-by: tschatzl, sjohanss

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

Changeset: e886b0d7ff87
Author:    dtitov
Date:      2020-03-26 09:03 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/e886b0d7ff87

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



From mandy.chung at oracle.com  Thu Mar 26 17:01:49 2020
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 26 Mar 2020 17:01:49 +0000
Subject: hg: valhalla/valhalla: Merge
Message-ID: <202003261701.02QH1nDV004544@aojmv0008.oracle.com>

Changeset: 1e14b42ab69b
Author:    mchung
Date:      2020-03-26 09:55 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/1e14b42ab69b

Merge

! src/hotspot/share/classfile/systemDictionary.cpp
! test/jdk/ProblemList.txt



From rriggs at openjdk.java.net  Thu Mar 26 17:14:10 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 26 Mar 2020 17:14:10 GMT
Subject: [lworld] RFR: Prototype inline cursors for List
Message-ID: 

Implementation of Cursors and jmh tests comparing
typical List traversal via direct index, iterator,
inline cursor, and an iterator implemented on top of cursor.

Sample results:

                                   (size)  Mode  Cnt       Score       Error  Units
XArrayListCursorTest.getViaArray            100000  avgt    5  507793.484  7086.038  ns/op
XArrayListCursorTest.getViaCursorForLoop    100000  avgt    5  656461.958  52488.547  ns/op
XArrayListCursorTest.getViaCursorWhileLoop  100000  avgt    5  641963.323  32219.409  ns/op
XArrayListCursorTest.getViaIterator         100000  avgt    5  558863.817  23539.256  ns/op
XArrayListCursorTest.getViaIteratorCurs     100000  avgt    5  733161.466  33721.881  ns/op

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

Commit messages:
 - Prototype inline cursors for List

Changes: https://git.openjdk.java.net/valhalla/pull/5/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/5/webrev.00
  Stats: 2139 lines in 3 files changed: 2139 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/5.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/5/head:pull/5

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


From brian.goetz at oracle.com  Thu Mar 26 17:45:37 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 26 Mar 2020 13:45:37 -0400
Subject: [lworld] RFR: Prototype inline cursors for List
In-Reply-To: 
References: 
Message-ID: <36ae35d3-0296-e5c1-e0df-5f21cfd7901f@oracle.com>

These don't look so good!? I suspect that the Iterator is performing so 
well because it's getting good EA, but not sure why cursors aren't doing 
better?? Guess we'll have to dig into the generated code....

On 3/26/2020 1:14 PM, Roger Riggs wrote:
> Implementation of Cursors and jmh tests comparing
> typical List traversal via direct index, iterator,
> inline cursor, and an iterator implemented on top of cursor.
>
> Sample results:
>
>                                     (size)  Mode  Cnt       Score       Error  Units
> XArrayListCursorTest.getViaArray            100000  avgt    5  507793.484  7086.038  ns/op
> XArrayListCursorTest.getViaCursorForLoop    100000  avgt    5  656461.958  52488.547  ns/op
> XArrayListCursorTest.getViaCursorWhileLoop  100000  avgt    5  641963.323  32219.409  ns/op
> XArrayListCursorTest.getViaIterator         100000  avgt    5  558863.817  23539.256  ns/op
> XArrayListCursorTest.getViaIteratorCurs     100000  avgt    5  733161.466  33721.881  ns/op
>
> -------------
>
> Commit messages:
>   - Prototype inline cursors for List
>
> Changes: https://git.openjdk.java.net/valhalla/pull/5/files
>   Webrev: https://webrevs.openjdk.java.net/valhalla/5/webrev.00
>    Stats: 2139 lines in 3 files changed: 2139 ins; 0 del; 0 mod
>    Patch: https://git.openjdk.java.net/valhalla/pull/5.diff
>    Fetch: git fetch https://git.openjdk.java.net/valhalla pull/5/head:pull/5
>
> PR: https://git.openjdk.java.net/valhalla/pull/5



From paul.sandoz at oracle.com  Thu Mar 26 17:47:45 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Mar 2020 10:47:45 -0700
Subject: [lworld] RFR: Prototype inline cursors for List
In-Reply-To: 
References: 
Message-ID: <6BB67ED5-DA7C-4667-9CF3-FAB31ADBA6CA@oracle.com>

IMHO you need to look at the hotspots of the generated code to get more insights as to why the cursor is not on par with the EA?ed iterator.

Use dtraceasm on the Mac, or perfasm on Linux, it's great!
 
Paul.

> On Mar 26, 2020, at 10:14 AM, Roger Riggs  wrote:
> 
> Implementation of Cursors and jmh tests comparing
> typical List traversal via direct index, iterator,
> inline cursor, and an iterator implemented on top of cursor.
> 
> Sample results:
> 
>                                   (size)  Mode  Cnt       Score       Error  Units
> XArrayListCursorTest.getViaArray            100000  avgt    5  507793.484  7086.038  ns/op
> XArrayListCursorTest.getViaCursorForLoop    100000  avgt    5  656461.958  52488.547  ns/op
> XArrayListCursorTest.getViaCursorWhileLoop  100000  avgt    5  641963.323  32219.409  ns/op
> XArrayListCursorTest.getViaIterator         100000  avgt    5  558863.817  23539.256  ns/op
> XArrayListCursorTest.getViaIteratorCurs     100000  avgt    5  733161.466  33721.881  ns/op
> 
> -------------
> 
> Commit messages:
> - Prototype inline cursors for List
> 
> Changes: https://git.openjdk.java.net/valhalla/pull/5/files
> Webrev: https://webrevs.openjdk.java.net/valhalla/5/webrev.00
>  Stats: 2139 lines in 3 files changed: 2139 ins; 0 del; 0 mod
>  Patch: https://git.openjdk.java.net/valhalla/pull/5.diff
>  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/5/head:pull/5
> 
> PR: https://git.openjdk.java.net/valhalla/pull/5



From forax at univ-mlv.fr  Thu Mar 26 17:48:37 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 26 Mar 2020 18:48:37 +0100 (CET)
Subject: [lworld] RFR: Prototype inline cursors for List
In-Reply-To: 
References: 
Message-ID: <1955576905.770911.1585244917162.JavaMail.zimbra@u-pem.fr>

Hi Roger,
I think implementing remove() on a cursor is a bad idea, since we have introduced Collection.removeIf() in 8 the main use case of remove() has disappeared and it's still implemented by Iterator if someone really want it.
In term of performance, it makes a huge difference because you can now implement a snapshot at the beginning semantics, you don't have to be aware if the XArrayList changes and you don't have to propagate back the structural change done by remove(), so basically you can avoid the check for ConcurrentModification.

With that, in the cursor, you can capture the array and the size when creating it instead of capturing a reference to the enclosing class (XArrayList.this), it should be a little more efficient.
I believe you can also remove the try/catch + rethrow and use Objects.checkIndex instead.

If everything goes right, it should be has efficient as doing a for loop on the array.

regards,
R?mi

----- Mail original -----
> De: "Roger Riggs" 
> ?: "valhalla-dev" 
> Envoy?: Jeudi 26 Mars 2020 18:14:10
> Objet: [lworld] RFR: Prototype inline cursors for List

> Implementation of Cursors and jmh tests comparing
> typical List traversal via direct index, iterator,
> inline cursor, and an iterator implemented on top of cursor.
> 
> Sample results:
> 
>                                   (size)  Mode  Cnt       Score       Error  Units
> XArrayListCursorTest.getViaArray            100000  avgt    5  507793.484
> 7086.038  ns/op
> XArrayListCursorTest.getViaCursorForLoop    100000  avgt    5  656461.958
> 52488.547  ns/op
> XArrayListCursorTest.getViaCursorWhileLoop  100000  avgt    5  641963.323
> 32219.409  ns/op
> XArrayListCursorTest.getViaIterator         100000  avgt    5  558863.817
> 23539.256  ns/op
> XArrayListCursorTest.getViaIteratorCurs     100000  avgt    5  733161.466
> 33721.881  ns/op
> 
> -------------
> 
> Commit messages:
> - Prototype inline cursors for List
> 
> Changes: https://git.openjdk.java.net/valhalla/pull/5/files
> Webrev: https://webrevs.openjdk.java.net/valhalla/5/webrev.00
>  Stats: 2139 lines in 3 files changed: 2139 ins; 0 del; 0 mod
>  Patch: https://git.openjdk.java.net/valhalla/pull/5.diff
>  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/5/head:pull/5
> 
> PR: https://git.openjdk.java.net/valhalla/pull/5


From Roger.Riggs at oracle.com  Thu Mar 26 18:07:13 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 26 Mar 2020 14:07:13 -0400
Subject: [lworld] RFR: Prototype inline cursors for List
In-Reply-To: <36ae35d3-0296-e5c1-e0df-5f21cfd7901f@oracle.com>
References: 
 <36ae35d3-0296-e5c1-e0df-5f21cfd7901f@oracle.com>
Message-ID: <51defac2-8099-c3d0-d696-d8782f49e621@oracle.com>

Hi Brian,

I've looked at the code and its not a lot different in the number of 
fetches and conditional branches.
I'll be looking into it further.

Roger


On 3/26/20 1:45 PM, Brian Goetz wrote:
> These don't look so good!? I suspect that the Iterator is performing 
> so well because it's getting good EA, but not sure why cursors aren't 
> doing better?? Guess we'll have to dig into the generated code....
>
> On 3/26/2020 1:14 PM, Roger Riggs wrote:
>> Implementation of Cursors and jmh tests comparing
>> typical List traversal via direct index, iterator,
>> inline cursor, and an iterator implemented on top of cursor.
>>
>> Sample results:
>>
>> ??????????????????????????????????? (size)? Mode? Cnt Score?????? 
>> Error? Units
>> XArrayListCursorTest.getViaArray??????????? 100000? avgt??? 5 
>> 507793.484? 7086.038? ns/op
>> XArrayListCursorTest.getViaCursorForLoop??? 100000? avgt??? 5 
>> 656461.958? 52488.547? ns/op
>> XArrayListCursorTest.getViaCursorWhileLoop? 100000? avgt??? 5 
>> 641963.323? 32219.409? ns/op
>> XArrayListCursorTest.getViaIterator???????? 100000? avgt??? 5 
>> 558863.817? 23539.256? ns/op
>> XArrayListCursorTest.getViaIteratorCurs???? 100000? avgt??? 5 
>> 733161.466? 33721.881? ns/op
>>
>> -------------
>>
>> Commit messages:
>> ? - Prototype inline cursors for List
>>
>> Changes: https://git.openjdk.java.net/valhalla/pull/5/files
>> ? Webrev: https://webrevs.openjdk.java.net/valhalla/5/webrev.00
>> ?? Stats: 2139 lines in 3 files changed: 2139 ins; 0 del; 0 mod
>> ?? Patch: https://git.openjdk.java.net/valhalla/pull/5.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/valhalla 
>> pull/5/head:pull/5
>>
>> PR: https://git.openjdk.java.net/valhalla/pull/5
>



From Roger.Riggs at oracle.com  Thu Mar 26 18:14:54 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 26 Mar 2020 14:14:54 -0400
Subject: [lworld] RFR: Prototype inline cursors for List
In-Reply-To: <1955576905.770911.1585244917162.JavaMail.zimbra@u-pem.fr>
References: 
 <1955576905.770911.1585244917162.JavaMail.zimbra@u-pem.fr>
Message-ID: 

Hi Remi,

On 3/26/20 1:48 PM, Remi Forax wrote:
> Hi Roger,
> I think implementing remove() on a cursor is a bad idea, since we have introduced Collection.removeIf() in 8 the main use case of remove() has disappeared and it's still implemented by Iterator if someone really want it.
Possibly, I was trying out what it takes for parity with Iterator.
> In term of performance, it makes a huge difference because you can now implement a snapshot at the beginning semantics, you don't have to be aware if the XArrayList changes and you don't have to propagate back the structural change done by remove(), so basically you can avoid the check for ConcurrentModification.
Yes simplifying the semantics would help, but that would not be an 
ArrayList but something else.

Part of the exercise was to see where inline classes can subsitute for 
(assumed) more expensive identity classes.

>
> With that, in the cursor, you can capture the array and the size when creating it instead of capturing a reference to the enclosing class (XArrayList.this), it should be a little more efficient.
> I believe you can also remove the try/catch + rethrow and use Objects.checkIndex instead.
Unless the VM can eliminate the checks the implicit array range check 
should be cheaper/free.
Or I misunderstand how try/catch is implemented by the vm.

>
> If everything goes right, it should be has efficient as doing a for loop on the array.
Yep, that's the idea.

The cost avoidance of not doing allocation is hard to measure.

In some previous experiements, the extra data that had to be moved around
wiped out the savings by not having an identity object.

I've looked at the code with JMH and perfasm and
I'll be looking more closely at the performance and any help is appreciated.

Thanks, Roger

>
> regards,
> R?mi
>
> ----- Mail original -----
>> De: "Roger Riggs" 
>> ?: "valhalla-dev" 
>> Envoy?: Jeudi 26 Mars 2020 18:14:10
>> Objet: [lworld] RFR: Prototype inline cursors for List
>> Implementation of Cursors and jmh tests comparing
>> typical List traversal via direct index, iterator,
>> inline cursor, and an iterator implemented on top of cursor.
>>
>> Sample results:
>>
>>                                    (size)  Mode  Cnt       Score       Error  Units
>> XArrayListCursorTest.getViaArray            100000  avgt    5  507793.484
>> 7086.038  ns/op
>> XArrayListCursorTest.getViaCursorForLoop    100000  avgt    5  656461.958
>> 52488.547  ns/op
>> XArrayListCursorTest.getViaCursorWhileLoop  100000  avgt    5  641963.323
>> 32219.409  ns/op
>> XArrayListCursorTest.getViaIterator         100000  avgt    5  558863.817
>> 23539.256  ns/op
>> XArrayListCursorTest.getViaIteratorCurs     100000  avgt    5  733161.466
>> 33721.881  ns/op
>>
>> -------------
>>
>> Commit messages:
>> - Prototype inline cursors for List
>>
>> Changes: https://git.openjdk.java.net/valhalla/pull/5/files
>> Webrev: https://webrevs.openjdk.java.net/valhalla/5/webrev.00
>>   Stats: 2139 lines in 3 files changed: 2139 ins; 0 del; 0 mod
>>   Patch: https://git.openjdk.java.net/valhalla/pull/5.diff
>>   Fetch: git fetch https://git.openjdk.java.net/valhalla pull/5/head:pull/5
>>
>> PR: https://git.openjdk.java.net/valhalla/pull/5



From harold.seigel at oracle.com  Thu Mar 26 18:22:52 2020
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Thu, 26 Mar 2020 18:22:52 +0000
Subject: hg: valhalla/valhalla: Summary: Improve passing arguments to
 ClassFileParser constructor
Message-ID: <202003261822.02QIMq8Z025837@aojmv0008.oracle.com>

Changeset: cd8f44ac380d
Author:    hseigel
Date:      2020-03-26 18:22 +0000
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/cd8f44ac380d

Summary: Improve passing arguments to ClassFileParser constructor
Reviewed-by: lfoltan, mchung, coleenp

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classFileParser.hpp
! src/hotspot/share/classfile/klassFactory.cpp
! src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp



From forax at univ-mlv.fr  Thu Mar 26 19:38:22 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 26 Mar 2020 20:38:22 +0100 (CET)
Subject: [lworld] RFR: Prototype inline cursors for List
In-Reply-To: 
References: 
 <1955576905.770911.1585244917162.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <1978750245.805863.1585251502717.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Roger Riggs" 
> ?: "valhalla-dev" 
> Envoy?: Jeudi 26 Mars 2020 19:14:54
> Objet: Re: [lworld] RFR: Prototype inline cursors for List

> Hi Remi,

Hi Roger,

> 
> On 3/26/20 1:48 PM, Remi Forax wrote:
>> Hi Roger,
>> I think implementing remove() on a cursor is a bad idea, since we have
>> introduced Collection.removeIf() in 8 the main use case of remove() has
>> disappeared and it's still implemented by Iterator if someone really want it.
> Possibly, I was trying out what it takes for parity with Iterator.
>> In term of performance, it makes a huge difference because you can now implement
>> a snapshot at the beginning semantics, you don't have to be aware if the
>> XArrayList changes and you don't have to propagate back the structural change
>> done by remove(), so basically you can avoid the check for
>> ConcurrentModification.
> Yes simplifying the semantics would help, but that would not be an
> ArrayList but something else.
> 
> Part of the exercise was to see where inline classes can subsitute for
> (assumed) more expensive identity classes.
> 
>>
>> With that, in the cursor, you can capture the array and the size when creating
>> it instead of capturing a reference to the enclosing class (XArrayList.this),
>> it should be a little more efficient.
>> I believe you can also remove the try/catch + rethrow and use Objects.checkIndex
>> instead.
> Unless the VM can eliminate the checks the implicit array range check
> should be cheaper/free.
> Or I misunderstand how try/catch is implemented by the vm.

yes, i hope the range check to be fully removed.

> 
>>
>> If everything goes right, it should be has efficient as doing a for loop on the
>> array.
> Yep, that's the idea.
> 
> The cost avoidance of not doing allocation is hard to measure.

especially when the escape analysis works

> 
> In some previous experiements, the extra data that had to be moved around
> wiped out the savings by not having an identity object.

yes, when the cost of copy in a field or in an array is greater than the cost of dereferencing a pointer but here everything should be on the stack, so no trade-of.

> 
> I've looked at the code with JMH and perfasm and
> I'll be looking more closely at the performance and any help is appreciated.


Here my implementation
  https://github.com/forax/valuetype-lworld/blob/master/src/main/java/fr.umlv.valuetype/fr/umlv/valuetype/xlist/XArrayList.java#L1130
BTW, i believe your implementation has a bug, the index can overflow in advance().

with mostly the same test, i use microseconds so the results are more readable and a 3 seconds duration to have more stable results
  https://github.com/forax/valuetype-lworld/blob/master/src/test/java/fr.umlv.valuetype/fr/umlv/valuetype/perf/XArrayListCursorBenchMark.java#L21

Cursors are now faster than iterators and a loop + get().

Benchmark                                        (size)  Mode  Cnt    Score   Error  Units
XArrayListCursorBenchMark.getViaArray            100000  avgt    5  345.798 ? 3.048  us/op
XArrayListCursorBenchMark.getViaCursorForLoop    100000  avgt    5  278.712 ? 2.501  us/op
XArrayListCursorBenchMark.getViaCursorWhileLoop  100000  avgt    5  278.281 ? 3.816  us/op
XArrayListCursorBenchMark.getViaIterator         100000  avgt    5  323.989 ? 4.374  us/op
XArrayListCursorBenchMark.getViaIteratorCurs     100000  avgt    5  312.738 ? 1.848  us/op

> 
> Thanks, Roger
> 

cheers,
R?mi

>>
>> regards,
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Roger Riggs" 
>>> ?: "valhalla-dev" 
>>> Envoy?: Jeudi 26 Mars 2020 18:14:10
>>> Objet: [lworld] RFR: Prototype inline cursors for List
>>> Implementation of Cursors and jmh tests comparing
>>> typical List traversal via direct index, iterator,
>>> inline cursor, and an iterator implemented on top of cursor.
>>>
>>> Sample results:
>>>
>>>                                    (size)  Mode  Cnt       Score       Error  Units
>>> XArrayListCursorTest.getViaArray            100000  avgt    5  507793.484
>>> 7086.038  ns/op
>>> XArrayListCursorTest.getViaCursorForLoop    100000  avgt    5  656461.958
>>> 52488.547  ns/op
>>> XArrayListCursorTest.getViaCursorWhileLoop  100000  avgt    5  641963.323
>>> 32219.409  ns/op
>>> XArrayListCursorTest.getViaIterator         100000  avgt    5  558863.817
>>> 23539.256  ns/op
>>> XArrayListCursorTest.getViaIteratorCurs     100000  avgt    5  733161.466
>>> 33721.881  ns/op
>>>
>>> -------------
>>>
>>> Commit messages:
>>> - Prototype inline cursors for List
>>>
>>> Changes: https://git.openjdk.java.net/valhalla/pull/5/files
>>> Webrev: https://webrevs.openjdk.java.net/valhalla/5/webrev.00
>>>   Stats: 2139 lines in 3 files changed: 2139 ins; 0 del; 0 mod
>>>   Patch: https://git.openjdk.java.net/valhalla/pull/5.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/valhalla pull/5/head:pull/5
>>>
> >> PR: https://git.openjdk.java.net/valhalla/pull/5


From Roger.Riggs at oracle.com  Thu Mar 26 20:14:43 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 26 Mar 2020 16:14:43 -0400
Subject: [lworld] RFR: Prototype inline cursors for List
In-Reply-To: <1978750245.805863.1585251502717.JavaMail.zimbra@u-pem.fr>
References: 
 <1955576905.770911.1585244917162.JavaMail.zimbra@u-pem.fr>
 
 <1978750245.805863.1585251502717.JavaMail.zimbra@u-pem.fr>
Message-ID: <7fb84e42-0f1e-87c1-8d3b-018b944a9149@oracle.com>

Hi Remi,

yes, with those modifications its faster, but its not a Cursor for ArrayList
since CME is possible and not checked.
That would be appropriate for CopyOnWriteArraylist for example.

We also have a chance to create new implementations of List, etc.

I do want to understand where the pitfalls are when attempting
to improve implementations by replacing with inline classes.

On 3/26/20 3:38 PM, Remi Forax wrote:
> ----- Mail original -----
>> De: "Roger Riggs" 
>> ?: "valhalla-dev" 
>> Envoy?: Jeudi 26 Mars 2020 19:14:54
>> Objet: Re: [lworld] RFR: Prototype inline cursors for List
>> Hi Remi,
> Hi Roger,
>
>> On 3/26/20 1:48 PM, Remi Forax wrote:
>>> Hi Roger,
>>> I think implementing remove() on a cursor is a bad idea, since we have
>>> introduced Collection.removeIf() in 8 the main use case of remove() has
>>> disappeared and it's still implemented by Iterator if someone really want it.
>> Possibly, I was trying out what it takes for parity with Iterator.
>>> In term of performance, it makes a huge difference because you can now implement
>>> a snapshot at the beginning semantics, you don't have to be aware if the
>>> XArrayList changes and you don't have to propagate back the structural change
>>> done by remove(), so basically you can avoid the check for
>>> ConcurrentModification.
>> Yes simplifying the semantics would help, but that would not be an
>> ArrayList but something else.
>>
>> Part of the exercise was to see where inline classes can subsitute for
>> (assumed) more expensive identity classes.
>>
>>> With that, in the cursor, you can capture the array and the size when creating
>>> it instead of capturing a reference to the enclosing class (XArrayList.this),
>>> it should be a little more efficient.
>>> I believe you can also remove the try/catch + rethrow and use Objects.checkIndex
>>> instead.
>> Unless the VM can eliminate the checks the implicit array range check
>> should be cheaper/free.
>> Or I misunderstand how try/catch is implemented by the vm.
> yes, i hope the range check to be fully removed.
>
>>> If everything goes right, it should be has efficient as doing a for loop on the
>>> array.
>> Yep, that's the idea.
>>
>> The cost avoidance of not doing allocation is hard to measure.
> especially when the escape analysis works
>
>> In some previous experiements, the extra data that had to be moved around
>> wiped out the savings by not having an identity object.
> yes, when the cost of copy in a field or in an array is greater than the cost of dereferencing a pointer but here everything should be on the stack, so no trade-of.
>
>> I've looked at the code with JMH and perfasm and
>> I'll be looking more closely at the performance and any help is appreciated.
>
> Here my implementation
>    https://urldefense.com/v3/__https://github.com/forax/valuetype-lworld/blob/master/src/main/java/fr.umlv.valuetype/fr/umlv/valuetype/xlist/XArrayList.java*L1130__;Iw!!GqivPVa7Brio!KDKclikzivMcFelPyi433ivEn2MsWszmcVnYc16HMeRowkPFjlf386atqiTjAFWU$
> BTW, i believe your implementation has a bug, the index can overflow in advance().
That was intentional, since anything >= size is out of range anyway
and it has to be checked in get().
It wasn't worth an extra check.
>
> with mostly the same test, i use microseconds so the results are more readable and a 3 seconds duration to have more stable results
>    https://urldefense.com/v3/__https://github.com/forax/valuetype-lworld/blob/master/src/test/java/fr.umlv.valuetype/fr/umlv/valuetype/perf/XArrayListCursorBenchMark.java*L21__;Iw!!GqivPVa7Brio!KDKclikzivMcFelPyi433ivEn2MsWszmcVnYc16HMeRowkPFjlf386atqpU5B1iE$
>
> Cursors are now faster than iterators and a loop + get().
>
> Benchmark                                        (size)  Mode  Cnt    Score   Error  Units
> XArrayListCursorBenchMark.getViaArray            100000  avgt    5  345.798 ? 3.048  us/op
> XArrayListCursorBenchMark.getViaCursorForLoop    100000  avgt    5  278.712 ? 2.501  us/op
> XArrayListCursorBenchMark.getViaCursorWhileLoop  100000  avgt    5  278.281 ? 3.816  us/op
> XArrayListCursorBenchMark.getViaIterator         100000  avgt    5  323.989 ? 4.374  us/op
> XArrayListCursorBenchMark.getViaIteratorCurs     100000  avgt    5  312.738 ? 1.848  us/op

Good.

Thanks, Roger




From sergey.kuksenko at oracle.com  Thu Mar 26 20:37:20 2020
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Thu, 26 Mar 2020 13:37:20 -0700
Subject: [lworld] RFR: Prototype inline cursors for List
In-Reply-To: <36ae35d3-0296-e5c1-e0df-5f21cfd7901f@oracle.com>
References: 
 <36ae35d3-0296-e5c1-e0df-5f21cfd7901f@oracle.com>
Message-ID: <82dd9ee0-1243-76c8-e559-97fc27559798@oracle.com>

It won't work for ArrayList.

I told about that on Valhalla meeting (half year ago) and showed it's in 
my presentation about Valhalla performance 
(http://cr.openjdk.java.net/~skuksenko/valhalla/talk/vp.pdf, slides 68-75).

There is no difference cost between memory access to stack and heap. You 
won't get performance benefits on any range checks. Iterator/Cursor 
memory allocation itself is very cheap.

The only place where it may have significant effect (and it has) is GC 
write barriers.? Simple not-tuned Cursor for HashMap give +40% boost. If 
we want to see performance difference for Cursor we need an Iterator 
where Iterator's state contains references and these references should 
be updated on each "next()" invocation. ArrayList needs only update int 
field - no GC barriers.

My raw experiments were published in last August 
http://cr.openjdk.java.net/~skuksenko/valhalla/playground/.

It's still not enough to observe performance improvement on 
microbenchmarks. HotSpot is really good at 
Iterators-inside-microbenchmarks scalarization. Iterator should be 
forced DO NOT to scalarize the iterator. The simplest way to do it:

     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
     private static Iterator hide(Iterator it) {
         return it;
     }
         
  @Benchmark
     public int sumIteratorHidden() {
         int s = 0;
         for (Iterator iterator = hide(map.keyIterator()); iterator.hasNext(); ) {
             s += iterator.next();
         }
         return s;
     }


Minor note: Don't run it with ZGC. ZGC has no write barriers. Default G1 
is the best option due to highest cost of write barriers. ParallelGC 
write barriers has much less cost than G1 and Cursor still shows 
performance boost on ParallelGC, but much less than on G1.


On 3/26/20 10:45 AM, Brian Goetz wrote:
> These don't look so good!? I suspect that the Iterator is performing 
> so well because it's getting good EA, but not sure why cursors aren't 
> doing better?? Guess we'll have to dig into the generated code....
>
> On 3/26/2020 1:14 PM, Roger Riggs wrote:
>> Implementation of Cursors and jmh tests comparing
>> typical List traversal via direct index, iterator,
>> inline cursor, and an iterator implemented on top of cursor.
>>
>> Sample results:
>>
>> ??????????????????????????????????? (size)? Mode? Cnt Score?????? 
>> Error? Units
>> XArrayListCursorTest.getViaArray??????????? 100000? avgt??? 5 
>> 507793.484? 7086.038? ns/op
>> XArrayListCursorTest.getViaCursorForLoop??? 100000? avgt??? 5 
>> 656461.958? 52488.547? ns/op
>> XArrayListCursorTest.getViaCursorWhileLoop? 100000? avgt??? 5 
>> 641963.323? 32219.409? ns/op
>> XArrayListCursorTest.getViaIterator???????? 100000? avgt??? 5 
>> 558863.817? 23539.256? ns/op
>> XArrayListCursorTest.getViaIteratorCurs???? 100000? avgt??? 5 
>> 733161.466? 33721.881? ns/op
>>
>> -------------
>>
>> Commit messages:
>> ? - Prototype inline cursors for List
>>
>> Changes: https://git.openjdk.java.net/valhalla/pull/5/files
>> ? Webrev: https://webrevs.openjdk.java.net/valhalla/5/webrev.00
>> ?? Stats: 2139 lines in 3 files changed: 2139 ins; 0 del; 0 mod
>> ?? Patch: https://git.openjdk.java.net/valhalla/pull/5.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/valhalla 
>> pull/5/head:pull/5
>>
>> PR: https://git.openjdk.java.net/valhalla/pull/5
>


From forax at univ-mlv.fr  Thu Mar 26 20:57:33 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 26 Mar 2020 21:57:33 +0100 (CET)
Subject: [lworld] RFR: Prototype inline cursors for List
In-Reply-To: <7fb84e42-0f1e-87c1-8d3b-018b944a9149@oracle.com>
References: 
 <1955576905.770911.1585244917162.JavaMail.zimbra@u-pem.fr>
 
 <1978750245.805863.1585251502717.JavaMail.zimbra@u-pem.fr>
 <7fb84e42-0f1e-87c1-8d3b-018b944a9149@oracle.com>
Message-ID: <1406476194.821888.1585256253333.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Roger Riggs" 
> ?: "Remi Forax" 
> Cc: "valhalla-dev" 
> Envoy?: Jeudi 26 Mars 2020 21:14:43
> Objet: Re: [lworld] RFR: Prototype inline cursors for List

> Hi Remi,
> 
> yes, with those modifications its faster, but its not a Cursor for ArrayList
> since CME is possible and not checked.
> That would be appropriate for CopyOnWriteArraylist for example.

Or document that you may seen null when you iterate using a Cursor.

Another possible more heavy lifting isto  change the implementation of ArrayList to have all removes + add at the beginning (add(int, E)) to create a new array.
(having a flag that say if at least one iterator was spawn may alleviate a little bit the pain).
But i think it defeats the diminish the appeal of ArrayList as being the go to, general purpose list.

> 
> We also have a chance to create new implementations of List, etc.
> 
> I do want to understand where the pitfalls are when attempting
> to improve implementations by replacing with inline classes.

the problem is that reading modCount is what's make the implementation slow, i.e. as slow as the iterator when EA works.

R?mi 

> 
> On 3/26/20 3:38 PM, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "Roger Riggs" 
>>> ?: "valhalla-dev" 
>>> Envoy?: Jeudi 26 Mars 2020 19:14:54
>>> Objet: Re: [lworld] RFR: Prototype inline cursors for List
>>> Hi Remi,
>> Hi Roger,
>>
>>> On 3/26/20 1:48 PM, Remi Forax wrote:
>>>> Hi Roger,
>>>> I think implementing remove() on a cursor is a bad idea, since we have
>>>> introduced Collection.removeIf() in 8 the main use case of remove() has
>>>> disappeared and it's still implemented by Iterator if someone really want it.
>>> Possibly, I was trying out what it takes for parity with Iterator.
>>>> In term of performance, it makes a huge difference because you can now implement
>>>> a snapshot at the beginning semantics, you don't have to be aware if the
>>>> XArrayList changes and you don't have to propagate back the structural change
>>>> done by remove(), so basically you can avoid the check for
>>>> ConcurrentModification.
>>> Yes simplifying the semantics would help, but that would not be an
>>> ArrayList but something else.
>>>
>>> Part of the exercise was to see where inline classes can subsitute for
>>> (assumed) more expensive identity classes.
>>>
>>>> With that, in the cursor, you can capture the array and the size when creating
>>>> it instead of capturing a reference to the enclosing class (XArrayList.this), 
>>>> it should be a little more efficient.
>>>> I believe you can also remove the try/catch + rethrow and use Objects.checkIndex
>>>> instead.
>>> Unless the VM can eliminate the checks the implicit array range check
>>> should be cheaper/free.
>>> Or I misunderstand how try/catch is implemented by the vm.
>> yes, i hope the range check to be fully removed.
>>
>>>> If everything goes right, it should be has efficient as doing a for loop on the
>>>> array.
>>> Yep, that's the idea.
>>>
>>> The cost avoidance of not doing allocation is hard to measure.
>> especially when the escape analysis works
>>
>>> In some previous experiements, the extra data that had to be moved around
>>> wiped out the savings by not having an identity object.
>> yes, when the cost of copy in a field or in an array is greater than the cost of
>> dereferencing a pointer but here everything should be on the stack, so no
>> trade-of.
>>
>>> I've looked at the code with JMH and perfasm and
>>> I'll be looking more closely at the performance and any help is appreciated.
>>
>> Here my implementation
>>    https://urldefense.com/v3/__https://github.com/forax/valuetype-lworld/blob/master/src/main/java/fr.umlv.valuetype/fr/umlv/valuetype/xlist/XArrayList.java*L1130__;Iw!!GqivPVa7Brio!KDKclikzivMcFelPyi433ivEn2MsWszmcVnYc16HMeRowkPFjlf386atqiTjAFWU$
>> BTW, i believe your implementation has a bug, the index can overflow in
>> advance().
> That was intentional, since anything >= size is out of range anyway
> and it has to be checked in get().
> It wasn't worth an extra check.
>>
>> with mostly the same test, i use microseconds so the results are more readable
>> and a 3 seconds duration to have more stable results
>>    https://urldefense.com/v3/__https://github.com/forax/valuetype-lworld/blob/master/src/test/java/fr.umlv.valuetype/fr/umlv/valuetype/perf/XArrayListCursorBenchMark.java*L21__;Iw!!GqivPVa7Brio!KDKclikzivMcFelPyi433ivEn2MsWszmcVnYc16HMeRowkPFjlf386atqpU5B1iE$
>>
>> Cursors are now faster than iterators and a loop + get().
>>
>> Benchmark                                        (size)  Mode  Cnt    Score
>> Error  Units
>> XArrayListCursorBenchMark.getViaArray            100000  avgt    5  345.798 ?
>> 3.048  us/op
>> XArrayListCursorBenchMark.getViaCursorForLoop    100000  avgt    5  278.712 ?
>> 2.501  us/op
>> XArrayListCursorBenchMark.getViaCursorWhileLoop  100000  avgt    5  278.281 ?
>> 3.816  us/op
>> XArrayListCursorBenchMark.getViaIterator         100000  avgt    5  323.989 ?
>> 4.374  us/op
>> XArrayListCursorBenchMark.getViaIteratorCurs     100000  avgt    5  312.738 ?
>> 1.848  us/op
> 
> Good.
> 
> Thanks, Roger


From mandy.chung at oracle.com  Thu Mar 26 21:06:48 2020
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 26 Mar 2020 21:06:48 +0000
Subject: hg: valhalla/valhalla: [nestmates] add more tests to verify unloading
 of hidden classes
Message-ID: <202003262106.02QL6m26029546@aojmv0008.oracle.com>

Changeset: 580f082b9fc1
Author:    mchung
Date:      2020-03-26 14:06 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/580f082b9fc1

[nestmates] add more tests to verify unloading of hidden classes

! test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java



From david.holmes at oracle.com  Thu Mar 26 21:53:18 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Mar 2020 07:53:18 +1000
Subject: RFR: 8241562: Rework nest host resolution/validation error support
In-Reply-To: <6800fc4c-b940-2a87-cca9-7122129a6fce@oracle.com>
References: 
 <6800fc4c-b940-2a87-cca9-7122129a6fce@oracle.com>
Message-ID: 

Thanks Mandy.

David

On 27/03/2020 2:22 am, Mandy Chung wrote:
> Looks good.? I like this approach too.
> 
> Mandy
> 
> On 3/26/20 2:19 AM, David Holmes wrote:
>> webrev: http://cr.openjdk.java.net/~dholmes/8241562/webrev/
>>
>> This is (hopefully) the last pre-integration cleanup for JEP-371: 
>> Hidden classes.
>>
>> Rather than store the error message in a field of InstanceKlass we 
>> piggy-back onto the existing ResolutionErrorTable logic and add a new 
>> field to the ResolutionErrorEntry.
>>
>> Also factored out the complex error message logic in linkResolver 
>> methods.
>>
>> There's one code path in free_entry not covered by any existing 
>> testing so I will look at developing a test for that. Otherwise all 
>> new code paths have been tested.
>>
>> Thanks,
>> David
> 


From david.holmes at oracle.com  Thu Mar 26 22:23:55 2020
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Thu, 26 Mar 2020 22:23:55 +0000
Subject: hg: valhalla/valhalla: 8241562: Rework nest host
 resolution/validation error support
Message-ID: <202003262223.02QMNuqG010837@aojmv0008.oracle.com>

Changeset: 33727eb2c5b0
Author:    dholmes
Date:      2020-03-26 18:23 -0400
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/33727eb2c5b0

8241562: Rework nest host resolution/validation error support
Reviewed-by: lfoltan, hseigel, mchung, coleenp

! src/hotspot/share/classfile/resolutionErrors.cpp
! src/hotspot/share/classfile/resolutionErrors.hpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp



From mandy.chung at oracle.com  Thu Mar 26 23:57:39 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Mar 2020 16:57:39 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
Message-ID: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>

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 jan.lahoda at oracle.com  Fri Mar 27 11:31:33 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 27 Mar 2020 12:31:33 +0100
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,

Regarding the javac changes - should those be switched on/off depending 
the Target? Or, if one compiles with e.g. --release 14, will the newly 
generated output still work on JDK 14?

Jan

On 27. 03. 20 0:57, 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 forax at univ-mlv.fr  Fri Mar 27 12:00:06 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 27 Mar 2020 13:00:06 +0100 (CET)
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: <1271059704.1214239.1585310406005.JavaMail.zimbra@u-pem.fr>

Hi Mandy,
in ReflectionFactory, why in the case of a constructor the check to the anonymous class is removed ?

in BytecodeGenerator, the comment "// bootstrapping issue if using condy"
can be promoted on top of clinit, because i ask myself the same question seeing a static block was generated

in AbstractValidatingLambdaMetafactory.java, the field caller is not used after all ?

regards,
R?mi

----- Mail original -----
> De: "mandy chung" 
> ?: "valhalla-dev" , "core-libs-dev" ,
> "serviceability-dev" , "hotspot-dev" 
> Envoy?: Vendredi 27 Mars 2020 00:57:39
> Objet: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

> 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 rwestrel at redhat.com  Fri Mar 27 12:22:55 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 27 Mar 2020 13:22:55 +0100
Subject: [lworld] RFR: 8241533: [lworld] PhaseMacroExpand::migrate_outs
 should be replaced =?utf-8?Q?b=E2=80=A6?=
In-Reply-To: 
References: 
Message-ID: <87pncydm1s.fsf@redhat.com>


>  Webrev: https://webrevs.openjdk.java.net/valhalla/4/webrev.00

Looks good to me.

Roland.



From tobias.hartmann at oracle.com  Fri Mar 27 12:35:24 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 27 Mar 2020 13:35:24 +0100
Subject: =?UTF-8?Q?Re=3a_=5blworld=5d_RFR=3a_8241533=3a_=5blworld=5d_PhaseMa?=
 =?UTF-8?Q?croExpand=3a=3amigrate=5fouts_should_be_replaced_b=e2=80=a6?=
In-Reply-To: <87pncydm1s.fsf@redhat.com>
References: 
 <87pncydm1s.fsf@redhat.com>
Message-ID: <3eb6e334-e454-f5c5-16cd-fa143f70d26b@oracle.com>

Thanks Roland!

Best regards,
Tobias

On 27.03.20 13:22, Roland Westrelin wrote:
> 
>>  Webrev: https://webrevs.openjdk.java.net/valhalla/4/webrev.00
> 
> Looks good to me.
> 
> Roland.
> 


From thartmann at openjdk.java.net  Fri Mar 27 12:38:56 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 27 Mar 2020 12:38:56 GMT
Subject: [Integrated] [lworld] RFR: 8241533: [lworld]
 PhaseMacroExpand::migrate_outs should be replaced =?UTF-8?B?YuKApg==?=
In-Reply-To: 
References: 
Message-ID: <628308e2-0cce-47ff-9efc-6ae14528da02@openjdk.org>

Changeset: 78b0ffda
Author:    Tobias Hartmann 
Date:      2020-03-27 12:37:42 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/78b0ffda

8241533: [lworld] PhaseMacroExpand::migrate_outs should be replaced b?

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


From thartmann at openjdk.java.net  Fri Mar 27 13:48:59 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 27 Mar 2020 13:48:59 GMT
Subject: [lworld] RFR: 8235753: [lworld] Handle deoptimization when buffering
 scalarized inline type args in C1
Message-ID: 

When calling from C2 to C1 compiled code (i.e., no adapter in between) we need to buffer scalarized value type
arguments in the C1 compiled entry point of the method (because C1 requires an oop). To do that, we might need to call
into the runtime and that call might trigger deoptimization of the C1 compiled caller. That's a problem because the
arguments are still scalarized and neither the deopt code nor the interpreter know how to handle that state. It's not a
problem for all the other cases where buffering is necessary because it's either in the c2i adapter or C2 compiled code
where we can handle this already.

After trying all my ideas listed in JBS, I've ended up with the following solution:
When deoptimization of a C1 frame that is currently in a runtime call to buffer_value_args_xxx is performed, don't
patch the return address but only set the orig_pc in the frame (see changes to frame::deoptimize). This delays
deoptimization until we enter the method body where a new runtime check added in LIRGenerator::do_Base will detect the
pending deoptimization by checking the original_pc and jump to a deopt stub. This requires initializing the original_pc
to zero at the beginning of the method entry (because it usually contains garbage).

The patch also fixes the following problems:
- Stack banging code is accidentally skipped when entering the C1 method through a scalarized entry
- A clinit_barrier is never needed if the method is non-static
- Refactoring, conversion of some checks to asserts, better comments

Thanks,
Tobias

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

Commit messages:
 - 8235753: [lworld] Handle deoptimization when buffering scalarized inline type args in C1

Changes: https://git.openjdk.java.net/valhalla/pull/6/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/6/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8235753
  Stats: 215 lines in 13 files changed: 110 ins; 41 del; 64 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/6/head:pull/6

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


From mandy.chung at oracle.com  Fri Mar 27 15:50:55 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Mar 2020 08:50:55 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <1271059704.1214239.1585310406005.JavaMail.zimbra@u-pem.fr>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1271059704.1214239.1585310406005.JavaMail.zimbra@u-pem.fr>
Message-ID: 

On 3/27/20 5:00 AM, Remi Forax wrote:
> Hi Mandy,
> in ReflectionFactory, why in the case of a constructor the check to the anonymous class is removed ?

Good catch.? Fixed
>
> in BytecodeGenerator, the comment "// bootstrapping issue if using condy"
> can be promoted on top of clinit, because i ask myself the same question seeing a static block was generated

OK, that's clearer.
>
> in AbstractValidatingLambdaMetafactory.java, the field caller is not used after all ?

Thanks.? Removed.? It was left behind from an early prototype.

Below is the patch.? I will send out a new webrev and delta webrev in 
the next revision.

thanks
Mandy

diff --git 
a/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java 
b/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
--- 
a/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
+++ 
b/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
@@ -51,7 +51,6 @@
 ????? *???????? System.out.printf(">>> %s\n", iii.foo(44));
 ????? * }}
 ????? */
-??? final MethodHandles.Lookup caller;
 ???? final Class targetClass;?????????????? // The class calling the 
meta-factory via invokedynamic "class X"
 ???? final MethodType invokedType;???????????? // The type of the 
invoked method "(CC)II"
 ???? final Class samBase;?????????????????? // The type of the 
returned instance "interface JJ"
@@ -121,7 +120,6 @@
 ???????????????????? "Invalid caller: %s",
 ???????????????????? caller.lookupClass().getName()));
 ???????? }
-??????? this.caller = caller;
 ???????? this.targetClass = caller.lookupClass();
 ???????? this.invokedType = invokedType;

diff --git 
a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java 
b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
--- 
a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
+++ 
b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
@@ -363,6 +363,10 @@
 ???????? clinit(cw, className(), classData);
 ???? }

+??? /*
+???? *  to initialize the static final fields with the live 
class data
+???? * LambdaForms can't use condy due to bootstrapping issue.
+???? */
 ???? static void clinit(ClassWriter cw, String className, 
List classData) {
 ???????? if (classData.isEmpty())
 ???????????? return;
@@ -375,7 +379,6 @@

 ???????? MethodVisitor mv = cw.visitMethod(Opcodes.ACC_STATIC, 
"", "()V", null, null);
 ???????? mv.visitCode();
-??????? // bootstrapping issue if using condy
 ???????? mv.visitLdcInsn(Type.getType("L" + className + ";"));
 ???????? mv.visitMethodInsn(Opcodes.INVOKESTATIC, 
"java/lang/invoke/MethodHandleNatives",
 ??????????????????????????? "classData", 
"(Ljava/lang/Class;)Ljava/lang/Object;", false);
diff --git 
a/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java 
b/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
--- 
a/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
+++ 
b/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
@@ -245,7 +245,8 @@
 ???????????? return new BootstrapConstructorAccessorImpl(c);
 ???????? }

-??????? if (noInflation && !c.getDeclaringClass().isHiddenClass()) {
+??????? if (noInflation && !c.getDeclaringClass().isHiddenClass()
+??????????????? && 
!ReflectUtil.isVMAnonymousClass(c.getDeclaringClass())) {
 ???????????? return new MethodAccessorGenerator().
 ???????????????? generateConstructor(c.getDeclaringClass(),
 ???????????????????????????????????? c.getParameterTypes(),


From forax at univ-mlv.fr  Fri Mar 27 15:54:37 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 27 Mar 2020 16:54:37 +0100 (CET)
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1271059704.1214239.1585310406005.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <387396409.1414184.1585324477993.JavaMail.zimbra@u-pem.fr>

> De: "mandy chung" 
> ?: "Remi Forax" 
> Cc: "valhalla-dev" , "core-libs-dev"
> , "serviceability-dev"
> , "hotspot-dev"
> 
> Envoy?: Vendredi 27 Mars 2020 16:50:55
> Objet: Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

> On 3/27/20 5:00 AM, Remi Forax wrote:

>> Hi Mandy,
>> in ReflectionFactory, why in the case of a constructor the check to the
>> anonymous class is removed ?

> Good catch. Fixed

>> in BytecodeGenerator, the comment "// bootstrapping issue if using condy"
>> can be promoted on top of clinit, because i ask myself the same question seeing
>> a static block was generated

> OK, that's clearer.

>> in AbstractValidatingLambdaMetafactory.java, the field caller is not used after
>> all ?

> Thanks. Removed. It was left behind from an early prototype.

> Below is the patch. I will send out a new webrev and delta webrev in the next
> revision.
Thanks Mandy, 
Looks good. 

R?mi 

> thanks
> Mandy

> diff --git
> a/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> b/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> ---
> a/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> +++
> b/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> @@ -51,7 +51,6 @@
> * System.out.printf(">>> %s\n", iii.foo(44));
> * }}
> */
> - final MethodHandles.Lookup caller;
> final Class targetClass; // The class calling the meta-factory via
> invokedynamic "class X"
> final MethodType invokedType; // The type of the invoked method "(CC)II"
> final Class samBase; // The type of the returned instance "interface JJ"
> @@ -121,7 +120,6 @@
> "Invalid caller: %s",
> caller.lookupClass().getName()));
> }
> - this.caller = caller;
> this.targetClass = caller.lookupClass();
> this.invokedType = invokedType;

> diff --git
> a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> --- a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> +++ b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> @@ -363,6 +363,10 @@
> clinit(cw, className(), classData);
> }

> + /*
> + *  to initialize the static final fields with the live class data
> + * LambdaForms can't use condy due to bootstrapping issue.
> + */
> static void clinit(ClassWriter cw, String className, List classData)
> {
> if (classData.isEmpty())
> return;
> @@ -375,7 +379,6 @@

> MethodVisitor mv = cw.visitMethod(Opcodes.ACC_STATIC, "", "()V", null,
> null);
> mv.visitCode();
> - // bootstrapping issue if using condy
> mv.visitLdcInsn(Type.getType("L" + className + ";"));
> mv.visitMethodInsn(Opcodes.INVOKESTATIC, "java/lang/invoke/MethodHandleNatives",
> "classData", "(Ljava/lang/Class;)Ljava/lang/Object;", false);
> diff --git
> a/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
> b/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
> --- a/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
> +++ b/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
> @@ -245,7 +245,8 @@
> return new BootstrapConstructorAccessorImpl(c);
> }

> - if (noInflation && !c.getDeclaringClass().isHiddenClass()) {
> + if (noInflation && !c.getDeclaringClass().isHiddenClass()
> + && !ReflectUtil.isVMAnonymousClass(c.getDeclaringClass())) {
> return new MethodAccessorGenerator().
> generateConstructor(c.getDeclaringClass(),
> c.getParameterTypes(),


From mandy.chung at oracle.com  Fri Mar 27 16:13:50 2020
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 27 Mar 2020 16:13:50 +0000
Subject: hg: valhalla/valhalla: 2 new changesets
Message-ID: <202003271613.02RGDp3M002409@aojmv0008.oracle.com>

Changeset: e2fc6d1c5cbd
Author:    mchung
Date:      2020-03-27 09:12 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/e2fc6d1c5cbd

[nestmates] small fixes per Remi's review feedback

! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java

Changeset: b1e8e44590a1
Author:    mchung
Date:      2020-03-27 09:13 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/b1e8e44590a1

[nestmates] cleanup merge issue

! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/prims/jvm.cpp
! test/hotspot/jtreg/ProblemList.txt



From mandy.chung at oracle.com  Fri Mar 27 16:29:46 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Mar 2020 09:29:46 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
Message-ID: <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>

Hi Jan,

Good point.? The javac change only applies to JDK 15 and later and the 
lambda proxy class is not a nestmate when running on JDK 14 or earlier.

I probably need the help from langtools team to fix this.? I'll give it 
a try.

Mandy

On 3/27/20 4:31 AM, Jan Lahoda wrote:
> Hi Mandy,
>
> Regarding the javac changes - should those be switched on/off 
> depending the Target? Or, if one compiles with e.g. --release 14, will 
> the newly generated output still work on JDK 14?
>
> Jan
>
> On 27. 03. 20 0:57, 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 Mar 27 17:42:45 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Mar 2020 10:42:45 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <1271059704.1214239.1585310406005.JavaMail.zimbra@u-pem.fr>
 
Message-ID: <97312304-17e1-0d49-efd6-4cc953cf66f5@oracle.com>



On 3/27/20 8:50 AM, Mandy Chung wrote:
>>
>> in AbstractValidatingLambdaMetafactory.java, the field caller is not 
>> used after all ?
In fact the caller is needed to call defineHiddenClass :-)

Mandy


From mandy.chung at oracle.com  Fri Mar 27 18:30:10 2020
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 27 Mar 2020 18:30:10 +0000
Subject: hg: valhalla/valhalla: [nestmates] revert change in
 AbstractValidatingLambdaMetafactory
Message-ID: <202003271830.02RIUAQR028757@aojmv0008.oracle.com>

Changeset: 89d3a7ce35a9
Author:    mchung
Date:      2020-03-27 11:26 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/89d3a7ce35a9

[nestmates] revert change in AbstractValidatingLambdaMetafactory

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



From harold.seigel at oracle.com  Fri Mar 27 18:51:59 2020
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Fri, 27 Mar 2020 18:51:59 +0000
Subject: hg: valhalla/valhalla: Summary: Change 'weak hidden' to just 'hidden'
 in dcmd and other small changes
Message-ID: <202003271851.02RIpxjG012253@aojmv0008.oracle.com>

Changeset: 24d50cf7519f
Author:    hseigel
Date:      2020-03-27 18:51 +0000
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/24d50cf7519f

Summary: Change 'weak hidden' to just 'hidden' in dcmd and other small changes
Reviewed-by: mchung

! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/klassFactory.hpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/memory/metaspace/printCLDMetaspaceInfoClosure.cpp
! src/hotspot/share/prims/jvm.cpp
! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java
! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java



From paul.sandoz at oracle.com  Fri Mar 27 18:59:10 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Mar 2020 11:59: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: <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com>

Hi Mandy,

Very thorough, bravo!

Minor suggestions below.

Paul.

MethodHandleNatives.java
?

 142 
 143         /**
 144          * Flags for Lookup.ClassOptions
 145          */
 146         static final int
 147             NESTMATE_CLASS            = 0x00000001,
 148             HIDDEN_CLASS              = 0x00000002,
 149             STRONG_LOADER_LINK        = 0x00000004,
 150             ACCESS_VM_ANNOTATIONS     = 0x00000008;
 151     }
 

Suggest you add a comment to keep the values in sync with the VM component.


MethodHandles.java
?

1786          * (Given the {@code Lookup} object returned this method, its lookup class
1787          * is a {@code Class} object for which {@link Class#getName()} returns a string
1788          * that is not a binary name.)

?
(The {@code Lookup} object returned from this method has a lookup class that is 
a {@code Class} object whose {@link Class#getName()} returns a string
that is not a binary name.)
?


1902             Set opts = options.length > 0 ? Set.of(options) : Set.of();

You can just do:

  Set opts = Set.of(options)

And/or inline it into the subsequent method call.  The implementation of Set.of checks the array length.


2001         ClassDefiner makeHiddenClassDefiner(byte[] bytes,

I think you can telescope the methods for non-name and name accepting since IIUC the name is derived from the byte[].  Thereby you can remove some code duplication. i.e. pull ClassDefiner.className out from ClassDefiner and place the logic in the factory methods.  Alternative push the factory methods into ClassDefiner to keep all the logic together.



3797         public enum ClassOption {

Shuffle up to be closer to the defineHiddenClass


3798             /**
3799              * This class option specifies the hidden class be added to
3800              * {@linkplain Class#getNestHost nest} of a lookup class as
3801              * a nestmate.

Suggest:

"This class option specifies the hidden class ? -> ?Specifies that a hidden class 


3812              * This class option specifies the hidden class to have a strong

?Specifies that a hidden class have a ?"


3813              * relationship with the class loader marked as its defining loader,
3814              * as a normal class or interface has with its own defining loader.
3815              * This means that the hidden class may be unloaded if and only if
3816              * its defining loader is not reachable and thus may be reclaimed
3817              * by a garbage collector (JLS 12.7).


StringConcatFactory.java
?

 861             // use of @ForceInline no longer has any effect

?

 862             mv.visitAnnotation("Ljdk/internal/vm/annotation/ForceInline;", true);
 863             mv.visitCode();





> On Mar 26, 2020, at 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
> 
> 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 Mar 27 20:18:07 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Mar 2020 13:18:07 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com>
Message-ID: 



On 3/27/20 11:59 AM, Paul Sandoz wrote:
> Hi Mandy,
>
> Very thorough, bravo!

Thanks.
> Minor suggestions below.
>
> Paul.
>
> MethodHandleNatives.java
> ?
>
>   142
>   143         /**
>   144          * Flags for Lookup.ClassOptions
>   145          */
>   146         static final int
>   147             NESTMATE_CLASS            = 0x00000001,
>   148             HIDDEN_CLASS              = 0x00000002,
>   149             STRONG_LOADER_LINK        = 0x00000004,
>   150             ACCESS_VM_ANNOTATIONS     = 0x00000008;
>   151     }
>   
>
> Suggest you add a comment to keep the values in sync with the VM component.

Already in the class spec of this Constants class.? The values of all 
constants defined in this Constants class are verified in sync with VM 
(see verifyConstants).

>
> MethodHandles.java
> ?
>
> 1786          * (Given the {@code Lookup} object returned this method, its lookup class
> 1787          * is a {@code Class} object for which {@link Class#getName()} returns a string
> 1788          * that is not a binary name.)
>
> ?
> (The {@code Lookup} object returned from this method has a lookup class that is
> a {@code Class} object whose {@link Class#getName()} returns a string
> that is not a binary name.)
> ?
>
>
> 1902             Set opts = options.length > 0 ? Set.of(options) : Set.of();
>
> You can just do:
>
>    Set opts = Set.of(options)
>
> And/or inline it into the subsequent method call.  The implementation of Set.of checks the array length.

Great to know.? Thanks.
>
> 2001         ClassDefiner makeHiddenClassDefiner(byte[] bytes,
>
> I think you can telescope the methods for non-name and name accepting since IIUC the name is derived from the byte[].  Thereby you can remove some code duplication. i.e. pull ClassDefiner.className out from ClassDefiner and place the logic in the factory methods.  Alternative push the factory methods into ClassDefiner to keep all the logic together.
>
Ok.? I will move the className out.
>
> 3797         public enum ClassOption {
>
> Shuffle up to be closer to the defineHiddenClass

Moved before defineHiddenClass.

>
> 3798             /**
> 3799              * This class option specifies the hidden class be added to
> 3800              * {@linkplain Class#getNestHost nest} of a lookup class as
> 3801              * a nestmate.
>
> Suggest:
>
> "This class option specifies the hidden class ? -> ?Specifies that a hidden class
>
> 3812              * This class option specifies the hidden class to have a strong
>
> ?Specifies that a hidden class have a ?"

Specifies that a hidden class has a...

>
> 3813              * relationship with the class loader marked as its defining loader,
> 3814              * as a normal class or interface has with its own defining loader.
> 3815              * This means that the hidden class may be unloaded if and only if
> 3816              * its defining loader is not reachable and thus may be reclaimed
> 3817              * by a garbage collector (JLS 12.7).
>
>
> StringConcatFactory.java
> ?
>
>   861             // use of @ForceInline no longer has any effect
>
> ?

Right, I should have explained this [1].

This @ForceInline is used by BytecodeStringBuilderStrategy that 
generates code to have the same StringBuilder chain javac would emit. It 
uses `@ForceInline` annotation which may probably be for performance.? 
It's believed people rarely uses this non-default strategy.? This patch 
changes StringConcatFactory to the standard defineHiddenClass method and 
hence `@ForceInline` has no effect in the generated class for this 
non-default strategy.? If it turns out to be an issue, then we will 
determine if it should enable the access to VM annotations (I doubt this 
is supported strategy).

[1] https://bugs.openjdk.java.net/browse/JDK-8241548


From vicente.romero at oracle.com  Fri Mar 27 21:15:29 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 27 Mar 2020 17:15:29 -0400
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
 <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
Message-ID: 

Hi Mandy,

The patch for nestmates [1] could be used as a reference. There a new 
method was added to class `com.sun.tools.javac.jvm.Target`, named: 
`hasNestmateAccess` which checks if a target is ready for nestmates or 
not. I think that you can follow a similar approach here.

Thanks,
Vicente

[1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7

On 3/27/20 12:29 PM, Mandy Chung wrote:
> Hi Jan,
>
> Good point.? The javac change only applies to JDK 15 and later and the 
> lambda proxy class is not a nestmate when running on JDK 14 or earlier.
>
> I probably need the help from langtools team to fix this.? I'll give 
> it a try.
>
> Mandy
>
> On 3/27/20 4:31 AM, Jan Lahoda wrote:
>> Hi Mandy,
>>
>> Regarding the javac changes - should those be switched on/off 
>> depending the Target? Or, if one compiles with e.g. --release 14, 
>> will the newly generated output still work on JDK 14?
>>
>> Jan
>>
>> On 27. 03. 20 0:57, 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 Mar 27 22:22:19 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Mar 2020 15:22:19 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com>
 
Message-ID: <41b99011-921a-9fc6-c738-98c47e9959c3@oracle.com>

Hi Paul,

This is the delta incorporating your comment:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-psandoz/

This patch also took Alex's comment to make it clear that the hidden 
class is the lookup class of the returned Lookup object and drops the 
sentence you commented on:

On 3/27/20 1:18 PM, Mandy Chung wrote:
>> MethodHandles.java
>> ?
>>
>> 1786????????? * (Given the {@code Lookup} object returned this 
>> method, its lookup class
>> 1787????????? * is a {@code Class} object for which {@link 
>> Class#getName()} returns a string
>> 1788????????? * that is not a binary name.)
>>
>> ?
>> (The {@code Lookup} object returned from this method has a lookup 
>> class that is
>> a {@code Class} object whose {@link Class#getName()} returns a string
>> that is not a binary name.)
>> ?


Mandy


From mandy.chung at oracle.com  Fri Mar 27 22:29:03 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Mar 2020 15:29:03 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
 <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
 
Message-ID: 

Hi Vicente,

hasNestmateAccess is about VM supports static nestmates on JDK release 
 >= 11.

However this is about javac --release 14 and the compiled classes may 
run on JDK 14 that lambda and string concat spin classes that are not 
nestmates. I have a patch with Jan's help:

http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html

(you can apply the above patch on valhalla repo "nestmates" branch)

About testing, I wanted to run BridgeMethodsForLambdaTest and 
TestLambdaBytecode test with --release 14 but it turns out not 
straight-forward.? Any help would be appreciated.

thanks
Mandy

On 3/27/20 2:15 PM, Vicente Romero wrote:
> Hi Mandy,
>
> The patch for nestmates [1] could be used as a reference. There a new 
> method was added to class `com.sun.tools.javac.jvm.Target`, named: 
> `hasNestmateAccess` which checks if a target is ready for nestmates or 
> not. I think that you can follow a similar approach here.
>
> Thanks,
> Vicente
>
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7
>
> On 3/27/20 12:29 PM, Mandy Chung wrote:
>> Hi Jan,
>>
>> Good point.? The javac change only applies to JDK 15 and later and 
>> the lambda proxy class is not a nestmate when running on JDK 14 or 
>> earlier.
>>
>> I probably need the help from langtools team to fix this.? I'll give 
>> it a try.
>>
>> Mandy
>>
>> On 3/27/20 4:31 AM, Jan Lahoda wrote:
>>> Hi Mandy,
>>>
>>> Regarding the javac changes - should those be switched on/off 
>>> depending the Target? Or, if one compiles with e.g. --release 14, 
>>> will the newly generated output still work on JDK 14?
>>>
>>> Jan
>>>
>>> On 27. 03. 20 0:57, 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 vicente.romero at oracle.com  Fri Mar 27 22:48:52 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 27 Mar 2020 18:48:52 -0400
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
 <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
 
 
Message-ID: <60348819-ace5-8e52-f1ff-5f9654c915e0@oracle.com>

Hi Mandy,

On 3/27/20 6:29 PM, Mandy Chung wrote:
> Hi Vicente,
>
> hasNestmateAccess is about VM supports static nestmates on JDK release 
> >= 11.

I was not suggesting the use of `hasNestmateAccess` but to follow the 
same approach which is adding a new method at class `Target` to check if 
the new goodies were in the given target
>
> However this is about javac --release 14 and the compiled classes may 
> run on JDK 14 that lambda and string concat spin classes that are not 
> nestmates. I have a patch with Jan's help:
>
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html

which is what the patch above is doing

>
> (you can apply the above patch on valhalla repo "nestmates" branch)
>
> About testing, I wanted to run BridgeMethodsForLambdaTest and 
> TestLambdaBytecode test with --release 14 but it turns out not 
> straight-forward.? Any help would be appreciated.
>
> thanks
> Mandy

Vicente
>
> On 3/27/20 2:15 PM, Vicente Romero wrote:
>> Hi Mandy,
>>
>> The patch for nestmates [1] could be used as a reference. There a new 
>> method was added to class `com.sun.tools.javac.jvm.Target`, named: 
>> `hasNestmateAccess` which checks if a target is ready for nestmates 
>> or not. I think that you can follow a similar approach here.
>>
>> Thanks,
>> Vicente
>>
>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7
>>
>> On 3/27/20 12:29 PM, Mandy Chung wrote:
>>> Hi Jan,
>>>
>>> Good point.? The javac change only applies to JDK 15 and later and 
>>> the lambda proxy class is not a nestmate when running on JDK 14 or 
>>> earlier.
>>>
>>> I probably need the help from langtools team to fix this. I'll give 
>>> it a try.
>>>
>>> Mandy
>>>
>>> On 3/27/20 4:31 AM, Jan Lahoda wrote:
>>>> Hi Mandy,
>>>>
>>>> Regarding the javac changes - should those be switched on/off 
>>>> depending the Target? Or, if one compiles with e.g. --release 14, 
>>>> will the newly generated output still work on JDK 14?
>>>>
>>>> Jan
>>>>
>>>> On 27. 03. 20 0:57, 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 david.holmes at oracle.com  Fri Mar 27 23:01:58 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 28 Mar 2020 09:01:58 +1000
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
 <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
 
 
Message-ID: <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com>

Hi Mandy,

On 28/03/2020 8:29 am, Mandy Chung wrote:
> Hi Vicente,
> 
> hasNestmateAccess is about VM supports static nestmates on JDK release 
>  >= 11.
> 
> However this is about javac --release 14 and the compiled classes may 
> run on JDK 14 that lambda and string concat spin classes that are not 
> nestmates. I have a patch with Jan's help:
> 
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html 

+             /**
+              * The VM does not support access across nested classes 
(8010319).
+              * Were that ever to change, this should be removed.
+              */
+             boolean isPrivateInOtherClass() {

I'm not at all sure what this means - access across different nests? 
(I'm not even sure what that means.)

Thanks,
David
-----

> 
> (you can apply the above patch on valhalla repo "nestmates" branch)
> 
> About testing, I wanted to run BridgeMethodsForLambdaTest and 
> TestLambdaBytecode test with --release 14 but it turns out not 
> straight-forward.? Any help would be appreciated.
> 
> thanks
> Mandy
> 
> On 3/27/20 2:15 PM, Vicente Romero wrote:
>> Hi Mandy,
>>
>> The patch for nestmates [1] could be used as a reference. There a new 
>> method was added to class `com.sun.tools.javac.jvm.Target`, named: 
>> `hasNestmateAccess` which checks if a target is ready for nestmates or 
>> not. I think that you can follow a similar approach here.
>>
>> Thanks,
>> Vicente
>>
>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7
>>
>> On 3/27/20 12:29 PM, Mandy Chung wrote:
>>> Hi Jan,
>>>
>>> Good point.? The javac change only applies to JDK 15 and later and 
>>> the lambda proxy class is not a nestmate when running on JDK 14 or 
>>> earlier.
>>>
>>> I probably need the help from langtools team to fix this.? I'll give 
>>> it a try.
>>>
>>> Mandy
>>>
>>> On 3/27/20 4:31 AM, Jan Lahoda wrote:
>>>> Hi Mandy,
>>>>
>>>> Regarding the javac changes - should those be switched on/off 
>>>> depending the Target? Or, if one compiles with e.g. --release 14, 
>>>> will the newly generated output still work on JDK 14?
>>>>
>>>> Jan
>>>>
>>>> On 27. 03. 20 0:57, 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 forax at univ-mlv.fr  Fri Mar 27 23:40:59 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 28 Mar 2020 00:40:59 +0100 (CET)
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
 <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
 
 
 <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com>
Message-ID: <405050984.1553152.1585352459094.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "David Holmes" 
> ?: "mandy chung" , "Vicente Romero" , "jan lahoda"
> 
> Cc: "serviceability-dev" , "hotspot-dev" ,
> "core-libs-dev" , "valhalla-dev" 
> Envoy?: Samedi 28 Mars 2020 00:01:58
> Objet: Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

> Hi Mandy,

Hi David,

> 
> On 28/03/2020 8:29 am, Mandy Chung wrote:
>> Hi Vicente,
>> 
>> hasNestmateAccess is about VM supports static nestmates on JDK release
>>  >= 11.
>> 
>> However this is about javac --release 14 and the compiled classes may
>> run on JDK 14 that lambda and string concat spin classes that are not
>> nestmates. I have a patch with Jan's help:
>> 
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html
> 
> +             /**
> +              * The VM does not support access across nested classes
> (8010319).
> +              * Were that ever to change, this should be removed.
> +              */
> +             boolean isPrivateInOtherClass() {
> 
> I'm not at all sure what this means - access across different nests?
> (I'm not even sure what that means.)

Access inside the same nest.
As you know, until now, a lambda proxy is a VM anonymous class that can only see the private fields of the class declaring the lambda (the host class) and not the private fields of a class of the nest (the enclosing classes in term of Java the language).

R?mi

> 
> Thanks,
> David
> -----
> 
>> 
>> (you can apply the above patch on valhalla repo "nestmates" branch)
>> 
>> About testing, I wanted to run BridgeMethodsForLambdaTest and
>> TestLambdaBytecode test with --release 14 but it turns out not
>> straight-forward.? Any help would be appreciated.
>> 
>> thanks
>> Mandy
>> 
>> On 3/27/20 2:15 PM, Vicente Romero wrote:
>>> Hi Mandy,
>>>
>>> The patch for nestmates [1] could be used as a reference. There a new
>>> method was added to class `com.sun.tools.javac.jvm.Target`, named:
>>> `hasNestmateAccess` which checks if a target is ready for nestmates or
>>> not. I think that you can follow a similar approach here.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7
>>>
>>> On 3/27/20 12:29 PM, Mandy Chung wrote:
>>>> Hi Jan,
>>>>
>>>> Good point.? The javac change only applies to JDK 15 and later and
>>>> the lambda proxy class is not a nestmate when running on JDK 14 or
>>>> earlier.
>>>>
>>>> I probably need the help from langtools team to fix this.? I'll give
>>>> it a try.
>>>>
>>>> Mandy
>>>>
>>>> On 3/27/20 4:31 AM, Jan Lahoda wrote:
>>>>> Hi Mandy,
>>>>>
>>>>> Regarding the javac changes - should those be switched on/off
>>>>> depending the Target? Or, if one compiles with e.g. --release 14,
>>>>> will the newly generated output still work on JDK 14?
>>>>>
>>>>> Jan
>>>>>
>>>>> On 27. 03. 20 0:57, 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 Mar 27 23:46:00 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Mar 2020 16:46:00 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
 <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
 
 
 <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com>
Message-ID: <09126b64-2aa5-9b0d-ec5a-62753a416ea9@oracle.com>



On 3/27/20 4:01 PM, David Holmes wrote:
> Hi Mandy,
>
> On 28/03/2020 8:29 am, Mandy Chung wrote:
>> Hi Vicente,
>>
>> hasNestmateAccess is about VM supports static nestmates on JDK 
>> release ?>= 11.
>>
>> However this is about javac --release 14 and the compiled classes may 
>> run on JDK 14 that lambda and string concat spin classes that are not 
>> nestmates. I have a patch with Jan's help:
>>
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html 
>
>
> +???????????? /**
> +????????????? * The VM does not support access across nested classes 
> (8010319).
> +????????????? * Were that ever to change, this should be removed.
> +????????????? */
> +???????????? boolean isPrivateInOtherClass() {
>
> I'm not at all sure what this means - access across different nests? 
> (I'm not even sure what that means.)

This just reverts? the old code that I removed.

What this method is trying to determine if it accesses a private in 
another class in the same nest (nested classes) that needs a synthetic 
bridge method to access.

Mandy


From david.holmes at oracle.com  Sat Mar 28 01:15:43 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 28 Mar 2020 11:15:43 +1000
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <09126b64-2aa5-9b0d-ec5a-62753a416ea9@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
 <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
 
 
 <51d0a4cf-2565-2d61-31bb-ff43bca6b0e4@oracle.com>
 <09126b64-2aa5-9b0d-ec5a-62753a416ea9@oracle.com>
Message-ID: <069c76b6-dd85-f8f5-c2dd-1ba994178084@oracle.com>

Hi Mandy,

On 28/03/2020 9:46 am, Mandy Chung wrote:
> 
> 
> On 3/27/20 4:01 PM, David Holmes wrote:
>> Hi Mandy,
>>
>> On 28/03/2020 8:29 am, Mandy Chung wrote:
>>> Hi Vicente,
>>>
>>> hasNestmateAccess is about VM supports static nestmates on JDK 
>>> release ?>= 11.
>>>
>>> However this is about javac --release 14 and the compiled classes may 
>>> run on JDK 14 that lambda and string concat spin classes that are not 
>>> nestmates. I have a patch with Jan's help:
>>>
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html 
>>
>>
>> +???????????? /**
>> +????????????? * The VM does not support access across nested classes 
>> (8010319).
>> +????????????? * Were that ever to change, this should be removed.
>> +????????????? */
>> +???????????? boolean isPrivateInOtherClass() {
>>
>> I'm not at all sure what this means - access across different nests? 
>> (I'm not even sure what that means.)
> 
> This just reverts? the old code that I removed.

Ah I see. This is ancient pre-nestmate code. Can we at least fix the 
comment as it really doesn't make any sense

> What this method is trying to determine if it accesses a private in 
> another class in the same nest (nested classes) that needs a synthetic 
> bridge method to access.

That would be a good comment to add. Something like:

If compiling for a release where the VM does not support access between
nested classes, this method indicates if a synthetic bridge method is
needed for access.

Thanks,
David

> Mandy


From paul.sandoz at oracle.com  Sat Mar 28 01:39:46 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Mar 2020 18:39:46 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <41b99011-921a-9fc6-c738-98c47e9959c3@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <72EC6AFD-412B-4238-B98E-90AF8C185D98@oracle.com>
 
 <41b99011-921a-9fc6-c738-98c47e9959c3@oracle.com>
Message-ID: <2667FFDE-44A9-4584-BF16-897B863D89F3@oracle.com>

+1
Paul.

> On Mar 27, 2020, at 3:22 PM, Mandy Chung  wrote:
> 
> Hi Paul,
> 
> This is the delta incorporating your comment:
>   http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-psandoz/ 
> 
> This patch also took Alex's comment to make it clear that the hidden class is the lookup class of the returned Lookup object and drops the sentence you commented on:
> 
> On 3/27/20 1:18 PM, Mandy Chung wrote:
>>> MethodHandles.java 
>>> ? 
>>> 
>>> 1786          * (Given the {@code Lookup} object returned this method, its lookup class 
>>> 1787          * is a {@code Class} object for which {@link Class#getName()} returns a string 
>>> 1788          * that is not a binary name.) 
>>> 
>>> ? 
>>> (The {@code Lookup} object returned from this method has a lookup class that is 
>>> a {@code Class} object whose {@link Class#getName()} returns a string 
>>> that is not a binary name.) 
>>> ? 
> 
> 
> Mandy



From dean.long at oracle.com  Sat Mar 28 02:25:36 2020
From: dean.long at oracle.com (Dean Long)
Date: Fri, 27 Mar 2020 19:25:36 -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: <13d7ba73-e49f-a55d-7e80-bd10153152a4@oracle.com>

I looked at the AOT, C2, and JVMCI changes and I didn't find any issues.

dl

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
>
> 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 jrose at openjdk.java.net  Sat Mar 28 21:52:30 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Sat, 28 Mar 2020 21:52:30 GMT
Subject: [lworld] RFR: 8236522: non-tearable inline classes
Message-ID: 

Reviewed on valhalla-dev as https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006879.html

(Note:  The design is also under discussion by valhalla-spec-experts.)

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

Commit messages:
 - 8236522: non-tearable inline classes

Changes: https://git.openjdk.java.net/valhalla/pull/7/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/7/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236522
  Stats: 844 lines in 23 files changed: 808 ins; 7 del; 29 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/7.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/7/head:pull/7

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


From chris.plummer at oracle.com  Sat Mar 28 03:51:37 2020
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 27 Mar 2020 20:51:37 -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: <90f9276d-2777-88ba-b1ec-9901711fcf02@oracle.com>

Hi Mandy,

A couple of very minor nits in the jvmtiRedefineClasses.cpp comments:

 ?153???? // classes for primitives, arrays, hidden and vm unsafe 
anonymous classes
 ?154???? // cannot be redefined.? Check here so following code can 
assume these classes
 ?155???? // are InstanceKlass.
 ?156???? if (!is_modifiable_class(mirror)) {
 ?157?????? _res = JVMTI_ERROR_UNMODIFIABLE_CLASS;
 ?158?????? return false;
 ?159???? }

I think this code and comment predate anonymous classes. Probably before 
anonymous classes the check was not for !is_modifiable_class() but 
instead was just a check for primitive or array class types since they 
are not an InstanceKlass, and would cause issues when cast to one in the 
code that lies below this section. When anonymous classes were added, 
the code got changed to use !is_modifiable_class() and the comment was 
not correctly updated (anonymous classes are an InstanceKlass). Then 
with this webrev the mention of hidden classes was added, also 
incorrectly implying they are not an InstanceKlass. I think you should 
just leave off the last sentence of the comment.

There's some ambiguity in the application of adjectives in the following:

 ?297?? // Cannot redefine or retransform a hidden or an unsafe 
anonymous class.

I'd suggest:

 ?297?? // Cannot redefine or retransform a hidden class or an unsafe 
anonymous class.

There are some places in libjdwp that need to be fixed. I spoke to 
Serguei about those this afternoon. Basically the 
convertSignatureToClassname() function needs to be fixed to handle 
hidden classes. Without the fix classname filtering will have problems 
if the filter contains a pattern with a '/' to filter on hidden classes. 
Also CLASS_UNLOAD events will not properly convert hidden class names. 
We also need tests for these cases. I think these are all things that 
can be addressed later.

I still need to look over the JVMTI tests.

thanks,

Chris

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
>
> 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  Mon Mar 30 02:17:27 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sun, 29 Mar 2020 19:17:27 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <90f9276d-2777-88ba-b1ec-9901711fcf02@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <90f9276d-2777-88ba-b1ec-9901711fcf02@oracle.com>
Message-ID: 



On 3/27/20 8:51 PM, Chris Plummer wrote:
> Hi Mandy,
>
> A couple of very minor nits in the jvmtiRedefineClasses.cpp comments:
>
> ?153???? // classes for primitives, arrays, hidden and vm unsafe 
> anonymous classes
> ?154???? // cannot be redefined.? Check here so following code can 
> assume these classes
> ?155???? // are InstanceKlass.
> ?156???? if (!is_modifiable_class(mirror)) {
> ?157?????? _res = JVMTI_ERROR_UNMODIFIABLE_CLASS;
> ?158?????? return false;
> ?159???? }
>
> I think this code and comment predate anonymous classes. Probably 
> before anonymous classes the check was not for !is_modifiable_class() 
> but instead was just a check for primitive or array class types since 
> they are not an InstanceKlass, and would cause issues when cast to one 
> in the code that lies below this section. When anonymous classes were 
> added, the code got changed to use !is_modifiable_class() and the 
> comment was not correctly updated (anonymous classes are an 
> InstanceKlass). Then with this webrev the mention of hidden classes 
> was added, also incorrectly implying they are not an InstanceKlass. I 
> think you should just leave off the last sentence of the comment.
>

I agree with you that this comment needs update.?? Perhaps it should say 
"primitive, array types and hidden classes are non-modifiable. A 
modifiable class must be an InstanceKlass."

I leave it to Serguei who may have other opinion.

> There's some ambiguity in the application of adjectives in the following:
>
> ?297?? // Cannot redefine or retransform a hidden or an unsafe 
> anonymous class.
>
> I'd suggest:
>
> ?297?? // Cannot redefine or retransform a hidden class or an unsafe 
> anonymous class.
>

+1

> There are some places in libjdwp that need to be fixed. I spoke to 
> Serguei about those this afternoon. Basically the 
> convertSignatureToClassname() function needs to be fixed to handle 
> hidden classes. Without the fix classname filtering will have problems 
> if the filter contains a pattern with a '/' to filter on hidden 
> classes. Also CLASS_UNLOAD events will not properly convert hidden 
> class names. We also need tests for these cases. I think these are all 
> things that can be addressed later.
>

Good catch.? I have created a subtask under JDK-8230502:
 ?? https://bugs.openjdk.java.net/browse/JDK-8230502

> I still need to look over the JVMTI tests.
>

Thanks
Mandy
> thanks,
>
> Chris
>
> 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 
>>
>>
>> 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 serguei.spitsyn at oracle.com  Mon Mar 30 03:40:43 2020
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Sun, 29 Mar 2020 20:40:43 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <90f9276d-2777-88ba-b1ec-9901711fcf02@oracle.com>
 
Message-ID: <7fe9fd65-8bee-beb3-03af-ab56120a4cc1@oracle.com>

Hi Mandy and Chris,


On 3/29/20 19:17, Mandy Chung wrote:
>
>
> On 3/27/20 8:51 PM, Chris Plummer wrote:
>> Hi Mandy,
>>
>> A couple of very minor nits in the jvmtiRedefineClasses.cpp comments:
>>
>> ?153???? // classes for primitives, arrays, hidden and vm unsafe 
>> anonymous classes
>> ?154???? // cannot be redefined.? Check here so following code can 
>> assume these classes
>> ?155???? // are InstanceKlass.
>> ?156???? if (!is_modifiable_class(mirror)) {
>> ?157?????? _res = JVMTI_ERROR_UNMODIFIABLE_CLASS;
>> ?158?????? return false;
>> ?159???? }
>>
>> I think this code and comment predate anonymous classes. Probably 
>> before anonymous classes the check was not for !is_modifiable_class() 
>> but instead was just a check for primitive or array class types since 
>> they are not an InstanceKlass, and would cause issues when cast to 
>> one in the code that lies below this section. When anonymous classes 
>> were added, the code got changed to use !is_modifiable_class() and 
>> the comment was not correctly updated (anonymous classes are an 
>> InstanceKlass). Then with this webrev the mention of hidden classes 
>> was added, also incorrectly implying they are not an InstanceKlass. I 
>> think you should just leave off the last sentence of the comment.
>>
>
> I agree with you that this comment needs update.?? Perhaps it should 
> say "primitive, array types and hidden classes are non-modifiable. A 
> modifiable class must be an InstanceKlass."
>
> I leave it to Serguei who may have other opinion.

We already had a chat with Chris about this.
This suggestion looks right.


>> There's some ambiguity in the application of adjectives in the 
>> following:
>>
>> ?297?? // Cannot redefine or retransform a hidden or an unsafe 
>> anonymous class.
>>
>> I'd suggest:
>>
>> ?297?? // Cannot redefine or retransform a hidden class or an unsafe 
>> anonymous class.
>>
>
> +1

+1

>> There are some places in libjdwp that need to be fixed. I spoke to 
>> Serguei about those this afternoon. Basically the 
>> convertSignatureToClassname() function needs to be fixed to handle 
>> hidden classes. Without the fix classname filtering will have 
>> problems if the filter contains a pattern with a '/' to filter on 
>> hidden classes. Also CLASS_UNLOAD events will not properly convert 
>> hidden class names. We also need tests for these cases. I think these 
>> are all things that can be addressed later.
>>
>
> Good catch.? I have created a subtask under JDK-8230502:
> ?? https://bugs.openjdk.java.net/browse/JDK-8230502

Yes, it is good catch. Thank you for filing the subtask.
We discussed this with Chris.
This was expected to be found with new test coverage and fixed in the 
JDI chunk of work which we have decided to separate from JEP 371.


Thanks,
Serguei

>> I still need to look over the JVMTI tests.
>>
>
> Thanks
> Mandy
>> thanks,
>>
>> Chris
>>
>> 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 
>>>
>>>
>>> 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 serguei.spitsyn at oracle.com  Mon Mar 30 09:30:54 2020
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 30 Mar 2020 02:30:54 -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: 

Hi Mandy,

I have just one comment so far.

http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03/src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp.frames.html

 ?356?? void add_classes(LoadedClassInfo* first_class, int num_classes, 
bool has_class_mirror_holder) {
 ?357???? LoadedClassInfo** p_list_to_add_to;
 ?358???? bool is_hidden = first_class->_klass->is_hidden();
 ?359???? if (has_class_mirror_holder) {
 ?360?????? p_list_to_add_to = is_hidden ? &_hidden_weak_classes : 
&_anon_classes;
 ?361???? } else {
 ?362?????? p_list_to_add_to = &_classes;
 ?363???? }
 ?364???? // Search tail.
 ?365???? while ((*p_list_to_add_to) != NULL) {
 ?366?????? p_list_to_add_to = &(*p_list_to_add_to)->_next;
 ?367???? }
 ?368???? *p_list_to_add_to = first_class;
 ?369???? if (has_class_mirror_holder) {
 ?370?????? if (is_hidden) {
 ?371???????? _num_hidden_weak_classes += num_classes;
 ?372?????? } else {
 ?373???????? _num_anon_classes += num_classes;
 ?374?????? }
 ?375???? } else {
 ?376?????? _num_classes += num_classes;
 ?377???? }
 ?378?? }

 ?Q1: I'm just curious, what happens if a cld has arrays of hidden classes?
 ???? Is the bottom_klass always expected to be the first?


Thanks,
Serguei


On 3/26/20 16:57, 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 david.holmes at oracle.com  Mon Mar 30 09:54:51 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Mar 2020 19:54:51 +1000
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
Message-ID: <546cf8e4-00e4-1d22-6402-6620b8d7b2db@oracle.com>

Sorry to jump in on this but it caught my eye though I may be missing a 
larger context ...

On 30/03/2020 7:30 pm, serguei.spitsyn at oracle.com wrote:
> Hi Mandy,
> 
> I have just one comment so far.
> 
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03/src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp.frames.html 
> 
> 
>  ?356?? void add_classes(LoadedClassInfo* first_class, int num_classes, 
> bool has_class_mirror_holder) {
>  ?357???? LoadedClassInfo** p_list_to_add_to;
>  ?358???? bool is_hidden = first_class->_klass->is_hidden();
>  ?359???? if (has_class_mirror_holder) {
>  ?360?????? p_list_to_add_to = is_hidden ? &_hidden_weak_classes : 
> &_anon_classes;
>  ?361???? } else {
>  ?362?????? p_list_to_add_to = &_classes;
>  ?363???? }
>  ?364???? // Search tail.
>  ?365???? while ((*p_list_to_add_to) != NULL) {
>  ?366?????? p_list_to_add_to = &(*p_list_to_add_to)->_next;
>  ?367???? }
>  ?368???? *p_list_to_add_to = first_class;
>  ?369???? if (has_class_mirror_holder) {
>  ?370?????? if (is_hidden) {
>  ?371???????? _num_hidden_weak_classes += num_classes;

Why does hidden imply weak here?

David
-----

>  ?372?????? } else {
>  ?373???????? _num_anon_classes += num_classes;
>  ?374?????? }
>  ?375???? } else {
>  ?376?????? _num_classes += num_classes;
>  ?377???? }
>  ?378?? }
> 
>  ?Q1: I'm just curious, what happens if a cld has arrays of hidden classes?
>  ???? Is the bottom_klass always expected to be the first?
> 
> 
> Thanks,
> Serguei
> 
> 
> On 3/26/20 16:57, 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 harold.seigel at oracle.com  Mon Mar 30 12:28:10 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Mon, 30 Mar 2020 08:28:10 -0400
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
Message-ID: 

Hi Serguei,

The bottom class is always the first class.? The bottom class of 
[Integer and [[[Integer is Integer in both cases.

Thanks, Harold

On 3/30/2020 5:30 AM, serguei.spitsyn at oracle.com wrote:
> Hi Mandy,
>
> I have just one comment so far.
>
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03/src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp.frames.html 
>
>
> ?356?? void add_classes(LoadedClassInfo* first_class, int num_classes, 
> bool has_class_mirror_holder) {
> ?357???? LoadedClassInfo** p_list_to_add_to;
> ?358???? bool is_hidden = first_class->_klass->is_hidden();
> ?359???? if (has_class_mirror_holder) {
> ?360?????? p_list_to_add_to = is_hidden ? &_hidden_weak_classes : 
> &_anon_classes;
> ?361???? } else {
> ?362?????? p_list_to_add_to = &_classes;
> ?363???? }
> ?364???? // Search tail.
> ?365???? while ((*p_list_to_add_to) != NULL) {
> ?366?????? p_list_to_add_to = &(*p_list_to_add_to)->_next;
> ?367???? }
> ?368???? *p_list_to_add_to = first_class;
> ?369???? if (has_class_mirror_holder) {
> ?370?????? if (is_hidden) {
> ?371???????? _num_hidden_weak_classes += num_classes;
> ?372?????? } else {
> ?373???????? _num_anon_classes += num_classes;
> ?374?????? }
> ?375???? } else {
> ?376?????? _num_classes += num_classes;
> ?377???? }
> ?378?? }
>
> ?Q1: I'm just curious, what happens if a cld has arrays of hidden 
> classes?
> ???? Is the bottom_klass always expected to be the first?
>
>
> Thanks,
> Serguei
>
>
> On 3/26/20 16:57, 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  Mon Mar 30 12:32:48 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 30 Mar 2020 14:32:48 +0200
Subject: Updated SoV documents
In-Reply-To: <7c7f797d-b5da-7f1e-04f1-e0b3e9d2e745@oracle.com>
References: <7c7f797d-b5da-7f1e-04f1-e0b3e9d2e745@oracle.com>
Message-ID: <993eeccb-997e-c075-df53-62dc1df54e09@oracle.com>

Hi Brian,

very nice!

Here are some minor comments/questions:

1. Background:
> each aimed at a understanding a separate aspect of the problem" 

Should be "each aimed at understanding a separate aspect of the problem".

3. JVM Model:
> However, because the JVM knows that inline objects do not have identity, it can routinely optimize layout (flattening), instantiation, member access, and calling conventions (scalarization) for inline objects.

We mostly use the term "scalarization" to describe that inline objects are "passed as fields" in the
scope of a method. Performance-wise this is the more important optimization compared to the calling
convention (see https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-December/006668.html). I
would therefore suggest to differentiate between scalarization in the scope of a method (and it's
inlinees) and scalarization at method boundaries (i.e., the calling convention optimizations).

> The L World design was significantly  ...

Should be "L-World".

4: Translation scheme:
> class C extends A implements I { }

Shouldn't C be declared as "inline class C"?
Otherwise, it would be ref-default which wouldn't create C$val, right?

> now we have a new translation target, one which can routinely optimize layout, instantiation, and calling conventions for inline classes and their reference projections

What kind of optimizations do you expect for reference projections of inline classes?

Thanks,
Tobias


From brian.goetz at oracle.com  Mon Mar 30 13:52:17 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 30 Mar 2020 09:52:17 -0400
Subject: Updated SoV documents
In-Reply-To: <993eeccb-997e-c075-df53-62dc1df54e09@oracle.com>
References: <7c7f797d-b5da-7f1e-04f1-e0b3e9d2e745@oracle.com>
 <993eeccb-997e-c075-df53-62dc1df54e09@oracle.com>
Message-ID: 

> 3. JVM Model:
>> However, because the JVM knows that inline objects do not have identity, it can routinely optimize layout (flattening), instantiation, member access, and calling conventions (scalarization) for inline objects.
> 
> We mostly use the term "scalarization" to describe that inline objects are "passed as fields" in the
> scope of a method. Performance-wise this is the more important optimization compared to the calling
> convention (see https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-December/006668.html). I
> would therefore suggest to differentiate between scalarization in the scope of a method (and it's
> inlinees) and scalarization at method boundaries (i.e., the calling convention optimizations).

By ?scalarization in the scope of a method?, you mean ordinary field hoisting?  Since that is an optimization we do routinely for final fields, I had assumed that it was only scalarization at method boundaries the was important and new here?

> 4: Translation scheme:
>> class C extends A implements I { }
> 
> Shouldn't C be declared as "inline class C"?
> Otherwise, it would be ref-default which wouldn't create C$val, right?

Yes.  

There?s also a small error about ref-default inline classes; the ref projection has to be called C, not C$ref, for binary compatibility purposes.

> 
>> now we have a new translation target, one which can routinely optimize layout, instantiation, and calling conventions for inline classes and their reference projections
> 
> What kind of optimizations do you expect for reference projections of inline classes?

Basically, better escape analysis is the primary one.  If we can prove non-nullity (or confidently speculate on it), I would assume then we can recover the scalarization optimizations, but I understand we haven?t done this (and may not.)  

From david.holmes at oracle.com  Mon Mar 30 14:01:21 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Mar 2020 00:01:21 +1000
Subject: RFR (S): 8241704: Add test case for unloadable class with nest host
 error
Message-ID: <38ff7ec3-43d5-ed7f-e3eb-d01ffd1b6575@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8241704
webrev: http://cr.openjdk.java.net/~dholmes/8241704/webrev/

After JDK-8241562 there is an untested code path in 
ResolutionErrorTable::free_entry if we can unload a class that had a 
nest host validation or resolution error. So I took an existing nest 
host membership test (where the claimed host is in another package) and 
ran it in a new classloader and then triggered unloading. With a 
debugging printf enabled this showed the previously unused code path 
being executed.

Thanks,
David


From coleen.phillimore at oracle.com  Mon Mar 30 14:18:58 2020
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 30 Mar 2020 10:18:58 -0400
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <546cf8e4-00e4-1d22-6402-6620b8d7b2db@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
 <546cf8e4-00e4-1d22-6402-6620b8d7b2db@oracle.com>
Message-ID: <9cd71367-edc6-efc8-0a53-2e703ffbbfab@oracle.com>



On 3/30/20 5:54 AM, David Holmes wrote:
> Sorry to jump in on this but it caught my eye though I may be missing 
> a larger context ...
>
> On 30/03/2020 7:30 pm, serguei.spitsyn at oracle.com wrote:
>> Hi Mandy,
>>
>> I have just one comment so far.
>>
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03/src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp.frames.html 
>>
>>
>> ??356?? void add_classes(LoadedClassInfo* first_class, int 
>> num_classes, bool has_class_mirror_holder) {
>> ??357???? LoadedClassInfo** p_list_to_add_to;
>> ??358???? bool is_hidden = first_class->_klass->is_hidden();
>> ??359???? if (has_class_mirror_holder) {
>> ??360?????? p_list_to_add_to = is_hidden ? &_hidden_weak_classes : 
>> &_anon_classes;
>> ??361???? } else {
>> ??362?????? p_list_to_add_to = &_classes;
>> ??363???? }
>> ??364???? // Search tail.
>> ??365???? while ((*p_list_to_add_to) != NULL) {
>> ??366?????? p_list_to_add_to = &(*p_list_to_add_to)->_next;
>> ??367???? }
>> ??368???? *p_list_to_add_to = first_class;
>> ??369???? if (has_class_mirror_holder) {
>> ??370?????? if (is_hidden) {
>> ??371???????? _num_hidden_weak_classes += num_classes;
>
> Why does hidden imply weak here?

has_class_mirror_holder() implies weak.

Coleen
>
> David
> -----
>
>> ??372?????? } else {
>> ??373???????? _num_anon_classes += num_classes;
>> ??374?????? }
>> ??375???? } else {
>> ??376?????? _num_classes += num_classes;
>> ??377???? }
>> ??378?? }
>>
>> ??Q1: I'm just curious, what happens if a cld has arrays of hidden 
>> classes?
>> ????? Is the bottom_klass always expected to be the first?
>>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 3/26/20 16:57, 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  Mon Mar 30 14:49:51 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 30 Mar 2020 16:49:51 +0200
Subject: Updated SoV documents
In-Reply-To: 
References: <7c7f797d-b5da-7f1e-04f1-e0b3e9d2e745@oracle.com>
 <993eeccb-997e-c075-df53-62dc1df54e09@oracle.com>
 
Message-ID: <6d24ff81-b2ec-c534-934e-fe3079e7a07f@oracle.com>

Hi Brian,

On 30.03.20 15:52, Brian Goetz wrote:
> By ?scalarization in the scope of a method?, you mean ordinary field hoisting?  Since that is an optimization we do routinely for final fields, 

No, I'm basically talking about what C2's -XX:+EliminateAllocations does today for very limited
cases of non-escaping object allocations (that's what we call "scalar replacement"). Instead of
trying to figure out if an allocation is necessary and the object needs to be passed/accessed via an
indirection through a pointer, we use the fact that inline types don't have identity, i.e. can never
escape, avoid allocations and just pass the fields in registers or on the native stack. This avoids
allocation overhead, memory accesses (including barriers) and helps all kinds of later optimizations
like constant folding.

While this might sound trivial, it's not and it's *much* more powerful than what we do today for
final fields or non-escaping object allocations. In fact, final fields do not help EA at all because
the holder object still has identity.

Here's a simple example on pages 21-22:
http://cr.openjdk.java.net/~thartmann/talks/2018-Value_Types_Compiler_Offsite.pdf

For method 'computePOJO', C2 emits an allocation for 'Complex' because due to control flow, Escape
Analysis is not able to determine that the 'c' is non-escaping (even though the constructor is fully
inlined). As a result, the generated assembly is non-optimal and contains allocations + memory accesses.

On the other hand, C2 generates optimal code for 'computeValueType' because without any analysis,
'Complex' is known to be non-escaping and can be "scalar replaced". The code contains no allocations
and no memory accesses, just some operations on registers.

> I had assumed that it was only scalarization at method boundaries the was important and new here?

No, not at all. For the JIT, the main benefit of inline types is that we don't need to rely on
traditional Escape Analysis which is very limited (in fact, we don't even apply Escape Analysis to
inline types because they they don't have identity and therefore can not escape). Scalarization at
method boundaries is just the cream topping.

> There?s also a small error about ref-default inline classes; the ref projection has to be called C, not C$ref, for binary compatibility purposes.

Okay, makes sense.

> Basically, better escape analysis is the primary one.  If we can prove non-nullity (or confidently speculate on it), I would assume then we can recover the scalarization optimizations, but I understand we haven?t done this (and may not.)  

We actually do this already in the scope of a method (and it's inlinees). If we can prove or
speculate on non-nullity, we apply the same optimizations to C$ref that would be applied to C$val. I
wouldn't call this "better escape analysis" though because there is no escape analysis involved.

However, we don't do this beyond call boundaries (details are explained in [1]).

You are saying "can routinely optimize layout" but I don't see how we could do this for the
reference projections?

Best regards,
Tobias

[1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-December/006668.html


From brian.goetz at oracle.com  Mon Mar 30 16:07:47 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 30 Mar 2020 12:07:47 -0400
Subject: Updated SoV documents
In-Reply-To: <6d24ff81-b2ec-c534-934e-fe3079e7a07f@oracle.com>
References: <7c7f797d-b5da-7f1e-04f1-e0b3e9d2e745@oracle.com>
 <993eeccb-997e-c075-df53-62dc1df54e09@oracle.com>
 
 <6d24ff81-b2ec-c534-934e-fe3079e7a07f@oracle.com>
Message-ID: 



>> By ?scalarization in the scope of a method?, you mean ordinary field hoisting?  Since that is an optimization we do routinely for final fields,
> No, I'm basically talking about what C2's -XX:+EliminateAllocations does today for very limited
> cases of non-escaping object allocations (that's what we call "scalar replacement").

OK, now I see where we are stumbling over terms.

Yes, for within-method (or inlinee) scalar replacement, I assume that we 
can do this better for inlines (including reference projections) than we 
can for identity classes -- this is what I meant below by "better escape 
analysis."? I had been folding traditional within-method scalar 
replacement into "escape analysis".

>
>> Basically, better escape analysis is the primary one.  If we can prove non-nullity (or confidently speculate on it), I would assume then we can recover the scalarization optimizations, but I understand we haven?t done this (and may not.)
> We actually do this already in the scope of a method (and it's inlinees). If we can prove or
> speculate on non-nullity, we apply the same optimizations to C$ref that would be applied to C$val. I
> wouldn't call this "better escape analysis" though because there is no escape analysis involved.
>
> However, we don't do this beyond call boundaries (details are explained in [1]).
>
> You are saying "can routinely optimize layout" but I don't see how we could do this for the
> reference projections?
>

No.? In fact, if a field is typed with a reference type, then we should 
take that as an indication of programmer intent that the layout they 
wanted was a reference, not inlining.? So we should not attempt to 
optimize layout at all for reference projections.? (Note that I assume 
the VM is ignorant about the concept of reference projection, and just 
goes on hierarchy analysis and knowledge of which types are reference 
types / identity classes / inline classes.)


From serguei.spitsyn at oracle.com  Mon Mar 30 16:19:19 2020
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 30 Mar 2020 09:19:19 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: 
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
Message-ID: <50b1658d-2195-53af-ea0b-e13842e00496@oracle.com>

On 3/30/20 02:30, serguei.spitsyn at oracle.com wrote:
> Hi Mandy,
>
> I have just one comment so far.
>
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03/src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp.frames.html 
>
>
> ?356?? void add_classes(LoadedClassInfo* first_class, int num_classes, 
> bool has_class_mirror_holder) {
> ?357???? LoadedClassInfo** p_list_to_add_to;
> ?358???? bool is_hidden = first_class->_klass->is_hidden();
> ?359???? if (has_class_mirror_holder) {
> ?360?????? p_list_to_add_to = is_hidden ? &_hidden_weak_classes : 
> &_anon_classes;
> ?361???? } else {
> ?362?????? p_list_to_add_to = &_classes;
> ?363???? }
> ?364???? // Search tail.
> ?365???? while ((*p_list_to_add_to) != NULL) {
> ?366?????? p_list_to_add_to = &(*p_list_to_add_to)->_next;
> ?367???? }
> ?368???? *p_list_to_add_to = first_class;
> ?369???? if (has_class_mirror_holder) {
> ?370?????? if (is_hidden) {
> ?371???????? _num_hidden_weak_classes += num_classes;
> ?372?????? } else {
> ?373???????? _num_anon_classes += num_classes;
> ?374?????? }
> ?375???? } else {
> ?376?????? _num_classes += num_classes;
> ?377???? }
> ?378?? }
>
> ?Q1: I'm just curious, what happens if a cld has arrays of hidden 
> classes?
> ???? Is the bottom_klass always expected to be the first?

Please, skip it. I've got the answer.
The array classes were not included into the LoadedClassInfo* by the 
classes_do.

Thanks,
Serguei

>
> Thanks,
> Serguei
>
>
> On 3/26/20 16:57, 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 harold.seigel at oracle.com  Mon Mar 30 18:05:29 2020
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Mon, 30 Mar 2020 18:05:29 +0000
Subject: hg: valhalla/valhalla: Summary: Remove incorrect text from comment
Message-ID: <202003301805.02UI5TGB007964@aojmv0008.oracle.com>

Changeset: d97444469015
Author:    hseigel
Date:      2020-03-30 18:04 +0000
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/d97444469015

Summary: Remove incorrect text from comment
Reviewed-by: mchung

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



From mandy.chung at oracle.com  Mon Mar 30 19:13:57 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 30 Mar 2020 12:13:57 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 
 <08191054-8d0a-ae60-ac99-e2849f08ce85@oracle.com>
Message-ID: <528c7933-be32-9863-6cc5-92223a75bbee@oracle.com>

This is the patch to keep the JDK 14 behavior if target release to 14 
(thanks to Jan for helping making change in javac to get the tests working)
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/

Mandy

On 3/27/20 9:29 AM, Mandy Chung wrote:
> Hi Jan,
>
> Good point.? The javac change only applies to JDK 15 and later and the 
> lambda proxy class is not a nestmate when running on JDK 14 or earlier.
>
> I probably need the help from langtools team to fix this.? I'll give 
> it a try.
>
> Mandy



From mandy.chung at oracle.com  Mon Mar 30 20:31:12 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 30 Mar 2020 13:31:12 -0700
Subject: RFR (S): 8241704: Add test case for unloadable class with nest
 host error
In-Reply-To: <38ff7ec3-43d5-ed7f-e3eb-d01ffd1b6575@oracle.com>
References: <38ff7ec3-43d5-ed7f-e3eb-d01ffd1b6575@oracle.com>
Message-ID: 

Hi David,

The new test looks fine to me.? Thanks for the elaborated comment that 
helps to understand how this test sets up.? (Caveat: I'm not familiar 
with ClassUnloadCommon test library)

Mandy

On 3/30/20 7:01 AM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241704
> webrev: http://cr.openjdk.java.net/~dholmes/8241704/webrev/
>
> After JDK-8241562 there is an untested code path in 
> ResolutionErrorTable::free_entry if we can unload a class that had a 
> nest host validation or resolution error. So I took an existing nest 
> host membership test (where the claimed host is in another package) 
> and ran it in a new classloader and then triggered unloading. With a 
> debugging printf enabled this showed the previously unused code path 
> being executed.
>
> Thanks,
> David



From rriggs at openjdk.java.net  Mon Mar 30 21:54:32 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 30 Mar 2020 21:54:32 GMT
Subject: [lworld] [Rev 01] RFR: Prototype inline cursors for List
In-Reply-To: 
References: 
Message-ID: 

> Implementation of Cursors and jmh tests comparing
> typical List traversal via direct index, iterator,
> inline cursor, and an iterator implemented on top of cursor.
> 
> Sample results:
> 
>                                    (size)  Mode  Cnt       Score       Error  Units
> XArrayListCursorTest.getViaArray            100000  avgt    5  507793.484  7086.038  ns/op
> XArrayListCursorTest.getViaCursorForLoop    100000  avgt    5  656461.958  52488.547  ns/op
> XArrayListCursorTest.getViaCursorWhileLoop  100000  avgt    5  641963.323  32219.409  ns/op
> XArrayListCursorTest.getViaIterator         100000  avgt    5  558863.817  23539.256  ns/op
> XArrayListCursorTest.getViaIteratorCurs     100000  avgt    5  733161.466  33721.881  ns/op

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Deleted remove methods

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/5/files
  - new: https://git.openjdk.java.net/valhalla/pull/5/files/105adbff..4e940aed

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

  Stats: 76 lines in 3 files changed: 1 ins; 62 del; 13 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/5.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/5/head:pull/5

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


From jrose at openjdk.java.net  Mon Mar 30 22:58:05 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 30 Mar 2020 22:58:05 GMT
Subject: [lworld] RFR: 8236522: non-tearable inline classes
In-Reply-To: 
References: 
Message-ID: 

On Sat, 28 Mar 2020 21:46:15 GMT, John R Rose  wrote:

> Reviewed on valhalla-dev as https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006879.html
> 
> (Note:  The design is also under discussion by valhalla-spec-experts.)

Targeted regression testing in `test/hotspot/jtreg/runtime/valhalla/valuetypes` shows only pre-existing failures.

Adding `+UnlockDiagnosticVMOptions` to JTREG tests, since new option `ForceNonTearable` is diagnostic.

Pre-existing bug reported as https://bugs.openjdk.java.net/browse/JDK-8241894

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

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


From david.holmes at oracle.com  Mon Mar 30 23:24:06 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Mar 2020 09:24:06 +1000
Subject: RFR (S): 8241704: Add test case for unloadable class with nest
 host error
In-Reply-To: 
References: <38ff7ec3-43d5-ed7f-e3eb-d01ffd1b6575@oracle.com>
 
Message-ID: <150f29d6-1069-4360-0908-5d043e00943b@oracle.com>

Thanks Mandy! I only found out about ClassUnloadCommon after reinventing 
part of it :)

David

On 31/03/2020 6:31 am, Mandy Chung wrote:
> Hi David,
> 
> The new test looks fine to me.? Thanks for the elaborated comment that 
> helps to understand how this test sets up.? (Caveat: I'm not familiar 
> with ClassUnloadCommon test library)
> 
> Mandy
> 
> On 3/30/20 7:01 AM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241704
>> webrev: http://cr.openjdk.java.net/~dholmes/8241704/webrev/
>>
>> After JDK-8241562 there is an untested code path in 
>> ResolutionErrorTable::free_entry if we can unload a class that had a 
>> nest host validation or resolution error. So I took an existing nest 
>> host membership test (where the claimed host is in another package) 
>> and ran it in a new classloader and then triggered unloading. With a 
>> debugging printf enabled this showed the previously unused code path 
>> being executed.
>>
>> Thanks,
>> David
> 


From david.holmes at oracle.com  Mon Mar 30 23:25:52 2020
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Mon, 30 Mar 2020 23:25:52 +0000
Subject: hg: valhalla/valhalla: 8241704: Add test case for unloadable class
 with nest host error
Message-ID: <202003302325.02UNPqrI022837@aojmv0008.oracle.com>

Changeset: c964a558522d
Author:    dholmes
Date:      2020-03-30 19:25 -0400
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/c964a558522d

8241704: Add test case for unloadable class with nest host error
Reviewed-by: mchung

+ test/hotspot/jtreg/runtime/Nestmates/membership/Helper.java
+ test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithClassUnload.java



From mandy.chung at oracle.com  Tue Mar 31 01:04:26 2020
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 31 Mar 2020 01:04:26 +0000
Subject: hg: valhalla/valhalla: 5 new changesets
Message-ID: <202003310104.02V14ROP009251@aojmv0008.oracle.com>

Changeset: f4dc7eafeb51
Author:    mchung
Date:      2020-03-30 16:28 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/f4dc7eafeb51

[nestmates] javac should keep old behavior to synthesize a bridge method if target to release <= 14.
Reviewed-by: vromero, jlahoda
Contributed-by: jan.lahoda at oracle.com, mandy.chung at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java
+ test/langtools/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTargetRelease14Test.java
! test/langtools/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java
! test/langtools/tools/javac/lambda/bytecode/TestLambdaBytecode.java
+ test/langtools/tools/javac/lambda/bytecode/TestLambdaBytecodeTargetRelease14.java

Changeset: 19f8a7827a31
Author:    mchung
Date:      2020-03-30 17:39 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/19f8a7827a31

[nestmates] Add reachability fence to UnloadingTest to ensure object not GC'ed

! test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java

Changeset: 912c4c0ca796
Author:    mchung
Date:      2020-03-30 17:40 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/912c4c0ca796

[nestmates] Remove -Xcomp test run from BasicTest.java.  Cover by tier6 testing

! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java

Changeset: a41d4b835eab
Author:    mchung
Date:      2020-03-30 17:56 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/a41d4b835eab

[nestmates] Fix @modules in new tests
Contributed-by: amy.lu at oracle.com, mandy.chung at oracle.com, serguei.spitsyn at oracle.com

! test/hotspot/jtreg/runtime/HiddenClasses/CastToParentTest.java
! test/hotspot/jtreg/runtime/HiddenClasses/GCHiddenClass.java
! test/hotspot/jtreg/runtime/HiddenClasses/HiddenClassStack.java
! test/hotspot/jtreg/runtime/HiddenClasses/HiddenGetModule.java
! test/hotspot/jtreg/runtime/HiddenClasses/InstantiateHiddenClass.java
! test/hotspot/jtreg/runtime/HiddenClasses/NestedHidden.java
! test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java
! test/hotspot/jtreg/runtime/HiddenClasses/TestHiddenClassUnloading.java
! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java
! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/P/Q/HiddenClassSigTest.java
! test/jdk/java/lang/instrument/HiddenClass/HiddenClassAgent.java
! test/jdk/java/lang/invoke/defineHiddenClass/LambdaNestedInnerTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/SelfReferenceDescriptor.java
! test/jdk/java/lang/invoke/lambda/superProtectedMethod/InheritedProtectedMethod.java
! test/jdk/jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java

Changeset: c5a6786c46c0
Author:    mchung
Date:      2020-03-30 17:57 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/c5a6786c46c0

Merge




From jrose at openjdk.java.net  Tue Mar 31 06:18:57 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Tue, 31 Mar 2020 06:18:57 GMT
Subject: [Integrated] [lworld] RFR: 8236522: non-tearable inline classes
In-Reply-To: 
References: 
Message-ID: 

Changeset: cab7a5b9
Author:    John R Rose 
Date:      2020-03-31 06:17:43 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/cab7a5b9

8236522: NonTearable marker interface for inline classes

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classFileParser.hpp
! src/hotspot/share/classfile/fieldLayoutBuilder.cpp
! src/hotspot/share/classfile/fieldLayoutBuilder.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/oops/arrayKlass.hpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/valueArrayKlass.cpp
! src/hotspot/share/oops/valueArrayKlass.hpp
! src/hotspot/share/oops/valueKlass.cpp
! src/hotspot/share/oops/valueKlass.hpp
! src/hotspot/share/opto/valuetypenode.cpp
! src/hotspot/share/opto/valuetypenode.hpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/utilities/stringUtils.cpp
! src/hotspot/share/utilities/stringUtils.hpp
+ src/java.base/share/classes/java/lang/NonTearable.java
! test/hotspot/jtreg/runtime/valhalla/valuetypes/FlattenableSemanticTest.java
+ test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueTearing.java
! test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueTypeArray.java
! test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueTypeDensity.java
! test/hotspot/jtreg/runtime/valhalla/valuetypes/ValueTypesTest.java


From jrose at openjdk.java.net  Tue Mar 31 06:21:18 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Tue, 31 Mar 2020 06:21:18 GMT
Subject: [lworld] [Rev 01] RFR: 8236522: NonTearable marker interface for
 inline classes
In-Reply-To: 
References: 
Message-ID: 

> Reviewed on valhalla-dev as https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006879.html
> 
> (Note:  The design is also under discussion by valhalla-spec-experts.)

John R Rose has refreshed the contents of this pull request, and previous commits have been removed. The incremental
views will show differences compared to the previous content of the PR. The pull request contains one new commit since
the last revision:

  8236522: NonTearable marker interface for inline classes

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/7/files
  - new: https://git.openjdk.java.net/valhalla/pull/7/files/fcaa7503..c6ff6820

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

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

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


From tobias.hartmann at oracle.com  Tue Mar 31 06:53:25 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 31 Mar 2020 08:53:25 +0200
Subject: Updated SoV documents
In-Reply-To: 
References: <7c7f797d-b5da-7f1e-04f1-e0b3e9d2e745@oracle.com>
 <993eeccb-997e-c075-df53-62dc1df54e09@oracle.com>
 
 <6d24ff81-b2ec-c534-934e-fe3079e7a07f@oracle.com>
 
Message-ID: <3fecdaa5-c5f5-4272-25cd-1db444417a0e@oracle.com>

Hi Brian,

On 30.03.20 18:07, Brian Goetz wrote:
>>> By ?scalarization in the scope of a method?, you mean ordinary field hoisting?? Since that is an
>>> optimization we do routinely for final fields,
>> No, I'm basically talking about what C2's -XX:+EliminateAllocations does today for very limited
>> cases of non-escaping object allocations (that's what we call "scalar replacement").
> 
> OK, now I see where we are stumbling over terms.
> 
> Yes, for within-method (or inlinee) scalar replacement, I assume that we can do this better for
> inlines (including reference projections) than we can for identity classes -- this is what I meant
> below by "better escape analysis."? I had been folding traditional within-method scalar replacement
> into "escape analysis".

OK, looks like we are on the same page now.

>> You are saying "can routinely optimize layout" but I don't see how we could do this for the
>> reference projections?
>>
> No.? In fact, if a field is typed with a reference type, then we should take that as an indication
> of programmer intent that the layout they wanted was a reference, not inlining.? So we should not
> attempt to optimize layout at all for reference projections.? (Note that I assume the VM is ignorant
> about the concept of reference projection, and just goes on hierarchy analysis and knowledge of
> which types are reference types / identity classes / inline classes.)

Makes sense. I would suggest to slightly rephrase this sentence in the Translation Scheme chapter
then to make it clear that we are not optimizing the layout for reference projections:

> routinely optimize layout [...] for inline classes and their reference projections

Best regards,
Tobias


From thartmann at openjdk.java.net  Tue Mar 31 08:42:21 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 31 Mar 2020 08:42:21 GMT
Subject: [lworld] RFR: 8241910: [lworld] C2 crashes due to duplicate
 storestore barrier added by JDK-8236522
Message-ID: <4j1huMP8_l9vOcM1rRqPORdk5wXiAxl8TeATOp7E9Eg=.7be08dab-8183-4e94-8f6a-468348539cbd@github.com>

The fix for JDK-8236522 contained the partial/broken fix for a missing barrier issue that was already fixed by
JDK-8238780. As a result, tests are failing:

compiler/valhalla/valuetypes/TestIntrinsics.java macosx-x64-debug Exception: java.lang.RuntimeException: Expected to
get exit value of [0] compiler/valhalla/valuetypes/TestIntrinsics.java macosx-x64-debug Exception:
java.lang.RuntimeException: Expected to get exit value of [0] compiler/valhalla/valuetypes/TestBufferTearing.java
macosx-x64-debug ExitCode: 134 compiler/valhalla/valuetypes/TestBufferTearing.java macosx-x64-debug ExitCode: 134
compiler/valhalla/valuetypes/TestIntrinsics.java linux-x64-debug Exception: java.lang.RuntimeException: Expected to get
exit value of [0] compiler/valhalla/valuetypes/TestBufferTearing.java linux-x64-debug ExitCode: 134
compiler/valhalla/valuetypes/TestIntrinsics.java linux-x64-open-debug Exception: java.lang.RuntimeException: Expected
to get exit value of [0] compiler/valhalla/valuetypes/TestBufferTearing.java linux-x64-open-debug ExitCode: 134

The changes to valuetypenode.cpp/hpp should be reverted.

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

Commit messages:
 - 8241910: [lworld] C2 crashes due to duplicate storestore barrier added by JDK-8236522

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

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


From thartmann at openjdk.java.net  Tue Mar 31 09:08:52 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 31 Mar 2020 09:08:52 GMT
Subject: [Integrated] [lworld] RFR: 8241910: [lworld] C2 crashes due to
 duplicate storestore barrier added by JDK-8236522
In-Reply-To: <4j1huMP8_l9vOcM1rRqPORdk5wXiAxl8TeATOp7E9Eg=.7be08dab-8183-4e94-8f6a-468348539cbd@github.com>
References: <4j1huMP8_l9vOcM1rRqPORdk5wXiAxl8TeATOp7E9Eg=.7be08dab-8183-4e94-8f6a-468348539cbd@github.com>
Message-ID: 

Changeset: 2a6ddbd8
Author:    Tobias Hartmann 
Date:      2020-03-31 09:08:05 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/2a6ddbd8

8241910: [lworld] C2 crashes due to duplicate storestore barrier added by JDK-8236522

! src/hotspot/share/opto/valuetypenode.cpp
! src/hotspot/share/opto/valuetypenode.hpp


From thartmann at openjdk.java.net  Tue Mar 31 09:19:33 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 31 Mar 2020 09:19:33 GMT
Subject: [lworld] RFR: 8241918: [lworld] Build failures after JDK-8236522
Message-ID: 

workspace/open/src/hotspot/share/utilities/stringUtils.cpp:276:13: error: 'bool class_list_match_sane()' declared
'static' but never defined [-Werror=unused-function] [2020-03-31T06:37:08,459Z] static bool class_list_match_sane();
[2020-03-31T06:37:08,459Z] ^~~~~~~~~~~~~~~~~~~~~
[2020-03-31T06:37:08,822Z] cc1plus: all warnings being treated as errors

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

Commit messages:
 - 8241918: [lworld] Build failures after JDK-8236522

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

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


From dsimms at openjdk.java.net  Tue Mar 31 09:51:29 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 31 Mar 2020 09:51:29 GMT
Subject: [lworld] RFR: 8241918: [lworld] Build failures after JDK-8236522
In-Reply-To: 
References: 
Message-ID: 

On Tue, 31 Mar 2020 09:14:04 GMT, Tobias Hartmann  wrote:

> workspace/open/src/hotspot/share/utilities/stringUtils.cpp:276:13: error: 'bool class_list_match_sane()' declared
> 'static' but never defined [-Werror=unused-function] [2020-03-31T06:37:08,459Z] static bool class_list_match_sane();
> [2020-03-31T06:37:08,459Z] ^~~~~~~~~~~~~~~~~~~~~
> [2020-03-31T06:37:08,822Z] cc1plus: all warnings being treated as errors

Looks good !

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

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


From thartmann at openjdk.java.net  Tue Mar 31 09:51:29 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 31 Mar 2020 09:51:29 GMT
Subject: [lworld] [Rev 01] RFR: 8241918: [lworld] Build failures after
 JDK-8236522
In-Reply-To: 
References: 
Message-ID: <6tMKXknDu6uBSS-ub-ZClXKaKNsCbQqquUYvtQEAIQE=.09378b59-59a6-45af-b888-1f198a6d8fa8@github.com>

> workspace/open/src/hotspot/share/utilities/stringUtils.cpp:276:13: error: 'bool class_list_match_sane()' declared
> 'static' but never defined [-Werror=unused-function] [2020-03-31T06:37:08,459Z] static bool class_list_match_sane();
> [2020-03-31T06:37:08,459Z] ^~~~~~~~~~~~~~~~~~~~~
> [2020-03-31T06:37:08,822Z] cc1plus: all warnings being treated as errors

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Removed const from function pointer and added cast to int

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/9/files
  - new: https://git.openjdk.java.net/valhalla/pull/9/files/b9819647..93cff9de

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

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

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


From dsimms at openjdk.java.net  Tue Mar 31 09:55:11 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 31 Mar 2020 09:55:11 GMT
Subject: [lworld] [Rev 01] RFR: 8241918: [lworld] Build failures after
 JDK-8236522
In-Reply-To: <6tMKXknDu6uBSS-ub-ZClXKaKNsCbQqquUYvtQEAIQE=.09378b59-59a6-45af-b888-1f198a6d8fa8@github.com>
References: 
 <6tMKXknDu6uBSS-ub-ZClXKaKNsCbQqquUYvtQEAIQE=.09378b59-59a6-45af-b888-1f198a6d8fa8@github.com>
Message-ID: 

On Tue, 31 Mar 2020 09:51:29 GMT, Tobias Hartmann  wrote:

>> workspace/open/src/hotspot/share/utilities/stringUtils.cpp:276:13: error: 'bool class_list_match_sane()' declared
>> 'static' but never defined [-Werror=unused-function] [2020-03-31T06:37:08,459Z] static bool class_list_match_sane();
>> [2020-03-31T06:37:08,459Z] ^~~~~~~~~~~~~~~~~~~~~
>> [2020-03-31T06:37:08,822Z] cc1plus: all warnings being treated as errors
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed const from function pointer and added cast to int

Looks good !

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

Marked as reviewed by dsimms (Committer).

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


From thartmann at openjdk.java.net  Tue Mar 31 10:45:53 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 31 Mar 2020 10:45:53 GMT
Subject: [Integrated] [lworld] RFR: 8241918: [lworld] Build failures after
 JDK-8236522
In-Reply-To: 
References: 
Message-ID: 

Changeset: ece2a2d3
Author:    Tobias Hartmann 
Date:      2020-03-31 10:44:57 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/ece2a2d3

8241918: [lworld] Build failures after JDK-8236522

Reviewed-by: dsimms

! src/hotspot/share/utilities/stringUtils.cpp


From rwestrel at redhat.com  Tue Mar 31 13:32:45 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 31 Mar 2020 15:32:45 +0200
Subject: [lworld] RFR: 8235753: [lworld] Handle deoptimization when
 buffering scalarized inline type args in C1
In-Reply-To: 
References: 
Message-ID: <87y2rgd4zm.fsf@redhat.com>


>  Webrev: https://webrevs.openjdk.java.net/valhalla/6/webrev.00

Ok.

Roland.



From tobias.hartmann at oracle.com  Tue Mar 31 13:47:34 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 31 Mar 2020 15:47:34 +0200
Subject: [lworld] RFR: 8235753: [lworld] Handle deoptimization when
 buffering scalarized inline type args in C1
In-Reply-To: <87y2rgd4zm.fsf@redhat.com>
References: 
 <87y2rgd4zm.fsf@redhat.com>
Message-ID: 

Thanks, Roland!

Best regards,
Tobias

On 31.03.20 15:32, Roland Westrelin wrote:
> 
>>  Webrev: https://webrevs.openjdk.java.net/valhalla/6/webrev.00
> 
> Ok.
> 
> Roland.
> 


From thartmann at openjdk.java.net  Tue Mar 31 13:48:51 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 31 Mar 2020 13:48:51 GMT
Subject: [Integrated] [lworld] RFR: 8235753: [lworld] Handle
 deoptimization when buffering scalarized inline type args in C1
In-Reply-To: 
References: 
Message-ID: <79702f6d-c019-447e-a092-d6d26c7e4ae1@openjdk.org>

Changeset: 0595ad08
Author:    Tobias Hartmann 
Date:      2020-03-31 13:48:23 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/0595ad08

8235753: [lworld] Handle deoptimization when buffering scalarized inline type args in C1

! 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/share/c1/c1_FrameMap.hpp
! src/hotspot/share/c1/c1_LIR.cpp
! src/hotspot/share/c1/c1_LIR.hpp
! src/hotspot/share/c1/c1_LIRAssembler.cpp
! src/hotspot/share/c1/c1_LIRAssembler.hpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_MacroAssembler.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/frame.cpp
! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestDeoptimizationWhenBuffering.java


From rriggs at openjdk.java.net  Tue Mar 31 13:56:46 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 31 Mar 2020 13:56:46 GMT
Subject: [Integrated] [lworld] RFR: Prototype inline cursors for List
In-Reply-To: 
References: 
Message-ID: <187b95ca-1c10-40d7-9758-e2ce6b0179e6@openjdk.org>

Changeset: d544758b
Author:    Roger Riggs 
Date:      2020-03-31 13:55:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d544758b

Prototype inline cursors for List

+ test/micro/org/openjdk/bench/valhalla/corelibs/InlineCursor.java
+ test/micro/org/openjdk/bench/valhalla/corelibs/XArrayList.java
+ test/micro/org/openjdk/bench/valhalla/corelibs/XArrayListCursorTest.java


From harold.seigel at oracle.com  Tue Mar 31 16:43:51 2020
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Tue, 31 Mar 2020 16:43:51 +0000
Subject: hg: valhalla/valhalla: Summary: Minor changes in response to review
 comments
Message-ID: <202003311643.02VGhpS3026246@aojmv0008.oracle.com>

Changeset: d30b62c68646
Author:    hseigel
Date:      2020-03-31 16:43 +0000
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/d30b62c68646

Summary: Minor changes in response to review comments
Reviewed-by: mchung

! src/hotspot/share/ci/ciInstanceKlass.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java



From mandy.chung at oracle.com  Tue Mar 31 18:06:58 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 31 Mar 2020 11:06:58 -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: <940c6907-612e-8744-376c-5362991d4a42@oracle.com>

This patch addresses Joe's feedback on the CSR [1]:

http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-jdarcy/

Specifically, it adds to the class specification of java.lang.Class to 
describe how the relevant methods behave for hidden classes.? In 
addition, use the new inline @jvms tag.

Thanks
Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8238359

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 
>
>
> 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  Tue Mar 31 18:34:29 2020
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 31 Mar 2020 18:34:29 +0000
Subject: hg: valhalla/valhalla: [nestmates] add more test cases for hidden
 classes
Message-ID: <202003311834.02VIYU3U029845@aojmv0008.oracle.com>

Changeset: 40500443661b
Author:    mchung
Date:      2020-03-31 11:34 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/40500443661b

[nestmates] add more test cases for hidden classes

! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
+ test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenAnnotation.java
+ test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenEnum.java
+ test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenRecord.java



From john.r.rose at oracle.com  Tue Mar 31 19:11:03 2020
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 31 Mar 2020 12:11:03 -0700
Subject: [Integrated] [lworld] RFR: 8241918: [lworld] Build failures after
 JDK-8236522
In-Reply-To: 
References: 
 
Message-ID: 

Thanks for the bail-out.  Sorry about the mess.  ? John

On Mar 31, 2020, at 3:45 AM, Tobias Hartmann  wrote:
> 
> Changeset: ece2a2d3
> Author:    Tobias Hartmann 
> Date:      2020-03-31 10:44:57 +0000
> URL:       https://git.openjdk.java.net/valhalla/commit/ece2a2d3
> 
> 8241918: [lworld] Build failures after JDK-8236522
> 
> Reviewed-by: dsimms
> 
> ! src/hotspot/share/utilities/stringUtils.cpp



From mandy.chung at oracle.com  Tue Mar 31 19:25:53 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 31 Mar 2020 12:25:53 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
In-Reply-To: <940c6907-612e-8744-376c-5362991d4a42@oracle.com>
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
 <940c6907-612e-8744-376c-5362991d4a42@oracle.com>
Message-ID: 

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`.

Mandy

On 3/31/20 11:06 AM, Mandy Chung wrote:
> This patch addresses Joe's feedback on the CSR [1]:
>
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-jdarcy/ 
>
>
> Specifically, it adds to the class specification of java.lang.Class to 
> describe how the relevant methods behave for hidden classes.? In 
> addition, use the new inline @jvms tag.
>
> Thanks
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8238359
>
> 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 
>>
>>
>> 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  Tue Mar 31 23:09:25 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 31 Mar 2020 16:09:25 -0700
Subject: RFR: [nestmates] rename Class::isHiddenClass to Class::isHidden
Message-ID: 

Alex observes that a class or interface can be hidden and so he suggest 
to rename `isHiddenClass` to `isHidden` as it's not limited to class only.

`isHidden` is like `isSynthetic`, it could be a class or interface.

`isLocalClass` and `sAnonymousClass` are specific for class only because 
the Java language only has local classes and anon classes, not local 
interfaces or anon. interfaces. `isMemberClass` isn't correct since it 
can be a class or interface.

Webrev:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-rename-isHidden/

Thanks
Mandy



From david.holmes at oracle.com  Tue Mar 31 23:45:24 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 1 Apr 2020 09:45:24 +1000
Subject: RFR: [nestmates] rename Class::isHiddenClass to Class::isHidden
In-Reply-To: 
References: 
Message-ID: <101a2c36-9bbc-8020-45ee-65f00983e7e2@oracle.com>

Hi Mandy,

The rename looks good. The misc import cleanups are also good. :)

Thanks,
David

On 1/04/2020 9:09 am, Mandy Chung wrote:
> Alex observes that a class or interface can be hidden and so he suggest 
> to rename `isHiddenClass` to `isHidden` as it's not limited to class only.
> 
> `isHidden` is like `isSynthetic`, it could be a class or interface.
> 
> `isLocalClass` and `sAnonymousClass` are specific for class only because 
> the Java language only has local classes and anon classes, not local 
> interfaces or anon. interfaces. `isMemberClass` isn't correct since it 
> can be a class or interface.
> 
> Webrev:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-rename-isHidden/ 
> 
> 
> Thanks
> Mandy
> 


From mandy.chung at oracle.com  Tue Mar 31 23:52:48 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 31 Mar 2020 16:52:48 -0700
Subject: RFR: [nestmates] rename Class::isHiddenClass to Class::isHidden
In-Reply-To: <101a2c36-9bbc-8020-45ee-65f00983e7e2@oracle.com>
References: 
 <101a2c36-9bbc-8020-45ee-65f00983e7e2@oracle.com>
Message-ID: <41e37f64-989a-defb-2291-5f596e44c487@oracle.com>

Thanks David.

Mandy

On 3/31/20 4:45 PM, David Holmes wrote:
> Hi Mandy,
>
> The rename looks good. The misc import cleanups are also good. :)
>
> Thanks,
> David
>
> On 1/04/2020 9:09 am, Mandy Chung wrote:
>> Alex observes that a class or interface can be hidden and so he 
>> suggest to rename `isHiddenClass` to `isHidden` as it's not limited 
>> to class only.
>>
>> `isHidden` is like `isSynthetic`, it could be a class or interface.
>>
>> `isLocalClass` and `sAnonymousClass` are specific for class only 
>> because the Java language only has local classes and anon classes, 
>> not local interfaces or anon. interfaces. `isMemberClass` isn't 
>> correct since it can be a class or interface.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-rename-isHidden/ 
>>
>>
>> Thanks
>> Mandy
>>



From mandy.chung at oracle.com  Tue Mar 31 23:54:59 2020
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 31 Mar 2020 23:54:59 +0000
Subject: hg: valhalla/valhalla: [nestmates] Rename Class:isHiddenClass to
 isHidden per Alex's feedback
Message-ID: <202003312354.02VNsxgT000278@aojmv0008.oracle.com>

Changeset: fb5c34c883b5
Author:    mchung
Date:      2020-03-31 16:54 -0700
URL:       https://hg.openjdk.java.net/valhalla/valhalla/rev/fb5c34c883b5

[nestmates] Rename Class:isHiddenClass to isHidden per Alex's feedback
Reviewed-by: dholmes

! src/hotspot/share/classfile/vmSymbols.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/library_call.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java
! src/java.base/share/classes/java/lang/reflect/Field.java
! src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java
! src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java
! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
! src/java.base/share/classes/jdk/internal/reflect/UnsafeFieldAccessorFactory.java
! src/java.base/share/native/libjava/Class.c
! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java
! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/P/Q/HiddenClassSigTest.java
! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp
! test/jdk/java/lang/instrument/HiddenClass/HiddenClassAgent.java
! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/DefineClassWithClassData.java
! test/jdk/java/lang/invoke/defineHiddenClass/HiddenNestmateTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/LambdaNestedInnerTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/UnreflectTest.java
! test/jdk/java/lang/invoke/nestmates/NestmateTest.java
! test/jdk/java/lang/reflect/AccessibleObject/HiddenClassTest.java
! test/jdk/sun/misc/UnsafeFieldOffsets.java