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: <aa8a2c0b-aa43-db8f-07a1-6d7a24cc5ea9@oracle.com>
References: <eb51f2f0-a3ab-815e-e34c-0bdda2aa70c8@loongson.cn>
 <f796d503-eb49-137b-7cdc-e5f7fee7b75e@loongson.cn>
 <282b2c79-1ce0-95bb-c37a-d151edcc02f4@oracle.com>
 <03736619-e07f-e33c-635b-5e8d722d0142@loongson.cn>
 <FD1B893A-709D-462C-8914-AB27F049C841@oracle.com>
 <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn>
 <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com>
 <ea65b061-b324-7407-67b2-52329d665b84@loongson.cn>
 <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com>
 <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn>
 <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com>
 <c64b65b7-b8a4-02e1-8049-1988a9f18ead@loongson.cn>
 <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com>
 <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn>
 <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn>
 <beceebc3-b136-1451-9cf6-276f50556aaf@loongson.cn>
 <dfa7f06e-f668-a8f0-1c7c-1ba68b98943a@oracle.com>
 <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn>
 <aa8a2c0b-aa43-db8f-07a1-6d7a24cc5ea9@oracle.com>
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 <typename L, typename R>
> +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: <e67cac34-6ad5-69ed-cb7c-e1b32d786e36@oracle.com>

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: <e67cac34-6ad5-69ed-cb7c-e1b32d786e36@oracle.com>
References: <18cc95c1-4b46-2eec-bb16-34380aad9394@oracle.com>
 <e67cac34-6ad5-69ed-cb7c-e1b32d786e36@oracle.com>
Message-ID: <f282b9c2-94f2-898e-54cd-1f6938a8e804@oracle.com>

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: <ce4fde63-635d-2c16-c327-bef4b69d2f9e@oracle.com>

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: <fa9d9c9f-26dc-6b5f-be46-f4ae54a83b07@oracle.com>
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>
 <e553c295-b1ca-a681-8678-553c279475e4@oracle.com>
 <20544c1c-12fc-520b-0cdd-30e32b6cda32@redhat.com>
 <7a2fb3a4-a68f-d98c-a39c-02cc9cd48e1a@oracle.com>
 <358ae47a-422f-e243-febe-086820ec6bc9@oracle.com>
 <b1496ee8-92b7-e325-67ba-c856a74dca8d@oracle.com>
 <fa9d9c9f-26dc-6b5f-be46-f4ae54a83b07@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: <OF01067BF1.4D5686C1-ON49258407.002FD8AF-49258407.0031FEED@notes.na.collabserv.com>
 <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com>
 <AM6PR02MB47881842E6D9260F14C171419A1D0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com>
 <OF6889606B.A0521716-ON49258408.001CB507-49258408.001D8311@LocalDomain>
 <OF080791F9.5D04D7FA-ON4925840A.0027062F-4925840A.002768A3@notes.na.collabserv.com>
 <d17ed36c-7e28-778e-8108-76ab494b41f9@redhat.com>
 <OF306A2E19.5BEC9014-ON4925840B.001A0F00-4925840B.001AF226@notes.na.collabserv.com>
 <21b41ea7-f8e8-39ee-aebf-b6f80ab41367@redhat.com>
Message-ID: <OF128F9F9F.978FB55A-ON4925840E.00179126-4925840E.0017A60B@notes.na.collabserv.com>

Hi Andrew,

Thank you for clarification.  I understood.

Regards,
Ogata


Andrew John Hughes <gnu.andrew at redhat.com> wrote on 2019/06/01 01:18:22:

> From: Andrew John Hughes <gnu.andrew at redhat.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> Cc: "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-
> dev at openjdk.java.net>, "jdk8u-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: <OF48C7D8C8.F3BBC2EA-ON49258409.001C98B2-49258409.001CF2EE@LocalDomain>
References: <OFAB7607C5.3D66DF42-ON492583FD.001D0796-492583FD.001E9E82@notes.na.collabserv.com>
 <AM6PR02MB478833E09D322275AE28B56A9A1E0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OFB1A8D0E2.7CFF6D43-ON49258408.0038FF1B-49258408.00394E90@notes.na.collabserv.com>
 <CA+3eh11rcqtWhYXWuPh=XpOC3SDwQW0vbCDF6T=PoyTUvmVEmw@mail.gmail.com>
 <AM6PR02MB4788C68CD85E8A2914C6158C9A1E0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OF48C7D8C8.F3BBC2EA-ON49258409.001C98B2-49258409.001CF2EE@LocalDomain>
Message-ID: <OF96298D1F.172AE8C1-ON4925840E.0017B66C-4925840E.0017DFDD@notes.na.collabserv.com>

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" <hotspot-compiler-
> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" 
<ppc-aix-port-
> dev at openjdk.java.net>, Volker Simonis <volker.simonis at gmail.com>, 
"Doerr, 
> Martin" <martin.doerr at sap.com>
> 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" <martin.doerr at sap.com> wrote on 2019/05/28 23:04:15:
> 
> > From: "Doerr, Martin" <martin.doerr at sap.com>
> > To: Volker Simonis <volker.simonis at gmail.com>, Kazunori Ogata 
<OGATAK at jp.ibm.com>
> > Cc: "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-
> > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" 
<ppc-aix-port-
> > 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 <volker.simonis at gmail.com>
> > > Sent: Dienstag, 28. Mai 2019 15:04
> > > To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > > Cc: Doerr, Martin <martin.doerr at sap.com>; 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 <OGATAK at jp.ibm.com>
> > > wrote:
> > > >
> > > > Hi Martin,
> > > >
> > > > Thank you for your review.
> > > >
> > > > Regards,
> > > > Ogata
> > > >
> > > > "Doerr, Martin" <martin.doerr at sap.com> wrote on 2019/05/28 
18:21:29:
> > > >
> > > > > From: "Doerr, Martin" <martin.doerr at sap.com>
> > > > > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "hotspot-compiler-
> > > > > dev at openjdk.java.net" <hotspot-compiler-dev at openjdk.java.net>,
> > > "ppc-aix-
> > > > > port-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 <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: <f282b9c2-94f2-898e-54cd-1f6938a8e804@oracle.com>
References: <18cc95c1-4b46-2eec-bb16-34380aad9394@oracle.com>
 <e67cac34-6ad5-69ed-cb7c-e1b32d786e36@oracle.com>
 <f282b9c2-94f2-898e-54cd-1f6938a8e804@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: <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.com>
References: <877eailvgp.fsf@redhat.com>
 <70fedac3-59a2-e077-4de0-af6f6604dc16@redhat.com> <87imtwaz43.fsf@redhat.com>
 <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.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: <c5e34308-c2bd-81c8-dd33-363fb7cebad2@oracle.com>
References: <871s0qlu20.fsf@redhat.com>
 <b69c8f77-ab80-530c-fa09-7da30273da90@oracle.com>
 <c5e34308-c2bd-81c8-dd33-363fb7cebad2@oracle.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>
 <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190603/0726b46a/signature.asc>

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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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>
 <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.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>
 <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190603/cdd28ae2/signature-0001.asc>

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: <OF96298D1F.172AE8C1-ON4925840E.0017B66C-4925840E.0017DFDD@notes.na.collabserv.com>
References: <OFAB7607C5.3D66DF42-ON492583FD.001D0796-492583FD.001E9E82@notes.na.collabserv.com>
 <AM6PR02MB478833E09D322275AE28B56A9A1E0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OFB1A8D0E2.7CFF6D43-ON49258408.0038FF1B-49258408.00394E90@notes.na.collabserv.com>
 <CA+3eh11rcqtWhYXWuPh=XpOC3SDwQW0vbCDF6T=PoyTUvmVEmw@mail.gmail.com>
 <AM6PR02MB4788C68CD85E8A2914C6158C9A1E0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OF48C7D8C8.F3BBC2EA-ON49258409.001C98B2-49258409.001CF2EE@LocalDomain>
 <OF96298D1F.172AE8C1-ON4925840E.0017B66C-4925840E.0017DFDD@notes.na.collabserv.com>
Message-ID: <AM6PR02MB478877147A96636A50F0DB409A140@AM6PR02MB4788.eurprd02.prod.outlook.com>

Hi Ogata,

yes, looks good. Thanks for fixing.

Martin


> -----Original Message-----
> From: Kazunori Ogata <OGATAK at jp.ibm.com>
> Sent: Montag, 3. Juni 2019 06:21
> To: Volker Simonis <volker.simonis at gmail.com>; Doerr, Martin
> <martin.doerr at sap.com>
> 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" <hotspot-compiler-
> > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-
> > dev at openjdk.java.net>, Volker Simonis <volker.simonis at gmail.com>,
> "Doerr,
> > Martin" <martin.doerr at sap.com>
> > 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" <martin.doerr at sap.com> wrote on 2019/05/28 23:04:15:
> >
> > > From: "Doerr, Martin" <martin.doerr at sap.com>
> > > To: Volker Simonis <volker.simonis at gmail.com>, Kazunori Ogata
> <OGATAK at jp.ibm.com>
> > > Cc: "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-
> > > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-
> > > 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 <volker.simonis at gmail.com>
> > > > Sent: Dienstag, 28. Mai 2019 15:04
> > > > To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > > > Cc: Doerr, Martin <martin.doerr at sap.com>; 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
> <OGATAK at jp.ibm.com>
> > > > wrote:
> > > > >
> > > > > Hi Martin,
> > > > >
> > > > > Thank you for your review.
> > > > >
> > > > > Regards,
> > > > > Ogata
> > > > >
> > > > > "Doerr, Martin" <martin.doerr at sap.com> wrote on 2019/05/28
> 18:21:29:
> > > > >
> > > > > > From: "Doerr, Martin" <martin.doerr at sap.com>
> > > > > > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "hotspot-compiler-
> > > > > > dev at openjdk.java.net" <hotspot-compiler-
> dev at openjdk.java.net>,
> > > > "ppc-aix-
> > > > > > port-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 <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>
 <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.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>
 <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190603/1293f16a/signature.asc>

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: <AM6PR02MB478877147A96636A50F0DB409A140@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <OFAB7607C5.3D66DF42-ON492583FD.001D0796-492583FD.001E9E82@notes.na.collabserv.com>
 <AM6PR02MB478833E09D322275AE28B56A9A1E0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OFB1A8D0E2.7CFF6D43-ON49258408.0038FF1B-49258408.00394E90@notes.na.collabserv.com>
 <CA+3eh11rcqtWhYXWuPh=XpOC3SDwQW0vbCDF6T=PoyTUvmVEmw@mail.gmail.com>
 <AM6PR02MB4788C68CD85E8A2914C6158C9A1E0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OF48C7D8C8.F3BBC2EA-ON49258409.001C98B2-49258409.001CF2EE@LocalDomain>
 <OF96298D1F.172AE8C1-ON4925840E.0017B66C-4925840E.0017DFDD@notes.na.collabserv.com>
 <AM6PR02MB478877147A96636A50F0DB409A140@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <OF0D2C8795.A84E5B1E-ON4925840E.003867FA-4925840E.00389529@notes.na.collabserv.com>

Hi Martin,

Thank you for your review.


Regards,
Ogata


"Doerr, Martin" <martin.doerr at sap.com> wrote on 2019/06/03 18:10:00:

> From: "Doerr, Martin" <martin.doerr at sap.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, Volker Simonis 
<volker.simonis at gmail.com>
> Cc: "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
> dev at openjdk.java.net>, "hotspot-compiler-dev at openjdk.java.net" <hotspot-
> 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 <OGATAK at jp.ibm.com>
> > Sent: Montag, 3. Juni 2019 06:21
> > To: Volker Simonis <volker.simonis at gmail.com>; Doerr, Martin
> > <martin.doerr at sap.com>
> > 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" <hotspot-compiler-
> > > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> > <ppc-aix-port-
> > > dev at openjdk.java.net>, Volker Simonis <volker.simonis at gmail.com>,
> > "Doerr,
> > > Martin" <martin.doerr at sap.com>
> > > 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" <martin.doerr at sap.com> wrote on 2019/05/28 23:04:15:
> > >
> > > > From: "Doerr, Martin" <martin.doerr at sap.com>
> > > > To: Volker Simonis <volker.simonis at gmail.com>, Kazunori Ogata
> > <OGATAK at jp.ibm.com>
> > > > Cc: "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-
> > > > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> > <ppc-aix-port-
> > > > 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 <volker.simonis at gmail.com>
> > > > > Sent: Dienstag, 28. Mai 2019 15:04
> > > > > To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > > > > Cc: Doerr, Martin <martin.doerr at sap.com>; 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
> > <OGATAK at jp.ibm.com>
> > > > > wrote:
> > > > > >
> > > > > > Hi Martin,
> > > > > >
> > > > > > Thank you for your review.
> > > > > >
> > > > > > Regards,
> > > > > > Ogata
> > > > > >
> > > > > > "Doerr, Martin" <martin.doerr at sap.com> wrote on 2019/05/28
> > 18:21:29:
> > > > > >
> > > > > > > From: "Doerr, Martin" <martin.doerr at sap.com>
> > > > > > > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "hotspot-compiler-
> > > > > > > dev at openjdk.java.net" <hotspot-compiler-
> > dev at openjdk.java.net>,
> > > > > "ppc-aix-
> > > > > > > port-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 <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: <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.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: <eb51f2f0-a3ab-815e-e34c-0bdda2aa70c8@loongson.cn>
 <282b2c79-1ce0-95bb-c37a-d151edcc02f4@oracle.com>
 <03736619-e07f-e33c-635b-5e8d722d0142@loongson.cn>
 <FD1B893A-709D-462C-8914-AB27F049C841@oracle.com>
 <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn>
 <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com>
 <ea65b061-b324-7407-67b2-52329d665b84@loongson.cn>
 <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com>
 <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn>
 <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com>
 <c64b65b7-b8a4-02e1-8049-1988a9f18ead@loongson.cn>
 <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com>
 <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn>
 <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn>
 <beceebc3-b136-1451-9cf6-276f50556aaf@loongson.cn>
 <dfa7f06e-f668-a8f0-1c7c-1ba68b98943a@oracle.com>
 <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn>
 <aa8a2c0b-aa43-db8f-07a1-6d7a24cc5ea9@oracle.com>
 <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 <typename L, typename R>
>> +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: <AM6PR02MB4788A72D604B0BDA22C375D19A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788A72D604B0BDA22C375D19A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
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: <AM6PR02MB4788D4D7C4255E80D3B7C3CC9A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788D4D7C4255E80D3B7C3CC9A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
Message-ID: <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>



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: <AM6PR02MB4788BDD025B74D28BAC1D0AA9A140@AM6PR02MB4788.eurprd02.prod.outlook.com>

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 <vladimir.x.ivanov at oracle.com>
> Sent: Freitag, 31. Mai 2019 22:15
> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> Cc: Doerr, Martin <martin.doerr at sap.com>
> 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/ <http://cr.openjdk.java.net/~iveresov/8225202/webrev.00/>

