From dms at samersoff.net Sun Sep 1 16:06:09 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 1 Sep 2019 19:06:09 +0300 Subject: Likely a bug in G1BarrierSetAssembler::oop_store_at Message-ID: <0b228b16-4e73-88db-379b-bf766bb5fd42@samersoff.net> Hello Everybody, I found a following code in x86 G1BarrierSetAssembler::oop_store_at It looks like we pass the same register as both new_val and tmp2 to g1_write_barrier_post. I don't have x86 setup in hands so can't say how critical it is. // G1 barrier needs uncompressed oop for region cross check. if (UseCompressedOops) { new_val = tmp2; __ movptr(new_val, val); } } BarrierSetAssembler::store_at(masm, decorators, type, Address(tmp1, 0), val, noreg, noreg); if (needs_post_barrier) { g1_write_barrier_post(masm /*masm*/, tmp1 /* store_adr */, new_val /* new_val */, rthread /* thread */, tmp3 /* tmp */, tmp2 /* tmp2 */); } -Dmitry From dms at samersoff.net Mon Sep 2 11:16:10 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 2 Sep 2019 14:16:10 +0300 Subject: RFR(L): AARCH64 support for lworld v.06 In-Reply-To: References: Message-ID: <182a12bf-4d53-e992-c808-4ef5c8e24c03@samersoff.net> Hello Everybody, Please review v.06 of adding AArch64 support to lworld branch http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.06/ What was done: 1. Adopted changes in shared code and fixed compilation errors 2. Removed all DMS CHECK kludges (but some of them become FIXME) 3. All the code needed to support value pack/unpack logic is in place. Problems left: There are couple of bugs mostly related to register usage while we pack/unpack values. Therefore, ValueTypePassFieldsAsArgs/ValueTypePassFieldsAsArgs is still hardly disabled for aarch64 Testing (the same as for v.05): All tests in runtime/valhalla/valuetypes and in compiler/valhalla/valuetypes/ are passed compiler/valhalla/valuetypes/TestMethodHandles.java compiler/valhalla/valuetypes/TestBasicFunctionality.java are passed after manually tweaking of output patterns, I have not found a way to support both x86 and aarch64, so these tests remain unchanged and run on x64 only. -Dmitry From ioi.lam at oracle.com Mon Sep 2 23:41:21 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 2 Sep 2019 16:41:21 -0700 Subject: Likely a bug in G1BarrierSetAssembler::oop_store_at In-Reply-To: <0b228b16-4e73-88db-379b-bf766bb5fd42@samersoff.net> References: <0b228b16-4e73-88db-379b-bf766bb5fd42@samersoff.net> Message-ID: <296450f0-0f3d-e180-e12f-e63b738ac180@oracle.com> CC-ing hotspot-gc-dev at openjdk.java.net. Hi Dmitry, The code you mentioned also exists in the mainline repo: http://hg.openjdk.java.net/jdk/jdk/file/7cf02b2c1455/src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp#l392 I think the code is OK, but maybe some from GC team can take a look at it, too. The movptr is necessary because BarrierSetAssembler::store_at may modify the contents of val, so we save its value into a temp register, tmp2. ??? if (needs_post_barrier) { ????? // G1 barrier needs uncompressed oop for region cross check. ????? if (UseCompressedOops) { ??????? new_val = tmp2; ??????? __ movptr(new_val, val); ????? } ??? } ??? BarrierSetAssembler::store_at(masm, decorators, type, Address(tmp1, 0), val, noreg, noreg, noreg); Later, inside g1_write_barrier_post, tmp2 is written only here, but we never read new_value after writing into tmp2, so we should be safe. ? __ jcc(Assembler::equal, runtime); ? __ subl(queue_index, wordSize); ? __ movptr(tmp2, buffer); #ifdef _LP64 ? __ movslq(rscratch1, queue_index); ? __ addq(tmp2, rscratch1); ? __ movq(Address(tmp2, 0), card_addr); #else ? __ addl(tmp2, queue_index); ? __ movl(Address(tmp2, 0), card_addr); #endif ? __ jmp(done); ? __ bind(runtime); ? // save the live input values ? __ push(store_addr); ? __ push(new_val); #ifdef _LP64 ? __ call_VM_leaf(CAST_FROM_FN_PTR(address, G1BarrierSetRuntime::write_ref_field_post_entry), card_addr, r15_thread); #else ? __ push(thread); ? __ call_VM_leaf(CAST_FROM_FN_PTR(address, G1BarrierSetRuntime::write_ref_field_post_entry), card_addr, thread); ? __ pop(thread); #endif ? __ pop(new_val); ? __ pop(store_addr); ? __ bind(done); My question is --- why are we saving new_value when making the runtime call? new_val can only be val or tmp2, but it's OK to scratch both registers in G1BarrierSetAssembler::oop_store_at(), and neither registers are used after the runtime call. I commented out the push/pop of new_val and ran all tests under test/hotspot/jtreg/gc without problem. Thanks - Ioi On 9/1/19 9:06 AM, Dmitry Samersoff wrote: > Hello Everybody, > > I found a following code in x86 G1BarrierSetAssembler::oop_store_at > > It looks like we pass the same register as both new_val and tmp2 to > g1_write_barrier_post. > > I don't have x86 setup in hands so can't say how critical it is. > > > // G1 barrier needs uncompressed oop for region cross check. > if (UseCompressedOops) { > new_val = tmp2; > __ movptr(new_val, val); > } > } > > BarrierSetAssembler::store_at(masm, decorators, type, Address(tmp1, > 0), val, noreg, noreg); > > if (needs_post_barrier) { > g1_write_barrier_post(masm /*masm*/, > tmp1 /* store_adr */, > new_val /* new_val */, > rthread /* thread */, > tmp3 /* tmp */, > tmp2 /* tmp2 */); > } > > -Dmitry > From frederic.parain at oracle.com Tue Sep 3 14:24:08 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 3 Sep 2019 10:24:08 -0400 Subject: RFR: 8230482: Initial support for empty inline classes Message-ID: <2A11CD31-AB86-4493-B639-95C4609DDD87@oracle.com> Greetings, Please review this code that adds initial support for empty inline classes. CR: https://bugs.openjdk.java.net/browse/JDK-8230482 Webrev: http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.00/index.html Thank you, Fred From thomas.schatzl at oracle.com Tue Sep 3 13:40:43 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 03 Sep 2019 15:40:43 +0200 Subject: Likely a bug in G1BarrierSetAssembler::oop_store_at In-Reply-To: <296450f0-0f3d-e180-e12f-e63b738ac180@oracle.com> References: <0b228b16-4e73-88db-379b-bf766bb5fd42@samersoff.net> <296450f0-0f3d-e180-e12f-e63b738ac180@oracle.com> Message-ID: <91552df43e882d84774261774f7d2f995fe661fd.camel@oracle.com> Hi, On Mon, 2019-09-02 at 16:41 -0700, Ioi Lam wrote: > CC-ing hotspot-gc-dev at openjdk.java.net. > > > Hi Dmitry, > > The code you mentioned also exists in the mainline repo: > > http://hg.openjdk.java.net/jdk/jdk/file/7cf02b2c1455/src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp#l392 > > I think the code is OK, but maybe some from GC team can take a look > at it, too. The code is okay. The only problem is that > > The movptr is necessary because BarrierSetAssembler::store_at may > modify the contents of val, so we save its value into a temp To be a little more exact, BarrierSetAssembler::store_at modifies the value in val if it is a reference, i.e. it compresses it with compressed oops enabled. For the inter-region filter we need the uncompressed value though, saving it in new_val/tmp2. > register, tmp2. > > if (needs_post_barrier) { > // G1 barrier needs uncompressed oop for region cross check. > if (UseCompressedOops) { > new_val = tmp2; > __ movptr(new_val, val); > } > } > BarrierSetAssembler::store_at(masm, decorators, type, > Address(tmp1, 0), val, noreg, noreg, noreg); > > > Later, inside g1_write_barrier_post, tmp2 is written only here, but > we never read new_value after writing into tmp2, so we should be > safe. > > __ jcc(Assembler::equal, runtime); > __ subl(queue_index, wordSize); > __ movptr(tmp2, buffer); > #ifdef _LP64 > __ movslq(rscratch1, queue_index); > __ addq(tmp2, rscratch1); > __ movq(Address(tmp2, 0), card_addr); > #else > __ addl(tmp2, queue_index); > __ movl(Address(tmp2, 0), card_addr); > #endif > __ jmp(done); > > __ bind(runtime); > // save the live input values > __ push(store_addr); > __ push(new_val); > #ifdef _LP64 > __ call_VM_leaf(CAST_FROM_FN_PTR(address, > G1BarrierSetRuntime::write_ref_field_post_entry), card_addr, > r15_thread); > #else > __ push(thread); > __ call_VM_leaf(CAST_FROM_FN_PTR(address, > G1BarrierSetRuntime::write_ref_field_post_entry), card_addr, thread); > __ pop(thread); > #endif > __ pop(new_val); > __ pop(store_addr); > > __ bind(done); > > > My question is --- why are we saving new_value when making the > runtime call? new_val can only be val or tmp2, but it's OK to scratch > both registers in G1BarrierSetAssembler::oop_store_at(), and neither > registers are used after the runtime call. I can imagine that sometime/somewhere there has been an implicit contract that "val" should not be modified. Apparently G1 never did that anyway... I will file a CR to look at this some more. > > I commented out the push/pop of new_val and ran all tests under > test/hotspot/jtreg/gc without problem. Thanks, Thomas From martin.doerr at sap.com Tue Sep 3 13:50:16 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 3 Sep 2019 13:50:16 +0000 Subject: Likely a bug in G1BarrierSetAssembler::oop_store_at In-Reply-To: <296450f0-0f3d-e180-e12f-e63b738ac180@oracle.com> References: <0b228b16-4e73-88db-379b-bf766bb5fd42@samersoff.net> <296450f0-0f3d-e180-e12f-e63b738ac180@oracle.com> Message-ID: Hi, I agree with Ioi, tmp2 only gets modified after new_val was read for the last time. So I can't see any bug here. > My question is --- why are we saving new_value when making the runtime > call? new_val can only be val or tmp2, but it's OK to scratch both > registers in G1BarrierSetAssembler::oop_store_at(), and neither > registers are used after the runtime call. I think we could skip saving and restoring it if we use CompressedOops (because it's just a temp register). If running with -XX:-UseCompressedOops, I think we should preserve the register "val". Users of store_at may not expect val to get killed. Best regards, Martin > -----Original Message----- > From: hotspot-gc-dev On > Behalf Of Ioi Lam > Sent: Dienstag, 3. September 2019 01:41 > To: valhalla-dev at openjdk.java.net; hotspot-gc-dev dev at openjdk.java.net> > Subject: Re: Likely a bug in G1BarrierSetAssembler::oop_store_at > > CC-ing hotspot-gc-dev at openjdk.java.net. > > > Hi Dmitry, > > The code you mentioned also exists in the mainline repo: > > http://hg.openjdk.java.net/jdk/jdk/file/7cf02b2c1455/src/hotspot/cpu/x86/ > gc/g1/g1BarrierSetAssembler_x86.cpp#l392 > > I think the code is OK, but maybe some from GC team can take a look at > it, too. > > The movptr is necessary because BarrierSetAssembler::store_at may modify > the contents of val, so we save its value into a temp register, tmp2. > > ??? if (needs_post_barrier) { > ????? // G1 barrier needs uncompressed oop for region cross check. > ????? if (UseCompressedOops) { > ??????? new_val = tmp2; > ??????? __ movptr(new_val, val); > ????? } > ??? } > ??? BarrierSetAssembler::store_at(masm, decorators, type, Address(tmp1, > 0), val, noreg, noreg, noreg); > > > Later, inside g1_write_barrier_post, tmp2 is written only here, but we > never read new_value after writing into tmp2, so we should be safe. > > ? __ jcc(Assembler::equal, runtime); > ? __ subl(queue_index, wordSize); > ? __ movptr(tmp2, buffer); > #ifdef _LP64 > ? __ movslq(rscratch1, queue_index); > ? __ addq(tmp2, rscratch1); > ? __ movq(Address(tmp2, 0), card_addr); > #else > ? __ addl(tmp2, queue_index); > ? __ movl(Address(tmp2, 0), card_addr); > #endif > ? __ jmp(done); > > ? __ bind(runtime); > ? // save the live input values > ? __ push(store_addr); > ? __ push(new_val); > #ifdef _LP64 > ? __ call_VM_leaf(CAST_FROM_FN_PTR(address, > G1BarrierSetRuntime::write_ref_field_post_entry), card_addr, r15_thread); > #else > ? __ push(thread); > ? __ call_VM_leaf(CAST_FROM_FN_PTR(address, > G1BarrierSetRuntime::write_ref_field_post_entry), card_addr, thread); > ? __ pop(thread); > #endif > ? __ pop(new_val); > ? __ pop(store_addr); > > ? __ bind(done); > > > My question is --- why are we saving new_value when making the runtime > call? new_val can only be val or tmp2, but it's OK to scratch both > registers in G1BarrierSetAssembler::oop_store_at(), and neither > registers are used after the runtime call. > > I commented out the push/pop of new_val and ran all tests under > test/hotspot/jtreg/gc without problem. > > > Thanks > - Ioi > > On 9/1/19 9:06 AM, Dmitry Samersoff wrote: > > Hello Everybody, > > > > I found a following code in x86 G1BarrierSetAssembler::oop_store_at > > > > It looks like we pass the same register as both new_val and tmp2 to > > g1_write_barrier_post. > > > > I don't have x86 setup in hands so can't say how critical it is. > > > > > > // G1 barrier needs uncompressed oop for region cross check. > > if (UseCompressedOops) { > > new_val = tmp2; > > __ movptr(new_val, val); > > } > > } > > > > BarrierSetAssembler::store_at(masm, decorators, type, Address(tmp1, > > 0), val, noreg, noreg); > > > > if (needs_post_barrier) { > > g1_write_barrier_post(masm /*masm*/, > > tmp1 /* store_adr */, > > new_val /* new_val */, > > rthread /* thread */, > > tmp3 /* tmp */, > > tmp2 /* tmp2 */); > > } > > > > -Dmitry > > From forax at univ-mlv.fr Tue Sep 3 15:29:41 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 3 Sep 2019 17:29:41 +0200 (CEST) Subject: RFR: 8230482: Initial support for empty inline classes In-Reply-To: <2A11CD31-AB86-4493-B639-95C4609DDD87@oracle.com> References: <2A11CD31-AB86-4493-B639-95C4609DDD87@oracle.com> Message-ID: <768856499.1023055.1567524581092.JavaMail.zimbra@u-pem.fr> Hi Frederic, i think you can add a test where an empty inline object is used as field in the middle of several fields (perhaps using inheritance to be sure of the layout ?). R?mi ----- Mail original ----- > De: "Frederic Parain" > ?: "valhalla-dev" > Envoy?: Mardi 3 Septembre 2019 16:24:08 > Objet: RFR: 8230482: Initial support for empty inline classes > Greetings, > > Please review this code that adds initial support for empty inline classes. > > CR: https://bugs.openjdk.java.net/browse/JDK-8230482 > Webrev: http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.00/index.html > > Thank you, > > Fred From ioi.lam at oracle.com Tue Sep 3 15:41:51 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 3 Sep 2019 08:41:51 -0700 Subject: RFR: 8230482: Initial support for empty inline classes In-Reply-To: <768856499.1023055.1567524581092.JavaMail.zimbra@u-pem.fr> References: <2A11CD31-AB86-4493-B639-95C4609DDD87@oracle.com> <768856499.1023055.1567524581092.JavaMail.zimbra@u-pem.fr> Message-ID: Maybe we should also have some System.arraycopy() tests? Thanks - Ioi On 9/3/19 8:29 AM, Remi Forax wrote: > Hi Frederic, > i think you can add a test where an empty inline object is used as field in the middle of several fields > (perhaps using inheritance to be sure of the layout ?). > > R?mi > > ----- Mail original ----- >> De: "Frederic Parain" >> ?: "valhalla-dev" >> Envoy?: Mardi 3 Septembre 2019 16:24:08 >> Objet: RFR: 8230482: Initial support for empty inline classes >> Greetings, >> >> Please review this code that adds initial support for empty inline classes. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8230482 >> Webrev: http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.00/index.html >> >> Thank you, >> >> Fred From dms at samersoff.net Tue Sep 3 16:27:09 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Tue, 3 Sep 2019 19:27:09 +0300 Subject: Likely a bug in G1BarrierSetAssembler::oop_store_at In-Reply-To: <91552df43e882d84774261774f7d2f995fe661fd.camel@oracle.com> References: <0b228b16-4e73-88db-379b-bf766bb5fd42@samersoff.net> <296450f0-0f3d-e180-e12f-e63b738ac180@oracle.com> <91552df43e882d84774261774f7d2f995fe661fd.camel@oracle.com> Message-ID: <59722115-5e28-f4b1-23a7-dca05ea5e8c8@samersoff.net> Hello Everybody, Thank you for the explanation. On AARCH64 there are an assertion that all passed registers are different, so the code similar to this one cause an assert crash. I'll check the code and see how to arrange it on AArch64 side. -Dmitry On 03.09.2019 16:40, Thomas Schatzl wrote: > Hi, > > On Mon, 2019-09-02 at 16:41 -0700, Ioi Lam wrote: >> CC-ing hotspot-gc-dev at openjdk.java.net. >> >> >> Hi Dmitry, >> >> The code you mentioned also exists in the mainline repo: >> >> > http://hg.openjdk.java.net/jdk/jdk/file/7cf02b2c1455/src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp#l392 >> >> I think the code is OK, but maybe some from GC team can take a look >> at it, too. > > The code is okay. The only problem is that > >> >> The movptr is necessary because BarrierSetAssembler::store_at may >> modify the contents of val, so we save its value into a temp > > To be a little more exact, BarrierSetAssembler::store_at modifies the > value in val if it is a reference, i.e. it compresses it with > compressed oops enabled. For the inter-region filter we need the > uncompressed value though, saving it in new_val/tmp2. > >> register, tmp2. >> >> if (needs_post_barrier) { >> // G1 barrier needs uncompressed oop for region cross check. >> if (UseCompressedOops) { >> new_val = tmp2; >> __ movptr(new_val, val); >> } >> } >> BarrierSetAssembler::store_at(masm, decorators, type, >> Address(tmp1, 0), val, noreg, noreg, noreg); >> >> >> Later, inside g1_write_barrier_post, tmp2 is written only here, but >> we never read new_value after writing into tmp2, so we should be >> safe. >> >> __ jcc(Assembler::equal, runtime); >> __ subl(queue_index, wordSize); >> __ movptr(tmp2, buffer); >> #ifdef _LP64 >> __ movslq(rscratch1, queue_index); >> __ addq(tmp2, rscratch1); >> __ movq(Address(tmp2, 0), card_addr); >> #else >> __ addl(tmp2, queue_index); >> __ movl(Address(tmp2, 0), card_addr); >> #endif >> __ jmp(done); >> >> __ bind(runtime); >> // save the live input values >> __ push(store_addr); >> __ push(new_val); >> #ifdef _LP64 >> __ call_VM_leaf(CAST_FROM_FN_PTR(address, >> G1BarrierSetRuntime::write_ref_field_post_entry), card_addr, >> r15_thread); >> #else >> __ push(thread); >> __ call_VM_leaf(CAST_FROM_FN_PTR(address, >> G1BarrierSetRuntime::write_ref_field_post_entry), card_addr, thread); >> __ pop(thread); >> #endif >> __ pop(new_val); >> __ pop(store_addr); >> >> __ bind(done); >> >> >> My question is --- why are we saving new_value when making the >> runtime call? new_val can only be val or tmp2, but it's OK to scratch >> both registers in G1BarrierSetAssembler::oop_store_at(), and neither >> registers are used after the runtime call. > > I can imagine that sometime/somewhere there has been an implicit > contract that "val" should not be modified. Apparently G1 never did > that anyway... > > I will file a CR to look at this some more. > >> >> I commented out the push/pop of new_val and ran all tests under >> test/hotspot/jtreg/gc without problem. > > Thanks, > Thomas > > From tobias.hartmann at oracle.com Wed Sep 4 08:11:31 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 04 Sep 2019 08:11:31 +0000 Subject: hg: valhalla/valhalla: 8230348: [lworld] SIGSEGV in Compile::Output() Message-ID: <201909040811.x848BVnD008293@aojmv0008.oracle.com> Changeset: 605c732af5ff Author: thartmann Date: 2019-09-04 10:11 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/605c732af5ff 8230348: [lworld] SIGSEGV in Compile::Output() ! src/hotspot/share/opto/output.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestOnStackReplacement.java From tobias.hartmann at oracle.com Wed Sep 4 11:36:55 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 04 Sep 2019 11:36:55 +0000 Subject: hg: valhalla/valhalla: 8230397: [lworld] C2 compilation fails with assert(projs->fallthrough_proj != __null) failed: must be found Message-ID: <201909041136.x84Bau1O029873@aojmv0008.oracle.com> Changeset: 6840a94ad058 Author: thartmann Date: 2019-09-04 13:36 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6840a94ad058 8230397: [lworld] C2 compilation fails with assert(projs->fallthrough_proj != __null) failed: must be found ! src/hotspot/share/opto/callnode.cpp + test/hotspot/jtreg/compiler/valhalla/valuetypes/TestDeadAllocationRemoval.java From frederic.parain at oracle.com Wed Sep 4 16:28:41 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 4 Sep 2019 12:28:41 -0400 Subject: RFR: 8230482: Initial support for empty inline classes In-Reply-To: References: <2A11CD31-AB86-4493-B639-95C4609DDD87@oracle.com> <768856499.1023055.1567524581092.JavaMail.zimbra@u-pem.fr> Message-ID: <61527B6B-A5E0-4D90-AB04-0254C501E816@oracle.com> Remi, Ioi, Here?s a new webrev with the new tests added: http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.01/ On a 64bits platform with compressed oops, the layout of the WithEmptyField class is: Layout of class runtime/valhalla/valuetypes/EmptyValueTest$WithEmptyField | offset | kind | size | alignment | signature | name | Instance fields: 0 RESERVED 12 12 INHERITED 4 16 FLATTENED 1 1 Qruntime/valhalla/valuetypes/EmptyValueTest$EmptyValue; empty 17 EMPTY 3 20 REGULAR 4 4 Ljava/lang/Object; o The inherited field at offset 12 being the int field from the super class. Thank you, Fred > On Sep 3, 2019, at 11:41, Ioi Lam wrote: > > Maybe we should also have some System.arraycopy() tests? > > Thanks > - Ioi > > On 9/3/19 8:29 AM, Remi Forax wrote: >> Hi Frederic, >> i think you can add a test where an empty inline object is used as field in the middle of several fields >> (perhaps using inheritance to be sure of the layout ?). >> >> R?mi >> >> ----- Mail original ----- >>> De: "Frederic Parain" >>> ?: "valhalla-dev" >>> Envoy?: Mardi 3 Septembre 2019 16:24:08 >>> Objet: RFR: 8230482: Initial support for empty inline classes >>> Greetings, >>> >>> Please review this code that adds initial support for empty inline classes. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8230482 >>> Webrev: http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.00/index.html >>> >>> Thank you, >>> >>> Fred > From ioi.lam at oracle.com Wed Sep 4 16:39:36 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 4 Sep 2019 09:39:36 -0700 Subject: RFR: 8230482: Initial support for empty inline classes In-Reply-To: <61527B6B-A5E0-4D90-AB04-0254C501E816@oracle.com> References: <2A11CD31-AB86-4493-B639-95C4609DDD87@oracle.com> <768856499.1023055.1567524581092.JavaMail.zimbra@u-pem.fr> <61527B6B-A5E0-4D90-AB04-0254C501E816@oracle.com> Message-ID: <26e6d6ef-f14b-cddc-a759-c91274f8b0e1@oracle.com> Hi Fred, The changes look good to me. 1549?? const int total_fields = length + num_injected + (is_value_type ? 2 : 0); Maybe add a comment what the "2" means? Also, I think it will be good to add a Java reflection test to query the fields in EmptyValue, to make sure zero fields are returned. Thanks - Ioi On 9/4/19 9:28 AM, Frederic Parain wrote: > Remi, Ioi, > > Here?s a new webrev with the new tests added: > > http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.01/ > > On a 64bits platform with compressed oops, the layout of > the WithEmptyField class is: > > Layout of class runtime/valhalla/valuetypes/EmptyValueTest$WithEmptyField > | offset | kind | size | alignment | signature | name | > Instance fields: > 0 RESERVED 12 > 12 INHERITED 4 > 16 FLATTENED 1 1 Qruntime/valhalla/valuetypes/EmptyValueTest$EmptyValue; empty > 17 EMPTY 3 > 20 REGULAR 4 4 Ljava/lang/Object; o > > The inherited field at offset 12 being the int field from the super class. > > Thank you, > > Fred > > >> On Sep 3, 2019, at 11:41, Ioi Lam wrote: >> >> Maybe we should also have some System.arraycopy() tests? >> >> Thanks >> - Ioi >> >> On 9/3/19 8:29 AM, Remi Forax wrote: >>> Hi Frederic, >>> i think you can add a test where an empty inline object is used as field in the middle of several fields >>> (perhaps using inheritance to be sure of the layout ?). >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Frederic Parain" >>>> ?: "valhalla-dev" >>>> Envoy?: Mardi 3 Septembre 2019 16:24:08 >>>> Objet: RFR: 8230482: Initial support for empty inline classes >>>> Greetings, >>>> >>>> Please review this code that adds initial support for empty inline classes. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8230482 >>>> Webrev: http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.00/index.html >>>> >>>> Thank you, >>>> >>>> Fred From frederic.parain at oracle.com Wed Sep 4 17:50:25 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 4 Sep 2019 13:50:25 -0400 Subject: RFR: 8230482: Initial support for empty inline classes In-Reply-To: <26e6d6ef-f14b-cddc-a759-c91274f8b0e1@oracle.com> References: <2A11CD31-AB86-4493-B639-95C4609DDD87@oracle.com> <768856499.1023055.1567524581092.JavaMail.zimbra@u-pem.fr> <61527B6B-A5E0-4D90-AB04-0254C501E816@oracle.com> <26e6d6ef-f14b-cddc-a759-c91274f8b0e1@oracle.com> Message-ID: Ioi, Thank you for reviewing this change. new webrev: http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.02/index.html I?ve added a comment explaining why inline classes need two additional slots. There?s already a test checking that the injected field is not visible via reflection (EmptyValueTest.java:120-127 in the last webrev). I?ve added a few more tests to check that access by reflection to the empty field in WithEmptyField works. However, this path is not optimized yet (i.e. new instances of EmptyValue are created). Regards, Fred > On Sep 4, 2019, at 12:39, Ioi Lam wrote: > > Hi Fred, > > The changes look good to me. > > 1549 const int total_fields = length + num_injected + (is_value_type ? 2 : 0); > > Maybe add a comment what the "2" means? > > Also, I think it will be good to add a Java reflection test to query the fields in > EmptyValue, to make sure zero fields are returned. > > Thanks > - Ioi > > > On 9/4/19 9:28 AM, Frederic Parain wrote: >> Remi, Ioi, >> >> Here?s a new webrev with the new tests added: >> >> http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.01/ >> >> On a 64bits platform with compressed oops, the layout of >> the WithEmptyField class is: >> >> Layout of class runtime/valhalla/valuetypes/EmptyValueTest$WithEmptyField >> | offset | kind | size | alignment | signature | name | >> Instance fields: >> 0 RESERVED 12 >> 12 INHERITED 4 >> 16 FLATTENED 1 1 Qruntime/valhalla/valuetypes/EmptyValueTest$EmptyValue; empty >> 17 EMPTY 3 >> 20 REGULAR 4 4 Ljava/lang/Object; o >> >> The inherited field at offset 12 being the int field from the super class. >> >> Thank you, >> >> Fred >> >> >>> On Sep 3, 2019, at 11:41, Ioi Lam wrote: >>> >>> Maybe we should also have some System.arraycopy() tests? >>> >>> Thanks >>> - Ioi >>> >>> On 9/3/19 8:29 AM, Remi Forax wrote: >>>> Hi Frederic, >>>> i think you can add a test where an empty inline object is used as field in the middle of several fields >>>> (perhaps using inheritance to be sure of the layout ?). >>>> >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "Frederic Parain" >>>>> ?: "valhalla-dev" >>>>> Envoy?: Mardi 3 Septembre 2019 16:24:08 >>>>> Objet: RFR: 8230482: Initial support for empty inline classes >>>>> Greetings, >>>>> >>>>> Please review this code that adds initial support for empty inline classes. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8230482 >>>>> Webrev: http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.00/index.html >>>>> >>>>> Thank you, >>>>> >>>>> Fred > From ioi.lam at oracle.com Wed Sep 4 20:08:28 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 4 Sep 2019 13:08:28 -0700 Subject: RFR: 8230482: Initial support for empty inline classes In-Reply-To: References: <2A11CD31-AB86-4493-B639-95C4609DDD87@oracle.com> <768856499.1023055.1567524581092.JavaMail.zimbra@u-pem.fr> <61527B6B-A5E0-4D90-AB04-0254C501E816@oracle.com> <26e6d6ef-f14b-cddc-a759-c91274f8b0e1@oracle.com> Message-ID: <2f3779fb-1bd8-4cce-9d79-69fda4e56173@oracle.com> The new version looks good. Thanks! - Ioi On 9/4/2019 10:50 AM, Frederic Parain wrote: > Ioi, > > Thank you for reviewing this change. > > new webrev: > http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.02/index.html > > I?ve added a comment explaining why inline classes need > two additional slots. > > There?s already a test checking that the injected field is not > visible via reflection (EmptyValueTest.java:120-127 in the last > webrev). > > I?ve added a few more tests to check that access by reflection to > the empty field in WithEmptyField works. However, this path is > not optimized yet (i.e. new instances of EmptyValue are created). > > Regards, > > Fred > >> On Sep 4, 2019, at 12:39, Ioi Lam wrote: >> >> Hi Fred, >> >> The changes look good to me. >> >> 1549 const int total_fields = length + num_injected + (is_value_type ? 2 : 0); >> >> Maybe add a comment what the "2" means? >> >> Also, I think it will be good to add a Java reflection test to query the fields in >> EmptyValue, to make sure zero fields are returned. >> >> Thanks >> - Ioi >> >> >> On 9/4/19 9:28 AM, Frederic Parain wrote: >>> Remi, Ioi, >>> >>> Here?s a new webrev with the new tests added: >>> >>> http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.01/ >>> >>> On a 64bits platform with compressed oops, the layout of >>> the WithEmptyField class is: >>> >>> Layout of class runtime/valhalla/valuetypes/EmptyValueTest$WithEmptyField >>> | offset | kind | size | alignment | signature | name | >>> Instance fields: >>> 0 RESERVED 12 >>> 12 INHERITED 4 >>> 16 FLATTENED 1 1 Qruntime/valhalla/valuetypes/EmptyValueTest$EmptyValue; empty >>> 17 EMPTY 3 >>> 20 REGULAR 4 4 Ljava/lang/Object; o >>> >>> The inherited field at offset 12 being the int field from the super class. >>> >>> Thank you, >>> >>> Fred >>> >>> >>>> On Sep 3, 2019, at 11:41, Ioi Lam wrote: >>>> >>>> Maybe we should also have some System.arraycopy() tests? >>>> >>>> Thanks >>>> - Ioi >>>> >>>> On 9/3/19 8:29 AM, Remi Forax wrote: >>>>> Hi Frederic, >>>>> i think you can add a test where an empty inline object is used as field in the middle of several fields >>>>> (perhaps using inheritance to be sure of the layout ?). >>>>> >>>>> R?mi >>>>> >>>>> ----- Mail original ----- >>>>>> De: "Frederic Parain" >>>>>> ?: "valhalla-dev" >>>>>> Envoy?: Mardi 3 Septembre 2019 16:24:08 >>>>>> Objet: RFR: 8230482: Initial support for empty inline classes >>>>>> Greetings, >>>>>> >>>>>> Please review this code that adds initial support for empty inline classes. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8230482 >>>>>> Webrev: http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.00/index.html >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Fred From tobias.hartmann at oracle.com Thu Sep 5 13:32:16 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 05 Sep 2019 13:32:16 +0000 Subject: hg: valhalla/valhalla: [lworld] Fixed C1 time out in TestDeadAllocationRemoval due to long running loop Message-ID: <201909051332.x85DWHlc012721@aojmv0008.oracle.com> Changeset: c1d2cb660518 Author: thartmann Date: 2019-09-05 15:32 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c1d2cb660518 [lworld] Fixed C1 time out in TestDeadAllocationRemoval due to long running loop ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestDeadAllocationRemoval.java From frederic.parain at oracle.com Thu Sep 5 13:39:02 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 5 Sep 2019 09:39:02 -0400 Subject: RFR: 8230482: Initial support for empty inline classes In-Reply-To: <2f3779fb-1bd8-4cce-9d79-69fda4e56173@oracle.com> References: <2A11CD31-AB86-4493-B639-95C4609DDD87@oracle.com> <768856499.1023055.1567524581092.JavaMail.zimbra@u-pem.fr> <61527B6B-A5E0-4D90-AB04-0254C501E816@oracle.com> <26e6d6ef-f14b-cddc-a759-c91274f8b0e1@oracle.com> <2f3779fb-1bd8-4cce-9d79-69fda4e56173@oracle.com> Message-ID: <53000426-7f61-45d8-664a-6d23bc86180d@oracle.com> Ioi, Thank you for the review. Fred On 9/4/19 4:08 PM, Ioi Lam wrote: > The new version looks good. Thanks! > - Ioi > > On 9/4/2019 10:50 AM, Frederic Parain wrote: >> Ioi, >> >> Thank you for reviewing this change. >> >> new webrev: >> http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.02/index.html >> >> I?ve added a comment explaining why inline classes need >> two additional slots. >> >> There?s already a test checking that the injected field is not >> visible via reflection (EmptyValueTest.java:120-127 in the last >> webrev). >> >> I?ve added a few more tests to check that access by reflection to >> the empty field in WithEmptyField works. However, this path is >> not optimized yet (i.e. new instances of EmptyValue are created). >> >> Regards, >> >> Fred >> >>> On Sep 4, 2019, at 12:39, Ioi Lam wrote: >>> >>> Hi Fred, >>> >>> The changes look good to me. >>> >>> 1549?? const int total_fields = length + num_injected + >>> (is_value_type ? 2 : 0); >>> >>> Maybe add a comment what the "2" means? >>> >>> Also, I think it will be good to add a Java reflection test to query >>> the fields in >>> EmptyValue, to make sure zero fields are returned. >>> >>> Thanks >>> - Ioi >>> >>> >>> On 9/4/19 9:28 AM, Frederic Parain wrote: >>>> Remi, Ioi, >>>> >>>> Here?s a new webrev with the new tests added: >>>> >>>> http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.01/ >>>> >>>> On a 64bits platform with compressed oops, the layout of >>>> the WithEmptyField class is: >>>> >>>> Layout of class >>>> runtime/valhalla/valuetypes/EmptyValueTest$WithEmptyField >>>> | offset | kind | size | alignment | signature | name | >>>> Instance fields: >>>> ?? 0 RESERVED 12 >>>> ?? 12 INHERITED 4 >>>> ?? 16 FLATTENED 1 1 >>>> Qruntime/valhalla/valuetypes/EmptyValueTest$EmptyValue; empty >>>> ?? 17 EMPTY 3 >>>> ?? 20 REGULAR 4 4 Ljava/lang/Object; o >>>> >>>> The inherited field at offset 12 being the int field from the super >>>> class. >>>> >>>> Thank you, >>>> >>>> Fred >>>> >>>> >>>>> On Sep 3, 2019, at 11:41, Ioi Lam wrote: >>>>> >>>>> Maybe we should also have some System.arraycopy() tests? >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> On 9/3/19 8:29 AM, Remi Forax wrote: >>>>>> Hi Frederic, >>>>>> i think you can add a test where an empty inline object is used as >>>>>> field in the middle of several fields >>>>>> (perhaps using inheritance to be sure of the layout ?). >>>>>> >>>>>> R?mi >>>>>> >>>>>> ----- Mail original ----- >>>>>>> De: "Frederic Parain" >>>>>>> ?: "valhalla-dev" >>>>>>> Envoy?: Mardi 3 Septembre 2019 16:24:08 >>>>>>> Objet: RFR: 8230482: Initial support for empty inline classes >>>>>>> Greetings, >>>>>>> >>>>>>> Please review this code that adds initial support for empty >>>>>>> inline classes. >>>>>>> >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8230482 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~fparain/emptyvalue/webrev.00/index.html >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> Fred > From frederic.parain at oracle.com Thu Sep 5 13:49:39 2019 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Thu, 05 Sep 2019 13:49:39 +0000 Subject: hg: valhalla/valhalla: 8230482: Initial support for empty inline classes Message-ID: <201909051349.x85Dneqi022820@aojmv0008.oracle.com> Changeset: 521de4f32286 Author: fparain Date: 2019-09-05 09:48 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/521de4f32286 8230482: Initial support for empty inline classes Reviewed-by: iklam ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/valueKlass.cpp ! src/hotspot/share/oops/valueKlass.hpp - test/hotspot/jtreg/runtime/valhalla/valuetypes/Empty.java + test/hotspot/jtreg/runtime/valhalla/valuetypes/EmptyValueTest.java From forax at univ-mlv.fr Thu Sep 5 15:26:18 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Sep 2019 17:26:18 +0200 (CEST) Subject: build with shenandoah is broken Message-ID: <336594398.1990393.1567697178452.JavaMail.zimbra@u-pem.fr> It's not a big deal but the build is broken again in Shenandoah code. https://travis-ci.org/forax/java-next/jobs/581220697#L1349 R?mi From frederic.parain at oracle.com Thu Sep 5 15:37:01 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 5 Sep 2019 11:37:01 -0400 Subject: build with shenandoah is broken In-Reply-To: <336594398.1990393.1567697178452.JavaMail.zimbra@u-pem.fr> References: <336594398.1990393.1567697178452.JavaMail.zimbra@u-pem.fr> Message-ID: <8DCCF662-1A27-42D0-8684-B439A58A339F@oracle.com> This is due to the changes in the AccessAPI introduced by 8229539. Fred > On Sep 5, 2019, at 11:26, Remi Forax wrote: > > It's not a big deal but the build is broken again in Shenandoah code. > > https://travis-ci.org/forax/java-next/jobs/581220697#L1349 > > R?mi From mandy.chung at oracle.com Fri Sep 6 03:03:35 2019 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 06 Sep 2019 03:03:35 +0000 Subject: hg: valhalla/valhalla: [Nestmates] Add JVM_IsHiddenClass to test if it's hidden class and other misc cleanup. Message-ID: <201909060303.x8633aMj023901@aojmv0008.oracle.com> Changeset: d0a11d2498d2 Author: mchung Date: 2019-09-05 20:03 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/d0a11d2498d2 [Nestmates] Add JVM_IsHiddenClass to test if it's hidden class and other misc cleanup. ! make/hotspot/symbols/symbols-unix ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/utilities/accessFlags.hpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/native/libjava/Class.c ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java ! test/hotspot/jtreg/runtime/Nestmates/membership/TestDynamicNestmateMembership.java ! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java ! test/jdk/java/lang/invoke/defineHiddenClass/DefineClassWithClassData.java ! test/jdk/java/lang/invoke/defineHiddenClass/DefineHiddenClassTest.java ! test/jdk/java/lang/invoke/defineHiddenClass/SelfReferenceDescriptor.java ! test/micro/org/openjdk/bench/java/lang/invoke/LookupDefineClass.java From tobias.hartmann at oracle.com Fri Sep 6 08:19:15 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 06 Sep 2019 08:19:15 +0000 Subject: hg: valhalla/valhalla: 8230433: [lworld] C2 compilation fails with assert(_del_tick == node->_del_tick) failed: no unexpected deletions allowed Message-ID: <201909060819.x868JG3V023031@aojmv0008.oracle.com> Changeset: 4cf4325ad271 Author: thartmann Date: 2019-09-06 10:19 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4cf4325ad271 8230433: [lworld] C2 compilation fails with assert(_del_tick == node->_del_tick) failed: no unexpected deletions allowed ! src/hotspot/share/opto/valuetypenode.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestBasicFunctionality.java From dms at samersoff.net Fri Sep 6 10:28:05 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Fri, 6 Sep 2019 13:28:05 +0300 Subject: RFR(L): AARCH64 support for lworld v.06 In-Reply-To: <182a12bf-4d53-e992-c808-4ef5c8e24c03@samersoff.net> References: <182a12bf-4d53-e992-c808-4ef5c8e24c03@samersoff.net> Message-ID: Hello Everybody, Could someone help with review? -Dmitry On 02.09.19 14:16, Dmitry Samersoff wrote: > Hello Everybody, > > > Please review v.06 of adding AArch64 support to lworld branch > > http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.06/ > > What was done: > > 1. Adopted changes in shared code and fixed compilation errors > > 2. Removed all DMS CHECK kludges (but some of them become FIXME) > > 3. All the code needed to support value pack/unpack logic > is in place. > > > Problems left: > > There are couple of bugs mostly related to register usage while we > pack/unpack values. > > Therefore, ValueTypePassFieldsAsArgs/ValueTypePassFieldsAsArgs is > still hardly disabled for aarch64 > > > Testing (the same as for v.05): > > All tests in runtime/valhalla/valuetypes and in > compiler/valhalla/valuetypes/ are passed > > compiler/valhalla/valuetypes/TestMethodHandles.java > compiler/valhalla/valuetypes/TestBasicFunctionality.java > > are passed after manually tweaking of output patterns, I have not > found a way to support both x86 and aarch64, so these tests remain > unchanged and run on x64 only. > > > -Dmitry > From rwestrel at redhat.com Fri Sep 6 13:01:28 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 06 Sep 2019 15:01:28 +0200 Subject: RFR(L): AARCH64 support for lworld v.06 In-Reply-To: <182a12bf-4d53-e992-c808-4ef5c8e24c03@samersoff.net> References: <182a12bf-4d53-e992-c808-4ef5c8e24c03@samersoff.net> Message-ID: <87pnkdlgt3.fsf@redhat.com> > Please review v.06 of adding AArch64 support to lworld branch I went over it quickly so this is not a real review. I see no reason not to push it given it's aarch64 only. Thanks for working on aarch64 support. Roland. From tobias.hartmann at oracle.com Fri Sep 6 13:36:05 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 06 Sep 2019 13:36:05 +0000 Subject: hg: valhalla/valhalla: 8230394: [lworld] C2 compilation fails with assert(_refresh_tick < 2*100000) failed: DU iteration must converge quickly Message-ID: <201909061336.x86Da6DH018745@aojmv0008.oracle.com> Changeset: 35008408519d Author: thartmann Date: 2019-09-06 15:33 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/35008408519d 8230394: [lworld] C2 compilation fails with assert(_refresh_tick < 2*100000) failed: DU iteration must converge quickly ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/split_if.cpp ! src/hotspot/share/opto/valuetypenode.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestBasicFunctionality.java From dms at samersoff.net Sun Sep 8 12:05:47 2019 From: dms at samersoff.net (dms at samersoff.net) Date: Sun, 08 Sep 2019 12:05:47 +0000 Subject: hg: valhalla/valhalla: [lworld] Valhalla support for AArch64 part 2 Message-ID: <201909081205.x88C5lW2012484@aojmv0008.oracle.com> Changeset: 8bd3c0a77be7 Author: dsamersoff Date: 2019-09-08 12:02 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8bd3c0a77be7 [lworld] Valhalla support for AArch64 part 2 ! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp From dms at samersoff.net Sun Sep 8 12:06:57 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 8 Sep 2019 15:06:57 +0300 Subject: RFR(L): AARCH64 support for lworld v.06 In-Reply-To: <87pnkdlgt3.fsf@redhat.com> References: <182a12bf-4d53-e992-c808-4ef5c8e24c03@samersoff.net> <87pnkdlgt3.fsf@redhat.com> Message-ID: <800ecf42-2fae-e702-9da1-a7769f160068@samersoff.net> Roland, Thank you! I pushed the changes. -Dmitry On 06.09.2019 16:01, Roland Westrelin wrote: > >> Please review v.06 of adding AArch64 support to lworld branch > > I went over it quickly so this is not a real review. I see no reason not > to push it given it's aarch64 only. Thanks for working on aarch64 > support. > > Roland. > From tobias.hartmann at oracle.com Mon Sep 9 12:59:34 2019 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 09 Sep 2019 12:59:34 +0000 Subject: hg: valhalla/valhalla: 8230761: [lworld] C2 compilation fails with assert(reg < CHUNK_SIZE) failed Message-ID: <201909091259.x89CxZfZ005282@aojmv0008.oracle.com> Changeset: a3238d454e63 Author: thartmann Date: 2019-09-09 14:59 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a3238d454e63 8230761: [lworld] C2 compilation fails with assert(reg < CHUNK_SIZE) failed ! src/hotspot/share/opto/matcher.cpp ! test/hotspot/jtreg/compiler/valhalla/valuetypes/TestOnStackReplacement.java From david.holmes at oracle.com Mon Sep 9 20:52:56 2019 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 09 Sep 2019 20:52:56 +0000 Subject: hg: valhalla/valhalla: 769 new changesets Message-ID: <201909092053.x89KrmZK019657@aojmv0008.oracle.com> Changeset: e27ae3706392 Author: jwilhelm Date: 2019-06-20 04:08 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e27ae3706392 Added tag jdk-13+26 for changeset 0692b67f5462 ! .hgtags Changeset: 1170b6d92d1c Author: xuelei Date: 2019-06-19 21:49 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1170b6d92d1c 8225766: Curve in certificate should not affect signature scheme when using TLSv1.3 Reviewed-by: ascarpino ! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java ! src/java.base/share/classes/sun/security/ssl/X509Authentication.java + test/jdk/sun/security/ssl/SignatureScheme/Tls13NamedGroups.java Changeset: 65916ade7fa2 Author: erikj Date: 2019-06-20 07:56 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/65916ade7fa2 8226404: bootcycle build uses wrong CDS archive Reviewed-by: iklam ! make/autoconf/bootcycle-spec.gmk.in Changeset: 8892555795cd Author: kvn Date: 2019-06-20 10:32 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/8892555795cd 8223794: applications/kitchensink/Kitchensink.java crash bad oop with Graal Summary: added new nmethod::oop_at_phantom() method for JVMCI to notify GC that oop should be kept alive Reviewed-by: dlong, eosterlund ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp Changeset: 76647c08ce0c Author: epavlova Date: 2019-06-20 11:42 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/76647c08ce0c 8225684: [AOT] vmTestbase/vm/oom/production/AlwaysOOMProduction tests fail with AOTed java.base Reviewed-by: kvn + test/hotspot/jtreg/ProblemList-aot.txt Changeset: de3484367466 Author: jjg Date: 2019-06-20 14:24 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/de3484367466 8226412: Fix command-line help text for javac -target Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties Changeset: ced62a6a7bbe Author: dtitov Date: 2019-06-20 18:47 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ced62a6a7bbe 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout Reviewed-by: sspitsyn, cjplummer ! src/hotspot/os/linux/perfMemory_linux.cpp Changeset: 81ac9262e63b Author: jwilhelm Date: 2019-06-21 04:16 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/81ac9262e63b Merge ! .hgtags Changeset: 00f29fe98900 Author: coffeys Date: 2019-06-21 08:07 +0000 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/00f29fe98900 8133489: Better messaging for PKIX path validation matching Reviewed-by: xuelei ! src/java.base/share/classes/java/security/cert/X509CertSelector.java ! test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java Changeset: 17ba7ce18564 Author: hannesw Date: 2019-06-21 12:23 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/17ba7ce18564 8225802: Remove unused CSS classes from HTML doclet Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: e764228f71dc Author: mullan Date: 2019-06-21 08:38 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e764228f71dc 8226307: Curve names should be case-insensitive Reviewed-by: igerasim, jnimeh, wetmore ! src/java.base/share/classes/sun/security/util/CurveDB.java ! test/jdk/java/security/KeyAgreement/KeyAgreementTest.java Changeset: 6dfdcd31463d Author: kvn Date: 2019-06-21 13:04 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6dfdcd31463d 8185139: [Graal] Tests which set too restrictive security manager fail with Graal Summary: tests should also check default policy Reviewed-by: mchung, dfuchs, alanb, mullan ! test/jdk/ProblemList-graal.txt ! test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java ! test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/jdk/java/lang/ProcessBuilder/Basic.java ! test/jdk/java/lang/ProcessBuilder/SecurityManagerClinit.java ! test/jdk/java/lang/ProcessHandle/PermissionTest.java ! test/jdk/java/lang/System/Logger/custom/CustomLoggerTest.java ! test/jdk/java/lang/System/Logger/default/DefaultLoggerTest.java ! test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java ! test/jdk/java/lang/System/LoggerFinder/DefaultLoggerFinderTest/DefaultLoggerFinderTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/BaseLoggerBridgeTest/BaseLoggerBridgeTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/BasePlatformLoggerTest/BasePlatformLoggerTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/LoggerBridgeTest/LoggerBridgeTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest/PlatformLoggerBridgeTest.java ! test/jdk/java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java ! test/jdk/java/lang/System/LoggerFinder/jdk/DefaultPlatformLoggerTest/DefaultPlatformLoggerTest.java ! test/jdk/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/jdk/java/lang/invoke/MethodHandleConstants.java ! test/jdk/java/security/Policy/Dynamic/DynamicPolicy.java ! test/jdk/java/util/concurrent/Executors/PrivilegedCallables.java ! test/jdk/java/util/logging/FileHandlerLongLimit.java ! test/jdk/java/util/logging/FileHandlerPath.java ! test/jdk/java/util/logging/FileHandlerPatternExceptions.java ! test/jdk/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexUpdate.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigurationTest.java ! test/jdk/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java ! test/jdk/java/util/logging/LogManagerAppContextDeadlock.java ! test/jdk/java/util/logging/RootLogger/RootLevelInConfigFile.java ! test/jdk/java/util/logging/TestAppletLoggerContext.java ! test/jdk/java/util/logging/TestConfigurationListeners.java Changeset: 31bf7b93df5d Author: kvn Date: 2019-06-21 16:21 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/31bf7b93df5d 8225810: Update JVMCI Reviewed-by: never, dnsimon ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompilationRequest.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java + src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstantScope.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaType.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedPrimitiveType.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/IndirectHotSpotObjectConstantImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/SharedLibraryJVMCIReflection.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TypeUniverse.java Changeset: a3e3f3caf284 Author: sspitsyn Date: 2019-06-20 23:12 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a3e3f3caf284 8223736: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events Summary: Fix the synchronization issue in the test Reviewed-by: cjplummer, dcubed, amenkov ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp Changeset: 68ef70c9a921 Author: erikj Date: 2019-06-21 06:33 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/68ef70c9a921 8226538: find-files.gmk gets corrupted if tab completion is used before running make first Reviewed-by: tbell ! make/common/FindTests.gmk ! test/make/TestMake.gmk Changeset: a6411f1e63f3 Author: adinn Date: 2019-06-21 15:16 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/a6411f1e63f3 8226203: MappedByteBuffer.force method may have no effect on implementation specific map modes Summary: Fix comment for MappedByteBuffer force methods Reviewed-by: alanb ! src/java.base/share/classes/java/nio/MappedByteBuffer.java Changeset: e9d4e0a9c8c7 Author: coleenp Date: 2019-06-21 09:53 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e9d4e0a9c8c7 8226394: [TESTBUG] vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java fails with java.lang.NoClassDefFoundError Summary: don't use printStackTrace to verify OOM type. Reviewed-by: lfoltan, dholmes ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java Changeset: 076f34b82b98 Author: weijun Date: 2019-06-21 23:44 +0800 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/076f34b82b98 8225257: sun/security/tools/keytool/PSS.java timed out Reviewed-by: valeriep - test/jdk/sun/security/tools/keytool/PSS.java + test/jdk/sun/security/tools/keytool/pss/PSS.java + test/jdk/sun/security/tools/keytool/pss/java.base/sun/security/rsa/RSAKeyPairGenerator.java Changeset: e00591da418d Author: erikj Date: 2019-06-21 10:38 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e00591da418d 8226269: Race in SetupProcessMarkdown Reviewed-by: tbell ! make/common/ProcessMarkdown.gmk Changeset: 97c75e545302 Author: jjg Date: 2019-06-21 11:41 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/97c75e545302 8226592: Fix HTML in table for jdk.zipfs module-info Reviewed-by: bpb, lancea ! src/jdk.zipfs/share/classes/module-info.java Changeset: 179204eb9444 Author: jjg Date: 2019-06-21 12:09 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/179204eb9444 8226593: Fix HTML in com/sun/jdi/doc-files/signature.html Reviewed-by: sspitsyn, lancea ! src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html Changeset: 72bbc930d7b6 Author: jwilhelm Date: 2019-06-22 02:03 +0200 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/72bbc930d7b6 Merge - test/jdk/sun/security/tools/keytool/PSS.java Changeset: c9e362aef472 Author: zgu Date: 2019-06-24 09:51 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c9e362aef472 8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 73250862f818 Author: michaelm Date: 2019-06-24 15:10 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/73250862f818 8219804: java/net/MulticastSocket/Promiscuous.java fails intermittently due to NumberFormatException Reviewed-by: chegar, dfuchs ! test/jdk/java/net/MulticastSocket/Promiscuous.java Changeset: 6ca3526c4e25 Author: michaelm Date: 2019-06-24 15:19 +0100 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/6ca3526c4e25 8226683: Remove review suggestion from fix to 8219804 Reviewed-by: chegar ! test/jdk/java/net/MulticastSocket/Promiscuous.java Changeset: aee0d296c0ef Author: zgu Date: 2019-06-24 11:46 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/aee0d296c0ef 8226311: Shenandoah: Concurrent evacuation of OopStorage backed weak roots Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootVerifier.hpp Changeset: c396e381cfa4 Author: zgu Date: 2019-06-24 14:13 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/c396e381cfa4 8226310: Shenandoah: Concurrent evacuation of CLDG Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: ae2e53e379cb Author: coleenp Date: 2019-06-24 16:51 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/ae2e53e379cb 8214822: Move ConcurrentHashTable VALUE parameter to CONFIG Summary: make VALUE parameter be included in CONFIG configuration, also remove BaseConfig Reviewed-by: dholmes, kbarrett ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/prims/resolvedMethodTable.cpp ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp ! test/hotspot/gtest/utilities/test_concurrentHashtable.cpp Changeset: 80b27dc96ca3 Author: dcubed Date: 2019-06-24 22:38 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/80b27dc96ca3 8226699: [BACKOUT] JDK-8221734 Deoptimize with handshakes Reviewed-by: dholmes, rehn, dlong ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/aot/aotCompiledMethod.cpp ! src/hotspot/share/aot/aotCompiledMethod.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/gc/z/zBarrierSetNMethod.cpp ! src/hotspot/share/gc/z/zNMethod.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/biasedLocking.cpp ! src/hotspot/share/runtime/biasedLocking.hpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.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/services/dtraceAttacher.cpp - test/hotspot/jtreg/compiler/codecache/stress/UnexpectedDeoptimizationAllTest.java Changeset: f1e5ddb814b7 Author: serb Date: 2019-06-21 16:20 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/f1e5ddb814b7 8225146: Accessibility issues in javax/swing/plaf/nimbus/doc-files/properties.html Reviewed-by: aivanov ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html Changeset: e17c9a93b505 Author: sspitsyn Date: 2019-06-21 18:20 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/e17c9a93b505 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed Summary: Improve synchronization in the test Reviewed-by: dcubed, amenkov ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/tc02t001.cpp Changeset: 4d5eabe8d341 Author: sspitsyn Date: 2019-06-22 14:35 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/4d5eabe8d341 8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events Summary: Fix one more sync issue in the test Reviewed-by: dcubed, amenkov ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001.java Changeset: 00c08fae63e8 Author: mullan Date: 2019-06-24 10:11 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/00c08fae63e8 8180005: Provide specific links in KeyManagerFactory and TrustManagerFactory to the Standard Algorithm Names Specification Reviewed-by: ascarpino ! src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java Changeset: 1cd4d287839b Author: bobv Date: 2019-06-24 11:49 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1cd4d287839b 8224502: [TESTBUG] JDK docker test TestSystemMetrics.java fails with access issues and OOM Reviewed-by: sgehwolf, mseledtsov ! test/jdk/ProblemList.txt ! test/jdk/jdk/internal/platform/docker/TestSystemMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java Changeset: 1e4bbd6fbb2f Author: bobv Date: 2019-06-24 11:52 -0400 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/1e4bbd6fbb2f 8224506: [TESTBUG] TestDockerMemoryMetrics.java fails with exitValue = 137 Reviewed-by: sgehwolf, mseledtsov ! test/jdk/ProblemList.txt ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java Changeset: fe6c2f0b42be Author: jjg Date: 2019-06-24 13:40 -0700 URL: https://hg.openjdk.java.net/valhalla/valhalla/rev/fe6c2f0b42be 8226628: The copyright footer should be enclosed in