From fujie at loongson.cn Sat Jun 1 01:37:17 2019 From: fujie at loongson.cn (Jie Fu) Date: Sat, 1 Jun 2019 09:37:17 +0800 Subject: RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached In-Reply-To: References: <282b2c79-1ce0-95bb-c37a-d151edcc02f4@oracle.com> <03736619-e07f-e33c-635b-5e8d722d0142@loongson.cn> <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn> <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com> <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com> <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn> <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com> <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com> <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn> <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn> <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn> Message-ID: <1e559921-8d8c-177a-c301-429bc657053a@loongson.cn> Hi Vladimir Ivanov, Thanks for your review and suggestions. Updated: http://cr.openjdk.java.net/~jiefu/8224162/webrev.10/ Thanks a lot. Best regards, Jie On 2019/6/1 ??5:47, Vladimir Ivanov wrote: > +template > +int ciMethod::saturated_add(L a, R b) { > > What do you think about moving it to globalDefinitions.hpp? > > Probably, it's worth getting rid of the template parameters and > introduce specializations (akin to JAVA_INTEGER_OP) since the > implementation makes sense only for int/uint. It seems cool. I like this style. > > +? jlong sum? = src1 + src2; > I'd prefer to see explicit casts to jlong to stress there's no > overflow possible here for 32-bit values. > Done > > +??? return c < 0 ? max_jint : c; > +????? case Bytecodes::_instanceof: return c > 0 ? min_jint : c; > > Please, put parentheses around ternary expressions. > Done From david.holmes at oracle.com Sat Jun 1 05:26:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 1 Jun 2019 15:26:05 +1000 Subject: [13] RFR (XS): 8225141: Better handling of classes in error state in fast class initialization checks In-Reply-To: <18cc95c1-4b46-2eec-bb16-34380aad9394@oracle.com> References: <18cc95c1-4b46-2eec-bb16-34380aad9394@oracle.com> Message-ID: Hi Vladimir, On 1/06/2019 6:53 am, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8225141/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8225141 > > Fast class initialization checks don't properly handle classes in error > state when performed from (previously) initializing thread. > > One way to fix it is to add one more fast path check > (InstanceKlass::_init_state == being_initialized) into the barrier, but > that would require significant changes, since both newly introduced > checks (JDK-8223213 [1]) and existing C1 checks should be changed. > > What I propose is to set InstanceKlass::_init_thread only for the > duration when the klass is in being_initialized state and reset it back > to NULL when changing class state. It makes existing "_init_thread == > current_thread" check equivalent to "_init_state == being_initialized && > _init_thread == current_thread". That seems reasonable. By clearing the init_thread we no longer consider this a recursive initialization by the current thread and take the slow path which will reveal the class is erroneous. Looking at the fast init changes I'm unclear why these assertions are valid: +void LIR_Assembler::clinit_barrier(ciMethod* method) { + assert(method->holder()->is_being_initialized() || method->holder()->is_initialized(), + "initialization should have been started"); + if (C->clinit_barrier_on_entry()) { + assert(C->method()->holder()->is_being_initialized() || C->method()->holder()->is_initialized(), + "initialization should have been started"); I'm not sure how we get to these code fragments such that its guaranteed initialization must already have been initiated (and possibly completed) - can't this be the first time we've called a static method and so the current thread would become responsible for doing the initialization? And again what if the class is actually in an error state? This ties in to JDK-8225106. Thanks, David ----- > Testing: hs-precheckin-comp, tier1-4 > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8223213 From vladimir.x.ivanov at oracle.com Sat Jun 1 11:53:11 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 1 Jun 2019 14:53:11 +0300 Subject: [13] RFR (XS): 8225141: Better handling of classes in error state in fast class initialization checks In-Reply-To: References: <18cc95c1-4b46-2eec-bb16-34380aad9394@oracle.com> Message-ID: Thanks for the feedback, David. >> What I propose is to set InstanceKlass::_init_thread only for the >> duration when the klass is in being_initialized state and reset it >> back to NULL when changing class state. It makes existing >> "_init_thread == current_thread" check equivalent to "_init_state == >> being_initialized && _init_thread == current_thread". > > That seems reasonable. By clearing the init_thread we no longer consider > this a recursive initialization by the current thread and take the slow > path which will reveal the class is erroneous. > > Looking at the fast init changes I'm unclear why these assertions are > valid: > > +void LIR_Assembler::clinit_barrier(ciMethod* method) { > +? assert(method->holder()->is_being_initialized() || > method->holder()->is_initialized(), > +???????? "initialization should have been started"); > > +? if (C->clinit_barrier_on_entry()) { > +??? assert(C->method()->holder()->is_being_initialized() || > C->method()->holder()->is_initialized(), > +?????????? "initialization should have been started"); > > I'm not sure how we get to these code fragments such that its guaranteed > initialization must already have been initiated (and possibly completed) > - can't this be the first time we've called a static method and so the > current thread would become responsible for doing the initialization? First of all, sorry for the confusion. I should have mentioned that this patch is intended to go in along with the fix for JDK-8225106 [1]. It relaxes the aforementioned asserts and makes class error state expected. Still, pre-initialized states shouldn't be seen by JITs there: even in -Xcomp mode, first invocation triggers resolution (which initiates class initialization) and only then resolved method is submitted for compilation. > And again what if the class is actually in an error state? This ties in > to JDK-8225106. Proposed fix for JDK-8225106 adds new logic which fail the compilation if method holder is in error state. Plus, if initialization fails after compilation is over, the barrier will forward execution into slow path and exception will be thrown during re-resolution. This scenario is tested by runtime/clinit/ClassInitBarrier (and the fix adds more scenarios). Best regards, Vladimir Ivanov [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/034058.html > > Thanks, > David > ----- > >> Testing: hs-precheckin-comp, tier1-4 >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8223213 From vladimir.x.ivanov at oracle.com Sat Jun 1 11:53:23 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 1 Jun 2019 14:53:23 +0300 Subject: [13] RFR (XS): 8225141: Better handling of classes in error state in fast class initialization checks In-Reply-To: <70f49678-782e-9b38-d4b8-79cb88c71e70@oracle.com> References: <18cc95c1-4b46-2eec-bb16-34380aad9394@oracle.com> <70f49678-782e-9b38-d4b8-79cb88c71e70@oracle.com> Message-ID: Thanks, Dean. Best regards, Vladimir Ivanov On 01/06/2019 02:14, dean.long at oracle.com wrote: > Looks good. > > dl > > On 5/31/19 1:53 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8225141/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8225141 >> >> Fast class initialization checks don't properly handle classes in >> error state when performed from (previously) initializing thread. >> >> One way to fix it is to add one more fast path check >> (InstanceKlass::_init_state == being_initialized) into the barrier, >> but that would require significant changes, since both newly >> introduced checks (JDK-8223213 [1]) and existing C1 checks should be >> changed. >> >> What I propose is to set InstanceKlass::_init_thread only for the >> duration when the klass is in being_initialized state and reset it >> back to NULL when changing class state. It makes existing >> "_init_thread == current_thread" check equivalent to "_init_state == >> being_initialized && _init_thread == current_thread". >> >> Testing: hs-precheckin-comp, tier1-4 >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8223213 > From patric.hedlin at oracle.com Sun Jun 2 14:11:31 2019 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Sun, 2 Jun 2019 16:11:31 +0200 Subject: RFR(M): 8223363: Bad node estimate assertion failure In-Reply-To: References: <97125c44-5709-3cc6-7a29-70ee1a0d1f7c@oracle.com> <08d8d09a-44a8-15ff-835c-363820140151@redhat.com> <82222832-8d19-3972-a98b-45f5de55685f@oracle.com> <5409c3e8-ef31-c753-abf7-e9334d18f517@redhat.com> <936169ea-0e8a-540f-29e1-615243e483a5@oracle.com> <412dc2e7-b748-5467-8d5d-6cea5bd81957@redhat.com> <20544c1c-12fc-520b-0cdd-30e32b6cda32@redhat.com> <7a2fb3a4-a68f-d98c-a39c-02cc9cd48e1a@oracle.com> <358ae47a-422f-e243-febe-086820ec6bc9@oracle.com> Message-ID: <16b335cf-38c4-426b-9e69-5362e665840e@oracle.com> Thanks for reviewing Vladimir. /Patric On 2019-05-31 16:26, Vladimir Kozlov wrote: > Looks good. > > thanks, > Vladimir > > On 5/31/19 1:55 AM, Patric Hedlin wrote: >> Updated testcase with "@requires !vm.graal.enabled". >> >> Refreshed Webrev: http://cr.openjdk.java.net/~phedlin/tr8223363/ >> >> Best regards, >> Patric >> >> On 29/05/2019 19:00, Vladimir Kozlov wrote: >>> >>> Hi Patric >>> >>> Add to test '@requires !vm.graal.enabled' to avoid running with Graal. >>> And add link to test results to the bug report. I assume you need to >>> run 1-3 tiers and hs-precheckin-comp. >>> >>> Thanks, >>> Vladimir >>> >>> On 5/29/19 12:48 AM, Patric Hedlin wrote: >>>> Updated webrev: http://cr.openjdk.java.net/~phedlin/tr8223363/ >>>> >>>> Now also including the testcase for/from 8223502. >>>> >>>> Best regards, >>>> Patric >>>> >>>> On 28/05/2019 18:50, Aleksey Shipilev wrote: >>>>> On 5/28/19 6:49 PM, Patric Hedlin wrote: >>>>>> On 2019-05-28 15:51, Aleksey Shipilev wrote: >>>>>>> On 5/28/19 3:07 PM, Patric Hedlin wrote: >>>>>>>> Ooops, sorry. The test-case from 8223502 is here: Webrev: >>>>>>>> http://cr.openjdk.java.net/~phedlin/tr8223502/ >>>>>>> Yes, so what prevents us from including that test in this >>>>>>> changeset? Surely it acts like the >>>>>>> regression tests for the fix. >>>>>> Absolutely nothing. The error was only in my webrev generation >>>>>> that didn't include both bookmarks. >>>>>> They will be pushed "as one". (I can generate a new, single, >>>>>> complete, webrev in the morning if you >>>>>> prefer.) >>>>> Yes, please. I prefer full webrevs to understand what exactly is >>>>> being pushed. >>>>> >>>>> -Aleksey >>>>> >>>> >> From OGATAK at jp.ibm.com Mon Jun 3 04:18:18 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Mon, 3 Jun 2019 13:18:18 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <21b41ea7-f8e8-39ee-aebf-b6f80ab41367@redhat.com> References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> <21b41ea7-f8e8-39ee-aebf-b6f80ab41367@redhat.com> Message-ID: Hi Andrew, Thank you for clarification. I understood. Regards, Ogata Andrew John Hughes wrote on 2019/06/01 01:18:22: > From: Andrew John Hughes > To: Kazunori Ogata > Cc: "hotspot-compiler-dev at openjdk.java.net" dev at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" > Date: 2019/06/01 01:18 > Subject: [EXTERNAL] Re: [8u-dev, ppc] RFR for (almost clean) backport of > 8185969: PPC64: Improve VSR support to use up to 64 registers > > > > On 31/05/2019 05:54, Kazunori Ogata wrote: > > Hi Andrew, > > > > Thank you for your confirmation. > > > >> However, please don't assume an acceptable review just because there is > >> no objection. > > > > I see. I thought review was optional in this case since it is almost clean > > and no change in the actual code. But I should have waited for your > > reply, as you reviewed the patch. I'll be more careful. > > > > > > Regards, > > Ogata > > > > > > You didn't do anything wrong. I just wanted to clarify that there should > always been an explicit ok if a review is required, in case there was > any misunderstanding. > > Regards, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] From OGATAK at jp.ibm.com Mon Jun 3 04:20:46 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Mon, 3 Jun 2019 13:20:46 +0900 Subject: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array with double float literals In-Reply-To: References: Message-ID: Hi Volker and Martin, Is the updated webrev good? Regards, Ogata Kazunori Ogata/Japan/IBM wrote on 2019/05/29 14:16:12: > From: Kazunori Ogata/Japan/IBM > To: "hotspot-compiler-dev at openjdk.java.net" dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, Volker Simonis , "Doerr, > Martin" > Date: 2019/05/29 14:16 > Subject: Re: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array > with double float literals > > Hi Volker and Martin, > > Thank you for your comment. I updated the webrev. > > http://cr.openjdk.java.net/~horii/8224090/webrev.01/ > > Regards, > Ogata > > "Doerr, Martin" wrote on 2019/05/28 23:04:15: > > > From: "Doerr, Martin" > > To: Volker Simonis , Kazunori Ogata > > Cc: "hotspot-compiler-dev at openjdk.java.net" > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > dev at openjdk.java.net> > > Date: 2019/05/28 23:08 > > Subject: RE: RFR: 8224090: [PPC64] Fix SLP patterns for filling > > an array with double float literals > > > > Right, this needs to get changed. > > > > Best regards, > > Martin > > > > > -----Original Message----- > > > From: Volker Simonis > > > Sent: Dienstag, 28. Mai 2019 15:04 > > > To: Kazunori Ogata > > > Cc: Doerr, Martin ; hotspot-compiler- > > > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > > Subject: Re: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array with > > > double float literals > > > > > > Hi Ogata, > > > > > > you change looks good, but you should use "jlong_cast()" in the > > > "immD_0()" operand. > > > > > > Thank you and best regards, > > > Volker > > > > > > > > > On Tue, May 28, 2019 at 12:26 PM Kazunori Ogata > > > wrote: > > > > > > > > Hi Martin, > > > > > > > > Thank you for your review. > > > > > > > > Regards, > > > > Ogata > > > > > > > > "Doerr, Martin" wrote on 2019/05/28 18:21:29: > > > > > > > > > From: "Doerr, Martin" > > > > > To: Kazunori Ogata , "hotspot-compiler- > > > > > dev at openjdk.java.net" , > > > "ppc-aix- > > > > > port-dev at openjdk.java.net" > > > > > Date: 2019/05/28 18:21 > > > > > Subject: [EXTERNAL] RE: RFR: 8224090: [PPC64] Fix SLP patterns for > > > > filling > > > > > an array with double float literals > > > > > > > > > > Hi Ogata, > > > > > > > > > > looks good. Thanks for fixing. > > > > > > > > > > Best regards, > > > > > Martin > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: hotspot-compiler-dev > > > > > bounces at openjdk.java.net> On Behalf Of Kazunori Ogata > > > > > > Sent: Freitag, 17. Mai 2019 07:34 > > > > > > To: hotspot-compiler-dev at openjdk.java.net; ppc-aix-port- > > > > > > dev at openjdk.java.net > > > > > > Subject: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array > > > > with double > > > > > > float literals > > > > > > > > > > > > Hi, > > > > > > > > > > > > May I get review for a webrev to fix SLP patterns that use PPC64 VSX > > > > > > instructions? > > > > > > > > > > > > We found that SLP patterns added by JDK-8208171 [1] use incorrect > > > data > > > > > > type, so the patterns have never been used. Further, the pattern for > > > > > > filling -1.0 is confused with the operation for filling -1L. > > > > > > > > > > > > This webrev fixes the pattern to fill an array with 0 to use 0.0d > > > > instead > > > > > > of 0d, and removes the pattern to will with -1 because the bit pattern > > > > of > > > > > > -1.0d is not easy to generate using a single VSX instruction. It's > > > > should > > > > > > be better to load the literal from TOC and use general repl2D_reg_Ex > > > > > > pattern. > > > > > > > > > > > > I also fixed some comments in "format %{ ... %}" to show correct > > > > matching > > > > > > types. > > > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224090 > > > > > > > > > > > > Webrev: http://cr.openjdk.java.net/~horii/8224090/webrev.00/ > > > > > > > > > > > > Ref: > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8208171 > > > > > > > > > > > > > > > > > > Regards, > > > > > > Ogata > > > > > > > > > > > > > > > > > > > > From david.holmes at oracle.com Mon Jun 3 06:35:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Jun 2019 16:35:49 +1000 Subject: [13] RFR (XS): 8225141: Better handling of classes in error state in fast class initialization checks In-Reply-To: References: <18cc95c1-4b46-2eec-bb16-34380aad9394@oracle.com> Message-ID: <52635b16-57a2-cb71-40c9-6470be77dcbb@oracle.com> Hi Vladimir, Thanks for clarifying how the different pieces connect. I'm somewhat surprised this wasn't caught during pre-push testing, but hopefully this now covers all cases. Thanks, David On 1/06/2019 9:53 pm, Vladimir Ivanov wrote: > Thanks for the feedback, David. > >>> What I propose is to set InstanceKlass::_init_thread only for the >>> duration when the klass is in being_initialized state and reset it >>> back to NULL when changing class state. It makes existing >>> "_init_thread == current_thread" check equivalent to "_init_state == >>> being_initialized && _init_thread == current_thread". >> >> That seems reasonable. By clearing the init_thread we no longer >> consider this a recursive initialization by the current thread and >> take the slow path which will reveal the class is erroneous. >> >> Looking at the fast init changes I'm unclear why these assertions are >> valid: >> >> +void LIR_Assembler::clinit_barrier(ciMethod* method) { >> +? assert(method->holder()->is_being_initialized() || >> method->holder()->is_initialized(), >> +???????? "initialization should have been started"); >> >> +? if (C->clinit_barrier_on_entry()) { >> +??? assert(C->method()->holder()->is_being_initialized() || >> C->method()->holder()->is_initialized(), >> +?????????? "initialization should have been started"); >> >> I'm not sure how we get to these code fragments such that its >> guaranteed initialization must already have been initiated (and >> possibly completed) - can't this be the first time we've called a >> static method and so the current thread would become responsible for >> doing the initialization? > > First of all, sorry for the confusion. I should have mentioned that this > patch is intended to go in along with the fix for JDK-8225106 [1]. It > relaxes the aforementioned asserts and makes class error state expected. > > Still, pre-initialized states shouldn't be seen by JITs there: even in > -Xcomp mode, first invocation triggers resolution (which initiates class > initialization) and only then resolved method is submitted for compilation. > >> And again what if the class is actually in an error state? This ties >> in to JDK-8225106. > > Proposed fix for JDK-8225106 adds new logic which fail the compilation > if method holder is in error state. Plus, if initialization fails after > compilation is over, the barrier will forward execution into slow path > and exception will be thrown during re-resolution. This scenario is > tested by runtime/clinit/ClassInitBarrier (and the fix adds more > scenarios). > > Best regards, > Vladimir Ivanov > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/034058.html > > > >> >> Thanks, >> David >> ----- >> >>> Testing: hs-precheckin-comp, tier1-4 >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8223213 From rwestrel at redhat.com Mon Jun 3 07:30:37 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 03 Jun 2019 09:30:37 +0200 Subject: RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded In-Reply-To: References: <877eailvgp.fsf@redhat.com> <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com> Message-ID: <87v9xn9lcy.fsf@redhat.com> Hi Dean, Thanks for looking at this. > It seems to do what you want, but I'm curious, what's the worse that can > happen if we call set_shared() on a node that doesn't need it? Some complex match rules wouldn't trigger anymore. Let's say we have (CmpN (LoadN ... and we erroneously call set_shared on the LoadN then this: instruct testN_mem(rFlagsReg cr, memory mem, immN0 zero) %{ predicate(CompressedOops::base() != NULL); match(Set cr (CmpN (LoadN mem) zero)); won't match and instead of a single instruction we would have a load instruction followed by a comparison. So worse case, correctness is not affected but code quality can be. Roland. From rwestrel at redhat.com Mon Jun 3 07:36:31 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 03 Jun 2019 09:36:31 +0200 Subject: RFR(S): 8173196: [REDO] C2 does not optimize redundant memory operations with G1 In-Reply-To: References: <871s0qlu20.fsf@redhat.com> Message-ID: <87sgsr9l34.fsf@redhat.com> Thanks for the review, Vladimir. Roland. From rkennke at redhat.com Mon Jun 3 08:01:41 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 3 Jun 2019 10:01:41 +0200 Subject: RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded In-Reply-To: <87v9xn9lcy.fsf@redhat.com> References: <877eailvgp.fsf@redhat.com> <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com> <87v9xn9lcy.fsf@redhat.com> Message-ID: <20bc16d4-b1a0-612e-3af9-287c2fcbc7f0@redhat.com> Hi Roland, > Hi Dean, > > Thanks for looking at this. > >> It seems to do what you want, but I'm curious, what's the worse that can >> happen if we call set_shared() on a node that doesn't need it? > > Some complex match rules wouldn't trigger anymore. Let's say we have > (CmpN (LoadN ... and we erroneously call set_shared on the LoadN then > this: > > instruct testN_mem(rFlagsReg cr, memory mem, immN0 zero) > %{ > predicate(CompressedOops::base() != NULL); > match(Set cr (CmpN (LoadN mem) zero)); > > won't match and instead of a single instruction we would have a load > instruction followed by a comparison. > > So worse case, correctness is not affected but code quality can be. In general? Or only in offset==0 case? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rwestrel at redhat.com Mon Jun 3 08:50:35 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 03 Jun 2019 10:50:35 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> Message-ID: <87k1e39hno.fsf@redhat.com> Hi Nils, >> loopnode.cpp: >> >> Do we really need a new entry in the gc api for barrier_insertion() >> couldn't this go under optimize_loops()? > > It could. There is only remove_range_check_casts in between right now. I > choose to have it as its own for separation, in a similar way to how > LoopOptsNone are used. I think your answer is for code in compile.cpp but my question was about PhaseIdealLoop::build_and_optimize(). Do we need any change at all in this method or could existing gc api points be used instead? >> In fixup_uses_in_catch() wouldn't you need to deal with phis the way you >> do in call_catch_cleanup_one(): >> >> 1019 // We found no single catchproj that dominated the use - The use is at a point after >> 1020 // where control flow from multiple catch projs have merged. We will have to create >> 1021 // phi nodes before the use and tie the output from the cloned loads together. It >> 1022 // can be a single phi or a number of chained phis, depending on control flow > > No - it's a two step process. > > There is a load hanging off a call with multiple catch projs. (There can > be no other control-flow in between.) The load have uses, either (1) in > the catch blocks, or (2) in some cases in the call block, hanging off > the load. > > fixup_uses_in_catch responsibility is to turn (2) into (1). It clones > all uses of the load, in the call block, out to the catch blocks. This > is done recursively. There can never be any phis here. Ok. >> Is there a chance that a load would be processed by >> fixup_uses_in_catch()? I see call_catch_cleanup_one() is where they are >> expected to be handled but you only go there if >> load->is_barrier_required() is true. So could you have a load for which >> is_barrier_required() is true have a use for which is_barrier_required() >> is not true and both of them be in the catch block? > > In theory yes. If the load without a barrier is a use of the load with a > barrier, it would be processed first. When the load with a barrier is > processed, it would clone the load without a barrier, like any other node. If I understand the logic right, in the case, that load would be cloned as many times as there are uses. But couldn't there be multiple uses in a control flow path causing a load to be executed multiple times which would be in violation of the java memory model? Roland. From rwestrel at redhat.com Mon Jun 3 08:51:12 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 03 Jun 2019 10:51:12 +0200 Subject: RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded In-Reply-To: <20bc16d4-b1a0-612e-3af9-287c2fcbc7f0@redhat.com> References: <877eailvgp.fsf@redhat.com> <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com> <87v9xn9lcy.fsf@redhat.com> <20bc16d4-b1a0-612e-3af9-287c2fcbc7f0@redhat.com> Message-ID: <87h8979hmn.fsf@redhat.com> >> So worse case, correctness is not affected but code quality can be. > > In general? Or only in offset==0 case? In general. I understand Dean's question as being a general question. Roland. From rkennke at redhat.com Mon Jun 3 09:03:29 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 3 Jun 2019 11:03:29 +0200 Subject: RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded In-Reply-To: <87h8979hmn.fsf@redhat.com> References: <877eailvgp.fsf@redhat.com> <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com> <87v9xn9lcy.fsf@redhat.com> <20bc16d4-b1a0-612e-3af9-287c2fcbc7f0@redhat.com> <87h8979hmn.fsf@redhat.com> Message-ID: <5829d956-29cd-9783-e91b-dd0da127e9be@redhat.com> >>> So worse case, correctness is not affected but code quality can be. >> >> In general? Or only in offset==0 case? > > In general. I understand Dean's question as being a general question. Yes, sure. My question was, if the code-quality-problem is a general problem, or would only affect offset==0 case, because as I understood, what you changed is set_shared() for offset==0 case too, and other cases have already been covered? Also, besides code-quality, could it affect performance? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From martin.doerr at sap.com Mon Jun 3 09:10:00 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 3 Jun 2019 09:10:00 +0000 Subject: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array with double float literals In-Reply-To: References: Message-ID: Hi Ogata, yes, looks good. Thanks for fixing. Martin > -----Original Message----- > From: Kazunori Ogata > Sent: Montag, 3. Juni 2019 06:21 > To: Volker Simonis ; Doerr, Martin > > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array with > double float literals > > Hi Volker and Martin, > > Is the updated webrev good? > > > Regards, > Ogata > > Kazunori Ogata/Japan/IBM wrote on 2019/05/29 14:16:12: > > > From: Kazunori Ogata/Japan/IBM > > To: "hotspot-compiler-dev at openjdk.java.net" > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > dev at openjdk.java.net>, Volker Simonis , > "Doerr, > > Martin" > > Date: 2019/05/29 14:16 > > Subject: Re: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array > > > with double float literals > > > > Hi Volker and Martin, > > > > Thank you for your comment. I updated the webrev. > > > > http://cr.openjdk.java.net/~horii/8224090/webrev.01/ > > > > Regards, > > Ogata > > > > "Doerr, Martin" wrote on 2019/05/28 23:04:15: > > > > > From: "Doerr, Martin" > > > To: Volker Simonis , Kazunori Ogata > > > > Cc: "hotspot-compiler-dev at openjdk.java.net" > > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > > dev at openjdk.java.net> > > > Date: 2019/05/28 23:08 > > > Subject: RE: RFR: 8224090: [PPC64] Fix SLP patterns for filling > > > an array with double float literals > > > > > > Right, this needs to get changed. > > > > > > Best regards, > > > Martin > > > > > > > -----Original Message----- > > > > From: Volker Simonis > > > > Sent: Dienstag, 28. Mai 2019 15:04 > > > > To: Kazunori Ogata > > > > Cc: Doerr, Martin ; hotspot-compiler- > > > > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > > > Subject: Re: RFR: 8224090: [PPC64] Fix SLP patterns for filling an > array with > > > > double float literals > > > > > > > > Hi Ogata, > > > > > > > > you change looks good, but you should use "jlong_cast()" in the > > > > "immD_0()" operand. > > > > > > > > Thank you and best regards, > > > > Volker > > > > > > > > > > > > On Tue, May 28, 2019 at 12:26 PM Kazunori Ogata > > > > > wrote: > > > > > > > > > > Hi Martin, > > > > > > > > > > Thank you for your review. > > > > > > > > > > Regards, > > > > > Ogata > > > > > > > > > > "Doerr, Martin" wrote on 2019/05/28 > 18:21:29: > > > > > > > > > > > From: "Doerr, Martin" > > > > > > To: Kazunori Ogata , "hotspot-compiler- > > > > > > dev at openjdk.java.net" dev at openjdk.java.net>, > > > > "ppc-aix- > > > > > > port-dev at openjdk.java.net" dev at openjdk.java.net> > > > > > > Date: 2019/05/28 18:21 > > > > > > Subject: [EXTERNAL] RE: RFR: 8224090: [PPC64] Fix SLP patterns > for > > > > > filling > > > > > > an array with double float literals > > > > > > > > > > > > Hi Ogata, > > > > > > > > > > > > looks good. Thanks for fixing. > > > > > > > > > > > > Best regards, > > > > > > Martin > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hotspot-compiler-dev > > > > > > bounces at openjdk.java.net> On Behalf Of Kazunori Ogata > > > > > > > Sent: Freitag, 17. Mai 2019 07:34 > > > > > > > To: hotspot-compiler-dev at openjdk.java.net; ppc-aix-port- > > > > > > > dev at openjdk.java.net > > > > > > > Subject: RFR: 8224090: [PPC64] Fix SLP patterns for filling an > array > > > > > with double > > > > > > > float literals > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > May I get review for a webrev to fix SLP patterns that use > PPC64 VSX > > > > > > > instructions? > > > > > > > > > > > > > > We found that SLP patterns added by JDK-8208171 [1] use > incorrect > > > > data > > > > > > > type, so the patterns have never been used. Further, the > pattern for > > > > > > > filling -1.0 is confused with the operation for filling -1L. > > > > > > > > > > > > > > This webrev fixes the pattern to fill an array with 0 to use > 0.0d > > > > > instead > > > > > > > of 0d, and removes the pattern to will with -1 because the bit > pattern > > > > > of > > > > > > > -1.0d is not easy to generate using a single VSX instruction. > It's > > > > > should > > > > > > > be better to load the literal from TOC and use general > repl2D_reg_Ex > > > > > > > pattern. > > > > > > > > > > > > > > I also fixed some comments in "format %{ ... %}" to show > correct > > > > > matching > > > > > > > types. > > > > > > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224090 > > > > > > > > > > > > > > Webrev: http://cr.openjdk.java.net/~horii/8224090/webrev.00/ > > > > > > > > > > > > > > Ref: > > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8208171 > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Ogata > > > > > > > > > > > > > > > > > > > > > > > > > > From rwestrel at redhat.com Mon Jun 3 09:11:08 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 03 Jun 2019 11:11:08 +0200 Subject: RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded In-Reply-To: <5829d956-29cd-9783-e91b-dd0da127e9be@redhat.com> References: <877eailvgp.fsf@redhat.com> <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com> <87v9xn9lcy.fsf@redhat.com> <20bc16d4-b1a0-612e-3af9-287c2fcbc7f0@redhat.com> <87h8979hmn.fsf@redhat.com> <5829d956-29cd-9783-e91b-dd0da127e9be@redhat.com> Message-ID: <87ef4b9gpf.fsf@redhat.com> > Yes, sure. My question was, if the code-quality-problem is a general > problem, or would only affect offset==0 case, because as I understood, > what you changed is set_shared() for offset==0 case too, and other cases > have already been covered? To be clear, there's no code quality or performance problem unless there's a bug in the change I propose. What it does as far I understand is simply extend the current behavior for LoadN to LoadN at offset 0. Now if I'm wrong it could introduce a code quality/performance regression that could affect all LoadN, not only those at offset 0. Roland. From rkennke at redhat.com Mon Jun 3 09:27:54 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 3 Jun 2019 11:27:54 +0200 Subject: RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded In-Reply-To: <87ef4b9gpf.fsf@redhat.com> References: <877eailvgp.fsf@redhat.com> <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com> <87v9xn9lcy.fsf@redhat.com> <20bc16d4-b1a0-612e-3af9-287c2fcbc7f0@redhat.com> <87h8979hmn.fsf@redhat.com> <5829d956-29cd-9783-e91b-dd0da127e9be@redhat.com> <87ef4b9gpf.fsf@redhat.com> Message-ID: <9c7e87df-7e23-4773-57c9-3dd3286905bc@redhat.com> >> Yes, sure. My question was, if the code-quality-problem is a general >> problem, or would only affect offset==0 case, because as I understood, >> what you changed is set_shared() for offset==0 case too, and other cases >> have already been covered? > > To be clear, there's no code quality or performance problem unless > there's a bug in the change I propose. What it does as far I understand > is simply extend the current behavior for LoadN to LoadN at offset > 0. Now if I'm wrong it could introduce a code quality/performance > regression that could affect all LoadN, not only those at offset 0. Ah ok. Thanks for the clarification. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From OGATAK at jp.ibm.com Mon Jun 3 10:18:01 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Mon, 3 Jun 2019 19:18:01 +0900 Subject: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array with double float literals In-Reply-To: References: Message-ID: Hi Martin, Thank you for your review. Regards, Ogata "Doerr, Martin" wrote on 2019/06/03 18:10:00: > From: "Doerr, Martin" > To: Kazunori Ogata , Volker Simonis > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, "hotspot-compiler-dev at openjdk.java.net" compiler-dev at openjdk.java.net> > Date: 2019/06/03 18:10 > Subject: [EXTERNAL] RE: RFR: 8224090: [PPC64] Fix SLP patterns for filling > an array with double float literals > > Hi Ogata, > > yes, looks good. Thanks for fixing. > > Martin > > > > -----Original Message----- > > From: Kazunori Ogata > > Sent: Montag, 3. Juni 2019 06:21 > > To: Volker Simonis ; Doerr, Martin > > > > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-compiler- > > dev at openjdk.java.net > > Subject: Re: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array with > > double float literals > > > > Hi Volker and Martin, > > > > Is the updated webrev good? > > > > > > Regards, > > Ogata > > > > Kazunori Ogata/Japan/IBM wrote on 2019/05/29 14:16:12: > > > > > From: Kazunori Ogata/Japan/IBM > > > To: "hotspot-compiler-dev at openjdk.java.net" > > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > > > dev at openjdk.java.net>, Volker Simonis , > > "Doerr, > > > Martin" > > > Date: 2019/05/29 14:16 > > > Subject: Re: RFR: 8224090: [PPC64] Fix SLP patterns for filling an array > > > > > with double float literals > > > > > > Hi Volker and Martin, > > > > > > Thank you for your comment. I updated the webrev. > > > > > > http://cr.openjdk.java.net/~horii/8224090/webrev.01/ > > > > > > Regards, > > > Ogata > > > > > > "Doerr, Martin" wrote on 2019/05/28 23:04:15: > > > > > > > From: "Doerr, Martin" > > > > To: Volker Simonis , Kazunori Ogata > > > > > > Cc: "hotspot-compiler-dev at openjdk.java.net" > > > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > > > > dev at openjdk.java.net> > > > > Date: 2019/05/28 23:08 > > > > Subject: RE: RFR: 8224090: [PPC64] Fix SLP patterns for filling > > > > an array with double float literals > > > > > > > > Right, this needs to get changed. > > > > > > > > Best regards, > > > > Martin > > > > > > > > > -----Original Message----- > > > > > From: Volker Simonis > > > > > Sent: Dienstag, 28. Mai 2019 15:04 > > > > > To: Kazunori Ogata > > > > > Cc: Doerr, Martin ; hotspot-compiler- > > > > > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > > > > Subject: Re: RFR: 8224090: [PPC64] Fix SLP patterns for filling an > > array with > > > > > double float literals > > > > > > > > > > Hi Ogata, > > > > > > > > > > you change looks good, but you should use "jlong_cast()" in the > > > > > "immD_0()" operand. > > > > > > > > > > Thank you and best regards, > > > > > Volker > > > > > > > > > > > > > > > On Tue, May 28, 2019 at 12:26 PM Kazunori Ogata > > > > > > > wrote: > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Thank you for your review. > > > > > > > > > > > > Regards, > > > > > > Ogata > > > > > > > > > > > > "Doerr, Martin" wrote on 2019/05/28 > > 18:21:29: > > > > > > > > > > > > > From: "Doerr, Martin" > > > > > > > To: Kazunori Ogata , "hotspot-compiler- > > > > > > > dev at openjdk.java.net" > dev at openjdk.java.net>, > > > > > "ppc-aix- > > > > > > > port-dev at openjdk.java.net" > dev at openjdk.java.net> > > > > > > > Date: 2019/05/28 18:21 > > > > > > > Subject: [EXTERNAL] RE: RFR: 8224090: [PPC64] Fix SLP patterns > > for > > > > > > filling > > > > > > > an array with double float literals > > > > > > > > > > > > > > Hi Ogata, > > > > > > > > > > > > > > looks good. Thanks for fixing. > > > > > > > > > > > > > > Best regards, > > > > > > > Martin > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hotspot-compiler-dev > > > > > > > bounces at openjdk.java.net> On Behalf Of Kazunori Ogata > > > > > > > > Sent: Freitag, 17. Mai 2019 07:34 > > > > > > > > To: hotspot-compiler-dev at openjdk.java.net; ppc-aix-port- > > > > > > > > dev at openjdk.java.net > > > > > > > > Subject: RFR: 8224090: [PPC64] Fix SLP patterns for filling an > > array > > > > > > with double > > > > > > > > float literals > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > May I get review for a webrev to fix SLP patterns that use > > PPC64 VSX > > > > > > > > instructions? > > > > > > > > > > > > > > > > We found that SLP patterns added by JDK-8208171 [1] use > > incorrect > > > > > data > > > > > > > > type, so the patterns have never been used. Further, the > > pattern for > > > > > > > > filling -1.0 is confused with the operation for filling -1L. > > > > > > > > > > > > > > > > This webrev fixes the pattern to fill an array with 0 to use > > 0.0d > > > > > > instead > > > > > > > > of 0d, and removes the pattern to will with -1 because the bit > > pattern > > > > > > of > > > > > > > > -1.0d is not easy to generate using a single VSX instruction. > > It's > > > > > > should > > > > > > > > be better to load the literal from TOC and use general > > repl2D_reg_Ex > > > > > > > > pattern. > > > > > > > > > > > > > > > > I also fixed some comments in "format %{ ... %}" to show > > correct > > > > > > matching > > > > > > > > types. > > > > > > > > > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224090 > > > > > > > > > > > > > > > > Webrev: http://cr.openjdk.java.net/~horii/8224090/webrev.00/ > > > > > > > > > > > > > > > > Ref: > > > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8208171 > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Ogata > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From adinn at redhat.com Mon Jun 3 13:17:25 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 3 Jun 2019 14:17:25 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> Message-ID: <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> Hi Vladimir, Thanks for the follow-up and for checking the submit failure. I have addressed all the points you raised (point by point comments are included below). A new webrev which passes a submit run is here: http://cr.openjdk.java.net/~adinn/8224974/webrev.04 n.b. This webrev also includes changes to the javadoc for ExtendedMapMode suggested by Alan Bateman. regards, Andrew Dinn ----------- On 30/05/2019 17:58, Vladimir Kozlov wrote: > On 5/30/19 9:08 AM, Andrew Dinn wrote: >> I have uploaded a new webrev which attempts to address the problem. >> >> ?? http://cr.openjdk.java.net/~adinn/8224974/webrev.03 > > I looked only on HotSpot code. Sure, thank you. > stubGenerator_x86_64.cpp - in generate_data_cache_writeback() next are > not used: > > +??? bool optimized = VM_Version::supports_clflushopt(); > +??? bool no_evict = VM_Version::supports_clwb(); Yes. I have removed them. > vm_version_x86.hpp it should check CPUID flag in 32-bit: > > +#else > +? static bool supports_clflush() { return true; } I have added a new feature flag CPU_FLUSH, which is set conditional on the cpuid1 edx bit being set. The 32-bit version of supports_clflush() test for the presence of this feature. The 64-bit version always returns true. On 64-bit I still set the feature flag (unconditionally) even though it is not used. I prefer the loss of 1-2 cycles to the risk of surprising someone looking at the feature bits in a debugger. > We don't check has_match_rule() in LibraryCallKit any more. > In .ad files you need to add predicate to new insrtructions: > > ? predicate(VM_Version::supports_data_cache_line_flush()); Ok, done. > Also add this check to Matcher::match_rule_supported() which you can use > then in C2Compiler::is_intrinsic_supported(). Yes, this is much better. Done. > DISABLE_UNSAFE_WRITEBACK_INTRINSIC should be checked much early may be > together with os::supports_map_sync() when you set > _data_cache_line_flush_size. Doing that that would change the behaviour. If I push the check down into the VM_Version code as you suggest then that will disable map and writeback operations as well as the JIT intrinsic. This test was used to allow the benefit of the intrinsic to be measured. However, I don't think it is worth worrying about retaining this test. It was useful during development but is probably not going to be needed any more. So, I have removed it. >> Unfortunately, this latest webrev still fails when uploaded to the >> submit repo. ... > > ?t:/workspace/open/src/java.base/windows/native/libnio/ch/FileChannelImpl.c(64): > error C2220: warning treated as error - no 'object' file generated > ?t:/workspace/open/src/java.base/windows/native/libnio/ch/FileChannelImpl.c(64): > warning C4029: declared formal parameter list different from definition Ah, got it. The change to handle the isSync argument to map0 needs propagating to the Windows native implementation. Also, I tweaked the Windows C code to throw InternalError if mapSync is ever passed as true. That /should never happen/ in the current implementation. If/when this gets ported to Windows then the code that does the throw can be replaced with case handling to call mmap with MAP_SYNC. From vladimir.x.ivanov at oracle.com Mon Jun 3 13:55:03 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 3 Jun 2019 16:55:03 +0300 Subject: RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached In-Reply-To: <1e559921-8d8c-177a-c301-429bc657053a@loongson.cn> References: <282b2c79-1ce0-95bb-c37a-d151edcc02f4@oracle.com> <03736619-e07f-e33c-635b-5e8d722d0142@loongson.cn> <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn> <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com> <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com> <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn> <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com> <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com> <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn> <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn> <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn> <1e559921-8d8c-177a-c301-429bc657053a@loongson.cn> Message-ID: <26ee82f6-ffb4-6ce6-daad-fcfc85ef293a@oracle.com> FYI there was a new failure in compiler/unsafe/UnsafeGetConstantField spotted on solaris-sparcv9. I'm looking into it and let you know about my findings. Best regards, Vladimir Ivanov On 01/06/2019 04:37, Jie Fu wrote: > Hi Vladimir Ivanov, > > Thanks for your review and suggestions. > Updated: http://cr.openjdk.java.net/~jiefu/8224162/webrev.10/ > > Thanks a lot. > Best regards, > Jie > > On 2019/6/1 ??5:47, Vladimir Ivanov wrote: >> +template >> +int ciMethod::saturated_add(L a, R b) { >> >> What do you think about moving it to globalDefinitions.hpp? >> >> Probably, it's worth getting rid of the template parameters and >> introduce specializations (akin to JAVA_INTEGER_OP) since the >> implementation makes sense only for int/uint. > It seems cool. I like this style. >> >> +? jlong sum? = src1 + src2; >> I'd prefer to see explicit casts to jlong to stress there's no >> overflow possible here for 32-bit values. >> > Done >> >> +??? return c < 0 ? max_jint : c; >> +????? case Bytecodes::_instanceof: return c > 0 ? min_jint : c; >> >> Please, put parentheses around ternary expressions. >> > Done > > From vladimir.x.ivanov at oracle.com Mon Jun 3 13:58:37 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 3 Jun 2019 16:58:37 +0300 Subject: RFR(M): 8224827: Implement fast class initialization checks on s390 In-Reply-To: References: Message-ID: <41e14f2c-21b5-3807-ee13-9b7e97cf23a6@oracle.com> Hi Martin, I'm not an expert in s390 assembly, but the patch looks reasonable. Glad to see s390 and ppc64 ports follow with fast class init checks. Best regards, Vladimir Ivanov On 31/05/2019 18:54, Doerr, Martin wrote: > Hi, > > please review the s390 implementation of JDK-8223213: > > http://cr.openjdk.java.net/~mdoerr/8224827_s390_fast_clinit/webrev.00/ > > x86 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9ad765641e8f > > Best regards, > > Martin > From vladimir.x.ivanov at oracle.com Mon Jun 3 13:58:52 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 3 Jun 2019 16:58:52 +0300 Subject: RFR(M): 8224826: Implement fast class initialization checks on PPC64 In-Reply-To: References: Message-ID: <60f90571-fccb-52e9-9742-eae7d6669157@oracle.com> I'm not an expert in ppc64 assembly, but the patch looks reasonable. Best regards, Vladimir Ivanov On 31/05/2019 18:54, Doerr, Martin wrote: > Hi, > > please review the PPC64 implementation of JDK-8223213: > http://cr.openjdk.java.net/~mdoerr/8224826_ppc64_fast_clinit/webrev.00/ > > x86 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9ad765641e8f > > Best regards, > Martin > From adinn at redhat.com Mon Jun 3 14:37:58 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 3 Jun 2019 15:37:58 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> Message-ID: On 03/06/2019 14:17, Andrew Dinn wrote: > Hi Vladimir, > > Thanks for the follow-up and for checking the submit failure. I have > addressed all the points you raised (point by point comments are > included below). A new webrev which passes a submit run is here: > > http://cr.openjdk.java.net/~adinn/8224974/webrev.04 > > n.b. This webrev also includes changes to the javadoc for > ExtendedMapMode suggested by Alan Bateman. . . . I have made one further change to locate the new ExtendedMapMode enum in module jdk.nio.mapmode and package jdk.nio.mapmode as suggested offline by Alan Bateman and the OpenJDK lead. Please refer to this webrev instead: webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.05 The CSR and JEP have been updated accordingly CSR: https://bugs.openjdk.java.net/browse/JDK-8224975 JEP: https://bugs.openjdk.java.net/browse/JDK-8207851 regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martin.doerr at sap.com Mon Jun 3 14:50:55 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 3 Jun 2019 14:50:55 +0000 Subject: [13] RFR (S): 8225106: C2: Parse::clinit_deopt asserts when holder klass is in error state In-Reply-To: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com> References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com> Message-ID: Hi Vladimir, thanks for addressing this issue so quickly. The new assertions look correct to me. Would "initializion_not_started" be a better name? I'd rather use Unimplemented() in MacroAssembler::clinit_barrier when both labels are provided, because this case is not used and doesn't look very useful. But you can keep what you have if you prefer that. I think the "assert(VM_Version::supports_fast_class_init_checks(), ..." are pointless in platform files. Would you like to keep them? Thanks for improving the test. Seems like you currently expect a wrong exception: Execution failed: `main' threw exception: java.lang.AssertionError: INIT_FAILURE: unexpected exception thrown: expected java.lang.NoClassDefFoundError, caught java.lang.AssertionError Also thank you for looking at my PPC64 and s390 implementations. I'll rebase and update them after this change is pushed. Best regards, Martin > -----Original Message----- > From: Vladimir Ivanov > Sent: Freitag, 31. Mai 2019 22:15 > To: hotspot compiler > Cc: Doerr, Martin > Subject: [13] RFR (S): 8225106: C2: Parse::clinit_deopt asserts when holder > klass is in error state > > http://cr.openjdk.java.net/~vlivanov/8225106/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8225106 > > Some asserts introduced as part of JDK-8223213 [1] don't take into > account the case when the class which participates in class > intialization barrier is in error state (class initialization failed > with an exception). > > Proposed fix adjusts the asserts, plus slightly improves handling of > cases when classes in error state are encountered. > > Testing: hs-precheckin-comp, tier1-4 > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8223213 From ekaterina.pavlova at oracle.com Mon Jun 3 20:37:14 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Mon, 3 Jun 2019 13:37:14 -0700 Subject: RFR (T/XXS) 8225199: [Graal] compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java fails with -XX:CompileThresholdScaling=0.1 Message-ID: <9c026f52-9d62-da26-9074-f5d528f8d567@oracle.com> Hi, compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java started to fail in Graal as JIT mode after switching -Xcomp testing configuration to -XX:CompileThresholdScaling=0.1 configuration. The test is sensitive to this setting. As suggested by Vladimir the fix is to return default value for CompileThresholdScaling back by adding -XX:CompileThresholdScaling=1.0 flag. Please review this tiny fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8225199 webrev: http://cr.openjdk.java.net/~epavlova//8225199/webrev.00/index.html thanks, -katya From vladimir.kozlov at oracle.com Mon Jun 3 21:00:15 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 3 Jun 2019 14:00:15 -0700 Subject: RFR (T/XXS) 8225199: [Graal] compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java fails with -XX:CompileThresholdScaling=0.1 In-Reply-To: <9c026f52-9d62-da26-9074-f5d528f8d567@oracle.com> References: <9c026f52-9d62-da26-9074-f5d528f8d567@oracle.com> Message-ID: <587bc98f-b684-8b50-16c3-47d65c5f3de4@oracle.com> Good. Thanks, Vladimir On 6/3/19 1:37 PM, Ekaterina Pavlova wrote: > Hi, > > compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java started to fail in Graal as JIT mode after switching -Xcomp > testing configuration to -XX:CompileThresholdScaling=0.1 configuration. The test is sensitive to this setting. > As suggested by Vladimir the fix is to return default value for CompileThresholdScaling back by adding > -XX:CompileThresholdScaling=1.0 flag. > > Please review this tiny fix. > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8225199 > ?webrev: http://cr.openjdk.java.net/~epavlova//8225199/webrev.00/index.html > > thanks, > -katya From igor.veresov at oracle.com Mon Jun 3 21:09:08 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 3 Jun 2019 14:09:08 -0700 Subject: RFR(XS) 8225202: Add missing include after JDK-8223320 Message-ID: <6096616E-C8A3-4505-85E0-57EAABA87AB9@oracle.com> Webrev: http://cr.openjdk.java.net/~iveresov/8225202/webrev.00/ Thanks! igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Jun 3 21:14:34 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 3 Jun 2019 14:14:34 -0700 Subject: RFR(XS) 8225202: Add missing include after JDK-8223320 In-Reply-To: <6096616E-C8A3-4505-85E0-57EAABA87AB9@oracle.com> References: <6096616E-C8A3-4505-85E0-57EAABA87AB9@oracle.com> Message-ID: <9dfca48f-f400-85ce-6e4c-638e5c20db67@oracle.com> Looks good. Thanks, Vladimir On 6/3/19 2:09 PM, Igor Veresov wrote: > Webrev: http://cr.openjdk.java.net/~iveresov/8225202/webrev.00/ > > Thanks! > igor > > > From gromero at linux.vnet.ibm.com Mon Jun 3 21:35:23 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 3 Jun 2019 18:35:23 -0300 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> Message-ID: <8a2de9b7-adfa-786e-1088-fe06f7eb781d@linux.vnet.ibm.com> Hi, On 05/30/2019 04:10 AM, Kazunori Ogata wrote: > Since it looks there is no further objection, I added jdk8u-fix-request > tag in the original bug report. Thanks for backporting it, Ogata! Martin and Andrew, thanks a lot for reviewing it. Pushed to jdk8u-dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/846245a33793 Best regards, Gustavo From dean.long at oracle.com Mon Jun 3 21:55:04 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 3 Jun 2019 14:55:04 -0700 Subject: Questions around codeheaps, codeblobs and code locality In-Reply-To: References: Message-ID: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> I wonder if something like -XX:+UseTransparentHugePages would help with the iTLB issue. dl On 6/3/19 12:14 PM, keita abdoul-kader wrote: > Hello, > > I have been looking into the code cache layout and ways to reduce the high > amount of iTLB we are observing on some of our workloads. It seems that > after the works on segmented codeHeaps, the plan was to add support for non > contiguous codeBlobs as the next step to improve code locality in the code > cache. is the work on non contiguous codeBlobs still active ? > > Also, does the hotspot has support for any form of code compaction ? > Compacting the code heap is mentioned in one of the comment in > relocInfo.hpp, but browsing the source code it seems that once the > codeBlobs is filled with the content of a codeBuffer, they are never moved > in a way to reduce codeheap fragmentation. > > In general, is there an umbrella project or a set of open task around > improving code locality ? Please note that most of my observation driving > this come from spark-sql workloads. Since spark-sql generates dynamically > generate a lots of code, i might simply be observing a pathological case. > > Thanks From vladimir.kozlov at oracle.com Tue Jun 4 01:18:15 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 3 Jun 2019 18:18:15 -0700 Subject: deoptimization.cpp Events::log / Events::log_deopt_message - was : RE: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: Message-ID: log_deopt_message() is used for crashes to list these events in hs_err file: https://bugs.openjdk.java.net/browse/JDK-7141200 Vladimir On 5/23/19 4:16 AM, Baesken, Matthias wrote: > Hello, could please someone comment on the Events::log / Events::log_deopt_message calls in deoptimization.cpp , should they better all > Go to the depot log ( Events::log_deopt_message ) ? > > Best regards, Matthias > >>> >>> Btw when looking into the other already present Events::log* calls I wondered about this : >>> In deoptimization.cpp , there are 3 calls to Events:log, like >>> >>> Events::log(thread, "DEOPT UNPACKING pc=" INTPTR_FORMAT " sp=" >> INTPTR_FORMAT " mode %d", >>> p2i(stub_frame.pc()), p2i(stub_frame.sp()), exec_mode); >>> >>> But just one Events::log_deopt_message >>> >>> Events::log_deopt_message(thread, "Uncommon trap: reason=%s >> action=%s pc=" INTPTR_FORMAT " method=%s @ %d %s", >>> trap_reason_name(reason), trap_action_name(action), >> p2i(fr.pc()), >>> trap_method->name_and_sig_as_C_string(), trap_bci, nm- >>> compiler_name()); >>> >>> I think all 4 messages should go to the separate deoptimization - log and use Events::log_deopt_message. >>> Or is there a special intentation why some go into the depot-log (Events::log_deopt_message ) and some into the general events log (Events::log) ? >> >> I have no idea sorry. Best to open an issue and/or discuss this with the >> compiler folk. >> > From OGATAK at jp.ibm.com Tue Jun 4 04:18:07 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 4 Jun 2019 13:18:07 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <8a2de9b7-adfa-786e-1088-fe06f7eb781d@linux.vnet.ibm.com> References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> <8a2de9b7-adfa-786e-1088-fe06f7eb781d@linux.vnet.ibm.com> Message-ID: Hi Gustavo, Thank you for sponsoring it! Regards, Ogata "Gustavo Romero" wrote on 2019/06/04 06:35:23: > From: "Gustavo Romero" > To: Kazunori Ogata/Japan/IBM at IBMJP > Cc: "hotspot-compiler-dev at openjdk.java.net" dev at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" dev at openjdk.java.net>, "Doerr, Martin" , "Andrew > Hughes" > Date: 2019/06/04 06:35 > Subject: Re: [8u-dev, ppc] RFR for (almost clean) backport of 8185969: > PPC64: Improve VSR support to use up to 64 registers > > Hi, > > On 05/30/2019 04:10 AM, Kazunori Ogata wrote: > > Since it looks there is no further objection, I added jdk8u-fix-request > > tag in the original bug report. > > Thanks for backporting it, Ogata! > > Martin and Andrew, thanks a lot for reviewing it. > > Pushed to jdk8u-dev: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/846245a33793 > > Best regards, > Gustavo From per.liden at oracle.com Tue Jun 4 08:51:45 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 4 Jun 2019 10:51:45 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <5a262187-a9e5-0057-2904-487d0b034712@oracle.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <5a262187-a9e5-0057-2904-487d0b034712@oracle.com> Message-ID: <5582ca3e-8354-06fb-7185-f24a48f947f5@oracle.com> fixup_partial_loads() still appears in zHeap.hpp. diff --git a/src/hotspot/share/gc/z/zHeap.hpp b/src/hotspot/share/gc/z/zHeap.hpp --- a/src/hotspot/share/gc/z/zHeap.hpp +++ b/src/hotspot/share/gc/z/zHeap.hpp @@ -77,7 +77,6 @@ void flip_to_remapped(); void out_of_memory(); - void fixup_partial_loads(); public: static ZHeap* heap(); /Per On 5/29/19 4:54 PM, Nils Eliasson wrote: > Latest webrev uploaded with all the fixes you suggested: > > http://cr.openjdk.java.net/~neliasso/8224675/webrev.03/ > > Regards, > > Nils > > > On 2019-05-29 14:18, Nils Eliasson wrote: >> Hi Roland, >> >> On 2019-05-29 09:48, Roland Westrelin wrote: >>> Hi Nils, >>> >>>> Webrev: http://cr.openjdk.java.net/~neliasso/8224675/webrev.01/ >>> zBarrierSetC2.cpp: typo loadbarrers line 756 >> Fixed >>> lcm.cpp: >>> >>> void PhaseCFG:: call_catch_cleanup(Block* block) { >>> >>> space after ::? >> Fixed >>> >>> loopnode.cpp: >>> >>> Node *u >>> >>> I thought the usually recommended style was: >>> >>> Node* u >> Yes. >>> loopnode.cpp: >>> >>> Do we really need a new entry in the gc api for barrier_insertion() >>> couldn't this go under optimize_loops()? >> >> It could. There is only remove_range_check_casts in between right now. >> I choose to have it as its own for separation, in a similar way to how >> LoopOptsNone are used. >> >> >>> memnode.hpp: >>> >>> ? 168?? enum LoadBarrier { >>> ? 169???? UnProcessed???? = 0, >>> ? 170???? RequireBarrier? = 1, >>> ? 171???? WeakBarrier???? = 3,? // Inclusive with RequireBarrier >>> ? 172???? ExpandedBarrier = 4 >>> ? 173?? }; >>> >>> Shouldn't that be abstracted away through the gc api somehow? >> >> Yes. >> >> I would have preferred using the node-flags, but they are all taken >> unless we expand it to 32 bits, or overload the flags that are only >> used during codegen and later. That would require some verification of >> the flag use to catch any mistakes. >> >>> >>> zBarrierSetC2.cpp: >>> >>> typo (witch): >>> >>> 981???? // For each load use, see witch catch projs dominates, create >>> load clone lazily and reconnect >> Fixed >>> >>> In fixup_uses_in_catch() wouldn't you need to deal with phis the way you >>> do in call_catch_cleanup_one(): >>> >>> 1019???? // We found no single catchproj that dominated the use - The >>> use is at a point after >>> 1020???? // where control flow from multiple catch projs have merged. >>> We will have to create >>> 1021???? // phi nodes before the use and tie the output from the >>> cloned loads together. It >>> 1022???? // can be a single phi or a number of chained phis, >>> depending on control flow >> >> No - it's a two step process. >> >> There is a load hanging off a call with multiple catch projs. (There >> can be no other control-flow in between.) The load have uses, either >> (1) in the catch blocks, or (2) in some cases in the call block, >> hanging off the load. >> >> fixup_uses_in_catch responsibility is to turn (2) into (1). It clones >> all uses of the load, in the call block, out to the catch blocks. This >> is done recursively. There can never be any phis here. >> >> >>> Is there a chance that a load would be processed by >>> fixup_uses_in_catch()? I see call_catch_cleanup_one() is where they are >>> expected to be handled but you only go there if >>> load->is_barrier_required() is true. So could you have a load for which >>> is_barrier_required() is true have a use for which is_barrier_required() >>> is not true and both of them be in the catch block? >> >> In theory yes. If the load without a barrier is a use of the load with >> a barrier, it would be processed first. When the load with a barrier >> is processed, it would clone the load without a barrier, like any >> other node. >> >> Another case is two loads that both require a barrier. One would be >> processed first, that one can't have the other one as a use, because >> the loads are processed in post order. And when the other load is >> processed, the first has already been cloned out. >> >> Thanks for the feedback! >> >> I'll get back with a new webrev. >> >> // Nils >> >>> >>> Roland. From vladimir.x.ivanov at oracle.com Tue Jun 4 09:31:00 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 4 Jun 2019 12:31:00 +0300 Subject: [13] RFR (S): 8225106: C2: Parse::clinit_deopt asserts when holder klass is in error state In-Reply-To: References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com> Message-ID: <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com> Thanks, Martin. > The new assertions look correct to me. Would "initializion_not_started" be a better name? Probably, but ciInstanceKlass::is_not_initialized() mirrors existing InstanceKlass::is_not_initialized(). So either both should be renamed or left as is. > I'd rather use Unimplemented() in MacroAssembler::clinit_barrier when both labels are provided, because this case is not used and doesn't look very useful. But you can keep what you have if you prefer that. Agree. I'll switch to Unimplemented() before pushing. > I think the "assert(VM_Version::supports_fast_class_init_checks(), ..." are pointless in platform files. Would you like to keep them? Yes, I'd like to leave them as is. In x86_64.ad it doesn't look completely redundant: if (C->clinit_barrier_on_entry()) { assert(VM_Version::supports_fast_class_init_checks(), "sanity"); Moreover, c1_LIRAssembler_x86.cpp is shared between 32-bit & 64-bit ports and 32-bit port lacks fast clinit checks. > Thanks for improving the test. Seems like you currently expect a wrong exception: > Execution failed: `main' threw exception: java.lang.AssertionError: INIT_FAILURE: unexpected exception thrown: expected java.lang.NoClassDefFoundError, caught java.lang.AssertionError More like the error message is a bit misleading: the failure is caused by a bug which is addressed by JDK-8225141 [1]. Would providing exception message improve the situation? > Also thank you for looking at my PPC64 and s390 implementations. I'll rebase and update them after this change is pushed. Sounds good. Best regards, Vladimir Ivanov [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/034062.html >> -----Original Message----- >> From: Vladimir Ivanov >> Sent: Freitag, 31. Mai 2019 22:15 >> To: hotspot compiler >> Cc: Doerr, Martin >> Subject: [13] RFR (S): 8225106: C2: Parse::clinit_deopt asserts when holder >> klass is in error state >> >> http://cr.openjdk.java.net/~vlivanov/8225106/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8225106 >> >> Some asserts introduced as part of JDK-8223213 [1] don't take into >> account the case when the class which participates in class >> intialization barrier is in error state (class initialization failed >> with an exception). >> >> Proposed fix adjusts the asserts, plus slightly improves handling of >> cases when classes in error state are encountered. >> >> Testing: hs-precheckin-comp, tier1-4 >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8223213 From martin.doerr at sap.com Tue Jun 4 09:51:32 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 4 Jun 2019 09:51:32 +0000 Subject: [13] RFR (S): 8225106: C2: Parse::clinit_deopt asserts when holder klass is in error state In-Reply-To: <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com> References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com> <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com> Message-ID: Hi Vladimir, > > The new assertions look correct to me. Would "initializion_not_started" be > a better name? > Probably, but ciInstanceKlass::is_not_initialized() mirrors existing > InstanceKlass::is_not_initialized(). So either both should be renamed or > left as is. I think this name is a little bit misleading, because the function implies that the initialization has not even been started. I'd understand "not initialized" rather as "initialization has not completed". I'll leave it up to you and other reviewers if you want to change it. > > I think the "assert(VM_Version::supports_fast_class_init_checks(), ..." are > pointless in platform files. Would you like to keep them? > > Yes, I'd like to leave them as is. > > In x86_64.ad it doesn't look completely redundant: > if (C->clinit_barrier_on_entry()) { > assert(VM_Version::supports_fast_class_init_checks(), "sanity"); > > Moreover, c1_LIRAssembler_x86.cpp is shared between 32-bit & 64-bit > ports and 32-bit port lacks fast clinit checks. Makes sense for files which are shared between 32 and 64 bit. > > Thanks for improving the test. Seems like you currently expect a wrong > exception: > > Execution failed: `main' threw exception: java.lang.AssertionError: > INIT_FAILURE: unexpected exception thrown: expected > java.lang.NoClassDefFoundError, caught java.lang.AssertionError > > More like the error message is a bit misleading: the failure is caused > by a bug which is addressed by JDK-8225141 [1]. Would providing > exception message improve the situation? Thanks for explaining. I'd appreciate a message improvement, but I don't insist on it. Otherwise, change looks good to me. Best regards, Martin From Alan.Bateman at oracle.com Tue Jun 4 10:40:11 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Jun 2019 11:40:11 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> Message-ID: <42909e1f-e235-8f4b-d881-cff556fb7bc2@oracle.com> On 03/06/2019 15:37, Andrew Dinn wrote: > : > > The CSR and JEP have been updated accordingly > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224975 > JEP: https://bugs.openjdk.java.net/browse/JDK-8207851 > The specification section in the CSR was missing the module definition so I added that. The rest looks okay so I've added myself as Reviewer so you can finalize it. -Alan. From rwestrel at redhat.com Tue Jun 4 12:06:57 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 04 Jun 2019 14:06:57 +0200 Subject: RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded In-Reply-To: <9c7e87df-7e23-4773-57c9-3dd3286905bc@redhat.com> References: <877eailvgp.fsf@redhat.com> <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com> <87v9xn9lcy.fsf@redhat.com> <20bc16d4-b1a0-612e-3af9-287c2fcbc7f0@redhat.com> <87h8979hmn.fsf@redhat.com> <5829d956-29cd-9783-e91b-dd0da127e9be@redhat.com> <87ef4b9gpf.fsf@redhat.com> <9c7e87df-7e23-4773-57c9-3dd3286905bc@redhat.com> Message-ID: <87imtlftb2.fsf@redhat.com> I got at least 2 reviews for this (Roman and Nils). Not sure if Dean's comment counts as a review, though. If no one objects in the next 24 hours, I'll push that change. Roland. From abdoulk.keita at gmail.com Tue Jun 4 00:30:47 2019 From: abdoulk.keita at gmail.com (keita abdoul-kader) Date: Mon, 3 Jun 2019 17:30:47 -0700 Subject: Questions around codeheaps, codeblobs and code locality In-Reply-To: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> References: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> Message-ID: Hello dean, We did try -XX:+UseTransparentHugePages in production and saw no performance improvements (although i check if there was a reduction in iTLB misses). Also i should probably note that we are still using java 8 and as such still using the unify/non segmented code cache. On Mon, Jun 3, 2019 at 2:55 PM wrote: > I wonder if something like -XX:+UseTransparentHugePages would help with > the iTLB issue. > > dl > > On 6/3/19 12:14 PM, keita abdoul-kader wrote: > > Hello, > > > > I have been looking into the code cache layout and ways to reduce the > high > > amount of iTLB we are observing on some of our workloads. It seems that > > after the works on segmented codeHeaps, the plan was to add support for > non > > contiguous codeBlobs as the next step to improve code locality in the > code > > cache. is the work on non contiguous codeBlobs still active ? > > > > Also, does the hotspot has support for any form of code compaction ? > > Compacting the code heap is mentioned in one of the comment in > > relocInfo.hpp, but browsing the source code it seems that once the > > codeBlobs is filled with the content of a codeBuffer, they are never > moved > > in a way to reduce codeheap fragmentation. > > > > In general, is there an umbrella project or a set of open task around > > improving code locality ? Please note that most of my observation > driving > > this come from spark-sql workloads. Since spark-sql generates dynamically > > generate a lots of code, i might simply be observing a pathological case. > > > > Thanks > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Tue Jun 4 14:44:50 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 4 Jun 2019 16:44:50 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <87k1e39hno.fsf@redhat.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <87k1e39hno.fsf@redhat.com> Message-ID: <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> On 2019-06-03 10:50, Roland Westrelin wrote: > Hi Nils, > >>> loopnode.cpp: >>> >>> Do we really need a new entry in the gc api for barrier_insertion() >>> couldn't this go under optimize_loops()? >> It could. There is only remove_range_check_casts in between right now. I >> choose to have it as its own for separation, in a similar way to how >> LoopOptsNone are used. > I think your answer is for code in compile.cpp but my question was about > PhaseIdealLoop::build_and_optimize(). Do we need any change at all in > this method or could existing gc api points be used instead? Ah - I think I get it. You mean like this: void ZBarrierSetC2::barrier_insertion_phase(PhaseIterGVN& igvn)const { PhaseIdealLoop ideal_loop(igvn,LoopOptsNone); // First make sure all loads between call and catch are moved to the catch block clean_catch_blocks(&ideal_loop); // Then expand barriers on all loads insert_load_barriers(&ideal_loop); // Handle all Unsafe that need barriers. insert_barriers_on_unsafe(&ideal_loop); // Cleanup any modified bits igvn.optimize(); igvn.C->clear_major_progress(); } An excellent idea. Then I can remove the new LoopOptsMode::BarrierInsertion. > >>> In fixup_uses_in_catch() wouldn't you need to deal with phis the way you >>> do in call_catch_cleanup_one(): >>> >>> 1019 // We found no single catchproj that dominated the use - The use is at a point after >>> 1020 // where control flow from multiple catch projs have merged. We will have to create >>> 1021 // phi nodes before the use and tie the output from the cloned loads together. It >>> 1022 // can be a single phi or a number of chained phis, depending on control flow >> No - it's a two step process. >> >> There is a load hanging off a call with multiple catch projs. (There can >> be no other control-flow in between.) The load have uses, either (1) in >> the catch blocks, or (2) in some cases in the call block, hanging off >> the load. >> >> fixup_uses_in_catch responsibility is to turn (2) into (1). It clones >> all uses of the load, in the call block, out to the catch blocks. This >> is done recursively. There can never be any phis here. > Ok. > >>> Is there a chance that a load would be processed by >>> fixup_uses_in_catch()? I see call_catch_cleanup_one() is where they are >>> expected to be handled but you only go there if >>> load->is_barrier_required() is true. So could you have a load for which >>> is_barrier_required() is true have a use for which is_barrier_required() >>> is not true and both of them be in the catch block? >> In theory yes. If the load without a barrier is a use of the load with a >> barrier, it would be processed first. When the load with a barrier is >> processed, it would clone the load without a barrier, like any other node. > If I understand the logic right, in the case, that load would be cloned > as many times as there are uses. But couldn't there be multiple uses in > a control flow path causing a load to be executed multiple times which > would be in violation of the java memory model? I've been running some experiments with asserts on the clone code. 1) There can never be any control flow here - so now phis or such. 2) Stores have explicit control - and would never be scheduled here either. 3) Loads - they end up here because they can float. They only matter if there is a use dominated by the catch (after a merge of catch control flow), or uses in more than one catch-proj branch. The only nodes observed being cloned is LoadPNodes with barriers, BoolNodes, and CmpP nodes. It's the same pattern of comparing a pointer. All other load has it's control in the catch-projs. I will add asserts to the clone in fixup_uses_in_catch to reflect this conclusion and make sure that I catch any change in behavior. / Nils > > Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Tue Jun 4 16:17:12 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 4 Jun 2019 19:17:12 +0300 Subject: RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached In-Reply-To: <26ee82f6-ffb4-6ce6-daad-fcfc85ef293a@oracle.com> References: <03736619-e07f-e33c-635b-5e8d722d0142@loongson.cn> <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn> <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com> <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com> <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn> <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com> <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com> <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn> <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn> <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn> <1e559921-8d8c-177a-c301-429bc657053a@loongson.cn> <26ee82f6-ffb4-6ce6-daad-fcfc85ef293a@oracle.com> Message-ID: <714d5887-e989-0b64-a7d1-62ad59d66c85@oracle.com> Hi Jie, The failure is caused by saturated_add() returning 0 for non-zero arguments on sparc. The culprit is jlong vs jint and reinterpret_cast. I believe what happens is, since sparc is big-endian, the cast from 64-bit to 32-bit may return upper part of the value (depending on actual machine code). I suggest to fix it by switching from reinterpret_cast to static_cast. Along with the fix, I slightly refactored your patch and ended up with the following version: http://cr.openjdk.java.net/~vlivanov/jiefu/8224162/webrev.11_10/ Let me know what you think about it. Best regards, Vladimir Ivanov On 03/06/2019 16:55, Vladimir Ivanov wrote: > FYI there was a new failure in compiler/unsafe/UnsafeGetConstantField > spotted on solaris-sparcv9.? I'm looking into it and let you know about > my findings. > > Best regards, > Vladimir Ivanov > > On 01/06/2019 04:37, Jie Fu wrote: >> Hi Vladimir Ivanov, >> >> Thanks for your review and suggestions. >> Updated: http://cr.openjdk.java.net/~jiefu/8224162/webrev.10/ >> >> Thanks a lot. >> Best regards, >> Jie >> >> On 2019/6/1 ??5:47, Vladimir Ivanov wrote: >>> +template >>> +int ciMethod::saturated_add(L a, R b) { >>> >>> What do you think about moving it to globalDefinitions.hpp? >>> >>> Probably, it's worth getting rid of the template parameters and >>> introduce specializations (akin to JAVA_INTEGER_OP) since the >>> implementation makes sense only for int/uint. >> It seems cool. I like this style. >>> >>> +? jlong sum? = src1 + src2; >>> I'd prefer to see explicit casts to jlong to stress there's no >>> overflow possible here for 32-bit values. >>> >> Done >>> >>> +??? return c < 0 ? max_jint : c; >>> +????? case Bytecodes::_instanceof: return c > 0 ? min_jint : c; >>> >>> Please, put parentheses around ternary expressions. >>> >> Done >> >> From dean.long at oracle.com Tue Jun 4 16:53:11 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 4 Jun 2019 09:53:11 -0700 Subject: RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded In-Reply-To: <87imtlftb2.fsf@redhat.com> References: <877eailvgp.fsf@redhat.com> <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com> <87v9xn9lcy.fsf@redhat.com> <20bc16d4-b1a0-612e-3af9-287c2fcbc7f0@redhat.com> <87h8979hmn.fsf@redhat.com> <5829d956-29cd-9783-e91b-dd0da127e9be@redhat.com> <87ef4b9gpf.fsf@redhat.com> <9c7e87df-7e23-4773-57c9-3dd3286905bc@redhat.com> <87imtlftb2.fsf@redhat.com> Message-ID: <8066e2e2-cfaa-ce0b-8d4b-19afb0152d04@oracle.com> Yes, you can count me as a reviewer. dl On 6/4/19 5:06 AM, Roland Westrelin wrote: > I got at least 2 reviews for this (Roman and Nils). Not sure if Dean's > comment counts as a review, though. If no one objects in the next 24 > hours, I'll push that change. > > Roland. From mikael.vidstedt at oracle.com Tue Jun 4 20:38:00 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Jun 2019 13:38:00 -0700 Subject: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests Message-ID: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 has been fixed they should be problem listed. java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java bug: https://bugs.openjdk.java.net/browse/JDK-8225305 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ Cheers, Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Tue Jun 4 20:52:48 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Jun 2019 13:52:48 -0700 Subject: RFR(XS): 8225307: ProblemList compiler/codegen/TestCharVect2.java and compiler/c2/cr6340864/TestLongVect.java Message-ID: <461DE4AC-C607-4892-BC90-C56144B504FB@oracle.com> The two tests (in subject) are failing frequently. Until https://bugs.openjdk.java.net/browse/JDK-8224234 is fixed they should be problem listed. Bug: https://bugs.openjdk.java.net/browse/JDK-8225307 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225307/webrev.00/open/webrev/ Cheers, Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Jun 4 20:59:48 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 4 Jun 2019 13:59:48 -0700 Subject: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests In-Reply-To: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> References: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> Message-ID: <52E971E0-1CB8-4951-9DFC-F5EDA9857E9C@oracle.com> Looks good. Thanks Vladimir > On Jun 4, 2019, at 1:38 PM, Mikael Vidstedt wrote: > > > The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 has been fixed they should be problem listed. > > java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java > java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java > java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java > > bug: https://bugs.openjdk.java.net/browse/JDK-8225305 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ > > Cheers, > Mikael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Jun 4 20:58:50 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 4 Jun 2019 13:58:50 -0700 Subject: RFR(XS): 8225307: ProblemList compiler/codegen/TestCharVect2.java and compiler/c2/cr6340864/TestLongVect.java In-Reply-To: <461DE4AC-C607-4892-BC90-C56144B504FB@oracle.com> References: <461DE4AC-C607-4892-BC90-C56144B504FB@oracle.com> Message-ID: <3ED98491-58C8-4A56-A571-25D985A5E063@oracle.com> Good. Thanks Vladimir > On Jun 4, 2019, at 1:52 PM, Mikael Vidstedt wrote: > > > The two tests (in subject) are failing frequently. Until https://bugs.openjdk.java.net/browse/JDK-8224234 is fixed they should be problem listed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225307 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225307/webrev.00/open/webrev/ > > Cheers, > Mikael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Jun 4 21:06:20 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 4 Jun 2019 14:06:20 -0700 Subject: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests In-Reply-To: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> References: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> Message-ID: <3C94D555-5251-492D-8FC9-B5740A515B53@oracle.com> Hi Mikael, as it looks like 8222445 isn't going to be fixed for a long time (as it's "targeted" to tbd), and the defect seems to affect only AOT run, I don't think it's a good idea to put these tests into a general problem list. I'd suggest to either create aot-specific problem list or put them into -graal specific problem list. -- Igor > On Jun 4, 2019, at 1:38 PM, Mikael Vidstedt wrote: > > > The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 has been fixed they should be problem listed. > > java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java > java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java > java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java > > bug: https://bugs.openjdk.java.net/browse/JDK-8225305 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ > > Cheers, > Mikael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Jun 4 22:18:01 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Jun 2019 15:18:01 -0700 Subject: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests In-Reply-To: <3C94D555-5251-492D-8FC9-B5740A515B53@oracle.com> References: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> <3C94D555-5251-492D-8FC9-B5740A515B53@oracle.com> Message-ID: I agree with Igor.? The best is to keep running these tests except the AOT, perhaps + fastdebug, run only. Mandy On 6/4/19 2:06 PM, Igor Ignatyev wrote: > Hi Mikael, > > as it looks like 8222445 isn't going to be fixed for a long time (as it's "targeted" to tbd), and the defect seems to affect only AOT run, I don't think it's a good idea to put these tests into a general problem list. I'd suggest to either create aot-specific problem list or put them into -graal specific problem list. > > -- Igor > >> On Jun 4, 2019, at 1:38 PM, Mikael Vidstedt wrote: >> >> >> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 has been fixed they should be problem listed. >> >> java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java >> java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java >> java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8225305 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ >> >> Cheers, >> Mikael >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Wed Jun 5 02:18:52 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Jun 2019 19:18:52 -0700 Subject: RFR(XS): 8225307: ProblemList compiler/codegen/TestCharVect2.java and compiler/c2/cr6340864/TestLongVect.java In-Reply-To: <3ED98491-58C8-4A56-A571-25D985A5E063@oracle.com> References: <461DE4AC-C607-4892-BC90-C56144B504FB@oracle.com> <3ED98491-58C8-4A56-A571-25D985A5E063@oracle.com> Message-ID: Thanks Vladimir! Change pushed. Cheers, Mikael > On Jun 4, 2019, at 1:58 PM, Vladimir Kozlov wrote: > > Good. > > Thanks > Vladimir > > On Jun 4, 2019, at 1:52 PM, Mikael Vidstedt > wrote: > >> >> The two tests (in subject) are failing frequently. Until https://bugs.openjdk.java.net/browse/JDK-8224234 is fixed they should be problem listed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225307 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225307/webrev.00/open/webrev/ >> >> Cheers, >> Mikael >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Wed Jun 5 02:29:12 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Jun 2019 19:29:12 -0700 Subject: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests In-Reply-To: References: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> <3C94D555-5251-492D-8FC9-B5740A515B53@oracle.com> Message-ID: <21CE23AC-69BB-487F-A4B3-FB83D4F99882@oracle.com> I, too, agree. :) New webrev which adds a new ProblemList-aot.txt to be used when running tests with AOT. Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.01/open/webrev/ Cheers, Mikael > On Jun 4, 2019, at 3:18 PM, Mandy Chung wrote: > > I agree with Igor. The best is to keep running these tests except > the AOT, perhaps + fastdebug, run only. > > Mandy > > On 6/4/19 2:06 PM, Igor Ignatyev wrote: >> Hi Mikael, >> >> as it looks like 8222445 isn't going to be fixed for a long time (as it's "targeted" to tbd), and the defect seems to affect only AOT run, I don't think it's a good idea to put these tests into a general problem list. I'd suggest to either create aot-specific problem list or put them into -graal specific problem list. >> >> -- Igor >> >>> On Jun 4, 2019, at 1:38 PM, Mikael Vidstedt wrote: >>> >>> >>> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 has been fixed they should be problem listed. >>> >>> java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java >>> java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java >>> java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8225305 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ >>> >>> Cheers, >>> Mikael >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Wed Jun 5 02:37:37 2019 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Tue, 4 Jun 2019 19:37:37 -0700 Subject: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests In-Reply-To: <21CE23AC-69BB-487F-A4B3-FB83D4F99882@oracle.com> References: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> <3C94D555-5251-492D-8FC9-B5740A515B53@oracle.com> <21CE23AC-69BB-487F-A4B3-FB83D4F99882@oracle.com> Message-ID: <2346EF7E-9FE4-4760-B52D-8ECA786F5537@oracle.com> LGTM! ? Igor > On Jun 4, 2019, at 7:29 PM, Mikael Vidstedt wrote: > > > I, too, agree. :) > > New webrev which adds a new ProblemList-aot.txt to be used when running tests with AOT. > > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.01/open/webrev/ > > Cheers, > Mikael > >> On Jun 4, 2019, at 3:18 PM, Mandy Chung wrote: >> >> I agree with Igor. The best is to keep running these tests except >> the AOT, perhaps + fastdebug, run only. >> >> Mandy >> >>> On 6/4/19 2:06 PM, Igor Ignatyev wrote: >>> Hi Mikael, >>> >>> as it looks like 8222445 isn't going to be fixed for a long time (as it's "targeted" to tbd), and the defect seems to affect only AOT run, I don't think it's a good idea to put these tests into a general problem list. I'd suggest to either create aot-specific problem list or put them into -graal specific problem list. >>> >>> -- Igor >>> >>>> On Jun 4, 2019, at 1:38 PM, Mikael Vidstedt wrote: >>>> >>>> >>>> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 has been fixed they should be problem listed. >>>> >>>> java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java >>>> java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java >>>> java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8225305 >>>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ >>>> >>>> Cheers, >>>> Mikael >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Jun 5 05:06:38 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Jun 2019 22:06:38 -0700 Subject: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests In-Reply-To: <21CE23AC-69BB-487F-A4B3-FB83D4F99882@oracle.com> References: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> <3C94D555-5251-492D-8FC9-B5740A515B53@oracle.com> <21CE23AC-69BB-487F-A4B3-FB83D4F99882@oracle.com> Message-ID: <7f26b6c6-4eda-f30b-9525-b3d2286cdcd8@oracle.com> Looks okay. Just to mention the alternativ: we could add "@requires !vm.aot.enabled" in those tests if only a few. Mandy On 6/4/19 7:29 PM, Mikael Vidstedt wrote: > > I, too, agree. :) > > New webrev which adds a new ProblemList-aot.txt to be used when > running tests with AOT. > > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.01/open/webrev/ > > Cheers, > Mikael > >> On Jun 4, 2019, at 3:18 PM, Mandy Chung > > wrote: >> >> I agree with Igor.? The best is to keep running these tests except >> the AOT, perhaps + fastdebug, run only. >> >> Mandy >> >> On 6/4/19 2:06 PM, Igor Ignatyev wrote: >>> Hi Mikael, >>> >>> as it looks like 8222445 isn't going to be fixed for a long time (as it's "targeted" to tbd), and the defect seems to affect only AOT run, I don't think it's a good idea to put these tests into a general problem list. I'd suggest to either create aot-specific problem list or put them into -graal specific problem list. >>> >>> -- Igor >>> >>>> On Jun 4, 2019, at 1:38 PM, Mikael Vidstedt wrote: >>>> >>>> >>>> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Untilhttps://bugs.openjdk.java.net/browse/JDK-8222445 has been fixed they should be problem listed. >>>> >>>> java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java >>>> java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java >>>> java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java >>>> >>>> bug:https://bugs.openjdk.java.net/browse/JDK-8225305 >>>> webrev:http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ >>>> >>>> Cheers, >>>> Mikael >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujie at loongson.cn Wed Jun 5 05:53:12 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 5 Jun 2019 13:53:12 +0800 Subject: RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached In-Reply-To: <714d5887-e989-0b64-a7d1-62ad59d66c85@oracle.com> References: <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn> <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com> <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com> <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn> <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com> <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com> <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn> <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn> <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn> <1e559921-8d8c-177a-c301-429bc657053a@loongson.cn> <26ee82f6-ffb4-6ce6-daad-fcfc85ef293a@oracle.com> <714d5887-e989-0b64-a7d1-62ad59d66c85@oracle.com> Message-ID: <40c0a440-c10d-ca0d-a766-fdd493db8135@loongson.cn> Hi Vladimir Ivanov and all, Thanks Vladimir Ivanov for your help and review. Updated: http://cr.openjdk.java.net/~jiefu/8224162/webrev.11/ Vladimir Ivanov's nice refactoring has been merged in it. May I get a second review for this change? Thanks a lot. Best regards, Jie On 2019/6/5 ??12:17, Vladimir Ivanov wrote: > The failure is caused by saturated_add() returning 0 for non-zero > arguments on sparc. The culprit is jlong vs jint and > reinterpret_cast. I believe what happens is, since sparc is > big-endian, the cast from 64-bit to 32-bit may return upper part of > the value (depending on actual machine code). I suggest to fix it by > switching from reinterpret_cast to static_cast. Great! To be honest, I didn't realize the problem of reinterpret_cast on big-endian systems before. Thanks for your fix. > > Along with the fix, I slightly refactored your patch and ended up with > the following version: > ? http://cr.openjdk.java.net/~vlivanov/jiefu/8224162/webrev.11_10/ > > Let me know what you think about it. I like it. Thank you very much. From rwestrel at redhat.com Wed Jun 5 08:20:23 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 05 Jun 2019 10:20:23 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <87k1e39hno.fsf@redhat.com> <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> Message-ID: <87ftoofnp4.fsf@redhat.com> > Ah - I think I get it. You mean like this: > > void ZBarrierSetC2::barrier_insertion_phase(PhaseIterGVN& igvn)const { > PhaseIdealLoop ideal_loop(igvn,LoopOptsNone); > > // First make sure all loads between call and catch are moved to the > catch block clean_catch_blocks(&ideal_loop); > > // Then expand barriers on all loads insert_load_barriers(&ideal_loop); > > // Handle all Unsafe that need barriers. insert_barriers_on_unsafe(&ideal_loop); > > // Cleanup any modified bits igvn.optimize(); > > igvn.C->clear_major_progress(); > } > > An excellent idea. Then I can remove the new LoopOptsMode::BarrierInsertion. I was thinking something like what we do in Shenandoah for barrier expansion: PhaseIdealLoop ideal_loop(igvn, LoopOptsShenandoahExpand); ShenandoahBarrierSetC2::is_gc_specific_loop_opts_pass() returns true for LoopOptsShenandoahExpand and ShenandoahBarrierSetC2::optimize_loops() handles LoopOptsShenandoahExpand. So there's nothing shenandoah specific in PhaseIdealLoop::build_and_optimize(). > I've been running some experiments with asserts on the clone code. > > 1) There can never be any control flow here - so now phis or such. > > 2) Stores have explicit control - and would never be scheduled here either. > > 3) Loads - they end up here because they can float. They only matter if > there is a use dominated by the catch (after a merge of catch control > flow), or uses in more than one catch-proj branch. The only nodes > observed being cloned is LoadPNodes with barriers, BoolNodes, and CmpP > nodes. It's the same pattern of comparing a pointer. All other load has > it's control in the catch-projs. > > I will add asserts to the clone in fixup_uses_in_catch to reflect this > conclusion and make sure that I catch any change in behavior. I was thinking of something like: try { non_inlined_call1(); int v = some_object.object_field.int_field; non_inlined_call2(v, v); } catch (..) { int v = some_object.object_field.int_field; // some use for v } So there would be a LoadP, a load barrier and a LoadI right after the call. The LoadI is the first to be cloned. It has 3 uses, so it's cloned 3 times? Which would mean non_inlined_call2 is actually called with: SomeObject object = some_object.object_field; non_inlined_call2(object.int_field, object.int_field); the field is reloaded and that code doesn't have the same effect as above. Or am I missing something? Roland. From rwestrel at redhat.com Wed Jun 5 08:21:05 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 05 Jun 2019 10:21:05 +0200 Subject: RFR(S): 8224580: Matcher can cause oop field/array element to be reloaded In-Reply-To: <8066e2e2-cfaa-ce0b-8d4b-19afb0152d04@oracle.com> References: <877eailvgp.fsf@redhat.com> <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com> <87v9xn9lcy.fsf@redhat.com> <20bc16d4-b1a0-612e-3af9-287c2fcbc7f0@redhat.com> <87h8979hmn.fsf@redhat.com> <5829d956-29cd-9783-e91b-dd0da127e9be@redhat.com> <87ef4b9gpf.fsf@redhat.com> <9c7e87df-7e23-4773-57c9-3dd3286905bc@redhat.com> <87imtlftb2.fsf@redhat.com> <8066e2e2-cfaa-ce0b-8d4b-19afb0152d04@oracle.com> Message-ID: <87d0jsfnny.fsf@redhat.com> > Yes, you can count me as a reviewer. Thanks! Roland. From adinn at redhat.com Wed Jun 5 08:43:35 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 5 Jun 2019 09:43:35 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <42909e1f-e235-8f4b-d881-cff556fb7bc2@oracle.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <42909e1f-e235-8f4b-d881-cff556fb7bc2@oracle.com> Message-ID: <7adbabb2-c804-90aa-ee58-b97b7aed52eb@redhat.com> On 04/06/2019 11:40, Alan Bateman wrote: > On 03/06/2019 15:37, Andrew Dinn wrote: >> : >> >> The CSR and JEP have been updated accordingly >> >> CSR:? https://bugs.openjdk.java.net/browse/JDK-8224975 >> JEP:? https://bugs.openjdk.java.net/browse/JDK-8207851 >> > The specification section in the CSR was missing the module definition > so I added that. The rest looks okay so I've added myself as Reviewer so > you can finalize it. Thanks, Alan. Done. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martin.doerr at sap.com Wed Jun 5 09:30:10 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 5 Jun 2019 09:30:10 +0000 Subject: RFR(S): 8222103: [testbug] compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest may exceed VM limit In-Reply-To: <21920A56-9559-4CB3-A084-5F9F3EF92BCA@oracle.com> References: <9F82E0AB-45DB-45F4-B453-691F4A1AB244@oracle.com> <21920A56-9559-4CB3-A084-5F9F3EF92BCA@oracle.com> Message-ID: Hi Peter, reviewed and pushed. Best regards, Martin From: hotspot-compiler-dev On Behalf Of Igor Ignatyev Sent: Freitag, 31. Mai 2019 19:09 To: Januschke, Peter Cc: hotspot-compiler-dev at openjdk.java.net compiler Subject: Re: RFR(S): 8222103: [testbug] compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest may exceed VM limit Hi Peter, the patch looks good to me. -- Igor On May 31, 2019, at 6:46 AM, Januschke, Peter > wrote: Hi, sorry for taking so long. Since I am a member of SAP?s work council, I have only very limited time for doing development. So now here is a solution like proposed by Igor: http://cr.openjdk.java.net/~mdoerr/8222103_testbug/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8222103 Please review, and I please need a sponsor. Best regards Peter From: Igor Ignatyev > Sent: Dienstag, 9. April 2019 18:30 To: Nils Eliasson >; Januschke, Peter > Cc: hotspot-compiler-dev at openjdk.java.net compiler > Subject: Re: RFR(S): 8222103: [testbug] compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest may exceed VM limit Nils, thanks for the clarification. Peter, I haven't looked at these tests for quite a while, and, I guess, presence of 'jcmd' in the path got me confused, so I (now obviously) incorrectly assumed that the directives are added by jcmd. in this case, I agree that it is a test bug. I'd however prefer it to be fixed slightly different and instead of adding 'CompilerDirectivesLimit to command line I'd read its value using WhiteBox and limit ClearDirectivesFileStackTest::AMOUNT by it. you'll also need to update year in the copyright notice. Thanks, -- Igor On Apr 9, 2019, at 4:55 AM, Nils Eliasson > wrote: Hi, The design is that you add a number of directives together to get a desired behavior. Adding just some of them make no sense. If you add directives by command line, and get an error (syntax or limit) - it will print the error stop the startup. This allows the user to correct the problem and retry. If you add by jcmd, the error is printed on the jcmd console, but the VM continues on unaffected. The user can correct the problem and make another try. I think there is a separate test of the limit. And if that is already covered, testing it in this test too, seems unnecessary. Regards, // Nils On 2019-04-09 11:34, Januschke, Peter wrote: Hi Igor, the current implementation prints a message and then stops: bool DirectivesStack::check_capacity(int request_size, outputStream* st) { if ((request_size + _depth) > CompilerDirectivesLimit) { st->print_cr("Could not add %i more directives. Currently %i/%i directives.", request_size, _depth, CompilerDirectivesLimit); return false; } return true; } Best regards Peter From: Igor Ignatyev Sent: Montag, 8. April 2019 19:25 To: Januschke, Peter Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(S): 8222103: [testbug] compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest may exceed VM limit Hi Peter, I don't think it's a test bug, VM shouldn't stop execution if someone requests too many compiler directives, instead it should reject requests which will exceed its capacity. -- Igor On Apr 8, 2019, at 1:18 AM, Januschke, Peter > wrote: Hi, I propose the following fix to the test mentioned in the subject: Problem: The test generates a random number of compiler directives, which might be greater than the value of CompilerDirectivesLimit. This causes the VM to stop execution upon the corresponding capacity check. Fix: set CompilerDirectivesLimit to the max random number used. http://cr.openjdk.java.net/~goetz/wr19/peter/8222103-01 https://bugs.openjdk.java.net/browse/JDK-8222103 Please review, and I please need a sponsor. Best regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 5 09:57:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Jun 2019 10:57:10 +0100 Subject: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests In-Reply-To: <21CE23AC-69BB-487F-A4B3-FB83D4F99882@oracle.com> References: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> <3C94D555-5251-492D-8FC9-B5740A515B53@oracle.com> <21CE23AC-69BB-487F-A4B3-FB83D4F99882@oracle.com> Message-ID: <06fd05af-629a-a698-997f-d5b333f4ae7a@oracle.com> On 05/06/2019 03:29, Mikael Vidstedt wrote: > I, too, agree. :) > > New webrev which adds a new ProblemList-aot.txt to be used when running tests with AOT. > > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.01/open/webrev/ > This is better than excluding it unconditional. BTW: Just on term "quarantined" in the comments. We normally use "exclude" rather than "quarantine" as it's the exclude list that is provided to jtreg via the -exclude option. -Alan. From brian.burkhalter at oracle.com Wed Jun 5 14:36:09 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2019 07:36:09 -0700 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> Message-ID: HI Andrew, I have some minor comments on webrev.05. (webrev.06 looks rather strange.) Thanks, Brian Note: Hotspot changes not reviewed here. General Check copyrights. Some headers are missing altogether, some have incorrect years. MappedByteBuffer.java 84: ?any of other modes? -> ?any of the other modes?, ?this? -> ?This? 85: nit: usually use American spelling: ?behaviour? -> ?behavior? (but it does not matter so much here as it is not public javadoc. 172: ?pasing? -> ?passing? 175: delete ?using? 181: comma or semicolon before ?otherwise? 355-365: Collapse to? Unsafe.getUnsafe().writebackMemory(address + index, length); Unsafe.java 924-945: Capitalize first words of sentences. 959: Is there a possibility of overflow, e.g., use Math.addExact(address, length) ? 1290: Insert blank line after. FileChannelImpl.c (Unix) 85: ?||! map_sync? -> ??|| !map_sync? 98-110: Put symbolic name definitions at head of file? FileChannelImpl.c (Windows) 91: Use same message as at Unix version line 135? ExtendedMapMode 13: Constant name should be MAP_MODE_CONSTRUCTOR. 13: Insert blank line after 34-36: Move to before line 13. 24: Move constructor to end of class. > On Jun 3, 2019, at 7:37 AM, Andrew Dinn wrote: > > > > On 03/06/2019 14:17, Andrew Dinn wrote: >> Hi Vladimir, >> >> Thanks for the follow-up and for checking the submit failure. I have >> addressed all the points you raised (point by point comments are >> included below). A new webrev which passes a submit run is here: >> >> http://cr.openjdk.java.net/~adinn/8224974/webrev.04 >> >> n.b. This webrev also includes changes to the javadoc for >> ExtendedMapMode suggested by Alan Bateman. > . . . > > I have made one further change to locate the new ExtendedMapMode enum in > module jdk.nio.mapmode and package jdk.nio.mapmode as suggested offline > by Alan Bateman and the OpenJDK lead. Please refer to this webrev instead: > > webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.05 > > The CSR and JEP have been updated accordingly > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224975 > JEP: https://bugs.openjdk.java.net/browse/JDK-8207851 > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Jun 5 14:46:22 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2019 07:46:22 -0700 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> Message-ID: <53712EB1-D1C1-4174-BA69-9C7D85DCE9A8@oracle.com> To clarify, the following comments were for the _internal_ class. These along with a number of my other comments are just stylistic and not absolutely necessary to change. Thanks, Brian > On Jun 5, 2019, at 7:36 AM, Brian Burkhalter wrote: > > ExtendedMapMode > 13: Constant name should be MAP_MODE_CONSTRUCTOR. > 13: Insert blank line after > 34-36: Move to before line 13. > 24: Move constructor to end of class. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 5 15:15:58 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Jun 2019 16:15:58 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <7adbabb2-c804-90aa-ee58-b97b7aed52eb@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <42909e1f-e235-8f4b-d881-cff556fb7bc2@oracle.com> <7adbabb2-c804-90aa-ee58-b97b7aed52eb@redhat.com> Message-ID: <8c1c2dbe-0dc4-609e-4cf5-093a2f0734b7@oracle.com> On 05/06/2019 09:43, Andrew Dinn wrote: > On 04/06/2019 11:40, Alan Bateman wrote: >> On 03/06/2019 15:37, Andrew Dinn wrote: >>> : >>> >>> The CSR and JEP have been updated accordingly >>> >>> CSR:? https://bugs.openjdk.java.net/browse/JDK-8224975 >>> JEP:? https://bugs.openjdk.java.net/browse/JDK-8207851 >>> >> The specification section in the CSR was missing the module definition >> so I added that. The rest looks okay so I've added myself as Reviewer so >> you can finalize it. > Thanks, Alan. Done. > I see the CSR is finalized now and I'm sure Joe will look at this in the coming days. I re-read the JEP and I think it needs a few edits before seeking Brian's endorsement. One thing is that the scope is "JDK" but the Description still has a "Proposed Java SE API Changes" sub-section. The supported interfaces are the new jdk.nio.mapmode module and probably the name of the new buffer pool, everything else is describing the implementation. I think the "Proposal Internal JDK API changes" section is okay. I think the "Alternatives" section should list waiting for Project Panama as an alternative. We've had at two discussions here about buffers not being the long term API for this and I think we should at least acknowledge that in this section. This goes partly with the reference in the "Risks and Assumptions" section to the the absolute bulk put/get methods - these methods have been added for Java SE 13. -Alan From mikael.vidstedt at oracle.com Wed Jun 5 15:50:08 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 5 Jun 2019 08:50:08 -0700 Subject: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests In-Reply-To: <06fd05af-629a-a698-997f-d5b333f4ae7a@oracle.com> References: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com> <3C94D555-5251-492D-8FC9-B5740A515B53@oracle.com> <21CE23AC-69BB-487F-A4B3-FB83D4F99882@oracle.com> <06fd05af-629a-a698-997f-d5b333f4ae7a@oracle.com> Message-ID: <576FCA5E-8F22-467B-82B2-D8D2233F8817@oracle.com> > On Jun 5, 2019, at 2:57 AM, Alan Bateman wrote: > > > > On 05/06/2019 03:29, Mikael Vidstedt wrote: >> I, too, agree. :) >> >> New webrev which adds a new ProblemList-aot.txt to be used when running tests with AOT. >> >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.01/open/webrev/ >> > This is better than excluding it unconditional. > > BTW: Just on term "quarantined" in the comments. We normally use "exclude" rather than "quarantine" as it's the exclude list that is provided to jtreg via the -exclude option. That indeed sounds like a more appropriate term. For better or worse this is consistent with the comments in the other ProblemList files, so I?ll leave it the way it is. Vladimir/Igor/Mandy/Alan - thanks for the reviews. Change pushed!` Cheers, Mikael From vladimir.kozlov at oracle.com Wed Jun 5 16:25:20 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Jun 2019 09:25:20 -0700 Subject: RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached In-Reply-To: <40c0a440-c10d-ca0d-a766-fdd493db8135@loongson.cn> References: <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn> <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com> <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com> <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn> <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com> <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com> <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn> <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn> <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn> <1e559921-8d8c-177a-c301-429bc657053a@loongson.cn> <26ee82f6-ffb4-6ce6-daad-fcfc85ef293a@oracle.com> <714d5887-e989-0b64-a7d1-62ad59d66c85@oracle.com> <40c0a440-c10d-ca0d-a766-fdd493db8135@loongson.cn> Message-ID: <3f4ba661-d1d5-dcd7-123f-63bce383deb5@oracle.com> Looks good to me. Thanks, Vladimir K. On 6/4/19 10:53 PM, Jie Fu wrote: > Hi Vladimir Ivanov and all, > > Thanks Vladimir Ivanov for your help and review. > Updated: http://cr.openjdk.java.net/~jiefu/8224162/webrev.11/ > > Vladimir Ivanov's nice refactoring has been merged in it. > May I get a second review for this change? > > Thanks a lot. > Best regards, > Jie > > On 2019/6/5 ??12:17, Vladimir Ivanov wrote: >> The failure is caused by saturated_add() returning 0 for non-zero arguments on sparc. The culprit is jlong vs jint and >> reinterpret_cast. I believe what happens is, since sparc is big-endian, the cast from 64-bit to 32-bit may >> return upper part of the value (depending on actual machine code). I suggest to fix it by switching from >> reinterpret_cast to static_cast. > > Great! > To be honest, I didn't realize the problem of reinterpret_cast on big-endian systems before. > Thanks for your fix. > >> >> Along with the fix, I slightly refactored your patch and ended up with the following version: >> ? http://cr.openjdk.java.net/~vlivanov/jiefu/8224162/webrev.11_10/ >> >> Let me know what you think about it. > > I like it. Thank you very much. > > From adinn at redhat.com Wed Jun 5 17:10:16 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 5 Jun 2019 18:10:16 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> Message-ID: Hi Brian, Thanks very much for reviewing the patch. Also, commendations on your eagle-eyed thoroughness. I have happily accepted most corrections. I have commented (inline below) in a few places where I think things might need to be discussed further. I will upload a new webrev after these points are resolved. On 05/06/2019 15:36, Brian Burkhalter wrote: > I have some minor comments on webrev.05. (webrev.06 looks rather strange.) That is the next working version being queued up -- you may well have seen an intermediate version while it was uploading. > Note: Hotspot changes not reviewed here. Sure. > General > Check copyrights. Some headers are missing altogether, some have > incorrect years. Yes, all of them are now fixed. > MappedByteBuffer.java > 84:?any of other modes? -> ?any of the other modes?, ?this? -> ?This? > 85:nit: usually use American spelling: ?behaviour? -> ?behavior? (but it > does not matter so much here as it is not public javadoc. > 172:?pasing? -> ?passing? > 175:delete ?using? > 181:comma or semicolon before ?otherwise? All done. I even gritted my teeth and spelled behaviour 'US-wize'. > 355-365: Collapse to? > > Unsafe.getUnsafe().writebackMemory(address + index, length); Sure, done. Although personally I'm 'not much into that whole brevity thing'. > Unsafe.java > 924-945:Capitalize first words of sentences. Done. > 959:Is there a possibility of overflow, e.g., use Math.addExact(address, > length) ? I think it assumed that all OSes currently ported (certainly Linux) will never map a vmem region so that addition of a valid internal offset might overflow. If it did we would be in big trouble as regards null pointer checking. So, modulo input from those wiser than me in operating system lore, I think this is not needed. > 1290:Insert blank line after. Done. > FileChannelImpl.c (Unix) > 85:?||! map_sync? -> ??|| !map_sync? Done. > 98-110:Put symbolic name definitions at head of file? I thought these definitions would be better placed at the point where the defines are needed so as to make it clear why this is being done. If you are strongly motivated to move them to the more normal location I will do so. > FileChannelImpl.c (Windows) > 91:Use same message as at Unix version line 135? Perhaps but I don't think they are the same error and thougt it beter to reinforce that with different messages. Note the different exception types. In the case of Windows we should never reach this point -- at least not until a Windows port comes along and requires the message to be changed (effectively removing here and replacing it with somewhere else). So, an InternalError is thrown. In the Unix case the error might conceivably happen (because the target OS mmap implementation does not have proper MAP_SYNC support. Hence the use of IOException. > ExtendedMapMode > 13:Constant name should be MAP_MODE_CONSTRUCTOR. > 13:Insert blank line after > 34-36:Move to before line 13. > 24:Move constructor to end of class. Yes, all good. Thanks! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From brian.burkhalter at oracle.com Wed Jun 5 17:25:54 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2019 10:25:54 -0700 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> Message-ID: Hi Andrew, > On Jun 5, 2019, at 10:10 AM, Andrew Dinn wrote: > > Thanks very much for reviewing the patch. Also, commendations on your > eagle-eyed thoroughness. Thanks. :-) > I have happily accepted most corrections. I have commented (inline > below) Likewise. > in a few places where I think things might need to be discussed > further. I will upload a new webrev after these points are resolved. OK > On 05/06/2019 15:36, Brian Burkhalter wrote: >> I have some minor comments on webrev.05. (webrev.06 looks rather strange.) > > That is the next working version being queued up -- you may well have > seen an intermediate version while it was uploading. Must have done as it looks OK now. >> MappedByteBuffer.java >> 84:?any of other modes? -> ?any of the other modes?, ?this? -> ?This? >> 85:nit: usually use American spelling: ?behaviour? -> ?behavior? (but it >> does not matter so much here as it is not public javadoc. >> 172:?pasing? -> ?passing? >> 175:delete ?using? >> 181:comma or semicolon before ?otherwise? > > All done. I even gritted my teeth and spelled behaviour 'US-wize?. ;-) >> 959:Is there a possibility of overflow, e.g., use Math.addExact(address, >> length) ? > > I think it assumed that all OSes currently ported (certainly Linux) will > never map a vmem region so that addition of a valid internal offset > might overflow. If it did we would be in big trouble as regards null > pointer checking. So, modulo input from those wiser than me in operating > system lore, I think this is not needed. It sounds reasonable to leave it as-is in that case. >> 98-110:Put symbolic name definitions at head of file? > > I thought these definitions would be better placed at the point where > the defines are needed so as to make it clear why this is being done. If > you are strongly motivated to move them to the more normal location I > will do so. I think that is reasonable as well so no need to move them. >> FileChannelImpl.c (Windows) >> 91:Use same message as at Unix version line 135? > > Perhaps but I don't think they are the same error and thougt it beter to > reinforce that with different messages. Note the different exception > types. In the case of Windows we should never reach this point -- at > least not until a Windows port comes along and requires the message to > be changed (effectively removing here and replacing it with somewhere > else). So, an InternalError is thrown. In the Unix case the error might > conceivably happen (because the target OS mmap implementation does not > have proper MAP_SYNC support. Hence the use of IOException. All right, then leave it as it is. >> ExtendedMapMode >> 13:Constant name should be MAP_MODE_CONSTRUCTOR. >> 13:Insert blank line after >> 34-36:Move to before line 13. >> 24:Move constructor to end of class. > Yes, all good. Thanks! Good. I suppose these changes will be in version 7. If it is likely that comments will be forthcoming from others then it might be worth waiting to incorporate any further changes in version 7. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed Jun 5 17:46:13 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 5 Jun 2019 20:46:13 +0300 Subject: RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached In-Reply-To: <40c0a440-c10d-ca0d-a766-fdd493db8135@loongson.cn> References: <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn> <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com> <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com> <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn> <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com> <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com> <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn> <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn> <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn> <1e559921-8d8c-177a-c301-429bc657053a@loongson.cn> <26ee82f6-ffb4-6ce6-daad-fcfc85ef293a@oracle.com> <714d5887-e989-0b64-a7d1-62ad59d66c85@oracle.com> <40c0a440-c10d-ca0d-a766-fdd493db8135@loongson.cn> Message-ID: > Updated: http://cr.openjdk.java.net/~jiefu/8224162/webrev.11/ Looks good. No new failures during tier1-4 testing. I'll push the fix for you. Best regards, Vladimir Ivanov From brian.burkhalter at oracle.com Wed Jun 5 17:47:37 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2019 10:47:37 -0700 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> Message-ID: <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> Hi Andrew, Please ignore the content below: I see the changes are in version 6 which I had not looked through before posting my previous message. Thanks, Brian > On Jun 5, 2019, at 10:25 AM, Brian Burkhalter wrote: > > I suppose these changes will be in version 7. If it is likely that comments will be forthcoming from others then it might be worth waiting to incorporate any further changes in version 7. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Wed Jun 5 18:13:14 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 5 Jun 2019 15:13:14 -0300 Subject: RFR: 8207851: Implement JEP 352 In-Reply-To: <67ad071d-376b-8b0d-9b2f-42dca17a1041@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <67ad071d-376b-8b0d-9b2f-42dca17a1041@redhat.com> Message-ID: <3b0f0bcb-4ea0-fe71-acdb-6ca9e44a6d8d@linux.vnet.ibm.com> Hi Andrew, On 05/24/2019 07:06 AM, Andrew Dinn wrote: > Ping! > > Any takers for a review? I found some trailing space in v5 and it seems they are in v6 as well. You might want to check the followings: src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp + // data cache line writeback + StubRoutines::_data_cache_writeback = generate_data_cache_writeback(); + StubRoutines::_data_cache_writeback_sync = generate_data_cache_writeback_sync(); + <-- here src/hotspot/cpu/aarch64/vm_version_aarch64.cpp + if (_dcpop || UsePOCForPOP) { + _data_cache_line_flush_size = dcache_line; + } + } + <-- here src/hotspot/cpu/x86/macroAssembler_x86.cpp + // no need for fence when using CLFLUSH + clflush(line); + } <-- here src/hotspot/cpu/x86/stubGenerator_x86_64.cpp in generate_data_cache_writeback(): + __ ret(0); + + return start; <-- here in generate_data_cache_writeback_sync(): + __ jcc(Assembler::notEqual, skip); <-- here and + // data cache line writeback + StubRoutines::_data_cache_writeback = generate_data_cache_writeback(); + StubRoutines::_data_cache_writeback_sync = generate_data_cache_writeback_sync(); + <-- here (like in aarch64 file) src/java.base/share/classes/java/nio/MappedByteBuffer.java + private final boolean isSync; + <-- here and + private boolean isSync() { + return isSync; + } + <-- here src/java.base/share/classes/jdk/internal/misc/Unsafe.java + * that must be guaranteed written back to memory. + * <-- here and here: + * @since 13 + */ + <-- here + checkSize(length); + } + <-- here + * calling method {@link writeback #writeback} if it is disabled). + * <-- here + throw new RuntimeException("writebackMemory not enabled!"); + } + } + <-- here + // following memory writes + @HotSpotIntrinsicCandidate + private native void writebackPostSync0(); + <-- here src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java + incrementStats(); + } + <-- here totalCapacity -= cap; } } } + <-- here + super(address, size, cap, fd); + incrementStats(); + } + <-- here + totalCapacity -= cap; + } + } + } + <-- here src/java.base/unix/native/libnio/ch/FileChannelImpl.c + // should never be called with map_sync and prot == PRIVATE + assert((prot != sun_nio_ch_FileChannelImpl_MAP_PV) ||! map_sync); + <-- here +#ifndef MAP_SHARED_VALIDATE +#define MAP_SHARED_VALIDATE 0x03 +#endif + <-- here test/jdk/java/nio/MappedByteBuffer/PmemTest.java +import com.sun.nio.file.ExtendedMapMode; + <-- here + public static final int NUM_KBS = 16; + <-- here Best regards, Gustavo From vladimir.x.ivanov at oracle.com Wed Jun 5 18:15:27 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 5 Jun 2019 21:15:27 +0300 Subject: RFR: JDK-8224963: Char-Byte Performance Enhancement In-Reply-To: References: <68b970be-e551-577d-0ca1-28c16880a2ff@oracle.com> Message-ID: Thanks, Adam. I ported ASCIIEncodingBenchmark to JMH [1] and then tried your patch [2] on x86 (Skylake). Unfortunately, I couldn't reproduce any improvements. Moreover, the patched version is slower: ASCIIEncodingBenchmark.charToByte BEFORE (numberOfChars) Mode Cnt Score Error Units 0 thrpt 5 111413694.893 ? 763410.998 ops/s 1 thrpt 5 87992741.333 ? 148702.045 ops/s 16 thrpt 5 53456010.326 ? 100007.754 ops/s 64 thrpt 5 27901519.758 ? 94808.481 ops/s 512 thrpt 5 4958471.149 ? 14774.009 ops/s 4096 thrpt 5 600449.051 ? 37885.719 ops/s 8192 thrpt 5 269098.868 ? 1634.533 ops/s 65536 thrpt 5 38855.167 ? 92.170 ops/s 1048576 thrpt 5 2630.800 ? 5.076 ops/s AFTER (w/ [2] applied) (numberOfChars) Mode Cnt Score Error Units 0 thrpt 5 119674686.849 ? 510819.775 ops/s 1 thrpt 5 80067544.958 ? 176550.132 ops/s 16 thrpt 5 47836555.989 ? 137233.882 ops/s 64 thrpt 5 22814214.962 ? 80747.066 ops/s 512 thrpt 5 3686203.220 ? 38087.643 ops/s 4096 thrpt 5 489024.453 ? 55092.933 ops/s 8192 thrpt 5 243057.291 ? 1483.443 ops/s 65536 thrpt 5 30503.779 ? 43.282 ops/s 1048576 thrpt 5 1879.556 ? 10.168 ops/s Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/afarley/8224963/benchmarks/src/main/java/org/benchmark/ASCIIEncodingBenchmark.java [2] http://cr.openjdk.java.net/~afarley/8224963/webrev/ On 31/05/2019 19:07, Adam Farley8 wrote: > Hi Vladimir, > > Here's a minimised version of the benchmark, which converts chars to > bytes using nio. > > I found that the conversion rates are similar between Hotspot and OpenJ9 > for encoding > single-character buffers, and that the difference becomes palpable as > you increase the > size of the buffer. 4096-char buffers, for example, show the 6x > difference I mentioned > earlier. > > This makes sense to me, as we're spending less time messing around with > objects at the > test level, and more time actually utilising the encoding code. > > You should just be able to run the benchmark on the command line. > > "java ASCIIEncodingBenchmark " > > Benchmark code: > http://cr.openjdk.java.net/~afarley/8224963/ASCIIEncodingBenchmark.java > > If you need a microbenchmark for a specific framework, name it and I'll > get it done. > > Or one of my team will get it done. Off for a week. :) > > Best Regards > > Adam Farley > IBM Runtimes > > > Vladimir Ivanov wrote on 29/05/2019 17:19:36: > >> From: Vladimir Ivanov >> To: Adam Farley8 >> Cc: hotspot-compiler-dev at openjdk.java.net >> Date: 29/05/2019 17:23 >> Subject: Re: RFR: JDK-8224963: Char-Byte Performance Enhancement >> >> Adam, >> >> Among all options, I'm in favor of enhancing C2 to produce better code. >> Then on my preference list goes rewriting JDK code to make it amenable >> to missing optimizations (the patch you propose). And, as a last resort, >> I'd consider introducing new intrinsics. >> >> The microbenchmarks would help understand what pieces as missing in C2 >> and decide how to proceed. >> >> I haven't had HotSpot vs J9 comparison in mind, but in absence of >> benchmarks available comparing generated code (by C2) between original >> and updated JDK version would help understand what goes wrong. >> >> Best regards, >> Vladimir Ivanov >> >> On 29/05/2019 17:53, Adam Farley8 wrote: >> > Hi Vladimir, >> > >> > I have a locally-written performance test I used to get the "6x". >> > Will chase up with the guy who wrote it to see if I can share it. >> > If not, I'll write a new one. >> > >> > As for the enhancements, two options are: >> > >> > - matching on the new method names, and replacing the inner logic >> > with some souped-up version of said logic. >> > >> > - alter the code to match on one of the C2 idioms, though I imagine >> > if it were that simple, OpenJDK would come with a list of said >> > idioms so everything people write can be easily accelerated by the >> > JIT. >> > >> > As for how OpenJ9 does it specifically, I don't know, and I suspect >> > it's safer if I don't find out, contamination-wise. >> > >> > Does any of that help? >> > >> > Best Regards >> > >> > Adam Farley >> > IBM Runtimes >> > >> > >> > Vladimir Ivanov wrote on 29/05/201913:22:27: >> > >> >> From: Vladimir Ivanov >> >> To: Adam Farley8 , ?hotspot-compiler- >> >> dev at openjdk.java.net >> >> Date: 29/05/2019 13:22 >> >> Subject: Re: RFR: JDK-8224963: ?Char-Byte Performance Enhancement >> >> >> >> Hi Adam, >> >> >> >> The bug mentions ~6x improvement in throughput. Are there have any >> >> microbenchmarks you can share which demonstrate that? That would greatly >> >> simplify the analysis of changes you propose. >> >> >> >> Also, if you can elaborate on what optimization opportunities C2 misses >> >> in original code, please, do. >> >> >> >> Best regards, >> >> Vladimir Ivanov >> >> >> >> On 29/05/2019 12:45, Adam Farley8 wrote: >> >> > Hi All, >> >> > >> >> > Could someone familiar with the Hotspot JIT please review and ?opine on >> >> > the below? >> >> > >> >> > The Char-Byte encoding/decoding methods inside some of the sun.nio.cs >> >> > classes >> >> > (such as US_ASCII) see a lot of use, and OpenJDK on the OpenJ9 >> VM seems to >> >> > do this a lot faster. >> >> > >> >> > Is it possible to achieve a similar improvement on OpenJDK on ?Hotspot by >> >> > tweaking the CL code to match Hotspot JIT compiler idioms, or ?by >> >> > introducing >> >> > a method name for the HS JIT to match on? >> >> > >> >> > An example of these changes to US_ASCII.java is linked below. ?No OpenJ9 >> >> > code >> >> > is included in the work item or the webrev, to avoid contamination. >> >> > >> >> > Work item: https://urldefense.proofpoint.com/v2/url? >> >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8224963&d=DwIC- >> >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=4XPqGhxLchCLvSQhTIu3Wvm63NE2XpuEJf- >> >> PzjFCXb4&s=2ChxP3IE0tkvevxSXfil3PGlpEHkUPxgwMxHH5J-A34&e= >> >> > >> >> > Example Webrev: _https://urldefense.proofpoint.com/v2/url? >> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8224963_webrev_-5F&d=DwIC- >> >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=4XPqGhxLchCLvSQhTIu3Wvm63NE2XpuEJf- >> >> PzjFCXb4&s=fCeNvvk3Fehc6ssZfoNkJao_NJyoxeov7cxiyMSvuwQ&e= >> >> > >> >> > Best Regards >> >> > >> >> > Adam Farley >> >> > IBM Runtimes >> >> > >> >> > Unless stated otherwise above: >> >> > IBM United Kingdom Limited - Registered in England and Wales ?with number >> >> > 741598. >> >> > Registered office: PO Box 41, North Harbour, Portsmouth, >> Hampshire ?PO6 3AU >> >> >> > >> > Unless stated otherwise above: >> > IBM United Kingdom Limited - Registered in England and Wales with number >> > 741598. >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From vladimir.x.ivanov at oracle.com Wed Jun 5 18:16:20 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 5 Jun 2019 21:16:20 +0300 Subject: [13] RFR (XS): 8225141: Better handling of classes in error state in fast class initialization checks In-Reply-To: <52635b16-57a2-cb71-40c9-6470be77dcbb@oracle.com> References: <18cc95c1-4b46-2eec-bb16-34380aad9394@oracle.com> <52635b16-57a2-cb71-40c9-6470be77dcbb@oracle.com> Message-ID: <69c300fa-e86e-5f8a-eb92-cb59ed1d85a9@oracle.com> Thanks, David! Best regards, Vladimir Ivanov On 03/06/2019 09:35, David Holmes wrote: > Hi Vladimir, > > Thanks for clarifying how the different pieces connect. I'm somewhat > surprised this wasn't caught during pre-push testing, but hopefully this > now covers all cases. > > Thanks, > David > > On 1/06/2019 9:53 pm, Vladimir Ivanov wrote: >> Thanks for the feedback, David. >> >>>> What I propose is to set InstanceKlass::_init_thread only for the >>>> duration when the klass is in being_initialized state and reset it >>>> back to NULL when changing class state. It makes existing >>>> "_init_thread == current_thread" check equivalent to "_init_state == >>>> being_initialized && _init_thread == current_thread". >>> >>> That seems reasonable. By clearing the init_thread we no longer >>> consider this a recursive initialization by the current thread and >>> take the slow path which will reveal the class is erroneous. >>> >>> Looking at the fast init changes I'm unclear why these assertions are >>> valid: >>> >>> +void LIR_Assembler::clinit_barrier(ciMethod* method) { >>> +? assert(method->holder()->is_being_initialized() || >>> method->holder()->is_initialized(), >>> +???????? "initialization should have been started"); >>> >>> +? if (C->clinit_barrier_on_entry()) { >>> +??? assert(C->method()->holder()->is_being_initialized() || >>> C->method()->holder()->is_initialized(), >>> +?????????? "initialization should have been started"); >>> >>> I'm not sure how we get to these code fragments such that its >>> guaranteed initialization must already have been initiated (and >>> possibly completed) - can't this be the first time we've called a >>> static method and so the current thread would become responsible for >>> doing the initialization? >> >> First of all, sorry for the confusion. I should have mentioned that >> this patch is intended to go in along with the fix for JDK-8225106 >> [1]. It relaxes the aforementioned asserts and makes class error state >> expected. >> >> Still, pre-initialized states shouldn't be seen by JITs there: even in >> -Xcomp mode, first invocation triggers resolution (which initiates >> class initialization) and only then resolved method is submitted for >> compilation. >> >>> And again what if the class is actually in an error state? This ties >>> in to JDK-8225106. >> >> Proposed fix for JDK-8225106 adds new logic which fail the compilation >> if method holder is in error state. Plus, if initialization fails >> after compilation is over, the barrier will forward execution into >> slow path and exception will be thrown during re-resolution. This >> scenario is tested by runtime/clinit/ClassInitBarrier (and the fix >> adds more scenarios). >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/034058.html >> >> >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> Testing: hs-precheckin-comp, tier1-4 >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8223213 From brian.burkhalter at oracle.com Wed Jun 5 18:17:48 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2019 11:17:48 -0700 Subject: RFR: 8207851: Implement JEP 352 In-Reply-To: <3b0f0bcb-4ea0-fe71-acdb-6ca9e44a6d8d@linux.vnet.ibm.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <67ad071d-376b-8b0d-9b2f-42dca17a1041@redhat.com> <3b0f0bcb-4ea0-fe71-acdb-6ca9e44a6d8d@linux.vnet.ibm.com> Message-ID: <1B979240-1C4F-417A-AB82-82A91C0FCA12@oracle.com> Yes, jcheck [1] is a good thing to run for this. Then normalizer [2] can be used to clean them up. Thanks, Brian [1] https://openjdk.java.net/projects/code-tools/jcheck/ [2] /make/scripts/normalizer.pl > On Jun 5, 2019, at 11:13 AM, Gustavo Romero wrote: > > I found some trailing space in v5 and it seems they are in v6 as well. > > You might want to check the followings: -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed Jun 5 18:47:06 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 5 Jun 2019 21:47:06 +0300 Subject: [13] RFR (S): 8225106: C2: Parse::clinit_deopt asserts when holder klass is in error state In-Reply-To: References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com> <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com> Message-ID: Thanks, Martin. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8225106/webrev.01/ One more review, please? >>> Thanks for improving the test. Seems like you currently expect a wrong >> exception: >>> Execution failed: `main' threw exception: java.lang.AssertionError: >> INIT_FAILURE: unexpected exception thrown: expected >> java.lang.NoClassDefFoundError, caught java.lang.AssertionError >> >> More like the error message is a bit misleading: the failure is caused >> by a bug which is addressed by JDK-8225141 [1]. Would providing >> exception message improve the situation? > > Thanks for explaining. I'd appreciate a message improvement, but I don't insist on it. Now it prints [1]: unexpected exception thrown: expected java.lang.NoClassDefFoundError, caught java.lang.AssertionError: INIT_FAILURE: no exception thrown Best regards, Vladimir Ivanov [1] ----------System.err:(23/1765)---------- java.lang.AssertionError: INIT_FAILURE: unexpected exception thrown: expected java.lang.NoClassDefFoundError, caught java.lang.AssertionError: INIT_FAILURE: no exception thrown at ClassInitBarrier.failure(ClassInitBarrier.java:174) at ClassInitBarrier.execute(ClassInitBarrier.java:161) at ClassInitBarrier.lambda$checkBlockingAction$5(ClassInitBarrier.java:326) at ClassInitBarrier.checkBlockingAction(ClassInitBarrier.java:328) at ClassInitBarrier$Test.runTests(ClassInitBarrier.java:110) at ClassInitBarrier$Test.run(ClassInitBarrier.java:144) at ClassInitBarrier.main(ClassInitBarrier.java:444) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:830) Caused by: java.lang.AssertionError: INIT_FAILURE: no exception thrown at ClassInitBarrier.failure(ClassInitBarrier.java:170) at ClassInitBarrier.execute(ClassInitBarrier.java:153) ... 11 more From vladimir.kozlov at oracle.com Wed Jun 5 19:36:13 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Jun 2019 12:36:13 -0700 Subject: [13] RFR (S): 8225106: C2: Parse::clinit_deopt asserts when holder klass is in error state In-Reply-To: References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com> <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com> Message-ID: Looks good. Thanks, Vladimir K. On 6/5/19 11:47 AM, Vladimir Ivanov wrote: > Thanks, Martin. > > Updated webrev: > ? http://cr.openjdk.java.net/~vlivanov/8225106/webrev.01/ > > One more review, please? > >>>> Thanks for improving the test. Seems like you currently expect a wrong >>> exception: >>>> Execution failed: `main' threw exception: java.lang.AssertionError: >>> INIT_FAILURE: unexpected exception thrown: expected >>> java.lang.NoClassDefFoundError, caught java.lang.AssertionError >>> >>> More like the error message is a bit misleading: the failure is caused >>> by a? bug which is addressed by JDK-8225141 [1]. Would providing >>> exception message improve the situation? >> >> Thanks for explaining. I'd appreciate a message improvement, but I don't insist on it. > > Now it prints [1]: unexpected exception thrown: expected java.lang.NoClassDefFoundError, caught > java.lang.AssertionError: INIT_FAILURE: no exception thrown > > Best regards, > Vladimir Ivanov > > [1] > ----------System.err:(23/1765)---------- > java.lang.AssertionError: INIT_FAILURE: unexpected exception thrown: expected java.lang.NoClassDefFoundError, caught > java.lang.AssertionError: INIT_FAILURE: no exception thrown > ? at ClassInitBarrier.failure(ClassInitBarrier.java:174) > ? at ClassInitBarrier.execute(ClassInitBarrier.java:161) > ? at ClassInitBarrier.lambda$checkBlockingAction$5(ClassInitBarrier.java:326) > ? at ClassInitBarrier.checkBlockingAction(ClassInitBarrier.java:328) > ? at ClassInitBarrier$Test.runTests(ClassInitBarrier.java:110) > ? at ClassInitBarrier$Test.run(ClassInitBarrier.java:144) > ? at ClassInitBarrier.main(ClassInitBarrier.java:444) > ? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ? at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ? at java.base/java.lang.reflect.Method.invoke(Method.java:567) > ? at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > ? at java.base/java.lang.Thread.run(Thread.java:830) > Caused by: java.lang.AssertionError: INIT_FAILURE: no exception thrown > ? at ClassInitBarrier.failure(ClassInitBarrier.java:170) > ? at ClassInitBarrier.execute(ClassInitBarrier.java:153) > ? ... 11 more > > From vladimir.kozlov at oracle.com Wed Jun 5 22:20:44 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Jun 2019 15:20:44 -0700 Subject: [13] RFR(S) 8225350: compiler/jvmci/compilerToVM/IsCompilableTest.java timed out Message-ID: <9e3eb6b1-4fec-3fe8-7ea8-d0eec56e11d7@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8225350 http://cr.openjdk.java.net/~kvn/8225350/webrev.00/ Tests which use JVMCICompiler (Graal) explicitly are timed out when run with -Xcomp -XX:-TieredCompilation flags. Run such tests only in Xmixed + TieredCompilation mode. Thanks, Vladimir From vladimir.kozlov at oracle.com Wed Jun 5 22:52:23 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Jun 2019 15:52:23 -0700 Subject: RFR: 8219687: G1 asserts nmethod should not be unloaded during parallel code cache unloading In-Reply-To: References: Message-ID: <26f8fccc-0f60-008d-f22d-42d53beb7058@oracle.com> Assert changes look fine to me. Thanks, Vladimir On 6/3/19 8:39 AM, Erik ?sterlund wrote: > Hi, > > There is an assert that G1 occasionally hits during parallel code cache unloading. > When oops_do() is called to compute is_unloading(), the nmethod should not be unloaded says the assert. > > However... imagine the following scenario: > > A bunch of parallel GC threads are walking the code cache in parallel, unloading dead things. > > GC thread 1 finds nmethod A in the code cache iteration. It is_unloading(), and hence its method()->method_holder() > dependency context is found to need cleaning, and cleaning starts. In that dependency context, it finds nmethod B, which > is asked if it is_unloading(). The result of the question is not cached, and calls oops_do is used to compute the answer. > > GC thread 1 now peempts and wakes up later. > > GC thread 2 finds nmethod B in the code cache iteration. It is_unloading(), and hence made make_unloaded(), eventually > changing the state to unloaded. > > GC thread 1 now wakes up and runs the assert on nmethod B that it must not be unloaded, and we get the stack trace above. > > So there is absolutely no harm with calling oops_do on nmethods that racingly become unloaded here, and that assertion > should just be silenced. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8219687/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8219687 > > Thanks, > /Erik From brian.burkhalter at oracle.com Thu Jun 6 00:06:47 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2019 17:06:47 -0700 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> Message-ID: <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> Hi Andrew, With version 6 [1] of the patch applied, tests throw this exception: Mapped java.lang.InternalError: java.lang.NullPointerException at java.base/jdk.internal.misc.ExtendedMapMode.newMapMode(ExtendedMapMode.java:58) at java.base/jdk.internal.misc.ExtendedMapMode.(ExtendedMapMode.java:40) at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1007) Looks like a problem in the initialization order of the static final constants: MAP_MODE_CONSTRUCTOR needs to be initialized first so I think the *_SYNC constants need to be after the static initializer [2]. Sorry for suggesting the change that was the proximate cause of this. :-( Thanks, Brian [1] http://cr.openjdk.java.net/~adinn/8224974/webrev.06/ [2] diff --- a/src/java.base/share/classes/jdk/internal/misc/ExtendedMapMode.java +++ b/src/java.base/share/classes/jdk/internal/misc/ExtendedMapMode.java @@ -37,10 +37,6 @@ static final MethodHandle MAP_MODE_CONSTRUCTOR; - public static final MapMode READ_ONLY_SYNC = newMapMode("READ_ONLY_SYNC"); - - public static final MapMode READ_WRITE_SYNC = newMapMode("READ_WRITE_SYNC"); - static { try { var lookup = MethodHandles.privateLookupIn(MapMode.class, MethodHandles.lookup()); @@ -51,6 +47,10 @@ } } + public static final MapMode READ_ONLY_SYNC = newMapMode("READ_ONLY_SYNC"); + + public static final MapMode READ_WRITE_SYNC = newMapMode("READ_WRITE_SYNC"); + private static MapMode newMapMode(String name) { try { return (MapMode) MAP_MODE_CONSTRUCTOR.invoke(name); > On Jun 5, 2019, at 10:47 AM, Brian Burkhalter wrote: > > Hi Andrew, > > Please ignore the content below: I see the changes are in version 6 which I had not looked through before posting my previous message. > > Thanks, > > Brian > >> On Jun 5, 2019, at 10:25 AM, Brian Burkhalter > wrote: >> >> I suppose these changes will be in version 7. If it is likely that comments will be forthcoming from others then it might be worth waiting to incorporate any further changes in version 7. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujie at loongson.cn Thu Jun 6 00:20:24 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 6 Jun 2019 08:20:24 +0800 Subject: RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached In-Reply-To: References: <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com> <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com> <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn> <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com> <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com> <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn> <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn> <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn> <1e559921-8d8c-177a-c301-429bc657053a@loongson.cn> <26ee82f6-ffb4-6ce6-daad-fcfc85ef293a@oracle.com> <714d5887-e989-0b64-a7d1-62ad59d66c85@oracle.com> <40c0a440-c10d-ca0d-a766-fdd493db8135@loongson.cn> Message-ID: <0342ff4e-7fc7-66f8-6eed-d723cb93d1fe@loongson.cn> Thanks Vladimir Ivanov and Vladimir Kozlov. On 2019/6/6 ??1:46, Vladimir Ivanov wrote: > No new failures during tier1-4 testing. I'll push the fix for you. From OGATAK at jp.ibm.com Thu Jun 6 07:54:36 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Thu, 6 Jun 2019 16:54:36 +0900 Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic Message-ID: Hi, May I get review of non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic? The original patch itself can be applied cleanly (besides difference of the source directory structure). However, in jdk8u, it also needs to change the arguments of make_runtime_call() based on the CCallingCenventionRequiresAsLongs flag. So I made additional changes to src/share/vm/opto/library_call.cpp and runtime.cpp. To separate the change in the original patch and the additional changes, I made webrev incrementally. webrev.02 below only contains the changes by the original patch, and webrev.03 contains all changes including the additional ones. The difference between the two webrevs is the changes in library_call.cpp and runtime.cpp. Original bug report: https://bugs.openjdk.java.net/browse/JDK-8185979 Webrev based on the original patch: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.02/ Webrev of all changes: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.03/ I verified there is no degradation in jtreg (make test) results in both fastdebug and release builds. Regards, Ogata From martin.doerr at sap.com Thu Jun 6 08:29:07 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 6 Jun 2019 08:29:07 +0000 Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: References: Message-ID: Hi Ogata, looks correct. Best regards, Martin > -----Original Message----- > From: hotspot-compiler-dev bounces at openjdk.java.net> On Behalf Of Kazunori Ogata > Sent: Donnerstag, 6. Juni 2019 09:55 > To: hotspot-compiler-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: > Implement SHA2 intrinsic > > Hi, > > May I get review of non-clean backport of 8185979: PPC64: Implement SHA2 > intrinsic? > > The original patch itself can be applied cleanly (besides difference of > the source directory structure). However, in jdk8u, it also needs to > change the arguments of make_runtime_call() based on the > CCallingCenventionRequiresAsLongs flag. So I made additional changes to > src/share/vm/opto/library_call.cpp and runtime.cpp. > > To separate the change in the original patch and the additional changes, I > made webrev incrementally. webrev.02 below only contains the changes by > the original patch, and webrev.03 contains all changes including the > additional ones. The difference between the two webrevs is the changes in > library_call.cpp and runtime.cpp. > > > Original bug report: > https://bugs.openjdk.java.net/browse/JDK-8185979 > > Webrev based on the original patch: > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.02/ > > Webrev of all changes: > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.03/ > > > I verified there is no degradation in jtreg (make test) results in both > fastdebug and release builds. > > > Regards, > Ogata From OGATAK at jp.ibm.com Thu Jun 6 08:45:51 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Thu, 6 Jun 2019 17:45:51 +0900 Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: References: Message-ID: Hi Martin, Thank you for your review. Regards, Ogata "Doerr, Martin" wrote on 2019/06/06 17:29:07: > From: "Doerr, Martin" > To: Kazunori Ogata , "hotspot-compiler- > dev at openjdk.java.net" , "jdk8u- > dev at openjdk.java.net" > Date: 2019/06/06 17:29 > Subject: [EXTERNAL] RE: [8u-dev, ppc] RFR for non-clean backport of > 8185979: PPC64: Implement SHA2 intrinsic > > Hi Ogata, > > looks correct. > > Best regards, > Martin > > > > -----Original Message----- > > From: hotspot-compiler-dev > bounces at openjdk.java.net> On Behalf Of Kazunori Ogata > > Sent: Donnerstag, 6. Juni 2019 09:55 > > To: hotspot-compiler-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > > Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: > > Implement SHA2 intrinsic > > > > Hi, > > > > May I get review of non-clean backport of 8185979: PPC64: Implement SHA2 > > intrinsic? > > > > The original patch itself can be applied cleanly (besides difference of > > the source directory structure). However, in jdk8u, it also needs to > > change the arguments of make_runtime_call() based on the > > CCallingCenventionRequiresAsLongs flag. So I made additional changes to > > src/share/vm/opto/library_call.cpp and runtime.cpp. > > > > To separate the change in the original patch and the additional changes, I > > made webrev incrementally. webrev.02 below only contains the changes by > > the original patch, and webrev.03 contains all changes including the > > additional ones. The difference between the two webrevs is the changes in > > library_call.cpp and runtime.cpp. > > > > > > Original bug report: > > https://bugs.openjdk.java.net/browse/JDK-8185979 > > > > Webrev based on the original patch: > > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.02/ > > > > Webrev of all changes: > > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.03/ > > > > > > I verified there is no degradation in jtreg (make test) results in both > > fastdebug and release builds. > > > > > > Regards, > > Ogata > > From adinn at redhat.com Thu Jun 6 08:53:20 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 6 Jun 2019 09:53:20 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> Message-ID: <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> Hi Brian, On 06/06/2019 01:06, Brian Burkhalter wrote: > With version 6 [1] of the patch applied, tests throw this exception: > > Mapped java.lang.InternalError: java.lang.NullPointerException > at > java.base/jdk.internal.misc.ExtendedMapMode.newMapMode(ExtendedMapMode.java:58) > at > java.base/jdk.internal.misc.ExtendedMapMode.(ExtendedMapMode.java:40) > at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1007) > > Looks like a problem in the initialization order of the static final > constants: MAP_MODE_CONSTRUCTOR needs to be initialized first so I think > the *_SYNC constants need to be after the static initializer [2]. Doh! Yes, you are right. Sorry for adding confusion. webrev.06 was not meant to be intended for public consumption. I uploaded it last night when I set the rebuild off but I didn't intend to advertise it until I had retested and got your confirmation on the suggestions I made. Anyway, thanks all the same for reviewing it, trying to run it and also finding/fixing this issue. I have updated webrev.06 in place and PmemTest now runs ok. I still need to have Jonathan Halliday test the patch with our Transaction and Data Grid software before it can be properly signed off. Another submit run will also be needed. However, PmemTest is a good enough sanity check to validate the changes you requested. So, here is webrev.06 as the latest official patch: http://cr.openjdk.java.net/~adinn/8224974/webrev.06/ It should address changes requested on this list by Alan and Vladimir all the changes you requested in your review (modulo those you agreed to defer on) the change to correct this static init order bug a change to graal test CheckGraalIntrinsics to declare the new jdk13 intrinsics in alphanum sort order (this was requested offline by Alan -- without it the test refuses to run on jdk13) The last of those changes still leaves one issue unanswered (although it may not actually be an issue). Vladimir is probably best able to comment. When I run CheckGraalIntrinsics (which is actually run indirectly by compiler/graalunit/HotspotTest) with my patched tree it fails, claiming that Graal does not know about Unsafe.writeback0: java.lang.AssertionError: missing Graal intrinsics for: jdk/internal/misc/Unsafe.writeback0(J)V I am assuming this is what is expected to happen? Or perhaps the test is supposed to be added to the problem or exclude lists? > Sorry for suggesting the change that was the proximate cause of this. :-( No problem :-) Thanks for reviewing and checking! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Thu Jun 6 09:13:41 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 6 Jun 2019 10:13:41 +0100 Subject: RFR: 8207851: Implement JEP 352 In-Reply-To: <3b0f0bcb-4ea0-fe71-acdb-6ca9e44a6d8d@linux.vnet.ibm.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <67ad071d-376b-8b0d-9b2f-42dca17a1041@redhat.com> <3b0f0bcb-4ea0-fe71-acdb-6ca9e44a6d8d@linux.vnet.ibm.com> Message-ID: Hi Gustavo, On 05/06/2019 19:13, Gustavo Romero wrote: > I found some trailing space in v5 and it seems they are in v6 as well. Thanks for the heads up. I will fix these in the next webrev (07). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martin.doerr at sap.com Thu Jun 6 09:35:56 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 6 Jun 2019 09:35:56 +0000 Subject: [11u] RFR (Backport): 8177899: Tests fail due to code cache exhaustion on machines with many cores Message-ID: Hi, we noticed that jdk11u is also affected by https://bugs.openjdk.java.net/browse/JDK-8177899 The VM didn't come up on a SPARC machine due to too high upper limit of compiler threads leading to misconfigured code cache. Unfortunately, the original change does not apply cleanly and needs manual resolution. Original change: http://hg.openjdk.java.net/jdk/jdk/rev/0451e0a2f1f5 My backport: http://cr.openjdk.java.net/~mdoerr/8177899_code_cache/jdk11u/webrev.00/ Here's the complete list of what I had to integrate manually: compile.cpp: Does not apply cleanly because of conflict with JDK-8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset Trivial to resolve: Original JDK-8177899 removes this part of JDK-8209594. We just need to take the new line: int size = C2Compiler::initial_code_buffer_size(const_size); compilationPolicy.cpp: Does not apply cleanly because neighboring hunk has changed: JDK-8214206: Fix for JDK-8213419 is broken on 32-bit Just need to insert code manually next to where log2_int was changed to log2_intptr. tieredThresholdPolicy.cpp: Does not apply cleanly because the file was renamed: JDK-8209186: Rename SimpleThresholdPolicy to TieredThresholdPolicy Change needs to get applied to simpleThresholdPolicy.cpp instead. Not difficult. Please review. I'm targeting to 11.0.5. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Thu Jun 6 09:46:29 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 6 Jun 2019 10:46:29 +0100 Subject: RFR: 8207851: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <67ad071d-376b-8b0d-9b2f-42dca17a1041@redhat.com> <3b0f0bcb-4ea0-fe71-acdb-6ca9e44a6d8d@linux.vnet.ibm.com> Message-ID: <5c3af4bf-32f8-2f73-2263-b3aa77e84c66@redhat.com> On 6/6/19 10:13 AM, Andrew Dinn wrote: > On 05/06/2019 19:13, Gustavo Romero wrote: >> I found some trailing space in v5 and it seems they are in v6 as well. > Thanks for the heads up. I will fix these in the next webrev (07). Handy hint. In your .emacs, add this: (add-hook 'java-mode-hook (lambda () (progn (set-variable 'show-trailing-whitespace t) ))) (add-hook 'c-mode-hook (lambda () (progn (set-variable 'show-trailing-whitespace t) ))) ...and you'll never have any trouble with trailing whitespace again. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Jun 6 12:15:15 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 6 Jun 2019 13:15:15 +0100 Subject: RFR: 8207851: Implement JEP 352 In-Reply-To: <5c3af4bf-32f8-2f73-2263-b3aa77e84c66@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <67ad071d-376b-8b0d-9b2f-42dca17a1041@redhat.com> <3b0f0bcb-4ea0-fe71-acdb-6ca9e44a6d8d@linux.vnet.ibm.com> <5c3af4bf-32f8-2f73-2263-b3aa77e84c66@redhat.com> Message-ID: On 06/06/2019 10:46, Andrew Haley wrote: > Handy hint. In your .emacs, add this: > > ;;; goodbye trailing whitespace blues!!! > > (add-hook 'java-mode-hook > (lambda () > (progn > (set-variable 'show-trailing-whitespace t) > ))) > > (add-hook 'c-mode-hook > (lambda () > (progn > (set-variable 'show-trailing-whitespace t) > ))) > > > (add-hook 'c++-mode-hook > (lambda () > (progn > (set-variable 'show-trailing-whitespace t) > ))) There, fixed that for ya! > ...and you'll never have any trouble with trailing whitespace again. Now working beautifully, thank you! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.x.ivanov at oracle.com Thu Jun 6 12:25:32 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 6 Jun 2019 15:25:32 +0300 Subject: [13] RFR (S): 8225106: C2: Parse::clinit_deopt asserts when holder klass is in error state In-Reply-To: References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com> <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com> Message-ID: Thanks, Vladimir. Best regards, Vladimir Ivanov On 05/06/2019 22:36, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir K. > > On 6/5/19 11:47 AM, Vladimir Ivanov wrote: >> Thanks, Martin. >> >> Updated webrev: >> ?? http://cr.openjdk.java.net/~vlivanov/8225106/webrev.01/ >> >> One more review, please? >> >>>>> Thanks for improving the test. Seems like you currently expect a wrong >>>> exception: >>>>> Execution failed: `main' threw exception: java.lang.AssertionError: >>>> INIT_FAILURE: unexpected exception thrown: expected >>>> java.lang.NoClassDefFoundError, caught java.lang.AssertionError >>>> >>>> More like the error message is a bit misleading: the failure is caused >>>> by a? bug which is addressed by JDK-8225141 [1]. Would providing >>>> exception message improve the situation? >>> >>> Thanks for explaining. I'd appreciate a message improvement, but I >>> don't insist on it. >> >> Now it prints [1]: unexpected exception thrown: expected >> java.lang.NoClassDefFoundError, caught java.lang.AssertionError: >> INIT_FAILURE: no exception thrown >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> ----------System.err:(23/1765)---------- >> java.lang.AssertionError: INIT_FAILURE: unexpected exception thrown: >> expected java.lang.NoClassDefFoundError, caught >> java.lang.AssertionError: INIT_FAILURE: no exception thrown >> ?? at ClassInitBarrier.failure(ClassInitBarrier.java:174) >> ?? at ClassInitBarrier.execute(ClassInitBarrier.java:161) >> ?? at >> ClassInitBarrier.lambda$checkBlockingAction$5(ClassInitBarrier.java:326) >> ?? at ClassInitBarrier.checkBlockingAction(ClassInitBarrier.java:328) >> ?? at ClassInitBarrier$Test.runTests(ClassInitBarrier.java:110) >> ?? at ClassInitBarrier$Test.run(ClassInitBarrier.java:144) >> ?? at ClassInitBarrier.main(ClassInitBarrier.java:444) >> ?? at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> ?? at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> ?? at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> ?? at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> ?? at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> >> ?? at java.base/java.lang.Thread.run(Thread.java:830) >> Caused by: java.lang.AssertionError: INIT_FAILURE: no exception thrown >> ?? at ClassInitBarrier.failure(ClassInitBarrier.java:170) >> ?? at ClassInitBarrier.execute(ClassInitBarrier.java:153) >> ?? ... 11 more >> >> From martin.doerr at sap.com Thu Jun 6 12:27:46 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 6 Jun 2019 12:27:46 +0000 Subject: RFR(M): 8224826: Implement fast class initialization checks on PPC64 In-Reply-To: References: Message-ID: Hi, please review the rebased and updated version (after JDK-8225106): http://cr.openjdk.java.net/~mdoerr/8224826_ppc64_fast_clinit/webrev.01/ Best regards, Martin Hi, please review the PPC64 implementation of JDK-8223213: http://cr.openjdk.java.net/~mdoerr/8224826_ppc64_fast_clinit/webrev.00/ x86 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9ad765641e8f Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Jun 6 12:29:14 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 6 Jun 2019 12:29:14 +0000 Subject: RFR(M): 8224827: Implement fast class initialization checks on s390 In-Reply-To: References: Message-ID: Hi, please review the rebased and updated version (after JDK-8225106): http://cr.openjdk.java.net/~mdoerr/8224827_s390_fast_clinit/webrev.01/ Note: Applies on top of JDK-8223249 which is still waiting for a 2nd review. Best regards, Martin Hi, please review the s390 implementation of JDK-8223213: http://cr.openjdk.java.net/~mdoerr/8224827_s390_fast_clinit/webrev.00/ x86 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9ad765641e8f Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Thu Jun 6 12:32:44 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 6 Jun 2019 15:32:44 +0300 Subject: RFR(M): 8224826: Implement fast class initialization checks on PPC64 In-Reply-To: References: Message-ID: <441c82a9-57ac-38a8-3326-4f648db64e57@oracle.com> Looks good. Best regards, Vladimir Ivanov On 06/06/2019 15:27, Doerr, Martin wrote: > Hi, > > please review the rebased and updated version (after JDK-8225106): > http://cr.openjdk.java.net/~mdoerr/8224826_ppc64_fast_clinit/webrev.01/ > > Best regards, > Martin > > > Hi, > > please review the PPC64 implementation of JDK-8223213: > http://cr.openjdk.java.net/~mdoerr/8224826_ppc64_fast_clinit/webrev.00/ > > x86 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9ad765641e8f > > Best regards, > Martin > From vladimir.x.ivanov at oracle.com Thu Jun 6 12:33:26 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 6 Jun 2019 15:33:26 +0300 Subject: RFR(M): 8224827: Implement fast class initialization checks on s390 In-Reply-To: References: Message-ID: Looks good. Best regards, Vladimir Ivanov On 06/06/2019 15:29, Doerr, Martin wrote: > Hi, > > please review the rebased and updated version (after JDK-8225106): > http://cr.openjdk.java.net/~mdoerr/8224827_s390_fast_clinit/webrev.01/ > > Note: Applies on top of JDK-8223249 which is still waiting for a 2nd review. > > Best regards, > Martin > > > > Hi, > > please review the s390 implementation of JDK-8223213: > http://cr.openjdk.java.net/~mdoerr/8224827_s390_fast_clinit/webrev.00/ > > x86 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9ad765641e8f > > Best regards, > Martin > From brian.burkhalter at oracle.com Thu Jun 6 16:24:42 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 6 Jun 2019 09:24:42 -0700 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> Message-ID: <13D82172-FEA3-4F9C-8887-974A770E3FFA@oracle.com> Hi Andrew, > On Jun 6, 2019, at 1:53 AM, Andrew Dinn wrote: > > [?] > > I have updated webrev.06 in place and PmemTest now runs ok. I still need > to have Jonathan Halliday test the patch with our Transaction and Data > Grid software before it can be properly signed off. Another submit run > will also be needed. However, PmemTest is a good enough sanity check to > validate the changes you requested. > > So, here is webrev.06 as the latest official patch: > > http://cr.openjdk.java.net/~adinn/8224974/webrev.06/ I am running it through our tests now. > It should address > > [?] > > The last of those changes still leaves one issue unanswered (although it > may not actually be an issue). Vladimir is probably best able to comment. > > When I run CheckGraalIntrinsics (which is actually run indirectly by > compiler/graalunit/HotspotTest) with my patched tree it fails, claiming > that Graal does not know about Unsafe.writeback0: > > java.lang.AssertionError: missing Graal intrinsics for: > jdk/internal/misc/Unsafe.writeback0(J)V > > I am assuming this is what is expected to happen? Or perhaps the test is > supposed to be added to the problem or exclude lists? I?ll leave it to Vladimir or someone else more knowledgeable than I to comment on this area. >> Sorry for suggesting the change that was the proximate cause of this. :-( > No problem :-) Thanks for reviewing and checking! You are welcome! Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Jun 6 17:40:25 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 10:40:25 -0700 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> Message-ID: <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> Hotspot changes looks good. CheckGraalIntrinsics failed because of typo - you should use 'J' instead of 'L': + "jdk/internal/misc/Unsafe.writeback0(L)V", One nitpick in vmSymbols.hpp spacing is off in next line: + do_intrinsic(_writebackPostSync0, jdk_internal_misc_Unsafe, writebackPostSync0_name, void_method_signature , F_RN) \ Thanks, Vladimir On 6/6/19 1:53 AM, Andrew Dinn wrote: > Hi Brian, > > On 06/06/2019 01:06, Brian Burkhalter wrote: >> With version 6 [1] of the patch applied, tests throw this exception: >> >> Mapped java.lang.InternalError: java.lang.NullPointerException >> at >> java.base/jdk.internal.misc.ExtendedMapMode.newMapMode(ExtendedMapMode.java:58) >> at >> java.base/jdk.internal.misc.ExtendedMapMode.(ExtendedMapMode.java:40) >> at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1007) >> >> Looks like a problem in the initialization order of the static final >> constants: MAP_MODE_CONSTRUCTOR needs to be initialized first so I think >> the *_SYNC constants need to be after the static initializer [2]. > > Doh! Yes, you are right. > > Sorry for adding confusion. webrev.06 was not meant to be intended for > public consumption. I uploaded it last night when I set the rebuild off > but I didn't intend to advertise it until I had retested and got your > confirmation on the suggestions I made. Anyway, thanks all the same for > reviewing it, trying to run it and also finding/fixing this issue. > > I have updated webrev.06 in place and PmemTest now runs ok. I still need > to have Jonathan Halliday test the patch with our Transaction and Data > Grid software before it can be properly signed off. Another submit run > will also be needed. However, PmemTest is a good enough sanity check to > validate the changes you requested. > > So, here is webrev.06 as the latest official patch: > > http://cr.openjdk.java.net/~adinn/8224974/webrev.06/ > > It should address > > changes requested on this list by Alan and Vladimir > > all the changes you requested in your review > (modulo those you agreed to defer on) > > the change to correct this static init order bug > > a change to graal test CheckGraalIntrinsics to declare > the new jdk13 intrinsics in alphanum sort order > (this was requested offline by Alan -- without it the test > refuses to run on jdk13) > > The last of those changes still leaves one issue unanswered (although it > may not actually be an issue). Vladimir is probably best able to comment. > > When I run CheckGraalIntrinsics (which is actually run indirectly by > compiler/graalunit/HotspotTest) with my patched tree it fails, claiming > that Graal does not know about Unsafe.writeback0: > > java.lang.AssertionError: missing Graal intrinsics for: > jdk/internal/misc/Unsafe.writeback0(J)V > > I am assuming this is what is expected to happen? Or perhaps the test is > supposed to be added to the problem or exclude lists? > >> Sorry for suggesting the change that was the proximate cause of this. :-( > No problem :-) Thanks for reviewing and checking! > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From nils.eliasson at oracle.com Thu Jun 6 18:03:29 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 6 Jun 2019 20:03:29 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <87ftoofnp4.fsf@redhat.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <87k1e39hno.fsf@redhat.com> <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> <87ftoofnp4.fsf@redhat.com> Message-ID: <96902012-a7e3-86ea-c7e5-65896708bc4a@oracle.com> On 2019-06-05 10:20, Roland Westrelin wrote: >> Ah - I think I get it. You mean like this: >> >> void ZBarrierSetC2::barrier_insertion_phase(PhaseIterGVN& igvn)const { >> PhaseIdealLoop ideal_loop(igvn,LoopOptsNone); >> >> // First make sure all loads between call and catch are moved to the >> catch block clean_catch_blocks(&ideal_loop); >> >> // Then expand barriers on all loads insert_load_barriers(&ideal_loop); >> >> // Handle all Unsafe that need barriers. insert_barriers_on_unsafe(&ideal_loop); >> >> // Cleanup any modified bits igvn.optimize(); >> >> igvn.C->clear_major_progress(); >> } >> >> An excellent idea. Then I can remove the new LoopOptsMode::BarrierInsertion. > I was thinking something like what we do in Shenandoah for barrier > expansion: > > PhaseIdealLoop ideal_loop(igvn, LoopOptsShenandoahExpand); > > ShenandoahBarrierSetC2::is_gc_specific_loop_opts_pass() returns true for > LoopOptsShenandoahExpand and ShenandoahBarrierSetC2::optimize_loops() > handles LoopOptsShenandoahExpand. So there's nothing shenandoah specific > in PhaseIdealLoop::build_and_optimize(). I followed your example and changed my implementation inline with that. > >> I've been running some experiments with asserts on the clone code. >> >> 1) There can never be any control flow here - so now phis or such. >> >> 2) Stores have explicit control - and would never be scheduled here either. >> >> 3) Loads - they end up here because they can float. They only matter if >> there is a use dominated by the catch (after a merge of catch control >> flow), or uses in more than one catch-proj branch. The only nodes >> observed being cloned is LoadPNodes with barriers, BoolNodes, and CmpP >> nodes. It's the same pattern of comparing a pointer. All other load has >> it's control in the catch-projs. >> >> I will add asserts to the clone in fixup_uses_in_catch to reflect this >> conclusion and make sure that I catch any change in behavior. > I was thinking of something like: > > try { > non_inlined_call1(); > int v = some_object.object_field.int_field; > non_inlined_call2(v, v); > } catch (..) { > int v = some_object.object_field.int_field; > // some use for v > } > > So there would be a LoadP, a load barrier and a LoadI right after the > call. The LoadI is the first to be cloned. It has 3 uses, so it's cloned > 3 times? Which would mean non_inlined_call2 is actually called with: > > SomeObject object = some_object.object_field; > non_inlined_call2(object.int_field, object.int_field); > > the field is reloaded and that code doesn't have the same effect as > above. Or am I missing something? The object_field usually gets a null-check which creates a control flow that anchors the LoadI further down. I managed to find one case in specjbb with a static call followed by a LoadL. I fixed this by calling the call_catch_cleanup recursively on these load, when encountered. They will then be handled in the same way as the LoadPs with a barrier. I also found an issue that I could get duplicate phis in blocks when connecting the loads together. I fixed this by keeping track on which regions has gotten a phi, and caching them. I've also added a number of small fixes after feedback from Erik ?. New webrev: http://cr.openjdk.java.net/~neliasso/8224675/webrev.06/ Regards, Nils > > Roland. From igor.ignatyev at oracle.com Thu Jun 6 18:23:10 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 11:23:10 -0700 Subject: [13] RFR(S) 8225350: compiler/jvmci/compilerToVM/IsCompilableTest.java timed out In-Reply-To: <9e3eb6b1-4fec-3fe8-7ea8-d0eec56e11d7@oracle.com> References: <9e3eb6b1-4fec-3fe8-7ea8-d0eec56e11d7@oracle.com> Message-ID: <73669281-F06A-46AE-BFEB-E9BC307F62CD@oracle.com> Hi Vladimir, am I right assuming that +TieredCompilation is required only till we get libgraal? if so, I'd prefer to have them as separate @require directives (jtreg join all @require by logical-and) and preceded by @comment saying they are they needed and when they can be remove, smth like this: > diff -r f5dfbaa152ef test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java > --- a/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Wed Jun 05 18:28:03 2019 -0700 > +++ b/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Thu Jun 06 11:21:51 2019 -0700 > @@ -25,7 +25,9 @@ > * @test TestBasicLogOutput > * @bug 8203370 > * @summary Ensure -XX:-JVMCIPrintProperties can be enabled and successfully prints expected output to stdout. > - * @requires vm.jvmci > + * @requires vm.jvmci && vm.compMode == "Xmixed" > + * @comment graal w/ -Tiered is too slow, excluding this combination till we get libgraal (JDK-8207267), > + * @requires !vm.graal.enabled | vm.opt.TieredCompilation == null | vm.opt.TieredCompilation == true > * @library /test/lib > */ -- Igor > On Jun 5, 2019, at 3:20 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8225350 > http://cr.openjdk.java.net/~kvn/8225350/webrev.00/ > > Tests which use JVMCICompiler (Graal) explicitly are timed out when run with -Xcomp -XX:-TieredCompilation flags. > > Run such tests only in Xmixed + TieredCompilation mode. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Jun 6 18:33:32 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 11:33:32 -0700 Subject: [13] RFR(S) 8225350: compiler/jvmci/compilerToVM/IsCompilableTest.java timed out In-Reply-To: <73669281-F06A-46AE-BFEB-E9BC307F62CD@oracle.com> References: <9e3eb6b1-4fec-3fe8-7ea8-d0eec56e11d7@oracle.com> <73669281-F06A-46AE-BFEB-E9BC307F62CD@oracle.com> Message-ID: <70CC384E-4A80-4D63-8459-EE8CACBA195B@oracle.com> Good suggestion. I will do that. Thanks Vladimir > On Jun 6, 2019, at 11:23 AM, Igor Ignatyev wrote: > > Hi Vladimir, > > am I right assuming that +TieredCompilation is required only till we get libgraal? if so, I'd prefer to have them as separate @require directives (jtreg join all @require by logical-and) and preceded by @comment saying they are they needed and when they can be remove, smth like this: > >> diff -r f5dfbaa152ef test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java >> --- a/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Wed Jun 05 18:28:03 2019 -0700 >> +++ b/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Thu Jun 06 11:21:51 2019 -0700 >> @@ -25,7 +25,9 @@ >> * @test TestBasicLogOutput >> * @bug 8203370 >> * @summary Ensure -XX:-JVMCIPrintProperties can be enabled and successfully prints expected output to stdout. >> - * @requires vm.jvmci >> + * @requires vm.jvmci && vm.compMode == "Xmixed" >> + * @comment graal w/ -Tiered is too slow, excluding this combination till we get libgraal (JDK-8207267), >> + * @requires !vm.graal.enabled | vm.opt.TieredCompilation == null | vm.opt.TieredCompilation == true >> * @library /test/lib >> */ > > -- Igor > >> On Jun 5, 2019, at 3:20 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8225350 >> http://cr.openjdk.java.net/~kvn/8225350/webrev.00/ >> >> Tests which use JVMCICompiler (Graal) explicitly are timed out when run with -Xcomp -XX:-TieredCompilation flags. >> >> Run such tests only in Xmixed + TieredCompilation mode. >> >> Thanks, >> Vladimir > From igor.ignatyev at oracle.com Thu Jun 6 18:35:53 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 11:35:53 -0700 Subject: RFR(T) : 8225450 : use @file in CtwRunner Message-ID: http://cr.openjdk.java.net/~iignatyev//8225450/webrev.00/index.html > 34 lines changed: 5 ins; 0 del; 29 mod; Hi all, could you please review this trivial patch for CtwRunner which makes it more robust? from JBS: > I've noticed that CtwRunner might fail when used to compile a big set of jar files on windows due to exceeding command line length limit. the fix is to save command line to a file and pass this file to java launcher as @file. webrev: http://cr.openjdk.java.net/~iignatyev//8225450/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8225450 testing: - test/hotspot/jtreg/applications/ctw/modules - manually check that the previously failing execution works on windows Thanks, -- Igor From vladimir.kozlov at oracle.com Thu Jun 6 18:51:23 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 11:51:23 -0700 Subject: RFR(T) : 8225450 : use @file in CtwRunner In-Reply-To: References: Message-ID: <3b1b6fe9-3ee4-874f-ec8d-fe0d79d5af11@oracle.com> Good. Thanks, Vladimir On 6/6/19 11:35 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8225450/webrev.00/index.html >> 34 lines changed: 5 ins; 0 del; 29 mod; > > Hi all, > > could you please review this trivial patch for CtwRunner which makes it more robust? > from JBS: >> I've noticed that CtwRunner might fail when used to compile a big set of jar files on windows due to exceeding command line length limit. the fix is to save command line to a file and pass this file to java launcher as @file. > > webrev: http://cr.openjdk.java.net/~iignatyev//8225450/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8225450 > testing: > - test/hotspot/jtreg/applications/ctw/modules > - manually check that the previously failing execution works on windows > > Thanks, > -- Igor > From brian.burkhalter at oracle.com Thu Jun 6 18:59:56 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 6 Jun 2019 11:59:56 -0700 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <13D82172-FEA3-4F9C-8887-974A770E3FFA@oracle.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <13D82172-FEA3-4F9C-8887-974A770E3FFA@oracle.com> Message-ID: <9F355689-D204-4C28-9EA3-602930CA07D1@oracle.com> Hi Andrew, > On Jun 6, 2019, at 9:24 AM, Brian Burkhalter wrote: > >> So, here is webrev.06 as the latest official patch: >> >> http://cr.openjdk.java.net/~adinn/8224974/webrev.06/ I created a delta webrev versus version 5 and this looks good modulo the trailing whitespace which I think you wrote you were going to fix in version 7. > I am running it through our tests now. All tier 1-3 tests passed on our four usual platforms. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.osterlund at oracle.com Thu Jun 6 19:06:25 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 6 Jun 2019 21:06:25 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <96902012-a7e3-86ea-c7e5-65896708bc4a@oracle.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <87k1e39hno.fsf@redhat.com> <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> <87ftoofnp4.fsf@redhat.com> <96902012-a7e3-86ea-c7e5-65896708bc4a@oracle.com> Message-ID: Hi Nils, One final nit... could you please remove the now seemingly unnecessary "friend class ZBarrierSetC2" in PhaseIdealLoop? I don't need another webrev for that. This looks good. Great job Nils. This will improve the robustness of our barriers. /Erik On 2019-06-06 20:03, Nils Eliasson wrote: > > On 2019-06-05 10:20, Roland Westrelin wrote: >>> Ah - I think I get it. You mean like this: >>> >>> void ZBarrierSetC2::barrier_insertion_phase(PhaseIterGVN& igvn)const { >>> ??? PhaseIdealLoop ideal_loop(igvn,LoopOptsNone); >>> >>> ??? // First make sure all loads between call and catch are moved to the >>> catch block clean_catch_blocks(&ideal_loop); >>> >>> ??? // Then expand barriers on all loads >>> insert_load_barriers(&ideal_loop); >>> >>> ??? // Handle all Unsafe that need barriers. >>> insert_barriers_on_unsafe(&ideal_loop); >>> >>> ??? // Cleanup any modified bits igvn.optimize(); >>> >>> ??? igvn.C->clear_major_progress(); >>> } >>> >>> An excellent idea. Then I can remove the new >>> LoopOptsMode::BarrierInsertion. >> I was thinking something like what we do in Shenandoah for barrier >> expansion: >> >> PhaseIdealLoop ideal_loop(igvn, LoopOptsShenandoahExpand); >> >> ShenandoahBarrierSetC2::is_gc_specific_loop_opts_pass() returns true for >> LoopOptsShenandoahExpand and ShenandoahBarrierSetC2::optimize_loops() >> handles LoopOptsShenandoahExpand. So there's nothing shenandoah specific >> in PhaseIdealLoop::build_and_optimize(). > > I followed your example and changed my implementation inline with that. > > >> >>> I've been running some experiments with asserts on the clone code. >>> >>> 1) There can never be any control flow here - so now phis or such. >>> >>> 2) Stores have explicit control - and would never be scheduled here >>> either. >>> >>> 3) Loads - they end up here because they can float. They only matter if >>> there is a use dominated by the catch (after a merge of catch control >>> flow), or uses in more than one catch-proj branch. The only nodes >>> observed being cloned is LoadPNodes with barriers, BoolNodes, and CmpP >>> nodes. It's the same pattern of comparing a pointer. All other load has >>> it's control in the catch-projs. >>> >>> I will add asserts to the clone in fixup_uses_in_catch to reflect this >>> conclusion and make sure that I catch any change in behavior. >> I was thinking of something like: >> >> try { >> ?? non_inlined_call1(); >> ?? int v = some_object.object_field.int_field; >> ?? non_inlined_call2(v, v); >> } catch (..) { >> ?? int v = some_object.object_field.int_field; >> ?? // some use for v >> } >> >> So there would be a LoadP, a load barrier and a LoadI right after the >> call. The LoadI is the first to be cloned. It has 3 uses, so it's cloned >> 3 times? Which would mean non_inlined_call2 is actually called with: >> >> ?? SomeObject object = some_object.object_field; >> ?? non_inlined_call2(object.int_field, object.int_field); >> >> the field is reloaded and that code doesn't have the same effect as >> above. Or am I missing something? > > The object_field usually gets a null-check which creates a control flow > that anchors the LoadI further down. I managed to find one case in > specjbb with a static call followed by a LoadL. > > I fixed this by calling the call_catch_cleanup recursively on these > load, when encountered. They will then be handled in the same way as the > LoadPs with a barrier. > > I also found an issue that I could get duplicate phis in blocks when > connecting the loads together. I fixed this by keeping track on which > regions has gotten a phi, and caching them. > > I've also added a number of small fixes after feedback from Erik ?. > > New webrev: http://cr.openjdk.java.net/~neliasso/8224675/webrev.06/ > > Regards, > > Nils > > >> >> Roland. From vladimir.kozlov at oracle.com Thu Jun 6 20:14:51 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 13:14:51 -0700 Subject: [13] RFR(S) 8208379: compiler/jvmci/events/JvmciNotifyInstallEventTest.java failed with "Got unexpected event count after 2nd install attempt: expected 9 to equal 2" Message-ID: http://cr.openjdk.java.net/~kvn/8208379/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8208379 Two JVMCI tests use own EmptyCompiler test compiler instead of Graal to control produced JVMCI events. We should not run these tests with Graal. Note, I removed the run with Graal in JvmciNotifyInstallEventTest.java test which I incorrectly added in my changes for JDK-8225019. Thanks, Vladimir From igor.ignatyev at oracle.com Thu Jun 6 20:50:43 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 13:50:43 -0700 Subject: RFR(T) : 8225450 : use @file in CtwRunner In-Reply-To: <3b1b6fe9-3ee4-874f-ec8d-fe0d79d5af11@oracle.com> References: <3b1b6fe9-3ee4-874f-ec8d-fe0d79d5af11@oracle.com> Message-ID: <0CB41A12-919A-4F09-B59F-3F9623616B29@oracle.com> thanks Vladimir! pushed. -- Igor > On Jun 6, 2019, at 11:51 AM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 6/6/19 11:35 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8225450/webrev.00/index.html >>> 34 lines changed: 5 ins; 0 del; 29 mod; >> Hi all, >> could you please review this trivial patch for CtwRunner which makes it more robust? >> from JBS: >>> I've noticed that CtwRunner might fail when used to compile a big set of jar files on windows due to exceeding command line length limit. the fix is to save command line to a file and pass this file to java launcher as @file. >> webrev: http://cr.openjdk.java.net/~iignatyev//8225450/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225450 >> testing: >> - test/hotspot/jtreg/applications/ctw/modules >> - manually check that the previously failing execution works on windows >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Thu Jun 6 20:53:27 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 13:53:27 -0700 Subject: [13] RFR(S) 8208379: compiler/jvmci/events/JvmciNotifyInstallEventTest.java failed with "Got unexpected event count after 2nd install attempt: expected 9 to equal 2" In-Reply-To: References: Message-ID: <25D855F1-0C28-4AEE-AF01-F2602CBA5595@oracle.com> Hi Vladimir, sounds reasonable. I have one question though. as far as I can see, 8225019 just added "-Djvmci.Compiler=graal" to L#50: > - * -Xbootclasspath/a:. -Xmixed > + * -Djvmci.Compiler=graal -Xbootclasspath/a:. -Xmixed why are you removing the whole @run? Thanks -- Igor > On Jun 6, 2019, at 1:14 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8208379/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8208379 > > Two JVMCI tests use own EmptyCompiler test compiler instead of Graal to control produced JVMCI events. > We should not run these tests with Graal. > > Note, I removed the run with Graal in JvmciNotifyInstallEventTest.java test which I incorrectly added in my changes for JDK-8225019. > > Thanks, > Vladimir From igor.ignatyev at oracle.com Thu Jun 6 21:17:36 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 14:17:36 -0700 Subject: RFR(S) : 8149040 : Cleanup compiler/jsr292/NonInlinedCall tests after JDK-8148994 Message-ID: http://cr.openjdk.java.net/~iignatyev//8149040/webrev.00/index.html > 168 lines changed: 1 ins; 162 del; 5 mod; Hi all, could you please review this small clean up in NonInlinedCall tests? testing: tier1 + compiler/jsr292 webrev: http://cr.openjdk.java.net/~iignatyev//8149040/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8149040 Thanks, -- Igor From vladimir.kozlov at oracle.com Thu Jun 6 21:53:43 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 14:53:43 -0700 Subject: RFR(S) : 8149040 : Cleanup compiler/jsr292/NonInlinedCall tests after JDK-8148994 In-Reply-To: References: Message-ID: <35CF8810-C61E-40CC-AFA6-20AC385B74D6@oracle.com> Good. Thanks Vladimir > On Jun 6, 2019, at 2:17 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8149040/webrev.00/index.html >> 168 lines changed: 1 ins; 162 del; 5 mod; > > Hi all, > > could you please review this small clean up in NonInlinedCall tests? > > testing: tier1 + compiler/jsr292 > webrev: http://cr.openjdk.java.net/~iignatyev//8149040/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8149040 > > Thanks, > -- Igor From vladimir.kozlov at oracle.com Thu Jun 6 22:01:16 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 15:01:16 -0700 Subject: [13] RFR(S) 8208379: compiler/jvmci/events/JvmciNotifyInstallEventTest.java failed with "Got unexpected event count after 2nd install attempt: expected 9 to equal 2" In-Reply-To: <25D855F1-0C28-4AEE-AF01-F2602CBA5595@oracle.com> References: <25D855F1-0C28-4AEE-AF01-F2602CBA5595@oracle.com> Message-ID: <81bbc142-be1a-2cc7-1029-490bde8edfcf@oracle.com> On 6/6/19 1:53 PM, Igor Ignatyev wrote: > Hi Vladimir, > > sounds reasonable. I have one question though. as far as I can see, 8225019 just added "-Djvmci.Compiler=graal" to L#50: >> - * -Xbootclasspath/a:. -Xmixed >> + * -Djvmci.Compiler=graal -Xbootclasspath/a:. -Xmixed > > why are you removing the whole @run? By default without explicit -Djvmci.Compiler= JVMCI will select Graal and we will have the same issue as this bug. Thanks, Vladimir > > Thanks > -- Igor > >> On Jun 6, 2019, at 1:14 PM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8208379/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8208379 >> >> Two JVMCI tests use own EmptyCompiler test compiler instead of Graal to control produced JVMCI events. >> We should not run these tests with Graal. >> >> Note, I removed the run with Graal in JvmciNotifyInstallEventTest.java test which I incorrectly added in my changes for JDK-8225019. > >> >> Thanks, >> Vladimir > From igor.ignatyev at oracle.com Thu Jun 6 22:04:48 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 15:04:48 -0700 Subject: [13] RFR(S) 8208379: compiler/jvmci/events/JvmciNotifyInstallEventTest.java failed with "Got unexpected event count after 2nd install attempt: expected 9 to equal 2" In-Reply-To: <81bbc142-be1a-2cc7-1029-490bde8edfcf@oracle.com> References: <25D855F1-0C28-4AEE-AF01-F2602CBA5595@oracle.com> <81bbc142-be1a-2cc7-1029-490bde8edfcf@oracle.com> Message-ID: > On Jun 6, 2019, at 3:01 PM, Vladimir Kozlov wrote: > > On 6/6/19 1:53 PM, Igor Ignatyev wrote: >> Hi Vladimir, >> sounds reasonable. I have one question though. as far as I can see, 8225019 just added "-Djvmci.Compiler=graal" to L#50: >>> - * -Xbootclasspath/a:. -Xmixed >>> + * -Djvmci.Compiler=graal -Xbootclasspath/a:. -Xmixed >> why are you removing the whole @run? > > By default without explicit -Djvmci.Compiler= JVMCI will select Graal and we will have the same issue as this bug. ok, I see. LGTM. -- Igor > > Thanks, > Vladimir > >> Thanks >> -- Igor >>> On Jun 6, 2019, at 1:14 PM, Vladimir Kozlov wrote: >>> >>> http://cr.openjdk.java.net/~kvn/8208379/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8208379 >>> >>> Two JVMCI tests use own EmptyCompiler test compiler instead of Graal to control produced JVMCI events. >>> We should not run these tests with Graal. >>> >>> Note, I removed the run with Graal in JvmciNotifyInstallEventTest.java test which I incorrectly added in my changes for JDK-8225019. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Thu Jun 6 22:06:14 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 15:06:14 -0700 Subject: [13] RFR(S) 8208379: compiler/jvmci/events/JvmciNotifyInstallEventTest.java failed with "Got unexpected event count after 2nd install attempt: expected 9 to equal 2" In-Reply-To: References: <25D855F1-0C28-4AEE-AF01-F2602CBA5595@oracle.com> <81bbc142-be1a-2cc7-1029-490bde8edfcf@oracle.com> Message-ID: Thanks, Vladimir On 6/6/19 3:04 PM, Igor Ignatyev wrote: > >> On Jun 6, 2019, at 3:01 PM, Vladimir Kozlov wrote: >> >> On 6/6/19 1:53 PM, Igor Ignatyev wrote: >>> Hi Vladimir, >>> sounds reasonable. I have one question though. as far as I can see, 8225019 just added "-Djvmci.Compiler=graal" to L#50: >>>> - * -Xbootclasspath/a:. -Xmixed >>>> + * -Djvmci.Compiler=graal -Xbootclasspath/a:. -Xmixed >>> why are you removing the whole @run? >> >> By default without explicit -Djvmci.Compiler= JVMCI will select Graal and we will have the same issue as this bug. > ok, I see. LGTM. > > -- Igor >> >> Thanks, >> Vladimir >> >>> Thanks >>> -- Igor >>>> On Jun 6, 2019, at 1:14 PM, Vladimir Kozlov wrote: >>>> >>>> http://cr.openjdk.java.net/~kvn/8208379/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8208379 >>>> >>>> Two JVMCI tests use own EmptyCompiler test compiler instead of Graal to control produced JVMCI events. >>>> We should not run these tests with Graal. >>>> >>>> Note, I removed the run with Graal in JvmciNotifyInstallEventTest.java test which I incorrectly added in my changes for JDK-8225019. >>>> >>>> Thanks, >>>> Vladimir > From leonid.mesnik at oracle.com Fri Jun 7 00:36:01 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 6 Jun 2019 17:36:01 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. Message-ID: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> Hi Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 passed. webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8225388 Leonid From sandhya.viswanathan at intel.com Fri Jun 7 00:41:41 2019 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Fri, 7 Jun 2019 00:41:41 +0000 Subject: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> Please find below a small patch which fixes the issue: JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ Multiplication is implemented as shift, add sequence in certain cases. The problem was occurring because the "shift by" register was being overwritten due to missing effect statement in the shift rules. The problem was introduced as part of https://bugs.openjdk.java.net/browse/JDK-8222074. The patch adds the missing effect statements. Best Regards, Sandhya -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Fri Jun 7 02:33:15 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 6 Jun 2019 19:33:15 -0700 Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use Dependencies::find_unique_concrete_method() for non-virtual methods Message-ID: https://bugs.openjdk.java.net/browse/JDK-8223050 http://cr.openjdk.java.net/~dlong/8223050/webrev/ Avoid generating unnecessary dependencies for methods that can be statically bound.? While working on this I discovered that Graal's HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match that of the VM, because it was missing a check for . dl From vladimir.kozlov at oracle.com Fri Jun 7 02:41:28 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 19:41:28 -0700 Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use Dependencies::find_unique_concrete_method() for non-virtual methods In-Reply-To: References: Message-ID: <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com> Seems reasonable to me but Graal experts should review it. Thanks, Vladimir PS: please, run more graal tiers - I added comment in bug report. On 6/6/19 7:33 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8223050 > http://cr.openjdk.java.net/~dlong/8223050/webrev/ > > Avoid generating unnecessary dependencies for methods that can be statically bound.? While working on this I discovered > that Graal's HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match that of the VM, because it was missing a > check for . > > dl From dean.long at oracle.com Fri Jun 7 03:05:34 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 6 Jun 2019 20:05:34 -0700 Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use Dependencies::find_unique_concrete_method() for non-virtual methods In-Reply-To: <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com> References: <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com> Message-ID: <3e57b88d-a72c-8e86-62af-0b03dab4bd55@oracle.com> Thanks Vladimir. dl On 6/6/19 7:41 PM, Vladimir Kozlov wrote: > Seems reasonable to me but Graal experts should review it. > > Thanks, > Vladimir > > PS: please, run more graal tiers - I added comment in bug report. > > On 6/6/19 7:33 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8223050 >> http://cr.openjdk.java.net/~dlong/8223050/webrev/ >> >> Avoid generating unnecessary dependencies for methods that can be >> statically bound.? While working on this I discovered that Graal's >> HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match >> that of the VM, because it was missing a check for . >> >> dl From igor.ignatyev at oracle.com Fri Jun 7 06:03:29 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 23:03:29 -0700 Subject: RFR(T) : 8225469 : clean up problem lists Message-ID: http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html > 4 lines changed: 0 ins; 4 del; 0 mod; Hi all, could you please review this trivial patch which cleans up graal-specific problem lists? webrev: http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8225469 testing: unproblem-listed tests w/ graal as JIT (hs-tier4-graal) Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Jun 7 06:05:53 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 23:05:53 -0700 Subject: RFR(T) : 8225469 : clean up problem lists In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 6/6/19 11:03 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html >> 4 lines changed: 0 ins; 4 del; 0 mod; > > Hi all, > > could you please review this trivial patch which cleans up graal-specific problem lists? > > webrev: http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8225469 > testing: unproblem-listed tests w/ graal as JIT (hs-tier4-graal) > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Fri Jun 7 06:10:16 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 23:10:16 -0700 Subject: RFR(T) : 8225469 : clean up problem lists In-Reply-To: References: Message-ID: <18CB1865-4A28-4078-8604-BF4858A0B0EC@oracle.com> Thanks Vladimir! pushed. -- Igor > On Jun 6, 2019, at 11:05 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 6/6/19 11:03 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html >>> 4 lines changed: 0 ins; 4 del; 0 mod; >> Hi all, >> could you please review this trivial patch which cleans up graal-specific problem lists? >> webrev: http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225469 >> testing: unproblem-listed tests w/ graal as JIT (hs-tier4-graal) >> Thanks, >> -- Igor From tobias.hartmann at oracle.com Fri Jun 7 08:00:12 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 7 Jun 2019 10:00:12 +0200 Subject: RFR(S) : 8149040 : Cleanup compiler/jsr292/NonInlinedCall tests after JDK-8148994 In-Reply-To: <35CF8810-C61E-40CC-AFA6-20AC385B74D6@oracle.com> References: <35CF8810-C61E-40CC-AFA6-20AC385B74D6@oracle.com> Message-ID: +1 Best regards, Tobias On 06.06.19 23:53, Vladimir Kozlov wrote: > Good. > > Thanks > Vladimir > >> On Jun 6, 2019, at 2:17 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8149040/webrev.00/index.html >>> 168 lines changed: 1 ins; 162 del; 5 mod; >> >> Hi all, >> >> could you please review this small clean up in NonInlinedCall tests? >> >> testing: tier1 + compiler/jsr292 >> webrev: http://cr.openjdk.java.net/~iignatyev//8149040/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8149040 >> >> Thanks, >> -- Igor From tobias.hartmann at oracle.com Fri Jun 7 08:07:24 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 7 Jun 2019 10:07:24 +0200 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> Message-ID: <328960e6-67d8-efa7-66b2-128a39d51259@oracle.com> Hi Leonid, this looks good to me! Please remove the extra whitespace at the end of compileBroker.hpp:420 before the ")". No new webrev required. Thanks, Tobias On 07.06.19 02:36, Leonid Mesnik wrote: > Hi > > Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics > command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 > passed. > > webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8225388 > > Leonid > > From doug.simon at oracle.com Fri Jun 7 08:13:56 2019 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 7 Jun 2019 10:13:56 +0200 Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use Dependencies::find_unique_concrete_method() for non-virtual methods In-Reply-To: <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com> References: <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com> Message-ID: Change looks good to me. -Doug > On 7 Jun 2019, at 04:41, Vladimir Kozlov wrote: > > Seems reasonable to me but Graal experts should review it. > > Thanks, > Vladimir > > PS: please, run more graal tiers - I added comment in bug report. > > On 6/6/19 7:33 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8223050 >> http://cr.openjdk.java.net/~dlong/8223050/webrev/ >> Avoid generating unnecessary dependencies for methods that can be statically bound. While working on this I discovered that Graal's HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match that of the VM, because it was missing a check for . >> dl From tobias.hartmann at oracle.com Fri Jun 7 08:24:38 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 7 Jun 2019 10:24:38 +0200 Subject: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> Message-ID: Hi Sandhya, this looks good to me. Best regards, Tobias On 07.06.19 02:41, Viswanathan, Sandhya wrote: > Please find below a small patch which fixes the issue: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 > > Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ > > ? > > Multiplication is implemented as shift, add sequence in certain cases. > > The problem was occurring because the ?shift by? register was being overwritten due to missing > effect statement in the shift rules. > > The problem was introduced as part of https://bugs.openjdk.java.net/browse/JDK-8222074. > > The patch adds the missing effect statements. > > ? > > Best Regards, > > Sandhya > > ? > From serguei.spitsyn at oracle.com Fri Jun 7 08:37:37 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Jun 2019 01:37:37 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> Message-ID: <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Jun 7 09:51:04 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 7 Jun 2019 11:51:04 +0200 Subject: Questions around codeheaps, codeblobs and code locality In-Reply-To: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> References: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> Message-ID: <726994dd-fd15-cadb-7a1c-9daac1780050@oracle.com> Hi, > On 6/3/19 12:14 PM, keita abdoul-kader wrote: >> I have been looking into the code cache layout and ways to reduce the high >> amount of iTLB we are observing on some of our workloads. It seems that >> after the works on segmented codeHeaps, the plan was to add support for non >> contiguous codeBlobs as the next step to improve code locality in the code >> cache. is the work? on non contiguous codeBlobs still active ? With the segmented code cache, we've seen some nice improvements (slide 19 onwards): http://cr.openjdk.java.net/~thartmann/talks/2014-Efficient_Code_Cache_Management.pdf We had several ideas on how to improve things further (see slide 31) but there are currently no plans to work on any of these. >> Also, does the hotspot has support for any form of code compaction ? >> Compacting the code heap is mentioned in one of the comment in >> relocInfo.hpp, but browsing the source code it seems that once? the >> codeBlobs is filled with the content of a codeBuffer, they are never moved >> in a way to reduce codeheap fragmentation. No, code in the code cache is not moved/compacted but only removed. >> ? In general, is there an umbrella project or a set of open task around >> improving code locality ?? Please note that most of my observation driving >> this come from spark-sql workloads. Since spark-sql generates dynamically >> generate a lots of code, i might simply be observing a pathological case. No, we don't have any umbrella project for this. Best regards, Tobias From vladimir.x.ivanov at oracle.com Fri Jun 7 10:40:55 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 7 Jun 2019 13:40:55 +0300 Subject: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 07/06/2019 03:41, Viswanathan, Sandhya wrote: > Please find below a small patch which fixes the issue: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 > > Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ > > Multiplication is implemented as shift, add sequence in certain cases. > > The problem was occurring because the ?shift by? register was being > overwritten due to missing effect statement in the shift rules. > > The problem was introduced as part of > https://bugs.openjdk.java.net/browse/JDK-8222074. > > The patch adds the missing effect statements. > > Best Regards, > > Sandhya > From adinn at redhat.com Fri Jun 7 11:24:33 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 7 Jun 2019 12:24:33 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> Message-ID: <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> On 06/06/2019 18:40, Vladimir Kozlov wrote: > Hotspot changes looks good. > > CheckGraalIntrinsics failed because of typo - you should use 'J' instead > of 'L': > > +? "jdk/internal/misc/Unsafe.writeback0(L)V", Doh! Thanks, Vladimir :-) With that correction the test now passes. > One nitpick in vmSymbols.hpp spacing is off in next line: > > +? do_intrinsic(_writebackPostSync0,??????? > jdk_internal_misc_Unsafe,???? writebackPostSync0_name, > void_method_signature , F_RN)?? \ That line and the one two lines further on were both misaligned. I have uploaded a new webrev to fix the bove problems. This version also removes all the extra extraneous whitespace found by Brian and Gustavo. webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.07/ I have posted the changes to the submit repo to re-verify that all builds pass. I have also asked Jonathan Halliday to re-test this version against the Red Hat middleware clients to ensure there are no functional or performance changes. Modulo confirmation of those two checks this looks like it is a complete implementation. Unless anyone has more changes to recommend? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From nils.eliasson at oracle.com Fri Jun 7 12:45:58 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 7 Jun 2019 14:45:58 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <87k1e39hno.fsf@redhat.com> <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> <87ftoofnp4.fsf@redhat.com> <96902012-a7e3-86ea-c7e5-65896708bc4a@oracle.com> Message-ID: <6a8f92d8-14b2-c90b-f7d6-e8bbb23db76f@oracle.com> Hi Erik, I uploaded webrev with the friend declaration removed. I also changed back the shape of how the barrier_insertion is called from Compile.cpp. Then that will call PhaseIdealLoop::optimize and use it in the same way as Shenandoah does GC specific loop opts. I also added a clearing of major progress after the barrier insertion. Otherwise some LoopLimit nodes won't be removed correctly in the following macro expansion phase. Thank you! Regards, / Nils On 2019-06-06 21:06, Erik ?sterlund wrote: > Hi Nils, > > One final nit... could you please remove the now seemingly unnecessary > "friend class ZBarrierSetC2" in PhaseIdealLoop? I don't need another > webrev for that. > > This looks good. Great job Nils. This will improve the robustness of > our barriers. > > /Erik > > On 2019-06-06 20:03, Nils Eliasson wrote: >> >> On 2019-06-05 10:20, Roland Westrelin wrote: >>>> Ah - I think I get it. You mean like this: >>>> >>>> void ZBarrierSetC2::barrier_insertion_phase(PhaseIterGVN& igvn)const { >>>> ??? PhaseIdealLoop ideal_loop(igvn,LoopOptsNone); >>>> >>>> ??? // First make sure all loads between call and catch are moved >>>> to the >>>> catch block clean_catch_blocks(&ideal_loop); >>>> >>>> ??? // Then expand barriers on all loads >>>> insert_load_barriers(&ideal_loop); >>>> >>>> ??? // Handle all Unsafe that need barriers. >>>> insert_barriers_on_unsafe(&ideal_loop); >>>> >>>> ??? // Cleanup any modified bits igvn.optimize(); >>>> >>>> ??? igvn.C->clear_major_progress(); >>>> } >>>> >>>> An excellent idea. Then I can remove the new >>>> LoopOptsMode::BarrierInsertion. >>> I was thinking something like what we do in Shenandoah for barrier >>> expansion: >>> >>> PhaseIdealLoop ideal_loop(igvn, LoopOptsShenandoahExpand); >>> >>> ShenandoahBarrierSetC2::is_gc_specific_loop_opts_pass() returns true >>> for >>> LoopOptsShenandoahExpand and ShenandoahBarrierSetC2::optimize_loops() >>> handles LoopOptsShenandoahExpand. So there's nothing shenandoah >>> specific >>> in PhaseIdealLoop::build_and_optimize(). >> >> I followed your example and changed my implementation inline with that. >> >> >>> >>>> I've been running some experiments with asserts on the clone code. >>>> >>>> 1) There can never be any control flow here - so now phis or such. >>>> >>>> 2) Stores have explicit control - and would never be scheduled here >>>> either. >>>> >>>> 3) Loads - they end up here because they can float. They only >>>> matter if >>>> there is a use dominated by the catch (after a merge of catch control >>>> flow), or uses in more than one catch-proj branch. The only nodes >>>> observed being cloned is LoadPNodes with barriers, BoolNodes, and CmpP >>>> nodes. It's the same pattern of comparing a pointer. All other load >>>> has >>>> it's control in the catch-projs. >>>> >>>> I will add asserts to the clone in fixup_uses_in_catch to reflect this >>>> conclusion and make sure that I catch any change in behavior. >>> I was thinking of something like: >>> >>> try { >>> ?? non_inlined_call1(); >>> ?? int v = some_object.object_field.int_field; >>> ?? non_inlined_call2(v, v); >>> } catch (..) { >>> ?? int v = some_object.object_field.int_field; >>> ?? // some use for v >>> } >>> >>> So there would be a LoadP, a load barrier and a LoadI right after the >>> call. The LoadI is the first to be cloned. It has 3 uses, so it's >>> cloned >>> 3 times? Which would mean non_inlined_call2 is actually called with: >>> >>> ?? SomeObject object = some_object.object_field; >>> ?? non_inlined_call2(object.int_field, object.int_field); >>> >>> the field is reloaded and that code doesn't have the same effect as >>> above. Or am I missing something? >> >> The object_field usually gets a null-check which creates a control >> flow that anchors the LoadI further down. I managed to find one case >> in specjbb with a static call followed by a LoadL. >> >> I fixed this by calling the call_catch_cleanup recursively on these >> load, when encountered. They will then be handled in the same way as >> the LoadPs with a barrier. >> >> I also found an issue that I could get duplicate phis in blocks when >> connecting the loads together. I fixed this by keeping track on which >> regions has gotten a phi, and caching them. >> >> I've also added a number of small fixes after feedback from Erik ?. >> >> New webrev: http://cr.openjdk.java.net/~neliasso/8224675/webrev.06/ >> >> Regards, >> >> Nils >> >> >>> >>> Roland. From nils.eliasson at oracle.com Fri Jun 7 12:53:54 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 7 Jun 2019 14:53:54 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <6a8f92d8-14b2-c90b-f7d6-e8bbb23db76f@oracle.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <87k1e39hno.fsf@redhat.com> <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> <87ftoofnp4.fsf@redhat.com> <96902012-a7e3-86ea-c7e5-65896708bc4a@oracle.com> <6a8f92d8-14b2-c90b-f7d6-e8bbb23db76f@oracle.com> Message-ID: <8b795acf-4d12-f27f-1a54-0073f5552dfd@oracle.com> http://cr.openjdk.java.net/~neliasso/8224675/webrev.07/ On 2019-06-07 14:45, Nils Eliasson wrote: > Hi Erik, > > I uploaded webrev with the friend declaration removed. > > I also changed back the shape of how the barrier_insertion is called > from Compile.cpp. Then that will call PhaseIdealLoop::optimize and use > it in the same way as Shenandoah does GC specific loop opts. > > I also added a clearing of major progress after the barrier insertion. > Otherwise some LoopLimit nodes won't be removed correctly in the > following macro expansion phase. > > Thank you! > > Regards, > > / Nils > > On 2019-06-06 21:06, Erik ?sterlund wrote: >> Hi Nils, >> >> One final nit... could you please remove the now seemingly >> unnecessary "friend class ZBarrierSetC2" in PhaseIdealLoop? I don't >> need another webrev for that. >> >> This looks good. Great job Nils. This will improve the robustness of >> our barriers. >> >> /Erik >> >> On 2019-06-06 20:03, Nils Eliasson wrote: >>> >>> On 2019-06-05 10:20, Roland Westrelin wrote: >>>>> Ah - I think I get it. You mean like this: >>>>> >>>>> void ZBarrierSetC2::barrier_insertion_phase(PhaseIterGVN& >>>>> igvn)const { >>>>> ??? PhaseIdealLoop ideal_loop(igvn,LoopOptsNone); >>>>> >>>>> ??? // First make sure all loads between call and catch are moved >>>>> to the >>>>> catch block clean_catch_blocks(&ideal_loop); >>>>> >>>>> ??? // Then expand barriers on all loads >>>>> insert_load_barriers(&ideal_loop); >>>>> >>>>> ??? // Handle all Unsafe that need barriers. >>>>> insert_barriers_on_unsafe(&ideal_loop); >>>>> >>>>> ??? // Cleanup any modified bits igvn.optimize(); >>>>> >>>>> ??? igvn.C->clear_major_progress(); >>>>> } >>>>> >>>>> An excellent idea. Then I can remove the new >>>>> LoopOptsMode::BarrierInsertion. >>>> I was thinking something like what we do in Shenandoah for barrier >>>> expansion: >>>> >>>> PhaseIdealLoop ideal_loop(igvn, LoopOptsShenandoahExpand); >>>> >>>> ShenandoahBarrierSetC2::is_gc_specific_loop_opts_pass() returns >>>> true for >>>> LoopOptsShenandoahExpand and ShenandoahBarrierSetC2::optimize_loops() >>>> handles LoopOptsShenandoahExpand. So there's nothing shenandoah >>>> specific >>>> in PhaseIdealLoop::build_and_optimize(). >>> >>> I followed your example and changed my implementation inline with that. >>> >>> >>>> >>>>> I've been running some experiments with asserts on the clone code. >>>>> >>>>> 1) There can never be any control flow here - so now phis or such. >>>>> >>>>> 2) Stores have explicit control - and would never be scheduled >>>>> here either. >>>>> >>>>> 3) Loads - they end up here because they can float. They only >>>>> matter if >>>>> there is a use dominated by the catch (after a merge of catch control >>>>> flow), or uses in more than one catch-proj branch. The only nodes >>>>> observed being cloned is LoadPNodes with barriers, BoolNodes, and >>>>> CmpP >>>>> nodes. It's the same pattern of comparing a pointer. All other >>>>> load has >>>>> it's control in the catch-projs. >>>>> >>>>> I will add asserts to the clone in fixup_uses_in_catch to reflect >>>>> this >>>>> conclusion and make sure that I catch any change in behavior. >>>> I was thinking of something like: >>>> >>>> try { >>>> ?? non_inlined_call1(); >>>> ?? int v = some_object.object_field.int_field; >>>> ?? non_inlined_call2(v, v); >>>> } catch (..) { >>>> ?? int v = some_object.object_field.int_field; >>>> ?? // some use for v >>>> } >>>> >>>> So there would be a LoadP, a load barrier and a LoadI right after the >>>> call. The LoadI is the first to be cloned. It has 3 uses, so it's >>>> cloned >>>> 3 times? Which would mean non_inlined_call2 is actually called with: >>>> >>>> ?? SomeObject object = some_object.object_field; >>>> ?? non_inlined_call2(object.int_field, object.int_field); >>>> >>>> the field is reloaded and that code doesn't have the same effect as >>>> above. Or am I missing something? >>> >>> The object_field usually gets a null-check which creates a control >>> flow that anchors the LoadI further down. I managed to find one case >>> in specjbb with a static call followed by a LoadL. >>> >>> I fixed this by calling the call_catch_cleanup recursively on these >>> load, when encountered. They will then be handled in the same way as >>> the LoadPs with a barrier. >>> >>> I also found an issue that I could get duplicate phis in blocks when >>> connecting the loads together. I fixed this by keeping track on >>> which regions has gotten a phi, and caching them. >>> >>> I've also added a number of small fixes after feedback from Erik ?. >>> >>> New webrev: http://cr.openjdk.java.net/~neliasso/8224675/webrev.06/ >>> >>> Regards, >>> >>> Nils >>> >>> >>>> >>>> Roland. From tobias.hartmann at oracle.com Fri Jun 7 13:44:24 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 7 Jun 2019 15:44:24 +0200 Subject: [13] RFR(S): 8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL In-Reply-To: <837ac2a7-d8eb-34ff-06f0-586ed75bd639@oracle.com> References: <2b0a8781-4688-558d-353e-8ef3483fc833@oracle.com> <445d5158-21f3-0fc1-43ac-273ad81d0533@oracle.com> <837ac2a7-d8eb-34ff-06f0-586ed75bd639@oracle.com> Message-ID: <22fd359e-56c6-90c4-d380-3d2c34adb1e5@oracle.com> Getting back to this. I've added additional tests that trigger constant folding of the address to NULL only after parsing with incremental inlining. This triggers the same assert during final graph reshaping. New code in MemNode::Ideal_common will detect this, cut of control and add a HaltNode to fail if this is ever executed (we will fail with a SIGILL). I've also fixed a missing 'unsafe' argument being passed on in graphKit.hpp. http://cr.openjdk.java.net/~thartmann/8224658/webrev.01/ Thanks, Tobias On 23.05.19 15:21, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for looking at this. > > On 23.05.19 15:09, Vladimir Ivanov wrote: >> The fix should work fine for Unsafe.getXxx(0) case, but what if address turns into 0 later? For >> example, I don't see a reason why it can't theoretically happen in presence of post-parse inlining >> happening in effectively unreachable code. > > Yes that's possible and I thought it doesn't matter because we won't hit that assert during IGVN. > I've just checked in detail and C2 actually completely removes the unsafe access in that case which > is obviously incorrect. > > I'll come back once I have a fix ready. > > Thanks, > Tobias > From adinn at redhat.com Fri Jun 7 14:10:49 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 7 Jun 2019 15:10:49 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> Message-ID: <08aef662-69e2-eb70-ef83-043837dbdd69@redhat.com> On 07/06/2019 12:24, Andrew Dinn wrote: > On 06/06/2019 18:40, Vladimir Kozlov wrote: >> Hotspot changes looks good. >> >> CheckGraalIntrinsics failed because of typo - you should use 'J' instead >> of 'L': >> >> +? "jdk/internal/misc/Unsafe.writeback0(L)V", > > Doh! Thanks, Vladimir :-) > > With that correction the test now passes. > >> One nitpick in vmSymbols.hpp spacing is off in next line: >> >> +? do_intrinsic(_writebackPostSync0,??????? >> jdk_internal_misc_Unsafe,???? writebackPostSync0_name, >> void_method_signature , F_RN)?? \ > That line and the one two lines further on were both misaligned. > > I have uploaded a new webrev to fix the bove problems. This version also > removes all the extra extraneous whitespace found by Brian and Gustavo. > > webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.07/ > > I have posted the changes to the submit repo to re-verify that all > builds pass. I have also asked Jonathan Halliday to re-test this version > against the Red Hat middleware clients to ensure there are no functional > or performance changes. > > Modulo confirmation of those two checks this looks like it is a complete > implementation. Unless anyone has more changes to recommend? I just want to confirm that the submit job was clean and the middleware clients are performing as expected. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.x.ivanov at oracle.com Fri Jun 7 14:27:25 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 7 Jun 2019 17:27:25 +0300 Subject: [13] RFR(S): 8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL In-Reply-To: <22fd359e-56c6-90c4-d380-3d2c34adb1e5@oracle.com> References: <2b0a8781-4688-558d-353e-8ef3483fc833@oracle.com> <445d5158-21f3-0fc1-43ac-273ad81d0533@oracle.com> <837ac2a7-d8eb-34ff-06f0-586ed75bd639@oracle.com> <22fd359e-56c6-90c4-d380-3d2c34adb1e5@oracle.com> Message-ID: <8d250d22-e990-8ce9-48df-647393d2f1e1@oracle.com> > http://cr.openjdk.java.net/~thartmann/8224658/webrev.01/ Looks good. There are existing usages of Halt for optimizing unsafe accesses (e.g., GraphKit::must_be_not_null), but, as a future enhancement, it would be nice to provide more information about the root cause of the crash. As an example, JDK-8219902 [1] which involved Halt execution manifested as: # SIGILL (0x4) at pc=0x00007f55b4df37d6, pid=15865, tid=15869 # # JRE version: OpenJDK Runtime Environment (13.0+9) (build 13-ea+9) # Java VM: OpenJDK 64-Bit Server VM (13-ea+9, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # J 10152 c2 com.sun.tools.javac.tree.Pretty.visitLiteral(Lcom/sun/tools/javac/tree/JCTree$JCLiteral;)V jdk.compiler at 13-ea (282 bytes) @ 0x00007f55b4df37d6 [0x00007f55b4df07a0+0x0000000000003036] Without laborous analysis of generated code, it's impossible to say whether it's a JVM bug or a problem in user code. I believe JVM can do better in such situations and print meaningful error message instead when crashing. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8219902 > On 23.05.19 15:21, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for looking at this. >> >> On 23.05.19 15:09, Vladimir Ivanov wrote: >>> The fix should work fine for Unsafe.getXxx(0) case, but what if address turns into 0 later? For >>> example, I don't see a reason why it can't theoretically happen in presence of post-parse inlining >>> happening in effectively unreachable code. >> >> Yes that's possible and I thought it doesn't matter because we won't hit that assert during IGVN. >> I've just checked in detail and C2 actually completely removes the unsafe access in that case which >> is obviously incorrect. >> >> I'll come back once I have a fix ready. >> >> Thanks, >> Tobias >> From erik.osterlund at oracle.com Fri Jun 7 14:27:40 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 7 Jun 2019 16:27:40 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <8b795acf-4d12-f27f-1a54-0073f5552dfd@oracle.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <87k1e39hno.fsf@redhat.com> <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> <87ftoofnp4.fsf@redhat.com> <96902012-a7e3-86ea-c7e5-65896708bc4a@oracle.com> <6a8f92d8-14b2-c90b-f7d6-e8bbb23db76f@oracle.com> <8b795acf-4d12-f27f-1a54-0073f5552dfd@oracle.com> Message-ID: Looks good. /Erik > On 7 Jun 2019, at 14:53, Nils Eliasson wrote: > > > http://cr.openjdk.java.net/~neliasso/8224675/webrev.07/ > > >> On 2019-06-07 14:45, Nils Eliasson wrote: >> Hi Erik, >> >> I uploaded webrev with the friend declaration removed. >> >> I also changed back the shape of how the barrier_insertion is called from Compile.cpp. Then that will call PhaseIdealLoop::optimize and use it in the same way as Shenandoah does GC specific loop opts. >> >> I also added a clearing of major progress after the barrier insertion. Otherwise some LoopLimit nodes won't be removed correctly in the following macro expansion phase. >> >> Thank you! >> >> Regards, >> >> / Nils >> >>> On 2019-06-06 21:06, Erik ?sterlund wrote: >>> Hi Nils, >>> >>> One final nit... could you please remove the now seemingly unnecessary "friend class ZBarrierSetC2" in PhaseIdealLoop? I don't need another webrev for that. >>> >>> This looks good. Great job Nils. This will improve the robustness of our barriers. >>> >>> /Erik >>> >>>> On 2019-06-06 20:03, Nils Eliasson wrote: >>>> >>>> On 2019-06-05 10:20, Roland Westrelin wrote: >>>>>> Ah - I think I get it. You mean like this: >>>>>> >>>>>> void ZBarrierSetC2::barrier_insertion_phase(PhaseIterGVN& igvn)const { >>>>>> PhaseIdealLoop ideal_loop(igvn,LoopOptsNone); >>>>>> >>>>>> // First make sure all loads between call and catch are moved to the >>>>>> catch block clean_catch_blocks(&ideal_loop); >>>>>> >>>>>> // Then expand barriers on all loads insert_load_barriers(&ideal_loop); >>>>>> >>>>>> // Handle all Unsafe that need barriers. insert_barriers_on_unsafe(&ideal_loop); >>>>>> >>>>>> // Cleanup any modified bits igvn.optimize(); >>>>>> >>>>>> igvn.C->clear_major_progress(); >>>>>> } >>>>>> >>>>>> An excellent idea. Then I can remove the new LoopOptsMode::BarrierInsertion. >>>>> I was thinking something like what we do in Shenandoah for barrier >>>>> expansion: >>>>> >>>>> PhaseIdealLoop ideal_loop(igvn, LoopOptsShenandoahExpand); >>>>> >>>>> ShenandoahBarrierSetC2::is_gc_specific_loop_opts_pass() returns true for >>>>> LoopOptsShenandoahExpand and ShenandoahBarrierSetC2::optimize_loops() >>>>> handles LoopOptsShenandoahExpand. So there's nothing shenandoah specific >>>>> in PhaseIdealLoop::build_and_optimize(). >>>> >>>> I followed your example and changed my implementation inline with that. >>>> >>>> >>>>> >>>>>> I've been running some experiments with asserts on the clone code. >>>>>> >>>>>> 1) There can never be any control flow here - so now phis or such. >>>>>> >>>>>> 2) Stores have explicit control - and would never be scheduled here either. >>>>>> >>>>>> 3) Loads - they end up here because they can float. They only matter if >>>>>> there is a use dominated by the catch (after a merge of catch control >>>>>> flow), or uses in more than one catch-proj branch. The only nodes >>>>>> observed being cloned is LoadPNodes with barriers, BoolNodes, and CmpP >>>>>> nodes. It's the same pattern of comparing a pointer. All other load has >>>>>> it's control in the catch-projs. >>>>>> >>>>>> I will add asserts to the clone in fixup_uses_in_catch to reflect this >>>>>> conclusion and make sure that I catch any change in behavior. >>>>> I was thinking of something like: >>>>> >>>>> try { >>>>> non_inlined_call1(); >>>>> int v = some_object.object_field.int_field; >>>>> non_inlined_call2(v, v); >>>>> } catch (..) { >>>>> int v = some_object.object_field.int_field; >>>>> // some use for v >>>>> } >>>>> >>>>> So there would be a LoadP, a load barrier and a LoadI right after the >>>>> call. The LoadI is the first to be cloned. It has 3 uses, so it's cloned >>>>> 3 times? Which would mean non_inlined_call2 is actually called with: >>>>> >>>>> SomeObject object = some_object.object_field; >>>>> non_inlined_call2(object.int_field, object.int_field); >>>>> >>>>> the field is reloaded and that code doesn't have the same effect as >>>>> above. Or am I missing something? >>>> >>>> The object_field usually gets a null-check which creates a control flow that anchors the LoadI further down. I managed to find one case in specjbb with a static call followed by a LoadL. >>>> >>>> I fixed this by calling the call_catch_cleanup recursively on these load, when encountered. They will then be handled in the same way as the LoadPs with a barrier. >>>> >>>> I also found an issue that I could get duplicate phis in blocks when connecting the loads together. I fixed this by keeping track on which regions has gotten a phi, and caching them. >>>> >>>> I've also added a number of small fixes after feedback from Erik ?. >>>> >>>> New webrev: http://cr.openjdk.java.net/~neliasso/8224675/webrev.06/ >>>> >>>> Regards, >>>> >>>> Nils >>>> >>>> >>>>> >>>>> Roland. From rwestrel at redhat.com Fri Jun 7 14:37:16 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 07 Jun 2019 16:37:16 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <8b795acf-4d12-f27f-1a54-0073f5552dfd@oracle.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <87k1e39hno.fsf@redhat.com> <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> <87ftoofnp4.fsf@redhat.com> <96902012-a7e3-86ea-c7e5-65896708bc4a@oracle.com> <6a8f92d8-14b2-c90b-f7d6-e8bbb23db76f@oracle.com> <8b795acf-4d12-f27f-1a54-0073f5552dfd@oracle.com> Message-ID: <87pnnpea1v.fsf@redhat.com> > http://cr.openjdk.java.net/~neliasso/8224675/webrev.07/ vmSymbols.cpp has no change? in compile.cpp, indentation looks wrong: 2406 bs->barrier_insertion_phase(C, igvn); 2407 if (failing()) return; That looks good to me. No need for another webrev. Roland. From dmitrij.pochepko at bell-sw.com Fri Jun 7 14:36:50 2019 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 7 Jun 2019 17:36:50 +0300 Subject: RFR: 8222412 - AARCH64: multiple instructions encoding issues Message-ID: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com> Hi all, please review patch for JDK-8222412 - AARCH64: multiple instructions encoding issues I updated python script aarch64-asmtest.py used for automatic tests generation and requesting review for the issues found by eyeballing and by the updated script. Issue: https://bugs.openjdk.java.net/browse/JDK-8222412 Webrev of instruction encoding cumulative fix: http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/ (assembler_aarch64.cpp part consists of automatically generated instructions only). Updated script: http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/aarch64-asmtest.py Fixes summary: incorrect encoding fixes: - post_reg addressing mode is encoded incorrectly in case of r0 index register (caused by declaration of r0 as 0 i.e. NULL). Fixed. Testcase is generated by aarch64-asmtest.py. - load-with-replicate instructions (ld1r, ld2r, ld3r, ld4r) with post immediate addressing mode are encoded incorrectly (offset value should be calculated differently for replicate and non-replicate instructions). Fixed. Testcase is generated by aarch64-asmtest.py. - ld1*/ld2*/ld3*/ld4* instructions should accept subsequent SIMD registers modulo 32. (i.e. "v31, v0, v1, v2" is valid sequence). Current implementation is not calculating modulo 32. Fixed. Testcase is generated by aarch64-asmtest.py. missing asserts fixes: - bitfield move instructions (*bfm*) accept out-of-range parameters for 32-bit version. Check added. - extrw instruction encoding accept out-of-range parameter. Check added. - logical operations(and, orr, eor, bic, orn, eon) with shifted register accept out-of-range parameter for 32-bit versions. Check added. - add, sub instructions with shifted register accept out-of-range parameter for 32-bit versions. Check added. - vector versions of add, sub, mul, mla, mls, sshl, ushl, umull, umlal accept incorrect simd type. Check added. - vector versions of abs, neg, not, add, cls, clz, cnt, uaddl accept incorrect simd type. Check added. - vector instructions with immediate argument (mov, orr, mvn, bic) accept incorrect shift value and silently convert it. Check added. - simd move to general purpose register allows incorrect simd arrangement type. Check added. - zip/uzp/trn instructions accept incorrect simd arrangement type. Check added. zero register fixes: - extr and extrw encoding do not allow zr as parameter. Fixed. Testcase is generated by aarch64-asmtest.py. - pair exclusive load/store instructions doesn't allow 2nd target register to be zr (while allowing 1st). Fixed. Testcase is generated by aarch64-asmtest.py. - lse atomic instructions doesn't allow source register to be zr (for example, no swap (swp) with zr is allowed). Fixed. Testcase is generated by aarch64-asmtest.py. - conditional compare instructions doesn't allow 1st compared register to be zr. Fixed. Testcase is generated by aarch64-asmtest.py. - simd move from general purpose register doesn't allow to use zero register as source. Fixed. Testcase is generated by aarch64-asmtest.py. - simd dup instruction doesn't allow to use zero register as duplication source. Fixed. Testcase is generated by aarch64-asmtest.py. miscellaneous fixes: - ushll and ushll2 instructions are implemented as synonyms. Same with pmull/pmull2. Fixed. - fixed assert message misprint in add,sub instructions with extended register Testing: I checked instructions generation via python-generated code in release and fastdebug build. I also run hotspot jtreg tests: compiler/*, gc/* and runtime/* using fastdebug build. Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Fri Jun 7 14:44:32 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 7 Jun 2019 16:44:32 +0200 Subject: RFR(XL): 8224675: Late GC barrier insertion for ZGC In-Reply-To: <87pnnpea1v.fsf@redhat.com> References: <87a7f5bt0g.fsf@redhat.com> <87a3f42d-94ff-b588-85ea-e8bbf07cc2df@oracle.com> <87k1e39hno.fsf@redhat.com> <414066b2-9cc2-9ac2-cd99-997228bf5707@oracle.com> <87ftoofnp4.fsf@redhat.com> <96902012-a7e3-86ea-c7e5-65896708bc4a@oracle.com> <6a8f92d8-14b2-c90b-f7d6-e8bbb23db76f@oracle.com> <8b795acf-4d12-f27f-1a54-0073f5552dfd@oracle.com> <87pnnpea1v.fsf@redhat.com> Message-ID: On 2019-06-07 16:37, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~neliasso/8224675/webrev.07/ > vmSymbols.cpp has no change? There was a leftover indentation change. I removed it. > > in compile.cpp, indentation looks wrong: > > 2406 bs->barrier_insertion_phase(C, igvn); > 2407 if (failing()) return; Fixed. > > That looks good to me. No need for another webrev. Thank you Roland! I will run tests over the weekend and hopefully push on Monday morning. Regards, Niols > > Roland. From aph at redhat.com Fri Jun 7 15:29:45 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Jun 2019 16:29:45 +0100 Subject: [aarch64-port-dev ] RFR: 8222412 - AARCH64: multiple instructions encoding issues In-Reply-To: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com> References: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com> Message-ID: <56d760a2-4719-d00e-bc27-d507c2aa86b2@redhat.com> On 6/7/19 3:36 PM, Dmitrij Pochepko wrote: > please review patch for JDK-8222412 - AARCH64: multiple instructions > encoding issues > > I updated python script aarch64-asmtest.py used for automatic tests > generation and requesting review for the issues found by eyeballing and > by the updated script. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8222412 > > Webrev of instruction encoding cumulative fix: > http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/ > (assembler_aarch64.cpp part consists of automatically generated > instructions only). > > Updated script: > http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/aarch64-asmtest.py Excellent. That's a thorough piece of work. One thing that I did not check: does this patch cover all of the instructions that we generate? Thank you. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Fri Jun 7 16:02:23 2019 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 7 Jun 2019 19:02:23 +0300 Subject: [aarch64-port-dev ] RFR: 8222412 - AARCH64: multiple instructions encoding issues In-Reply-To: <56d760a2-4719-d00e-bc27-d507c2aa86b2@redhat.com> References: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com> <56d760a2-4719-d00e-bc27-d507c2aa86b2@redhat.com> Message-ID: On 07/06/2019 6:29 PM, Andrew Haley wrote: > On 6/7/19 3:36 PM, Dmitrij Pochepko wrote: >> please review patch for JDK-8222412 - AARCH64: multiple instructions >> encoding issues >> >> I updated python script aarch64-asmtest.py used for automatic tests >> generation and requesting review for the issues found by eyeballing and >> by the updated script. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8222412 >> >> Webrev of instruction encoding cumulative fix: >> http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/ >> (assembler_aarch64.cpp part consists of automatically generated >> instructions only). >> >> Updated script: >> http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/aarch64-asmtest.py > Excellent. That's a thorough piece of work. > > One thing that I did not check: does this patch cover all of the > instructions that we generate? > > Thank you. I only added test cases to cover instructions, which generation logic was changed by this patch (positive cases only, because negative cases triggers asserts). There is still a number of instructions (mostly SIMD), which are not generated by this testing mechanism. It should probably be a separate test-coverage-only effort. Do we want it in future? From leonid.mesnik at oracle.com Fri Jun 7 16:10:58 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 7 Jun 2019 09:10:58 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> Message-ID: <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> Hi Currently DCmdArgument is used to parse any numeric values in dcmd framework including positive integer values for port, ttl etc. Adding new type DCmdArgument requires adding more specialized methods like template <> void DCmdArgument::parse_value(const char* str, size_t len, TRAPS) { and other to parse and validate any *integer* parameters. See http://hg.openjdk.java.net/jdk/jdk/file/47ee6c00d27c/src/hotspot/share/services/diagnosticArgument.cpp#l112 I think that it is easier to use single jlong for all integer like it is done now rather than adding more types. One might said that it would be better to add size_t type and use it for all non-negative integers. It would be good improvement for all dcmd args parsing. As well as overall improvement of parameters validation. (dcmd often don't throw exception and just return in the case of incorrect arguments). But sees like separate effort for whole dcmd framework. Leonid > On Jun 7, 2019, at 1:37 AM, serguei.spitsyn at oracle.com wrote: > > Hi Leonid, > > It looks good to me. > One minor comment on the src/hotspot/share/services/diagnosticCommand.?pp > + DCmdArgument _granularity; > > I'm curios if using size_t instead of jlong as in other files would be more unified. > > Thanks, > Serguei > > > > On 6/6/19 17:36, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 passed. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 >> >> Leonid >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Fri Jun 7 16:22:51 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Jun 2019 17:22:51 +0100 Subject: [aarch64-port-dev ] RFR: 8222412 - AARCH64: multiple instructions encoding issues In-Reply-To: References: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com> <56d760a2-4719-d00e-bc27-d507c2aa86b2@redhat.com> Message-ID: <0ceedc01-330c-0951-b49a-f180bb7c1f16@redhat.com> On 6/7/19 5:02 PM, Dmitrij Pochepko wrote: > > On 07/06/2019 6:29 PM, Andrew Haley wrote: >> On 6/7/19 3:36 PM, Dmitrij Pochepko wrote: >>> please review patch for JDK-8222412 - AARCH64: multiple instructions >>> encoding issues >>> >>> I updated python script aarch64-asmtest.py used for automatic tests >>> generation and requesting review for the issues found by eyeballing and >>> by the updated script. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8222412 >>> >>> Webrev of instruction encoding cumulative fix: >>> http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/ >>> (assembler_aarch64.cpp part consists of automatically generated >>> instructions only). >>> >>> Updated script: >>> http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/aarch64-asmtest.py >> Excellent. That's a thorough piece of work. >> >> One thing that I did not check: does this patch cover all of the >> instructions that we generate? >> >> Thank you. > > I only added test cases to cover instructions, which generation logic > was changed by this patch (positive cases only, because negative cases > triggers asserts). > > There is still a number of instructions (mostly SIMD), which are not > generated by this testing mechanism. It should probably be a separate > test-coverage-only effort. Do we want it in future? It's certainly not essential but might be nice. Patch is approved. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Fri Jun 7 16:25:00 2019 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 7 Jun 2019 19:25:00 +0300 Subject: [aarch64-port-dev ] RFR: 8222412 - AARCH64: multiple instructions encoding issues In-Reply-To: <0ceedc01-330c-0951-b49a-f180bb7c1f16@redhat.com> References: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com> <56d760a2-4719-d00e-bc27-d507c2aa86b2@redhat.com> <0ceedc01-330c-0951-b49a-f180bb7c1f16@redhat.com> Message-ID: On 07/06/2019 7:22 PM, Andrew Haley wrote: > On 6/7/19 5:02 PM, Dmitrij Pochepko wrote: >> On 07/06/2019 6:29 PM, Andrew Haley wrote: >>> On 6/7/19 3:36 PM, Dmitrij Pochepko wrote: >>>> please review patch for JDK-8222412 - AARCH64: multiple instructions >>>> encoding issues >>>> >>>> I updated python script aarch64-asmtest.py used for automatic tests >>>> generation and requesting review for the issues found by eyeballing and >>>> by the updated script. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8222412 >>>> >>>> Webrev of instruction encoding cumulative fix: >>>> http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/ >>>> (assembler_aarch64.cpp part consists of automatically generated >>>> instructions only). >>>> >>>> Updated script: >>>> http://cr.openjdk.java.net/~dpochepk/8222412/webrev.02/aarch64-asmtest.py >>> Excellent. That's a thorough piece of work. >>> >>> One thing that I did not check: does this patch cover all of the >>> instructions that we generate? >>> >>> Thank you. >> I only added test cases to cover instructions, which generation logic >> was changed by this patch (positive cases only, because negative cases >> triggers asserts). >> >> There is still a number of instructions (mostly SIMD), which are not >> generated by this testing mechanism. It should probably be a separate >> test-coverage-only effort. Do we want it in future? > It's certainly not essential but might be nice. > > Patch is approved. > Thank you for review! From aph at redhat.com Fri Jun 7 16:28:07 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Jun 2019 17:28:07 +0100 Subject: [aarch64-port-dev ] RFR: 8222412 - AARCH64: multiple instructions encoding issues In-Reply-To: <0ceedc01-330c-0951-b49a-f180bb7c1f16@redhat.com> References: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com> <56d760a2-4719-d00e-bc27-d507c2aa86b2@redhat.com> <0ceedc01-330c-0951-b49a-f180bb7c1f16@redhat.com> Message-ID: <8916bb09-d5ed-12c6-5ff3-f74b8366422a@redhat.com> On 6/7/19 5:22 PM, Andrew Haley wrote: > It's certainly not essential but might be nice. > > Patch is approved. I guess we should also check in the Python script to cpu/aarch64. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From abdoulk.keita at gmail.com Fri Jun 7 16:20:48 2019 From: abdoulk.keita at gmail.com (keita abdoul-kader) Date: Fri, 7 Jun 2019 09:20:48 -0700 Subject: Questions around codeheaps, codeblobs and code locality In-Reply-To: References: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> <726994dd-fd15-cadb-7a1c-9daac1780050@oracle.com> Message-ID: On Fri, Jun 7, 2019 at 9:20 AM keita abdoul-kader wrote: > Thanks Tobias for taking the time. > > Those are nice improvements indeed. Do you expect the remaining work item > to (cumulatively) bring comparable gain ? Or have we reach the point of > diminishing returns? > Would you mind expanding on how you obtained the heat map on slide 13 and > 19 of your presentation ? I would like to reproduce those on our internal > workloads. > > > > > > On Fri, Jun 7, 2019 at 2:51 AM Tobias Hartmann > wrote: > >> Hi, >> >> > On 6/3/19 12:14 PM, keita abdoul-kader wrote: >> >> I have been looking into the code cache layout and ways to reduce the >> high >> >> amount of iTLB we are observing on some of our workloads. It seems that >> >> after the works on segmented codeHeaps, the plan was to add support >> for non >> >> contiguous codeBlobs as the next step to improve code locality in the >> code >> >> cache. is the work on non contiguous codeBlobs still active ? >> >> With the segmented code cache, we've seen some nice improvements (slide >> 19 onwards): >> >> http://cr.openjdk.java.net/~thartmann/talks/2014-Efficient_Code_Cache_Management.pdf >> >> We had several ideas on how to improve things further (see slide 31) but >> there are currently no >> plans to work on any of these. >> >> >> Also, does the hotspot has support for any form of code compaction ? >> >> Compacting the code heap is mentioned in one of the comment in >> >> relocInfo.hpp, but browsing the source code it seems that once the >> >> codeBlobs is filled with the content of a codeBuffer, they are never >> moved >> >> in a way to reduce codeheap fragmentation. >> >> No, code in the code cache is not moved/compacted but only removed. >> >> >> In general, is there an umbrella project or a set of open task around >> >> improving code locality ? Please note that most of my observation >> driving >> >> this come from spark-sql workloads. Since spark-sql generates >> dynamically >> >> generate a lots of code, i might simply be observing a pathological >> case. >> >> No, we don't have any umbrella project for this. >> >> Best regards, >> Tobias >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at bell-sw.com Fri Jun 7 16:36:19 2019 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 7 Jun 2019 19:36:19 +0300 Subject: [aarch64-port-dev ] RFR: 8222412 - AARCH64: multiple instructions encoding issues In-Reply-To: <8916bb09-d5ed-12c6-5ff3-f74b8366422a@redhat.com> References: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com> <56d760a2-4719-d00e-bc27-d507c2aa86b2@redhat.com> <0ceedc01-330c-0951-b49a-f180bb7c1f16@redhat.com> <8916bb09-d5ed-12c6-5ff3-f74b8366422a@redhat.com> Message-ID: <5ec69241-a9c8-fe07-2f7a-40195e78a0b3@bell-sw.com> On 07/06/2019 7:28 PM, Andrew Haley wrote: > On 6/7/19 5:22 PM, Andrew Haley wrote: >> It's certainly not essential but might be nice. >> >> Patch is approved. > I guess we should also check in the Python script to cpu/aarch64. > Sure. Do I need new webrev for that, or just include aarch64-asmtest.py in commit? From serguei.spitsyn at oracle.com Fri Jun 7 16:48:33 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Jun 2019 09:48:33 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> Message-ID: <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> An HTML attachment was scrubbed... URL: From aph at redhat.com Fri Jun 7 17:16:29 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Jun 2019 18:16:29 +0100 Subject: [aarch64-port-dev ] RFR: 8222412 - AARCH64: multiple instructions encoding issues In-Reply-To: <5ec69241-a9c8-fe07-2f7a-40195e78a0b3@bell-sw.com> References: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com> <56d760a2-4719-d00e-bc27-d507c2aa86b2@redhat.com> <0ceedc01-330c-0951-b49a-f180bb7c1f16@redhat.com> <8916bb09-d5ed-12c6-5ff3-f74b8366422a@redhat.com> <5ec69241-a9c8-fe07-2f7a-40195e78a0b3@bell-sw.com> Message-ID: <6b6d050f-3def-68ba-747d-56590bee8d8c@redhat.com> On 6/7/19 5:36 PM, Dmitrij Pochepko wrote: > > On 07/06/2019 7:28 PM, Andrew Haley wrote: >> On 6/7/19 5:22 PM, Andrew Haley wrote: >>> It's certainly not essential but might be nice. >>> >>> Patch is approved. >> I guess we should also check in the Python script to cpu/aarch64. >> > Sure. Do I need new webrev for that, or just include aarch64-asmtest.py > in commit? No new webrev, just commit it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From leonid.mesnik at oracle.com Fri Jun 7 18:23:35 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 7 Jun 2019 11:23:35 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> Message-ID: I read documentation about CRS on following wiki https://wiki.openjdk.java.net/display/csr . It says that CRS requires if command-line options are changes. However I believe that fix don't change actual behavior of 'granularity' option so no CSR is needed for this small help update. Any advise is welcome. Leonid > On Jun 7, 2019, at 9:48 AM, serguei.spitsyn at oracle.com wrote: > > Okay then. > I wonder now, if a CSR needs to be filed for this change. > > Thanks, > Serguei > > > On 6/7/19 09:10, Leonid Mesnik wrote: >> Hi >> >> Currently DCmdArgument is used to parse any numeric values in dcmd framework including positive integer values for port, ttl etc. >> >> Adding new type DCmdArgument requires adding more specialized methods like >> template <> void DCmdArgument::parse_value(const char* str, >> size_t len, TRAPS) { >> >> and other to parse and validate any *integer* parameters. See >> http://hg.openjdk.java.net/jdk/jdk/file/47ee6c00d27c/src/hotspot/share/services/diagnosticArgument.cpp#l112 >> >> I think that it is easier to use single jlong for all integer like it is done now rather than adding more types. >> >> One might said that it would be better to add size_t type and use it for all non-negative integers. It would be good improvement for all dcmd args parsing. As well as overall improvement of parameters validation. (dcmd often don't throw exception and just return in the case of incorrect arguments). But sees like separate effort for whole dcmd framework. >> >> >> Leonid >>> On Jun 7, 2019, at 1:37 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Hi Leonid, >>> >>> It looks good to me. >>> One minor comment on the src/hotspot/share/services/diagnosticCommand.?pp >>> + DCmdArgument _granularity; >>> >>> I'm curios if using size_t instead of jlong as in other files would be more unified. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 6/6/19 17:36, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 passed. >>>> >>>> webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 >>>> >>>> Leonid >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jun 7 18:29:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Jun 2019 11:29:14 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From sandhya.viswanathan at intel.com Fri Jun 7 18:45:21 2019 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Fri, 7 Jun 2019 18:45:21 +0000 Subject: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com> Hi Vladimir/Tobias, Thanks a lot for the review. Best Regards, Sandhya -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Friday, June 07, 2019 3:41 AM To: Viswanathan, Sandhya ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc Looks good. Best regards, Vladimir Ivanov On 07/06/2019 03:41, Viswanathan, Sandhya wrote: > Please find below a small patch which fixes the issue: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 > > Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ > > Multiplication is implemented as shift, add sequence in certain cases. > > The problem was occurring because the "shift by" register was being > overwritten due to missing effect statement in the shift rules. > > The problem was introduced as part of > https://bugs.openjdk.java.net/browse/JDK-8222074. > > The patch adds the missing effect statements. > > Best Regards, > > Sandhya > From vladimir.kozlov at oracle.com Fri Jun 7 19:35:49 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 7 Jun 2019 12:35:49 -0700 Subject: [13] RFR(S) 8225350: compiler/jvmci/compilerToVM/IsCompilableTest.java timed out In-Reply-To: <70CC384E-4A80-4D63-8459-EE8CACBA195B@oracle.com> References: <9e3eb6b1-4fec-3fe8-7ea8-d0eec56e11d7@oracle.com> <73669281-F06A-46AE-BFEB-E9BC307F62CD@oracle.com> <70CC384E-4A80-4D63-8459-EE8CACBA195B@oracle.com> Message-ID: http://cr.openjdk.java.net/~kvn/8225350/webrev.02/ After few testing I found that no need check Tiered compilation to pass tests. Some changed tests (like IsCompilableTest.java) don't need Graal to compile a method - they only use JVMCI API. Timeout happened with them only because of -Xcomp stop execution until a method is compiled (Xcomp switch off background compilation). Require running in Xmixed more is enough to avoid timeout even when TieredCompilation is off. I kept TieredCompilation check in MaterializeVirtualObjectTest.java which needs it for execution. TestJVMCIPrintProperties.java does not need Graal. It forks process with -Djvmci.Compiler=null to check properties setting and exit after that. So I excluding it from runs with Graal. Thanks, Vladimir On 6/6/19 11:33 AM, Vladimir Kozlov wrote: > Good suggestion. I will do that. > > Thanks > Vladimir > >> On Jun 6, 2019, at 11:23 AM, Igor Ignatyev wrote: >> >> Hi Vladimir, >> >> am I right assuming that +TieredCompilation is required only till we get libgraal? if so, I'd prefer to have them as separate @require directives (jtreg join all @require by logical-and) and preceded by @comment saying they are they needed and when they can be remove, smth like this: >> >>> diff -r f5dfbaa152ef test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java >>> --- a/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Wed Jun 05 18:28:03 2019 -0700 >>> +++ b/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Thu Jun 06 11:21:51 2019 -0700 >>> @@ -25,7 +25,9 @@ >>> * @test TestBasicLogOutput >>> * @bug 8203370 >>> * @summary Ensure -XX:-JVMCIPrintProperties can be enabled and successfully prints expected output to stdout. >>> - * @requires vm.jvmci >>> + * @requires vm.jvmci && vm.compMode == "Xmixed" >>> + * @comment graal w/ -Tiered is too slow, excluding this combination till we get libgraal (JDK-8207267), >>> + * @requires !vm.graal.enabled | vm.opt.TieredCompilation == null | vm.opt.TieredCompilation == true >>> * @library /test/lib >>> */ >> >> -- Igor >> >>> On Jun 5, 2019, at 3:20 PM, Vladimir Kozlov wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8225350 >>> http://cr.openjdk.java.net/~kvn/8225350/webrev.00/ >>> >>> Tests which use JVMCICompiler (Graal) explicitly are timed out when run with -Xcomp -XX:-TieredCompilation flags. >>> >>> Run such tests only in Xmixed + TieredCompilation mode. >>> >>> Thanks, >>> Vladimir >> > From igor.ignatyev at oracle.com Fri Jun 7 20:04:36 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 7 Jun 2019 13:04:36 -0700 Subject: [13] RFR(S) 8225350: compiler/jvmci/compilerToVM/IsCompilableTest.java timed out In-Reply-To: References: <9e3eb6b1-4fec-3fe8-7ea8-d0eec56e11d7@oracle.com> <73669281-F06A-46AE-BFEB-E9BC307F62CD@oracle.com> <70CC384E-4A80-4D63-8459-EE8CACBA195B@oracle.com> Message-ID: <1FF5A78F-D09C-4ECB-B638-E800AD523AB8@oracle.com> LGTM -- Igor > On Jun 7, 2019, at 12:35 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8225350/webrev.02/ > > After few testing I found that no need check Tiered compilation to pass tests. > Some changed tests (like IsCompilableTest.java) don't need Graal to compile a method - they only use JVMCI API. > Timeout happened with them only because of -Xcomp stop execution until a method is compiled (Xcomp switch off background compilation). Require running in Xmixed more is enough to avoid timeout even when TieredCompilation is off. > > I kept TieredCompilation check in MaterializeVirtualObjectTest.java which needs it for execution. > > TestJVMCIPrintProperties.java does not need Graal. It forks process with -Djvmci.Compiler=null to check properties setting and exit after that. So I excluding it from runs with Graal. > > Thanks, > Vladimir > > On 6/6/19 11:33 AM, Vladimir Kozlov wrote: >> Good suggestion. I will do that. >> Thanks >> Vladimir >>> On Jun 6, 2019, at 11:23 AM, Igor Ignatyev wrote: >>> >>> Hi Vladimir, >>> >>> am I right assuming that +TieredCompilation is required only till we get libgraal? if so, I'd prefer to have them as separate @require directives (jtreg join all @require by logical-and) and preceded by @comment saying they are they needed and when they can be remove, smth like this: >>> >>>> diff -r f5dfbaa152ef test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java >>>> --- a/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Wed Jun 05 18:28:03 2019 -0700 >>>> +++ b/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Thu Jun 06 11:21:51 2019 -0700 >>>> @@ -25,7 +25,9 @@ >>>> * @test TestBasicLogOutput >>>> * @bug 8203370 >>>> * @summary Ensure -XX:-JVMCIPrintProperties can be enabled and successfully prints expected output to stdout. >>>> - * @requires vm.jvmci >>>> + * @requires vm.jvmci && vm.compMode == "Xmixed" >>>> + * @comment graal w/ -Tiered is too slow, excluding this combination till we get libgraal (JDK-8207267), >>>> + * @requires !vm.graal.enabled | vm.opt.TieredCompilation == null | vm.opt.TieredCompilation == true >>>> * @library /test/lib >>>> */ >>> >>> -- Igor >>> >>>> On Jun 5, 2019, at 3:20 PM, Vladimir Kozlov wrote: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8225350 >>>> http://cr.openjdk.java.net/~kvn/8225350/webrev.00/ >>>> >>>> Tests which use JVMCICompiler (Graal) explicitly are timed out when run with -Xcomp -XX:-TieredCompilation flags. >>>> >>>> Run such tests only in Xmixed + TieredCompilation mode. >>>> >>>> Thanks, >>>> Vladimir >>> From vladimir.kozlov at oracle.com Fri Jun 7 20:53:33 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 7 Jun 2019 13:53:33 -0700 Subject: [13] RFR(S) 8225350: compiler/jvmci/compilerToVM/IsCompilableTest.java timed out In-Reply-To: <1FF5A78F-D09C-4ECB-B638-E800AD523AB8@oracle.com> References: <9e3eb6b1-4fec-3fe8-7ea8-d0eec56e11d7@oracle.com> <73669281-F06A-46AE-BFEB-E9BC307F62CD@oracle.com> <70CC384E-4A80-4D63-8459-EE8CACBA195B@oracle.com> <1FF5A78F-D09C-4ECB-B638-E800AD523AB8@oracle.com> Message-ID: Thank you, Igor Vladimir On 6/7/19 1:04 PM, Igor Ignatyev wrote: > LGTM > > -- Igor > >> On Jun 7, 2019, at 12:35 PM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8225350/webrev.02/ >> >> After few testing I found that no need check Tiered compilation to pass tests. >> Some changed tests (like IsCompilableTest.java) don't need Graal to compile a method - they only use JVMCI API. >> Timeout happened with them only because of -Xcomp stop execution until a method is compiled (Xcomp switch off background compilation). Require running in Xmixed more is enough to avoid timeout even when TieredCompilation is off. >> >> I kept TieredCompilation check in MaterializeVirtualObjectTest.java which needs it for execution. >> >> TestJVMCIPrintProperties.java does not need Graal. It forks process with -Djvmci.Compiler=null to check properties setting and exit after that. So I excluding it from runs with Graal. >> >> Thanks, >> Vladimir >> >> On 6/6/19 11:33 AM, Vladimir Kozlov wrote: >>> Good suggestion. I will do that. >>> Thanks >>> Vladimir >>>> On Jun 6, 2019, at 11:23 AM, Igor Ignatyev wrote: >>>> >>>> Hi Vladimir, >>>> >>>> am I right assuming that +TieredCompilation is required only till we get libgraal? if so, I'd prefer to have them as separate @require directives (jtreg join all @require by logical-and) and preceded by @comment saying they are they needed and when they can be remove, smth like this: >>>> >>>>> diff -r f5dfbaa152ef test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java >>>>> --- a/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Wed Jun 05 18:28:03 2019 -0700 >>>>> +++ b/test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java Thu Jun 06 11:21:51 2019 -0700 >>>>> @@ -25,7 +25,9 @@ >>>>> * @test TestBasicLogOutput >>>>> * @bug 8203370 >>>>> * @summary Ensure -XX:-JVMCIPrintProperties can be enabled and successfully prints expected output to stdout. >>>>> - * @requires vm.jvmci >>>>> + * @requires vm.jvmci && vm.compMode == "Xmixed" >>>>> + * @comment graal w/ -Tiered is too slow, excluding this combination till we get libgraal (JDK-8207267), >>>>> + * @requires !vm.graal.enabled | vm.opt.TieredCompilation == null | vm.opt.TieredCompilation == true >>>>> * @library /test/lib >>>>> */ >>>> >>>> -- Igor >>>> >>>>> On Jun 5, 2019, at 3:20 PM, Vladimir Kozlov wrote: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8225350 >>>>> http://cr.openjdk.java.net/~kvn/8225350/webrev.00/ >>>>> >>>>> Tests which use JVMCICompiler (Graal) explicitly are timed out when run with -Xcomp -XX:-TieredCompilation flags. >>>>> >>>>> Run such tests only in Xmixed + TieredCompilation mode. >>>>> >>>>> Thanks, >>>>> Vladimir >>>> > From leonid.mesnik at oracle.com Fri Jun 7 21:12:53 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 7 Jun 2019 14:12:53 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <328960e6-67d8-efa7-66b2-128a39d51259@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <328960e6-67d8-efa7-66b2-128a39d51259@oracle.com> Message-ID: <9C63833C-6547-4047-A031-B41E799090E9@oracle.com> Thank you for review. Leonid > On Jun 7, 2019, at 1:07 AM, Tobias Hartmann wrote: > > Hi Leonid, > > this looks good to me! Please remove the extra whitespace at the end of compileBroker.hpp:420 before > the ")". No new webrev required. > > Thanks, > Tobias > > On 07.06.19 02:36, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics >> command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 >> passed. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 >> >> Leonid >> >> From leonid.mesnik at oracle.com Fri Jun 7 21:13:01 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 7 Jun 2019 14:13:01 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> Message-ID: <855919F3-A2F1-4105-A0A6-E4E23B57397F@oracle.com> Thank you for review. Leonid > On Jun 7, 2019, at 11:29 AM, serguei.spitsyn at oracle.com wrote: > > On 6/7/19 11:23, Leonid Mesnik wrote: >> I read documentation about CRS on following wiki https://wiki.openjdk.java.net/display/csr . It says that CRS requires if command-line options are changes. >> However I believe that fix don't change actual behavior of 'granularity' option so no CSR is needed for this small help update. > > I see now. > Agreed, this dos not require a CSR. > > Thanks, > Serguei > > >> >> Any advise is welcome. >> >> Leonid >> >>> On Jun 7, 2019, at 9:48 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Okay then. >>> I wonder now, if a CSR needs to be filed for this change. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/7/19 09:10, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Currently DCmdArgument is used to parse any numeric values in dcmd framework including positive integer values for port, ttl etc. >>>> >>>> Adding new type DCmdArgument requires adding more specialized methods like >>>> template <> void DCmdArgument::parse_value(const char* str, >>>> size_t len, TRAPS) { >>>> >>>> and other to parse and validate any *integer* parameters. See >>>> http://hg.openjdk.java.net/jdk/jdk/file/47ee6c00d27c/src/hotspot/share/services/diagnosticArgument.cpp#l112 >>>> >>>> I think that it is easier to use single jlong for all integer like it is done now rather than adding more types. >>>> >>>> One might said that it would be better to add size_t type and use it for all non-negative integers. It would be good improvement for all dcmd args parsing. As well as overall improvement of parameters validation. (dcmd often don't throw exception and just return in the case of incorrect arguments). But sees like separate effort for whole dcmd framework. >>>> >>>> >>>> Leonid >>>>> On Jun 7, 2019, at 1:37 AM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Hi Leonid, >>>>> >>>>> It looks good to me. >>>>> One minor comment on the src/hotspot/share/services/diagnosticCommand.?pp >>>>> + DCmdArgument _granularity; >>>>> >>>>> I'm curios if using size_t instead of jlong as in other files would be more unified. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 6/6/19 17:36, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 passed. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 >>>>>> >>>>>> Leonid >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Fri Jun 7 22:12:00 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 7 Jun 2019 15:12:00 -0700 Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use Dependencies::find_unique_concrete_method() for non-virtual methods In-Reply-To: References: <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com> Message-ID: <4b6031ea-82fc-b3f9-be93-afea5d743c4b@oracle.com> Thanks Doug! dl On 6/7/19 1:13 AM, Doug Simon wrote: > Change looks good to me. > > -Doug > >> On 7 Jun 2019, at 04:41, Vladimir Kozlov wrote: >> >> Seems reasonable to me but Graal experts should review it. >> >> Thanks, >> Vladimir >> >> PS: please, run more graal tiers - I added comment in bug report. >> >> On 6/6/19 7:33 PM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8223050 >>> http://cr.openjdk.java.net/~dlong/8223050/webrev/ >>> Avoid generating unnecessary dependencies for methods that can be statically bound. While working on this I discovered that Graal's HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match that of the VM, because it was missing a check for . >>> dl From vladimir.x.ivanov at oracle.com Fri Jun 7 22:17:20 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 8 Jun 2019 01:17:20 +0300 Subject: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> Message-ID: <92f20357-b952-35d7-bd6f-4d7b53e05d2e@oracle.com> BTW should the fix also remove affected tests from the problem list? [1] Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk/jdk/rev/da9dac56aafc On 07/06/2019 03:41, Viswanathan, Sandhya wrote: > Please find below a small patch which fixes the issue: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 > > Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ > > Multiplication is implemented as shift, add sequence in certain cases. > > The problem was occurring because the ?shift by? register was being > overwritten due to missing effect statement in the shift rules. > > The problem was introduced as part of > https://bugs.openjdk.java.net/browse/JDK-8222074. > > The patch adds the missing effect statements. > > Best Regards, > > Sandhya > From vivek.r.deshpande at intel.com Fri Jun 7 22:48:14 2019 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 7 Jun 2019 22:48:14 +0000 Subject: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com> Thank you All. Pushed the changes. Regards, Vivek -----Original Message----- From: Viswanathan, Sandhya Sent: Friday, June 7, 2019 11:45 AM To: Vladimir Ivanov ; Tobias Hartmann Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R Subject: RE: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc Hi Vladimir/Tobias, Thanks a lot for the review. Best Regards, Sandhya -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Friday, June 07, 2019 3:41 AM To: Viswanathan, Sandhya ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc Looks good. Best regards, Vladimir Ivanov On 07/06/2019 03:41, Viswanathan, Sandhya wrote: > Please find below a small patch which fixes the issue: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 > > Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ > > Multiplication is implemented as shift, add sequence in certain cases. > > The problem was occurring because the "shift by" register was being > overwritten due to missing effect statement in the shift rules. > > The problem was introduced as part of > https://bugs.openjdk.java.net/browse/JDK-8222074. > > The patch adds the missing effect statements. > > Best Regards, > > Sandhya > From vladimir.kozlov at oracle.com Fri Jun 7 23:43:05 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 7 Jun 2019 16:43:05 -0700 Subject: [13] RFR(S) 8225492: Update JVMCI Message-ID: <1645aa7a-42c4-8ec0-20b9-ee42d810bdea@oracle.com> http://cr.openjdk.java.net/~kvn/8225492/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8225492 Sync latest jvmci-8 changes. Thanks, Vladimir From jesper.wilhelmsson at oracle.com Sat Jun 8 00:58:17 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Sat, 8 Jun 2019 02:58:17 +0200 Subject: RFR: JDK-8223807 - Update Graal Message-ID: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com> Hi, Please review the patch to integrate recent Graal changes into OpenJDK. Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433 JBS duplicates fixed by this integration: https://bugs.openjdk.java.net/browse/JDK-8223924 Bug: https://bugs.openjdk.java.net/browse/JDK-8223807 Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/ This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. Thanks, /Jesper -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From leelamohan.venati at gmail.com Sat Jun 8 01:39:39 2019 From: leelamohan.venati at gmail.com (Leela Mohan) Date: Fri, 7 Jun 2019 18:39:39 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: References: <4C2D0A78.5020906@oracle.com> <4C2D0EC1.4090607@oracle.com> Message-ID: This is super late reply to this review mail but i have couple of questions about this change. Looking at the diff here : http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/65b0c03b165d I think, Calling JvmtiExport::post_compiled_method_load(JvmtiEnv* env,..) to JvmtiExport::post_compiled_method_load(nmethod*) versio is possibly incorrect since, this would do callbacks to multiple jvmti environments (jvmti agents) which is unexpected. Callbacks are expected to be called to current jvmti env which called GenerateEvents. On Thu, Jul 1, 2010 at 4:07 PM Tom Rodriguez wrote: > Thanks. Dan also reviewed this as I was developing it. > > tom > > On Jul 1, 2010, at 2:55 PM, Vladimir Kozlov wrote: > > > Thanks, Tom > > > > Changes are good to go. > > > > Vladimir > > > > On 7/1/10 2:41 PM, Tom Rodriguez wrote: > >> > >> On Jul 1, 2010, at 2:36 PM, Vladimir Kozlov wrote: > >> > >>> You did not explain your changes for cb->name(). > >> > >> That was just a clean up I've been wanting to do. There was a time > then only some of the CodeBlob subclasses had name() methods but now it's > part of CodeBlob so that logic is unnecessary. > >> > >>> Why we don't lock nmethod in sweeper during CodeCache walk but lock > here? > >> > >> nmethodLocker protects you from the sweeper so the sweeper doesn't need > protection. > >> > >> tom > >> > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> On 7/1/10 1:58 PM, Tom Rodriguez wrote: > >>>> http://cr.openjdk.java.net/~never/6965671/ > >>>> > >>>> 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of > order with lock CodeCache_lock/1 > >>>> Reviewed-by: > >>>> > >>>> The jmethodID fix created a deadlock because of lock ordering when > >>>> walking the CodeCache to generate CompiledMethodLoad events. The walk > >>>> is performed with the CodeCache_lock held but we need to acquire the > >>>> JNIGlobalHandle_lock to make a jmethodID. I considered switching back > >>>> to collecting the methodOop instead of the jmethodID under the lock > >>>> but inspection of the code made it clear that there's a preexisting > >>>> problem with GC of the methodOops stored into the nmethodDesc. > >>>> Instead I switched to a simpler implementation that holds the > >>>> CodeCache_lock while walking the CodeCache but releases the lock to > >>>> actually perform the notify. This simplifies the code greatly as well > >>>> as fixing the bug. > >>>> > >>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION > >>>> tests. > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Sat Jun 8 04:36:52 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 7 Jun 2019 21:36:52 -0700 Subject: RFR(S) : 8149040 : Cleanup compiler/jsr292/NonInlinedCall tests after JDK-8148994 In-Reply-To: References: <35CF8810-C61E-40CC-AFA6-20AC385B74D6@oracle.com> Message-ID: <387413AC-2AF4-4DA4-B727-4D4B6F7CDC13@oracle.com> Tobias, Vladimir, thank you both for your review. pushed. -- Igor > On Jun 7, 2019, at 1:00 AM, Tobias Hartmann wrote: > > +1 > > Best regards, > Tobias > > On 06.06.19 23:53, Vladimir Kozlov wrote: >> Good. >> >> Thanks >> Vladimir >> >>> On Jun 6, 2019, at 2:17 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8149040/webrev.00/index.html >>>> 168 lines changed: 1 ins; 162 del; 5 mod; >>> >>> Hi all, >>> >>> could you please review this small clean up in NonInlinedCall tests? >>> >>> testing: tier1 + compiler/jsr292 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8149040/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149040 >>> >>> Thanks, >>> -- Igor From Alan.Bateman at oracle.com Sun Jun 9 15:53:55 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 9 Jun 2019 16:53:55 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> Message-ID: <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> On 07/06/2019 12:24, Andrew Dinn wrote: > : > Modulo confirmation of those two checks this looks like it is a complete > implementation. Unless anyone has more changes to recommend? > I read through the recent mails and I think you are nearly done with the code review. There are still a few updates to be done to the JEP and it will need to be endorsed before propose-to-target. Given that JDK 13 enters RDP1 on June 13 then I assume it's best to re-target the CSR to 14 and for the JEP to become a candidate for that release. -Alan. From lutz.schmidt at sap.com Sun Jun 9 19:15:43 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Sun, 9 Jun 2019 19:15:43 +0000 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <9C63833C-6547-4047-A031-B41E799090E9@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <328960e6-67d8-efa7-66b2-128a39d51259@oracle.com>, <9C63833C-6547-4047-A031-B41E799090E9@oracle.com> Message-ID: <1AC06094-D32D-42E6-832A-3B77E8B3B380@sap.com> Hi Leonid, thanks for taking care of this. I?m on vacation and almost offline. Best, Lutz Lutz Schmidt | P&I Technology HCP Core | +49 (6227) 7-42834 On 7. Jun 2019, at 23:14, Leonid Mesnik wrote: Thank you for review. Leonid > On Jun 7, 2019, at 1:07 AM, Tobias Hartmann wrote: > > Hi Leonid, > > this looks good to me! Please remove the extra whitespace at the end of compileBroker.hpp:420 before > the ")". No new webrev required. > > Thanks, > Tobias > >> On 07.06.19 02:36, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics >> command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 >> passed. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 >> >> Leonid >> >> From gromero at linux.vnet.ibm.com Sun Jun 9 20:43:32 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Sun, 9 Jun 2019 17:43:32 -0300 Subject: RFR(M): 8224826: Implement fast class initialization checks on PPC64 In-Reply-To: References: Message-ID: Hi Martin, On 06/06/2019 09:27 AM, Doerr, Martin wrote: > please review the rebased and updated version (after JDK-8225106): > > http://cr.openjdk.java.net/~mdoerr/8224826_ppc64_fast_clinit/webrev.01/ Change looks good. I also tested the 'release' and 'fastdebug' builds in different modes (Interpreter, C1 TieredStopAtLevel={2,3}, and C2). For 'release' I checked the speedups using the microbench from Claes [1] and observed significant speedups (~10x) in the static member/block initialization. Best regards, Gustavo [1] https://bugs.openjdk.java.net/browse/JDK-8219233 From adinn at redhat.com Mon Jun 10 07:56:59 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 10 Jun 2019 08:56:59 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> Message-ID: <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> On 09/06/2019 16:53, Alan Bateman wrote: > On 07/06/2019 12:24, Andrew Dinn wrote: >> : >> Modulo confirmation of those two checks this looks like it is a complete >> implementation. Unless anyone has more changes to recommend? >> > I read through the recent mails and I think you are nearly done with the > code review. There are still a few updates to be done to the JEP and it > will need to be endorsed before propose-to-target. Given that JDK 13 > enters RDP1 on June 13 then I assume it's best to re-target the CSR to > 14 and for the JEP to become a candidate for that release. Yes, I agree it is too late to squeeze this into 13. I have updated the fix version for the JEP and CSR to 14: JEP: https://bugs.openjdk.java.net/browse/JDK-8207851 CSR: https://bugs.openjdk.java.net/browse/JDK-8224975 I'll wait for any further feedback on the JEP and implementation. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Mon Jun 10 08:18:06 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2019 09:18:06 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> Message-ID: <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> On 10/06/2019 08:56, Andrew Dinn wrote: > : > Yes, I agree it is too late to squeeze this into 13. I have updated the > fix version for the JEP and CSR to 14: > > JEP: https://bugs.openjdk.java.net/browse/JDK-8207851 > CSR: https://bugs.openjdk.java.net/browse/JDK-8224975 > > I'll wait for any further feedback on the JEP and implementation. > The new release cadence is wonderful for situations like this as JDK 14 is only 6 months after 13. I don't have any other feedback on the JEP beyond my last mail about removing the "Proposed Java API Changes" section from the Description. Once we you ready then Brian (as area lead) should be contacted to seek his endorsement. -Alan [1] https://mail.openjdk.java.net/pipermail/nio-dev/2019-June/006238.html From adinn at redhat.com Mon Jun 10 10:09:03 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 10 Jun 2019 11:09:03 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> Message-ID: <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> Hi Alan, On 10/06/2019 09:18, Alan Bateman wrote: > I don't have any other feedback on the JEP beyond my last mail about > removing the "Proposed Java API Changes" section from the Description. > Once we you ready then Brian (as area lead) should be contacted to seek > his endorsement. I have updated the Proposed Java API Changes to remove the changes to map exception signature and force region specification. They were covered in the prior enabling JIRAs/CSRs. So, the remaining two sections mention 1) the new module + package + enum and 2) the bean counting changes. The new section 1 clarifies when UnsupportedOperationException is thrown vs when IOException is thrown as part of the explanation of what the new modes are for. I also added a paragraph to the alternatives section explaining that Panama was and still is an alternative option and why we decided to proceed with this model despite it being still under consideration. Finally, I am unclear whether the presence of the new module + package means this is an SE JEP or a JDK JEP? In the latest update I have assumed the JEP type is still JDK and changed the title for the public API changes to "Proposed Java API Changes". Is that right? Or do you want the JEP type to be SE and have the title remain "Proposed Java SE API Changes" regards, Andrew Dinn ----------- From nils.eliasson at oracle.com Mon Jun 10 13:55:25 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 10 Jun 2019 15:55:25 +0200 Subject: RFR(T/XS): 8225509: clean_catch_blocks must add preds first Message-ID: Hi, When the late load barrier insertion is handling loads in clean_catch_blocks, the pushing of predecessor nodes on the iteration stack must be done before the processing of a load, because it changes the graph. Bug: https://bugs.openjdk.java.net/browse/JDK-8225509 Webrev: http://cr.openjdk.java.net/~neliasso/8225509/webrev.01/ Please review, Nils From vladimir.kozlov at oracle.com Mon Jun 10 15:04:33 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Jun 2019 08:04:33 -0700 Subject: RFR(T/XS): 8225509: clean_catch_blocks must add preds first In-Reply-To: References: Message-ID: <7fda9b8c-806c-d1e7-a003-e418975e2d94@oracle.com> Good. Thanks, Vladimir On 6/10/19 6:55 AM, Nils Eliasson wrote: > Hi, > > When the late load barrier insertion is handling loads in clean_catch_blocks, the pushing of predecessor nodes on the > iteration stack must be done before the processing of a load, because it changes the graph. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225509 > > Webrev: http://cr.openjdk.java.net/~neliasso/8225509/webrev.01/ > > Please review, > > Nils > From nils.eliasson at oracle.com Mon Jun 10 15:27:39 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 10 Jun 2019 17:27:39 +0200 Subject: RFR(T/XS): 8225509: clean_catch_blocks must add preds first In-Reply-To: <7fda9b8c-806c-d1e7-a003-e418975e2d94@oracle.com> References: <7fda9b8c-806c-d1e7-a003-e418975e2d94@oracle.com> Message-ID: <663bbe8d-21a3-2704-a289-feeb9605a8c3@oracle.com> Thank you Vladimir! / Nils On 2019-06-10 17:04, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 6/10/19 6:55 AM, Nils Eliasson wrote: >> Hi, >> >> When the late load barrier insertion is handling loads in >> clean_catch_blocks, the pushing of predecessor nodes on the iteration >> stack must be done before the processing of a load, because it >> changes the graph. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225509 >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8225509/webrev.01/ >> >> Please review, >> >> Nils >> From vladimir.kozlov at oracle.com Mon Jun 10 15:49:50 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Jun 2019 08:49:50 -0700 Subject: RFR: JDK-8223807 - Update Graal In-Reply-To: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com> References: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com> Message-ID: <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com> There are a lot of crashes in compiler/aot and gc/stress/gcbasher tests. We need to resolve them. It seems you don't need to apply `overwritten` changes - Update changes has them. Thanks, Vladimir On 6/7/19 5:58 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review the patch to integrate recent Graal changes into OpenJDK. > Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433 > > JBS duplicates fixed by this integration: > https://bugs.openjdk.java.net/browse/JDK-8223924 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223807 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/ > > This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. > > Thanks, > /Jesper > From vladimir.kozlov at oracle.com Mon Jun 10 16:05:29 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Jun 2019 09:05:29 -0700 Subject: RFR: JDK-8223807 - Update Graal In-Reply-To: <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com> References: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com> <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com> Message-ID: <67f36d91-1936-2937-756f-ae75f8bf03ae@oracle.com> These changes incorrectly reversed part of 8209626 changes in jaotc/MetadataBuilder.java file causing these AOT failures. Vladimir On 6/10/19 8:49 AM, Vladimir Kozlov wrote: > There are a lot of crashes in compiler/aot and gc/stress/gcbasher tests. We need to resolve them. > > It seems you don't need to apply `overwritten` changes - Update changes has them. > > Thanks, > Vladimir > > On 6/7/19 5:58 PM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> Please review the patch to integrate recent Graal changes into OpenJDK. >> Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433 >> >> JBS duplicates fixed by this integration: >> https://bugs.openjdk.java.net/browse/JDK-8223924 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223807 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/ >> >> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >> >> Thanks, >> /Jesper >> From Alan.Bateman at oracle.com Mon Jun 10 17:44:04 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2019 18:44:04 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> Message-ID: <072ce1bb-ad2c-a2cd-42fc-b4076dac99c7@oracle.com> On 10/06/2019 11:09, Andrew Dinn wrote: > : > Finally, I am unclear whether the presence of the new module + package > means this is an SE JEP or a JDK JEP? In the latest update I have > assumed the JEP type is still JDK and changed the title for the public > API changes to "Proposed Java API Changes". Is that right? Or do you > want the JEP type to be SE and have the title remain "Proposed Java SE > API Changes" > The module is JDK-specific so keeping the scope "JDK" is right. -Alan From tom.rodriguez at oracle.com Mon Jun 10 17:45:37 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 10 Jun 2019 10:45:37 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: References: <4C2D0A78.5020906@oracle.com> <4C2D0EC1.4090607@oracle.com> Message-ID: <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com> Leela Mohan wrote on 6/7/19 6:39 PM: > This is super late reply to this review mail but i have couple of > questions about this change. Wow 9 years. :) > > Looking at the diff here : > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/65b0c03b165d > > I think, Calling?JvmtiExport::post_compiled_method_load(JvmtiEnv* > env,..) to?JvmtiExport::post_compiled_method_load(nmethod*) versio is > possibly incorrect since, this would do callbacks to multiple jvmti > environments (jvmti agents) which is unexpected. Callbacks are expected > to be called to current jvmti env which called GenerateEvents. I think you're right. Anyone listening for those events will also get notified which isn't quite right. Please file a bug. It should be easy enough to fix. Factoring out the notification body of post_compiled_method_load into it's own method and calling that from generate_compiled_method_load_events would work great. tom > > > > > > On Thu, Jul 1, 2010 at 4:07 PM Tom Rodriguez > wrote: > > Thanks.? Dan also reviewed this as I was developing it. > > tom > > On Jul 1, 2010, at 2:55 PM, Vladimir Kozlov wrote: > > > Thanks, Tom > > > > Changes are good to go. > > > > Vladimir > > > > On 7/1/10 2:41 PM, Tom Rodriguez wrote: > >> > >> On Jul 1, 2010, at 2:36 PM, Vladimir Kozlov wrote: > >> > >>> You did not explain your changes for cb->name(). > >> > >> That was just a clean up I've been wanting to do.? There was a > time then only some of the CodeBlob subclasses had name() methods > but now it's part of CodeBlob so that logic is unnecessary. > >> > >>> Why we don't lock nmethod in sweeper during CodeCache walk but > lock here? > >> > >> nmethodLocker protects you from the sweeper so the sweeper > doesn't need protection. > >> > >> tom > >> > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> On 7/1/10 1:58 PM, Tom Rodriguez wrote: > >>>> http://cr.openjdk.java.net/~never/6965671/ > > >>>> > >>>> 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 > out of order with lock CodeCache_lock/1 > >>>> Reviewed-by: > >>>> > >>>> The jmethodID fix created a deadlock because of lock ordering when > >>>> walking the CodeCache to generate CompiledMethodLoad events. > The walk > >>>> is performed with the CodeCache_lock held but we need to > acquire the > >>>> JNIGlobalHandle_lock to make a jmethodID.? I considered > switching back > >>>> to collecting the methodOop instead of the jmethodID under the > lock > >>>> but inspection of the code made it clear that there's a > preexisting > >>>> problem with GC of the methodOops stored into the nmethodDesc. > >>>> Instead I switched to a simpler implementation that holds the > >>>> CodeCache_lock while walking the CodeCache but releases the > lock to > >>>> actually perform the notify.? This simplifies the code greatly > as well > >>>> as fixing the bug. > >>>> > >>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and > JDI_REGRESSION > >>>> tests. > >> > From vladimir.kozlov at oracle.com Mon Jun 10 21:44:21 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Jun 2019 14:44:21 -0700 Subject: an issue after: 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com> Message-ID: Hi Sandhya and Vivek, I got new failure after pulling these changes. The failure is intermittent, I saw it once in my testing. The failed test compiler/codegen/TestShortFloatVect.java ran without any other flags with only ones specified in test's @run. I got: ----------System.out:(3/50)---------- Testing Short + Float vectors Warmup Verification ----------System.err:(17/546)---------- test_ci: b1[968] = 0.0 != -103.0 test_ci: b1[969] = 0.0 != -103.0 test_ci: b1[970] = 0.0 != -103.0 test_ci: b1[971] = 0.0 != -103.0 test_ci: b1[976] = 0.0 != -103.0 test_ci: b1[977] = 0.0 != -103.0 test_ci: b1[978] = 0.0 != -103.0 test_ci: b1[979] = 0.0 != -103.0 test_ci: b1[984] = 0.0 != -103.0 test_ci: b1[985] = 0.0 != -103.0 test_ci: b1[986] = 0.0 != -103.0 test_ci: b1[987] = 0.0 != -103.0 test_ci: b1[992] = 0.0 != -103.0 test_ci: b1[993] = 0.0 != -103.0 test_ci: b1[994] = 0.0 != -103.0 test_ci: b1[995] = 0.0 != -103.0 FAILED: 16 errors test_ci() method simple assign constant value to short[] and float[] arrays in the same loop: static void test_ci(short[] a, float[] b) { for (int i = 0; i < a.length; i+=1) { a[i] = -123; b[i] = -103.f; } } The HW is MacPro with Xeon E5-1620_v2 3.70GHz FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C SMEP ERMS RDWRFSGS SYSCALL XD 1GBPAGE EM64T LAHF RDTSCP TSCI Please, look. Thanks, Vladimir On 6/7/19 3:48 PM, Deshpande, Vivek R wrote: > Thank you All. > Pushed the changes. > > Regards, > Vivek > > -----Original Message----- > From: Viswanathan, Sandhya > Sent: Friday, June 7, 2019 11:45 AM > To: Vladimir Ivanov ; Tobias Hartmann > Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R > Subject: RE: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc > > Hi Vladimir/Tobias, > > Thanks a lot for the review. > > Best Regards, > Sandhya > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Friday, June 07, 2019 3:41 AM > To: Viswanathan, Sandhya ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc > > Looks good. > > Best regards, > Vladimir Ivanov > > On 07/06/2019 03:41, Viswanathan, Sandhya wrote: >> Please find below a small patch which fixes the issue: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 >> >> Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ >> >> Multiplication is implemented as shift, add sequence in certain cases. >> >> The problem was occurring because the "shift by" register was being >> overwritten due to missing effect statement in the shift rules. >> >> The problem was introduced as part of >> https://bugs.openjdk.java.net/browse/JDK-8222074. >> >> The patch adds the missing effect statements. >> >> Best Regards, >> >> Sandhya >> From igor.veresov at oracle.com Mon Jun 10 22:11:49 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 10 Jun 2019 15:11:49 -0700 Subject: [13] RFR(S) 8225492: Update JVMCI In-Reply-To: <1645aa7a-42c4-8ec0-20b9-ee42d810bdea@oracle.com> References: <1645aa7a-42c4-8ec0-20b9-ee42d810bdea@oracle.com> Message-ID: <3F67C3A9-F5FB-4B95-B29A-53C37E997049@oracle.com> Looks good. igor > On Jun 7, 2019, at 4:43 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8225492/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8225492 > > Sync latest jvmci-8 changes. > > Thanks, > Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Jun 10 22:17:09 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Jun 2019 15:17:09 -0700 Subject: [13] RFR(S) 8225492: Update JVMCI In-Reply-To: <3F67C3A9-F5FB-4B95-B29A-53C37E997049@oracle.com> References: <1645aa7a-42c4-8ec0-20b9-ee42d810bdea@oracle.com> <3F67C3A9-F5FB-4B95-B29A-53C37E997049@oracle.com> Message-ID: Thank you, Igor Vladimir > On Jun 10, 2019, at 3:11 PM, Igor Veresov wrote: > > Looks good. > > igor > > > >> On Jun 7, 2019, at 4:43 PM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8225492/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8225492 >> >> Sync latest jvmci-8 changes. >> >> Thanks, >> Vladimir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Jun 10 23:30:14 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 10 Jun 2019 16:30:14 -0700 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <08aef662-69e2-eb70-ef83-043837dbdd69@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <506d2bee-9376-52f7-731c-4d872c944847@oracle.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <08aef662-69e2-eb70-ef83-043837dbdd69@redhat.com> Message-ID: Hi Andrew, > On Jun 7, 2019, at 7:10 AM, Andrew Dinn wrote: > >> I have uploaded a new webrev to fix the bove problems. This version also >> removes all the extra extraneous whitespace found by Brian and Gustavo. >> >> webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.07/ >> >> I have posted the changes to the submit repo to re-verify that all >> builds pass. I have also asked Jonathan Halliday to re-test this version >> against the Red Hat middleware clients to ensure there are no functional >> or performance changes. >> >> Modulo confirmation of those two checks this looks like it is a complete >> implementation. Unless anyone has more changes to recommend? > I just want to confirm that the submit job was clean and the middleware > clients are performing as expected. I wanted to let you know that I ran version 7 above through our tests and did not see any problems related to your changes. I think the copyright years in PmemTest.java are wrong however: 2002, 2011. I suppose it should be just 2019. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Tue Jun 11 02:45:14 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 11 Jun 2019 04:45:14 +0200 Subject: RFR: JDK-8223807 - Update Graal In-Reply-To: <67f36d91-1936-2937-756f-ae75f8bf03ae@oracle.com> References: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com> <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com> <67f36d91-1936-2937-756f-ae75f8bf03ae@oracle.com> Message-ID: <10CB23D8-7D4F-40C5-AD54-B2E8E3E71C52@oracle.com> Hi, I re-applied the patch for JDK-8209626 and restarted the testing. /Jesper > On 10 Jun 2019, at 18:05, Vladimir Kozlov wrote: > > These changes incorrectly reversed part of 8209626 changes in jaotc/MetadataBuilder.java file causing these AOT failures. > > Vladimir > > On 6/10/19 8:49 AM, Vladimir Kozlov wrote: >> There are a lot of crashes in compiler/aot and gc/stress/gcbasher tests. We need to resolve them. >> It seems you don't need to apply `overwritten` changes - Update changes has them. >> Thanks, >> Vladimir >> On 6/7/19 5:58 PM, jesper.wilhelmsson at oracle.com wrote: >>> Hi, >>> >>> Please review the patch to integrate recent Graal changes into OpenJDK. >>> Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433 >>> >>> JBS duplicates fixed by this integration: >>> https://bugs.openjdk.java.net/browse/JDK-8223924 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223807 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/ >>> >>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>> >>> Thanks, >>> /Jesper >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From martin.doerr at sap.com Tue Jun 11 07:54:11 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 Jun 2019 07:54:11 +0000 Subject: RFR(M): 8224826: Implement fast class initialization checks on PPC64 In-Reply-To: References: Message-ID: Hi Vladimir and Gustavo, thank you for reviewing. Also thanks for the performance measurement. Best regards, Martin > -----Original Message----- > From: Gustavo Romero > Sent: Sonntag, 9. Juni 2019 22:44 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' ; > hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8224826: Implement fast class initialization checks on > PPC64 > Importance: High > > Hi Martin, > > On 06/06/2019 09:27 AM, Doerr, Martin wrote: > > please review the rebased and updated version (after JDK-8225106): > > > > > http://cr.openjdk.java.net/~mdoerr/8224826_ppc64_fast_clinit/webrev.01/ > > Change looks good. > > I also tested the 'release' and 'fastdebug' builds in different modes > (Interpreter, C1 TieredStopAtLevel={2,3}, and C2). For 'release' I checked the > speedups using the microbench from Claes [1] and observed significant > speedups > (~10x) in the static member/block initialization. > > Best regards, > Gustavo > > [1] https://bugs.openjdk.java.net/browse/JDK-8219233 From nils.eliasson at oracle.com Tue Jun 11 08:27:12 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 11 Jun 2019 10:27:12 +0200 Subject: RFR(T): 8225564: Remove wrong assert in clean_catch_blocks Message-ID: <7d0e33db-2890-a8ff-235f-3768d89cfa8e@oracle.com> Hi, This patch removes an assert that is wrong. When traversing the graph for fixing the catch blocks, postorder is not guaranteed. The fix_up_uses can find a load that must be handled first. The cleanup already supports (and expects that). Bug: https://bugs.openjdk.java.net/browse/JDK-8225564 Webrev: http://cr.openjdk.java.net/~neliasso/8225564/ Regards, Nils From rahul.v.raghavan at oracle.com Tue Jun 11 08:53:42 2019 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Tue, 11 Jun 2019 14:23:42 +0530 Subject: RFR: 8225567: Wrong file headers with 8202414 fix changeset Message-ID: <4cd0944a-9039-0eef-c44c-21ca3fd8cc69@oracle.com> Hi, Please review the following changes. During 8202414 fix, by mistake committed files with wrong header. So proposing following changes as fix - http://cr.openjdk.java.net/~rraghavan/8225567/webrev.00/ [src/hotspot/share/opto/memnode.cpp] - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights reserved. [test/hotspot/jtreg/compiler/c2/Test8202414.java] - * Copyright (c) 2019, Huawei Technologies Co. Ltd. All rights reserved. + * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. Thanks, Rahul From tobias.hartmann at oracle.com Tue Jun 11 08:57:01 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 11 Jun 2019 10:57:01 +0200 Subject: RFR: 8225567: Wrong file headers with 8202414 fix changeset In-Reply-To: <4cd0944a-9039-0eef-c44c-21ca3fd8cc69@oracle.com> References: <4cd0944a-9039-0eef-c44c-21ca3fd8cc69@oracle.com> Message-ID: <9064bba7-63bb-4a3f-1877-93adb4a57d3d@oracle.com> Hi Rahul, looks good and trivial to me. Best regards, Tobias On 11.06.19 10:53, Rahul Raghavan wrote: > Hi, > > Please review the following changes. > > During 8202414 fix, by mistake committed files with wrong header. > So proposing following changes as fix > > - http://cr.openjdk.java.net/~rraghavan/8225567/webrev.00/ > > > [src/hotspot/share/opto/memnode.cpp] > - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights reserved. > > > [test/hotspot/jtreg/compiler/c2/Test8202414.java] > - * Copyright (c) 2019, Huawei Technologies Co. Ltd. All rights reserved. > + * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. > > > Thanks, > Rahul From adam.farley at uk.ibm.com Tue Jun 11 09:04:04 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 11 Jun 2019 10:04:04 +0100 Subject: RFR: JDK-8224963: Char-Byte Performance Enhancement In-Reply-To: References: <68b970be-e551-577d-0ca1-28c16880a2ff@oracle.com> Message-ID: Hi Vladmir, Yes, that is what I see locally as well. Merely patching the class library code will not effect any performance enhancement. Quite the opposite. :) The changes in the class library were designed to work in tandem with some changes to the OpenJ9 JIT compiler, which is what accelerates performance. Naturally, investigating and sharing OpenJ9 logic is a bad idea due to contamination, so we're stuck with investigating the CL changes to identify any potential value to OpenJDK with Hotspot. You mentioned: > >> Among all options, I'm in favor of enhancing C2 to produce better code. > >> Then on my preference list goes rewriting JDK code to make it amenable > >> to missing optimizations (the patch you propose). And, as a last resort, > >> I'd consider introducing new intrinsics. I wouldn't know where to start with enhancing C2, and since intrinsics are dead last, that leaves "missing optimizations". Is there a guide to code patterns the Hotspot JIT matches on for optimizations? Seems like that'd be a useful thing to have in many circumstances. Best Regards Adam Farley IBM Runtimes Vladimir Ivanov wrote on 05/06/2019 19:15:27: > From: Vladimir Ivanov > To: Adam Farley8 > Cc: hotspot-compiler-dev at openjdk.java.net > Date: 05/06/2019 19:15 > Subject: Re: RFR: JDK-8224963: Char-Byte Performance Enhancement > > Thanks, Adam. > > I ported ASCIIEncodingBenchmark to JMH [1] and then tried your patch [2] > on x86 (Skylake). Unfortunately, I couldn't reproduce any improvements. > Moreover, the patched version is slower: > > ASCIIEncodingBenchmark.charToByte > > BEFORE > > (numberOfChars) Mode Cnt Score Error Units > 0 thrpt 5 111413694.893 ? 763410.998 ops/s > 1 thrpt 5 87992741.333 ? 148702.045 ops/s > 16 thrpt 5 53456010.326 ? 100007.754 ops/s > 64 thrpt 5 27901519.758 ? 94808.481 ops/s > 512 thrpt 5 4958471.149 ? 14774.009 ops/s > 4096 thrpt 5 600449.051 ? 37885.719 ops/s > 8192 thrpt 5 269098.868 ? 1634.533 ops/s > 65536 thrpt 5 38855.167 ? 92.170 ops/s > 1048576 thrpt 5 2630.800 ? 5.076 ops/s > > > AFTER (w/ [2] applied) > > (numberOfChars) Mode Cnt Score Error Units > 0 thrpt 5 119674686.849 ? 510819.775 ops/s > 1 thrpt 5 80067544.958 ? 176550.132 ops/s > 16 thrpt 5 47836555.989 ? 137233.882 ops/s > 64 thrpt 5 22814214.962 ? 80747.066 ops/s > 512 thrpt 5 3686203.220 ? 38087.643 ops/s > 4096 thrpt 5 489024.453 ? 55092.933 ops/s > 8192 thrpt 5 243057.291 ? 1483.443 ops/s > 65536 thrpt 5 30503.779 ? 43.282 ops/s > 1048576 thrpt 5 1879.556 ? 10.168 ops/s > > Best regards, > Vladimir Ivanov > > [1] > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Evlivanov_afarley_8224963_benchmarks_src_main_java_org_benchmark_ASCIIEncodingBenchmark.java&d=DwID- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DhftUaO7rUKBkPBr7fj_QKxuhGMMaGVLpOOaH3S32mQ&s=bJmKa3fafyoSYAtBdtVGwupNh-2GBKXqmq1N3Xlk7dM&e= > > [2] https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8224963_webrev_&d=DwID- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DhftUaO7rUKBkPBr7fj_QKxuhGMMaGVLpOOaH3S32mQ&s=FjbcOPZ3tu8D4vAty24tvlqXLT8-1urgxzI3PNHnwr4&e= > > On 31/05/2019 19:07, Adam Farley8 wrote: > > Hi Vladimir, > > > > Here's a minimised version of the benchmark, which converts chars to > > bytes using nio. > > > > I found that the conversion rates are similar between Hotspot and OpenJ9 > > for encoding > > single-character buffers, and that the difference becomes palpable as > > you increase the > > size of the buffer. 4096-char buffers, for example, show the 6x > > difference I mentioned > > earlier. > > > > This makes sense to me, as we're spending less time messing around with > > objects at the > > test level, and more time actually utilising the encoding code. > > > > You should just be able to run the benchmark on the command line. > > > > "java ASCIIEncodingBenchmark " > > > > Benchmark code: > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8224963_ASCIIEncodingBenchmark.java&d=DwID- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DhftUaO7rUKBkPBr7fj_QKxuhGMMaGVLpOOaH3S32mQ&s=NZb- > FdMcPTYj5JaL96_u4pjbApNczpZcIf28okScqqE&e= > > > > If you need a microbenchmark for a specific framework, name it and I'll > > get it done. > > > > Or one of my team will get it done. Off for a week. :) > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > Vladimir Ivanov wrote on 29/05/201917:19:36: > > > >> From: Vladimir Ivanov > >> To: Adam Farley8 > >> Cc: hotspot-compiler-dev at openjdk.java.net > >> Date: 29/05/2019 17:23 > >> Subject: Re: RFR: JDK-8224963: Char-Byte Performance Enhancement > >> > >> Adam, > >> > >> Among all options, I'm in favor of enhancing C2 to produce better code. > >> Then on my preference list goes rewriting JDK code to make it amenable > >> to missing optimizations (the patch you propose). And, as a last resort, > >> I'd consider introducing new intrinsics. > >> > >> The microbenchmarks would help understand what pieces as missing in C2 > >> and decide how to proceed. > >> > >> I haven't had HotSpot vs J9 comparison in mind, but in absence of > >> benchmarks available comparing generated code (by C2) between original > >> and updated JDK version would help understand what goes wrong. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >> On 29/05/2019 17:53, Adam Farley8 wrote: > >> > Hi Vladimir, > >> > > >> > I have a locally-written performance test I used to get the "6x". > >> > Will chase up with the guy who wrote it to see if I can share it. > >> > If not, I'll write a new one. > >> > > >> > As for the enhancements, two options are: > >> > > >> > - matching on the new method names, and replacing the inner logic > >> > with some souped-up version of said logic. > >> > > >> > - alter the code to match on one of the C2 idioms, though I imagine > >> > if it were that simple, OpenJDK would come with a list of said > >> > idioms so everything people write can be easily accelerated by the > >> > JIT. > >> > > >> > As for how OpenJ9 does it specifically, I don't know, and I suspect > >> > it's safer if I don't find out, contamination-wise. > >> > > >> > Does any of that help? > >> > > >> > Best Regards > >> > > >> > Adam Farley > >> > IBM Runtimes > >> > > >> > > >> > Vladimir Ivanov wrote on 29/05/ > 201913:22:27: > >> > > >> >> From: Vladimir Ivanov > >> >> To: Adam Farley8 , hotspot-compiler- > >> >> dev at openjdk.java.net > >> >> Date: 29/05/2019 13:22 > >> >> Subject: Re: RFR: JDK-8224963: Char-Byte Performance Enhancement > >> >> > >> >> Hi Adam, > >> >> > >> >> The bug mentions ~6x improvement in throughput. Are there have any > >> >> microbenchmarks you can share which demonstrate that? That > would greatly > >> >> simplify the analysis of changes you propose. > >> >> > >> >> Also, if you can elaborate on what optimization opportunities C2 misses > >> >> in original code, please, do. > >> >> > >> >> Best regards, > >> >> Vladimir Ivanov > >> >> > >> >> On 29/05/2019 12:45, Adam Farley8 wrote: > >> >> > Hi All, > >> >> > > >> >> > Could someone familiar with the Hotspot JIT please review > and opine on > >> >> > the below? > >> >> > > >> >> > The Char-Byte encoding/decoding methods inside some of the sun.nio.cs > >> >> > classes > >> >> > (such as US_ASCII) see a lot of use, and OpenJDK on the OpenJ9 > >> VM seems to > >> >> > do this a lot faster. > >> >> > > >> >> > Is it possible to achieve a similar improvement on OpenJDK > on Hotspot by > >> >> > tweaking the CL code to match Hotspot JIT compiler idioms, or by > >> >> > introducing > >> >> > a method name for the HS JIT to match on? > >> >> > > >> >> > An example of these changes to US_ASCII.java is linked > below. No OpenJ9 > >> >> > code > >> >> > is included in the work item or the webrev, to avoid contamination. > >> >> > > >> >> > Work item: https://urldefense.proofpoint.com/v2/url? > >> >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8224963&d=DwIC- > >> >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=4XPqGhxLchCLvSQhTIu3Wvm63NE2XpuEJf- > >> >> PzjFCXb4&s=2ChxP3IE0tkvevxSXfil3PGlpEHkUPxgwMxHH5J-A34&e= > >> >> > > >> >> > Example Webrev: _https://urldefense.proofpoint.com/v2/url? > >> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8224963_webrev_-5F&d=DwIC- > >> >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=4XPqGhxLchCLvSQhTIu3Wvm63NE2XpuEJf- > >> >> PzjFCXb4&s=fCeNvvk3Fehc6ssZfoNkJao_NJyoxeov7cxiyMSvuwQ&e= > >> >> > > >> >> > Best Regards > >> >> > > >> >> > Adam Farley > >> >> > IBM Runtimes > >> >> > > >> >> > Unless stated otherwise above: > >> >> > IBM United Kingdom Limited - Registered in England and > Wales with number > >> >> > 741598. > >> >> > Registered office: PO Box 41, North Harbour, Portsmouth, > >> Hampshire PO6 3AU > >> >> > >> > > >> > Unless stated otherwise above: > >> > IBM United Kingdom Limited - Registered in England and Wales with number > >> > 741598. > >> > Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > >> > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahul.v.raghavan at oracle.com Tue Jun 11 09:07:54 2019 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Tue, 11 Jun 2019 14:37:54 +0530 Subject: RFR: 8225567: Wrong file headers with 8202414 fix changeset In-Reply-To: <9064bba7-63bb-4a3f-1877-93adb4a57d3d@oracle.com> References: <4cd0944a-9039-0eef-c44c-21ca3fd8cc69@oracle.com> <9064bba7-63bb-4a3f-1877-93adb4a57d3d@oracle.com> Message-ID: Thank you Tobias. Pushed the changes. On 11/06/19 2:27 PM, Tobias Hartmann wrote: > Hi Rahul, > > looks good and trivial to me. > > Best regards, > Tobias > > On 11.06.19 10:53, Rahul Raghavan wrote: >> Hi, >> >> Please review the following changes. >> >> During 8202414 fix, by mistake committed files with wrong header. >> So proposing following changes as fix >> >> - http://cr.openjdk.java.net/~rraghavan/8225567/webrev.00/ >> >> >> [src/hotspot/share/opto/memnode.cpp] >> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights reserved. >> >> >> [test/hotspot/jtreg/compiler/c2/Test8202414.java] >> - * Copyright (c) 2019, Huawei Technologies Co. Ltd. All rights reserved. >> + * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. >> >> >> Thanks, >> Rahul From adinn at redhat.com Tue Jun 11 09:21:43 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 11 Jun 2019 10:21:43 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <08aef662-69e2-eb70-ef83-043837dbdd69@redhat.com> Message-ID: <7a742f60-4b47-407b-4667-d007cc130a7f@redhat.com> On 11/06/2019 00:30, Brian Burkhalter wrote: > I wanted to let you know that I ran version 7 above through our tests > and did not see any problems related to your changes. Excellent. Thanks very much for running that check. > I think the copyright years in PmemTest.java are wrong however: 2002, > 2011. I suppose it should be just 2019. Well spotted! Let's hope that is the final escapee. I have tweaked my latest patch accordingly. I have also updated the patch to specify @since 14 instead of @since 13 in the two places where new elements are added. I'll post a final webrev once I am sure there are no other changes needed. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Jun 11 09:23:32 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 11 Jun 2019 10:23:32 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <072ce1bb-ad2c-a2cd-42fc-b4076dac99c7@oracle.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <072ce1bb-ad2c-a2cd-42fc-b4076dac99c7@oracle.com> Message-ID: On 10/06/2019 18:44, Alan Bateman wrote: > On 10/06/2019 11:09, Andrew Dinn wrote: >> : >> Finally, I am unclear whether the presence of the new module + package >> means this is an SE JEP or a JDK JEP? In the latest update I have >> assumed the JEP type is still JDK and changed the title for the public >> API changes to "Proposed Java API Changes". Is that right? Or do you >> want the JEP type to be SE and have the title remain "Proposed Java SE >> API Changes" >> > The module is JDK-specific so keeping the scope "JDK" is right. Ok, in that case I'll ask Brian if he can endorse the JEP and then target for JDK14. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Jun 11 09:50:20 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 11 Jun 2019 10:50:20 +0100 Subject: RFR: JDK-8224963: Char-Byte Performance Enhancement In-Reply-To: References: <68b970be-e551-577d-0ca1-28c16880a2ff@oracle.com> Message-ID: Hi Adam, On 11/06/2019 10:04, Adam Farley8 wrote: > Merely patching the class library code will not effect any performance > enhancement. > > Quite the opposite. :) > > The changes in the class library were designed to work in tandem with > some changes to the OpenJ9 JIT compiler, which is what accelerates > performance. > > Naturally, investigating and sharing OpenJ9 logic is a bad idea due to > contamination, so we're stuck with investigating the CL changes to > identify any potential value to OpenJDK with Hotspot. This seems a slightly odd way to go about arriving at an improvement in the generated code. What you probably ought to do in order to make progress here -- and /without/ exposing any secrets about the J9 implementation -- is to take an assembly dump of the x86 code that is currently being generated and then identify some transformation to that x86 code which 1) brings it nearer to what J9 produces and/or 2) clearly improves performance (you appear to be assuming 1 and 2 go together here but that is not actually required). n.b. you could identify such a generated code transformation starting either from the existing Java source or from your modified Java source. If you /can/ specify what the improved machine code needs to look like relative to the current code then it would be possible and, perhaps, relatively easy for someone who does understand the C2 compiler to determine whether there is a way to adopt this alternative code-generation strategy simply by tweaking the C2 compiler. Of course, the alternative might be that effecting such a change in generated code would require major changes to C2 -- it might even be (as the Arkansas farmer says) that you can't get there from here. Whatever, proceeding as suggested above won't expose what J9 is doing and won't require you to know what C2 is doing. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From tobias.hartmann at oracle.com Tue Jun 11 09:57:13 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 11 Jun 2019 11:57:13 +0200 Subject: [13] RFR(S): 8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL In-Reply-To: <8d250d22-e990-8ce9-48df-647393d2f1e1@oracle.com> References: <2b0a8781-4688-558d-353e-8ef3483fc833@oracle.com> <445d5158-21f3-0fc1-43ac-273ad81d0533@oracle.com> <837ac2a7-d8eb-34ff-06f0-586ed75bd639@oracle.com> <22fd359e-56c6-90c4-d380-3d2c34adb1e5@oracle.com> <8d250d22-e990-8ce9-48df-647393d2f1e1@oracle.com> Message-ID: <2533e6fe-a20c-09f4-37f0-5621972695bd@oracle.com> Hi Vladimir, Thanks again for looking at this! Unfortunately, I found another problem when running with OptoScheduling enabled (which is the default on SPARC). The scheduler assumes that HaltNodes are either in a separate block or preceded by an (uncommon trap) call. This is no longer true with my changes (see [1]). I've modified the code to simply skip projections if there are any before the HaltNode: http://cr.openjdk.java.net/~thartmann/8224658/webrev.02/ I've also reverted this old fix which is no longer needed because of the _bb_start < _bb_end check: http://hg.openjdk.java.net/jdk/jdk/rev/c974c3e10bf7 On 07.06.19 16:27, Vladimir Ivanov wrote: > There are existing usages of Halt for optimizing unsafe accesses (e.g., GraphKit::must_be_not_null), > but, as a future enhancement, it would be nice to provide more information about the root cause of > the crash. As an example, JDK-8219902 [1] which involved Halt execution manifested as: > > ? # SIGILL (0x4) at pc=0x00007f55b4df37d6, pid=15865, tid=15869 > ? # > ? # JRE version: OpenJDK Runtime Environment (13.0+9) (build 13-ea+9) > ? # Java VM: OpenJDK 64-Bit Server VM (13-ea+9, mixed mode, sharing, tiered, compressed oops, g1 gc, > linux-amd64) > ? # Problematic frame: > ? # J 10152 c2 > com.sun.tools.javac.tree.Pretty.visitLiteral(Lcom/sun/tools/javac/tree/JCTree$JCLiteral;)V > jdk.compiler at 13-ea (282 bytes) @ 0x00007f55b4df37d6 [0x00007f55b4df07a0+0x0000000000003036] > > Without laborous analysis of generated code, it's impossible to say whether it's a JVM bug or a > problem in user code. I believe JVM can do better in such situations and print meaningful error > message instead when crashing. Yes, I agree that additional output would be very valuable. I'll file a RFE once this is in. Thanks, Tobias [1] # Schedule BB#003 (initial) 25 Region === 25 19 [[ 25 18 ]] !jvms: Unsafe::putInt @ bci:-1 UnsafeZero::test @ bci:14 18 MemBarCPUOrder === 25 0 10 0 0 [[ 17 ]] !jvms: Unsafe::putInt @ bci:4 Unsafe::putInt @ bci:5 UnsafeZero::test @ bci:14 17 MachProj === 18 [[ 16 ]] #0/unmatched !jvms: Unsafe::putInt @ bci:4 Unsafe::putInt @ bci:5 UnsafeZero::test @ bci:14 16 ShouldNotReachHere === 17 0 0 12 0 [[ 1 ]] !jvms: Unsafe::putInt @ bci:-1 UnsafeZero::test @ bci:14 From tobias.hartmann at oracle.com Tue Jun 11 10:01:17 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 11 Jun 2019 12:01:17 +0200 Subject: RFR(T): 8225564: Remove wrong assert in clean_catch_blocks In-Reply-To: <7d0e33db-2890-a8ff-235f-3768d89cfa8e@oracle.com> References: <7d0e33db-2890-a8ff-235f-3768d89cfa8e@oracle.com> Message-ID: <5ee2bdd9-3e76-370a-a4ed-5f7602d47a34@oracle.com> Hi Nils, looks reasonable and trivial to me. Best regards, Tobias On 11.06.19 10:27, Nils Eliasson wrote: > Hi, > > This patch removes an assert that is wrong. > > When traversing the graph for fixing the catch blocks, postorder is not guaranteed. The fix_up_uses > can find a load that must be handled first. The cleanup already supports (and expects that). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225564 > > Webrev: http://cr.openjdk.java.net/~neliasso/8225564/ > > Regards, > > Nils > From tobias.hartmann at oracle.com Tue Jun 11 10:11:30 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 11 Jun 2019 12:11:30 +0200 Subject: Questions around codeheaps, codeblobs and code locality In-Reply-To: References: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> <726994dd-fd15-cadb-7a1c-9daac1780050@oracle.com> Message-ID: <7c71c4b8-26b0-aaed-0419-7fc8b29139ee@oracle.com> On 07.06.19 18:20, keita abdoul-kader wrote: > Those are nice improvements indeed. Do you expect the remaining work item to (cumulatively) > bring comparable gain ? Or have we reach the point of diminishing returns? It's hard to say but I'm afraid that the cost/complexity of the implementation overweights the potential performance benefits. > Would you mind expanding on how you obtained the heat map on slide 13 and 19 of your > presentation ? I would like to reproduce those on our internal workloads. I've simply added some code that prints the hotness value for every nmethod in the code cache at VM exit and then plotted these values as heatmap with Plotly [1]. Unfortunately, I don't have the code anymore. Best regards, Tobias [1] https://plot.ly/python/ From tobias.hartmann at oracle.com Tue Jun 11 10:23:09 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 11 Jun 2019 12:23:09 +0200 Subject: [11u] RFR (Backport): 8177899: Tests fail due to code cache exhaustion on machines with many cores In-Reply-To: References: Message-ID: <97caa47e-ca35-45f2-0af4-b417cbbd167d@oracle.com> Hi Martin, this looks good to me. Best regards, Tobias On 06.06.19 11:35, Doerr, Martin wrote: > Hi, > > ? > > we noticed that jdk11u is also affected by > > https://bugs.openjdk.java.net/browse/JDK-8177899 > > ? > > The VM didn?t come up on a SPARC machine due to too high upper limit of compiler threads leading to > misconfigured code cache. > > ? > > Unfortunately, the original change does not apply cleanly and needs manual resolution. > > ? > > Original change: > > http://hg.openjdk.java.net/jdk/jdk/rev/0451e0a2f1f5 > > ? > > My backport: > > http://cr.openjdk.java.net/~mdoerr/8177899_code_cache/jdk11u/webrev.00/ > > ? > > Here?s the complete list of what I had to integrate manually: > > ? > > compile.cpp: Does not apply cleanly because of conflict with > > JDK-8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset > > Trivial to resolve: Original JDK-8177899 removes this part of JDK-8209594. > > We just need to take the new line: int size = C2Compiler::initial_code_buffer_size(const_size); > > ? > > compilationPolicy.cpp: Does not apply cleanly because neighboring hunk has changed: > > JDK-8214206: Fix for JDK-8213419 is broken on 32-bit > > Just need to insert code manually next to where log2_int was changed to log2_intptr. > > ? > > tieredThresholdPolicy.cpp: Does not apply cleanly because the file was renamed: > > JDK-8209186: Rename SimpleThresholdPolicy to TieredThresholdPolicy > > Change needs to get applied to simpleThresholdPolicy.cpp instead. Not difficult. > > ? > > Please review. I?m targeting to 11.0.5. > > ? > > Best regards, > > Martin > > ? > From martin.doerr at sap.com Tue Jun 11 10:27:12 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 Jun 2019 10:27:12 +0000 Subject: [11u] RFR (Backport): 8177899: Tests fail due to code cache exhaustion on machines with many cores In-Reply-To: <97caa47e-ca35-45f2-0af4-b417cbbd167d@oracle.com> References: <97caa47e-ca35-45f2-0af4-b417cbbd167d@oracle.com> Message-ID: Hi Tobias, thank you for the review. Best regards, Martin > -----Original Message----- > From: Tobias Hartmann > Sent: Dienstag, 11. Juni 2019 12:23 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net; Lindenmaier, Goetz > ; Schmidt, Lutz ; > Volker Simonis (volker.simonis at gmail.com) > Subject: Re: [11u] RFR (Backport): 8177899: Tests fail due to code cache > exhaustion on machines with many cores > > Hi Martin, > > this looks good to me. > > Best regards, > Tobias > > On 06.06.19 11:35, Doerr, Martin wrote: > > Hi, > > > > > > > > we noticed that jdk11u is also affected by > > > > https://bugs.openjdk.java.net/browse/JDK-8177899 > > > > > > > > The VM didn't come up on a SPARC machine due to too high upper limit of > compiler threads leading to > > misconfigured code cache. > > > > > > > > Unfortunately, the original change does not apply cleanly and needs > manual resolution. > > > > > > > > Original change: > > > > http://hg.openjdk.java.net/jdk/jdk/rev/0451e0a2f1f5 > > > > > > > > My backport: > > > > > http://cr.openjdk.java.net/~mdoerr/8177899_code_cache/jdk11u/webrev.0 > 0/ > > > > > > > > Here's the complete list of what I had to integrate manually: > > > > > > > > compile.cpp: Does not apply cleanly because of conflict with > > > > JDK-8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump > exceeds 8-bit offset > > > > Trivial to resolve: Original JDK-8177899 removes this part of JDK-8209594. > > > > We just need to take the new line: int size = > C2Compiler::initial_code_buffer_size(const_size); > > > > > > > > compilationPolicy.cpp: Does not apply cleanly because neighboring hunk > has changed: > > > > JDK-8214206: Fix for JDK-8213419 is broken on 32-bit > > > > Just need to insert code manually next to where log2_int was changed to > log2_intptr. > > > > > > > > tieredThresholdPolicy.cpp: Does not apply cleanly because the file was > renamed: > > > > JDK-8209186: Rename SimpleThresholdPolicy to TieredThresholdPolicy > > > > Change needs to get applied to simpleThresholdPolicy.cpp instead. Not > difficult. > > > > > > > > Please review. I'm targeting to 11.0.5. > > > > > > > > Best regards, > > > > Martin > > > > > > From nils.eliasson at oracle.com Tue Jun 11 10:38:35 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 11 Jun 2019 12:38:35 +0200 Subject: RFR(T): 8225564: Remove wrong assert in clean_catch_blocks In-Reply-To: <5ee2bdd9-3e76-370a-a4ed-5f7602d47a34@oracle.com> References: <7d0e33db-2890-a8ff-235f-3768d89cfa8e@oracle.com> <5ee2bdd9-3e76-370a-a4ed-5f7602d47a34@oracle.com> Message-ID: <535f1fab-c9d4-f1ff-b957-d7a5262d94a6@oracle.com> Thank you Tobias! / Nils On 2019-06-11 12:01, Tobias Hartmann wrote: > Hi Nils, > > looks reasonable and trivial to me. > > Best regards, > Tobias > > On 11.06.19 10:27, Nils Eliasson wrote: >> Hi, >> >> This patch removes an assert that is wrong. >> >> When traversing the graph for fixing the catch blocks, postorder is not guaranteed. The fix_up_uses >> can find a load that must be handled first. The cleanup already supports (and expects that). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225564 >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8225564/ >> >> Regards, >> >> Nils >> From vladimir.kozlov at oracle.com Tue Jun 11 14:08:43 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Jun 2019 07:08:43 -0700 Subject: RFR(T): 8225564: Remove wrong assert in clean_catch_blocks In-Reply-To: <5ee2bdd9-3e76-370a-a4ed-5f7602d47a34@oracle.com> References: <7d0e33db-2890-a8ff-235f-3768d89cfa8e@oracle.com> <5ee2bdd9-3e76-370a-a4ed-5f7602d47a34@oracle.com> Message-ID: <35EBA48C-8213-4B0A-9D8C-9A14C2BD41E8@oracle.com> +1 Thanks Vladimir > On Jun 11, 2019, at 3:01 AM, Tobias Hartmann wrote: > > Hi Nils, > > looks reasonable and trivial to me. > > Best regards, > Tobias > >> On 11.06.19 10:27, Nils Eliasson wrote: >> Hi, >> >> This patch removes an assert that is wrong. >> >> When traversing the graph for fixing the catch blocks, postorder is not guaranteed. The fix_up_uses >> can find a load that must be handled first. The cleanup already supports (and expects that). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225564 >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8225564/ >> >> Regards, >> >> Nils >> From sandhya.viswanathan at intel.com Tue Jun 11 16:11:16 2019 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Tue, 11 Jun 2019 16:11:16 +0000 Subject: an issue after: 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B05518@FMSMSX126.amr.corp.intel.com> Hi Vladimir, We will take a look. Thanks for reporting the issue. Best Regards, Sandhya -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Monday, June 10, 2019 2:44 PM To: Deshpande, Vivek R ; Viswanathan, Sandhya Cc: hotspot-compiler-dev at openjdk.java.net Subject: an issue after: 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc Hi Sandhya and Vivek, I got new failure after pulling these changes. The failure is intermittent, I saw it once in my testing. The failed test compiler/codegen/TestShortFloatVect.java ran without any other flags with only ones specified in test's @run. I got: ----------System.out:(3/50)---------- Testing Short + Float vectors Warmup Verification ----------System.err:(17/546)---------- test_ci: b1[968] = 0.0 != -103.0 test_ci: b1[969] = 0.0 != -103.0 test_ci: b1[970] = 0.0 != -103.0 test_ci: b1[971] = 0.0 != -103.0 test_ci: b1[976] = 0.0 != -103.0 test_ci: b1[977] = 0.0 != -103.0 test_ci: b1[978] = 0.0 != -103.0 test_ci: b1[979] = 0.0 != -103.0 test_ci: b1[984] = 0.0 != -103.0 test_ci: b1[985] = 0.0 != -103.0 test_ci: b1[986] = 0.0 != -103.0 test_ci: b1[987] = 0.0 != -103.0 test_ci: b1[992] = 0.0 != -103.0 test_ci: b1[993] = 0.0 != -103.0 test_ci: b1[994] = 0.0 != -103.0 test_ci: b1[995] = 0.0 != -103.0 FAILED: 16 errors test_ci() method simple assign constant value to short[] and float[] arrays in the same loop: static void test_ci(short[] a, float[] b) { for (int i = 0; i < a.length; i+=1) { a[i] = -123; b[i] = -103.f; } } The HW is MacPro with Xeon E5-1620_v2 3.70GHz FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C SMEP ERMS RDWRFSGS SYSCALL XD 1GBPAGE EM64T LAHF RDTSCP TSCI Please, look. Thanks, Vladimir On 6/7/19 3:48 PM, Deshpande, Vivek R wrote: > Thank you All. > Pushed the changes. > > Regards, > Vivek > > -----Original Message----- > From: Viswanathan, Sandhya > Sent: Friday, June 7, 2019 11:45 AM > To: Vladimir Ivanov ; Tobias Hartmann > Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R > Subject: RE: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc > > Hi Vladimir/Tobias, > > Thanks a lot for the review. > > Best Regards, > Sandhya > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Friday, June 07, 2019 3:41 AM > To: Viswanathan, Sandhya ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc > > Looks good. > > Best regards, > Vladimir Ivanov > > On 07/06/2019 03:41, Viswanathan, Sandhya wrote: >> Please find below a small patch which fixes the issue: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 >> >> Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ >> >> Multiplication is implemented as shift, add sequence in certain cases. >> >> The problem was occurring because the "shift by" register was being >> overwritten due to missing effect statement in the shift rules. >> >> The problem was introduced as part of >> https://bugs.openjdk.java.net/browse/JDK-8222074. >> >> The patch adds the missing effect statements. >> >> Best Regards, >> >> Sandhya >> From vladimir.kozlov at oracle.com Tue Jun 11 16:15:40 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Jun 2019 09:15:40 -0700 Subject: an issue after: 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B05518@FMSMSX126.amr.corp.intel.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B05518@FMSMSX126.amr.corp.intel.com> Message-ID: <28768ede-0444-4435-fb07-923427761615@oracle.com> Thanks you, Sandhya I had run the test on the same machine for 100 iterations but without reproducing the failure. It seems very rare case. Vladimir On 6/11/19 9:11 AM, Viswanathan, Sandhya wrote: > Hi Vladimir, > > We will take a look. > > Thanks for reporting the issue. > > Best Regards, > Sandhya > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Monday, June 10, 2019 2:44 PM > To: Deshpande, Vivek R ; Viswanathan, Sandhya > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: an issue after: 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc > > Hi Sandhya and Vivek, > > I got new failure after pulling these changes. The failure is intermittent, I saw it once in my testing. > > The failed test compiler/codegen/TestShortFloatVect.java ran without any other flags with only ones specified in test's > @run. I got: > > ----------System.out:(3/50)---------- > Testing Short + Float vectors > Warmup > Verification > ----------System.err:(17/546)---------- > test_ci: b1[968] = 0.0 != -103.0 > test_ci: b1[969] = 0.0 != -103.0 > test_ci: b1[970] = 0.0 != -103.0 > test_ci: b1[971] = 0.0 != -103.0 > test_ci: b1[976] = 0.0 != -103.0 > test_ci: b1[977] = 0.0 != -103.0 > test_ci: b1[978] = 0.0 != -103.0 > test_ci: b1[979] = 0.0 != -103.0 > test_ci: b1[984] = 0.0 != -103.0 > test_ci: b1[985] = 0.0 != -103.0 > test_ci: b1[986] = 0.0 != -103.0 > test_ci: b1[987] = 0.0 != -103.0 > test_ci: b1[992] = 0.0 != -103.0 > test_ci: b1[993] = 0.0 != -103.0 > test_ci: b1[994] = 0.0 != -103.0 > test_ci: b1[995] = 0.0 != -103.0 > FAILED: 16 errors > > test_ci() method simple assign constant value to short[] and float[] arrays in the same loop: > > static void test_ci(short[] a, float[] b) { > for (int i = 0; i < a.length; i+=1) { > a[i] = -123; > b[i] = -103.f; > } > } > > The HW is MacPro with Xeon E5-1620_v2 3.70GHz > > FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE > SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE > TSCTMR AVX1.0 RDRAND F16C SMEP ERMS RDWRFSGS SYSCALL XD 1GBPAGE EM64T LAHF RDTSCP TSCI > > Please, look. > > Thanks, > Vladimir > > On 6/7/19 3:48 PM, Deshpande, Vivek R wrote: >> Thank you All. >> Pushed the changes. >> >> Regards, >> Vivek >> >> -----Original Message----- >> From: Viswanathan, Sandhya >> Sent: Friday, June 7, 2019 11:45 AM >> To: Vladimir Ivanov ; Tobias Hartmann >> Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R >> Subject: RE: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc >> >> Hi Vladimir/Tobias, >> >> Thanks a lot for the review. >> >> Best Regards, >> Sandhya >> >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Friday, June 07, 2019 3:41 AM >> To: Viswanathan, Sandhya ; hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc >> >> Looks good. >> >> Best regards, >> Vladimir Ivanov >> >> On 07/06/2019 03:41, Viswanathan, Sandhya wrote: >>> Please find below a small patch which fixes the issue: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 >>> >>> Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ >>> >>> Multiplication is implemented as shift, add sequence in certain cases. >>> >>> The problem was occurring because the "shift by" register was being >>> overwritten due to missing effect statement in the shift rules. >>> >>> The problem was introduced as part of >>> https://bugs.openjdk.java.net/browse/JDK-8222074. >>> >>> The patch adds the missing effect statements. >>> >>> Best Regards, >>> >>> Sandhya >>> From martin.doerr at sap.com Tue Jun 11 16:27:13 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 Jun 2019 16:27:13 +0000 Subject: an issue after: 8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: <28768ede-0444-4435-fb07-923427761615@oracle.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B05518@FMSMSX126.amr.corp.intel.com> <28768ede-0444-4435-fb07-923427761615@oracle.com> Message-ID: Hi everybody, I think the appropriate effect is "TEMP_DEF dst" when you modify the dst register before you read one of the input registers. "DEF dst" or "USE src" don't need to get specified explicitly if these registers occur in the match rule as destination or source. Best regards, Martin > -----Original Message----- > From: hotspot-compiler-dev bounces at openjdk.java.net> On Behalf Of Vladimir Kozlov > Sent: Dienstag, 11. Juni 2019 18:16 > To: Viswanathan, Sandhya ; Deshpande, > Vivek R > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: an issue after: 8224234: compiler/codegen/TestCharVect2.java > fails in test_mulc > > Thanks you, Sandhya > > I had run the test on the same machine for 100 iterations but without > reproducing the failure. It > seems very rare case. > > Vladimir > > On 6/11/19 9:11 AM, Viswanathan, Sandhya wrote: > > Hi Vladimir, > > > > We will take a look. > > > > Thanks for reporting the issue. > > > > Best Regards, > > Sandhya > > > > > > -----Original Message----- > > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > > Sent: Monday, June 10, 2019 2:44 PM > > To: Deshpande, Vivek R ; Viswanathan, > Sandhya > > Cc: hotspot-compiler-dev at openjdk.java.net > > Subject: an issue after: 8224234: compiler/codegen/TestCharVect2.java > fails in test_mulc > > > > Hi Sandhya and Vivek, > > > > I got new failure after pulling these changes. The failure is intermittent, I > saw it once in my testing. > > > > The failed test compiler/codegen/TestShortFloatVect.java ran without any > other flags with only ones specified in test's > > @run. I got: > > > > ----------System.out:(3/50)---------- > > Testing Short + Float vectors > > Warmup > > Verification > > ----------System.err:(17/546)---------- > > test_ci: b1[968] = 0.0 != -103.0 > > test_ci: b1[969] = 0.0 != -103.0 > > test_ci: b1[970] = 0.0 != -103.0 > > test_ci: b1[971] = 0.0 != -103.0 > > test_ci: b1[976] = 0.0 != -103.0 > > test_ci: b1[977] = 0.0 != -103.0 > > test_ci: b1[978] = 0.0 != -103.0 > > test_ci: b1[979] = 0.0 != -103.0 > > test_ci: b1[984] = 0.0 != -103.0 > > test_ci: b1[985] = 0.0 != -103.0 > > test_ci: b1[986] = 0.0 != -103.0 > > test_ci: b1[987] = 0.0 != -103.0 > > test_ci: b1[992] = 0.0 != -103.0 > > test_ci: b1[993] = 0.0 != -103.0 > > test_ci: b1[994] = 0.0 != -103.0 > > test_ci: b1[995] = 0.0 != -103.0 > > FAILED: 16 errors > > > > test_ci() method simple assign constant value to short[] and float[] arrays > in the same loop: > > > > static void test_ci(short[] a, float[] b) { > > for (int i = 0; i < a.length; i+=1) { > > a[i] = -123; > > b[i] = -103.f; > > } > > } > > > > The HW is MacPro with Xeon E5-1620_v2 3.70GHz > > > > FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV > PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE > > SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR > PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE > > TSCTMR AVX1.0 RDRAND F16C SMEP ERMS RDWRFSGS SYSCALL XD > 1GBPAGE EM64T LAHF RDTSCP TSCI > > > > Please, look. > > > > Thanks, > > Vladimir > > > > On 6/7/19 3:48 PM, Deshpande, Vivek R wrote: > >> Thank you All. > >> Pushed the changes. > >> > >> Regards, > >> Vivek > >> > >> -----Original Message----- > >> From: Viswanathan, Sandhya > >> Sent: Friday, June 7, 2019 11:45 AM > >> To: Vladimir Ivanov ; Tobias Hartmann > > >> Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R > > >> Subject: RE: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails > in test_mulc > >> > >> Hi Vladimir/Tobias, > >> > >> Thanks a lot for the review. > >> > >> Best Regards, > >> Sandhya > >> > >> -----Original Message----- > >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > >> Sent: Friday, June 07, 2019 3:41 AM > >> To: Viswanathan, Sandhya ; hotspot- > compiler-dev at openjdk.java.net > >> Subject: Re: RFR (XS) 8224234: compiler/codegen/TestCharVect2.java fails > in test_mulc > >> > >> Looks good. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >> On 07/06/2019 03:41, Viswanathan, Sandhya wrote: > >>> Please find below a small patch which fixes the issue: > >>> > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 > >>> > >>> Patch: http://cr.openjdk.java.net/~sviswanathan/8224234/ > >>> > >>> Multiplication is implemented as shift, add sequence in certain cases. > >>> > >>> The problem was occurring because the "shift by" register was being > >>> overwritten due to missing effect statement in the shift rules. > >>> > >>> The problem was introduced as part of > >>> https://bugs.openjdk.java.net/browse/JDK-8222074. > >>> > >>> The patch adds the missing effect statements. > >>> > >>> Best Regards, > >>> > >>> Sandhya > >>> From igor.ignatyev at oracle.com Tue Jun 11 18:49:26 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 11 Jun 2019 11:49:26 -0700 Subject: RFR(S) : 8225554 : add JFR event for uncommon trap Message-ID: http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html > 187 lines changed: 184 ins; 0 del; 3 mod; Hi all, could you please review this small patch which adds jfr event for uncommon trap? webrev: http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8225554 testing: - tier1 (which includes a newly added test) - modified version of compiler/intrinsics/klass/CastNullCheckDroppingsTest.java (see JDK-8129092[1]) [1] https://bugs.openjdk.java.net/browse/JDK-8129092 Thanks, -- Igor From leelamohan.venati at gmail.com Tue Jun 11 19:53:09 2019 From: leelamohan.venati at gmail.com (Leela Mohan) Date: Tue, 11 Jun 2019 12:53:09 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com> References: <4C2D0A78.5020906@oracle.com> <4C2D0EC1.4090607@oracle.com> <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com> Message-ID: On Mon, Jun 10, 2019 at 10:45 AM Tom Rodriguez wrote: > > > Leela Mohan wrote on 6/7/19 6:39 PM: > > This is super late reply to this review mail but i have couple of > > questions about this change. > > Wow 9 years. :) > > > > > Looking at the diff here : > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/65b0c03b165d > > > > I think, Calling JvmtiExport::post_compiled_method_load(JvmtiEnv* > > env,..) to JvmtiExport::post_compiled_method_load(nmethod*) versio is > > possibly incorrect since, this would do callbacks to multiple jvmti > > environments (jvmti agents) which is unexpected. Callbacks are expected > > to be called to current jvmti env which called GenerateEvents. > > I think you're right. Anyone listening for those events will also get > notified which isn't quite right. Please file a bug. It should be easy > enough to fix. Factoring out the notification body of > post_compiled_method_load into it's own method and calling that from > generate_compiled_method_load_events would work great. > Thanks for confirming. I don't know the formalities of filing a bug. Can you please pass me the instructions. Thanks. And I was wondering what was the original lock rank ordering issue. It took some time for me to understand what the issue is. Before the change, CodeCache_lock was held when nmethod closure (i.e) nmethodCollector::do_nmethod(nmethod* nm) was called on each nmethod and closure was calling nmethod::get_and_cache_jmethod_id() which needed JNIGlobalHandle_lock (jmethods then were jweak handles). Lot seemed to have changed after this but intent of not holding CodeCache_lock around nmethod::get_and_cache_jmethod_id() is still valid. Thanks, Leela > tom > > > > > > > > > > > > > On Thu, Jul 1, 2010 at 4:07 PM Tom Rodriguez > > wrote: > > > > Thanks. Dan also reviewed this as I was developing it. > > > > tom > > > > On Jul 1, 2010, at 2:55 PM, Vladimir Kozlov wrote: > > > > > Thanks, Tom > > > > > > Changes are good to go. > > > > > > Vladimir > > > > > > On 7/1/10 2:41 PM, Tom Rodriguez wrote: > > >> > > >> On Jul 1, 2010, at 2:36 PM, Vladimir Kozlov wrote: > > >> > > >>> You did not explain your changes for cb->name(). > > >> > > >> That was just a clean up I've been wanting to do. There was a > > time then only some of the CodeBlob subclasses had name() methods > > but now it's part of CodeBlob so that logic is unnecessary. > > >> > > >>> Why we don't lock nmethod in sweeper during CodeCache walk but > > lock here? > > >> > > >> nmethodLocker protects you from the sweeper so the sweeper > > doesn't need protection. > > >> > > >> tom > > >> > > >>> > > >>> Thanks, > > >>> Vladimir > > >>> > > >>> On 7/1/10 1:58 PM, Tom Rodriguez wrote: > > >>>> http://cr.openjdk.java.net/~never/6965671/ > > > > >>>> > > >>>> 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 > > out of order with lock CodeCache_lock/1 > > >>>> Reviewed-by: > > >>>> > > >>>> The jmethodID fix created a deadlock because of lock ordering > when > > >>>> walking the CodeCache to generate CompiledMethodLoad events. > > The walk > > >>>> is performed with the CodeCache_lock held but we need to > > acquire the > > >>>> JNIGlobalHandle_lock to make a jmethodID. I considered > > switching back > > >>>> to collecting the methodOop instead of the jmethodID under the > > lock > > >>>> but inspection of the code made it clear that there's a > > preexisting > > >>>> problem with GC of the methodOops stored into the nmethodDesc. > > >>>> Instead I switched to a simpler implementation that holds the > > >>>> CodeCache_lock while walking the CodeCache but releases the > > lock to > > >>>> actually perform the notify. This simplifies the code greatly > > as well > > >>>> as fixing the bug. > > >>>> > > >>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and > > JDI_REGRESSION > > >>>> tests. > > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Jun 11 21:13:58 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 11 Jun 2019 14:13:58 -0700 Subject: RFR(T) [13] : 8066173 : compiler/types/correctness/OffTest.java failed with assert Message-ID: <135958F1-4067-4298-8A7D-26823106F862@oracle.com> http://cr.openjdk.java.net/~iignatyev//8066173/webrev.00/index.html > 3 lines changed: 1 ins; 0 del; 2 mod; Hi all, could you please review this trivial fix removes compiler/types/correctness from problem list on all platform and problem list them only on solaris-sparcv9 due to 8225620[1]? from JBS: > Patric Hedlin added a comment: > The implementation in *load_extra_data()* has changed over the last few months (for JDK12/13) and may/should not manifest the problem any more. However, there might still be a potential problem (window) in *prepare_metadata()*, in the current JDK13 code base, where _PrepareExtraDataClosure_ will use the (now) fragile/raced (_SafepointSynchronize_) *safepoint_counter()*. The scenario would be that a safepoint has indeed started during *prepare_metadata()* but finishes after, without being detected. > > The test-case also uses the WhiteBox API to clean method data, via (_WhiteBox_) *clearMethodState()*. This would explain the (mal-) interaction with the previous implementation of *load_extra_data()*. > > 1. I would suggest that the issue is closed until manifested anew. > > 2. The Safepoint code/state should perhaps be scrutinized further to close the potential problem window. (Robbin will file a new report.) webrev: http://cr.openjdk.java.net/~iignatyev//8066173/webrev.00/index.html testing: compiler/types/correctness on {linux-x64,windows-x64,mac-x64} x {product,fastdebug} JBS: https://bugs.openjdk.java.net/browse/JDK-8066173 [1] https://bugs.openjdk.java.net/browse/JDK-8225620 Thanks, -- Igor From vladimir.kozlov at oracle.com Tue Jun 11 21:29:19 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Jun 2019 14:29:19 -0700 Subject: RFR(T) [13] : 8066173 : compiler/types/correctness/OffTest.java failed with assert In-Reply-To: <135958F1-4067-4298-8A7D-26823106F862@oracle.com> References: <135958F1-4067-4298-8A7D-26823106F862@oracle.com> Message-ID: <2FEA77A0-984D-435C-982E-DC7C2C707191@oracle.com> Good. Thanks Vladimir > On Jun 11, 2019, at 2:13 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8066173/webrev.00/index.html >> 3 lines changed: 1 ins; 0 del; 2 mod; > > Hi all, > > could you please review this trivial fix removes compiler/types/correctness from problem list on all platform and problem list them only on solaris-sparcv9 due to 8225620[1]? > > from JBS: >> Patric Hedlin added a comment: > >> The implementation in *load_extra_data()* has changed over the last few months (for JDK12/13) and may/should not manifest the problem any more. However, there might still be a potential problem (window) in *prepare_metadata()*, in the current JDK13 code base, where _PrepareExtraDataClosure_ will use the (now) fragile/raced (_SafepointSynchronize_) *safepoint_counter()*. The scenario would be that a safepoint has indeed started during *prepare_metadata()* but finishes after, without being detected. >> >> The test-case also uses the WhiteBox API to clean method data, via (_WhiteBox_) *clearMethodState()*. This would explain the (mal-) interaction with the previous implementation of *load_extra_data()*. >> >> 1. I would suggest that the issue is closed until manifested anew. >> >> 2. The Safepoint code/state should perhaps be scrutinized further to close the potential problem window. (Robbin will file a new report.) > > > webrev: http://cr.openjdk.java.net/~iignatyev//8066173/webrev.00/index.html > testing: compiler/types/correctness on {linux-x64,windows-x64,mac-x64} x {product,fastdebug} > JBS: https://bugs.openjdk.java.net/browse/JDK-8066173 > > [1] https://bugs.openjdk.java.net/browse/JDK-8225620 > > Thanks, > -- Igor From igor.ignatyev at oracle.com Tue Jun 11 22:01:14 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 11 Jun 2019 15:01:14 -0700 Subject: RFR(T) [13] : 8066173 : compiler/types/correctness/OffTest.java failed with assert In-Reply-To: <2FEA77A0-984D-435C-982E-DC7C2C707191@oracle.com> References: <135958F1-4067-4298-8A7D-26823106F862@oracle.com> <2FEA77A0-984D-435C-982E-DC7C2C707191@oracle.com> Message-ID: <76DF84E9-2AC7-4882-BD3B-8B6ED1CCDE34@oracle.com> thanks Vladimir, pushed. -- Igor > On Jun 11, 2019, at 2:29 PM, Vladimir Kozlov wrote: > > Good. > > Thanks > Vladimir > >> On Jun 11, 2019, at 2:13 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8066173/webrev.00/index.html >>> 3 lines changed: 1 ins; 0 del; 2 mod; >> >> Hi all, >> >> could you please review this trivial fix removes compiler/types/correctness from problem list on all platform and problem list them only on solaris-sparcv9 due to 8225620[1]? >> >> from JBS: >>> Patric Hedlin added a comment: >> >>> The implementation in *load_extra_data()* has changed over the last few months (for JDK12/13) and may/should not manifest the problem any more. However, there might still be a potential problem (window) in *prepare_metadata()*, in the current JDK13 code base, where _PrepareExtraDataClosure_ will use the (now) fragile/raced (_SafepointSynchronize_) *safepoint_counter()*. The scenario would be that a safepoint has indeed started during *prepare_metadata()* but finishes after, without being detected. >>> >>> The test-case also uses the WhiteBox API to clean method data, via (_WhiteBox_) *clearMethodState()*. This would explain the (mal-) interaction with the previous implementation of *load_extra_data()*. >>> >>> 1. I would suggest that the issue is closed until manifested anew. >>> >>> 2. The Safepoint code/state should perhaps be scrutinized further to close the potential problem window. (Robbin will file a new report.) >> >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8066173/webrev.00/index.html >> testing: compiler/types/correctness on {linux-x64,windows-x64,mac-x64} x {product,fastdebug} >> JBS: https://bugs.openjdk.java.net/browse/JDK-8066173 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8225620 >> >> Thanks, >> -- Igor > From smita.kamath at intel.com Tue Jun 11 23:23:28 2019 From: smita.kamath at intel.com (Kamath, Smita) Date: Tue, 11 Jun 2019 23:23:28 +0000 Subject: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. Message-ID: <6563F381B547594081EF9DE181D0791296149EE6@fmsmsx123.amr.corp.intel.com> Hi Vladimir, As per Intel Architecture Instruction Set Reference [1] Vector AES Encrypt and Decrypt Operations will be supported in future Intel ISA. We would like to contribute optimizations for AES-ECB algorithm to support encryption and decryption operations using AVX512+VAES instructions. These optimizations are for x86_64 architecture that have AVX512-VAES enabled. Shravya(cc'ed) and I are co-contributors. Shay Gueron(shay.gueron at intel.com) and Regev Shemy (regev.shemy at intel.com) are the authors of the algorithm. I have tested the algorithm with Intel SDE [2] to confirm encoding and semantics are correctly implemented. Please take a look and let me know if you have any questions or comments. http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.00/ Bug Id: https://bugs.openjdk.java.net/browse/JDK-8225625 [1] https://software.intel.com/sites/default/files/managed/ad/01/253666-sdm-vol-2a.pdf (Page 152 - 159) [2] https://software.intel.com/en-us/articles/intel-software-development-emulator Regards, Smita Kamath -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Wed Jun 12 02:02:04 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 11 Jun 2019 23:02:04 -0300 Subject: RFR(M): 8224827: Implement fast class initialization checks on s390 In-Reply-To: References: Message-ID: <62bd9968-c59b-1ce3-17a6-8b7c4206962b@linux.vnet.ibm.com> Hi Martin, On 06/06/2019 09:29 AM, Doerr, Martin wrote: > please review the rebased and updated version (after JDK-8225106): > http://cr.openjdk.java.net/~mdoerr/8224827_s390_fast_clinit/webrev.01/ > > Note: Applies on top of JDK-8223249 which is still waiting for a 2nd review. Like the similar change for PPC64, looks good. Best regards, Gustavo From ekaterina.pavlova at oracle.com Wed Jun 12 06:33:28 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 11 Jun 2019 23:33:28 -0700 Subject: RFR (T/XS) 8225622: [AOT] runtime/SharedArchiveFile/TestInterpreterMethodEntries.java crashed with AOTed java.base Message-ID: Hi, please review small test patch which disables first test case from running in case AOT is used. This test cases crashes when running with AOT because the test case explicitly disables intrinsics ( -XX:-UseCRC32Intrinsics -XX:-UseCRC32CIntrinsics ) while they were enabled for AOT library. JBS: https://bugs.openjdk.java.net/browse/JDK-8225622 webrev: http://cr.openjdk.java.net/~epavlova//8225622/webrev.00/index.html testing: run the test with and without AOT on all platforms. thanks, -katya From bsrbnd at gmail.com Wed Jun 12 10:09:07 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 12 Jun 2019 12:09:07 +0200 Subject: RFR: 8225644: [TESTBUG] langtools/tools/javac/generics/inference/8058199/T8058199.java fails with -Xcomp In-Reply-To: <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> References: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com> <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> Message-ID: [ Forwarding to hotspot-compiler-dev ] The CCE messages are probably generated here: http://hg.openjdk.java.net/jdk/jdk/file/755e82641224/src/hotspot/share/runtime/sharedRuntime.hpp#l301 http://hg.openjdk.java.net/jdk/jdk/file/755e82641224/src/hotspot/share/runtime/sharedRuntime.hpp#l315 Note that the second one might be called from interpreted code and seems to generate the expected message. I hope this helps, Bernard On Wed, 12 Jun 2019 at 08:15, Jie Fu wrote: > > Hi Joe, > > Thanks for your review. > Do you mean the JIT shouldn't dump the signature like "[Ljava/lang/String;"? > > I'd like to do more investigation. > Thanks. > > Best regards, > Jie > > On 2019/6/12 ??2:01, Joe Darcy wrote: > > Hello, > > > > If the javac test is only failing under -Xcomp, a reasonable avenue to > > investigate is that -Xcomp is misbehaving rather than the test code. > > > > Cheers, > > > > -Joe > > > > On 6/11/2019 10:56 PM, Jie Fu wrote: > >> Hi all, > >> > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225644 > >> Webrev: http://cr.openjdk.java.net/~jiefu/8225644/webrev.00/ > >> > >> Reason: with -Xcomp, the signature was dumped as > >> "[Ljava/lang/String;" rather than "[Ljava.lang.String;". > >> Fix: It might be better to replace '/' with '.' before matching. > >> > >> Could you please review it? > >> > >> Thanks a lot. > >> Best regards, > >> Jie > >> > >> > From vladimir.x.ivanov at oracle.com Wed Jun 12 11:46:56 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 12 Jun 2019 14:46:56 +0300 Subject: [13] RFR(S): 8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL In-Reply-To: <2533e6fe-a20c-09f4-37f0-5621972695bd@oracle.com> References: <2b0a8781-4688-558d-353e-8ef3483fc833@oracle.com> <445d5158-21f3-0fc1-43ac-273ad81d0533@oracle.com> <837ac2a7-d8eb-34ff-06f0-586ed75bd639@oracle.com> <22fd359e-56c6-90c4-d380-3d2c34adb1e5@oracle.com> <8d250d22-e990-8ce9-48df-647393d2f1e1@oracle.com> <2533e6fe-a20c-09f4-37f0-5621972695bd@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/8224658/webrev.02/ Looks good. Best regards, Vladimir Ivanov > I've also reverted this old fix which is no longer needed because of the _bb_start < _bb_end check: > http://hg.openjdk.java.net/jdk/jdk/rev/c974c3e10bf7 > > On 07.06.19 16:27, Vladimir Ivanov wrote: >> There are existing usages of Halt for optimizing unsafe accesses (e.g., GraphKit::must_be_not_null), >> but, as a future enhancement, it would be nice to provide more information about the root cause of >> the crash. As an example, JDK-8219902 [1] which involved Halt execution manifested as: >> >> ? # SIGILL (0x4) at pc=0x00007f55b4df37d6, pid=15865, tid=15869 >> ? # >> ? # JRE version: OpenJDK Runtime Environment (13.0+9) (build 13-ea+9) >> ? # Java VM: OpenJDK 64-Bit Server VM (13-ea+9, mixed mode, sharing, tiered, compressed oops, g1 gc, >> linux-amd64) >> ? # Problematic frame: >> ? # J 10152 c2 >> com.sun.tools.javac.tree.Pretty.visitLiteral(Lcom/sun/tools/javac/tree/JCTree$JCLiteral;)V >> jdk.compiler at 13-ea (282 bytes) @ 0x00007f55b4df37d6 [0x00007f55b4df07a0+0x0000000000003036] >> >> Without laborous analysis of generated code, it's impossible to say whether it's a JVM bug or a >> problem in user code. I believe JVM can do better in such situations and print meaningful error >> message instead when crashing. > > Yes, I agree that additional output would be very valuable. I'll file a RFE once this is in. > > Thanks, > Tobias > > [1] > # Schedule BB#003 (initial) > 25 Region === 25 19 [[ 25 18 ]] !jvms: Unsafe::putInt @ bci:-1 UnsafeZero::test @ bci:14 > 18 MemBarCPUOrder === 25 0 10 0 0 [[ 17 ]] !jvms: Unsafe::putInt @ bci:4 Unsafe::putInt @ > bci:5 UnsafeZero::test @ bci:14 > 17 MachProj === 18 [[ 16 ]] #0/unmatched !jvms: Unsafe::putInt @ bci:4 Unsafe::putInt @ bci:5 > UnsafeZero::test @ bci:14 > 16 ShouldNotReachHere === 17 0 0 12 0 [[ 1 ]] !jvms: Unsafe::putInt @ bci:-1 > UnsafeZero::test @ bci:14 > From tobias.hartmann at oracle.com Wed Jun 12 11:51:45 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 12 Jun 2019 13:51:45 +0200 Subject: [13] RFR(S): 8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL In-Reply-To: References: <2b0a8781-4688-558d-353e-8ef3483fc833@oracle.com> <445d5158-21f3-0fc1-43ac-273ad81d0533@oracle.com> <837ac2a7-d8eb-34ff-06f0-586ed75bd639@oracle.com> <22fd359e-56c6-90c4-d380-3d2c34adb1e5@oracle.com> <8d250d22-e990-8ce9-48df-647393d2f1e1@oracle.com> <2533e6fe-a20c-09f4-37f0-5621972695bd@oracle.com> Message-ID: Thanks, Vladimir! Best regards, Tobias On 12.06.19 13:46, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~thartmann/8224658/webrev.02/ > > Looks good. > > Best regards, > Vladimir Ivanov > >> I've also reverted this old fix which is no longer needed because of the _bb_start < _bb_end check: >> http://hg.openjdk.java.net/jdk/jdk/rev/c974c3e10bf7 >> >> On 07.06.19 16:27, Vladimir Ivanov wrote: >>> There are existing usages of Halt for optimizing unsafe accesses (e.g., GraphKit::must_be_not_null), >>> but, as a future enhancement, it would be nice to provide more information about the root cause of >>> the crash. As an example, JDK-8219902 [1] which involved Halt execution manifested as: >>> >>> ?? # SIGILL (0x4) at pc=0x00007f55b4df37d6, pid=15865, tid=15869 >>> ?? # >>> ?? # JRE version: OpenJDK Runtime Environment (13.0+9) (build 13-ea+9) >>> ?? # Java VM: OpenJDK 64-Bit Server VM (13-ea+9, mixed mode, sharing, tiered, compressed oops, g1 >>> gc, >>> linux-amd64) >>> ?? # Problematic frame: >>> ?? # J 10152 c2 >>> com.sun.tools.javac.tree.Pretty.visitLiteral(Lcom/sun/tools/javac/tree/JCTree$JCLiteral;)V >>> jdk.compiler at 13-ea (282 bytes) @ 0x00007f55b4df37d6 [0x00007f55b4df07a0+0x0000000000003036] >>> >>> Without laborous analysis of generated code, it's impossible to say whether it's a JVM bug or a >>> problem in user code. I believe JVM can do better in such situations and print meaningful error >>> message instead when crashing. >> >> Yes, I agree that additional output would be very valuable. I'll file a RFE once this is in. >> >> Thanks, >> Tobias >> >> [1] >> #? Schedule BB#003 (initial) >> ? 25??? Region??? ===? 25? 19? [[ 25? 18 ]]? !jvms: Unsafe::putInt @ bci:-1 UnsafeZero::test @ bci:14 >> ? 18??? MemBarCPUOrder??? ===? 25? 0? 10? 0? 0? [[ 17 ]]? !jvms: Unsafe::putInt @ bci:4 >> Unsafe::putInt @ >> bci:5 UnsafeZero::test @ bci:14 >> ? 17??? MachProj??? ===? 18? [[ 16 ]] #0/unmatched !jvms: Unsafe::putInt @ bci:4 Unsafe::putInt @ >> bci:5 >> UnsafeZero::test @ bci:14 >> ? 16??? ShouldNotReachHere??? ===? 17? 0? 0? 12? 0? [[ 1 ]]? !jvms: Unsafe::putInt @ bci:-1 >> UnsafeZero::test @ bci:14 >> From rwestrel at redhat.com Wed Jun 12 12:01:08 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 12 Jun 2019 14:01:08 +0200 Subject: [13] RFR(S): 8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL In-Reply-To: <2533e6fe-a20c-09f4-37f0-5621972695bd@oracle.com> References: <2b0a8781-4688-558d-353e-8ef3483fc833@oracle.com> <445d5158-21f3-0fc1-43ac-273ad81d0533@oracle.com> <837ac2a7-d8eb-34ff-06f0-586ed75bd639@oracle.com> <22fd359e-56c6-90c4-d380-3d2c34adb1e5@oracle.com> <8d250d22-e990-8ce9-48df-647393d2f1e1@oracle.com> <2533e6fe-a20c-09f4-37f0-5621972695bd@oracle.com> Message-ID: <87a7endncr.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8224658/webrev.02/ Looks reasonable to me. Roland. From tobias.hartmann at oracle.com Wed Jun 12 12:02:45 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 12 Jun 2019 14:02:45 +0200 Subject: [13] RFR(S): 8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL In-Reply-To: <87a7endncr.fsf@redhat.com> References: <2b0a8781-4688-558d-353e-8ef3483fc833@oracle.com> <445d5158-21f3-0fc1-43ac-273ad81d0533@oracle.com> <837ac2a7-d8eb-34ff-06f0-586ed75bd639@oracle.com> <22fd359e-56c6-90c4-d380-3d2c34adb1e5@oracle.com> <8d250d22-e990-8ce9-48df-647393d2f1e1@oracle.com> <2533e6fe-a20c-09f4-37f0-5621972695bd@oracle.com> <87a7endncr.fsf@redhat.com> Message-ID: <33db6cec-15c7-36b7-41c5-d6ae7e7c4754@oracle.com> Thanks Roland! Best regards, Tobias On 12.06.19 14:01, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8224658/webrev.02/ > > Looks reasonable to me. > > Roland. > From martin.doerr at sap.com Wed Jun 12 12:28:53 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 Jun 2019 12:28:53 +0000 Subject: RFR(M): 8224827: Implement fast class initialization checks on s390 In-Reply-To: <62bd9968-c59b-1ce3-17a6-8b7c4206962b@linux.vnet.ibm.com> References: <62bd9968-c59b-1ce3-17a6-8b7c4206962b@linux.vnet.ibm.com> Message-ID: Hi Vladimir and Gustavo, thank you for reviewing. I'm glad to have PPC64 and s390 support in jdk13 like on x86. Best regards, Martin > -----Original Message----- > From: Gustavo Romero > Sent: Mittwoch, 12. Juni 2019 04:02 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' ; > hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8224827: Implement fast class initialization checks on > s390 > > Hi Martin, > > On 06/06/2019 09:29 AM, Doerr, Martin wrote: > > please review the rebased and updated version (after JDK-8225106): > > http://cr.openjdk.java.net/~mdoerr/8224827_s390_fast_clinit/webrev.01/ > > > > Note: Applies on top of JDK-8223249 which is still waiting for a 2nd review. > > Like the similar change for PPC64, looks good. > > Best regards, > Gustavo From martin.doerr at sap.com Wed Jun 12 14:53:18 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 Jun 2019 14:53:18 +0000 Subject: RFR(T): 8225663: [testbug] Missing JNIEXPORT in XAbortProvoker native function Message-ID: Hi, please review my trivial fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8225663 Webrev: http://cr.openjdk.java.net/~mdoerr/8225663_test_rtm/webrev.00/ Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Wed Jun 12 14:59:33 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 12 Jun 2019 11:59:33 -0300 Subject: RFR(T): 8225663: [testbug] Missing JNIEXPORT in XAbortProvoker native function In-Reply-To: References: Message-ID: Hi Martin, On 06/12/2019 11:53 AM, Doerr, Martin wrote: > please review my trivial fix. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8225663 > > Webrev: > http://cr.openjdk.java.net/~mdoerr/8225663_test_rtm/webrev.00/ Looks good and trivial! Apologies for breaking it on Windows. Best regards, Gustavo From vladimir.kozlov at oracle.com Wed Jun 12 15:11:44 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2019 08:11:44 -0700 Subject: RFR (T/XS) 8225622: [AOT] runtime/SharedArchiveFile/TestInterpreterMethodEntries.java crashed with AOTed java.base In-Reply-To: References: Message-ID: <14FB381F-53CE-4ECF-9A0D-8A6F3696D6AB@oracle.com> Looks good. Thanks Vladimir > On Jun 11, 2019, at 11:33 PM, Ekaterina Pavlova wrote: > > Hi, > > please review small test patch which disables first test case from running in case AOT is used. > This test cases crashes when running with AOT because the test case explicitly disables intrinsics > ( -XX:-UseCRC32Intrinsics -XX:-UseCRC32CIntrinsics ) while they were enabled for AOT library. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225622 > webrev: http://cr.openjdk.java.net/~epavlova//8225622/webrev.00/index.html > testing: run the test with and without AOT on all platforms. > > thanks, > -katya From rwestrel at redhat.com Wed Jun 12 15:14:14 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 12 Jun 2019 17:14:14 +0200 Subject: RFR(XL): 6312651: Compiler should only use verified interface types for optimization In-Reply-To: <87ftp9l5cy.fsf@redhat.com> References: <87ftp9l5cy.fsf@redhat.com> Message-ID: <874l4ueszd.fsf@redhat.com> Any taker for this? Roland. Roland Westrelin writes: > http://cr.openjdk.java.net/~roland/6312651/webrev.00/ > > This is a fix for a bug that John filed 14 years ago (almost) but has > always affected c2 as far as I understand. The fix is implemented along > the lines of John's recommendation: 1) the type system should keep track > of an object's instance class and the set of interfaces it implements > separately (or array of instance klass + set of interfaces), 2) > interfaces in signatures should not be trusted. > > For 1), the _klass in TypeOopPtr/TypeKlassPtr now only refers to > instance classes (or arrays of instance class). TypeOopPtr/TypeKlassPtr > has an extra field _interfaces that carries the set of interfaces > implemented by that type. > > For klass pointers, TypeKlassPtr is no longer sufficient because for > arrays, we need the type to also include interfaces that the element > implements. So I added 2 classes to the type system, TypeKlassInstPtr > and TypeAryKlassPtr that mirror TypeInstPtr/TypeAryPtr. TypeAryKlassPtr > has a TypeKlassPtr element which can then record what interfaces the > element type implements. The meet implementation for both also mirrors > TypeInstPtr/TypeAryPtr closely. > > In the existing implementation the TypeOopPtr/TypeKlassPtr klass() > accessor is used in a lot of places to perform class equality checks, > subtyping tests or to build a TypeOopPtr from a TypeKlassPtr or the > other way around. That can't work now because klass() only gives partial > information about the type. Rather than expose _klass and _interfaces > through accessors, I have: > > - made the klass() accessor non public so code that's not closely tied > to the actual type system implementation shouldn't use it > > - made some operations go through the type classes: testing for class > equality should be done through klass_eq() which tests both class and > interface set equality, same goes for subtyping tests. Creating a > TypeKlassPtr from a TypeOopPtr or the other way around is now always > done with the as_klass_type()/as_instance_type() methods. > > - introduced 3 new accessors: instance_klass() on > TypeInstPtr/TypeInstKlassPtr which only returns the instance class, > ignoring any interface implemented by the type; exact_klass() on > TypeOopPtr/TypeKlassPtr which only works for exact types and can > return an interface or array of interfaces; base_element_type() on > TypeAryPtr/TypeAryKlassPtr() which returns the base element of the > array and in case of an array of objects, only the instance class, not > whatever interface the element implements. These 3 are AFAICT good > enough to support existing c2 optimizations. > > For 2), TypeOopPtr::cast_to_non_interface() is used to filter out > interfaces whenever signatures are used. > > As expected, this change makes several workarounds no longer necessary > and cleans up the code quite a bit. For instance, > CheckCastPPNode::Value() now falls back to the "right" implementation of > ConstraintCastNode::Value() which leverages the type system. > > Fixing CheckCastPPNode::Value() exposes a bug in the C2 type checking > logic: if a type check is proved to always fail during optimizations, > the CheckCastPPNode becomes top, but the actual type checking logic in > Phase::gen_subtype_check() doesn't always optimize out so the data path > dies but not the control path. To fix that, I added a > PartialSubtypeCheckNode::Value() method that triggers on subtype check > failures consistently with CheckCastPPNode::Value. Problem is > PartialSubtypeCheckNode is not checked first in > Phase::gen_subtype_check(). So I added a duplicate test on the > PartialSubtypeCheckNode result first in that logic, under an Opaque4Node > so the actual is never compiled in the final code. > > Note that "8220416: Comparison of klass pointers is not optimized any > more" is fixed by this. > > CastNullCheckDroppingsTest.java needs a change because > testObjClassCast() has a call to objClass.cast() followed by a cast to > String, so 2 casts in a raw once compiled. With the existing > implementation, c2 can't see the casts as redundant and it keeps the > second one. That one triggers a deopt if the test is passed null. The > Class::cast implementation nevers traps for null. With the updated > implementation, c2 sees the second cast as useless and optimizes it out. > > I dropped the CmpNNode::sub() becasue CmpN nodes are only created during > final graph reshape so this is dead code. > > Performance is unaffected by this change AFAICT> > > Roland. From vladimir.kozlov at oracle.com Wed Jun 12 15:14:05 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2019 08:14:05 -0700 Subject: RFR(T): 8225663: [testbug] Missing JNIEXPORT in XAbortProvoker native function In-Reply-To: References: Message-ID: <2CD9E5CF-B51E-4F93-AAB9-885DC52054C8@oracle.com> Good. Thanks Vladimir > On Jun 12, 2019, at 7:53 AM, Doerr, Martin wrote: > > Hi, > > please review my trivial fix. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8225663 > > Webrev: > http://cr.openjdk.java.net/~mdoerr/8225663_test_rtm/webrev.00/ > > Best regards, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Jun 12 15:04:24 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 Jun 2019 15:04:24 +0000 Subject: RFR(T): 8225663: [testbug] Missing JNIEXPORT in XAbortProvoker native function In-Reply-To: References: Message-ID: Hi Martin, thanks for fixing the export , looks good to me . Best regards, Matthias From: Doerr, Martin Sent: Mittwoch, 12. Juni 2019 16:53 To: 'hotspot-compiler-dev at openjdk.java.net' ; Gustavo Romero ; Baesken, Matthias ; Zeller, Arno Subject: RFR(T): 8225663: [testbug] Missing JNIEXPORT in XAbortProvoker native function Hi, please review my trivial fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8225663 Webrev: http://cr.openjdk.java.net/~mdoerr/8225663_test_rtm/webrev.00/ Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed Jun 12 16:02:22 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 12 Jun 2019 19:02:22 +0300 Subject: RFR(XL): 6312651: Compiler should only use verified interface types for optimization In-Reply-To: <874l4ueszd.fsf@redhat.com> References: <87ftp9l5cy.fsf@redhat.com> <874l4ueszd.fsf@redhat.com> Message-ID: <6c9caa98-aed1-a5f4-fa52-7a90a8893cdf@oracle.com> Hi Roland, I'm very interested in the enhancements you propose and I plan to look into it, but I need more time to finish the review. I hope hope you are fine with deferring it for jdk14. Best regards, Vladimir Ivanov On 12/06/2019 18:14, Roland Westrelin wrote: > > Any taker for this? > > Roland. > > Roland Westrelin writes: > >> http://cr.openjdk.java.net/~roland/6312651/webrev.00/ >> >> This is a fix for a bug that John filed 14 years ago (almost) but has >> always affected c2 as far as I understand. The fix is implemented along >> the lines of John's recommendation: 1) the type system should keep track >> of an object's instance class and the set of interfaces it implements >> separately (or array of instance klass + set of interfaces), 2) >> interfaces in signatures should not be trusted. >> >> For 1), the _klass in TypeOopPtr/TypeKlassPtr now only refers to >> instance classes (or arrays of instance class). TypeOopPtr/TypeKlassPtr >> has an extra field _interfaces that carries the set of interfaces >> implemented by that type. >> >> For klass pointers, TypeKlassPtr is no longer sufficient because for >> arrays, we need the type to also include interfaces that the element >> implements. So I added 2 classes to the type system, TypeKlassInstPtr >> and TypeAryKlassPtr that mirror TypeInstPtr/TypeAryPtr. TypeAryKlassPtr >> has a TypeKlassPtr element which can then record what interfaces the >> element type implements. The meet implementation for both also mirrors >> TypeInstPtr/TypeAryPtr closely. >> >> In the existing implementation the TypeOopPtr/TypeKlassPtr klass() >> accessor is used in a lot of places to perform class equality checks, >> subtyping tests or to build a TypeOopPtr from a TypeKlassPtr or the >> other way around. That can't work now because klass() only gives partial >> information about the type. Rather than expose _klass and _interfaces >> through accessors, I have: >> >> - made the klass() accessor non public so code that's not closely tied >> to the actual type system implementation shouldn't use it >> >> - made some operations go through the type classes: testing for class >> equality should be done through klass_eq() which tests both class and >> interface set equality, same goes for subtyping tests. Creating a >> TypeKlassPtr from a TypeOopPtr or the other way around is now always >> done with the as_klass_type()/as_instance_type() methods. >> >> - introduced 3 new accessors: instance_klass() on >> TypeInstPtr/TypeInstKlassPtr which only returns the instance class, >> ignoring any interface implemented by the type; exact_klass() on >> TypeOopPtr/TypeKlassPtr which only works for exact types and can >> return an interface or array of interfaces; base_element_type() on >> TypeAryPtr/TypeAryKlassPtr() which returns the base element of the >> array and in case of an array of objects, only the instance class, not >> whatever interface the element implements. These 3 are AFAICT good >> enough to support existing c2 optimizations. >> >> For 2), TypeOopPtr::cast_to_non_interface() is used to filter out >> interfaces whenever signatures are used. >> >> As expected, this change makes several workarounds no longer necessary >> and cleans up the code quite a bit. For instance, >> CheckCastPPNode::Value() now falls back to the "right" implementation of >> ConstraintCastNode::Value() which leverages the type system. >> >> Fixing CheckCastPPNode::Value() exposes a bug in the C2 type checking >> logic: if a type check is proved to always fail during optimizations, >> the CheckCastPPNode becomes top, but the actual type checking logic in >> Phase::gen_subtype_check() doesn't always optimize out so the data path >> dies but not the control path. To fix that, I added a >> PartialSubtypeCheckNode::Value() method that triggers on subtype check >> failures consistently with CheckCastPPNode::Value. Problem is >> PartialSubtypeCheckNode is not checked first in >> Phase::gen_subtype_check(). So I added a duplicate test on the >> PartialSubtypeCheckNode result first in that logic, under an Opaque4Node >> so the actual is never compiled in the final code. >> >> Note that "8220416: Comparison of klass pointers is not optimized any >> more" is fixed by this. >> >> CastNullCheckDroppingsTest.java needs a change because >> testObjClassCast() has a call to objClass.cast() followed by a cast to >> String, so 2 casts in a raw once compiled. With the existing >> implementation, c2 can't see the casts as redundant and it keeps the >> second one. That one triggers a deopt if the test is passed null. The >> Class::cast implementation nevers traps for null. With the updated >> implementation, c2 sees the second cast as useless and optimizes it out. >> >> I dropped the CmpNNode::sub() becasue CmpN nodes are only created during >> final graph reshape so this is dead code. >> >> Performance is unaffected by this change AFAICT> >> >> Roland. From vladimir.kozlov at oracle.com Wed Jun 12 16:27:14 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2019 09:27:14 -0700 Subject: [13] RFR (T/XS) 8223796: JVMCIEnv::get_jvmci_type does not keep klasses alive Message-ID: <74dafe9b-1fa2-92dc-a50e-31d2621933da@oracle.com> http://cr.openjdk.java.net/~kvn/8223796/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8223796 The JVMCIEnv::get_jvmci_type() function has the block of code guarded by #ifdef INCLUDE_ALL_GCS and calls G1SATBCardTableModRefBS::enqueue() to keep Klass alive. However, the INCLUDE_ALL_GCS does not exist in jdk13 and the G1SATBCardTableModRefBS class does not exist either. We use the Access API to keep things alive. Erik ?sterlund wrote: "I think the klass handle looking thing (JVMCIKlassHandle) you get passed in already did klass_holder() and put that in a handle [1]. klass_holder() didn?t use to keep things alive but it does nowadays. Seems like removing the G1 stuff and the comment should be enough for jdk-jdk." I removed this code as Erik suggested. Thanks, Vladimir [1] http://hg.openjdk.java.net/jdk/jdk/file/f492567244ab/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l50 From igor.veresov at oracle.com Wed Jun 12 17:23:10 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 12 Jun 2019 10:23:10 -0700 Subject: [13] RFR (T/XS) 8223796: JVMCIEnv::get_jvmci_type does not keep klasses alive In-Reply-To: <74dafe9b-1fa2-92dc-a50e-31d2621933da@oracle.com> References: <74dafe9b-1fa2-92dc-a50e-31d2621933da@oracle.com> Message-ID: <5F9DF3B3-6B9B-4790-91F8-2CFAFBB45FF8@oracle.com> Looks good. igor > On Jun 12, 2019, at 9:27 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8223796/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8223796 > > The JVMCIEnv::get_jvmci_type() function has the block of code guarded by #ifdef INCLUDE_ALL_GCS and calls G1SATBCardTableModRefBS::enqueue() to keep Klass alive. However, the INCLUDE_ALL_GCS does not exist in jdk13 and the G1SATBCardTableModRefBS class does not exist either. We use the Access API to keep things alive. > > Erik ?sterlund wrote: > "I think the klass handle looking thing (JVMCIKlassHandle) you get passed in already did klass_holder() and put that in a handle [1]. klass_holder() didn?t use to keep things alive but it does nowadays. Seems like removing the G1 stuff and the comment should be enough for jdk-jdk." > > I removed this code as Erik suggested. > > Thanks, > Vladimir > > [1] http://hg.openjdk.java.net/jdk/jdk/file/f492567244ab/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Jun 12 17:33:16 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2019 10:33:16 -0700 Subject: [13] RFR (T/XS) 8223796: JVMCIEnv::get_jvmci_type does not keep klasses alive In-Reply-To: <5F9DF3B3-6B9B-4790-91F8-2CFAFBB45FF8@oracle.com> References: <74dafe9b-1fa2-92dc-a50e-31d2621933da@oracle.com> <5F9DF3B3-6B9B-4790-91F8-2CFAFBB45FF8@oracle.com> Message-ID: Thank you, Igor Vladimir On 6/12/19 10:23 AM, Igor Veresov wrote: > Looks good. > > igor > > > >> On Jun 12, 2019, at 9:27 AM, Vladimir Kozlov > > wrote: >> >> http://cr.openjdk.java.net/~kvn/8223796/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8223796 >> >> The JVMCIEnv::get_jvmci_type() function has the block of code guarded by #ifdef INCLUDE_ALL_GCS >> and calls G1SATBCardTableModRefBS::enqueue() to keep Klass alive. However, the INCLUDE_ALL_GCS >> does not exist in jdk13 and the G1SATBCardTableModRefBS class does not exist either. We use the >> Access API to keep things alive. >> >> Erik ?sterlund wrote: >> "I think the klass handle looking thing (JVMCIKlassHandle) you get passed in already did >> klass_holder() and put that in a handle [1]. klass_holder() didn?t use to keep things alive but it >> does nowadays. Seems like removing the G1 stuff and the comment should be enough for jdk-jdk." >> >> I removed this code as Erik suggested. >> >> Thanks, >> Vladimir >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/f492567244ab/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l50 > From ekaterina.pavlova at oracle.com Wed Jun 12 19:56:59 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 12 Jun 2019 12:56:59 -0700 Subject: RFR (T/XS) 8225622: [AOT] runtime/SharedArchiveFile/TestInterpreterMethodEntries.java crashed with AOTed java.base In-Reply-To: <14FB381F-53CE-4ECF-9A0D-8A6F3696D6AB@oracle.com> References: <14FB381F-53CE-4ECF-9A0D-8A6F3696D6AB@oracle.com> Message-ID: <8207af97-4a3d-c65f-0d48-cf91f548617d@oracle.com> Vladimir, thank you for the review. Pushed. -katya On 6/12/19 8:11 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks > Vladimir > >> On Jun 11, 2019, at 11:33 PM, Ekaterina Pavlova wrote: >> >> Hi, >> >> please review small test patch which disables first test case from running in case AOT is used. >> This test cases crashes when running with AOT because the test case explicitly disables intrinsics >> ( -XX:-UseCRC32Intrinsics -XX:-UseCRC32CIntrinsics ) while they were enabled for AOT library. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225622 >> webrev: http://cr.openjdk.java.net/~epavlova//8225622/webrev.00/index.html >> testing: run the test with and without AOT on all platforms. >> >> thanks, >> -katya > From igor.ignatyev at oracle.com Wed Jun 12 20:47:13 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Jun 2019 13:47:13 -0700 Subject: RFR(T) [13] : 8225676 : cleanup hotspot ProblemList Message-ID: <0907E9D4-6689-4437-9B44-DAC92846EACA@oracle.com> http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html > 9 lines changed: 2 ins; 4 del; 3 mod; Hi all, could you please review this small and trivial patch which cleans up hotspot problem lists? - 8224234 : "compiler/codegen/TestCharVect2.java fails in test_mulc" was fixed recently w/o removing problem list entry - 8221577 : "[Graal] Implement basic type consistency checks for Low level MH intrinsics" and 8224254 :"compiler/graalunit/HotspotJdk9Test.java is timing out intermittently" are closed as a dup of next graal update -- 8224254 - 8066173 : "compiler/types/correctness/OffTest.java failed with assert" used wrong bug id to problem list tests on solaris-sparcv9 webrev: http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8225676 Thanks, -- Igor From david.holmes at oracle.com Thu Jun 13 00:16:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2019 10:16:31 +1000 Subject: RFR(T) [13] : 8225676 : cleanup hotspot ProblemList In-Reply-To: <0907E9D4-6689-4437-9B44-DAC92846EACA@oracle.com> References: <0907E9D4-6689-4437-9B44-DAC92846EACA@oracle.com> Message-ID: Hi Igor, On 13/06/2019 6:47 am, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html >> 9 lines changed: 2 ins; 4 del; 3 mod; > > Hi all, > > could you please review this small and trivial patch which cleans up hotspot problem lists? > > - 8224234 : "compiler/codegen/TestCharVect2.java fails in test_mulc" was fixed recently w/o removing problem list entry Okay. > - 8221577 : "[Graal] Implement basic type consistency checks for Low level MH intrinsics" and 8224254 :"compiler/graalunit/HotspotJdk9Test.java is timing out intermittently" are closed as a dup of next graal update -- 8224254 That last 8224254 should be 8223807 right? > - 8066173 : "compiler/types/correctness/OffTest.java failed with assert" used wrong bug id to problem list tests on solaris-sparcv9 Okay. Thanks, David > webrev: http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8225676 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Thu Jun 13 00:23:55 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Jun 2019 17:23:55 -0700 Subject: RFR(T) [13] : 8225676 : cleanup hotspot ProblemList In-Reply-To: References: <0907E9D4-6689-4437-9B44-DAC92846EACA@oracle.com> Message-ID: <457388D6-7292-438E-B813-8659EC0C0AF2@oracle.com> Hi David, thanks for your review. > That last 8224254 should be 8223807 right? right, copy-paste error in the email. the patch uses 8223807. -- Igor > On Jun 12, 2019, at 5:16 PM, David Holmes wrote: > > Hi Igor, > > On 13/06/2019 6:47 am, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html >>> 9 lines changed: 2 ins; 4 del; 3 mod; >> Hi all, >> could you please review this small and trivial patch which cleans up hotspot problem lists? >> - 8224234 : "compiler/codegen/TestCharVect2.java fails in test_mulc" was fixed recently w/o removing problem list entry > > Okay. > >> - 8221577 : "[Graal] Implement basic type consistency checks for Low level MH intrinsics" and 8224254 :"compiler/graalunit/HotspotJdk9Test.java is timing out intermittently" are closed as a dup of next graal update -- 8224254 > > That last 8224254 should be 8223807 right? > >> - 8066173 : "compiler/types/correctness/OffTest.java failed with assert" used wrong bug id to problem list tests on solaris-sparcv9 > > Okay. > > Thanks, > David > >> webrev: http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225676 >> Thanks, >> -- Igor From tom.rodriguez at oracle.com Thu Jun 13 00:24:41 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 12 Jun 2019 17:24:41 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: References: <4C2D0A78.5020906@oracle.com> <4C2D0EC1.4090607@oracle.com> <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com> Message-ID: <57037b04-866f-74d1-b9c4-ab00c29dbbef@oracle.com> Leela Mohan wrote on 6/11/19 12:53 PM: > > > On Mon, Jun 10, 2019 at 10:45 AM Tom Rodriguez > wrote: > > > > Leela Mohan wrote on 6/7/19 6:39 PM: > > This is super late reply to this review mail but i have couple of > > questions about this change. > > Wow 9 years.? :) > > > > > Looking at the diff here : > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/65b0c03b165d > > > > I think, Calling?JvmtiExport::post_compiled_method_load(JvmtiEnv* > > env,..) to?JvmtiExport::post_compiled_method_load(nmethod*) > versio is > > possibly incorrect since, this would do callbacks to multiple jvmti > > environments (jvmti agents) which is unexpected. Callbacks are > expected > > to be called to current jvmti env which called GenerateEvents. > > I think you're right.? Anyone listening for those events will also get > notified which isn't quite right.? Please file a bug.? It should be > easy > enough to fix.? Factoring out the notification body of > post_compiled_method_load into it's own method and calling that from > generate_compiled_method_load_events would work great. > > > Thanks for confirming. I don't know the formalities of filing a bug. Can > you please pass me the instructions. Thanks. You can file a bug report at https://bugreport.java.com/bugreport/start_form.do and if you want to contribute a fix for it the general OpenJDK guidelines are at https://openjdk.java.net/contribute. That doesn't seem to cover the recommended process for hotspot such as the use of webrev, so maybe someone can provide a better link. tom > > And I was wondering what was the original lock rank ordering issue. It > took some time for me to understand what the issue is. > Before the change, CodeCache_lock was held when ?nmethod closure ?(i.e) > nmethodCollector::do_nmethod(nmethod* nm) was called on each nmethod and > closure was callingnmethod::get_and_cache_jmethod_id() which needed > JNIGlobalHandle_lock (jmethods then were jweak handles).? Lot seemed to > have changed after this but intent of not holding CodeCache_lock around > nmethod::get_and_cache_jmethod_id() is still valid. > > Thanks, > Leela > > > tom > > > > > > > > > > > > > On Thu, Jul 1, 2010 at 4:07 PM Tom Rodriguez > > > >> wrote: > > > >? ? ?Thanks.? Dan also reviewed this as I was developing it. > > > >? ? ?tom > > > >? ? ?On Jul 1, 2010, at 2:55 PM, Vladimir Kozlov wrote: > > > >? ? ? > Thanks, Tom > >? ? ? > > >? ? ? > Changes are good to go. > >? ? ? > > >? ? ? > Vladimir > >? ? ? > > >? ? ? > On 7/1/10 2:41 PM, Tom Rodriguez wrote: > >? ? ? >> > >? ? ? >> On Jul 1, 2010, at 2:36 PM, Vladimir Kozlov wrote: > >? ? ? >> > >? ? ? >>> You did not explain your changes for cb->name(). > >? ? ? >> > >? ? ? >> That was just a clean up I've been wanting to do.? There > was a > >? ? ?time then only some of the CodeBlob subclasses had name() methods > >? ? ?but now it's part of CodeBlob so that logic is unnecessary. > >? ? ? >> > >? ? ? >>> Why we don't lock nmethod in sweeper during CodeCache > walk but > >? ? ?lock here? > >? ? ? >> > >? ? ? >> nmethodLocker protects you from the sweeper so the sweeper > >? ? ?doesn't need protection. > >? ? ? >> > >? ? ? >> tom > >? ? ? >> > >? ? ? >>> > >? ? ? >>> Thanks, > >? ? ? >>> Vladimir > >? ? ? >>> > >? ? ? >>> On 7/1/10 1:58 PM, Tom Rodriguez wrote: > >? ? ? >>>> http://cr.openjdk.java.net/~never/6965671/ > > >? ? ? > >? ? ? >>>> > >? ? ? >>>> 6965671: fatal error: acquiring lock > JNIGlobalHandle_lock/16 > >? ? ?out of order with lock CodeCache_lock/1 > >? ? ? >>>> Reviewed-by: > >? ? ? >>>> > >? ? ? >>>> The jmethodID fix created a deadlock because of lock > ordering when > >? ? ? >>>> walking the CodeCache to generate CompiledMethodLoad > events. > >? ? ?The walk > >? ? ? >>>> is performed with the CodeCache_lock held but we need to > >? ? ?acquire the > >? ? ? >>>> JNIGlobalHandle_lock to make a jmethodID.? I considered > >? ? ?switching back > >? ? ? >>>> to collecting the methodOop instead of the jmethodID > under the > >? ? ?lock > >? ? ? >>>> but inspection of the code made it clear that there's a > >? ? ?preexisting > >? ? ? >>>> problem with GC of the methodOops stored into the > nmethodDesc. > >? ? ? >>>> Instead I switched to a simpler implementation that > holds the > >? ? ? >>>> CodeCache_lock while walking the CodeCache but releases the > >? ? ?lock to > >? ? ? >>>> actually perform the notify.? This simplifies the code > greatly > >? ? ?as well > >? ? ? >>>> as fixing the bug. > >? ? ? >>>> > >? ? ? >>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and > >? ? ?JDI_REGRESSION > >? ? ? >>>> tests. > >? ? ? >> > > > From fujie at loongson.cn Thu Jun 13 03:18:55 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 13 Jun 2019 11:18:55 +0800 Subject: RFR: 8225644: [TESTBUG] langtools/tools/javac/generics/inference/8058199/T8058199.java fails with -Xcomp In-Reply-To: References: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com> <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> Message-ID: <3734a50d-6d4e-0c97-44cf-5616c6db4509@loongson.cn> Hi Bernard, Thanks for your great help. I've updated the description of the JBS. And will send a new RFR to hotspot-compiler-dev at openjdk.java.net soon. Thanks a lot. Best regards, Jie On 2019/6/12 ??6:09, B. Blaser wrote: > [ Forwarding to hotspot-compiler-dev ] > > The CCE messages are probably generated here: > > http://hg.openjdk.java.net/jdk/jdk/file/755e82641224/src/hotspot/share/runtime/sharedRuntime.hpp#l301 > http://hg.openjdk.java.net/jdk/jdk/file/755e82641224/src/hotspot/share/runtime/sharedRuntime.hpp#l315 > > Note that the second one might be called from interpreted code and > seems to generate the expected message. > > I hope this helps, > Bernard > > On Wed, 12 Jun 2019 at 08:15, Jie Fu wrote: >> Hi Joe, >> >> Thanks for your review. >> Do you mean the JIT shouldn't dump the signature like "[Ljava/lang/String;"? >> >> I'd like to do more investigation. >> Thanks. >> >> Best regards, >> Jie >> >> On 2019/6/12 ??2:01, Joe Darcy wrote: >>> Hello, >>> >>> If the javac test is only failing under -Xcomp, a reasonable avenue to >>> investigate is that -Xcomp is misbehaving rather than the test code. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 6/11/2019 10:56 PM, Jie Fu wrote: >>>> Hi all, >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8225644 >>>> Webrev: http://cr.openjdk.java.net/~jiefu/8225644/webrev.00/ >>>> >>>> Reason: with -Xcomp, the signature was dumped as >>>> "[Ljava/lang/String;" rather than "[Ljava.lang.String;". >>>> Fix: It might be better to replace '/' with '.' before matching. >>>> >>>> Could you please review it? >>>> >>>> Thanks a lot. >>>> Best regards, >>>> Jie >>>> >>>> From fujie at loongson.cn Thu Jun 13 03:30:07 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 13 Jun 2019 11:30:07 +0800 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message Message-ID: Hi all, JBS:??? https://bugs.openjdk.java.net/browse/JDK-8225644 Webrev: http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ An early discussion of this issue was in the mailing-list of compiler-dev[1]. Thanks Joe and Bernard's help. Could you please review it? Thanks a lot. Best regards, Jie [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013464.html From rwestrel at redhat.com Thu Jun 13 08:25:12 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 13 Jun 2019 10:25:12 +0200 Subject: RFR(XL): 6312651: Compiler should only use verified interface types for optimization In-Reply-To: <6c9caa98-aed1-a5f4-fa52-7a90a8893cdf@oracle.com> References: <87ftp9l5cy.fsf@redhat.com> <874l4ueszd.fsf@redhat.com> <6c9caa98-aed1-a5f4-fa52-7a90a8893cdf@oracle.com> Message-ID: <871rzxevtj.fsf@redhat.com> Hi Vladimir, > I'm very interested in the enhancements you propose and I plan to look > into it, but I need more time to finish the review. > > I hope hope you are fine with deferring it for jdk14. Sure jdk14 is fine. Thanks for letting me know you intend to review it. Roland. From martin.doerr at sap.com Thu Jun 13 09:17:41 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 13 Jun 2019 09:17:41 +0000 Subject: RFR(T): 8225663: [testbug] Missing JNIEXPORT in XAbortProvoker native function In-Reply-To: <2CD9E5CF-B51E-4F93-AAB9-885DC52054C8@oracle.com> References: <2CD9E5CF-B51E-4F93-AAB9-885DC52054C8@oracle.com> Message-ID: Thanks for the reviews. Pushed. Best regards, Martin From: Vladimir Kozlov Sent: Mittwoch, 12. Juni 2019 17:14 To: Doerr, Martin Cc: hotspot-compiler-dev at openjdk.java.net; Gustavo Romero ; Baesken, Matthias ; Zeller, Arno Subject: Re: RFR(T): 8225663: [testbug] Missing JNIEXPORT in XAbortProvoker native function Good. Thanks Vladimir On Jun 12, 2019, at 7:53 AM, Doerr, Martin > wrote: Hi, please review my trivial fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8225663 Webrev: http://cr.openjdk.java.net/~mdoerr/8225663_test_rtm/webrev.00/ Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Thu Jun 13 09:46:40 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 13 Jun 2019 12:46:40 +0300 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: Message-ID: > http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ Looks good. Best regards, Vladimir Ivanov From fujie at loongson.cn Thu Jun 13 12:27:00 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 13 Jun 2019 20:27:00 +0800 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: Message-ID: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> Thanks Vladimir Ivanov for your review. On 2019/6/13 ??5:46, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ > > Looks good. > > Best regards, > Vladimir Ivanov From adam.farley at uk.ibm.com Thu Jun 13 15:08:21 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 13 Jun 2019 16:08:21 +0100 Subject: RFR: JDK-8224963: Char-Byte Performance Enhancement In-Reply-To: References: <68b970be-e551-577d-0ca1-28c16880a2ff@oracle.com> Message-ID: Hi Andrew, x86 code is something I haven't touched in years, and while it's possible I could find a way to make the code generated by C2 faster, I consider it unlikely that I'll be better at it than the current C2 specialists in the community. Thank you, and Vladmir, for your time. :) Best Regards Adam Farley IBM Runtimes Andrew Dinn wrote on 11/06/2019 10:50:20: > From: Andrew Dinn > To: Adam Farley8 , Vladimir Ivanov > > Cc: hotspot-compiler-dev at openjdk.java.net > Date: 11/06/2019 10:50 > Subject: Re: RFR: JDK-8224963: Char-Byte Performance Enhancement > > Hi Adam, > > On 11/06/2019 10:04, Adam Farley8 wrote: > > Merely patching the class library code will not effect any performance > > enhancement. > > > > Quite the opposite. :) > > > > The changes in the class library were designed to work in tandem with > > some changes to the OpenJ9 JIT compiler, which is what accelerates > > performance. > > > > Naturally, investigating and sharing OpenJ9 logic is a bad idea due to > > contamination, so we're stuck with investigating the CL changes to > > identify any potential value to OpenJDK with Hotspot. > > This seems a slightly odd way to go about arriving at an improvement in > the generated code. > > What you probably ought to do in order to make progress here -- and > /without/ exposing any secrets about the J9 implementation -- is to take > an assembly dump of the x86 code that is currently being generated and > then identify some transformation to that x86 code which 1) brings it > nearer to what J9 produces and/or 2) clearly improves performance (you > appear to be assuming 1 and 2 go together here but that is not actually > required). n.b. you could identify such a generated code transformation > starting either from the existing Java source or from your modified Java > source. > > If you /can/ specify what the improved machine code needs to look like > relative to the current code then it would be possible and, perhaps, > relatively easy for someone who does understand the C2 compiler to > determine whether there is a way to adopt this alternative > code-generation strategy simply by tweaking the C2 compiler. > > Of course, the alternative might be that effecting such a change in > generated code would require major changes to C2 -- it might even be (as > the Arkansas farmer says) that you can't get there from here. Whatever, > proceeding as suggested above won't expose what J9 is doing and won't > require you to know what C2 is doing. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Thu Jun 13 17:45:41 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 13 Jun 2019 19:45:41 +0200 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> Message-ID: Seems good to me too. Thanks, Bernard On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: > > Thanks Vladimir Ivanov for your review. > > On 2019/6/13 ??5:46, Vladimir Ivanov wrote: > > > >> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ > > > > Looks good. > > > > Best regards, > > Vladimir Ivanov > From fujie at loongson.cn Thu Jun 13 22:55:19 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 14 Jun 2019 06:55:19 +0800 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> Message-ID: <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> Hi Bernard, Thank you for your review. And could you please sponsor it? Thanks a lot. Best regards, Jie On 2019/6/14 ??1:45, B. Blaser wrote: > Seems good to me too. > > Thanks, > Bernard > > On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: >> Thanks Vladimir Ivanov for your review. >> >> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ >>> Looks good. >>> >>> Best regards, >>> Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Jun 13 23:04:35 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Jun 2019 16:04:35 -0700 Subject: [13] RFR(T) 8209590: compiler/compilercontrol/DontInlineCommandTest.java test fails with "Inline message differs" error Message-ID: <573c07a3-3bcc-4a02-3b75-83bb6c5e7c94@oracle.com> Unfortunately bug is closed because failed test is closed. But fix is in open test code: http://cr.openjdk.java.net/~kvn/8209590/webrev.00/ Here is evaluation (from bug report): The test checks that specified test method [1] is not inlined because -XX:CompileCommand=dontinline,*Klass*,* command line flag is used. But during failure the method is not inlined for a different reason: 'already compiled into a medium method' It happens due to flags combination passed by testing environment: -ea -esa -XX:CompileThreshold=100 -XX:-DoEscapeAnalysis -XX:-TieredCompilation Based on LogCompilation output the method's compiled size is 344 [2]. In failing case -XX:-TieredCompilation is off and InlineSmallCode flag default value for x86 is 1000 [3]. The code size inlining criteria is using InlineSmallCode/4 [4]. So 344 > 250. The fix is to set -XX:InlineSmallCode=4000 for tests which check inlining decisions. Tested with failing test. Thanks, Vladimir [1] http://hg.openjdk.java.net/jdk/jdk/file/d57d61aafef9/test/hotspot/jtreg/compiler/compilercontrol/share/pool/sub/Klass.java#l60 [2] [3] http://hg.openjdk.java.net/jdk/jdk/file/d57d61aafef9/src/hotspot/cpu/x86/globals_x86.hpp#l55 [4] http://hg.openjdk.java.net/jdk/jdk/file/d57d61aafef9/src/hotspot/share/opto/bytecodeInfo.cpp#l160 From igor.ignatyev at oracle.com Thu Jun 13 23:44:00 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 13 Jun 2019 16:44:00 -0700 Subject: [13] RFR(T) 8209590: compiler/compilercontrol/DontInlineCommandTest.java test fails with "Inline message differs" error In-Reply-To: <573c07a3-3bcc-4a02-3b75-83bb6c5e7c94@oracle.com> References: <573c07a3-3bcc-4a02-3b75-83bb6c5e7c94@oracle.com> Message-ID: Hi Vladimir, this sounds reasonable to me, reviewed. Cheers, -- Igor > On Jun 13, 2019, at 4:04 PM, Vladimir Kozlov wrote: > > Unfortunately bug is closed because failed test is closed. But fix is in open test code: > > http://cr.openjdk.java.net/~kvn/8209590/webrev.00/ > > Here is evaluation (from bug report): > > The test checks that specified test method [1] is not inlined because -XX:CompileCommand=dontinline,*Klass*,* command line flag is used. > > But during failure the method is not inlined for a different reason: > 'already compiled into a medium method' > > It happens due to flags combination passed by testing environment: > -ea -esa -XX:CompileThreshold=100 -XX:-DoEscapeAnalysis -XX:-TieredCompilation > > Based on LogCompilation output the method's compiled size is 344 [2]. > > In failing case -XX:-TieredCompilation is off and InlineSmallCode flag default value for x86 is 1000 [3]. > The code size inlining criteria is using InlineSmallCode/4 [4]. So 344 > 250. > > The fix is to set -XX:InlineSmallCode=4000 for tests which check inlining decisions. > > Tested with failing test. > > Thanks, > Vladimir > > [1] http://hg.openjdk.java.net/jdk/jdk/file/d57d61aafef9/test/hotspot/jtreg/compiler/compilercontrol/share/pool/sub/Klass.java#l60 > > [2] > > > [3] http://hg.openjdk.java.net/jdk/jdk/file/d57d61aafef9/src/hotspot/cpu/x86/globals_x86.hpp#l55 > > [4] http://hg.openjdk.java.net/jdk/jdk/file/d57d61aafef9/src/hotspot/share/opto/bytecodeInfo.cpp#l160 From vladimir.kozlov at oracle.com Thu Jun 13 23:55:32 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Jun 2019 16:55:32 -0700 Subject: [13] RFR(T) 8209590: compiler/compilercontrol/DontInlineCommandTest.java test fails with "Inline message differs" error In-Reply-To: References: <573c07a3-3bcc-4a02-3b75-83bb6c5e7c94@oracle.com> Message-ID: Thank you, Igor. Vladimir On 6/13/19 4:44 PM, Igor Ignatyev wrote: > Hi Vladimir, > > this sounds reasonable to me, reviewed. > > Cheers, > -- Igor > >> On Jun 13, 2019, at 4:04 PM, Vladimir Kozlov wrote: >> >> Unfortunately bug is closed because failed test is closed. But fix is in open test code: >> >> http://cr.openjdk.java.net/~kvn/8209590/webrev.00/ >> >> Here is evaluation (from bug report): >> >> The test checks that specified test method [1] is not inlined because -XX:CompileCommand=dontinline,*Klass*,* command line flag is used. >> >> But during failure the method is not inlined for a different reason: >> 'already compiled into a medium method' >> >> It happens due to flags combination passed by testing environment: >> -ea -esa -XX:CompileThreshold=100 -XX:-DoEscapeAnalysis -XX:-TieredCompilation >> >> Based on LogCompilation output the method's compiled size is 344 [2]. >> >> In failing case -XX:-TieredCompilation is off and InlineSmallCode flag default value for x86 is 1000 [3]. >> The code size inlining criteria is using InlineSmallCode/4 [4]. So 344 > 250. >> >> The fix is to set -XX:InlineSmallCode=4000 for tests which check inlining decisions. >> >> Tested with failing test. >> >> Thanks, >> Vladimir >> >> [1] http://hg.openjdk.java.net/jdk/jdk/file/d57d61aafef9/test/hotspot/jtreg/compiler/compilercontrol/share/pool/sub/Klass.java#l60 >> >> [2] >> >> >> [3] http://hg.openjdk.java.net/jdk/jdk/file/d57d61aafef9/src/hotspot/cpu/x86/globals_x86.hpp#l55 >> >> [4] http://hg.openjdk.java.net/jdk/jdk/file/d57d61aafef9/src/hotspot/share/opto/bytecodeInfo.cpp#l160 > From shravya.rukmannagari at intel.com Thu Jun 13 23:57:16 2019 From: shravya.rukmannagari at intel.com (Rukmannagari, Shravya) Date: Thu, 13 Jun 2019 23:57:16 +0000 Subject: JMH Tests Support for JDK-8222074 Message-ID: <8D6F463991A1574A8A803B8DA605414F3A8D88B2@ORSMSX111.amr.corp.intel.com> Hi All, I have added JMH test support for the following vector operations: 1) Absolute for all data types 2) Shifts for byte data types 3) Shift right arithmetic for long data type 4) Byte multiply 5) Negate for float/double Please find the webrev below and let me know if you have any comments or suggestions. Webrev: http://cr.openjdk.java.net/~srukmannagar/JMHTests/webrev/ Bug ID: https://bugs.openjdk.java.net/browse/JDK-8225626 Thanks, Shravya. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Fri Jun 14 08:03:55 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 14 Jun 2019 10:03:55 +0200 Subject: RFR: 8225351(13): assert failed: Revoke failed, unhandled biased lock state Message-ID: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> Hi all, please review. When looking at a JavaThreads locks we retrieve them per frame via it's monitors list. How this list actually populated differs from frame type. If a JavaThread tries to enter a new monitor a basic lock is directly/indirectly via e.g. scope info added to the virtual monitor list. If this lock is biased towards another JavaThread we try to revoke that bias with a safepoint. In this case a deopt handshake is already in queue. The handshake is thus executed before the revoke safepoint. The handshake goes over the monitors in compiled frames, find this lock and we hit the assert. The assert make sure we actual can revoke the lock. A basic lock on stack should always, if biased, be biased to current thread, with the exception: We may have a stack lock biased against another thread until ObjectSynchronizer::fast_enter returns. To handle this exception we can safely ignore biased lock towards other threads in the deopt handshake. Since such locks will always be revoked before we deopt/unpack stack. Code: http://cr.openjdk.java.net/~rehn/8225351/v1/webrev/index.html Issue: https://bugs.openjdk.java.net/browse/JDK-8225351 Passes t1-7 The assert code tested with local code changes to HandshakeAlot handshake. We then see this state where last lock can be biased towards another thread and the thread is trying to execute revoke safepoint. Thanks, Robbin From tianxiao.gu at gmail.com Fri Jun 14 08:09:06 2019 From: tianxiao.gu at gmail.com (Tianxiao Gu) Date: Fri, 14 Jun 2019 01:09:06 -0700 Subject: JVMCI may use an incorrect classloader to resolve a callee class Message-ID: Hi All, JVMCI may use a wrong classloader to resolve a callee class when the caller frame (obtained by frame caller_frame = thread->last_frame().sender(&cbl_map);) is a compiled inlined method (see CompilerRuntime::resolve_klass_helper at http://hg.openjdk.java.net/jdk/jdk/file/1afe0cb93482/src/hotspot/share/jvmci/compilerRuntime.cpp#l60 ). In an inlined method, the actual, direct caller of an unresolved callee may not be the root of the inline tree. The actual caller and the root of the inline tree may even have different classloaders. This should be a bug and can be reproduced with the attached test case in JDK 11. A patch would use vframeStream to walk the stack. The test case is based on AOT and uses custom classloaders. In JDK 11, we are still able to use AOT with custom classloaders though it is not type-safe. (See bug report https://bugs.openjdk.java.net/browse/JDK-8206963). Custom classloaders have been disabled in AOT in http://hg.openjdk.java.net/jdk/jdk/rev/ccfa71bacd6f. That means this bug will not be able to be reproduced in the latest JDK with the attached test case. Environment: $ uname -a Darwin US-204496-MP.local 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64 $ java -version java version "11.0.2" 2019-01-15 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) $ jaotc --version jaotc 11.0.2+9-LTS Reproducing Steps: 1. Unzip the attached test case and run script run.sh. 2. In AOT mode, we will see a message "Should not load me!", which indicates that a wrong classloader is used. 3. In interpreter mode, we will not see the message. Best regards, Tianxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: incorrect-caller.zip Type: application/zip Size: 3149 bytes Desc: not available URL: From tobias.hartmann at oracle.com Fri Jun 14 08:58:10 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 14 Jun 2019 10:58:10 +0200 Subject: [14] RFR(T): 8225783: Incorrect use of binary operators on booleans in type.cpp Message-ID: <72048880-ef30-a056-3e96-2fa23291fb7d@oracle.com> Hi, please review the following patch that fixes incorrect usages of | and & operators on booleans: https://bugs.openjdk.java.net/browse/JDK-8225783 http://cr.openjdk.java.net/~thartmann/8225783/webrev.00/ Thanks, Tobias From rwestrel at redhat.com Fri Jun 14 09:05:25 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 14 Jun 2019 11:05:25 +0200 Subject: [14] RFR(T): 8225783: Incorrect use of binary operators on booleans in type.cpp In-Reply-To: <72048880-ef30-a056-3e96-2fa23291fb7d@oracle.com> References: <72048880-ef30-a056-3e96-2fa23291fb7d@oracle.com> Message-ID: <87ef3wczai.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8225783/webrev.00/ Looks good. Roland. From tobias.hartmann at oracle.com Fri Jun 14 09:06:57 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 14 Jun 2019 11:06:57 +0200 Subject: [14] RFR(T): 8225783: Incorrect use of binary operators on booleans in type.cpp In-Reply-To: <87ef3wczai.fsf@redhat.com> References: <72048880-ef30-a056-3e96-2fa23291fb7d@oracle.com> <87ef3wczai.fsf@redhat.com> Message-ID: Thanks Roland. Best regards, Tobias On 14.06.19 11:05, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8225783/webrev.00/ > > Looks good. > > Roland. > From doug.simon at oracle.com Fri Jun 14 09:35:28 2019 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 14 Jun 2019 11:35:28 +0200 Subject: JVMCI may use an incorrect classloader to resolve a callee class In-Reply-To: References: Message-ID: Hi Tianxiao, Just for clarification, this only applies to AOT execution if I understand correctly? -Doug > On 14 Jun 2019, at 10:09, Tianxiao Gu wrote: > > Hi All, > > JVMCI may use a wrong classloader to resolve a callee class when the caller frame (obtained by frame caller_frame = thread->last_frame().sender(&cbl_map);) is a compiled inlined method (see CompilerRuntime::resolve_klass_helper at http://hg.openjdk.java.net/jdk/jdk/file/1afe0cb93482/src/hotspot/share/jvmci/compilerRuntime.cpp#l60 ). > > In an inlined method, the actual, direct caller of an unresolved callee may not be the root of the inline tree. The actual caller and the root of the inline tree may even have different classloaders. This should be a bug and can be reproduced with the attached test case in JDK 11. A patch would use vframeStream to walk the stack. > > The test case is based on AOT and uses custom classloaders. In JDK 11, we are still able to use AOT with custom classloaders though it is not type-safe. (See bug report https://bugs.openjdk.java.net/browse/JDK-8206963 ). Custom classloaders have been disabled in AOT in http://hg.openjdk.java.net/jdk/jdk/rev/ccfa71bacd6f . That means this bug will not be able to be reproduced in the latest JDK with the attached test case. > > Environment: > $ uname -a > Darwin US-204496-MP.local 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64 > $ java -version > java version "11.0.2" 2019-01-15 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) > $ jaotc --version > jaotc 11.0.2+9-LTS > > > Reproducing Steps: > 1. Unzip the attached test case and run script run.sh. > 2. In AOT mode, we will see a message "Should not load me!", which indicates that a wrong classloader is used. > 3. In interpreter mode, we will not see the message. > > Best regards, > Tianxiao > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tianxiao.gu at gmail.com Fri Jun 14 10:36:11 2019 From: tianxiao.gu at gmail.com (Tianxiao Gu) Date: Fri, 14 Jun 2019 03:36:11 -0700 Subject: JVMCI may use an incorrect classloader to resolve a callee class In-Reply-To: References: Message-ID: Hi Doug, Thank you very much for your reply. First, I am not sure whether the bug applies to AOT execution only. I used AOT to create the test case because in AOT I can easily force inline and also trigger the invocation of resolve_klass_by_symbol. I think this bug should apply to AOT only if method resolve_klass_by_symbol is only used by AOT. In my opinion, CompilerRutime in JVMCI should be consistent with SharedRuntime, where SharedRuntime uses the vframeStream to do the stack walk in the similar case. Best, Tianxiao On Fri, Jun 14, 2019 at 2:35 AM Doug Simon wrote: > Hi Tianxiao, > > Just for clarification, this only applies to AOT execution if I understand > correctly? > > -Doug > > On 14 Jun 2019, at 10:09, Tianxiao Gu wrote: > > Hi All, > > JVMCI may use a wrong classloader to resolve a callee class when the > caller frame (obtained by frame caller_frame = > thread->last_frame().sender(&cbl_map);) is a compiled inlined method (see > CompilerRuntime::resolve_klass_helper at > http://hg.openjdk.java.net/jdk/jdk/file/1afe0cb93482/src/hotspot/share/jvmci/compilerRuntime.cpp#l60 > ). > > In an inlined method, the actual, direct caller of an unresolved callee > may not be the root of the inline tree. The actual caller and the root of > the inline tree may even have different classloaders. This should be a bug > and can be reproduced with the attached test case in JDK 11. A patch would > use vframeStream to walk the stack. > > The test case is based on AOT and uses custom classloaders. In JDK 11, we > are still able to use AOT with custom classloaders though it is not > type-safe. (See bug report > https://bugs.openjdk.java.net/browse/JDK-8206963). Custom classloaders > have been disabled in AOT in > http://hg.openjdk.java.net/jdk/jdk/rev/ccfa71bacd6f. That means this bug > will not be able to be reproduced in the latest JDK with the attached test > case. > > Environment: > $ uname -a > Darwin US-204496-MP.local 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 > 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64 > $ java -version > java version "11.0.2" 2019-01-15 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) > $ jaotc --version > jaotc 11.0.2+9-LTS > > > Reproducing Steps: > 1. Unzip the attached test case and run script run.sh. > 2. In AOT mode, we will see a message "Should not load me!", which > indicates that a wrong classloader is used. > 3. In interpreter mode, we will not see the message. > > Best regards, > Tianxiao > > > > > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Fri Jun 14 12:16:50 2019 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 14 Jun 2019 14:16:50 +0200 Subject: JVMCI may use an incorrect classloader to resolve a callee class In-Reply-To: References: Message-ID: > On 14 Jun 2019, at 12:36, Tianxiao Gu wrote: > > Hi Doug, > > Thank you very much for your reply. > > First, I am not sure whether the bug applies to AOT execution only. I used AOT to create the test case because in AOT I can easily force inline and also trigger the invocation of resolve_klass_by_symbol. I think this bug should apply to AOT only if method resolve_klass_by_symbol is only used by AOT. I think that must be the case since CompilerRuntime is not present in https://github.com/graalvm/graal-jvmci-8. > In my opinion, CompilerRutime in JVMCI should be consistent with SharedRuntime, where SharedRuntime uses the vframeStream to do the stack walk in the similar case. Sounds reasonable but I?m not so familiar with CompilerRuntime so will others comment on that. -Doug > On Fri, Jun 14, 2019 at 2:35 AM Doug Simon > wrote: > Hi Tianxiao, > > Just for clarification, this only applies to AOT execution if I understand correctly? > > -Doug > >> On 14 Jun 2019, at 10:09, Tianxiao Gu > wrote: >> >> Hi All, >> >> JVMCI may use a wrong classloader to resolve a callee class when the caller frame (obtained by frame caller_frame = thread->last_frame().sender(&cbl_map);) is a compiled inlined method (see CompilerRuntime::resolve_klass_helper at http://hg.openjdk.java.net/jdk/jdk/file/1afe0cb93482/src/hotspot/share/jvmci/compilerRuntime.cpp#l60 ). >> >> In an inlined method, the actual, direct caller of an unresolved callee may not be the root of the inline tree. The actual caller and the root of the inline tree may even have different classloaders. This should be a bug and can be reproduced with the attached test case in JDK 11. A patch would use vframeStream to walk the stack. >> >> The test case is based on AOT and uses custom classloaders. In JDK 11, we are still able to use AOT with custom classloaders though it is not type-safe. (See bug report https://bugs.openjdk.java.net/browse/JDK-8206963 ). Custom classloaders have been disabled in AOT in http://hg.openjdk.java.net/jdk/jdk/rev/ccfa71bacd6f . That means this bug will not be able to be reproduced in the latest JDK with the attached test case. >> >> Environment: >> $ uname -a >> Darwin US-204496-MP.local 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64 >> $ java -version >> java version "11.0.2" 2019-01-15 LTS >> Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) >> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) >> $ jaotc --version >> jaotc 11.0.2+9-LTS >> >> >> Reproducing Steps: >> 1. Unzip the attached test case and run script run.sh. >> 2. In AOT mode, we will see a message "Should not load me!", which indicates that a wrong classloader is used. >> 3. In interpreter mode, we will not see the message. >> >> Best regards, >> Tianxiao >> >> > > > > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Fri Jun 14 17:53:48 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 14 Jun 2019 19:53:48 +0200 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> Message-ID: As shared code is affected, I've pushed it to jdk/submit to make sure all is right on every supported systems: http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 I've added a configuration to the failing test which might be kept when pushing to jdk/jdk providing that we get a Reviewer approval from the langtools team for this? Thanks, Bernard On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: > > Hi Bernard, > > Thank you for your review. > And could you please sponsor it? > > Thanks a lot. > Best regards, > Jie > > > On 2019/6/14 ??1:45, B. Blaser wrote: > > > Seems good to me too. > > > > Thanks, > > Bernard > > > > On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: > >> Thanks Vladimir Ivanov for your review. > >> > >> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: > >>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ > >>> Looks good. > >>> > >>> Best regards, > >>> Vladimir Ivanov > From vladimir.kozlov at oracle.com Fri Jun 14 18:07:34 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Jun 2019 11:07:34 -0700 Subject: JVMCI may use an incorrect classloader to resolve a callee class In-Reply-To: References: Message-ID: CompilerRutime is used only by AOT compiled code. The reason we disable custom classloaders (JDK-8206963) for AOT is because there are no way during AOT compilation to know (or even record) which class loaders will be used during execution. And track relations between custom class loaders is complicated for AOT code - most likely we would have to deoptimize all AOT code if it is used by custom class loaders. But you are right that we need to use vframe in resolve_klass_helper() to find inlined caller which holder may have different class loader than root compiled method because we have several builtin class loaders. Thanks, Vladimir On 6/14/19 5:16 AM, Doug Simon wrote: > > >> On 14 Jun 2019, at 12:36, Tianxiao Gu > wrote: >> >> Hi Doug, >> >> Thank you very much for your reply. >> >> First, I am not sure whether the bug applies to AOT execution only. I used AOT to create the test >> case because in AOT I can easily force inline and also trigger the invocation of >> resolve_klass_by_symbol. I think this bug should apply to AOT only if method >> resolve_klass_by_symbol is only used by AOT. > > I think that must be the case since CompilerRuntime is not present in > https://github.com/graalvm/graal-jvmci-8. > >> In my opinion, CompilerRutime in JVMCI should be consistent with SharedRuntime, where >> SharedRuntime uses the vframeStream to do the stack walk in the similar case. > > Sounds reasonable but I?m not so familiar with CompilerRuntime so will others comment on that. > > -Doug > >> On Fri, Jun 14, 2019 at 2:35 AM Doug Simon > >> wrote: >> >> Hi Tianxiao, >> >> Just for clarification, this only applies to AOT execution if I understand correctly? >> >> -Doug >> >>> On 14 Jun 2019, at 10:09, Tianxiao Gu > >>> wrote: >>> >>> Hi All, >>> >>> JVMCI may use a wrong classloader to resolve a callee class when the caller frame (obtained >>> by frame caller_frame = thread->last_frame().sender(&cbl_map);) is a compiled inlined method >>> (see CompilerRuntime::resolve_klass_helper at >>> http://hg.openjdk.java.net/jdk/jdk/file/1afe0cb93482/src/hotspot/share/jvmci/compilerRuntime.cpp#l60). >>> >>> In an inlined method, the actual, direct caller of an unresolved callee may not be the root >>> of the inline tree. The actual caller and the root of the inline tree may even have different >>> classloaders. This should be a bug and can be reproduced with the attached test case in JDK >>> 11. A patch would use vframeStream to walk the stack. >>> >>> The test case is based on AOT and uses custom classloaders. In JDK 11, we are still able to >>> use AOT with custom classloaders though it is not type-safe. (See bug report >>> https://bugs.openjdk.java.net/browse/JDK-8206963). Custom classloaders have been disabled in >>> AOT in http://hg.openjdk.java.net/jdk/jdk/rev/ccfa71bacd6f. That means this bug will not be >>> able to be reproduced in the latest JDK with the attached test case. >>> >>> Environment: >>> $ uname -a >>> Darwin US-204496-MP.local 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; >>> root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64 >>> $ java -version >>> java version "11.0.2" 2019-01-15 LTS >>> Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) >>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) >>> $ jaotc --version >>> jaotc 11.0.2+9-LTS >>> >>> >>> Reproducing Steps: >>> 1. Unzip the attached test case and run script run.sh. >>> 2. In AOT mode, we will see a message "Should not load me!", which indicates that a wrong >>> classloader is used. >>> 3. In interpreter mode, we will not see the message. >>> >>> Best regards, >>> Tianxiao >>> >>> >> >> >> >> -- >> > From vladimir.kozlov at oracle.com Fri Jun 14 18:31:40 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Jun 2019 11:31:40 -0700 Subject: [14] RFR(T) 8181837: [Graal] compiler/jvmci/SecurityRestrictionsTest.java fails with AccessControlException Message-ID: https://bugs.openjdk.java.net/browse/JDK-8181837 Testing shows that the test does not fail anymore. I removed it from Problem list: test/hotspot/jtreg/ProblemList-graal.txt @@ -42,6 +42,4 @@ compiler/graalunit/JttThreadsTest.java 8207757 generic-all -compiler/jvmci/SecurityRestrictionsTest.java 8181837 generic-all - compiler/unsafe/UnsafeGetConstantField.java 8181833 generic-all compiler/unsafe/UnsafeGetStableArrayElement.java 8181833 generic-all Thanks, Vladimir From fujie at loongson.cn Sat Jun 15 00:27:41 2019 From: fujie at loongson.cn (Jie Fu) Date: Sat, 15 Jun 2019 08:27:41 +0800 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> Message-ID: <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Thanks Bernard. I see all tests on mach5 have passed. And could I get one more review from the langtools team for the change[1]? Thanks a lot. Best regards, Jie [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 On 2019/6/15 ??1:53, B. Blaser wrote: > As shared code is affected, I've pushed it to jdk/submit to make sure > all is right on every supported systems: > > http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 > > I've added a configuration to the failing test which might be kept > when pushing to jdk/jdk providing that we get a Reviewer approval from > the langtools team for this? > > Thanks, > Bernard > > On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: >> Hi Bernard, >> >> Thank you for your review. >> And could you please sponsor it? >> >> Thanks a lot. >> Best regards, >> Jie >> >> >> On 2019/6/14 ??1:45, B. Blaser wrote: >> >>> Seems good to me too. >>> >>> Thanks, >>> Bernard >>> >>> On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: >>>> Thanks Vladimir Ivanov for your review. >>>> >>>> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ >>>>> Looks good. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From igor.ignatyev at oracle.com Sat Jun 15 02:45:26 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 14 Jun 2019 19:45:26 -0700 Subject: [14] RFR(T) 8181837: [Graal] compiler/jvmci/SecurityRestrictionsTest.java fails with AccessControlException In-Reply-To: References: Message-ID: <815658E6-B2DB-4017-A7F5-1574984CE538@oracle.com> LGTM. w/ this being a test bug, it is still eligible to be pushed in jdk/jdk13, so I'd recommend to push it there instead of jdk/jdk. Cheers, -- Igor > On Jun 14, 2019, at 11:31 AM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8181837 > > Testing shows that the test does not fail anymore. I removed it from Problem list: > > test/hotspot/jtreg/ProblemList-graal.txt > @@ -42,6 +42,4 @@ > compiler/graalunit/JttThreadsTest.java 8207757 generic-all > > -compiler/jvmci/SecurityRestrictionsTest.java 8181837 generic-all > - > compiler/unsafe/UnsafeGetConstantField.java 8181833 generic-all > compiler/unsafe/UnsafeGetStableArrayElement.java 8181833 generic-all > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Sat Jun 15 18:30:11 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 15 Jun 2019 11:30:11 -0700 Subject: [14] RFR(T) 8181837: [Graal] compiler/jvmci/SecurityRestrictionsTest.java fails with AccessControlException In-Reply-To: <815658E6-B2DB-4017-A7F5-1574984CE538@oracle.com> References: <815658E6-B2DB-4017-A7F5-1574984CE538@oracle.com> Message-ID: <629d0068-8406-ec37-e29a-7b02eee412bf@oracle.com> Thank you, Igor Okay, I will push it into jdk13. Vladimir On 6/14/19 7:45 PM, Igor Ignatyev wrote: > LGTM. w/ this being a test bug, it is still eligible to be pushed in jdk/jdk13, so I'd recommend to push it there instead of jdk/jdk. > > Cheers, > -- Igor > >> On Jun 14, 2019, at 11:31 AM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8181837 >> >> Testing shows that the test does not fail anymore. I removed it from Problem list: >> >> test/hotspot/jtreg/ProblemList-graal.txt >> @@ -42,6 +42,4 @@ >> compiler/graalunit/JttThreadsTest.java 8207757 generic-all >> >> -compiler/jvmci/SecurityRestrictionsTest.java 8181837 generic-all >> - >> compiler/unsafe/UnsafeGetConstantField.java 8181833 generic-all >> compiler/unsafe/UnsafeGetStableArrayElement.java 8181833 generic-all >> >> Thanks, >> Vladimir > From Alan.Bateman at oracle.com Sun Jun 16 08:47:51 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 16 Jun 2019 09:47:51 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> Message-ID: On 10/06/2019 11:09, Andrew Dinn wrote: > : > I have updated the Proposed Java API Changes to remove the changes to > map exception signature and force region specification. They were > covered in the prior enabling JIRAs/CSRs. > > So, the remaining two sections mention 1) the new module + package + > enum and 2) the bean counting changes. The new section 1 clarifies when > UnsupportedOperationException is thrown vs when IOException is thrown as > part of the explanation of what the new modes are for. > > I also added a paragraph to the alternatives section explaining that > Panama was and still is an alternative option and why we decided to > proceed with this model despite it being still under consideration. > I re-read the JEP, trying to put myself in the position of someone reading it for the first time in 2020. Summary section: What would you think about replacing this with a sentence that makes it clear that the JEP adds new JDK-specific file mapping modes to allow the FileChannel API create MappedByteBuffers over non-volatile memory? Goals section: I think the first paragraph could be re-worded to make it clear that the goal is to use the existing MappedByteBuffer API to access NVM. Paragraphs 2-5 split this into two sub-goals. The first suggests that it extends the MBB API but this is no longer the case. The second also hints that it adds a new API. I think these two need to be re-worded. Goal 3 and 4 are okay, although I think the 4th could be summarized as allowing mapped buffers on NVM to be tracked by the existing monitoring and management APIs. Description section It might be clearer of "Proposed Java API Changes" were renamed to "Proposed JDK-specific API changes". One other thing to mention is that I re-read the javadoc for the MBB force methods and I think we need to adjust one of the sentences in the existing (and new) methods to take account of implementation specific map modes. I've created JDK-8226203 [1] to track it. As support for implementation specific map modes is in new in Java SE 13 then it might be worth trying to get that fixed now while it is fresh in our minds. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8226203 From leelamohan.venati at gmail.com Sun Jun 16 17:38:04 2019 From: leelamohan.venati at gmail.com (Leela Mohan) Date: Sun, 16 Jun 2019 10:38:04 -0700 Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: <57037b04-866f-74d1-b9c4-ab00c29dbbef@oracle.com> References: <4C2D0A78.5020906@oracle.com> <4C2D0EC1.4090607@oracle.com> <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com> <57037b04-866f-74d1-b9c4-ab00c29dbbef@oracle.com> Message-ID: Submitted a bug report and here is the internal review ID : 9061251. On Wed, Jun 12, 2019 at 5:24 PM Tom Rodriguez wrote: > > > Leela Mohan wrote on 6/11/19 12:53 PM: > > > > > > On Mon, Jun 10, 2019 at 10:45 AM Tom Rodriguez > > wrote: > > > > > > > > Leela Mohan wrote on 6/7/19 6:39 PM: > > > This is super late reply to this review mail but i have couple of > > > questions about this change. > > > > Wow 9 years. :) > > > > > > > > Looking at the diff here : > > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/65b0c03b165d > > > > > > I think, Calling JvmtiExport::post_compiled_method_load(JvmtiEnv* > > > env,..) to JvmtiExport::post_compiled_method_load(nmethod*) > > versio is > > > possibly incorrect since, this would do callbacks to multiple > jvmti > > > environments (jvmti agents) which is unexpected. Callbacks are > > expected > > > to be called to current jvmti env which called GenerateEvents. > > > > I think you're right. Anyone listening for those events will also > get > > notified which isn't quite right. Please file a bug. It should be > > easy > > enough to fix. Factoring out the notification body of > > post_compiled_method_load into it's own method and calling that from > > generate_compiled_method_load_events would work great. > > > > > > Thanks for confirming. I don't know the formalities of filing a bug. Can > > you please pass me the instructions. Thanks. > > You can file a bug report at > https://bugreport.java.com/bugreport/start_form.do and if you want to > contribute a fix for it the general OpenJDK guidelines are at > https://openjdk.java.net/contribute. That doesn't seem to cover the > recommended process for hotspot such as the use of webrev, so maybe > someone can provide a better link. > > tom > > > > > And I was wondering what was the original lock rank ordering issue. It > > took some time for me to understand what the issue is. > > Before the change, CodeCache_lock was held when nmethod closure (i.e) > > nmethodCollector::do_nmethod(nmethod* nm) was called on each nmethod and > > closure was callingnmethod::get_and_cache_jmethod_id() which needed > > JNIGlobalHandle_lock (jmethods then were jweak handles). Lot seemed to > > have changed after this but intent of not holding CodeCache_lock around > > nmethod::get_and_cache_jmethod_id() is still valid. > > > > Thanks, > > Leela > > > > > > tom > > > > > > > > > > > > > > > > > > > > On Thu, Jul 1, 2010 at 4:07 PM Tom Rodriguez > > > > > > >> wrote: > > > > > > Thanks. Dan also reviewed this as I was developing it. > > > > > > tom > > > > > > On Jul 1, 2010, at 2:55 PM, Vladimir Kozlov wrote: > > > > > > > Thanks, Tom > > > > > > > > Changes are good to go. > > > > > > > > Vladimir > > > > > > > > On 7/1/10 2:41 PM, Tom Rodriguez wrote: > > > >> > > > >> On Jul 1, 2010, at 2:36 PM, Vladimir Kozlov wrote: > > > >> > > > >>> You did not explain your changes for cb->name(). > > > >> > > > >> That was just a clean up I've been wanting to do. There > > was a > > > time then only some of the CodeBlob subclasses had name() > methods > > > but now it's part of CodeBlob so that logic is unnecessary. > > > >> > > > >>> Why we don't lock nmethod in sweeper during CodeCache > > walk but > > > lock here? > > > >> > > > >> nmethodLocker protects you from the sweeper so the sweeper > > > doesn't need protection. > > > >> > > > >> tom > > > >> > > > >>> > > > >>> Thanks, > > > >>> Vladimir > > > >>> > > > >>> On 7/1/10 1:58 PM, Tom Rodriguez wrote: > > > >>>> http://cr.openjdk.java.net/~never/6965671/ > > > > > > > > >>>> > > > >>>> 6965671: fatal error: acquiring lock > > JNIGlobalHandle_lock/16 > > > out of order with lock CodeCache_lock/1 > > > >>>> Reviewed-by: > > > >>>> > > > >>>> The jmethodID fix created a deadlock because of lock > > ordering when > > > >>>> walking the CodeCache to generate CompiledMethodLoad > > events. > > > The walk > > > >>>> is performed with the CodeCache_lock held but we need to > > > acquire the > > > >>>> JNIGlobalHandle_lock to make a jmethodID. I considered > > > switching back > > > >>>> to collecting the methodOop instead of the jmethodID > > under the > > > lock > > > >>>> but inspection of the code made it clear that there's a > > > preexisting > > > >>>> problem with GC of the methodOops stored into the > > nmethodDesc. > > > >>>> Instead I switched to a simpler implementation that > > holds the > > > >>>> CodeCache_lock while walking the CodeCache but releases > the > > > lock to > > > >>>> actually perform the notify. This simplifies the code > > greatly > > > as well > > > >>>> as fixing the bug. > > > >>>> > > > >>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and > > > JDI_REGRESSION > > > >>>> tests. > > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fairoz.matte at oracle.com Mon Jun 17 05:47:36 2019 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Mon, 17 Jun 2019 05:47:36 +0000 (UTC) Subject: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 In-Reply-To: References: <4C2D0A78.5020906@oracle.com> <4C2D0EC1.4090607@oracle.com> <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com> <57037b04-866f-74d1-b9c4-ab00c29dbbef@oracle.com> Message-ID: <8b38c3bf-c9d3-495f-891e-14ec46052023@default> Hi Leela, ? Thanks for filing the issue. Your issue is moved to https://bugs.openjdk.java.net/browse/JDK-8226213 Yes it is an issue and lead to sending events to wrong jvmtiEnv. This has been already fixed in JDK13 with https://bugs.openjdk.java.net/browse/JDK-8222072 ? Please do let me know, if you differ in my evaluation. ? Thanks, Fairoz ? From: Leela Mohan Sent: Sunday, June 16, 2019 11:08 PM To: Tom Rodriguez Cc: Vladimir Kozlov ; hotspot compiler Subject: Re: review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 ? Submitted a bug report and here is the ?internal review ID : 9061251. ? On Wed, Jun 12, 2019 at 5:24 PM Tom Rodriguez wrote: Leela Mohan wrote on 6/11/19 12:53 PM: > > > On Mon, Jun 10, 2019 at 10:45 AM Tom Rodriguez > wrote: > > > >? ? ?Leela Mohan wrote on 6/7/19 6:39 PM: >? ? ? > This is super late reply to this review mail but i have couple of >? ? ? > questions about this change. > >? ? ?Wow 9 years.? :) > >? ? ? > >? ? ? > Looking at the diff here : >? ? ? > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/65b0c03b165d >? ? ? > >? ? ? > I think, Calling?JvmtiExport::post_compiled_method_load(JvmtiEnv* >? ? ? > env,..) to?JvmtiExport::post_compiled_method_load(nmethod*) >? ? ?versio is >? ? ? > possibly incorrect since, this would do callbacks to multiple jvmti >? ? ? > environments (jvmti agents) which is unexpected. Callbacks are >? ? ?expected >? ? ? > to be called to current jvmti env which called GenerateEvents. > >? ? ?I think you're right.? Anyone listening for those events will also get >? ? ?notified which isn't quite right.? Please file a bug.? It should be >? ? ?easy >? ? ?enough to fix.? Factoring out the notification body of >? ? ?post_compiled_method_load into it's own method and calling that from >? ? ?generate_compiled_method_load_events would work great. > > > Thanks for confirming. I don't know the formalities of filing a bug. Can > you please pass me the instructions. Thanks. You can file a bug report at https://bugreport.java.com/bugreport/start_form.do and if you want to contribute a fix for it the general OpenJDK guidelines are at https://openjdk.java.net/contribute.? That doesn't seem to cover the recommended process for hotspot such as the use of webrev, so maybe someone can provide a better link. tom > > And I was wondering what was the original lock rank ordering issue. It > took some time for me to understand what the issue is. > Before the change, CodeCache_lock was held when ?nmethod closure ?(i.e) > nmethodCollector::do_nmethod(nmethod* nm) was called on each nmethod and > closure was callingnmethod::get_and_cache_jmethod_id() which needed > JNIGlobalHandle_lock (jmethods then were jweak handles).? Lot seemed to > have changed after this but intent of not holding CodeCache_lock around > nmethod::get_and_cache_jmethod_id() is still valid. > > Thanks, > Leela > > >? ? ?tom > >? ? ? > >? ? ? > >? ? ? > >? ? ? > >? ? ? > >? ? ? > On Thu, Jul 1, 2010 at 4:07 PM Tom Rodriguez >? ? ? >? ? ? > ? ? ?>> wrote: >? ? ? > >? ? ? >? ? ?Thanks.? Dan also reviewed this as I was developing it. >? ? ? > >? ? ? >? ? ?tom >? ? ? > >? ? ? >? ? ?On Jul 1, 2010, at 2:55 PM, Vladimir Kozlov wrote: >? ? ? > >? ? ? >? ? ? > Thanks, Tom >? ? ? >? ? ? > >? ? ? >? ? ? > Changes are good to go. >? ? ? >? ? ? > >? ? ? >? ? ? > Vladimir >? ? ? >? ? ? > >? ? ? >? ? ? > On 7/1/10 2:41 PM, Tom Rodriguez wrote: >? ? ? >? ? ? >> >? ? ? >? ? ? >> On Jul 1, 2010, at 2:36 PM, Vladimir Kozlov wrote: >? ? ? >? ? ? >> >? ? ? >? ? ? >>> You did not explain your changes for cb->name(). >? ? ? >? ? ? >> >? ? ? >? ? ? >> That was just a clean up I've been wanting to do.? There >? ? ?was a >? ? ? >? ? ?time then only some of the CodeBlob subclasses had name() methods >? ? ? >? ? ?but now it's part of CodeBlob so that logic is unnecessary. >? ? ? >? ? ? >> >? ? ? >? ? ? >>> Why we don't lock nmethod in sweeper during CodeCache >? ? ?walk but >? ? ? >? ? ?lock here? >? ? ? >? ? ? >> >? ? ? >? ? ? >> nmethodLocker protects you from the sweeper so the sweeper >? ? ? >? ? ?doesn't need protection. >? ? ? >? ? ? >> >? ? ? >? ? ? >> tom >? ? ? >? ? ? >> >? ? ? >? ? ? >>> >? ? ? >? ? ? >>> Thanks, >? ? ? >? ? ? >>> Vladimir >? ? ? >? ? ? >>> >? ? ? >? ? ? >>> On 7/1/10 1:58 PM, Tom Rodriguez wrote: >? ? ? >? ? ? >>>> http://cr.openjdk.java.net/~never/6965671/ >? ? ? >? ? ? >? ? ? >? ? ? >? ? ? >>>> >? ? ? >? ? ? >>>> 6965671: fatal error: acquiring lock >? ? ?JNIGlobalHandle_lock/16 >? ? ? >? ? ?out of order with lock CodeCache_lock/1 >? ? ? >? ? ? >>>> Reviewed-by: >? ? ? >? ? ? >>>> >? ? ? >? ? ? >>>> The jmethodID fix created a deadlock because of lock >? ? ?ordering when >? ? ? >? ? ? >>>> walking the CodeCache to generate CompiledMethodLoad >? ? ?events. >? ? ? >? ? ?The walk >? ? ? >? ? ? >>>> is performed with the CodeCache_lock held but we need to >? ? ? >? ? ?acquire the >? ? ? >? ? ? >>>> JNIGlobalHandle_lock to make a jmethodID.? I considered >? ? ? >? ? ?switching back >? ? ? >? ? ? >>>> to collecting the methodOop instead of the jmethodID >? ? ?under the >? ? ? >? ? ?lock >? ? ? >? ? ? >>>> but inspection of the code made it clear that there's a >? ? ? >? ? ?preexisting >? ? ? >? ? ? >>>> problem with GC of the methodOops stored into the >? ? ?nmethodDesc. >? ? ? >? ? ? >>>> Instead I switched to a simpler implementation that >? ? ?holds the >? ? ? >? ? ? >>>> CodeCache_lock while walking the CodeCache but releases the >? ? ? >? ? ?lock to >? ? ? >? ? ? >>>> actually perform the notify.? This simplifies the code >? ? ?greatly >? ? ? >? ? ?as well >? ? ? >? ? ? >>>> as fixing the bug. >? ? ? >? ? ? >>>> >? ? ? >? ? ? >>>> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and >? ? ? >? ? ?JDI_REGRESSION >? ? ? >? ? ? >>>> tests. >? ? ? >? ? ? >> >? ? ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahul.v.raghavan at oracle.com Mon Jun 17 14:53:17 2019 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 17 Jun 2019 20:23:17 +0530 Subject: [13] RFR: 8226198: use of & instead of && in LibraryCallKit::arraycopy_restore_alloc_state Message-ID: Hi, Please review the following proposed changes for JDK 13. - http://cr.openjdk.java.net/~rraghavan/8226198/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8226198 (correctly used logical operator) [src/hotspot/share/opto/library_call.cpp] JVMState* LibraryCallKit::arraycopy_restore_alloc_state(AllocateArrayNode* alloc, int& saved_reexecute_sp) { ................ - if (!C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_intrinsic) & + if (!C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_intrinsic) && !C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_null_check)) { // Make sure there's no store between the allocation and the // arraycopy otherwise visible side effects could be rexecuted // in case of deoptimization and cause incorrect execution. ................ Confirmed no issues with testing. Thanks, Rahul From gromero at linux.vnet.ibm.com Mon Jun 17 14:53:42 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 17 Jun 2019 11:53:42 -0300 Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: References: Message-ID: <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com> Hi Ogata, Thanks a lot for backporting it. HotSpot changes look good, only the Jtreg part needs a small fix, apparently. Sorry for not mentioning it earlier, I just noticed it before pushing. Jtreg is falling with: /home/gromero/hg/upstream/jdk8u-dev/hotspot/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java:70: error: constructor OrPredicate in class OrPredicate cannot be applied to given types; new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new String[] { "sha" }, ^ required: BooleanSupplier,BooleanSupplier found: CPUSpecificPredicate reason: actual and formal argument lists differ in length /home/gromero/hg/upstream/jdk8u-dev/hotspot/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java:79: error: constructor OrPredicate in class OrPredicate cannot be applied to given types; new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new String[] { "sha" }, ^ required: BooleanSupplier,BooleanSupplier found: CPUSpecificPredicate reason: actual and formal argument lists differ in length 2 errors and I got all SHA tests passing with: diff -r 1dc0df528dbc test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java --- a/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java Mon Jun 17 09:21:58 2019 -0400 +++ b/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java Mon Jun 17 10:35:21 2019 -0400 @@ -67,18 +67,18 @@ null), new OrPredicate(new CPUSpecificPredicate("ppc64.*", new String[] { "sha" }, null), - new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new String[] { "sha" }, - null) - ))); + new CPUSpecificPredicate("ppc64le.*", new String[] { "sha" }, + null) + )); public static final BooleanSupplier SHA512_INSTRUCTION_AVAILABLE = new OrPredicate(new CPUSpecificPredicate("sparc.*", new String[] { "sha512" }, null), new OrPredicate(new CPUSpecificPredicate("ppc64.*", new String[] { "sha" }, null), - new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new String[] { "sha" }, + new CPUSpecificPredicate("ppc64le.*", new String[] { "sha" }, null) - ))); + )); public static final BooleanSupplier ANY_SHA_INSTRUCTION_AVAILABLE = new OrPredicate(IntrinsicPredicates.SHA1_INSTRUCTION_AVAILABLE, Sometimes JTwork dir can contain stale tests, so it's necessary to ensure it's cleared so new changes are effective. Could you please confirm the fix above is correct? Thank you. Best regards, Gustavo On 06/06/2019 05:45 AM, Kazunori Ogata wrote: > Hi Martin, > > Thank you for your review. > > Regards, > Ogata > > "Doerr, Martin" wrote on 2019/06/06 17:29:07: > >> From: "Doerr, Martin" >> To: Kazunori Ogata , "hotspot-compiler- >> dev at openjdk.java.net" , "jdk8u- >> dev at openjdk.java.net" >> Date: 2019/06/06 17:29 >> Subject: [EXTERNAL] RE: [8u-dev, ppc] RFR for non-clean backport of >> 8185979: PPC64: Implement SHA2 intrinsic >> >> Hi Ogata, >> >> looks correct. >> >> Best regards, >> Martin >> >> >>> -----Original Message----- >>> From: hotspot-compiler-dev >> bounces at openjdk.java.net> On Behalf Of Kazunori Ogata >>> Sent: Donnerstag, 6. Juni 2019 09:55 >>> To: hotspot-compiler-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >>> Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: >>> Implement SHA2 intrinsic >>> >>> Hi, >>> >>> May I get review of non-clean backport of 8185979: PPC64: Implement > SHA2 >>> intrinsic? >>> >>> The original patch itself can be applied cleanly (besides difference > of >>> the source directory structure). However, in jdk8u, it also needs to >>> change the arguments of make_runtime_call() based on the >>> CCallingCenventionRequiresAsLongs flag. So I made additional changes > to >>> src/share/vm/opto/library_call.cpp and runtime.cpp. >>> >>> To separate the change in the original patch and the additional > changes, I >>> made webrev incrementally. webrev.02 below only contains the changes > by >>> the original patch, and webrev.03 contains all changes including the >>> additional ones. The difference between the two webrevs is the > changes in >>> library_call.cpp and runtime.cpp. >>> >>> >>> Original bug report: >>> https://bugs.openjdk.java.net/browse/JDK-8185979 >>> >>> Webrev based on the original patch: >>> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.02/ >>> >>> Webrev of all changes: >>> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.03/ >>> >>> >>> I verified there is no degradation in jtreg (make test) results in > both >>> fastdebug and release builds. >>> >>> >>> Regards, >>> Ogata >> >> > > From tobias.hartmann at oracle.com Mon Jun 17 14:57:57 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 17 Jun 2019 16:57:57 +0200 Subject: [13] RFR: 8226198: use of & instead of && in LibraryCallKit::arraycopy_restore_alloc_state In-Reply-To: References: Message-ID: <8d8791a1-0845-4e1d-c619-3f9c69b8d211@oracle.com> Hi Rahul, looks good and trivial. Please also fix the indentation in line 4505 before pushing. Best regards, Tobias On 17.06.19 16:53, Rahul Raghavan wrote: > Hi, > > Please review the following proposed changes for JDK 13. > > - http://cr.openjdk.java.net/~rraghavan/8226198/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8226198 > (correctly used logical operator) > > [src/hotspot/share/opto/library_call.cpp] > ?JVMState* LibraryCallKit::arraycopy_restore_alloc_state(AllocateArrayNode* alloc, int& > saved_reexecute_sp) { > ................ > -??? if (!C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_intrinsic) & > +??? if (!C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_intrinsic) && > ?????????? !C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_null_check)) { > ?????? // Make sure there's no store between the allocation and the > ?????? // arraycopy otherwise visible side effects could be rexecuted > ?????? // in case of deoptimization and cause incorrect execution. > ................ > > > Confirmed no issues with testing. > > Thanks, > Rahul From vladimir.kozlov at oracle.com Mon Jun 17 15:21:46 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Jun 2019 08:21:46 -0700 Subject: [13] RFR: 8226198: use of & instead of && in LibraryCallKit::arraycopy_restore_alloc_state In-Reply-To: <8d8791a1-0845-4e1d-c619-3f9c69b8d211@oracle.com> References: <8d8791a1-0845-4e1d-c619-3f9c69b8d211@oracle.com> Message-ID: <05b4597d-6237-79d9-b5c4-28b61dafbaed@oracle.com> +1 Thanks, Vladimir On 6/17/19 7:57 AM, Tobias Hartmann wrote: > Hi Rahul, > > looks good and trivial. Please also fix the indentation in line 4505 before pushing. > > Best regards, > Tobias > > On 17.06.19 16:53, Rahul Raghavan wrote: >> Hi, >> >> Please review the following proposed changes for JDK 13. >> >> - http://cr.openjdk.java.net/~rraghavan/8226198/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8226198 >> (correctly used logical operator) >> >> [src/hotspot/share/opto/library_call.cpp] >> ?JVMState* LibraryCallKit::arraycopy_restore_alloc_state(AllocateArrayNode* alloc, int& >> saved_reexecute_sp) { >> ................ >> -??? if (!C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_intrinsic) & >> +??? if (!C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_intrinsic) && >> ?????????? !C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_null_check)) { >> ?????? // Make sure there's no store between the allocation and the >> ?????? // arraycopy otherwise visible side effects could be rexecuted >> ?????? // in case of deoptimization and cause incorrect execution. >> ................ >> >> >> Confirmed no issues with testing. >> >> Thanks, >> Rahul From daniel.daugherty at oracle.com Mon Jun 17 20:34:40 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 17 Jun 2019 16:34:40 -0400 Subject: RFR: 8225351(13): assert failed: Revoke failed, unhandled biased lock state In-Reply-To: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> References: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> Message-ID: Hi Robbin, Okay so I read this email and then the bug report. The conclusion sounds like we have an assert() that is a little too aggressive so I moved on to the webrev... I expected to find a refinement to an assert(), but that's not quite what I see... Let me re-read everything again... Hmmm... still reads the same, but let me dive into the code instead... On 6/14/19 4:03 AM, Robbin Ehn wrote: > Hi all, please review. > > When looking at a JavaThreads locks we retrieve them per frame via > it's monitors > list. How this list actually populated differs from frame type. If a > JavaThread tries to enter a new monitor a basic lock is > directly/indirectly via e.g. scope info added to the virtual monitor > list. If this lock is biased towards another > JavaThread we try to revoke that bias with a safepoint. In this case a > deopt > handshake is already in queue. The handshake is thus executed before > the revoke > safepoint. > The handshake goes over the monitors in compiled frames, find this > lock and we > hit the assert. The assert make sure we actual can revoke the lock. A > basic lock > on stack should always, if biased, be biased to current thread, with the > exception: > We may have a stack lock biased against another thread until > ObjectSynchronizer::fast_enter returns. > > To handle this exception we can safely ignore biased lock towards > other threads > in the deopt handshake. Since such locks will always be revoked before we > deopt/unpack stack. > > Code: > http://cr.openjdk.java.net/~rehn/8225351/v1/webrev/index.html First a little analysis: Our failing assert is here: src/hotspot/share/runtime/biasedLocking.cpp: BiasedLocking::Condition BiasedLocking::revoke_own_locks_in_handshake(Handle obj, TRAPS) { ? assert(mark->biased_locker() == THREAD && ???????? prototype_header->bias_epoch() == mark->bias_epoch(), "Revoke failed, unhandled biased lock state"); Since the function is called revoke_own_locks_in_handshake() it makes sense that we're checking that the locks are biased to THREAD (presumably the current thread since that's the TRAPS protocol). Just checking... Uhhhh... Looks like we can get to this code path from Deoptimization::deoptimize_frame_internal() when the current thread is the target thread *AND* when we are deoptimizing at a safepoint and the current thread is not the target thread. To my brain that makes use of the 'TRAPS' parameter "wrong", i.e., it should a "Thread* thread" parameter, but that's probably a carry over from older biased locking code. However, let's leave the topic of the "TRAPS" parameter alone for a separate investigation. It's entirely possible that my memory about the TRAPS protocol is rusty (or it has evolved since I last committed it to memory). src/hotspot/share/runtime/deoptimization.cpp ??? old L1464: ??? oop obj = (objects_to_revoke->at(i))(); ??? old L1465: BiasedLocking::revoke_own_locks_in_handshake(objects_to_revoke->at(i), thread); ??? new L1486: ??? Handle obj = objects_to_revoke->at(i); ??? new L1487: ??? markOop mark = obj->mark(); ??? new L1488: ??? if (mark->has_bias_pattern()) { ??? new L1489: ????? if (mark->biased_locker() == thread) { ??? new L1490: BiasedLocking::revoke_own_locks_in_handshake(obj, thread); ??????? So BiasedLocking::revoke_own_locks_in_handshake() has: ? ? ? ? >? markOop mark = obj->mark(); ? ? ? ? >? if (!mark->has_bias_pattern()) { ?? ? ?? > ?? return NOT_BIASED; ? ? ? ? >? } ??????? which shows that the code previously recognized that it could be ??????? called with an 'obj' parameter that wasn't biased. Perhaps it ??????? would be better to change revoke_own_locks_in_handshake() to ??????? something like: ??????? if (!mark->has_bias_pattern() || mark->biased_locker() != THREAD) { ??????? Of course, that means we would be returning "NOT_BIASED" for ??????? the case where the target object _is_ biased, but just not ??????? biased to our target thread. ??????? Another thought occurs to me: If this is happening during a handshake ??????? and not at a safepoint, then what prevents the object from passing ??????? new L1488 and L1489 in deoptimization.cpp, then we call ??????? revoke_own_locks_in_handshake() and pass "(!mark->has_bias_pattern())" ??????? only discover that the object has been rebiased to another thread at ??????? the assert? In other words, what happens if this revocation attempt ??????? loses a race with another revocation & rebias attempt? ??? L1493: ??????? #ifdef ASSERT ??? L1494: ??????? lock_in_top_frame(obj, thread); ??? L1495: ??????? #endif ??????? I think this should be: ??????????????????? DEBUG_ONLY(lock_in_top_frame(obj, thread);) ??? L1456: void lock_in_top_frame(Handle ho, JavaThread* thread) { ??? L1463: ??? if (mon_info->eliminated()) { ??? L1464: ????? continue; ??? L1465: ??? } ??? L1473: ? assert(false, "Lock not found in top frame"); ??????? I'm having problems with this sanity check. That function expects ??????? to find a BasicLock (via a MonitorInfo) that refers to the ??????? object whose bias we are trying to revoke. That check is assuming ??????? that a biased lock must be in the thread's top frame and I don't ??????? think that is a valid assumption. ??????? revoke_using_handshake() calls get_monitors_from_stack() and that ??????? function collects objects that have monitors from all vframes into ??????? 'objects_to_revoke'. ??????? Maybe I'm missing something obvious here? Dan > Issue: > https://bugs.openjdk.java.net/browse/JDK-8225351 > > Passes t1-7 > The assert code tested with local code changes to HandshakeAlot > handshake. > We then see this state where last lock can be biased towards another > thread and the thread is trying to execute revoke safepoint. > > Thanks, Robbin From igor.ignatyev at oracle.com Tue Jun 18 01:36:02 2019 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Mon, 17 Jun 2019 18:36:02 -0700 Subject: RFR(S) : 8225554 : add JFR event for uncommon trap In-Reply-To: References: Message-ID: Misha, thanks for your review. I?ll update the year before pushing, thanks for bringing this up to my attention. Compiler folks, Can someone take a look? Cheers, ? Igor > On Jun 17, 2019, at 6:02 PM, mikhailo.seledtsov at oracle.com wrote: > > Hi Igor, > > Overall looks good from procedural POV of adding JFR event. The test looks good as well. > > I am not familiar well enough with compiler domain, hence someone familiar with compiler should review this as well. > > And, perhaps Markus would like to review as well (added him to CC). > > Minor: please update Copyright year prior to push in jfrType.cpp (no need to re-post webrev for this). > > > Misha > >> On 6/11/19 11:49 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html >>> 187 lines changed: 184 ins; 0 del; 3 mod; >> Hi all, >> >> could you please review this small patch which adds jfr event for uncommon trap? >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225554 >> testing: >> - tier1 (which includes a newly added test) >> - modified version of compiler/intrinsics/klass/CastNullCheckDroppingsTest.java (see JDK-8129092[1]) >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8129092 >> >> Thanks, >> -- Igor From rahul.v.raghavan at oracle.com Tue Jun 18 04:35:45 2019 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Tue, 18 Jun 2019 10:05:45 +0530 Subject: [13] RFR: 8226198: use of & instead of && in LibraryCallKit::arraycopy_restore_alloc_state In-Reply-To: <05b4597d-6237-79d9-b5c4-28b61dafbaed@oracle.com> References: <8d8791a1-0845-4e1d-c619-3f9c69b8d211@oracle.com> <05b4597d-6237-79d9-b5c4-28b61dafbaed@oracle.com> Message-ID: >> Please also fix the indentation in line 4505 Done, pushed. Thanks Tobias, Vladimir. -Rahul On 17/06/19 8:51 PM, Vladimir Kozlov wrote: > +1 > > Thanks, > Vladimir > > On 6/17/19 7:57 AM, Tobias Hartmann wrote: >> Hi Rahul, >> >> looks good and trivial. Please also fix the indentation in line 4505 >> before pushing. >> >> Best regards, >> Tobias >> >> On 17.06.19 16:53, Rahul Raghavan wrote: >>> Hi, >>> >>> Please review the following proposed changes for JDK 13. >>> >>> - http://cr.openjdk.java.net/~rraghavan/8226198/webrev.00/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8226198 >>> (correctly used logical operator) >>> >>> [src/hotspot/share/opto/library_call.cpp] >>> ??JVMState* >>> LibraryCallKit::arraycopy_restore_alloc_state(AllocateArrayNode* >>> alloc, int& >>> saved_reexecute_sp) { >>> ................ >>> -??? if (!C->too_many_traps(trap_method, trap_bci, >>> Deoptimization::Reason_intrinsic) & >>> +??? if (!C->too_many_traps(trap_method, trap_bci, >>> Deoptimization::Reason_intrinsic) && >>> ??????????? !C->too_many_traps(trap_method, trap_bci, >>> Deoptimization::Reason_null_check)) { >>> ??????? // Make sure there's no store between the allocation and the >>> ??????? // arraycopy otherwise visible side effects could be rexecuted >>> ??????? // in case of deoptimization and cause incorrect execution. >>> ................ >>> >>> >>> Confirmed no issues with testing. >>> >>> Thanks, >>> Rahul From robbin.ehn at oracle.com Tue Jun 18 07:12:18 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 18 Jun 2019 09:12:18 +0200 Subject: RFR: 8225351(13): assert failed: Revoke failed, unhandled biased lock state In-Reply-To: References: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> Message-ID: <3b396925-c4d8-e916-537b-6943e2023911@oracle.com> Hi Dan, On 2019-06-17 22:34, Daniel D. Daugherty wrote: > Hi Robbin, > > Okay so I read this email and then the bug report. The conclusion sounds > like we have an assert() that is a little too aggressive so I moved on to > the webrev... I expected to find a refinement to an assert(), but that's > not quite what I see... > > Let me re-read everything again... > > Hmmm... still reads the same, but let me dive into the code instead... > > > On 6/14/19 4:03 AM, Robbin Ehn wrote: >> Hi all, please review. To answer: > I'm having problems with this sanity check. That function expects > to find a BasicLock (via a MonitorInfo) that refers to the > object whose bias we are trying to revoke. That check is assuming > that a biased lock must be in the thread's top frame and I don't > think that is a valid assumption. >> >> When looking at a JavaThreads locks we retrieve them per frame via it's monitors >> list. How this list actually populated differs from frame type. If a >> JavaThread tries to enter a new monitor a basic lock is directly/indirectly >> via e.g. scope info added to the virtual monitor list. The lock is taken in this current java frame, the scope desc about the lock is thus added to current frame. When fast path fails we call into to VM to get the lock. This MonitorInfo (generated from the scope desc) points to the "biased to other thread lock" must thus be in top java frame. This is the only case when a biased lock towards another thread will be on our stack, when we have not yet had time to revoke it. I don't want another case falling through the assert, if anything I'm saying would be incorrect. Unfortunate the monitor info is not guaranteed to be in order otherwise this assert would also check this is the last lock in the top frame. (at least interpreter can have them out-of-order, this is compiled frames, but I didn't feel sure about it) If this lock is biased >> towards another >> JavaThread we try to revoke that bias with a safepoint. In this case a deopt >> handshake is already in queue. The handshake is thus executed before the revoke >> safepoint. >> The handshake goes over the monitors in compiled frames, find this lock and we >> hit the assert. The assert make sure we actual can revoke the lock. A basic lock >> on stack should always, if biased, be biased to current thread, with the >> exception: >> We may have a stack lock biased against another thread until >> ObjectSynchronizer::fast_enter returns. >> >> To handle this exception we can safely ignore biased lock towards other threads >> in the deopt handshake. Since such locks will always be revoked before we >> deopt/unpack stack. >> >> Code: >> http://cr.openjdk.java.net/~rehn/8225351/v1/webrev/index.html > > First a little analysis: > > Our failing assert is here: > > src/hotspot/share/runtime/biasedLocking.cpp: > > BiasedLocking::Condition BiasedLocking::revoke_own_locks_in_handshake(Handle > obj, TRAPS) { > > ? assert(mark->biased_locker() == THREAD && > ???????? prototype_header->bias_epoch() == mark->bias_epoch(), "Revoke failed, > unhandled biased lock state"); > > Since the function is called revoke_own_locks_in_handshake() it makes > sense that we're checking that the locks are biased to THREAD (presumably > the current thread since that's the TRAPS protocol). Just checking... > Uhhhh... Looks like we can get to this code path from > Deoptimization::deoptimize_frame_internal() when the current thread is > the target thread *AND* when we are deoptimizing at a safepoint and the > current thread is not the target thread. To my brain that makes use of > the 'TRAPS' parameter "wrong", i.e., it should a "Thread* thread" > parameter, but that's probably a carry over from older biased locking > code. > > However, let's leave the topic of the "TRAPS" parameter alone for a > separate investigation. It's entirely possible that my memory about the > TRAPS protocol is rusty (or it has evolved since I last committed it to > memory). Old code, changed to "JavaThread *thread". > > > src/hotspot/share/runtime/deoptimization.cpp > ??? old L1464: ??? oop obj = (objects_to_revoke->at(i))(); > ??? old L1465: > BiasedLocking::revoke_own_locks_in_handshake(objects_to_revoke->at(i), thread); > > ??? new L1486: ??? Handle obj = objects_to_revoke->at(i); > ??? new L1487: ??? markOop mark = obj->mark(); > ??? new L1488: ??? if (mark->has_bias_pattern()) { > ??? new L1489: ????? if (mark->biased_locker() == thread) { > ??? new L1490: BiasedLocking::revoke_own_locks_in_handshake(obj, thread); > > ??????? So BiasedLocking::revoke_own_locks_in_handshake() has: > > ? ? ? ? >? markOop mark = obj->mark(); > ? ? ? ? >? if (!mark->has_bias_pattern()) { > ?? ? ?? > ?? return NOT_BIASED; > ? ? ? ? >? } > > ??????? which shows that the code previously recognized that it could be > ??????? called with an 'obj' parameter that wasn't biased. Perhaps it > ??????? would be better to change revoke_own_locks_in_handshake() to > ??????? something like: We may not call mark->biased_locker() on a non-biased lock. So this call is just to let us call biased_locker(). There is not a biased_locker_if_biased() method. > > ??????? if (!mark->has_bias_pattern() || mark->biased_locker() != THREAD) { > > ??????? Of course, that means we would be returning "NOT_BIASED" for > ??????? the case where the target object _is_ biased, but just not > ??????? biased to our target thread. Yes, I did not like that. And since the method is called 'own_locks' it didn't make sense to feed locks owned by other threads. > > ??????? Another thought occurs to me: If this is happening during a handshake > ??????? and not at a safepoint, then what prevents the object from passing > ??????? new L1488 and L1489 in deoptimization.cpp, then we call > ??????? revoke_own_locks_in_handshake() and pass "(!mark->has_bias_pattern())" > ??????? only discover that the object has been rebiased to another thread at > ??????? the assert? In other words, what happens if this revocation attempt > ??????? loses a race with another revocation & rebias attempt? In this case current thread going to revoke that bias in the safepoint happening after the handshake. Any other thread will need todo a safepoint to revoke it also. Since we are in a handshake we know there is not going to be a safepoint until we finishes the handshake. It's not possible to rebias to another thread without a safepoint when the lock is biased to another thread. > > ??? L1493: ??????? #ifdef ASSERT > ??? L1494: ??????? lock_in_top_frame(obj, thread); > ??? L1495: ??????? #endif > ??????? I think this should be: > > ??????????????????? DEBUG_ONLY(lock_in_top_frame(obj, thread);) Fixed. > > ??? L1456: void lock_in_top_frame(Handle ho, JavaThread* thread) { > ??? L1463: ??? if (mon_info->eliminated()) { > ??? L1464: ????? continue; > ??? L1465: ??? } > ??? L1473: ? assert(false, "Lock not found in top frame"); > ??????? I'm having problems with this sanity check. That function expects > ??????? to find a BasicLock (via a MonitorInfo) that refers to the > ??????? object whose bias we are trying to revoke. That check is assuming > ??????? that a biased lock must be in the thread's top frame and I don't > ??????? think that is a valid assumption. > > ??????? revoke_using_handshake() calls get_monitors_from_stack() and that > ??????? function collects objects that have monitors from all vframes into > ??????? 'objects_to_revoke'. > > ??????? Maybe I'm missing something obvious here? I hope above explains more. Thanks, Robbin > > Dan > >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8225351 >> >> Passes t1-7 >> The assert code tested with local code changes to HandshakeAlot handshake. >> We then see this state where last lock can be biased towards another thread >> and the thread is trying to execute revoke safepoint. >> >> Thanks, Robbin > From markus.gronlund at oracle.com Tue Jun 18 09:44:07 2019 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 18 Jun 2019 02:44:07 -0700 (PDT) Subject: RFR(S) : 8225554 : add JFR event for uncommon trap In-Reply-To: References: Message-ID: <688e6abd-fe01-43fd-99c0-a4b8066ddbb2@default> Hi Igor, Thank you for looking into providing this support. This work partly overlaps with something I have been working on under the following enhancement: Enh: https://bugs.openjdk.java.net/browse/JDK-8216041 I have had a patch somewhat semi-ready for some years now, please see: http://cr.openjdk.java.net/~mgronlun/8216041/ Here is what the information set could look visually by default (no structured rendering) in JDK Mission Control: http://cr.openjdk.java.net/~mgronlun/8216041/DeoptimizationEvent.jpg Maybe we should merge our work for this effort (I am interested in your test case)? I think we need to take a larger view on this, especially to see if this information could also be made understandable and maybe even useful to the end-user / developer. This is the reason I choose to use the "deoptimization" concept instead of the more internal UncomonTrap. Let's see if we together can craft a useful event here. Thanks Markus -----Original Message----- From: Igor Ignatyev Sent: den 11 juni 2019 20:49 To: hotspot-jfr-dev at openjdk.java.net; hotspot compiler Subject: RFR(S) : 8225554 : add JFR event for uncommon trap http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html > 187 lines changed: 184 ins; 0 del; 3 mod; Hi all, could you please review this small patch which adds jfr event for uncommon trap? webrev: http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8225554 testing: - tier1 (which includes a newly added test) - modified version of compiler/intrinsics/klass/CastNullCheckDroppingsTest.java (see JDK-8129092[1]) [1] https://bugs.openjdk.java.net/browse/JDK-8129092 Thanks, -- Igor From adinn at redhat.com Tue Jun 18 11:43:26 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 18 Jun 2019 12:43:26 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> Message-ID: <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> Hi Alan, Thanks for reviewing the JEP one more time. On 16/06/2019 09:47, Alan Bateman wrote: > I re-read the JEP, trying to put myself in the position of someone > reading it for the first time in 2020. > > Summary section: > > What would you think about replacing this with a sentence that makes it > clear that the JEP adds new JDK-specific file mapping modes to allow the > FileChannel API create MappedByteBuffers over non-volatile memory? I would be happy with that way of describing the behaviour change except that what you suggest doesn't mention actually making it work -- which /is/ part of the JEP. How about: "Add new JDK-specific file mapping modes, allowing the FileChannel API to be used to create MappedByteBuffers over non-volatile memory, and extend the underlying implementation to support this new use case" > Goals section: > > I think the first paragraph could be re-worded to make it clear that the > goal is to use the existing MappedByteBuffer API to access NVM. Yes indeed: "This JEP proposes that class MappedByteBuffer be reworked to support access to non-volatile memory (NVM). The only API change required is a new enumeration employed by FileChannel clients to request mapping of a file located on an NVM-backed file system rather than a conventional, file storage system. Recent changes to the MappedByteBufer API mean that it supports all the behaviours needed to allow direct memory updates and provide the durability guarantees needed for higher level, Java client libraries to implement persistent data types (e.g. block file systems, journaled logs, persistent objects, etc.). The implementations of FileChannel and MappedByteBuffer need revising to be aware of this new backing type for the mapped file." > Paragraphs 2-5 split this into two sub-goals. The first suggests that it > extends the MBB API but this is no longer the case. The second also > hints that it adds a new API. I think these two need to be re-worded. Agreed. How about this: "The primary goal of this JEP is to ensure that clients can access and update NVM from a Java program efficiently and coherently. A key element of this goal is to ensure that individual writes (or small groups of contiguous writes) to a buffer region can be committed with minimal overhead i.e. to ensure that any changes which might still be in cache are written back to memory." n.b. I snuck in the word coherence because I thought it clarified the notion of committing to memory. > Goal 3 and 4 are okay, although I think the 4th could be summarized as > allowing mapped buffers on NVM to be tracked by the existing monitoring > and management APIs. Agreed. So, renumbering accordingly, how about this: "A second, subordinate goal is to implement this commit behaviour using a restricted, JDK-internal API defined in class Unsafe, allowing it to be re-used by classes other than MappedByteBuffer that may need to commit NVM. A final, related goal is to allow buffers mapped over NVM to be tracked by the existing monitoring and management APIs." > Description section > > It might be clearer of "Proposed Java API Changes" were renamed to > "Proposed JDK-specific API changes". Agreed. > One other thing to mention is that I re-read the javadoc for the MBB > force methods and I think we need to adjust one of the sentences in the > existing (and new) methods to take account of implementation specific > map modes. I've created JDK-8226203 [1] to track it. As support for > implementation specific map modes is in new in Java SE 13 then it might > be worth trying to get that fixed now while it is fresh in our minds. Sure, I'll post an RFR with the javadoc patch as a separate step. Can it go into jdk13? or is it too late for that? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From OGATAK at jp.ibm.com Tue Jun 18 12:21:20 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 18 Jun 2019 21:21:20 +0900 Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com> References: <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com> Message-ID: Hi Gustavo, Thank you so much for spotting the error. I should have checked the test results more carefully. Thank you too for suggesting the fix. I verified it solved the problem. I updated the webrev: http://cr.openjdk.java.net/~ogatak/jdk8u_aes_be/8185979/webrev.04/ Regards, Ogata "Gustavo Romero" wrote on 2019/06/17 23:53:42: > From: "Gustavo Romero" > To: Kazunori Ogata/Japan/IBM at IBMJP > Cc: "Doerr, Martin" , "hotspot-compiler- > dev at openjdk.java.net" , "jdk8u- > dev at openjdk.java.net" > Date: 2019/06/17 23:53 > Subject: Re: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: > Implement SHA2 intrinsic > > Hi Ogata, > > Thanks a lot for backporting it. > > HotSpot changes look good, only the Jtreg part needs a small fix, apparently. > > Sorry for not mentioning it earlier, I just noticed it before pushing. > > Jtreg is falling with: > > /home/gromero/hg/upstream/jdk8u-dev/hotspot/test/compiler/testlibrary/sha/ > predicate/IntrinsicPredicates.java:70: error: constructor OrPredicate in > class OrPredicate cannot be applied to given types; > new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new > String[] { "sha" }, > ^ > required: BooleanSupplier,BooleanSupplier > found: CPUSpecificPredicate > reason: actual and formal argument lists differ in length > /home/gromero/hg/upstream/jdk8u-dev/hotspot/test/compiler/testlibrary/sha/ > predicate/IntrinsicPredicates.java:79: error: constructor OrPredicate in > class OrPredicate cannot be applied to given types; > new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new > String[] { "sha" }, > ^ > required: BooleanSupplier,BooleanSupplier > found: CPUSpecificPredicate > reason: actual and formal argument lists differ in length > 2 errors > > and I got all SHA tests passing with: > > diff -r 1dc0df528dbc test/compiler/testlibrary/sha/predicate/ > IntrinsicPredicates.java > --- a/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java > Mon Jun 17 09:21:58 2019 -0400 > +++ b/test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java > Mon Jun 17 10:35:21 2019 -0400 > @@ -67,18 +67,18 @@ > null), > new OrPredicate(new CPUSpecificPredicate("ppc64.*", new > String[] { "sha" }, > null), > - new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new > String[] { "sha" }, > - null) > - ))); > + new CPUSpecificPredicate("ppc64le.*", new > String[] { "sha" }, > + null) > + )); > > public static final BooleanSupplier SHA512_INSTRUCTION_AVAILABLE > = new OrPredicate(new CPUSpecificPredicate("sparc.*", new > String[] { "sha512" }, > null), > new OrPredicate(new CPUSpecificPredicate("ppc64.*", new > String[] { "sha" }, > null), > - new OrPredicate(new CPUSpecificPredicate("ppc64le.*", new > String[] { "sha" }, > + new CPUSpecificPredicate("ppc64le.*", new > String[] { "sha" }, > null) > - ))); > + )); > > public static final BooleanSupplier ANY_SHA_INSTRUCTION_AVAILABLE > = new OrPredicate(IntrinsicPredicates.SHA1_INSTRUCTION_AVAILABLE, > > Sometimes JTwork dir can contain stale tests, so it's necessary to ensure it's > cleared so new changes are effective. > > Could you please confirm the fix above is correct? > > Thank you. > > Best regards, > Gustavo > > > On 06/06/2019 05:45 AM, Kazunori Ogata wrote: > > Hi Martin, > > > > Thank you for your review. > > > > Regards, > > Ogata > > > > "Doerr, Martin" wrote on 2019/06/06 17:29:07: > > > >> From: "Doerr, Martin" > >> To: Kazunori Ogata , "hotspot-compiler- > >> dev at openjdk.java.net" , "jdk8u- > >> dev at openjdk.java.net" > >> Date: 2019/06/06 17:29 > >> Subject: [EXTERNAL] RE: [8u-dev, ppc] RFR for non-clean backport of > >> 8185979: PPC64: Implement SHA2 intrinsic > >> > >> Hi Ogata, > >> > >> looks correct. > >> > >> Best regards, > >> Martin > >> > >> > >>> -----Original Message----- > >>> From: hotspot-compiler-dev >>> bounces at openjdk.java.net> On Behalf Of Kazunori Ogata > >>> Sent: Donnerstag, 6. Juni 2019 09:55 > >>> To: hotspot-compiler-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > >>> Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: > >>> Implement SHA2 intrinsic > >>> > >>> Hi, > >>> > >>> May I get review of non-clean backport of 8185979: PPC64: Implement > > SHA2 > >>> intrinsic? > >>> > >>> The original patch itself can be applied cleanly (besides difference > > of > >>> the source directory structure). However, in jdk8u, it also needs to > >>> change the arguments of make_runtime_call() based on the > >>> CCallingCenventionRequiresAsLongs flag. So I made additional changes > > to > >>> src/share/vm/opto/library_call.cpp and runtime.cpp. > >>> > >>> To separate the change in the original patch and the additional > > changes, I > >>> made webrev incrementally. webrev.02 below only contains the changes > > by > >>> the original patch, and webrev.03 contains all changes including the > >>> additional ones. The difference between the two webrevs is the > > changes in > >>> library_call.cpp and runtime.cpp. > >>> > >>> > >>> Original bug report: > >>> https://bugs.openjdk.java.net/browse/JDK-8185979 > >>> > >>> Webrev based on the original patch: > >>> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.02/ > >>> > >>> Webrev of all changes: > >>> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.03/ > >>> > >>> > >>> I verified there is no degradation in jtreg (make test) results in > > both > >>> fastdebug and release builds. > >>> > >>> > >>> Regards, > >>> Ogata > >> > >> > > > > From vladimir.x.ivanov at oracle.com Tue Jun 18 14:24:22 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 18 Jun 2019 17:24:22 +0300 Subject: JMH Tests Support for JDK-8222074 In-Reply-To: <8D6F463991A1574A8A803B8DA605414F3A8D88B2@ORSMSX111.amr.corp.intel.com> References: <8D6F463991A1574A8A803B8DA605414F3A8D88B2@ORSMSX111.amr.corp.intel.com> Message-ID: > Webrev: http://cr.openjdk.java.net/~srukmannagar/JMHTests/webrev/ Some comments: 35 private static final int COUNT = 1024; I'd prefer to see a parameter (@Param) instead of hard-coded value and different input sizes to be tested (e.g., fits into L1/L2/L3, memory-bound case). 50 private Random r = new Random(); In general, it's a good practice (for diagnostic purposes) to either fix the seed or allow to specify it from command line. For example, you could introduce additional parameter (@Param seed) and randomize it when "seed == 0". In that case, it should be printed into the log, so it's possible to rerun the benchmark with the same seed. Otherwise, looks good! Best regards, Vladimir Ivanov From gromero at linux.vnet.ibm.com Tue Jun 18 14:25:15 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 18 Jun 2019 11:25:15 -0300 Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: References: <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com> Message-ID: <36140f54-5078-4238-66cd-9de912a64b88@linux.vnet.ibm.com> Hi Ogata, On 06/18/2019 09:21 AM, Kazunori Ogata wrote: > Thank you too for suggesting the fix. I verified it solved the problem. I > updated the webrev: > > http://cr.openjdk.java.net/~ogatak/jdk8u_aes_be/8185979/webrev.04/ Thanks for the updated webrev. Only a nit: we don't use tabs in spaces. You can use jcheck [0] to catch most of such "nonconformities". Pushed to jdk8u-dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c4567d28f31f Thank you. Best regards, Gustavo [0] https://openjdk.java.net/projects/code-tools/jcheck/ From mikhailo.seledtsov at oracle.com Tue Jun 18 01:02:44 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Mon, 17 Jun 2019 18:02:44 -0700 Subject: RFR(S) : 8225554 : add JFR event for uncommon trap In-Reply-To: References: Message-ID: Hi Igor, Overall looks good from procedural POV of adding JFR event. The test looks good as well. I am not familiar well enough with compiler domain, hence someone familiar with compiler should review this as well. And, perhaps Markus would like to review as well (added him to CC). ?Minor: please update Copyright year prior to push in jfrType.cpp (no need to re-post webrev for this). Misha On 6/11/19 11:49 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html >> 187 lines changed: 184 ins; 0 del; 3 mod; > Hi all, > > could you please review this small patch which adds jfr event for uncommon trap? > > webrev: http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8225554 > testing: > - tier1 (which includes a newly added test) > - modified version of compiler/intrinsics/klass/CastNullCheckDroppingsTest.java (see JDK-8129092[1]) > > [1] https://bugs.openjdk.java.net/browse/JDK-8129092 > > Thanks, > -- Igor From daniel.daugherty at oracle.com Tue Jun 18 15:46:36 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Jun 2019 11:46:36 -0400 Subject: RFR: 8225351(13): assert failed: Revoke failed, unhandled biased lock state In-Reply-To: <3b396925-c4d8-e916-537b-6943e2023911@oracle.com> References: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> <3b396925-c4d8-e916-537b-6943e2023911@oracle.com> Message-ID: <5b7ab526-46bf-db83-4292-6a5322ab6f68@oracle.com> Hi Robbin, I'm still having trouble with this. Please bear with me below... On 6/18/19 3:12 AM, Robbin Ehn wrote: > Hi Dan, > > On 2019-06-17 22:34, Daniel D. Daugherty wrote: >> Hi Robbin, >> >> Okay so I read this email and then the bug report. The conclusion sounds >> like we have an assert() that is a little too aggressive so I moved >> on to >> the webrev... I expected to find a refinement to an assert(), but that's >> not quite what I see... >> >> Let me re-read everything again... >> >> Hmmm... still reads the same, but let me dive into the code instead... >> >> >> On 6/14/19 4:03 AM, Robbin Ehn wrote: >>> Hi all, please review. > > To answer: > >????????? I'm having problems with this sanity check. That function > expects > >????????? to find a BasicLock (via a MonitorInfo) that refers to the > >????????? object whose bias we are trying to revoke. That check is > assuming > >????????? that a biased lock must be in the thread's top frame and I > don't > >????????? think that is a valid assumption. > >>> >>> When looking at a JavaThreads locks we retrieve them per frame via >>> it's monitors >>> list. How this list actually populated differs from frame type. If a >>> JavaThread tries to enter a new monitor a basic lock is >>> directly/indirectly via e.g. scope info added to the virtual monitor >>> list. > > The lock is taken in this current java frame, the scope desc about the > lock is thus added to current frame. When fast path fails we call into > to VM to get the > lock. This MonitorInfo (generated from the scope desc) points to the > "biased to > other thread lock" must thus be in top java frame. > This is the only case when a biased lock towards another thread will > be on our > stack, when we have not yet had time to revoke it. > > I don't want another case falling through the assert, if anything I'm > saying > would be incorrect. > > Unfortunate the monitor info is not guaranteed to be in order > otherwise this > assert would also check this is the last lock in the top frame. > (at least interpreter can have them out-of-order, this is compiled > frames, but I didn't feel sure about it) I attached the hs_err_pid file from Mikael's original Mach5 sighting to the bug report. Let me get oriented here by looking at the crashing stack: V? [jvm.dll+0x50bd22]? report_vm_error+0x102? (debug.cpp:264) V? [jvm.dll+0x2d553e] BiasedLocking::revoke_own_locks_in_handshake+0xfe (biasedlocking.cpp:640) ?????????????????????? Deoptimization::revoke_using_handshake() optimized out V? [jvm.dll+0x51a6f5]? Deoptimization::deopt_thread+0x1b5 (deoptimization.cpp:1518) V? [jvm.dll+0x51a960]? Deoptimization::deoptimize+0x50 (deoptimization.cpp:1500) V? [jvm.dll+0xc7bca2]? JavaThread::deoptimize_marked_methods+0xe2 (thread.cpp:2840) V? [jvm.dll+0x680f89] HandshakeThreadsOperation::do_handshake+0x189? (handshake.cpp:248) V? [jvm.dll+0x68144f]? VM_HandshakeAllThreads::doit+0x36f (handshake.cpp:193) V? [jvm.dll+0xcdf18e]? VM_Operation::evaluate+0xbe (vmoperations.cpp:71) V? [jvm.dll+0xce42a8]? VMThread::evaluate_operation+0xb8 (vmthread.cpp:406) V? [jvm.dll+0xce507f]? VMThread::loop+0x84f? (vmthread.cpp:616) V? [jvm.dll+0xce5708]? VMThread::run+0xd8? (vmthread.cpp:305) V? [jvm.dll+0xc79232]? Thread::call_run+0x192? (thread.cpp:405) V? [jvm.dll+0xad6f0e]? thread_native_entry+0x10e (os_windows.cpp:471) Okay, so deopt_thread() is called with the 'frame fr' that we are trying to deopt and it calls revoke_using_handshake() with the same 'frame fr'. revoke_using_handshake() calls? get_monitors_from_stack() passing the same 'frame fr' and populates 'objects_to_revoke'. We go thru the list of objects that need to be revoked and call revoke_own_locks_in_handshake() on each one. It is in one of the revoke_own_locks_in_handshake() calls that we fail the assertion because the object is biased towards another thread. Okay, so now I'm oriented in the code and see where the assertion fails and where you changed to code so that we don't call that code if we see that the assertion is going to fail. I'm good with that part of the fix and I didn't make that clear before. Sorry about that. For the else-branch where you added the call to the lock_in_top_frame(): L1488: ??? if (mark->has_bias_pattern()) { L1489: ????? if (mark->biased_locker() == thread) { L1492: ????? } else { L1493: ??????? #ifdef ASSERT L1494: ??????? lock_in_top_frame(obj, thread); L1495: ??????? #endif L1496: ????? } You are still in the "has_bias_pattern" if-statement so we know the object is biased. You are in the else-branch of comparing the biased locker to the target thread so you know that the object is biased to some other thread. Okay so now I'm oriented in the new checking code. The target thread has a BasicLock on its stack that refers to the object, but the object is biased to another thread so the target thread is contending on the lock which means that the frame _must be_ the top frame because the target thread is blocked. I (finally) see why the new check is okay. Maybe I'm the only reviewer that had trouble with the new check and, if so, I'm sorry about that. Please consider the following: L1492:?????? } else { ?????????????? // Biased to another thread means 'thread' is ?????????????? // contending for the lock in the top frame. ?????????????? DEBUG_ONLY(verify_BasicLock_in_top_frame(obj, thread); ???????????? } Thumbs up! Your call on whether to make more changes to this fix. Dan > > If this lock is biased >>> towards another >>> JavaThread we try to revoke that bias with a safepoint. In this case >>> a deopt >>> handshake is already in queue. The handshake is thus executed before >>> the revoke >>> safepoint. >>> The handshake goes over the monitors in compiled frames, find this >>> lock and we >>> hit the assert. The assert make sure we actual can revoke the lock. >>> A basic lock >>> on stack should always, if biased, be biased to current thread, with >>> the >>> exception: >>> We may have a stack lock biased against another thread until >>> ObjectSynchronizer::fast_enter returns. >>> >>> To handle this exception we can safely ignore biased lock towards >>> other threads >>> in the deopt handshake. Since such locks will always be revoked >>> before we >>> deopt/unpack stack. >>> >>> Code: >>> http://cr.openjdk.java.net/~rehn/8225351/v1/webrev/index.html >> >> First a little analysis: >> >> Our failing assert is here: >> >> src/hotspot/share/runtime/biasedLocking.cpp: >> >> BiasedLocking::Condition >> BiasedLocking::revoke_own_locks_in_handshake(Handle obj, TRAPS) { >> >> ?? assert(mark->biased_locker() == THREAD && >> ????????? prototype_header->bias_epoch() == mark->bias_epoch(), >> "Revoke failed, unhandled biased lock state"); >> >> Since the function is called revoke_own_locks_in_handshake() it makes >> sense that we're checking that the locks are biased to THREAD >> (presumably >> the current thread since that's the TRAPS protocol). Just checking... >> Uhhhh... Looks like we can get to this code path from >> Deoptimization::deoptimize_frame_internal() when the current thread is >> the target thread *AND* when we are deoptimizing at a safepoint and the >> current thread is not the target thread. To my brain that makes use of >> the 'TRAPS' parameter "wrong", i.e., it should a "Thread* thread" >> parameter, but that's probably a carry over from older biased locking >> code. >> >> However, let's leave the topic of the "TRAPS" parameter alone for a >> separate investigation. It's entirely possible that my memory about the >> TRAPS protocol is rusty (or it has evolved since I last committed it to >> memory). > > Old code, changed to "JavaThread *thread". > >> >> >> src/hotspot/share/runtime/deoptimization.cpp >> ???? old L1464: ??? oop obj = (objects_to_revoke->at(i))(); >> ???? old L1465: >> BiasedLocking::revoke_own_locks_in_handshake(objects_to_revoke->at(i), >> thread); >> >> ???? new L1486: ??? Handle obj = objects_to_revoke->at(i); >> ???? new L1487: ??? markOop mark = obj->mark(); >> ???? new L1488: ??? if (mark->has_bias_pattern()) { >> ???? new L1489: ????? if (mark->biased_locker() == thread) { >> ???? new L1490: BiasedLocking::revoke_own_locks_in_handshake(obj, >> thread); >> >> ???????? So BiasedLocking::revoke_own_locks_in_handshake() has: >> >> ?? ? ? ? >? markOop mark = obj->mark(); >> ?? ? ? ? >? if (!mark->has_bias_pattern()) { >> ??? ? ?? > ?? return NOT_BIASED; >> ?? ? ? ? >? } >> >> ???????? which shows that the code previously recognized that it >> could be >> ???????? called with an 'obj' parameter that wasn't biased. Perhaps it >> ???????? would be better to change revoke_own_locks_in_handshake() to >> ???????? something like: > > We may not call mark->biased_locker() on a non-biased lock. > So this call is just to let us call biased_locker(). > There is not a biased_locker_if_biased() method. > >> >> ???????? if (!mark->has_bias_pattern() || mark->biased_locker() != >> THREAD) { >> >> ???????? Of course, that means we would be returning "NOT_BIASED" for >> ???????? the case where the target object _is_ biased, but just not >> ???????? biased to our target thread. > > Yes, I did not like that. And since the method is called 'own_locks' > it didn't > make sense to feed locks owned by other threads. > >> >> ???????? Another thought occurs to me: If this is happening during a >> handshake >> ???????? and not at a safepoint, then what prevents the object from >> passing >> ???????? new L1488 and L1489 in deoptimization.cpp, then we call >> ???????? revoke_own_locks_in_handshake() and pass >> "(!mark->has_bias_pattern())" >> ???????? only discover that the object has been rebiased to another >> thread at >> ???????? the assert? In other words, what happens if this revocation >> attempt >> ???????? loses a race with another revocation & rebias attempt? > > In this case current thread going to revoke that bias in the safepoint > happening > after the handshake. Any other thread will need todo a safepoint to > revoke it > also. Since we are in a handshake we know there is not going to be a > safepoint > until we finishes the handshake. > It's not possible to rebias to another thread without a safepoint when > the lock is biased to another thread. > >> >> ???? L1493: ??????? #ifdef ASSERT >> ???? L1494: ??????? lock_in_top_frame(obj, thread); >> ???? L1495: ??????? #endif >> ???????? I think this should be: >> >> ???????????????????? DEBUG_ONLY(lock_in_top_frame(obj, thread);) > > Fixed. > >> >> ???? L1456: void lock_in_top_frame(Handle ho, JavaThread* thread) { >> ???? L1463: ??? if (mon_info->eliminated()) { >> ???? L1464: ????? continue; >> ???? L1465: ??? } >> ???? L1473: ? assert(false, "Lock not found in top frame"); >> ???????? I'm having problems with this sanity check. That function >> expects >> ???????? to find a BasicLock (via a MonitorInfo) that refers to the >> ???????? object whose bias we are trying to revoke. That check is >> assuming >> ???????? that a biased lock must be in the thread's top frame and I >> don't >> ???????? think that is a valid assumption. >> >> ???????? revoke_using_handshake() calls get_monitors_from_stack() and >> that >> ???????? function collects objects that have monitors from all >> vframes into >> ???????? 'objects_to_revoke'. >> >> ???????? Maybe I'm missing something obvious here? > > I hope above explains more. > > Thanks, Robbin > >> >> Dan >> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8225351 >>> >>> Passes t1-7 >>> The assert code tested with local code changes to HandshakeAlot >>> handshake. >>> We then see this state where last lock can be biased towards another >>> thread and the thread is trying to execute revoke safepoint. >>> >>> Thanks, Robbin >> From igor.ignatyev at oracle.com Tue Jun 18 16:28:57 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Jun 2019 09:28:57 -0700 Subject: RFR(T) [13] : 8226313 : problem list compiler/types/correctness tests Message-ID: <43663152-87EC-4F79-9C11-6D438BDAF811@oracle.com> http://cr.openjdk.java.net/~iignatyev//8226313/webrev.00/index.html > 3 lines changed: 3 ins; 0 del; 0 mod; Hi all, could you please review this trivial patch which problem-lists compiler/types/correctness tests on all platforms till 8225670 is fixed? webrev: http://cr.openjdk.java.net/~iignatyev//8226313/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8226313 Thanks, -- Igor From tobias.hartmann at oracle.com Tue Jun 18 16:36:14 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 18 Jun 2019 18:36:14 +0200 Subject: RFR(T) [13] : 8226313 : problem list compiler/types/correctness tests In-Reply-To: <43663152-87EC-4F79-9C11-6D438BDAF811@oracle.com> References: <43663152-87EC-4F79-9C11-6D438BDAF811@oracle.com> Message-ID: Hi Igor, looks good. Thanks, Tobias On 18.06.19 18:28, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8226313/webrev.00/index.html >> 3 lines changed: 3 ins; 0 del; 0 mod; > > Hi all, > > could you please review this trivial patch which problem-lists compiler/types/correctness tests on all platforms till 8225670 is fixed? > > webrev: http://cr.openjdk.java.net/~iignatyev//8226313/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8226313 > > Thanks, > -- Igor > From robbin.ehn at oracle.com Tue Jun 18 17:38:49 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 18 Jun 2019 19:38:49 +0200 Subject: RFR: 8225351(13): assert failed: Revoke failed, unhandled biased lock state In-Reply-To: <5b7ab526-46bf-db83-4292-6a5322ab6f68@oracle.com> References: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> <3b396925-c4d8-e916-537b-6943e2023911@oracle.com> <5b7ab526-46bf-db83-4292-6a5322ab6f68@oracle.com> Message-ID: Hi Dan, Far down! On 2019-06-18 17:46, Daniel D. Daugherty wrote: > Hi Robbin, > > I'm still having trouble with this. Please bear with me below... > > > On 6/18/19 3:12 AM, Robbin Ehn wrote: >> Hi Dan, >> >> On 2019-06-17 22:34, Daniel D. Daugherty wrote: >>> Hi Robbin, >>> >>> Okay so I read this email and then the bug report. The conclusion sounds >>> like we have an assert() that is a little too aggressive so I moved on to >>> the webrev... I expected to find a refinement to an assert(), but that's >>> not quite what I see... >>> >>> Let me re-read everything again... >>> >>> Hmmm... still reads the same, but let me dive into the code instead... >>> >>> >>> On 6/14/19 4:03 AM, Robbin Ehn wrote: >>>> Hi all, please review. >> >> To answer: >> >????????? I'm having problems with this sanity check. That function expects >> >????????? to find a BasicLock (via a MonitorInfo) that refers to the >> >????????? object whose bias we are trying to revoke. That check is assuming >> >????????? that a biased lock must be in the thread's top frame and I don't >> >????????? think that is a valid assumption. >> >>>> >>>> When looking at a JavaThreads locks we retrieve them per frame via it's >>>> monitors >>>> list. How this list actually populated differs from frame type. If a >>>> JavaThread tries to enter a new monitor a basic lock is directly/indirectly >>>> via e.g. scope info added to the virtual monitor list. >> >> The lock is taken in this current java frame, the scope desc about the lock is >> thus added to current frame. When fast path fails we call into to VM to get the >> lock. This MonitorInfo (generated from the scope desc) points to the "biased to >> other thread lock" must thus be in top java frame. >> This is the only case when a biased lock towards another thread will be on our >> stack, when we have not yet had time to revoke it. >> >> I don't want another case falling through the assert, if anything I'm saying >> would be incorrect. >> >> Unfortunate the monitor info is not guaranteed to be in order otherwise this >> assert would also check this is the last lock in the top frame. >> (at least interpreter can have them out-of-order, this is compiled frames, but >> I didn't feel sure about it) > > I attached the hs_err_pid file from Mikael's original Mach5 sighting > to the bug report. Let me get oriented here by looking at the crashing > stack: > > V? [jvm.dll+0x50bd22]? report_vm_error+0x102? (debug.cpp:264) > V? [jvm.dll+0x2d553e] BiasedLocking::revoke_own_locks_in_handshake+0xfe > (biasedlocking.cpp:640) > ?????????????????????? Deoptimization::revoke_using_handshake() optimized out > V? [jvm.dll+0x51a6f5]? Deoptimization::deopt_thread+0x1b5 (deoptimization.cpp:1518) > V? [jvm.dll+0x51a960]? Deoptimization::deoptimize+0x50 (deoptimization.cpp:1500) > V? [jvm.dll+0xc7bca2]? JavaThread::deoptimize_marked_methods+0xe2 (thread.cpp:2840) > V? [jvm.dll+0x680f89] HandshakeThreadsOperation::do_handshake+0x189 > (handshake.cpp:248) > V? [jvm.dll+0x68144f]? VM_HandshakeAllThreads::doit+0x36f (handshake.cpp:193) > V? [jvm.dll+0xcdf18e]? VM_Operation::evaluate+0xbe (vmoperations.cpp:71) > V? [jvm.dll+0xce42a8]? VMThread::evaluate_operation+0xb8 (vmthread.cpp:406) > V? [jvm.dll+0xce507f]? VMThread::loop+0x84f? (vmthread.cpp:616) > V? [jvm.dll+0xce5708]? VMThread::run+0xd8? (vmthread.cpp:305) > V? [jvm.dll+0xc79232]? Thread::call_run+0x192? (thread.cpp:405) > V? [jvm.dll+0xad6f0e]? thread_native_entry+0x10e (os_windows.cpp:471) > > Okay, so deopt_thread() is called with the 'frame fr' that we are trying > to deopt and it calls revoke_using_handshake() with the same 'frame fr'. > revoke_using_handshake() calls? get_monitors_from_stack() passing the > same 'frame fr' and populates 'objects_to_revoke'. We go thru the list > of objects that need to be revoked and call revoke_own_locks_in_handshake() > on each one. It is in one of the revoke_own_locks_in_handshake() calls > that we fail the assertion because the object is biased towards another > thread. > > Okay, so now I'm oriented in the code and see where the assertion fails > and where you changed to code so that we don't call that code if we see > that the assertion is going to fail. I'm good with that part of the fix > and I didn't make that clear before. Sorry about that. > > > For the else-branch where you added the call to the lock_in_top_frame(): > > L1488: ??? if (mark->has_bias_pattern()) { > L1489: ????? if (mark->biased_locker() == thread) { > > L1492: ????? } else { > L1493: ??????? #ifdef ASSERT > L1494: ??????? lock_in_top_frame(obj, thread); > L1495: ??????? #endif > L1496: ????? } > > You are still in the "has_bias_pattern" if-statement so we know the > object is biased. You are in the else-branch of comparing the biased > locker to the target thread so you know that the object is biased to > some other thread. > > Okay so now I'm oriented in the new checking code. The target thread > has a BasicLock on its stack that refers to the object, but the object > is biased to another thread so the target thread is contending on the > lock which means that the frame _must be_ the top frame because the > target thread is blocked. Yes! The VM thread is running the handshake on behalf of the target thread, which means it's either native or blocked (or suspended). > > I (finally) see why the new check is okay. Maybe I'm the only > reviewer that had trouble with the new check and, if so, I'm > sorry about that. No, this was/is very complicated to find and understand. > > Please consider the following: > > L1492:?????? } else { > ?????????????? // Biased to another thread means 'thread' is > ?????????????? // contending for the lock in the top frame. > ?????????????? DEBUG_ONLY(verify_BasicLock_in_top_frame(obj, thread); > ???????????? } > > Thumbs up! Your call on whether to make more changes to this fix. Great thanks, fixed! For the record here is the last part of the stacktrace for the JavaThread the VM thread is execution the handshake on behalf of. (Not same crash, local reprod) #0 0x00007f110137c72c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f110137c72c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f11006d9e80 in os::PlatformMonitor::wait (this=this at entry=0x7f10f801e530, millis=millis at entry=0) at /home/rehn/source/jdk/vanilla-jdk/open/src/hotspot/os/posix/os_posix.hpp:279 #2 0x00007f110063a06c in Monitor::wait (this=0x7f10f801e520, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /home/rehn/source/jdk/vanilla-jdk/open/src/hotspot/share/runtime/mutex.cpp:214 #3 0x00007f1100a92c9f in MonitorLocker::wait (timeout=0, as_suspend_equivalent=false, this=0x7f10a2ef2bd0) at /home/rehn/source/jdk/vanilla-jdk/open/src/hotspot/share/runtime/mutexLocker.hpp:261 #4 VMThread::execute (op=0x7f10a2ef2e40) at /home/rehn/source/jdk/vanilla-jdk/open/src/hotspot/share/runtime/vmThread.cpp:755 #5 0x00007f10ff96f02d in BiasedLocking::revoke_and_rebias (obj=..., attempt_rebias=attempt_rebias at entry=true, __the_thread__=__the_thread__ at entry=0x7f10f84d3000) at /home/rehn/source/jdk/vanilla-jdk/open/src/hotspot/share/runtime/biasedLocking.cpp:745 #6 0x00007f11009376d3 in ObjectSynchronizer::fast_enter (obj=obj at entry=..., lock=lock at entry=0x7f10a2ef35e8, attempt_rebias=attempt_rebias at entry=true, __the_thread__=__the_thread__ at entry=0x7f10f84d3000) at /home/rehn/source/jdk/vanilla-jdk/open/src/hotspot/share/runtime/synchronizer.cpp:271 #7 0x00007f10ffac67ac in Runtime1::monitorenter (thread=0x7f10f84d3000, obj=0x43492b1e0, lock=0x7f10a2ef35e8) at /home/rehn/source/jdk/vanilla-jdk/open/src/hotspot/share/runtime/basicLock.hpp:67 #8 0x00007f10e0adacd4 in ?? () #9 0x0000000000000000 in ?? () Thanks Dan! /Robbin > > Dan > >> >> If this lock is biased >>>> towards another >>>> JavaThread we try to revoke that bias with a safepoint. In this case a deopt >>>> handshake is already in queue. The handshake is thus executed before the revoke >>>> safepoint. >>>> The handshake goes over the monitors in compiled frames, find this lock and we >>>> hit the assert. The assert make sure we actual can revoke the lock. A basic >>>> lock >>>> on stack should always, if biased, be biased to current thread, with the >>>> exception: >>>> We may have a stack lock biased against another thread until >>>> ObjectSynchronizer::fast_enter returns. >>>> >>>> To handle this exception we can safely ignore biased lock towards other threads >>>> in the deopt handshake. Since such locks will always be revoked before we >>>> deopt/unpack stack. >>>> >>>> Code: >>>> http://cr.openjdk.java.net/~rehn/8225351/v1/webrev/index.html >>> >>> First a little analysis: >>> >>> Our failing assert is here: >>> >>> src/hotspot/share/runtime/biasedLocking.cpp: >>> >>> BiasedLocking::Condition BiasedLocking::revoke_own_locks_in_handshake(Handle >>> obj, TRAPS) { >>> >>> ?? assert(mark->biased_locker() == THREAD && >>> ????????? prototype_header->bias_epoch() == mark->bias_epoch(), "Revoke >>> failed, unhandled biased lock state"); >>> >>> Since the function is called revoke_own_locks_in_handshake() it makes >>> sense that we're checking that the locks are biased to THREAD (presumably >>> the current thread since that's the TRAPS protocol). Just checking... >>> Uhhhh... Looks like we can get to this code path from >>> Deoptimization::deoptimize_frame_internal() when the current thread is >>> the target thread *AND* when we are deoptimizing at a safepoint and the >>> current thread is not the target thread. To my brain that makes use of >>> the 'TRAPS' parameter "wrong", i.e., it should a "Thread* thread" >>> parameter, but that's probably a carry over from older biased locking >>> code. >>> >>> However, let's leave the topic of the "TRAPS" parameter alone for a >>> separate investigation. It's entirely possible that my memory about the >>> TRAPS protocol is rusty (or it has evolved since I last committed it to >>> memory). >> >> Old code, changed to "JavaThread *thread". >> >>> >>> >>> src/hotspot/share/runtime/deoptimization.cpp >>> ???? old L1464: ??? oop obj = (objects_to_revoke->at(i))(); >>> ???? old L1465: >>> BiasedLocking::revoke_own_locks_in_handshake(objects_to_revoke->at(i), thread); >>> >>> ???? new L1486: ??? Handle obj = objects_to_revoke->at(i); >>> ???? new L1487: ??? markOop mark = obj->mark(); >>> ???? new L1488: ??? if (mark->has_bias_pattern()) { >>> ???? new L1489: ????? if (mark->biased_locker() == thread) { >>> ???? new L1490: BiasedLocking::revoke_own_locks_in_handshake(obj, thread); >>> >>> ???????? So BiasedLocking::revoke_own_locks_in_handshake() has: >>> >>> ?? ? ? ? >? markOop mark = obj->mark(); >>> ?? ? ? ? >? if (!mark->has_bias_pattern()) { >>> ??? ? ?? > ?? return NOT_BIASED; >>> ?? ? ? ? >? } >>> >>> ???????? which shows that the code previously recognized that it could be >>> ???????? called with an 'obj' parameter that wasn't biased. Perhaps it >>> ???????? would be better to change revoke_own_locks_in_handshake() to >>> ???????? something like: >> >> We may not call mark->biased_locker() on a non-biased lock. >> So this call is just to let us call biased_locker(). >> There is not a biased_locker_if_biased() method. >> >>> >>> ???????? if (!mark->has_bias_pattern() || mark->biased_locker() != THREAD) { >>> >>> ???????? Of course, that means we would be returning "NOT_BIASED" for >>> ???????? the case where the target object _is_ biased, but just not >>> ???????? biased to our target thread. >> >> Yes, I did not like that. And since the method is called 'own_locks' it didn't >> make sense to feed locks owned by other threads. >> >>> >>> ???????? Another thought occurs to me: If this is happening during a handshake >>> ???????? and not at a safepoint, then what prevents the object from passing >>> ???????? new L1488 and L1489 in deoptimization.cpp, then we call >>> ???????? revoke_own_locks_in_handshake() and pass "(!mark->has_bias_pattern())" >>> ???????? only discover that the object has been rebiased to another thread at >>> ???????? the assert? In other words, what happens if this revocation attempt >>> ???????? loses a race with another revocation & rebias attempt? >> >> In this case current thread going to revoke that bias in the safepoint happening >> after the handshake. Any other thread will need todo a safepoint to revoke it >> also. Since we are in a handshake we know there is not going to be a safepoint >> until we finishes the handshake. >> It's not possible to rebias to another thread without a safepoint when the >> lock is biased to another thread. >> >>> >>> ???? L1493: ??????? #ifdef ASSERT >>> ???? L1494: ??????? lock_in_top_frame(obj, thread); >>> ???? L1495: ??????? #endif >>> ???????? I think this should be: >>> >>> ???????????????????? DEBUG_ONLY(lock_in_top_frame(obj, thread);) >> >> Fixed. >> >>> >>> ???? L1456: void lock_in_top_frame(Handle ho, JavaThread* thread) { >>> ???? L1463: ??? if (mon_info->eliminated()) { >>> ???? L1464: ????? continue; >>> ???? L1465: ??? } >>> ???? L1473: ? assert(false, "Lock not found in top frame"); >>> ???????? I'm having problems with this sanity check. That function expects >>> ???????? to find a BasicLock (via a MonitorInfo) that refers to the >>> ???????? object whose bias we are trying to revoke. That check is assuming >>> ???????? that a biased lock must be in the thread's top frame and I don't >>> ???????? think that is a valid assumption. >>> >>> ???????? revoke_using_handshake() calls get_monitors_from_stack() and that >>> ???????? function collects objects that have monitors from all vframes into >>> ???????? 'objects_to_revoke'. >>> >>> ???????? Maybe I'm missing something obvious here? >> >> I hope above explains more. >> >> Thanks, Robbin >> >>> >>> Dan >>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8225351 >>>> >>>> Passes t1-7 >>>> The assert code tested with local code changes to HandshakeAlot handshake. >>>> We then see this state where last lock can be biased towards another thread >>>> and the thread is trying to execute revoke safepoint. >>>> >>>> Thanks, Robbin >>> From dean.long at oracle.com Tue Jun 18 17:52:06 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 18 Jun 2019 10:52:06 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails Message-ID: https://bugs.openjdk.java.net/browse/JDK-8225369 http://cr.openjdk.java.net/~dlong/8225369/webrev/ This test triggers a race, which can result in different resolved values of the MethodHandle constant.? The VM chooses a winner and stores that value in the constant pool cache, however Graal is not checking the cache.? The trivial fix is to use the proper API that goes through the cache. dl From vladimir.kozlov at oracle.com Tue Jun 18 18:01:49 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Jun 2019 11:01:49 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: References: Message-ID: <1e976016-9592-065b-5c03-2be382013d00@oracle.com> Looks good. Thanks, Vladimir On 6/18/19 10:52 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8225369 > http://cr.openjdk.java.net/~dlong/8225369/webrev/ > > This test triggers a race, which can result in different resolved values of the MethodHandle constant.? The VM chooses a > winner and stores that value in the constant pool cache, however Graal is not checking the cache.? The trivial fix is to > use the proper API that goes through the cache. > > dl From dean.long at oracle.com Tue Jun 18 18:03:12 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 18 Jun 2019 11:03:12 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: <1e976016-9592-065b-5c03-2be382013d00@oracle.com> References: <1e976016-9592-065b-5c03-2be382013d00@oracle.com> Message-ID: <4c63c0ab-1b83-11c2-3c14-8614e7c27b43@oracle.com> Thanks Vladimir. dl On 6/18/19 11:01 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/18/19 10:52 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8225369 >> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >> >> This test triggers a race, which can result in different resolved >> values of the MethodHandle constant.? The VM chooses a winner and >> stores that value in the constant pool cache, however Graal is not >> checking the cache.? The trivial fix is to use the proper API that >> goes through the cache. >> >> dl From igor.ignatyev at oracle.com Tue Jun 18 18:42:02 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Jun 2019 11:42:02 -0700 Subject: RFR(T) [13] : 8226313 : problem list compiler/types/correctness tests In-Reply-To: References: <43663152-87EC-4F79-9C11-6D438BDAF811@oracle.com> Message-ID: Hi Tobias, thanks for your review. it looks like jtreg doesn't merge lines of problem list, so I had to change the patch: > diff -r 922a4a554807 test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt Tue Jun 18 10:00:35 2019 +0530 > +++ b/test/hotspot/jtreg/ProblemList.txt Tue Jun 18 11:40:18 2019 -0700 > @@ -49,8 +49,8 @@ > compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 generic-all > compiler/tiered/LevelTransitionTest.java 8067651 generic-all > > -compiler/types/correctness/CorrectnessTest.java 8225620 solaris-sparcv9 > -compiler/types/correctness/OffTest.java 8225620 solaris-sparcv9 > +compiler/types/correctness/CorrectnessTest.java 8225670,8225620 generic-all,solaris-sparcv9 > +compiler/types/correctness/OffTest.java 8225670,8225620 generic-all,solaris-sparcv9 > > compiler/c2/Test6852078.java 8194310 generic-all > compiler/c2/Test8004741.java 8214904 generic-all PS I'll file an RFE for jtreg to support multiple entries for one test in a problem list. Thanks, -- Igor > On Jun 18, 2019, at 9:36 AM, Tobias Hartmann wrote: > > Hi Igor, > > looks good. > > Thanks, > Tobias > > On 18.06.19 18:28, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8226313/webrev.00/index.html >>> 3 lines changed: 3 ins; 0 del; 0 mod; >> >> Hi all, >> >> could you please review this trivial patch which problem-lists compiler/types/correctness tests on all platforms till 8225670 is fixed? >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8226313/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8226313 >> >> Thanks, >> -- Igor >> From patricio.chilano.mateo at oracle.com Tue Jun 18 20:49:52 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Tue, 18 Jun 2019 16:49:52 -0400 Subject: RFR: 8225351(13): assert failed: Revoke failed, unhandled biased lock state In-Reply-To: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> References: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> Message-ID: <7ae58eac-7533-d043-6836-d24c4c1bb72b@oracle.com> Hi Robbin, Change looks good to me! One question though. In deoptimization.cpp there is method fetch_unroll_info_helper() which calls create_vframeArray() which will eventually call vframeArrayElement::fill_in(). That method tries to get the monitors from the stack and has the following assertion: assert(monitor->owner() == NULL || (!monitor->owner()->is_unlocked() && !monitor->owner()->has_bias_pattern()), "object must be null or locked, and unbiased"); So it is expecting that the locked monitors are not biased anymore. Do you know exactly when fetch_unroll_info_helper() would be called during this deoptimization phase? There is a comment "fetch_unroll_info() is called at the beginning of the deoptimization handler" but no sure what that means exactly since it is expecting monitors to be revoked already. My question is whether we could hit that assert later on if we avoid trying to revoke these biased objects that actually belong to somebody else. One scenario could be as follows: 1) JT1 calls BiasedLocking::revoke_and_rebias() for object X, finds X is biased toward JT2 and requests a revocation using a bulk rebias operation. The attempt_rebias flag is true, so this call comes from interpreter/c1/c2 where JT1 was trying to lock this object. 2) VMThread executes a deoptimization operation (present in the VM queue before the bulk rebias operation was added). VMThread executes the handshake on behalf of JT1, who is blocked, finds monitor associated with object X in the stack but skips revocation since JT1 is not the owner. JT2 executes the handshake too but does not revoke bias of X because it is not currently using that lock (it's not in its stack). 3) VMThread executes the bulk rebias operation for objects of class X that JT1 requested. Object? X is not currently in the stack of JT2 and so the bias for object X expires and is not valid anymore. Since bulk_revoke_or_rebias_at_safepoint() was called with a value of attempt_rebias_of_object=true the object will be rebiased towards JT1. 4) JT1 unblocks, and tries to execute fetch_unroll_info_helper() (?) But not sure if that last step is possible. Thanks Robbin! Patricio On 6/14/19 4:03 AM, Robbin Ehn wrote: > Hi all, please review. > > When looking at a JavaThreads locks we retrieve them per frame via > it's monitors > list. How this list actually populated differs from frame type. If a > JavaThread tries to enter a new monitor a basic lock is > directly/indirectly via e.g. scope info added to the virtual monitor > list. If this lock is biased towards another > JavaThread we try to revoke that bias with a safepoint. In this case a > deopt > handshake is already in queue. The handshake is thus executed before > the revoke > safepoint. > The handshake goes over the monitors in compiled frames, find this > lock and we > hit the assert. The assert make sure we actual can revoke the lock. A > basic lock > on stack should always, if biased, be biased to current thread, with the > exception: > We may have a stack lock biased against another thread until > ObjectSynchronizer::fast_enter returns. > > To handle this exception we can safely ignore biased lock towards > other threads > in the deopt handshake. Since such locks will always be revoked before we > deopt/unpack stack. > > Code: > http://cr.openjdk.java.net/~rehn/8225351/v1/webrev/index.html > Issue: > https://bugs.openjdk.java.net/browse/JDK-8225351 > > Passes t1-7 > The assert code tested with local code changes to HandshakeAlot > handshake. > We then see this state where last lock can be biased towards another > thread and the thread is trying to execute revoke safepoint. > > Thanks, Robbin From igor.ignatyev at oracle.com Tue Jun 18 23:19:51 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Jun 2019 16:19:51 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists Message-ID: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html > 30 lines changed: 0 ins; 20 del; 10 mod; Hi all, because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 Thanks, -- Igor From ekaterina.pavlova at oracle.com Tue Jun 18 23:33:18 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 18 Jun 2019 16:33:18 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: > +vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java 8204506,8195635 macosx-all,generic-all Doesn't generic-all imply macosx-all as well? Otherwise looks good. thanks, -katya On 6/18/19 4:19 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >> 30 lines changed: 0 ins; 20 del; 10 mod; > > Hi all, > > because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 > webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 > > Thanks, > -- Igor > From vladimir.kozlov at oracle.com Wed Jun 19 00:09:08 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Jun 2019 17:09:08 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: How we endup wiith 3 copies of the same test and bug in jdk/ProblemList-graal.txt? We should have some verification to avoid that. Changes are good except what Katya pointed. Thanks, Vladimir On 6/18/19 4:19 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >> 30 lines changed: 0 ins; 20 del; 10 mod; > > Hi all, > > because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 > webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Wed Jun 19 00:10:57 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Jun 2019 17:10:57 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: it is, I however decided to leave macosx-all in an attempt to show that 8204506 affects only that platform. -- Igor > On Jun 18, 2019, at 4:33 PM, Ekaterina Pavlova wrote: > >> +vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java 8204506,8195635 macosx-all,generic-all > > Doesn't generic-all imply macosx-all as well? > > Otherwise looks good. > > thanks, > -katya > > > On 6/18/19 4:19 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >>> 30 lines changed: 0 ins; 20 del; 10 mod; >> Hi all, >> because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 >> webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 >> Thanks, >> -- Igor > From igor.ignatyev at oracle.com Wed Jun 19 00:16:28 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Jun 2019 17:16:28 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: I have no idea how/why we listed com/sun/jdi/ tests thrice. verification of problem lists is discussed in CODETOOLS-7902481, I'd appreciate if you provide your input there. I have answered Katya's comment in a separate thread. -- Igor > On Jun 18, 2019, at 5:09 PM, Vladimir Kozlov wrote: > > How we endup wiith 3 copies of the same test and bug in jdk/ProblemList-graal.txt? > We should have some verification to avoid that. > > Changes are good except what Katya pointed. > > Thanks, > Vladimir > > On 6/18/19 4:19 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >>> 30 lines changed: 0 ins; 20 del; 10 mod; >> Hi all, >> because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 >> webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 >> Thanks, >> -- Igor From vladimir.kozlov at oracle.com Wed Jun 19 00:18:11 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Jun 2019 17:18:11 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: On 6/18/19 5:16 PM, Igor Ignatyev wrote: > I have no idea how/why we listed com/sun/jdi/ tests thrice. verification of problem lists is discussed in CODETOOLS-7902481, I'd appreciate if you provide your input there. > > I have answered Katya's comment in a separate thread. Okay. Thanks, Vladimir > > -- Igor > >> On Jun 18, 2019, at 5:09 PM, Vladimir Kozlov wrote: >> >> How we endup wiith 3 copies of the same test and bug in jdk/ProblemList-graal.txt? >> We should have some verification to avoid that. >> >> Changes are good except what Katya pointed. >> >> Thanks, >> Vladimir >> >> On 6/18/19 4:19 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >>>> 30 lines changed: 0 ins; 20 del; 10 mod; >>> Hi all, >>> because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 >>> Thanks, >>> -- Igor > From OGATAK at jp.ibm.com Wed Jun 19 06:52:49 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 19 Jun 2019 15:52:49 +0900 Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: <36140f54-5078-4238-66cd-9de912a64b88@linux.vnet.ibm.com> References: <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com> <36140f54-5078-4238-66cd-9de912a64b88@linux.vnet.ibm.com> Message-ID: Hi Gustavo, Thank you for sponsoring the patch and fixing the use of tab characters. Sorry for bothering you with my blunders... I've set up jcheck in my hg. Regards, Ogata "Gustavo Romero" wrote on 2019/06/18 23:25:15: > From: "Gustavo Romero" > To: Kazunori Ogata/Japan/IBM at IBMJP > Cc: "hotspot-compiler-dev at openjdk.java.net" dev at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" dev at openjdk.java.net>, "Doerr, Martin" > Date: 2019/06/18 23:25 > Subject: Re: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: > Implement SHA2 intrinsic > > Hi Ogata, > > On 06/18/2019 09:21 AM, Kazunori Ogata wrote: > > Thank you too for suggesting the fix. I verified it solved the problem. I > > updated the webrev: > > > > http://cr.openjdk.java.net/~ogatak/jdk8u_aes_be/8185979/webrev.04/ > > Thanks for the updated webrev. Only a nit: we don't use tabs in spaces. > > You can use jcheck [0] to catch most of such "nonconformities". > > Pushed to jdk8u-dev: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c4567d28f31f > > Thank you. > > Best regards, > Gustavo > > [0] https://openjdk.java.net/projects/code-tools/jcheck/ From tobias.hartmann at oracle.com Wed Jun 19 08:37:13 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 19 Jun 2019 10:37:13 +0200 Subject: [13] RFR(T): 8226381: ProblemList java/lang/reflect/PublicMethods/PublicMethodsTest.java Message-ID: <4e91790f-ea0b-e4c5-03f6-6b3dcd6f330f@oracle.com> Hi, please review the following patch that ProblemLists the test until 8226309 is fixed: https://bugs.openjdk.java.net/browse/JDK-8226381 http://cr.openjdk.java.net/~thartmann/8226381/webrev.00/ Thanks, Tobias From tobias.hartmann at oracle.com Wed Jun 19 08:39:51 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 19 Jun 2019 10:39:51 +0200 Subject: [13] RFR(T): 8226382: ProblemList java/lang/constant/MethodTypeDescTest.java Message-ID: Hi, please review the following patch that ProblemLists the test until 8225349 is fixed: https://bugs.openjdk.java.net/browse/JDK-8226382 http://cr.openjdk.java.net/~thartmann/8226382/webrev.00/ Thanks, Tobias From igor.ignatyev at oracle.com Wed Jun 19 10:19:17 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 19 Jun 2019 03:19:17 -0700 Subject: [13] RFR(T): 8226382: ProblemList java/lang/constant/MethodTypeDescTest.java In-Reply-To: References: Message-ID: <14F122CD-49BD-47E6-9C1E-C851CB71425A@oracle.com> Hi Tobias, LGTM Thanks, -- Igor > On Jun 19, 2019, at 1:39 AM, Tobias Hartmann wrote: > > Hi, > > please review the following patch that ProblemLists the test until 8225349 is fixed: > https://bugs.openjdk.java.net/browse/JDK-8226382 > http://cr.openjdk.java.net/~thartmann/8226382/webrev.00/ > > Thanks, > Tobias From igor.ignatyev at oracle.com Wed Jun 19 10:19:54 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 19 Jun 2019 03:19:54 -0700 Subject: [13] RFR(T): 8226381: ProblemList java/lang/reflect/PublicMethods/PublicMethodsTest.java In-Reply-To: <4e91790f-ea0b-e4c5-03f6-6b3dcd6f330f@oracle.com> References: <4e91790f-ea0b-e4c5-03f6-6b3dcd6f330f@oracle.com> Message-ID: <0B1CA506-48A0-45E0-94D4-11911FC089A5@oracle.com> Hi Tobias, LGTM Thanks, -- Igor > On Jun 19, 2019, at 1:37 AM, Tobias Hartmann wrote: > > Hi, > > please review the following patch that ProblemLists the test until 8226309 is fixed: > https://bugs.openjdk.java.net/browse/JDK-8226381 > http://cr.openjdk.java.net/~thartmann/8226381/webrev.00/ > > Thanks, > Tobias From tobias.hartmann at oracle.com Wed Jun 19 10:21:30 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 19 Jun 2019 12:21:30 +0200 Subject: [13] RFR(T): 8226382: ProblemList java/lang/constant/MethodTypeDescTest.java In-Reply-To: <14F122CD-49BD-47E6-9C1E-C851CB71425A@oracle.com> References: <14F122CD-49BD-47E6-9C1E-C851CB71425A@oracle.com> Message-ID: <8a4395ef-5ec0-9da6-7b32-2b9614e8a6d5@oracle.com> Thanks Igor! Best regards, Tobias On 19.06.19 12:19, Igor Ignatyev wrote: > Hi Tobias, > > LGTM > > Thanks, > -- Igor > >> On Jun 19, 2019, at 1:39 AM, Tobias Hartmann wrote: >> >> Hi, >> >> please review the following patch that ProblemLists the test until 8225349 is fixed: >> https://bugs.openjdk.java.net/browse/JDK-8226382 >> http://cr.openjdk.java.net/~thartmann/8226382/webrev.00/ >> >> Thanks, >> Tobias > From tobias.hartmann at oracle.com Wed Jun 19 10:21:41 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 19 Jun 2019 12:21:41 +0200 Subject: [13] RFR(T): 8226381: ProblemList java/lang/reflect/PublicMethods/PublicMethodsTest.java In-Reply-To: <0B1CA506-48A0-45E0-94D4-11911FC089A5@oracle.com> References: <4e91790f-ea0b-e4c5-03f6-6b3dcd6f330f@oracle.com> <0B1CA506-48A0-45E0-94D4-11911FC089A5@oracle.com> Message-ID: Thanks Igor! Best regards, Tobias On 19.06.19 12:19, Igor Ignatyev wrote: > Hi Tobias, > > LGTM > > Thanks, > -- Igor > >> On Jun 19, 2019, at 1:37 AM, Tobias Hartmann wrote: >> >> Hi, >> >> please review the following patch that ProblemLists the test until 8226309 is fixed: >> https://bugs.openjdk.java.net/browse/JDK-8226381 >> http://cr.openjdk.java.net/~thartmann/8226381/webrev.00/ >> >> Thanks, >> Tobias > From nils.eliasson at oracle.com Wed Jun 19 12:49:36 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 19 Jun 2019 14:49:36 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers Message-ID: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> Hi, This patch fixes a minor problem in process_users_of_allocation in macro.cpp. When removing the initalize node we must handle the case that there is a gc barrier in the control flow. This patch strengthens the requirement that the zgc loadbarrier node has a control out when expanding. Bug: https://bugs.openjdk.java.net/browse/JDK-8226287 Webrev: http://cr.openjdk.java.net/~neliasso/8226287/webrev.01/ Please review, Regards, Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Wed Jun 19 13:36:10 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 19 Jun 2019 10:36:10 -0300 Subject: [8u-dev, ppc] RFR for non-clean backport of 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: References: <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com> <36140f54-5078-4238-66cd-9de912a64b88@linux.vnet.ibm.com> Message-ID: On 06/19/2019 03:52 AM, Kazunori Ogata wrote: > Hi Gustavo, > > Thank you for sponsoring the patch and fixing the use of tab characters. > Sorry for bothering you with my blunders... I've set up jcheck in my hg. No bothering at all! I'm glad to help, Ogata. Cheers, Gustavo From eric.caspole at oracle.com Wed Jun 19 15:35:07 2019 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 19 Jun 2019 11:35:07 -0400 Subject: JMH Tests Support for JDK-8222074 In-Reply-To: <8D6F463991A1574A8A803B8DA605414F3A8D88B2@ORSMSX111.amr.corp.intel.com> References: <8D6F463991A1574A8A803B8DA605414F3A8D88B2@ORSMSX111.amr.corp.intel.com> Message-ID: Hi Shravya, I agree with Vladimir's comment from yesterday, otherwise looks good. I tested it on new hardware it shows the new optimizations' benefit. Thanks, Eric On 6/13/19 19:57, Rukmannagari, Shravya wrote: > Hi All, > > I have added JMH test support for the following vector operations: > > 1) Absolute for all data types > 2) Shifts for byte data types > 3) Shift right arithmetic for long data type > 4) Byte multiply > 5) Negate for float/double > > Please find the webrev below and let me know if you have any comments or > suggestions. > > Webrev: http://cr.openjdk.java.net/~srukmannagar/JMHTests/webrev/ > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8225626 > > Thanks, > > Shravya. > From vladimir.kozlov at oracle.com Wed Jun 19 15:37:25 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Jun 2019 08:37:25 -0700 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> Message-ID: Looks good but run all testing before push. Thanks Vladimir > On Jun 19, 2019, at 5:49 AM, Nils Eliasson wrote: > > Hi, > > This patch fixes a minor problem in process_users_of_allocation in macro.cpp. When removing the initalize node we must handle the case that there is a gc barrier in the control flow. > > This patch strengthens the requirement that the zgc loadbarrier node has a control out when expanding. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226287 > > Webrev: http://cr.openjdk.java.net/~neliasso/8226287/webrev.01/ > > Please review, > > Regards, > > Nils > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Jun 19 21:53:31 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Jun 2019 14:53:31 -0700 Subject: [13] RFR(S) 8223794: applications/kitchensink/Kitchensink.java crash bad oop with Graal Message-ID: <5b66250d-a294-0d0f-e938-6a98dfe8c9ca@oracle.com> http://cr.openjdk.java.net/~kvn/8223794/webrev.03/ https://bugs.openjdk.java.net/browse/JDK-8223794 Big thanks to Erik O. for pointing the possible cause of this problem and fix suggestion: "The JVMCINMethodData::get_nmethod_mirror() function in JVMCI is used to read the nmethod mirror from the nmethod oop section. However, the nmethod oops are weak, and not kept alive by GC. Yet strong references are created to the returned oop in places, without going through a keep-alive barrier. This could result in creating edges to dead oops, resulting in a crash eventually." I added nmethod::oop_at_phantom() method to notify GC that oop should be kept alive. It is used in JVMCI where it needs strong reference. I originally named new method and argument 'strong' but Erik pointed that: "Maybe s/strong/phantom/g for the new method name and parameters. Otherwise it is the other way around, i.e. when strong is true in the current webrev01, we actually read it as a phantom oop ref, and conversely when strong is false, we do read it as a strong oop ref. That is a bit confusing." Running Kitchensink without fix triggers the failure intermittently. With the fix I did not see the failure. Thanks, Vladimir From dean.long at oracle.com Wed Jun 19 23:16:53 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 19 Jun 2019 16:16:53 -0700 Subject: [13] RFR(S) 8223794: applications/kitchensink/Kitchensink.java crash bad oop with Graal In-Reply-To: <5b66250d-a294-0d0f-e938-6a98dfe8c9ca@oracle.com> References: <5b66250d-a294-0d0f-e938-6a98dfe8c9ca@oracle.com> Message-ID: Looks good. dl On 6/19/19 2:53 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8223794/webrev.03/ > https://bugs.openjdk.java.net/browse/JDK-8223794 > > Big thanks to Erik O. for pointing the possible cause of this problem > and fix suggestion: > > "The JVMCINMethodData::get_nmethod_mirror() function in JVMCI is used > to read the nmethod mirror from the nmethod oop section. However, the > nmethod oops are weak, and not kept alive by GC. Yet strong references > are created to the returned oop in places, without going through a > keep-alive barrier. This could result in creating edges to dead oops, > resulting in a crash eventually." > > I added nmethod::oop_at_phantom() method to notify GC that oop should > be kept alive. It is used in JVMCI where it needs strong reference. I > originally named new method and argument 'strong' but Erik pointed that: > > "Maybe s/strong/phantom/g for the new method name and parameters. > Otherwise it is the other way around, i.e. when strong is true in the > current webrev01, we actually read it as a phantom oop ref, and > conversely when strong is false, we do read it as a strong oop ref. > That is a bit confusing." > > Running Kitchensink without fix triggers the failure intermittently. > With the fix I did not see the failure. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Jun 19 23:55:52 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Jun 2019 16:55:52 -0700 Subject: [13] RFR(S) 8223794: applications/kitchensink/Kitchensink.java crash bad oop with Graal In-Reply-To: References: <5b66250d-a294-0d0f-e938-6a98dfe8c9ca@oracle.com> Message-ID: <2f3c3153-d1de-043a-2aa1-e27dc6b5aa8d@oracle.com> Thank you, Dean Vladimir K On 6/19/19 4:16 PM, dean.long at oracle.com wrote: > Looks good. > > dl > > On 6/19/19 2:53 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8223794/webrev.03/ >> https://bugs.openjdk.java.net/browse/JDK-8223794 >> >> Big thanks to Erik O. for pointing the possible cause of this problem and fix suggestion: >> >> "The JVMCINMethodData::get_nmethod_mirror() function in JVMCI is used to read the nmethod mirror from the nmethod oop >> section. However, the nmethod oops are weak, and not kept alive by GC. Yet strong references are created to the >> returned oop in places, without going through a keep-alive barrier. This could result in creating edges to dead oops, >> resulting in a crash eventually." >> >> I added nmethod::oop_at_phantom() method to notify GC that oop should be kept alive. It is used in JVMCI where it >> needs strong reference. I originally named new method and argument 'strong' but Erik pointed that: >> >> "Maybe s/strong/phantom/g for the new method name and parameters. Otherwise it is the other way around, i.e. when >> strong is true in the current webrev01, we actually read it as a phantom oop ref, and conversely when strong is false, >> we do read it as a strong oop ref. That is a bit confusing." >> >> Running Kitchensink without fix triggers the failure intermittently. With the fix I did not see the failure. >> >> Thanks, >> Vladimir > From jesper.wilhelmsson at oracle.com Wed Jun 19 23:58:24 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 20 Jun 2019 01:58:24 +0200 Subject: RFR: JDK-8223807 - Update Graal In-Reply-To: <10CB23D8-7D4F-40C5-AD54-B2E8E3E71C52@oracle.com> References: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com> <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com> <67f36d91-1936-2937-756f-ae75f8bf03ae@oracle.com> <10CB23D8-7D4F-40C5-AD54-B2E8E3E71C52@oracle.com> Message-ID: <9B10D185-8D4B-484B-92A2-D7B8F5F2326F@oracle.com> Due to the delay in getting this snapshot pushed, and the fact that we see test failures with this snapshot that has been fixed / is being fixed in Graal, this integration is withdrawn. We will start a new integration with a more recent graal snapshot as soon as the known issues are resolved. /Jesper > On 11 Jun 2019, at 04:45, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > I re-applied the patch for JDK-8209626 and restarted the testing. > /Jesper > >> On 10 Jun 2019, at 18:05, Vladimir Kozlov wrote: >> >> These changes incorrectly reversed part of 8209626 changes in jaotc/MetadataBuilder.java file causing these AOT failures. >> >> Vladimir >> >> On 6/10/19 8:49 AM, Vladimir Kozlov wrote: >>> There are a lot of crashes in compiler/aot and gc/stress/gcbasher tests. We need to resolve them. >>> It seems you don't need to apply `overwritten` changes - Update changes has them. >>> Thanks, >>> Vladimir >>> On 6/7/19 5:58 PM, jesper.wilhelmsson at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>> Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433 >>>> >>>> JBS duplicates fixed by this integration: >>>> https://bugs.openjdk.java.net/browse/JDK-8223924 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223807 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/ >>>> >>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>> >>>> Thanks, >>>> /Jesper >>>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From igor.ignatyev at oracle.com Thu Jun 20 00:20:01 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 19 Jun 2019 17:20:01 -0700 Subject: RFR(S) : 8225554 : add JFR event for uncommon trap In-Reply-To: <688e6abd-fe01-43fd-99c0-a4b8066ddbb2@default> References: <688e6abd-fe01-43fd-99c0-a4b8066ddbb2@default> Message-ID: <8B759742-CAD0-4811-93C6-18466203A070@oracle.com> Hi Markus, I definitely support the idea of making the event as helpful for end-users as possible; and having information about the uncommon trap "location" (method, line-number, bci) seems to be very useful. I don't think that 'instruction' field is helpful though b/c w/o seeing the rest of method code it can't be really used to understand what/why happened. what do you think? regarding the name, although I don't think this even can be used by people w/o understanding some level of hotspot internals, they at least need to understand what a bit cryptic reasons and actions mean, "Deoptimization" sounds good to me. please let me know how you can proceed further here, I can update my patch to rename even and include location info, or I can just withdraw my patch in favor of yours (that's if you plan to finish work on it in near future and it won't be left for other few years :) ) Thanks, -- Igor > On Jun 18, 2019, at 2:44 AM, Markus Gronlund wrote: > > Hi Igor, > > Thank you for looking into providing this support. > > This work partly overlaps with something I have been working on under the following enhancement: > > Enh: https://bugs.openjdk.java.net/browse/JDK-8216041 > > I have had a patch somewhat semi-ready for some years now, please see: > http://cr.openjdk.java.net/~mgronlun/8216041/ > > Here is what the information set could look visually by default (no structured rendering) in JDK Mission Control: > http://cr.openjdk.java.net/~mgronlun/8216041/DeoptimizationEvent.jpg > > Maybe we should merge our work for this effort (I am interested in your test case)? > > I think we need to take a larger view on this, especially to see if this information could also be made understandable and maybe even useful to the end-user / developer. > > This is the reason I choose to use the "deoptimization" concept instead of the more internal UncomonTrap. > > Let's see if we together can craft a useful event here. > > Thanks > Markus > > -----Original Message----- > From: Igor Ignatyev > Sent: den 11 juni 2019 20:49 > To: hotspot-jfr-dev at openjdk.java.net; hotspot compiler > Subject: RFR(S) : 8225554 : add JFR event for uncommon trap > > http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html >> 187 lines changed: 184 ins; 0 del; 3 mod; > > Hi all, > > could you please review this small patch which adds jfr event for uncommon trap? > > webrev: http://cr.openjdk.java.net/~iignatyev//8225554/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8225554 > testing: > - tier1 (which includes a newly added test) > - modified version of compiler/intrinsics/klass/CastNullCheckDroppingsTest.java (see JDK-8129092[1]) > > [1] https://bugs.openjdk.java.net/browse/JDK-8129092 > > Thanks, > -- Igor From igor.ignatyev at oracle.com Thu Jun 20 00:32:58 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 19 Jun 2019 17:32:58 -0700 Subject: RFR(M) [14] : 8225654 : rework vmTestbase/jit/graph Message-ID: <3A418E88-2FBA-4253-A249-C30A6DC1C5CC@oracle.com> http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html > 2536 lines changed: 354 ins; 787 del; 1395 mod; Hi all, could you please review the patch which reworks vmTestbase/jit/graph to make them more readable and reliable? that includes the following changes: - as none of our cgt* tests used more than 1 thread, all test execution is now done in main thread; - use exception instead of System::exit to signal problems; - replaced ExecDriver execution mode w/ regular 'main'; - make the tests to use reproducible random from jdk.test.lib.Utils ; - close filereader opened by jit/graph/Globals ; - moved tests to one directory; - mark a test as skipped if OOME or SOE happens - editorial changes such as adding { }, fixing typos, removing commented code, etc. webrev: http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8225654 testing: test/hotspot/jtreg/vmTestbase/jit/graph on linux-x64,windows-x64,macosx-x64,solaris-sparcv9 Thanks, -- Igor From vladimir.kozlov at oracle.com Thu Jun 20 01:03:57 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Jun 2019 18:03:57 -0700 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal Message-ID: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8185139 For Graal to work we have to give Graal module all permissions which is specified in default policy [1]. Unfortunately this cause problem for Graal running tests which overwrite default policy. I discussed this with Mandy and she suggested that such tests should also check default policy. I implemented her suggestion. Note, this is not only Graal problem. There were already similar fixes before [2]. I also updated Graal's problem list. Several tests were left on problem list (with different bug id) because they would not run with Java Graal (for example, they use --limit-modules flag which prevents loading Graal module). We will enable such tests again when libgraal is supported. I ran testing which execute these tests with Graal. It shows only known problems which are not related to these changes. Thanks, Vladimir [1] http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 [2] https://bugs.openjdk.java.net/browse/JDK-8189291 From ekaterina.pavlova at oracle.com Thu Jun 20 01:12:19 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 19 Jun 2019 18:12:19 -0700 Subject: RFR(T/XXS) [13] : 8225684: [AOT] Problem list serviceability/sa tests failed with AOTed java.base Message-ID: <8a1a580e-a782-8a7e-7e3d-e0ae9411d70d@oracle.com> Hi, please review this tiny patch which adds serviceability/sa tests into AOT specific problem list. JBS: https://bugs.openjdk.java.net/browse/JDK-8225684 webrev: http://cr.openjdk.java.net/~epavlova//8225684/webrev.00/index.html thanks, -katya From vladimir.kozlov at oracle.com Thu Jun 20 01:16:16 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Jun 2019 18:16:16 -0700 Subject: RFR(T/XXS) [13] : 8225684: [AOT] Problem list serviceability/sa tests failed with AOTed java.base In-Reply-To: <8a1a580e-a782-8a7e-7e3d-e0ae9411d70d@oracle.com> References: <8a1a580e-a782-8a7e-7e3d-e0ae9411d70d@oracle.com> Message-ID: <8c03137d-0537-1788-a50e-0a531697d9ff@oracle.com> Looks good. I assume testing scripts will process this new list. Thanks, Vladimir On 6/19/19 6:12 PM, Ekaterina Pavlova wrote: > Hi, > > please review this tiny patch which adds serviceability/sa tests into AOT specific problem list. > > ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8225684 > ? webrev: http://cr.openjdk.java.net/~epavlova//8225684/webrev.00/index.html > > thanks, > -katya > From ekaterina.pavlova at oracle.com Thu Jun 20 01:27:14 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 19 Jun 2019 18:27:14 -0700 Subject: RFR(T/XXS) [13] : 8225684: [AOT] Problem list serviceability/sa tests failed with AOTed java.base In-Reply-To: <8c03137d-0537-1788-a50e-0a531697d9ff@oracle.com> References: <8a1a580e-a782-8a7e-7e3d-e0ae9411d70d@oracle.com> <8c03137d-0537-1788-a50e-0a531697d9ff@oracle.com> Message-ID: <323127fc-f8ed-c679-1428-c56860afb0ea@oracle.com> On 6/19/19 6:16 PM, Vladimir Kozlov wrote: > Looks good. > > I assume testing scripts will process this new list. yes, thanks for prompt review! -katya > Thanks, > Vladimir > > On 6/19/19 6:12 PM, Ekaterina Pavlova wrote: >> Hi, >> >> please review this tiny patch which adds serviceability/sa tests into AOT specific problem list. >> >> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8225684 >> ?? webrev: http://cr.openjdk.java.net/~epavlova//8225684/webrev.00/index.html >> >> thanks, >> -katya >> From david.holmes at oracle.com Thu Jun 20 04:03:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Jun 2019 21:03:28 -0700 Subject: RFR: 8225351(13): assert failed: Revoke failed, unhandled biased lock state In-Reply-To: <5b7ab526-46bf-db83-4292-6a5322ab6f68@oracle.com> References: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> <3b396925-c4d8-e916-537b-6943e2023911@oracle.com> <5b7ab526-46bf-db83-4292-6a5322ab6f68@oracle.com> Message-ID: Hi Dan, > Maybe I'm the only reviewer that had trouble with the new check and, > if so, I'm sorry about that. To this point you are the only reviewer and this potential reviewer was waiting to see how this discussion resolved :) Now I have something to base my review on - tomorrow (sorry Robbin, still lagging way behind after my travels.) Cheers, David On 18/06/2019 1:46 am, Daniel D. Daugherty wrote: > Hi Robbin, > > I'm still having trouble with this. Please bear with me below... > > > On 6/18/19 3:12 AM, Robbin Ehn wrote: >> Hi Dan, >> >> On 2019-06-17 22:34, Daniel D. Daugherty wrote: >>> Hi Robbin, >>> >>> Okay so I read this email and then the bug report. The conclusion sounds >>> like we have an assert() that is a little too aggressive so I moved >>> on to >>> the webrev... I expected to find a refinement to an assert(), but that's >>> not quite what I see... >>> >>> Let me re-read everything again... >>> >>> Hmmm... still reads the same, but let me dive into the code instead... >>> >>> >>> On 6/14/19 4:03 AM, Robbin Ehn wrote: >>>> Hi all, please review. >> >> To answer: >> >????????? I'm having problems with this sanity check. That function >> expects >> >????????? to find a BasicLock (via a MonitorInfo) that refers to the >> >????????? object whose bias we are trying to revoke. That check is >> assuming >> >????????? that a biased lock must be in the thread's top frame and I >> don't >> >????????? think that is a valid assumption. >> >>>> >>>> When looking at a JavaThreads locks we retrieve them per frame via >>>> it's monitors >>>> list. How this list actually populated differs from frame type. If a >>>> JavaThread tries to enter a new monitor a basic lock is >>>> directly/indirectly via e.g. scope info added to the virtual monitor >>>> list. >> >> The lock is taken in this current java frame, the scope desc about the >> lock is thus added to current frame. When fast path fails we call into >> to VM to get the >> lock. This MonitorInfo (generated from the scope desc) points to the >> "biased to >> other thread lock" must thus be in top java frame. >> This is the only case when a biased lock towards another thread will >> be on our >> stack, when we have not yet had time to revoke it. >> >> I don't want another case falling through the assert, if anything I'm >> saying >> would be incorrect. >> >> Unfortunate the monitor info is not guaranteed to be in order >> otherwise this >> assert would also check this is the last lock in the top frame. >> (at least interpreter can have them out-of-order, this is compiled >> frames, but I didn't feel sure about it) > > I attached the hs_err_pid file from Mikael's original Mach5 sighting > to the bug report. Let me get oriented here by looking at the crashing > stack: > > V? [jvm.dll+0x50bd22]? report_vm_error+0x102? (debug.cpp:264) > V? [jvm.dll+0x2d553e] BiasedLocking::revoke_own_locks_in_handshake+0xfe > (biasedlocking.cpp:640) > ?????????????????????? Deoptimization::revoke_using_handshake() > optimized out > V? [jvm.dll+0x51a6f5]? Deoptimization::deopt_thread+0x1b5 > (deoptimization.cpp:1518) > V? [jvm.dll+0x51a960]? Deoptimization::deoptimize+0x50 > (deoptimization.cpp:1500) > V? [jvm.dll+0xc7bca2]? JavaThread::deoptimize_marked_methods+0xe2 > (thread.cpp:2840) > V? [jvm.dll+0x680f89] HandshakeThreadsOperation::do_handshake+0x189 > (handshake.cpp:248) > V? [jvm.dll+0x68144f]? VM_HandshakeAllThreads::doit+0x36f > (handshake.cpp:193) > V? [jvm.dll+0xcdf18e]? VM_Operation::evaluate+0xbe (vmoperations.cpp:71) > V? [jvm.dll+0xce42a8]? VMThread::evaluate_operation+0xb8 (vmthread.cpp:406) > V? [jvm.dll+0xce507f]? VMThread::loop+0x84f? (vmthread.cpp:616) > V? [jvm.dll+0xce5708]? VMThread::run+0xd8? (vmthread.cpp:305) > V? [jvm.dll+0xc79232]? Thread::call_run+0x192? (thread.cpp:405) > V? [jvm.dll+0xad6f0e]? thread_native_entry+0x10e (os_windows.cpp:471) > > Okay, so deopt_thread() is called with the 'frame fr' that we are trying > to deopt and it calls revoke_using_handshake() with the same 'frame fr'. > revoke_using_handshake() calls? get_monitors_from_stack() passing the > same 'frame fr' and populates 'objects_to_revoke'. We go thru the list > of objects that need to be revoked and call revoke_own_locks_in_handshake() > on each one. It is in one of the revoke_own_locks_in_handshake() calls > that we fail the assertion because the object is biased towards another > thread. > > Okay, so now I'm oriented in the code and see where the assertion fails > and where you changed to code so that we don't call that code if we see > that the assertion is going to fail. I'm good with that part of the fix > and I didn't make that clear before. Sorry about that. > > > For the else-branch where you added the call to the lock_in_top_frame(): > > L1488: ??? if (mark->has_bias_pattern()) { > L1489: ????? if (mark->biased_locker() == thread) { > > L1492: ????? } else { > L1493: ??????? #ifdef ASSERT > L1494: ??????? lock_in_top_frame(obj, thread); > L1495: ??????? #endif > L1496: ????? } > > You are still in the "has_bias_pattern" if-statement so we know the > object is biased. You are in the else-branch of comparing the biased > locker to the target thread so you know that the object is biased to > some other thread. > > Okay so now I'm oriented in the new checking code. The target thread > has a BasicLock on its stack that refers to the object, but the object > is biased to another thread so the target thread is contending on the > lock which means that the frame _must be_ the top frame because the > target thread is blocked. > > I (finally) see why the new check is okay. Maybe I'm the only > reviewer that had trouble with the new check and, if so, I'm > sorry about that. > > Please consider the following: > > L1492:?????? } else { > ?????????????? // Biased to another thread means 'thread' is > ?????????????? // contending for the lock in the top frame. > ?????????????? DEBUG_ONLY(verify_BasicLock_in_top_frame(obj, thread); > ???????????? } > > Thumbs up! Your call on whether to make more changes to this fix. > > Dan > >> >> If this lock is biased >>>> towards another >>>> JavaThread we try to revoke that bias with a safepoint. In this case >>>> a deopt >>>> handshake is already in queue. The handshake is thus executed before >>>> the revoke >>>> safepoint. >>>> The handshake goes over the monitors in compiled frames, find this >>>> lock and we >>>> hit the assert. The assert make sure we actual can revoke the lock. >>>> A basic lock >>>> on stack should always, if biased, be biased to current thread, with >>>> the >>>> exception: >>>> We may have a stack lock biased against another thread until >>>> ObjectSynchronizer::fast_enter returns. >>>> >>>> To handle this exception we can safely ignore biased lock towards >>>> other threads >>>> in the deopt handshake. Since such locks will always be revoked >>>> before we >>>> deopt/unpack stack. >>>> >>>> Code: >>>> http://cr.openjdk.java.net/~rehn/8225351/v1/webrev/index.html >>> >>> First a little analysis: >>> >>> Our failing assert is here: >>> >>> src/hotspot/share/runtime/biasedLocking.cpp: >>> >>> BiasedLocking::Condition >>> BiasedLocking::revoke_own_locks_in_handshake(Handle obj, TRAPS) { >>> >>> ?? assert(mark->biased_locker() == THREAD && >>> ????????? prototype_header->bias_epoch() == mark->bias_epoch(), >>> "Revoke failed, unhandled biased lock state"); >>> >>> Since the function is called revoke_own_locks_in_handshake() it makes >>> sense that we're checking that the locks are biased to THREAD >>> (presumably >>> the current thread since that's the TRAPS protocol). Just checking... >>> Uhhhh... Looks like we can get to this code path from >>> Deoptimization::deoptimize_frame_internal() when the current thread is >>> the target thread *AND* when we are deoptimizing at a safepoint and the >>> current thread is not the target thread. To my brain that makes use of >>> the 'TRAPS' parameter "wrong", i.e., it should a "Thread* thread" >>> parameter, but that's probably a carry over from older biased locking >>> code. >>> >>> However, let's leave the topic of the "TRAPS" parameter alone for a >>> separate investigation. It's entirely possible that my memory about the >>> TRAPS protocol is rusty (or it has evolved since I last committed it to >>> memory). >> >> Old code, changed to "JavaThread *thread". >> >>> >>> >>> src/hotspot/share/runtime/deoptimization.cpp >>> ???? old L1464: ??? oop obj = (objects_to_revoke->at(i))(); >>> ???? old L1465: >>> BiasedLocking::revoke_own_locks_in_handshake(objects_to_revoke->at(i), thread); >>> >>> >>> ???? new L1486: ??? Handle obj = objects_to_revoke->at(i); >>> ???? new L1487: ??? markOop mark = obj->mark(); >>> ???? new L1488: ??? if (mark->has_bias_pattern()) { >>> ???? new L1489: ????? if (mark->biased_locker() == thread) { >>> ???? new L1490: BiasedLocking::revoke_own_locks_in_handshake(obj, >>> thread); >>> >>> ???????? So BiasedLocking::revoke_own_locks_in_handshake() has: >>> >>> ?? ? ? ? >? markOop mark = obj->mark(); >>> ?? ? ? ? >? if (!mark->has_bias_pattern()) { >>> ??? ? ?? > ?? return NOT_BIASED; >>> ?? ? ? ? >? } >>> >>> ???????? which shows that the code previously recognized that it >>> could be >>> ???????? called with an 'obj' parameter that wasn't biased. Perhaps it >>> ???????? would be better to change revoke_own_locks_in_handshake() to >>> ???????? something like: >> >> We may not call mark->biased_locker() on a non-biased lock. >> So this call is just to let us call biased_locker(). >> There is not a biased_locker_if_biased() method. >> >>> >>> ???????? if (!mark->has_bias_pattern() || mark->biased_locker() != >>> THREAD) { >>> >>> ???????? Of course, that means we would be returning "NOT_BIASED" for >>> ???????? the case where the target object _is_ biased, but just not >>> ???????? biased to our target thread. >> >> Yes, I did not like that. And since the method is called 'own_locks' >> it didn't >> make sense to feed locks owned by other threads. >> >>> >>> ???????? Another thought occurs to me: If this is happening during a >>> handshake >>> ???????? and not at a safepoint, then what prevents the object from >>> passing >>> ???????? new L1488 and L1489 in deoptimization.cpp, then we call >>> ???????? revoke_own_locks_in_handshake() and pass >>> "(!mark->has_bias_pattern())" >>> ???????? only discover that the object has been rebiased to another >>> thread at >>> ???????? the assert? In other words, what happens if this revocation >>> attempt >>> ???????? loses a race with another revocation & rebias attempt? >> >> In this case current thread going to revoke that bias in the safepoint >> happening >> after the handshake. Any other thread will need todo a safepoint to >> revoke it >> also. Since we are in a handshake we know there is not going to be a >> safepoint >> until we finishes the handshake. >> It's not possible to rebias to another thread without a safepoint when >> the lock is biased to another thread. >> >>> >>> ???? L1493: ??????? #ifdef ASSERT >>> ???? L1494: ??????? lock_in_top_frame(obj, thread); >>> ???? L1495: ??????? #endif >>> ???????? I think this should be: >>> >>> ???????????????????? DEBUG_ONLY(lock_in_top_frame(obj, thread);) >> >> Fixed. >> >>> >>> ???? L1456: void lock_in_top_frame(Handle ho, JavaThread* thread) { >>> ???? L1463: ??? if (mon_info->eliminated()) { >>> ???? L1464: ????? continue; >>> ???? L1465: ??? } >>> ???? L1473: ? assert(false, "Lock not found in top frame"); >>> ???????? I'm having problems with this sanity check. That function >>> expects >>> ???????? to find a BasicLock (via a MonitorInfo) that refers to the >>> ???????? object whose bias we are trying to revoke. That check is >>> assuming >>> ???????? that a biased lock must be in the thread's top frame and I >>> don't >>> ???????? think that is a valid assumption. >>> >>> ???????? revoke_using_handshake() calls get_monitors_from_stack() and >>> that >>> ???????? function collects objects that have monitors from all >>> vframes into >>> ???????? 'objects_to_revoke'. >>> >>> ???????? Maybe I'm missing something obvious here? >> >> I hope above explains more. >> >> Thanks, Robbin >> >>> >>> Dan >>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8225351 >>>> >>>> Passes t1-7 >>>> The assert code tested with local code changes to HandshakeAlot >>>> handshake. >>>> We then see this state where last lock can be biased towards another >>>> thread and the thread is trying to execute revoke safepoint. >>>> >>>> Thanks, Robbin >>> From erik.osterlund at oracle.com Thu Jun 20 05:22:21 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 20 Jun 2019 07:22:21 +0200 Subject: [13] RFR(S) 8223794: applications/kitchensink/Kitchensink.java crash bad oop with Graal In-Reply-To: <5b66250d-a294-0d0f-e938-6a98dfe8c9ca@oracle.com> References: <5b66250d-a294-0d0f-e938-6a98dfe8c9ca@oracle.com> Message-ID: <2F79DBA9-2AC2-415D-B9F8-3718BC9B159D@oracle.com> Hi Vladimir, Looks good. Thanks, /Erik > On 19 Jun 2019, at 23:53, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8223794/webrev.03/ > https://bugs.openjdk.java.net/browse/JDK-8223794 > > Big thanks to Erik O. for pointing the possible cause of this problem and fix suggestion: > > "The JVMCINMethodData::get_nmethod_mirror() function in JVMCI is used to read the nmethod mirror from the nmethod oop section. However, the nmethod oops are weak, and not kept alive by GC. Yet strong references are created to the returned oop in places, without going through a keep-alive barrier. This could result in creating edges to dead oops, resulting in a crash eventually." > > I added nmethod::oop_at_phantom() method to notify GC that oop should be kept alive. It is used in JVMCI where it needs strong reference. I originally named new method and argument 'strong' but Erik pointed that: > > "Maybe s/strong/phantom/g for the new method name and parameters. Otherwise it is the other way around, i.e. when strong is true in the current webrev01, we actually read it as a phantom oop ref, and conversely when strong is false, we do read it as a strong oop ref. That is a bit confusing." > > Running Kitchensink without fix triggers the failure intermittently. With the fix I did not see the failure. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Jun 20 05:35:44 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Jun 2019 22:35:44 -0700 Subject: [13] RFR(S) 8223794: applications/kitchensink/Kitchensink.java crash bad oop with Graal In-Reply-To: <2F79DBA9-2AC2-415D-B9F8-3718BC9B159D@oracle.com> References: <5b66250d-a294-0d0f-e938-6a98dfe8c9ca@oracle.com> <2F79DBA9-2AC2-415D-B9F8-3718BC9B159D@oracle.com> Message-ID: <9FD85E12-785D-4F69-A405-3841EBAC3B1D@oracle.com> Thank you, Erik Vladimir > On Jun 19, 2019, at 10:22 PM, Erik Osterlund wrote: > > Hi Vladimir, > > Looks good. > > Thanks, > /Erik > >> On 19 Jun 2019, at 23:53, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8223794/webrev.03/ >> https://bugs.openjdk.java.net/browse/JDK-8223794 >> >> Big thanks to Erik O. for pointing the possible cause of this problem and fix suggestion: >> >> "The JVMCINMethodData::get_nmethod_mirror() function in JVMCI is used to read the nmethod mirror from the nmethod oop section. However, the nmethod oops are weak, and not kept alive by GC. Yet strong references are created to the returned oop in places, without going through a keep-alive barrier. This could result in creating edges to dead oops, resulting in a crash eventually." >> >> I added nmethod::oop_at_phantom() method to notify GC that oop should be kept alive. It is used in JVMCI where it needs strong reference. I originally named new method and argument 'strong' but Erik pointed that: >> >> "Maybe s/strong/phantom/g for the new method name and parameters. Otherwise it is the other way around, i.e. when strong is true in the current webrev01, we actually read it as a phantom oop ref, and conversely when strong is false, we do read it as a strong oop ref. That is a bit confusing." >> >> Running Kitchensink without fix triggers the failure intermittently. With the fix I did not see the failure. >> >> Thanks, >> Vladimir > From mandy.chung at oracle.com Thu Jun 20 06:23:06 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Jun 2019 23:23:06 -0700 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> Message-ID: <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> Hi Vladimir, Indeed these are test issues that the tests will need to grant permissions to jdk.internal.vm.compiler as the default policy grants. Thanks for going extra miles to fix the tests. My suggestion may be a bit general.? What I intend to say the custom security policy should extend the default policy unless it intentionally excludes configuring permissions for specific modules.? I review the the patch but the test doesn't clearly tell what the test intends to do w.r.t. security configuration. We should avoid inadvertently granting permissions that the test expects to disallow.? A better solution is to limit granting permissions just for `jdk.internal.vm.compiler` module rather than all. Attached is ModulePolicy class that allows you to get the Policy for a specific module. It can be put in the test library that these tests can use them. So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and implies method will call the returned ModulePolicy if present. test/lib/jdk/test/lib/security is one existing testlibrary for security related stuff.? You can consider putting ModulePolicy.java there. This is one idea. Mandy On 6/19/19 6:03 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8185139 > > For Graal to work we have to give Graal module all permissions which > is specified in default policy [1]. > Unfortunately this cause problem for Graal running tests which > overwrite default policy. > > I discussed this with Mandy and she suggested that such tests should > also check default policy. I implemented her suggestion. Note, this is > not only Graal problem. There were already similar fixes before [2]. > > I also updated Graal's problem list. Several tests were left on > problem list (with different bug id) because they would not run with > Java Graal (for example, they use --limit-modules flag which prevents > loading Graal module). We will enable such tests again when libgraal > is supported. > > I ran testing which execute these tests with Graal. It shows only > known problems which are not related to these changes. > > Thanks, > Vladimir > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 > [2] https://bugs.openjdk.java.net/browse/JDK-8189291 -------------- next part -------------- import java.lang.module.*; import java.net.*; import java.util.HashMap; import java.util.Map; import java.util.Optional; import java.util.function.Function; import java.util.stream.*; import java.security.*; public class ModulePolicy extends Policy { private static final Policy DEFAULT_POLICY = Policy.getPolicy(); private static final Map modulePolicies = ModuleLayer.boot() .configuration().modules().stream() .map(rm -> new ModulePolicy(rm)) .collect(Collectors.toMap(ModulePolicy::name, Function.identity())); public static Optional get(String name) { return Optional.ofNullable(modulePolicies.get(name)); } final String name; final URL codeSourceUrl; final PermissionCollection permissions; private ModulePolicy(ResolvedModule rm) { URL url = createURL(rm.reference().location().orElseThrow()); CodeSource cs = new CodeSource(url, (CodeSigner[]) null); this.name = rm.name(); this.codeSourceUrl = url; this.permissions = DEFAULT_POLICY.getPermissions(cs); } public String name() { return name; } private URL createURL(URI uri) { URL url = null; try { url = uri.toURL(); } catch (MalformedURLException | IllegalArgumentException e) { } return url; } @Override public PermissionCollection getPermissions(CodeSource cs) { return codeSourceUrl.equals(cs.getLocation()) ? permissions : new Permissions(); } @Override public boolean implies(ProtectionDomain domain, Permission perm) { return permissions.implies(perm); } } From robbin.ehn at oracle.com Thu Jun 20 07:15:23 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 20 Jun 2019 09:15:23 +0200 Subject: RFR: 8225351(13): assert failed: Revoke failed, unhandled biased lock state In-Reply-To: <7ae58eac-7533-d043-6836-d24c4c1bb72b@oracle.com> References: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> <7ae58eac-7533-d043-6836-d24c4c1bb72b@oracle.com> Message-ID: <4327d72a-f0bb-d4f5-7ddf-a5cd978bde94@oracle.com> Hi Patricio, On 2019-06-18 22:49, Patricio Chilano wrote: > Hi Robbin, > > Change looks good to me! Thanks! Below is an issue, thanks for noticing! There are several of options here, still considering which one I like... This fix will have to address that also. I'll respond to RFR mail with whatever I do. Thanks, Robbin > > One question though. In deoptimization.cpp there is method > fetch_unroll_info_helper() which calls create_vframeArray() which will > eventually call vframeArrayElement::fill_in(). That method tries to get the > monitors from the stack and has the following assertion: > > assert(monitor->owner() == NULL || (!monitor->owner()->is_unlocked() && > !monitor->owner()->has_bias_pattern()), "object must be null or locked, and > unbiased"); > > So it is expecting that the locked monitors are not biased anymore. Do you know > exactly when fetch_unroll_info_helper() would be called during this > deoptimization phase? There is a comment "fetch_unroll_info() is called at the > beginning of the deoptimization handler" but no sure what that means exactly > since it is expecting monitors to be revoked already. > My question is whether we could hit that assert later on if we avoid trying to > revoke these biased objects that actually belong to somebody else. One scenario > could be as follows: > > 1) JT1 calls BiasedLocking::revoke_and_rebias() for object X, finds X is biased > toward JT2 and requests a revocation using a bulk rebias operation. The > attempt_rebias flag is true, so this call comes from interpreter/c1/c2 where JT1 > was trying to lock this object. > 2) VMThread executes a deoptimization operation (present in the VM queue before > the bulk rebias operation was added). VMThread executes the handshake on behalf > of JT1, who is blocked, finds monitor associated with object X in the stack but > skips revocation since JT1 is not the owner. JT2 executes the handshake too > but does not revoke bias of X because it is not currently using that lock (it's > not in its stack). > 3) VMThread executes the bulk rebias operation for objects of class X that JT1 > requested. Object? X is not currently in the stack of JT2 and so the bias for > object X expires and is not valid anymore. Since > bulk_revoke_or_rebias_at_safepoint() was called with a value of > attempt_rebias_of_object=true the object will be rebiased towards JT1. > 4) JT1 unblocks, and tries to execute fetch_unroll_info_helper() (?) > > But not sure if that last step is possible. > > > Thanks Robbin! > > > Patricio > > On 6/14/19 4:03 AM, Robbin Ehn wrote: >> Hi all, please review. >> >> When looking at a JavaThreads locks we retrieve them per frame via it's monitors >> list. How this list actually populated differs from frame type. If a >> JavaThread tries to enter a new monitor a basic lock is directly/indirectly >> via e.g. scope info added to the virtual monitor list. If this lock is biased >> towards another >> JavaThread we try to revoke that bias with a safepoint. In this case a deopt >> handshake is already in queue. The handshake is thus executed before the revoke >> safepoint. >> The handshake goes over the monitors in compiled frames, find this lock and we >> hit the assert. The assert make sure we actual can revoke the lock. A basic lock >> on stack should always, if biased, be biased to current thread, with the >> exception: >> We may have a stack lock biased against another thread until >> ObjectSynchronizer::fast_enter returns. >> >> To handle this exception we can safely ignore biased lock towards other threads >> in the deopt handshake. Since such locks will always be revoked before we >> deopt/unpack stack. >> >> Code: >> http://cr.openjdk.java.net/~rehn/8225351/v1/webrev/index.html >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8225351 >> >> Passes t1-7 >> The assert code tested with local code changes to HandshakeAlot handshake. >> We then see this state where last lock can be biased towards another thread >> and the thread is trying to execute revoke safepoint. >> >> Thanks, Robbin > From erik.osterlund at oracle.com Thu Jun 20 09:38:43 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 20 Jun 2019 11:38:43 +0200 Subject: RFR: 8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers Message-ID: Hi, With the new late barrier expansion mechanism, we thought we could finally disable some workarounds that fixed up bad oops in the stack, that should never be allowed to be bad really if the compiler did what we want it to do. It turns out that it is still possible for bad oops to end up in the stack. This is attributed to spills of the loaded bad oop that never really got usedin the application. These spills could be observed in the disassembly. While the oop isn't used in the nmethod, it might be used by e.g. deoptimization, forcing it to stick around. The cause for the spill causing the trouble is that the medium slow path (LoadBarrierSlowRegNode) defines (DEF) a new value returned from the slow path reloads the oop into that register, instead of using the original oop as input. So the LoadBarrierSlowRegNode would sometimes get a different register to the original load, causing the loaded bad value to spill bad values for deopt sometimes, eventually causing crashes in heap iteration code and asserts. To solve the problem, the original oop was added as an input edge to LoadBarrierSlowRegNode, so that we in the AD file could have the input and output of the node be the same, matching the original load. That attempt first produced a bad AD file because the ADLC parser doesn't like that the LoadBarrierSlowRegNode had an additional edge when it is modeled as a load, which is treated specially in places. It has been originally modeled as a load because it reloads the value and hence needs to quack like a load. However, with the new late barrier expansion approach we can re-model it as a TypeNode instead because the slowreg node can't really move around so much in the circumstances where they are now expanded (late and tucked into tight control flow blocks). Nevertheless, it is a bit iffy and a follow-up RFE will remove the current practice of returning reloaded values from the barrier slowpaths to make this increasingly sane. But I want this fix to be as minimal as possible as it's going in to 13, and the risk of making such changes for 13 is not worth it. Thanks goes to StefanK, Per and Nils for helping diagnose the problem, finding good reproducers, helping out testing the fix, and good discussions along the way. This patch has made it through mach5 hs-tier1-5, many runs of gc-testsuite, 100 kitchensink runs, and ~1 day of StefanK's quite reliable reproducer with custom StefanK verification code that normally crashes within an hour. Webrev: http://cr.openjdk.java.net/~eosterlund/8225642/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8225642 Thanks, /Erik From nils.eliasson at oracle.com Thu Jun 20 09:45:52 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 20 Jun 2019 11:45:52 +0200 Subject: RFR: 8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers In-Reply-To: References: Message-ID: <0cb8d0e0-e40d-4524-97e9-555ff86d85b5@oracle.com> Hi Erik, Looks great! // Nils On 2019-06-20 11:38, Erik ?sterlund wrote: > Hi, > > With the new late barrier expansion mechanism, we thought we could > finally disable some workarounds that fixed up bad oops in the stack, > that should never be allowed to be bad really if the compiler did what > we want it to do. > It turns out that it is still possible for bad oops to end up in the > stack. This is attributed to spills of the loaded bad oop that never > really got usedin the application. These spills could be observed in > the disassembly. While the oop isn't used in the nmethod, it might be > used by e.g. deoptimization, forcing it to stick around. The cause for > the spill causing the trouble is that the medium slow path > (LoadBarrierSlowRegNode) defines (DEF) a new value returned from the > slow path reloads the oop into that register, instead of using the > original oop as input. So the LoadBarrierSlowRegNode would sometimes > get a different register to the original load, causing the loaded bad > value to spill bad values for deopt sometimes, eventually causing > crashes in heap iteration code and asserts. > > To solve the problem, the original oop was added as an input edge to > LoadBarrierSlowRegNode, so that we in the AD file could have the input > and output of the node be the same, matching the original load. That > attempt first produced a bad AD file because the ADLC parser doesn't > like that the LoadBarrierSlowRegNode had an additional edge when it is > modeled as a load, which is treated specially in places. It has been > originally modeled as a load because it reloads the value and hence > needs to quack like a load. However, with the new late barrier > expansion approach we can re-model it as a TypeNode instead because > the slowreg node can't really move around so much in the circumstances > where they are now expanded (late and tucked into tight control flow > blocks). Nevertheless, it is a bit iffy and a follow-up RFE will > remove the current practice of returning reloaded values from the > barrier slowpaths to make this increasingly sane. But I want this fix > to be as minimal as possible as it's going in to 13, and the risk of > making such changes for 13 is not worth it. > > Thanks goes to StefanK, Per and Nils for helping diagnose the problem, > finding good reproducers, helping out testing the fix, and good > discussions along the way. > > This patch has made it through mach5 hs-tier1-5, many runs of > gc-testsuite, 100 kitchensink runs, and ~1 day of StefanK's quite > reliable reproducer with custom StefanK verification code that > normally crashes within an hour. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8225642/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8225642 > > Thanks, > /Erik From erik.osterlund at oracle.com Thu Jun 20 10:02:24 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 20 Jun 2019 12:02:24 +0200 Subject: RFR: 8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers In-Reply-To: <0cb8d0e0-e40d-4524-97e9-555ff86d85b5@oracle.com> References: <0cb8d0e0-e40d-4524-97e9-555ff86d85b5@oracle.com> Message-ID: Hi Nils, Thanks for the review. /Erik On 2019-06-20 11:45, Nils Eliasson wrote: > Hi Erik, > > Looks great! > > // Nils > > On 2019-06-20 11:38, Erik ?sterlund wrote: >> Hi, >> >> With the new late barrier expansion mechanism, we thought we could >> finally disable some workarounds that fixed up bad oops in the stack, >> that should never be allowed to be bad really if the compiler did >> what we want it to do. >> It turns out that it is still possible for bad oops to end up in the >> stack. This is attributed to spills of the loaded bad oop that never >> really got usedin the application. These spills could be observed in >> the disassembly. While the oop isn't used in the nmethod, it might be >> used by e.g. deoptimization, forcing it to stick around. The cause >> for the spill causing the trouble is that the medium slow path >> (LoadBarrierSlowRegNode) defines (DEF) a new value returned from the >> slow path reloads the oop into that register, instead of using the >> original oop as input. So the LoadBarrierSlowRegNode would sometimes >> get a different register to the original load, causing the loaded bad >> value to spill bad values for deopt sometimes, eventually causing >> crashes in heap iteration code and asserts. >> >> To solve the problem, the original oop was added as an input edge to >> LoadBarrierSlowRegNode, so that we in the AD file could have the >> input and output of the node be the same, matching the original load. >> That attempt first produced a bad AD file because the ADLC parser >> doesn't like that the LoadBarrierSlowRegNode had an additional edge >> when it is modeled as a load, which is treated specially in places. >> It has been originally modeled as a load because it reloads the value >> and hence needs to quack like a load. However, with the new late >> barrier expansion approach we can re-model it as a TypeNode instead >> because the slowreg node can't really move around so much in the >> circumstances where they are now expanded (late and tucked into tight >> control flow blocks). Nevertheless, it is a bit iffy and a follow-up >> RFE will remove the current practice of returning reloaded values >> from the barrier slowpaths to make this increasingly sane. But I want >> this fix to be as minimal as possible as it's going in to 13, and the >> risk of making such changes for 13 is not worth it. >> >> Thanks goes to StefanK, Per and Nils for helping diagnose the >> problem, finding good reproducers, helping out testing the fix, and >> good discussions along the way. >> >> This patch has made it through mach5 hs-tier1-5, many runs of >> gc-testsuite, 100 kitchensink runs, and ~1 day of StefanK's quite >> reliable reproducer with custom StefanK verification code that >> normally crashes within an hour. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8225642/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8225642 >> >> Thanks, >> /Erik From daniel.fuchs at oracle.com Thu Jun 20 10:14:33 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 20 Jun 2019 11:14:33 +0100 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> Message-ID: <822064bd-653a-d724-bbd9-aec7d88bcfed@oracle.com> Hi Vladimir, On 20/06/2019 02:03, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ Ah - I see that the logging test are the principal offenders here. Sorry about that ;-( I looked at the various logging tests and the proposed changes look good to me. Thanks for updating them! I skimmed through the rest and didn't see any particular issue. best regards, -- daniel > > https://bugs.openjdk.java.net/browse/JDK-8185139 > > For Graal to work we have to give Graal module all permissions which is > specified in default policy [1]. > Unfortunately this cause problem for Graal running tests which overwrite > default policy. > > I discussed this with Mandy and she suggested that such tests should > also check default policy. I implemented her suggestion. Note, this is > not only Graal problem. There were already similar fixes before [2]. > > I also updated Graal's problem list. Several tests were left on problem > list (with different bug id) because they would not run with Java Graal > (for example, they use --limit-modules flag which prevents loading Graal > module). We will enable such tests again when libgraal is supported. > > I ran testing which execute these tests with Graal. It shows only known > problems which are not related to these changes. > > Thanks, > Vladimir > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 > > [2] https://bugs.openjdk.java.net/browse/JDK-8189291 From per.liden at oracle.com Thu Jun 20 11:04:52 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 20 Jun 2019 13:04:52 +0200 Subject: RFR: 8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers In-Reply-To: References: Message-ID: <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com> On 6/20/19 11:38 AM, Erik ?sterlund wrote: > Hi, > > With the new late barrier expansion mechanism, we thought we could > finally disable some workarounds that fixed up bad oops in the stack, > that should never be allowed to be bad really if the compiler did what > we want it to do. > It turns out that it is still possible for bad oops to end up in the > stack. This is attributed to spills of the loaded bad oop that never > really got usedin the application. These spills could be observed in the > disassembly. While the oop isn't used in the nmethod, it might be used > by e.g. deoptimization, forcing it to stick around. The cause for the > spill causing the trouble is that the medium slow path > (LoadBarrierSlowRegNode) defines (DEF) a new value returned from the > slow path reloads the oop into that register, instead of using the > original oop as input. So the LoadBarrierSlowRegNode would sometimes get > a different register to the original load, causing the loaded bad value > to spill bad values for deopt sometimes, eventually causing crashes in > heap iteration code and asserts. > > To solve the problem, the original oop was added as an input edge to > LoadBarrierSlowRegNode, so that we in the AD file could have the input > and output of the node be the same, matching the original load. That > attempt first produced a bad AD file because the ADLC parser doesn't > like that the LoadBarrierSlowRegNode had an additional edge when it is > modeled as a load, which is treated specially in places. It has been > originally modeled as a load because it reloads the value and hence > needs to quack like a load. However, with the new late barrier expansion > approach we can re-model it as a TypeNode instead because the slowreg > node can't really move around so much in the circumstances where they > are now expanded (late and tucked into tight control flow blocks). > Nevertheless, it is a bit iffy and a follow-up RFE will remove the > current practice of returning reloaded values from the barrier slowpaths > to make this increasingly sane. But I want this fix to be as minimal as > possible as it's going in to 13, and the risk of making such changes for > 13 is not worth it. > > Thanks goes to StefanK, Per and Nils for helping diagnose the problem, > finding good reproducers, helping out testing the fix, and good > discussions along the way. > > This patch has made it through mach5 hs-tier1-5, many runs of > gc-testsuite, 100 kitchensink runs, and ~1 day of StefanK's quite > reliable reproducer with custom StefanK verification code that normally > crashes within an hour. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8225642/webrev.00/ Looks good to me! /Per > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8225642 > > Thanks, > /Erik From erik.osterlund at oracle.com Thu Jun 20 11:19:55 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 20 Jun 2019 13:19:55 +0200 Subject: RFR: 8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers In-Reply-To: <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com> References: <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com> Message-ID: Hi Per, Thanks for the review. /Erik > On 20 Jun 2019, at 13:04, Per Liden wrote: > >> On 6/20/19 11:38 AM, Erik ?sterlund wrote: >> Hi, >> With the new late barrier expansion mechanism, we thought we could finally disable some workarounds that fixed up bad oops in the stack, that should never be allowed to be bad really if the compiler did what we want it to do. >> It turns out that it is still possible for bad oops to end up in the stack. This is attributed to spills of the loaded bad oop that never really got usedin the application. These spills could be observed in the disassembly. While the oop isn't used in the nmethod, it might be used by e.g. deoptimization, forcing it to stick around. The cause for the spill causing the trouble is that the medium slow path (LoadBarrierSlowRegNode) defines (DEF) a new value returned from the slow path reloads the oop into that register, instead of using the original oop as input. So the LoadBarrierSlowRegNode would sometimes get a different register to the original load, causing the loaded bad value to spill bad values for deopt sometimes, eventually causing crashes in heap iteration code and asserts. >> To solve the problem, the original oop was added as an input edge to LoadBarrierSlowRegNode, so that we in the AD file could have the input and output of the node be the same, matching the original load. That attempt first produced a bad AD file because the ADLC parser doesn't like that the LoadBarrierSlowRegNode had an additional edge when it is modeled as a load, which is treated specially in places. It has been originally modeled as a load because it reloads the value and hence needs to quack like a load. However, with the new late barrier expansion approach we can re-model it as a TypeNode instead because the slowreg node can't really move around so much in the circumstances where they are now expanded (late and tucked into tight control flow blocks). Nevertheless, it is a bit iffy and a follow-up RFE will remove the current practice of returning reloaded values from the barrier slowpaths to make this increasingly sane. But I want this fix to be as minimal as possible as it's going in to 13, and the risk of making such changes for 13 is not worth it. >> Thanks goes to StefanK, Per and Nils for helping diagnose the problem, finding good reproducers, helping out testing the fix, and good discussions along the way. >> This patch has made it through mach5 hs-tier1-5, many runs of gc-testsuite, 100 kitchensink runs, and ~1 day of StefanK's quite reliable reproducer with custom StefanK verification code that normally crashes within an hour. >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8225642/webrev.00/ > > Looks good to me! > > /Per > >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8225642 >> Thanks, >> /Erik From Roger.Riggs at oracle.com Thu Jun 20 13:32:35 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 20 Jun 2019 09:32:35 -0400 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> Message-ID: <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com> Hi, If this were java.base, we would use doPrivilege to ignore the policy and place specific limits. Encumbering the default policy with conditions needed by a trusted subsystem seems like distributing what should be a local implementation issue. $.02, Roger On 6/20/19 2:23 AM, Mandy Chung wrote: > Hi Vladimir, > > Indeed these are test issues that the tests will need to grant > permissions > to jdk.internal.vm.compiler as the default policy grants. > > Thanks for going extra miles to fix the tests. > > My suggestion may be a bit general.? What I intend to say the custom > security policy should extend the default policy unless it intentionally > excludes configuring permissions for specific modules.? I review the > the patch but the test doesn't clearly tell what the test intends to > do w.r.t. security configuration. > > We should avoid inadvertently granting permissions that the test expects > to disallow.? A better solution is to limit granting permissions just for > `jdk.internal.vm.compiler` module rather than all. > > Attached is ModulePolicy class that allows you to get the Policy for > a specific module. It can be put in the test library that these tests > can use them. > > So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and > implies method will call the returned ModulePolicy if present. > > test/lib/jdk/test/lib/security is one existing testlibrary for security > related stuff.? You can consider putting ModulePolicy.java there. > > This is one idea. > > Mandy > > On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8185139 >> >> For Graal to work we have to give Graal module all permissions which >> is specified in default policy [1]. >> Unfortunately this cause problem for Graal running tests which >> overwrite default policy. >> >> I discussed this with Mandy and she suggested that such tests should >> also check default policy. I implemented her suggestion. Note, this >> is not only Graal problem. There were already similar fixes before [2]. >> >> I also updated Graal's problem list. Several tests were left on >> problem list (with different bug id) because they would not run with >> Java Graal (for example, they use --limit-modules flag which prevents >> loading Graal module). We will enable such tests again when libgraal >> is supported. >> >> I ran testing which execute these tests with Graal. It shows only >> known problems which are not related to these changes. >> >> Thanks, >> Vladimir >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Jun 20 15:04:29 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Jun 2019 08:04:29 -0700 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com> Message-ID: The Policy API does not assume the presence of the default policy for the runtime to use. jdk.internal.vm.compiler already uses doPrivileged.?? The module ends up with no permission as the test policy does not consult the default policy. Mandy On 6/20/19 6:32 AM, Roger Riggs wrote: > Hi, > > If this were java.base, we would use doPrivilege to ignore the policy > and place specific limits. > Encumbering the default policy with conditions needed by a trusted > subsystem seems > like distributing what should be a local implementation issue. > > $.02, Roger > > On 6/20/19 2:23 AM, Mandy Chung wrote: >> Hi Vladimir, >> >> Indeed these are test issues that the tests will need to grant >> permissions >> to jdk.internal.vm.compiler as the default policy grants. >> >> Thanks for going extra miles to fix the tests. >> >> My suggestion may be a bit general.? What I intend to say the custom >> security policy should extend the default policy unless it intentionally >> excludes configuring permissions for specific modules.? I review the >> the patch but the test doesn't clearly tell what the test intends to >> do w.r.t. security configuration. >> >> We should avoid inadvertently granting permissions that the test expects >> to disallow.? A better solution is to limit granting permissions just >> for >> `jdk.internal.vm.compiler` module rather than all. >> >> Attached is ModulePolicy class that allows you to get the Policy for >> a specific module. It can be put in the test library that these tests >> can use them. >> >> So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and >> implies method will call the returned ModulePolicy if present. >> >> test/lib/jdk/test/lib/security is one existing testlibrary for security >> related stuff.? You can consider putting ModulePolicy.java there. >> >> This is one idea. >> >> Mandy >> >> On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8185139 >>> >>> For Graal to work we have to give Graal module all permissions which >>> is specified in default policy [1]. >>> Unfortunately this cause problem for Graal running tests which >>> overwrite default policy. >>> >>> I discussed this with Mandy and she suggested that such tests should >>> also check default policy. I implemented her suggestion. Note, this >>> is not only Graal problem. There were already similar fixes before [2]. >>> >>> I also updated Graal's problem list. Several tests were left on >>> problem list (with different bug id) because they would not run with >>> Java Graal (for example, they use --limit-modules flag which >>> prevents loading Graal module). We will enable such tests again when >>> libgraal is supported. >>> >>> I ran testing which execute these tests with Graal. It shows only >>> known problems which are not related to these changes. >>> >>> Thanks, >>> Vladimir >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 >> > From Alan.Bateman at oracle.com Thu Jun 20 15:36:06 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Jun 2019 16:36:06 +0100 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> Message-ID: <11d9ab2a-a39f-7912-209c-15877351ad5d@oracle.com> On 20/06/2019 07:23, Mandy Chung wrote: > : > > My suggestion may be a bit general.? What I intend to say the custom > security policy should extend the default policy unless it intentionally > excludes configuring permissions for specific modules. I think that's right. In the case of the j.u.logging tests then maybe SimplePolicy could be factored out into a separate source file so there aren't 20 or so tests with a SimplePolicy and implies method that checks the default policy. -Alan From stuart.monteith at linaro.org Thu Jun 20 16:29:39 2019 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 20 Jun 2019 17:29:39 +0100 Subject: RFR: 8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers In-Reply-To: References: <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com> Message-ID: Hello, Sorry, I should check my ZGC filter more often. I notice that there are some changes that are required for Aarch64. Would you like me to send a patch to be incorporated into this patch, or shall I pursue a separate bug? Thanks, Stuart On Thu, 20 Jun 2019 at 12:33, Erik Osterlund wrote: > > Hi Per, > > Thanks for the review. > > /Erik > > > On 20 Jun 2019, at 13:04, Per Liden wrote: > > > >> On 6/20/19 11:38 AM, Erik ?sterlund wrote: > >> Hi, > >> With the new late barrier expansion mechanism, we thought we could finally disable some workarounds that fixed up bad oops in the stack, that should never be allowed to be bad really if the compiler did what we want it to do. > >> It turns out that it is still possible for bad oops to end up in the stack. This is attributed to spills of the loaded bad oop that never really got usedin the application. These spills could be observed in the disassembly. While the oop isn't used in the nmethod, it might be used by e.g. deoptimization, forcing it to stick around. The cause for the spill causing the trouble is that the medium slow path (LoadBarrierSlowRegNode) defines (DEF) a new value returned from the slow path reloads the oop into that register, instead of using the original oop as input. So the LoadBarrierSlowRegNode would sometimes get a different register to the original load, causing the loaded bad value to spill bad values for deopt sometimes, eventually causing crashes in heap iteration code and asserts. > >> To solve the problem, the original oop was added as an input edge to LoadBarrierSlowRegNode, so that we in the AD file could have the input and output of the node be the same, matching the original load. That attempt first produced a bad AD file because the ADLC parser doesn't like that the LoadBarrierSlowRegNode had an additional edge when it is modeled as a load, which is treated specially in places. It has been originally modeled as a load because it reloads the value and hence needs to quack like a load. However, with the new late barrier expansion approach we can re-model it as a TypeNode instead because the slowreg node can't really move around so much in the circumstances where they are now expanded (late and tucked into tight control flow blocks). Nevertheless, it is a bit iffy and a follow-up RFE will remove the current practice of returning reloaded values from the barrier slowpaths to make this increasingly sane. But I want this fix to be as minimal as possible as it's going in to 13, and the risk of making such changes for 13 is not worth it. > >> Thanks goes to StefanK, Per and Nils for helping diagnose the problem, finding good reproducers, helping out testing the fix, and good discussions along the way. > >> This patch has made it through mach5 hs-tier1-5, many runs of gc-testsuite, 100 kitchensink runs, and ~1 day of StefanK's quite reliable reproducer with custom StefanK verification code that normally crashes within an hour. > >> Webrev: > >> http://cr.openjdk.java.net/~eosterlund/8225642/webrev.00/ > > > > Looks good to me! > > > > /Per > > > >> Bug: > >> https://bugs.openjdk.java.net/browse/JDK-8225642 > >> Thanks, > >> /Erik > From daniel.fuchs at oracle.com Thu Jun 20 16:40:45 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 20 Jun 2019 17:40:45 +0100 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <11d9ab2a-a39f-7912-209c-15877351ad5d@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <11d9ab2a-a39f-7912-209c-15877351ad5d@oracle.com> Message-ID: Hi Alan, On 20/06/2019 16:36, Alan Bateman wrote: > I think that's right. In the case of the j.u.logging tests then maybe > SimplePolicy could be factored out into a separate source file so there > aren't 20 or so tests with a SimplePolicy and implies method that checks > the default policy. I don't like this idea much as there can be some subtle differences between these SimplePolicy classes. I strongly hope that having to modify these test policy implementations is not something that we will need to do very often, and trying to factor out the SimplePolicy implementation is likely to be more trouble than it's worth. best regards, -- daniel > > -Alan > From erik.osterlund at oracle.com Thu Jun 20 16:56:57 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 20 Jun 2019 18:56:57 +0200 Subject: RFR: 8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers In-Reply-To: References: <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com> Message-ID: <31ED223B-3108-480C-8605-175863A6D15F@oracle.com> Hi Stuart, I can fold in some AArch64 juice if you got some. :) Thanks, /Erik > On 20 Jun 2019, at 18:29, Stuart Monteith wrote: > > Hello, > Sorry, I should check my ZGC filter more often. I notice that there > are some changes that are required for Aarch64. Would you like me to > send a patch to be incorporated into this patch, or shall I pursue a > separate bug? > > Thanks, > Stuart > >> On Thu, 20 Jun 2019 at 12:33, Erik Osterlund wrote: >> >> Hi Per, >> >> Thanks for the review. >> >> /Erik >> >>>> On 20 Jun 2019, at 13:04, Per Liden wrote: >>>> >>>> On 6/20/19 11:38 AM, Erik ?sterlund wrote: >>>> Hi, >>>> With the new late barrier expansion mechanism, we thought we could finally disable some workarounds that fixed up bad oops in the stack, that should never be allowed to be bad really if the compiler did what we want it to do. >>>> It turns out that it is still possible for bad oops to end up in the stack. This is attributed to spills of the loaded bad oop that never really got usedin the application. These spills could be observed in the disassembly. While the oop isn't used in the nmethod, it might be used by e.g. deoptimization, forcing it to stick around. The cause for the spill causing the trouble is that the medium slow path (LoadBarrierSlowRegNode) defines (DEF) a new value returned from the slow path reloads the oop into that register, instead of using the original oop as input. So the LoadBarrierSlowRegNode would sometimes get a different register to the original load, causing the loaded bad value to spill bad values for deopt sometimes, eventually causing crashes in heap iteration code and asserts. >>>> To solve the problem, the original oop was added as an input edge to LoadBarrierSlowRegNode, so that we in the AD file could have the input and output of the node be the same, matching the original load. That attempt first produced a bad AD file because the ADLC parser doesn't like that the LoadBarrierSlowRegNode had an additional edge when it is modeled as a load, which is treated specially in places. It has been originally modeled as a load because it reloads the value and hence needs to quack like a load. However, with the new late barrier expansion approach we can re-model it as a TypeNode instead because the slowreg node can't really move around so much in the circumstances where they are now expanded (late and tucked into tight control flow blocks). Nevertheless, it is a bit iffy and a follow-up RFE will remove the current practice of returning reloaded values from the barrier slowpaths to make this increasingly sane. But I want this fix to be as minimal as possible as it's going in to 13, and the risk of making such changes for 13 is not worth it. >>>> Thanks goes to StefanK, Per and Nils for helping diagnose the problem, finding good reproducers, helping out testing the fix, and good discussions along the way. >>>> This patch has made it through mach5 hs-tier1-5, many runs of gc-testsuite, 100 kitchensink runs, and ~1 day of StefanK's quite reliable reproducer with custom StefanK verification code that normally crashes within an hour. >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8225642/webrev.00/ >>> >>> Looks good to me! >>> >>> /Per >>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8225642 >>>> Thanks, >>>> /Erik >> From stuart.monteith at linaro.org Thu Jun 20 17:05:57 2019 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 20 Jun 2019 18:05:57 +0100 Subject: RFR: 8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers In-Reply-To: <31ED223B-3108-480C-8605-175863A6D15F@oracle.com> References: <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com> <31ED223B-3108-480C-8605-175863A6D15F@oracle.com> Message-ID: Thanks Erik. Hopefully this should be all we need - I haven't spotted anything fundamentally different: http://cr.openjdk.java.net/~smonteith/8225642/8225642.patch I've done a little testing. Thanks! On Thu, 20 Jun 2019 at 17:57, Erik Osterlund wrote: > > Hi Stuart, > > I can fold in some AArch64 juice if you got some. :) > > Thanks, > /Erik > > > On 20 Jun 2019, at 18:29, Stuart Monteith wrote: > > > > Hello, > > Sorry, I should check my ZGC filter more often. I notice that there > > are some changes that are required for Aarch64. Would you like me to > > send a patch to be incorporated into this patch, or shall I pursue a > > separate bug? > > > > Thanks, > > Stuart > > > >> On Thu, 20 Jun 2019 at 12:33, Erik Osterlund wrote: > >> > >> Hi Per, > >> > >> Thanks for the review. > >> > >> /Erik > >> > >>>> On 20 Jun 2019, at 13:04, Per Liden wrote: > >>>> > >>>> On 6/20/19 11:38 AM, Erik ?sterlund wrote: > >>>> Hi, > >>>> With the new late barrier expansion mechanism, we thought we could finally disable some workarounds that fixed up bad oops in the stack, that should never be allowed to be bad really if the compiler did what we want it to do. > >>>> It turns out that it is still possible for bad oops to end up in the stack. This is attributed to spills of the loaded bad oop that never really got usedin the application. These spills could be observed in the disassembly. While the oop isn't used in the nmethod, it might be used by e.g. deoptimization, forcing it to stick around. The cause for the spill causing the trouble is that the medium slow path (LoadBarrierSlowRegNode) defines (DEF) a new value returned from the slow path reloads the oop into that register, instead of using the original oop as input. So the LoadBarrierSlowRegNode would sometimes get a different register to the original load, causing the loaded bad value to spill bad values for deopt sometimes, eventually causing crashes in heap iteration code and asserts. > >>>> To solve the problem, the original oop was added as an input edge to LoadBarrierSlowRegNode, so that we in the AD file could have the input and output of the node be the same, matching the original load. That attempt first produced a bad AD file because the ADLC parser doesn't like that the LoadBarrierSlowRegNode had an additional edge when it is modeled as a load, which is treated specially in places. It has been originally modeled as a load because it reloads the value and hence needs to quack like a load. However, with the new late barrier expansion approach we can re-model it as a TypeNode instead because the slowreg node can't really move around so much in the circumstances where they are now expanded (late and tucked into tight control flow blocks). Nevertheless, it is a bit iffy and a follow-up RFE will remove the current practice of returning reloaded values from the barrier slowpaths to make this increasingly sane. But I want this fix to be as minimal as possible as it's going in to 13, and the risk of making such changes for 13 is not worth it. > >>>> Thanks goes to StefanK, Per and Nils for helping diagnose the problem, finding good reproducers, helping out testing the fix, and good discussions along the way. > >>>> This patch has made it through mach5 hs-tier1-5, many runs of gc-testsuite, 100 kitchensink runs, and ~1 day of StefanK's quite reliable reproducer with custom StefanK verification code that normally crashes within an hour. > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~eosterlund/8225642/webrev.00/ > >>> > >>> Looks good to me! > >>> > >>> /Per > >>> > >>>> Bug: > >>>> https://bugs.openjdk.java.net/browse/JDK-8225642 > >>>> Thanks, > >>>> /Erik > >> > From erik.osterlund at oracle.com Thu Jun 20 17:08:53 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 20 Jun 2019 19:08:53 +0200 Subject: RFR: 8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers In-Reply-To: References: <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com> <31ED223B-3108-480C-8605-175863A6D15F@oracle.com> Message-ID: Hi Stuart, That looks right. I will fold it in to my push. Thanks, /Erik > On 20 Jun 2019, at 19:05, Stuart Monteith wrote: > > Thanks Erik. > > Hopefully this should be all we need - I haven't spotted anything > fundamentally different: > http://cr.openjdk.java.net/~smonteith/8225642/8225642.patch > > I've done a little testing. > > Thanks! > > >> On Thu, 20 Jun 2019 at 17:57, Erik Osterlund wrote: >> >> Hi Stuart, >> >> I can fold in some AArch64 juice if you got some. :) >> >> Thanks, >> /Erik >> >>> On 20 Jun 2019, at 18:29, Stuart Monteith wrote: >>> >>> Hello, >>> Sorry, I should check my ZGC filter more often. I notice that there >>> are some changes that are required for Aarch64. Would you like me to >>> send a patch to be incorporated into this patch, or shall I pursue a >>> separate bug? >>> >>> Thanks, >>> Stuart >>> >>>> On Thu, 20 Jun 2019 at 12:33, Erik Osterlund wrote: >>>> >>>> Hi Per, >>>> >>>> Thanks for the review. >>>> >>>> /Erik >>>> >>>>>> On 20 Jun 2019, at 13:04, Per Liden wrote: >>>>>> >>>>>> On 6/20/19 11:38 AM, Erik ?sterlund wrote: >>>>>> Hi, >>>>>> With the new late barrier expansion mechanism, we thought we could finally disable some workarounds that fixed up bad oops in the stack, that should never be allowed to be bad really if the compiler did what we want it to do. >>>>>> It turns out that it is still possible for bad oops to end up in the stack. This is attributed to spills of the loaded bad oop that never really got usedin the application. These spills could be observed in the disassembly. While the oop isn't used in the nmethod, it might be used by e.g. deoptimization, forcing it to stick around. The cause for the spill causing the trouble is that the medium slow path (LoadBarrierSlowRegNode) defines (DEF) a new value returned from the slow path reloads the oop into that register, instead of using the original oop as input. So the LoadBarrierSlowRegNode would sometimes get a different register to the original load, causing the loaded bad value to spill bad values for deopt sometimes, eventually causing crashes in heap iteration code and asserts. >>>>>> To solve the problem, the original oop was added as an input edge to LoadBarrierSlowRegNode, so that we in the AD file could have the input and output of the node be the same, matching the original load. That attempt first produced a bad AD file because the ADLC parser doesn't like that the LoadBarrierSlowRegNode had an additional edge when it is modeled as a load, which is treated specially in places. It has been originally modeled as a load because it reloads the value and hence needs to quack like a load. However, with the new late barrier expansion approach we can re-model it as a TypeNode instead because the slowreg node can't really move around so much in the circumstances where they are now expanded (late and tucked into tight control flow blocks). Nevertheless, it is a bit iffy and a follow-up RFE will remove the current practice of returning reloaded values from the barrier slowpaths to make this increasingly sane. But I want this fix to be as minimal as possible as it's going in to 13, and the risk of making such changes for 13 is not worth it. >>>>>> Thanks goes to StefanK, Per and Nils for helping diagnose the problem, finding good reproducers, helping out testing the fix, and good discussions along the way. >>>>>> This patch has made it through mach5 hs-tier1-5, many runs of gc-testsuite, 100 kitchensink runs, and ~1 day of StefanK's quite reliable reproducer with custom StefanK verification code that normally crashes within an hour. >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eosterlund/8225642/webrev.00/ >>>>> >>>>> Looks good to me! >>>>> >>>>> /Per >>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8225642 >>>>>> Thanks, >>>>>> /Erik >>>> >> From vladimir.kozlov at oracle.com Thu Jun 20 17:39:47 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Jun 2019 10:39:47 -0700 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <11d9ab2a-a39f-7912-209c-15877351ad5d@oracle.com> Message-ID: I agree with Daniel. I did look into factoring SimplePolicy into a separate file but found, as Daniel pointed, there were some differences which would complicate this common class and would require more time to make such changes. Thank you Daniel, Roger and Alan for reviews. And special thanks to Mandy for helping me with this issue from start to finish. Thanks, Vladimir On 6/20/19 9:40 AM, Daniel Fuchs wrote: > Hi Alan, > > On 20/06/2019 16:36, Alan Bateman wrote: >> I think that's right. In the case of the j.u.logging tests then maybe SimplePolicy could be factored out into a >> separate source file so there aren't 20 or so tests with a SimplePolicy and implies method that checks the default >> policy. > > I don't like this idea much as there can be some subtle differences > between these SimplePolicy classes. I strongly hope that having > to modify these test policy implementations is not something that we > will need to do very often, and trying to factor out the SimplePolicy > implementation is likely to be more trouble than it's worth. > > best regards, > > -- daniel > >> >> -Alan >> > From vladimir.kozlov at oracle.com Thu Jun 20 18:05:46 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Jun 2019 11:05:46 -0700 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> Message-ID: <53c2c755-572f-c76e-5872-6bd6ed8914b8@oracle.com> Hi Mandy I am not sure about this suggestion. Graal module may not be present in the JDK (on SPARC for example). And I don't want pollute general tests with Graal specific code: ModulePolicy.get("jdk.internal.vm.compiler"). If you or other have concerns about some tests looking on default policy I can keep them on problem list to run them later only with libgraal. I found only 2 closed tests in which I had doubt about using default policy. I kept them on problem list. Other tests, as I understand, manipulate permissions for test classes. They don't extend system classes so default policy should not affect test class permissions. Thanks, Vladimir On 6/19/19 11:23 PM, Mandy Chung wrote: > Hi Vladimir, > > Indeed these are test issues that the tests will need to grant permissions > to jdk.internal.vm.compiler as the default policy grants. > > Thanks for going extra miles to fix the tests. > > My suggestion may be a bit general.? What I intend to say the custom > security policy should extend the default policy unless it intentionally > excludes configuring permissions for specific modules.? I review the > the patch but the test doesn't clearly tell what the test intends to > do w.r.t. security configuration. > > We should avoid inadvertently granting permissions that the test expects > to disallow.? A better solution is to limit granting permissions just for > `jdk.internal.vm.compiler` module rather than all. > > Attached is ModulePolicy class that allows you to get the Policy for > a specific module. It can be put in the test library that these tests > can use them. > > So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and > implies method will call the returned ModulePolicy if present. > > test/lib/jdk/test/lib/security is one existing testlibrary for security > related stuff.? You can consider putting ModulePolicy.java there. > > This is one idea. > > Mandy > > On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8185139 >> >> For Graal to work we have to give Graal module all permissions which is specified in default policy [1]. >> Unfortunately this cause problem for Graal running tests which overwrite default policy. >> >> I discussed this with Mandy and she suggested that such tests should also check default policy. I implemented her >> suggestion. Note, this is not only Graal problem. There were already similar fixes before [2]. >> >> I also updated Graal's problem list. Several tests were left on problem list (with different bug id) because they >> would not run with Java Graal (for example, they use --limit-modules flag which prevents loading Graal module). We >> will enable such tests again when libgraal is supported. >> >> I ran testing which execute these tests with Graal. It shows only known problems which are not related to these changes. >> >> Thanks, >> Vladimir >> >> [1] http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 > From sean.mullan at oracle.com Thu Jun 20 20:40:57 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 20 Jun 2019 16:40:57 -0400 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com> Message-ID: <1f43fbbd-cf86-b3cd-af41-9155bdd05dbd@oracle.com> Sorry, I'm just catching up and looking at this now. The one thing I don't like about these tests that use their own Policy implementation is that the permissions that are granted inside the test are granted to all code, and not just the test, which may lead to cases where permissions that should be granted to JDK modules in default.policy may be missed. In tests that use policy files, we should grant permissions to only the test, for example: grant codebase "file:${test.classes}/.../-" { permission ...; }; However, in looking through our policy files, there are many that are not doing that. Something to fix, so I'll file a bug. This could also be fixed in these tests by inspecting the CodeSource of the ProtectionDomain. Or better yet, they should just use the jtreg java.security.policy option and a policy file and avoid the need to create a Policy implementation. Thanks, Sean On 6/20/19 11:04 AM, Mandy Chung wrote: > The Policy API does not assume the presence of the default policy for > the runtime to use. > > jdk.internal.vm.compiler already uses doPrivileged.?? The module ends up > with no permission as the test policy does not consult the default policy. > > Mandy > > On 6/20/19 6:32 AM, Roger Riggs wrote: >> Hi, >> >> If this were java.base, we would use doPrivilege to ignore the policy >> and place specific limits. >> Encumbering the default policy with conditions needed by a trusted >> subsystem seems >> like distributing what should be a local implementation issue. >> >> $.02, Roger >> >> On 6/20/19 2:23 AM, Mandy Chung wrote: >>> Hi Vladimir, >>> >>> Indeed these are test issues that the tests will need to grant >>> permissions >>> to jdk.internal.vm.compiler as the default policy grants. >>> >>> Thanks for going extra miles to fix the tests. >>> >>> My suggestion may be a bit general.? What I intend to say the custom >>> security policy should extend the default policy unless it intentionally >>> excludes configuring permissions for specific modules.? I review the >>> the patch but the test doesn't clearly tell what the test intends to >>> do w.r.t. security configuration. >>> >>> We should avoid inadvertently granting permissions that the test expects >>> to disallow.? A better solution is to limit granting permissions just >>> for >>> `jdk.internal.vm.compiler` module rather than all. >>> >>> Attached is ModulePolicy class that allows you to get the Policy for >>> a specific module. It can be put in the test library that these tests >>> can use them. >>> >>> So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and >>> implies method will call the returned ModulePolicy if present. >>> >>> test/lib/jdk/test/lib/security is one existing testlibrary for security >>> related stuff.? You can consider putting ModulePolicy.java there. >>> >>> This is one idea. >>> >>> Mandy >>> >>> On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8185139 >>>> >>>> For Graal to work we have to give Graal module all permissions which >>>> is specified in default policy [1]. >>>> Unfortunately this cause problem for Graal running tests which >>>> overwrite default policy. >>>> >>>> I discussed this with Mandy and she suggested that such tests should >>>> also check default policy. I implemented her suggestion. Note, this >>>> is not only Graal problem. There were already similar fixes before [2]. >>>> >>>> I also updated Graal's problem list. Several tests were left on >>>> problem list (with different bug id) because they would not run with >>>> Java Graal (for example, they use --limit-modules flag which >>>> prevents loading Graal module). We will enable such tests again when >>>> libgraal is supported. >>>> >>>> I ran testing which execute these tests with Graal. It shows only >>>> known problems which are not related to these changes. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >>>> >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 >>> >> > From shravya.rukmannagari at intel.com Fri Jun 21 00:17:14 2019 From: shravya.rukmannagari at intel.com (Rukmannagari, Shravya) Date: Fri, 21 Jun 2019 00:17:14 +0000 Subject: JMH Tests Support for JDK-8222074 In-Reply-To: References: <8D6F463991A1574A8A803B8DA605414F3A8D88B2@ORSMSX111.amr.corp.intel.com> Message-ID: <8D6F463991A1574A8A803B8DA605414F4116ECE1@ORSMSX111.amr.corp.intel.com> Hi Vladimir, Thank you for reviewing the patch. I have updated the patch as per your comments. Please let me know if you have any questions or comments. http://cr.openjdk.java.net/~srukmannagar/JMHTests/webrev.02/ Thanks, Shravya. -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Tuesday, June 18, 2019 7:24 AM To: Rukmannagari, Shravya ; hotspot compiler Subject: Re: JMH Tests Support for JDK-8222074 > Webrev: http://cr.openjdk.java.net/~srukmannagar/JMHTests/webrev/ Some comments: 35 private static final int COUNT = 1024; I'd prefer to see a parameter (@Param) instead of hard-coded value and different input sizes to be tested (e.g., fits into L1/L2/L3, memory-bound case). 50 private Random r = new Random(); In general, it's a good practice (for diagnostic purposes) to either fix the seed or allow to specify it from command line. For example, you could introduce additional parameter (@Param seed) and randomize it when "seed == 0". In that case, it should be printed into the log, so it's possible to rerun the benchmark with the same seed. Otherwise, looks good! Best regards, Vladimir Ivanov From mandy.chung at oracle.com Fri Jun 21 01:02:59 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Jun 2019 18:02:59 -0700 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <1f43fbbd-cf86-b3cd-af41-9155bdd05dbd@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com> <1f43fbbd-cf86-b3cd-af41-9155bdd05dbd@oracle.com> Message-ID: <13602729-7b19-c198-2c62-0a02d7580d27@oracle.com> On 6/20/19 1:40 PM, Sean Mullan wrote: > Sorry, I'm just catching up and looking at this now. > > The one thing I don't like about these tests that use their own Policy > implementation is that the permissions that are granted inside the > test are granted to all code, and not just the test, which may lead to > cases where permissions that should be granted to JDK modules in > default.policy may be missed. > When the test wants a fine-control on turning on security manager programmatically and test various security permission combinations, I prefer to use a custom Policy implementation. Otherwise, I have to maintain multiple different test.policy files to test different permission combination which will be prone to editing error. I think we should provide a test library to help building a custom Policy implementation that can take the default policy, preferrably the policy for the resolved modules such that the test can focus its logic of security configuration and does not need to code with the system modules in mind. That's what I started with ModulePolicy and could potentially build up test library for configuring security permissions programmatically. Mandy > In tests that use policy files, we should grant permissions to only > the test, for example: > > ? grant codebase "file:${test.classes}/.../-" { > ??? permission ...; > ? }; > > However, in looking through our policy files, there are many that are > not doing that. Something to fix, so I'll file a bug. > > This could also be fixed in these tests by inspecting the CodeSource > of the ProtectionDomain. Or better yet, they should just use the jtreg > java.security.policy option and a policy file and avoid the need to > create a Policy implementation. > > Thanks, > Sean > > > On 6/20/19 11:04 AM, Mandy Chung wrote: >> The Policy API does not assume the presence of the default policy for >> the runtime to use. >> >> jdk.internal.vm.compiler already uses doPrivileged.?? The module ends up >> with no permission as the test policy does not consult the default >> policy. >> >> Mandy >> >> On 6/20/19 6:32 AM, Roger Riggs wrote: >>> Hi, >>> >>> If this were java.base, we would use doPrivilege to ignore the >>> policy and place specific limits. >>> Encumbering the default policy with conditions needed by a trusted >>> subsystem seems >>> like distributing what should be a local implementation issue. >>> >>> $.02, Roger >>> >>> On 6/20/19 2:23 AM, Mandy Chung wrote: >>>> Hi Vladimir, >>>> >>>> Indeed these are test issues that the tests will need to grant >>>> permissions >>>> to jdk.internal.vm.compiler as the default policy grants. >>>> >>>> Thanks for going extra miles to fix the tests. >>>> >>>> My suggestion may be a bit general.? What I intend to say the custom >>>> security policy should extend the default policy unless it >>>> intentionally >>>> excludes configuring permissions for specific modules.? I review the >>>> the patch but the test doesn't clearly tell what the test intends to >>>> do w.r.t. security configuration. >>>> >>>> We should avoid inadvertently granting permissions that the test >>>> expects >>>> to disallow.? A better solution is to limit granting permissions >>>> just for >>>> `jdk.internal.vm.compiler` module rather than all. >>>> >>>> Attached is ModulePolicy class that allows you to get the Policy for >>>> a specific module. It can be put in the test library that these tests >>>> can use them. >>>> >>>> So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and >>>> implies method will call the returned ModulePolicy if present. >>>> >>>> test/lib/jdk/test/lib/security is one existing testlibrary for >>>> security >>>> related stuff.? You can consider putting ModulePolicy.java there. >>>> >>>> This is one idea. >>>> >>>> Mandy >>>> >>>> On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8185139 >>>>> >>>>> For Graal to work we have to give Graal module all permissions >>>>> which is specified in default policy [1]. >>>>> Unfortunately this cause problem for Graal running tests which >>>>> overwrite default policy. >>>>> >>>>> I discussed this with Mandy and she suggested that such tests >>>>> should also check default policy. I implemented her suggestion. >>>>> Note, this is not only Graal problem. There were already similar >>>>> fixes before [2]. >>>>> >>>>> I also updated Graal's problem list. Several tests were left on >>>>> problem list (with different bug id) because they would not run >>>>> with Java Graal (for example, they use --limit-modules flag which >>>>> prevents loading Graal module). We will enable such tests again >>>>> when libgraal is supported. >>>>> >>>>> I ran testing which execute these tests with Graal. It shows only >>>>> known problems which are not related to these changes. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >>>>> >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 >>>> >>> >> From mandy.chung at oracle.com Fri Jun 21 01:20:28 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Jun 2019 18:20:28 -0700 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <53c2c755-572f-c76e-5872-6bd6ed8914b8@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <53c2c755-572f-c76e-5872-6bd6ed8914b8@oracle.com> Message-ID: Hi Vladimir, As long as the owner of the test review the patch and confirm the test policy intends to extend the default policy, those test change will be fine. test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java 417 DEFAULT_POLICY.implies(domain, permission)) return true; Nit: separating this to a new if-case after 426 to make it distinct. I reviewedtest/jdk/java/lang/Class/getDeclaredField/* and test/jdk/java/lang/invoke/* patch and they look fine. My suggestion is to minimize the risk of your patch.? Since Daniel has reviewed the logging test change (which is the bulk of this patch), I have no issue if the reviewers approve this patch.? I will file a separate RFE for the test library idea. Mandy On 6/20/19 11:05 AM, Vladimir Kozlov wrote: > Hi Mandy > > I am not sure about this suggestion. Graal module may not be present > in the JDK (on SPARC for example). > And I don't want pollute general tests with Graal specific code: > ModulePolicy.get("jdk.internal.vm.compiler"). > > If you or other have concerns about some tests looking on default > policy I can keep them on problem list to run them later only with > libgraal. > > I found only 2 closed tests in which I had doubt about using default > policy. I kept them on problem list. > Other tests, as I understand, manipulate permissions for test classes. > They don't extend system classes so default policy should not affect > test class permissions. > > Thanks, > Vladimir > > On 6/19/19 11:23 PM, Mandy Chung wrote: >> Hi Vladimir, >> >> Indeed these are test issues that the tests will need to grant >> permissions >> to jdk.internal.vm.compiler as the default policy grants. >> >> Thanks for going extra miles to fix the tests. >> >> My suggestion may be a bit general.? What I intend to say the custom >> security policy should extend the default policy unless it intentionally >> excludes configuring permissions for specific modules.? I review the >> the patch but the test doesn't clearly tell what the test intends to >> do w.r.t. security configuration. >> >> We should avoid inadvertently granting permissions that the test expects >> to disallow.? A better solution is to limit granting permissions just >> for >> `jdk.internal.vm.compiler` module rather than all. >> >> Attached is ModulePolicy class that allows you to get the Policy for >> a specific module. It can be put in the test library that these tests >> can use them. >> >> So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and >> implies method will call the returned ModulePolicy if present. >> >> test/lib/jdk/test/lib/security is one existing testlibrary for security >> related stuff.? You can consider putting ModulePolicy.java there. >> >> This is one idea. >> >> Mandy >> >> On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8185139 >>> >>> For Graal to work we have to give Graal module all permissions which >>> is specified in default policy [1]. >>> Unfortunately this cause problem for Graal running tests which >>> overwrite default policy. >>> >>> I discussed this with Mandy and she suggested that such tests should >>> also check default policy. I implemented her suggestion. Note, this >>> is not only Graal problem. There were already similar fixes before [2]. >>> >>> I also updated Graal's problem list. Several tests were left on >>> problem list (with different bug id) because they would not run with >>> Java Graal (for example, they use --limit-modules flag which >>> prevents loading Graal module). We will enable such tests again when >>> libgraal is supported. >>> >>> I ran testing which execute these tests with Graal. It shows only >>> known problems which are not related to these changes. >>> >>> Thanks, >>> Vladimir >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 >> From vladimir.kozlov at oracle.com Fri Jun 21 02:16:27 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Jun 2019 19:16:27 -0700 Subject: [14] RFR(M) 8225810: Update JVMCI Message-ID: <46860d89-1d42-2d1e-b617-f5488b40204c@oracle.com> https://cr.openjdk.java.net/~kvn/8225810/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8225810 Sync latest changes from graal-jvmci-8. Tested with tier1-3. Thanks, Vladimir From david.holmes at oracle.com Fri Jun 21 04:18:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Jun 2019 21:18:42 -0700 Subject: RFR: 8225351(13): assert failed: Revoke failed, unhandled biased lock state In-Reply-To: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> References: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com> Message-ID: Hi Robbin, The other discussion has helped clarify some things but I still have an issue with the initial starting premise: "We may have a stack lock biased against another thread until ObjectSynchronizer::fast_enter returns." How do we get a "stack lock" if the object is biased to another thread? Doesn't the locking attempt first try to see if the object is already biased towards the current thread, and if it finds it is biased towards another thread it will first revoke that bias? That aside, it seems to me that Deoptimization::revoke_using_handshake implies that upon return all Monitors found in the frame map are guaranteed to be unbiased. But that is not the case as we are only revoking biases that are towards the given thread. This breaks the symmetry/duality we have with Deoptimization::revoke_using_safepoint. It is not clear to me when the bias in that case will actually be revoked. A minor nit: 1456 void lock_in_top_frame(Handle ho, JavaThread* thread) { This might read better as check_lock_in_top_frame, else "lock" sounds like an action. Also this file doesn't use the h_x style for naming Handles, so ho could just be o, though I'd personally prefer h_o, or better h_obj. Thanks, David ----- On 14/06/2019 1:03 am, Robbin Ehn wrote: > Hi all, please review. > > When looking at a JavaThreads locks we retrieve them per frame via it's > monitors > list. How this list actually populated differs from frame type. If a > JavaThread tries to enter a new monitor a basic lock is > directly/indirectly via e.g. scope info added to the virtual monitor > list. If this lock is biased towards another > JavaThread we try to revoke that bias with a safepoint. In this case a > deopt > handshake is already in queue. The handshake is thus executed before the > revoke > safepoint. > The handshake goes over the monitors in compiled frames, find this lock > and we > hit the assert. The assert make sure we actual can revoke the lock. A > basic lock > on stack should always, if biased, be biased to current thread, with the > exception: > We may have a stack lock biased against another thread until > ObjectSynchronizer::fast_enter returns. > > To handle this exception we can safely ignore biased lock towards other > threads > in the deopt handshake. Since such locks will always be revoked before we > deopt/unpack stack. > > Code: > http://cr.openjdk.java.net/~rehn/8225351/v1/webrev/index.html > Issue: > https://bugs.openjdk.java.net/browse/JDK-8225351 > > Passes t1-7 > The assert code tested with local code changes to HandshakeAlot handshake. > We then see this state where last lock can be biased towards another > thread and the thread is trying to execute revoke safepoint. > > Thanks, Robbin From daniel.fuchs at oracle.com Fri Jun 21 11:15:46 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 21 Jun 2019 12:15:46 +0100 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <1f43fbbd-cf86-b3cd-af41-9155bdd05dbd@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com> <1f43fbbd-cf86-b3cd-af41-9155bdd05dbd@oracle.com> Message-ID: <09a8dedf-be7c-a685-fe2d-710942851502@oracle.com> Hi Sean, On 20/06/2019 21:40, Sean Mullan wrote: This could also be fixed in these tests by inspecting the CodeSource of > the ProtectionDomain. Or better yet, they should just use the jtreg > java.security.policy option and a policy file and avoid the need to > create a Policy implementation. In what logging tests are concerned that would be quite an undertaking. For those tests, part of the test need to have permission to change the configuration, and part of the test need to not have the permission to double check that either the permission is not required for those operations, or that the permission is checked - if it is required. Hence the use of a custom Policy implementation that uses ThreadLocale to figure out whether to grant or deny permissions. best regards, -- daniel > > Thanks, > Sean > > > On 6/20/19 11:04 AM, Mandy Chung wrote: >> The Policy API does not assume the presence of the default policy for >> the runtime to use. >> >> jdk.internal.vm.compiler already uses doPrivileged.?? The module ends up >> with no permission as the test policy does not consult the default >> policy. >> >> Mandy >> >> On 6/20/19 6:32 AM, Roger Riggs wrote: >>> Hi, >>> >>> If this were java.base, we would use doPrivilege to ignore the policy >>> and place specific limits. >>> Encumbering the default policy with conditions needed by a trusted >>> subsystem seems >>> like distributing what should be a local implementation issue. >>> >>> $.02, Roger >>> >>> On 6/20/19 2:23 AM, Mandy Chung wrote: >>>> Hi Vladimir, >>>> >>>> Indeed these are test issues that the tests will need to grant >>>> permissions >>>> to jdk.internal.vm.compiler as the default policy grants. >>>> >>>> Thanks for going extra miles to fix the tests. >>>> >>>> My suggestion may be a bit general.? What I intend to say the custom >>>> security policy should extend the default policy unless it >>>> intentionally >>>> excludes configuring permissions for specific modules.? I review the >>>> the patch but the test doesn't clearly tell what the test intends to >>>> do w.r.t. security configuration. >>>> >>>> We should avoid inadvertently granting permissions that the test >>>> expects >>>> to disallow.? A better solution is to limit granting permissions >>>> just for >>>> `jdk.internal.vm.compiler` module rather than all. >>>> >>>> Attached is ModulePolicy class that allows you to get the Policy for >>>> a specific module. It can be put in the test library that these tests >>>> can use them. >>>> >>>> So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and >>>> implies method will call the returned ModulePolicy if present. >>>> >>>> test/lib/jdk/test/lib/security is one existing testlibrary for security >>>> related stuff.? You can consider putting ModulePolicy.java there. >>>> >>>> This is one idea. >>>> >>>> Mandy >>>> >>>> On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8185139 >>>>> >>>>> For Graal to work we have to give Graal module all permissions >>>>> which is specified in default policy [1]. >>>>> Unfortunately this cause problem for Graal running tests which >>>>> overwrite default policy. >>>>> >>>>> I discussed this with Mandy and she suggested that such tests >>>>> should also check default policy. I implemented her suggestion. >>>>> Note, this is not only Graal problem. There were already similar >>>>> fixes before [2]. >>>>> >>>>> I also updated Graal's problem list. Several tests were left on >>>>> problem list (with different bug id) because they would not run >>>>> with Java Graal (for example, they use --limit-modules flag which >>>>> prevents loading Graal module). We will enable such tests again >>>>> when libgraal is supported. >>>>> >>>>> I ran testing which execute these tests with Graal. It shows only >>>>> known problems which are not related to these changes. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >>>>> >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 >>>> >>> >> From dmitrij.pochepko at bell-sw.com Fri Jun 21 12:34:35 2019 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 21 Jun 2019 15:34:35 +0300 Subject: RFR: 8223173: Implement fast class initialization checks on AARCH64 Message-ID: Hi all, please review patch for enhancement: JDK-8223173 - Implement fast class initialization checks on AARCH64 CR: https://bugs.openjdk.java.net/browse/JDK-8223173 webrev: http://cr.openjdk.java.net/~dpochepk/8223173/webrev.01/ This patch follows x86-64 patch (JDK-8223213) and later bugfix (JDK-8225106). Also, leading nop generation in C1 is moved from build_frame method to verified_entry method to follow x86_64 implementation and use clinit_barrier correctly (see invocation of clinit_barrier in hotspot/share/c1/c1_LIRAssembler.cpp) Original performance issue reported by JDK-8219233 is resolved (x3 improvement for reported case on AARCH64). Testing: - hotspot jtreg tests both in release and fastdebug modes: no regressions found - jck tests in release and fastdebug modes: no regressions found Please review this fix for JDK 14. Once this is in, I'd like to request approval for backporting to JDK 13 since corresponding fixes for x86_64 and PPC are in JDK 13 already, unless the community feels otherwise. Thanks, Dmitrij From aph at redhat.com Fri Jun 21 13:28:39 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Jun 2019 14:28:39 +0100 Subject: [aarch64-port-dev ] RFR: 8223173: Implement fast class initialization checks on AARCH64 In-Reply-To: References: Message-ID: <2431209e-42ed-4a83-f3a9-e76916b07734@redhat.com> On 6/21/19 1:34 PM, Dmitrij Pochepko wrote: > Please review this fix for JDK 14. Once this is in, I'd like to request > approval for backporting to JDK 13 since corresponding fixes for x86_64 > and PPC are in JDK 13 already, unless the community feels otherwise. Please don't use aliases for scratch registers unless it's necessary: + { // Bypass the barrier for non-static methods + Register flags = rscratch1; + __ ldrw(flags, Address(rmethod, Method::access_flags_offset())); + __ andsw(zr, flags, JVM_ACC_STATIC); + __ br(Assembler::EQ, L_skip_barrier); // non-static + } The use of rscratch1 and rscratch2 in clinit_barrier() is very tricky. It would be safer to write clinit_barrier() in a way that uses no scratch registers other than the ones that it is passed. Register thread should not be an argument. So, declare MacroAssembler::clinit_barrier as: void MacroAssembler::clinit_barrier(Register klass, Register scratch, Label* L_fast_path, Label* L_slow_path) { Otherwise this looks OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sean.mullan at oracle.com Fri Jun 21 14:36:52 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Jun 2019 10:36:52 -0400 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <09a8dedf-be7c-a685-fe2d-710942851502@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com> <1f43fbbd-cf86-b3cd-af41-9155bdd05dbd@oracle.com> <09a8dedf-be7c-a685-fe2d-710942851502@oracle.com> Message-ID: <3219e59e-160d-14e3-88f2-e9c047cb0013@oracle.com> On 6/21/19 7:15 AM, Daniel Fuchs wrote: > Hi Sean, > > On 20/06/2019 21:40, Sean Mullan wrote: > ?This could also be fixed in these tests by inspecting the CodeSource of >> the ProtectionDomain. Or better yet, they should just use the jtreg >> java.security.policy option and a policy file and avoid the need to >> create a Policy implementation. > > In what logging tests are concerned that would be quite an undertaking. > For those tests, part of the test need to have permission to change > the configuration, and part of the test need to not have the > permission to double check that either the permission is not > required for those operations, or that the permission is checked - if > it is required. > > Hence the use of a custom Policy implementation that uses > ThreadLocale to figure out whether to grant or > deny permissions. Ok, I see that is challenging, and I understand why you had to do that. You probably could have done something similar by breaking up the test into multiple classes in separate directories (or jars) with different ProtectionDomains, but that would require a bit of work, and maybe it is overkill. But I think then you could probably use the JDK Policy provider with a single policy file. (I'm not suggesting doing this right now, just was wondering if you considered this). --Sean > > best regards, > > -- daniel > >> >> Thanks, >> Sean >> >> >> On 6/20/19 11:04 AM, Mandy Chung wrote: >>> The Policy API does not assume the presence of the default policy for >>> the runtime to use. >>> >>> jdk.internal.vm.compiler already uses doPrivileged.?? The module ends up >>> with no permission as the test policy does not consult the default >>> policy. >>> >>> Mandy >>> >>> On 6/20/19 6:32 AM, Roger Riggs wrote: >>>> Hi, >>>> >>>> If this were java.base, we would use doPrivilege to ignore the >>>> policy and place specific limits. >>>> Encumbering the default policy with conditions needed by a trusted >>>> subsystem seems >>>> like distributing what should be a local implementation issue. >>>> >>>> $.02, Roger >>>> >>>> On 6/20/19 2:23 AM, Mandy Chung wrote: >>>>> Hi Vladimir, >>>>> >>>>> Indeed these are test issues that the tests will need to grant >>>>> permissions >>>>> to jdk.internal.vm.compiler as the default policy grants. >>>>> >>>>> Thanks for going extra miles to fix the tests. >>>>> >>>>> My suggestion may be a bit general.? What I intend to say the custom >>>>> security policy should extend the default policy unless it >>>>> intentionally >>>>> excludes configuring permissions for specific modules.? I review the >>>>> the patch but the test doesn't clearly tell what the test intends to >>>>> do w.r.t. security configuration. >>>>> >>>>> We should avoid inadvertently granting permissions that the test >>>>> expects >>>>> to disallow.? A better solution is to limit granting permissions >>>>> just for >>>>> `jdk.internal.vm.compiler` module rather than all. >>>>> >>>>> Attached is ModulePolicy class that allows you to get the Policy for >>>>> a specific module. It can be put in the test library that these tests >>>>> can use them. >>>>> >>>>> So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and >>>>> implies method will call the returned ModulePolicy if present. >>>>> >>>>> test/lib/jdk/test/lib/security is one existing testlibrary for >>>>> security >>>>> related stuff.? You can consider putting ModulePolicy.java there. >>>>> >>>>> This is one idea. >>>>> >>>>> Mandy >>>>> >>>>> On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8185139 >>>>>> >>>>>> For Graal to work we have to give Graal module all permissions >>>>>> which is specified in default policy [1]. >>>>>> Unfortunately this cause problem for Graal running tests which >>>>>> overwrite default policy. >>>>>> >>>>>> I discussed this with Mandy and she suggested that such tests >>>>>> should also check default policy. I implemented her suggestion. >>>>>> Note, this is not only Graal problem. There were already similar >>>>>> fixes before [2]. >>>>>> >>>>>> I also updated Graal's problem list. Several tests were left on >>>>>> problem list (with different bug id) because they would not run >>>>>> with Java Graal (for example, they use --limit-modules flag which >>>>>> prevents loading Graal module). We will enable such tests again >>>>>> when libgraal is supported. >>>>>> >>>>>> I ran testing which execute these tests with Graal. It shows only >>>>>> known problems which are not related to these changes. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >>>>>> >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 >>>>> >>>> >>> > From sean.mullan at oracle.com Fri Jun 21 14:39:35 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Jun 2019 10:39:35 -0400 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <13602729-7b19-c198-2c62-0a02d7580d27@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com> <1f43fbbd-cf86-b3cd-af41-9155bdd05dbd@oracle.com> <13602729-7b19-c198-2c62-0a02d7580d27@oracle.com> Message-ID: On 6/20/19 9:02 PM, Mandy Chung wrote: > On 6/20/19 1:40 PM, Sean Mullan wrote: >> Sorry, I'm just catching up and looking at this now. >> >> The one thing I don't like about these tests that use their own Policy >> implementation is that the permissions that are granted inside the >> test are granted to all code, and not just the test, which may lead to >> cases where permissions that should be granted to JDK modules in >> default.policy may be missed. >> > > When the test wants a fine-control on turning on security manager > programmatically and test various security permission combinations, > I prefer to use a custom Policy implementation. > > Otherwise, I have to maintain multiple different test.policy files to > test different permission combination which will be prone to editing > error. > > I think we should provide a test library to help building a custom Policy > implementation that can take the default policy, preferrably the policy > for the resolved modules such that the test can focus its logic of > security configuration and does not need to code with the system > modules in mind. It seems a little related to https://bugs.openjdk.java.net/browse/JDK-8080294 --Sean > > That's what I started with ModulePolicy and could potentially build up > test library for configuring security permissions programmatically. > > Mandy > >> In tests that use policy files, we should grant permissions to only >> the test, for example: >> >> ? grant codebase "file:${test.classes}/.../-" { >> ??? permission ...; >> ? }; >> >> However, in looking through our policy files, there are many that are >> not doing that. Something to fix, so I'll file a bug. >> >> This could also be fixed in these tests by inspecting the CodeSource >> of the ProtectionDomain. Or better yet, they should just use the jtreg >> java.security.policy option and a policy file and avoid the need to >> create a Policy implementation. >> >> Thanks, >> Sean >> >> >> On 6/20/19 11:04 AM, Mandy Chung wrote: >>> The Policy API does not assume the presence of the default policy for >>> the runtime to use. >>> >>> jdk.internal.vm.compiler already uses doPrivileged.?? The module ends up >>> with no permission as the test policy does not consult the default >>> policy. >>> >>> Mandy >>> >>> On 6/20/19 6:32 AM, Roger Riggs wrote: >>>> Hi, >>>> >>>> If this were java.base, we would use doPrivilege to ignore the >>>> policy and place specific limits. >>>> Encumbering the default policy with conditions needed by a trusted >>>> subsystem seems >>>> like distributing what should be a local implementation issue. >>>> >>>> $.02, Roger >>>> >>>> On 6/20/19 2:23 AM, Mandy Chung wrote: >>>>> Hi Vladimir, >>>>> >>>>> Indeed these are test issues that the tests will need to grant >>>>> permissions >>>>> to jdk.internal.vm.compiler as the default policy grants. >>>>> >>>>> Thanks for going extra miles to fix the tests. >>>>> >>>>> My suggestion may be a bit general.? What I intend to say the custom >>>>> security policy should extend the default policy unless it >>>>> intentionally >>>>> excludes configuring permissions for specific modules.? I review the >>>>> the patch but the test doesn't clearly tell what the test intends to >>>>> do w.r.t. security configuration. >>>>> >>>>> We should avoid inadvertently granting permissions that the test >>>>> expects >>>>> to disallow.? A better solution is to limit granting permissions >>>>> just for >>>>> `jdk.internal.vm.compiler` module rather than all. >>>>> >>>>> Attached is ModulePolicy class that allows you to get the Policy for >>>>> a specific module. It can be put in the test library that these tests >>>>> can use them. >>>>> >>>>> So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and >>>>> implies method will call the returned ModulePolicy if present. >>>>> >>>>> test/lib/jdk/test/lib/security is one existing testlibrary for >>>>> security >>>>> related stuff.? You can consider putting ModulePolicy.java there. >>>>> >>>>> This is one idea. >>>>> >>>>> Mandy >>>>> >>>>> On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8185139 >>>>>> >>>>>> For Graal to work we have to give Graal module all permissions >>>>>> which is specified in default policy [1]. >>>>>> Unfortunately this cause problem for Graal running tests which >>>>>> overwrite default policy. >>>>>> >>>>>> I discussed this with Mandy and she suggested that such tests >>>>>> should also check default policy. I implemented her suggestion. >>>>>> Note, this is not only Graal problem. There were already similar >>>>>> fixes before [2]. >>>>>> >>>>>> I also updated Graal's problem list. Several tests were left on >>>>>> problem list (with different bug id) because they would not run >>>>>> with Java Graal (for example, they use --limit-modules flag which >>>>>> prevents loading Graal module). We will enable such tests again >>>>>> when libgraal is supported. >>>>>> >>>>>> I ran testing which execute these tests with Graal. It shows only >>>>>> known problems which are not related to these changes. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >>>>>> >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 >>>>> >>>> >>> > From daniel.fuchs at oracle.com Fri Jun 21 16:29:33 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 21 Jun 2019 17:29:33 +0100 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: <3219e59e-160d-14e3-88f2-e9c047cb0013@oracle.com> References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com> <1f43fbbd-cf86-b3cd-af41-9155bdd05dbd@oracle.com> <09a8dedf-be7c-a685-fe2d-710942851502@oracle.com> <3219e59e-160d-14e3-88f2-e9c047cb0013@oracle.com> Message-ID: <7bc248a1-196b-7c27-4f8f-defd52957728@oracle.com> Hi Sean, On 21/06/2019 15:36, Sean Mullan wrote: > Ok, I see that is challenging, and I understand why you had to do that. > You probably could have done something similar by breaking up the test > into multiple classes in separate directories (or jars) with different > ProtectionDomains, but that would require a bit of work, and maybe it is > overkill. But I think then you could probably use the JDK Policy > provider with a single policy file. (I'm not suggesting doing this right > now, just was wondering if you considered this). > Yes - I considered it - but then it makes the test much more difficult to understand (as its logic is split over several files) - and requires either invoking the compiler from within the test or moving classes around after jtreg has compiled them in a @driver command so that you can actually have different codesource locations. Using a custom Policy implementation looked much simpler at the time. And when you've done it once - well - copy & paste is your friend... If there comes a time where having a custom policy implementation becomes a maintenance issue and a technical debt then we/I will need to take what time is required to revisit. But I'd rather not do it if it's not a necessity. best regards, -- daniel From tom.rodriguez at oracle.com Fri Jun 21 16:35:01 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Jun 2019 09:35:01 -0700 Subject: [14] RFR(M) 8225810: Update JVMCI In-Reply-To: <46860d89-1d42-2d1e-b617-f5488b40204c@oracle.com> References: <46860d89-1d42-2d1e-b617-f5488b40204c@oracle.com> Message-ID: <0f1b517f-7169-e10d-f632-91be603bb900@oracle.com> Looks good. tom Vladimir Kozlov wrote on 6/20/19 7:16 PM: > https://cr.openjdk.java.net/~kvn/8225810/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8225810 > > Sync latest changes from graal-jvmci-8. > > Tested with tier1-3. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Jun 21 16:42:04 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Jun 2019 09:42:04 -0700 Subject: [14] RFR(M) 8225810: Update JVMCI In-Reply-To: <0f1b517f-7169-e10d-f632-91be603bb900@oracle.com> References: <46860d89-1d42-2d1e-b617-f5488b40204c@oracle.com> <0f1b517f-7169-e10d-f632-91be603bb900@oracle.com> Message-ID: <4789335a-ef2c-1d5a-665e-ba5010acfd9e@oracle.com> Thank you, Tom. Vladimir On 6/21/19 9:35 AM, Tom Rodriguez wrote: > Looks good. > > tom > > Vladimir Kozlov wrote on 6/20/19 7:16 PM: >> https://cr.openjdk.java.net/~kvn/8225810/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8225810 >> >> Sync latest changes from graal-jvmci-8. >> >> Tested with tier1-3. >> >> Thanks, >> Vladimir From tom.rodriguez at oracle.com Fri Jun 21 16:42:34 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Jun 2019 09:42:34 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: References: Message-ID: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> Doesn't that make resolveConstantInPool completely unused? It should probably be deleted and the javadoc updated for resolvePossiblyCachedConstantInPool. tom dean.long at oracle.com wrote on 6/18/19 10:52 AM: > https://bugs.openjdk.java.net/browse/JDK-8225369 > http://cr.openjdk.java.net/~dlong/8225369/webrev/ > > This test triggers a race, which can result in different resolved values > of the MethodHandle constant.? The VM chooses a winner and stores that > value in the constant pool cache, however Graal is not checking the > cache.? The trivial fix is to use the proper API that goes through the > cache. > > dl From dmitrij.pochepko at bell-sw.com Fri Jun 21 17:57:15 2019 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 21 Jun 2019 20:57:15 +0300 Subject: [aarch64-port-dev ] RFR: 8223173: Implement fast class initialization checks on AARCH64 In-Reply-To: <2431209e-42ed-4a83-f3a9-e76916b07734@redhat.com> References: <2431209e-42ed-4a83-f3a9-e76916b07734@redhat.com> Message-ID: <414db280-0d8c-4d70-522b-719ac4e87fda@bell-sw.com> On 21/06/2019 4:28 PM, Andrew Haley wrote: > On 6/21/19 1:34 PM, Dmitrij Pochepko wrote: > >> Please review this fix for JDK 14. Once this is in, I'd like to request >> approval for backporting to JDK 13 since corresponding fixes for x86_64 >> and PPC are in JDK 13 already, unless the community feels otherwise. > Please don't use aliases for scratch registers unless it's necessary: > > + { // Bypass the barrier for non-static methods > + Register flags = rscratch1; > + __ ldrw(flags, Address(rmethod, Method::access_flags_offset())); > + __ andsw(zr, flags, JVM_ACC_STATIC); > + __ br(Assembler::EQ, L_skip_barrier); // non-static > + } > > The use of rscratch1 and rscratch2 in clinit_barrier() is very tricky. It > would be safer to write clinit_barrier() in a way that uses no scratch > registers other than the ones that it is passed. > > Register thread should not be an argument. > > So, declare MacroAssembler::clinit_barrier as: > > void MacroAssembler::clinit_barrier(Register klass, Register scratch, Label* L_fast_path, Label* L_slow_path) { > > Otherwise this looks OK, thanks. > webrev 02 with with aliases removed and clinit_barrier declaration and invocation changed: http://cr.openjdk.java.net/~dpochepk/8223173/webrev.02/ I also ran hotspot jtreg tier1-3 tests in fastdebug mode as sanity check Thanks, Dmitrij From dean.long at oracle.com Fri Jun 21 19:48:25 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 21 Jun 2019 12:48:25 -0700 Subject: RFR (S) 8222446: assert(C->env()->system_dictionary_modification_counter_changed()) failed: Must invalidate if TypeFuncs differ In-Reply-To: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com> References: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com> Message-ID: For the most part, this looks good.? I only have a couple concerns: 1) The distinction in both validate_compile_task_dependencies functions between "dependencies failed" and "dependencies invalid" is even more fuzzy after this change.? I suggest filing an RFE to remove this distinction. 2) In Parse::do_exits(), we don't know that concurrent class loading didn't cause the problem.? We should be optimistic and allow the retry: C->record_failure(C2Compiler::retry_class_loading_during_parsing()); rather than more drastic ??? C->record_method_not_compilable This is actually what the code did in an earlier revision. dl On 6/20/19 10:28 AM, coleen.phillimore at oracle.com wrote: > Summary: Remove SystemDictionary::modification_counter optimization > > See bug for more details.? To avoid the assert in the bug report, it's > necessary to also increase the modification counter for class > unloading, which needs special code for concurrent class unloading. > The global counter is used to verify that validate_dependencies() gets > the same answer based on the subklass hierarchy, but provides a quick > exit in production mode.? Removing it may allow more nmethods to be > created that don't depend on the classes that may be loaded while the > Method is being compiled. Performance testing was done on this with no > change in performance.? Also investigated the breakpoint setting code > which incremented the modification counter. Dependent compilations are > invalidated using evol_method dependencies, so updating the system > dictionary modification counter isn't unnecessary. > > Tested with hs-tier1-8 testing, and CTW, and local jvmti/jdi/jdwp test > runs with -Xcomp. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222446.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8222446 > > Thanks, > Coleen From vladimir.kozlov at oracle.com Fri Jun 21 19:56:05 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Jun 2019 12:56:05 -0700 Subject: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal In-Reply-To: References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com> <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com> <53c2c755-572f-c76e-5872-6bd6ed8914b8@oracle.com> Message-ID: <148d6e78-609d-04fe-bcac-710b7d08615a@oracle.com> Thank you, Mandy On 6/20/19 6:20 PM, Mandy Chung wrote: > Hi Vladimir, > > As long as the owner of the test review the patch and confirm the > test policy intends to extend the default policy, those test change > will be fine. > > test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java > > 417 DEFAULT_POLICY.implies(domain, permission)) return true; Nit: separating this to a new if-case after 426 to make it > distinct. I did as you suggested: @@ -420,6 +422,7 @@ return true; } } + if (DEFAULT_POLICY.implies(domain, permission)) return true; return false; } > > I reviewed test/jdk/java/lang/Class/getDeclaredField/* and > test/jdk/java/lang/invoke/* patch and they look fine. Thanks. > > My suggestion is to minimize the risk of your patch.? Since Daniel > has reviewed the logging test change (which is the bulk of this patch), > I have no issue if the reviewers approve this patch.? I will file > a separate RFE for the test library idea. I will be pushing my changes since I don't see objections in reviews. Main discussion is how make these tests more robust which could be done separately. Thanks, Vladimir > > Mandy > > > On 6/20/19 11:05 AM, Vladimir Kozlov wrote: >> Hi Mandy >> >> I am not sure about this suggestion. Graal module may not be present in the JDK (on SPARC for example). >> And I don't want pollute general tests with Graal specific code: ModulePolicy.get("jdk.internal.vm.compiler"). >> >> If you or other have concerns about some tests looking on default policy I can keep them on problem list to run them >> later only with libgraal. >> >> I found only 2 closed tests in which I had doubt about using default policy. I kept them on problem list. >> Other tests, as I understand, manipulate permissions for test classes. They don't extend system classes so default >> policy should not affect test class permissions. >> >> Thanks, >> Vladimir >> >> On 6/19/19 11:23 PM, Mandy Chung wrote: >>> Hi Vladimir, >>> >>> Indeed these are test issues that the tests will need to grant permissions >>> to jdk.internal.vm.compiler as the default policy grants. >>> >>> Thanks for going extra miles to fix the tests. >>> >>> My suggestion may be a bit general.? What I intend to say the custom >>> security policy should extend the default policy unless it intentionally >>> excludes configuring permissions for specific modules.? I review the >>> the patch but the test doesn't clearly tell what the test intends to >>> do w.r.t. security configuration. >>> >>> We should avoid inadvertently granting permissions that the test expects >>> to disallow.? A better solution is to limit granting permissions just for >>> `jdk.internal.vm.compiler` module rather than all. >>> >>> Attached is ModulePolicy class that allows you to get the Policy for >>> a specific module. It can be put in the test library that these tests >>> can use them. >>> >>> So the test can call ModulePolicy.get("jdk.internal.vm.compiler") and >>> implies method will call the returned ModulePolicy if present. >>> >>> test/lib/jdk/test/lib/security is one existing testlibrary for security >>> related stuff.? You can consider putting ModulePolicy.java there. >>> >>> This is one idea. >>> >>> Mandy >>> >>> On 6/19/19 6:03 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8185139 >>>> >>>> For Graal to work we have to give Graal module all permissions which is specified in default policy [1]. >>>> Unfortunately this cause problem for Graal running tests which overwrite default policy. >>>> >>>> I discussed this with Mandy and she suggested that such tests should also check default policy. I implemented her >>>> suggestion. Note, this is not only Graal problem. There were already similar fixes before [2]. >>>> >>>> I also updated Graal's problem list. Several tests were left on problem list (with different bug id) because they >>>> would not run with Java Graal (for example, they use --limit-modules flag which prevents loading Graal module). We >>>> will enable such tests again when libgraal is supported. >>>> >>>> I ran testing which execute these tests with Graal. It shows only known problems which are not related to these >>>> changes. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> [1] http://hg.openjdk.java.net/jdk/jdk/file/49ed5e31fe1e/src/java.base/share/lib/security/default.policy#l156 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291 >>> > From dean.long at oracle.com Fri Jun 21 20:09:48 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 21 Jun 2019 13:09:48 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> Message-ID: <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> On 6/21/19 9:42 AM, Tom Rodriguez wrote: > Doesn't that make resolveConstantInPool completely unused? Yes, except for a jtreg test, which can be removed. > It should probably be deleted and the javadoc updated for > resolvePossiblyCachedConstantInPool. OK. dl > > tom > > dean.long at oracle.com wrote on 6/18/19 10:52 AM: >> https://bugs.openjdk.java.net/browse/JDK-8225369 >> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >> >> This test triggers a race, which can result in different resolved >> values of the MethodHandle constant.? The VM chooses a winner and >> stores that value in the constant pool cache, however Graal is not >> checking the cache.? The trivial fix is to use the proper API that >> goes through the cache. >> >> dl From dean.long at oracle.com Fri Jun 21 20:14:07 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 21 Jun 2019 13:14:07 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> Message-ID: If we only have one API, renaming resolvePossiblyCachedConstantInPool to resolveConstantInPool would make it more consistent with other resolve methods.? What do you think? dl On 6/21/19 1:09 PM, dean.long at oracle.com wrote: > On 6/21/19 9:42 AM, Tom Rodriguez wrote: >> Doesn't that make resolveConstantInPool completely unused? > > Yes, except for a jtreg test, which can be removed. > >> It should probably be deleted and the javadoc updated for >> resolvePossiblyCachedConstantInPool. > > OK. > > dl > >> >> tom >> >> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>> >>> This test triggers a race, which can result in different resolved >>> values of the MethodHandle constant.? The VM chooses a winner and >>> stores that value in the constant pool cache, however Graal is not >>> checking the cache.? The trivial fix is to use the proper API that >>> goes through the cache. >>> >>> dl > From tom.rodriguez at oracle.com Fri Jun 21 20:35:55 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Jun 2019 13:35:55 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> Message-ID: <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> dean.long at oracle.com wrote on 6/21/19 1:14 PM: > If we only have one API, renaming resolvePossiblyCachedConstantInPool to > resolveConstantInPool would make it more consistent with other resolve > methods.? What do you think? I assume the naming is to provide a clue to the API use in ConstantPool. It does seem like it's really only about constants and not general constant pool resolution right? tom > > dl > > On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>> Doesn't that make resolveConstantInPool completely unused? >> >> Yes, except for a jtreg test, which can be removed. >> >>> It should probably be deleted and the javadoc updated for >>> resolvePossiblyCachedConstantInPool. >> >> OK. >> >> dl >> >>> >>> tom >>> >>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>> >>>> This test triggers a race, which can result in different resolved >>>> values of the MethodHandle constant.? The VM chooses a winner and >>>> stores that value in the constant pool cache, however Graal is not >>>> checking the cache.? The trivial fix is to use the proper API that >>>> goes through the cache. >>>> >>>> dl >> > From coleen.phillimore at oracle.com Fri Jun 21 20:44:52 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 21 Jun 2019 16:44:52 -0400 Subject: RFR (S) 8222446: assert(C->env()->system_dictionary_modification_counter_changed()) failed: Must invalidate if TypeFuncs differ In-Reply-To: References: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com> Message-ID: <154ad551-d397-5abe-1b6a-7a3ddd129f3d@oracle.com> Dean,? Thank you for reviewing and for your help and discussion of this change. On 6/21/19 3:48 PM, dean.long at oracle.com wrote: > For the most part, this looks good.? I only have a couple concerns: > > 1) The distinction in both validate_compile_task_dependencies > functions between "dependencies failed" and "dependencies invalid" is > even more fuzzy after this change.? I suggest filing an RFE to remove > this distinction. Yes, in jvmciRuntime I had to carefully preserve this logic or some tests failed.?? I'll file an RFE for you. > > 2) In Parse::do_exits(), we don't know that concurrent class loading > didn't cause the problem.? We should be optimistic and allow the retry: > C->record_failure(C2Compiler::retry_class_loading_during_parsing()); > rather than more drastic > ??? C->record_method_not_compilable > This is actually what the code did in an earlier revision. Erik and I were trying to guess which was the right answer.? It seemed too lucky that you'd do concurrent class loading in this time period, so we picked the more drastic answer, but I tested both.? So I'll change it to the optimistic answer. Thanks! Coleen > > dl > > On 6/20/19 10:28 AM, coleen.phillimore at oracle.com wrote: >> Summary: Remove SystemDictionary::modification_counter optimization >> >> See bug for more details.? To avoid the assert in the bug report, >> it's necessary to also increase the modification counter for class >> unloading, which needs special code for concurrent class unloading. >> The global counter is used to verify that validate_dependencies() >> gets the same answer based on the subklass hierarchy, but provides a >> quick exit in production mode.? Removing it may allow more nmethods >> to be created that don't depend on the classes that may be loaded >> while the Method is being compiled. Performance testing was done on >> this with no change in performance.? Also investigated the breakpoint >> setting code which incremented the modification counter. Dependent >> compilations are invalidated using evol_method dependencies, so >> updating the system dictionary modification counter isn't unnecessary. >> >> Tested with hs-tier1-8 testing, and CTW, and local jvmti/jdi/jdwp >> test runs with -Xcomp. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8222446.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8222446 >> >> Thanks, >> Coleen > From dean.long at oracle.com Fri Jun 21 21:59:45 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 21 Jun 2019 14:59:45 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> Message-ID: On 6/21/19 1:35 PM, Tom Rodriguez wrote: > > > dean.long at oracle.com wrote on 6/21/19 1:14 PM: >> If we only have one API, renaming resolvePossiblyCachedConstantInPool >> to resolveConstantInPool would make it more consistent with other >> resolve methods.? What do you think? > > I assume the naming is to provide a clue to the API use in > ConstantPool. ?It does seem like it's really only about constants and > not general constant pool resolution right? > Yes, it's about those types of constants that are Objects.? The resolution could involve calling into Java, but we should only do that once.? That's why the cache is important.? Going through the cache should be the default, and every other lookup and resolve method should be going through the cache, so the PossiblyCached part seems confusing and redundant now. dl > tom > >> >> dl >> >> On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >>> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>>> Doesn't that make resolveConstantInPool completely unused? >>> >>> Yes, except for a jtreg test, which can be removed. >>> >>>> It should probably be deleted and the javadoc updated for >>>> resolvePossiblyCachedConstantInPool. >>> >>> OK. >>> >>> dl >>> >>>> >>>> tom >>>> >>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>>> >>>>> This test triggers a race, which can result in different resolved >>>>> values of the MethodHandle constant.? The VM chooses a winner and >>>>> stores that value in the constant pool cache, however Graal is not >>>>> checking the cache.? The trivial fix is to use the proper API that >>>>> goes through the cache. >>>>> >>>>> dl >>> >> From vladimir.kozlov at oracle.com Fri Jun 21 22:47:19 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Jun 2019 15:47:19 -0700 Subject: [13] RFR(S) 8226566: [JVMCI] java.* classes are no longer necessarily resolved by the boot class loader Message-ID: <3633fc6c-38e7-3c83-af60-cefffe92cc89@oracle.com> https://cr.openjdk.java.net/~kvn/8226566/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8226566 Doug proposed the fix. I tested it. Thanks, Vladimir From dean.long at oracle.com Fri Jun 21 23:14:13 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 21 Jun 2019 16:14:13 -0700 Subject: [13] RFR(S) 8226566: [JVMCI] java.* classes are no longer necessarily resolved by the boot class loader In-Reply-To: <3633fc6c-38e7-3c83-af60-cefffe92cc89@oracle.com> References: <3633fc6c-38e7-3c83-af60-cefffe92cc89@oracle.com> Message-ID: <4e580971-e491-0c3e-4516-5011a9ae0f3c@oracle.com> Doesn't this assume that the classloader for accessingClass is well-behaved and delegates to the classloader for Object?? If the classloader is not well-behaved, is it safe to return true here? What happens if we just remove the special case for java.lang.Object's classloader?? Does it hurt performance? dl On 6/21/19 3:47 PM, Vladimir Kozlov wrote: > https://cr.openjdk.java.net/~kvn/8226566/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8226566 > > Doug proposed the fix. I tested it. > > Thanks, > Vladimir From tom.rodriguez at oracle.com Fri Jun 21 23:39:38 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Jun 2019 16:39:38 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> Message-ID: <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com> dean.long at oracle.com wrote on 6/21/19 2:59 PM: > On 6/21/19 1:35 PM, Tom Rodriguez wrote: >> >> >> dean.long at oracle.com wrote on 6/21/19 1:14 PM: >>> If we only have one API, renaming resolvePossiblyCachedConstantInPool >>> to resolveConstantInPool would make it more consistent with other >>> resolve methods.? What do you think? >> >> I assume the naming is to provide a clue to the API use in >> ConstantPool. ?It does seem like it's really only about constants and >> not general constant pool resolution right? >> > Yes, it's about those types of constants that are Objects.? The > resolution could involve calling into Java, but we should only do that > once.? That's why the cache is important.? Going through the cache > should be the default, and every other lookup and resolve method should > be going through the cache, so the PossiblyCached part seems confusing > and redundant now. Is this something that's changed in 13+? It would be nice to maintain JVMCI source consistency between 8 and 13 where possible. Anyway, I don't feel strongly either way about the name. It's pure internals anyway. tom > > dl >> tom >> >>> >>> dl >>> >>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>>>> Doesn't that make resolveConstantInPool completely unused? >>>> >>>> Yes, except for a jtreg test, which can be removed. >>>> >>>>> It should probably be deleted and the javadoc updated for >>>>> resolvePossiblyCachedConstantInPool. >>>> >>>> OK. >>>> >>>> dl >>>> >>>>> >>>>> tom >>>>> >>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>>>> >>>>>> This test triggers a race, which can result in different resolved >>>>>> values of the MethodHandle constant.? The VM chooses a winner and >>>>>> stores that value in the constant pool cache, however Graal is not >>>>>> checking the cache.? The trivial fix is to use the proper API that >>>>>> goes through the cache. >>>>>> >>>>>> dl >>>> >>> > From vladimir.kozlov at oracle.com Sat Jun 22 00:33:41 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Jun 2019 17:33:41 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com> References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com> Message-ID: On 6/21/19 4:39 PM, Tom Rodriguez wrote: > > > dean.long at oracle.com wrote on 6/21/19 2:59 PM: >> On 6/21/19 1:35 PM, Tom Rodriguez wrote: >>> >>> >>> dean.long at oracle.com wrote on 6/21/19 1:14 PM: >>>> If we only have one API, renaming resolvePossiblyCachedConstantInPool to resolveConstantInPool would make it more >>>> consistent with other resolve methods.? What do you think? >>> >>> I assume the naming is to provide a clue to the API use in ConstantPool. ?It does seem like it's really only about >>> constants and not general constant pool resolution right? >>> >> Yes, it's about those types of constants that are Objects.? The resolution could involve calling into Java, but we >> should only do that once.? That's why the cache is important.? Going through the cache should be the default, and >> every other lookup and resolve method should be going through the cache, so the PossiblyCached part seems confusing >> and redundant now. > > Is this something that's changed in 13+?? It would be nice to maintain JVMCI source consistency between 8 and 13 where > possible.? Anyway, I don't feel strongly either way about the name.? It's pure internals anyway. Please, keep name the same for consistency with jvmci-8. Vladimir > > tom > >> >> dl >>> tom >>> >>>> >>>> dl >>>> >>>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >>>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>>>>> Doesn't that make resolveConstantInPool completely unused? >>>>> >>>>> Yes, except for a jtreg test, which can be removed. >>>>> >>>>>> It should probably be deleted and the javadoc updated for resolvePossiblyCachedConstantInPool. >>>>> >>>>> OK. >>>>> >>>>> dl >>>>> >>>>>> >>>>>> tom >>>>>> >>>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>>>>> >>>>>>> This test triggers a race, which can result in different resolved values of the MethodHandle constant.? The VM >>>>>>> chooses a winner and stores that value in the constant pool cache, however Graal is not checking the cache.? The >>>>>>> trivial fix is to use the proper API that goes through the cache. >>>>>>> >>>>>>> dl >>>>> >>>> >> From doug.simon at oracle.com Sat Jun 22 11:25:44 2019 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 22 Jun 2019 13:25:44 +0200 Subject: [13] RFR(S) 8226566: [JVMCI] java.* classes are no longer necessarily resolved by the boot class loader In-Reply-To: <4e580971-e491-0c3e-4516-5011a9ae0f3c@oracle.com> References: <3633fc6c-38e7-3c83-af60-cefffe92cc89@oracle.com> <4e580971-e491-0c3e-4516-5011a9ae0f3c@oracle.com> Message-ID: > On 22 Jun 2019, at 01:14, dean.long at oracle.com wrote: > > Doesn't this assume that the classloader for accessingClass is well-behaved and delegates to the classloader for Object? If the classloader is not well-behaved, is it safe to return true here? I don?t think it's possible for anything but the boot or platform class loader to load java.* classes: https://github.com/openjdk/jdk13/blob/master/src/java.base/share/classes/java/lang/ClassLoader.java#L891-L899 I?ve tested this: public class Main extends ClassLoader { @Override protected Class findClass(String name) throws ClassNotFoundException { byte[] b = {}; return defineClass(name, b, 0, b.length); } @Override protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException { return findClass(name); } public static void main(String[] args) throws Throwable { Main cl = new Main(); for (String name : args) { try { System.out.printf("%s: loader = %s%n", name, Class.forName(name).getClassLoader()); System.out.println(Class.forName(name, true, cl)); } catch (Exception e) { e.printStackTrace(); } } } } > java -version java version "11.0.3" 2019-04-16 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode) > java Main java.lang.Boolean java.sql.Array java.lang.Boolean: loader = null java.lang.SecurityException: Prohibited package name: java.lang at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:898) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1014) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877) at Main.findClass(Main.java:5) at Main.loadClass(Main.java:10) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:398) at Main.main(Main.java:18) java.sql.Array: loader = jdk.internal.loader.ClassLoaders$PlatformClassLoader at 47d384ee java.lang.SecurityException: Prohibited package name: java.sql at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:898) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1014) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877) at Main.findClass(Main.java:5) at Main.loadClass(Main.java:10) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:398) at Main.main(Main.java:18) > What happens if we just remove the special case for java.lang.Object's classloader? Does it hurt performance? It avoids a VM call for resolving all boot classes during compilation. We could also avoid the VM call for when resolving platform classes as well but I?m not sure how to get a ResolvedJavaType for a platform class. I don?t recall the measurements on the performance impact of this optimization. Maybe it doesn?t show up. However, in libgraal VM calls are relatively more expensive so seems like its worth keeping this shortcut. -Doug > > On 6/21/19 3:47 PM, Vladimir Kozlov wrote: >> https://cr.openjdk.java.net/~kvn/8226566/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8226566 >> >> Doug proposed the fix. I tested it. >> >> Thanks, >> Vladimir > From bsrbnd at gmail.com Mon Jun 24 10:54:19 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 24 Jun 2019 12:54:19 +0200 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: Or we could add another test case not to change the existing one: http://hg.openjdk.java.net/jdk/submit/rev/ba939c7fbedd Full branch log: http://hg.openjdk.java.net/jdk/submit/log?rev=branch(%22JDK-8225644%22) Vladimir, does this look good to you? Thanks, Bernard On Wed, 19 Jun 2019 at 08:57, Jie Fu wrote: > > Hi Joe, > > Are you OK if one more configuration would be added to the failing test[1] ? > > Thanks a lot. > Best regards, > Jie > > [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323#l2.15 > > > On 2019/6/15 ??8:27, Jie Fu wrote: > > Thanks Bernard. > > > > I see all tests on mach5 have passed. > > And could I get one more review from the langtools team for the > > change[1]? > > > > Thanks a lot. > > Best regards, > > Jie > > > > [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 > > > > On 2019/6/15 ??1:53, B. Blaser wrote: > >> As shared code is affected, I've pushed it to jdk/submit to make sure > >> all is right on every supported systems: > >> > >> http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 > >> > >> I've added a configuration to the failing test which might be kept > >> when pushing to jdk/jdk providing that we get a Reviewer approval from > >> the langtools team for this? > >> > >> Thanks, > >> Bernard > >> > >> On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: > >>> Hi Bernard, > >>> > >>> Thank you for your review. > >>> And could you please sponsor it? > >>> > >>> Thanks a lot. > >>> Best regards, > >>> Jie > >>> > >>> > >>> On 2019/6/14 ??1:45, B. Blaser wrote: > >>> > >>>> Seems good to me too. > >>>> > >>>> Thanks, > >>>> Bernard > >>>> > >>>> On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: > >>>>> Thanks Vladimir Ivanov for your review. > >>>>> > >>>>> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: > >>>>>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ > >>>>>> Looks good. > >>>>>> > >>>>>> Best regards, > >>>>>> Vladimir Ivanov > > > From adinn at redhat.com Mon Jun 24 11:35:34 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 24 Jun 2019 12:35:34 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> Message-ID: <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> Hi Alan, I have uploaded a webrev which I believe answers all outstanding review comments: JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974 webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.08/ This includes the changes Joe Darcy highlighted in his code review of the implementation CSR (module header comment plus @since 14 changes in Unsafe.java). It also allows for the tweaks to the force API documentation (JDK-8226203). So, I think the only work still outstanding is to agree changes to the JEP wording (as proposed in my previous post -- see below) plus endorsement and targeting of the JEP. regards, Andrew Dinn ----------- On 18/06/2019 12:43, Andrew Dinn wrote: > Hi Alan, > > Thanks for reviewing the JEP one more time. > > On 16/06/2019 09:47, Alan Bateman wrote: >> I re-read the JEP, trying to put myself in the position of someone >> reading it for the first time in 2020. >> >> Summary section: >> >> What would you think about replacing this with a sentence that makes it >> clear that the JEP adds new JDK-specific file mapping modes to allow the >> FileChannel API create MappedByteBuffers over non-volatile memory? > > I would be happy with that way of describing the behaviour change except > that what you suggest doesn't mention actually making it work -- which > /is/ part of the JEP. How about: > > "Add new JDK-specific file mapping modes, allowing the FileChannel API > to be used to create MappedByteBuffers over non-volatile memory, and > extend the underlying implementation to support this new use case" > >> Goals section: >> >> I think the first paragraph could be re-worded to make it clear that the >> goal is to use the existing MappedByteBuffer API to access NVM. > > Yes indeed: > > "This JEP proposes that class MappedByteBuffer be reworked to support > access to non-volatile memory (NVM). The only API change required is a > new enumeration employed by FileChannel clients to request mapping of a > file located on an NVM-backed file system rather than a conventional, > file storage system. Recent changes to the MappedByteBufer API mean that > it supports all the behaviours needed to allow direct memory updates and > provide the durability guarantees needed for higher level, Java client > libraries to implement persistent data types (e.g. block file systems, > journaled logs, persistent objects, etc.). The implementations of > FileChannel and MappedByteBuffer need revising to be aware of this new > backing type for the mapped file." > >> Paragraphs 2-5 split this into two sub-goals. The first suggests that it >> extends the MBB API but this is no longer the case. The second also >> hints that it adds a new API. I think these two need to be re-worded. > > Agreed. How about this: > > "The primary goal of this JEP is to ensure that clients can access and > update NVM from a Java program efficiently and coherently. A key element > of this goal is to ensure that individual writes (or small groups of > contiguous writes) to a buffer region can be committed with minimal > overhead i.e. to ensure that any changes which might still be in cache > are written back to memory." > > n.b. I snuck in the word coherence because I thought it clarified the > notion of committing to memory. > >> Goal 3 and 4 are okay, although I think the 4th could be summarized as >> allowing mapped buffers on NVM to be tracked by the existing monitoring >> and management APIs. > > Agreed. So, renumbering accordingly, how about this: > > "A second, subordinate goal is to implement this commit behaviour using > a restricted, JDK-internal API defined in class Unsafe, allowing it to > be re-used by classes other than MappedByteBuffer that may need to > commit NVM. > > A final, related goal is to allow buffers mapped over NVM to be tracked > by the existing monitoring and management APIs." > >> Description section >> >> It might be clearer of "Proposed Java API Changes" were renamed to >> "Proposed JDK-specific API changes". > > Agreed. > >> One other thing to mention is that I re-read the javadoc for the MBB >> force methods and I think we need to adjust one of the sentences in the >> existing (and new) methods to take account of implementation specific >> map modes. I've created JDK-8226203 [1] to track it. As support for >> implementation specific map modes is in new in Java SE 13 then it might >> be worth trying to get that fixed now while it is fresh in our minds. > Sure, I'll post an RFR with the javadoc patch as a separate step. Can it > go into jdk13? or is it too late for that? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From bsrbnd at gmail.com Mon Jun 24 16:25:08 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 24 Jun 2019 18:25:08 +0200 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: Hi All, It seems there's a build problem on SPARC but the jdk/submit report isn't clear enough to solve it. Would it be possible to have more details? Jie, did you see any build problem on the jdk/submit report you received some days ago when I pushed the fix with your user-name? Thanks, Bernard On Mon, 24 Jun 2019 at 12:54, B. Blaser wrote: > > Or we could add another test case not to change the existing one: > http://hg.openjdk.java.net/jdk/submit/rev/ba939c7fbedd > > Full branch log: > http://hg.openjdk.java.net/jdk/submit/log?rev=branch(%22JDK-8225644%22) > > Vladimir, does this look good to you? > > Thanks, > Bernard > > On Wed, 19 Jun 2019 at 08:57, Jie Fu wrote: > > > > Hi Joe, > > > > Are you OK if one more configuration would be added to the failing test[1] ? > > > > Thanks a lot. > > Best regards, > > Jie > > > > [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323#l2.15 > > > > > > On 2019/6/15 ??8:27, Jie Fu wrote: > > > Thanks Bernard. > > > > > > I see all tests on mach5 have passed. > > > And could I get one more review from the langtools team for the > > > change[1]? > > > > > > Thanks a lot. > > > Best regards, > > > Jie > > > > > > [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 > > > > > > On 2019/6/15 ??1:53, B. Blaser wrote: > > >> As shared code is affected, I've pushed it to jdk/submit to make sure > > >> all is right on every supported systems: > > >> > > >> http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 > > >> > > >> I've added a configuration to the failing test which might be kept > > >> when pushing to jdk/jdk providing that we get a Reviewer approval from > > >> the langtools team for this? > > >> > > >> Thanks, > > >> Bernard > > >> > > >> On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: > > >>> Hi Bernard, > > >>> > > >>> Thank you for your review. > > >>> And could you please sponsor it? > > >>> > > >>> Thanks a lot. > > >>> Best regards, > > >>> Jie > > >>> > > >>> > > >>> On 2019/6/14 ??1:45, B. Blaser wrote: > > >>> > > >>>> Seems good to me too. > > >>>> > > >>>> Thanks, > > >>>> Bernard > > >>>> > > >>>> On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: > > >>>>> Thanks Vladimir Ivanov for your review. > > >>>>> > > >>>>> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: > > >>>>>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ > > >>>>>> Looks good. > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Vladimir Ivanov > > > > > From dean.long at oracle.com Mon Jun 24 18:40:43 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 24 Jun 2019 11:40:43 -0700 Subject: [13] RFR(S) 8226566: [JVMCI] java.* classes are no longer necessarily resolved by the boot class loader In-Reply-To: References: <3633fc6c-38e7-3c83-af60-cefffe92cc89@oracle.com> <4e580971-e491-0c3e-4516-5011a9ae0f3c@oracle.com> Message-ID: <24f55c64-3f32-d793-1a4a-6744af882ee6@oracle.com> The code isn't restricted to just java.* anymore.? Now it's any type that the platform classloader defines.? Isn't it possible that the class was resolved by the platform classloader, but accessingClass has a custom classloader that throws ClassNotFound? dl On 6/22/19 4:25 AM, Doug Simon wrote: > >> On 22 Jun 2019, at 01:14, dean.long at oracle.com >> wrote: >> >> Doesn't this assume that the classloader for accessingClass is >> well-behaved and delegates to the classloader for Object?? If the >> classloader is not well-behaved, is it safe to return true here? > > I don?t think it's possible for anything but the boot or platform > class loader to load java.* classes: > > https://github.com/openjdk/jdk13/blob/master/src/java.base/share/classes/java/lang/ClassLoader.java#L891-L899 > > I?ve tested this: > > public class Main extends ClassLoader { > @Override > protected Class findClass(String name) throws ClassNotFoundException { > byte[] b = {}; > return defineClass(name, b, 0, b.length); > ? } > > @Override > protected Class loadClass(String name, boolean resolve) throws > ClassNotFoundException { > return findClass(name); > ? } > > public static void main(String[] args) throws Throwable { > ? ? ? Main cl = new Main(); > for (String name : args) { > try { > ? ? ? ? ? ? ??System.out.printf("%s: loader = %s%n", name, > Class.forName(name).getClassLoader()); > ? ? ? ? ? ? ? System.out.println(Class.forName(name, true, cl)); > ? ? ? ? ? } catch (Exception e) { > e.printStackTrace(); > ? ? ? ? ? } > ? ? ? } > ? } > } > > > java -version > java version "11.0.3" 2019-04-16 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode) > > java?Main java.lang.Boolean java.sql.Array > java.lang.Boolean: loader = null > java.lang.SecurityException: Prohibited package name: java.lang > at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:898) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1014) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877) > at Main.findClass(Main.java:5) > at Main.loadClass(Main.java:10) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:398) > at Main.main(Main.java:18) > java.sql.Array: loader = > jdk.internal.loader.ClassLoaders$PlatformClassLoader at 47d384ee > java.lang.SecurityException: Prohibited package name: java.sql > at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:898) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1014) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877) > at Main.findClass(Main.java:5) > at Main.loadClass(Main.java:10) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:398) > at Main.main(Main.java:18) > >> What happens if we just remove the special case for >> java.lang.Object's classloader?? Does it hurt performance? > > It avoids a VM call for resolving all boot classes during compilation. > We could also avoid the VM call for when resolving platform classes as > well but I?m not sure how to get a ResolvedJavaType for a platform class. > > I don?t recall the measurements on the performance impact of this > optimization. Maybe it doesn?t show up. However, in libgraal VM calls > are relatively more expensive so seems like its worth keeping this > shortcut. > > -Doug > >> >> On 6/21/19 3:47 PM, Vladimir Kozlov wrote: >>> https://cr.openjdk.java.net/~kvn/8226566/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8226566 >>> >>> Doug proposed the fix. I tested it. >>> >>> Thanks, >>> Vladimir >> > From dean.long at oracle.com Mon Jun 24 18:55:36 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 24 Jun 2019 11:55:36 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com> Message-ID: <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com> On 6/21/19 5:33 PM, Vladimir Kozlov wrote: > On 6/21/19 4:39 PM, Tom Rodriguez wrote: >> >> >> dean.long at oracle.com wrote on 6/21/19 2:59 PM: >>> On 6/21/19 1:35 PM, Tom Rodriguez wrote: >>>> >>>> >>>> dean.long at oracle.com wrote on 6/21/19 1:14 PM: >>>>> If we only have one API, renaming >>>>> resolvePossiblyCachedConstantInPool to resolveConstantInPool would >>>>> make it more consistent with other resolve methods.? What do you >>>>> think? >>>> >>>> I assume the naming is to provide a clue to the API use in >>>> ConstantPool. ?It does seem like it's really only about constants >>>> and not general constant pool resolution right? >>>> >>> Yes, it's about those types of constants that are Objects. The >>> resolution could involve calling into Java, but we should only do >>> that once.? That's why the cache is important.? Going through the >>> cache should be the default, and every other lookup and resolve >>> method should be going through the cache, so the PossiblyCached part >>> seems confusing and redundant now. >> >> Is this something that's changed in 13+?? It would be nice to >> maintain JVMCI source consistency between 8 and 13 where possible.? >> Anyway, I don't feel strongly either way about the name.? It's pure >> internals anyway. > > Please, keep name the same for consistency with jvmci-8. > OK, here's the webrev that removes the unused method, but does not rename: http://cr.openjdk.java.net/~dlong/8225369/remove/ While I was at it, I merged ResolveConstantInPoolTest into ResolvePossiblyCachedConstantInPoolTest, but it's not strictly necessary.? I could keep them separate. dl > Vladimir > >> >> tom >> >>> >>> dl >>>> tom >>>> >>>>> >>>>> dl >>>>> >>>>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >>>>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>>>>>> Doesn't that make resolveConstantInPool completely unused? >>>>>> >>>>>> Yes, except for a jtreg test, which can be removed. >>>>>> >>>>>>> It should probably be deleted and the javadoc updated for >>>>>>> resolvePossiblyCachedConstantInPool. >>>>>> >>>>>> OK. >>>>>> >>>>>> dl >>>>>> >>>>>>> >>>>>>> tom >>>>>>> >>>>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>>>>>> >>>>>>>> This test triggers a race, which can result in different >>>>>>>> resolved values of the MethodHandle constant.? The VM chooses a >>>>>>>> winner and stores that value in the constant pool cache, >>>>>>>> however Graal is not checking the cache.? The trivial fix is to >>>>>>>> use the proper API that goes through the cache. >>>>>>>> >>>>>>>> dl >>>>>> >>>>> >>> From tom.rodriguez at oracle.com Mon Jun 24 19:08:16 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 24 Jun 2019 12:08:16 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com> References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com> <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com> Message-ID: <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com> >> Please, keep name the same for consistency with jvmci-8. >> > > OK, here's the webrev that removes the unused method, but does not rename: > > http://cr.openjdk.java.net/~dlong/8225369/remove/ > > While I was at it, I merged ResolveConstantInPoolTest into > ResolvePossiblyCachedConstantInPoolTest, but it's not strictly > necessary.? I could keep them separate. Looks great to me. tom > > dl > >> Vladimir >> >>> >>> tom >>> >>>> >>>> dl >>>>> tom >>>>> >>>>>> >>>>>> dl >>>>>> >>>>>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >>>>>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>>>>>>> Doesn't that make resolveConstantInPool completely unused? >>>>>>> >>>>>>> Yes, except for a jtreg test, which can be removed. >>>>>>> >>>>>>>> It should probably be deleted and the javadoc updated for >>>>>>>> resolvePossiblyCachedConstantInPool. >>>>>>> >>>>>>> OK. >>>>>>> >>>>>>> dl >>>>>>> >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>>>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>>>>>>> >>>>>>>>> This test triggers a race, which can result in different >>>>>>>>> resolved values of the MethodHandle constant.? The VM chooses a >>>>>>>>> winner and stores that value in the constant pool cache, >>>>>>>>> however Graal is not checking the cache.? The trivial fix is to >>>>>>>>> use the proper API that goes through the cache. >>>>>>>>> >>>>>>>>> dl >>>>>>> >>>>>> >>>> > From doug.simon at oracle.com Mon Jun 24 19:12:55 2019 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 24 Jun 2019 21:12:55 +0200 Subject: [13] RFR(S) 8226566: [JVMCI] java.* classes are no longer necessarily resolved by the boot class loader In-Reply-To: <24f55c64-3f32-d793-1a4a-6744af882ee6@oracle.com> References: <3633fc6c-38e7-3c83-af60-cefffe92cc89@oracle.com> <4e580971-e491-0c3e-4516-5011a9ae0f3c@oracle.com> <24f55c64-3f32-d793-1a4a-6744af882ee6@oracle.com> Message-ID: <79F8EACC-5A8F-4A43-8E99-9F83365C9743@oracle.com> > On 24 Jun 2019, at 20:40, dean.long at oracle.com wrote: > > The code isn't restricted to just java.* anymore. Now it's any type that the platform classloader defines. Isn't it possible that the class was resolved by the platform classloader, but accessingClass has a custom classloader that throws ClassNotFound? I see your point - we should retain the check for java.*. -Doug > On 6/22/19 4:25 AM, Doug Simon wrote: >> >>> On 22 Jun 2019, at 01:14, dean.long at oracle.com wrote: >>> >>> Doesn't this assume that the classloader for accessingClass is well-behaved and delegates to the classloader for Object? If the classloader is not well-behaved, is it safe to return true here? >> >> I don?t think it's possible for anything but the boot or platform class loader to load java.* classes: >> >> https://github.com/openjdk/jdk13/blob/master/src/java.base/share/classes/java/lang/ClassLoader.java#L891-L899 >> >> I?ve tested this: >> >> public class Main extends ClassLoader { >> @Override >> protected Class findClass(String name) throws ClassNotFoundException { >> byte[] b = {}; >> return defineClass(name, b, 0, b.length); >> } >> >> @Override >> protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException { >> return findClass(name); >> } >> >> public static void main(String[] args) throws Throwable { >> Main cl = new Main(); >> for (String name : args) { >> try { >> System.out.printf("%s: loader = %s%n", name, Class.forName(name).getClassLoader()); >> System.out.println(Class.forName(name, true, cl)); >> } catch (Exception e) { >> e.printStackTrace(); >> } >> } >> } >> } >> >> > java -version >> java version "11.0.3" 2019-04-16 LTS >> Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS) >> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode) >> > java Main java.lang.Boolean java.sql.Array >> java.lang.Boolean: loader = null >> java.lang.SecurityException: Prohibited package name: java.lang >> at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:898) >> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1014) >> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877) >> at Main.findClass(Main.java:5) >> at Main.loadClass(Main.java:10) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> at java.base/java.lang.Class.forName0(Native Method) >> at java.base/java.lang.Class.forName(Class.java:398) >> at Main.main(Main.java:18) >> java.sql.Array: loader = jdk.internal.loader.ClassLoaders$PlatformClassLoader at 47d384ee >> java.lang.SecurityException: Prohibited package name: java.sql >> at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:898) >> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1014) >> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877) >> at Main.findClass(Main.java:5) >> at Main.loadClass(Main.java:10) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> at java.base/java.lang.Class.forName0(Native Method) >> at java.base/java.lang.Class.forName(Class.java:398) >> at Main.main(Main.java:18) >> >>> What happens if we just remove the special case for java.lang.Object's classloader? Does it hurt performance? >> >> It avoids a VM call for resolving all boot classes during compilation. We could also avoid the VM call for when resolving platform classes as well but I?m not sure how to get a ResolvedJavaType for a platform class. >> >> I don?t recall the measurements on the performance impact of this optimization. Maybe it doesn?t show up. However, in libgraal VM calls are relatively more expensive so seems like its worth keeping this shortcut. >> >> -Doug >> >>> >>> On 6/21/19 3:47 PM, Vladimir Kozlov wrote: >>>> https://cr.openjdk.java.net/~kvn/8226566/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8226566 >>>> >>>> Doug proposed the fix. I tested it. >>>> >>>> Thanks, >>>> Vladimir >>> >> > From vladimir.kozlov at oracle.com Mon Jun 24 19:23:36 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 24 Jun 2019 12:23:36 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com> References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com> <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com> <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com> Message-ID: +1 Dean, did you file PR to fix it upstream? Thanks, Vladimir On 6/24/19 12:08 PM, Tom Rodriguez wrote: > >>> Please, keep name the same for consistency with jvmci-8. >>> >> >> OK, here's the webrev that removes the unused method, but does not rename: >> >> http://cr.openjdk.java.net/~dlong/8225369/remove/ >> >> While I was at it, I merged ResolveConstantInPoolTest into ResolvePossiblyCachedConstantInPoolTest, but it's not >> strictly necessary.? I could keep them separate. > > Looks great to me. > > tom > >> >> dl >> >>> Vladimir >>> >>>> >>>> tom >>>> >>>>> >>>>> dl >>>>>> tom >>>>>> >>>>>>> >>>>>>> dl >>>>>>> >>>>>>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >>>>>>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>>>>>>>> Doesn't that make resolveConstantInPool completely unused? >>>>>>>> >>>>>>>> Yes, except for a jtreg test, which can be removed. >>>>>>>> >>>>>>>>> It should probably be deleted and the javadoc updated for resolvePossiblyCachedConstantInPool. >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> dl >>>>>>>> >>>>>>>>> >>>>>>>>> tom >>>>>>>>> >>>>>>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>>>>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>>>>>>>> >>>>>>>>>> This test triggers a race, which can result in different resolved values of the MethodHandle constant.? The VM >>>>>>>>>> chooses a winner and stores that value in the constant pool cache, however Graal is not checking the cache. >>>>>>>>>> The trivial fix is to use the proper API that goes through the cache. >>>>>>>>>> >>>>>>>>>> dl >>>>>>>> >>>>>>> >>>>> >> From daniel.daugherty at oracle.com Mon Jun 24 21:35:26 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Jun 2019 17:35:26 -0400 Subject: [13] RFR(XS/M): 8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes Message-ID: Greetings, The Runtime team has decided to backout the following fix from JDK13: ??? JDK-8221734 Deoptimize with handshakes ??? https://bugs.openjdk.java.net/browse/JDK-8221734 in order to provide time to deal with the following regression in the JDK14 time frame: ??? JDK-8225351 assert failed: Revoke failed, unhandled biased lock state ??? https://bugs.openjdk.java.net/browse/JDK-8225351 This is a backout of an 'M'-sized patch so it's 'XS' because it is a backout that has been mechanically verified, but the numbers of lines touched makes it an 'M'. Here's the backout bug: ??? JDK-8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes ??? https://bugs.openjdk.java.net/browse/JDK-8226699 Here's the webrev: http://cr.openjdk.java.net/~dcubed/8226699-webrev/0_for_jdk13/index.html Here's the webrev for JDK-8221734: ??? http://cr.openjdk.java.net/~rehn/8221734/v5/webrev/ Thanks, in advance, for any comments, questions or suggestions. Dan (and Robbin) From dean.long at oracle.com Mon Jun 24 21:49:50 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 24 Jun 2019 14:49:50 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com> References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com> <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com> <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com> Message-ID: Thanks Tom. dl On 6/24/19 12:08 PM, Tom Rodriguez wrote: > >>> Please, keep name the same for consistency with jvmci-8. >>> >> >> OK, here's the webrev that removes the unused method, but does not >> rename: >> >> http://cr.openjdk.java.net/~dlong/8225369/remove/ >> >> While I was at it, I merged ResolveConstantInPoolTest into >> ResolvePossiblyCachedConstantInPoolTest, but it's not strictly >> necessary.? I could keep them separate. > > Looks great to me. > > tom > >> >> dl >> >>> Vladimir >>> >>>> >>>> tom >>>> >>>>> >>>>> dl >>>>>> tom >>>>>> >>>>>>> >>>>>>> dl >>>>>>> >>>>>>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >>>>>>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>>>>>>>> Doesn't that make resolveConstantInPool completely unused? >>>>>>>> >>>>>>>> Yes, except for a jtreg test, which can be removed. >>>>>>>> >>>>>>>>> It should probably be deleted and the javadoc updated for >>>>>>>>> resolvePossiblyCachedConstantInPool. >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> dl >>>>>>>> >>>>>>>>> >>>>>>>>> tom >>>>>>>>> >>>>>>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>>>>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>>>>>>>> >>>>>>>>>> This test triggers a race, which can result in different >>>>>>>>>> resolved values of the MethodHandle constant.? The VM chooses >>>>>>>>>> a winner and stores that value in the constant pool cache, >>>>>>>>>> however Graal is not checking the cache.? The trivial fix is >>>>>>>>>> to use the proper API that goes through the cache. >>>>>>>>>> >>>>>>>>>> dl >>>>>>>> >>>>>>> >>>>> >> From david.holmes at oracle.com Mon Jun 24 21:52:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 Jun 2019 17:52:05 -0400 Subject: [13] RFR(XS/M): 8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes In-Reply-To: References: Message-ID: <5b74285b-7649-5c45-5b46-c2032d5bf2e5@oracle.com> Hi Dan, This looks like an accurate backout of the changes. Thanks, David On 24/06/2019 2:35 pm, Daniel D. Daugherty wrote: > Greetings, > > The Runtime team has decided to backout the following fix from JDK13: > > ??? JDK-8221734 Deoptimize with handshakes > ??? https://bugs.openjdk.java.net/browse/JDK-8221734 > > in order to provide time to deal with the following regression in the > JDK14 time frame: > > ??? JDK-8225351 assert failed: Revoke failed, unhandled biased lock state > ??? https://bugs.openjdk.java.net/browse/JDK-8225351 > > This is a backout of an 'M'-sized patch so it's 'XS' because it is a > backout that has been mechanically verified, but the numbers of lines > touched makes it an 'M'. > > Here's the backout bug: > > ??? JDK-8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes > ??? https://bugs.openjdk.java.net/browse/JDK-8226699 > > Here's the webrev: > > http://cr.openjdk.java.net/~dcubed/8226699-webrev/0_for_jdk13/index.html > > Here's the webrev for JDK-8221734: > > ??? http://cr.openjdk.java.net/~rehn/8221734/v5/webrev/ > > Thanks, in advance, for any comments, questions or suggestions. > > Dan (and Robbin) From dean.long at oracle.com Mon Jun 24 21:52:51 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 24 Jun 2019 14:52:51 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com> <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com> <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com> Message-ID: I don't see anything to upstream to Graal here.? Do you mean jvmci-8? dl On 6/24/19 12:23 PM, Vladimir Kozlov wrote: > +1 > > Dean, did you file PR to fix it upstream? > > Thanks, > Vladimir > > On 6/24/19 12:08 PM, Tom Rodriguez wrote: >> >>>> Please, keep name the same for consistency with jvmci-8. >>>> >>> >>> OK, here's the webrev that removes the unused method, but does not >>> rename: >>> >>> http://cr.openjdk.java.net/~dlong/8225369/remove/ >>> >>> While I was at it, I merged ResolveConstantInPoolTest into >>> ResolvePossiblyCachedConstantInPoolTest, but it's not strictly >>> necessary.? I could keep them separate. >> >> Looks great to me. >> >> tom >> >>> >>> dl >>> >>>> Vladimir >>>> >>>>> >>>>> tom >>>>> >>>>>> >>>>>> dl >>>>>>> tom >>>>>>> >>>>>>>> >>>>>>>> dl >>>>>>>> >>>>>>>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >>>>>>>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>>>>>>>>> Doesn't that make resolveConstantInPool completely unused? >>>>>>>>> >>>>>>>>> Yes, except for a jtreg test, which can be removed. >>>>>>>>> >>>>>>>>>> It should probably be deleted and the javadoc updated for >>>>>>>>>> resolvePossiblyCachedConstantInPool. >>>>>>>>> >>>>>>>>> OK. >>>>>>>>> >>>>>>>>> dl >>>>>>>>> >>>>>>>>>> >>>>>>>>>> tom >>>>>>>>>> >>>>>>>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>>>>>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>>>>>>>>> >>>>>>>>>>> This test triggers a race, which can result in different >>>>>>>>>>> resolved values of the MethodHandle constant.? The VM >>>>>>>>>>> chooses a winner and stores that value in the constant pool >>>>>>>>>>> cache, however Graal is not checking the cache.? The trivial >>>>>>>>>>> fix is to use the proper API that goes through the cache. >>>>>>>>>>> >>>>>>>>>>> dl >>>>>>>>> >>>>>>>> >>>>>> >>> From vladimir.kozlov at oracle.com Mon Jun 24 22:05:59 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 24 Jun 2019 15:05:59 -0700 Subject: [13] RFR(XXS) 8225369: [AOT] vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails In-Reply-To: References: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com> <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com> <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com> <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com> <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com> <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com> Message-ID: Yes, I meant jvmci-8 Thanks Vladimir > On Jun 24, 2019, at 2:52 PM, dean.long at oracle.com wrote: > > I don't see anything to upstream to Graal here. Do you mean jvmci-8? > > dl > >> On 6/24/19 12:23 PM, Vladimir Kozlov wrote: >> +1 >> >> Dean, did you file PR to fix it upstream? >> >> Thanks, >> Vladimir >> >>> On 6/24/19 12:08 PM, Tom Rodriguez wrote: >>> >>>>> Please, keep name the same for consistency with jvmci-8. >>>>> >>>> >>>> OK, here's the webrev that removes the unused method, but does not rename: >>>> >>>> http://cr.openjdk.java.net/~dlong/8225369/remove/ >>>> >>>> While I was at it, I merged ResolveConstantInPoolTest into ResolvePossiblyCachedConstantInPoolTest, but it's not strictly necessary. I could keep them separate. >>> >>> Looks great to me. >>> >>> tom >>> >>>> >>>> dl >>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> tom >>>>>> >>>>>>> >>>>>>> dl >>>>>>>> tom >>>>>>>> >>>>>>>>> >>>>>>>>> dl >>>>>>>>> >>>>>>>>>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote: >>>>>>>>>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote: >>>>>>>>>>> Doesn't that make resolveConstantInPool completely unused? >>>>>>>>>> >>>>>>>>>> Yes, except for a jtreg test, which can be removed. >>>>>>>>>> >>>>>>>>>>> It should probably be deleted and the javadoc updated for resolvePossiblyCachedConstantInPool. >>>>>>>>>> >>>>>>>>>> OK. >>>>>>>>>> >>>>>>>>>> dl >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> tom >>>>>>>>>>> >>>>>>>>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369 >>>>>>>>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> This test triggers a race, which can result in different resolved values of the MethodHandle constant. The VM chooses a winner and stores that value in the constant pool cache, however Graal is not checking the cache. The trivial fix is to use the proper API that goes through the cache. >>>>>>>>>>>> >>>>>>>>>>>> dl >>>>>>>>>> >>>>>>>>> >>>>>>> >>>> > From daniel.daugherty at oracle.com Mon Jun 24 22:07:04 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Jun 2019 18:07:04 -0400 Subject: [13] RFR(XS/M): 8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes In-Reply-To: <5b74285b-7649-5c45-5b46-c2032d5bf2e5@oracle.com> References: <5b74285b-7649-5c45-5b46-c2032d5bf2e5@oracle.com> Message-ID: David, Thanks for the fast review! Dan On 6/24/19 5:52 PM, David Holmes wrote: > Hi Dan, > > This looks like an accurate backout of the changes. > > Thanks, > David > > On 24/06/2019 2:35 pm, Daniel D. Daugherty wrote: >> Greetings, >> >> The Runtime team has decided to backout the following fix from JDK13: >> >> ???? JDK-8221734 Deoptimize with handshakes >> ???? https://bugs.openjdk.java.net/browse/JDK-8221734 >> >> in order to provide time to deal with the following regression in the >> JDK14 time frame: >> >> ???? JDK-8225351 assert failed: Revoke failed, unhandled biased lock >> state >> ???? https://bugs.openjdk.java.net/browse/JDK-8225351 >> >> This is a backout of an 'M'-sized patch so it's 'XS' because it is a >> backout that has been mechanically verified, but the numbers of lines >> touched makes it an 'M'. >> >> Here's the backout bug: >> >> ???? JDK-8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes >> ???? https://bugs.openjdk.java.net/browse/JDK-8226699 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8226699-webrev/0_for_jdk13/index.html >> >> Here's the webrev for JDK-8221734: >> >> ???? http://cr.openjdk.java.net/~rehn/8221734/v5/webrev/ >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan (and Robbin) From robbin.ehn at oracle.com Mon Jun 24 22:16:19 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 25 Jun 2019 00:16:19 +0200 Subject: [13] RFR(XS/M): 8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes In-Reply-To: References: Message-ID: <367eaac1-4af5-4753-c47d-d0eac23c0d51@oracle.com> Thanks a lot Dan! Look good! /Robbin On 2019-06-24 23:35, Daniel D. Daugherty wrote: > Greetings, > > The Runtime team has decided to backout the following fix from JDK13: > > ??? JDK-8221734 Deoptimize with handshakes > ??? https://bugs.openjdk.java.net/browse/JDK-8221734 > > in order to provide time to deal with the following regression in the > JDK14 time frame: > > ??? JDK-8225351 assert failed: Revoke failed, unhandled biased lock state > ??? https://bugs.openjdk.java.net/browse/JDK-8225351 > > This is a backout of an 'M'-sized patch so it's 'XS' because it is a > backout that has been mechanically verified, but the numbers of lines > touched makes it an 'M'. > > Here's the backout bug: > > ??? JDK-8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes > ??? https://bugs.openjdk.java.net/browse/JDK-8226699 > > Here's the webrev: > > http://cr.openjdk.java.net/~dcubed/8226699-webrev/0_for_jdk13/index.html > > Here's the webrev for JDK-8221734: > > ??? http://cr.openjdk.java.net/~rehn/8221734/v5/webrev/ > > Thanks, in advance, for any comments, questions or suggestions. > > Dan (and Robbin) From daniel.daugherty at oracle.com Mon Jun 24 22:17:06 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Jun 2019 18:17:06 -0400 Subject: [13] RFR(XS/M): 8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes In-Reply-To: <367eaac1-4af5-4753-c47d-d0eac23c0d51@oracle.com> References: <367eaac1-4af5-4753-c47d-d0eac23c0d51@oracle.com> Message-ID: Robbin, Thanks for the fast review! Dan On 6/24/19 6:16 PM, Robbin Ehn wrote: > Thanks a lot Dan! > > Look good! > > /Robbin > > On 2019-06-24 23:35, Daniel D. Daugherty wrote: >> Greetings, >> >> The Runtime team has decided to backout the following fix from JDK13: >> >> ???? JDK-8221734 Deoptimize with handshakes >> ???? https://bugs.openjdk.java.net/browse/JDK-8221734 >> >> in order to provide time to deal with the following regression in the >> JDK14 time frame: >> >> ???? JDK-8225351 assert failed: Revoke failed, unhandled biased lock >> state >> ???? https://bugs.openjdk.java.net/browse/JDK-8225351 >> >> This is a backout of an 'M'-sized patch so it's 'XS' because it is a >> backout that has been mechanically verified, but the numbers of lines >> touched makes it an 'M'. >> >> Here's the backout bug: >> >> ???? JDK-8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes >> ???? https://bugs.openjdk.java.net/browse/JDK-8226699 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8226699-webrev/0_for_jdk13/index.html >> >> Here's the webrev for JDK-8221734: >> >> ???? http://cr.openjdk.java.net/~rehn/8221734/v5/webrev/ >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan (and Robbin) From fujie at loongson.cn Tue Jun 25 00:28:46 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 25 Jun 2019 08:28:46 +0800 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: <80a00ee2-34b1-dd98-64f4-9bf4a9c870b7@loongson.cn> On 2019/6/25 ??12:25, B. Blaser wrote: > Jie, did you see any build problem on the jdk/submit report you > received some days ago when I pushed the fix with your user-name? No. All tests passed. I will forward that email immediately. From fujie at loongson.cn Tue Jun 25 00:34:03 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 25 Jun 2019 08:34:03 +0800 Subject: Fwd: [Mach5] mach5-one-jiefu-JDK-8225644-20190614-1812-3158854: PASSED In-Reply-To: <1175670685.2384.1560542688455.JavaMail.root@infra-sca-m900-6.us.oracle.com> References: <1175670685.2384.1560542688455.JavaMail.root@infra-sca-m900-6.us.oracle.com> Message-ID: <96c273cd-b9a2-a0b4-04c9-605cce840d5b@loongson.cn> Hi Bernard and all, Forward the test results on mach5. It shows that all tests have passed. Thanks a lot. Best regards, Jie -------- Forwarded Message -------- Subject: [Mach5] mach5-one-jiefu-JDK-8225644-20190614-1812-3158854: PASSED Date: Fri, 14 Jun 2019 20:04:48 GMT From: do-not-reply at oracle.com Reply-To: mach5_admin_ww_grp at oracle.com To: fujie at loongson.cn Job: mach5-one-jiefu-JDK-8225644-20190614-1812-3158854 BuildId: 2019-06-14-1809331.fujie.source No failed tests Tasks Summary * NOTHING_TO_RUN: 0 * UNABLE_TO_RUN: 0 * KILLED: 0 * EXECUTED_WITH_FAILURE: 0 * FAILED: 0 * HARNESS_ERROR: 0 * NA: 0 * PASSED: 77 From daniel.daugherty at oracle.com Tue Jun 25 02:30:24 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Jun 2019 22:30:24 -0400 Subject: [13] RFR(XS/M): 8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes In-Reply-To: References: <3bb094a7-b18e-569d-bd5b-998ca6a2d1ba@oracle.com> Message-ID: Thanks for the review! Dan On 6/24/19 7:17 PM, dean.long at oracle.com wrote: > It's fine with me, as long as I don't need to verify it :-) > > dl > > On 6/24/19 3:19 PM, Daniel D. Daugherty wrote: >> Hi Dean, >> >> It would be good to hear from you on this backout... >> >> Dan >> >> >> On 6/24/19 5:35 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> The Runtime team has decided to backout the following fix from JDK13: >>> >>> ??? JDK-8221734 Deoptimize with handshakes >>> ??? https://bugs.openjdk.java.net/browse/JDK-8221734 >>> >>> in order to provide time to deal with the following regression in the >>> JDK14 time frame: >>> >>> ??? JDK-8225351 assert failed: Revoke failed, unhandled biased lock >>> state >>> ??? https://bugs.openjdk.java.net/browse/JDK-8225351 >>> >>> This is a backout of an 'M'-sized patch so it's 'XS' because it is a >>> backout that has been mechanically verified, but the numbers of lines >>> touched makes it an 'M'. >>> >>> Here's the backout bug: >>> >>> ??? JDK-8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes >>> ??? https://bugs.openjdk.java.net/browse/JDK-8226699 >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8226699-webrev/0_for_jdk13/index.html >>> >>> >>> Here's the webrev for JDK-8221734: >>> >>> ??? http://cr.openjdk.java.net/~rehn/8221734/v5/webrev/ >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan (and Robbin) >>> >> > From nils.eliasson at oracle.com Tue Jun 25 08:13:47 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 25 Jun 2019 10:13:47 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> Message-ID: <4efedfa0-a5dd-e8b6-e7ca-2f65a156663d@oracle.com> I need a second reviewer. // Nils On 2019-06-19 14:49, Nils Eliasson wrote: > > Hi, > > This patch fixes a minor problem in process_users_of_allocation in > macro.cpp. When removing the initalize node we must handle the case > that there is a gc barrier in the control flow. > > This patch strengthens the requirement that the zgc loadbarrier node > has a control out when expanding. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226287 > > > Webrev: http://cr.openjdk.java.net/~neliasso/8226287/webrev.01/ > > Please review, > > Regards, > > Nils > > > From rwestrel at redhat.com Tue Jun 25 10:16:44 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 25 Jun 2019 12:16:44 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> Message-ID: <87mui6c6lv.fsf@redhat.com> > Webrev: http://cr.openjdk.java.net/~neliasso/8226287/webrev.01/ So the initialization node is not always removed? Roland. From nils.eliasson at oracle.com Tue Jun 25 13:12:35 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 25 Jun 2019 15:12:35 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <87mui6c6lv.fsf@redhat.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> <87mui6c6lv.fsf@redhat.com> Message-ID: <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> The IR breaks on removal of the initialize node if there's a barrier between the allocation and the initialize node. Like this: Allocate Proj (Control) Catch CatchProj LoadBarrier Proj (Control) Initalize In theory the LoadP could have its barrier before the Allocate, but it has been scheduled with the catch as control. And then when the barriers is inserted it is pushed down to the catchProj. (The Loads use is in that block.) // Nils On 2019-06-25 12:16, Roland Westrelin wrote: >> Webrev: http://cr.openjdk.java.net/~neliasso/8226287/webrev.01/ > So the initialization node is not always removed? > > Roland. From vladimir.x.ivanov at oracle.com Tue Jun 25 17:56:16 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 25 Jun 2019 20:56:16 +0300 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: > Or we could add another test case not to change the existing one: > http://hg.openjdk.java.net/jdk/submit/rev/ba939c7fbedd > > Full branch log: > http://hg.openjdk.java.net/jdk/submit/log?rev=branch(%22JDK-8225644%22) > > Vladimir, does this look good to you? Yes, looks good. I'm in favor of a dedicated test rather than introducing new C1-specific configuration into existing one from langtools. Best regards, Vladimir Ivanov > On Wed, 19 Jun 2019 at 08:57, Jie Fu wrote: >> >> Hi Joe, >> >> Are you OK if one more configuration would be added to the failing test[1] ? >> >> Thanks a lot. >> Best regards, >> Jie >> >> [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323#l2.15 >> >> >> On 2019/6/15 ??8:27, Jie Fu wrote: >>> Thanks Bernard. >>> >>> I see all tests on mach5 have passed. >>> And could I get one more review from the langtools team for the >>> change[1]? >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 >>> >>> On 2019/6/15 ??1:53, B. Blaser wrote: >>>> As shared code is affected, I've pushed it to jdk/submit to make sure >>>> all is right on every supported systems: >>>> >>>> http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 >>>> >>>> I've added a configuration to the failing test which might be kept >>>> when pushing to jdk/jdk providing that we get a Reviewer approval from >>>> the langtools team for this? >>>> >>>> Thanks, >>>> Bernard >>>> >>>> On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: >>>>> Hi Bernard, >>>>> >>>>> Thank you for your review. >>>>> And could you please sponsor it? >>>>> >>>>> Thanks a lot. >>>>> Best regards, >>>>> Jie >>>>> >>>>> >>>>> On 2019/6/14 ??1:45, B. Blaser wrote: >>>>> >>>>>> Seems good to me too. >>>>>> >>>>>> Thanks, >>>>>> Bernard >>>>>> >>>>>> On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: >>>>>>> Thanks Vladimir Ivanov for your review. >>>>>>> >>>>>>> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: >>>>>>>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ >>>>>>>> Looks good. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>> >> From jesper.wilhelmsson at oracle.com Tue Jun 25 19:51:49 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 25 Jun 2019 21:51:49 +0200 Subject: RFR: JDK-8225497 - Update Graal Message-ID: Hi, Please review the patch to integrate recent Graal changes into OpenJDK. Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff JBS duplicates fixed by this integration: https://bugs.openjdk.java.net/browse/JDK-8223924 https://bugs.openjdk.java.net/browse/JDK-8221514 https://bugs.openjdk.java.net/browse/JDK-8221577 https://bugs.openjdk.java.net/browse/JDK-8224254 Bug: https://bugs.openjdk.java.net/browse/JDK-8225497 Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/ This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. Thanks, /Jesper From vladimir.kozlov at oracle.com Tue Jun 25 19:57:39 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Jun 2019 12:57:39 -0700 Subject: RFR: JDK-8225497 - Update Graal In-Reply-To: References: Message-ID: Hi Jesper Webrev link is broken. Vladimir On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review the patch to integrate recent Graal changes into OpenJDK. > Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff > > JBS duplicates fixed by this integration: > https://bugs.openjdk.java.net/browse/JDK-8223924 > https://bugs.openjdk.java.net/browse/JDK-8221514 > https://bugs.openjdk.java.net/browse/JDK-8221577 > https://bugs.openjdk.java.net/browse/JDK-8224254 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225497 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/ > > This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. > > Thanks, > /Jesper > From bsrbnd at gmail.com Tue Jun 25 20:12:18 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 25 Jun 2019 22:12:18 +0200 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: Thanks for your approval, Vladimir, and thanks to Jie for his contribution, pushed: http://hg.openjdk.java.net/jdk/jdk/rev/41fd388aaa4d Regards, Bernard On Tue, 25 Jun 2019 at 19:56, Vladimir Ivanov wrote: > > > > Or we could add another test case not to change the existing one: > > http://hg.openjdk.java.net/jdk/submit/rev/ba939c7fbedd > > > > Full branch log: > > http://hg.openjdk.java.net/jdk/submit/log?rev=branch(%22JDK-8225644%22) > > > > Vladimir, does this look good to you? > > Yes, looks good. I'm in favor of a dedicated test rather than > introducing new C1-specific configuration into existing one from langtools. > > Best regards, > Vladimir Ivanov From jesper.wilhelmsson at oracle.com Tue Jun 25 21:21:33 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 25 Jun 2019 23:21:33 +0200 Subject: RFR: JDK-8225497 - Update Graal In-Reply-To: References: Message-ID: <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com> Oops. Fixed. /Jesper > On 25 Jun 2019, at 21:57, Vladimir Kozlov wrote: > > Hi Jesper > > Webrev link is broken. > > Vladimir > > On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> Please review the patch to integrate recent Graal changes into OpenJDK. >> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff >> JBS duplicates fixed by this integration: >> https://bugs.openjdk.java.net/browse/JDK-8223924 >> https://bugs.openjdk.java.net/browse/JDK-8221514 >> https://bugs.openjdk.java.net/browse/JDK-8221577 >> https://bugs.openjdk.java.net/browse/JDK-8224254 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/ >> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >> Thanks, >> /Jesper From vladimir.kozlov at oracle.com Tue Jun 25 23:15:00 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Jun 2019 16:15:00 -0700 Subject: RFR: JDK-8225497 - Update Graal In-Reply-To: <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com> References: <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com> Message-ID: In general changes looks good. But changes are and the testing are done with jdk/jdk as base. We need this 'Update Graal' in JDK 13. I looked on testing results and they look good so far (still running). I linked existing bugs for some failures. And other failures seem were present before. I checked overwritten-diffs.txt and you don't need to apply it. Changes in this 'Update Graal' includes them. And again, for JDK 13 it could be different. Thanks, Vladimir On 6/25/19 2:21 PM, jesper.wilhelmsson at oracle.com wrote: > Oops. Fixed. > /Jesper > >> On 25 Jun 2019, at 21:57, Vladimir Kozlov wrote: >> >> Hi Jesper >> >> Webrev link is broken. >> >> Vladimir >> >> On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote: >>> Hi, >>> Please review the patch to integrate recent Graal changes into OpenJDK. >>> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff >>> JBS duplicates fixed by this integration: >>> https://bugs.openjdk.java.net/browse/JDK-8223924 >>> https://bugs.openjdk.java.net/browse/JDK-8221514 >>> https://bugs.openjdk.java.net/browse/JDK-8221577 >>> https://bugs.openjdk.java.net/browse/JDK-8224254 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/ >>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>> Thanks, >>> /Jesper > From fujie at loongson.cn Wed Jun 26 00:37:13 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 26 Jun 2019 08:37:13 +0800 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: Thank you so much, Bernard and Vladimir Ivanov. On 2019/6/26 ??4:12, B. Blaser wrote: > Thanks for your approval, Vladimir, and thanks to Jie for his > contribution, pushed: > http://hg.openjdk.java.net/jdk/jdk/rev/41fd388aaa4d > > Regards, > Bernard From jesper.wilhelmsson at oracle.com Wed Jun 26 01:46:01 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 26 Jun 2019 03:46:01 +0200 Subject: RFR: JDK-8225497 - Update Graal In-Reply-To: References: <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com> Message-ID: This is a webrev based on JDK 13: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/ I have restarted the testing with this merge. /Jesper > On 26 Jun 2019, at 01:15, Vladimir Kozlov wrote: > > In general changes looks good. > > But changes are and the testing are done with jdk/jdk as base. We need this 'Update Graal' in JDK 13. > > I looked on testing results and they look good so far (still running). I linked existing bugs for some failures. And other failures seem were present before. > > I checked overwritten-diffs.txt and you don't need to apply it. Changes in this 'Update Graal' includes them. And again, for JDK 13 it could be different. > > Thanks, > Vladimir > > On 6/25/19 2:21 PM, jesper.wilhelmsson at oracle.com wrote: >> Oops. Fixed. >> /Jesper >>> On 25 Jun 2019, at 21:57, Vladimir Kozlov wrote: >>> >>> Hi Jesper >>> >>> Webrev link is broken. >>> >>> Vladimir >>> >>> On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote: >>>> Hi, >>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff >>>> JBS duplicates fixed by this integration: >>>> https://bugs.openjdk.java.net/browse/JDK-8223924 >>>> https://bugs.openjdk.java.net/browse/JDK-8221514 >>>> https://bugs.openjdk.java.net/browse/JDK-8221577 >>>> https://bugs.openjdk.java.net/browse/JDK-8224254 >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/ >>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>> Thanks, >>>> /Jesper From rwestrel at redhat.com Wed Jun 26 09:24:06 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 26 Jun 2019 11:24:06 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> <87mui6c6lv.fsf@redhat.com> <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> Message-ID: <87y31obsy1.fsf@redhat.com> > The IR breaks on removal of the initialize node if there's a barrier > between the allocation and the initialize node. Like this: In what way does it break? Is the problem that removing the Initialize node with the current code would also remove the LoadBarrier? Roland. From nils.eliasson at oracle.com Wed Jun 26 12:17:48 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 26 Jun 2019 14:17:48 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <87y31obsy1.fsf@redhat.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> <87mui6c6lv.fsf@redhat.com> <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> <87y31obsy1.fsf@redhat.com> Message-ID: On 2019-06-26 11:24, Roland Westrelin wrote: >> The IR breaks on removal of the initialize node if there's a barrier >> between the allocation and the initialize node. Like this: > In what way does it break? Is the problem that removing the Initialize > node with the current code would also remove the LoadBarrier? The loadbarrier is left hanging. Later in expand_loadbarrier_node we crash when trying to remove a dead node? in PhaseIterGVN::remove_globally_dead_node(Node*). Sometimes "assert(init->in(TypeFunc::Control) == _fallthroughcatchproj)" in macro.cpp line~1006 catches the problem. > > Roland. From rwestrel at redhat.com Wed Jun 26 13:42:55 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 26 Jun 2019 15:42:55 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> <87mui6c6lv.fsf@redhat.com> <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> <87y31obsy1.fsf@redhat.com> Message-ID: <87mui4bgyo.fsf@redhat.com> > The loadbarrier is left hanging. Later in expand_loadbarrier_node we > crash when trying to remove a dead node? in > PhaseIterGVN::remove_globally_dead_node(Node*). > > Sometimes "assert(init->in(TypeFunc::Control) == _fallthroughcatchproj)" > in macro.cpp line~1006 catches the problem. Wouldn't there be a way to remove the init barrier anyway? Doesn't: _igvn.replace_node(ctrl_proj, init->in(TypeFunc::Control)); always work? Roland. From nils.eliasson at oracle.com Wed Jun 26 13:54:57 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 26 Jun 2019 15:54:57 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <87mui4bgyo.fsf@redhat.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> <87mui6c6lv.fsf@redhat.com> <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> <87y31obsy1.fsf@redhat.com> <87mui4bgyo.fsf@redhat.com> Message-ID: <55a7feb7-5246-ee29-54eb-1440e06607d6@oracle.com> On 2019-06-26 15:42, Roland Westrelin wrote: >> The loadbarrier is left hanging. Later in expand_loadbarrier_node we >> crash when trying to remove a dead node? in >> PhaseIterGVN::remove_globally_dead_node(Node*). >> >> Sometimes "assert(init->in(TypeFunc::Control) == _fallthroughcatchproj)" >> in macro.cpp line~1006 catches the problem. > Wouldn't there be a way to remove the init barrier anyway? Doesn't: > > _igvn.replace_node(ctrl_proj, init->in(TypeFunc::Control)); > > always work? _igvn.replace_node(ctrl_proj, init->in(TypeFunc::Control)) should always work. I added the checks to be able to keep the "assert(init->in(TypeFunc::Control) == _fallthroughcatchproj, "allocation control projection");" Mostly because it could be nice to catch any other malformed control flow here. And from the beginning I was a bit unsure if there where other code paths that assumes the alloc->proj->catch->catchproj->initialize pattern. I can remove it if you want to. It definitely gets easier to read. > > Roland. From rwestrel at redhat.com Wed Jun 26 14:09:00 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 26 Jun 2019 16:09:00 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <55a7feb7-5246-ee29-54eb-1440e06607d6@oracle.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> <87mui6c6lv.fsf@redhat.com> <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> <87y31obsy1.fsf@redhat.com> <87mui4bgyo.fsf@redhat.com> <55a7feb7-5246-ee29-54eb-1440e06607d6@oracle.com> Message-ID: <87ftnwbfr7.fsf@redhat.com> > _igvn.replace_node(ctrl_proj, init->in(TypeFunc::Control)) should always > work. > > I added the checks to be able to keep the > "assert(init->in(TypeFunc::Control) == _fallthroughcatchproj, > "allocation control projection");" > > Mostly because it could be nice to catch any other malformed control > flow here. And from the beginning I was a bit unsure if there where > other code paths that assumes the > alloc->proj->catch->catchproj->initialize pattern. > > I can remove it if you want to. It definitely gets easier to read. It makes sense now. I think it would be better to not make: _igvn.replace_node(ctrl_proj, init->in(TypeFunc::Control)); conditional but modify the assert: assert(init->in(TypeFunc::Control) == _fallthroughcatchproj || (bs->is_gc_barrier_node(init->in(TypeFunc::Control ...) Otherwise it seems that sometimes we don't remove the init barrier but it's unclear why. Also a comment would be nice. Roland. From vladimir.x.ivanov at oracle.com Wed Jun 26 16:05:15 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Jun 2019 19:05:15 +0300 Subject: RFR(XL): 6312651: Compiler should only use verified interface types for optimization In-Reply-To: <87ftp9l5cy.fsf@redhat.com> References: <87ftp9l5cy.fsf@redhat.com> Message-ID: Hi Roland, I started looking into the patch. Instead of doing high-level review first, I rebased the patch to jdk/jdk tip and initial round of testing spotted the following problems: (1) build failure on SPARC [1] The following workaround solved the problem: diff --git a/src/hotspot/share/opto/type.hpp b/src/hotspot/share/opto/type.hpp --- a/src/hotspot/share/opto/type.hpp +++ b/src/hotspot/share/opto/type.hpp @@ -804,7 +804,6 @@ class InterfaceSet { private: GrowableArray _list; - static int compare(ciKlass* const &, ciKlass* const & k2); void raw_add(ciKlass* interface); void verify() const; public: @@ -818,6 +817,8 @@ bool empty() const { return _list.length() == 0; } GrowableArray* list() const; + static int compare(ciKlass* const &, ciKlass* const & k2); + inline void* operator new( size_t x ) throw() { Compile* compile = Compile::current(); return compile->type_arena()->Amalloc_D(x); ============ (2) Numerous test failures: # Internal Error (src/hotspot/share/opto/type.cpp:3696), pid=75399, tid=43267 # assert(!ik->is_interface()) failed: no interface here The problem is triggered by array of interface types. Used the following workaround: diff --git a/src/hotspot/share/opto/type.cpp b/src/hotspot/share/opto/type.cpp --- a/src/hotspot/share/opto/type.cpp +++ b/src/hotspot/share/opto/type.cpp @@ -3385,6 +3385,9 @@ assert(interfaces.eq(*TypeAryPtr::_array_interfaces), "unexpected array interfaces"); // Element is an object array. Recursively call ourself. ciKlass* eklass = klass->as_obj_array_klass()->element_klass(); + if (eklass->is_loaded() && eklass->is_interface()) { + eklass = ciEnv::current()->Object_klass(); + } const TypeOopPtr *etype = TypeOopPtr::make_from_klass_common(eklass, TypePtr::interfaces(eklass, true, true, true), false, try_for_exact); bool xk = etype->klass_is_exact(); const TypeAry* arr0 = TypeAry::make(etype, TypeInt::POS); ============ (3) Unloaded classes in signatures trigger the following assert: # Internal Error (open/src/hotspot/share/ci/ciInstanceKlass.hpp:145), pid=6557, tid=6570 # assert(is_loaded()) failed: must be loaded V [libjvm.so+0x5ff406] ciInstanceKlass::is_interface()+0x56 V [libjvm.so+0x17049ad] TypeKlassPtr::TypeKlassPtr(Type::TYPES, TypePtr::PTR, ciKlass*, TypePtr::InterfaceSet const&, int)+0xfd V [libjvm.so+0x1712d9b] TypeInstKlassPtr::TypeInstKlassPtr(TypePtr::PTR, ciKlass*, TypePtr::InterfaceSet const&, int)+0x2b V [libjvm.so+0x1708284] TypeInstPtr::as_klass_type(bool) const+0xa4 V [libjvm.so+0x14441b7] Parse::check_interpreter_type(Node*, Type const*, SafePointNode*&)+0x467 V [libjvm.so+0x1444c51] Parse::load_interpreter_state(Node*)+0x971 V [libjvm.so+0x14457bd] Parse::Parse(JVMState*, ciMethod*, float)+0x60d Used workaround: diff --git a/src/hotspot/share/opto/parse1.cpp b/src/hotspot/share/opto/parse1.cpp --- a/src/hotspot/share/opto/parse1.cpp +++ b/src/hotspot/share/opto/parse1.cpp @@ -167,7 +167,7 @@ // When paths are cut off, values at later merge points can rise // toward more specific classes. Make sure these specific classes // are still in effect. - if (tp != NULL) { + if (tp != NULL && tp->is_loaded()) { // TypeFlow asserted a specific object type. Value must have that type. Node* bad_type_ctrl = NULL; l = gen_checkcast(l, makecon(tp->as_klass_type()->cast_to_exactness(true)), &bad_type_ctrl); ============ (4) runtime/Unsafe/AllocateInstance.java java.lang.AssertionError: Should throw InstantiationException for an interface at AllocateInstance.testInterface(AllocateInstance.java:71) at AllocateInstance.main(AllocateInstance.java:81) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) at java.base/java.lang.Thread.run(Thread.java:830) Initial problem is EA eliminates non-escaping allocation of an interface class (ik == Object vs cik == InterfaceClass): src/hotspot/share/opto/escape.cpp @@ -819,11 +819,12 @@ } } } else { // Allocate instance - ciInstanceKlass* ik = kt->is_instklassptr()->instance_klass(); - if (ik->is_subclass_of(_compile->env()->Thread_klass()) || - ik->is_subclass_of(_compile->env()->Reference_klass()) || - !ik->can_be_instantiated() || - ik->has_finalizer()) { es = PointsToNode::GlobalEscape; } } Then, Allocate expansion uses wrong instance layout info (again Object vs InterfaceClass): src/hotspot/share/opto/graphKit.cpp @@ -3470,7 +3470,7 @@ } lhelper = Klass::array_layout_helper(elem); } else { - lhelper = inst_klass->is_instklassptr()->instance_klass()->layout_helper(); } if (lhelper != Klass::_lh_neutral_value) { constant_value = lhelper; I'll wait for the fixes before initiating broader testing. Best regards, Vladimir Ivanov [1] src/hotspot/share/opto/type.cpp, line 2977: Error: static TypePtr::InterfaceSet::compare(ciKlass*const&, ciKlass*const&) is not accessible from ciKlass* GrowableArray::insert_sorted<&TypePtr::InterfaceSet::compare>(ciKlass*const&). src/hotspot/share/opto/type.cpp, line 2977: Where, temwhileinst: While instantiating "ciKlass* GrowableArray::insert_sorted<&TypePtr::InterfaceSet::compare>(ciKlass*const&)". src/hotspot/share/opto/type.cpp, line 2977: Where, teminstend: Instantiated from non-template code. src/hotspot/share/opto/type.cpp, line 2977: Error: static TypePtr::InterfaceSet::compare(ciKlass*const&, ciKlass*const&) is not accessible from ciKlass* GrowableArray::insert_sorted<&TypePtr::InterfaceSet::compare>(ciKlass*const&). src/hotspot/share/opto/type.cpp, line 2977: Where, temwhileinst: While instantiating "ciKlass* GrowableArray::insert_sorted<&TypePtr::InterfaceSet::compare>(ciKlass*const&)". src/hotspot/share/opto/type.cpp, line 2977: Where, teminstend: Instantiated from non-template code. On 20/05/2019 14:42, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/6312651/webrev.00/ > > This is a fix for a bug that John filed 14 years ago (almost) but has > always affected c2 as far as I understand. The fix is implemented along > the lines of John's recommendation: 1) the type system should keep track > of an object's instance class and the set of interfaces it implements > separately (or array of instance klass + set of interfaces), 2) > interfaces in signatures should not be trusted. > > For 1), the _klass in TypeOopPtr/TypeKlassPtr now only refers to > instance classes (or arrays of instance class). TypeOopPtr/TypeKlassPtr > has an extra field _interfaces that carries the set of interfaces > implemented by that type. > > For klass pointers, TypeKlassPtr is no longer sufficient because for > arrays, we need the type to also include interfaces that the element > implements. So I added 2 classes to the type system, TypeKlassInstPtr > and TypeAryKlassPtr that mirror TypeInstPtr/TypeAryPtr. TypeAryKlassPtr > has a TypeKlassPtr element which can then record what interfaces the > element type implements. The meet implementation for both also mirrors > TypeInstPtr/TypeAryPtr closely. > > In the existing implementation the TypeOopPtr/TypeKlassPtr klass() > accessor is used in a lot of places to perform class equality checks, > subtyping tests or to build a TypeOopPtr from a TypeKlassPtr or the > other way around. That can't work now because klass() only gives partial > information about the type. Rather than expose _klass and _interfaces > through accessors, I have: > > - made the klass() accessor non public so code that's not closely tied > to the actual type system implementation shouldn't use it > > - made some operations go through the type classes: testing for class > equality should be done through klass_eq() which tests both class and > interface set equality, same goes for subtyping tests. Creating a > TypeKlassPtr from a TypeOopPtr or the other way around is now always > done with the as_klass_type()/as_instance_type() methods. > > - introduced 3 new accessors: instance_klass() on > TypeInstPtr/TypeInstKlassPtr which only returns the instance class, > ignoring any interface implemented by the type; exact_klass() on > TypeOopPtr/TypeKlassPtr which only works for exact types and can > return an interface or array of interfaces; base_element_type() on > TypeAryPtr/TypeAryKlassPtr() which returns the base element of the > array and in case of an array of objects, only the instance class, not > whatever interface the element implements. These 3 are AFAICT good > enough to support existing c2 optimizations. > > For 2), TypeOopPtr::cast_to_non_interface() is used to filter out > interfaces whenever signatures are used. > > As expected, this change makes several workarounds no longer necessary > and cleans up the code quite a bit. For instance, > CheckCastPPNode::Value() now falls back to the "right" implementation of > ConstraintCastNode::Value() which leverages the type system. > > Fixing CheckCastPPNode::Value() exposes a bug in the C2 type checking > logic: if a type check is proved to always fail during optimizations, > the CheckCastPPNode becomes top, but the actual type checking logic in > Phase::gen_subtype_check() doesn't always optimize out so the data path > dies but not the control path. To fix that, I added a > PartialSubtypeCheckNode::Value() method that triggers on subtype check > failures consistently with CheckCastPPNode::Value. Problem is > PartialSubtypeCheckNode is not checked first in > Phase::gen_subtype_check(). So I added a duplicate test on the > PartialSubtypeCheckNode result first in that logic, under an Opaque4Node > so the actual is never compiled in the final code. > > Note that "8220416: Comparison of klass pointers is not optimized any > more" is fixed by this. > > CastNullCheckDroppingsTest.java needs a change because > testObjClassCast() has a call to objClass.cast() followed by a cast to > String, so 2 casts in a raw once compiled. With the existing > implementation, c2 can't see the casts as redundant and it keeps the > second one. That one triggers a deopt if the test is passed null. The > Class::cast implementation nevers traps for null. With the updated > implementation, c2 sees the second cast as useless and optimizes it out. > > I dropped the CmpNNode::sub() becasue CmpN nodes are only created during > final graph reshape so this is dead code. > > Performance is unaffected by this change AFAICT> > > Roland. > From vladimir.x.ivanov at oracle.com Wed Jun 26 16:21:37 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Jun 2019 19:21:37 +0300 Subject: RFR(XL): 6312651: Compiler should only use verified interface types for optimization In-Reply-To: <87ftp9l5cy.fsf@redhat.com> References: <87ftp9l5cy.fsf@redhat.com> Message-ID: <5f8f5fbf-504d-5cb5-c327-9269020126b3@oracle.com> Roland, > Fixing CheckCastPPNode::Value() exposes a bug in the C2 type checking > logic: if a type check is proved to always fail during optimizations, > the CheckCastPPNode becomes top, but the actual type checking logic in > Phase::gen_subtype_check() doesn't always optimize out so the data path > dies but not the control path. To fix that, I added a > PartialSubtypeCheckNode::Value() method that triggers on subtype check > failures consistently with CheckCastPPNode::Value. Problem is > PartialSubtypeCheckNode is not checked first in > Phase::gen_subtype_check(). So I added a duplicate test on the > PartialSubtypeCheckNode result first in that logic, under an Opaque4Node > so the actual is never compiled in the final code. I have been working on JDK-8222075 [1] to fix a performance regression (JDK-8220708 [2]) caused by interface subtype checks. I checked that your patch fixes it. What I came up with is a solution based on late expansion of subtype checks [3]. It makes IR shape simpler (guard + deopt) and it works well with predicate hoisting. Do you see any value in representing subtype checks as macro nodes once C2 type system handles interfaces better? Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8222075 [2] https://bugs.openjdk.java.net/browse/JDK-8220708 [3] http://cr.openjdk.java.net/~vlivanov/8222075/webrev.00/ From vladimir.kozlov at oracle.com Wed Jun 26 16:33:40 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2019 09:33:40 -0700 Subject: RFR: JDK-8225497 - Update Graal In-Reply-To: References: <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com> Message-ID: <74b8ac64-32b4-ff4c-3708-97432697680d@oracle.com> Looks good. I looked on testing results. We still hit gcbasher failures but it is not new and we will work on it. Other failures I known timeout or other known bugs. I think we can push this into jdk 13. Thanks, Vladimir On 6/25/19 6:46 PM, jesper.wilhelmsson at oracle.com wrote: > This is a webrev based on JDK 13: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/ > I have restarted the testing with this merge. > /Jesper > >> On 26 Jun 2019, at 01:15, Vladimir Kozlov wrote: >> >> In general changes looks good. >> >> But changes are and the testing are done with jdk/jdk as base. We need this 'Update Graal' in JDK 13. >> >> I looked on testing results and they look good so far (still running). I linked existing bugs for some failures. And other failures seem were present before. >> >> I checked overwritten-diffs.txt and you don't need to apply it. Changes in this 'Update Graal' includes them. And again, for JDK 13 it could be different. >> >> Thanks, >> Vladimir >> >> On 6/25/19 2:21 PM, jesper.wilhelmsson at oracle.com wrote: >>> Oops. Fixed. >>> /Jesper >>>> On 25 Jun 2019, at 21:57, Vladimir Kozlov wrote: >>>> >>>> Hi Jesper >>>> >>>> Webrev link is broken. >>>> >>>> Vladimir >>>> >>>> On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote: >>>>> Hi, >>>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>>> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff >>>>> JBS duplicates fixed by this integration: >>>>> https://bugs.openjdk.java.net/browse/JDK-8223924 >>>>> https://bugs.openjdk.java.net/browse/JDK-8221514 >>>>> https://bugs.openjdk.java.net/browse/JDK-8221577 >>>>> https://bugs.openjdk.java.net/browse/JDK-8224254 >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497 >>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/ >>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>>> Thanks, >>>>> /Jesper > From vladimir.kozlov at oracle.com Wed Jun 26 19:13:39 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2019 12:13:39 -0700 Subject: RFR: JDK-8225497 - Update Graal In-Reply-To: <74b8ac64-32b4-ff4c-3708-97432697680d@oracle.com> References: <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com> <74b8ac64-32b4-ff4c-3708-97432697680d@oracle.com> Message-ID: <8472328F-CFC3-4CD8-A1F4-84CA20FCE080@oracle.com> After discussing with Mikael I was convinced to not push this Graal update into JDK 13 - too many changes not related to listed bugs it fixed. This should go only into current JDK. Thanks Vladimir > On Jun 26, 2019, at 9:33 AM, Vladimir Kozlov wrote: > > Looks good. > > I looked on testing results. We still hit gcbasher failures but it is not new and we will work on it. > Other failures I known timeout or other known bugs. > > I think we can push this into jdk 13. > > Thanks, > Vladimir > >> On 6/25/19 6:46 PM, jesper.wilhelmsson at oracle.com wrote: >> This is a webrev based on JDK 13: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/ >> I have restarted the testing with this merge. >> /Jesper >>> On 26 Jun 2019, at 01:15, Vladimir Kozlov wrote: >>> >>> In general changes looks good. >>> >>> But changes are and the testing are done with jdk/jdk as base. We need this 'Update Graal' in JDK 13. >>> >>> I looked on testing results and they look good so far (still running). I linked existing bugs for some failures. And other failures seem were present before. >>> >>> I checked overwritten-diffs.txt and you don't need to apply it. Changes in this 'Update Graal' includes them. And again, for JDK 13 it could be different. >>> >>> Thanks, >>> Vladimir >>> >>>> On 6/25/19 2:21 PM, jesper.wilhelmsson at oracle.com wrote: >>>> Oops. Fixed. >>>> /Jesper >>>>> On 25 Jun 2019, at 21:57, Vladimir Kozlov wrote: >>>>> >>>>> Hi Jesper >>>>> >>>>> Webrev link is broken. >>>>> >>>>> Vladimir >>>>> >>>>>> On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote: >>>>>> Hi, >>>>>> Please review the patch to integrate recent Graal changes into OpenJDK. >>>>>> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff >>>>>> JBS duplicates fixed by this integration: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223924 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8221514 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8221577 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8224254 >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497 >>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/ >>>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug. >>>>>> Thanks, >>>>>> /Jesper From smita.kamath at intel.com Wed Jun 26 23:27:48 2019 From: smita.kamath at intel.com (Kamath, Smita) Date: Wed, 26 Jun 2019 23:27:48 +0000 Subject: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. In-Reply-To: <6563F381B547594081EF9DE181D0791296149EE6@fmsmsx123.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791296149EE6@fmsmsx123.amr.corp.intel.com> Message-ID: <6563F381B547594081EF9DE181D079129615C797@fmsmsx123.amr.corp.intel.com> Hi All, Could you please review AES-ECB implemented using AVX512+VAES instructions. Thanks and Regards, Smita Kamath From: Kamath, Smita Sent: Tuesday, June 11, 2019 4:23 PM To: 'Vladimir Kozlov' ; Anthony Scarpino Cc: Viswanathan, Sandhya ; Shravya Rukmannagari (shravya.rukmannagari at intel.com) ; hotspot compiler ; Shemy, Regev Subject: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. Hi Vladimir, As per Intel Architecture Instruction Set Reference [1] Vector AES Encrypt and Decrypt Operations will be supported in future Intel ISA. We would like to contribute optimizations for AES-ECB algorithm to support encryption and decryption operations using AVX512+VAES instructions. These optimizations are for x86_64 architecture that have AVX512-VAES enabled. Shravya(cc'ed) and I are co-contributors. Shay Gueron(shay.gueron at intel.com) and Regev Shemy (regev.shemy at intel.com) are the authors of the algorithm. I have tested the algorithm with Intel SDE [2] to confirm encoding and semantics are correctly implemented. Please take a look and let me know if you have any questions or comments. http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.00/ Bug Id: https://bugs.openjdk.java.net/browse/JDK-8225625 [1] https://software.intel.com/sites/default/files/managed/ad/01/253666-sdm-vol-2a.pdf (Page 152 - 159) [2] https://software.intel.com/en-us/articles/intel-software-development-emulator Regards, Smita Kamath From rwestrel at redhat.com Thu Jun 27 08:19:15 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 27 Jun 2019 10:19:15 +0200 Subject: RFR(XL): 6312651: Compiler should only use verified interface types for optimization In-Reply-To: References: <87ftp9l5cy.fsf@redhat.com> Message-ID: <87d0izbfuk.fsf@redhat.com> Hi Vladimir, > I started looking into the patch. > > Instead of doing high-level review first, I rebased the patch to jdk/jdk > tip and initial round of testing spotted the following problems: Excellent. Thank you. > (2) Numerous test failures: > # Internal Error (src/hotspot/share/opto/type.cpp:3696), pid=75399, > tid=43267 > # assert(!ik->is_interface()) failed: no interface here Does it fail that way with a test I can run? > (3) Unloaded classes in signatures trigger the following assert: Same as above, can I reproduce it? > (4) runtime/Unsafe/AllocateInstance.java > java.lang.AssertionError: Should throw InstantiationException for an > interface > at AllocateInstance.testInterface(AllocateInstance.java:71) > at AllocateInstance.main(AllocateInstance.java:81) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) > at java.base/java.lang.Thread.run(Thread.java:830) That one runs fine with no option or -Xcomp. Does it need any specific option to fail? Thanks for investigating failures and suggesting work arounds. I'd like to understand failures better though. Roland. From tobias.hartmann at oracle.com Thu Jun 27 09:02:19 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 27 Jun 2019 11:02:19 +0200 Subject: [14] RFR(S): 8226879: Memory leak in Type::hashcons Message-ID: Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8226879 http://cr.openjdk.java.net/~thartmann/8226879/webrev.00/ We might allocate a new type in xdual() but if the type is self symmetric we just discard it without calling delete. This only affects the per-compilation arena (which is freed after compilation). Thanks, Tobias From rwestrel at redhat.com Thu Jun 27 11:17:41 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 27 Jun 2019 13:17:41 +0200 Subject: RFR(XL): 6312651: Compiler should only use verified interface types for optimization In-Reply-To: <5f8f5fbf-504d-5cb5-c327-9269020126b3@oracle.com> References: <87ftp9l5cy.fsf@redhat.com> <5f8f5fbf-504d-5cb5-c327-9269020126b3@oracle.com> Message-ID: <87a7e3b7l6.fsf@redhat.com> > Do you see any value in representing subtype checks as macro nodes once > C2 type system handles interfaces better? I noticed that sometimes (profile) predication moves the second test in the general subtype check out of loop but not the first one (because its input is not loop invariant). Because that second test is really designed to be executed only after the first one fails, it can fail for a valid subtype check when it's a predicate causing (profile) predication to be disabled on next compilation. A macro node would solve that problem. Beyond that, turning subtype checks into a macro nodes sound like a reasonable move. Roland. From vladimir.x.ivanov at oracle.com Thu Jun 27 14:12:12 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 27 Jun 2019 17:12:12 +0300 Subject: RFR(XL): 6312651: Compiler should only use verified interface types for optimization In-Reply-To: <87d0izbfuk.fsf@redhat.com> References: <87ftp9l5cy.fsf@redhat.com> <87d0izbfuk.fsf@redhat.com> Message-ID: It seems the trick here is the rebase I did. I failed to link the failures I see to the rebase changes, but, please, double-check I didn't break anything. I use the following changes on top of your patch: http://cr.openjdk.java.net/~vlivanov/roland/6312651/rebase.00/ $ hg log -r qparent changeset: 55511:91b38bfb9079 tag: qparent user: aoqi date: Thu Jun 27 18:00:54 2019 +0800 summary: 8226871: invalid use of incomplete type class MacroAssembler when building minimal after JDK-8191278 >> (2) Numerous test failures: >> # Internal Error (src/hotspot/share/opto/type.cpp:3696), pid=75399, >> tid=43267 >> # assert(!ik->is_interface()) failed: no interface here > > Does it fail that way with a test I can run? For example, gc/epsilon/TestArraycopyCheckcast.java # Internal Error (/Users/vlivanov/ws/jdk/open/jdk/src/hotspot/share/opto/type.cpp:3696), pid=49533, tid=16387 # assert(!ik->is_interface()) failed: no interface here Current CompileTask: C2: 2313 321 b 4 jdk.internal.module.SystemModuleFinders$SystemModuleFinder:: (21 bytes) V [libjvm.dylib+0x11c23bb] TypeInstPtr::make(TypePtr::PTR, ciKlass*, TypePtr::InterfaceSet const&, bool, ciObject*, int, int, TypePtr const*, int)+0x23b V [libjvm.dylib+0x11cb794] TypeOopPtr::make_from_klass_common(ciKlass*, TypePtr::InterfaceSet const&, bool, bool)+0x2e4 V [libjvm.dylib+0x11cb87c] TypeOopPtr::make_from_klass_common(ciKlass*, TypePtr::InterfaceSet const&, bool, bool)+0x3cc V [libjvm.dylib+0x2e63ee] TypeOopPtr::make_from_klass(ciKlass*)+0x3e V [libjvm.dylib+0x11be347] Type::get_const_type(ciType*)+0x67 V [libjvm.dylib+0x11c6393] TypeTuple::make_domain(ciInstanceKlass*, ciSignature*)+0x173 V [libjvm.dylib+0x11d8474] TypeFunc::make(ciMethod*)+0x94 V [libjvm.dylib+0x5d0947] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xa37 >> (3) Unloaded classes in signatures trigger the following assert: > > Same as above, can I reproduce it? Unfortunately, the failing test is not part of open repository. The test triggers an OSR compilation of a method with a unloaded method in its signature. As the stack trace shows, the assert is fired during interpreter state unpacking. >> (4) runtime/Unsafe/AllocateInstance.java >> java.lang.AssertionError: Should throw InstantiationException for an >> interface >> at AllocateInstance.testInterface(AllocateInstance.java:71) >> at AllocateInstance.main(AllocateInstance.java:81) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> at >> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) >> at java.base/java.lang.Thread.run(Thread.java:830) > > That one runs fine with no option or -Xcomp. Does it need any specific > option to fail? It fails reliably w/o any additional flags. Best regards, Vladimir Ivanov From alfonso.peterssen at oracle.com Thu Jun 27 14:16:25 2019 From: alfonso.peterssen at oracle.com (=?UTF-8?Q?Alfonso=c2=b2_Peterssen?=) Date: Thu, 27 Jun 2019 16:16:25 +0200 Subject: hotspot-compiler-dev Digest, Vol 145, Issue 95 In-Reply-To: References: Message-ID: <1a33eef6-afad-71a8-ec70-bbbf7fc805f8@oracle.com> We considered adding interfaces to the compiler type system ("stamps") in Graal as well, but we dropped the effort since there was no real performance benefit (see below) to justify the compiler performance hit. Measuring the impact of such a change is hard, we opted to measure how often the "stamps" with interfaces produced a better, more precise type. Note that this number is an upper-bound, that does't not necessarily translates to performance gains, most of the time this "improved" type is discarded or not used at all. In our tests we saw a mere 1% improvement for Java (dacapo), which means that with the interfaces we had a "better" type just 1% of the time. For Scala (scala-dacapo) the impact was slightly higher, just below 3% since traits are encoded using interfaces. Scala is in general interface-heavy; any effect would be more visible in Scala workloads. We also tried several representations: flat sets (the representation you are using) and cannonical sets (minimal set of disjoint interface roots) which are more compact but union/intersection operations are more expensive complexity-wise. The measurements revelead that the cannonical sets were more compact than the flat sets in the wild, while the cost of union/intersection operations was comparable (e.g. the cannonical sets operations were more expensive but they where always very small). Another issue with having interfaces is that it can easily explode on pathological cases; for such cases we also considered bounded sets (dropping interfaces) but again saw no improvement and had issues because we couldn't trust the "stamp" anymore (since some interfaces could be missing). The last option we considered was bounded union types, think 1 | 12 instead of 1..12; we tried for types and for ints, but again, saw little improvements that didn't justify the complexity and the compiler perf hit. We have different implementations, so your approach may still be worth it performance wise (please do try some Scala workloads). Finally... it's very hard to change the "stamps" in Graal without breaking things, but it seems you succeeded which may indicate that your "stamps" are not abused as much all over the codebase as the Graal ones. Best, Alfonso2 On 6/27/19 2:00 PM, hotspot-compiler-dev-request at openjdk.java.net wrote: > Send hotspot-compiler-dev mailing list submissions to > hotspot-compiler-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.openjdk.java.net/mailman/listinfo/hotspot-compiler-dev > or, via email, send a message with subject or body 'help' to > hotspot-compiler-dev-request at openjdk.java.net > > You can reach the person managing the list at > hotspot-compiler-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of hotspot-compiler-dev digest..." > > > Today's Topics: > > 1. Re: RFR(XL): 6312651: Compiler should only use verified > interface types for optimization (Roland Westrelin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 27 Jun 2019 13:17:41 +0200 > From: Roland Westrelin > To: Vladimir Ivanov , > hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(XL): 6312651: Compiler should only use verified > interface types for optimization > Message-ID: <87a7e3b7l6.fsf at redhat.com> > Content-Type: text/plain > > >> Do you see any value in representing subtype checks as macro nodes once >> C2 type system handles interfaces better? > I noticed that sometimes (profile) predication moves the second test in > the general subtype check out of loop but not the first one (because its > input is not loop invariant). Because that second test is really > designed to be executed only after the first one fails, it can fail for > a valid subtype check when it's a predicate causing (profile) > predication to be disabled on next compilation. A macro node would solve > that problem. Beyond that, turning subtype checks into a macro nodes > sound like a reasonable move. > > Roland. > > > End of hotspot-compiler-dev Digest, Vol 145, Issue 95 > ***************************************************** From vladimir.kozlov at oracle.com Thu Jun 27 15:41:32 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Jun 2019 08:41:32 -0700 Subject: [14] RFR(S): 8226879: Memory leak in Type::hashcons In-Reply-To: References: Message-ID: <2D3C1E6A-BA0C-4FBE-9F43-21E277E9EAC7@oracle.com> Good. Thanks Vladimir > On Jun 27, 2019, at 2:02 AM, Tobias Hartmann wrote: > > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8226879 > http://cr.openjdk.java.net/~thartmann/8226879/webrev.00/ > > We might allocate a new type in xdual() but if the type is self symmetric we just discard it without > calling delete. This only affects the per-compilation arena (which is freed after compilation). > > Thanks, > Tobias From igor.ignatyev at oracle.com Thu Jun 27 18:38:42 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 27 Jun 2019 11:38:42 -0700 Subject: RFR(T) : 8226905 : unproblem list applications/ctw/modules/* tests on windows Message-ID: <0E91E002-C714-4B11-8DE9-07E86B08EDE1@oracle.com> http://cr.openjdk.java.net/~iignatyev//8226905/webrev.00 > 4 lines changed: 0 ins; 4 del; 0 mod Hi all, could you please review this tiny and trivial patch which unproblem-lists applications/ctw/modules/java_desktop.java, java_desktop_2.java, and jdk_jconsole.java tests? from JBS: > applications/ctw/modules/java_desktop.java, applications/ctw/modules/java_desktop_2.java, and applications/ctw/modules/jdk_jconsole.java were problem-listed due to JDK-8205016. further analysis showed that it's rather a configuration issue -- we run these tests on hosts which look like headful but aren't properly configured, so when awt gets initialized it (most probably) rightfully complains about that and show an error message box. > > the solution was to run these tests on headful hosts or w/ "-Djava.awt.headless=true". testing: the affected tests on windows hosts w/ -Djava.awt.headless=true JBS: https://bugs.openjdk.java.net/browse/JDK-8226905 webrev: http://cr.openjdk.java.net/~iignatyev//8226905/webrev.00/index.html Thanks, -- Igor From igor.ignatyev at oracle.com Thu Jun 27 22:27:50 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 27 Jun 2019 15:27:50 -0700 Subject: RFR(M) [14] : 8225654 : rework vmTestbase/jit/graph In-Reply-To: <3A418E88-2FBA-4253-A249-C30A6DC1C5CC@oracle.com> References: <3A418E88-2FBA-4253-A249-C30A6DC1C5CC@oracle.com> Message-ID: <86F0F16D-4170-4548-9E3B-84AEC0C7CEB4@oracle.com> ping? -- Igor > On Jun 19, 2019, at 5:32 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html >> 2536 lines changed: 354 ins; 787 del; 1395 mod; > > > Hi all, > > could you please review the patch which reworks vmTestbase/jit/graph to make them more readable and reliable? that includes the following changes: > - as none of our cgt* tests used more than 1 thread, all test execution is now done in main thread; > - use exception instead of System::exit to signal problems; > - replaced ExecDriver execution mode w/ regular 'main'; > - make the tests to use reproducible random from jdk.test.lib.Utils ; > - close filereader opened by jit/graph/Globals ; > - moved tests to one directory; > - mark a test as skipped if OOME or SOE happens > - editorial changes such as adding { }, fixing typos, removing commented code, etc. > > webrev: http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8225654 > testing: test/hotspot/jtreg/vmTestbase/jit/graph on linux-x64,windows-x64,macosx-x64,solaris-sparcv9 > > Thanks, > -- Igor > > From dean.long at oracle.com Thu Jun 27 23:49:09 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 27 Jun 2019 16:49:09 -0700 Subject: [13] RFR(XXS) 8226533: JVMCI: findUniqueConcreteMethod should handle statically bindable methods directly Message-ID: https://bugs.openjdk.java.net/browse/JDK-8226533 http://cr.openjdk.java.net/~dlong/8226533/webrev/ This fixes a problem that shows up with -XX:+BootstrapJVMCI after JDK-8223050.? Thanks Doug for the patch. dl From vladimir.kozlov at oracle.com Fri Jun 28 00:23:44 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Jun 2019 17:23:44 -0700 Subject: [13] RFR(XXS) 8226533: JVMCI: findUniqueConcreteMethod should handle statically bindable methods directly In-Reply-To: References: Message-ID: <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com> Looks good. Thanks Vladimir > On Jun 27, 2019, at 4:49 PM, dean.long at oracle.com wrote: > > https://bugs.openjdk.java.net/browse/JDK-8226533 > http://cr.openjdk.java.net/~dlong/8226533/webrev/ > > This fixes a problem that shows up with -XX:+BootstrapJVMCI after JDK-8223050. Thanks Doug for the patch. > > dl From dean.long at oracle.com Fri Jun 28 00:52:26 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 27 Jun 2019 17:52:26 -0700 Subject: [13] RFR(XXS) 8226533: JVMCI: findUniqueConcreteMethod should handle statically bindable methods directly In-Reply-To: <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com> References: <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com> Message-ID: <0c9c376b-7cea-66dc-e13d-302f02167c01@oracle.com> Thanks Vladimir. dl On 6/27/19 5:23 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks > Vladimir > >> On Jun 27, 2019, at 4:49 PM, dean.long at oracle.com wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8226533 >> http://cr.openjdk.java.net/~dlong/8226533/webrev/ >> >> This fixes a problem that shows up with -XX:+BootstrapJVMCI after JDK-8223050. Thanks Doug for the patch. >> >> dl From tobias.hartmann at oracle.com Fri Jun 28 07:13:30 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 28 Jun 2019 09:13:30 +0200 Subject: [14] RFR(S): 8226879: Memory leak in Type::hashcons In-Reply-To: <2D3C1E6A-BA0C-4FBE-9F43-21E277E9EAC7@oracle.com> References: <2D3C1E6A-BA0C-4FBE-9F43-21E277E9EAC7@oracle.com> Message-ID: <2aa0d302-fa24-e5bc-64cd-ed1aa000907c@oracle.com> Thanks Vladimir! Pushed. Best regards, Tobias On 27.06.19 17:41, Vladimir Kozlov wrote: > Good. > > Thanks > Vladimir > >> On Jun 27, 2019, at 2:02 AM, Tobias Hartmann wrote: >> >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8226879 >> http://cr.openjdk.java.net/~thartmann/8226879/webrev.00/ >> >> We might allocate a new type in xdual() but if the type is self symmetric we just discard it without >> calling delete. This only affects the per-compilation arena (which is freed after compilation). >> >> Thanks, >> Tobias > From nils.eliasson at oracle.com Fri Jun 28 08:46:55 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 28 Jun 2019 10:46:55 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <87ftnwbfr7.fsf@redhat.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> <87mui6c6lv.fsf@redhat.com> <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> <87y31obsy1.fsf@redhat.com> <87mui4bgyo.fsf@redhat.com> <55a7feb7-5246-ee29-54eb-1440e06607d6@oracle.com> <87ftnwbfr7.fsf@redhat.com> Message-ID: <15b10e5c-7382-634e-7e3c-2a36de2737ef@oracle.com> New version: The replace is unconditional like you suggested, and then the rest happens in an assert block. I also improved it to handle multiple barriers. That required a new barrierset method that you will have to implement in Shenandoah, but the base implementation should do unless you have hit this problem too. I also added a check that the barrier traversal makes progress to catch any instances of missing implementations. http://cr.openjdk.java.net/~neliasso/8226287/webrev.02 Regards, Nils On 2019-06-26 16:09, Roland Westrelin wrote: >> _igvn.replace_node(ctrl_proj, init->in(TypeFunc::Control)) should always >> work. >> >> I added the checks to be able to keep the >> "assert(init->in(TypeFunc::Control) == _fallthroughcatchproj, >> "allocation control projection");" >> >> Mostly because it could be nice to catch any other malformed control >> flow here. And from the beginning I was a bit unsure if there where >> other code paths that assumes the >> alloc->proj->catch->catchproj->initialize pattern. >> >> I can remove it if you want to. It definitely gets easier to read. > It makes sense now. I think it would be better to not make: > > _igvn.replace_node(ctrl_proj, init->in(TypeFunc::Control)); > > conditional but modify the assert: > > assert(init->in(TypeFunc::Control) == _fallthroughcatchproj || > (bs->is_gc_barrier_node(init->in(TypeFunc::Control ...) > > Otherwise it seems that sometimes we don't remove the init barrier but > it's unclear why. Also a comment would be nice. > > Roland. From rwestrel at redhat.com Fri Jun 28 08:52:14 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 28 Jun 2019 10:52:14 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <15b10e5c-7382-634e-7e3c-2a36de2737ef@oracle.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> <87mui6c6lv.fsf@redhat.com> <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> <87y31obsy1.fsf@redhat.com> <87mui4bgyo.fsf@redhat.com> <55a7feb7-5246-ee29-54eb-1440e06607d6@oracle.com> <87ftnwbfr7.fsf@redhat.com> <15b10e5c-7382-634e-7e3c-2a36de2737ef@oracle.com> Message-ID: <875zoqay81.fsf@redhat.com> > http://cr.openjdk.java.net/~neliasso/8226287/webrev.02 That looks good to me. Thanks for making the change. Roland. From nils.eliasson at oracle.com Fri Jun 28 09:32:38 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 28 Jun 2019 11:32:38 +0200 Subject: [13] RFR(XS):8226287: Make process_users_of_allocation handle gc barriers In-Reply-To: <875zoqay81.fsf@redhat.com> References: <7aebc886-db96-c4e5-382f-4e0f59ce46b3@oracle.com> <87mui6c6lv.fsf@redhat.com> <4b0707ff-20e3-17ad-1ca4-dcf61920227a@oracle.com> <87y31obsy1.fsf@redhat.com> <87mui4bgyo.fsf@redhat.com> <55a7feb7-5246-ee29-54eb-1440e06607d6@oracle.com> <87ftnwbfr7.fsf@redhat.com> <15b10e5c-7382-634e-7e3c-2a36de2737ef@oracle.com> <875zoqay81.fsf@redhat.com> Message-ID: <74409bc9-7ddd-e5c3-4d01-d21111becf5e@oracle.com> Thanks! // Nils On 2019-06-28 10:52, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~neliasso/8226287/webrev.02 > That looks good to me. Thanks for making the change. > > Roland. From dean.long at oracle.com Fri Jun 28 18:13:09 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 28 Jun 2019 11:13:09 -0700 Subject: [13] RFR(XXS) 8226533: JVMCI: findUniqueConcreteMethod should handle statically bindable methods directly In-Reply-To: <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com> References: <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com> Message-ID: Since Doug Simon is the contributor, I'll list myself as the second reviewer and push this. dl On 6/27/19 5:23 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks > Vladimir > >> On Jun 27, 2019, at 4:49 PM, dean.long at oracle.com wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8226533 >> http://cr.openjdk.java.net/~dlong/8226533/webrev/ >> >> This fixes a problem that shows up with -XX:+BootstrapJVMCI after JDK-8223050. Thanks Doug for the patch. >> >> dl From igor.veresov at oracle.com Fri Jun 28 22:23:16 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 28 Jun 2019 15:23:16 -0700 Subject: RFR(S): 8226778 [JVMCI] Handle unpacking properly in Deoptimziation::get_cached_box() Message-ID: This is a forward port of the change to jvmci-8. It fixes a problem with decoding of StackValue on big-endian platforms. The fix is for JDK13, with intention do be automatically forward ported to JDK14. Webrev: http://cr.openjdk.java.net/~iveresov/8226778/webrev.00/ Thanks! igor From vladimir.kozlov at oracle.com Sat Jun 29 03:53:00 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 28 Jun 2019 20:53:00 -0700 Subject: RFR(S): 8226778 [JVMCI] Handle unpacking properly in Deoptimziation::get_cached_box() In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 6/28/19 3:23 PM, Igor Veresov wrote: > This is a forward port of the change to jvmci-8. It fixes a problem with decoding of StackValue on big-endian platforms. > The fix is for JDK13, with intention do be automatically forward ported to JDK14. > > Webrev: http://cr.openjdk.java.net/~iveresov/8226778/webrev.00/ > > Thanks! > igor > > > From igor.veresov at oracle.com Sat Jun 29 04:39:26 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 28 Jun 2019 21:39:26 -0700 Subject: RFR(S): 8226778 [JVMCI] Handle unpacking properly in Deoptimziation::get_cached_box() In-Reply-To: References: Message-ID: Thanks, Vladimir! igor > On Jun 28, 2019, at 8:53 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 6/28/19 3:23 PM, Igor Veresov wrote: >> This is a forward port of the change to jvmci-8. It fixes a problem with decoding of StackValue on big-endian platforms. >> The fix is for JDK13, with intention do be automatically forward ported to JDK14. >> Webrev: http://cr.openjdk.java.net/~iveresov/8226778/webrev.00/ >> Thanks! >> igor