From frederic.parain at oracle.com Mon Dec 2 15:40:37 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 2 Dec 2019 10:40:37 -0500 Subject: RFR: 8234633 [lworld] Create fast path for aaload/aastore of inlined values In-Reply-To: <7d000703-4553-e315-5982-761ed44f57e6@oracle.com> References: <7d000703-4553-e315-5982-761ed44f57e6@oracle.com> Message-ID: Looks good to me. Minor style comment: interp_masm_x86.cpp:1285 could be re-written: movptr(at_rsp(), obj); Fred > On Nov 27, 2019, at 11:13, David Simms wrote: > > > Bug/RFE: https://bugs.openjdk.java.net/browse/JDK-8234633 > > Webrev: http://cr.openjdk.java.net/~dsimms/valhalla/8234633/webrev0/ > > > Continued hand rolling assembler, new for aaload and aastore. > > Added "MacroAssembler::data_for_value_array_index()" provides similar operation to "valueArrayOopDesc::value_at_addr". > > > /David Simms > > > From maurizio.cimadamore at oracle.com Mon Dec 2 15:50:27 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 2 Dec 2019 15:50:27 +0000 Subject: Hidden classes + class data In-Reply-To: References: <871949138.2149512.1574434660660.JavaMail.zimbra@u-pem.fr> <94ddd5c6-9729-e03f-9246-e30e83267c02@oracle.com> <65152B04-2358-46C6-828E-A0700E43BEF6@oracle.com> <1737758747.13944.1574809432804.JavaMail.zimbra@u-pem.fr> <66898D0F-53EE-42C8-AC9E-288BE7400DA3@oracle.com> Message-ID: <4a397388-1fea-a99d-941b-a74296675de8@oracle.com> On 27/11/2019 01:30, Mandy Chung wrote: > > > On 11/26/19 4:55 PM, John Rose wrote: >> On Nov 26, 2019, at 3:03 PM, forax at univ-mlv.fr wrote: >>> I wonder if defineHiddenClassWithClassData should not take another >>> class as parameter instead of a byte array (using the byte array of >>> that class) enabling more sharing of the bytecode and allowing to do >>> the? verification only once if defineHiddenClassWithClassData is >>> called several times with the same Class. >> Yes.? I?d like to try this with templates, when we get them, since >> templates are supposed to share metadata with their species. >> >> E.g., for a lambda form of a predefined shape with 2 free variables >> (a type and a MH), define it as a template with those parameters >> and inject it as many times as you see distinct combinations of >> those parameters. > > This produces a distinct Class mirror for each hidden class defined > from the same metadata (class bytes) with a different class data. > > Perhaps we can experiment ClassDefiner builder-like API.?? I will > explore this. In the MVT Valhalla prototype we used to have a way to obtain a method handle using a 'method builder' (from the bytecode API used there). I think it should be possible to do the same, using a 'class builder' - so that you can actually define the contents of the class w/o specifying a byte array, down to the code attribute level. In other words, there is a big overlap with what you call a 'ClassDefiner' builder and the builders provided by the bytecode API under exploration, so I think it'd be best to try and avoid to solve the same problem twice. Maurizio > > Mandy From maurizio.cimadamore at oracle.com Mon Dec 2 15:54:02 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 2 Dec 2019 15:54:02 +0000 Subject: RFR: JNI support for flattened arrays In-Reply-To: References: Message-ID: <60a276fc-b9d7-4a08-cd96-e7f27a7b8528@oracle.com> Looks nice - at some point I'd like to experiment with this on the Panama side to e.g. build a Layout object out of an inline class which does not (transitively) contain oops. Then we could easily create an heap-based inline array, then move it off-heap using an array segment with the required layout. Maurizio On 22/11/2019 21:08, Frederic Parain wrote: > Please review these changes adding JNI support for flattened arrays. > > The model for accessing flattened arrays from native code is the same > as for primitive arrays, with these two new methods: > > void* (JNICALL *GetFlattenedArrayElements) > (JNIEnv* env, jarray array , jboolean *isCopy); > void (JNICALL *ReleaseFlattenedArrayElements) > (JNIEnv* env, jarray, void* elem, jint mode); > > Native access to inline types arrays is allowed only if the array is > flattened and array elements do not contain oops. > > However, native code needs more information to deal with inline types > arrays: > > In order to get the size of an element of the array: > > jsize (JNICALL *GetFlattenedArrayElementSize) > (JNIEnv* env, jarray array); > > In order to get the class of the array elements: > > jclass (JNICALL *GetFlattenedArrayElementClass) > (JNIEnv* env, jarray array); > > > An in order to get the offset of a field inside an array element, or > inside a flattened field: > > jsize (JNICALL *GetFieldOffsetInFlattenedLayout) > (JNIEnv* env, jclass clazz, const char *name, const char *signature, jboolean* isFlattened); > > The webrev includes tests showing examples on how to interact with > a flattened array from native code (initialization, update, sorting). > > Webrev: > http://cr.openjdk.java.net/~fparain/jniflattenedarrays/webrev.00/index.html > > Thank you, > > Fred > > From frederic.parain at oracle.com Mon Dec 2 16:03:33 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 2 Dec 2019 11:03:33 -0500 Subject: RFR: 8235190 [lworld] Add fastpath to access uninitialized inline fields Message-ID: <46EBFC10-B496-4A40-B204-B249E790A7BB@oracle.com> Please review these interpreter changes adding fastpaths when accessing uninitialized inline fields: CR: https://bugs.openjdk.java.net/browse/JDK-8235190 Webrev: http://cr.openjdk.java.net/~fparain/8235190/webrev.00/index.html Thank you, Fred From mandy.chung at oracle.com Mon Dec 2 19:55:59 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 Dec 2019 11:55:59 -0800 Subject: Hidden classes + class data In-Reply-To: <4a397388-1fea-a99d-941b-a74296675de8@oracle.com> References: <871949138.2149512.1574434660660.JavaMail.zimbra@u-pem.fr> <94ddd5c6-9729-e03f-9246-e30e83267c02@oracle.com> <65152B04-2358-46C6-828E-A0700E43BEF6@oracle.com> <1737758747.13944.1574809432804.JavaMail.zimbra@u-pem.fr> <66898D0F-53EE-42C8-AC9E-288BE7400DA3@oracle.com> <4a397388-1fea-a99d-941b-a74296675de8@oracle.com> Message-ID: On 12/2/19 7:50 AM, Maurizio Cimadamore wrote: > > On 27/11/2019 01:30, Mandy Chung wrote: >> >> >> On 11/26/19 4:55 PM, John Rose wrote: >>> On Nov 26, 2019, at 3:03 PM, forax at univ-mlv.fr wrote: >>>> I wonder if defineHiddenClassWithClassData should not take another >>>> class as parameter instead of a byte array (using the byte array of >>>> that class) enabling more sharing of the bytecode and allowing to >>>> do the? verification only once if defineHiddenClassWithClassData is >>>> called several times with the same Class. >>> Yes.? I?d like to try this with templates, when we get them, since >>> templates are supposed to share metadata with their species. >>> >>> E.g., for a lambda form of a predefined shape with 2 free variables >>> (a type and a MH), define it as a template with those parameters >>> and inject it as many times as you see distinct combinations of >>> those parameters. >> >> This produces a distinct Class mirror for each hidden class defined >> from the same metadata (class bytes) with a different class data. >> >> Perhaps we can experiment ClassDefiner builder-like API.?? I will >> explore this. > > In the MVT Valhalla prototype we used to have a way to obtain a method > handle using a 'method builder' (from the bytecode API used there). I > think it should be possible to do the same, using a 'class builder' - > so that you can actually define the contents of the class w/o > specifying a byte array, down to the code attribute level. In other > words, there is a big overlap with what you call a 'ClassDefiner' > builder and the builders provided by the bytecode API under > exploration, so I think it'd be best to try and avoid to solve the > same problem twice. > Yes I remember that.? I agree and we should avoid solving the same problem twice.? There was a plan to include the bytecode API in the JDK.?? Any update/news on that? Mandy From david.simms at oracle.com Tue Dec 3 09:10:22 2019 From: david.simms at oracle.com (David Simms) Date: Tue, 3 Dec 2019 10:10:22 +0100 Subject: RFR: 8235190 [lworld] Add fastpath to access uninitialized inline fields In-Reply-To: <46EBFC10-B496-4A40-B204-B249E790A7BB@oracle.com> References: <46EBFC10-B496-4A40-B204-B249E790A7BB@oracle.com> Message-ID: <47da5165-d9bf-c5ef-e87c-d73b6582fda1@oracle.com> Looks good ! On 2/12/19 5:03 pm, Frederic Parain wrote: > Please review these interpreter changes adding fastpaths when > accessing uninitialized inline fields: > > CR: https://bugs.openjdk.java.net/browse/JDK-8235190 > > Webrev: > http://cr.openjdk.java.net/~fparain/8235190/webrev.00/index.html > > Thank you, > > Fred > From david.simms at oracle.com Tue Dec 3 09:15:08 2019 From: david.simms at oracle.com (David Simms) Date: Tue, 3 Dec 2019 10:15:08 +0100 Subject: RFR: 8234633 [lworld] Create fast path for aaload/aastore of inlined values In-Reply-To: References: <7d000703-4553-e315-5982-761ed44f57e6@oracle.com> Message-ID: <96d55548-fa2d-fa74-a9fc-5afd3d9c62bf@oracle.com> Thanks for looking at this Frederic, good spotting the at_rsp short hand, comment applied On 2/12/19 4:40 pm, Frederic Parain wrote: > Looks good to me. > > Minor style comment: > > interp_masm_x86.cpp:1285 > > could be re-written: > > movptr(at_rsp(), obj); > > Fred > > >> On Nov 27, 2019, at 11:13, David Simms wrote: >> >> >> Bug/RFE: https://bugs.openjdk.java.net/browse/JDK-8234633 >> >> Webrev: http://cr.openjdk.java.net/~dsimms/valhalla/8234633/webrev0/ >> >> >> Continued hand rolling assembler, new for aaload and aastore. >> >> Added "MacroAssembler::data_for_value_array_index()" provides similar operation to "valueArrayOopDesc::value_at_addr". >> >> >> /David Simms >> >> >> From david.simms at oracle.com Tue Dec 3 09:22:09 2019 From: david.simms at oracle.com (David Simms) Date: Tue, 3 Dec 2019 10:22:09 +0100 Subject: RFR: 8234633 [lworld] Create fast path for aaload/aastore of inlined values In-Reply-To: <96d55548-fa2d-fa74-a9fc-5afd3d9c62bf@oracle.com> References: <7d000703-4553-e315-5982-761ed44f57e6@oracle.com> <96d55548-fa2d-fa74-a9fc-5afd3d9c62bf@oracle.com> Message-ID: <3b43d9f3-2dce-8bad-c826-94a0c036a0e5@oracle.com> "at_rsp()" was of course private to templateTable, but "store_ptr()" seems more suitable from InterpreterMacroAssembler On 3/12/19 10:15 am, David Simms wrote: > > Thanks for looking at this Frederic, good spotting the at_rsp short > hand, comment applied > > On 2/12/19 4:40 pm, Frederic Parain wrote: >> Looks good to me. >> >> Minor style comment: >> >> interp_masm_x86.cpp:1285 >> >> could be re-written: >> >> movptr(at_rsp(), obj); >> >> Fred >> >> >>> On Nov 27, 2019, at 11:13, David Simms wrote: >>> >>> >>> Bug/RFE: https://bugs.openjdk.java.net/browse/JDK-8234633 >>> >>> Webrev: http://cr.openjdk.java.net/~dsimms/valhalla/8234633/webrev0/ >>> >>> >>> Continued hand rolling assembler, new for aaload and aastore. >>> >>> Added "MacroAssembler::data_for_value_array_index()" provides >>> similar operation to "valueArrayOopDesc::value_at_addr". >>> >>> >>> /David Simms >>> >>> >>> > From david.simms at oracle.com Tue Dec 3 09:32:55 2019 From: david.simms at oracle.com (david.simms at oracle.com) Date: Tue, 03 Dec 2019 09:32:55 +0000 Subject: hg: valhalla/valhalla: 8234633: lworld] Create fast path for aaload/aastore of inlined values Message-ID: <201912030932.xB39Wtif024138@aojmv0008.oracle.com> Changeset: 9e2818af0a07 Author: dsimms Date: 2019-12-03 10:24 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/9e2818af0a07 8234633: lworld] Create fast path for aaload/aastore of inlined values Reviewed-by: fparain ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/templateTable_x86.cpp From jesper at selskabet.org Tue Dec 3 12:31:56 2019 From: jesper at selskabet.org (=?UTF-8?Q?Jesper_Steen_M=C3=B8ller?=) Date: Tue, 3 Dec 2019 13:31:56 +0100 Subject: New Valhalla contributor Message-ID: Hello "gods and mortals of Valhalla", I just signed up as a contributor, more or less as direct consequence of hearing Tobi Ajilas talk at DEVOXX Belgium (https://devoxx.be/talk/?id=41660). Interesting stuff! I've always liked working on compilers, and been an independent OpenSource contributor in the past, primarily on Eclipse WTP (XPath 2 engine and XSL tooling) and on Eclipse JDT (some work on Java 8 support). Other programming language interest include Rust (since 2018), but I have a background with C and C++. Kind regards Jesper From frederic.parain at oracle.com Tue Dec 3 13:34:04 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 3 Dec 2019 08:34:04 -0500 Subject: RFR: 8235190 [lworld] Add fastpath to access uninitialized inline fields In-Reply-To: <47da5165-d9bf-c5ef-e87c-d73b6582fda1@oracle.com> References: <46EBFC10-B496-4A40-B204-B249E790A7BB@oracle.com> <47da5165-d9bf-c5ef-e87c-d73b6582fda1@oracle.com> Message-ID: <1E7D01C8-26BF-44A1-BC36-E334DE3B9A2B@oracle.com> Thank you for the review. Fred > On Dec 3, 2019, at 04:10, David Simms wrote: > > > Looks good ! > > On 2/12/19 5:03 pm, Frederic Parain wrote: >> Please review these interpreter changes adding fastpaths when >> accessing uninitialized inline fields: >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8235190 >> >> Webrev: >> http://cr.openjdk.java.net/~fparain/8235190/webrev.00/index.html >> >> Thank you, >> >> Fred >> > > From frederic.parain at oracle.com Tue Dec 3 13:36:39 2019 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Tue, 03 Dec 2019 13:36:39 +0000 Subject: hg: valhalla/valhalla: 8235190: [lworld] Add fastpath to access uninitialized inline fields Message-ID: <201912031336.xB3Dadi6016232@aojmv0008.oracle.com> Changeset: 31bfb68ec5ca Author: fparain Date: 2019-12-03 08:35 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/31bfb68ec5ca 8235190: [lworld] Add fastpath to access uninitialized inline fields Reviewed-by: dsimms ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp From tobias.hartmann at oracle.com Tue Dec 3 16:52:35 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Tue, 03 Dec 2019 16:52:35 +0000 Subject: hg: valhalla/valhalla: 8235254: [lworld] TestNativeClone crashes in PhaseMacroExpand::expand_arraycopy_node() with ZGC Message-ID: <201912031652.xB3Gqasf020794@aojmv0008.oracle.com> Changeset: 7ec4118062f9 Author: thartmann Date: 2019-12-03 17:52 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7ec4118062f9 8235254: [lworld] TestNativeClone crashes in PhaseMacroExpand::expand_arraycopy_node() with ZGC ! src/hotspot/share/opto/macroArrayCopy.cpp From tobias.hartmann at oracle.com Tue Dec 3 17:06:03 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Tue, 03 Dec 2019 17:06:03 +0000 Subject: hg: valhalla/valhalla: 8235253: [lworld] TestStressReturnBuffering fails with ZGC Message-ID: <201912031706.xB3H64IW029900@aojmv0008.oracle.com> Changeset: d6ecf9333bc1 Author: thartmann Date: 2019-12-03 18:05 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d6ecf9333bc1 8235253: [lworld] TestStressReturnBuffering fails with ZGC ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestStressReturnBuffering.java From mandy.chung at oracle.com Thu Dec 5 01:13:25 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 4 Dec 2019 17:13:25 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes Message-ID: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> Draft JEP: ? https://bugs.openjdk.java.net/browse/JDK-8220607 The past discussion was tracked in JDK-8171335 [1] regarding dynamic nestmates and the replacement of Unsafe::defineAnonymousClass which consists of four separable features: 1. non-discoverable and cannot participate in symbolic resolution 2. lifecycle is independent of its defining class loader 3. private member access of the given host class 4. constant pool patching The JEP proposes to support a new kind of classes: "hidden classes" that can optionally join as a member of a nest and/or can be weakly referenced by its defining class loader. It covers 1-3 above. ? 4 is separated from this JEP to give time to explore the class data support that may benefit to prototype with template classes. javadoc and specdiff: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ The current prototype is in the nestmates branch and all JDK use of Unsafe::defineAnonymousClass are replaced with hidden classes [3]. thanks Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8171335 [2] https://bugs.openjdk.java.net/browse/JDK-8230501 [3] http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/ From david.simms at oracle.com Thu Dec 5 08:31:12 2019 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 05 Dec 2019 08:31:12 +0000 Subject: hg: valhalla/valhalla: 103 new changesets Message-ID: <201912050831.xB58VM2w019031@aojmv0008.oracle.com> Changeset: bdf999e08a3a Author: cgo Date: 2019-11-27 10:13 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/bdf999e08a3a 8234807: [TESTBUG] LoopRotateBadNodeBudget fails for client VMs due to Unrecognized VM option PartialPeelNewPhiDelta Reviewed-by: kvn ! test/hotspot/jtreg/compiler/loopopts/LoopRotateBadNodeBudget.java Changeset: fc216dcef2bb Author: fyang Date: 2019-11-04 16:10 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/fc216dcef2bb 8233466: aarch64: remove unnecessary load of mdo when profiling return and parameters type Reviewed-by: adinn ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp Changeset: 70f49f08c9e6 Author: cgo Date: 2019-11-28 16:11 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/70f49f08c9e6 8234894: [TESTBUG] TestEliminateLocksOffCrash fails for client VMs due to Unrecognized VM option EliminateLocks Reviewed-by: thartmann ! test/hotspot/jtreg/compiler/escapeAnalysis/TestEliminateLocksOffCrash.java Changeset: be238525d240 Author: lucy Date: 2019-11-28 16:28 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/be238525d240 8234583: PrintAssemblyOptions isn't passed to hsdis library Reviewed-by: vlivanov, mdoerr ! src/hotspot/share/compiler/disassembler.cpp Changeset: 72f3dd43dd28 Author: egahlin Date: 2019-11-28 16:38 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/72f3dd43dd28 8234888: EventStream::close doesn't abort streaming thread Reviewed-by: mgronlun, mseledtsov ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! test/jdk/jdk/jfr/api/consumer/recordingstream/TestClose.java Changeset: b42eaca7d234 Author: jboes Date: 2019-11-28 13:02 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b42eaca7d234 8233185: HttpServer.stop() blocks indefinitely when called on dispatch thread Summary: Skip dispatcherThread.join() if current thread is the dispatcherThread Reviewed-by: dfuchs, msheppar, vtewari ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java + test/jdk/com/sun/net/httpserver/HttpServerTest.java Changeset: 43eee1237934 Author: cito Date: 2019-11-28 18:30 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/43eee1237934 8232594: Make the output of the JFR command duration more user friendly Reviewed-by: egahlin, cito Contributed-by: chiroito107 at gmail.com, erik.gahlin at oracle.com ! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java + test/jdk/jdk/jfr/jvm/TestFormatDuration.java Changeset: 6f12009ea9d7 Author: pconcannon Date: 2019-11-28 16:49 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6f12009ea9d7 8233307: MulticastSocket getOption(IP_MULTICAST_IF) returns interface when not set Summary: The MulticastSocket method getOption has been changed to conform to the behavior described in StandardSocketOptions.IP_MULTICAST_IF. Reviewed-by: chegar, dfuchs ! src/java.base/share/classes/java/net/MulticastSocket.java ! src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c ! src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c + test/jdk/java/net/NetworkInterface/NoSetNetworkInterface.java Changeset: f29e5cd27300 Author: rhalade Date: 2019-11-28 10:43 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f29e5cd27300 8233223: Add Amazon Root CA certificates Reviewed-by: mullan + make/data/cacerts/amazonrootca1 + make/data/cacerts/amazonrootca2 + make/data/cacerts/amazonrootca3 + make/data/cacerts/amazonrootca4 + test/jdk/security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: e0d919d7c1a6 Author: jjiang Date: 2019-11-29 14:07 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e0d919d7c1a6 8234724: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java supports TLSv1.3 Reviewed-by: xuelei ! test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: 753ab8dcdbba Author: ssahoo Date: 2019-11-28 22:29 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/753ab8dcdbba 8234723: javax/net/ssl/TLS tests support TLSv1.3 Summary: Missing TLSv1.3 test cases Reviewed-by: xuelei ! test/jdk/javax/net/ssl/TLS/TLSClientPropertyTest.java ! test/jdk/javax/net/ssl/TLS/TestJSSEClientDefaultProtocol.java ! test/jdk/javax/net/ssl/TLS/TestJSSEClientProtocol.java ! test/jdk/javax/net/ssl/TLS/TestJSSEServerProtocol.java Changeset: 7089399d6ade Author: mbaesken Date: 2019-11-28 09:23 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7089399d6ade 8234625: hs test serviceability/sa/ClhsdbCDSCore.java fails on macOS 10.15 Reviewed-by: clanger, iignatyev ! test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java Changeset: 70021dbed82b Author: bulasevich Date: 2019-11-29 11:28 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/70021dbed82b 8234893: ARM32: build failure after JDK-8234387 Reviewed-by: vlivanov ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/arm_32.ad Changeset: 9ee940f1de90 Author: tschatzl Date: 2019-11-29 10:20 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/9ee940f1de90 8227739: Merge cost predictions for scanning cards and log buffer entries Summary: Revamp the cost predictions for the changes in JDK-8200545 and JDK-8213108. Reviewed-by: sjohanss, kbarrett ! src/hotspot/share/gc/g1/g1Analytics.cpp ! src/hotspot/share/gc/g1/g1Analytics.hpp ! src/hotspot/share/gc/g1/g1CardTable.hpp ! src/hotspot/share/gc/g1/g1CardTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp ! src/hotspot/share/gc/g1/g1HotCardCache.cpp ! src/hotspot/share/gc/g1/g1HotCardCache.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: 11ff4e485670 Author: tschatzl Date: 2019-11-29 10:20 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/11ff4e485670 8227434: G1 predictions may over/underflow with high variance input Summary: Clamp G1 prediction output to sensible values. Reviewed-by: lkorinth, sjohanss ! src/hotspot/share/gc/g1/g1Analytics.cpp ! src/hotspot/share/gc/g1/g1Analytics.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1IHOPControl.cpp ! src/hotspot/share/gc/g1/g1IHOPControl.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Predictions.hpp ! src/hotspot/share/gc/g1/survRateGroup.cpp ! test/hotspot/gtest/gc/g1/test_g1Predictions.cpp Changeset: 5775e4825e58 Author: tschatzl Date: 2019-11-29 10:20 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5775e4825e58 8233998: New young regions registered too early in collection set Reviewed-by: sangheki, sjohanss ! src/hotspot/share/gc/g1/g1CollectionSet.cpp Changeset: ae2eb76c486d Author: mbaesken Date: 2019-11-28 13:02 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ae2eb76c486d 8234821: remove unused functions from libjli Reviewed-by: clanger, alanb ! src/java.base/macosx/native/libjli/java_md_macosx.m ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h ! src/java.base/unix/native/libjli/java_md_common.c ! src/java.base/unix/native/libjli/java_md_solinux.c ! src/java.base/windows/native/libjli/java_md.c Changeset: 5e8f9713e343 Author: neliasso Date: 2019-11-29 11:26 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5e8f9713e343 8234520: ZGC: C2: Oop instance cloning causing skipped compiles Reviewed-by: pliden, vlivanov ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/gc/z/zBarrierSetRuntime.cpp ! src/hotspot/share/gc/z/zBarrierSetRuntime.hpp ! src/hotspot/share/opto/arraycopynode.hpp Changeset: 3636bab5e81e Author: rehn Date: 2019-11-29 12:09 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3636bab5e81e 8234086: VM operation can be simplified Reviewed-by: kbarrett, dholmes, dcubed ! src/hotspot/share/jfr/leakprofiler/utilities/vmOperation.hpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp ! src/hotspot/share/runtime/biasedLocking.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/vmOperations.cpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! test/hotspot/gtest/threadHelper.inline.hpp Changeset: 851a389fc54d Author: adinn Date: 2019-11-29 15:37 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/851a389fc54d 8232828: AArch64: compiler/c2/aarch64/TestVolatilesG1.java fails after JDK-8225776 Reviewed-by: aph ! test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java Changeset: 2c3578aa0bdf Author: egahlin Date: 2019-11-29 17:31 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2c3578aa0bdf 8234671: JFR api/consumer/recordingstream/TestStart.java failed due to timeout at testStartTwice() Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/StreamConfiguration.java ! test/jdk/jdk/jfr/api/consumer/recordingstream/TestClose.java ! test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnEvent.java Changeset: f280911d3427 Author: iklam Date: 2019-11-29 14:11 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f280911d3427 8230385: [cds] No message is logged when shared image cannot be used due to mismatched configuration Reviewed-by: stuefe, dholmes, ccheung ! src/hotspot/share/runtime/arguments.cpp Changeset: 289000934908 Author: alanb Date: 2019-11-30 16:21 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/289000934908 8234805: (dc) Remove JNI upcall from DatagramChannel.receive implementation Reviewed-by: dfuchs, chegar ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java + src/java.base/share/classes/sun/nio/ch/NativeSocketAddress.java + src/java.base/share/native/libnio/ch/NativeSocketAddress.c ! src/java.base/unix/native/libnio/ch/DatagramChannelImpl.c ! src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c + test/jdk/java/nio/channels/DatagramChannel/ManySenders.java Changeset: 5b96c12f909d Author: phh Date: 2019-11-30 14:33 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5b96c12f909d 8234541: C1 emits an empty message when it inlines successfully Summary: Use "inline" as the message when successfull Reviewed-by: thartmann, mdoerr Contributed-by: navy.xliu at gmail.com ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_GraphBuilder.hpp Changeset: 5028793d05ff Author: igerasim Date: 2019-12-01 15:29 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5028793d05ff 8234147: Avoid looking up standard charsets in core libraries Reviewed-by: alanb ! src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/java.base/share/classes/com/sun/security/ntlm/NTLM.java ! src/java.base/share/classes/java/io/InputStreamReader.java ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/lang/CharacterName.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/SocksSocketImpl.java ! src/java.base/share/classes/java/net/URI.java ! src/java.base/share/classes/java/nio/file/FileChannelLinesSpliterator.java ! src/java.base/share/classes/java/nio/file/Files.java ! src/java.base/share/classes/java/util/Base64.java ! src/java.base/share/classes/java/util/Properties.java ! src/java.base/share/classes/java/util/PropertyResourceBundle.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/jar/Attributes.java ! src/java.base/share/classes/java/util/jar/Manifest.java ! src/java.base/share/classes/java/util/zip/ZipCoder.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/java/util/zip/ZipInputStream.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java ! src/java.base/share/classes/jdk/internal/module/IllegalAccessMaps.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/perf/Perf.java ! src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java ! src/java.base/share/classes/sun/net/www/ParseUtil.java ! src/java.base/share/classes/sun/net/www/http/ChunkedInputStream.java ! src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java ! src/java.base/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/java.base/share/classes/sun/nio/cs/ThreadLocalCoders.java ! src/java.base/share/classes/sun/util/PropertyResourceBundleCharset.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! src/java.prefs/share/classes/java/util/prefs/XmlSupport.java ! src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java ! test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java Changeset: 8dcd966f7fd4 Author: jlahoda Date: 2019-12-02 10:58 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8dcd966f7fd4 8233524: Wrong module name for \"package P is declared in the unnamed module, but module M does not read it\" Summary: Using the correct placeholder for the module name. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: f5f494bd4d3e Author: jlahoda Date: 2019-12-02 10:58 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f5f494bd4d3e 8234078: Missing license headers in a few javac files Reviewed-by: vromero ! make/langtools/tools/propertiesparser/resources/templates.properties ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java - src/jdk.compiler/share/classes/META-INF/services/com.sun.tools.javac.platform.PlatformProvider - src/jdk.compiler/share/classes/com/sun/tools/javac/services/javax.tools.JavaCompilerTool Changeset: e199f4a62e66 Author: tschatzl Date: 2019-12-02 14:21 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e199f4a62e66 8233919: Incrementally calculate the occupied cards in a heap region remembered set Summary: Instead of iterating over the remembered set card containers, continuously update a single counter per remembered set about occupancy. Reviewed-by: sangheki, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! src/hotspot/share/gc/g1/sparsePRT.cpp ! src/hotspot/share/gc/g1/sparsePRT.hpp + src/hotspot/share/gc/g1/sparsePRT.inline.hpp Changeset: 7dfcc42ad35b Author: tschatzl Date: 2019-12-02 14:21 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7dfcc42ad35b 8233588: Clean up SurvRateGroup Summary: Remove unnecessary members, enforce stricter visibility within use. Reviewed-by: sangheki, kbarrett ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/g1/survRateGroup.cpp ! src/hotspot/share/gc/g1/survRateGroup.hpp Changeset: d1b2fa77e75e Author: tschatzl Date: 2019-12-02 14:21 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d1b2fa77e75e 8231579: G1's incremental calculation of region elapsed time always uses the same age group for prediction Summary: Separate calculation of time required for copying objects from non-copy time. Calculate the former in bulk, and the latter as usual, combining them as needed. Reviewed-by: sjohanss, kbarrett ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp Changeset: 676eb5c4a3e4 Author: tschatzl Date: 2019-12-02 14:21 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/676eb5c4a3e4 8234574: Rename prediction methods in G1Analytics Reviewed-by: sjohanss, sangheki ! src/hotspot/share/gc/g1/g1Analytics.cpp ! src/hotspot/share/gc/g1/g1Analytics.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1IHOPControl.cpp ! src/hotspot/share/gc/g1/g1IHOPControl.hpp ! src/hotspot/share/gc/g1/g1Predictions.hpp ! src/hotspot/share/gc/g1/survRateGroup.cpp ! src/hotspot/share/gc/g1/survRateGroup.hpp ! test/hotspot/gtest/gc/g1/test_g1Predictions.cpp Changeset: 1d4f51045433 Author: tschatzl Date: 2019-12-02 14:21 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1d4f51045433 8234179: Move HeapRegion::_recorded_rs_length/_predicted_elapsed_time_ms into G1CollectionSet Reviewed-by: sjohanss, lkorinth ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp Changeset: d680c3ff80f6 Author: tschatzl Date: 2019-12-02 14:21 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d680c3ff80f6 8234586: Rename survRateGroup.?pp files to g1SurvRateGroup.?pp Reviewed-by: kbarrett, sjohanss + src/hotspot/share/gc/g1/g1SurvRateGroup.cpp + src/hotspot/share/gc/g1/g1SurvRateGroup.hpp ! src/hotspot/share/gc/g1/heapRegion.hpp - src/hotspot/share/gc/g1/survRateGroup.cpp - src/hotspot/share/gc/g1/survRateGroup.hpp Changeset: a79eafba5b38 Author: tschatzl Date: 2019-12-02 14:21 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a79eafba5b38 8234587: Rename the SurvRateGroup class to G1SurvRateGroup Reviewed-by: kbarrett, sangheki ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! src/hotspot/share/gc/g1/g1SurvRateGroup.cpp ! src/hotspot/share/gc/g1/g1SurvRateGroup.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: e79ece2eb1ba Author: coleenp Date: 2019-12-02 08:40 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e79ece2eb1ba 8173361: various crashes in JvmtiExport::post_compiled_method_load Summary: Don't post information that uses metadata from unloaded nmethods Reviewed-by: eosterlund, dholmes, sspitsyn ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiImpl.cpp ! src/hotspot/share/prims/jvmtiImpl.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/serviceThread.cpp ! src/hotspot/share/runtime/serviceThread.hpp ! src/hotspot/share/runtime/thread.hpp Changeset: 4774b50671ed Author: coleenp Date: 2019-12-02 09:02 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4774b50671ed 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators Summary: call extension ClassUnload event as a deferred event from the ServiceThread and remove unsafe arguments Reviewed-by: sspitsyn, dholmes ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiExport.hpp ! src/hotspot/share/prims/jvmtiExtensions.cpp ! src/hotspot/share/prims/jvmtiImpl.cpp ! src/hotspot/share/prims/jvmtiImpl.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.inline.hpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/ex03t001.cpp Changeset: 73da8751c395 Author: rriggs Date: 2019-12-02 09:45 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/73da8751c395 8233799: Review the need for overview.html in the java.time package Reviewed-by: dfuchs, naoto, lancea - src/java.base/share/classes/java/time/overview.html Changeset: 2baa1f8721b8 Author: hannesw Date: 2019-12-02 18:52 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2baa1f8721b8 8223252: Update Javadoc help page with new search features Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties Changeset: d8b5e32ffa2f Author: xuelei Date: 2019-12-02 10:42 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d8b5e32ffa2f 8235183: Remove the "HACK CODE" in comment Reviewed-by: jnimeh ! src/java.base/share/classes/sun/security/ssl/NamedGroup.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java ! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java Changeset: f794ce3de310 Author: weijun Date: 2019-12-03 14:38 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f794ce3de310 8234744: KeyStore.store can write wrong type of file Reviewed-by: mullan ! src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java + test/jdk/sun/security/provider/KeyStore/WrongStoreType.java Changeset: 37434b8a1e8e Author: jiefu Date: 2019-12-03 09:36 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/37434b8a1e8e 8235218: Minimal VM is broken after JDK-8173361 Reviewed-by: dholmes ! src/hotspot/share/prims/jvmtiImpl.hpp Changeset: 0b1c61e76d60 Author: psadhukhan Date: 2019-11-21 14:43 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0b1c61e76d60 8234385: [TESTBUG] java/awt/EventQueue/6980209/bug6980209.java fails in linux nightly Reviewed-by: serb ! test/jdk/java/awt/EventQueue/6980209/bug6980209.java Changeset: 5602e016309b Author: jdv Date: 2019-11-22 11:35 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/5602e016309b 8233696: [TESTBUG]Some jtreg tests fail when CAPS_LOCK is ON Reviewed-by: serb, prr ! test/jdk/java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java ! test/jdk/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java ! test/jdk/java/awt/Toolkit/LockingKeyStateTest/LockingKeyStateTest.java ! test/jdk/java/awt/Toolkit/RealSync/Test.java ! test/jdk/javax/swing/JFileChooser/8041694/bug8041694.java Changeset: b256c7afe8cc Author: psadhukhan Date: 2019-11-25 11:20 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b256c7afe8cc 8193544: Regression automated test '/open/test/jdk/javax/swing/JDialog/Transparency/TransparencyTest.java' fails Reviewed-by: serb ! test/jdk/javax/swing/JDialog/Transparency/TransparencyTest.java Changeset: aa3918700fea Author: prr Date: 2019-11-25 12:09 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/aa3918700fea 8227324: Upgrade to freetype 2.10.1 Reviewed-by: serb, jdv ! src/java.desktop/share/legal/freetype.md ! src/java.desktop/share/native/libfreetype/include/freetype/freetype.h ! src/java.desktop/share/native/libfreetype/include/freetype/fterrors.h ! src/java.desktop/share/native/libfreetype/include/freetype/ftglyph.h ! src/java.desktop/share/native/libfreetype/include/freetype/ftimage.h ! src/java.desktop/share/native/libfreetype/include/freetype/ftmodapi.h ! src/java.desktop/share/native/libfreetype/include/freetype/ftoutln.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/ftcalc.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/ftobjs.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/ftstream.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/fttrace.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/internal.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/psaux.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/services/svgldict.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/sfnt.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/t1types.h ! src/java.desktop/share/native/libfreetype/include/freetype/internal/tttypes.h + src/java.desktop/share/native/libfreetype/include/freetype/internal/wofftypes.h ! src/java.desktop/share/native/libfreetype/src/autofit/afblue.c ! src/java.desktop/share/native/libfreetype/src/autofit/afblue.dat ! src/java.desktop/share/native/libfreetype/src/autofit/afblue.h ! src/java.desktop/share/native/libfreetype/src/autofit/afcjk.c ! src/java.desktop/share/native/libfreetype/src/autofit/afglobal.c ! src/java.desktop/share/native/libfreetype/src/autofit/aflatin.c ! src/java.desktop/share/native/libfreetype/src/autofit/afranges.c ! src/java.desktop/share/native/libfreetype/src/autofit/afscript.h ! src/java.desktop/share/native/libfreetype/src/autofit/afstyles.h ! src/java.desktop/share/native/libfreetype/src/base/ftbbox.c ! src/java.desktop/share/native/libfreetype/src/base/ftbitmap.c ! src/java.desktop/share/native/libfreetype/src/base/ftinit.c ! src/java.desktop/share/native/libfreetype/src/base/ftlcdfil.c ! src/java.desktop/share/native/libfreetype/src/base/ftobjs.c ! src/java.desktop/share/native/libfreetype/src/base/ftoutln.c ! src/java.desktop/share/native/libfreetype/src/base/ftstroke.c ! src/java.desktop/share/native/libfreetype/src/cff/cffdrivr.c ! src/java.desktop/share/native/libfreetype/src/cff/cffobjs.c ! src/java.desktop/share/native/libfreetype/src/cff/cffparse.c ! src/java.desktop/share/native/libfreetype/src/cff/cffparse.h ! src/java.desktop/share/native/libfreetype/src/psaux/afmparse.c ! src/java.desktop/share/native/libfreetype/src/psaux/psfixed.h ! src/java.desktop/share/native/libfreetype/src/psaux/psfont.c ! src/java.desktop/share/native/libfreetype/src/psaux/psobjs.c ! src/java.desktop/share/native/libfreetype/src/psaux/psobjs.h ! src/java.desktop/share/native/libfreetype/src/raster/ftraster.c ! src/java.desktop/share/native/libfreetype/src/sfnt/sfdriver.c ! src/java.desktop/share/native/libfreetype/src/sfnt/sfobjs.c ! src/java.desktop/share/native/libfreetype/src/sfnt/sfobjs.h + src/java.desktop/share/native/libfreetype/src/sfnt/sfwoff.c + src/java.desktop/share/native/libfreetype/src/sfnt/sfwoff.h ! src/java.desktop/share/native/libfreetype/src/sfnt/ttcmap.c ! src/java.desktop/share/native/libfreetype/src/sfnt/ttmtx.c ! src/java.desktop/share/native/libfreetype/src/smooth/ftgrays.c ! src/java.desktop/share/native/libfreetype/src/smooth/ftsmooth.c ! src/java.desktop/share/native/libfreetype/src/truetype/ttgload.c ! src/java.desktop/share/native/libfreetype/src/truetype/ttgxvar.c ! src/java.desktop/share/native/libfreetype/src/truetype/ttgxvar.h ! src/java.desktop/share/native/libfreetype/src/truetype/ttinterp.c ! src/java.desktop/share/native/libfreetype/src/truetype/ttobjs.c ! src/java.desktop/share/native/libfreetype/src/truetype/ttpload.c ! src/java.desktop/share/native/libfreetype/src/type1/t1driver.c ! src/java.desktop/share/native/libfreetype/src/type1/t1load.c Changeset: 998cf5f99b8b Author: prr Date: 2019-11-26 09:50 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/998cf5f99b8b 8234769: Duplicate attribution in freetype.md Reviewed-by: psadhukhan ! src/java.desktop/share/legal/freetype.md Changeset: 1e563056dd3c Author: pbansal Date: 2019-11-27 11:05 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1e563056dd3c 8230235: Rendering HTML with empty img attribute and documentBaseKey cause Exception Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/javax/swing/text/html/ImageView.java + test/jdk/javax/swing/text/html/TestJLabelWithHTMLText.java Changeset: b4c6bc80171d Author: psadhukhan Date: 2019-11-27 13:35 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b4c6bc80171d 8234786: Fix for JDK-8214578 breaks OS X 10.12 compatibility Reviewed-by: jdv ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h Changeset: 327b35573471 Author: dbatrak Date: 2019-11-27 16:39 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/327b35573471 8210058: Algorithmic Italic font leans opposite angle in Printing Reviewed-by: prr, jdv, psadhukhan ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c + test/jdk/java/awt/font/Rotate/A.ttf + test/jdk/java/awt/font/Rotate/RotatedItalicsTest.java Changeset: 7637e77c4c8a Author: psadhukhan Date: 2019-12-02 11:58 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/7637e77c4c8a 8234149: Several regression tests do not dispose Frame at end Reviewed-by: serb ! test/jdk/javax/swing/AbstractButton/6711682/bug6711682.java ! test/jdk/javax/swing/Action/8133039/bug8133039.java ! test/jdk/javax/swing/JButton/4368790/bug4368790.java ! test/jdk/javax/swing/JButton/4796987/bug4796987.java ! test/jdk/javax/swing/JColorChooser/Test8051548.java ! test/jdk/javax/swing/JComboBox/4523758/bug4523758.java ! test/jdk/javax/swing/JComboBox/6236162/bug6236162.java ! test/jdk/javax/swing/JComboBox/7195179/Test7195179.java ! test/jdk/javax/swing/JComboBox/8057893/bug8057893.java ! test/jdk/javax/swing/JComponent/4337267/bug4337267.java ! test/jdk/javax/swing/JComponent/6989617/bug6989617.java ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java ! test/jdk/javax/swing/JEditorPane/4492274/bug4492274.java ! test/jdk/javax/swing/JFrame/4962534/bug4962534.java ! test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java ! test/jdk/javax/swing/JInternalFrame/5066752/bug5066752.java ! test/jdk/javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java ! test/jdk/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java ! test/jdk/javax/swing/JLabel/6596966/bug6596966.java ! test/jdk/javax/swing/JLayer/6824395/bug6824395.java ! test/jdk/javax/swing/JList/6462008/bug6462008.java ! test/jdk/javax/swing/JList/6510999/bug6510999.java ! test/jdk/javax/swing/JMenu/4417601/bug4417601.java ! test/jdk/javax/swing/JMenu/4515762/bug4515762.java ! test/jdk/javax/swing/JMenu/4692443/bug4692443.java ! test/jdk/javax/swing/JMenu/6359669/bug6359669.java ! test/jdk/javax/swing/JMenu/6470128/bug6470128.java ! test/jdk/javax/swing/JMenu/6538132/bug6538132.java ! test/jdk/javax/swing/JMenuBar/4750590/bug4750590.java ! test/jdk/javax/swing/JMenuItem/4171437/bug4171437.java ! test/jdk/javax/swing/JMenuItem/4654927/bug4654927.java ! test/jdk/javax/swing/JMenuItem/6209975/bug6209975.java ! test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java ! test/jdk/javax/swing/JPopupMenu/6217905/bug6217905.java ! test/jdk/javax/swing/JPopupMenu/6515446/bug6515446.java ! test/jdk/javax/swing/JPopupMenu/6580930/bug6580930.java ! test/jdk/javax/swing/JPopupMenu/6827786/bug6827786.java ! test/jdk/javax/swing/JPopupMenu/6987844/bug6987844.java ! test/jdk/javax/swing/JRadioButton/8041561/bug8041561.java ! test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java ! test/jdk/javax/swing/JRootPane/4670486/bug4670486.java ! test/jdk/javax/swing/JScrollBar/4708809/bug4708809.java ! test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java ! test/jdk/javax/swing/JScrollBar/6542335/bug6542335.java ! test/jdk/javax/swing/JScrollBar/bug4202954/bug4202954.java ! test/jdk/javax/swing/JSpinner/4973721/bug4973721.java ! test/jdk/javax/swing/JSplitPane/4885629/bug4885629.java ! test/jdk/javax/swing/JTabbedPane/4361477/bug4361477.java ! test/jdk/javax/swing/JTabbedPane/4624207/bug4624207.java ! test/jdk/javax/swing/JTabbedPane/6495408/bug6495408.java ! test/jdk/javax/swing/JTabbedPane/7161568/bug7161568.java ! test/jdk/javax/swing/JTabbedPane/8134116/Bug8134116.java ! test/jdk/javax/swing/JTable/4220171/bug4220171.java ! test/jdk/javax/swing/JTable/6777378/bug6777378.java Changeset: 8991f75a1409 Author: psadhukhan Date: 2019-12-03 11:52 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8991f75a1409 Merge - src/hotspot/share/gc/g1/survRateGroup.cpp - src/hotspot/share/gc/g1/survRateGroup.hpp - src/java.base/share/classes/java/time/overview.html - src/jdk.compiler/share/classes/META-INF/services/com.sun.tools.javac.platform.PlatformProvider - src/jdk.compiler/share/classes/com/sun/tools/javac/services/javax.tools.JavaCompilerTool - src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystem.java - src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystemProvider.java - test/jdk/jdk/jfr/api/consumer/streaming/TestRepositoryMigration.java - test/jdk/sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java - test/langtools/jdk/javadoc/doclet/testDocFiles/pkg/Test.java - test/langtools/jdk/javadoc/doclet/testDocFiles/pkg/doc-files/test.txt Changeset: 9eaef94e74b5 Author: psadhukhan Date: 2019-12-03 12:42 +0530 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/9eaef94e74b5 Merge Changeset: 90f3ea9785d5 Author: thartmann Date: 2019-12-03 08:29 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/90f3ea9785d5 8234617: C1: Incorrect result of field load due to missing narrowing conversion Summary: Emit an explicit conversion to get the correct field value after the write. Reviewed-by: vlivanov, mdoerr ! src/hotspot/share/c1/c1_GraphBuilder.cpp + test/hotspot/jtreg/compiler/conversions/Conversion.jasm + test/hotspot/jtreg/compiler/conversions/TestPrimitiveConversions.java Changeset: 1f2359ae7a86 Author: stefank Date: 2019-12-03 10:40 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1f2359ae7a86 8234822: Limit ZGC jtreg-support to Windows 2019 Server Reviewed-by: iignatyev, eosterlund ! test/lib/sun/hotspot/gc/GC.java Changeset: d4a477d5080f Author: stefank Date: 2019-11-07 15:29 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d4a477d5080f 8233299: Implementation: JEP 365: ZGC on Windows Reviewed-by: pliden, eosterlund ! make/autoconf/hotspot.m4 ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp + src/hotspot/os/windows/gc/z/zBackingFile_windows.cpp + src/hotspot/os/windows/gc/z/zBackingFile_windows.hpp + src/hotspot/os/windows/gc/z/zInitialize_windows.cpp + src/hotspot/os/windows/gc/z/zLargePages_windows.cpp + src/hotspot/os/windows/gc/z/zMapper_windows.cpp + src/hotspot/os/windows/gc/z/zMapper_windows.hpp + src/hotspot/os/windows/gc/z/zNUMA_windows.cpp + src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp + src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.hpp + src/hotspot/os/windows/gc/z/zSyscall_windows.cpp + src/hotspot/os/windows/gc/z/zSyscall_windows.hpp + src/hotspot/os/windows/gc/z/zUtils_windows.cpp + src/hotspot/os/windows/gc/z/zVirtualMemory_windows.cpp Changeset: ac3c8cae4815 Author: mbaesken Date: 2019-11-29 09:52 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ac3c8cae4815 8234741: enhance os::get_core_path on macOS Reviewed-by: clanger, gziemski ! src/hotspot/os/bsd/os_bsd.cpp Changeset: de99f7acea70 Author: mgronlun Date: 2019-12-03 12:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/de99f7acea70 8216041: [Event Request] - Deoptimization Reviewed-by: iignatyev, vlivanov, egahlin Contributed-by: Igor Ignatyev ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc + test/jdk/jdk/jfr/event/compiler/TestDeoptimization.java ! test/lib/jdk/test/lib/jfr/EventNames.java Changeset: d48638a26026 Author: michaelm Date: 2019-12-03 11:55 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d48638a26026 8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2() fails on Windows 10 Reviewed-by: alanb ! test/jdk/java/net/Socket/Timeouts.java Changeset: 721dc0c243e7 Author: michaelm Date: 2019-12-03 11:57 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/721dc0c243e7 8234824: java/nio/channels/SocketChannel/AdaptSocket.java fails on Windows 10 Reviewed-by: alanb ! test/jdk/java/nio/channels/SocketChannel/AdaptSocket.java Changeset: 0821487ef0ab Author: jlaskey Date: 2019-12-03 08:35 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0821487ef0ab 8233116: Escape Sequences For Line Continuation and White Space (Preview) Reviewed-by: vromero, jlahoda, bchristi, mcimadamore ! src/java.base/share/classes/java/lang/String.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! test/jdk/java/lang/String/TranslateEscapes.java ! test/langtools/tools/javac/TextBlockAPI.java ! test/langtools/tools/javac/TextBlockLang.java Changeset: 79fba633d07f Author: pliden Date: 2019-12-03 13:51 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/79fba633d07f 8234543: ZGC: Parallel pre-touch Reviewed-by: eosterlund, stefank ! src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp ! src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.hpp ! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp ! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.hpp ! src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp ! src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp ! src/hotspot/share/gc/z/zPhysicalMemory.cpp ! src/hotspot/share/gc/z/zPhysicalMemory.hpp ! src/hotspot/share/gc/z/zWorkers.cpp + test/hotspot/jtreg/gc/z/TestAlwaysPreTouch.java Changeset: aa12d1f0bc66 Author: hseigel Date: 2019-12-03 14:10 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/aa12d1f0bc66 8234656: Improve granularity of verifier logging Summary: Print brief output for log level 'info'. Print detailed output for 'debug' and 'trace'. Reviewed-by: iklam, lfoltan, dholmes ! src/hotspot/share/classfile/verifier.cpp ! test/hotspot/jtreg/runtime/logging/VerificationTest.java ! test/hotspot/jtreg/runtime/verifier/TraceClassRes.java Changeset: 2945676fa6ae Author: jboes Date: 2019-12-03 12:44 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2945676fa6ae 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux Summary: Add 'ifconfig -a' on Solaris and Linux, 'ipconfig /all' on Windows Reviewed-by: iignatyev, vtewari ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties ! test/failure_handler/src/share/conf/solaris.properties ! test/failure_handler/src/share/conf/windows.properties Changeset: 99b71c5b02ff Author: rehn Date: 2019-12-03 15:32 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/99b71c5b02ff 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure Reviewed-by: dholmes, pliden, coleenp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1RemSetSummary.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedup.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zMark.cpp ! src/hotspot/share/gc/z/zRootsIterator.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.hpp ! src/hotspot/share/gc/z/zWorkers.hpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp ! src/hotspot/share/jfr/writers/jfrJavaEventWriter.cpp ! src/hotspot/share/memory/iterator.hpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/biasedLocking.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/threadSMR.inline.hpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/utilities/globalCounter.cpp Changeset: 0c4b36eb590d Author: jjiang Date: 2019-12-04 00:06 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/0c4b36eb590d 8235255: ProblemList javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java Reviewed-by: mullan ! test/jdk/ProblemList.txt Changeset: 252a8bb9f587 Author: eosterlund Date: 2019-12-03 16:13 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/252a8bb9f587 8234426: Sweeper should not CompiledIC::set_to_clean with ICStubs for is_unloading() nmethods Reviewed-by: stefank, thartmann ! src/hotspot/share/code/compiledMethod.cpp Changeset: cfed0da56a7b Author: eosterlund Date: 2019-12-03 16:13 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/cfed0da56a7b 8234662: Sweeper should keep current nmethod alive before yielding for ICStub refills Reviewed-by: pliden, stefank ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/gc/shared/barrierSetNMethod.hpp Changeset: 54af3178cdbd Author: vlivanov Date: 2019-12-03 20:13 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/54af3178cdbd 8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp Changeset: 138b0f3fe18c Author: vlivanov Date: 2019-12-03 20:13 +0300 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/138b0f3fe18c 8234923: Missed call_site_target nmethod dependency for non-fully initialized ConstantCallSite instance Reviewed-by: jrose ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciCallSite.cpp ! src/hotspot/share/ci/ciCallSite.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/opto/type.cpp ! src/java.base/share/classes/java/lang/invoke/ConstantCallSite.java ! test/jdk/java/lang/invoke/CallSiteTest.java Changeset: ca50cc82e443 Author: sspitsyn Date: 2019-12-03 19:45 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ca50cc82e443 8235280: UnProblemList vmTestbase/nsk/jvmti/GetThreadState/thrstat001/TestDescription.java Summary: Remove test from ProblemList.txt. Reviewed-by: iignatyev ! test/hotspot/jtreg/ProblemList.txt Changeset: d66315fd78c3 Author: kbarrett Date: 2019-12-03 15:12 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d66315fd78c3 8213415: BitMap::word_index_round_up overflow problems Summary: Limit BitMap sizes so to-word round-up can't overflow. Reviewed-by: tschatzl, stuefe ! src/hotspot/share/gc/parallel/parMarkBitMap.cpp ! src/hotspot/share/gc/parallel/parMarkBitMap.hpp ! src/hotspot/share/gc/parallel/parMarkBitMap.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/utilities/bitMap.cpp ! src/hotspot/share/utilities/bitMap.hpp ! src/hotspot/share/utilities/bitMap.inline.hpp ! test/hotspot/gtest/utilities/test_bitMap_setops.cpp Changeset: 1ea1c063ad52 Author: rkennke Date: 2019-12-03 21:23 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1ea1c063ad52 8235260: Shenandoah: Don't allow recycle-assist until concurrent roots are done Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp Changeset: 68f9bbda438d Author: kbarrett Date: 2019-12-03 19:09 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/68f9bbda438d 8234779: Provide idiom for declaring classes noncopyable Summary: Add NONCOPYABLE macro and uses. Reviewed-by: dholmes, pliden, coleenp ! src/hotspot/os/aix/os_perf_aix.cpp ! src/hotspot/os/bsd/os_perf_bsd.cpp ! src/hotspot/os/bsd/semaphore_bsd.hpp ! src/hotspot/os/linux/os_perf_linux.cpp ! src/hotspot/os/linux/waitBarrier_linux.hpp ! src/hotspot/os/posix/os_posix.hpp ! src/hotspot/os/posix/semaphore_posix.hpp ! src/hotspot/os/solaris/os_perf_solaris.cpp ! src/hotspot/os/solaris/os_solaris.hpp ! src/hotspot/os/windows/os_perf_windows.cpp ! src/hotspot/os/windows/os_windows.hpp ! src/hotspot/os/windows/semaphore_windows.hpp ! src/hotspot/share/gc/g1/g1FreeIdSet.hpp ! src/hotspot/share/gc/g1/g1SharedDirtyCardQueue.hpp ! src/hotspot/share/gc/shared/oopStorage.hpp ! src/hotspot/share/gc/shared/oopStorage.inline.hpp ! src/hotspot/share/gc/shared/oopStorageParState.hpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.hpp ! src/hotspot/share/gc/z/zArray.hpp ! src/hotspot/share/gc/z/zList.hpp ! src/hotspot/share/jfr/jni/jfrJavaCall.hpp ! src/hotspot/share/memory/metaspaceClosure.hpp ! src/hotspot/share/oops/array.hpp ! src/hotspot/share/runtime/os_perf.hpp ! src/hotspot/share/runtime/semaphore.hpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/utilities/bitMap.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/lockFreeStack.hpp ! src/hotspot/share/utilities/ostream.hpp ! src/hotspot/share/utilities/singleWriterSynchronizer.hpp ! src/hotspot/share/utilities/waitBarrier.hpp ! src/hotspot/share/utilities/waitBarrier_generic.hpp Changeset: e3463d022cb9 Author: xuelei Date: 2019-12-03 17:15 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e3463d022cb9 8235263: Revert TLS 1.3 change that wrapped IOExceptions Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: b8b80f27d7a9 Author: cjplummer Date: 2019-12-03 20:08 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b8b80f27d7a9 8235221: Fix ProblemList.txt for sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java Reviewed-by: iignatyev ! test/jdk/ProblemList.txt Changeset: f90eefff864e Author: iignatyev Date: 2019-12-03 20:23 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f90eefff864e 8129092: compiler/intrinsics/classcast/NullCheckDroppingsTest.java testVarClassCast() can fail Reviewed-by: kvn ! test/hotspot/jtreg/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java Changeset: a1802614d6fe Author: thartmann Date: 2019-12-04 07:07 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a1802614d6fe 8234616: assert(0 <= i && i < _len) failed: illegal index in PhaseMacroExpand::expand_macro_nodes() Summary: Make sure the index into the macro node array is decremented on removal. Reviewed-by: vlivanov, kvn ! src/hotspot/share/opto/macro.cpp Changeset: 047b5d642743 Author: pli Date: 2019-11-29 03:48 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/047b5d642743 8234791: Fix Client VM build for x86_64 and AArch64 Reviewed-by: adinn, aph, thartmann ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/share/runtime/arguments.cpp Changeset: 775b714a2e49 Author: mbaesken Date: 2019-12-03 11:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/775b714a2e49 8235243: handle VS2017 15.9 and VS2019 in abstract_vm_version Reviewed-by: dholmes, mdoerr ! src/hotspot/share/runtime/abstract_vm_version.cpp Changeset: 396b2290219f Author: jlahoda Date: 2019-12-04 09:38 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/396b2290219f 8234899: Compiler reports AssertionError for conditional operator ? : and pattern matching for instanceof Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java + test/langtools/tools/javac/ConditionalExpressionResolvePending.java ! test/langtools/tools/javac/patterns/BindingsTest1.java Changeset: 4fcdea88d423 Author: jlahoda Date: 2019-12-04 09:38 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4fcdea88d423 8234922: No compilation error reported not reported for a binding variable when loop broken with label Summary: Any break outside of a loop should confine the binding variables from the loop's condition to the loop Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! test/langtools/tools/javac/patterns/BindingsTest1.java ! test/langtools/tools/javac/patterns/BindingsTest2.java ! test/langtools/tools/javac/patterns/BindingsTest2.out + test/langtools/tools/javac/patterns/BreakAndLoops.java Changeset: cfc005b8a117 Author: mbaesken Date: 2019-12-04 09:43 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/cfc005b8a117 8235325: build failure on Linux after 8235243 Reviewed-by: clanger ! src/hotspot/share/runtime/abstract_vm_version.cpp Changeset: 636d71e53732 Author: stefank Date: 2019-12-04 10:26 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/636d71e53732 8235257: Split 'assert(loader != NULL && oopDesc::is_oop(loader), "loader must be oop")' Reviewed-by: dcubed, hseigel ! src/hotspot/share/classfile/javaClasses.cpp Changeset: c2ce3849c62f Author: rehn Date: 2019-12-04 11:57 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c2ce3849c62f 8234742: Improve handshake logging Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/thread.hpp Changeset: 354025d0427d Author: azeller Date: 2019-12-02 17:10 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/354025d0427d 8234696: tools/jlink/plugins/VendorInfoPluginsTest.java times out Reviewed-by: mchung, clanger ! test/jdk/tools/jlink/plugins/VendorInfoPluginsTest.java Changeset: 3b61c66ce692 Author: mbaesken Date: 2019-12-03 15:17 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/3b61c66ce692 8234397: add OS uptime information to os::print_os_info output Reviewed-by: clanger, dholmes, lucy ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/bsd/os_bsd.hpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/posix/os_posix.hpp ! src/hotspot/os/solaris/os_solaris.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 19d927f669e9 Author: tschatzl Date: 2019-12-04 16:58 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/19d927f669e9 8235247: WorkerDataArray leaks C heap memory for associated work items Reviewed-by: lkorinth, kbarrett ! src/hotspot/share/gc/shared/workerDataArray.inline.hpp Changeset: 86fdc7632b01 Author: coleenp Date: 2019-12-04 11:09 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/86fdc7632b01 8234355: Buffer overflow in jcmd GC.class_stats due to too many classes Summary: Remove use of GC.class_stats in testing and failure analysis (plan to deprecate) Reviewed-by: dcubed ! test/failure_handler/src/share/conf/common.properties Changeset: d2977f4e9ef6 Author: alanb Date: 2019-12-04 16:37 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d2977f4e9ef6 8235193: (dc) Remove JNI overhead from DatagramChannel.send implementation Reviewed-by: chegar ! src/java.base/share/classes/java/net/Inet4Address.java ! src/java.base/share/classes/java/net/Inet6Address.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/jdk/internal/access/JavaNetInetAddressAccess.java ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/NativeSocketAddress.java ! src/java.base/share/native/libnio/ch/NativeSocketAddress.c ! src/java.base/unix/native/libnio/ch/DatagramChannelImpl.c ! src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c - test/jdk/java/nio/channels/DatagramChannel/ManySenders.java + test/jdk/java/nio/channels/DatagramChannel/ManySourcesAndTargets.java Changeset: 799c800624fb Author: tschatzl Date: 2019-12-04 18:54 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/799c800624fb 8235347: [Backout] 8235247: WorkerDataArray leaks C heap memory for associated work items Summary: Backout of earlier change due to unexpected crashes. Reviewed-by: sjohanss ! src/hotspot/share/gc/shared/workerDataArray.inline.hpp Changeset: a9347576dbc7 Author: mchung Date: 2019-12-04 10:46 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a9347576dbc7 8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup Summary: Add a new Lookup::hasFullPrivilegeAccess method and document the capabilities requiring full privileges Reviewed-by: alanb, plevart ! src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java ! src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! test/jdk/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java Changeset: e71931b1c3b7 Author: coleenp Date: 2019-12-04 13:48 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e71931b1c3b7 8235273: nmethodLocker not needed for COMPILED_METHOD_UNLOAD events Summary: remove unnecessary nmethodLocker Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/prims/jvmtiImpl.cpp ! src/hotspot/share/prims/jvmtiImpl.hpp Changeset: db5097a1ec61 Author: rkennke Date: 2019-12-04 20:03 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/db5097a1ec61 8235337: Shenandoah: Fix evac OOM scoping for concurrent class unloading Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp Changeset: f97907a7bba9 Author: iklam Date: 2019-12-04 11:19 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f97907a7bba9 8235179: [TESTBUG] DynamicArchiveRelocationTest.java fails with 'runtime archive relocation start' missing Reviewed-by: mseledtsov, ccheung ! test/hotspot/jtreg/runtime/cds/appcds/ArchiveRelocationTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicArchiveRelocationTest.java Changeset: 288777cf0702 Author: mgronlun Date: 2019-12-04 21:26 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/288777cf0702 8234060: Potential memory reordering problem in JfrBuffer flush mechanism Reviewed-by: egahlin Contributed-by: Denghui Dong ! src/hotspot/share/jfr/recorder/storage/jfrBuffer.cpp ! src/hotspot/share/jfr/recorder/storage/jfrBuffer.hpp ! src/hotspot/share/jfr/recorder/storage/jfrMemorySpace.inline.hpp ! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp ! src/hotspot/share/jfr/recorder/storage/jfrStorageUtils.inline.hpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventWriter.java Changeset: 8a8c60853789 Author: rkennke Date: 2019-12-04 21:40 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8a8c60853789 8235355: Shenandoah: Resolve deadlock between OOM handler and nmethod lock Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp Changeset: 8e76f81d057a Author: vromero Date: 2019-12-04 15:57 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8e76f81d057a 8225054: Compiler implementation for records 8225052: javax.lang.model support for records 8225053: Preview APIs support for records 8225055: Javadoc for records 8226314: com.sun.source support for records 8227113: Specification for java.lang.Record 8233526: JVM support for records Summary: implement records in the compiler and the JVM, including serialization, reflection and APIs support Reviewed-by: mcimadamore, briangoetz, alanb, darcy, chegar, jrose, jlahoda, coleenp, dholmes, lfoltan, mchung, sadayapalam, hannesw, sspitsyn Contributed-by: vicente.romero at oracle.com, brian.goetz at oracle.com, maurizio.cimadamore at oracle.com, harold.seigel at oracle.com, joe.darcy at oracle.com, jonathan.gibbons at oracle.com, chris.hegarty at oracle.com, jan.lahoda at oracle.com ! make/CompileInterimLangtools.gmk ! make/hotspot/symbols/symbols-unix ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp + src/hotspot/share/oops/recordComponent.cpp + src/hotspot/share/oops/recordComponent.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmti.xml ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.hpp ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/lang/Class.java + src/java.base/share/classes/java/lang/Record.java ! src/java.base/share/classes/java/lang/annotation/ElementType.java + src/java.base/share/classes/java/lang/reflect/RecordComponent.java + src/java.base/share/classes/java/lang/runtime/ObjectMethods.java + src/java.base/share/classes/java/lang/runtime/package-info.java ! src/java.base/share/classes/jdk/internal/PreviewFeature.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/reflect/annotation/TypeAnnotation.java ! src/java.base/share/native/libjava/Class.c ! src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java + src/java.compiler/share/classes/javax/lang/model/element/RecordComponentElement.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/element/package-info.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/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/ElementFilter.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/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/Elements.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 ! src/java.instrument/share/native/libinstrument/JavaExceptions.c ! src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/tools/doclint/Checker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Kinds.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/pubapi/PubApi.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/pubapi/TypeDesc.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/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/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.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/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ClassWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PackageSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Resources.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PackageSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ParamTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ClassUseMapper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/TypeElementCatalog.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocMemberEnter.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/Record_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! src/jdk.jshell/share/classes/jdk/jshell/ReplParser.java + test/hotspot/jtreg/runtime/records/RedefineRecord.java + test/hotspot/jtreg/runtime/records/TEST.properties + test/hotspot/jtreg/runtime/records/abstractRecord.jcod + test/hotspot/jtreg/runtime/records/badRecordAttribute.jcod + test/hotspot/jtreg/runtime/records/ignoreRecordAttribute.java + test/hotspot/jtreg/runtime/records/notFinalRecord.jcod + test/hotspot/jtreg/runtime/records/oldRecordAttribute.jcod + test/hotspot/jtreg/runtime/records/recordAttributeTest.java + test/hotspot/jtreg/runtime/records/recordIgnoredVersion.jcod + test/hotspot/jtreg/runtime/records/recordReflectionTest.java + test/hotspot/jtreg/runtime/records/shortRecordAttribute.jcod + test/hotspot/jtreg/runtime/records/superNotJLRecord.jcod + test/hotspot/jtreg/runtime/records/twoRecordAttributes.jcod ! test/jdk/ProblemList.txt + test/jdk/java/io/Serializable/records/AbsentStreamValuesTest.java + test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java + test/jdk/java/io/Serializable/records/BadValues.java + test/jdk/java/io/Serializable/records/BasicRecordSer.java + test/jdk/java/io/Serializable/records/ConstructorAccessTest.java + test/jdk/java/io/Serializable/records/ConstructorPermissionTest.java + test/jdk/java/io/Serializable/records/CycleTest.java + test/jdk/java/io/Serializable/records/ProhibitedMethods.java + test/jdk/java/io/Serializable/records/ReadResolveTest.java + test/jdk/java/io/Serializable/records/RecordClassTest.java + test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java + test/jdk/java/io/Serializable/records/SerialVersionUIDTest.java + test/jdk/java/io/Serializable/records/StreamRefTest.java + test/jdk/java/io/Serializable/records/TEST.properties + test/jdk/java/io/Serializable/records/ThrowingConstructorTest.java + test/jdk/java/io/Serializable/records/WriteReplaceTest.java + test/jdk/java/io/Serializable/records/empty_security.policy + test/jdk/java/io/Serializable/records/migration/AbstractTest.java + test/jdk/java/io/Serializable/records/migration/AssignableFrom.java + test/jdk/java/io/Serializable/records/migration/AssignableFromTest.java + test/jdk/java/io/Serializable/records/migration/DefaultValues.java + test/jdk/java/io/Serializable/records/migration/DefaultValuesTest.java + test/jdk/java/io/Serializable/records/migration/Point.java + test/jdk/java/io/Serializable/records/migration/SuperStreamFields.java + test/jdk/java/io/Serializable/records/migration/SuperStreamFieldsTest.java + test/jdk/java/io/Serializable/records/migration/plain/AssignableFromImpl.java + test/jdk/java/io/Serializable/records/migration/plain/DefaultValuesImpl.java + test/jdk/java/io/Serializable/records/migration/plain/PointImpl.java + test/jdk/java/io/Serializable/records/migration/plain/SuperStreamFieldsImpl.java + test/jdk/java/io/Serializable/records/migration/record/AssignableFromImpl.java + test/jdk/java/io/Serializable/records/migration/record/DefaultValuesImpl.java + test/jdk/java/io/Serializable/records/migration/record/PointImpl.java + test/jdk/java/io/Serializable/records/migration/record/SuperStreamFieldsImpl.java - test/jdk/java/lang/Runtime/Resources.java - test/jdk/java/lang/Runtime/Version/Basic.java - test/jdk/java/lang/Runtime/Version/VersionProps.java - test/jdk/java/lang/Runtime/exec/ArgWithSpaceAndFinalBackslash.java - test/jdk/java/lang/Runtime/exec/BadEnvp.java - test/jdk/java/lang/Runtime/exec/ConcurrentRead.java - test/jdk/java/lang/Runtime/exec/Duped.java - test/jdk/java/lang/Runtime/exec/ExecCommand.java - test/jdk/java/lang/Runtime/exec/ExecEmptyString.java - test/jdk/java/lang/Runtime/exec/ExecWithDir.java - test/jdk/java/lang/Runtime/exec/ExecWithInput.java - test/jdk/java/lang/Runtime/exec/ExecWithLotsOfArgs.java - test/jdk/java/lang/Runtime/exec/ExitValue.java - test/jdk/java/lang/Runtime/exec/LotsOfDestroys.java - test/jdk/java/lang/Runtime/exec/LotsOfOutput.java - test/jdk/java/lang/Runtime/exec/SetCwd.java - test/jdk/java/lang/Runtime/exec/SleepyCat.java - test/jdk/java/lang/Runtime/exec/Space.java - test/jdk/java/lang/Runtime/exec/Status.java - test/jdk/java/lang/Runtime/exec/StreamsSurviveDestroy.java - test/jdk/java/lang/Runtime/exec/UnixCommands.java - test/jdk/java/lang/Runtime/exec/WinCommand.java - test/jdk/java/lang/Runtime/exec/setcwd.sh - test/jdk/java/lang/Runtime/loadLibrary/LoadLibraryTest.java - test/jdk/java/lang/Runtime/loadLibrary/src/Target.java - test/jdk/java/lang/Runtime/loadLibrary/src/Target2.java - test/jdk/java/lang/Runtime/shutdown/Basic.java - test/jdk/java/lang/Runtime/shutdown/ShutdownHooks.java - test/jdk/java/lang/Runtime/shutdown/ShutdownHooks.sh - test/jdk/java/lang/Runtime/shutdown/ShutdownInterruptedMain.java + test/jdk/java/lang/RuntimeTests/Resources.java + test/jdk/java/lang/RuntimeTests/Version/Basic.java + test/jdk/java/lang/RuntimeTests/Version/VersionProps.java + test/jdk/java/lang/RuntimeTests/exec/ArgWithSpaceAndFinalBackslash.java + test/jdk/java/lang/RuntimeTests/exec/BadEnvp.java + test/jdk/java/lang/RuntimeTests/exec/ConcurrentRead.java + test/jdk/java/lang/RuntimeTests/exec/Duped.java + test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java + test/jdk/java/lang/RuntimeTests/exec/ExecEmptyString.java + test/jdk/java/lang/RuntimeTests/exec/ExecWithDir.java + test/jdk/java/lang/RuntimeTests/exec/ExecWithInput.java + test/jdk/java/lang/RuntimeTests/exec/ExecWithLotsOfArgs.java + test/jdk/java/lang/RuntimeTests/exec/ExitValue.java + test/jdk/java/lang/RuntimeTests/exec/LotsOfDestroys.java + test/jdk/java/lang/RuntimeTests/exec/LotsOfOutput.java + test/jdk/java/lang/RuntimeTests/exec/SetCwd.java + test/jdk/java/lang/RuntimeTests/exec/SleepyCat.java + test/jdk/java/lang/RuntimeTests/exec/Space.java + test/jdk/java/lang/RuntimeTests/exec/Status.java + test/jdk/java/lang/RuntimeTests/exec/StreamsSurviveDestroy.java + test/jdk/java/lang/RuntimeTests/exec/UnixCommands.java + test/jdk/java/lang/RuntimeTests/exec/WinCommand.java + test/jdk/java/lang/RuntimeTests/exec/setcwd.sh + test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTest.java + test/jdk/java/lang/RuntimeTests/loadLibrary/src/Target.java + test/jdk/java/lang/RuntimeTests/loadLibrary/src/Target2.java + test/jdk/java/lang/RuntimeTests/shutdown/Basic.java + test/jdk/java/lang/RuntimeTests/shutdown/ShutdownHooks.java + test/jdk/java/lang/RuntimeTests/shutdown/ShutdownHooks.sh + test/jdk/java/lang/RuntimeTests/shutdown/ShutdownInterruptedMain.java + test/jdk/java/lang/instrument/RedefineRecordAttr/Host/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/Host/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostA/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostA/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostAB/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostAB/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostABC/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostABC/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostABCD/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostABD/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostAC/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostACB/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostB/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostBA/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostBAC/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostBCA/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostCAB/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/HostCBA/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttr/TestRecordAttr.java + test/jdk/java/lang/instrument/RedefineRecordAttrGenericSig/Host/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttrGenericSig/Host/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttrGenericSig/HostA/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttrGenericSig/HostA/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttrGenericSig/HostB/redef/Host.java + test/jdk/java/lang/instrument/RedefineRecordAttrGenericSig/TestRecordAttrGenericSig.java ! test/jdk/java/lang/instrument/TEST.properties + test/jdk/java/lang/reflect/records/RecordReflectionTest.java + test/jdk/java/lang/reflect/records/TEST.properties + test/jdk/java/lang/runtime/ObjectMethodsTest.java + test/jdk/java/lang/runtime/TEST.properties + test/jdk/java/lang/runtime/empty.policy ! test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java ! test/langtools/ProblemList.txt ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/examples/AnnotatedBinaryNode.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/examples/BinaryNode.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/examples/Coords.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/examples/Holder.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/examples/Node.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/examples/NonNull.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/examples/Point.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/examples/SerializablePoint.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/examples/SerializableProxy.java + test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk11/element-list ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java ! test/langtools/jdk/javadoc/tool/api/basic/GetTask_DiagListenerTest.java ! test/langtools/jdk/javadoc/tool/modules/ModuleTestBase.java ! test/langtools/jdk/javadoc/tool/reporter_generates_warnings/pkg/MyDoclet.java ! test/langtools/jdk/jshell/CompletenessTest.java ! test/langtools/lib/annotations/annotations/classfile/ClassfileInspector.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/lib/combo/tools/javac/combo/Template.java ! test/langtools/lib/combo/tools/javac/combo/TemplateTest.java ! test/langtools/tools/javac/6402516/CheckLocalElements.java ! test/langtools/tools/javac/MethodParameters/AttributeVisitor.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer2.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java + test/langtools/tools/javac/diags/examples/AccessorCantBeGeneric.java + test/langtools/tools/javac/diags/examples/AccessorCantThrowException.java + test/langtools/tools/javac/diags/examples/AccessorMethodCantBeStatic.java + test/langtools/tools/javac/diags/examples/AccessorReturnTypeDoesntMatch.java + test/langtools/tools/javac/diags/examples/CanonicalCantInvokeOtherConstructor.java + test/langtools/tools/javac/diags/examples/CanonicalConstructorArgumentMismatch.java + test/langtools/tools/javac/diags/examples/CanonicalConstructorCantHaveReturn.java + test/langtools/tools/javac/diags/examples/CanonicalConstructorCantHaveThrowsClause.java + test/langtools/tools/javac/diags/examples/CanonicalConstructorMustBePublic.java + test/langtools/tools/javac/diags/examples/CanonicalMustNotDeclareTypeVariables.java + test/langtools/tools/javac/diags/examples/ConstructorWithSameErasureAsCanonical.java + test/langtools/tools/javac/diags/examples/FirstInvocationMustBeAnotherConstructor.java + test/langtools/tools/javac/diags/examples/IllegalRecordComponentName.java ! test/langtools/tools/javac/diags/examples/IllegalStartOfStmt.java + test/langtools/tools/javac/diags/examples/InstanceInitializersNotAllowedInRecords.java + test/langtools/tools/javac/diags/examples/InvalidSuperTypeRecord.java + test/langtools/tools/javac/diags/examples/KindnameRecord.java + test/langtools/tools/javac/diags/examples/MethodMustBePublic.java + test/langtools/tools/javac/diags/examples/Records.java + test/langtools/tools/javac/diags/examples/RecordsCanNotDeclareInstanceFields.java + test/langtools/tools/javac/diags/examples/RecordsCantDeclareComponentModifiers.java + test/langtools/tools/javac/diags/examples/RecordsNotAllowedInInnerClasses.java ! test/langtools/tools/javac/expswitch/ExpSwitchNestingTest.java ! test/langtools/tools/javac/importscope/T8193717.java ! test/langtools/tools/javac/lambda/bridge/template_tests/BridgeMethodTestCase.java ! test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/langtools/tools/javac/modules/AnnotationProcessing.java ! test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java ! test/langtools/tools/javac/parser/extend/TrialParser.java ! test/langtools/tools/javac/patterns/scope/ScopeTest.java ! test/langtools/tools/javac/processing/model/TestSourceVersion.java ! test/langtools/tools/javac/processing/model/TestSymtabItems.java + test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java + test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java + test/langtools/tools/javac/processing/model/element/JavaxLangModelForRecords.java ! test/langtools/tools/javac/processing/model/element/TestElementKindPredicates.java + test/langtools/tools/javac/processing/model/element/TestRecord.java + test/langtools/tools/javac/processing/model/element/TestRecordDesugar.java ! test/langtools/tools/javac/processing/model/util/TestTypeKindVisitors.java + test/langtools/tools/javac/records/MapAccessorToComponent.java + test/langtools/tools/javac/records/RecordCompilationTests.java + test/langtools/tools/javac/records/RecordMemberTests.java + test/langtools/tools/javac/records/VarargsRecordsTest.java + test/langtools/tools/javac/records/mandated_members/CheckRecordMembers.java + test/langtools/tools/javac/records/mandated_members/read_resolve_method/CheckReadResolveMethodTest.java + test/langtools/tools/javac/records/writeread/Record.java + test/langtools/tools/javac/records/writeread/WriteReadTest.java ! test/langtools/tools/javac/tree/JavacTreeScannerTest.java ! test/langtools/tools/javac/tree/SourceTreeScannerTest.java ! test/langtools/tools/javac/tree/TreeKindTest.java ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java ! test/langtools/tools/lib/toolbox/ToolBox.java ! test/lib/jdk/test/lib/ByteCodeLoader.java Changeset: c22583a70542 Author: mseledtsov Date: 2019-12-04 14:44 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c22583a70542 8235356: [TESTBUG] Disable 'producer is alive' check in JFR TestCrossProcessStreaming Summary: disabled the check Reviewed-by: dcubed ! test/jdk/jdk/jfr/api/consumer/streaming/TestCrossProcessStreaming.java Changeset: 666fa504b60c Author: sviswanathan Date: 2019-12-04 14:55 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/666fa504b60c 8235288: AVX 512 instructions inadvertently used on Xeon for small vector width operations Reviewed-by: kvn, vlivanov ! src/hotspot/cpu/x86/macroAssembler_x86.hpp Changeset: e7f7be79ba52 Author: phh Date: 2019-12-04 15:01 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e7f7be79ba52 8234288: Turkey Time Zone returns incorrect time zone name Summary: Add and use "Turkey Time" time zone. Reviewed-by: naoto, martin, phh Contributed-by: letuyang at amazon.com ! src/java.base/share/classes/sun/util/resources/TimeZoneNames.java ! test/jdk/sun/text/resources/LocaleData ! test/jdk/sun/text/resources/LocaleDataTest.java Changeset: 1413f714d1a9 Author: cgo Date: 2019-12-04 10:38 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1413f714d1a9 8234906: [TESTBUG] TestDivZeroCheckControl fails for client VMs due to Unrecognized VM option LoopUnrollLimit Reviewed-by: kvn ! test/hotspot/jtreg/compiler/loopopts/TestDivZeroCheckControl.java Changeset: 18420160287b Author: weijun Date: 2019-12-05 10:36 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/18420160287b 8234267: DelegationPermission implementation doesn't completely follow the updated specification Reviewed-by: xuelei ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! test/jdk/javax/security/auth/kerberos/DelegationPermissionInit.java Changeset: 832efc785f53 Author: valeriep Date: 2019-12-05 03:55 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/832efc785f53 8233016: javax.crypto.Cipher throws NPE for the given custom CipherSpi and Provider Summary: Changed to throw IAE instead of NPE for non-null invalid arguments Reviewed-by: mullan ! src/java.base/share/classes/javax/crypto/Cipher.java From david.simms at oracle.com Thu Dec 5 08:50:49 2019 From: david.simms at oracle.com (david.simms at oracle.com) Date: Thu, 05 Dec 2019 08:50:49 +0000 Subject: hg: valhalla/valhalla: Added tag jdk-14+26 for changeset 288777cf0702 Message-ID: <201912050850.xB58ooYu000228@aojmv0008.oracle.com> Changeset: e4b6321c11a4 Author: jwilhelm Date: 2019-12-05 08:21 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e4b6321c11a4 Added tag jdk-14+26 for changeset 288777cf0702 ! .hgtags From tobias.hartmann at oracle.com Thu Dec 5 13:42:23 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 05 Dec 2019 13:42:23 +0000 Subject: hg: valhalla/valhalla: Merge Message-ID: <201912051342.xB5DgOPT017459@aojmv0008.oracle.com> Changeset: 87b84b7634db Author: thartmann Date: 2019-12-05 14:41 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/87b84b7634db Merge ! .hgtags ! make/autoconf/hotspot.m4 ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_GraphBuilder.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/compiler/compileBroker.cpp - src/hotspot/share/gc/g1/survRateGroup.cpp - src/hotspot/share/gc/g1/survRateGroup.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/memory/iterator.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/opto/arraycopynode.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiImpl.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/biasedLocking.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmOperations.cpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java - src/java.base/share/classes/java/time/overview.html - src/jdk.compiler/share/classes/META-INF/services/com.sun.tools.javac.platform.PlatformProvider ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.compiler/share/classes/com/sun/tools/javac/services/javax.tools.JavaCompilerTool ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt From maurizio.cimadamore at oracle.com Thu Dec 5 17:02:26 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Dec 2019 17:02:26 +0000 Subject: Hidden classes + class data In-Reply-To: References: <871949138.2149512.1574434660660.JavaMail.zimbra@u-pem.fr> <94ddd5c6-9729-e03f-9246-e30e83267c02@oracle.com> <65152B04-2358-46C6-828E-A0700E43BEF6@oracle.com> <1737758747.13944.1574809432804.JavaMail.zimbra@u-pem.fr> <66898D0F-53EE-42C8-AC9E-288BE7400DA3@oracle.com> <4a397388-1fea-a99d-941b-a74296675de8@oracle.com> Message-ID: On 02/12/2019 19:55, Mandy Chung wrote: > > > On 12/2/19 7:50 AM, Maurizio Cimadamore wrote: >> >> On 27/11/2019 01:30, Mandy Chung wrote: >>> >>> >>> On 11/26/19 4:55 PM, John Rose wrote: >>>> On Nov 26, 2019, at 3:03 PM, forax at univ-mlv.fr wrote: >>>>> I wonder if defineHiddenClassWithClassData should not take another >>>>> class as parameter instead of a byte array (using the byte array >>>>> of that class) enabling more sharing of the bytecode and allowing >>>>> to do the? verification only once if >>>>> defineHiddenClassWithClassData is called several times with the >>>>> same Class. >>>> Yes.? I?d like to try this with templates, when we get them, since >>>> templates are supposed to share metadata with their species. >>>> >>>> E.g., for a lambda form of a predefined shape with 2 free variables >>>> (a type and a MH), define it as a template with those parameters >>>> and inject it as many times as you see distinct combinations of >>>> those parameters. >>> >>> This produces a distinct Class mirror for each hidden class defined >>> from the same metadata (class bytes) with a different class data. >>> >>> Perhaps we can experiment ClassDefiner builder-like API.?? I will >>> explore this. >> >> In the MVT Valhalla prototype we used to have a way to obtain a >> method handle using a 'method builder' (from the bytecode API used >> there). I think it should be possible to do the same, using a 'class >> builder' - so that you can actually define the contents of the class >> w/o specifying a byte array, down to the code attribute level. In >> other words, there is a big overlap with what you call a >> 'ClassDefiner' builder and the builders provided by the bytecode API >> under exploration, so I think it'd be best to try and avoid to solve >> the same problem twice. >> > > Yes I remember that.? I agree and we should avoid solving the same > problem twice.? There was a plan to include the bytecode API in the > JDK.?? Any update/news on that? We're still hacking on that... Maurizio > > Mandy From maurizio.cimadamore at oracle.com Thu Dec 5 17:25:57 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Dec 2019 17:25:57 +0000 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> Message-ID: <85eef535-fe0f-2abc-24af-7fdc494320c1@oracle.com> Hi Mandy, reads great - other possible use cases worth mentioning in the JEP is InvokerBytecodeGenerator for lambda forms. (we also have one in the memory access API, to customize memory access VarHandles). Maurizio On 05/12/2019 01:13, Mandy Chung wrote: > Draft JEP: > ? https://bugs.openjdk.java.net/browse/JDK-8220607 > > The past discussion was tracked in JDK-8171335 [1] regarding dynamic > nestmates and the replacement of Unsafe::defineAnonymousClass which > consists of four separable features: > 1. non-discoverable and cannot participate in symbolic resolution > 2. lifecycle is independent of its defining class loader > 3. private member access of the given host class > 4. constant pool patching > > The JEP proposes to support a new kind of classes: "hidden classes" > that can optionally join as a member of a nest and/or can be weakly > referenced by its defining class loader. It covers 1-3 above. ? 4 is > separated from this JEP to give time to explore the class data support > that may benefit to prototype with template classes. > > javadoc and specdiff: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > The current prototype is in the nestmates branch and all JDK use of > Unsafe::defineAnonymousClass are replaced with hidden classes [3]. > > thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8171335 > [2] https://bugs.openjdk.java.net/browse/JDK-8230501 > [3] > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/ > From mandy.chung at oracle.com Thu Dec 5 17:58:34 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Dec 2019 09:58:34 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <85eef535-fe0f-2abc-24af-7fdc494320c1@oracle.com> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <85eef535-fe0f-2abc-24af-7fdc494320c1@oracle.com> Message-ID: <1c78fcd9-51c7-cbae-82e6-7b7a979f460a@oracle.com> Maurizio, thanks for reviewing. Lambda forms are one use case.? As it's more the internals of method handle implementation as IR and its dependency on class data support, I think it's okay to leave it out. Mandy On 12/5/19 9:25 AM, Maurizio Cimadamore wrote: > Hi Mandy, > reads great - other possible use cases worth mentioning in the JEP is > InvokerBytecodeGenerator for lambda forms. (we also have one in the > memory access API, to customize memory access VarHandles). > > Maurizio > > On 05/12/2019 01:13, Mandy Chung wrote: >> Draft JEP: >> ? https://bugs.openjdk.java.net/browse/JDK-8220607 >> >> The past discussion was tracked in JDK-8171335 [1] regarding dynamic >> nestmates and the replacement of Unsafe::defineAnonymousClass which >> consists of four separable features: >> 1. non-discoverable and cannot participate in symbolic resolution >> 2. lifecycle is independent of its defining class loader >> 3. private member access of the given host class >> 4. constant pool patching >> >> The JEP proposes to support a new kind of classes: "hidden classes" >> that can optionally join as a member of a nest and/or can be weakly >> referenced by its defining class loader. It covers 1-3 above. ? 4 is >> separated from this JEP to give time to explore the class data >> support that may benefit to prototype with template classes. >> >> javadoc and specdiff: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> The current prototype is in the nestmates branch and all JDK use of >> Unsafe::defineAnonymousClass are replaced with hidden classes [3]. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8171335 >> [2] https://bugs.openjdk.java.net/browse/JDK-8230501 >> [3] >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/ >> From paul.sandoz at oracle.com Thu Dec 5 23:29:51 2019 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 Dec 2019 15:29:51 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> Message-ID: Very nicely written and extremely informative. Since Nashorn was deprecated in 11 (https://openjdk.java.net/jeps/335 ) is it worth updating it? ? At run time, any attempt to resolve a hidden class by name, it may result in a LinkageError which is no difference from resolving a symbolic reference to an ordinary class that cannot be found. ? -> ? At run time, any attempt to resolve a hidden class by name may result in a LinkageError, which is no differer from resolving a symbolic reference to an ordinary class that cannot be found. " ?May? or ?will? ? ? A hidden class' name is disjoint from ordinary class names is accomplished for it to include a /. It is not a binary name (JVMS 4.2.1), ... ? -> ? The namespace of a hidden class names is disjoint from the namespace of ordinary class names. A hidden class name is not a binary name (JVMS 4.2.1), and thus such a name is forbidden when passed as the first argument to ... ? ? If C's static nest membership is invalid, then the hidden class is added as a member of the nest of C as nest host (C becomes the nest host of its own nest) and the error occurs during nest membership validation is not propagated. ? s/error occurs/error occurring/ ? Accordingly, hidden classes will not have the ability to control their optimization, even when defined by JDK code. (This is not thought to present any risk to the migration of JDK code from defining VM-anonymous classes to defining hidden classes.) ? (You probably know this?) FWIW it's not the case for classes defined for lambda forms which do make use of @DontInline and @ForceInline. Although such classes are generated with patching, so when public support for patching is added this assumption may need to be revised if we want to replace the Unsafe usages. What about final fields being implicitly stable fields for classes in java.lang.invoke? I would presume a hidden class might inherit such policies from its lookup class. Paul. > On Dec 4, 2019, at 5:13 PM, Mandy Chung wrote: > > Draft JEP: > https://bugs.openjdk.java.net/browse/JDK-8220607 > > The past discussion was tracked in JDK-8171335 [1] regarding dynamic nestmates and the replacement of Unsafe::defineAnonymousClass which consists of four separable features: > 1. non-discoverable and cannot participate in symbolic resolution > 2. lifecycle is independent of its defining class loader > 3. private member access of the given host class > 4. constant pool patching > > The JEP proposes to support a new kind of classes: "hidden classes" that can optionally join as a member of a nest and/or can be weakly referenced by its defining class loader. It covers 1-3 above. 4 is separated from this JEP to give time to explore the class data support that may benefit to prototype with template classes. > > javadoc and specdiff: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > The current prototype is in the nestmates branch and all JDK use of Unsafe::defineAnonymousClass are replaced with hidden classes [3]. > > thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8171335 > [2] https://bugs.openjdk.java.net/browse/JDK-8230501 > [3] http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/ > From mandy.chung at oracle.com Fri Dec 6 02:05:23 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Dec 2019 18:05:23 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> Message-ID: On 12/5/19 3:29 PM, Paul Sandoz wrote: > Very nicely written and extremely informative. > Thanks.? Kudos to Alex B. for his feedback and improved writing. > > Since Nashorn was deprecated in 11 > (https://openjdk.java.net/jeps/335)?is it worth updating it? > > It was a good exercise to identify any migration challenge.? It turns out it's straight-forward. http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java.sdiff.html Like the dynamic proxy, nashorn generates classes in a dynamic module for strong encapsulation.?? Allowing a hidden class to be injected in an empty package is something we should look into in the future. > > ? > At run time, any attempt to resolve a hidden class by name, it may > result in a?LinkageError?which is no difference from?resolving a > symbolic reference to an ordinary class that cannot be found. > ? > -> > ? > At run time, any attempt to resolve a hidden class by name may result > in a?LinkageError,?which is no differer from?resolving a symbolic > reference to an ordinary class that cannot be found. > " > > ?May? or ?will? ? > Should be "will".? I have to remind myself why I wrote "may" at that time (it has been quite some time ago). : > > ? > Accordingly, hidden classes will not have the ability to control their > optimization, even when defined by JDK code. (This is not?thought to > present any risk to the migration of JDK code from defining > VM-anonymous classes to defining hidden classes.) > ? > > (You probably know this?) FWIW it's not the case for classes defined > for lambda forms which do make use of @DontInline and @ForceInline. > ?Although such classes are generated with patching, so when public > support for patching is added this assumption may need to be revised > if we want to replace the Unsafe usages. Lambda forms are trusted classes defined by the bootstrap class loader and so they get access to these VM internal annotations. It's replaced with a package-private Lookup::defineHiddenClassWithClassData for now. http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java.udiff.html > > What about final fields being implicitly stable fields for classes in > java.lang.invoke? > AFAICS, hidden class doesn't affect this at all as it's determined by java.lang.invoke package, right? > I would presume a hidden class might inherit such policies from its > lookup class. > I will double check. Mandy From mandy.chung at oracle.com Fri Dec 6 02:07:02 2019 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 06 Dec 2019 02:07:02 +0000 Subject: hg: valhalla/valhalla: Merge Message-ID: <201912060207.xB6272c5017321@aojmv0008.oracle.com> Changeset: eee025d47c8a Author: mchung Date: 2019-12-05 18:06 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/eee025d47c8a Merge ! make/hotspot/symbols/symbols-unix ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/classfile/vmSymbols.hpp - src/hotspot/share/gc/g1/survRateGroup.cpp - src/hotspot/share/gc/g1/survRateGroup.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/cpCache.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/prims/jvm.cpp ! src/hotspot/share/prims/jvmti.xml ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/unsafe.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.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/time/overview.html ! src/java.base/share/native/libjava/Class.c - src/jdk.compiler/share/classes/META-INF/services/com.sun.tools.javac.platform.PlatformProvider ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java - src/jdk.compiler/share/classes/com/sun/tools/javac/services/javax.tools.JavaCompilerTool ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java - src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystem.java - src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystemProvider.java ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt - test/jdk/java/lang/Runtime/Resources.java - test/jdk/java/lang/Runtime/Version/Basic.java - test/jdk/java/lang/Runtime/Version/VersionProps.java - test/jdk/java/lang/Runtime/exec/ArgWithSpaceAndFinalBackslash.java - test/jdk/java/lang/Runtime/exec/BadEnvp.java - test/jdk/java/lang/Runtime/exec/ConcurrentRead.java - test/jdk/java/lang/Runtime/exec/Duped.java - test/jdk/java/lang/Runtime/exec/ExecCommand.java - test/jdk/java/lang/Runtime/exec/ExecEmptyString.java - test/jdk/java/lang/Runtime/exec/ExecWithDir.java - test/jdk/java/lang/Runtime/exec/ExecWithInput.java - test/jdk/java/lang/Runtime/exec/ExecWithLotsOfArgs.java - test/jdk/java/lang/Runtime/exec/ExitValue.java - test/jdk/java/lang/Runtime/exec/LotsOfDestroys.java - test/jdk/java/lang/Runtime/exec/LotsOfOutput.java - test/jdk/java/lang/Runtime/exec/SetCwd.java - test/jdk/java/lang/Runtime/exec/SleepyCat.java - test/jdk/java/lang/Runtime/exec/Space.java - test/jdk/java/lang/Runtime/exec/Status.java - test/jdk/java/lang/Runtime/exec/StreamsSurviveDestroy.java - test/jdk/java/lang/Runtime/exec/UnixCommands.java - test/jdk/java/lang/Runtime/exec/WinCommand.java - test/jdk/java/lang/Runtime/exec/setcwd.sh - test/jdk/java/lang/Runtime/loadLibrary/LoadLibraryTest.java - test/jdk/java/lang/Runtime/loadLibrary/src/Target.java - test/jdk/java/lang/Runtime/loadLibrary/src/Target2.java - test/jdk/java/lang/Runtime/shutdown/Basic.java - test/jdk/java/lang/Runtime/shutdown/ShutdownHooks.java - test/jdk/java/lang/Runtime/shutdown/ShutdownHooks.sh - test/jdk/java/lang/Runtime/shutdown/ShutdownInterruptedMain.java - test/jdk/jdk/jfr/api/consumer/streaming/TestRepositoryMigration.java - test/jdk/sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java - test/langtools/jdk/javadoc/doclet/testDocFiles/pkg/Test.java - test/langtools/jdk/javadoc/doclet/testDocFiles/pkg/doc-files/test.txt ! test/langtools/lib/annotations/annotations/classfile/ClassfileInspector.java ! test/langtools/tools/javac/MethodParameters/AttributeVisitor.java ! test/langtools/tools/javac/lambda/methodReference/ProtectedInaccessibleMethodRefTest2.java From david.holmes at oracle.com Fri Dec 6 02:23:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Dec 2019 12:23:55 +1000 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> Message-ID: <437f7bb2-0fd7-7245-c26d-21f919effec9@oracle.com> On 6/12/2019 12:05 pm, Mandy Chung wrote: > On 12/5/19 3:29 PM, Paul Sandoz wrote: >> Very nicely written and extremely informative. >> > > Thanks.? Kudos to Alex B. for his feedback and improved writing. >> >> Since Nashorn was deprecated in 11 >> (https://openjdk.java.net/jeps/335)?is it worth updating it? >> >> > > It was a good exercise to identify any migration challenge.? It turns > out it's straight-forward. > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java.sdiff.html > > > Like the dynamic proxy, nashorn generates classes in a dynamic module > for strong encapsulation.?? Allowing a hidden class to be injected in an > empty package is something we should look into in the future. > >> >> ? >> At run time, any attempt to resolve a hidden class by name, it may >> result in a?LinkageError?which is no difference from?resolving a >> symbolic reference to an ordinary class that cannot be found. >> ? >> -> >> ? >> At run time, any attempt to resolve a hidden class by name may result >> in a?LinkageError,?which is no differer from?resolving a symbolic >> reference to an ordinary class that cannot be found. >> " >> >> ?May? or ?will? ? >> > > Should be "will".? I have to remind myself why I wrote "may" at that > time (it has been quite some time ago). It's unclear to me from that text whether this is referring to the augmented name of the hidden class ie. com.example.Foo/1234, or the name that may be present in the byte array. If the former then LE will be thrown. If the latter then LE may be thrown as you may have a different classfile using the same name. BTW typo: "no difference" -> "no different" Cheers, David > : > >> >> ? >> Accordingly, hidden classes will not have the ability to control their >> optimization, even when defined by JDK code. (This is not?thought to >> present any risk to the migration of JDK code from defining >> VM-anonymous classes to defining hidden classes.) >> ? >> >> (You probably know this?) FWIW it's not the case for classes defined >> for lambda forms which do make use of @DontInline and @ForceInline. >> ?Although such classes are generated with patching, so when public >> support for patching is added this assumption may need to be revised >> if we want to replace the Unsafe usages. > > Lambda forms are trusted classes defined by the bootstrap class loader > and so they get access to these VM internal annotations. > > It's replaced with a package-private > Lookup::defineHiddenClassWithClassData for now. > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java.udiff.html > > >> >> What about final fields being implicitly stable fields for classes in >> java.lang.invoke? >> > > AFAICS, hidden class doesn't affect this at all as it's determined by > java.lang.invoke package, right? > >> I would presume a hidden class might inherit such policies from its >> lookup class. >> > > I will double check. > > Mandy > > From mandy.chung at oracle.com Fri Dec 6 03:15:26 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Dec 2019 19:15:26 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <437f7bb2-0fd7-7245-c26d-21f919effec9@oracle.com> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <437f7bb2-0fd7-7245-c26d-21f919effec9@oracle.com> Message-ID: On 12/5/19 6:23 PM, David Holmes wrote: >> Should be "will". I have to remind myself why I wrote "may" at that >> time (it has been quite some time ago). > > It's unclear to me from that text whether this is referring to the > augmented name of the hidden class ie. com.example.Foo/1234, or the > name that may be present in the byte array. If the former then LE will > be thrown. If the latter then LE may be thrown as you may have a > different classfile using the same name. > Thanks.? Now reading the context around this sentence, I used "may" intentionally. This is indeed unclear.?? A class file can never have a symbolic reference to "com.example.foo/1234" since the descriptor is in internal form.??? If it attempts to reference a class name "com.example.foo/1234".replace(".", "/") or "com/example/foo" - a class of that name may or may not be found. > BTW typo: "no difference" -> "no different" Fixed. Mandy From paul.sandoz at oracle.com Fri Dec 6 16:39:14 2019 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 Dec 2019 08:39:14 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> Message-ID: > On Dec 5, 2019, at 6:05 PM, Mandy Chung wrote: > > > > On 12/5/19 3:29 PM, Paul Sandoz wrote: >> Very nicely written and extremely informative. >> > > Thanks. Kudos to Alex B. for his feedback and improved writing. >> >> Since Nashorn was deprecated in 11 (https://openjdk.java.net/jeps/335) is it worth updating it? >> >> > > It was a good exercise to identify any migration challenge. It turns out it's straight-forward. > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java.sdiff.html > > Like the dynamic proxy, nashorn generates classes in a dynamic module for strong encapsulation. Allowing a hidden class to be injected in an empty package is something we should look into in the future. Ok. > >> >> ? >> At run time, any attempt to resolve a hidden class by name, it may result in a LinkageError which is no difference from resolving a symbolic reference to an ordinary class that cannot be found. >> ? >> -> >> ? >> At run time, any attempt to resolve a hidden class by name may result in a LinkageError, which is no differer from resolving a symbolic reference to an ordinary class that cannot be found. >> " >> >> ?May? or ?will? ? >> > > Should be "will". I have to remind myself why I wrote "may" at that time (it has been quite some time ago). > > : > >> >> ? >> Accordingly, hidden classes will not have the ability to control their optimization, even when defined by JDK code. (This is not thought to present any risk to the migration of JDK code from defining VM-anonymous classes to defining hidden classes.) >> ? >> >> (You probably know this?) FWIW it's not the case for classes defined for lambda forms which do make use of @DontInline and @ForceInline. Although such classes are generated with patching, so when public support for patching is added this assumption may need to be revised if we want to replace the Unsafe usages. > > Lambda forms are trusted classes defined by the bootstrap class loader and so they get access to these VM internal annotations. > > It's replaced with a package-private Lookup::defineHiddenClassWithClassData for now. > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java.udiff.html > Ok. >> >> What about final fields being implicitly stable fields for classes in java.lang.invoke? >> > > AFAICS, hidden class doesn't affect this at all as it's determined by java.lang.invoke package, right? > >> I would presume a hidden class might inherit such policies from its lookup class. >> > > I will double check. > My memory is hazy on this: I thought the same trigger (package of the lookup class) for whether those compiler-based annotations were allowed was the same trigger for whether final fields were trusted. So I had some slight concern that replacements with the public methods in the JDK for code within j.l.lnvoke (bootstrap methods etc) might affect final field behavior. Paul. From Roger.Riggs at oracle.com Fri Dec 6 19:52:51 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 6 Dec 2019 14:52:51 -0500 Subject: RFR 8235492 : Update Prototype HashMap using inline classes Message-ID: <04fd14ee-b06a-8bb2-a311-ab444057861e@oracle.com> Updates to a prototype HashMap implementation using inline-classes and open hashing and corresponding jmh tests.? The jmh tests are structured to compare the current HashMap with the new HashMap in the jmh valhalla/corelibs/mapprotos package. The performance is not quite up to the current HashMap metrics so more investigation is needed. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-inline-hashmap-micros-8235492/webrev-inline-hashmap-micros-8235492/webrev/ Regards, Roger From kasperni at gmail.com Fri Dec 6 20:09:06 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 6 Dec 2019 20:09:06 +0000 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> Message-ID: On Thu, 5 Dec 2019 at 01:13, <(unknown sender)> wrote: > > Draft JEP: > ? https://bugs.openjdk.java.net/browse/JDK-8220607 Looks good, one quick question though. Is there any reason for the asymmetry with Lookup.defineClass()? defineHiddenClass() takes a boolean initialize parameter while defineClass() does not. Also, as I see it there is no way to defer initialization of a hidden class, without instantiating an instance of it? Normally you can get around the fact that Unsafe.ensureClassInitialized is not public via Class.forName. Making Unsafe.ensureClassInitialized public in some way would also help when trying to implement the SharedSecrets "pattern" for modular access outside of the JDK. try { Class.forName(initalizeClass.getName(), true, initalizeClass.getClassLoader()); } catch (ClassNotFoundException e) { throw new ExceptionInInitializerError(e); // Should never happen } Is a bit of an eyesore. /Kasper From kasperni at gmail.com Fri Dec 6 20:55:34 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 6 Dec 2019 20:55:34 +0000 Subject: inline string Message-ID: Hi, Are there any plans to add an InlineString type to the JDK? I can imagine that the first thing every single library out there will do with Valhalla is to implement their own inline string. It would be really nice to have a standardized version with good interop with JDK classes. /Kasper From forax at univ-mlv.fr Fri Dec 6 21:11:04 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 6 Dec 2019 22:11:04 +0100 (CET) Subject: inline string In-Reply-To: References: Message-ID: <1652034567.13519.1575666664841.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Kasper Nielsen" > ?: "valhalla-dev" > Envoy?: Vendredi 6 D?cembre 2019 21:55:34 > Objet: inline string > Hi, Hi Kasper, > > Are there any plans to add an InlineString type to the JDK? > > I can imagine that the first thing every single library out there will do with > Valhalla is to implement their own inline string. It would be really nice to > have a standardized version with good interop with JDK classes. you mean [1] :) I think it's fine as an exercise (my implementation is how to use unsafe with inlined fields) but i disagree that the JDK should have such class because one implementation of String is far better than two (or three, four like you have in any decent C++ application) whatever the performance you get (and having performance when you re-implement String without the intrinsics is not easy). Maybe in the future, with Array 2.0 (an array that behave like an inline) and the panama vector API, String implementation may be changed but introducing another kind of String seems a bad idea. > > /Kasper R?mi [1] https://github.com/forax/valuetype-lworld/blob/master/src/main/java/fr.umlv.valuetype/fr/umlv/valuetype/SmallString.java From mandy.chung at oracle.com Fri Dec 6 22:21:49 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Dec 2019 14:21:49 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> Message-ID: <978528f5-bbf8-0899-fd7d-5dd367d8e696@oracle.com> On 12/6/19 12:09 PM, Kasper Nielsen wrote: > On Thu, 5 Dec 2019 at 01:13, <(unknown sender)> wrote: >> Draft JEP: >> ? https://bugs.openjdk.java.net/browse/JDK-8220607 > Looks good, one quick question though. Is there any reason for the asymmetry > with Lookup.defineClass()? defineHiddenClass() takes a boolean initialize > parameter while defineClass() does not. Another asymmetry between Lookup::defineClass and defineHiddenClass is the return value, Class vs Lookup. It's trivial to get the class from a Lookup object but we can't go the other way. If a framework wants to get Lookup from a hidden class it just defines (e.g. get a MethodHandle and invoke), if dHC returned a Class, the hidden class had to provide an entry point to return its Lookup object.? Such entry point has to be accessible to the framework but it has to be cautious in leaking its full-power Lookup. > Also, as I see it there is no way to defer initialization of a hidden class, > without instantiating an instance of it? Normally you can get around the fact > that Unsafe.ensureClassInitialized is not public via Class.forName. Exactly since `Class::forName` with initialize=true to invoke `` does not work for a hidden class. FWIW.? A class may also be initialized as a result of execution of other bytecodes such as getstatic, putstatic, invokestatic etc as specified in JVMS 5.5 besides new. > Making Unsafe.ensureClassInitialized public in some way would also help when > trying to implement the SharedSecrets "pattern" for modular access outside of > the JDK. > > try { > Class.forName(initalizeClass.getName(), true, > initalizeClass.getClassLoader()); > } catch (ClassNotFoundException e) { > throw new ExceptionInInitializerError(e); // Should never happen > } > > Is a bit of an eyesore. Yes it is. I have considered adding Lookup::defineClassAsLookup(byte[] bytes, boolean initialize).?? Lookup::defineClass was added in JDK 9.?? I haven't seen any request to initialize the class.?? So I think it can be done as a separate enhancement.? I will file a JBS issue. Mandy From brian.goetz at oracle.com Fri Dec 6 22:51:50 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 6 Dec 2019 17:51:50 -0500 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <978528f5-bbf8-0899-fd7d-5dd367d8e696@oracle.com> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <978528f5-bbf8-0899-fd7d-5dd367d8e696@oracle.com> Message-ID: <4de73f82-1a93-a516-4f49-496702903f32@oracle.com> > Another asymmetry between Lookup::defineClass and defineHiddenClass is > the return value, Class vs Lookup. > > It's trivial to get the class from a Lookup object but we can't go the > other way. If a framework wants to get Lookup from a hidden class it > just defines (e.g. get a MethodHandle and invoke), if dHC returned a > Class, the hidden class had to provide an entry point to return its > Lookup object.? Such entry point has to be accessible to the framework > but it has to be cautious in leaking its full-power Lookup. For the reasons you give, this asymmetry doesn't bother me.? Most users of dC will want the class; users of dHC will generally _need_ the lookup. > > I have considered adding Lookup::defineClassAsLookup(byte[] bytes, > boolean initialize).?? Lookup::defineClass was added in JDK 9.?? I > haven't seen any request to initialize the class.?? So I think it can > be done as a separate enhancement.? I will file a JBS issue. I agree that this should be a separate enhancement. I'd like to see this bit of unsafe removed too, but no need to hold up this train to get to that one. From mandy.chung at oracle.com Fri Dec 6 23:32:14 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Dec 2019 15:32:14 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <4de73f82-1a93-a516-4f49-496702903f32@oracle.com> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <978528f5-bbf8-0899-fd7d-5dd367d8e696@oracle.com> <4de73f82-1a93-a516-4f49-496702903f32@oracle.com> Message-ID: <01bb3376-9a9e-50fd-1db9-e87ed42ec23a@oracle.com> On 12/6/19 2:51 PM, Brian Goetz wrote: > >> Another asymmetry between Lookup::defineClass and defineHiddenClass >> is the return value, Class vs Lookup. >> >> It's trivial to get the class from a Lookup object but we can't go >> the other way. If a framework wants to get Lookup from a hidden class >> it just defines (e.g. get a MethodHandle and invoke), if dHC returned >> a Class, the hidden class had to provide an entry point to return its >> Lookup object.? Such entry point has to be accessible to the >> framework but it has to be cautious in leaking its full-power Lookup. > > For the reasons you give, this asymmetry doesn't bother me.? Most > users of dC will want the class; users of dHC will generally _need_ > the lookup. > >> >> I have considered adding Lookup::defineClassAsLookup(byte[] bytes, >> boolean initialize).?? Lookup::defineClass was added in JDK 9.?? I >> haven't seen any request to initialize the class. So I think it can >> be done as a separate enhancement.? I will file a JBS issue. > > I agree that this should be a separate enhancement. I'd like to see > this bit of unsafe removed too, but no need to hold up this train to > get to that one. > https://bugs.openjdk.java.net/browse/JDK-8235521 Mandy From kasperni at gmail.com Fri Dec 6 23:34:13 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 6 Dec 2019 23:34:13 +0000 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <978528f5-bbf8-0899-fd7d-5dd367d8e696@oracle.com> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <978528f5-bbf8-0899-fd7d-5dd367d8e696@oracle.com> Message-ID: On Fri, 6 Dec 2019 at 22:22, Mandy Chung wrote: > > > > On 12/6/19 12:09 PM, Kasper Nielsen wrote: > > On Thu, 5 Dec 2019 at 01:13, <(unknown sender)> wrote: > >> Draft JEP: > >> ? https://bugs.openjdk.java.net/browse/JDK-8220607 > > Looks good, one quick question though. Is there any reason for the asymmetry > > with Lookup.defineClass()? defineHiddenClass() takes a boolean initialize > > parameter while defineClass() does not. > > Another asymmetry between Lookup::defineClass and defineHiddenClass is > the return value, Class vs Lookup. Right, I was merely questioning which situations you would need to initialize a hidden class, but not a "normal" class. I think of the use cases for Lookup::defineHiddenClass as a subset of those for Lookup::defineClass > It's trivial to get the class from a Lookup object but we can't go the > other way. If a framework wants to get Lookup from a hidden class it > just defines (e.g. get a MethodHandle and invoke), if dHC returned a > Class, the hidden class had to provide an entry point to return its > Lookup object. Such entry point has to be accessible to the framework > but it has to be cautious in leaking its full-power Lookup. At first glance, I was a bit puzzled by the return type, but it's quite a clever solution. > I have considered adding Lookup::defineClassAsLookup(byte[] bytes, > boolean initialize). Lookup::defineClass was added in JDK 9. I > haven't seen any request to initialize the class. So I think it can be > done as a separate enhancement. I will file a JBS issue. I don't think Lookup::defineClassAsLookup is enough, something like Lookup::ensureClassInitialized(Class clazz) (requiring MODULE_ACCESS?) is still needed in my opinion. Again since we don't have any way of expressing that a certain member is only accessible within a single module. I have had to implement something similar to jdk.internal.misc.SharedSecrets in a couple of libraries. public static JavaLangModuleAccess getJavaLangModuleAccess() { if (javaLangModuleAccess == null) { unsafe.ensureClassInitialized(ModuleDescriptor.class); } return javaLangModuleAccess; } Unfortunately, without some kind of Lookup::ensureClassInitialized method, you will still need to resort to Class.forName outside of the JDK. I know this is quite a specialized use case, but I'm sure other people will run into the issue as more and more libraries are better encapsulated. Thanks Kasper From kasperni at gmail.com Fri Dec 6 23:37:27 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 6 Dec 2019 23:37:27 +0000 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <01bb3376-9a9e-50fd-1db9-e87ed42ec23a@oracle.com> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <978528f5-bbf8-0899-fd7d-5dd367d8e696@oracle.com> <4de73f82-1a93-a516-4f49-496702903f32@oracle.com> <01bb3376-9a9e-50fd-1db9-e87ed42ec23a@oracle.com> Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8235521 > > Mandy Hi Mandy, Ignore my previous email, I mistakenly thought you would only add defineClassAsLookup(). Thanks Kasper From mandy.chung at oracle.com Sat Dec 7 00:06:44 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Dec 2019 16:06:44 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <978528f5-bbf8-0899-fd7d-5dd367d8e696@oracle.com> <4de73f82-1a93-a516-4f49-496702903f32@oracle.com> <01bb3376-9a9e-50fd-1db9-e87ed42ec23a@oracle.com> Message-ID: <3b97dcf5-5b00-bde3-b349-972d8e377f9d@oracle.com> On 12/6/19 3:37 PM, Kasper Nielsen wrote: >> https://bugs.openjdk.java.net/browse/JDK-8235521 >> >> Mandy > Hi Mandy, > > Ignore my previous email, I mistakenly thought you would only add > defineClassAsLookup(). > > No worries.? I should have made it clearer. Lookup::ensureClassInitialized is a possibility.? A framework may not always get a Lookup with MODULE access. Class::ensureInitialized is an alternative.? In any case, we have to work through this. thanks Mandy From david.simms at oracle.com Mon Dec 9 09:18:40 2019 From: david.simms at oracle.com (David Simms) Date: Mon, 9 Dec 2019 10:18:40 +0100 Subject: Future direction, check out the spec experts list email of late... Message-ID: <325711b5-621c-8939-8a85-e94c9858ea20@oracle.com> If you are not actively subscribed to the spec experts (directly or via forwarding list "valhalla-spec-observers"), now is a good time to read through archives from the last few days: https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-December/thread.html /D From kasperni at gmail.com Mon Dec 9 12:19:52 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Mon, 9 Dec 2019 12:19:52 +0000 Subject: inline string In-Reply-To: <1652034567.13519.1575666664841.JavaMail.zimbra@u-pem.fr> References: <1652034567.13519.1575666664841.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, > > I think it's fine as an exercise (my implementation is how to use unsafe with inlined fields) but i disagree that the JDK should have such class because one implementation of String is far better than two (or three, four like you have in any decent C++ application) whatever the performance you get (and having performance when you re-implement String without the intrinsics is not easy). > > Maybe in the future, with Array 2.0 (an array that behave like an inline) and the panama vector API, String implementation may be changed but introducing another kind of String seems a bad idea. This makes sense to me. As I understand it fused arrays will never work with inline types because the size of an inline type needs to be constant. So you end up with either an inline type and a referenced array. Or a reference type and a fused array. Either way, you need to allocate something on the heap. Thanks Kasper From roger.riggs at oracle.com Mon Dec 9 19:42:38 2019 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Mon, 09 Dec 2019 19:42:38 +0000 Subject: hg: valhalla/valhalla: 8235492: Update Prototype HashMap using inline classes Message-ID: <201912091942.xB9Jgc72013722@aojmv0008.oracle.com> Changeset: 2cf707b0e227 Author: rriggs Date: 2019-12-06 14:44 -0500 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/2cf707b0e227 8235492: Update Prototype HashMap using inline classes ! test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/GetX.java + test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/HashMap.java ! test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/HashMapBench.java ! test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/HashMapToArray.java ! test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/MapBase.java ! test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/PutX.java ! test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/README.md ! test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/ReplX.java ! test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/WalkX.java - test/micro/org/openjdk/bench/valhalla/corelibs/mapprotos/YHashMap.java From forax at univ-mlv.fr Mon Dec 9 23:19:45 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 10 Dec 2019 00:19:45 +0100 (CET) Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> Message-ID: <1259645747.535320.1575933585592.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > ?: "mandy chung" > Cc: "valhalla-dev" > Envoy?: Vendredi 6 D?cembre 2019 17:39:14 > Objet: Re: RFR: 8220607 Draft JEP: Hidden Classes Hi Paul, ... >>> >>> What about final fields being implicitly stable fields for classes in >>> java.lang.invoke? >>> >> >> AFAICS, hidden class doesn't affect this at all as it's determined by >> java.lang.invoke package, right? >> >>> I would presume a hidden class might inherit such policies from its lookup >>> class. >>> >> >> I will double check. >> > > My memory is hazy on this: I thought the same trigger (package of the lookup > class) for whether those compiler-based annotations were allowed was the same > trigger for whether final fields were trusted. So I had some slight concern > that replacements with the public methods in the JDK for code within j.l.lnvoke > (bootstrap methods etc) might affect final field behavior. For anonymous classes created using unsafe.defineAnonymousClass, final fields of all of them are considered as trusted, independent of if the host class is in java.lang or not. This is a very important property for adapter codes (generated dynamically) in a dynamic language because it means that if the adapter is constant (bound in a method handle tree in my case) then all the field access will be replaced by constants so the whole code will be constant folded. I rely on this property heavily. If hidden classes have not that property, it means that hidden classes are useless for me and that people will see perf regressions if they are using lambdas stored in static final fields if lambdas starts to use hidden classes instead of anonymous classes. > > Paul. R?mi From mandy.chung at oracle.com Mon Dec 9 23:51:15 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Dec 2019 15:51:15 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <1259645747.535320.1575933585592.JavaMail.zimbra@u-pem.fr> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <1259645747.535320.1575933585592.JavaMail.zimbra@u-pem.fr> Message-ID: On 12/9/19 3:19 PM, Remi Forax wrote: >> My memory is hazy on this: I thought the same trigger (package of the lookup >> class) for whether those compiler-based annotations were allowed was the same >> trigger for whether final fields were trusted. So I had some slight concern >> that replacements with the public methods in the JDK for code within j.l.lnvoke >> (bootstrap methods etc) might affect final field behavior. > For anonymous classes created using unsafe.defineAnonymousClass, final fields of all of them are considered as trusted, independent of if the host class is in java.lang or not. > This is a very important property for adapter codes (generated dynamically) in a dynamic language because it means that if the adapter is constant (bound in a method handle tree in my case) then all the field access will be replaced by constants so the whole code will be constant folded. I rely on this property heavily. > > If hidden classes have not that property, it means that hidden classes are useless for me and that people will see perf regressions if they are using lambdas stored in static final fields if lambdas starts to use hidden classes instead of anonymous classes. > FYI.?? In the current prototype, it does trusted the final fields of hidden class but we have to re-examine it from the specification perspective and also serialization. http://hg.openjdk.java.net/valhalla/valhalla/file/eee025d47c8a/src/hotspot/share/ci/ciField.cpp#l215 Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8235602 From forax at univ-mlv.fr Tue Dec 10 01:28:33 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 10 Dec 2019 02:28:33 +0100 (CET) Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <1259645747.535320.1575933585592.JavaMail.zimbra@u-pem.fr> Message-ID: <1153975711.540795.1575941313031.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "mandy chung" > ?: "Remi Forax" , "Paul Sandoz" > Cc: "valhalla-dev" > Envoy?: Mardi 10 D?cembre 2019 00:51:15 > Objet: Re: RFR: 8220607 Draft JEP: Hidden Classes > On 12/9/19 3:19 PM, Remi Forax wrote: >>> My memory is hazy on this: I thought the same trigger (package of the lookup >>> class) for whether those compiler-based annotations were allowed was the same >>> trigger for whether final fields were trusted. So I had some slight concern >>> that replacements with the public methods in the JDK for code within j.l.lnvoke >>> (bootstrap methods etc) might affect final field behavior. >> For anonymous classes created using unsafe.defineAnonymousClass, final fields of >> all of them are considered as trusted, independent of if the host class is in >> java.lang or not. >> This is a very important property for adapter codes (generated dynamically) in a >> dynamic language because it means that if the adapter is constant (bound in a >> method handle tree in my case) then all the field access will be replaced by >> constants so the whole code will be constant folded. I rely on this property >> heavily. >> >> If hidden classes have not that property, it means that hidden classes are >> useless for me and that people will see perf regressions if they are using >> lambdas stored in static final fields if lambdas starts to use hidden classes >> instead of anonymous classes. >> > > FYI.?? In the current prototype, it does trusted the final fields of > hidden class but we have to re-examine it from the specification > perspective and also serialization. yes, and so currently, i can replace all my use case of unafe.defineAnonymousClass that doesn't use the constant pool patching. > > http://hg.openjdk.java.net/valhalla/valhalla/file/eee025d47c8a/src/hotspot/share/ci/ciField.cpp#l215 I vote for not allowing setAccessible/JNI to work on final fields of hidden classes. I don't want to have to think about a framework/library that will change my adapter fields at runtime. > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8235602 R?mi From mandy.chung at oracle.com Tue Dec 10 06:29:37 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Dec 2019 22:29:37 -0800 Subject: RFR: 8220607 Draft JEP: Hidden Classes In-Reply-To: <1153975711.540795.1575941313031.JavaMail.zimbra@u-pem.fr> References: <35f98b68-0133-8783-6beb-5dcabbe4f540@oracle.com> <1259645747.535320.1575933585592.JavaMail.zimbra@u-pem.fr> <1153975711.540795.1575941313031.JavaMail.zimbra@u-pem.fr> Message-ID: On 12/9/19 5:28 PM, forax at univ-mlv.fr wrote: > On 12/9/19 3:19 PM, Remi Forax wrote: >> FYI.?? In the current prototype, it does trusted the final fields of >> hidden class but we have to re-examine it from the specification >> perspective and also serialization. > yes, and so currently, i can replace all my use case of unafe.defineAnonymousClass that doesn't use the constant pool patching. thanks for the news. >> http://hg.openjdk.java.net/valhalla/valhalla/file/eee025d47c8a/src/hotspot/share/ci/ciField.cpp#l215 > I vote for not allowing setAccessible/JNI to work on final fields of hidden classes. I don't want to have to think about a framework/library that will change my adapter fields at runtime. > > That was the restriction I initially proposed but existing framework is impacted by this.?? Such compatibility concern is not low.?? On the other hand, "sealing up" the field or method from reflection is only useful for non-hidden classes as well.?? John calls this "a locked class" a separate feature.?? I do want the "locked class" feature as well. I was pondering a little bit.? Perhaps we should make Field::set fail on a hidden class's final field ignoring the accessible flag. I have to look into this in particular custom serialization would need to continue to work. Mandy [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-September/006314.html From augustnagro at gmail.com Tue Dec 10 18:17:14 2019 From: augustnagro at gmail.com (August Nagro) Date: Tue, 10 Dec 2019 12:17:14 -0600 Subject: Inline Classes and extends Message-ID: I?m very excited about Valhalla after having read the recent ?Language Model? design document. One question I have is about `extends`. I understand that inline classes cannot extend IdentityClass, but what about other inline classes? I have a lot of classes that would make sense as inline, but are held back by their superclass (which also could be inline). - August Nagro From john.r.rose at oracle.com Tue Dec 10 18:21:15 2019 From: john.r.rose at oracle.com (John Rose) Date: Tue, 10 Dec 2019 10:21:15 -0800 Subject: Inline Classes and extends In-Reply-To: References: Message-ID: <714390DE-7FD6-43D7-AF3D-63BD56F64001@oracle.com> On Dec 10, 2019, at 10:17 AM, August Nagro wrote: > > One question I have is about `extends`. I understand that inline classes cannot extend IdentityClass, but what about other inline classes? I have a lot of classes that would make sense as inline, but are held back by their superclass (which also could be inline). One thing you get with the extra indirection of reference objects is layout polymorphism, the power to have one type which points at two or more distinct layouts. If you get rid of the pointer (which is a must for inlines, so they can ?work like an int?), then you also lose the ability to represent layout polymorphism. It?s like in C++ when you try to mix inheritance and by-value storage of instances: Stuff goes wrong, awkwardly. struct A { int x; } struct B : public A { int y; } A avar; avar.x = 1; B bvar; bvar.x = 2; bvar.y = 3; A anotheravar = bvar; // what happened to the 3?? ? John From augustnagro at gmail.com Tue Dec 10 18:31:01 2019 From: augustnagro at gmail.com (August Nagro) Date: Tue, 10 Dec 2019 12:31:01 -0600 Subject: Inline Classes and extends In-Reply-To: <714390DE-7FD6-43D7-AF3D-63BD56F64001@oracle.com> References: <714390DE-7FD6-43D7-AF3D-63BD56F64001@oracle.com> Message-ID: <22593063-3DF8-4BFE-A734-B59B38306DAA@gmail.com> Ah, I see what you mean! Appreciate the quick response. > On Dec 10, 2019, at 12:21 PM, John Rose wrote: > > On Dec 10, 2019, at 10:17 AM, August Nagro wrote: >> >> One question I have is about `extends`. I understand that inline classes cannot extend IdentityClass, but what about other inline classes? I have a lot of classes that would make sense as inline, but are held back by their superclass (which also could be inline). > > One thing you get with the extra indirection of reference objects > is layout polymorphism, the power to have one type which points > at two or more distinct layouts. > > If you get rid of the pointer (which is a must for inlines, so they > can ?work like an int?), then you also lose the ability to represent > layout polymorphism. > > It?s like in C++ when you try to mix inheritance and by-value storage > of instances: Stuff goes wrong, awkwardly. > > struct A { int x; } > struct B : public A { int y; } > A avar; avar.x = 1; > B bvar; bvar.x = 2; bvar.y = 3; > A anotheravar = bvar; // what happened to the 3?? > > ? John From scolebourne at joda.org Tue Dec 10 21:08:25 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 10 Dec 2019 21:08:25 +0000 Subject: Inline Classes and extends In-Reply-To: <714390DE-7FD6-43D7-AF3D-63BD56F64001@oracle.com> References: <714390DE-7FD6-43D7-AF3D-63BD56F64001@oracle.com> Message-ID: Is there any hope of rescuing superclass cases by converting the superclass to an interface? I'm particularly thinking of java.time.ZoneId and it's subclasses ZoneRegion and ZoneOffset. ZoneId had to be an abstract class originally as there were no sealed types, but it could be converted to a sealed interface in the future if that was a compatible change. Then the two subclasses could be inline classes (which they logically are). It also assumes we can have package scoped inline classes. I ask because the plan to convert the primitive box types to interfaces suggests ZoneId could be another candidate. Stephen On Tue, 10 Dec 2019, 18:24 John Rose, wrote: > On Dec 10, 2019, at 10:17 AM, August Nagro wrote: > > > > One question I have is about `extends`. I understand that inline classes > cannot extend IdentityClass, but what about other inline classes? I have a > lot of classes that would make sense as inline, but are held back by their > superclass (which also could be inline). > > One thing you get with the extra indirection of reference objects > is layout polymorphism, the power to have one type which points > at two or more distinct layouts. > > If you get rid of the pointer (which is a must for inlines, so they > can ?work like an int?), then you also lose the ability to represent > layout polymorphism. > > It?s like in C++ when you try to mix inheritance and by-value storage > of instances: Stuff goes wrong, awkwardly. > > struct A { int x; } > struct B : public A { int y; } > A avar; avar.x = 1; > B bvar; bvar.x = 2; bvar.y = 3; > A anotheravar = bvar; // what happened to the 3?? > > ? John From john.r.rose at oracle.com Tue Dec 10 22:14:54 2019 From: john.r.rose at oracle.com (John Rose) Date: Tue, 10 Dec 2019 14:14:54 -0800 Subject: Inline Classes and extends In-Reply-To: References: <714390DE-7FD6-43D7-AF3D-63BD56F64001@oracle.com> Message-ID: <918E0B3F-C28F-4D0A-AD5D-B3DDC636F3C4@oracle.com> On Dec 10, 2019, at 1:08 PM, Stephen Colebourne wrote: > > Is there any hope of rescuing superclass cases by converting the superclass > to an interface? > > I'm particularly thinking of java.time.ZoneId and it's subclasses > ZoneRegion and ZoneOffset. ZoneId had to be an abstract class originally as > there were no sealed types, but it could be converted to a sealed interface > in the future if that was a compatible change. Then the two subclasses > could be inline classes (which they logically are). It also assumes we can > have package scoped inline classes. > > I ask because the plan to convert the primitive box types to interfaces > suggests ZoneId could be another candidate. Yes, on a case-by-case basis, and probably in this caser. There are some moves here we could do: (a) make interfaces even more like abstract classes, or (b) accept a class C as a super of an inline, if it?s enough like an interface. (a) is a long-term trend; see default methods and then sealing, both of which are tricks that used to be the sole property of abstract classes. This trend could be characterized as making interfaces more concrete, more like abstract classes. (b) is an option to explore *if we are forced to*. The insight here is that maybe an abstract inline class is permissible if, like an interface, it is "abstract enough" to pass muster as a reference view on more than one concrete inlines. This move could be characterized as allowing (some) abstract classes to perform interface-like duties. We are holding off from these moves, not because they haven't been proposed yet, but because they do not yet seem to pay for themselves, yet. Future adventures like adapting ZoneId will help us decide whether to change our tune about (a) or (b). Note that a variation of (a) is already on the table, since Optional will need to be migrated to an interface, in which case Optional will have to behave like an abstract class relative to linkage requests (invokevirtual, CONSTANT_Methodref) which originate from old code that tries to treat Optional like an abstract class. In the long term, I don?t think it would be wrong to end up with interfaces and abstract classes looking very similar indeed. But we?ll have to get there by steps, I think, with each step clearly motivated. ? John From brian.goetz at oracle.com Tue Dec 10 22:21:59 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 10 Dec 2019 17:21:59 -0500 Subject: Inline Classes and extends In-Reply-To: References: <714390DE-7FD6-43D7-AF3D-63BD56F64001@oracle.com> Message-ID: <3e90b60e-1f58-56d7-a2f6-e2a59cebd76b@oracle.com> As the document suggests, we are considering such treatment for Integer (and Number, ugh) and Optional.? While this surely has its own set of costs (supporting interface methods in `invokevirtual`, etc), this seems to be the lesser of evils compared to allowing inline classes to extend abstract classes (on which we'd need to imposes a complicated and hard-to-statically-check set of conditions.)? As you point out, if we have this tool in our box, then (combined with sealed types) it lets API designers compatibly evolve their APIs towards a more abstract representation, which seems like a beneficial direction. There's no problem with non-public inline classes.? (The combination of public reference projection and private implementation class is expected to be a common one.) On 12/10/2019 4:08 PM, Stephen Colebourne wrote: > Is there any hope of rescuing superclass cases by converting the superclass > to an interface? > > I'm particularly thinking of java.time.ZoneId and it's subclasses > ZoneRegion and ZoneOffset. ZoneId had to be an abstract class originally as > there were no sealed types, but it could be converted to a sealed interface > in the future if that was a compatible change. Then the two subclasses > could be inline classes (which they logically are). It also assumes we can > have package scoped inline classes. > > I ask because the plan to convert the primitive box types to interfaces > suggests ZoneId could be another candidate. > > Stephen > > > On Tue, 10 Dec 2019, 18:24 John Rose, wrote: > >> On Dec 10, 2019, at 10:17 AM, August Nagro wrote: >>> One question I have is about `extends`. I understand that inline classes >> cannot extend IdentityClass, but what about other inline classes? I have a >> lot of classes that would make sense as inline, but are held back by their >> superclass (which also could be inline). >> >> One thing you get with the extra indirection of reference objects >> is layout polymorphism, the power to have one type which points >> at two or more distinct layouts. >> >> If you get rid of the pointer (which is a must for inlines, so they >> can ?work like an int?), then you also lose the ability to represent >> layout polymorphism. >> >> It?s like in C++ when you try to mix inheritance and by-value storage >> of instances: Stuff goes wrong, awkwardly. >> >> struct A { int x; } >> struct B : public A { int y; } >> A avar; avar.x = 1; >> B bvar; bvar.x = 2; bvar.y = 3; >> A anotheravar = bvar; // what happened to the 3?? >> >> ? John From tobias.hartmann at oracle.com Wed Dec 11 10:46:59 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 11 Dec 2019 11:46:59 +0100 Subject: RFR(M): 8234500: [lworld] Multiple failures with -XX:+DeoptimizeALot Message-ID: <7d920daa-a5f6-df16-575a-17fa63321f4c@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8234500 http://cr.openjdk.java.net/~thartmann/8234500/webrev.00/ This patch fixes all the places in the JITs where inline type buffering might trigger deoptimization and re-execution of the corresponding bytecode in the interpreter is necessary for correctness. There's still a problem with the calling convention and C1 that is hard to fix. The problem is that 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. I'll address this issue with a separate bug. C1: - c1_FrameMap.cpp: Account for the additional stack slot for storing the increment for stack extension when computing the frame size. - Need to re-execute flattened array load/store, defaultvalue, withfield and flattened putfield when deoptimizing on buffering. To propagate this information to the debug info, I've added a _should_reexecute field to ValueStack and IRScopeDebugInfo. We also need to keep track of the state_before. C2: - callGenerator.cpp: When late inlining a method handle call that returns an inline type, we need to allocate a buffer for the returned ValueTypeNode because the caller expects an oop return. Do this before the method handle call in case the buffer allocation triggers deoptimization and we need to (re-)execute the call in the interpreter. - graphKit.cpp: Make sure the call is (re-)executed in the interpreter, if buffering of inline type arguments triggers deoptimization. Also, make sure to re-execute a store to a non-flattened field if buffering triggers deoptimization. - library_call.cpp: The caller expects and oop when incrementally inlining an intrinsic that returns an inline type. Make sure the call is re-executed if the allocation triggers a deoptimization. Also make sure unsafe accesses that require buffering are re-executed if the allocation triggers deoptimization. - parse1.cpp: Returning an inline type might require buffering. Make sure we (re-execute) the return if allocation triggers deoptimization. Also, make sure we allocate in the callee when returning from an incrementally inlined method because the caller expects an oop. - parse2.cpp: Re-execute flattened array load/store and acmp if buffering triggers deoptimization. Also added missing decorators to store_flattened. - parse3: Re-execute field store if buffering triggers deoptimization. - parseHelper.cpp: Re-execute withfield if buffering triggers deoptimization. - frame_x86.cpp: When extending the stack in the callee method entry to make room for unpacking of inline type args, we keep a copy of the sender pc at the expected location in the callee frame. If the sender pc is patched due to deoptimization (see frame::deoptimize -> frame::patch_pc), the copy is not consistent anymore. All tests now pass with -XX:-DeoptimizeALot -XX:-TieredCompilation. Thanks, Tobias From brian.goetz at oracle.com Wed Dec 11 18:09:56 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 11 Dec 2019 13:09:56 -0500 Subject: Fwd: Re: Lifting operations from inline classes to reference projections In-Reply-To: References: Message-ID: <1b418a68-b969-aaa2-a338-956bf59bc964@oracle.com> This was received in the -comments bag. Translation will be the subject of an upcoming writeup, so stay tuned for that. You could be asking one of several different questions.? If you have an inaccessible inline class, then by default, the reference projection is also inaccessible. If you want to expose a public interface but private implementation (this is what the migrated Optional would want), then you can do that; you declare a public reference projection and a private implementation, and you put your factories _on the interface_. -------- Forwarded Message -------- Subject: Re: Lifting operations from inline classes to reference projections Date: Thu, 12 Dec 2019 02:53:30 +0900 From: Mateusz Romanowski To: valhalla-spec-comments at openjdk.java.net Hi Brian et al, Could you please show how following package-private inline class would be translated? inline class Point { public Point(int x, int z) { this.x = x; this.y = y; } public Point sum(Point that) { return new Point(this.x+that.x,this.y+that.y); } private final int x, y; } I am wondering how the client of public reference projection would get an instance of the private implementation inline class. Thanks, Mateusz Romanowski From tobias.hartmann at oracle.com Fri Dec 13 15:59:39 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 13 Dec 2019 16:59:39 +0100 Subject: Optimizing the way to Valhalla: JIT Status Update Message-ID: Hi, I thought now is a good time to give a high level status update about the inline type implementation and optimizations in the JIT. The goal is to set realistic expectations about what is currently optimized and about what could be added with reasonable engineering effort in the near future. Below, I'm only distinguishing between null-free (.inline) and nullable (.ref) inline types because that's what the JIT cares about most. After the LW1 EA binaries were released in July 2018, we were working towards LW2: - C2 support for LW2 specific features: nullable and non-scalarized inline types, array covariance, substitutability check, conversions/casting between types and calling convention changes [1]. - Various performance improvements: Object array accesses, aaload/aastore profiling, reflective invocations, synchronization, lock coarsening, unsafe/hashCode/reflection/array intrinsics and inline type array specific loop unswitching to mitigate impact on legacy code [2]. - Other new inline type specific C2 optimizations [3]. - Full C1 support for LW2 including calling convention. - Stabilization work: fixed ~130 compiler bugs for LW1 and LW2 [4]. - Thousands of lines of new test code and many extensions to our inline type specific test framework. Below are some more details about various optimizations that might be of interest. Array access (aaload, aastore): - Optimized flattened load/store if array type is known at compile time, runtime call otherwise. - Optimized runtime checks based on array storage properties. - Type information is also used to guide optimizations of following code and omit runtime checks: - After successfully storing null, the destination array can't be null-free (-> not flat). - After successfully casting an array element to a non-inline-type, the source array can't be null-free (-> not flat). - After successfully casting an array element to a non-flattenable type, the source array can't be flat. - Speculate on varargs Object array being not null-free (-> not flat). - Loop unswitching and hoisting based on flattened array check to mitigate performance impact on Object array accesses. - New profiling points for array type, element type and whether the array is flat or null-free are collected for both aaload and aastore. We then speculate based on these properties. Optimized acmp implementation: if (a == b) { return true; } else if (a != NULL && a.isValue() && b != NULL && a.type() == b.type()) { // Slow runtime call for the substitutability check return ValueBootstrapMethods.isSubstitutable(); } else { return false; } - Based on type system information, C2 is often able to remove parts or all of the above. - Implicit null checks and knowledge about nullity/flatness are used to improve remaining checks. - We currently always delegate the substitutability check to the runtime (-> slow). - Planned: profiling [5] and optimized substitutability check [6]. Scalarization in the scope of a compiled method: - C2 is aggressively scalarizing whenever null-free inline types are created, loaded or passed. For example, at defaultvalue, withfield, flattened array/field load, through inlined calls/returns (also method handles and incremental inlining), scalarized calls and returns. This means that each field of the inline type is passed individually in registers or on the stack and no heap allocation is necessary. - In addition, we attempt to prove or speculate that nullable inline types are null-free and then scalarize these as well. Please note that this is *not* done across call boundaries. Scalarized calling convention: - Null-free inline types are passed as arguments and returned in a scalarized form. That means that instead of passing/returning a pointer, each field of the inline type is passed/returned individually in registers or on the stack. - The implementation is very complex because we need to handle mismatches in the calling convention between the interpreter, C1 and C2. The following variants exist: - All null-free inline type arguments are scalarized (C2). - Inline type receiver is not scalarized (interface, method handle call). - No arguments are scalarized (interpreter and C1). We can basically have any combination of the above where there is an inconsistency between what the caller passes and what the callee expects (in many cases, the caller does not "know" what the callee expects). To solve that, we need to translate between calling conventions in the adapters / entry points by allocating and packing or unpacking. The same problem exists for returns. - Nullable inline types are *not* scalarized in the calling convention. That's mainly because the VM only supports one compiled version of each method. If we would speculatively scalarize an inline type argument, that compiled method could not handle null and we would need to deoptimize when seeing null (-> huge, unexpected performance impact). Since scalarized adapters are created at link time, we would also not be able to re-compile that method without scalarization, i.e. passing null will always be extremely slow. Related to that, Roland investigated lazy adapter creation a while ago and explained some of the additional problems here [7]. - One option to scalarize nullable inline types in the calling convention would be to pass an additional, artificial field that can be used to check if the inline type is null. Compiled code would then "null-check" before using the fields. However, this solution is far from trivial to implement and the overhead of the additional fields and the runtime checks might cancel out the improvements of scalarization. Also, the VM would need to ensure that the type is loaded when the adapters are created at method link time. The currently planned JIT work can be found here: https://bugs.openjdk.java.net/issues/?filter=36444 In my opinion, the main ongoing challenge is that we don't have a good understanding about what still needs to be done with respect to performance. For example, we don't have any numbers on the performance impact of the calling convention optimization. We also need to evaluate the inline type specific profiling that we have. Is the current version good enough? Do we need more? In general, we need to identify performance issues and prioritize them. After all, this entire project is solely about performance. Hope this helps. Please let me know if you have any questions. Best regards, Tobias [1] For example: https://bugs.openjdk.java.net/browse/JDK-8215477 https://bugs.openjdk.java.net/browse/JDK-8220716 https://bugs.openjdk.java.net/browse/JDK-8215559 https://bugs.openjdk.java.net/browse/JDK-8206139 https://bugs.openjdk.java.net/browse/JDK-8212190 https://bugs.openjdk.java.net/browse/JDK-8211772 [2] For example: https://bugs.openjdk.java.net/browse/JDK-8227634 https://bugs.openjdk.java.net/browse/JDK-8227463 https://bugs.openjdk.java.net/browse/JDK-8229288 https://bugs.openjdk.java.net/browse/JDK-8222221 [3] For example: https://bugs.openjdk.java.net/browse/JDK-8220666 https://bugs.openjdk.java.net/browse/JDK-8227180 https://bugs.openjdk.java.net/browse/JDK-8228367 [4] https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=18410 [5] https://bugs.openjdk.java.net/browse/JDK-8235914 [6] https://bugs.openjdk.java.net/browse/JDK-8228361 [7] https://mail.openjdk.java.net/pipermail/valhalla-dev/2018-April/004093.html From tobias.hartmann at oracle.com Mon Dec 16 15:07:30 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 16 Dec 2019 15:07:30 +0000 Subject: hg: valhalla/valhalla: 8230408: [lworld] TestCallingConventionC1.test109 times out Message-ID: <201912161507.xBGF7VwB012004@aojmv0008.oracle.com> Changeset: 1711231a9e7e Author: thartmann Date: 2019-12-16 16:07 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1711231a9e7e 8230408: [lworld] TestCallingConventionC1.test109 times out ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestCallingConventionC1.java ! test/hotspot/jtreg/compiler/valhalla/valuetypes/ValueTypeTest.java From brian.goetz at oracle.com Mon Dec 16 18:02:04 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 16 Dec 2019 13:02:04 -0500 Subject: Fwd: State of Valhalla: array conversions In-Reply-To: <463cebdf-35d3-f27a-81d3-16419d598829@web.de> References: <463cebdf-35d3-f27a-81d3-16419d598829@web.de> Message-ID: <47fbba44-db67-eba1-8b43-2d672ac4310b@oracle.com> Received through the -comments list. The simpler answer is: there is no conversion of form here.? The notation `X <: Y` means "X is a subtype of Y", or, more simply, "X is-a Y."? So there's no copying or loss of identity; the structure and identity are the same before and after the widening, just as with `Runnable[] <: Object[]`. -------- Forwarded Message -------- Subject: State of Valhalla: array conversions Date: Mon, 16 Dec 2019 18:08:07 +0100 From: Gernot Neppert To: valhalla-spec-comments at openjdk.java.net Hello, the document states that "For any class X (inline or identity) that implements interface I, the following subtyping relationship holds for arrays of X: X[] <: I[] <: Object[]" While this seems intuitive and consistent with the new "reference-projection", it raises the question: What kind of conversion will the assignment of an array-of-inlines to an array-of-refs be? Of course, a sensible one-way conversion is feasible. But then, the array-of-refs would not be an alias of the original array anymore. Given the following code: int[] a = {42, 43, 4711}; Integer[] r = a; r[1] = -1; I'd expect the assignment r[1] = -1 to modify the original array a, too! It's hard to imagine how that could be efficiently implemented. Regards, Gernot From ioi.lam at oracle.com Tue Dec 17 06:20:57 2019 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Tue, 17 Dec 2019 06:20:57 +0000 Subject: hg: valhalla/valhalla: 8225638: [lworld] Store inline classes in CDS archive Message-ID: <201912170620.xBH6KwRV019238@aojmv0008.oracle.com> Changeset: d02b937ae15b Author: iklam Date: 2019-12-16 22:20 -0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d02b937ae15b 8225638: [lworld] Store inline classes in CDS archive ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/memory/dynamicArchive.cpp ! src/hotspot/share/memory/metaspaceClosure.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/method.inline.hpp ! src/hotspot/share/oops/valueKlass.cpp ! src/hotspot/share/oops/valueKlass.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/hotspot/jtreg/runtime/cds/appcds/ArchiveRelocationTest.java + test/hotspot/jtreg/runtime/cds/appcds/HelloInlineClassTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicArchiveRelocationTest.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/HelloDynamicInlineClass.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/HelloInlineClassApp.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/HelloRelocation.java ! test/jtreg-ext/requires/VMProps.java From ioi.lam at oracle.com Tue Dec 17 06:26:40 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 16 Dec 2019 22:26:40 -0800 Subject: CDS Support for Valhalla Message-ID: <4702dc9b-3ff6-97df-9527-459791c0e07c@oracle.com> Folks, I've push CDS support for inline classes: ?? http://hg.openjdk.java.net/valhalla/valhalla/rev/d02b937ae15b The main changes are: ? + support for new method entries for VT calling conventions ? + special handling of ValueKlass during CDS archiving and restoring I've re-enabled CDS by default in the JVM, and also restored testing for CDS. I ran tiers1,2,3 a couple of times and don't see any new failures. Please let me know if you experience any problems that may be related to CDS :-) Thanks - Ioi From david.simms at oracle.com Tue Dec 17 11:10:38 2019 From: david.simms at oracle.com (David Simms) Date: Tue, 17 Dec 2019 12:10:38 +0100 Subject: CDS Support for Valhalla In-Reply-To: <4702dc9b-3ff6-97df-9527-459791c0e07c@oracle.com> References: <4702dc9b-3ff6-97df-9527-459791c0e07c@oracle.com> Message-ID: <928647ee-5b91-b889-c810-b7e27651acc2@oracle.com> Wohoa ! Thanks Ioi ! The number of "missing features from prototype" is steadily heading towards zero. /Mr. Simms On 17/12/19 7:26 am, Ioi Lam wrote: > Folks, > > I've push CDS support for inline classes: > > ?? http://hg.openjdk.java.net/valhalla/valhalla/rev/d02b937ae15b > > The main changes are: > ? + support for new method entries for VT calling conventions > ? + special handling of ValueKlass during CDS archiving and restoring > > I've re-enabled CDS by default in the JVM, and also restored testing > for CDS. > I ran tiers1,2,3 a couple of times and don't see any new failures. > > Please let me know if you experience any problems that may be related > to CDS :-) > > Thanks > - Ioi > From frederic.parain at oracle.com Tue Dec 17 16:37:06 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 17 Dec 2019 11:37:06 -0500 Subject: Second JNI extension for flattened arrays Message-ID: <6FC70741-5BE6-42AC-8EDC-E411AA3C74CE@oracle.com> Here?s a second JNI extension for flattened arrays. The first extension (JDK-8234761) was designed to provide fast native access to flattened arrays of pure primitives inline types. This second extension has a different goal: it aims at providing easy access to any kind of flattened array. One pain point of flattened arrays is that even if a code needs a single field from a flattened value stored in an array, it usually has to get the whole element first, and then get the field from the element. With flattened fields, this process can include several more steps to get the flattened field before being able to get one field from this flattened field. This proposal of a new JNI extension tries to avoid this burden by defining the notion of sub-element and sub-element selector. A sub-element represents either a whole element of a flattened array, or a field stored in an element of a flattened array. A sub-element can be at any level of nesting: if the array element includes flattened fields which themselves include flattened field, any field of any of these flattened fields is a sub-element. Any kind of field is a sub-element: primitive fields, reference fields, or flattened fields. The new JNI APIs provide a way to create sub-element selectors, Java objects designating a particular sub-element of a flattened array. They also provide methods to directly read or write sub-elements without having to go through all steps of nesting. Webrev: http://cr.openjdk.java.net/~fparain/jniflattenedarraysubelement/webrev.00/index.html Comments are welcome. Thank you, Fred From frederic.parain at oracle.com Tue Dec 17 17:01:01 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 17 Dec 2019 12:01:01 -0500 Subject: Second JNI extension for flattened arrays In-Reply-To: <6FC70741-5BE6-42AC-8EDC-E411AA3C74CE@oracle.com> References: <6FC70741-5BE6-42AC-8EDC-E411AA3C74CE@oracle.com> Message-ID: I?ve forgot to add the examples: Example: inline class Conainee { float f; short s; Containee(float f, short s) { this.f = f; this.s = s; } } inline class ValueWithOops { String s = "bonjour"; int i = 0; Containee c = new Containee(2.3f, (short)4); // flattened inline field BigValue b = new BigValue(); // non-flattened inline field } To create a subelement for an array of ValueWithOops: jobject selector1 = (*env)->CreateSubElementSelector(env, array); This SubElementSelector designates a whole element in the array. To create a sub-element selector for the field s of class ValueWithOops: jobject selector2 (*env)->GetSubElementSelector(env, selector1, "s", "Ljava/lang/String;"); To read field s of the element at index 4 of the array: jobject s = (*env)->GetObjectSubElement(env, array, selector2, 4); To create a sub-element selector for the field s in the flattened field c of an element of type ValueWithOops: jobject selector3 = (*env)->GetSubElementSelector(env, selector1, "c", "QContainee;"); jobject selector4 = (*env)->GetSubElementSelector(env, selector3, "s", "S"); To update the value of field s in the flattened field c in the element stored at index 8: (*env)->SetShortSubElement(env, array, selector4, 8, (short)12); To read flattened field c from the element at index 1: jobject c = (*env)->GetObjectSubElement(env, array, selector3, 1); The API takes care of extracting the flattened field before returning it as an oop. > On Dec 17, 2019, at 11:37, Frederic Parain wrote: > > Here?s a second JNI extension for flattened arrays. > > The first extension (JDK-8234761) was designed to provide fast native access > to flattened arrays of pure primitives inline types. > This second extension has a different goal: it aims at providing easy access > to any kind of flattened array. > > One pain point of flattened arrays is that even if a code needs a single > field from a flattened value stored in an array, it usually has to get > the whole element first, and then get the field from the element. With > flattened fields, this process can include several more steps to get the > flattened field before being able to get one field from this flattened field. > > This proposal of a new JNI extension tries to avoid this burden by defining > the notion of sub-element and sub-element selector. > > A sub-element represents either a whole element of a flattened array, or a > field stored in an element of a flattened array. A sub-element can be at > any level of nesting: if the array element includes flattened fields which > themselves include flattened field, any field of any of these flattened > fields is a sub-element. Any kind of field is a sub-element: primitive > fields, reference fields, or flattened fields. > > The new JNI APIs provide a way to create sub-element selectors, Java objects > designating a particular sub-element of a flattened array. They also provide > methods to directly read or write sub-elements without having to go through > all steps of nesting. > > Webrev: > http://cr.openjdk.java.net/~fparain/jniflattenedarraysubelement/webrev.00/index.html > > Comments are welcome. > > Thank you, > > Fred > From harold.seigel at oracle.com Tue Dec 17 19:31:30 2019 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 17 Dec 2019 19:31:30 +0000 Subject: hg: valhalla/valhalla: 8235690: [nestmates] InstanceKlass::signature_name returns incorrect hidden class name Message-ID: <201912171931.xBHJVUxH007323@aojmv0008.oracle.com> Changeset: b6402b9800be Author: hseigel Date: 2019-12-17 19:31 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/b6402b9800be 8235690: [nestmates] InstanceKlass::signature_name returns incorrect hidden class name Summary: Add needed name mangling for hidden classes so right name gets returned Reviewed-by: sspitsyn ! src/hotspot/share/oops/instanceKlass.cpp + test/hotspot/jtreg/serviceability/jvmti/HiddenClass/MyPackage/HiddenClassSigTest.java + test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp From maurizio.cimadamore at oracle.com Wed Dec 18 23:51:47 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 18 Dec 2019 23:51:47 +0000 Subject: Second JNI extension for flattened arrays In-Reply-To: <6FC70741-5BE6-42AC-8EDC-E411AA3C74CE@oracle.com> References: <6FC70741-5BE6-42AC-8EDC-E411AA3C74CE@oracle.com> Message-ID: <9fccca31-488a-65df-fd63-c052b60b8064@oracle.com> It's nice to see how Panama and Valhalla are trying to get at the same result from opposite directions; in Panama, the layout API allows you to define what you call a 'selector', from which you can then obtain a var handle which - given a base pointer (and and one or more indices) allows you to retrieve the desired element. What you are doing here is kind of similar, (i) by allowing clients to create 'selectors' and then (ii) to have API points which accept such selectors and perform the extraction for you. Part of me is thinking if these two approaches (the Panama way and the Valhalla/JNI way) shouldn't share more - e.g. I wonder if we could implement some of the primitives you have exposed using the Panama memory access API - so that the selector could just be an opaque object (which wraps some Panama layout + some var handle) and when you do a get/set using a selector, you basically just end up calling the var handle with the right type. Perhaps not worth thinking about now, but maybe something to keep in the back of our minds. Maurizio On 17/12/2019 16:37, Frederic Parain wrote: > This proposal of a new JNI extension tries to avoid this burden by defining > the notion of sub-element and sub-element selector. > > A sub-element represents either a whole element of a flattened array, or a > field stored in an element of a flattened array. A sub-element can be at > any level of nesting: if the array element includes flattened fields which > themselves include flattened field, any field of any of these flattened > fields is a sub-element. Any kind of field is a sub-element: primitive > fields, reference fields, or flattened fields. From rwestrel at redhat.com Thu Dec 19 08:45:36 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 19 Dec 2019 09:45:36 +0100 Subject: RFR(M): 8234500: [lworld] Multiple failures with -XX:+DeoptimizeALot In-Reply-To: <7d920daa-a5f6-df16-575a-17fa63321f4c@oracle.com> References: <7d920daa-a5f6-df16-575a-17fa63321f4c@oracle.com> Message-ID: <87k16sln4f.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8234500/webrev.00/ Looks good to me. Roland. From tobias.hartmann at oracle.com Thu Dec 19 09:34:17 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 19 Dec 2019 10:34:17 +0100 Subject: RFR(M): 8234500: [lworld] Multiple failures with -XX:+DeoptimizeALot In-Reply-To: <87k16sln4f.fsf@redhat.com> References: <7d920daa-a5f6-df16-575a-17fa63321f4c@oracle.com> <87k16sln4f.fsf@redhat.com> Message-ID: Hi Roland, thanks a lot for reviewing this large change! Best regards, Tobias On 19.12.19 09:45, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8234500/webrev.00/ > > Looks good to me. > > Roland. > From david.simms at oracle.com Thu Dec 19 12:58:55 2019 From: david.simms at oracle.com (David Simms) Date: Thu, 19 Dec 2019 13:58:55 +0100 Subject: Second JNI extension for flattened arrays In-Reply-To: <6FC70741-5BE6-42AC-8EDC-E411AA3C74CE@oracle.com> References: <6FC70741-5BE6-42AC-8EDC-E411AA3C74CE@oracle.com> Message-ID: Wow, nice work Frederic, some nice additions to the public API. Perhaps of use for core libraries wishing to make some optimizations with inline classes. Obviously Panama is on it's own track, and for now we are living in isolation from it...may revisit the need for the API, closer to the time when it becomes apparent what features will be available Code Review: clean, no comments, push it /Mr. Simms On 2019-12-17 17:37, Frederic Parain wrote: > Here?s a second JNI extension for flattened arrays. > > The first extension (JDK-8234761) was designed to provide fast native access > to flattened arrays of pure primitives inline types. > This second extension has a different goal: it aims at providing easy access > to any kind of flattened array. > > One pain point of flattened arrays is that even if a code needs a single > field from a flattened value stored in an array, it usually has to get > the whole element first, and then get the field from the element. With > flattened fields, this process can include several more steps to get the > flattened field before being able to get one field from this flattened field. > > This proposal of a new JNI extension tries to avoid this burden by defining > the notion of sub-element and sub-element selector. > > A sub-element represents either a whole element of a flattened array, or a > field stored in an element of a flattened array. A sub-element can be at > any level of nesting: if the array element includes flattened fields which > themselves include flattened field, any field of any of these flattened > fields is a sub-element. Any kind of field is a sub-element: primitive > fields, reference fields, or flattened fields. > > The new JNI APIs provide a way to create sub-element selectors, Java objects > designating a particular sub-element of a flattened array. They also provide > methods to directly read or write sub-elements without having to go through > all steps of nesting. > > Webrev: > http://cr.openjdk.java.net/~fparain/jniflattenedarraysubelement/webrev.00/index.html > > Comments are welcome. > > Thank you, > > Fred > From frederic.parain at oracle.com Thu Dec 19 15:48:24 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 19 Dec 2019 10:48:24 -0500 Subject: Second JNI extension for flattened arrays In-Reply-To: References: <6FC70741-5BE6-42AC-8EDC-E411AA3C74CE@oracle.com> Message-ID: Thank you David. Unfortunately, I had a private discussion with John yesterday, and there?s a minor change in the API: the GetSubElementSelector now takes a jfieldID in argument instead of a name/signature pair. Changes are limited to GetSubElementSelector and tests using it. New webrev: http://cr.openjdk.java.net/~fparain/jniflattenedarraysubelement/webrev.01/index.html Regards, Fred > On Dec 19, 2019, at 07:58, David Simms wrote: > > > Wow, nice work Frederic, some nice additions to the public API. Perhaps of use for core libraries wishing to make some optimizations with inline classes. > > Obviously Panama is on it's own track, and for now we are living in isolation from it...may revisit the need for the API, closer to the time when it becomes apparent what features will be available > > Code Review: clean, no comments, push it > > /Mr. Simms > > > On 2019-12-17 17:37, Frederic Parain wrote: >> Here?s a second JNI extension for flattened arrays. >> >> The first extension (JDK-8234761) was designed to provide fast native access >> to flattened arrays of pure primitives inline types. >> This second extension has a different goal: it aims at providing easy access >> to any kind of flattened array. >> >> One pain point of flattened arrays is that even if a code needs a single >> field from a flattened value stored in an array, it usually has to get >> the whole element first, and then get the field from the element. With >> flattened fields, this process can include several more steps to get the >> flattened field before being able to get one field from this flattened field. >> >> This proposal of a new JNI extension tries to avoid this burden by defining >> the notion of sub-element and sub-element selector. >> >> A sub-element represents either a whole element of a flattened array, or a >> field stored in an element of a flattened array. A sub-element can be at >> any level of nesting: if the array element includes flattened fields which >> themselves include flattened field, any field of any of these flattened >> fields is a sub-element. Any kind of field is a sub-element: primitive >> fields, reference fields, or flattened fields. >> >> The new JNI APIs provide a way to create sub-element selectors, Java objects >> designating a particular sub-element of a flattened array. They also provide >> methods to directly read or write sub-elements without having to go through >> all steps of nesting. >> >> Webrev: >> http://cr.openjdk.java.net/~fparain/jniflattenedarraysubelement/webrev.00/index.html >> >> Comments are welcome. >> >> Thank you, >> >> Fred >> From tobias.hartmann at oracle.com Fri Dec 20 08:37:15 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 20 Dec 2019 08:37:15 +0000 Subject: hg: valhalla/valhalla: 8234500: [lworld] Multiple failures with -XX:+DeoptimizeALot Message-ID: <201912200837.xBK8bFA5027935@aojmv0008.oracle.com> Changeset: c3824206b8c3 Author: thartmann Date: 2019-12-20 09:36 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c3824206b8c3 8234500: [lworld] Multiple failures with -XX:+DeoptimizeALot Reviewed-by: roland ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/share/c1/c1_FrameMap.cpp ! src/hotspot/share/c1/c1_FrameMap.hpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_IR.cpp ! src/hotspot/share/c1/c1_IR.hpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LinearScan.cpp ! src/hotspot/share/c1/c1_ValueStack.cpp ! src/hotspot/share/c1/c1_ValueStack.hpp ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/parse3.cpp ! src/hotspot/share/opto/parseHelper.cpp ! src/hotspot/share/opto/valuetypenode.cpp ! src/hotspot/share/opto/valuetypenode.hpp ! src/hotspot/share/runtime/deoptimization.cpp + test/hotspot/jtreg/compiler/valhalla/valuetypes/TestDeoptimizationWhenBuffering.java From scolebourne at joda.org Fri Dec 20 10:39:15 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 20 Dec 2019 10:39:15 +0000 Subject: Inline classes, strings and intern Message-ID: If I declare an inline class (examplar syntax): _Inline_ class StrPos (String str, int pos) {} then the strings are compared with `==` not `.equals()`. Thus: a = new StrPos("abba", 2) b = new StrPos("abbac".substring(0, 4), 2) a == b -> false a.equals(b) -> true If I were the author is such a class, I might not like that. But there is a "simple" solution - interning. If I call `String.intern()` on the string in the constructor of the inline class then a == b would now be true. Great! Except that my understanding is that interning is frowned upon these days. Obviously the same interning approach could be made to work for any type (such as using Guava's `Interners` class), but it seems particularly relevant to discuss it wrt `String.intern()` because it is built in and has special JVM global behaviour. It seems to me that because `String.intern()` exists and is easy to use, it could be widely abused to get the desired == behaviour for inline classes. Is this a real problem that needs more thought? Or not something to worry about? Stephen From scolebourne at joda.org Fri Dec 20 11:34:48 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 20 Dec 2019 11:34:48 +0000 Subject: How common are Reference-default classes? Message-ID: Recent spec-experts discussion identifies inline-default and reference-default types [1]. I think its a great point to consider, and wanted to add my own data points on reference-default. In OpenGamma code, including the OSS Strata [2], we have almost no need for object identity at all. The few uses of synchronized are on methods or on a `new Object()` instance, and are therefore easy to migrate. The 4 uses of IdentityHashMap look easily solvable in other ways. And we avoid subclassing, using interfaces for hierarchies instead. As such, it seems to me that pretty much every instantiable class could be a Reference-default inline class (certainly all the beans could be, I suspect the classes representing functionality would gain little). The potential gains seem large as the change would affect the whole system, even if only 10% of cases actually ended up being flattened by the JVM. I suspect there are plenty of other systems in the wild that would be in the same situation wrt identity. Which suggests to me that reference-default inline classes have the potential to be very common, much more common than inline-default ones (unless I'm missing something obvious...). ie. there are more use cases for identityless classes than true value types. Given the data above, I think option 4 being discussed is worthy of serious consideration. If the underlying inline type is not visible or needed in most cases (ie. the ones described above), then the syntax `Foo.inline` isn't such a problem (or perhaps the underlying pure inline type is a JVM-level thing not visible to the language). For those use cases like Point or LocalDate where the inline type is actually needed and meaningful it could then be opt-in, where I still like the syntax of `point` vs `Point`, or `localDate` vs `LocalDate`. And those use cases may be infrequent enough that option 1 is sufficient. (Overall, I suspect that I am arguing here for two distinct features from Valhalla - "light" (identityless) classes and "inline" classes. More work no doubt, but feels like it could be a better outcome and more consistent with the large body of existing Java code.) thanks Stephen [1] http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-December/001177.html [2] https://github.com/OpenGamma/Strata From brian.goetz at oracle.com Fri Dec 20 14:38:53 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 20 Dec 2019 09:38:53 -0500 Subject: Inline classes, strings and intern In-Reply-To: References: Message-ID: <2D1F1BAE-F9CB-4A29-BCD8-94FC8070ACD4@oracle.com> In a community as large as Java, any abuse you can think of, will surely be done by someone. My from-the-hip opinion on this is not going to be make the existing interning abuses much worse. Most of the interning abuses came from the early days, before people really got the memo that `==` was a low-level primitive and generally shouldn?t be used for much. (Fortunately, I see much less use of it these days than in the older days.) When I see someone using interning, it?s a red flag, not because it?s intrinsically bad, but because it is almost always misused, generally out of incorrect priorities (e.g., unwarranted performance obsession, syntactic obsession, etc.) Many of the earlier benefits of interning (memory compaction) now come for free with string deduplication during GC. > On Dec 20, 2019, at 5:39 AM, Stephen Colebourne wrote: > > If I declare an inline class (examplar syntax): > > _Inline_ class StrPos (String str, int pos) {} > > then the strings are compared with `==` not `.equals()`. Thus: > > a = new StrPos("abba", 2) > b = new StrPos("abbac".substring(0, 4), 2) > a == b -> false > a.equals(b) -> true > > If I were the author is such a class, I might not like that. But there > is a "simple" solution - interning. If I call `String.intern()` on the > string in the constructor of the inline class then a == b would now be > true. > > Great! Except that my understanding is that interning is frowned upon > these days. Obviously the same interning approach could be made to > work for any type (such as using Guava's `Interners` class), but it > seems particularly relevant to discuss it wrt `String.intern()` > because it is built in and has special JVM global behaviour. > > It seems to me that because `String.intern()` exists and is easy to > use, it could be widely abused to get the desired == behaviour for > inline classes. Is this a real problem that needs more thought? Or not > something to worry about? > > Stephen From brian.goetz at oracle.com Fri Dec 20 16:13:20 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 20 Dec 2019 11:13:20 -0500 Subject: How common are Reference-default classes? In-Reply-To: References: Message-ID: <78cd4536-8270-9786-6252-00a50ef9a090@oracle.com> Summary: "Flattening is very cool, but if there were a middle ground where I could get some non-flattening benefits by giving up identity, I'd be a customer for that, since I don't use identity much anyway." Which is a good reminder; of course, this depends on what benefits you could get in the inline-but-not-flat cases. (On the other hand, the OpenGamma codebase is what I would call a fairly "disciplined" and "actively curated" codebase; you started out with a set of API design principles and stuck to them fairly consistently, and when you make changes in style, do so uniformly. Which is very good, of course, but not necessarily all that common, so I'll just log the warning that this might not be ideal the codebase to extrapolate from.) > In OpenGamma code, including the OSS Strata [2], we have almost no > need for object identity at all. The few uses of synchronized are on > methods or on a `new Object()` instance, and are therefore easy to > migrate. The 4 uses of IdentityHashMap look easily solvable in other > ways. And we avoid subclassing, using interfaces for hierarchies > instead. As such, it seems to me that pretty much every instantiable > class could be a Reference-default inline class (certainly all the > beans could be, I suspect the classes representing functionality would > gain little). The potential gains seem large as the change would > affect the whole system, even if only 10% of cases actually ended up > being flattened by the JVM. > > I suspect there are plenty of other systems in the wild that would be > in the same situation wrt identity. Which suggests to me that > reference-default inline classes have the potential to be very common, > much more common than inline-default ones (unless I'm missing > something obvious...). ie. there are more use cases for identityless > classes than true value types. > > Given the data above, I think option 4 being discussed is worthy of > serious consideration. If the underlying inline type is not visible or > needed in most cases (ie. the ones described above), then the syntax > `Foo.inline` isn't such a problem (or perhaps the underlying pure > inline type is a JVM-level thing not visible to the language). For > those use cases like Point or LocalDate where the inline type is > actually needed and meaningful it could then be opt-in, where I still > like the syntax of `point` vs `Point`, or `localDate` vs `LocalDate`. > And those use cases may be infrequent enough that option 1 is > sufficient. (Overall, I suspect that I am arguing here for two > distinct features from Valhalla - "light" (identityless) classes and > "inline" classes. More work no doubt, but feels like it could be a > better outcome and more consistent with the large body of existing > Java code.) > > thanks > Stephen > > [1] http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-December/001177.html > [2] https://github.com/OpenGamma/Strata From romanowski.mateusz at gmail.com Fri Dec 20 18:45:18 2019 From: romanowski.mateusz at gmail.com (Mateusz Romanowski) Date: Fri, 20 Dec 2019 18:45:18 +0000 Subject: Migration of Integer to inline Message-ID: Hi All, I have been re-reading *state of valhalla* and following the discussions regarding *inline-friendly* abstract classes. If non-Object abstract class as superclass of inline class is allowed, the migration story for Optional seems easy. It would be the same for Integer, if only there were no pesky public Integer::new... Could you share any preliminary thoughts how the classfiles (found in *dusty* jars) that use the Integer constructor would be treated? Is it feasible to have the bytecode weaved to replace the new-dup-init sequence during class loading? Thanks, Mateusz From brian.goetz at oracle.com Fri Dec 20 19:13:10 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 20 Dec 2019 14:13:10 -0500 Subject: Migration of Integer to inline In-Reply-To: References: Message-ID: <60b15981-d115-6634-d52c-b746640bb2a2@oracle.com> > If non-Object abstract class as superclass of inline class is allowed, the > migration story for Optional seems easy. > It would be the same for Integer, if only there were no pesky public > Integer::new... These constructors have been deprecated since Java 9; and there has been IDE support for migrating invocations of these to the appropriate factory methods for at least a dozen years.? It is reasonable to deprecate them for removal. As with `new Object()`, it is also possible to take heroic measures to relink `new Ljava/lang/Integer;` bytecodes to instantiate some other type, though we're not ready to plunk for that yet (it's more complicated than for Object.) Bytecode weaving (perhaps even at load time, with an agent) is indeed a possible means of rewriting these dusty jars. > > Could you share any preliminary thoughts how the classfiles (found in > *dusty* jars) that use the Integer constructor would be treated? > > Is it feasible to have the bytecode weaved to replace the new-dup-init > sequence during class loading? > > Thanks, > Mateusz From romanowski.mateusz at gmail.com Fri Dec 20 23:11:07 2019 From: romanowski.mateusz at gmail.com (Mateusz Romanowski) Date: Fri, 20 Dec 2019 23:11:07 +0000 Subject: Migration of Integer to inline In-Reply-To: <60b15981-d115-6634-d52c-b746640bb2a2@oracle.com> References: <60b15981-d115-6634-d52c-b746640bb2a2@oracle.com> Message-ID: Thanks for quick response. As for Integer::new, some people (including me once) might still use the constructor to bypass the IntegerCache. The migration story could then include some Integer::valueOfUncached factory for such usages. I would love to see such method introduced with the constructor being made synthetic (JDK-8236444). Cheers. W dniu pi?tek, 20 grudnia 2019 Brian Goetz napisa?(a): > > >> If non-Object abstract class as superclass of inline class is allowed, the >> migration story for Optional seems easy. >> It would be the same for Integer, if only there were no pesky public >> Integer::new... > > These constructors have been deprecated since Java 9; and there has been IDE support for migrating invocations of these to the appropriate factory methods for at least a dozen years. It is reasonable to deprecate them for removal. > > As with `new Object()`, it is also possible to take heroic measures to relink `new Ljava/lang/Integer;` bytecodes to instantiate some other type, though we're not ready to plunk for that yet (it's more complicated than for Object.) > > Bytecode weaving (perhaps even at load time, with an agent) is indeed a possible means of rewriting these dusty jars. > >> >> Could you share any preliminary thoughts how the classfiles (found in >> *dusty* jars) that use the Integer constructor would be treated? >> >> Is it feasible to have the bytecode weaved to replace the new-dup-init >> sequence during class loading? >> >> Thanks, >> Mateusz > > From brian.goetz at oracle.com Fri Dec 20 23:38:25 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 20 Dec 2019 18:38:25 -0500 Subject: Migration of Integer to inline In-Reply-To: References: <60b15981-d115-6634-d52c-b746640bb2a2@oracle.com> Message-ID: <5cc10930-7713-6d12-922f-588350826c32@oracle.com> If we can successfully migrate Integer to be a value type, the cache goes away, since the instances no longer have identity. On 12/20/2019 6:11 PM, Mateusz Romanowski wrote: > Thanks for quick response. > > As for Integer::new, some people (including me once) might still use > the constructor to bypass the IntegerCache. > > The migration story could then include some Integer::valueOfUncached > factory for such usages. > > I would love to see such method introduced with the constructor being > made synthetic (JDK-8236444). > > Cheers. > > > W dniu pi?tek, 20 grudnia 2019 Brian Goetz > napisa?(a): > > > > > >> If non-Object abstract class as superclass of inline class is > allowed, the > >> migration story for Optional seems easy. > >> It would be the same for Integer, if only there were no pesky public > >> Integer::new... > > > > These constructors have been deprecated since Java 9; and there has > been IDE support for migrating invocations of these to the appropriate > factory methods for at least a dozen years.? It is reasonable to > deprecate them for removal. > > > > As with `new Object()`, it is also possible to take heroic measures > to relink `new Ljava/lang/Integer;` bytecodes to instantiate some > other type, though we're not ready to plunk for that yet (it's more > complicated than for Object.) > > > > Bytecode weaving (perhaps even at load time, with an agent) is > indeed a possible means of rewriting these dusty jars. > > > >> > >> Could you share any preliminary thoughts how the classfiles (found in > >> *dusty* jars) that use the Integer constructor would be treated? > >> > >> Is it feasible to have the bytecode weaved to replace the new-dup-init > >> sequence during class loading? > >> > >> Thanks, > >> Mateusz > > > > From romanowski.mateusz at gmail.com Sat Dec 21 00:17:31 2019 From: romanowski.mateusz at gmail.com (Mateusz Romanowski) Date: Sat, 21 Dec 2019 00:17:31 +0000 Subject: Migration of Integer to inline In-Reply-To: <5cc10930-7713-6d12-922f-588350826c32@oracle.com> References: <60b15981-d115-6634-d52c-b746640bb2a2@oracle.com> <5cc10930-7713-6d12-922f-588350826c32@oracle.com> Message-ID: True. Sorry for being unclear, but I wanted to point out that not only *dusty* but *current* classfiles as well might contain Integer::new invocations. I found once that replacing Integer::valueOf (1) reference with deprecated Integer::new (2) made quite a difference as current JIT elided boxing (through scalarization) only for (2). I was quite surprised at that time how going through cache kills performance.. W dniu sobota, 21 grudnia 2019 Brian Goetz napisa?(a): > If we can successfully migrate Integer to be a value type, the cache goes away, since the instances no longer have identity. > > On 12/20/2019 6:11 PM, Mateusz Romanowski wrote: > > Thanks for quick response. > > As for Integer::new, some people (including me once) might still use the constructor to bypass the IntegerCache. > > The migration story could then include some Integer::valueOfUncached factory for such usages. > > I would love to see such method introduced with the constructor being made synthetic (JDK-8236444). > > Cheers. > > > W dniu pi?tek, 20 grudnia 2019 Brian Goetz napisa?(a): >> >> >>> If non-Object abstract class as superclass of inline class is allowed, the >>> migration story for Optional seems easy. >>> It would be the same for Integer, if only there were no pesky public >>> Integer::new... >> >> These constructors have been deprecated since Java 9; and there has been IDE support for migrating invocations of these to the appropriate factory methods for at least a dozen years. It is reasonable to deprecate them for removal. >> >> As with `new Object()`, it is also possible to take heroic measures to relink `new Ljava/lang/Integer;` bytecodes to instantiate some other type, though we're not ready to plunk for that yet (it's more complicated than for Object.) >> >> Bytecode weaving (perhaps even at load time, with an agent) is indeed a possible means of rewriting these dusty jars. >> >>> >>> Could you share any preliminary thoughts how the classfiles (found in >>> *dusty* jars) that use the Integer constructor would be treated? >>> >>> Is it feasible to have the bytecode weaved to replace the new-dup-init >>> sequence during class loading? >>> >>> Thanks, >>> Mateusz >> >> > From kirk.pepperdine at gmail.com Sat Dec 21 16:55:09 2019 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Sat, 21 Dec 2019 17:55:09 +0100 Subject: Migration of Integer to inline In-Reply-To: <5cc10930-7713-6d12-922f-588350826c32@oracle.com> References: <60b15981-d115-6634-d52c-b746640bb2a2@oracle.com> <5cc10930-7713-6d12-922f-588350826c32@oracle.com> Message-ID: <4A58CD76-4C8C-4262-A517-E0B8DE728F01@gmail.com> > On Dec 21, 2019, at 12:38 AM, Brian Goetz wrote: > > If we can successfully migrate Integer to be a value type, the cache goes away, since the instances no longer have identity. +1, can Santa deliver this for Christmas? Kind regards, Kirk > > On 12/20/2019 6:11 PM, Mateusz Romanowski wrote: >> Thanks for quick response. >> >> As for Integer::new, some people (including me once) might still use the constructor to bypass the IntegerCache. >> >> The migration story could then include some Integer::valueOfUncached factory for such usages. >> >> I would love to see such method introduced with the constructor being made synthetic (JDK-8236444). >> >> Cheers. >> >> >> W dniu pi?tek, 20 grudnia 2019 Brian Goetz > napisa?(a): >> > >> > >> >> If non-Object abstract class as superclass of inline class is allowed, the >> >> migration story for Optional seems easy. >> >> It would be the same for Integer, if only there were no pesky public >> >> Integer::new... >> > >> > These constructors have been deprecated since Java 9; and there has been IDE support for migrating invocations of these to the appropriate factory methods for at least a dozen years. It is reasonable to deprecate them for removal. >> > >> > As with `new Object()`, it is also possible to take heroic measures to relink `new Ljava/lang/Integer;` bytecodes to instantiate some other type, though we're not ready to plunk for that yet (it's more complicated than for Object.) >> > >> > Bytecode weaving (perhaps even at load time, with an agent) is indeed a possible means of rewriting these dusty jars. >> > >> >> >> >> Could you share any preliminary thoughts how the classfiles (found in >> >> *dusty* jars) that use the Integer constructor would be treated? >> >> >> >> Is it feasible to have the bytecode weaved to replace the new-dup-init >> >> sequence during class loading? >> >> >> >> Thanks, >> >> Mateusz >> > >> > > From forax at univ-mlv.fr Sat Dec 21 17:18:23 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 21 Dec 2019 18:18:23 +0100 (CET) Subject: Migration of Integer to inline In-Reply-To: References: <60b15981-d115-6634-d52c-b746640bb2a2@oracle.com> <5cc10930-7713-6d12-922f-588350826c32@oracle.com> Message-ID: <1097852913.1070091.1576948703903.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mateusz Romanowski" > ?: "Brian Goetz" > Cc: "valhalla-dev" > Envoy?: Samedi 21 D?cembre 2019 01:17:31 > Objet: Migration of Integer to inline > True. > Sorry for being unclear, but I wanted to point out that not only *dusty* > but *current* classfiles as well might contain Integer::new invocations. > > I found once that replacing Integer::valueOf (1) reference with deprecated > Integer::new (2) made quite a difference as current JIT elided boxing > (through scalarization) only for (2). > I was quite surprised at that time how going through cache kills > performance.. This was fixed recently see https://bugs.openjdk.java.net/browse/JDK-8075052 Anyway i agree with you, most of the existing code is still using new Integer() because this constructor was only deprecated in 9 and not a lot applications have not yet migrated to 11, so most people are unaware that those constructors have been deprecated. We should have a way to backport @Deprecated (seen as future deprecation). R?mi > > W dniu sobota, 21 grudnia 2019 Brian Goetz > napisa?(a): >> If we can successfully migrate Integer to be a value type, the cache goes > away, since the instances no longer have identity. >> >> On 12/20/2019 6:11 PM, Mateusz Romanowski wrote: >> >> Thanks for quick response. >> >> As for Integer::new, some people (including me once) might still use the > constructor to bypass the IntegerCache. >> >> The migration story could then include some Integer::valueOfUncached > factory for such usages. >> >> I would love to see such method introduced with the constructor being > made synthetic (JDK-8236444). >> >> Cheers. >> >> >> W dniu pi?tek, 20 grudnia 2019 Brian Goetz > napisa?(a): >>> >>> >>>> If non-Object abstract class as superclass of inline class is allowed, > the >>>> migration story for Optional seems easy. >>>> It would be the same for Integer, if only there were no pesky public >>>> Integer::new... >>> >>> These constructors have been deprecated since Java 9; and there has been > IDE support for migrating invocations of these to the appropriate factory > methods for at least a dozen years. It is reasonable to deprecate them for > removal. >>> >>> As with `new Object()`, it is also possible to take heroic measures to > relink `new Ljava/lang/Integer;` bytecodes to instantiate some other type, > though we're not ready to plunk for that yet (it's more complicated than > for Object.) >>> >>> Bytecode weaving (perhaps even at load time, with an agent) is indeed a > possible means of rewriting these dusty jars. >>> >>>> >>>> Could you share any preliminary thoughts how the classfiles (found in >>>> *dusty* jars) that use the Integer constructor would be treated? >>>> >>>> Is it feasible to have the bytecode weaved to replace the new-dup-init >>>> sequence during class loading? >>>> >>>> Thanks, >>>> Mateusz >>> >>> From forax at univ-mlv.fr Sat Dec 21 18:35:33 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 21 Dec 2019 19:35:33 +0100 (CET) Subject: record and inline Message-ID: <163037851.1073851.1576953333336.JavaMail.zimbra@u-pem.fr> Hi guys, i wanted to test several combinations of record and inline but the current sources are not based on latest jdk sources so records are not included. R?mi From john.r.rose at oracle.com Tue Dec 24 08:05:56 2019 From: john.r.rose at oracle.com (John Rose) Date: Tue, 24 Dec 2019 00:05:56 -0800 Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity Message-ID: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com> Define a new modifier which enforces atomicity of all instances (in the heap) of the given inline class. Working title "__AlwaysAtomic". Suggested final "alwaysatomic" or just "atomic". Represented in classfile using currently free modifier bit 0x0040 = ACC_VOLATILE. https://bugs.openjdk.java.net/browse/JDK-8236522 http://cr.openjdk.java.net/~jrose/jvm/atomic-8236522 From john.r.rose at oracle.com Tue Dec 24 21:36:34 2019 From: john.r.rose at oracle.com (John Rose) Date: Tue, 24 Dec 2019 13:36:34 -0800 Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity In-Reply-To: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com> References: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com> Message-ID: The webrev is updated in place, with an improved unit test for detecting tearing and its absence. This uncovered a missing StoreStore barrier in C2, which I also fixed. BTW, the funny pattern match logic for class names is not just for this change set. We will want the same pattern match for other at hoc diagnostics, such as flagging surprising synchronization. ? John On Dec 24, 2019, at 12:05 AM, John Rose wrote: > > Define a new modifier which enforces atomicity of all instances (in the heap) of the given inline class. > > Working title "__AlwaysAtomic". Suggested final "alwaysatomic" or just "atomic". > > Represented in classfile using currently free modifier bit 0x0040 = ACC_VOLATILE. > > https://bugs.openjdk.java.net/browse/JDK-8236522 > http://cr.openjdk.java.net/~jrose/jvm/atomic-8236522 >