Thanks!
igor



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190603/d1b8ef74/attachment.html>

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: <OF080791F9.5D04D7FA-ON4925840A.0027062F-4925840A.002768A3@notes.na.collabserv.com>
References: <OF01067BF1.4D5686C1-ON49258407.002FD8AF-49258407.0031FEED@notes.na.collabserv.com>
 <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com>
 <AM6PR02MB47881842E6D9260F14C171419A1D0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com>
 <OF6889606B.A0521716-ON49258408.001CB507-49258408.001D8311@LocalDomain>
 <OF080791F9.5D04D7FA-ON4925840A.0027062F-4925840A.002768A3@notes.na.collabserv.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: <CAG22-wv7HHYrE8avy__VY-PfhTX+n1rA+sMyFXPE_P_cCB6veQ@mail.gmail.com>
References: <CAG22-wv7HHYrE8avy__VY-PfhTX+n1rA+sMyFXPE_P_cCB6veQ@mail.gmail.com>
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: <AM6PR02MB50783919356CA882AD3B7D6693010@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB50783919356CA882AD3B7D6693010@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <fdf79470-0507-f8d0-60d8-184618ba12b6@oracle.com>

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: <OF01067BF1.4D5686C1-ON49258407.002FD8AF-49258407.0031FEED@notes.na.collabserv.com>
 <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com>
 <AM6PR02MB47881842E6D9260F14C171419A1D0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com>
 <OF6889606B.A0521716-ON49258408.001CB507-49258408.001D8311@LocalDomain>
 <OF080791F9.5D04D7FA-ON4925840A.0027062F-4925840A.002768A3@notes.na.collabserv.com>
 <8a2de9b7-adfa-786e-1088-fe06f7eb781d@linux.vnet.ibm.com>
Message-ID: <OF291F85C1.8E8EC1EC-ON4925840F.00178159-4925840F.0017A1E3@notes.na.collabserv.com>

Hi Gustavo,

Thank you for sponsoring it!

Regards,
Ogata

"Gustavo Romero" <gromero at linux.vnet.ibm.com> wrote on 2019/06/04 
06:35:23:

> From: "Gustavo Romero" <gromero at linux.vnet.ibm.com>
> To: Kazunori Ogata/Japan/IBM at IBMJP
> Cc: "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-
> dev at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" <jdk8u-
> dev at openjdk.java.net>, "Doerr, Martin" <martin.doerr at sap.com>, "Andrew 
> Hughes" <gnu.andrew at redhat.com>
> 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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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: <AM6PR02MB4788BDD025B74D28BAC1D0AA9A140@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com>
 <AM6PR02MB4788BDD025B74D28BAC1D0AA9A140@AM6PR02MB4788.eurprd02.prod.outlook.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 <vladimir.x.ivanov at oracle.com>
>> Sent: Freitag, 31. Mai 2019 22:15
>> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>> Cc: Doerr, Martin <martin.doerr at sap.com>
>> 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>
 <AM6PR02MB4788BDD025B74D28BAC1D0AA9A140@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com>
Message-ID: <AM6PR02MB4788F34FB813C90FA2D738559A150@AM6PR02MB4788.eurprd02.prod.outlook.com>

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: <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@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>
 <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.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: <CAG22-wv7HHYrE8avy__VY-PfhTX+n1rA+sMyFXPE_P_cCB6veQ@mail.gmail.com>
 <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com>
Message-ID: <CAG22-wuFqwiOMtHmcqUQAYu6gPZJkWeQ=4+1ypCNGusazRTGfQ@mail.gmail.com>

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 <dean.long at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190603/f0ddb2e1/attachment.html>

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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/d8435232/attachment.html>

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: <eb51f2f0-a3ab-815e-e34c-0bdda2aa70c8@loongson.cn>
 <03736619-e07f-e33c-635b-5e8d722d0142@loongson.cn>
 <FD1B893A-709D-462C-8914-AB27F049C841@oracle.com>
 <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn>
 <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com>
 <ea65b061-b324-7407-67b2-52329d665b84@loongson.cn>
 <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com>
 <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn>
 <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com>
 <c64b65b7-b8a4-02e1-8049-1988a9f18ead@loongson.cn>
 <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com>
 <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn>
 <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn>
 <beceebc3-b136-1451-9cf6-276f50556aaf@loongson.cn>
 <dfa7f06e-f668-a8f0-1c7c-1ba68b98943a@oracle.com>
 <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn>
 <aa8a2c0b-aa43-db8f-07a1-6d7a24cc5ea9@oracle.com>
 <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<int&>. 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 <typename L, typename R>
>>> +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>
 <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.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 <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 <https://bugs.openjdk.java.net/browse/JDK-8225305>
webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/>

Cheers,
Mikael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/38c62d78/attachment.html>

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 <https://bugs.openjdk.java.net/browse/JDK-8224234> is fixed they should be problem listed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8225307 <https://bugs.openjdk.java.net/browse/JDK-8225307>
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225307/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8225307/webrev.00/open/webrev/>

Cheers,
Mikael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/5773e52c/attachment.html>

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 <mikael.vidstedt at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/d89ff017/attachment.html>

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 <mikael.vidstedt at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/c26b4c29/attachment-0001.html>

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 <mikael.vidstedt at oracle.com> wrote:
> 
> 
> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 <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 <https://bugs.openjdk.java.net/browse/JDK-8225305>
> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/>
> 
> Cheers,
> Mikael
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/681e4fe8/attachment.html>

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: <ec878655-53a0-e264-b1fa-cc751be59500@oracle.com>

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 <mikael.vidstedt at oracle.com> wrote:
>>
>>
>> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 <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 <https://bugs.openjdk.java.net/browse/JDK-8225305>
>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/>
>>
>> Cheers,
>> Mikael
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/8374b114/attachment.html>

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: <F303F13F-1539-433B-9990-27F2CF3DF286@oracle.com>


Thanks Vladimir! Change pushed.

Cheers,
Mikael

> On Jun 4, 2019, at 1:58 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Good.
> 
> Thanks
> Vladimir
> 
> On Jun 4, 2019, at 1:52 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com <mailto:mikael.vidstedt at oracle.com>> wrote:
> 
>> 
>> The two tests (in subject) are failing frequently. Until https://bugs.openjdk.java.net/browse/JDK-8224234 <https://bugs.openjdk.java.net/browse/JDK-8224234> is fixed they should be problem listed.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225307 <https://bugs.openjdk.java.net/browse/JDK-8225307>
>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225307/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8225307/webrev.00/open/webrev/>
>> 
>> Cheers,
>> Mikael
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/134af0e3/attachment.html>

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: <ec878655-53a0-e264-b1fa-cc751be59500@oracle.com>
References: <5E0AA771-DAD0-4A75-AD95-8FAF507F3172@oracle.com>
 <3C94D555-5251-492D-8FC9-B5740A515B53@oracle.com>
 <ec878655-53a0-e264-b1fa-cc751be59500@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/ <http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.01/open/webrev/>

Cheers,
Mikael

> On Jun 4, 2019, at 3:18 PM, Mandy Chung <mandy.chung at oracle.com> 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 <mikael.vidstedt at oracle.com> <mailto:mikael.vidstedt at oracle.com> wrote:
>>> 
>>> 
>>> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 <https://bugs.openjdk.java.net/browse/JDK-8222445> <https://bugs.openjdk.java.net/browse/JDK-8222445> <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 <https://bugs.openjdk.java.net/browse/JDK-8225305> <https://bugs.openjdk.java.net/browse/JDK-8225305> <https://bugs.openjdk.java.net/browse/JDK-8225305>
>>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/> <http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/> <http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/>
>>> 
>>> Cheers,
>>> Mikael
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/9b7e30e7/attachment-0001.html>

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>
 <ec878655-53a0-e264-b1fa-cc751be59500@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 <mikael.vidstedt at oracle.com> 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 <mandy.chung at oracle.com> 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 <mikael.vidstedt at oracle.com> wrote:
>>>> 
>>>> 
>>>> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 <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 <https://bugs.openjdk.java.net/browse/JDK-8225305>
>>>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/>
>>>> 
>>>> Cheers,
>>>> Mikael
>>>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/307c7945/attachment.html>

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>
 <ec878655-53a0-e264-b1fa-cc751be59500@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 <mandy.chung at oracle.com 
>> <mailto:mandy.chung at oracle.com>> 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<mikael.vidstedt at oracle.com>  wrote:
>>>>
>>>>
>>>> The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Untilhttps://bugs.openjdk.java.net/browse/JDK-8222445  <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  <https://bugs.openjdk.java.net/browse/JDK-8225305>
>>>> webrev:http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/  <http://cr.openjdk.java.net/~mikael/webrevs/8225305/webrev.00/open/webrev/>
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190604/e3f8137a/attachment.html>

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: <eb51f2f0-a3ab-815e-e34c-0bdda2aa70c8@loongson.cn>
 <FD1B893A-709D-462C-8914-AB27F049C841@oracle.com>
 <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn>
 <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com>
 <ea65b061-b324-7407-67b2-52329d665b84@loongson.cn>
 <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com>
 <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn>
 <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com>
 <c64b65b7-b8a4-02e1-8049-1988a9f18ead@loongson.cn>
 <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com>
 <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn>
 <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn>
 <beceebc3-b136-1451-9cf6-276f50556aaf@loongson.cn>
 <dfa7f06e-f668-a8f0-1c7c-1ba68b98943a@oracle.com>
 <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn>
 <aa8a2c0b-aa43-db8f-07a1-6d7a24cc5ea9@oracle.com>
 <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<int&>. 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<int&> 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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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>
 <d4f9cc5b-d312-9190-d2ef-4e7caf9ac8e8@oracle.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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@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: <VI1PR02MB3712D57F960E9FA6C883855BE92C0@VI1PR02MB3712.eurprd02.prod.outlook.com>
 <D74CB096-6134-42A9-98B4-7AF119F94463@oracle.com>
 <VI1PR02MB371266466D32221555D74369E92D0@VI1PR02MB3712.eurprd02.prod.outlook.com>
 <e6907936-c1ab-6ec1-71a4-a0eb8b23819b@oracle.com>
 <9F82E0AB-45DB-45F4-B453-691F4A1AB244@oracle.com>
 <AM6PR02MB3655E6557D8B80AC7145872BE9190@AM6PR02MB3655.eurprd02.prod.outlook.com>
 <21920A56-9559-4CB3-A084-5F9F3EF92BCA@oracle.com>
Message-ID: <DB7PR02MB4790B9B3449E1000640828A09A160@DB7PR02MB4790.eurprd02.prod.outlook.com>

Hi Peter,

reviewed and pushed.

Best regards,
Martin


From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net> On Behalf Of Igor Ignatyev
Sent: Freitag, 31. Mai 2019 19:09
To: Januschke, Peter <peter.januschke at sap.com>
Cc: hotspot-compiler-dev at openjdk.java.net compiler <hotspot-compiler-dev at openjdk.java.net>
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 <peter.januschke at sap.com<mailto:peter.januschke at sap.com>> 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 <igor.ignatyev at oracle.com<mailto:igor.ignatyev at oracle.com>>
Sent: Dienstag, 9. April 2019 18:30
To: Nils Eliasson <nils.eliasson at oracle.com<mailto:nils.eliasson at oracle.com>>; Januschke, Peter <peter.januschke at sap.com<mailto:peter.januschke at sap.com>>
Cc: hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net> compiler <hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>>
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 <nils.eliasson at oracle.com<mailto:nils.eliasson at oracle.com>> 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 <igor.ignatyev at oracle.com><mailto:igor.ignatyev at oracle.com>
Sent: Montag, 8. April 2019 19:25
To: Januschke, Peter <peter.januschke at sap.com><mailto:peter.januschke at sap.com>
Cc: hotspot-compiler-dev at openjdk.java.net<mailto: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 <peter.januschke at sap.com<mailto:peter.januschke at sap.com>> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190605/f240cdac/attachment-0001.html>

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>
 <ec878655-53a0-e264-b1fa-cc751be59500@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/ <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: <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
Message-ID: <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>

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 <adinn at redhat.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190605/b2d196e8/attachment.html>

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: <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.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 <brian.burkhalter at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190605/9ff4e720/attachment.html>

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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@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>
 <ec878655-53a0-e264-b1fa-cc751be59500@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 <alan.bateman at oracle.com> 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/ <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: <eb51f2f0-a3ab-815e-e34c-0bdda2aa70c8@loongson.cn>
 <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn>
 <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com>
 <ea65b061-b324-7407-67b2-52329d665b84@loongson.cn>
 <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com>
 <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn>
 <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com>
 <c64b65b7-b8a4-02e1-8049-1988a9f18ead@loongson.cn>
 <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com>
 <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn>
 <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn>
 <beceebc3-b136-1451-9cf6-276f50556aaf@loongson.cn>
 <dfa7f06e-f668-a8f0-1c7c-1ba68b98943a@oracle.com>
 <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn>
 <aa8a2c0b-aa43-db8f-07a1-6d7a24cc5ea9@oracle.com>
 <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<int&>. 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<int&> 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: <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
Message-ID: <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>

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: <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
Message-ID: <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.com>

Hi Andrew,

> On Jun 5, 2019, at 10:10 AM, Andrew Dinn <adinn at redhat.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190605/d8367e4c/attachment-0001.html>

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: <eb51f2f0-a3ab-815e-e34c-0bdda2aa70c8@loongson.cn>
 <259a914e-1c9c-c884-6114-6f855a96afb6@loongson.cn>
 <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com>
 <ea65b061-b324-7407-67b2-52329d665b84@loongson.cn>
 <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com>
 <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn>
 <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com>
 <c64b65b7-b8a4-02e1-8049-1988a9f18ead@loongson.cn>
 <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com>
 <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn>
 <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn>
 <beceebc3-b136-1451-9cf6-276f50556aaf@loongson.cn>
 <dfa7f06e-f668-a8f0-1c7c-1ba68b98943a@oracle.com>
 <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn>
 <aa8a2c0b-aa43-db8f-07a1-6d7a24cc5ea9@oracle.com>
 <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: <ee2c1abc-a359-13f7-1f40-5ccb41304f22@oracle.com>


> 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: <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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 <brian.burkhalter at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190605/15f92397/attachment.html>

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: <OF145E34DC.BB688A46-ON0025840B.0054EC73-8025840B.00589184@notes.na.collabserv.com>
References: <OF5A103C8F.49119082-ON00258409.00336268-80258409.003591DC@notes.na.collabserv.com>
 <68b970be-e551-577d-0ca1-28c16880a2ff@oracle.com>
 <OF61020F18.EE36B8A7-ON00258409.004F6B79-80258409.0051D5E9@notes.na.collabserv.com>
 <dfdc2eeb-2d29-5ce4-1ec8-42f6dff3c613@oracle.com>
 <OF145E34DC.BB688A46-ON0025840B.0054EC73-8025840B.00589184@notes.na.collabserv.com>
Message-ID: <edf0de93-5f6f-1959-7244-ab4258b71cad@oracle.com>

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 <num of chars in buffer, per encoding>"
> 
> 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 <vladimir.x.ivanov at oracle.com> wrote on 29/05/2019 17:19:36:
> 
>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>> To: Adam Farley8 <adam.farley at uk.ibm.com>
>> 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 <vladimir.x.ivanov at oracle.com> wrote on  29/05/201913:22:27:
>> > 
>> >> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>> >> To: Adam Farley8 <adam.farley at uk.ibm.com>, ?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>
 <e67cac34-6ad5-69ed-cb7c-e1b32d786e36@oracle.com>
 <f282b9c2-94f2-898e-54cd-1f6938a8e804@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/ <https://openjdk.java.net/projects/code-tools/jcheck/>
[2] <OpenJDK>/make/scripts/normalizer.pl

> On Jun 5, 2019, at 11:13 AM, Gustavo Romero <gromero at linux.vnet.ibm.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190605/3ca9b570/attachment.html>

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: <AM6PR02MB4788F34FB813C90FA2D738559A150@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com>
 <AM6PR02MB4788BDD025B74D28BAC1D0AA9A140@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com>
 <AM6PR02MB4788F34FB813C90FA2D738559A150@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <e7e736d0-6578-ae38-1abd-3279ba212a6d@oracle.com>

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: <e7e736d0-6578-ae38-1abd-3279ba212a6d@oracle.com>
References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com>
 <AM6PR02MB4788BDD025B74D28BAC1D0AA9A140@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com>
 <AM6PR02MB4788F34FB813C90FA2D738559A150@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <e7e736d0-6578-ae38-1abd-3279ba212a6d@oracle.com>
Message-ID: <fceea298-2584-4839-0053-ccdb88245bbb@oracle.com>

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: <dc8be281-398c-56d9-2df9-5cad13d406ac@oracle.com>
References: <dc8be281-398c-56d9-2df9-5cad13d406ac@oracle.com>
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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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.<clinit>(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 <brian.burkhalter at oracle.com> 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 <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190605/43e042e9/attachment.html>

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: <ee2c1abc-a359-13f7-1f40-5ccb41304f22@oracle.com>
References: <eb51f2f0-a3ab-815e-e34c-0bdda2aa70c8@loongson.cn>
 <1060f01d-dcfa-3a04-284d-1c6a95c791fc@oracle.com>
 <ea65b061-b324-7407-67b2-52329d665b84@loongson.cn>
 <4c2da2fb-7550-d51b-539a-4656fc67bb00@oracle.com>
 <38b00331-34f7-b4a8-f033-f1489a154806@loongson.cn>
 <0669b1e3-5258-7765-aac8-8d3e5c47066c@oracle.com>
 <c64b65b7-b8a4-02e1-8049-1988a9f18ead@loongson.cn>
 <8e25f068-609a-de80-a020-fbc0ede4b96a@oracle.com>
 <063fa1f0-864c-b049-1ece-534322505bf7@loongson.cn>
 <828dfe7a-bbfd-3782-62e9-ae4ac4490cb7@loongson.cn>
 <beceebc3-b136-1451-9cf6-276f50556aaf@loongson.cn>
 <dfa7f06e-f668-a8f0-1c7c-1ba68b98943a@oracle.com>
 <289bd842-4f56-f5ec-70ff-bf31a1c56f19@loongson.cn>
 <aa8a2c0b-aa43-db8f-07a1-6d7a24cc5ea9@oracle.com>
 <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>
 <ee2c1abc-a359-13f7-1f40-5ccb41304f22@oracle.com>
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: <OFCF50AB8E.620EEDF8-ON49258411.0029F9B0-49258411.002B74BF@notes.na.collabserv.com>

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: <OFCF50AB8E.620EEDF8-ON49258411.0029F9B0-49258411.002B74BF@notes.na.collabserv.com>
References: <OFCF50AB8E.620EEDF8-ON49258411.0029F9B0-49258411.002B74BF@notes.na.collabserv.com>
Message-ID: <AM6PR02MB47885FAE8BE2A6EA8AB4D03F9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>

Hi Ogata,

looks correct.

Best regards,
Martin


> -----Original Message-----
> From: hotspot-compiler-dev <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: <AM6PR02MB47885FAE8BE2A6EA8AB4D03F9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <OFCF50AB8E.620EEDF8-ON49258411.0029F9B0-49258411.002B74BF@notes.na.collabserv.com>
 <AM6PR02MB47885FAE8BE2A6EA8AB4D03F9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <OF6B75518B.43F9C814-ON49258411.003003AD-49258411.00302747@notes.na.collabserv.com>

Hi Martin,

Thank you for your review.

Regards,
Ogata

"Doerr, Martin" <martin.doerr at sap.com> wrote on 2019/06/06 17:29:07:

> From: "Doerr, Martin" <martin.doerr at sap.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, "hotspot-compiler-
> dev at openjdk.java.net" <hotspot-compiler-dev at openjdk.java.net>, "jdk8u-
> 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 <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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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.<clinit>(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: <f10faa62-8b49-cbeb-c7d0-a7112488d803@redhat.com>

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: <AM6PR02MB4788BC849EBACC9FC634E6409A170@AM6PR02MB4788.eurprd02.prod.outlook.com>

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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190606/794b38b2/attachment.html>

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: <f10faa62-8b49-cbeb-c7d0-a7112488d803@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>
 <f10faa62-8b49-cbeb-c7d0-a7112488d803@redhat.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://www.redhat.com>
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>
 <f10faa62-8b49-cbeb-c7d0-a7112488d803@redhat.com>
 <5c3af4bf-32f8-2f73-2263-b3aa77e84c66@redhat.com>
Message-ID: <e812058f-154a-84c5-0a82-d3d7ab0c3d82@redhat.com>

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: <fceea298-2584-4839-0053-ccdb88245bbb@oracle.com>
References: <28899e8f-daa5-2d90-c139-dcb833c9a93f@oracle.com>
 <AM6PR02MB4788BDD025B74D28BAC1D0AA9A140@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <2f886e1a-4df4-c34c-4582-dce10ab6c9f2@oracle.com>
 <AM6PR02MB4788F34FB813C90FA2D738559A150@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <e7e736d0-6578-ae38-1abd-3279ba212a6d@oracle.com>
 <fceea298-2584-4839-0053-ccdb88245bbb@oracle.com>
Message-ID: <f41097a6-b1ac-6a97-8d57-45dedc739a0d@oracle.com>

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: <AM6PR02MB4788D4D7C4255E80D3B7C3CC9A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788D4D7C4255E80D3B7C3CC9A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4788F097297D02512F57F4C99A170@AM6PR02MB4788.eurprd02.prod.outlook.com>

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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190606/66326e13/attachment.html>

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: <AM6PR02MB4788A72D604B0BDA22C375D19A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788A72D604B0BDA22C375D19A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4788B384F474771874641C9A9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>

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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190606/298f53d0/attachment-0001.html>

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: <AM6PR02MB4788F097297D02512F57F4C99A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788D4D7C4255E80D3B7C3CC9A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <AM6PR02MB4788F097297D02512F57F4C99A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
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: <AM6PR02MB4788B384F474771874641C9A9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788A72D604B0BDA22C375D19A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <AM6PR02MB4788B384F474771874641C9A9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <a1e74fdc-0bd8-508e-c9f2-adb7f92093bc@oracle.com>

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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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 <adinn at redhat.com> 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/ <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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190606/f5352623/attachment-0001.html>

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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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.<clinit>(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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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 <vladimir.kozlov at oracle.com> 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 <igor.ignatyev at oracle.com> 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 <vladimir.kozlov at oracle.com> 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: <F39C6FC1-671E-45EF-9A74-D31BCCB90B34@oracle.com>

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: <F39C6FC1-671E-45EF-9A74-D31BCCB90B34@oracle.com>
References: <F39C6FC1-671E-45EF-9A74-D31BCCB90B34@oracle.com>
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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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 <brian.burkhalter at oracle.com> wrote:
> 
>> So, here is webrev.06 as the latest official patch:
>> 
>>  http://cr.openjdk.java.net/~adinn/8224974/webrev.06/ <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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190606/feba8fcc/attachment.html>

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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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: <e1920ede-4cf0-c3fb-a10e-01f2fe26491e@oracle.com>

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: <a066cf1f-300b-0e8c-73c7-191bbafbec1e@oracle.com>

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: <F39C6FC1-671E-45EF-9A74-D31BCCB90B34@oracle.com>
 <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 <vladimir.kozlov at oracle.com> 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: <a066cf1f-300b-0e8c-73c7-191bbafbec1e@oracle.com>
References: <a066cf1f-300b-0e8c-73c7-191bbafbec1e@oracle.com>
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 <vladimir.kozlov at oracle.com> 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: <C55BF0BB-A6F9-4D8A-BF47-0E04D1BAF9FA@oracle.com>

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: <C55BF0BB-A6F9-4D8A-BF47-0E04D1BAF9FA@oracle.com>
References: <C55BF0BB-A6F9-4D8A-BF47-0E04D1BAF9FA@oracle.com>
Message-ID: <35CF8810-C61E-40CC-AFA6-20AC385B74D6@oracle.com>

Good.

Thanks
Vladimir

> On Jun 6, 2019, at 2:17 PM, Igor Ignatyev <igor.ignatyev at oracle.com> 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: <a066cf1f-300b-0e8c-73c7-191bbafbec1e@oracle.com>
 <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 <vladimir.kozlov at oracle.com> 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: <a066cf1f-300b-0e8c-73c7-191bbafbec1e@oracle.com>
 <25D855F1-0C28-4AEE-AF01-F2602CBA5595@oracle.com>
 <81bbc142-be1a-2cc7-1029-490bde8edfcf@oracle.com>
Message-ID: <F5245BF4-4834-4FD4-B21F-187BDAB7D969@oracle.com>


> On Jun 6, 2019, at 3:01 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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 <vladimir.kozlov at oracle.com> 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: <F5245BF4-4834-4FD4-B21F-187BDAB7D969@oracle.com>
References: <a066cf1f-300b-0e8c-73c7-191bbafbec1e@oracle.com>
 <25D855F1-0C28-4AEE-AF01-F2602CBA5595@oracle.com>
 <81bbc142-be1a-2cc7-1029-490bde8edfcf@oracle.com>
 <F5245BF4-4834-4FD4-B21F-187BDAB7D969@oracle.com>
Message-ID: <d87a4a31-be91-ce47-5f5a-e729ee5eef22@oracle.com>

Thanks,
Vladimir

On 6/6/19 3:04 PM, Igor Ignatyev wrote:
> 
>> On Jun 6, 2019, at 3:01 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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 <vladimir.kozlov at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/15ec4ad9/attachment.html>

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: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>

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

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: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
References: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
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 <init>.
> 
> 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: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
 <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 <init>.
>>
>> 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: <FA21FCAB-C984-4A46-805E-AFADE82CEF09@oracle.com>

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: <FA21FCAB-C984-4A46-805E-AFADE82CEF09@oracle.com>
References: <FA21FCAB-C984-4A46-805E-AFADE82CEF09@oracle.com>
Message-ID: <c09fab11-4cea-9073-9d2a-e38428d54302@oracle.com>

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: <c09fab11-4cea-9073-9d2a-e38428d54302@oracle.com>
References: <FA21FCAB-C984-4A46-805E-AFADE82CEF09@oracle.com>
 <c09fab11-4cea-9073-9d2a-e38428d54302@oracle.com>
Message-ID: <18CB1865-4A28-4078-8604-BF4858A0B0EC@oracle.com>

Thanks Vladimir! pushed.

-- Igor
> On Jun 6, 2019, at 11:05 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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: <C55BF0BB-A6F9-4D8A-BF47-0E04D1BAF9FA@oracle.com>
 <35CF8810-C61E-40CC-AFA6-20AC385B74D6@oracle.com>
Message-ID: <aa1e12d5-8c63-7068-c002-b2784aa260ef@oracle.com>

+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 <igor.ignatyev at oracle.com> 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: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
 <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com>
Message-ID: <ABD67EC6-95BC-4004-97CC-5FF80A80C9CB@oracle.com>

Change looks good to me.

-Doug

> On 7 Jun 2019, at 04:41, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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 <init>.
>> 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: <d206cc45-529d-1537-f83b-e4dafe24be39@oracle.com>

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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/3cd5b1dd/attachment.html>

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: <CAG22-wv7HHYrE8avy__VY-PfhTX+n1rA+sMyFXPE_P_cCB6veQ@mail.gmail.com>
 <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: <abb07b84-5e48-ab9d-cf78-700c6450c4f7@oracle.com>

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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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: <e1920ede-4cf0-c3fb-a10e-01f2fe26491e@oracle.com>
References: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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>
 <e1920ede-4cf0-c3fb-a10e-01f2fe26491e@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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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>
 <e1920ede-4cf0-c3fb-a10e-01f2fe26491e@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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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>
 <e1920ede-4cf0-c3fb-a10e-01f2fe26491e@oracle.com>
 <6a8f92d8-14b2-c90b-f7d6-e8bbb23db76f@oracle.com>
 <8b795acf-4d12-f27f-1a54-0073f5552dfd@oracle.com>
Message-ID: <DE28C5D3-A78A-47AA-8763-CBF7A9C99F12@oracle.com>

Looks good.

/Erik

> On 7 Jun 2019, at 14:53, Nils Eliasson <nils.eliasson at oracle.com> 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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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>
 <e1920ede-4cf0-c3fb-a10e-01f2fe26491e@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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/eec0a708/attachment-0001.html>

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: <ab2e9d7f-35ad-2fbe-0def-730a2e1b3041@oracle.com>
 <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>
 <e1920ede-4cf0-c3fb-a10e-01f2fe26491e@oracle.com>
 <6a8f92d8-14b2-c90b-f7d6-e8bbb23db76f@oracle.com>
 <8b795acf-4d12-f27f-1a54-0073f5552dfd@oracle.com> <87pnnpea1v.fsf@redhat.com>
Message-ID: <e896945f-2dbc-233c-cb94-3a2964389110@oracle.com>


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://www.redhat.com>
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: <bb4386fa-ac0c-3b31-36f6-10383682035e@bell-sw.com>


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<jlong> is used to parse any numeric values in dcmd framework including positive integer values for port, ttl etc.

Adding new type DCmdArgument<size_t> requires adding more specialized methods like
template <> void DCmdArgument<jlong>::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 <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<jlong> _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/ <http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/> 
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 <https://bugs.openjdk.java.net/browse/JDK-8225388> 
>> 
>> Leonid 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/8a4bb596/attachment.html>

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: <bb4386fa-ac0c-3b31-36f6-10383682035e@bell-sw.com>
References: <84ed5d8d-99aa-0eae-6094-cddcea052545@bell-sw.com>
 <56d760a2-4719-d00e-bc27-d507c2aa86b2@redhat.com>
 <bb4386fa-ac0c-3b31-36f6-10383682035e@bell-sw.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://www.redhat.com>
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>
 <bb4386fa-ac0c-3b31-36f6-10383682035e@bell-sw.com>
 <0ceedc01-330c-0951-b49a-f180bb7c1f16@redhat.com>
Message-ID: <daad51ef-b554-9afc-f4d5-0114f42fe018@bell-sw.com>


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>
 <bb4386fa-ac0c-3b31-36f6-10383682035e@bell-sw.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://www.redhat.com>
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: <CAG22-wvPiPw28Bm4dU+_buYw-MydHt9vM2_xg3mXKF6efHc+OQ@mail.gmail.com>
References: <CAG22-wv7HHYrE8avy__VY-PfhTX+n1rA+sMyFXPE_P_cCB6veQ@mail.gmail.com>
 <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com>
 <726994dd-fd15-cadb-7a1c-9daac1780050@oracle.com>
 <CAG22-wvPiPw28Bm4dU+_buYw-MydHt9vM2_xg3mXKF6efHc+OQ@mail.gmail.com>
Message-ID: <CAG22-wvu7_-6QZNvTuLP7ksoekdEktMK8cYi74OccfZi9ha9UA@mail.gmail.com>

On Fri, Jun 7, 2019 at 9:20 AM keita abdoul-kader <abdoulk.keita at gmail.com>
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 <tobias.hartmann at oracle.com>
> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/ca29d856/attachment.html>

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>
 <bb4386fa-ac0c-3b31-36f6-10383682035e@bell-sw.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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/83669280/attachment-0001.html>

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>
 <bb4386fa-ac0c-3b31-36f6-10383682035e@bell-sw.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://www.redhat.com>
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: <AA6B1F44-3FAD-4F24-8F53-E774F5BE40C3@oracle.com>

I read documentation about CRS on following wiki https://wiki.openjdk.java.net/display/csr <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<jlong> is used to parse any numeric values in dcmd framework including positive integer values for port, ttl etc.
>> 
>> Adding new type DCmdArgument<size_t> requires adding more specialized methods like
>> template <> void DCmdArgument<jlong>::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 <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 <mailto: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<jlong> _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/ <http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/> 
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 <https://bugs.openjdk.java.net/browse/JDK-8225388> 
>>>> 
>>>> Leonid 
>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/b3b5f117/attachment.html>

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: <AA6B1F44-3FAD-4F24-8F53-E774F5BE40C3@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>
 <AA6B1F44-3FAD-4F24-8F53-E774F5BE40C3@oracle.com>
Message-ID: <b7b3dc27-7d9c-5940-7238-2738d76ae690@oracle.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/783dcb32/attachment-0001.html>

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: <abb07b84-5e48-ab9d-cf78-700c6450c4f7@oracle.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com>
 <abb07b84-5e48-ab9d-cf78-700c6450c4f7@oracle.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 <sandhya.viswanathan at intel.com>; 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: <f477e11b-2eab-abc5-eabe-053bb24abfef@oracle.com>

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 <igor.ignatyev at oracle.com> 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 <vladimir.kozlov at oracle.com> 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: <f477e11b-2eab-abc5-eabe-053bb24abfef@oracle.com>
References: <9e3eb6b1-4fec-3fe8-7ea8-d0eec56e11d7@oracle.com>
 <73669281-F06A-46AE-BFEB-E9BC307F62CD@oracle.com>
 <70CC384E-4A80-4D63-8459-EE8CACBA195B@oracle.com>
 <f477e11b-2eab-abc5-eabe-053bb24abfef@oracle.com>
Message-ID: <1FF5A78F-D09C-4ECB-B638-E800AD523AB8@oracle.com>

LGTM

-- Igor

> On Jun 7, 2019, at 12:35 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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 <igor.ignatyev at oracle.com> 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 <vladimir.kozlov at oracle.com> 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>
 <f477e11b-2eab-abc5-eabe-053bb24abfef@oracle.com>
 <1FF5A78F-D09C-4ECB-B638-E800AD523AB8@oracle.com>
Message-ID: <dda8b412-2c1b-2da2-f8da-9f3fc86ff9aa@oracle.com>

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 <vladimir.kozlov at oracle.com> 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 <igor.ignatyev at oracle.com> 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 <vladimir.kozlov at oracle.com> 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 <tobias.hartmann at oracle.com> 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: <b7b3dc27-7d9c-5940-7238-2738d76ae690@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>
 <AA6B1F44-3FAD-4F24-8F53-E774F5BE40C3@oracle.com>
 <b7b3dc27-7d9c-5940-7238-2738d76ae690@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 <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 <mailto: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<jlong> is used to parse any numeric values in dcmd framework including positive integer values for port, ttl etc.
>>>> 
>>>> Adding new type DCmdArgument<size_t> requires adding more specialized methods like
>>>> template <> void DCmdArgument<jlong>::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 <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 <mailto: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<jlong> _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/ <http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/> 
>>>>>> 
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 <https://bugs.openjdk.java.net/browse/JDK-8225388> 
>>>>>> 
>>>>>> Leonid 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/f8c55893/attachment.html>

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: <ABD67EC6-95BC-4004-97CC-5FF80A80C9CB@oracle.com>
References: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
 <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com>
 <ABD67EC6-95BC-4004-97CC-5FF80A80C9CB@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 <vladimir.kozlov at oracle.com> 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 <init>.
>>> 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>
 <abb07b84-5e48-ab9d-cf78-700c6450c4f7@oracle.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 <vladimir.x.ivanov at oracle.com>; Tobias Hartmann <tobias.hartmann at oracle.com>
Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R <vivek.r.deshpande at intel.com>
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 <sandhya.viswanathan at intel.com>; 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190608/30a5f234/signature.asc>

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: <F1AD4CAD-62EE-4ED2-855A-34EEA324E146@oracle.com>
References: <F3280CA8-3DB2-4B68-A08C-60ED1865BB2D@oracle.com>
 <4C2D0A78.5020906@oracle.com>
 <E27854FA-1D96-4E14-BC4B-E19361D55BA2@oracle.com>
 <4C2D0EC1.4090607@oracle.com>
 <F1AD4CAD-62EE-4ED2-855A-34EEA324E146@oracle.com>
Message-ID: <CANBtmZtX=m8tPDXTp1_-GvsFWXi2CupVL03rEtj2_Lcm=xfztQ@mail.gmail.com>

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 <tom.rodriguez at oracle.com>
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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/c8ab8829/attachment.html>

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: <aa1e12d5-8c63-7068-c002-b2784aa260ef@oracle.com>
References: <C55BF0BB-A6F9-4D8A-BF47-0E04D1BAF9FA@oracle.com>
 <35CF8810-C61E-40CC-AFA6-20AC385B74D6@oracle.com>
 <aa1e12d5-8c63-7068-c002-b2784aa260ef@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 <tobias.hartmann at oracle.com> 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 <igor.ignatyev at oracle.com> 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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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 <leonid.mesnik at oracle.com> wrote:

Thank you for review.

Leonid

> On Jun 7, 2019, at 1:07 AM, Tobias Hartmann <tobias.hartmann at oracle.com> 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: <AM6PR02MB4788F097297D02512F57F4C99A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788D4D7C4255E80D3B7C3CC9A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <AM6PR02MB4788F097297D02512F57F4C99A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <f78f7dda-34bb-e065-ea92-5f23be3306b3@linux.vnet.ibm.com>

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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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: <e0846ca8-7a97-d372-70bd-ae8d18f4805c@oracle.com>

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: <e0846ca8-7a97-d372-70bd-ae8d18f4805c@oracle.com>
References: <e0846ca8-7a97-d372-70bd-ae8d18f4805c@oracle.com>
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: <e0846ca8-7a97-d372-70bd-ae8d18f4805c@oracle.com>
 <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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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: <CANBtmZtX=m8tPDXTp1_-GvsFWXi2CupVL03rEtj2_Lcm=xfztQ@mail.gmail.com>
References: <F3280CA8-3DB2-4B68-A08C-60ED1865BB2D@oracle.com>
 <4C2D0A78.5020906@oracle.com>
 <E27854FA-1D96-4E14-BC4B-E19361D55BA2@oracle.com>
 <4C2D0EC1.4090607@oracle.com>
 <F1AD4CAD-62EE-4ED2-855A-34EEA324E146@oracle.com>
 <CANBtmZtX=m8tPDXTp1_-GvsFWXi2CupVL03rEtj2_Lcm=xfztQ@mail.gmail.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 <tom.rodriguez at oracle.com 
> <mailto:tom.rodriguez at oracle.com>> 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/
>     <http://cr.openjdk.java.net/%7Enever/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>
 <abb07b84-5e48-ab9d-cf78-700c6450c4f7@oracle.com>
 <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com>
 <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com>
Message-ID: <df73969e-cb45-8a25-45be-2d1b970139c5@oracle.com>

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 <vladimir.x.ivanov at oracle.com>; Tobias Hartmann <tobias.hartmann at oracle.com>
> Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R <vivek.r.deshpande at intel.com>
> 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 <sandhya.viswanathan at intel.com>; 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 <vladimir.kozlov at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190610/c727206b/attachment.html>

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: <C1220770-1DB1-4847-9E45-DA96B3E1540D@oracle.com>

Thank you, Igor

Vladimir

> On Jun 10, 2019, at 3:11 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> Looks good.
> 
> igor
> 
> 
> 
>> On Jun 7, 2019, at 4:43 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190610/630970d5/attachment-0001.html>

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>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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: <DF218115-C3BC-4DA7-9450-B92DE269ED0F@oracle.com>

Hi Andrew,

> On Jun 7, 2019, at 7:10 AM, Andrew Dinn <adinn at redhat.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190610/2a5759c8/attachment.html>

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 <vladimir.kozlov at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190611/a9bd8c76/signature.asc>

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: <f78f7dda-34bb-e065-ea92-5f23be3306b3@linux.vnet.ibm.com>
References: <AM6PR02MB4788D4D7C4255E80D3B7C3CC9A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <AM6PR02MB4788F097297D02512F57F4C99A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <f78f7dda-34bb-e065-ea92-5f23be3306b3@linux.vnet.ibm.com>
Message-ID: <AM6PR02MB478813A1925550C53490B46B9AED0@AM6PR02MB4788.eurprd02.prod.outlook.com>

Hi Vladimir and Gustavo,

thank you for reviewing.

Also thanks for the performance measurement.
 
Best regards,
Martin


> -----Original Message-----
> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
> Sent: Sonntag, 9. Juni 2019 22:44
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <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

<webrev> - 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
> 
> <webrev> - 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: <edf0de93-5f6f-1959-7244-ab4258b71cad@oracle.com>
References: <OF5A103C8F.49119082-ON00258409.00336268-80258409.003591DC@notes.na.collabserv.com>
 <68b970be-e551-577d-0ca1-28c16880a2ff@oracle.com>
 <OF61020F18.EE36B8A7-ON00258409.004F6B79-80258409.0051D5E9@notes.na.collabserv.com>
 <dfdc2eeb-2d29-5ce4-1ec8-42f6dff3c613@oracle.com>
 <OF145E34DC.BB688A46-ON0025840B.0054EC73-8025840B.00589184@notes.na.collabserv.com>
 <edf0de93-5f6f-1959-7244-ab4258b71cad@oracle.com>
Message-ID: <OFEF950A80.DFCA876A-ON00258416.002F8DD3-80258416.0031D04B@notes.na.collabserv.com>

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 <vladimir.x.ivanov at oracle.com> wrote on 05/06/2019 
19:15:27:

> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>
> 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 <num of chars in buffer, per encoding>"
> > 
> > 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 <vladimir.x.ivanov at oracle.com> wrote on 
29/05/201917:19:36:
> > 
> >> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> >> To: Adam Farley8 <adam.farley at uk.ibm.com>
> >> 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 <vladimir.x.ivanov at oracle.com> wrote on  29/05/
> 201913:22:27:
> >> > 
> >> >> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> >> >> To: Adam Farley8 <adam.farley at uk.ibm.com>,  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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190611/d2cd2ca9/attachment-0001.html>

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: <bd210b7f-adde-d226-72f1-29c5eb1a9720@oracle.com>

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
>>
>> <webrev> - 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: <DF218115-C3BC-4DA7-9450-B92DE269ED0F@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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>
 <DF218115-C3BC-4DA7-9450-B92DE269ED0F@oracle.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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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: <b3c7e974-37b0-58ff-3950-bf298e6985f5@redhat.com>

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: <OFEF950A80.DFCA876A-ON00258416.002F8DD3-80258416.0031D04B@notes.na.collabserv.com>
References: <OF5A103C8F.49119082-ON00258409.00336268-80258409.003591DC@notes.na.collabserv.com>
 <68b970be-e551-577d-0ca1-28c16880a2ff@oracle.com>
 <OF61020F18.EE36B8A7-ON00258409.004F6B79-80258409.0051D5E9@notes.na.collabserv.com>
 <dfdc2eeb-2d29-5ce4-1ec8-42f6dff3c613@oracle.com>
 <OF145E34DC.BB688A46-ON0025840B.0054EC73-8025840B.00589184@notes.na.collabserv.com>
 <edf0de93-5f6f-1959-7244-ab4258b71cad@oracle.com>
 <OFEF950A80.DFCA876A-ON00258416.002F8DD3-80258416.0031D04B@notes.na.collabserv.com>
Message-ID: <bc65f5f1-a05c-bf70-6277-452c990fd995@redhat.com>

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: <CAG22-wvu7_-6QZNvTuLP7ksoekdEktMK8cYi74OccfZi9ha9UA@mail.gmail.com>
References: <CAG22-wv7HHYrE8avy__VY-PfhTX+n1rA+sMyFXPE_P_cCB6veQ@mail.gmail.com>
 <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com>
 <726994dd-fd15-cadb-7a1c-9daac1780050@oracle.com>
 <CAG22-wvPiPw28Bm4dU+_buYw-MydHt9vM2_xg3mXKF6efHc+OQ@mail.gmail.com>
 <CAG22-wvu7_-6QZNvTuLP7ksoekdEktMK8cYi74OccfZi9ha9UA@mail.gmail.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: <AM6PR02MB4788BC849EBACC9FC634E6409A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788BC849EBACC9FC634E6409A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
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: <AM6PR02MB4788BC849EBACC9FC634E6409A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <97caa47e-ca35-45f2-0af4-b417cbbd167d@oracle.com>
Message-ID: <AM6PR02MB47889E3C1A9E0D209223B2699AED0@AM6PR02MB4788.eurprd02.prod.outlook.com>

Hi Tobias,

thank you for the review.

Best regards,
Martin


> -----Original Message-----
> From: Tobias Hartmann <tobias.hartmann at oracle.com>
> Sent: Dienstag, 11. Juni 2019 12:23
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>; jdk-
> updates-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Schmidt, Lutz <lutz.schmidt at sap.com>;
> Volker Simonis (volker.simonis at gmail.com) <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 <tobias.hartmann at oracle.com> 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: <df73969e-cb45-8a25-45be-2d1b970139c5@oracle.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B02432@FMSMSX126.amr.corp.intel.com>
 <abb07b84-5e48-ab9d-cf78-700c6450c4f7@oracle.com>
 <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com>
 <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com>
 <df73969e-cb45-8a25-45be-2d1b970139c5@oracle.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 <vivek.r.deshpande at intel.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
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 <vladimir.x.ivanov at oracle.com>; Tobias Hartmann <tobias.hartmann at oracle.com>
> Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R <vivek.r.deshpande at intel.com>
> 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 <sandhya.viswanathan at intel.com>; 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>
 <abb07b84-5e48-ab9d-cf78-700c6450c4f7@oracle.com>
 <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com>
 <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com>
 <df73969e-cb45-8a25-45be-2d1b970139c5@oracle.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 <vivek.r.deshpande at intel.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
> 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 <vladimir.x.ivanov at oracle.com>; Tobias Hartmann <tobias.hartmann at oracle.com>
>> Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R <vivek.r.deshpande at intel.com>
>> 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 <sandhya.viswanathan at intel.com>; 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>
 <abb07b84-5e48-ab9d-cf78-700c6450c4f7@oracle.com>
 <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B026F7@FMSMSX126.amr.corp.intel.com>
 <53E8E64DB2403849AFD89B7D4DAC8B2A9F50D4A4@ORSMSX106.amr.corp.intel.com>
 <df73969e-cb45-8a25-45be-2d1b970139c5@oracle.com>
 <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1B05518@FMSMSX126.amr.corp.intel.com>
 <28768ede-0444-4435-fb07-923427761615@oracle.com>
Message-ID: <AM6PR02MB4788A33763C4C537447C25CA9AED0@AM6PR02MB4788.eurprd02.prod.outlook.com>

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 <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Vladimir Kozlov
> Sent: Dienstag, 11. Juni 2019 18:16
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Deshpande,
> Vivek R <vivek.r.deshpande at intel.com>
> 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 <vivek.r.deshpande at intel.com>; Viswanathan,
> Sandhya <sandhya.viswanathan at intel.com>
> > 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 <vladimir.x.ivanov at oracle.com>; Tobias Hartmann
> <tobias.hartmann at oracle.com>
> >> Cc: hotspot-compiler-dev at openjdk.java.net; Deshpande, Vivek R
> <vivek.r.deshpande at intel.com>
> >> 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 <sandhya.viswanathan at intel.com>; 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: <CD6846A8-35E7-4CD2-8632-C749E1CE9320@oracle.com>

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: <F3280CA8-3DB2-4B68-A08C-60ED1865BB2D@oracle.com>
 <4C2D0A78.5020906@oracle.com>
 <E27854FA-1D96-4E14-BC4B-E19361D55BA2@oracle.com>
 <4C2D0EC1.4090607@oracle.com>
 <F1AD4CAD-62EE-4ED2-855A-34EEA324E146@oracle.com>
 <CANBtmZtX=m8tPDXTp1_-GvsFWXi2CupVL03rEtj2_Lcm=xfztQ@mail.gmail.com>
 <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com>
Message-ID: <CANBtmZut14=YycJvcDd2=oYK1gkoWGCKEX9BjhTvyf+vwH1ycg@mail.gmail.com>

On Mon, Jun 10, 2019 at 10:45 AM Tom Rodriguez <tom.rodriguez at oracle.com>
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 <tom.rodriguez at oracle.com
> > <mailto:tom.rodriguez at oracle.com>> 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/
> >     <http://cr.openjdk.java.net/%7Enever/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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190611/a7afd30e/attachment.html>

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 <igor.ignatyev at oracle.com> 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 <vladimir.kozlov at oracle.com> wrote:
> 
> Good.
> 
> Thanks
> Vladimir
> 
>> On Jun 11, 2019, at 2:13 PM, Igor Ignatyev <igor.ignatyev at oracle.com> 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<mailto:shay.gueron at intel.com>) and Regev Shemy (regev.shemy at intel.com<mailto: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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190611/d9a8e210/attachment.html>

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: <AM6PR02MB4788B384F474771874641C9A9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788A72D604B0BDA22C375D19A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <AM6PR02MB4788B384F474771874641C9A9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
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: <f6f82494-5bce-3c43-c2aa-aecca1894036@oracle.com>

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: <CAEgw74AwsauJTjTGP6bHk_CsXF_RzK5p+wu-jiK-zMG=VOfgsA@mail.gmail.com>

[ 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 <fujie at loongson.cn> 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: <e79a452c-14c0-2da2-f132-d32e67beb3c3@oracle.com>

> 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: <e79a452c-14c0-2da2-f132-d32e67beb3c3@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>
 <e79a452c-14c0-2da2-f132-d32e67beb3c3@oracle.com>
Message-ID: <dad95812-9588-0cc9-a74f-c1e711563e19@oracle.com>

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: <AM6PR02MB4788A72D604B0BDA22C375D19A190@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <AM6PR02MB4788B384F474771874641C9A9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <62bd9968-c59b-1ce3-17a6-8b7c4206962b@linux.vnet.ibm.com>
Message-ID: <AM6PR02MB47888CC01B36DFEA77B730509AEC0@AM6PR02MB4788.eurprd02.prod.outlook.com>

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 <gromero at linux.vnet.ibm.com>
> Sent: Mittwoch, 12. Juni 2019 04:02
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <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: <AM6PR02MB4788BC3E0EF2A3D392839BA19AEC0@AM6PR02MB4788.eurprd02.prod.outlook.com>

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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190612/bf17069e/attachment.html>

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: <AM6PR02MB4788BC3E0EF2A3D392839BA19AEC0@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788BC3E0EF2A3D392839BA19AEC0@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <fe24617a-748b-952b-0efa-f12ececbaa3d@linux.vnet.ibm.com>

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/ <http://cr.openjdk.java.net/%7Emdoerr/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: <f6f82494-5bce-3c43-c2aa-aecca1894036@oracle.com>
References: <f6f82494-5bce-3c43-c2aa-aecca1894036@oracle.com>
Message-ID: <14FB381F-53CE-4ECF-9A0D-8A6F3696D6AB@oracle.com>

Looks good.

Thanks
Vladimir

> On Jun 11, 2019, at 11:33 PM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> 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 <rwestrel at redhat.com> 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: <AM6PR02MB4788BC3E0EF2A3D392839BA19AEC0@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788BC3E0EF2A3D392839BA19AEC0@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <2CD9E5CF-B51E-4F93-AAB9-885DC52054C8@oracle.com>

Good.

Thanks
Vladimir

> On Jun 12, 2019, at 7:53 AM, Doerr, Martin <martin.doerr at sap.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190612/bed66de2/attachment.html>

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: <AM6PR02MB4788BC3E0EF2A3D392839BA19AEC0@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <AM6PR02MB4788BC3E0EF2A3D392839BA19AEC0@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB5078050D2EC01AD7298032C293EC0@AM6PR02MB5078.eurprd02.prod.outlook.com>

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' <hotspot-compiler-dev at openjdk.java.net>; Gustavo Romero <gromero at linux.vnet.ibm.com>; Baesken, Matthias <matthias.baesken at sap.com>; Zeller, Arno <arno.zeller at sap.com>
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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190612/9aecf789/attachment.html>

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 <rwestrel at redhat.com> 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 <vladimir.kozlov at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190612/26f28f7c/attachment.html>

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: <e747f8d7-0e6b-0006-6ef7-5803984cf817@oracle.com>

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 <vladimir.kozlov at oracle.com 
>> <mailto:vladimir.kozlov at oracle.com>> 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: <f6f82494-5bce-3c43-c2aa-aecca1894036@oracle.com>
 <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 <ekaterina.pavlova at oracle.com> 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: <ad6dc4c0-f155-8842-88ca-1e210b21be58@oracle.com>

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: <ad6dc4c0-f155-8842-88ca-1e210b21be58@oracle.com>
References: <0907E9D4-6689-4437-9B44-DAC92846EACA@oracle.com>
 <ad6dc4c0-f155-8842-88ca-1e210b21be58@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 <david.holmes at oracle.com> 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: <CANBtmZut14=YycJvcDd2=oYK1gkoWGCKEX9BjhTvyf+vwH1ycg@mail.gmail.com>
References: <F3280CA8-3DB2-4B68-A08C-60ED1865BB2D@oracle.com>
 <4C2D0A78.5020906@oracle.com>
 <E27854FA-1D96-4E14-BC4B-E19361D55BA2@oracle.com>
 <4C2D0EC1.4090607@oracle.com>
 <F1AD4CAD-62EE-4ED2-855A-34EEA324E146@oracle.com>
 <CANBtmZtX=m8tPDXTp1_-GvsFWXi2CupVL03rEtj2_Lcm=xfztQ@mail.gmail.com>
 <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com>
 <CANBtmZut14=YycJvcDd2=oYK1gkoWGCKEX9BjhTvyf+vwH1ycg@mail.gmail.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 <tom.rodriguez at oracle.com 
> <mailto:tom.rodriguez at oracle.com>> 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
>     <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>
>      > <mailto:tom.rodriguez at oracle.com
>     <mailto:tom.rodriguez at oracle.com>>> 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/
>     <http://cr.openjdk.java.net/%7Enever/6965671/>
>      >? ? ?<http://cr.openjdk.java.net/%7Enever/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: <CAEgw74AwsauJTjTGP6bHk_CsXF_RzK5p+wu-jiK-zMG=VOfgsA@mail.gmail.com>
References: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn>
 <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com>
 <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn>
 <CAEgw74AwsauJTjTGP6bHk_CsXF_RzK5p+wu-jiK-zMG=VOfgsA@mail.gmail.com>
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 <fujie at loongson.cn> 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: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>

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: <AM6PR02MB4788BC3E0EF2A3D392839BA19AEC0@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <2CD9E5CF-B51E-4F93-AAB9-885DC52054C8@oracle.com>
Message-ID: <AM6PR02MB4788F60EE23208B8A7A55D2A9AEF0@AM6PR02MB4788.eurprd02.prod.outlook.com>

Thanks for the reviews. Pushed.

Best regards,
Martin


From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
Sent: Mittwoch, 12. Juni 2019 17:14
To: Doerr, Martin <martin.doerr at sap.com>
Cc: hotspot-compiler-dev at openjdk.java.net; Gustavo Romero <gromero at linux.vnet.ibm.com>; Baesken, Matthias <matthias.baesken at sap.com>; Zeller, Arno <arno.zeller at sap.com>
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 <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190613/aaf727a6/attachment.html>

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: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
Message-ID: <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>


> 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: <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
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: <bc65f5f1-a05c-bf70-6277-452c990fd995@redhat.com>
References: <OF5A103C8F.49119082-ON00258409.00336268-80258409.003591DC@notes.na.collabserv.com>
 <68b970be-e551-577d-0ca1-28c16880a2ff@oracle.com>
 <OF61020F18.EE36B8A7-ON00258409.004F6B79-80258409.0051D5E9@notes.na.collabserv.com>
 <dfdc2eeb-2d29-5ce4-1ec8-42f6dff3c613@oracle.com>
 <OF145E34DC.BB688A46-ON0025840B.0054EC73-8025840B.00589184@notes.na.collabserv.com>
 <edf0de93-5f6f-1959-7244-ab4258b71cad@oracle.com>
 <OFEF950A80.DFCA876A-ON00258416.002F8DD3-80258416.0031D04B@notes.na.collabserv.com>
 <bc65f5f1-a05c-bf70-6277-452c990fd995@redhat.com>
Message-ID: <OF94673718.A39C5BA2-ON00258418.0052523D-80258418.00532938@notes.na.collabserv.com>

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 <adinn at redhat.com> wrote on 11/06/2019 10:50:20:

> From: Andrew Dinn <adinn at redhat.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>, Vladimir Ivanov 
> <vladimir.x.ivanov at oracle.com>
> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190613/76f8fd67/attachment.html>

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: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
Message-ID: <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>

Seems good to me too.

Thanks,
Bernard

On Thu, 13 Jun 2019 at 14:27, Jie Fu <fujie at loongson.cn> 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: <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
 <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
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 <fujie at loongson.cn> 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] <task compile_id='2409' method='compiler.compilercontrol.share.pool.sub.Klass$Internal smethod 
(Ljava/lang/Integer;)Ljava/lang/Integer;' bytes='20' count='50' backedge_count='1' iicount='100' 
blocking='1' stamp='18.732'>
<task_done success='1' nmsize='344' count='50' backedge_count='1' inlined_bytes='106' stamp='18.735'/>

[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: <FF7B4A11-262A-4E8E-ADB0-3E71446BCC57@oracle.com>

Hi Vladimir,

this sounds reasonable to me, reviewed.

Cheers,
-- Igor

> On Jun 13, 2019, at 4:04 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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] <task compile_id='2409' method='compiler.compilercontrol.share.pool.sub.Klass$Internal smethod (Ljava/lang/Integer;)Ljava/lang/Integer;' bytes='20' count='50' backedge_count='1' iicount='100' blocking='1' stamp='18.732'>
> <task_done success='1' nmsize='344' count='50' backedge_count='1' inlined_bytes='106' stamp='18.735'/>
> 
> [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: <FF7B4A11-262A-4E8E-ADB0-3E71446BCC57@oracle.com>
References: <573c07a3-3bcc-4a02-3b75-83bb6c5e7c94@oracle.com>
 <FF7B4A11-262A-4E8E-ADB0-3E71446BCC57@oracle.com>
Message-ID: <a3ae04dc-cff7-c88b-7050-c78563942292@oracle.com>

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 <vladimir.kozlov at oracle.com> 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] <task compile_id='2409' method='compiler.compilercontrol.share.pool.sub.Klass$Internal smethod (Ljava/lang/Integer;)Ljava/lang/Integer;' bytes='20' count='50' backedge_count='1' iicount='100' blocking='1' stamp='18.732'>
>> <task_done success='1' nmsize='344' count='50' backedge_count='1' inlined_bytes='106' stamp='18.735'/>
>>
>> [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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190613/45f51202/attachment.html>

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: <CAJgZ6Z9C0Q09Vsqf_8J6C7cJbYGZDP_Z+XXNr08-EOrxddpSow@mail.gmail.com>

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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190614/485ddbd1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: incorrect-caller.zip
Type: application/zip
Size: 3149 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190614/485ddbd1/incorrect-caller-0001.zip>

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: <f923c720-ef79-318d-184b-ebaaa8ecbbe9@oracle.com>

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: <CAJgZ6Z9C0Q09Vsqf_8J6C7cJbYGZDP_Z+XXNr08-EOrxddpSow@mail.gmail.com>
References: <CAJgZ6Z9C0Q09Vsqf_8J6C7cJbYGZDP_Z+XXNr08-EOrxddpSow@mail.gmail.com>
Message-ID: <D48E26BA-3750-4A30-B32B-315BDCB737E4@oracle.com>

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 <tianxiao.gu at gmail.com> 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 <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 <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 <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
> 
> <incorrect-caller.zip>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190614/414a2e89/attachment.html>

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: <D48E26BA-3750-4A30-B32B-315BDCB737E4@oracle.com>
References: <CAJgZ6Z9C0Q09Vsqf_8J6C7cJbYGZDP_Z+XXNr08-EOrxddpSow@mail.gmail.com>
 <D48E26BA-3750-4A30-B32B-315BDCB737E4@oracle.com>
Message-ID: <CAJgZ6Z-qzw3g7Qd-sS1R55zEezxfomX+m33mtn87cEWxdz18Cg@mail.gmail.com>

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 <doug.simon at oracle.com> 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 <tianxiao.gu at gmail.com> 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
>
> <incorrect-caller.zip>
>
>
>

--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190614/482dd5b8/attachment-0001.html>

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: <CAJgZ6Z-qzw3g7Qd-sS1R55zEezxfomX+m33mtn87cEWxdz18Cg@mail.gmail.com>
References: <CAJgZ6Z9C0Q09Vsqf_8J6C7cJbYGZDP_Z+XXNr08-EOrxddpSow@mail.gmail.com>
 <D48E26BA-3750-4A30-B32B-315BDCB737E4@oracle.com>
 <CAJgZ6Z-qzw3g7Qd-sS1R55zEezxfomX+m33mtn87cEWxdz18Cg@mail.gmail.com>
Message-ID: <ACEC247E-7BCF-46BA-8619-BB5CE92430F2@oracle.com>



> On 14 Jun 2019, at 12:36, Tianxiao Gu <tianxiao.gu at gmail.com> 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 <doug.simon at oracle.com <mailto:doug.simon at oracle.com>> 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 <tianxiao.gu at gmail.com <mailto:tianxiao.gu at gmail.com>> 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 <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 <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 <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
>> 
>> <incorrect-caller.zip>
> 
> 
> 
> -- 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190614/c4b70bc9/attachment.html>

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: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
 <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
 <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn>
Message-ID: <CAEgw74DiEwrmeB=3JF2mGBzvaTc21mNh=TZ7MXgfc+86pbpDaA@mail.gmail.com>

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 <fujie at loongson.cn> 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 <fujie at loongson.cn> 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: <ACEC247E-7BCF-46BA-8619-BB5CE92430F2@oracle.com>
References: <CAJgZ6Z9C0Q09Vsqf_8J6C7cJbYGZDP_Z+XXNr08-EOrxddpSow@mail.gmail.com>
 <D48E26BA-3750-4A30-B32B-315BDCB737E4@oracle.com>
 <CAJgZ6Z-qzw3g7Qd-sS1R55zEezxfomX+m33mtn87cEWxdz18Cg@mail.gmail.com>
 <ACEC247E-7BCF-46BA-8619-BB5CE92430F2@oracle.com>
Message-ID: <c6a26e95-9e6b-7b66-a8b7-ba0e12d55d7e@oracle.com>

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 <tianxiao.gu at gmail.com <mailto:tianxiao.gu at gmail.com>> 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 <doug.simon at oracle.com <mailto:doug.simon at oracle.com>> 
>> 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 <tianxiao.gu at gmail.com <mailto:tianxiao.gu at gmail.com>>
>>>     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
>>>
>>>     <incorrect-caller.zip>
>>
>>
>>
>> -- 
>>
> 

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: <ad583aaf-fe10-4127-37a3-1e18ade37e85@oracle.com>

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: <CAEgw74DiEwrmeB=3JF2mGBzvaTc21mNh=TZ7MXgfc+86pbpDaA@mail.gmail.com>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
 <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
 <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn>
 <CAEgw74DiEwrmeB=3JF2mGBzvaTc21mNh=TZ7MXgfc+86pbpDaA@mail.gmail.com>
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 <fujie at loongson.cn> 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 <fujie at loongson.cn> 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: <ad583aaf-fe10-4127-37a3-1e18ade37e85@oracle.com>
References: <ad583aaf-fe10-4127-37a3-1e18ade37e85@oracle.com>
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 <vladimir.kozlov at oracle.com> 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: <ad583aaf-fe10-4127-37a3-1e18ade37e85@oracle.com>
 <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 <vladimir.kozlov at oracle.com> 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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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: <a221d477-28e6-e63c-952b-aa1eb1098cd5@oracle.com>

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: <F3280CA8-3DB2-4B68-A08C-60ED1865BB2D@oracle.com>
 <4C2D0A78.5020906@oracle.com>
 <E27854FA-1D96-4E14-BC4B-E19361D55BA2@oracle.com>
 <4C2D0EC1.4090607@oracle.com>
 <F1AD4CAD-62EE-4ED2-855A-34EEA324E146@oracle.com>
 <CANBtmZtX=m8tPDXTp1_-GvsFWXi2CupVL03rEtj2_Lcm=xfztQ@mail.gmail.com>
 <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com>
 <CANBtmZut14=YycJvcDd2=oYK1gkoWGCKEX9BjhTvyf+vwH1ycg@mail.gmail.com>
 <57037b04-866f-74d1-b9c4-ab00c29dbbef@oracle.com>
Message-ID: <CANBtmZuLnJJ8WN7eJgh0EXTpVaXJ+9nYD23rFAu5TERu4TO_9w@mail.gmail.com>

Submitted a bug report and here is the  internal review ID : 9061251.

On Wed, Jun 12, 2019 at 5:24 PM Tom Rodriguez <tom.rodriguez at oracle.com>
wrote:

>
>
> Leela Mohan wrote on 6/11/19 12:53 PM:
> >
> >
> > On Mon, Jun 10, 2019 at 10:45 AM Tom Rodriguez <tom.rodriguez at oracle.com
> > <mailto:tom.rodriguez at oracle.com>> 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
> >     <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>
> >      > <mailto:tom.rodriguez at oracle.com
> >     <mailto:tom.rodriguez at oracle.com>>> 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/
> >     <http://cr.openjdk.java.net/%7Enever/6965671/>
> >      >     <http://cr.openjdk.java.net/%7Enever/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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190616/d87847c3/attachment.html>

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: <CANBtmZuLnJJ8WN7eJgh0EXTpVaXJ+9nYD23rFAu5TERu4TO_9w@mail.gmail.com>
References: <F3280CA8-3DB2-4B68-A08C-60ED1865BB2D@oracle.com>
 <4C2D0A78.5020906@oracle.com>
 <E27854FA-1D96-4E14-BC4B-E19361D55BA2@oracle.com>
 <4C2D0EC1.4090607@oracle.com>
 <F1AD4CAD-62EE-4ED2-855A-34EEA324E146@oracle.com>
 <CANBtmZtX=m8tPDXTp1_-GvsFWXi2CupVL03rEtj2_Lcm=xfztQ@mail.gmail.com>
 <72a8a839-968d-3229-80ca-d2383aa48a59@oracle.com>
 <CANBtmZut14=YycJvcDd2=oYK1gkoWGCKEX9BjhTvyf+vwH1ycg@mail.gmail.com>
 <57037b04-866f-74d1-b9c4-ab00c29dbbef@oracle.com>
 <CANBtmZuLnJJ8WN7eJgh0EXTpVaXJ+9nYD23rFAu5TERu4TO_9w@mail.gmail.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 <leelamohan.venati at gmail.com> 
Sent: Sunday, June 16, 2019 11:08 PM
To: Tom Rodriguez <tom.rodriguez at oracle.com>
Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
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 <HYPERLINK "mailto:tom.rodriguez at oracle.com"tom.rodriguez at oracle.com> wrote:



Leela Mohan wrote on 6/11/19 12:53 PM:
> 
> 
> On Mon, Jun 10, 2019 at 10:45 AM Tom Rodriguez <HYPERLINK "mailto:tom.rodriguez at oracle.com"tom.rodriguez at oracle.com 
> <mailto:HYPERLINK "mailto:tom.rodriguez at oracle.com"tom.rodriguez at oracle.com>> 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
>? ? ?<HYPERLINK "mailto:tom.rodriguez at oracle.com"tom.rodriguez at oracle.com <mailto:HYPERLINK "mailto:tom.rodriguez at oracle.com"tom.rodriguez at oracle.com>
>? ? ? > <mailto:HYPERLINK "mailto:tom.rodriguez at oracle.com"tom.rodriguez at oracle.com
>? ? ?<mailto:HYPERLINK "mailto:tom.rodriguez at oracle.com"tom.rodriguez at oracle.com>>> 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/
>? ? ?<http://cr.openjdk.java.net/%7Enever/6965671/>
>? ? ? >? ? ?<http://cr.openjdk.java.net/%7Enever/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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190617/92dc9794/attachment-0001.html>

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: <adaee36e-a79c-9969-b0eb-3eb4b1e213ba@oracle.com>

Hi,

Please review the following proposed changes for JDK 13.

<webrev> - 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: <OF6B75518B.43F9C814-ON49258411.003003AD-49258411.00302747@notes.na.collabserv.com>
References: <OFCF50AB8E.620EEDF8-ON49258411.0029F9B0-49258411.002B74BF@notes.na.collabserv.com>
 <AM6PR02MB47885FAE8BE2A6EA8AB4D03F9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OF6B75518B.43F9C814-ON49258411.003003AD-49258411.00302747@notes.na.collabserv.com>
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" <martin.doerr at sap.com> wrote on 2019/06/06 17:29:07:
> 
>> From: "Doerr, Martin" <martin.doerr at sap.com>
>> To: Kazunori Ogata <OGATAK at jp.ibm.com>, "hotspot-compiler-
>> dev at openjdk.java.net" <hotspot-compiler-dev at openjdk.java.net>, "jdk8u-
>> 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 <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: <adaee36e-a79c-9969-b0eb-3eb4b1e213ba@oracle.com>
References: <adaee36e-a79c-9969-b0eb-3eb4b1e213ba@oracle.com>
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.
> 
> <webrev> - 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: <adaee36e-a79c-9969-b0eb-3eb4b1e213ba@oracle.com>
 <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.
>>
>> <webrev> - 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: <d90a9576-d320-dbf0-b24a-b424d89fa778@oracle.com>

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: <f45a4dc5-ec51-445d-ca59-a989a8654950@oracle.com>
References: <CD6846A8-35E7-4CD2-8632-C749E1CE9320@oracle.com>
 <f45a4dc5-ec51-445d-ca59-a989a8654950@oracle.com>
Message-ID: <F0649FAA-B1C3-468D-AF6C-2343958D6EBC@oracle.com>

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: <adaee36e-a79c-9969-b0eb-3eb4b1e213ba@oracle.com>
 <8d8791a1-0845-4e1d-c619-3f9c69b8d211@oracle.com>
 <05b4597d-6237-79d9-b5c4-28b61dafbaed@oracle.com>
Message-ID: <dd068eb9-d271-c40b-285a-3f466245610c@oracle.com>

 >> 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.
>>>
>>> <webrev> - 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: <d90a9576-d320-dbf0-b24a-b424d89fa778@oracle.com>
References: <560e64a5-e199-49a0-edf5-3e3b5c1842ea@oracle.com>
 <d90a9576-d320-dbf0-b24a-b424d89fa778@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: <CD6846A8-35E7-4CD2-8632-C749E1CE9320@oracle.com>
References: <CD6846A8-35E7-4CD2-8632-C749E1CE9320@oracle.com>
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 <hotspot-compiler-dev at openjdk.java.net>
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: <a221d477-28e6-e63c-952b-aa1eb1098cd5@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com>
 <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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>
 <a221d477-28e6-e63c-952b-aa1eb1098cd5@oracle.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: <OFCF50AB8E.620EEDF8-ON49258411.0029F9B0-49258411.002B74BF@notes.na.collabserv.com>
 <AM6PR02MB47885FAE8BE2A6EA8AB4D03F9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OF6B75518B.43F9C814-ON49258411.003003AD-49258411.00302747@notes.na.collabserv.com>
 <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com>
Message-ID: <OFFF1F13B6.D1E6D020-ON4925841D.0043B283-4925841D.0043DF1F@notes.na.collabserv.com>

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" <gromero at linux.vnet.ibm.com> wrote on 2019/06/17 
23:53:42:

> From: "Gustavo Romero" <gromero at linux.vnet.ibm.com>
> To: Kazunori Ogata/Japan/IBM at IBMJP
> Cc: "Doerr, Martin" <martin.doerr at sap.com>, "hotspot-compiler-
> dev at openjdk.java.net" <hotspot-compiler-dev at openjdk.java.net>, "jdk8u-
> 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" <martin.doerr at sap.com> wrote on 2019/06/06 17:29:07:
> > 
> >> From: "Doerr, Martin" <martin.doerr at sap.com>
> >> To: Kazunori Ogata <OGATAK at jp.ibm.com>, "hotspot-compiler-
> >> dev at openjdk.java.net" <hotspot-compiler-dev at openjdk.java.net>, 
"jdk8u-
> >> 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 <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: <cc78cba8-b039-50bc-1b40-7a9d4b725e74@oracle.com>


> 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: <OFFF1F13B6.D1E6D020-ON4925841D.0043B283-4925841D.0043DF1F@notes.na.collabserv.com>
References: <OFCF50AB8E.620EEDF8-ON49258411.0029F9B0-49258411.002B74BF@notes.na.collabserv.com>
 <AM6PR02MB47885FAE8BE2A6EA8AB4D03F9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OF6B75518B.43F9C814-ON49258411.003003AD-49258411.00302747@notes.na.collabserv.com>
 <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com>
 <OFFF1F13B6.D1E6D020-ON4925841D.0043B283-4925841D.0043DF1F@notes.na.collabserv.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: <CD6846A8-35E7-4CD2-8632-C749E1CE9320@oracle.com>
References: <CD6846A8-35E7-4CD2-8632-C749E1CE9320@oracle.com>
Message-ID: <f45a4dc5-ec51-445d-ca59-a989a8654950@oracle.com>

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>
 <d90a9576-d320-dbf0-b24a-b424d89fa778@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) {
<snip>
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: <c15dfce1-2281-daa2-7c42-3500bea53401@oracle.com>

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>
 <d90a9576-d320-dbf0-b24a-b424d89fa778@oracle.com>
 <3b396925-c4d8-e916-537b-6943e2023911@oracle.com>
 <5b7ab526-46bf-db83-4292-6a5322ab6f68@oracle.com>
Message-ID: <ab278665-f3a3-2e15-4e78-cd0cdbf66648@oracle.com>

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) {
> <snip>
> 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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>

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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <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: <c15dfce1-2281-daa2-7c42-3500bea53401@oracle.com>
References: <43663152-87EC-4F79-9C11-6D438BDAF811@oracle.com>
 <c15dfce1-2281-daa2-7c42-3500bea53401@oracle.com>
Message-ID: <DDDDA3AA-9706-4EDD-AC75-19DD53A09151@oracle.com>

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 <tobias.hartmann at oracle.com> 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: <CC6DE0D7-5171-4899-B923-B7FA013370E2@oracle.com>

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: <CC6DE0D7-5171-4899-B923-B7FA013370E2@oracle.com>
References: <CC6DE0D7-5171-4899-B923-B7FA013370E2@oracle.com>
Message-ID: <d0f3ba9f-38c5-a643-7ca3-ec23b46696b9@oracle.com>

> +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: <CC6DE0D7-5171-4899-B923-B7FA013370E2@oracle.com>
References: <CC6DE0D7-5171-4899-B923-B7FA013370E2@oracle.com>
Message-ID: <a4bde277-77f9-d14b-e9e4-eb1f7c598bca@oracle.com>

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: <d0f3ba9f-38c5-a643-7ca3-ec23b46696b9@oracle.com>
References: <CC6DE0D7-5171-4899-B923-B7FA013370E2@oracle.com>
 <d0f3ba9f-38c5-a643-7ca3-ec23b46696b9@oracle.com>
Message-ID: <D4D4FE03-6AC8-4B01-8D24-92D560F17139@oracle.com>

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 <ekaterina.pavlova at oracle.com> 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: <a4bde277-77f9-d14b-e9e4-eb1f7c598bca@oracle.com>
References: <CC6DE0D7-5171-4899-B923-B7FA013370E2@oracle.com>
 <a4bde277-77f9-d14b-e9e4-eb1f7c598bca@oracle.com>
Message-ID: <B874CAEE-8012-41FC-9877-F601C5E2580C@oracle.com>

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 <vladimir.kozlov at oracle.com> 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: <B874CAEE-8012-41FC-9877-F601C5E2580C@oracle.com>
References: <CC6DE0D7-5171-4899-B923-B7FA013370E2@oracle.com>
 <a4bde277-77f9-d14b-e9e4-eb1f7c598bca@oracle.com>
 <B874CAEE-8012-41FC-9877-F601C5E2580C@oracle.com>
Message-ID: <df525b99-19fa-c038-0262-ceba4204d1eb@oracle.com>

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 <vladimir.kozlov at oracle.com> 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: <OFCF50AB8E.620EEDF8-ON49258411.0029F9B0-49258411.002B74BF@notes.na.collabserv.com>
 <AM6PR02MB47885FAE8BE2A6EA8AB4D03F9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OF6B75518B.43F9C814-ON49258411.003003AD-49258411.00302747@notes.na.collabserv.com>
 <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com>
 <OFFF1F13B6.D1E6D020-ON4925841D.0043B283-4925841D.0043DF1F@notes.na.collabserv.com>
 <36140f54-5078-4238-66cd-9de912a64b88@linux.vnet.ibm.com>
Message-ID: <OF43CAEC83.11FF44E3-ON4925841E.002531C9-4925841E.0025CBB6@notes.na.collabserv.com>

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" <gromero at linux.vnet.ibm.com> wrote on 2019/06/18 
23:25:15:

> From: "Gustavo Romero" <gromero at linux.vnet.ibm.com>
> To: Kazunori Ogata/Japan/IBM at IBMJP
> Cc: "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-
> dev at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" <jdk8u-
> dev at openjdk.java.net>, "Doerr, Martin" <martin.doerr at sap.com>
> 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: <ad0c4116-7893-7957-459f-5a9485e08d3f@oracle.com>

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: <ad0c4116-7893-7957-459f-5a9485e08d3f@oracle.com>
References: <ad0c4116-7893-7957-459f-5a9485e08d3f@oracle.com>
Message-ID: <14F122CD-49BD-47E6-9C1E-C851CB71425A@oracle.com>

Hi Tobias,

LGTM

Thanks,
-- Igor

> On Jun 19, 2019, at 1:39 AM, Tobias Hartmann <tobias.hartmann at oracle.com> 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 <tobias.hartmann at oracle.com> 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: <ad0c4116-7893-7957-459f-5a9485e08d3f@oracle.com>
 <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 <tobias.hartmann at oracle.com> 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: <c64e8b21-2f2e-c8bd-a5c2-148e326139d3@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:37 AM, Tobias Hartmann <tobias.hartmann at oracle.com> 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 
<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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190619/949d7157/attachment.html>

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: <OF43CAEC83.11FF44E3-ON4925841E.002531C9-4925841E.0025CBB6@notes.na.collabserv.com>
References: <OFCF50AB8E.620EEDF8-ON49258411.0029F9B0-49258411.002B74BF@notes.na.collabserv.com>
 <AM6PR02MB47885FAE8BE2A6EA8AB4D03F9A170@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <OF6B75518B.43F9C814-ON49258411.003003AD-49258411.00302747@notes.na.collabserv.com>
 <82a2105d-f287-f659-0590-5fb90ccc76bd@linux.vnet.ibm.com>
 <OFFF1F13B6.D1E6D020-ON4925841D.0043B283-4925841D.0043DF1F@notes.na.collabserv.com>
 <36140f54-5078-4238-66cd-9de912a64b88@linux.vnet.ibm.com>
 <OF43CAEC83.11FF44E3-ON4925841E.002531C9-4925841E.0025CBB6@notes.na.collabserv.com>
Message-ID: <a6ee17b3-cfd4-f3e5-1373-a26500df2f88@linux.vnet.ibm.com>

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: <f847b380-0590-cca3-bfb8-9d22b6eb1fa0@oracle.com>

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: <B609C2D4-DDA3-455C-9645-36B41CD7810C@oracle.com>

Looks good but run all testing before push.

Thanks
Vladimir

> On Jun 19, 2019, at 5:49 AM, Nils Eliasson <nils.eliasson at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190619/1004e64b/attachment.html>

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: <a2a91ae8-6977-2428-072f-8101db5b2c83@oracle.com>

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: <a2a91ae8-6977-2428-072f-8101db5b2c83@oracle.com>
References: <5b66250d-a294-0d0f-e938-6a98dfe8c9ca@oracle.com>
 <a2a91ae8-6977-2428-072f-8101db5b2c83@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 <vladimir.kozlov at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190620/655dc377/signature.asc>

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: <CD6846A8-35E7-4CD2-8632-C749E1CE9320@oracle.com>
 <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 <markus.gronlund at oracle.com> 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 <hotspot-compiler-dev at openjdk.java.net>
> 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>
 <d90a9576-d320-dbf0-b24a-b424d89fa778@oracle.com>
 <3b396925-c4d8-e916-537b-6943e2023911@oracle.com>
 <5b7ab526-46bf-db83-4292-6a5322ab6f68@oracle.com>
Message-ID: <aca1edfe-ddff-fb01-1f97-6a2bf6e48c5c@oracle.com>

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) {
> <snip>
> 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 <vladimir.kozlov at oracle.com> 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 <erik.osterlund at oracle.com> wrote:
> 
> Hi Vladimir,
> 
> Looks good.
> 
> Thanks,
> /Erik
> 
>> On 19 Jun 2019, at 23:53, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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<String, ModulePolicy> modulePolicies = 
            ModuleLayer.boot()
                       .configuration().modules().stream()
                       .map(rm -> new ModulePolicy(rm))
                       .collect(Collectors.toMap(ModulePolicy::name, Function.identity()));

    public static Optional<ModulePolicy> 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: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>

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: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
References: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
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: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
 <0cb8d0e0-e40d-4524-97e9-555ff86d85b5@oracle.com>
Message-ID: <ef003feb-5ed0-faca-24cb-05453a630350@oracle.com>

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: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
References: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
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: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
 <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com>
Message-ID: <AAACC9B6-7F9D-4EBA-A68C-AAF53C2BA452@oracle.com>

Hi Per,

Thanks for the review.

/Erik

> On 20 Jun 2019, at 13:04, Per Liden <per.liden at oracle.com> 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: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190620/611b3743/attachment.html>

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: <c4e64bec-ba4a-62ac-3655-f2d3ba148ffb@oracle.com>

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: <AAACC9B6-7F9D-4EBA-A68C-AAF53C2BA452@oracle.com>
References: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
 <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com>
 <AAACC9B6-7F9D-4EBA-A68C-AAF53C2BA452@oracle.com>
Message-ID: <CAEGA6kb9it+wWk25cLZKu3kOqgcYK=p168zJpJ+dcNCBFurJSw@mail.gmail.com>

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 <erik.osterlund at oracle.com> wrote:
>
> Hi Per,
>
> Thanks for the review.
>
> /Erik
>
> > On 20 Jun 2019, at 13:04, Per Liden <per.liden at oracle.com> 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: <bcf45a6d-eac3-f99e-fd1f-83d68c4d91bb@oracle.com>

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: <CAEGA6kb9it+wWk25cLZKu3kOqgcYK=p168zJpJ+dcNCBFurJSw@mail.gmail.com>
References: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
 <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com>
 <AAACC9B6-7F9D-4EBA-A68C-AAF53C2BA452@oracle.com>
 <CAEGA6kb9it+wWk25cLZKu3kOqgcYK=p168zJpJ+dcNCBFurJSw@mail.gmail.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 <stuart.monteith at linaro.org> 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 <erik.osterlund at oracle.com> wrote:
>> 
>> Hi Per,
>> 
>> Thanks for the review.
>> 
>> /Erik
>> 
>>>> On 20 Jun 2019, at 13:04, Per Liden <per.liden at oracle.com> 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: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
 <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com>
 <AAACC9B6-7F9D-4EBA-A68C-AAF53C2BA452@oracle.com>
 <CAEGA6kb9it+wWk25cLZKu3kOqgcYK=p168zJpJ+dcNCBFurJSw@mail.gmail.com>
 <31ED223B-3108-480C-8605-175863A6D15F@oracle.com>
Message-ID: <CAEGA6kZ3eHeCMbWRQaKrch4T4cKkgDvpYFw-Fi3zQ9_8bjpC8g@mail.gmail.com>

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 <erik.osterlund at oracle.com> 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 <stuart.monteith at linaro.org> 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 <erik.osterlund at oracle.com> wrote:
> >>
> >> Hi Per,
> >>
> >> Thanks for the review.
> >>
> >> /Erik
> >>
> >>>> On 20 Jun 2019, at 13:04, Per Liden <per.liden at oracle.com> 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: <CAEGA6kZ3eHeCMbWRQaKrch4T4cKkgDvpYFw-Fi3zQ9_8bjpC8g@mail.gmail.com>
References: <acbf5238-68fd-f4cc-b5b8-b33e67d24222@oracle.com>
 <5836b837-d1be-48db-b005-c0e118ad2309@oracle.com>
 <AAACC9B6-7F9D-4EBA-A68C-AAF53C2BA452@oracle.com>
 <CAEGA6kb9it+wWk25cLZKu3kOqgcYK=p168zJpJ+dcNCBFurJSw@mail.gmail.com>
 <31ED223B-3108-480C-8605-175863A6D15F@oracle.com>
 <CAEGA6kZ3eHeCMbWRQaKrch4T4cKkgDvpYFw-Fi3zQ9_8bjpC8g@mail.gmail.com>
Message-ID: <BCDD5972-E121-4131-B624-E87230B9C087@oracle.com>

Hi Stuart,

That looks right. I will fold it in to my push.

Thanks,
/Erik

> On 20 Jun 2019, at 19:05, Stuart Monteith <stuart.monteith at linaro.org> 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 <erik.osterlund at oracle.com> 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 <stuart.monteith at linaro.org> 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 <erik.osterlund at oracle.com> wrote:
>>>> 
>>>> Hi Per,
>>>> 
>>>> Thanks for the review.
>>>> 
>>>> /Erik
>>>> 
>>>>>> On 20 Jun 2019, at 13:04, Per Liden <per.liden at oracle.com> 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: <bcf45a6d-eac3-f99e-fd1f-83d68c4d91bb@oracle.com>
References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com>
 <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com>
 <11d9ab2a-a39f-7912-209c-15877351ad5d@oracle.com>
 <bcf45a6d-eac3-f99e-fd1f-83d68c4d91bb@oracle.com>
Message-ID: <e73f67ce-bdaa-bad7-6099-e04935528d29@oracle.com>

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: <c4e64bec-ba4a-62ac-3655-f2d3ba148ffb@oracle.com>
References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com>
 <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com>
 <8bc93db6-e4c0-44b7-1783-b04e90ff53a6@oracle.com>
 <c4e64bec-ba4a-62ac-3655-f2d3ba148ffb@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: <cc78cba8-b039-50bc-1b40-7a9d4b725e74@oracle.com>
References: <8D6F463991A1574A8A803B8DA605414F3A8D88B2@ORSMSX111.amr.corp.intel.com>
 <cc78cba8-b039-50bc-1b40-7a9d4b725e74@oracle.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 <shravya.rukmannagari at intel.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
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>
 <c4e64bec-ba4a-62ac-3655-f2d3ba148ffb@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: <b569e0a9-d404-0a9b-7a84-79609022b9d1@oracle.com>

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: <f472fab2-c5ac-d45e-fe3b-ce326caa5595@oracle.com>

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>
 <c4e64bec-ba4a-62ac-3655-f2d3ba148ffb@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<AtomicBoolean> 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: <dbe42596-bab2-8aeb-0245-8cad1fea608e@bell-sw.com>

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: <dbe42596-bab2-8aeb-0245-8cad1fea608e@bell-sw.com>
References: <dbe42596-bab2-8aeb-0245-8cad1fea608e@bell-sw.com>
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://www.redhat.com>
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>
 <c4e64bec-ba4a-62ac-3655-f2d3ba148ffb@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<AtomicBoolean> 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>
 <c4e64bec-ba4a-62ac-3655-f2d3ba148ffb@oracle.com>
 <1f43fbbd-cf86-b3cd-af41-9155bdd05dbd@oracle.com>
 <13602729-7b19-c198-2c62-0a02d7580d27@oracle.com>
Message-ID: <be243e5c-68a6-d14b-b078-c8e4f9c15e08@oracle.com>

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>
 <c4e64bec-ba4a-62ac-3655-f2d3ba148ffb@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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
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: <dbe42596-bab2-8aeb-0245-8cad1fea608e@bell-sw.com>
 <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: <fac0ad2e-28a3-4817-cf1d-88a6fa84d990@oracle.com>

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: <b569e0a9-d404-0a9b-7a84-79609022b9d1@oracle.com>
References: <2c87f82f-d79c-6be9-a459-0849824f7f9f@oracle.com>
 <89d31dd3-6eeb-6727-b2db-59ee2e572b7b@oracle.com>
 <53c2c755-572f-c76e-5872-6bd6ed8914b8@oracle.com>
 <b569e0a9-d404-0a9b-7a84-79609022b9d1@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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
Message-ID: <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>

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: <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@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: <fac0ad2e-28a3-4817-cf1d-88a6fa84d990@oracle.com>
References: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com>
 <fac0ad2e-28a3-4817-cf1d-88a6fa84d990@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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
Message-ID: <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>

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: <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
 <f1aab753-fa7c-d021-7464-332dc065ead6@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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
 <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
 <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com>
Message-ID: <fb14321d-5152-979d-6694-ae37c833160d@oracle.com>

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: <A45E4796-4486-4E19-B0E4-3FD4260DC83E@oracle.com>


> 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: <f4139dc9-ef25-44ac-a31f-a848d6dc06c7@loongson.cn>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
 <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
 <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn>
 <CAEgw74DiEwrmeB=3JF2mGBzvaTc21mNh=TZ7MXgfc+86pbpDaA@mail.gmail.com>
 <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn>
 <f4139dc9-ef25-44ac-a31f-a848d6dc06c7@loongson.cn>
Message-ID: <CAEgw74BxYZuNJAZSRs44v_inzqZn5h0b=YUjwuBM0FnuQkZnpw@mail.gmail.com>

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 <fujie at loongson.cn> 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 <fujie at loongson.cn> 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 <fujie at loongson.cn> 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>
 <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>
 <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com>
 <ddf7d4cf-b28d-beca-0943-46cb63b0b77c@redhat.com>
 <AB536BE0-3339-47CF-B6FF-34CEF11FEF32@oracle.com>
 <acb6ef81-1320-0a09-66dc-2ec2283e9dcf@redhat.com>
 <F454DC46-EFBC-441D-8363-8148BF0BF904@oracle.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>
 <a221d477-28e6-e63c-952b-aa1eb1098cd5@oracle.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: <CAEgw74BxYZuNJAZSRs44v_inzqZn5h0b=YUjwuBM0FnuQkZnpw@mail.gmail.com>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
 <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
 <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn>
 <CAEgw74DiEwrmeB=3JF2mGBzvaTc21mNh=TZ7MXgfc+86pbpDaA@mail.gmail.com>
 <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn>
 <f4139dc9-ef25-44ac-a31f-a848d6dc06c7@loongson.cn>
 <CAEgw74BxYZuNJAZSRs44v_inzqZn5h0b=YUjwuBM0FnuQkZnpw@mail.gmail.com>
Message-ID: <CAEgw74Ds=bawuzhvz5KiUs0Sr2=UoonJ5Z7Ji=JZx=zFeLXfYg@mail.gmail.com>

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 <bsrbnd at gmail.com> 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 <fujie at loongson.cn> 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 <fujie at loongson.cn> 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 <fujie at loongson.cn> 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: <A45E4796-4486-4E19-B0E4-3FD4260DC83E@oracle.com>
References: <3633fc6c-38e7-3c83-af60-cefffe92cc89@oracle.com>
 <4e580971-e491-0c3e-4516-5011a9ae0f3c@oracle.com>
 <A45E4796-4486-4E19-B0E4-3FD4260DC83E@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 
>> <mailto: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: <fb14321d-5152-979d-6694-ae37c833160d@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
 <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
 <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com>
 <fb14321d-5152-979d-6694-ae37c833160d@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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
 <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
 <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com>
 <fb14321d-5152-979d-6694-ae37c833160d@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>
 <A45E4796-4486-4E19-B0E4-3FD4260DC83E@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 <mailto: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 <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://cr.openjdk.java.net/~kvn/8226566/webrev.00/>
>>>> https://bugs.openjdk.java.net/browse/JDK-8226566 <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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
 <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
 <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com>
 <fb14321d-5152-979d-6694-ae37c833160d@oracle.com>
 <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com>
 <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com>
Message-ID: <fdf26ab0-52c4-46c6-6ab1-887ea8c45e84@oracle.com>

+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: <f8e591c8-cbd0-d817-883c-f254df46d408@oracle.com>

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: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
 <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
 <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com>
 <fb14321d-5152-979d-6694-ae37c833160d@oracle.com>
 <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com>
 <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com>
Message-ID: <cc455f75-7ad0-90a9-3467-a700158a7aca@oracle.com>

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: <f8e591c8-cbd0-d817-883c-f254df46d408@oracle.com>
References: <f8e591c8-cbd0-d817-883c-f254df46d408@oracle.com>
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: <fdf26ab0-52c4-46c6-6ab1-887ea8c45e84@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
 <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
 <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com>
 <fb14321d-5152-979d-6694-ae37c833160d@oracle.com>
 <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com>
 <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com>
 <fdf26ab0-52c4-46c6-6ab1-887ea8c45e84@oracle.com>
Message-ID: <cb87d895-0c8b-4ac8-4dd0-52b4e5b29b00@oracle.com>

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: <cb87d895-0c8b-4ac8-4dd0-52b4e5b29b00@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
 <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
 <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com>
 <fb14321d-5152-979d-6694-ae37c833160d@oracle.com>
 <8527d9c7-c1c6-c85e-6abe-256d97c1c9fe@oracle.com>
 <46b3341a-0409-f981-3ca8-96d1fd0740c0@oracle.com>
 <fdf26ab0-52c4-46c6-6ab1-887ea8c45e84@oracle.com>
 <cb87d895-0c8b-4ac8-4dd0-52b4e5b29b00@oracle.com>
Message-ID: <FAD471BF-1A4F-453E-B0FE-83428CA12463@oracle.com>

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: <f8e591c8-cbd0-d817-883c-f254df46d408@oracle.com>
 <5b74285b-7649-5c45-5b46-c2032d5bf2e5@oracle.com>
Message-ID: <ceb86326-3314-18da-6432-8bedfbad67df@oracle.com>

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: <f8e591c8-cbd0-d817-883c-f254df46d408@oracle.com>
References: <f8e591c8-cbd0-d817-883c-f254df46d408@oracle.com>
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: <f8e591c8-cbd0-d817-883c-f254df46d408@oracle.com>
 <367eaac1-4af5-4753-c47d-d0eac23c0d51@oracle.com>
Message-ID: <a53c1bc5-61a4-d485-d937-5a46bbd4916a@oracle.com>

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: <CAEgw74Ds=bawuzhvz5KiUs0Sr2=UoonJ5Z7Ji=JZx=zFeLXfYg@mail.gmail.com>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
 <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
 <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn>
 <CAEgw74DiEwrmeB=3JF2mGBzvaTc21mNh=TZ7MXgfc+86pbpDaA@mail.gmail.com>
 <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn>
 <f4139dc9-ef25-44ac-a31f-a848d6dc06c7@loongson.cn>
 <CAEgw74BxYZuNJAZSRs44v_inzqZn5h0b=YUjwuBM0FnuQkZnpw@mail.gmail.com>
 <CAEgw74Ds=bawuzhvz5KiUs0Sr2=UoonJ5Z7Ji=JZx=zFeLXfYg@mail.gmail.com>
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: <e29f94f8-1fb9-2756-9852-6fdd953bf3f6@oracle.com>
References: <f8e591c8-cbd0-d817-883c-f254df46d408@oracle.com>
 <3bb094a7-b18e-569d-bd5b-998ca6a2d1ba@oracle.com>
 <e29f94f8-1fb9-2756-9852-6fdd953bf3f6@oracle.com>
Message-ID: <ea131a6e-0e01-5dfd-fe87-df485da97bc6@oracle.com>

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 
> <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: <CAEgw74BxYZuNJAZSRs44v_inzqZn5h0b=YUjwuBM0FnuQkZnpw@mail.gmail.com>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
 <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
 <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn>
 <CAEgw74DiEwrmeB=3JF2mGBzvaTc21mNh=TZ7MXgfc+86pbpDaA@mail.gmail.com>
 <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn>
 <f4139dc9-ef25-44ac-a31f-a848d6dc06c7@loongson.cn>
 <CAEgw74BxYZuNJAZSRs44v_inzqZn5h0b=YUjwuBM0FnuQkZnpw@mail.gmail.com>
Message-ID: <b879dc3a-8ba2-0f2c-fc9c-b935debefd6a@oracle.com>


> 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 <fujie at loongson.cn> 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 <fujie at loongson.cn> 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 <fujie at loongson.cn> 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: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>

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: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
Message-ID: <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>

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: <b879dc3a-8ba2-0f2c-fc9c-b935debefd6a@oracle.com>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
 <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
 <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn>
 <CAEgw74DiEwrmeB=3JF2mGBzvaTc21mNh=TZ7MXgfc+86pbpDaA@mail.gmail.com>
 <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn>
 <f4139dc9-ef25-44ac-a31f-a848d6dc06c7@loongson.cn>
 <CAEgw74BxYZuNJAZSRs44v_inzqZn5h0b=YUjwuBM0FnuQkZnpw@mail.gmail.com>
 <b879dc3a-8ba2-0f2c-fc9c-b935debefd6a@oracle.com>
Message-ID: <CAEgw74Af9_njfyDr04MfH5Jfv35Q8GbiBP6pfvj+5pXk4ZOGQw@mail.gmail.com>

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
<vladimir.x.ivanov at oracle.com> 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: <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
Message-ID: <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>

Oops. Fixed.
/Jesper

> On 25 Jun 2019, at 21:57, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
 <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>
Message-ID: <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>

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 <vladimir.kozlov at oracle.com> 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: <CAEgw74Af9_njfyDr04MfH5Jfv35Q8GbiBP6pfvj+5pXk4ZOGQw@mail.gmail.com>
References: <c71f5a36-11dd-d7cb-6843-010bd7cd45f2@loongson.cn>
 <eea35231-665d-d922-64a5-aee4dbe5739b@oracle.com>
 <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn>
 <CAEgw74DWYihKUHpBL4MH-o4CVm9J17qB+OMD+bJMsCt=JYW-iA@mail.gmail.com>
 <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn>
 <CAEgw74DiEwrmeB=3JF2mGBzvaTc21mNh=TZ7MXgfc+86pbpDaA@mail.gmail.com>
 <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn>
 <f4139dc9-ef25-44ac-a31f-a848d6dc06c7@loongson.cn>
 <CAEgw74BxYZuNJAZSRs44v_inzqZn5h0b=YUjwuBM0FnuQkZnpw@mail.gmail.com>
 <b879dc3a-8ba2-0f2c-fc9c-b935debefd6a@oracle.com>
 <CAEgw74Af9_njfyDr04MfH5Jfv35Q8GbiBP6pfvj+5pXk4ZOGQw@mail.gmail.com>
Message-ID: <b76d3d72-2078-2fc3-dd62-68c5637a97d2@loongson.cn>

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: <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
 <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>
 <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>
Message-ID: <AFA7180F-017F-4340-A513-189CBB443D19@oracle.com>

This is a webrev based on JDK 13: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/ <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 <vladimir.kozlov at oracle.com> 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 <vladimir.kozlov at oracle.com> 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: <a916d261-ad1f-29e9-511d-dc80e68286ef@oracle.com>


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: <a916d261-ad1f-29e9-511d-dc80e68286ef@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> <a916d261-ad1f-29e9-511d-dc80e68286ef@oracle.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> <a916d261-ad1f-29e9-511d-dc80e68286ef@oracle.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> <a916d261-ad1f-29e9-511d-dc80e68286ef@oracle.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: <b85c72fc-542c-4a5c-f9d5-5fe8cd29af34@oracle.com>

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<ciKlass*> _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<ciKlass*>* 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<ciKlass*>::insert_sorted<&TypePtr::InterfaceSet::compare>(ciKlass*const&).
src/hotspot/share/opto/type.cpp, line 2977:     Where, temwhileinst: 
While instantiating "ciKlass* 
GrowableArray<ciKlass*>::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<ciKlass*>::insert_sorted<&TypePtr::InterfaceSet::compare>(ciKlass*const&).
src/hotspot/share/opto/type.cpp, line 2977:     Where, temwhileinst: 
While instantiating "ciKlass* 
GrowableArray<ciKlass*>::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: <AFA7180F-017F-4340-A513-189CBB443D19@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
 <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>
 <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>
 <AFA7180F-017F-4340-A513-189CBB443D19@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/ <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 <vladimir.kozlov at oracle.com> 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 <vladimir.kozlov at oracle.com> 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: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
 <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>
 <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>
 <AFA7180F-017F-4340-A513-189CBB443D19@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 <vladimir.kozlov at oracle.com> 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/ <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 <vladimir.kozlov at oracle.com> 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 <vladimir.kozlov at oracle.com> 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' <vladimir.kozlov at oracle.com>; Anthony Scarpino <anthony.scarpino at oracle.com>
Cc: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Shravya Rukmannagari (shravya.rukmannagari at intel.com) <shravya.rukmannagari at intel.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; Shemy, Regev <regev.shemy at intel.com>
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<mailto:shay.gueron at intel.com>) and Regev Shemy (regev.shemy at intel.com<mailto: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: <b85c72fc-542c-4a5c-f9d5-5fe8cd29af34@oracle.com>
References: <87ftp9l5cy.fsf@redhat.com>
 <b85c72fc-542c-4a5c-f9d5-5fe8cd29af34@oracle.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: <f7b0f051-50b2-27b5-33f0-b63dc1490f5f@oracle.com>

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>
 <b85c72fc-542c-4a5c-f9d5-5fe8cd29af34@oracle.com> <87d0izbfuk.fsf@redhat.com>
Message-ID: <b07aa089-374f-ce7c-8990-a0bcc9dc3a10@oracle.com>

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::<init> (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: <mailman.35.1561636851.24829.hotspot-compiler-dev@openjdk.java.net>
References: <mailman.35.1561636851.24829.hotspot-compiler-dev@openjdk.java.net>
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 <rwestrel at redhat.com>
> To: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>,
> 	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: <f7b0f051-50b2-27b5-33f0-b63dc1490f5f@oracle.com>
References: <f7b0f051-50b2-27b5-33f0-b63dc1490f5f@oracle.com>
Message-ID: <2D3C1E6A-BA0C-4FBE-9F43-21E277E9EAC7@oracle.com>

Good.

Thanks
Vladimir

> On Jun 27, 2019, at 2:02 AM, Tobias Hartmann <tobias.hartmann at oracle.com> 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 <igor.ignatyev at oracle.com> 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: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>

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: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>
References: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>
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: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>
 <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: <f7b0f051-50b2-27b5-33f0-b63dc1490f5f@oracle.com>
 <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 <tobias.hartmann at oracle.com> 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> <a916d261-ad1f-29e9-511d-dc80e68286ef@oracle.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> <a916d261-ad1f-29e9-511d-dc80e68286ef@oracle.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> <a916d261-ad1f-29e9-511d-dc80e68286ef@oracle.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: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>
 <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com>
Message-ID: <a53d19d4-0712-8ad1-1c41-0600816da19c@oracle.com>

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: <FC877FE2-5387-4730-8032-5FF3C8B4620D@oracle.com>

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/ <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: <FC877FE2-5387-4730-8032-5FF3C8B4620D@oracle.com>
References: <FC877FE2-5387-4730-8032-5FF3C8B4620D@oracle.com>
Message-ID: <ac93c75a-2b38-7d7b-5725-1149ad9a4372@oracle.com>

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/ <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: <ac93c75a-2b38-7d7b-5725-1149ad9a4372@oracle.com>
References: <FC877FE2-5387-4730-8032-5FF3C8B4620D@oracle.com>
 <ac93c75a-2b38-7d7b-5725-1149ad9a4372@oracle.com>
Message-ID: <CE6A2576-764C-492B-8BA1-E172D6EF78E4@oracle.com>

Thanks, Vladimir!

igor



> On Jun 28, 2019, at 8:53 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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/ <http://cr.openjdk.java.net/~iveresov/8226778/webrev.00/>
>> Thanks!
>> igor