From erik.joelsson at oracle.com  Thu Jan  2 07:57:07 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 2 Jan 2020 08:57:07 +0100
Subject: <AWT Dev> [15] Review Request: 8235975 Update copyright year to
 match last edit in jdk repository for 2014/15/16/17/18
In-Reply-To: <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com>
References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com>
 <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com>
Message-ID: <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com>

Build files look good.

/Erik

On 2019-12-24 19:22, Sergey Bylokhov wrote:
> Hello.
>
> Here is an updated version:
> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
> ? Patch (2 Mb): 
> http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch
> ? Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/
>
> ?- "jdk.internal.vm.compiler" is removed from the patch.
> ?- "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018"
>
> On 12/22/19 11:24 pm, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for JDK 15.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
>> Patch (2 Mb): 
>> http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch
>> Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02
>>
>> I have updated the source code copyrights by the 
>> "update_copyright_year.sh"
>> script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017
>> because of: "JDK-8187443: Forest Consolidation: Move files to unified 
>> layout"
>> which touched all files.
>>
>>
>
>

From Sergey.Bylokhov at oracle.com  Thu Jan  2 12:02:14 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 2 Jan 2020 15:02:14 +0300
Subject: <AWT Dev> [15] Review Request: 8235975 Update copyright year to
 match last edit in jdk repository for 2014/15/16/17/18
In-Reply-To: <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com>
References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com>
 <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com>
 <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com>
Message-ID: <0caab700-28e3-16e7-db00-b698557443f0@oracle.com>

I guess it is too late to fix it, will need to update the files at the end of 2020.

On 1/2/20 10:57 am, Erik Joelsson wrote:
> Build files look good.
> 
> /Erik
> 
> On 2019-12-24 19:22, Sergey Bylokhov wrote:
>> Hello.
>>
>> Here is an updated version:
>> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
>> ? Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch
>> ? Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/
>>
>> ?- "jdk.internal.vm.compiler" is removed from the patch.
>> ?- "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018"
>>
>> On 12/22/19 11:24 pm, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for JDK 15.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
>>> Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch
>>> Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02
>>>
>>> I have updated the source code copyrights by the "update_copyright_year.sh"
>>> script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017
>>> because of: "JDK-8187443: Forest Consolidation: Move files to unified layout"
>>> which touched all files.
>>>
>>>
>>
>>


-- 
Best regards, Sergey.

From igor.veresov at oracle.com  Thu Jan  2 15:00:48 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 2 Jan 2020 07:00:48 -0800
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
Message-ID: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>

Webrev: http://cr.openjdk.java.net/~iveresov/8236050/webrev.00 <http://cr.openjdk.java.net/~iveresov/8236050/webrev.00>

This change makes the TieredStopAtLevel processing aware of various compilation modes.

Thanks!
igor




From vladimir.x.ivanov at oracle.com  Thu Jan  2 23:16:00 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 3 Jan 2020 02:16:00 +0300
Subject: [14] RFR(S): 8236443 : Issues with specializing vector register
 type for phi operand with generic operands
In-Reply-To: <A66BBE673E08E1428E3A918AE4D5B32C0A0E2114@BGSMSX106.gar.corp.intel.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A0E2114@BGSMSX106.gar.corp.intel.com>
Message-ID: <be1bfe15-8512-4e8b-774f-a3b3544ad1ce@oracle.com>

Hi Jatin,

> Webrev: http://cr.openjdk.java.net/~jbhateja/8236443/webrev.02/

I like that you put the check on use side (ShiftV + ideal_in_idx).

Though ShiftCntV def is the only viable option in practice (phis 
shouldn't occur on x86 and would trigger a bug due to mismatch between 
node type and ideal_reg), it's nice to see such case being ruled out.

Some comments:

=======================================================================
src/hotspot/cpu/x86/x86.ad:

+const uint Matcher::special_vector_ideal_reg(int ideal_reg, int opcode, 
int ideal_in_idx, int size) {

I don't see a compelling reason why it should be a platform-specific 
check. ShiftCntV nodes override Node::ideal_reg() and putting the check 
in shared code looks appropriate.

Considering how LShiftCntVNode::ideal_reg is defined [1], IMO calling 
Matcher::vector_shift_count_ideal_reg(t->length_in_bytes()) is better 
than hardcoding VecS ideal register (which is x86-specific).


=======================================================================
+    case Op_RShiftCntV:
+    case Op_LShiftCntV:
+      // Ideal index corrosponding to def operand.
+      if (ideal_in_idx == -1)
+        return Op_VecS;
+      break;

Shouldn't ideal_in_idx be 0 instead?


Some stylistic notes:

=======================================================================
src/hotspot/cpu/x86/x86.ad:

+MachOper* Matcher::specialize_vector_operand_helper(Node* m, MachNode* 
n, int op_idx) {

It's a bit confusing to see Node* named "m" and MachNode* named "n". In 
the code base it's usually the opposite: n stands for Node and m stands 
for MachNode.

But maybe "def" and "use" are better names?


=======================================================================

+  switch(opcode) {
+    default:
+      return ideal_reg;
+    case Op_LShiftVB:
...
+    case Op_URShiftVL:
+      if (ideal_in_idx == 2)
+        return Op_VecS;
+      break;
+    case Op_RShiftCntV:
+    case Op_LShiftCntV:
+      // Ideal index corrosponding to def operand.
+      if (ideal_in_idx == -1)
+        return Op_VecS;
+      break;
+  }

Does it make sense to introduce ShiftV and ShiftCntV node classes [2] 
and use Node::is_ShiftV()/is_ShiftCntV() checks instead?

=======================================================================

+  switch(opcode) {
+    default:
+      return ideal_reg;
...
+  }
+  return ideal_reg;

return statement is redundant.


=======================================================================

src/hotspot/share/opto/matcher.cpp:

-    MachNode* m = live_nodes.pop()->isa_Mach();
+    Node* n = live_nodes.pop();
+    if (!n->is_Mach())
+      continue;
+    MachNode * m = n->as_Mach();
      if (m != NULL) {


Node::isa_Mach() + != NULL check is a well-established convention in C2 
code base to perform type checks on nodes (is_Mach()+as_Mach()). I'd 
prefer to keep the original version.

Best regards,
Vladimir Ivanov

[1] class LShiftCntVNode : public VectorNode {
       virtual uint ideal_reg() const { return 
Matcher::vector_shift_count_ideal_reg(vect_type()->length_in_bytes()); }
     };

[2] 
http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/node.hpp#l716

> Generic operand processing has been skipped for non-machine nodes (e.g. Phi) since they are skipped by the matcher.
> Non-definition operand resolution of a machine node will be able to pull the type information from non-machine node.
> 
> Re-organized the code by adding a target specific routine which can be used to return the operand types for special ideal nodes e.g. RShiftCntV/LShiftCntV.
> For such nodes, definition machine operand vary for different targets and vector lengths, a type based generic operand resolution
> is not possible in such cases.
> 
> Best Regards,
> Jatin
> 
> 

From claes.redestad at oracle.com  Fri Jan  3 10:53:25 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 3 Jan 2020 11:53:25 +0100
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
Message-ID: <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>

Hi,

logic in limit_level is a bit hard to follow. In case TieredStopAtLevel
is 4, level is 2 or 3 and compilation mode is high-only or high-only-
quick-internal it seems it'll return level, which is an invalid level
for the compilation mode..?

/Claes

On 2020-01-02 16:00, Igor Veresov wrote:
> Webrev: http://cr.openjdk.java.net/~iveresov/8236050/webrev.00 <http://cr.openjdk.java.net/~iveresov/8236050/webrev.00>
> 
> This change makes the TieredStopAtLevel processing aware of various compilation modes.
> 
> Thanks!
> igor
> 
> 
> 

From igor.veresov at oracle.com  Fri Jan  3 15:16:59 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 3 Jan 2020 07:16:59 -0800
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
 <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
Message-ID: <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>

That?s not a problem, the level argument is always valid. The case this change is fixing is the situation when the level needs to be changed due to TieredStopAtLevel (i.e. when level > TieredStopAtLevel).

igor

> On Jan 3, 2020, at 2:53 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> logic in limit_level is a bit hard to follow. In case TieredStopAtLevel
> is 4, level is 2 or 3 and compilation mode is high-only or high-only-
> quick-internal it seems it'll return level, which is an invalid level
> for the compilation mode..?
> 
> /Claes
> 
> On 2020-01-02 16:00, Igor Veresov wrote:
>> Webrev: http://cr.openjdk.java.net/~iveresov/8236050/webrev.00 <http://cr.openjdk.java.net/~iveresov/8236050/webrev.00>
>> This change makes the TieredStopAtLevel processing aware of various compilation modes.
>> Thanks!
>> igor


From claes.redestad at oracle.com  Fri Jan  3 15:44:01 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 3 Jan 2020 16:44:01 +0100
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
 <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
 <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>
Message-ID: <474c5c62-6679-3ddb-0fc8-06ebc03f76bf@oracle.com>

Right, it seemed to be the case, but I couldn't conclude it by reading
the surrounding/calling code. That's why I commented that the logic is a
bit hard to follow. :-)

I think an assert that the level argument is always valid would be a
sufficient guide here.

/Claes

On 2020-01-03 16:16, Igor Veresov wrote:
> That?s not a problem, the level argument is always valid. The case this change is fixing is the situation when the level needs to be changed due to TieredStopAtLevel (i.e. when level > TieredStopAtLevel).
> 
> igor
> 
>> On Jan 3, 2020, at 2:53 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> logic in limit_level is a bit hard to follow. In case TieredStopAtLevel
>> is 4, level is 2 or 3 and compilation mode is high-only or high-only-
>> quick-internal it seems it'll return level, which is an invalid level
>> for the compilation mode..?
>>
>> /Claes
>>
>> On 2020-01-02 16:00, Igor Veresov wrote:
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8236050/webrev.00 <http://cr.openjdk.java.net/~iveresov/8236050/webrev.00>
>>> This change makes the TieredStopAtLevel processing aware of various compilation modes.
>>> Thanks!
>>> igor
> 

From goetz.lindenmaier at sap.com  Fri Jan  3 16:32:33 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 3 Jan 2020 16:32:33 +0000
Subject: Help with downporting 8225019: Update JVMCI
Message-ID: <VE1PR02MB5422C0155A40F8C742099109EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi,

I am working on downporting 11.0.7-oracle fixes to OpenJDK
11.0.7.

I encountered "8225019: Update JVMCI" which is applying badly. 
It has lots of rejects. There are various places that are not
 trivial to resolve.

I don't have any background in JVMCI/AOT and SAP does
not use it (yet).
I would appreciate if someone with appropriate background
or interest could step up and bring this change to jdk11u-dev.

https://bugs.openjdk.java.net/browse/JDK-8225019
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/034050.html

Best regards,
  Goetz.

From matthias.baesken at sap.com  Fri Jan  3 15:49:11 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 3 Jan 2020 15:49:11 +0000
Subject: struct SwitchRange  and  C++ One Definition Rule [-Wodr]
Message-ID: <AM6PR02MB4200AECFEA11F6E16864ED9693230@AM6PR02MB4200.eurprd02.prod.outlook.com>

Hello,  when  experimenting  with  gcc8  and   the -flto compiler flag I was running into these  warnings  in the c1  coding :


/open_jdk/jdk_3/jdk/src/hotspot/share/c1/c1_LIRGenerator.hpp:50:7: warning: type 'struct SwitchRange' violates the C++ One Definition Rule [-Wodr]
class SwitchRange: public CompilationResourceObj {
       ^
/open_jdk/jdk_3/jdk/src/hotspot/share/opto/parse2.cpp:319: note: a different type is defined in another translation unit
class SwitchRange : public StackObj {

/usr/work/d040975/open_jdk/jdk_3/jdk/src/hotspot/share/c1/c1_LIRGenerator.hpp:52:7: note: the first difference of corresponding definitions is field '_low_key'
   int _low_key;
       ^
/open_jdk/jdk_3/jdk/src/hotspot/share/opto/parse2.cpp:321: note: a field with different name is defined in another translation unit
   jint _lo;                     // inclusive lower limit



Do  you think this should be fixed ( renaming  one SwitchRange  ) ?

Martin suggested that  even without  flto added   it could be problematic .


Thanks, Matthias

From kim.barrett at oracle.com  Fri Jan  3 19:12:52 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 3 Jan 2020 14:12:52 -0500
Subject: struct SwitchRange  and  C++ One Definition Rule [-Wodr]
In-Reply-To: <AM6PR02MB4200AECFEA11F6E16864ED9693230@AM6PR02MB4200.eurprd02.prod.outlook.com>
References: <AM6PR02MB4200AECFEA11F6E16864ED9693230@AM6PR02MB4200.eurprd02.prod.outlook.com>
Message-ID: <8EF4DC8C-37C0-4E17-AE92-2F2C8DD3869B@oracle.com>

> On Jan 3, 2020, at 10:49 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hello,  when  experimenting  with  gcc8  and   the -flto compiler flag I was running into these  warnings  in the c1  coding :
>  
>  
> /open_jdk/jdk_3/jdk/src/hotspot/share/c1/c1_LIRGenerator.hpp:50:7: warning: type 'struct SwitchRange' violates the C++ One Definition Rule [-Wodr]
> class SwitchRange: public CompilationResourceObj {
>        ^
> /open_jdk/jdk_3/jdk/src/hotspot/share/opto/parse2.cpp:319: note: a different type is defined in another translation unit
> class SwitchRange : public StackObj {
>  
> /usr/work/d040975/open_jdk/jdk_3/jdk/src/hotspot/share/c1/c1_LIRGenerator.hpp:52:7: note: the first difference of corresponding definitions is field '_low_key'
>    int _low_key;
>        ^
> /open_jdk/jdk_3/jdk/src/hotspot/share/opto/parse2.cpp:321: note: a field with different name is defined in another translation unit
>    jint _lo;                     // inclusive lower limit
>  
>  
>  
> Do  you think this should be fixed ( renaming  one SwitchRange  ) ?
> 

> Martin suggested that  even without  flto added   it could be problematic .

Yes, please file a bug and let's get this fixed quickly.  This sort of thing can lead
to really weird looking problems, like using the same vtable (which one picked
?at random?) for instances of both classes.


From igor.veresov at oracle.com  Sat Jan  4 00:28:22 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 3 Jan 2020 16:28:22 -0800
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <474c5c62-6679-3ddb-0fc8-06ebc03f76bf@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
 <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
 <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>
 <474c5c62-6679-3ddb-0fc8-06ebc03f76bf@oracle.com>
Message-ID: <58742AC8-84BD-425F-A64A-9CAA93DBD5A3@oracle.com>

Ok, we can add some verification: http://cr.openjdk.java.net/~iveresov/8236050/webrev.01/

igor



> On Jan 3, 2020, at 7:44 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Right, it seemed to be the case, but I couldn't conclude it by reading
> the surrounding/calling code. That's why I commented that the logic is a
> bit hard to follow. :-)
> 
> I think an assert that the level argument is always valid would be a
> sufficient guide here.
> 
> /Claes
> 
> On 2020-01-03 16:16, Igor Veresov wrote:
>> That?s not a problem, the level argument is always valid. The case this change is fixing is the situation when the level needs to be changed due to TieredStopAtLevel (i.e. when level > TieredStopAtLevel).
>> igor
>>> On Jan 3, 2020, at 2:53 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> logic in limit_level is a bit hard to follow. In case TieredStopAtLevel
>>> is 4, level is 2 or 3 and compilation mode is high-only or high-only-
>>> quick-internal it seems it'll return level, which is an invalid level
>>> for the compilation mode..?
>>> 
>>> /Claes
>>> 
>>> On 2020-01-02 16:00, Igor Veresov wrote:
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8236050/webrev.00 <http://cr.openjdk.java.net/~iveresov/8236050/webrev.00>
>>>> This change makes the TieredStopAtLevel processing aware of various compilation modes.
>>>> Thanks!
>>>> igor


From claes.redestad at oracle.com  Sat Jan  4 00:43:50 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 4 Jan 2020 01:43:50 +0100
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <58742AC8-84BD-425F-A64A-9CAA93DBD5A3@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
 <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
 <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>
 <474c5c62-6679-3ddb-0fc8-06ebc03f76bf@oracle.com>
 <58742AC8-84BD-425F-A64A-9CAA93DBD5A3@oracle.com>
Message-ID: <bb1c3d25-96d0-13d2-cbc0-1a103f49f2ae@oracle.com>

Thanks, looks good to me!

/Claes

On 2020-01-04 01:28, Igor Veresov wrote:
> Ok, we can add some verification: 
> http://cr.openjdk.java.net/~iveresov/8236050/webrev.01/
> 
> igor
> 
> 
> 
>> On Jan 3, 2020, at 7:44 AM, Claes Redestad <claes.redestad at oracle.com 
>> <mailto:claes.redestad at oracle.com>> wrote:
>>
>> Right, it seemed to be the case, but I couldn't conclude it by reading
>> the surrounding/calling code. That's why I commented that the logic is a
>> bit hard to follow. :-)
>>
>> I think an assert that the level argument is always valid would be a
>> sufficient guide here.
>>
>> /Claes
>>
>> On 2020-01-03 16:16, Igor Veresov wrote:
>>> That?s not a problem, the level argument is always valid. The case 
>>> this change is fixing is the situation when the level needs to be 
>>> changed due to TieredStopAtLevel (i.e. when level > TieredStopAtLevel).
>>> igor
>>>> On Jan 3, 2020, at 2:53 AM, Claes Redestad 
>>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> logic in limit_level is a bit hard to follow. In case TieredStopAtLevel
>>>> is 4, level is 2 or 3 and compilation mode is high-only or high-only-
>>>> quick-internal it seems it'll return level, which is an invalid level
>>>> for the compilation mode..?
>>>>
>>>> /Claes
>>>>
>>>> On 2020-01-02 16:00, Igor Veresov wrote:
>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8236050/webrev.00 
>>>>> <http://cr.openjdk.java.net/~iveresov/8236050/webrev.00>
>>>>> This change makes the TieredStopAtLevel processing aware of various 
>>>>> compilation modes.
>>>>> Thanks!
>>>>> igor
> 

From igor.veresov at oracle.com  Sun Jan  5 02:25:43 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Sat, 4 Jan 2020 18:25:43 -0800
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <bb1c3d25-96d0-13d2-cbc0-1a103f49f2ae@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
 <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
 <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>
 <474c5c62-6679-3ddb-0fc8-06ebc03f76bf@oracle.com>
 <58742AC8-84BD-425F-A64A-9CAA93DBD5A3@oracle.com>
 <bb1c3d25-96d0-13d2-cbc0-1a103f49f2ae@oracle.com>
Message-ID: <8F745069-EAAE-4120-9577-8AEDA5A8EDCA@oracle.com>

Actually, the verification found a problem with how the compilation levels are chosen in case of -Xcomp. 
So I had to fix that: http://cr.openjdk.java.net/~iveresov/8236050/webrev.02/

igor



> On Jan 3, 2020, at 4:43 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Thanks, looks good to me!
> 
> /Claes
> 
> On 2020-01-04 01:28, Igor Veresov wrote:
>> Ok, we can add some verification: http://cr.openjdk.java.net/~iveresov/8236050/webrev.01/
>> igor
>>> On Jan 3, 2020, at 7:44 AM, Claes Redestad <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>> 
>>> Right, it seemed to be the case, but I couldn't conclude it by reading
>>> the surrounding/calling code. That's why I commented that the logic is a
>>> bit hard to follow. :-)
>>> 
>>> I think an assert that the level argument is always valid would be a
>>> sufficient guide here.
>>> 
>>> /Claes
>>> 
>>> On 2020-01-03 16:16, Igor Veresov wrote:
>>>> That?s not a problem, the level argument is always valid. The case this change is fixing is the situation when the level needs to be changed due to TieredStopAtLevel (i.e. when level > TieredStopAtLevel).
>>>> igor
>>>>> On Jan 3, 2020, at 2:53 AM, Claes Redestad <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> logic in limit_level is a bit hard to follow. In case TieredStopAtLevel
>>>>> is 4, level is 2 or 3 and compilation mode is high-only or high-only-
>>>>> quick-internal it seems it'll return level, which is an invalid level
>>>>> for the compilation mode..?
>>>>> 
>>>>> /Claes
>>>>> 
>>>>> On 2020-01-02 16:00, Igor Veresov wrote:
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8236050/webrev.00 <http://cr.openjdk.java.net/~iveresov/8236050/webrev.00>
>>>>>> This change makes the TieredStopAtLevel processing aware of various compilation modes.
>>>>>> Thanks!
>>>>>> igor


From tobias.hartmann at oracle.com  Mon Jan  6 07:20:57 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 6 Jan 2020 08:20:57 +0100
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <8F745069-EAAE-4120-9577-8AEDA5A8EDCA@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
 <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
 <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>
 <474c5c62-6679-3ddb-0fc8-06ebc03f76bf@oracle.com>
 <58742AC8-84BD-425F-A64A-9CAA93DBD5A3@oracle.com>
 <bb1c3d25-96d0-13d2-cbc0-1a103f49f2ae@oracle.com>
 <8F745069-EAAE-4120-9577-8AEDA5A8EDCA@oracle.com>
Message-ID: <1e4fb10a-2462-f43d-2ae6-2479f45daae9@oracle.com>

Hi Igor,

On 05.01.20 03:25, Igor Veresov wrote:
> Actually, the verification found a problem with how the compilation levels are chosen in case of -Xcomp. 
> So I had to fix that: http://cr.openjdk.java.net/~iveresov/8236050/webrev.02/

Looks good to me. Maybe adding a test such that we catch similar problems before ATR would be good.

Best regards,
Tobias

From igor.veresov at oracle.com  Mon Jan  6 18:47:18 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Mon, 6 Jan 2020 10:47:18 -0800
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <1e4fb10a-2462-f43d-2ae6-2479f45daae9@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
 <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
 <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>
 <474c5c62-6679-3ddb-0fc8-06ebc03f76bf@oracle.com>
 <58742AC8-84BD-425F-A64A-9CAA93DBD5A3@oracle.com>
 <bb1c3d25-96d0-13d2-cbc0-1a103f49f2ae@oracle.com>
 <8F745069-EAAE-4120-9577-8AEDA5A8EDCA@oracle.com>
 <1e4fb10a-2462-f43d-2ae6-2479f45daae9@oracle.com>
Message-ID: <C7F5F9D1-9775-467A-BFE2-A9EA1F60F892@oracle.com>



> On Jan 5, 2020, at 11:20 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi Igor,
> 
> On 05.01.20 03:25, Igor Veresov wrote:
>> Actually, the verification found a problem with how the compilation levels are chosen in case of -Xcomp. 
>> So I had to fix that: http://cr.openjdk.java.net/~iveresov/8236050/webrev.02/
> 
> Looks good to me. Maybe adding a test such that we catch similar problems before ATR would be good.
> 

Sure thing. A quick test added: http://cr.openjdk.java.net/~iveresov/8236050/webrev.03/ <http://cr.openjdk.java.net/~iveresov/8236050/webrev.03/>

Thanks,
Igor


> Best regards,
> Tobias


From tobias.hartmann at oracle.com  Tue Jan  7 07:31:23 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 7 Jan 2020 08:31:23 +0100
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <C7F5F9D1-9775-467A-BFE2-A9EA1F60F892@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
 <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
 <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>
 <474c5c62-6679-3ddb-0fc8-06ebc03f76bf@oracle.com>
 <58742AC8-84BD-425F-A64A-9CAA93DBD5A3@oracle.com>
 <bb1c3d25-96d0-13d2-cbc0-1a103f49f2ae@oracle.com>
 <8F745069-EAAE-4120-9577-8AEDA5A8EDCA@oracle.com>
 <1e4fb10a-2462-f43d-2ae6-2479f45daae9@oracle.com>
 <C7F5F9D1-9775-467A-BFE2-A9EA1F60F892@oracle.com>
Message-ID: <7707d1d8-d5b0-7af1-877c-8fd0ffa5c84b@oracle.com>


On 06.01.20 19:47, Igor Veresov wrote:
> Sure thing. A quick test added:?http://cr.openjdk.java.net/~iveresov/8236050/webrev.03/

Looks good, thanks for adding!

Best regards,
Tobias

From tobias.hartmann at oracle.com  Tue Jan  7 07:44:33 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 7 Jan 2020 08:44:33 +0100
Subject: RFR: 8236181: C2: Remove useless step_over_gc_barrier() in
 int->bool conversion
In-Reply-To: <e3e4214e-4ee9-99ca-3a8f-2dd789f1713b@redhat.com>
References: <e3e4214e-4ee9-99ca-3a8f-2dd789f1713b@redhat.com>
Message-ID: <c551719a-5fda-6c77-63fa-26066b323427@oracle.com>

Hi Roman,

this looks good to me.

Best regards,
Tobias

On 18.12.19 13:40, Roman Kennke wrote:
> In cfgnode.cpp, in is_x2logic() that converts a diamond-shape if/else to simple bool patterns, we
> have a step_over_gc_barrier() at the end. This has been introduced by Shenandoah. I believe the
> intention was to convert obj vs null check to a simple boolean expression and eliminate the barrier
> on the unneeded path. However, it is not needed because Shenandoah we already eliminate barriers
> when the only user is a null-check, and it might actually be counter-productive if the barrier is
> needed on other paths, because it keeps the input of the barrier alive. This is probably a left-over
> from pre-LRB.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8236181
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8236181/webrev.00/
> 
> Testing: hotspot_gc_shenandoah, submit-repo (in-progress)
> 
> Can I please get a review?
> 
> Thanks,
> Roman
> 

From christian.hagedorn at oracle.com  Tue Jan  7 11:53:27 2020
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Tue, 7 Jan 2020 12:53:27 +0100
Subject: [14] RFR(XS): 8236140: assert(!VerifyHashTableKeys || _hash_lock ==
 0) failed: remove node from hash table before modifying it
Message-ID: <2d1fd1d5-dfaa-a1d3-3b18-c0e9f0a58a01@oracle.com>

Hi

Please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8236140
http://cr.openjdk.java.net/~chagedorn/8236140/webrev.00/

An input of the StoreL node in the test case was set without rehashing 
the store which triggers the assertion failure.

Thank you!

Best regards,
Christian

From rwestrel at redhat.com  Tue Jan  7 12:07:33 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 07 Jan 2020 13:07:33 +0100
Subject: RFR: 8236181: C2: Remove useless step_over_gc_barrier() in
 int->bool conversion
In-Reply-To: <e3e4214e-4ee9-99ca-3a8f-2dd789f1713b@redhat.com>
References: <e3e4214e-4ee9-99ca-3a8f-2dd789f1713b@redhat.com>
Message-ID: <875zhn79mi.fsf@redhat.com>


> However, it is not needed because Shenandoah we already eliminate
> barriers when the only user is a null-check, and it might actually be
> counter-productive if the barrier is needed on other paths, because it
> keeps the input of the barrier alive. This is probably a left-over
> from pre-LRB.

I'm not sure this is useless. If this triggers during igvn, it could be
that the Phi is processed before the CmpP and so the barrier at the CmpP
has no chance of being eliminated. Anyway, this is also likely uncommon
so I'm fine with removing it.

Roland.


From matthias.baesken at sap.com  Tue Jan  7 07:54:44 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 7 Jan 2020 07:54:44 +0000
Subject: struct SwitchRange  and  C++ One Definition Rule [-Wodr]
In-Reply-To: <8EF4DC8C-37C0-4E17-AE92-2F2C8DD3869B@oracle.com>
References: <AM6PR02MB4200AECFEA11F6E16864ED9693230@AM6PR02MB4200.eurprd02.prod.outlook.com>
 <8EF4DC8C-37C0-4E17-AE92-2F2C8DD3869B@oracle.com>
Message-ID: <AM6PR02MB42009022A6F4ED1F5EED1DED933F0@AM6PR02MB4200.eurprd02.prod.outlook.com>

Hi Kim, thanks for the feedback .

I opened :
8236709:  struct SwitchRange in HS violates C++ One Definition Rule
https://bugs.openjdk.java.net/browse/JDK-8236709

Best regards, Matthias


> > Hello,  when  experimenting  with  gcc8  and   the -flto compiler flag I was
> running into these  warnings  in the c1  coding :
> >
> > /open_jdk/jdk_3/jdk/src/hotspot/share/c1/c1_LIRGenerator.hpp:50:7:
> warning: type 'struct SwitchRange' violates the C++ One Definition Rule [-
> Wodr]
> > class SwitchRange: public CompilationResourceObj {
> >        ^
> > /open_jdk/jdk_3/jdk/src/hotspot/share/opto/parse2.cpp:319: note: a
> different type is defined in another translation unit
> > class SwitchRange : public StackObj {
> >
> >
> /usr/work/d040975/open_jdk/jdk_3/jdk/src/hotspot/share/c1/c1_LIRGener
> ator.hpp:52:7: note: the first difference of corresponding definitions is field
> '_low_key'
> >    int _low_key;
> >        ^
> > /open_jdk/jdk_3/jdk/src/hotspot/share/opto/parse2.cpp:321: note: a
> field with different name is defined in another translation unit
> >    jint _lo;                     // inclusive lower limit
> >
> >
> >
> > Do  you think this should be fixed ( renaming  one SwitchRange  ) ?
> >
> 
> > Martin suggested that  even without  flto added   it could be problematic .
> 
> Yes, please file a bug and let's get this fixed quickly.  This sort of thing can
> lead
> to really weird looking problems, like using the same vtable (which one
> picked
> ?at random?) for instances of both classes.


From nils.eliasson at oracle.com  Tue Jan  7 14:59:08 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 7 Jan 2020 15:59:08 +0100
Subject: [14] 8235984: C2: assert(out->in(PhiNode::Region) == head ||
 out->in(PhiNode::Region) == slow_head) failed: phi must be either part of the
 slow or the fast loop
In-Reply-To: <08f66862-fd59-feb1-5f3b-a0df81c07721@oracle.com>
References: <e985e329-b1c1-dbf0-39ae-a096b89c4c70@oracle.com>
 <08f66862-fd59-feb1-5f3b-a0df81c07721@oracle.com>
Message-ID: <6b15705e-8b49-488f-02a0-5ccf4e7a7d6b@oracle.com>

Hi Christian,

I agree with Tobias - lets go with fix b for 14, it seems to have the 
lowest risk.

Reviewed.

Best Regards,
Nils

On 2019-12-23 14:12, Tobias Hartmann wrote:
> Hi Christian,
>
> version b) looks good to me and I would go with that for JDK 14.
>
> Best regards,
> Tobias
>
> On 23.12.19 10:30, Christian Hagedorn wrote:
>> Hi
>>
>> Please review the following options for:
>> https://bugs.openjdk.java.net/browse/JDK-8235984
>>
>> The problem:
>> The original fix for JDK-8233033 [1] assumed that partially peeled statements always have a
>> dependency inside the loop to be unswitched (i.e. when following their outputs eventually a phi node
>> is hit belonging to either the slow or the fast loop). However, that is not always the case. As a
>> result the assert was hit.
>>
>> I suggest the following options:
>>
>> Option a) http://cr.openjdk.java.net/~chagedorn/8235984/webrev.a.00/
>> We first check at the start of loop unswitching if there are loop predicates for the loop to be
>> unswitched and if they have an additional control dependency to partially peeled statements (outcnt
>>> 1). Then we explicitly check the assumption that partially peeled statements have a dependency in
>> the loop to be unswitched (in order to keep the fix for JDK-8233033). If that is not the case, we
>> bailout. We could then file an RFE for JDK-15 to handle this missing case properly and remove the
>> bailout.
>>
>> Option b) http://cr.openjdk.java.net/~chagedorn/8235984/webrev.b.00/
>> We only check at the start of loop unswitching if there are loop predicates for the loop to be
>> unswitched and if they have an additional control dependency to partially peeled statements (outcnt
>>> 1). If that's the case we bailout without having the fix from JDK-8233033. We could then file an
>> RFE for JDK-15 to properly handle partially peeled statements all together (kinda a REDO of the fix
>> for JDK-8233033).
>>
>> Option c)
>> Trying to fix the missing cases from JDK-8233033 for JDK-14 without a bailout.
>>
>>
>> I've tried to come up with a fix (option c) last week but without success so far. The idea was to
>> also clone the partially peeled statements without a dependency in the loop to be unswitched, change
>> their control input to the correct cloned predicates and then add a phi node on each loop exit,
>> where we merge the slow and fast loop, to select the correct value. However, this has not worked
>> properly, yet and also involves a higher risk due to its complexity. I think we should not target
>> that option for JDK-14 but do it for JDK-15 in an RFE.
>>
>> Thus, I'd opt for either option a) or b). I tested Tier 1-7 for the complete bailout b) and Tier 1-8
>> for the "conditioned" bailout a). Both look fine. I also ran some standard benchmarks comparing a)
>> and b) to a baseline where I excluded the fix for JDK-8233033 (without bailing out and trying to fix
>> the problem). I could not see any difference in performance. Therefore, it suggests to go with the
>> low risk option b) for JDK-14 and do the entire fix in an RFE for JDK-15.
>>
>> What do you think?
>>
>>
>> Thank you!
>>
>> Best regards,
>> Christian
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233033


From nils.eliasson at oracle.com  Tue Jan  7 15:02:15 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 7 Jan 2020 16:02:15 +0100
Subject: [14] RFR(XS): 8236140: assert(!VerifyHashTableKeys || _hash_lock
 == 0) failed: remove node from hash table before modifying it
In-Reply-To: <2d1fd1d5-dfaa-a1d3-3b18-c0e9f0a58a01@oracle.com>
References: <2d1fd1d5-dfaa-a1d3-3b18-c0e9f0a58a01@oracle.com>
Message-ID: <38250d1f-f995-ff98-c683-7cfc6e111cd0@oracle.com>

Hi Christian!

The fix looks good to me.

Reviewed.

Best regards,
Nils

On 2020-01-07 12:53, Christian Hagedorn wrote:
> Hi
>
> Please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8236140
> http://cr.openjdk.java.net/~chagedorn/8236140/webrev.00/
>
> An input of the StoreL node in the test case was set without rehashing 
> the store which triggers the assertion failure.
>
> Thank you!
>
> Best regards,
> Christian


From igor.veresov at oracle.com  Tue Jan  7 15:07:03 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 7 Jan 2020 07:07:03 -0800
Subject: [14] RFR(S) 8236050: Some compiler tests fail when executed with
 custom TieredLevel
In-Reply-To: <7707d1d8-d5b0-7af1-877c-8fd0ffa5c84b@oracle.com>
References: <B43B8354-BDD3-46C2-B959-7FEF85F33308@oracle.com>
 <6188d3c7-839f-b822-4293-97526cecac6a@oracle.com>
 <6ED127C5-BFCB-4955-97FE-DBFF0498FEE0@oracle.com>
 <474c5c62-6679-3ddb-0fc8-06ebc03f76bf@oracle.com>
 <58742AC8-84BD-425F-A64A-9CAA93DBD5A3@oracle.com>
 <bb1c3d25-96d0-13d2-cbc0-1a103f49f2ae@oracle.com>
 <8F745069-EAAE-4120-9577-8AEDA5A8EDCA@oracle.com>
 <1e4fb10a-2462-f43d-2ae6-2479f45daae9@oracle.com>
 <C7F5F9D1-9775-467A-BFE2-A9EA1F60F892@oracle.com>
 <7707d1d8-d5b0-7af1-877c-8fd0ffa5c84b@oracle.com>
Message-ID: <2F0775F8-2FD2-459B-A18F-4CB96D231DCA@oracle.com>

Thanks, Tobias!

igor



> On Jan 6, 2020, at 11:31 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> 
> On 06.01.20 19:47, Igor Veresov wrote:
>> Sure thing. A quick test added: http://cr.openjdk.java.net/~iveresov/8236050/webrev.03/
> 
> Looks good, thanks for adding!
> 
> Best regards,
> Tobias


From christian.hagedorn at oracle.com  Tue Jan  7 15:18:08 2020
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Tue, 7 Jan 2020 16:18:08 +0100
Subject: [14] RFR(XS): 8236140: assert(!VerifyHashTableKeys || _hash_lock
 == 0) failed: remove node from hash table before modifying it
In-Reply-To: <38250d1f-f995-ff98-c683-7cfc6e111cd0@oracle.com>
References: <2d1fd1d5-dfaa-a1d3-3b18-c0e9f0a58a01@oracle.com>
 <38250d1f-f995-ff98-c683-7cfc6e111cd0@oracle.com>
Message-ID: <328e7f32-c525-c471-8158-d80eb94cf7c2@oracle.com>

Thank you Nils for the review!

Best regards,
Christian

On 07.01.20 16:02, Nils Eliasson wrote:
> Hi Christian!
> 
> The fix looks good to me.
> 
> Reviewed.
> 
> Best regards,
> Nils
> 
> On 2020-01-07 12:53, Christian Hagedorn wrote:
>> Hi
>>
>> Please review the following patch:
>> https://bugs.openjdk.java.net/browse/JDK-8236140
>> http://cr.openjdk.java.net/~chagedorn/8236140/webrev.00/
>>
>> An input of the StoreL node in the test case was set without rehashing 
>> the store which triggers the assertion failure.
>>
>> Thank you!
>>
>> Best regards,
>> Christian
> 

From christian.hagedorn at oracle.com  Tue Jan  7 15:33:56 2020
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Tue, 7 Jan 2020 16:33:56 +0100
Subject: [14] 8235984: C2: assert(out->in(PhiNode::Region) == head ||
 out->in(PhiNode::Region) == slow_head) failed: phi must be either part of the
 slow or the fast loop
In-Reply-To: <6b15705e-8b49-488f-02a0-5ccf4e7a7d6b@oracle.com>
References: <e985e329-b1c1-dbf0-39ae-a096b89c4c70@oracle.com>
 <08f66862-fd59-feb1-5f3b-a0df81c07721@oracle.com>
 <6b15705e-8b49-488f-02a0-5ccf4e7a7d6b@oracle.com>
Message-ID: <820c7ec7-b7dc-134f-49ca-461e8516e88a@oracle.com>

Thank you Nils for the review!

Then let's go with option b). I filed an RFE to do a proper fix in 15 [1].

Best regards,
Christian


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

On 07.01.20 15:59, Nils Eliasson wrote:
> Hi Christian,
> 
> I agree with Tobias - lets go with fix b for 14, it seems to have the 
> lowest risk.
> 
> Reviewed.
> 
> Best Regards,
> Nils
> 
> On 2019-12-23 14:12, Tobias Hartmann wrote:
>> Hi Christian,
>>
>> version b) looks good to me and I would go with that for JDK 14.
>>
>> Best regards,
>> Tobias
>>
>> On 23.12.19 10:30, Christian Hagedorn wrote:
>>> Hi
>>>
>>> Please review the following options for:
>>> https://bugs.openjdk.java.net/browse/JDK-8235984
>>>
>>> The problem:
>>> The original fix for JDK-8233033 [1] assumed that partially peeled 
>>> statements always have a
>>> dependency inside the loop to be unswitched (i.e. when following 
>>> their outputs eventually a phi node
>>> is hit belonging to either the slow or the fast loop). However, that 
>>> is not always the case. As a
>>> result the assert was hit.
>>>
>>> I suggest the following options:
>>>
>>> Option a) http://cr.openjdk.java.net/~chagedorn/8235984/webrev.a.00/
>>> We first check at the start of loop unswitching if there are loop 
>>> predicates for the loop to be
>>> unswitched and if they have an additional control dependency to 
>>> partially peeled statements (outcnt
>>>> 1). Then we explicitly check the assumption that partially peeled 
>>>> statements have a dependency in
>>> the loop to be unswitched (in order to keep the fix for JDK-8233033). 
>>> If that is not the case, we
>>> bailout. We could then file an RFE for JDK-15 to handle this missing 
>>> case properly and remove the
>>> bailout.
>>>
>>> Option b) http://cr.openjdk.java.net/~chagedorn/8235984/webrev.b.00/
>>> We only check at the start of loop unswitching if there are loop 
>>> predicates for the loop to be
>>> unswitched and if they have an additional control dependency to 
>>> partially peeled statements (outcnt
>>>> 1). If that's the case we bailout without having the fix from 
>>>> JDK-8233033. We could then file an
>>> RFE for JDK-15 to properly handle partially peeled statements all 
>>> together (kinda a REDO of the fix
>>> for JDK-8233033).
>>>
>>> Option c)
>>> Trying to fix the missing cases from JDK-8233033 for JDK-14 without a 
>>> bailout.
>>>
>>>
>>> I've tried to come up with a fix (option c) last week but without 
>>> success so far. The idea was to
>>> also clone the partially peeled statements without a dependency in 
>>> the loop to be unswitched, change
>>> their control input to the correct cloned predicates and then add a 
>>> phi node on each loop exit,
>>> where we merge the slow and fast loop, to select the correct value. 
>>> However, this has not worked
>>> properly, yet and also involves a higher risk due to its complexity. 
>>> I think we should not target
>>> that option for JDK-14 but do it for JDK-15 in an RFE.
>>>
>>> Thus, I'd opt for either option a) or b). I tested Tier 1-7 for the 
>>> complete bailout b) and Tier 1-8
>>> for the "conditioned" bailout a). Both look fine. I also ran some 
>>> standard benchmarks comparing a)
>>> and b) to a baseline where I excluded the fix for JDK-8233033 
>>> (without bailing out and trying to fix
>>> the problem). I could not see any difference in performance. 
>>> Therefore, it suggests to go with the
>>> low risk option b) for JDK-14 and do the entire fix in an RFE for 
>>> JDK-15.
>>>
>>> What do you think?
>>>
>>>
>>> Thank you!
>>>
>>> Best regards,
>>> Christian
>>>
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233033
> 

From tobias.hartmann at oracle.com  Tue Jan  7 16:27:20 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 7 Jan 2020 17:27:20 +0100
Subject: RFR(XS): 8229855: C2 fails with assert(false) failed: bad AD file
Message-ID: <790571f6-2a0e-613f-ebc8-0317f4a8f50c@oracle.com>

Hi,

please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8229855
http://cr.openjdk.java.net/~thartmann/8229855/webrev.00/

For the switch statement in TestJumpTable.java, C2 creates the following binary search tree with a
jump table at (*):

if (key_val > 45) {
  if (key_val != 60) {
    if (key_val <= 60) {
      (*)
    } else {
      [...]
    }
  } else {
    [...]
  }
} else {
  [...]
}

The jump table at (*) handles the following key_val ranges: {46..50}, {51}, {52..59}.
Parse::jump_switch_ranges -> Parse::create_jump_tables adds a CastII to narrow the type of key_val
to type int:46..59 (type int:0..13 after normalizing to zero):
http://hg.openjdk.java.net/jdk/jdk/file/44cb1f517839/src/hotspot/share/opto/parse2.cpp#l884

Now after some rounds of loop unrolling, key_val is known to be int:60..260 (normalized to
int:14..214) in one of the loop bodies. As a result, the narrow CastII node is replaced by TOP and
we crash in the matcher because the JumpNode user didn't go away.

The problem is that the key_val != 60 && key_val <= 60 combination is *not* found to be always false
if key_val becomes known as int:60..260 because C2's type system does not narrow the type after the
first check. The fix is to simply strengthen the second check to ensure that both control and data
paths die consistently.

I would like to push this simple fix into JDK 14 and follow-up in JDK 15 with an enhancement that
adds a general optimization for such integer checks:
https://bugs.openjdk.java.net/browse/JDK-8236721

I've quickly hacked a prototype that shows promising results (and would also fix this issue):
http://cr.openjdk.java.net/~thartmann/8236721/webrev.00/

Thanks,
Tobias

From tobias.hartmann at oracle.com  Tue Jan  7 16:31:23 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 7 Jan 2020 17:31:23 +0100
Subject: [14] RFR(XS): 8236140: assert(!VerifyHashTableKeys || _hash_lock
 == 0) failed: remove node from hash table before modifying it
In-Reply-To: <38250d1f-f995-ff98-c683-7cfc6e111cd0@oracle.com>
References: <2d1fd1d5-dfaa-a1d3-3b18-c0e9f0a58a01@oracle.com>
 <38250d1f-f995-ff98-c683-7cfc6e111cd0@oracle.com>
Message-ID: <f1763c4a-e6a9-ee1b-2f68-bb661aa2778a@oracle.com>

+1

Best regards,
Tobias

On 07.01.20 16:02, Nils Eliasson wrote:
> Hi Christian!
> 
> The fix looks good to me.
> 
> Reviewed.
> 
> Best regards,
> Nils
> 
> On 2020-01-07 12:53, Christian Hagedorn wrote:
>> Hi
>>
>> Please review the following patch:
>> https://bugs.openjdk.java.net/browse/JDK-8236140
>> http://cr.openjdk.java.net/~chagedorn/8236140/webrev.00/
>>
>> An input of the StoreL node in the test case was set without rehashing the store which triggers
>> the assertion failure.
>>
>> Thank you!
>>
>> Best regards,
>> Christian
> 

From rwestrel at redhat.com  Tue Jan  7 16:37:56 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 07 Jan 2020 17:37:56 +0100
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <7bc32dc2-1612-cb77-a467-ac67987b148c@oracle.com>
References: <87o8w8ptsq.fsf@redhat.com>
 <da3150a6-8303-894c-be9c-c90298f7de7d@oracle.com> <8736dfkko7.fsf@redhat.com>
 <7bc32dc2-1612-cb77-a467-ac67987b148c@oracle.com>
Message-ID: <87woa35ijf.fsf@redhat.com>


Hi Vladimir,

>>> Why you added check in must_be_not_null()? It is used only in library_call.cpp and should not relate to this changes.
>>> Did you find some issues?
>> 
>> I hit a crash when doing some CTW testing because an argument to
>> must_be_not_null() was already known to be not null. I suppose it's
>> unrelated to that change and something changed in the libraries instead.
>
> That's interesting. I initially thought it's just to simplify the IR and 
> avoid keeping redundant null check until loop opts are over.

must_be_not_null() is there for correctness. For some intrinsics, we
know that some parameter is not null and so the intrinsic implementation
skips the null check. Without must_be_not_null() calls, we, for
instance, add a load from an oop whose type is maybe a null
pointer. After some transformation we may end up with a load from
null. For instance if we have the following code shape:

for (;;) {
  if (p == null) {
    ..
  }
  v = p.f; // intrinsic. Load without a null check
}

after unswitching:

if (p == null) {
  for (;;) {
    v = null.f; // crashes the compiler
  }
} else {
  for (;;) {
    v = p.f;
  }
}

> Doesn't it signal about a more general problem with 
> GraphKit::must_be_not_null()?
>
> What if a value becomes non-null after GraphKit::must_be_not_null()? Is 
> there a chance to hit the very same problem you observed?

The problem I hit is that if the value passed to must_be_not_null is
already known to be not null. The null branch of must_be_not_null
optimizes out at parse time and:

C->root()->add_req(halt);

adds top to the RootNode which causes some failures during matching
because top is unexpected from Root.

Running RootNode::Ideal() would clean it up but it's not called. If the
null branch becomes dead after parsing then, AFAICT, RootNode::Ideal()
would be executed and the same problem would not happen.

Roland.


From christian.hagedorn at oracle.com  Tue Jan  7 16:48:48 2020
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Tue, 7 Jan 2020 17:48:48 +0100
Subject: [14] RFR(XS): 8236140: assert(!VerifyHashTableKeys || _hash_lock
 == 0) failed: remove node from hash table before modifying it
In-Reply-To: <f1763c4a-e6a9-ee1b-2f68-bb661aa2778a@oracle.com>
References: <2d1fd1d5-dfaa-a1d3-3b18-c0e9f0a58a01@oracle.com>
 <38250d1f-f995-ff98-c683-7cfc6e111cd0@oracle.com>
 <f1763c4a-e6a9-ee1b-2f68-bb661aa2778a@oracle.com>
Message-ID: <1937385b-c626-b697-cd36-8b4dd1c4087a@oracle.com>

Thank you for the review Tobias!

Best regards,
Christian

On 07.01.20 17:31, Tobias Hartmann wrote:
> +1
> 
> Best regards,
> Tobias
> 
> On 07.01.20 16:02, Nils Eliasson wrote:
>> Hi Christian!
>>
>> The fix looks good to me.
>>
>> Reviewed.
>>
>> Best regards,
>> Nils
>>
>> On 2020-01-07 12:53, Christian Hagedorn wrote:
>>> Hi
>>>
>>> Please review the following patch:
>>> https://bugs.openjdk.java.net/browse/JDK-8236140
>>> http://cr.openjdk.java.net/~chagedorn/8236140/webrev.00/
>>>
>>> An input of the StoreL node in the test case was set without rehashing the store which triggers
>>> the assertion failure.
>>>
>>> Thank you!
>>>
>>> Best regards,
>>> Christian
>>

From luhenry at microsoft.com  Tue Jan  7 22:16:05 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Tue, 7 Jan 2020 22:16:05 +0000
Subject: Fix potential bug in jaotc
Message-ID: <MWHPR21MB05114A4DA539DC03C41F825DB03F0@MWHPR21MB0511.namprd21.prod.outlook.com>

Hello,

As I was learning and reading over the codebase of src/jdk.aot and src/hotspot/share/aot, I discovered a discrepancy which might lead to future bugs. The issue is around how some of the metadata is generated and loaded between jaotc and the runtime.

In the runtime, `aot_metadata` (src/hotspot/share/aot/aotCompiledMethod.hpp) contains metadata about each method that is compiled in the AOT image - for example, information like the implicit and explicit exception table, or the oop map. Because the size of this data is specific to each method, `aot_metadata` contains fields that store offsets to the `this` pointer, and the data is stored right after the `aot_metadata` structure in the AOT image.

The structure of `aot_metadata` is the following:

class aot_metadata {
  int _size;
  int _code_size;
  int _entry;
  int _verified_entry;
  int _exception_handler_offset;
  int _deopt_handler_offset;
  int _stubs_offset;
  int _frame_size;
  int _orig_pc_offset;
  int _unsafe_access;

  // contain the offset to the `this` pointer
  int _pc_desc_begin;
  int _scopes_begin;
  int _reloc_begin;
  int _exception_table_begin;
  int _nul_chk_table_begin;
  int _oopmap_begin;
}

When creating the AOT image and generating the information in `jdk.tools.jaotc.MetadataBuilder` (src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java), the `aot_metadata._nul_chk_table_begin` field is conditionally generated. In the case where there is no implicit exceptions in the method, no data/field is generated in the AOT image. However, there is no check for the existence of this field when loading the `aot_metadata` from the AOT image.

This issue is mitigated by the fact that the `HotSpotMetaData.implicitExceptionBytes` is always set, even if only with an empty `byte[]`. Nonetheless, this field is populated in the runtime in `getMetadata` (in src/hotspot/share/jvmci/jvmciCompilerToVM.cpp), making the initialization and usage of this field far apart, complexifying the overall solution.

The following patch proposes to always generate the `aot_metadata._nul_chk_table_begin` field. It also has the advantage to unify how this field and the others are generated.

diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
index 34ce4d8c8b..fa89d34796 100644
--- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
+++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
@@ -98,7 +98,8 @@ final class MetadataBuilder {
             byte[] scopeDesc = metaData.scopesDescBytes();
             byte[] relocationInfo = metaData.relocBytes();
             byte[] oopMapInfo = metaData.oopMaps();
-            byte[] implicitExceptionBytes = HotSpotGraalServices.getImplicitExceptionBytes(metaData);
+            byte[] exceptionBytes = metaData.exceptionBytes();
+            byte[] implicitExceptionBytes = metaData.implicitExceptionBytes();

             // create a global symbol at this position for this method
             NativeOrderOutputStream metadataStream = new NativeOrderOutputStream();
@@ -143,10 +144,7 @@ final class MetadataBuilder {
                 NativeOrderOutputStream.PatchableInt scopeOffset = metadataStream.patchableInt();
                 NativeOrderOutputStream.PatchableInt relocationOffset = metadataStream.patchableInt();
                 NativeOrderOutputStream.PatchableInt exceptionOffset = metadataStream.patchableInt();
-                NativeOrderOutputStream.PatchableInt implictTableOffset = null;
-                if (implicitExceptionBytes != null) {
-                    implictTableOffset = metadataStream.patchableInt();
-                }
+                NativeOrderOutputStream.PatchableInt implictTableOffset = metadataStream.patchableInt();
                 NativeOrderOutputStream.PatchableInt oopMapOffset = metadataStream.patchableInt();
                 metadataStream.align(8);

@@ -160,12 +158,10 @@ final class MetadataBuilder {
                 metadataStream.put(relocationInfo).align(8);

                 exceptionOffset.set(metadataStream.position());
-                metadataStream.put(metaData.exceptionBytes()).align(8);
+                metadataStream.put(exceptionBytes).align(8);

-                if (implicitExceptionBytes != null) {
-                    implictTableOffset.set(metadataStream.position());
-                    metadataStream.put(implicitExceptionBytes).align(8);
-                }
+                implictTableOffset.set(metadataStream.position());
+                metadataStream.put(implicitExceptionBytes).align(8);

                 // oopmaps should be last
                 oopMapOffset.set(metadataStream.position());
diff --git a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
index fc54c41312..3acb6191b9 100644
--- a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
+++ b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
@@ -41,6 +41,7 @@ public class HotSpotMetaData {
         scopesDescBytes = new byte[0];
         relocBytes = new byte[0];
         exceptionBytes = new byte[0];
+        implicitExceptionBytes = new byte[0];
         oopMaps = new byte[0];
         metadata = new String[0];
         // ...some of them will be overwritten by the VM:

Thank you,

--
Ludovic







From tobias.hartmann at oracle.com  Wed Jan  8 10:09:01 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 8 Jan 2020 11:09:01 +0100
Subject: RFR(S): 8235762: JVM crash in SWPointer during C2 compilation
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE3DD88F1@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DD8064@dggeml527-mbx.china.huawei.com>
 <e10a10b9-78ad-5ff7-5b55-571b7feae324@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD80DB@dggeml527-mbx.china.huawei.com>
 <4ef39906-839b-9a08-3225-f99b974f08de@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD8325@dggeml527-mbx.china.huawei.com>
 <d429870d-248e-bbb6-d296-d373c7e5affd@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD88F1@dggeml527-mbx.china.huawei.com>
Message-ID: <4103e17e-57c4-ed78-bf64-1bb3cb99e9f4@oracle.com>

Hi Felix,

On 16.12.19 11:14, Yangfei (Felix) wrote:
> -- OK.  I will add one assertion immediately before breaking the loop. 

Thanks.

>> - Why do you need max_idx? Isn't is the case that if find_align_to_ref returns
>> NULL, there aren't any comparable memory operations left and it essentially
>> doesn't matter which one you chose?
> 
> -- I was considering minimizing the performance impact of the patch here.  
>   best_align_to_mem_ref is used in SuperWord::align_initial_loop_index for adjusting the pre-loop limit.  
>   For the test case in the webrev, best_align_to_mem_ref was chosen from node 470 (StoreB) and node 431 (StoreL).  
>   The vector width for these two memory operations are different on aarch64 platform: vw = 16 bytes for node 431 and 2 bytes for node 470.  
>   SuperWord::align_initial_loop_index will emit different code sequences for the test case.  
>   The max_idx tells us which memory operation has the biggest vector size.  

Okay, thanks for the details. Could you add a comment that explains this?

>> Also, is it guaranteed that max_idx is always initialized in SuperWord::find_align_to_ref?
> 
> -- Yes, I think so. 
>   When memops is not empty and the memory ops in memops are not comparable, find_align_to_ref will always sets its max_idx.  

Okay.

Thanks,
Tobias

From goetz.lindenmaier at sap.com  Wed Jan  8 13:41:52 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 8 Jan 2020 13:41:52 +0000
Subject: [14] RFR: 8236772: Fix build for windows 32-bit after 8212160 and
 8234331.
Message-ID: <VE1PR02MB5422C5B115E51594588FCB97EC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi,

Two warning fail the windows 32 bit build with VS 2017.

In count_leading_zeroes.hpp, a declaration is not included
in the _LP64 that covers all it's uses. Thus a warning
about an unused variable is raised.

A library for a test lacks the JNIEXPORT and JNICALL
required to match the signature in jvmti.h.

I'd like to push this to jdk14.

Please review:
http://cr.openjdk.java.net/~goetz/wr20/8236772-fix_ntintel_build-jdk14/01/

Best regards,
  Goetz.

From christoph.langer at sap.com  Wed Jan  8 14:50:44 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 8 Jan 2020 14:50:44 +0000
Subject: [14] RFR: 8236772: Fix build for windows 32-bit after 8212160 and
 8234331.
In-Reply-To: <VE1PR02MB5422C5B115E51594588FCB97EC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422C5B115E51594588FCB97EC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4984D6002F99A82B0749A1318A3E0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Goetz,

looks good and trivial to me.

Cheers
Christoph

> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Lindenmaier, Goetz
> Sent: Mittwoch, 8. Januar 2020 14:42
> To: hotspot-compiler-dev at openjdk.java.net
> Subject: [SUSPECTED SPAM] [CAUTION] [14] RFR: 8236772: Fix build for
> windows 32-bit after 8212160 and 8234331.
> 
> Hi,
> 
> Two warning fail the windows 32 bit build with VS 2017.
> 
> In count_leading_zeroes.hpp, a declaration is not included
> in the _LP64 that covers all it's uses. Thus a warning
> about an unused variable is raised.
> 
> A library for a test lacks the JNIEXPORT and JNICALL
> required to match the signature in jvmti.h.
> 
> I'd like to push this to jdk14.
> 
> Please review:
> http://cr.openjdk.java.net/~goetz/wr20/8236772-fix_ntintel_build-
> jdk14/01/
> 
> Best regards,
>   Goetz.

From smita.kamath at intel.com  Thu Jan  9 01:22:14 2020
From: smita.kamath at intel.com (Kamath, Smita)
Date: Thu, 9 Jan 2020 01:22:14 +0000
Subject: RFR(M):8167065: Add intrinsic support for double precision
 shifting on x86_64
In-Reply-To: <be683ef4-afbe-0d40-bf43-7efa430ad98f@oracle.com>
References: <6563F381B547594081EF9DE181D07912B2D6B7A7@fmsmsx123.amr.corp.intel.com>
 <70b5bff1-a2ad-6fea-24ee-f0748e2ccae6@oracle.com>
 <SN6PR11MB3134FA19A661AD004141C92999520@SN6PR11MB3134.namprd11.prod.outlook.com>
 <3914890d-74e3-c69e-6688-55cf9f0c8551@oracle.com>
 <SN6PR11MB3134C5857F7C451FB19E35C2992D0@SN6PR11MB3134.namprd11.prod.outlook.com>
 <8919a5ce-727a-fb25-e739-4c14da108a7a@oracle.com>
 <be683ef4-afbe-0d40-bf43-7efa430ad98f@oracle.com>
Message-ID: <SN6PR11MB31342CB567A40334105D478B99390@SN6PR11MB3134.namprd11.prod.outlook.com>

Hi Alan,

Thanks for the comment. I added these checks for caution but on further analysis it appears that these checks are not needed.

1)  For PrimitiveRightShift, we have the input array and its length passed as arguments. Since the input array, result[], is copied using arraycopy, we know that IOOBE will be thrown.  Therefore, it is safe to remove the checkIndex condition. 
         int result[] = new int[nInts+len+1]; 
         System.arraycopy(a, 0, result, 0, len);
         primitiveRightShift(result, result.length, 32 - nBits);

2) In case of PrimitiveLeftShift, I checked the call stack and verified that the length passed to the method is same as the length of the array. Therefore, the check is not necessary in this scenario.

3) In case of shiftLeft and shiftRight,  the number of iterations (numIter) is computed from the mag.length. The newMag array length is also computed and adjusted based on mag.length. 

If these changes look fine, I can send an updated webrev removing these checks. Please let me know.  

Thanks and Regards,
Smita Kamath

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com> 
Sent: Saturday, December 28, 2019 12:22 AM
To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; Kamath, Smita <smita.kamath at intel.com>
Cc: core-libs-dev at openjdk.java.net; 'hotspot compiler' <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64

On 20/12/2019 22:19, Vladimir Kozlov wrote:
> We should have added core-libs to review since you modified 
> BigInteger.java.
>
This adds Objects.checkFromToIndex checks in the middle of several supporting methods. Is IOOBE really possible in these cases or are these stand in for always-on asserts to ensure the instrinic is never used when the preconditions aren't satisfied?

-Alan

From Pengfei.Li at arm.com  Thu Jan  9 09:36:21 2020
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Thu, 9 Jan 2020 09:36:21 +0000
Subject: RFR(S): 8230591: AArch64: Missing intrinsics for Math.ceil, floor,
 rint
Message-ID: <DB7PR08MB3115627E0C96DB20E2F60E5096390@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi,

JBS: https://bugs.openjdk.java.net/browse/JDK-8230591
Webrev: http://cr.openjdk.java.net/~pli/rfr/8230591/webrev.00/

This patch adds missing intrinsics for Math.ceil, floor and rint on AArch64 with Instructions FRINTP, FRINTM and FRINTN, respectively. These 3 instructions respect to the Java API Spec of the 3 math methods quite well, especially for special cases such as +/-0.0, +/-Inf and NaN.

This also adds vectorized forms of these intrinsics. Intel has already added jtreg [1] and benchmark [2] for these intrinsics in its x86 patch [3].

Tests:
Jtreg: no new failure after my change.
JMH FpRoundingBenchmark.java[2]:
(Before)
  Benchmark                      (TESTSIZE)   Mode  Cnt    Score   Error   Units
  FpRoundingBenchmark.testceil         1024  thrpt   15  255.867 ? 0.123  ops/ms
  FpRoundingBenchmark.testfloor        1024  thrpt   15  249.013 ? 0.118  ops/ms
  FpRoundingBenchmark.testrint         1024  thrpt   15  419.425 ? 5.868  ops/ms
(After)
  Benchmark                      (TESTSIZE)   Mode  Cnt     Score   Error   Units
  FpRoundingBenchmark.testceil         1024  thrpt   15  1510.861 ? 2.626  ops/ms
  FpRoundingBenchmark.testfloor        1024  thrpt   15  1510.289 ? 6.147  ops/ms
  FpRoundingBenchmark.testrint         1024  thrpt   15  1510.780 ? 1.091  ops/ms


[1] https://hg.openjdk.java.net/jdk/jdk/file/b94889c7e153/test/hotspot/jtreg/compiler/c2/cr6340864/TestDoubleVect.java
[2] https://hg.openjdk.java.net/jdk/jdk/file/b94889c7e153/test/micro/org/openjdk/bench/java/math/FpRoundingBenchmark.java
[3] https://hg.openjdk.java.net/jdk/jdk/rev/6fc57e391539

--
Thanks,
Pengfei


From aph at redhat.com  Thu Jan  9 10:28:03 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 9 Jan 2020 10:28:03 +0000
Subject: RFR(S): 8230591: AArch64: Missing intrinsics for Math.ceil,
 floor, rint
In-Reply-To: <DB7PR08MB3115627E0C96DB20E2F60E5096390@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115627E0C96DB20E2F60E5096390@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <fa128596-79e9-60d4-b4ee-f9cc72e53b36@redhat.com>

On 1/9/20 9:36 AM, Pengfei Li wrote:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8230591
> Webrev: http://cr.openjdk.java.net/~pli/rfr/8230591/webrev.00/

These instructions fall into the category "AdvSIMD two-reg misc". Please
put them there. Otherwise 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 rwestrel at redhat.com  Thu Jan  9 12:25:24 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 09 Jan 2020 13:25:24 +0100
Subject: RFR(XS): 8229855: C2 fails with assert(false) failed: bad AD file
In-Reply-To: <790571f6-2a0e-613f-ebc8-0317f4a8f50c@oracle.com>
References: <790571f6-2a0e-613f-ebc8-0317f4a8f50c@oracle.com>
Message-ID: <87lfqg6cln.fsf@redhat.com>


> I would like to push this simple fix into JDK 14 and follow-up in JDK 15 with an enhancement that
> adds a general optimization for such integer checks:
> https://bugs.openjdk.java.net/browse/JDK-8236721

That sounds ok to me.

Roland.


From tobias.hartmann at oracle.com  Thu Jan  9 13:08:47 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 9 Jan 2020 14:08:47 +0100
Subject: RFR(XS): 8229855: C2 fails with assert(false) failed: bad AD file
In-Reply-To: <87lfqg6cln.fsf@redhat.com>
References: <790571f6-2a0e-613f-ebc8-0317f4a8f50c@oracle.com>
 <87lfqg6cln.fsf@redhat.com>
Message-ID: <3ce85c62-2cfc-0e94-ba7d-28c3b9961a9f@oracle.com>

Hi Roland,

thanks for the review!

Best regards,
Tobias

On 09.01.20 13:25, Roland Westrelin wrote:
> 
>> I would like to push this simple fix into JDK 14 and follow-up in JDK 15 with an enhancement that
>> adds a general optimization for such integer checks:
>> https://bugs.openjdk.java.net/browse/JDK-8236721
> 
> That sounds ok to me.
> 
> Roland.
> 

From tobias.hartmann at oracle.com  Thu Jan  9 13:22:24 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 9 Jan 2020 14:22:24 +0100
Subject: [15] RFR(S): 8236721: C2 should better optimize not-equal integer
 comparisons
Message-ID: <480a02e6-1d4b-900f-28cf-ce37b6382e81@oracle.com>

Hi,

please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8236721
http://cr.openjdk.java.net/~thartmann/8236721/webrev.00/

While working on JDK-8229855 [1], I've noticed that C2 is not able to fold not-equal integer
comparisons of the following kind:

val = int:lo..hi
if (val != lo) {
  if (val <= lo) {
    // Dead code
  }
}

In general, C2's type system is quite limited when it comes to representing "sparse" types. But if
an integer value is found to be unequal to it's lower/upper boundary, we can still narrow the type.

With this enhancement, all checks in the 8 methods in TestFoldNECompares.java are folded and the
methods are compiled as empty.

Thanks,
Tobias

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

From felix.yang at huawei.com  Fri Jan 10 01:13:23 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Fri, 10 Jan 2020 01:13:23 +0000
Subject: RFR(S): 8235762: JVM crash in SWPointer during C2 compilation
In-Reply-To: <4103e17e-57c4-ed78-bf64-1bb3cb99e9f4@oracle.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DD8064@dggeml527-mbx.china.huawei.com>
 <e10a10b9-78ad-5ff7-5b55-571b7feae324@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD80DB@dggeml527-mbx.china.huawei.com>
 <4ef39906-839b-9a08-3225-f99b974f08de@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD8325@dggeml527-mbx.china.huawei.com>
 <d429870d-248e-bbb6-d296-d373c7e5affd@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD88F1@dggeml527-mbx.china.huawei.com>
 <4103e17e-57c4-ed78-bf64-1bb3cb99e9f4@oracle.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE3DECF6D@dggeml507-mbx.china.huawei.com>

Hi Tobias,

  Updated webrev: http://cr.openjdk.java.net/~fyang/8235762/webrev.01/ 
  This also updated copyright years of the newly-added test case.  
  Still test OK with the latest repo.  Is this one better?  

Thanks,
Felix

> 
> Hi Felix,
> 
> On 16.12.19 11:14, Yangfei (Felix) wrote:
> > -- OK.  I will add one assertion immediately before breaking the loop.
> 
> Thanks.
> 
> >> - Why do you need max_idx? Isn't is the case that if
> >> find_align_to_ref returns NULL, there aren't any comparable memory
> >> operations left and it essentially doesn't matter which one you chose?
> >
> > -- I was considering minimizing the performance impact of the patch here.
> >   best_align_to_mem_ref is used in SuperWord::align_initial_loop_index for
> adjusting the pre-loop limit.
> >   For the test case in the webrev, best_align_to_mem_ref was chosen from
> node 470 (StoreB) and node 431 (StoreL).
> >   The vector width for these two memory operations are different on
> aarch64 platform: vw = 16 bytes for node 431 and 2 bytes for node 470.
> >   SuperWord::align_initial_loop_index will emit different code sequences for
> the test case.
> >   The max_idx tells us which memory operation has the biggest vector size.
> 
> Okay, thanks for the details. Could you add a comment that explains this?
> 
> >> Also, is it guaranteed that max_idx is always initialized in
> SuperWord::find_align_to_ref?
> >
> > -- Yes, I think so.
> >   When memops is not empty and the memory ops in memops are not
> comparable, find_align_to_ref will always sets its max_idx.
> 
> Okay.
> 
> Thanks,
> Tobias

From Pengfei.Li at arm.com  Fri Jan 10 03:34:38 2020
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Fri, 10 Jan 2020 03:34:38 +0000
Subject: RFR(S): 8230591: AArch64: Missing intrinsics for Math.ceil,
 floor, rint
In-Reply-To: <fa128596-79e9-60d4-b4ee-f9cc72e53b36@redhat.com>
References: <DB7PR08MB3115627E0C96DB20E2F60E5096390@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <fa128596-79e9-60d4-b4ee-f9cc72e53b36@redhat.com>
Message-ID: <DB7PR08MB311574B245F93A2AA5267C6496380@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi Andrew,

> These instructions fall into the category "AdvSIMD two-reg misc". Please put
> them there. Otherwise OK, thanks.

Some of these rounding instructions do not perfectly match category "AdvSIMD two-reg misc". In that category, we use "f((int)(T >> 1), 23, 22)" where the SIMD_Arrangement T is "100", "101" or "111" for "T2S", "T4S" or "T2D" respectively. In this case, the 23rd bit is always set to 1. But for some rounding instructions (FRINTN/FRINTM), the 23rd bit should be 0.

Moreover, I don't think instructions FSQRT/FABS/FNEG should be put into that category as their 23rd bit is not actually derived from the data type (or we say the SIMD_Arrangement T), although there's no error since those bits happen to be 1.

So for better instruction categories, I would like to add a new category (perhaps named "AdvSIMD two-reg arithmetic") and put rounding instructions as well as FSQRT/FABS/FNEG into this. I will upload a new webrev if you agree with me.

--
Thanks,
Pengfei


From aph at redhat.com  Fri Jan 10 09:38:57 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 10 Jan 2020 09:38:57 +0000
Subject: RFR(S): 8230591: AArch64: Missing intrinsics for Math.ceil,
 floor, rint
In-Reply-To: <DB7PR08MB311574B245F93A2AA5267C6496380@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115627E0C96DB20E2F60E5096390@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <fa128596-79e9-60d4-b4ee-f9cc72e53b36@redhat.com>
 <DB7PR08MB311574B245F93A2AA5267C6496380@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <98800e19-9bc1-654f-443c-d1fc1adfe4b7@redhat.com>

hi,

On 1/10/20 3:34 AM, Pengfei Li wrote:

>> These instructions fall into the category "AdvSIMD two-reg misc". Please put
>> them there. Otherwise OK, thanks.
>
> Some of these rounding instructions do not perfectly match category
> "AdvSIMD two-reg misc". In that category, we use "f((int)(T >> 1),
> 23, 22)" where the SIMD_Arrangement T is "100", "101" or "111" for
> "T2S", "T4S" or "T2D" respectively. In this case, the 23rd bit is
> always set to 1. But for some rounding instructions (FRINTN/FRINTM),
> the 23rd bit should be 0.

Sure, but the code in "AdvSIMD two-reg misc" can easily be made
flexible enough to accommodate that. All you have to do aas far as I
can see is make size a parameter: everything else is the same.

> Moreover, I don't think instructions FSQRT/FABS/FNEG should be put
> into that category as their 23rd bit is not actually derived from
> the data type (or we say the SIMD_Arrangement T), although there's
> no error since those bits happen to be 1.
>
> So for better instruction categories, I would like to add a new
> category (perhaps named "AdvSIMD two-reg arithmetic") and put
> rounding instructions as well as FSQRT/FABS/FNEG into this. I will
> upload a new webrev if you agree with me.

The grouping names are defined by the ARM reference manual, they are
not something we should invent for ourselves. If you go to the RM, see
"Advanced SIMD two-register miscellaneous"; the encodings are all
defined in terms of U, size, and opcode.

The important thing is that our assembler should follow the layout and
classification in that manual as closely as we possibly can.

-- 
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 vladimir.x.ivanov at oracle.com  Fri Jan 10 18:34:19 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 10 Jan 2020 21:34:19 +0300
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <87woa35ijf.fsf@redhat.com>
References: <87o8w8ptsq.fsf@redhat.com>
 <da3150a6-8303-894c-be9c-c90298f7de7d@oracle.com> <8736dfkko7.fsf@redhat.com>
 <7bc32dc2-1612-cb77-a467-ac67987b148c@oracle.com> <87woa35ijf.fsf@redhat.com>
Message-ID: <9f364210-53e4-0b4d-df3e-a02aa5219cb0@oracle.com>

Thanks for the clarifications, Roland.

>> Doesn't it signal about a more general problem with
>> GraphKit::must_be_not_null()?
>>
>> What if a value becomes non-null after GraphKit::must_be_not_null()? Is
>> there a chance to hit the very same problem you observed?
> 
> The problem I hit is that if the value passed to must_be_not_null is
> already known to be not null. The null branch of must_be_not_null
> optimizes out at parse time and:
> 
> C->root()->add_req(halt);
> 
> adds top to the RootNode which causes some failures during matching
> because top is unexpected from Root.
> 
> Running RootNode::Ideal() would clean it up but it's not called. If the
> null branch becomes dead after parsing then, AFAICT, RootNode::Ideal()
> would be executed and the same problem would not happen.

Makes sense.

Do you know why RootNode::Ideal() isn't called during IGVN pass after 
parsing is over?

Best regards,
Vladimir Ivanov

From sandhya.viswanathan at intel.com  Fri Jan 10 19:35:12 2020
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Fri, 10 Jan 2020 19:35:12 +0000
Subject: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to
 zmm0-zmm15 registers
Message-ID: <BYAPR11MB2983D0B14A75B35DC775930AEF380@BYAPR11MB2983.namprd11.prod.outlook.com>


JBS: https://bugs.openjdk.java.net/browse/JDK-8236944
Webrev: http://cr.openjdk.java.net/~sviswanathan/8236944/webrev.00/

Currently legVecZ operand is defined as follows:
operand legVecZ() %{
  constraint(ALLOC_IN_RC(vectorz_reg_vl));
  match(VecZ);
  format %{ %}
  interface(REG_INTER);
%}
This allows legVecZ to be zmm0-zmm31 on platforms supporting AVX 512 vl.

The legVecZ should instead be defined as:
operand legVecZ() %{
  constraint(ALLOC_IN_RC(vectorz_reg_legacy));
  match(VecZ);
  format %{ %}
  interface(REG_INTER);
%}

Please consider this for JDK 14.

Best Regards,
Sandhya

From vladimir.x.ivanov at oracle.com  Fri Jan 10 21:50:39 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 11 Jan 2020 00:50:39 +0300
Subject: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to
 zmm0-zmm15 registers
In-Reply-To: <BYAPR11MB2983D0B14A75B35DC775930AEF380@BYAPR11MB2983.namprd11.prod.outlook.com>
References: <BYAPR11MB2983D0B14A75B35DC775930AEF380@BYAPR11MB2983.namprd11.prod.outlook.com>
Message-ID: <c5365a54-a10a-8418-bf04-e13eca7ba12b@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 10.01.2020 22:35, Viswanathan, Sandhya wrote:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8236944
> 
> Webrev: http://cr.openjdk.java.net/~sviswanathan/8236944/webrev.00/
> 
> Currently legVecZ operand is defined as follows:
> 
> operand legVecZ() %{
> 
>  ? constraint(ALLOC_IN_RC(vectorz_reg_vl));
> 
>  ? match(VecZ);
> 
>  ? format %{ %}
> 
>  ? interface(REG_INTER);
> 
> %}
> 
> This allows legVecZ to be zmm0-zmm31 on platforms supporting AVX 512 vl.
> 
> The legVecZ should instead be defined as:
> 
> operand legVecZ() %{
> 
>  ? constraint(ALLOC_IN_RC(vectorz_reg_legacy));
> 
>  ? match(VecZ);
> 
>  ? format %{ %}
> 
>  ? interface(REG_INTER);
> 
> %}
> 
> Please consider this for JDK 14.
> 
> Best Regards,
> 
> Sandhya
> 

From vladimir.x.ivanov at oracle.com  Fri Jan 10 23:39:23 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 11 Jan 2020 02:39:23 +0300
Subject: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to
 zmm0-zmm15 registers
In-Reply-To: <c5365a54-a10a-8418-bf04-e13eca7ba12b@oracle.com>
References: <BYAPR11MB2983D0B14A75B35DC775930AEF380@BYAPR11MB2983.namprd11.prod.outlook.com>
 <c5365a54-a10a-8418-bf04-e13eca7ba12b@oracle.com>
Message-ID: <951f79b5-3418-0803-b1ec-627270cac012@oracle.com>

FYI test results are clean (hs-precheckin-comp,hs-tier1,hs-tier2).

Best regards,
Vladimir Ivanov

On 11.01.2020 00:50, Vladimir Ivanov wrote:
> Looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 10.01.2020 22:35, Viswanathan, Sandhya wrote:
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236944
>>
>> Webrev: http://cr.openjdk.java.net/~sviswanathan/8236944/webrev.00/
>>
>> Currently legVecZ operand is defined as follows:
>>
>> operand legVecZ() %{
>>
>> ?? constraint(ALLOC_IN_RC(vectorz_reg_vl));
>>
>> ?? match(VecZ);
>>
>> ?? format %{ %}
>>
>> ?? interface(REG_INTER);
>>
>> %}
>>
>> This allows legVecZ to be zmm0-zmm31 on platforms supporting AVX 512 vl.
>>
>> The legVecZ should instead be defined as:
>>
>> operand legVecZ() %{
>>
>> ?? constraint(ALLOC_IN_RC(vectorz_reg_legacy));
>>
>> ?? match(VecZ);
>>
>> ?? format %{ %}
>>
>> ?? interface(REG_INTER);
>>
>> %}
>>
>> Please consider this for JDK 14.
>>
>> Best Regards,
>>
>> Sandhya
>>

From sandhya.viswanathan at intel.com  Sat Jan 11 00:25:27 2020
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Sat, 11 Jan 2020 00:25:27 +0000
Subject: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to
 zmm0-zmm15 registers
In-Reply-To: <951f79b5-3418-0803-b1ec-627270cac012@oracle.com>
References: <BYAPR11MB2983D0B14A75B35DC775930AEF380@BYAPR11MB2983.namprd11.prod.outlook.com>
 <c5365a54-a10a-8418-bf04-e13eca7ba12b@oracle.com>
 <951f79b5-3418-0803-b1ec-627270cac012@oracle.com>
Message-ID: <BYAPR11MB298389E605A327CC3C3E7E2AEF3B0@BYAPR11MB2983.namprd11.prod.outlook.com>

Thanks a lot Vladimir! Can I push this onto JDK 14 branch?

Best Regards,
Sandhya


-----Original Message-----
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com> 
Sent: Friday, January 10, 2020 3:39 PM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to zmm0-zmm15 registers

FYI test results are clean (hs-precheckin-comp,hs-tier1,hs-tier2).

Best regards,
Vladimir Ivanov

On 11.01.2020 00:50, Vladimir Ivanov wrote:
> Looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 10.01.2020 22:35, Viswanathan, Sandhya wrote:
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236944
>>
>> Webrev: http://cr.openjdk.java.net/~sviswanathan/8236944/webrev.00/
>>
>> Currently legVecZ operand is defined as follows:
>>
>> operand legVecZ() %{
>>
>> ?? constraint(ALLOC_IN_RC(vectorz_reg_vl));
>>
>> ?? match(VecZ);
>>
>> ?? format %{ %}
>>
>> ?? interface(REG_INTER);
>>
>> %}
>>
>> This allows legVecZ to be zmm0-zmm31 on platforms supporting AVX 512 vl.
>>
>> The legVecZ should instead be defined as:
>>
>> operand legVecZ() %{
>>
>> ?? constraint(ALLOC_IN_RC(vectorz_reg_legacy));
>>
>> ?? match(VecZ);
>>
>> ?? format %{ %}
>>
>> ?? interface(REG_INTER);
>>
>> %}
>>
>> Please consider this for JDK 14.
>>
>> Best Regards,
>>
>> Sandhya
>>

From jatin.bhateja at intel.com  Sun Jan 12 18:12:16 2020
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Sun, 12 Jan 2020 18:12:16 +0000
Subject: [14] RFR(S): 8236443 : Issues with specializing vector register
 type for phi operand with generic operands
In-Reply-To: <be1bfe15-8512-4e8b-774f-a3b3544ad1ce@oracle.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A0E2114@BGSMSX106.gar.corp.intel.com>
 <be1bfe15-8512-4e8b-774f-a3b3544ad1ce@oracle.com>
Message-ID: <A66BBE673E08E1428E3A918AE4D5B32C0A0F9E92@BGSMSX106.gar.corp.intel.com>

Hi Vladimir,

Please find the update patch at below link.

http://cr.openjdk.java.net/~jbhateja/8236443/webrev.04/

Regards,
Jatin

> -----Original Message-----
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: Friday, January 3, 2020 4:46 AM
> To: Bhateja, Jatin <jatin.bhateja at intel.com>; hotspot-compiler-
> dev at openjdk.java.net
> Subject: Re: [14] RFR(S): 8236443 : Issues with specializing vector register type
> for phi operand with generic operands
> 
> Hi Jatin,
> 
> > Webrev: http://cr.openjdk.java.net/~jbhateja/8236443/webrev.02/
> 
> I like that you put the check on use side (ShiftV + ideal_in_idx).
> 
> Though ShiftCntV def is the only viable option in practice (phis shouldn't occur
> on x86 and would trigger a bug due to mismatch between node type and
> ideal_reg), it's nice to see such case being ruled out.
> 
> Some comments:
> 
> ================================================================
> =======
> src/hotspot/cpu/x86/x86.ad:
> 
> +const uint Matcher::special_vector_ideal_reg(int ideal_reg, int opcode,
> int ideal_in_idx, int size) {
> 
> I don't see a compelling reason why it should be a platform-specific
> check. ShiftCntV nodes override Node::ideal_reg() and putting the check
> in shared code looks appropriate.
> 
> Considering how LShiftCntVNode::ideal_reg is defined [1], IMO calling
> Matcher::vector_shift_count_ideal_reg(t->length_in_bytes()) is better
> than hardcoding VecS ideal register (which is x86-specific).
> 
> 
> ================================================================
> =======
> +    case Op_RShiftCntV:
> +    case Op_LShiftCntV:
> +      // Ideal index corrosponding to def operand.
> +      if (ideal_in_idx == -1)
> +        return Op_VecS;
> +      break;
> 
> Shouldn't ideal_in_idx be 0 instead?
> 
> 
> Some stylistic notes:
> 
> ================================================================
> =======
> src/hotspot/cpu/x86/x86.ad:
> 
> +MachOper* Matcher::specialize_vector_operand_helper(Node* m,
> MachNode*
> n, int op_idx) {
> 
> It's a bit confusing to see Node* named "m" and MachNode* named "n". In
> the code base it's usually the opposite: n stands for Node and m stands
> for MachNode.
> 
> But maybe "def" and "use" are better names?
> 
> 
> ================================================================
> =======
> 
> +  switch(opcode) {
> +    default:
> +      return ideal_reg;
> +    case Op_LShiftVB:
> ...
> +    case Op_URShiftVL:
> +      if (ideal_in_idx == 2)
> +        return Op_VecS;
> +      break;
> +    case Op_RShiftCntV:
> +    case Op_LShiftCntV:
> +      // Ideal index corrosponding to def operand.
> +      if (ideal_in_idx == -1)
> +        return Op_VecS;
> +      break;
> +  }
> 
> Does it make sense to introduce ShiftV and ShiftCntV node classes [2]
> and use Node::is_ShiftV()/is_ShiftCntV() checks instead?
> 
> ================================================================
> =======
> 
> +  switch(opcode) {
> +    default:
> +      return ideal_reg;
> ...
> +  }
> +  return ideal_reg;
> 
> return statement is redundant.
> 
> 
> ================================================================
> =======
> 
> src/hotspot/share/opto/matcher.cpp:
> 
> -    MachNode* m = live_nodes.pop()->isa_Mach();
> +    Node* n = live_nodes.pop();
> +    if (!n->is_Mach())
> +      continue;
> +    MachNode * m = n->as_Mach();
>       if (m != NULL) {
> 
> 
> Node::isa_Mach() + != NULL check is a well-established convention in C2
> code base to perform type checks on nodes (is_Mach()+as_Mach()). I'd
> prefer to keep the original version.
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] class LShiftCntVNode : public VectorNode {
>        virtual uint ideal_reg() const { return
> Matcher::vector_shift_count_ideal_reg(vect_type()->length_in_bytes()); }
>      };
> 
> [2]
> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/node.hpp
> #l716
> 
> > Generic operand processing has been skipped for non-machine nodes (e.g.
> Phi) since they are skipped by the matcher.
> > Non-definition operand resolution of a machine node will be able to pull the
> type information from non-machine node.
> >
> > Re-organized the code by adding a target specific routine which can be used
> to return the operand types for special ideal nodes e.g. RShiftCntV/LShiftCntV.
> > For such nodes, definition machine operand vary for different targets and
> vector lengths, a type based generic operand resolution
> > is not possible in such cases.
> >
> > Best Regards,
> > Jatin
> >
> >

From fairoz.matte at oracle.com  Mon Jan 13 06:00:34 2020
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Sun, 12 Jan 2020 22:00:34 -0800 (PST)
Subject: RFR: 8236701: [TESTBUG]
 compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord
Message-ID: <7e5c671e-6fef-46c1-9429-51cafe243c65@default>

Hi 

Please review the small change to fix the test bug.
Changes done to replace SuperWord to UseSuperWord

JBS - https://bugs.openjdk.java.net/browse/JDK-8236701
Webrev - http://cr.openjdk.java.net/~fmatte/8236701/webrev.00/

Thanks,
Fairoz

From tobias.hartmann at oracle.com  Mon Jan 13 06:21:18 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 13 Jan 2020 07:21:18 +0100
Subject: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to
 zmm0-zmm15 registers
In-Reply-To: <BYAPR11MB298389E605A327CC3C3E7E2AEF3B0@BYAPR11MB2983.namprd11.prod.outlook.com>
References: <BYAPR11MB2983D0B14A75B35DC775930AEF380@BYAPR11MB2983.namprd11.prod.outlook.com>
 <c5365a54-a10a-8418-bf04-e13eca7ba12b@oracle.com>
 <951f79b5-3418-0803-b1ec-627270cac012@oracle.com>
 <BYAPR11MB298389E605A327CC3C3E7E2AEF3B0@BYAPR11MB2983.namprd11.prod.outlook.com>
Message-ID: <6fbb3509-c51f-7c52-832a-3af4c992b149@oracle.com>

Hi Sandhya,

looks good to me too. Please push to
http://hg.openjdk.java.net/jdk/jdk14

Thanks,
Tobias

On 11.01.20 01:25, Viswanathan, Sandhya wrote:
> Thanks a lot Vladimir! Can I push this onto JDK 14 branch?
> 
> Best Regards,
> Sandhya
> 
> 
> -----Original Message-----
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com> 
> Sent: Friday, January 10, 2020 3:39 PM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> Subject: Re: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to zmm0-zmm15 registers
> 
> FYI test results are clean (hs-precheckin-comp,hs-tier1,hs-tier2).
> 
> Best regards,
> Vladimir Ivanov
> 
> On 11.01.2020 00:50, Vladimir Ivanov wrote:
>> Looks good.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 10.01.2020 22:35, Viswanathan, Sandhya wrote:
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236944
>>>
>>> Webrev: http://cr.openjdk.java.net/~sviswanathan/8236944/webrev.00/
>>>
>>> Currently legVecZ operand is defined as follows:
>>>
>>> operand legVecZ() %{
>>>
>>> ?? constraint(ALLOC_IN_RC(vectorz_reg_vl));
>>>
>>> ?? match(VecZ);
>>>
>>> ?? format %{ %}
>>>
>>> ?? interface(REG_INTER);
>>>
>>> %}
>>>
>>> This allows legVecZ to be zmm0-zmm31 on platforms supporting AVX 512 vl.
>>>
>>> The legVecZ should instead be defined as:
>>>
>>> operand legVecZ() %{
>>>
>>> ?? constraint(ALLOC_IN_RC(vectorz_reg_legacy));
>>>
>>> ?? match(VecZ);
>>>
>>> ?? format %{ %}
>>>
>>> ?? interface(REG_INTER);
>>>
>>> %}
>>>
>>> Please consider this for JDK 14.
>>>
>>> Best Regards,
>>>
>>> Sandhya
>>>

From ioi.lam at oracle.com  Mon Jan 13 07:21:49 2020
From: ioi.lam at oracle.com (Ioi Lam)
Date: Sun, 12 Jan 2020 23:21:49 -0800
Subject: RFR: 8236701: [TESTBUG]
 compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord
In-Reply-To: <7e5c671e-6fef-46c1-9429-51cafe243c65@default>
References: <7e5c671e-6fef-46c1-9429-51cafe243c65@default>
Message-ID: <1205f0b4-2353-ac86-a519-5fc7ace2a4e5@oracle.com>

Hi Fairoz,

Should the -XX:+IgnoreUnrecognizedVMOptions be removed?

Thanks
- Ioi

On 1/12/20 10:00 PM, Fairoz Matte wrote:
> Hi
>
> Please review the small change to fix the test bug.
> Changes done to replace SuperWord to UseSuperWord
>
> JBS - https://bugs.openjdk.java.net/browse/JDK-8236701
> Webrev - http://cr.openjdk.java.net/~fmatte/8236701/webrev.00/
>
> Thanks,
> Fairoz


From fairoz.matte at oracle.com  Mon Jan 13 08:29:00 2020
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Mon, 13 Jan 2020 00:29:00 -0800 (PST)
Subject: RFR: 8236701: [TESTBUG]
 compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord
In-Reply-To: <1205f0b4-2353-ac86-a519-5fc7ace2a4e5@oracle.com>
References: <7e5c671e-6fef-46c1-9429-51cafe243c65@default>
 <1205f0b4-2353-ac86-a519-5fc7ace2a4e5@oracle.com>
Message-ID: <68c8cbca-4f0e-41cd-bc07-d8f0268e0205@default>

Hi Ioi,

I verified on my Ubuntu linux machine, without the -XX:+IgnoreUnrecognizedVMOptions also test case passes.
I was not sure why that option was added.

Let me know, if that is ok to be removed, I will send the next webrev.

Thanks,
Fairoz

> -----Original Message-----
> From: Ioi Lam
> Sent: Monday, January 13, 2020 12:52 PM
> To: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR: 8236701: [TESTBUG]
> compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-
> SuperWord
> 
> Hi Fairoz,
> 
> Should the -XX:+IgnoreUnrecognizedVMOptions be removed?
> 
> Thanks
> - Ioi
> 
> On 1/12/20 10:00 PM, Fairoz Matte wrote:
> > Hi
> >
> > Please review the small change to fix the test bug.
> > Changes done to replace SuperWord to UseSuperWord
> >
> > JBS - https://bugs.openjdk.java.net/browse/JDK-8236701
> > Webrev - http://cr.openjdk.java.net/~fmatte/8236701/webrev.00/
> >
> > Thanks,
> > Fairoz
> 

From rwestrel at redhat.com  Mon Jan 13 09:58:50 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 13 Jan 2020 10:58:50 +0100
Subject: RFR(S): 8236759: ShouldNotReachHere in
 PhaseIdealLoop::verify_strip_mined_scheduling
Message-ID: <87zher1xut.fsf@redhat.com>


http://cr.openjdk.java.net/~roland/8236759/webrev.00/

Splitting a load thru phi, if the phi is at a strip mined loop head,
causes a load to be pinned at the outer strip mined loop head. That
logic should pin the load above the outer loop instead.

Roland.


From rwestrel at redhat.com  Mon Jan 13 10:20:30 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 13 Jan 2020 11:20:30 +0100
Subject: RFR(S): 8237007: Shenandoah: assert(_base == Tuple) failure during C2
 compilation
Message-ID: <87wo9v1wup.fsf@redhat.com>


http://cr.openjdk.java.net/~roland/8237007/webrev.00/

The assert fails because C2 expands a barrier between a membar and its
control projection. That happens because the gc barrier is assigned the
membar as control by loop optimizations (and not its control
projection). The gc barrier has a load as input which itself depends on
the memory state produced by the membar so the barrier has to be below
the membar. The gc barrier has a CMove as use. That CMove has a control
input that's above the membar and because it's considered pinned by loop
opts, it's assigned earliest possible control: the membar. Considering
the CMove as pinned is overly conservative AFAICT. My fix consists in
excluding CMove nodes from being pinned.

Roland.


From rwestrel at redhat.com  Mon Jan 13 10:54:26 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 13 Jan 2020 11:54:26 +0100
Subject: RFR(S): 8235584: UseProfiledLoopPredicate fails with
 assert(_phase->get_loop(c) == loop) failed: have to be in the same loop
Message-ID: <87r2031va5.fsf@redhat.com>


http://cr.openjdk.java.net/~roland/8235584/webrev.00/

This is related to 8235452. As explained by Tobias:

https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-December/036344.html

a strip mined loop is transformed so the CountedLoopEnd and the outer
strip mined loop are optimized out. There's still a loop but it's not
longer strip mined and not even a valid counted loop anymore but it
stays a CountedLoopNode with the strip mined flag set to true.

The loop predication code fails with an assert because when it
encounters the CountedLoop, the call to skip_strip_mined() sees it's
flagged as strip mined so it needs to skip the outer strip mined loop
but because the CountedLoop is no longer strip mined, it skips some
control that are not the outer loop. The fix is to check both whether
the loop is flagged as strip mined and a valid counted loop in
skip_strip_mined().

Also, the fix that Tobias pushed for 8235452 erroneously disabled
verification for the outer strip mined loop. This change restores it.

Roland.


From rwestrel at redhat.com  Mon Jan 13 11:05:56 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 13 Jan 2020 12:05:56 +0100
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <9f364210-53e4-0b4d-df3e-a02aa5219cb0@oracle.com>
References: <87o8w8ptsq.fsf@redhat.com>
 <da3150a6-8303-894c-be9c-c90298f7de7d@oracle.com> <8736dfkko7.fsf@redhat.com>
 <7bc32dc2-1612-cb77-a467-ac67987b148c@oracle.com> <87woa35ijf.fsf@redhat.com>
 <9f364210-53e4-0b4d-df3e-a02aa5219cb0@oracle.com>
Message-ID: <87o8v71uqz.fsf@redhat.com>


> Do you know why RootNode::Ideal() isn't called during IGVN pass after 
> parsing is over?

The root node would need to be enqueued in the igvn worklist during
parsing. The code pattern when an HaltNode is added to the graph is to
use add_req() which doesn't cause the root node to be put on the igvn
worklist.

Roland.


From patric.hedlin at oracle.com  Mon Jan 13 11:11:56 2020
From: patric.hedlin at oracle.com (Patric Hedlin)
Date: Mon, 13 Jan 2020 12:11:56 +0100
Subject: RFR(XS): 8235870: C2 crashes in
 IdealLoopTree::est_loop_flow_merge_sz()
Message-ID: <1f4bd3ac-8a0f-3d77-677b-1bdbdbaa49a2@oracle.com>

Dear all,

I would like to ask for help to review the following change/update:

Issue:? https://bugs.openjdk.java.net/browse/JDK-8235870
Webrev: http://cr.openjdk.java.net/~phedlin/tr8235870/

8235870: C2 crashes in IdealLoopTree::est_loop_flow_merge_sz()

 ??? Method missing necessary checks, made more robust.

Testing: hs-tier1-3, LuceneBench24H


Best regards,
Patric


From tobias.hartmann at oracle.com  Mon Jan 13 11:27:46 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 13 Jan 2020 12:27:46 +0100
Subject: RFR(S): 8235762: JVM crash in SWPointer during C2 compilation
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE3DECF6D@dggeml507-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DD8064@dggeml527-mbx.china.huawei.com>
 <e10a10b9-78ad-5ff7-5b55-571b7feae324@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD80DB@dggeml527-mbx.china.huawei.com>
 <4ef39906-839b-9a08-3225-f99b974f08de@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD8325@dggeml527-mbx.china.huawei.com>
 <d429870d-248e-bbb6-d296-d373c7e5affd@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD88F1@dggeml527-mbx.china.huawei.com>
 <4103e17e-57c4-ed78-bf64-1bb3cb99e9f4@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DECF6D@dggeml507-mbx.china.huawei.com>
Message-ID: <8797205a-c4ff-253d-404b-62a178c6e169@oracle.com>

Hi Felix,

looks reasonable to me. Thanks for updating.

Another review would be good.

Best regards,
Tobias

On 10.01.20 02:13, Yangfei (Felix) wrote:
> Hi Tobias,
> 
>   Updated webrev: http://cr.openjdk.java.net/~fyang/8235762/webrev.01/ 
>   This also updated copyright years of the newly-added test case.  
>   Still test OK with the latest repo.  Is this one better?  
> 
> Thanks,
> Felix
> 
>>
>> Hi Felix,
>>
>> On 16.12.19 11:14, Yangfei (Felix) wrote:
>>> -- OK.  I will add one assertion immediately before breaking the loop.
>>
>> Thanks.
>>
>>>> - Why do you need max_idx? Isn't is the case that if
>>>> find_align_to_ref returns NULL, there aren't any comparable memory
>>>> operations left and it essentially doesn't matter which one you chose?
>>>
>>> -- I was considering minimizing the performance impact of the patch here.
>>>   best_align_to_mem_ref is used in SuperWord::align_initial_loop_index for
>> adjusting the pre-loop limit.
>>>   For the test case in the webrev, best_align_to_mem_ref was chosen from
>> node 470 (StoreB) and node 431 (StoreL).
>>>   The vector width for these two memory operations are different on
>> aarch64 platform: vw = 16 bytes for node 431 and 2 bytes for node 470.
>>>   SuperWord::align_initial_loop_index will emit different code sequences for
>> the test case.
>>>   The max_idx tells us which memory operation has the biggest vector size.
>>
>> Okay, thanks for the details. Could you add a comment that explains this?
>>
>>>> Also, is it guaranteed that max_idx is always initialized in
>> SuperWord::find_align_to_ref?
>>>
>>> -- Yes, I think so.
>>>   When memops is not empty and the memory ops in memops are not
>> comparable, find_align_to_ref will always sets its max_idx.
>>
>> Okay.
>>
>> Thanks,
>> Tobias

From tobias.hartmann at oracle.com  Mon Jan 13 11:29:50 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 13 Jan 2020 12:29:50 +0100
Subject: RFR: 8236701: [TESTBUG]
 compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord
In-Reply-To: <68c8cbca-4f0e-41cd-bc07-d8f0268e0205@default>
References: <7e5c671e-6fef-46c1-9429-51cafe243c65@default>
 <1205f0b4-2353-ac86-a519-5fc7ace2a4e5@oracle.com>
 <68c8cbca-4f0e-41cd-bc07-d8f0268e0205@default>
Message-ID: <7ad3ddcb-b2d2-d815-a2f6-192612da9abc@oracle.com>

Hi Fairoz,

On 13.01.20 09:29, Fairoz Matte wrote:
> I was not sure why that option was added.

I think it's just because the author incorrectly assumed that some of the flags sre only available
in debug builds (which is not the case).

> Let me know, if that is ok to be removed, I will send the next webrev.

Yes, please do so. The change looks good to me.

Thanks,
Tobias

From tobias.hartmann at oracle.com  Mon Jan 13 11:30:53 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 13 Jan 2020 12:30:53 +0100
Subject: RFR: 8236701: [TESTBUG]
 compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord
In-Reply-To: <7ad3ddcb-b2d2-d815-a2f6-192612da9abc@oracle.com>
References: <7e5c671e-6fef-46c1-9429-51cafe243c65@default>
 <1205f0b4-2353-ac86-a519-5fc7ace2a4e5@oracle.com>
 <68c8cbca-4f0e-41cd-bc07-d8f0268e0205@default>
 <7ad3ddcb-b2d2-d815-a2f6-192612da9abc@oracle.com>
Message-ID: <8f0d6d6c-927e-6b9e-6213-3274a099d288@oracle.com>

Please also update the copyright.

Best regards,
Tobias

On 13.01.20 12:29, Tobias Hartmann wrote:
> Hi Fairoz,
> 
> On 13.01.20 09:29, Fairoz Matte wrote:
>> I was not sure why that option was added.
> 
> I think it's just because the author incorrectly assumed that some of the flags sre only available
> in debug builds (which is not the case).
> 
>> Let me know, if that is ok to be removed, I will send the next webrev.
> 
> Yes, please do so. The change looks good to me.
> 
> Thanks,
> Tobias
> 

From tobias.hartmann at oracle.com  Mon Jan 13 11:32:47 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 13 Jan 2020 12:32:47 +0100
Subject: RFR(XS): 8235870: C2 crashes in
 IdealLoopTree::est_loop_flow_merge_sz()
In-Reply-To: <1f4bd3ac-8a0f-3d77-677b-1bdbdbaa49a2@oracle.com>
References: <1f4bd3ac-8a0f-3d77-677b-1bdbdbaa49a2@oracle.com>
Message-ID: <3581fc6c-ca0d-597d-c702-f52a4a599172@oracle.com>

Hi Patric,

looks good and trivial to me.

Best regards,
Tobias

On 13.01.20 12:11, Patric Hedlin wrote:
> Dear all,
> 
> I would like to ask for help to review the following change/update:
> 
> Issue:? https://bugs.openjdk.java.net/browse/JDK-8235870
> Webrev: http://cr.openjdk.java.net/~phedlin/tr8235870/
> 
> 8235870: C2 crashes in IdealLoopTree::est_loop_flow_merge_sz()
> 
> ??? Method missing necessary checks, made more robust.
> 
> Testing: hs-tier1-3, LuceneBench24H
> 
> 
> Best regards,
> Patric
> 

From tobias.hartmann at oracle.com  Mon Jan 13 11:46:32 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 13 Jan 2020 12:46:32 +0100
Subject: RFR(S): 8235584: UseProfiledLoopPredicate fails with
 assert(_phase->get_loop(c) == loop) failed: have to be in the same loop
In-Reply-To: <87r2031va5.fsf@redhat.com>
References: <87r2031va5.fsf@redhat.com>
Message-ID: <1a4c0874-946b-aea3-fe83-ac5e2b9f1862@oracle.com>

Hi Roland,

On 13.01.20 11:54, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8235584/webrev.00/

Looks good to me.

> Also, the fix that Tobias pushed for 8235452 erroneously disabled
> verification for the outer strip mined loop. This change restores it.

Thanks for fixing. We should get this into JDK 14.

Best regards,
Tobias

From tobias.hartmann at oracle.com  Mon Jan 13 12:10:44 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 13 Jan 2020 13:10:44 +0100
Subject: RFR(S): 8236759: ShouldNotReachHere in
 PhaseIdealLoop::verify_strip_mined_scheduling
In-Reply-To: <87zher1xut.fsf@redhat.com>
References: <87zher1xut.fsf@redhat.com>
Message-ID: <aa8cab76-14b6-d55e-a533-9001697990e5@oracle.com>

Hi Roland,

On 13.01.20 10:58, Roland Westrelin wrote:
> Splitting a load thru phi, if the phi is at a strip mined loop head,
> causes a load to be pinned at the outer strip mined loop head. That
> logic should pin the load above the outer loop instead.

Just wondering why you need the checks in line 1487? Isn't in->is_OuterStripMinedLoop() sufficient
since we should never schedule a data node in the outer strip mined loop?

Best regards,
Tobias

From vladimir.x.ivanov at oracle.com  Mon Jan 13 12:17:41 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 13 Jan 2020 15:17:41 +0300
Subject: [14] RFR(S): 8236443 : Issues with specializing vector register
 type for phi operand with generic operands
In-Reply-To: <A66BBE673E08E1428E3A918AE4D5B32C0A0F9E92@BGSMSX106.gar.corp.intel.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A0E2114@BGSMSX106.gar.corp.intel.com>
 <be1bfe15-8512-4e8b-774f-a3b3544ad1ce@oracle.com>
 <A66BBE673E08E1428E3A918AE4D5B32C0A0F9E92@BGSMSX106.gar.corp.intel.com>
Message-ID: <6e7ecab1-e174-2c3d-50c3-92de6e1cfa67@oracle.com>


> http://cr.openjdk.java.net/~jbhateja/8236443/webrev.04/

Looks good.

Test results are clean (hs-precheckin-comp,hs-tier1,hs-tier2).

Best regards,
Vladimir Ivanov

> 
> Regards,
> Jatin
> 
>> -----Original Message-----
>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>> Sent: Friday, January 3, 2020 4:46 AM
>> To: Bhateja, Jatin <jatin.bhateja at intel.com>; hotspot-compiler-
>> dev at openjdk.java.net
>> Subject: Re: [14] RFR(S): 8236443 : Issues with specializing vector register type
>> for phi operand with generic operands
>>
>> Hi Jatin,
>>
>>> Webrev: http://cr.openjdk.java.net/~jbhateja/8236443/webrev.02/
>>
>> I like that you put the check on use side (ShiftV + ideal_in_idx).
>>
>> Though ShiftCntV def is the only viable option in practice (phis shouldn't occur
>> on x86 and would trigger a bug due to mismatch between node type and
>> ideal_reg), it's nice to see such case being ruled out.
>>
>> Some comments:
>>
>> ================================================================
>> =======
>> src/hotspot/cpu/x86/x86.ad:
>>
>> +const uint Matcher::special_vector_ideal_reg(int ideal_reg, int opcode,
>> int ideal_in_idx, int size) {
>>
>> I don't see a compelling reason why it should be a platform-specific
>> check. ShiftCntV nodes override Node::ideal_reg() and putting the check
>> in shared code looks appropriate.
>>
>> Considering how LShiftCntVNode::ideal_reg is defined [1], IMO calling
>> Matcher::vector_shift_count_ideal_reg(t->length_in_bytes()) is better
>> than hardcoding VecS ideal register (which is x86-specific).
>>
>>
>> ================================================================
>> =======
>> +    case Op_RShiftCntV:
>> +    case Op_LShiftCntV:
>> +      // Ideal index corrosponding to def operand.
>> +      if (ideal_in_idx == -1)
>> +        return Op_VecS;
>> +      break;
>>
>> Shouldn't ideal_in_idx be 0 instead?
>>
>>
>> Some stylistic notes:
>>
>> ================================================================
>> =======
>> src/hotspot/cpu/x86/x86.ad:
>>
>> +MachOper* Matcher::specialize_vector_operand_helper(Node* m,
>> MachNode*
>> n, int op_idx) {
>>
>> It's a bit confusing to see Node* named "m" and MachNode* named "n". In
>> the code base it's usually the opposite: n stands for Node and m stands
>> for MachNode.
>>
>> But maybe "def" and "use" are better names?
>>
>>
>> ================================================================
>> =======
>>
>> +  switch(opcode) {
>> +    default:
>> +      return ideal_reg;
>> +    case Op_LShiftVB:
>> ...
>> +    case Op_URShiftVL:
>> +      if (ideal_in_idx == 2)
>> +        return Op_VecS;
>> +      break;
>> +    case Op_RShiftCntV:
>> +    case Op_LShiftCntV:
>> +      // Ideal index corrosponding to def operand.
>> +      if (ideal_in_idx == -1)
>> +        return Op_VecS;
>> +      break;
>> +  }
>>
>> Does it make sense to introduce ShiftV and ShiftCntV node classes [2]
>> and use Node::is_ShiftV()/is_ShiftCntV() checks instead?
>>
>> ================================================================
>> =======
>>
>> +  switch(opcode) {
>> +    default:
>> +      return ideal_reg;
>> ...
>> +  }
>> +  return ideal_reg;
>>
>> return statement is redundant.
>>
>>
>> ================================================================
>> =======
>>
>> src/hotspot/share/opto/matcher.cpp:
>>
>> -    MachNode* m = live_nodes.pop()->isa_Mach();
>> +    Node* n = live_nodes.pop();
>> +    if (!n->is_Mach())
>> +      continue;
>> +    MachNode * m = n->as_Mach();
>>        if (m != NULL) {
>>
>>
>> Node::isa_Mach() + != NULL check is a well-established convention in C2
>> code base to perform type checks on nodes (is_Mach()+as_Mach()). I'd
>> prefer to keep the original version.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] class LShiftCntVNode : public VectorNode {
>>         virtual uint ideal_reg() const { return
>> Matcher::vector_shift_count_ideal_reg(vect_type()->length_in_bytes()); }
>>       };
>>
>> [2]
>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/node.hpp
>> #l716
>>
>>> Generic operand processing has been skipped for non-machine nodes (e.g.
>> Phi) since they are skipped by the matcher.
>>> Non-definition operand resolution of a machine node will be able to pull the
>> type information from non-machine node.
>>>
>>> Re-organized the code by adding a target specific routine which can be used
>> to return the operand types for special ideal nodes e.g. RShiftCntV/LShiftCntV.
>>> For such nodes, definition machine operand vary for different targets and
>> vector lengths, a type based generic operand resolution
>>> is not possible in such cases.
>>>
>>> Best Regards,
>>> Jatin
>>>
>>>

From vladimir.x.ivanov at oracle.com  Mon Jan 13 12:23:12 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 13 Jan 2020 15:23:12 +0300
Subject: RFR(XS): 8229855: C2 fails with assert(false) failed: bad AD file
In-Reply-To: <790571f6-2a0e-613f-ebc8-0317f4a8f50c@oracle.com>
References: <790571f6-2a0e-613f-ebc8-0317f4a8f50c@oracle.com>
Message-ID: <7c3f6220-dd80-78f2-9c92-2003eafe2ea9@oracle.com>


> http://cr.openjdk.java.net/~thartmann/8229855/webrev.00/

-        IfNode *iff_le  = jump_if_fork_int(key_val, test_val, 
BoolTest::le, if_prob(cnt, total_cnt), if_cnt(cnt));
+        IfNode *iff_le  = jump_if_fork_int(key_val, test_val, 
BoolTest::lt, if_prob(cnt, total_cnt), if_cnt(cnt));

Would be nice to rename iff_le to iff_lt as well.

Otherwise, looks good.

Best regards,
Vladimir Ivanov

> For the switch statement in TestJumpTable.java, C2 creates the following binary search tree with a
> jump table at (*):
> 
> if (key_val > 45) {
>    if (key_val != 60) {
>      if (key_val <= 60) {
>        (*)
>      } else {
>        [...]
>      }
>    } else {
>      [...]
>    }
> } else {
>    [...]
> }
> 
> The jump table at (*) handles the following key_val ranges: {46..50}, {51}, {52..59}.
> Parse::jump_switch_ranges -> Parse::create_jump_tables adds a CastII to narrow the type of key_val
> to type int:46..59 (type int:0..13 after normalizing to zero):
> http://hg.openjdk.java.net/jdk/jdk/file/44cb1f517839/src/hotspot/share/opto/parse2.cpp#l884
> 
> Now after some rounds of loop unrolling, key_val is known to be int:60..260 (normalized to
> int:14..214) in one of the loop bodies. As a result, the narrow CastII node is replaced by TOP and
> we crash in the matcher because the JumpNode user didn't go away.
> 
> The problem is that the key_val != 60 && key_val <= 60 combination is *not* found to be always false
> if key_val becomes known as int:60..260 because C2's type system does not narrow the type after the
> first check. The fix is to simply strengthen the second check to ensure that both control and data
> paths die consistently.
> 
> I would like to push this simple fix into JDK 14 and follow-up in JDK 15 with an enhancement that
> adds a general optimization for such integer checks:
> https://bugs.openjdk.java.net/browse/JDK-8236721
> 
> I've quickly hacked a prototype that shows promising results (and would also fix this issue):
> http://cr.openjdk.java.net/~thartmann/8236721/webrev.00/
> 
> Thanks,
> Tobias
> 

From rwestrel at redhat.com  Mon Jan 13 12:28:54 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 13 Jan 2020 13:28:54 +0100
Subject: RFR(S): 8235584: UseProfiledLoopPredicate fails with
 assert(_phase->get_loop(c) == loop) failed: have to be in the same loop
In-Reply-To: <1a4c0874-946b-aea3-fe83-ac5e2b9f1862@oracle.com>
References: <87r2031va5.fsf@redhat.com>
 <1a4c0874-946b-aea3-fe83-ac5e2b9f1862@oracle.com>
Message-ID: <87imlf1qwp.fsf@redhat.com>


Thanks for the review, Tobias.

Roland.


From rwestrel at redhat.com  Mon Jan 13 12:30:45 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 13 Jan 2020 13:30:45 +0100
Subject: RFR(S): 8236759: ShouldNotReachHere in
 PhaseIdealLoop::verify_strip_mined_scheduling
In-Reply-To: <aa8cab76-14b6-d55e-a533-9001697990e5@oracle.com>
References: <87zher1xut.fsf@redhat.com>
 <aa8cab76-14b6-d55e-a533-9001697990e5@oracle.com>
Message-ID: <87ftgj1qtm.fsf@redhat.com>


Thanks for reviewing this, Tobias.

> Just wondering why you need the checks in line 1487? Isn't in->is_OuterStripMinedLoop() sufficient
> since we should never schedule a data node in the outer strip mined loop?

It could be top too. Also I guess, I'm becoming paranoid about little
things going wrong with strip mining...

Roland.


From patric.hedlin at oracle.com  Mon Jan 13 12:31:24 2020
From: patric.hedlin at oracle.com (Patric Hedlin)
Date: Mon, 13 Jan 2020 13:31:24 +0100
Subject: RFR(XS): 8235870: C2 crashes in
 IdealLoopTree::est_loop_flow_merge_sz()
In-Reply-To: <3581fc6c-ca0d-597d-c702-f52a4a599172@oracle.com>
References: <1f4bd3ac-8a0f-3d77-677b-1bdbdbaa49a2@oracle.com>
 <3581fc6c-ca0d-597d-c702-f52a4a599172@oracle.com>
Message-ID: <d6089198-6beb-a09a-0bdc-c861f1865c46@oracle.com>

Thanks for reviewing Tobias.

/Patric

On 13/01/2020 12:32, Tobias Hartmann wrote:
> Hi Patric,
>
> looks good and trivial to me.
>
> Best regards,
> Tobias
>
> On 13.01.20 12:11, Patric Hedlin wrote:
>> Dear all,
>>
>> I would like to ask for help to review the following change/update:
>>
>> Issue:? https://bugs.openjdk.java.net/browse/JDK-8235870
>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8235870/
>>
>> 8235870: C2 crashes in IdealLoopTree::est_loop_flow_merge_sz()
>>
>>  ??? Method missing necessary checks, made more robust.
>>
>> Testing: hs-tier1-3, LuceneBench24H
>>
>>
>> Best regards,
>> Patric

From tobias.hartmann at oracle.com  Mon Jan 13 12:33:24 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 13 Jan 2020 13:33:24 +0100
Subject: RFR(XS): 8229855: C2 fails with assert(false) failed: bad AD file
In-Reply-To: <7c3f6220-dd80-78f2-9c92-2003eafe2ea9@oracle.com>
References: <790571f6-2a0e-613f-ebc8-0317f4a8f50c@oracle.com>
 <7c3f6220-dd80-78f2-9c92-2003eafe2ea9@oracle.com>
Message-ID: <721d5f78-a08c-4978-ae65-97c454cc4f85@oracle.com>

Hi Vladimir,

On 13.01.20 13:23, Vladimir Ivanov wrote:
> Would be nice to rename iff_le to iff_lt as well.

Good catch, I'll adjust that before pushing.

> Otherwise, looks good.

Thanks for the review!

Best regards,
Tobias

From nils.eliasson at oracle.com  Mon Jan 13 12:36:22 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 13 Jan 2020 13:36:22 +0100
Subject: RFR(XS): 8235870: C2 crashes in
 IdealLoopTree::est_loop_flow_merge_sz()
In-Reply-To: <1f4bd3ac-8a0f-3d77-677b-1bdbdbaa49a2@oracle.com>
References: <1f4bd3ac-8a0f-3d77-677b-1bdbdbaa49a2@oracle.com>
Message-ID: <2edeb499-a777-6e92-9b7b-3977de94d68e@oracle.com>

Hi Patrick,

Looks good!

Regards,
Nils Eliasson

On 2020-01-13 12:11, Patric Hedlin wrote:
> Dear all,
>
> I would like to ask for help to review the following change/update:
>
> Issue:? https://bugs.openjdk.java.net/browse/JDK-8235870
> Webrev: http://cr.openjdk.java.net/~phedlin/tr8235870/
>
> 8235870: C2 crashes in IdealLoopTree::est_loop_flow_merge_sz()
>
> ??? Method missing necessary checks, made more robust.
>
> Testing: hs-tier1-3, LuceneBench24H
>
>
> Best regards,
> Patric
>


From vladimir.x.ivanov at oracle.com  Mon Jan 13 14:00:47 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 13 Jan 2020 17:00:47 +0300
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <87o8v71uqz.fsf@redhat.com>
References: <87o8w8ptsq.fsf@redhat.com>
 <da3150a6-8303-894c-be9c-c90298f7de7d@oracle.com> <8736dfkko7.fsf@redhat.com>
 <7bc32dc2-1612-cb77-a467-ac67987b148c@oracle.com> <87woa35ijf.fsf@redhat.com>
 <9f364210-53e4-0b4d-df3e-a02aa5219cb0@oracle.com> <87o8v71uqz.fsf@redhat.com>
Message-ID: <467329e0-10e7-3dfa-ab4c-9f011630a756@oracle.com>


>> Do you know why RootNode::Ideal() isn't called during IGVN pass after
>> parsing is over?
> 
> The root node would need to be enqueued in the igvn worklist during
> parsing. The code pattern when an HaltNode is added to the graph is to
> use add_req() which doesn't cause the root node to be put on the igvn
> worklist.

I think the right way to fix the bug is to transform HaltNode after it 
is added to RootNode (e.g., as done in AllocateArrayNode::Ideal() [1]).
In case HaltNode is eliminiated, RootNode should be put on worklist.

I'm fine with leaving your change in GraphKit::must_be_not_null() as is.
With the shortcut it becomes easier to read without double-checking how 
Opaque4 behaves.

I quickly looked through other places with the same idiom and 
MemNode::Ideal_common() looks suspicious [3]. I don't see how it can 
suffer from the same problem, but it would be nice to fix it as well. 
I'm fine with filing a separate bug for it.

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/callnode.cpp#l1445

[2] ifnode.cpp:1234:         igvn->C->root()->add_req(halt);
     loopTransform.cpp:1271:  C->root()->add_req(halt);
     loopTransform.cpp:2434:  C->root()->add_req(halt);
     callnode.cpp:1447:       phase->C->root()->add_req(halt);
     loopnode.cpp:3676:       C->root()->add_req(halt);
     memnode.cpp:343:         phase->C->root()->add_req(halt);
     graphKit.cpp:1417:       C->root()->add_req(halt);

[3] 
http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/memnode.cpp#l342

From rwestrel at redhat.com  Mon Jan 13 15:25:28 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 13 Jan 2020 16:25:28 +0100
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <467329e0-10e7-3dfa-ab4c-9f011630a756@oracle.com>
References: <87o8w8ptsq.fsf@redhat.com>
 <da3150a6-8303-894c-be9c-c90298f7de7d@oracle.com> <8736dfkko7.fsf@redhat.com>
 <7bc32dc2-1612-cb77-a467-ac67987b148c@oracle.com> <87woa35ijf.fsf@redhat.com>
 <9f364210-53e4-0b4d-df3e-a02aa5219cb0@oracle.com> <87o8v71uqz.fsf@redhat.com>
 <467329e0-10e7-3dfa-ab4c-9f011630a756@oracle.com>
Message-ID: <87blr71iqf.fsf@redhat.com>


> I think the right way to fix the bug is to transform HaltNode after it 
> is added to RootNode (e.g., as done in AllocateArrayNode::Ideal() [1]).
> In case HaltNode is eliminiated, RootNode should be put on worklist.

AFAICT, that would not work. PhaseGVN::transform() doesn't change uses
of the node being transformed. The RootNode would need to be explicity
pushed on the igvn worklist with a call to
Compile::record_for_igvn(). But with the change to must_be_not_null(),
there's no need for that. So I don't see anything that need fixing to be
honest.

> I quickly looked through other places with the same idiom and 
> MemNode::Ideal_common() looks suspicious [3]. I don't see how it can 
> suffer from the same problem, but it would be nice to fix it as well. 
> I'm fine with filing a separate bug for it.

For the Halt node to be top, ctl would need to be top but that's handled
before or frame would need to be top which doesn't seem possible so I
don't see a problem there.

Roland.


From fairoz.matte at oracle.com  Mon Jan 13 15:53:08 2020
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Mon, 13 Jan 2020 07:53:08 -0800 (PST)
Subject: RFR: 8236701: [TESTBUG]
 compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord
In-Reply-To: <8f0d6d6c-927e-6b9e-6213-3274a099d288@oracle.com>
References: <7e5c671e-6fef-46c1-9429-51cafe243c65@default>
 <1205f0b4-2353-ac86-a519-5fc7ace2a4e5@oracle.com>
 <68c8cbca-4f0e-41cd-bc07-d8f0268e0205@default>
 <7ad3ddcb-b2d2-d815-a2f6-192612da9abc@oracle.com>
 <8f0d6d6c-927e-6b9e-6213-3274a099d288@oracle.com>
Message-ID: <015d7aac-a487-41bb-a0c4-d51f58b9f85d@default>

Hi Tobias,

Thanks for the review,
It does look like we still need "-XX:+IgnoreUnrecognizedVMOptions" flag.

Summary of the test case shows,  Superword support is only for limited platforms.

* @summary Add C2 x86 Superword support for VNNI VPDPWSSD Instruction
* @requires os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64"

I have updated copyright.

Thanks,
Fairoz

-----Original Message-----
From: Tobias Hartmann 
Sent: Monday, January 13, 2020 5:01 PM
To: Fairoz Matte <fairoz.matte at oracle.com>; Ioi Lam <ioi.lam at oracle.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR: 8236701: [TESTBUG] compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord

Please also update the copyright.

Best regards,
Tobias

On 13.01.20 12:29, Tobias Hartmann wrote:
> Hi Fairoz,
> 
> On 13.01.20 09:29, Fairoz Matte wrote:
>> I was not sure why that option was added.
> 
> I think it's just because the author incorrectly assumed that some of 
> the flags sre only available in debug builds (which is not the case).
> 
>> Let me know, if that is ok to be removed, I will send the next webrev.
> 
> Yes, please do so. The change looks good to me.
> 
> Thanks,
> Tobias
> 

From sandhya.viswanathan at intel.com  Mon Jan 13 16:29:45 2020
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Mon, 13 Jan 2020 16:29:45 +0000
Subject: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to
 zmm0-zmm15 registers
In-Reply-To: <6fbb3509-c51f-7c52-832a-3af4c992b149@oracle.com>
References: <BYAPR11MB2983D0B14A75B35DC775930AEF380@BYAPR11MB2983.namprd11.prod.outlook.com>
 <c5365a54-a10a-8418-bf04-e13eca7ba12b@oracle.com>
 <951f79b5-3418-0803-b1ec-627270cac012@oracle.com>
 <BYAPR11MB298389E605A327CC3C3E7E2AEF3B0@BYAPR11MB2983.namprd11.prod.outlook.com>
 <6fbb3509-c51f-7c52-832a-3af4c992b149@oracle.com>
Message-ID: <CY4PR11MB131719F78120D869A049B7DDEF350@CY4PR11MB1317.namprd11.prod.outlook.com>

Pushed to http://hg.openjdk.java.net/jdk/jdk14.

Thanks,
Sandhya

-----Original Message-----
From: Tobias Hartmann <tobias.hartmann at oracle.com> 
Sent: Sunday, January 12, 2020 10:21 PM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Vladimir Ivanov <vladimir.x.ivanov at oracle.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to zmm0-zmm15 registers

Hi Sandhya,

looks good to me too. Please push to
http://hg.openjdk.java.net/jdk/jdk14

Thanks,
Tobias

On 11.01.20 01:25, Viswanathan, Sandhya wrote:
> Thanks a lot Vladimir! Can I push this onto JDK 14 branch?
> 
> Best Regards,
> Sandhya
> 
> 
> -----Original Message-----
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com> 
> Sent: Friday, January 10, 2020 3:39 PM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> Subject: Re: [14]: RFR(XXS): 8236944:The legVecZ operand should be limited to zmm0-zmm15 registers
> 
> FYI test results are clean (hs-precheckin-comp,hs-tier1,hs-tier2).
> 
> Best regards,
> Vladimir Ivanov
> 
> On 11.01.2020 00:50, Vladimir Ivanov wrote:
>> Looks good.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 10.01.2020 22:35, Viswanathan, Sandhya wrote:
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236944
>>>
>>> Webrev: http://cr.openjdk.java.net/~sviswanathan/8236944/webrev.00/
>>>
>>> Currently legVecZ operand is defined as follows:
>>>
>>> operand legVecZ() %{
>>>
>>> ?? constraint(ALLOC_IN_RC(vectorz_reg_vl));
>>>
>>> ?? match(VecZ);
>>>
>>> ?? format %{ %}
>>>
>>> ?? interface(REG_INTER);
>>>
>>> %}
>>>
>>> This allows legVecZ to be zmm0-zmm31 on platforms supporting AVX 512 vl.
>>>
>>> The legVecZ should instead be defined as:
>>>
>>> operand legVecZ() %{
>>>
>>> ?? constraint(ALLOC_IN_RC(vectorz_reg_legacy));
>>>
>>> ?? match(VecZ);
>>>
>>> ?? format %{ %}
>>>
>>> ?? interface(REG_INTER);
>>>
>>> %}
>>>
>>> Please consider this for JDK 14.
>>>
>>> Best Regards,
>>>
>>> Sandhya
>>>

From vladimir.x.ivanov at oracle.com  Mon Jan 13 17:03:03 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 13 Jan 2020 20:03:03 +0300
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <87blr71iqf.fsf@redhat.com>
References: <87o8w8ptsq.fsf@redhat.com>
 <da3150a6-8303-894c-be9c-c90298f7de7d@oracle.com> <8736dfkko7.fsf@redhat.com>
 <7bc32dc2-1612-cb77-a467-ac67987b148c@oracle.com> <87woa35ijf.fsf@redhat.com>
 <9f364210-53e4-0b4d-df3e-a02aa5219cb0@oracle.com> <87o8v71uqz.fsf@redhat.com>
 <467329e0-10e7-3dfa-ab4c-9f011630a756@oracle.com> <87blr71iqf.fsf@redhat.com>
Message-ID: <580b9af0-1523-0cde-9b29-e09278e2fa1c@oracle.com>


>> I think the right way to fix the bug is to transform HaltNode after it
>> is added to RootNode (e.g., as done in AllocateArrayNode::Ideal() [1]).
>> In case HaltNode is eliminiated, RootNode should be put on worklist.
> 
> AFAICT, that would not work. PhaseGVN::transform() doesn't change uses
> of the node being transformed. The RootNode would need to be explicity
> pushed on the igvn worklist with a call to
> Compile::record_for_igvn(). But with the change to must_be_not_null(),
> there's no need for that. So I don't see anything that need fixing to be
> honest.

Yes, you are right. PhaseGVN::transform() doesn't register existing 
users for IGVN and the only way to make it work is to explicitly 
register RootNode when a HaltNode goes dead.

I understand that the change you have is enough to avoid the problematic 
case in GraphKit::must_be_not_null(). What I'd like to get rid of is the 
need for a correctness check to ensure that HaltNode can't go away. It's 
error-prone and can eventually get out of sync.

If you think it doesn't worth the effort, feel free to proceed with the 
current fix and I'll file a followup RFE.

Also, I'd like the bug to be handled separately (from 8231291). It'll 
simplify possible backporting: as I see from the history, the 
problematic code (JDK-8176506) was introduced in 10 and it may show up 
in 11u eventually.

>> I quickly looked through other places with the same idiom and
>> MemNode::Ideal_common() looks suspicious [3]. I don't see how it can
>> suffer from the same problem, but it would be nice to fix it as well.
>> I'm fine with filing a separate bug for it.
> 
> For the Halt node to be top, ctl would need to be top but that's handled
> before or frame would need to be top which doesn't seem possible so I
> don't see a problem there.

My point is it would be nice to avoid the need in such reasoning 
(especially for correctness purposes) in the first place.

Best regards,
Vladimir Ivanov

From hohensee at amazon.com  Mon Jan 13 22:53:50 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 13 Jan 2020 22:53:50 +0000
Subject: RFR(XXS): 8236228: clean up BarrierSet headers in c1_LIRAssembler
In-Reply-To: <EBF6337B-2C95-417C-9DB0-6C972EB66251@amazon.com>
References: <1982726B-9702-4087-B962-354D2B9FAD92@amazon.com>
 <VE1PR08MB5053E9D17314A06E5549522890280@VE1PR08MB5053.eurprd08.prod.outlook.com>
 <3C45D717-C0BF-40A4-93F5-EDA78FE91350@amazon.com>
 <3CC88DEC-56BE-4FDA-B775-7678F44E252A@amazon.com>
 <EBF6337B-2C95-417C-9DB0-6C972EB66251@amazon.com>
Message-ID: <2CDFB80B-04EA-4C95-A67A-1C1284C80C66@amazon.com>

Ping on behalf of Xin.

Thanks,

Paul

?On 12/30/19, 2:39 PM, "Liu, Xin" <xxinliu at amazon.com> wrote:

    Hi, Reviewers, 
    
    Thanks for reviewing it.  Paul is a reviewer.  Martin reviewed PPC and s390 and Ningsheng reviewed Arm&Aarch64. 
    Is that good to push?
    
    Thanks,
    --lx
    
    
    
    
    On 12/30/19, 11:16 AM, "Hohensee, Paul" <hohensee at amazon.com> wrote:
    
        Lgtm. Seems very low risk to me too.
        
        Paul
        
        On 12/26/19, 7:06 PM, "hotspot-compiler-dev on behalf of Liu, Xin" <hotspot-compiler-dev-bounces at openjdk.java.net on behalf of xxinliu at amazon.com> wrote:
        
            Hi, Ningsheng, 
            Thank you for submitting the trial repo.  I got the result email and it has passed all 80 tests. 
            
            Here is the updated webrev.  I updated the reviewers.
            https://cr.openjdk.java.net/~xliu/8236228/01/webrev/
            
            This is a low-risk patch. As long as  we can compile it, it won't have any side-effect at runtime. 
            
            thanks,
            --lx
            
            On 12/24/19, 9:52 PM, "Ningsheng Jian" <Ningsheng.Jian at arm.com> wrote:
            
                Hi lx,
                
                I've submitted it for you:
                
                http://hg.openjdk.java.net/jdk/submit/rev/9d61b00d5982
                
                I've also verified aarch64 and arm build locally, and it looks fine. 
                
                Thanks,
                Ningsheng
                
                > -----Original Message-----
                > From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net>
                > On Behalf Of Liu, Xin
                > Sent: Wednesday, December 25, 2019 4:57 AM
                > To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; 'hotspot-compiler-
                > dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
                > Subject: Re: RFR(XXS): 8236228: clean up BarrierSet headers in c1_LIRAssembler
                > 
                > I update the subject and switch back the corporation email.  Sorry, I didn?t
                > realize that there?s code of conduct. I will pay more attention on it.
                > 
                > I validate the patch without PCH using --disable-precompiled-headers on both
                > x86_64 and aarch64. Both of them built well.
                > I still have difficulty to verify SPARC. I try the submit repo but I don?t have
                > permission to push an experimental branch.  May I ask a sponsor submit it on
                > behalf of me?
                > 
                > Thanks,
                > --lx
                > 
                > 
                > 
                > 
                > Hi Lx
                > 
                > First, when you post RFR, please, include bug id in email's Subject.
                > 
                > You can use jdk/submit testing to verify builds on SPARC. We are still building on
                > it, with warning.
                > Changes seems fine to me but make sure verify that it builds without PCH.
                > 
                > Regards,
                > Vladimir
                > 
                > On 12/20/19 9:24 AM, Liu Xin wrote:
                > > Martin?
                > >
                > > Thank you very much. May I know how to validate Sparc? I don't have
                > > any SPARC machine to access.
                > >
                > > Thanks,
                > > --lx
                > >
                > >
                > > On Fri, Dec 20, 2019, 7:05 AM Doerr, Martin
                > <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
                > >
                > >> Hi lx,
                > >>
                > >> PPC and s390 parts are ok.
                > >>
                > >> Best regards,
                > >> Martin
                > >>
                > >>
                > >>> -----Original Message-----
                > >>> From: hotspot-compiler-dev <hotspot-compiler-dev-
                > >>> bounces at openjdk.java.net<mailto:bounces at openjdk.java.net>> On Behalf
                > >>> Of Liu, Xin
                > >>> Sent: Freitag, 20. Dezember 2019 04:48
                > >>> To:
                > >>> 'hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at o
                > >>> penjdk.java.net>' <hotspot-compiler-
                > >>> dev at openjdk.java.net<mailto:dev at openjdk.java.net>>
                > >>> Subject: [DMARC FAILURE] RFR(XXS): clean up BarrierSet headers in
                > >>> c1_LIRAssembler
                > >>>
                > >>> Hi, Reviewers,
                > >>>
                > >>> Could you take a look at my webrev? I feel that those barrisetSet
                > >> interfaces
                > >>> have nothing with c1_LIRAssembler.
                > >>>
                > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236228
                > >>> Webrev: https://cr.openjdk.java.net/~xliu/8236228/00/webrev/
                > >>>
                > >>> I try to build on aarch64 and x86_64 and it?s fine.
                > >>>
                > >>> Thanks,
                > >>> --lx
                > >>
                > >>
                
            
            
        
        
    
    


From jiefu at tencent.com  Tue Jan 14 01:26:12 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Tue, 14 Jan 2020 01:26:12 +0000
Subject: RFR: 8237055: [TESTBUG] compiler/c2/TestJumpTable.java fails with
 release VMs
Message-ID: <51CA1A9F-883F-49D2-8CC0-629F9CDAD420@tencent.com>

Hi all,



JBS: https://bugs.openjdk.java.net/browse/JDK-8237055



May I get reviews for this one-line fix?

The patch just adds -XX:+UnlockDiagnosticVMOptions for the test.



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

diff -r db9bdbeaed29 test/hotspot/jtreg/compiler/c2/TestJumpTable.java

--- a/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Mon Jan 13 14:09:30 2020 -0800

+++ b/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Tue Jan 14 09:11:06 2020 +0800

@@ -26,7 +26,7 @@

  * @bug 8229855

  * @summary Test jump table with key value that gets out of bounds after loop unrolling.

  * @run main/othervm -XX:CompileCommand=dontinline,compiler.c2.TestJumpTable::test*

- *                   -Xbatch -XX:-TieredCompilation -XX:-UseSwitchProfiling

+ *                   -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:-UseSwitchProfiling

  *                   compiler.c2.TestJumpTable

  */

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



Thanks a lot.

Best regards,

Jie

From felix.yang at huawei.com  Tue Jan 14 06:33:08 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Tue, 14 Jan 2020 06:33:08 +0000
Subject: RFR(S): 8235762: JVM crash in SWPointer during C2 compilation
In-Reply-To: <8797205a-c4ff-253d-404b-62a178c6e169@oracle.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DD8064@dggeml527-mbx.china.huawei.com>
 <e10a10b9-78ad-5ff7-5b55-571b7feae324@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD80DB@dggeml527-mbx.china.huawei.com>
 <4ef39906-839b-9a08-3225-f99b974f08de@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD8325@dggeml527-mbx.china.huawei.com>
 <d429870d-248e-bbb6-d296-d373c7e5affd@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD88F1@dggeml527-mbx.china.huawei.com>
 <4103e17e-57c4-ed78-bf64-1bb3cb99e9f4@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DECF6D@dggeml507-mbx.china.huawei.com>
 <8797205a-c4ff-253d-404b-62a178c6e169@oracle.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA1AF@dggeml527-mbx.china.huawei.com>

Hi Tobias,

    Thanks for reviewing this.  May I have another review please?  

Felix

> -----Original Message-----
> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com]
> Sent: Monday, January 13, 2020 7:28 PM
> To: Yangfei (Felix) <felix.yang at huawei.com>; Christian Hagedorn
> <christian.hagedorn at oracle.com>; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(S): 8235762: JVM crash in SWPointer during C2 compilation
> 
> Hi Felix,
> 
> looks reasonable to me. Thanks for updating.
> 
> Another review would be good.
> 
> Best regards,
> Tobias
> 
> On 10.01.20 02:13, Yangfei (Felix) wrote:
> > Hi Tobias,
> >
> >   Updated webrev: http://cr.openjdk.java.net/~fyang/8235762/webrev.01/
> >   This also updated copyright years of the newly-added test case.
> >   Still test OK with the latest repo.  Is this one better?
> >
> > Thanks,
> > Felix
> >


From tobias.hartmann at oracle.com  Tue Jan 14 08:51:03 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Jan 2020 09:51:03 +0100
Subject: RFR: 8237055: [TESTBUG] compiler/c2/TestJumpTable.java fails with
 release VMs
In-Reply-To: <51CA1A9F-883F-49D2-8CC0-629F9CDAD420@tencent.com>
References: <51CA1A9F-883F-49D2-8CC0-629F9CDAD420@tencent.com>
Message-ID: <11f12f70-bfdc-1b9f-9cca-e9119f8f8752@oracle.com>

Hi Jie,

looks good and trivial to me. Thanks for fixing!

Please push this into the JDK 14 repo:
http://hg.openjdk.java.net/jdk/jdk14

Thanks,
Tobias

On 14.01.20 02:26, jiefu(??) wrote:
> Hi all,
> 
> 
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8237055
> 
> 
> 
> May I get reviews for this one-line fix?
> 
> The patch just adds -XX:+UnlockDiagnosticVMOptions for the test.
> 
> 
> 
> -----------------------------------------------------------------------
> 
> diff -r db9bdbeaed29 test/hotspot/jtreg/compiler/c2/TestJumpTable.java
> 
> --- a/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Mon Jan 13 14:09:30 2020 -0800
> 
> +++ b/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Tue Jan 14 09:11:06 2020 +0800
> 
> @@ -26,7 +26,7 @@
> 
>   * @bug 8229855
> 
>   * @summary Test jump table with key value that gets out of bounds after loop unrolling.
> 
>   * @run main/othervm -XX:CompileCommand=dontinline,compiler.c2.TestJumpTable::test*
> 
> - *                   -Xbatch -XX:-TieredCompilation -XX:-UseSwitchProfiling
> 
> + *                   -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:-UseSwitchProfiling
> 
>   *                   compiler.c2.TestJumpTable
> 
>   */
> 
> -----------------------------------------------------------------------
> 
> 
> 
> Thanks a lot.
> 
> Best regards,
> 
> Jie
> 

From Pengfei.Li at arm.com  Tue Jan 14 08:54:50 2020
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Tue, 14 Jan 2020 08:54:50 +0000
Subject: RFR(S): 8230591: AArch64: Missing intrinsics for Math.ceil,
 floor, rint
In-Reply-To: <98800e19-9bc1-654f-443c-d1fc1adfe4b7@redhat.com>
References: <DB7PR08MB3115627E0C96DB20E2F60E5096390@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <fa128596-79e9-60d4-b4ee-f9cc72e53b36@redhat.com>
 <DB7PR08MB311574B245F93A2AA5267C6496380@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <98800e19-9bc1-654f-443c-d1fc1adfe4b7@redhat.com>
Message-ID: <DB7PR08MB311566042F7DC9E540EACAE996340@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi Andrew,

> Sure, but the code in "AdvSIMD two-reg misc" can easily be made flexible
> enough to accommodate that. All you have to do aas far as I can see is make
> size a parameter: everything else is the same.
> The important thing is that our assembler should follow the layout and
> classification in that manual as closely as we possibly can.

Thanks for your suggestion. I agree that we should align the layout and classification of the assembler code with ArmARM as closely as we can. But I found just adding one "size" parameter for this is not enough. If it is enough the RBIT instruction shouldn't be oddly encoded before in this category (from _rbit to rbit).

The problem here is that, after adding a "size" parameter for this misc category, the 2 bits in the size field [23:22] may be determined by the parameter "size" or the "SIMD_Arrangement T", or both. And who determines which bit differs instruction by instruction. To solve this problem in my latest webrev [1], I added an additional parameter "tmask" which is a 2-bit mask used accompany with "size" to indicate which bits in [23:22] are determined by the "SIMD_Arrangement T". The bit of "tmask" should be set to 1 if corresponding bit marked as "x" in the ArmARM doc.

With this, we can also encode RBIT normally like other instructions in the misc category.

[1] http://cr.openjdk.java.net/~pli/rfr/8230591/webrev.01/

I ran full jtreg and no new failure is found. How do you think of this?

--
Thanks,
Pengfei


From martin.doerr at sap.com  Tue Jan 14 09:01:42 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 14 Jan 2020 09:01:42 +0000
Subject: RFR(XXS): 8236228: clean up BarrierSet headers in c1_LIRAssembler
In-Reply-To: <2CDFB80B-04EA-4C95-A67A-1C1284C80C66@amazon.com>
References: <1982726B-9702-4087-B962-354D2B9FAD92@amazon.com>
 <VE1PR08MB5053E9D17314A06E5549522890280@VE1PR08MB5053.eurprd08.prod.outlook.com>
 <3C45D717-C0BF-40A4-93F5-EDA78FE91350@amazon.com>
 <3CC88DEC-56BE-4FDA-B775-7678F44E252A@amazon.com>
 <EBF6337B-2C95-417C-9DB0-6C972EB66251@amazon.com>
 <2CDFB80B-04EA-4C95-A67A-1C1284C80C66@amazon.com>
Message-ID: <AM0PR0202MB3297947242C472932EEDA27E9A340@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Xin and Paul,

yes, if submission forest testing has passed, it can get pushed.

Best regards,
Martin


> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Hohensee, Paul
> Sent: Montag, 13. Januar 2020 23:54
> To: Liu, Xin <xxinliu at amazon.com>; Ningsheng Jian
> <Ningsheng.Jian at arm.com>; Vladimir Kozlov <vladimir.kozlov at oracle.com>;
> 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-
> dev at openjdk.java.net>
> Cc: nd <nd at arm.com>
> Subject: Re: RFR(XXS): 8236228: clean up BarrierSet headers in
> c1_LIRAssembler
> 
> Ping on behalf of Xin.
> 
> Thanks,
> 
> Paul
> 
> ?On 12/30/19, 2:39 PM, "Liu, Xin" <xxinliu at amazon.com> wrote:
> 
>     Hi, Reviewers,
> 
>     Thanks for reviewing it.  Paul is a reviewer.  Martin reviewed PPC and s390
> and Ningsheng reviewed Arm&Aarch64.
>     Is that good to push?
> 
>     Thanks,
>     --lx
> 
> 
> 
> 
>     On 12/30/19, 11:16 AM, "Hohensee, Paul" <hohensee at amazon.com>
> wrote:
> 
>         Lgtm. Seems very low risk to me too.
> 
>         Paul
> 
>         On 12/26/19, 7:06 PM, "hotspot-compiler-dev on behalf of Liu, Xin"
> <hotspot-compiler-dev-bounces at openjdk.java.net on behalf of
> xxinliu at amazon.com> wrote:
> 
>             Hi, Ningsheng,
>             Thank you for submitting the trial repo.  I got the result email and it has
> passed all 80 tests.
> 
>             Here is the updated webrev.  I updated the reviewers.
>             https://cr.openjdk.java.net/~xliu/8236228/01/webrev/
> 
>             This is a low-risk patch. As long as  we can compile it, it won't have any
> side-effect at runtime.
> 
>             thanks,
>             --lx
> 
>             On 12/24/19, 9:52 PM, "Ningsheng Jian" <Ningsheng.Jian at arm.com>
> wrote:
> 
>                 Hi lx,
> 
>                 I've submitted it for you:
> 
>                 http://hg.openjdk.java.net/jdk/submit/rev/9d61b00d5982
> 
>                 I've also verified aarch64 and arm build locally, and it looks fine.
> 
>                 Thanks,
>                 Ningsheng
> 
>                 > -----Original Message-----
>                 > From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net>
>                 > On Behalf Of Liu, Xin
>                 > Sent: Wednesday, December 25, 2019 4:57 AM
>                 > To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; 'hotspot-
> compiler-
>                 > dev at openjdk.java.net' <hotspot-compiler-
> dev at openjdk.java.net>
>                 > Subject: Re: RFR(XXS): 8236228: clean up BarrierSet headers in
> c1_LIRAssembler
>                 >
>                 > I update the subject and switch back the corporation email.  Sorry, I
> didn?t
>                 > realize that there?s code of conduct. I will pay more attention on it.
>                 >
>                 > I validate the patch without PCH using --disable-precompiled-
> headers on both
>                 > x86_64 and aarch64. Both of them built well.
>                 > I still have difficulty to verify SPARC. I try the submit repo but I
> don?t have
>                 > permission to push an experimental branch.  May I ask a sponsor
> submit it on
>                 > behalf of me?
>                 >
>                 > Thanks,
>                 > --lx
>                 >
>                 >
>                 >
>                 >
>                 > Hi Lx
>                 >
>                 > First, when you post RFR, please, include bug id in email's Subject.
>                 >
>                 > You can use jdk/submit testing to verify builds on SPARC. We are
> still building on
>                 > it, with warning.
>                 > Changes seems fine to me but make sure verify that it builds
> without PCH.
>                 >
>                 > Regards,
>                 > Vladimir
>                 >
>                 > On 12/20/19 9:24 AM, Liu Xin wrote:
>                 > > Martin?
>                 > >
>                 > > Thank you very much. May I know how to validate Sparc? I don't
> have
>                 > > any SPARC machine to access.
>                 > >
>                 > > Thanks,
>                 > > --lx
>                 > >
>                 > >
>                 > > On Fri, Dec 20, 2019, 7:05 AM Doerr, Martin
>                 > <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
>                 > >
>                 > >> Hi lx,
>                 > >>
>                 > >> PPC and s390 parts are ok.
>                 > >>
>                 > >> Best regards,
>                 > >> Martin
>                 > >>
>                 > >>
>                 > >>> -----Original Message-----
>                 > >>> From: hotspot-compiler-dev <hotspot-compiler-dev-
>                 > >>>
> bounces at openjdk.java.net<mailto:bounces at openjdk.java.net>> On Behalf
>                 > >>> Of Liu, Xin
>                 > >>> Sent: Freitag, 20. Dezember 2019 04:48
>                 > >>> To:
>                 > >>> 'hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-
> compiler-dev at o
>                 > >>> penjdk.java.net>' <hotspot-compiler-
>                 > >>> dev at openjdk.java.net<mailto:dev at openjdk.java.net>>
>                 > >>> Subject: [DMARC FAILURE] RFR(XXS): clean up BarrierSet
> headers in
>                 > >>> c1_LIRAssembler
>                 > >>>
>                 > >>> Hi, Reviewers,
>                 > >>>
>                 > >>> Could you take a look at my webrev? I feel that those
> barrisetSet
>                 > >> interfaces
>                 > >>> have nothing with c1_LIRAssembler.
>                 > >>>
>                 > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236228
>                 > >>> Webrev:
> https://cr.openjdk.java.net/~xliu/8236228/00/webrev/
>                 > >>>
>                 > >>> I try to build on aarch64 and x86_64 and it?s fine.
>                 > >>>
>                 > >>> Thanks,
>                 > >>> --lx
>                 > >>
>                 > >>
> 
> 
> 
> 
> 
> 
> 


From rwestrel at redhat.com  Tue Jan 14 09:43:34 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 14 Jan 2020 10:43:34 +0100
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <580b9af0-1523-0cde-9b29-e09278e2fa1c@oracle.com>
References: <87o8w8ptsq.fsf@redhat.com>
 <da3150a6-8303-894c-be9c-c90298f7de7d@oracle.com> <8736dfkko7.fsf@redhat.com>
 <7bc32dc2-1612-cb77-a467-ac67987b148c@oracle.com> <87woa35ijf.fsf@redhat.com>
 <9f364210-53e4-0b4d-df3e-a02aa5219cb0@oracle.com> <87o8v71uqz.fsf@redhat.com>
 <467329e0-10e7-3dfa-ab4c-9f011630a756@oracle.com> <87blr71iqf.fsf@redhat.com>
 <580b9af0-1523-0cde-9b29-e09278e2fa1c@oracle.com>
Message-ID: <878sma1igp.fsf@redhat.com>


> I understand that the change you have is enough to avoid the problematic 
> case in GraphKit::must_be_not_null(). What I'd like to get rid of is the 
> need for a correctness check to ensure that HaltNode can't go away. It's 
> error-prone and can eventually get out of sync.

Fair enough. Then why not always enqueue the root node for igvn at the
end of parsing?

> Also, I'd like the bug to be handled separately (from 8231291). It'll 
> simplify possible backporting: as I see from the history, the 
> problematic code (JDK-8176506) was introduced in 10 and it may show up 
> in 11u eventually.

You're right. That's cleaner. I'll send new webrevs.

Roland.


From aph at redhat.com  Tue Jan 14 10:04:04 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 14 Jan 2020 10:04:04 +0000
Subject: RFR(S): 8230591: AArch64: Missing intrinsics for Math.ceil,
 floor, rint
In-Reply-To: <DB7PR08MB311566042F7DC9E540EACAE996340@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115627E0C96DB20E2F60E5096390@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <fa128596-79e9-60d4-b4ee-f9cc72e53b36@redhat.com>
 <DB7PR08MB311574B245F93A2AA5267C6496380@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <98800e19-9bc1-654f-443c-d1fc1adfe4b7@redhat.com>
 <DB7PR08MB311566042F7DC9E540EACAE996340@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <e30d2878-6946-47f3-c198-355f79b5909a@redhat.com>

On 1/14/20 8:54 AM, Pengfei Li wrote:
> [1] http://cr.openjdk.java.net/~pli/rfr/8230591/webrev.01/
> 
> I ran full jtreg and no new failure is found. How do you think of this?

Perfect, thanks. That's as well as it could be done, given the awkward
encoding.

-- 
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 jiefu at tencent.com  Tue Jan 14 10:19:40 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Tue, 14 Jan 2020 10:19:40 +0000
Subject: 8237055: [TESTBUG] compiler/c2/TestJumpTable.java fails with
 release VMs(Internet mail)
Message-ID: <4A3B3BF9-BAAC-4636-B2AD-34684DD12D36@tencent.com>

Hi Tobias,

Thanks for your review.

I have some problems to push the code and access my webrev through ssh (maybe caused by my local network config).
So I need your help to sponsor it.
I had prepared the patch in the attachment.

Thanks a lot.
Best regards,
Jie

?On 2020/1/14, 4:52 PM, "Tobias Hartmann" <tobias.hartmann at oracle.com> wrote:

    Hi Jie,
    
    looks good and trivial to me. Thanks for fixing!
    
    Please push this into the JDK 14 repo:
    http://hg.openjdk.java.net/jdk/jdk14
    
    Thanks,
    Tobias
    
    On 14.01.20 02:26, jiefu(??) wrote:
    > Hi all,
    > 
    > 
    > 
    > JBS: https://bugs.openjdk.java.net/browse/JDK-8237055
    > 
    > 
    > 
    > May I get reviews for this one-line fix?
    > 
    > The patch just adds -XX:+UnlockDiagnosticVMOptions for the test.
    > 
    > 
    > 
    > -----------------------------------------------------------------------
    > 
    > diff -r db9bdbeaed29 test/hotspot/jtreg/compiler/c2/TestJumpTable.java
    > 
    > --- a/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Mon Jan 13 14:09:30 2020 -0800
    > 
    > +++ b/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Tue Jan 14 09:11:06 2020 +0800
    > 
    > @@ -26,7 +26,7 @@
    > 
    >   * @bug 8229855
    > 
    >   * @summary Test jump table with key value that gets out of bounds after loop unrolling.
    > 
    >   * @run main/othervm -XX:CompileCommand=dontinline,compiler.c2.TestJumpTable::test*
    > 
    > - *                   -Xbatch -XX:-TieredCompilation -XX:-UseSwitchProfiling
    > 
    > + *                   -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:-UseSwitchProfiling
    > 
    >   *                   compiler.c2.TestJumpTable
    > 
    >   */
    > 
    > -----------------------------------------------------------------------
    > 
    > 
    > 
    > Thanks a lot.
    > 
    > Best regards,
    > 
    > Jie
    > 
    
    


From tobias.hartmann at oracle.com  Tue Jan 14 11:17:43 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Jan 2020 12:17:43 +0100
Subject: 8237055: [TESTBUG] compiler/c2/TestJumpTable.java fails with
 release VMs(Internet mail)
In-Reply-To: <4A3B3BF9-BAAC-4636-B2AD-34684DD12D36@tencent.com>
References: <4A3B3BF9-BAAC-4636-B2AD-34684DD12D36@tencent.com>
Message-ID: <28670645-10e3-363c-4e2b-b91495860be9@oracle.com>

Hi Jie,

sure, pushed.

Best regards,
Tobias

On 14.01.20 11:19, jiefu(??) wrote:
> Hi Tobias,
> 
> Thanks for your review.
> 
> I have some problems to push the code and access my webrev through ssh (maybe caused by my local network config).
> So I need your help to sponsor it.
> I had prepared the patch in the attachment.
> 
> Thanks a lot.
> Best regards,
> Jie
> 
> ?On 2020/1/14, 4:52 PM, "Tobias Hartmann" <tobias.hartmann at oracle.com> wrote:
> 
>     Hi Jie,
>     
>     looks good and trivial to me. Thanks for fixing!
>     
>     Please push this into the JDK 14 repo:
>     http://hg.openjdk.java.net/jdk/jdk14
>     
>     Thanks,
>     Tobias
>     
>     On 14.01.20 02:26, jiefu(??) wrote:
>     > Hi all,
>     > 
>     > 
>     > 
>     > JBS: https://bugs.openjdk.java.net/browse/JDK-8237055
>     > 
>     > 
>     > 
>     > May I get reviews for this one-line fix?
>     > 
>     > The patch just adds -XX:+UnlockDiagnosticVMOptions for the test.
>     > 
>     > 
>     > 
>     > -----------------------------------------------------------------------
>     > 
>     > diff -r db9bdbeaed29 test/hotspot/jtreg/compiler/c2/TestJumpTable.java
>     > 
>     > --- a/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Mon Jan 13 14:09:30 2020 -0800
>     > 
>     > +++ b/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Tue Jan 14 09:11:06 2020 +0800
>     > 
>     > @@ -26,7 +26,7 @@
>     > 
>     >   * @bug 8229855
>     > 
>     >   * @summary Test jump table with key value that gets out of bounds after loop unrolling.
>     > 
>     >   * @run main/othervm -XX:CompileCommand=dontinline,compiler.c2.TestJumpTable::test*
>     > 
>     > - *                   -Xbatch -XX:-TieredCompilation -XX:-UseSwitchProfiling
>     > 
>     > + *                   -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:-UseSwitchProfiling
>     > 
>     >   *                   compiler.c2.TestJumpTable
>     > 
>     >   */
>     > 
>     > -----------------------------------------------------------------------
>     > 
>     > 
>     > 
>     > Thanks a lot.
>     > 
>     > Best regards,
>     > 
>     > Jie
>     > 
>     
>     
> 

From vladimir.x.ivanov at oracle.com  Tue Jan 14 11:22:46 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 14 Jan 2020 14:22:46 +0300
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <878sma1igp.fsf@redhat.com>
References: <878sma1igp.fsf@redhat.com>
Message-ID: <C0E99B5F-257C-448F-BB77-23A412468E7A@oracle.com>

?
>> I understand that the change you have is enough to avoid the problematic 
>> case in GraphKit::must_be_not_null(). What I'd like to get rid of is the 
>> need for a correctness check to ensure that HaltNode can't go away. It's 
>> error-prone and can eventually get out of sync.
> 
> Fair enough. Then why not always enqueue the root node for igvn at the
> end of parsing?

Sounds good. FTR I?m fine with both options. But unconditionally registering RootNode for IGVN looks like a simpler and cleaner solution.

> 
>> Also, I'd like the bug to be handled separately (from 8231291). It'll 
>> simplify possible backporting: as I see from the history, the 
>> problematic code (JDK-8176506) was introduced in 10 and it may show up 
>> in 11u eventually.
> 
> You're right. That's cleaner. I'll send new webrevs.

Thanks!

Best regards,
Vladimir Ivanov

> 
> Roland.
> 


From jiefu at tencent.com  Tue Jan 14 11:53:55 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Tue, 14 Jan 2020 11:53:55 +0000
Subject: 8237055: [TESTBUG] compiler/c2/TestJumpTable.java fails with
 release VMs(Internet mail)
In-Reply-To: <28670645-10e3-363c-4e2b-b91495860be9@oracle.com>
References: <4A3B3BF9-BAAC-4636-B2AD-34684DD12D36@tencent.com>
 <28670645-10e3-363c-4e2b-b91495860be9@oracle.com>
Message-ID: <23418799-5240-4FF4-B1D9-DDCABD178180@tencent.com>

Thank you so much, Tobias.

?On 2020/1/14, 7:18 PM, "Tobias Hartmann" <tobias.hartmann at oracle.com> wrote:

    Hi Jie,
    
    sure, pushed.
    
    Best regards,
    Tobias
    
    On 14.01.20 11:19, jiefu(??) wrote:
    > Hi Tobias,
    > 
    > Thanks for your review.
    > 
    > I have some problems to push the code and access my webrev through ssh (maybe caused by my local network config).
    > So I need your help to sponsor it.
    > I had prepared the patch in the attachment.
    > 
    > Thanks a lot.
    > Best regards,
    > Jie
    > 
    > On 2020/1/14, 4:52 PM, "Tobias Hartmann" <tobias.hartmann at oracle.com> wrote:
    > 
    >     Hi Jie,
    >     
    >     looks good and trivial to me. Thanks for fixing!
    >     
    >     Please push this into the JDK 14 repo:
    >     http://hg.openjdk.java.net/jdk/jdk14
    >     
    >     Thanks,
    >     Tobias
    >     
    >     On 14.01.20 02:26, jiefu(??) wrote:
    >     > Hi all,
    >     > 
    >     > 
    >     > 
    >     > JBS: https://bugs.openjdk.java.net/browse/JDK-8237055
    >     > 
    >     > 
    >     > 
    >     > May I get reviews for this one-line fix?
    >     > 
    >     > The patch just adds -XX:+UnlockDiagnosticVMOptions for the test.
    >     > 
    >     > 
    >     > 
    >     > -----------------------------------------------------------------------
    >     > 
    >     > diff -r db9bdbeaed29 test/hotspot/jtreg/compiler/c2/TestJumpTable.java
    >     > 
    >     > --- a/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Mon Jan 13 14:09:30 2020 -0800
    >     > 
    >     > +++ b/test/hotspot/jtreg/compiler/c2/TestJumpTable.java Tue Jan 14 09:11:06 2020 +0800
    >     > 
    >     > @@ -26,7 +26,7 @@
    >     > 
    >     >   * @bug 8229855
    >     > 
    >     >   * @summary Test jump table with key value that gets out of bounds after loop unrolling.
    >     > 
    >     >   * @run main/othervm -XX:CompileCommand=dontinline,compiler.c2.TestJumpTable::test*
    >     > 
    >     > - *                   -Xbatch -XX:-TieredCompilation -XX:-UseSwitchProfiling
    >     > 
    >     > + *                   -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:-UseSwitchProfiling
    >     > 
    >     >   *                   compiler.c2.TestJumpTable
    >     > 
    >     >   */
    >     > 
    >     > -----------------------------------------------------------------------
    >     > 
    >     > 
    >     > 
    >     > Thanks a lot.
    >     > 
    >     > Best regards,
    >     > 
    >     > Jie
    >     > 
    >     
    >     
    > 
    
    


From fairoz.matte at oracle.com  Tue Jan 14 13:32:47 2020
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Tue, 14 Jan 2020 05:32:47 -0800 (PST)
Subject: RFR: 8236701: [TESTBUG]
 compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord
In-Reply-To: <015d7aac-a487-41bb-a0c4-d51f58b9f85d@default>
References: <7e5c671e-6fef-46c1-9429-51cafe243c65@default>
 <1205f0b4-2353-ac86-a519-5fc7ace2a4e5@oracle.com>
 <68c8cbca-4f0e-41cd-bc07-d8f0268e0205@default>
 <7ad3ddcb-b2d2-d815-a2f6-192612da9abc@oracle.com>
 <8f0d6d6c-927e-6b9e-6213-3274a099d288@oracle.com>
 <015d7aac-a487-41bb-a0c4-d51f58b9f85d@default>
Message-ID: <a2e6fc45-dadf-4fb8-8e8a-26de45d0ab89@default>

Hi Tobias,

Sorry for my misunderstanding, @requires will restrict the execution on other platforms.
We don't really need "-XX:+IgnoreUnrecognizedVMOptions" flag.

Below is the updated webrev
http://cr.openjdk.java.net/~fmatte/8236701/webrev.01/

Thanks,
Fairoz

-----Original Message-----
From: Fairoz Matte 
Sent: Monday, January 13, 2020 9:23 PM
To: Tobias Hartmann <tobias.hartmann at oracle.com>; Ioi Lam <ioi.lam at oracle.com>; hotspot-compiler-dev at openjdk.java.net
Subject: RE: RFR: 8236701: [TESTBUG] compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord

Hi Tobias,

Thanks for the review,
It does look like we still need "-XX:+IgnoreUnrecognizedVMOptions" flag.

Summary of the test case shows,  Superword support is only for limited platforms.

* @summary Add C2 x86 Superword support for VNNI VPDPWSSD Instruction
* @requires os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64"

I have updated copyright.

Thanks,
Fairoz

-----Original Message-----
From: Tobias Hartmann
Sent: Monday, January 13, 2020 5:01 PM
To: Fairoz Matte <fairoz.matte at oracle.com>; Ioi Lam <ioi.lam at oracle.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR: 8236701: [TESTBUG] compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord

Please also update the copyright.

Best regards,
Tobias

On 13.01.20 12:29, Tobias Hartmann wrote:
> Hi Fairoz,
> 
> On 13.01.20 09:29, Fairoz Matte wrote:
>> I was not sure why that option was added.
> 
> I think it's just because the author incorrectly assumed that some of 
> the flags sre only available in debug builds (which is not the case).
> 
>> Let me know, if that is ok to be removed, I will send the next webrev.
> 
> Yes, please do so. The change looks good to me.
> 
> Thanks,
> Tobias
> 

From tobias.hartmann at oracle.com  Tue Jan 14 13:47:49 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Jan 2020 14:47:49 +0100
Subject: RFR: 8236701: [TESTBUG]
 compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord
In-Reply-To: <a2e6fc45-dadf-4fb8-8e8a-26de45d0ab89@default>
References: <7e5c671e-6fef-46c1-9429-51cafe243c65@default>
 <1205f0b4-2353-ac86-a519-5fc7ace2a4e5@oracle.com>
 <68c8cbca-4f0e-41cd-bc07-d8f0268e0205@default>
 <7ad3ddcb-b2d2-d815-a2f6-192612da9abc@oracle.com>
 <8f0d6d6c-927e-6b9e-6213-3274a099d288@oracle.com>
 <015d7aac-a487-41bb-a0c4-d51f58b9f85d@default>
 <a2e6fc45-dadf-4fb8-8e8a-26de45d0ab89@default>
Message-ID: <b9fbb7a9-18e5-aa3e-5aa7-69af553ef1cf@oracle.com>

Hi Fairoz,

On 14.01.20 14:32, Fairoz Matte wrote:
> http://cr.openjdk.java.net/~fmatte/8236701/webrev.01/

Looks good to me.

Best regards,
Tobias

From tobias.hartmann at oracle.com  Tue Jan 14 14:06:35 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Jan 2020 15:06:35 +0100
Subject: [15] RFR(M): 8236493: C2: Inconsistent known instance type
 information after EA
Message-ID: <4ee2aba1-2e74-fdc5-f2e0-edb96f809d7b@oracle.com>

Hi,

please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8236493
http://cr.openjdk.java.net/~thartmann/8236493/webrev.00/

While working on 8233164, I've noticed that escape analysis does not set known instance type
information for LoadNodes and their users if the loaded object does not escape but that information
is only (incrementally) propagated during IGVN. That's a problem because depending on the sequence
in which nodes on the worklist are processed, optimizations might still see the not-yet-updated (and
therefore incorrect) type. For example, another LoadNode optimization might rely on it's memory
input to be a general memory slice and re-wire it's inputs accordingly (ignoring known instance type
memory), when it is really reading from a known instance.

For a detailed description of an instance of such a problem, see my RFR for 8233164 [1]. There, the
type of a CastPPNode is not updated (yet) and a Load user is incorrectly re-wired.

To catch this case before things go horribly wrong, I've added an assert to
Node::raise_bottom_type(). Reverting the fix for 8233164 now immediately triggers the assert because
the known instance id of a DecodeNNode is only updated during IGVN [2]. All new tests in
TestInstanceIdPropagation.java trigger the assert as well.

The fix is to always eagerly propagate that information during EA. If an object loaded from the
field of a non-escaping object is also non-escaping, we need to propagate that information.

Thanks,
Tobias

[1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-December/036616.html

[2] Failure with TestArrayCopyMemoryChain.java when reverting fix for 8233164:

 300	Proj	===  288  [[ 301  305  312 ]] #5 !jvms: TestArrayCopyMemoryChain::test2 @ bci:25
 305	CheckCastPP	===  302  300  [[ 385  316 ]]  #byte[int:1]:NotNull:exact *,iid=288 !jvms:
TestArrayCopyMemoryChain::test2 @ bci:25
 385	EncodeP	=== _  305  [[ 387  403 ]]  #narrowoop: byte[int:1]:NotNull:exact *,iid=288 !orig=[402]
!jvms: TestArrayCopyMemoryChain$Wrapper::<init> @ bci:11 TestArrayCopyMemoryChain::test2 @ bci:41
 403 >	DecodeN	=== _  385  [[ 494  420 ]]  #byte[int:1]:NotNull:exact *,iid=288 !jvms:
TestArrayCopyMemoryChain::test2 @ bci:48
 494	CastPP	===  486  403  [[ 526  514 ]]  #byte[int:>=0]:NotNull:exact * !jvms:
TestArrayCopyMemoryChain::test2 @ bci:71
 420	CallStaticJava	===  404  327  341  8  9 ( 419  1  1  1  64  1  1  1  403  257  43  64  11  230
) [[ 421 ]] # Static uncommon_trap(reason='intrinsic_or_type_checked_inlining'
action='make_not_entrant' debug_id='0')  void ( int ) C=0.000100 TestArrayCopyMemoryChain::test2 @
bci:61 !jvms: TestArrayCopyMemoryChain::test2 @ bci:61
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/node.cpp:1088
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/oracle/jdk_jdk/open/src/hotspot/share/opto/node.cpp:1088), pid=6482, tid=6496
#  assert(false) failed: Known instance type should have been set during EA

From rwestrel at redhat.com  Tue Jan 14 14:09:38 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 14 Jan 2020 15:09:38 +0100
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <C0E99B5F-257C-448F-BB77-23A412468E7A@oracle.com>
References: <878sma1igp.fsf@redhat.com>
 <C0E99B5F-257C-448F-BB77-23A412468E7A@oracle.com>
Message-ID: <875zhe1659.fsf@redhat.com>


New webrev without the change GraphKit::must_be_not_null():

http://cr.openjdk.java.net/~roland/8231291/webrev.03/

Roland.


From rwestrel at redhat.com  Tue Jan 14 14:27:01 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 14 Jan 2020 15:27:01 +0100
Subject: [15] RFR(S): 8236721: C2 should better optimize not-equal integer
 comparisons
In-Reply-To: <480a02e6-1d4b-900f-28cf-ce37b6382e81@oracle.com>
References: <480a02e6-1d4b-900f-28cf-ce37b6382e81@oracle.com>
Message-ID: <8736ci15ca.fsf@redhat.com>


> http://cr.openjdk.java.net/~thartmann/8236721/webrev.00/

Looks good to me.

Roland.


From christian.hagedorn at oracle.com  Tue Jan 14 14:29:31 2020
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Tue, 14 Jan 2020 15:29:31 +0100
Subject: [15] RFR(S): 8235332: TestInstanceCloneAsLoadsStores.java fails with
 -XX:+StressGCM
Message-ID: <2ef5e2fd-d73c-5e1f-e50f-8ea36cd24029@oracle.com>

Hi

Please review the following patch
http://cr.openjdk.java.net/~chagedorn/8235332/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8235332

An ArrayCopyNode for a clone is not inlined for more than 8 
(=ArrayCopyLoadStoreMaxElem) fields. Therefore, the test cases uses 9 
fields. There is a GC barrier for 109 ArrayCopy [1] when disabling 
ReduceInitialCardMarks which is not taken into account in the pattern 
matching check for a clone at [2] in ConnectionGraph::find_inst_mem() 
during escape analysis. As a result, 161 MemBarStoreStore is skipped and 
the search continues at 160 MergeMem and the result is set to 97 Proj at 
[3]. Escape Analysis will then optimize 171 LoadI to directly use the 
memory output of the uninitialized allocation instead of the output of 
the ArrayCopyNode because it thinks the memory is the same [4]. This 
bug, however, is only observed when enabling the StressGCM flag which 
emits the field loading code before the array copy code which results in 
reads from uninitialized memory.

The existing pattern matching code to find an ArrayCopyNode over the 
MergeMemNode is replaced by a pattern matching over the MemBarNode 
taking GC barriers into account.

Thank you!

Best regards,
Christian


[1] 
https://bugs.openjdk.java.net/secure/attachment/86398/array_copy_with_gc_barrier.png
[2] 
http://hg.openjdk.java.net/jdk/jdk/file/f7edb9ca045c/src/hotspot/share/opto/escape.cpp#l2749
[3] 
http://hg.openjdk.java.net/jdk/jdk/file/f7edb9ca045c/src/hotspot/share/opto/escape.cpp#l2765
[4] 
https://bugs.openjdk.java.net/secure/attachment/86397/field_load_wrong_memory.png

From rwestrel at redhat.com  Tue Jan 14 14:36:33 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 14 Jan 2020 15:36:33 +0100
Subject: [15] RFR(S): 8235332: TestInstanceCloneAsLoadsStores.java fails
 with -XX:+StressGCM
In-Reply-To: <2ef5e2fd-d73c-5e1f-e50f-8ea36cd24029@oracle.com>
References: <2ef5e2fd-d73c-5e1f-e50f-8ea36cd24029@oracle.com>
Message-ID: <87zheqyuj2.fsf@redhat.com>


Hi Christian,

> http://cr.openjdk.java.net/~chagedorn/8235332/webrev.00/

If there's no GC barrier then:

Node* control_proj_ac = bs->step_over_gc_barrier(proj_in->in(0));

control_proj_ac is not a projection, it's proj_in->in(0) so the test
below can never succeed?

Roland.


From vladimir.x.ivanov at oracle.com  Tue Jan 14 14:41:16 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 14 Jan 2020 16:41:16 +0200
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <875zhe1659.fsf@redhat.com>
References: <875zhe1659.fsf@redhat.com>
Message-ID: <B15E6478-B809-48AF-9D24-FB0763833D81@oracle.com>


> http://cr.openjdk.java.net/~roland/8231291/webrev.03/

Looks good.

Best regards,
Vladimir Ivanov

From tobias.hartmann at oracle.com  Tue Jan 14 15:00:07 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Jan 2020 16:00:07 +0100
Subject: [15] RFR(S): 8236721: C2 should better optimize not-equal integer
 comparisons
In-Reply-To: <8736ci15ca.fsf@redhat.com>
References: <480a02e6-1d4b-900f-28cf-ce37b6382e81@oracle.com>
 <8736ci15ca.fsf@redhat.com>
Message-ID: <85a387b3-b71b-b96c-b70b-c58be54f4aab@oracle.com>

Hi Roland,

thanks for the review!

Best regards,
Tobias

On 14.01.20 15:27, Roland Westrelin wrote:
> 
>> http://cr.openjdk.java.net/~thartmann/8236721/webrev.00/
> 
> Looks good to me.
> 
> Roland.
> 

From nils.eliasson at oracle.com  Tue Jan 14 15:14:55 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 14 Jan 2020 16:14:55 +0100
Subject: RFR(S): 8235584: UseProfiledLoopPredicate fails with
 assert(_phase->get_loop(c) == loop) failed: have to be in the same loop
In-Reply-To: <1a4c0874-946b-aea3-fe83-ac5e2b9f1862@oracle.com>
References: <87r2031va5.fsf@redhat.com>
 <1a4c0874-946b-aea3-fe83-ac5e2b9f1862@oracle.com>
Message-ID: <a22be69b-6b07-a12f-d9f7-5c367b2d1393@oracle.com>

+1

Best regards,
Nils Eliasson

On 2020-01-13 12:46, Tobias Hartmann wrote:
> Hi Roland,
>
> On 13.01.20 11:54, Roland Westrelin wrote:
>> http://cr.openjdk.java.net/~roland/8235584/webrev.00/
> Looks good to me.
>
>> Also, the fix that Tobias pushed for 8235452 erroneously disabled
>> verification for the outer strip mined loop. This change restores it.
> Thanks for fixing. We should get this into JDK 14.
>
> Best regards,
> Tobias


From IOI.LAM at ORACLE.COM  Tue Jan 14 15:26:42 2020
From: IOI.LAM at ORACLE.COM (Ioi Lam)
Date: Tue, 14 Jan 2020 07:26:42 -0800
Subject: RFR: 8236701: [TESTBUG]
 compiler/loopopts/superword/Vec_MulAddS2I.java uses wrong flag -XX:-SuperWord
In-Reply-To: <b9fbb7a9-18e5-aa3e-5aa7-69af553ef1cf@oracle.com>
References: <b9fbb7a9-18e5-aa3e-5aa7-69af553ef1cf@oracle.com>
Message-ID: <3B9527AD-F34B-4813-92A2-803129A31061@ORACLE.COM>

Looks good to me too.

Thanks
Ioi

Sent from my iPad

> On Jan 14, 2020, at 5:47 AM, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
> 
> ?Hi Fairoz,
> 
>> On 14.01.20 14:32, Fairoz Matte wrote:
>> http://cr.openjdk.java.net/~fmatte/8236701/webrev.01/
> 
> Looks good to me.
> 
> Best regards,
> Tobias


From tobias.hartmann at oracle.com  Tue Jan 14 15:29:30 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Jan 2020 16:29:30 +0100
Subject: RFR(S): 8236759: ShouldNotReachHere in
 PhaseIdealLoop::verify_strip_mined_scheduling
In-Reply-To: <87ftgj1qtm.fsf@redhat.com>
References: <87zher1xut.fsf@redhat.com>
 <aa8cab76-14b6-d55e-a533-9001697990e5@oracle.com> <87ftgj1qtm.fsf@redhat.com>
Message-ID: <b24fdb9f-2b29-eef9-0c0c-1e22e3dfe6f4@oracle.com>

Hi Roland,

On 13.01.20 13:30, Roland Westrelin wrote:
>> Just wondering why you need the checks in line 1487? Isn't in->is_OuterStripMinedLoop() sufficient
>> since we should never schedule a data node in the outer strip mined loop?
> 
> It could be top too. Also I guess, I'm becoming paranoid about little
> things going wrong with strip mining...

Fair enough. Looks good to me but please add a brief comment (something like "should not schedule a
data node in the outer strip mined loop") before pushing.

Thanks,
Tobias

From nils.eliasson at oracle.com  Tue Jan 14 15:30:21 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 14 Jan 2020 16:30:21 +0100
Subject: RFR(S): 8235762: JVM crash in SWPointer during C2 compilation
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA1AF@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DD8064@dggeml527-mbx.china.huawei.com>
 <e10a10b9-78ad-5ff7-5b55-571b7feae324@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD80DB@dggeml527-mbx.china.huawei.com>
 <4ef39906-839b-9a08-3225-f99b974f08de@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD8325@dggeml527-mbx.china.huawei.com>
 <d429870d-248e-bbb6-d296-d373c7e5affd@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD88F1@dggeml527-mbx.china.huawei.com>
 <4103e17e-57c4-ed78-bf64-1bb3cb99e9f4@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DECF6D@dggeml507-mbx.china.huawei.com>
 <8797205a-c4ff-253d-404b-62a178c6e169@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DFA1AF@dggeml527-mbx.china.huawei.com>
Message-ID: <dd6b9bc6-9042-2743-9cc1-b23cc50fc9b4@oracle.com>

Hi Felix,

Your change looks good.

Thanks for fixing!

Best regards,
Nils

On 2020-01-14 07:33, Yangfei (Felix) wrote:
> Hi Tobias,
>
>      Thanks for reviewing this.  May I have another review please?
>
> Felix
>
>> -----Original Message-----
>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com]
>> Sent: Monday, January 13, 2020 7:28 PM
>> To: Yangfei (Felix) <felix.yang at huawei.com>; Christian Hagedorn
>> <christian.hagedorn at oracle.com>; hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR(S): 8235762: JVM crash in SWPointer during C2 compilation
>>
>> Hi Felix,
>>
>> looks reasonable to me. Thanks for updating.
>>
>> Another review would be good.
>>
>> Best regards,
>> Tobias
>>
>> On 10.01.20 02:13, Yangfei (Felix) wrote:
>>> Hi Tobias,
>>>
>>>    Updated webrev: http://cr.openjdk.java.net/~fyang/8235762/webrev.01/
>>>    This also updated copyright years of the newly-added test case.
>>>    Still test OK with the latest repo.  Is this one better?
>>>
>>> Thanks,
>>> Felix
>>>


From nils.eliasson at oracle.com  Tue Jan 14 15:31:26 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 14 Jan 2020 16:31:26 +0100
Subject: [15] RFR(S): 8236721: C2 should better optimize not-equal integer
 comparisons
In-Reply-To: <8736ci15ca.fsf@redhat.com>
References: <480a02e6-1d4b-900f-28cf-ce37b6382e81@oracle.com>
 <8736ci15ca.fsf@redhat.com>
Message-ID: <b5bc2a58-77bf-6c69-4922-565caa37622e@oracle.com>

+1

Best regards,
Nils Eliasosn

On 2020-01-14 15:27, Roland Westrelin wrote:
>> http://cr.openjdk.java.net/~thartmann/8236721/webrev.00/
> Looks good to me.
>
> Roland.
>


From tobias.hartmann at oracle.com  Tue Jan 14 15:36:23 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Jan 2020 16:36:23 +0100
Subject: [15] RFR(S): 8236721: C2 should better optimize not-equal integer
 comparisons
In-Reply-To: <b5bc2a58-77bf-6c69-4922-565caa37622e@oracle.com>
References: <480a02e6-1d4b-900f-28cf-ce37b6382e81@oracle.com>
 <8736ci15ca.fsf@redhat.com> <b5bc2a58-77bf-6c69-4922-565caa37622e@oracle.com>
Message-ID: <54a90eae-33c4-0b83-18ee-694c485f20b8@oracle.com>

Thanks Nils!

Best regards,
Tobias

On 14.01.20 16:31, Nils Eliasson wrote:
> +1
> 
> Best regards,
> Nils Eliasosn
> 
> On 2020-01-14 15:27, Roland Westrelin wrote:
>>> http://cr.openjdk.java.net/~thartmann/8236721/webrev.00/
>> Looks good to me.
>>
>> Roland.
>>
> 

From rwestrel at redhat.com  Tue Jan 14 15:53:58 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 14 Jan 2020 16:53:58 +0100
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <878sma1igp.fsf@redhat.com>
References: <87o8w8ptsq.fsf@redhat.com>
 <da3150a6-8303-894c-be9c-c90298f7de7d@oracle.com> <8736dfkko7.fsf@redhat.com>
 <7bc32dc2-1612-cb77-a467-ac67987b148c@oracle.com> <87woa35ijf.fsf@redhat.com>
 <9f364210-53e4-0b4d-df3e-a02aa5219cb0@oracle.com> <87o8v71uqz.fsf@redhat.com>
 <467329e0-10e7-3dfa-ab4c-9f011630a756@oracle.com> <87blr71iqf.fsf@redhat.com>
 <580b9af0-1523-0cde-9b29-e09278e2fa1c@oracle.com> <878sma1igp.fsf@redhat.com>
Message-ID: <87wo9uyqy1.fsf@redhat.com>


>> I understand that the change you have is enough to avoid the problematic 
>> case in GraphKit::must_be_not_null(). What I'd like to get rid of is the 
>> need for a correctness check to ensure that HaltNode can't go away. It's 
>> error-prone and can eventually get out of sync.
>
> Fair enough. Then why not always enqueue the root node for igvn at the
> end of parsing?

I filed 8237086 for this.

Roland.


From rwestrel at redhat.com  Tue Jan 14 16:07:24 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 14 Jan 2020 17:07:24 +0100
Subject: RFR(S): 8237086: assert(is_MachReturn()) running CTW with fix for
 JDK-8231291
Message-ID: <87tv4yyqbn.fsf@redhat.com>


http://cr.openjdk.java.net/~roland/8237086/webrev.00/

As discussed in:

https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036689.html

GraphKit::must_be_not_null() is called with a known to be non null
input. This causes the null branch of the test to be optimized to top
and a top be added to the RootNode. RootNode::Ideal() is never called to
clean the top inputs and the assert is hit during matching.

Roland.


From tobias.hartmann at oracle.com  Tue Jan 14 16:13:52 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Jan 2020 17:13:52 +0100
Subject: RFR(S): 8237007: Shenandoah: assert(_base == Tuple) failure
 during C2 compilation
In-Reply-To: <87wo9v1wup.fsf@redhat.com>
References: <87wo9v1wup.fsf@redhat.com>
Message-ID: <80847ab4-3b49-68c8-33af-8946fd14cda3@oracle.com>

Hi Roland,

as we've discussed off-thread, considering the CMove as unpinned seems reasonable because it does
not have any (side-)effects that would not be explicit in the graph.

Still wondering why the CMove then has a control input in the first place but your change looks good
to me. I'll run some testing.

Best regards,
Tobias

On 13.01.20 11:20, Roland Westrelin wrote:
> 
> http://cr.openjdk.java.net/~roland/8237007/webrev.00/
> 
> The assert fails because C2 expands a barrier between a membar and its
> control projection. That happens because the gc barrier is assigned the
> membar as control by loop optimizations (and not its control
> projection). The gc barrier has a load as input which itself depends on
> the memory state produced by the membar so the barrier has to be below
> the membar. The gc barrier has a CMove as use. That CMove has a control
> input that's above the membar and because it's considered pinned by loop
> opts, it's assigned earliest possible control: the membar. Considering
> the CMove as pinned is overly conservative AFAICT. My fix consists in
> excluding CMove nodes from being pinned.
> 
> Roland.
> 

From christian.hagedorn at oracle.com  Tue Jan 14 16:18:05 2020
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Tue, 14 Jan 2020 17:18:05 +0100
Subject: [15] RFR(S): 8235332: TestInstanceCloneAsLoadsStores.java fails
 with -XX:+StressGCM
In-Reply-To: <87zheqyuj2.fsf@redhat.com>
References: <2ef5e2fd-d73c-5e1f-e50f-8ea36cd24029@oracle.com>
 <87zheqyuj2.fsf@redhat.com>
Message-ID: <3f4d0542-5d72-dca4-d14d-7a13402fbf1c@oracle.com>

Hi Roland

>> http://cr.openjdk.java.net/~chagedorn/8235332/webrev.00/
> 
> If there's no GC barrier then:
> 
> Node* control_proj_ac = bs->step_over_gc_barrier(proj_in->in(0));
> 
> control_proj_ac is not a projection, it's proj_in->in(0) so the test
> below can never succeed?

If there is no GC barrier, then proj_in is a membar with its control 
input being a control projection from the ArrayCopyNode.

As an example, I have taken the test case TestEliminatedCloneBadMemEdge 
[1] which does not disable ReduceInitialCardMarks and has no GC barrier. 
We have the following situation at [2]:

proj_in is 132 MemBarCPUOrder. The original code then looked at the 
MergeMem 100 input following in(Compile::AliasIdxRaw) which is 101 Proj 
and its input 98 ArrayCopy. This passes the check.

My fix now directly looks at the control input of 132 MemBarCPUOrder 
which is the projection 99 Proj coming from the 98 ArrayCopy. This also 
passes the check.


  98	ArrayCopy	===  85  1  65  8  1 ( 47 _  90 _  97 _ _ _ _ ) [[ 99 
101 ]]  void ( java/lang/Object *, int, java/lang/Object *, int, int, 
int, int, BotPTR *+bot, BotPTR *+bot ) (clone, tightly coupled 
allocation) !jvms: TestEliminatedCloneBadMemEdge::test @ bci:1
  101	Proj	===  98  [[ 100 ]] #2  Memory: @rawptr:BotPTR, idx=Raw; 
!jvms: TestEliminatedCloneBadMemEdge::test @ bci:1
  100	MergeMem	=== _  1  39  101  86  1  86  86  86  86  86  86  86  86 
86  86  [[ 132 ]]  { N101:rawptr:BotPTR N86:java/lang/Object+8 ...
  99	Proj	===  98  [[ 132 ]] #0 !jvms: 
TestEliminatedCloneBadMemEdge::test @ bci:1
  132	MemBarCPUOrder	===  99  1  100  1  1  [[ 104  103 ]]  !orig=102 
!jvms: TestEliminatedCloneBadMemEdge::test @ bci:1


Best regards,
Christian


[1] 
http://hg.openjdk.java.net/jdk/jdk/file/2080e45e61ea/test/hotspot/jtreg/compiler/arraycopy/TestEliminatedCloneBadMemEdge.java
[2] 
http://hg.openjdk.java.net/jdk/jdk/file/f7edb9ca045c/src/hotspot/share/opto/escape.cpp#l2749

From rkennke at redhat.com  Tue Jan 14 17:06:53 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 14 Jan 2020 18:06:53 +0100
Subject: RFR(S): 8237007: Shenandoah: assert(_base == Tuple) failure
 during C2 compilation
In-Reply-To: <87wo9v1wup.fsf@redhat.com>
References: <87wo9v1wup.fsf@redhat.com>
Message-ID: <6026815f-10ab-dc72-9322-4484e96ce43a@redhat.com>

Hi Roland,

It looks ok to me. I'd probably add case Op_CMove cases to the switch
instead.

Thanks,
Roman

> http://cr.openjdk.java.net/~roland/8237007/webrev.00/
> 
> The assert fails because C2 expands a barrier between a membar and its
> control projection. That happens because the gc barrier is assigned the
> membar as control by loop optimizations (and not its control
> projection). The gc barrier has a load as input which itself depends on
> the memory state produced by the membar so the barrier has to be below
> the membar. The gc barrier has a CMove as use. That CMove has a control
> input that's above the membar and because it's considered pinned by loop
> opts, it's assigned earliest possible control: the membar. Considering
> the CMove as pinned is overly conservative AFAICT. My fix consists in
> excluding CMove nodes from being pinned.
> 
> Roland.
> 


From hohensee at amazon.com  Tue Jan 14 17:17:52 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 14 Jan 2020 17:17:52 +0000
Subject: RFR(XXS): 8236228: clean up BarrierSet headers in c1_LIRAssembler
In-Reply-To: <AM0PR0202MB3297947242C472932EEDA27E9A340@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <1982726B-9702-4087-B962-354D2B9FAD92@amazon.com>
 <VE1PR08MB5053E9D17314A06E5549522890280@VE1PR08MB5053.eurprd08.prod.outlook.com>
 <3C45D717-C0BF-40A4-93F5-EDA78FE91350@amazon.com>
 <3CC88DEC-56BE-4FDA-B775-7678F44E252A@amazon.com>
 <EBF6337B-2C95-417C-9DB0-6C972EB66251@amazon.com>
 <2CDFB80B-04EA-4C95-A67A-1C1284C80C66@amazon.com>
 <AM0PR0202MB3297947242C472932EEDA27E9A340@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <72203708-CF49-47D7-B4C1-737E9E5C0B07@amazon.com>

Thanks, Martin. Ningsheng and Xin report that the submit repo run passed (below). Pushed.

Paul

?On 1/14/20, 1:03 AM, "Doerr, Martin" <martin.doerr at sap.com> wrote:

    Hi Xin and Paul,
    
    yes, if submission forest testing has passed, it can get pushed.
    
    Best regards,
    Martin
    
    
    > -----Original Message-----
    > From: hotspot-compiler-dev <hotspot-compiler-dev-
    > bounces at openjdk.java.net> On Behalf Of Hohensee, Paul
    > Sent: Montag, 13. Januar 2020 23:54
    > To: Liu, Xin <xxinliu at amazon.com>; Ningsheng Jian
    > <Ningsheng.Jian at arm.com>; Vladimir Kozlov <vladimir.kozlov at oracle.com>;
    > 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-
    > dev at openjdk.java.net>
    > Cc: nd <nd at arm.com>
    > Subject: Re: RFR(XXS): 8236228: clean up BarrierSet headers in
    > c1_LIRAssembler
    > 
    > Ping on behalf of Xin.
    > 
    > Thanks,
    > 
    > Paul
    > 
    > On 12/30/19, 2:39 PM, "Liu, Xin" <xxinliu at amazon.com> wrote:
    > 
    >     Hi, Reviewers,
    > 
    >     Thanks for reviewing it.  Paul is a reviewer.  Martin reviewed PPC and s390
    > and Ningsheng reviewed Arm&Aarch64.
    >     Is that good to push?
    > 
    >     Thanks,
    >     --lx
    > 
    > 
    > 
    > 
    >     On 12/30/19, 11:16 AM, "Hohensee, Paul" <hohensee at amazon.com>
    > wrote:
    > 
    >         Lgtm. Seems very low risk to me too.
    > 
    >         Paul
    > 
    >         On 12/26/19, 7:06 PM, "hotspot-compiler-dev on behalf of Liu, Xin"
    > <hotspot-compiler-dev-bounces at openjdk.java.net on behalf of
    > xxinliu at amazon.com> wrote:
    > 
    >             Hi, Ningsheng,
    >             Thank you for submitting the trial repo.  I got the result email and it has
    > passed all 80 tests.
    > 
    >             Here is the updated webrev.  I updated the reviewers.
    >             https://cr.openjdk.java.net/~xliu/8236228/01/webrev/
    > 
    >             This is a low-risk patch. As long as  we can compile it, it won't have any
    > side-effect at runtime.
    > 
    >             thanks,
    >             --lx
    > 
    >             On 12/24/19, 9:52 PM, "Ningsheng Jian" <Ningsheng.Jian at arm.com>
    > wrote:
    > 
    >                 Hi lx,
    > 
    >                 I've submitted it for you:
    > 
    >                 http://hg.openjdk.java.net/jdk/submit/rev/9d61b00d5982
    > 
    >                 I've also verified aarch64 and arm build locally, and it looks fine.
    > 
    >                 Thanks,
    >                 Ningsheng
    > 
    >                 > -----Original Message-----
    >                 > From: hotspot-compiler-dev <hotspot-compiler-dev-
    > bounces at openjdk.java.net>
    >                 > On Behalf Of Liu, Xin
    >                 > Sent: Wednesday, December 25, 2019 4:57 AM
    >                 > To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; 'hotspot-
    > compiler-
    >                 > dev at openjdk.java.net' <hotspot-compiler-
    > dev at openjdk.java.net>
    >                 > Subject: Re: RFR(XXS): 8236228: clean up BarrierSet headers in
    > c1_LIRAssembler
    >                 >
    >                 > I update the subject and switch back the corporation email.  Sorry, I
    > didn?t
    >                 > realize that there?s code of conduct. I will pay more attention on it.
    >                 >
    >                 > I validate the patch without PCH using --disable-precompiled-
    > headers on both
    >                 > x86_64 and aarch64. Both of them built well.
    >                 > I still have difficulty to verify SPARC. I try the submit repo but I
    > don?t have
    >                 > permission to push an experimental branch.  May I ask a sponsor
    > submit it on
    >                 > behalf of me?
    >                 >
    >                 > Thanks,
    >                 > --lx
    >                 >
    >                 >
    >                 >
    >                 >
    >                 > Hi Lx
    >                 >
    >                 > First, when you post RFR, please, include bug id in email's Subject.
    >                 >
    >                 > You can use jdk/submit testing to verify builds on SPARC. We are
    > still building on
    >                 > it, with warning.
    >                 > Changes seems fine to me but make sure verify that it builds
    > without PCH.
    >                 >
    >                 > Regards,
    >                 > Vladimir
    >                 >
    >                 > On 12/20/19 9:24 AM, Liu Xin wrote:
    >                 > > Martin?
    >                 > >
    >                 > > Thank you very much. May I know how to validate Sparc? I don't
    > have
    >                 > > any SPARC machine to access.
    >                 > >
    >                 > > Thanks,
    >                 > > --lx
    >                 > >
    >                 > >
    >                 > > On Fri, Dec 20, 2019, 7:05 AM Doerr, Martin
    >                 > <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
    >                 > >
    >                 > >> Hi lx,
    >                 > >>
    >                 > >> PPC and s390 parts are ok.
    >                 > >>
    >                 > >> Best regards,
    >                 > >> Martin
    >                 > >>
    >                 > >>
    >                 > >>> -----Original Message-----
    >                 > >>> From: hotspot-compiler-dev <hotspot-compiler-dev-
    >                 > >>>
    > bounces at openjdk.java.net<mailto:bounces at openjdk.java.net>> On Behalf
    >                 > >>> Of Liu, Xin
    >                 > >>> Sent: Freitag, 20. Dezember 2019 04:48
    >                 > >>> To:
    >                 > >>> 'hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-
    > compiler-dev at o
    >                 > >>> penjdk.java.net>' <hotspot-compiler-
    >                 > >>> dev at openjdk.java.net<mailto:dev at openjdk.java.net>>
    >                 > >>> Subject: [DMARC FAILURE] RFR(XXS): clean up BarrierSet
    > headers in
    >                 > >>> c1_LIRAssembler
    >                 > >>>
    >                 > >>> Hi, Reviewers,
    >                 > >>>
    >                 > >>> Could you take a look at my webrev? I feel that those
    > barrisetSet
    >                 > >> interfaces
    >                 > >>> have nothing with c1_LIRAssembler.
    >                 > >>>
    >                 > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236228
    >                 > >>> Webrev:
    > https://cr.openjdk.java.net/~xliu/8236228/00/webrev/
    >                 > >>>
    >                 > >>> I try to build on aarch64 and x86_64 and it?s fine.
    >                 > >>>
    >                 > >>> Thanks,
    >                 > >>> --lx
    >                 > >>
    >                 > >>
    > 
    > 
    > 
    > 
    > 
    > 
    > 
    
    


From tobias.hartmann at oracle.com  Wed Jan 15 06:06:25 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 15 Jan 2020 07:06:25 +0100
Subject: RFR(S): 8237007: Shenandoah: assert(_base == Tuple) failure
 during C2 compilation
In-Reply-To: <80847ab4-3b49-68c8-33af-8946fd14cda3@oracle.com>
References: <87wo9v1wup.fsf@redhat.com>
 <80847ab4-3b49-68c8-33af-8946fd14cda3@oracle.com>
Message-ID: <069e55af-de92-0525-d3c0-9dfef181381c@oracle.com>


On 14.01.20 17:13, Tobias Hartmann wrote:
> I'll run some testing.

Tests passed.

Best regards,
Tobias

From felix.yang at huawei.com  Wed Jan 15 08:55:45 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Wed, 15 Jan 2020 08:55:45 +0000
Subject: RFR(S): 8235762: JVM crash in SWPointer during C2 compilation
In-Reply-To: <dd6b9bc6-9042-2743-9cc1-b23cc50fc9b4@oracle.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DD8064@dggeml527-mbx.china.huawei.com>
 <e10a10b9-78ad-5ff7-5b55-571b7feae324@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD80DB@dggeml527-mbx.china.huawei.com>
 <4ef39906-839b-9a08-3225-f99b974f08de@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD8325@dggeml527-mbx.china.huawei.com>
 <d429870d-248e-bbb6-d296-d373c7e5affd@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DD88F1@dggeml527-mbx.china.huawei.com>
 <4103e17e-57c4-ed78-bf64-1bb3cb99e9f4@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DECF6D@dggeml507-mbx.china.huawei.com>
 <8797205a-c4ff-253d-404b-62a178c6e169@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DFA1AF@dggeml527-mbx.china.huawei.com>
 <dd6b9bc6-9042-2743-9cc1-b23cc50fc9b4@oracle.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA564@dggeml527-mbx.china.huawei.com>

Hi Nils,

    Thanks for giving it another review.  Will do the push.  

Best regards,
Felix

> 
> Hi Felix,
> 
> Your change looks good.
> 
> Thanks for fixing!
> 
> Best regards,
> Nils
> 
> On 2020-01-14 07:33, Yangfei (Felix) wrote:
> > Hi Tobias,
> >
> >      Thanks for reviewing this.  May I have another review please?
> >
> > Felix
> >
> >> -----Original Message-----
> >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com]
> >> Sent: Monday, January 13, 2020 7:28 PM
> >> To: Yangfei (Felix) <felix.yang at huawei.com>; Christian Hagedorn
> >> <christian.hagedorn at oracle.com>;
> >> hotspot-compiler-dev at openjdk.java.net
> >> Subject: Re: RFR(S): 8235762: JVM crash in SWPointer during C2
> >> compilation
> >>
> >> Hi Felix,
> >>
> >> looks reasonable to me. Thanks for updating.
> >>
> >> Another review would be good.
> >>
> >> Best regards,
> >> Tobias
> >>
> >> On 10.01.20 02:13, Yangfei (Felix) wrote:
> >>> Hi Tobias,
> >>>
> >>>    Updated webrev:
> http://cr.openjdk.java.net/~fyang/8235762/webrev.01/
> >>>    This also updated copyright years of the newly-added test case.
> >>>    Still test OK with the latest repo.  Is this one better?
> >>>
> >>> Thanks,
> >>> Felix
> >>>


From rwestrel at redhat.com  Wed Jan 15 09:01:47 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 15 Jan 2020 10:01:47 +0100
Subject: RFR(S): 8237007: Shenandoah: assert(_base == Tuple) failure
 during C2 compilation
In-Reply-To: <069e55af-de92-0525-d3c0-9dfef181381c@oracle.com>
References: <87wo9v1wup.fsf@redhat.com>
 <80847ab4-3b49-68c8-33af-8946fd14cda3@oracle.com>
 <069e55af-de92-0525-d3c0-9dfef181381c@oracle.com>
Message-ID: <87pnflytxg.fsf@redhat.com>


Hi Tobias,

Thanks for the review and testing.

Roland.


From rwestrel at redhat.com  Wed Jan 15 09:03:39 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 15 Jan 2020 10:03:39 +0100
Subject: RFR(S): 8237007: Shenandoah: assert(_base == Tuple) failure
 during C2 compilation
In-Reply-To: <6026815f-10ab-dc72-9322-4484e96ce43a@redhat.com>
References: <87wo9v1wup.fsf@redhat.com>
 <6026815f-10ab-dc72-9322-4484e96ce43a@redhat.com>
Message-ID: <87muapytuc.fsf@redhat.com>


Hi Roman,

> It looks ok to me. I'd probably add case Op_CMove cases to the switch
> instead.

Thanks for looking at this. I would have to list all variants in the
switch:

CMoveD
CMoveVD
CMoveF
CMoveVF
CMoveI
CMoveL
CMoveP
CMoveN

That doesn't seem better to me and is quite error prone too.

Roland.


From rwestrel at redhat.com  Wed Jan 15 09:39:41 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 15 Jan 2020 10:39:41 +0100
Subject: RFR(S): 8235584: UseProfiledLoopPredicate fails with
 assert(_phase->get_loop(c) == loop) failed: have to be in the same loop
In-Reply-To: <a22be69b-6b07-a12f-d9f7-5c367b2d1393@oracle.com>
References: <87r2031va5.fsf@redhat.com>
 <1a4c0874-946b-aea3-fe83-ac5e2b9f1862@oracle.com>
 <a22be69b-6b07-a12f-d9f7-5c367b2d1393@oracle.com>
Message-ID: <87k15tys6a.fsf@redhat.com>


Thanks for the review, Nils.

Roland.


From rwestrel at redhat.com  Wed Jan 15 09:40:29 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 15 Jan 2020 10:40:29 +0100
Subject: RFR(S): 8231291: C2: loop opts before EA should maximally unroll
 loops
In-Reply-To: <B15E6478-B809-48AF-9D24-FB0763833D81@oracle.com>
References: <875zhe1659.fsf@redhat.com>
 <B15E6478-B809-48AF-9D24-FB0763833D81@oracle.com>
Message-ID: <87h80xys4y.fsf@redhat.com>


Thanks for the review, Vladimir.

Roland.


From rkennke at redhat.com  Wed Jan 15 09:44:10 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 15 Jan 2020 10:44:10 +0100
Subject: RFR(S): 8237007: Shenandoah: assert(_base == Tuple) failure
 during C2 compilation
In-Reply-To: <87muapytuc.fsf@redhat.com>
References: <87wo9v1wup.fsf@redhat.com>
 <6026815f-10ab-dc72-9322-4484e96ce43a@redhat.com> <87muapytuc.fsf@redhat.com>
Message-ID: <22c15858-02fd-4606-136b-8a86f8246c7d@redhat.com>

Hi Roland,

>> It looks ok to me. I'd probably add case Op_CMove cases to the switch
>> instead.
> 
> Thanks for looking at this. I would have to list all variants in the
> switch:
> 
> CMoveD
> CMoveVD
> CMoveF
> CMoveVF
> CMoveI
> CMoveL
> CMoveP
> CMoveN
> 
> That doesn't seem better to me and is quite error prone too.

Yes, true. It's the case for Op_Load* above too, and less pronounced for
Div, Mod, etc. I don't have a strong preference either way, your call.

Patch is good.

Thank you!
Roman


From rwestrel at redhat.com  Wed Jan 15 10:08:17 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 15 Jan 2020 11:08:17 +0100
Subject: [15] RFR(S): 8235332: TestInstanceCloneAsLoadsStores.java fails
 with -XX:+StressGCM
In-Reply-To: <3f4d0542-5d72-dca4-d14d-7a13402fbf1c@oracle.com>
References: <2ef5e2fd-d73c-5e1f-e50f-8ea36cd24029@oracle.com>
 <87zheqyuj2.fsf@redhat.com> <3f4d0542-5d72-dca4-d14d-7a13402fbf1c@oracle.com>
Message-ID: <87eew1yqum.fsf@redhat.com>


>> If there's no GC barrier then:
>> 
>> Node* control_proj_ac = bs->step_over_gc_barrier(proj_in->in(0));
>> 
>> control_proj_ac is not a projection, it's proj_in->in(0) so the test
>> below can never succeed?
>
> If there is no GC barrier, then proj_in is a membar with its control 
> input being a control projection from the ArrayCopyNode.
>
> As an example, I have taken the test case TestEliminatedCloneBadMemEdge 
> [1] which does not disable ReduceInitialCardMarks and has no GC barrier. 
> We have the following situation at [2]:
>
> proj_in is 132 MemBarCPUOrder. The original code then looked at the 
> MergeMem 100 input following in(Compile::AliasIdxRaw) which is 101 Proj 
> and its input 98 ArrayCopy. This passes the check.
>
> My fix now directly looks at the control input of 132 MemBarCPUOrder 
> which is the projection 99 Proj coming from the 98 ArrayCopy. This also 
> passes the check.

Ah! Right. I wonder if there's a reason why the current code follows the
control graph (as you do) instead of the memory graph. I couldn't find
one and your change looks good to me.

Roland.


From christian.hagedorn at oracle.com  Wed Jan 15 11:02:52 2020
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Wed, 15 Jan 2020 12:02:52 +0100
Subject: [15] RFR(S): 8235332: TestInstanceCloneAsLoadsStores.java fails
 with -XX:+StressGCM
In-Reply-To: <87eew1yqum.fsf@redhat.com>
References: <2ef5e2fd-d73c-5e1f-e50f-8ea36cd24029@oracle.com>
 <87zheqyuj2.fsf@redhat.com> <3f4d0542-5d72-dca4-d14d-7a13402fbf1c@oracle.com>
 <87eew1yqum.fsf@redhat.com>
Message-ID: <d2189e04-b4e1-a502-910a-cf14b466fb01@oracle.com>

>>> If there's no GC barrier then:
>>>
>>> Node* control_proj_ac = bs->step_over_gc_barrier(proj_in->in(0));
>>>
>>> control_proj_ac is not a projection, it's proj_in->in(0) so the test
>>> below can never succeed?
>>
>> If there is no GC barrier, then proj_in is a membar with its control
>> input being a control projection from the ArrayCopyNode.
>>
>> As an example, I have taken the test case TestEliminatedCloneBadMemEdge
>> [1] which does not disable ReduceInitialCardMarks and has no GC barrier.
>> We have the following situation at [2]:
>>
>> proj_in is 132 MemBarCPUOrder. The original code then looked at the
>> MergeMem 100 input following in(Compile::AliasIdxRaw) which is 101 Proj
>> and its input 98 ArrayCopy. This passes the check.
>>
>> My fix now directly looks at the control input of 132 MemBarCPUOrder
>> which is the projection 99 Proj coming from the 98 ArrayCopy. This also
>> passes the check.
> 
> Ah! Right. I wonder if there's a reason why the current code follows the
> control graph (as you do) instead of the memory graph. I couldn't find
> one and your change looks good to me.

Thank you for your review Roland! Was wondering about that, too.

Best regards,
Christian

From vladimir.kozlov at oracle.com  Wed Jan 15 18:08:39 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 15 Jan 2020 10:08:39 -0800
Subject: [14] RFR (T) 8236726: Put vmTestbase/vm/mlvm/indy/stress/java tests
 on AOT Problem list
Message-ID: <37b1ce65-749d-1d14-29e6-3620db823e9e@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8236726

I need more time to work on 8226689 [1]. I can't reproduce failure locally - it seems very intermittent.
For JDK 14 I suggest to put failed tests on AOT problem list to skip them.

Thanks,
Vladimir

diff -r 5b2e2fdb4d19 test/hotspot/jtreg/ProblemList-aot.txt
--- a/test/hotspot/jtreg/ProblemList-aot.txt
+++ b/test/hotspot/jtreg/ProblemList-aot.txt
@@ -81,3 +81,5 @@
  compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java    8167430 generic-all
  compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java  8167430 generic-all

+vmTestbase/vm/mlvm/indy/stress/java/relinkMutableCallSiteFreq/Test.java   8226689 generic-all
+vmTestbase/vm/mlvm/indy/stress/java/relinkVolatileCallSiteFreq/Test.java  8226689 generic-all


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

From igor.ignatyev at oracle.com  Wed Jan 15 18:43:59 2020
From: igor.ignatyev at oracle.com (Igor Ignatev)
Date: Wed, 15 Jan 2020 10:43:59 -0800
Subject: [14] RFR (T) 8236726: Put vmTestbase/vm/mlvm/indy/stress/java
 tests on AOT Problem list
In-Reply-To: <37b1ce65-749d-1d14-29e6-3620db823e9e@oracle.com>
References: <37b1ce65-749d-1d14-29e6-3620db823e9e@oracle.com>
Message-ID: <82CE54AD-5AF2-4C48-8A6C-DEBBE43EA9C4@oracle.com>

LGTM

? Igor

> On Jan 15, 2020, at 10:09 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> ?https://bugs.openjdk.java.net/browse/JDK-8236726
> 
> I need more time to work on 8226689 [1]. I can't reproduce failure locally - it seems very intermittent.
> For JDK 14 I suggest to put failed tests on AOT problem list to skip them.
> 
> Thanks,
> Vladimir
> 
> diff -r 5b2e2fdb4d19 test/hotspot/jtreg/ProblemList-aot.txt
> --- a/test/hotspot/jtreg/ProblemList-aot.txt
> +++ b/test/hotspot/jtreg/ProblemList-aot.txt
> @@ -81,3 +81,5 @@
> compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java    8167430 generic-all
> compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java  8167430 generic-all
> 
> +vmTestbase/vm/mlvm/indy/stress/java/relinkMutableCallSiteFreq/Test.java   8226689 generic-all
> +vmTestbase/vm/mlvm/indy/stress/java/relinkVolatileCallSiteFreq/Test.java  8226689 generic-all
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8226689


From vladimir.kozlov at oracle.com  Wed Jan 15 19:01:20 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 15 Jan 2020 11:01:20 -0800
Subject: [14] RFR (T) 8236726: Put vmTestbase/vm/mlvm/indy/stress/java
 tests on AOT Problem list
In-Reply-To: <82CE54AD-5AF2-4C48-8A6C-DEBBE43EA9C4@oracle.com>
References: <37b1ce65-749d-1d14-29e6-3620db823e9e@oracle.com>
 <82CE54AD-5AF2-4C48-8A6C-DEBBE43EA9C4@oracle.com>
Message-ID: <90ac9bdb-0835-ac27-241e-5741ce1f539d@oracle.com>

Thank you, Igor

Vladimir

On 1/15/20 10:43 AM, Igor Ignatev wrote:
> LGTM
> 
> ? Igor
> 
>> On Jan 15, 2020, at 10:09 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> ?https://bugs.openjdk.java.net/browse/JDK-8236726
>>
>> I need more time to work on 8226689 [1]. I can't reproduce failure locally - it seems very intermittent.
>> For JDK 14 I suggest to put failed tests on AOT problem list to skip them.
>>
>> Thanks,
>> Vladimir
>>
>> diff -r 5b2e2fdb4d19 test/hotspot/jtreg/ProblemList-aot.txt
>> --- a/test/hotspot/jtreg/ProblemList-aot.txt
>> +++ b/test/hotspot/jtreg/ProblemList-aot.txt
>> @@ -81,3 +81,5 @@
>> compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java    8167430 generic-all
>> compiler/intrinsics/sha/sanity/TestSHA512MultiBlockIntrinsics.java  8167430 generic-all
>>
>> +vmTestbase/vm/mlvm/indy/stress/java/relinkMutableCallSiteFreq/Test.java   8226689 generic-all
>> +vmTestbase/vm/mlvm/indy/stress/java/relinkVolatileCallSiteFreq/Test.java  8226689 generic-all
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8226689
> 

From martin.doerr at sap.com  Thu Jan 16 13:30:37 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 16 Jan 2020 13:30:37 +0000
Subject: RFR: 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <b220902b-e919-7fb1-7562-536b58c4f130@redhat.com>
References: <DM5PR2101MB1095F787A3769192A6B76474AC530@DM5PR2101MB1095.namprd21.prod.outlook.com>
 <87h81wl7vo.fsf@redhat.com>
 <AM0PR0202MB329784C5DA98D4865422A3989A520@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <87bls3ksen.fsf@redhat.com>
 <AM0PR0202MB3297533FFED6DCCC7A8482189A2D0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <875zibkmyq.fsf@redhat.com>
 <AM0PR0202MB32976EC81BACF131049410239A2D0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <0e22c4e6-74b9-a50b-df44-83c332457f14@redhat.com>
 <DM5PR2101MB1095E88DD902B679320EB0DFAC2D0@DM5PR2101MB1095.namprd21.prod.outlook.com>
 <b220902b-e919-7fb1-7562-536b58c4f130@redhat.com>
Message-ID: <AM0PR0202MB32975840A744A4E23AE61BB79A360@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Roman,

fix is in 11.0.7., 14 and 15, now.
Only backport to 8u is missing (I'm not working on 8u backports).

Best regards,
Martin


> -----Original Message-----
> From: Roman Kennke <rkennke at redhat.com>
> Sent: Freitag, 20. Dezember 2019 21:37
> To: Aditya Mandaleeka <adityam at microsoft.com>; Doerr, Martin
> <martin.doerr at sap.com>; Roland Westrelin <rwestrel at redhat.com>;
> hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> Cc: shenandoah-dev <shenandoah-dev at openjdk.java.net>
> Subject: Re: RFR: 8236179: C1 register allocation error with T_ADDRESS
> 
> Hi Aditya,
> 
> > Thanks again to everyone who helped get this change in! I am happy to
> help backport it as well if it can wait until January.
> 
> Thank *you* for figuring this out in the first place. This seems a
> rather serious bug for Shenandoah GC (and I'm still a bit surprised how
> we haven't seen it yet). I just realized we're also gonna need it in
> JDK14. I am not even quite sure what the process for this would be.
> We'll figure it out.
> 
> Thank you!
> 
> Roman
> 
> 
> > Thanks,
> > Aditya
> >
> > -----Original Message-----
> > From: Roman Kennke <rkennke at redhat.com>
> > Sent: Friday, December 20, 2019 11:59 AM
> > To: Doerr, Martin <martin.doerr at sap.com>; Roland Westrelin
> <rwestrel at redhat.com>; Aditya Mandaleeka <adityam at microsoft.com>;
> hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> > Cc: shenandoah-dev <shenandoah-dev at openjdk.java.net>
> > Subject: Re: RFR: 8236179: C1 register allocation error with T_ADDRESS
> >
> > Hi Martin,
> >
> >> thanks for reviewing it. Pushed to jdk/jdk.
> >
> > Thanks a lot!
> >
> >> I guess we'll have to backport it after some testing time.
> >
> > Yes, we're gonna need it in 11u and 8u.
> >
> > Thanks and have a nice weekend (and xmas, etc, if you're also taking time
> off)!
> >
> > Cheers,
> > Roman
> >
> >> Best regards,
> >> Martin
> >>
> >>
> >>> -----Original Message-----
> >>> From: Roland Westrelin <rwestrel at redhat.com>
> >>> Sent: Freitag, 20. Dezember 2019 16:59
> >>> To: Doerr, Martin <martin.doerr at sap.com>; Aditya Mandaleeka
> >>> <adityam at microsoft.com>; hotspot compiler <hotspot-compiler-
> >>> dev at openjdk.java.net>
> >>> Cc: shenandoah-dev <shenandoah-dev at openjdk.java.net>
> >>> Subject: RE: RFR: 8236179: C1 register allocation error with
> >>> T_ADDRESS
> >>>
> >>>
> >>>>
> http://cr.openjdk.java.net/~mdoerr/8236179_C1_T_ADDRESS/webrev.02/
> >>>
> >>> That looks good to me.
> >>>
> >>> Roland.
> >>
> >


From tobias.hartmann at oracle.com  Fri Jan 17 11:07:37 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 17 Jan 2020 12:07:37 +0100
Subject: [15] RFR(M): 8236493: C2: Inconsistent known instance type
 information after EA
In-Reply-To: <4ee2aba1-2e74-fdc5-f2e0-edb96f809d7b@oracle.com>
References: <4ee2aba1-2e74-fdc5-f2e0-edb96f809d7b@oracle.com>
Message-ID: <4a3e8089-bad3-57bf-cd95-27ed2cee3e55@oracle.com>

Hi,

I found some non-trivial issues with this. I will follow up with a new webrev after fixing.

Thanks,
Tobias

On 14.01.20 15:06, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8236493
> http://cr.openjdk.java.net/~thartmann/8236493/webrev.00/
> 
> While working on 8233164, I've noticed that escape analysis does not set known instance type
> information for LoadNodes and their users if the loaded object does not escape but that information
> is only (incrementally) propagated during IGVN. That's a problem because depending on the sequence
> in which nodes on the worklist are processed, optimizations might still see the not-yet-updated (and
> therefore incorrect) type. For example, another LoadNode optimization might rely on it's memory
> input to be a general memory slice and re-wire it's inputs accordingly (ignoring known instance type
> memory), when it is really reading from a known instance.
> 
> For a detailed description of an instance of such a problem, see my RFR for 8233164 [1]. There, the
> type of a CastPPNode is not updated (yet) and a Load user is incorrectly re-wired.
> 
> To catch this case before things go horribly wrong, I've added an assert to
> Node::raise_bottom_type(). Reverting the fix for 8233164 now immediately triggers the assert because
> the known instance id of a DecodeNNode is only updated during IGVN [2]. All new tests in
> TestInstanceIdPropagation.java trigger the assert as well.
> 
> The fix is to always eagerly propagate that information during EA. If an object loaded from the
> field of a non-escaping object is also non-escaping, we need to propagate that information.
> 
> Thanks,
> Tobias
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-December/036616.html
> 
> [2] Failure with TestArrayCopyMemoryChain.java when reverting fix for 8233164:
> 
>  300	Proj	===  288  [[ 301  305  312 ]] #5 !jvms: TestArrayCopyMemoryChain::test2 @ bci:25
>  305	CheckCastPP	===  302  300  [[ 385  316 ]]  #byte[int:1]:NotNull:exact *,iid=288 !jvms:
> TestArrayCopyMemoryChain::test2 @ bci:25
>  385	EncodeP	=== _  305  [[ 387  403 ]]  #narrowoop: byte[int:1]:NotNull:exact *,iid=288 !orig=[402]
> !jvms: TestArrayCopyMemoryChain$Wrapper::<init> @ bci:11 TestArrayCopyMemoryChain::test2 @ bci:41
>  403 >	DecodeN	=== _  385  [[ 494  420 ]]  #byte[int:1]:NotNull:exact *,iid=288 !jvms:
> TestArrayCopyMemoryChain::test2 @ bci:48
>  494	CastPP	===  486  403  [[ 526  514 ]]  #byte[int:>=0]:NotNull:exact * !jvms:
> TestArrayCopyMemoryChain::test2 @ bci:71
>  420	CallStaticJava	===  404  327  341  8  9 ( 419  1  1  1  64  1  1  1  403  257  43  64  11  230
> ) [[ 421 ]] # Static uncommon_trap(reason='intrinsic_or_type_checked_inlining'
> action='make_not_entrant' debug_id='0')  void ( int ) C=0.000100 TestArrayCopyMemoryChain::test2 @
> bci:61 !jvms: TestArrayCopyMemoryChain::test2 @ bci:61
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/node.cpp:1088
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/oracle/jdk_jdk/open/src/hotspot/share/opto/node.cpp:1088), pid=6482, tid=6496
> #  assert(false) failed: Known instance type should have been set during EA
> 

From tom.rodriguez at oracle.com  Fri Jan 17 21:10:58 2020
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 17 Jan 2020 13:10:58 -0800
Subject: [14] RFR (M) 8231515: [Graal] Crash during exception throwing in
 InterpreterRuntime::resolve_invoke
Message-ID: <d85579b8-f324-c4c2-5959-e0925ca0a734@oracle.com>

This fixes two separate but related issues. The primary crash is the 
JVMTI crash when using the post on exceptions support. In that case we 
use a FrameState which isn't suitable for deopt and we will crash if 
that deopt is taken. The second issue is related but more rare where our 
support for explicit exception throwing uses a stub that has a 
FrameState which is also not suitable for deopt. It's more rare because 
deoptimization in that path is much less likely. New logic was added to 
Graal to verify the FrameStates used for deopt which caught both of 
these problems. Minor changes to JVMCI were made to expose information 
to Graal but there are no changes that would affect anything besides 
Graal. New unit tests exercise these paths explicitly and local 
kitchensink testing of the fix inidicates that there were no more 
crashes with Graal. preliminary mach5 testing against 15 was clean but 
mach5 testing against jdk 14 is in progress.

http://cr.openjdk.java.net/~never/8231515/webrev
https://bugs.openjdk.java.net/browse/JDK-8231515

From vladimir.kozlov at oracle.com  Fri Jan 17 23:12:15 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 17 Jan 2020 15:12:15 -0800
Subject: [14] RFR (M) 8231515: [Graal] Crash during exception throwing in
 InterpreterRuntime::resolve_invoke
In-Reply-To: <d85579b8-f324-c4c2-5959-e0925ca0a734@oracle.com>
References: <d85579b8-f324-c4c2-5959-e0925ca0a734@oracle.com>
Message-ID: <c7699169-ffa8-02a4-2afe-1238fe3ba5ab@oracle.com>

Looks good.

Only small nitpick is spacing of '\' in new line in vmStructs_jvmci.cpp. No need for new webrev.

Note for records, it was reviewed by Dean already in Graal's PR.

Thanks,
Vladimir

On 1/17/20 1:10 PM, Tom Rodriguez wrote:
> This fixes two separate but related issues. The primary crash is the JVMTI crash when using the post on exceptions 
> support. In that case we use a FrameState which isn't suitable for deopt and we will crash if that deopt is taken. The 
> second issue is related but more rare where our support for explicit exception throwing uses a stub that has a 
> FrameState which is also not suitable for deopt. It's more rare because deoptimization in that path is much less likely. 
> New logic was added to Graal to verify the FrameStates used for deopt which caught both of these problems. Minor changes 
> to JVMCI were made to expose information to Graal but there are no changes that would affect anything besides Graal. New 
> unit tests exercise these paths explicitly and local kitchensink testing of the fix inidicates that there were no more 
> crashes with Graal. preliminary mach5 testing against 15 was clean but mach5 testing against jdk 14 is in progress.
> 
> http://cr.openjdk.java.net/~never/8231515/webrev
> https://bugs.openjdk.java.net/browse/JDK-8231515

From martin.doerr at sap.com  Mon Jan 20 14:25:26 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 20 Jan 2020 14:25:26 +0000
Subject: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay timestamp
 initialization
Message-ID: <AM0PR0202MB3297906E589CFAFF4635130B9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi,

I'd like to fix warmup issues we observed in test compiler/c2/Test8004741.java.
The issue is a missing timestamp initialization which leads to a premature counter decay at the first safepoint with -XX:-TieredCompilation.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8237375

Webrev:
http://cr.openjdk.java.net/~mdoerr/8237375_CounterDecay/webrev.00/
The webrev applies on top of the preliminary fix for https://bugs.openjdk.java.net/browse/JDK-8235741.
I'll wait until that one gets pushed.

What it changes:

  *   Move class CounterDecay up
  *   Introduce reset_last_timestamp()
  *   Use this function in decay() and in SimpleCompPolicy::initialize()

Best regards,
Martin


From volker.simonis at gmail.com  Mon Jan 20 17:57:57 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 20 Jan 2020 09:57:57 -0800
Subject: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
 timestamp initialization
In-Reply-To: <AM0PR0202MB3297906E589CFAFF4635130B9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3297906E589CFAFF4635130B9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <CA+3eh13jR7OJ8zKTapnx42EDsGqX0qufemm1AoN7QTs=qhFRyw@mail.gmail.com>

Looks good to me.

Thanks,
Volker

On Mon, Jan 20, 2020 at 6:26 AM Doerr, Martin <martin.doerr at sap.com> wrote:
>
> Hi,
>
> I'd like to fix warmup issues we observed in test compiler/c2/Test8004741.java.
> The issue is a missing timestamp initialization which leads to a premature counter decay at the first safepoint with -XX:-TieredCompilation.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8237375
>
> Webrev:
> http://cr.openjdk.java.net/~mdoerr/8237375_CounterDecay/webrev.00/
> The webrev applies on top of the preliminary fix for https://bugs.openjdk.java.net/browse/JDK-8235741.
> I'll wait until that one gets pushed.
>
> What it changes:
>
>   *   Move class CounterDecay up
>   *   Introduce reset_last_timestamp()
>   *   Use this function in decay() and in SimpleCompPolicy::initialize()
>
> Best regards,
> Martin
>

From david.holmes at oracle.com  Mon Jan 20 21:53:36 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Jan 2020 07:53:36 +1000
Subject: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
 timestamp initialization
In-Reply-To: <AM0PR0202MB3297906E589CFAFF4635130B9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3297906E589CFAFF4635130B9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <a8c76ca9-8198-be6a-a81d-d6b19a9ef8fb@oracle.com>

Hi Martin,

On 21/01/2020 12:25 am, Doerr, Martin wrote:
> Hi,
> 
> I?d like to fix warmup issues we observed in test 
> compiler/c2/Test8004741.java.
> 
> The issue is a missing timestamp initialization which leads to a 
> premature counter decay at the first safepoint with -XX:-TieredCompilation.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8237375
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~mdoerr/8237375_CounterDecay/webrev.00/
> 
> The webrev applies on top of the preliminary fix for 
> https://bugs.openjdk.java.net/browse/JDK-8235741.
> 
> I?ll wait until that one gets pushed.
> 
> What it changes:
> 
>   * Move class CounterDecay up
>   * Introduce reset_last_timestamp()

"reset" suggests clearing or moving back to an original value to me. How 
about just "set" or "update"?

Cheers,
David

>   * Use this function in decay() and in SimpleCompPolicy::initialize()
> 
> Best regards,
> 
> Martin
> 

From xxinliu at amazon.com  Mon Jan 20 22:24:53 2020
From: xxinliu at amazon.com (Liu, Xin)
Date: Mon, 20 Jan 2020 22:24:53 +0000
Subject: Does C2 disable incremental inlining for methods without @ForceInline?
Message-ID: <39E5D093-E575-4850-BBC3-9ED0A99B403D@amazon.com>

Hi,  hotspot-compiler,

If I understand correctly, C2 has actually disabled incremental inlining for almost all methods without @ForceInline.  Is it intentional?

2 positions check !callee-force_inline().

1. https://hg.openjdk.java.net/jdk/jdk/file/76b9822d2e65/src/hotspot/share/opto/bytecodeInfo.cpp#l368
2. https://hg.openjdk.java.net/jdk/jdk/file/76b9822d2e65/src/hotspot/share/opto/bytecodeInfo.cpp#l474

I ran ?dacapo/eclipse? and got 5345 inline failure msg ?size > DesiredMethodLimit?
If I comment out these 2 checks,  those messages will be all gone.  By checking LogCompilation, I can confirm that 386 more methods are inlined by incremental inlining.

jdk333 is baseline.
jdk335 is with the patch that comments out !callee-force_inline().
diff --git a/src/hotspot/share/opto/bytecodeInfo.cpp b/src/hotspot/share/opto/bytecodeInfo.cpp
--- a/src/hotspot/share/opto/bytecodeInfo.cpp
+++ b/src/hotspot/share/opto/bytecodeInfo.cpp
@@ -365,7 +365,7 @@
                                WarmCallInfo* wci_result, bool& should_delay) {

   if (ClipInlining && (int)count_inline_bcs() >= DesiredMethodLimit) {
-    if (!callee_method->force_inline() || !IncrementalInline) {
+    if (/*!callee_method->force_inline() || */!IncrementalInline) {
       set_msg("size > DesiredMethodLimit");
       return false;
     } else if (!C->inlining_incrementally()) {
@@ -471,7 +471,7 @@
   int size = callee_method->code_size_for_inlining();

   if (ClipInlining && (int)count_inline_bcs() + size >= DesiredMethodLimit) {
-    if (!callee_method->force_inline() || !IncrementalInline) {
+    if (/*!callee_method->force_inline() || */!IncrementalInline) {
       set_msg("size > DesiredMethodLimit");
       return false;
     } else if (!C->inlining_incrementally()) {


386 more methods are late_inlined.

% grep "late_inline method=" jit_jdk333.xml | wc -l
162

% grep "late_inline method=" jit_jdk335.xml | wc -l
548
Eg.
//jdk333.log
@ 3299   org.eclipse.jdt.internal.compiler.parser.Parser::consumeClassOrInterfaceName (19 bytes)   size > DesiredMethodLimit
//Jdk335.log
@ 3299   org.eclipse.jdt.internal.compiler.parser.Parser::consumeClassOrInterfaceName (19 bytes)   inline (hot)
       @ 10   org.eclipse.jdt.internal.compiler.parser.Parser::pushOnGenericsIdentifiersLengthStack (53 bytes)   inline (hot)
       @ 15   org.eclipse.jdt.internal.compiler.parser.Parser::pushOnGenericsLengthStack (53 bytes)   inline (hot)


The reason I ran dacapo/eclipse because I observed the most ?size > DesiredMethodLimit? so far.  Unfortunately, I can?t observe performance gain. My understanding is dacapo/eclipse is too big. The background noise can easily overshadow this tiny inlining gain. My understanding is incremental inlining is especially useful when C2 optimizer can slim down methods from over-threshold to below-threshold. I plan to make up a microbench to prove my point. Is it worth digging?

Thanks,
--lx






From Pengfei.Li at arm.com  Tue Jan 21 08:40:11 2020
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Tue, 21 Jan 2020 08:40:11 +0000
Subject: RFR(S): 8237524: AArch64: String.compareTo() may return incorrect
 result
Message-ID: <DB7PR08MB3115A91957168FF38760DC47960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi,

Please help review this small fix on AArch64 string intrinsics.

JBS: https://bugs.openjdk.java.net/browse/JDK-8237524
Webrev: http://cr.openjdk.java.net/~pli/rfr/8237524/webrev.00/

AArch64 String.compareTo() may return incorrect result in some corner
cases. This issue can be reproduced in below program by constructing two
strings from the same byte array but with different encoding options.

--------

import java.lang.reflect.Constructor;

public class Test {
  public static void main(String[] args) throws Exception {
    Constructor<String> c = String.class.getDeclaredConstructor(byte[].class, byte.class);
    c.setAccessible(true);

    byte[] bytes = new byte[] {
      'Y', 'm', '_', 'l', 'V', 'n', 'W', 'S', 'w', 'm', 'W', 'S'
    };

    String s1 = c.newInstance(bytes, (byte) 0);
    String s2 = c.newInstance(bytes, (byte) 1);
    System.out.println(s1.compareTo(s2));
  }
}

// $ java -Xint Test
// -27904
// $ java -Xcomp -XX:-TieredCompilation Test
// 6

--------

Root cause is in the AArch64 String.compareTo intrinsics. In the code of
MacroAssembler::string_compare(), we have a fast path that compares the
addresses of initial bytes of the two arrays. If the result is equal, we
skip the inflation of the Latin one and the byte-wise comparison part.
But we shouldn't do in this way if the encodings of the two strings are
different (the LU/UL cases). This patch removes the incorrect fast path
check.

Tests:
No new failure found in hotspot::hotspot_all_no_apps, jdk::jdk_core,
langtools::tier1 after this patch. A new jtreg case is also added for
this issue.

--
Thanks,
Pengfei


From rwestrel at redhat.com  Tue Jan 21 08:46:24 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 21 Jan 2020 09:46:24 +0100
Subject: Does C2 disable incremental inlining for methods without
 @ForceInline?
In-Reply-To: <39E5D093-E575-4850-BBC3-9ED0A99B403D@amazon.com>
References: <39E5D093-E575-4850-BBC3-9ED0A99B403D@amazon.com>
Message-ID: <87y2u1xkm7.fsf@redhat.com>


Hi lx,

> If I understand correctly, C2 has actually disabled incremental
> inlining for almost all methods without @ForceInline.  Is it
> intentional?

Incremental inlining was implemented to help with method
handle/invokedynamic and dynamic languages performance (nashorn at the
time). The problem there is that inlining through a method handle invoke
causes the inlining budget to be exhausted quickly both because the
graph grows fast and the inlining budget estimate C2 uses (number of
nodes in the graph estimated during parsing as number of nodes added to
the graph) is especially inaccurate for method invoke handle because the
graph at the call optimizes well. So the idea is that once the inlining
budget is exhausted, we run a pass of IGVN to clean the graph, count the
number of actual live nodes to have an accurate estimate of the graph
size and resume inlining with incremental inlining if the inlining
budget allows it.

There was no attempt at using incremental inlining for "regular" java
programs eventhough with lambdas, java code relies on invokedynamic and
so should trigger incremental inlining.

Roland.


From aph at redhat.com  Tue Jan 21 09:33:33 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Jan 2020 09:33:33 +0000
Subject: RFR(S): 8237524: AArch64: String.compareTo() may return incorrect
 result
In-Reply-To: <DB7PR08MB3115A91957168FF38760DC47960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115A91957168FF38760DC47960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <5111fcc0-9c3a-6f1b-9d6a-b666a41f4453@redhat.com>

On 1/21/20 8:40 AM, Pengfei Li wrote:
> Root cause is in the AArch64 String.compareTo intrinsics. In the code of
> MacroAssembler::string_compare(), we have a fast path that compares the
> addresses of initial bytes of the two arrays. If the result is equal, we
> skip the inflation of the Latin one and the byte-wise comparison part.
> But we shouldn't do in this way if the encodings of the two strings are
> different (the LU/UL cases). This patch removes the incorrect fast path
> check.

Is this really a bug? The test case is violating the protections
provided by the Java runtime, and the programmer deserves everything
that happens.

-- 
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 nick.gasson at arm.com  Tue Jan 21 10:11:25 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Tue, 21 Jan 2020 18:11:25 +0800
Subject: [aarch64-port-dev ] RFR(S): 8237524: AArch64: String.compareTo()
 may return incorrect result
In-Reply-To: <5111fcc0-9c3a-6f1b-9d6a-b666a41f4453@redhat.com>
References: <DB7PR08MB3115A91957168FF38760DC47960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <5111fcc0-9c3a-6f1b-9d6a-b666a41f4453@redhat.com>
Message-ID: <b5469d1a-82c8-1346-e658-0157a4a95da9@arm.com>

On 21/01/2020 17:33, Andrew Haley wrote:
> On 1/21/20 8:40 AM, Pengfei Li wrote:
>> Root cause is in the AArch64 String.compareTo intrinsics. In the code of
>> MacroAssembler::string_compare(), we have a fast path that compares the
>> addresses of initial bytes of the two arrays. If the result is equal, we
>> skip the inflation of the Latin one and the byte-wise comparison part.
>> But we shouldn't do in this way if the encodings of the two strings are
>> different (the LU/UL cases). This patch removes the incorrect fast path
>> check.
> 
> Is this really a bug? The test case is violating the protections
> provided by the Java runtime, and the programmer deserves everything
> that happens.
> 

Even if it's not strictly a bug, the pointer equality checks in the 
LU/UL branches are unnecessary: the only time they succeed is when the 
Strings were constructed in this backdoor way, and in that case they 
give the wrong result. So it seems better to just remove them.


Nick

From aph at redhat.com  Tue Jan 21 10:12:34 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Jan 2020 10:12:34 +0000
Subject: [aarch64-port-dev ] RFR(S): 8237524: AArch64: String.compareTo()
 may return incorrect result
In-Reply-To: <b5469d1a-82c8-1346-e658-0157a4a95da9@arm.com>
References: <DB7PR08MB3115A91957168FF38760DC47960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <5111fcc0-9c3a-6f1b-9d6a-b666a41f4453@redhat.com>
 <b5469d1a-82c8-1346-e658-0157a4a95da9@arm.com>
Message-ID: <56670d62-defa-4192-c084-bfa130adde41@redhat.com>

On 1/21/20 10:11 AM, Nick Gasson wrote:
> On 21/01/2020 17:33, Andrew Haley wrote:
>> On 1/21/20 8:40 AM, Pengfei Li wrote:
>>> Root cause is in the AArch64 String.compareTo intrinsics. In the code of
>>> MacroAssembler::string_compare(), we have a fast path that compares the
>>> addresses of initial bytes of the two arrays. If the result is equal, we
>>> skip the inflation of the Latin one and the byte-wise comparison part.
>>> But we shouldn't do in this way if the encodings of the two strings are
>>> different (the LU/UL cases). This patch removes the incorrect fast path
>>> check.
>>
>> Is this really a bug? The test case is violating the protections
>> provided by the Java runtime, and the programmer deserves everything
>> that happens.
> 
> Even if it's not strictly a bug, the pointer equality checks in the 
> LU/UL branches are unnecessary: the only time they succeed is when the 
> Strings were constructed in this backdoor way, and in that case they 
> give the wrong result. So it seems better to just remove them.

True enough; OK.

-- 
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 Pengfei.Li at arm.com  Tue Jan 21 10:13:30 2020
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Tue, 21 Jan 2020 10:13:30 +0000
Subject: RFR(S): 8237524: AArch64: String.compareTo() may return incorrect
 result
In-Reply-To: <5111fcc0-9c3a-6f1b-9d6a-b666a41f4453@redhat.com>
References: <DB7PR08MB3115A91957168FF38760DC47960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <5111fcc0-9c3a-6f1b-9d6a-b666a41f4453@redhat.com>
Message-ID: <DB7PR08MB3115F5DF450497160BAD3BB7960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi Andrew,

> Is this really a bug? The test case is violating the protections provided by the
> Java runtime, and the programmer deserves everything that happens.

To be honest, I don't know what kind of incorrect result should be classified as a bug. Indeed, I found this issue several months ago but didn't want to fix it because it doesn't break real Java workloads except the ones that use non-public string constructors.

But now I post this RFR with this thought: If the case that two strings with different encodings share the same memory cannot happen in normal applications, why don't we remove the redundant check to save 4 instructions in the generated intrinsics code? From this point, it's likely that this JBS should be classified as an enhancement instead of a bug.

--
Thanks,
Pengfei


From igor.veresov at oracle.com  Wed Jan 22 00:12:27 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 21 Jan 2020 16:12:27 -0800
Subject: [14] RFR (M) 8231515: [Graal] Crash during exception throwing in
 InterpreterRuntime::resolve_invoke
In-Reply-To: <d85579b8-f324-c4c2-5959-e0925ca0a734@oracle.com>
References: <d85579b8-f324-c4c2-5959-e0925ca0a734@oracle.com>
Message-ID: <E1DCF42C-90DB-4106-97E4-02278FE2263C@oracle.com>

I think you need to add setting of _aot_deopt_blob_unpack_with_exception_in_tls in AOTCodeHeap::link_graal_runtime_symbols() in aotCodeHeap.cpp. 

igor



> On Jan 17, 2020, at 1:10 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> 
> This fixes two separate but related issues. The primary crash is the JVMTI crash when using the post on exceptions support. In that case we use a FrameState which isn't suitable for deopt and we will crash if that deopt is taken. The second issue is related but more rare where our support for explicit exception throwing uses a stub that has a FrameState which is also not suitable for deopt. It's more rare because deoptimization in that path is much less likely. New logic was added to Graal to verify the FrameStates used for deopt which caught both of these problems. Minor changes to JVMCI were made to expose information to Graal but there are no changes that would affect anything besides Graal. New unit tests exercise these paths explicitly and local kitchensink testing of the fix inidicates that there were no more crashes with Graal. preliminary mach5 testing against 15 was clean but mach5 testing against jdk 14 is in progress.
> 
> http://cr.openjdk.java.net/~never/8231515/webrev
> https://bugs.openjdk.java.net/browse/JDK-8231515


From dean.long at oracle.com  Wed Jan 22 02:27:59 2020
From: dean.long at oracle.com (Dean Long)
Date: Tue, 21 Jan 2020 18:27:59 -0800
Subject: [14] RFR (M) 8231515: [Graal] Crash during exception throwing in
 InterpreterRuntime::resolve_invoke
In-Reply-To: <E1DCF42C-90DB-4106-97E4-02278FE2263C@oracle.com>
References: <d85579b8-f324-c4c2-5959-e0925ca0a734@oracle.com>
 <E1DCF42C-90DB-4106-97E4-02278FE2263C@oracle.com>
Message-ID: <501caf4e-ff8e-bd9d-59f6-6c64e77ef9bc@oracle.com>

Yes, we need the mapping in both directions.  Otherwise looks good.

dl

On 1/21/2020 4:12 PM, Igor Veresov wrote:
> I think you need to add setting of _aot_deopt_blob_unpack_with_exception_in_tls in AOTCodeHeap::link_graal_runtime_symbols() in aotCodeHeap.cpp.
> 
> igor
> 
> 
> 
>> On Jan 17, 2020, at 1:10 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>>
>> This fixes two separate but related issues. The primary crash is the JVMTI crash when using the post on exceptions support. In that case we use a FrameState which isn't suitable for deopt and we will crash if that deopt is taken. The second issue is related but more rare where our support for explicit exception throwing uses a stub that has a FrameState which is also not suitable for deopt. It's more rare because deoptimization in that path is much less likely. New logic was added to Graal to verify the FrameStates used for deopt which caught both of these problems. Minor changes to JVMCI were made to expose information to Graal but there are no changes that would affect anything besides Graal. New unit tests exercise these paths explicitly and local kitchensink testing of the fix inidicates that there were no more crashes with Graal. preliminary mach5 testing against 15 was clean but mach5 testing against jdk 14 is in progress.
>>
>> http://cr.openjdk.java.net/~never/8231515/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8231515
> 

From xxinliu at amazon.com  Wed Jan 22 07:47:49 2020
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 22 Jan 2020 07:47:49 +0000
Subject: Does C2 disable incremental inlining for methods without
 @ForceInline?
In-Reply-To: <87y2u1xkm7.fsf@redhat.com>
References: <39E5D093-E575-4850-BBC3-9ED0A99B403D@amazon.com>
 <87y2u1xkm7.fsf@redhat.com>
Message-ID: <840D453C-B544-4A0F-ABA6-AF4A6800F1E8@amazon.com>

Hi, Roland, 

Thank you to fill me the background.  I read your title of 8005071 again and it is for JSR 292. 
I ran some benchmarks in dacapo with my patch and indeed got nothing. 

Thanks, 
--lx

?On 1/21/20, 12:46 AM, "Roland Westrelin" <rwestrel at redhat.com> wrote:

    
    Hi lx,
    
    > If I understand correctly, C2 has actually disabled incremental
    > inlining for almost all methods without @ForceInline.  Is it
    > intentional?
    
    Incremental inlining was implemented to help with method
    handle/invokedynamic and dynamic languages performance (nashorn at the
    time). The problem there is that inlining through a method handle invoke
    causes the inlining budget to be exhausted quickly both because the
    graph grows fast and the inlining budget estimate C2 uses (number of
    nodes in the graph estimated during parsing as number of nodes added to
    the graph) is especially inaccurate for method invoke handle because the
    graph at the call optimizes well. So the idea is that once the inlining
    budget is exhausted, we run a pass of IGVN to clean the graph, count the
    number of actual live nodes to have an accurate estimate of the graph
    size and resume inlining with incremental inlining if the inlining
    budget allows it.
    
    There was no attempt at using incremental inlining for "regular" java
    programs eventhough with lambdas, java code relies on invokedynamic and
    so should trigger incremental inlining.
    
    Roland.
    
    


From martin.doerr at sap.com  Wed Jan 22 10:45:30 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 22 Jan 2020 10:45:30 +0000
Subject: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
 timestamp initialization
In-Reply-To: <CA+3eh13jR7OJ8zKTapnx42EDsGqX0qufemm1AoN7QTs=qhFRyw@mail.gmail.com>
References: <AM0PR0202MB3297906E589CFAFF4635130B9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <CA+3eh13jR7OJ8zKTapnx42EDsGqX0qufemm1AoN7QTs=qhFRyw@mail.gmail.com>
Message-ID: <AM0PR0202MB32977F6C7B28B626317F1FD79A0C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Volker,

thanks for the review!

Best regards,
Martin


> -----Original Message-----
> From: Volker Simonis <volker.simonis at gmail.com>
> Sent: Montag, 20. Januar 2020 18:58
> To: Doerr, Martin <martin.doerr at sap.com>
> Cc: hotspot-compiler-dev at openjdk.java.net; David Holmes
> (david.holmes at oracle.com) <david.holmes at oracle.com>
> Subject: Re: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
> timestamp initialization
> 
> Looks good to me.
> 
> Thanks,
> Volker
> 
> On Mon, Jan 20, 2020 at 6:26 AM Doerr, Martin <martin.doerr at sap.com>
> wrote:
> >
> > Hi,
> >
> > I'd like to fix warmup issues we observed in test
> compiler/c2/Test8004741.java.
> > The issue is a missing timestamp initialization which leads to a premature
> counter decay at the first safepoint with -XX:-TieredCompilation.
> >
> > Bug:
> > https://bugs.openjdk.java.net/browse/JDK-8237375
> >
> > Webrev:
> > http://cr.openjdk.java.net/~mdoerr/8237375_CounterDecay/webrev.00/
> > The webrev applies on top of the preliminary fix for
> https://bugs.openjdk.java.net/browse/JDK-8235741.
> > I'll wait until that one gets pushed.
> >
> > What it changes:
> >
> >   *   Move class CounterDecay up
> >   *   Introduce reset_last_timestamp()
> >   *   Use this function in decay() and in SimpleCompPolicy::initialize()
> >
> > Best regards,
> > Martin
> >

From martin.doerr at sap.com  Wed Jan 22 10:47:17 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 22 Jan 2020 10:47:17 +0000
Subject: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
 timestamp initialization
In-Reply-To: <a8c76ca9-8198-be6a-a81d-d6b19a9ef8fb@oracle.com>
References: <AM0PR0202MB3297906E589CFAFF4635130B9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <a8c76ca9-8198-be6a-a81d-d6b19a9ef8fb@oracle.com>
Message-ID: <AM0PR0202MB3297A0BC38780F3E37BC484E9A0C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi David,

I'll change it to update_last_timestamp before pushing.
Can I add you as reviewer?

Best regards,
Martin


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Montag, 20. Januar 2020 22:54
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
> Cc: David Holmes <David.Holmes at oracle.com>
> Subject: Re: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
> timestamp initialization
> 
> Hi Martin,
> 
> On 21/01/2020 12:25 am, Doerr, Martin wrote:
> > Hi,
> >
> > I'd like to fix warmup issues we observed in test
> > compiler/c2/Test8004741.java.
> >
> > The issue is a missing timestamp initialization which leads to a
> > premature counter decay at the first safepoint with -XX:-
> TieredCompilation.
> >
> > Bug:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8237375
> >
> > Webrev:
> >
> > http://cr.openjdk.java.net/~mdoerr/8237375_CounterDecay/webrev.00/
> >
> > The webrev applies on top of the preliminary fix for
> > https://bugs.openjdk.java.net/browse/JDK-8235741.
> >
> > I'll wait until that one gets pushed.
> >
> > What it changes:
> >
> >   * Move class CounterDecay up
> >   * Introduce reset_last_timestamp()
> 
> "reset" suggests clearing or moving back to an original value to me. How
> about just "set" or "update"?
> 
> Cheers,
> David
> 
> >   * Use this function in decay() and in SimpleCompPolicy::initialize()
> >
> > Best regards,
> >
> > Martin
> >

From david.holmes at oracle.com  Wed Jan 22 11:52:14 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 Jan 2020 21:52:14 +1000
Subject: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
 timestamp initialization
In-Reply-To: <AM0PR0202MB3297A0BC38780F3E37BC484E9A0C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3297906E589CFAFF4635130B9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <a8c76ca9-8198-be6a-a81d-d6b19a9ef8fb@oracle.com>
 <AM0PR0202MB3297A0BC38780F3E37BC484E9A0C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <ed1d04f0-8088-ed87-e1e3-5218c666b56a@oracle.com>

On 22/01/2020 8:47 pm, Doerr, Martin wrote:
> Hi David,
> 
> I'll change it to update_last_timestamp before pushing.
> Can I add you as reviewer?

Sure.

Thanks,
David

> Best regards,
> Martin
> 
> 
>> -----Original Message-----
>> From: David Holmes <david.holmes at oracle.com>
>> Sent: Montag, 20. Januar 2020 22:54
>> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
>> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
>> Cc: David Holmes <David.Holmes at oracle.com>
>> Subject: Re: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
>> timestamp initialization
>>
>> Hi Martin,
>>
>> On 21/01/2020 12:25 am, Doerr, Martin wrote:
>>> Hi,
>>>
>>> I'd like to fix warmup issues we observed in test
>>> compiler/c2/Test8004741.java.
>>>
>>> The issue is a missing timestamp initialization which leads to a
>>> premature counter decay at the first safepoint with -XX:-
>> TieredCompilation.
>>>
>>> Bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8237375
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~mdoerr/8237375_CounterDecay/webrev.00/
>>>
>>> The webrev applies on top of the preliminary fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8235741.
>>>
>>> I'll wait until that one gets pushed.
>>>
>>> What it changes:
>>>
>>>    * Move class CounterDecay up
>>>    * Introduce reset_last_timestamp()
>>
>> "reset" suggests clearing or moving back to an original value to me. How
>> about just "set" or "update"?
>>
>> Cheers,
>> David
>>
>>>    * Use this function in decay() and in SimpleCompPolicy::initialize()
>>>
>>> Best regards,
>>>
>>> Martin
>>>

From vladimir.x.ivanov at oracle.com  Wed Jan 22 11:52:25 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 22 Jan 2020 14:52:25 +0300
Subject: [15] RFR (L): 7175279: Don't use x87 FPU on x86-64
In-Reply-To: <7063EB29-D415-4A48-BA4F-B16C5A1F52F8@oracle.com>
References: <0b0897e0-1dbc-306d-b2cb-31de13fb8b34@oracle.com>
 <7063EB29-D415-4A48-BA4F-B16C5A1F52F8@oracle.com>
Message-ID: <16d75ed8-896b-25fe-0a0a-babc9087e631@oracle.com>

Thanks, Vladimir.

Anybody for a second (R)eview, please?

   http://cr.openjdk.java.net/~vlivanov/7175279/webrev.00/
   +
   http://cr.openjdk.java.net/~vlivanov/7175279/webrev.01-00/

Best regards,
Vladimir Ivanov

On 20.12.2019 01:00, Vladimir Kozlov wrote:
> Good
> 
> Thanks
> Vladimir
> 
>> On Dec 19, 2019, at 1:58 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>> ?
>>>>> Make ConversionStub x86_32-specific only if possible. From what I see it is only LIR_OpConvert in c1_LIR.hpp we have to deal with. I actually can't see how it could be only 32-specific. Hmm?
>>>>
>>>> I experimented with it, but it requires #ifdefs in c1_LIR.cpp/hpp which I don't like. So, I don't consider it as an  > option right now.
>>> Okay, NOT_IA32( ShouldNotReachHere() ) with comment in c1_CodeStubs.hpp should be enough for now.
>>
>> Incremental diff:
>>   http://cr.openjdk.java.net/~vlivanov/7175279/webrev.01-00/
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>>>>> c1_LinearScan.cpp - I think IA64 is used for Itanium. For 64-bit x86 we use AMD64:
>>>>>>>
>>>>>>> https://hg.openjdk.java.net/jdk/jdk/file/cfaa2457a60a/src/hotspot/share/utilities/macros.hpp#l456
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, you are right. Good catch! :-)
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>>> On 12/17/19 4:50 AM, Vladimir Ivanov wrote:
>>>>>>>> http://cr.openjdk.java.net/~vlivanov/7175279/webrev.00/
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7175279
>>>>>>>>
>>>>>>>> There was a major rewrite of math intrinsics which in 9 time frame which almost completely eliminated x87 code in x86-64 code base.
>>>>>>>>
>>>>>>>> Proposed patch removes the rest and makes x86-64 code x87-free.
>>>>>>>>
>>>>>>>> The main motivation for the patch is to completely eliminate non-strictfp behaving code in order to prepare the JVM for JEP 306 [1] and related enhancements [2].
>>>>>>>>
>>>>>>>> Most of the changes are in C1, but there is one case in template interpreter (java_lang_math_abs) which now uses StubRoutines::x86::double_sign_mask(). It forces its initialization to be moved to StubRoutines::initialize1().
>>>>>>>>
>>>>>>>> x87 instructions are made available only on x86-32.
>>>>>>>>
>>>>>>>> C1 changes involve removing FPU support on x86-64 and effectively make x86-specific support in linear scan allocator [2] x86-32-only.
>>>>>>>>
>>>>>>>> Testing: tier1-6, build on x86-23, linux-aarch64, linux-arm32.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Vladimir Ivanov
>>>>>>>>
>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8175916
>>>>>>>>
>>>>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8136414
>>>>>>>>
>>>>>>>> [3] http://hg.openjdk.java.net/jdk/jdk/file/ff7cd49f2aef/src/hotspot/cpu/x86/c1_LinearScan_x86.cpp
> 

From martin.doerr at sap.com  Wed Jan 22 11:56:01 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 22 Jan 2020 11:56:01 +0000
Subject: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
 timestamp initialization
In-Reply-To: <ed1d04f0-8088-ed87-e1e3-5218c666b56a@oracle.com>
References: <AM0PR0202MB3297906E589CFAFF4635130B9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <a8c76ca9-8198-be6a-a81d-d6b19a9ef8fb@oracle.com>
 <AM0PR0202MB3297A0BC38780F3E37BC484E9A0C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <ed1d04f0-8088-ed87-e1e3-5218c666b56a@oracle.com>
Message-ID: <AM0PR0202MB3297456C3F7DD1857B282B519A0C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi David,

thanks for the review. I'll push it after
https://bugs.openjdk.java.net/browse/JDK-8235741

Best regards,
Martin


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Mittwoch, 22. Januar 2020 12:52
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
> Cc: Volker Simonis (volker.simonis at gmail.com) <volker.simonis at gmail.com>
> Subject: Re: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
> timestamp initialization
> 
> On 22/01/2020 8:47 pm, Doerr, Martin wrote:
> > Hi David,
> >
> > I'll change it to update_last_timestamp before pushing.
> > Can I add you as reviewer?
> 
> Sure.
> 
> Thanks,
> David
> 
> > Best regards,
> > Martin
> >
> >
> >> -----Original Message-----
> >> From: David Holmes <david.holmes at oracle.com>
> >> Sent: Montag, 20. Januar 2020 22:54
> >> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> >> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
> >> Cc: David Holmes <David.Holmes at oracle.com>
> >> Subject: Re: RFR(S): 8237375: SimpleThresholdPolicy misses CounterDecay
> >> timestamp initialization
> >>
> >> Hi Martin,
> >>
> >> On 21/01/2020 12:25 am, Doerr, Martin wrote:
> >>> Hi,
> >>>
> >>> I'd like to fix warmup issues we observed in test
> >>> compiler/c2/Test8004741.java.
> >>>
> >>> The issue is a missing timestamp initialization which leads to a
> >>> premature counter decay at the first safepoint with -XX:-
> >> TieredCompilation.
> >>>
> >>> Bug:
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8237375
> >>>
> >>> Webrev:
> >>>
> >>>
> http://cr.openjdk.java.net/~mdoerr/8237375_CounterDecay/webrev.00/
> >>>
> >>> The webrev applies on top of the preliminary fix for
> >>> https://bugs.openjdk.java.net/browse/JDK-8235741.
> >>>
> >>> I'll wait until that one gets pushed.
> >>>
> >>> What it changes:
> >>>
> >>>    * Move class CounterDecay up
> >>>    * Introduce reset_last_timestamp()
> >>
> >> "reset" suggests clearing or moving back to an original value to me. How
> >> about just "set" or "update"?
> >>
> >> Cheers,
> >> David
> >>
> >>>    * Use this function in decay() and in SimpleCompPolicy::initialize()
> >>>
> >>> Best regards,
> >>>
> >>> Martin
> >>>

From rwestrel at redhat.com  Wed Jan 22 16:50:28 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 22 Jan 2020 17:50:28 +0100
Subject: RFR(S): 8237086: assert(is_MachReturn()) running CTW with fix for
 JDK-8231291
In-Reply-To: <87tv4yyqbn.fsf@redhat.com>
References: <87tv4yyqbn.fsf@redhat.com>
Message-ID: <87muafxwob.fsf@redhat.com>


> http://cr.openjdk.java.net/~roland/8237086/webrev.00/

Anyone for this fix?

Roland.


From rwestrel at redhat.com  Wed Jan 22 16:51:52 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 22 Jan 2020 17:51:52 +0100
Subject: RFR(S): 8236759: ShouldNotReachHere in
 PhaseIdealLoop::verify_strip_mined_scheduling
In-Reply-To: <b24fdb9f-2b29-eef9-0c0c-1e22e3dfe6f4@oracle.com>
References: <87zher1xut.fsf@redhat.com>
 <aa8cab76-14b6-d55e-a533-9001697990e5@oracle.com> <87ftgj1qtm.fsf@redhat.com>
 <b24fdb9f-2b29-eef9-0c0c-1e22e3dfe6f4@oracle.com>
Message-ID: <87k15jxwlz.fsf@redhat.com>


> Fair enough. Looks good to me but please add a brief comment (something like "should not schedule a
> data node in the outer strip mined loop") before pushing.

Thanks for the review, Tobias. I'll make the change you suggest.

Anyone else fo a review?

Roland.


From tom.rodriguez at oracle.com  Wed Jan 22 17:45:28 2020
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Wed, 22 Jan 2020 09:45:28 -0800
Subject: [14] RFR (M) 8231515: [Graal] Crash during exception throwing in
 InterpreterRuntime::resolve_invoke
In-Reply-To: <E1DCF42C-90DB-4106-97E4-02278FE2263C@oracle.com>
References: <d85579b8-f324-c4c2-5959-e0925ca0a734@oracle.com>
 <E1DCF42C-90DB-4106-97E4-02278FE2263C@oracle.com>
Message-ID: <2c7e5bb5-9521-72c2-33cc-8552db5288c1@oracle.com>

Ok.  I'll add that.  Why wouldn't testing have shown this problem? 
Maybe this call path isn't currently exercised by any AOT compiled code? 
  I guess there's no sanity checking between these 2 lists of symbols 
either.

A delta webrev is at 
http://cr.openjdk.java.net/~never/8231515.delta/webrev with a full 
webrev at http://cr.openjdk.java.net/~never/8231515_2/webrev

Should I redo any of the testing?  A local build worked fine.

tom

Igor Veresov wrote on 1/21/20 4:12 PM:
> I think you need to add setting of _aot_deopt_blob_unpack_with_exception_in_tls in AOTCodeHeap::link_graal_runtime_symbols() in aotCodeHeap.cpp.
> 
> igor
> 
> 
> 
>> On Jan 17, 2020, at 1:10 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>>
>> This fixes two separate but related issues. The primary crash is the JVMTI crash when using the post on exceptions support. In that case we use a FrameState which isn't suitable for deopt and we will crash if that deopt is taken. The second issue is related but more rare where our support for explicit exception throwing uses a stub that has a FrameState which is also not suitable for deopt. It's more rare because deoptimization in that path is much less likely. New logic was added to Graal to verify the FrameStates used for deopt which caught both of these problems. Minor changes to JVMCI were made to expose information to Graal but there are no changes that would affect anything besides Graal. New unit tests exercise these paths explicitly and local kitchensink testing of the fix inidicates that there were no more crashes with Graal. preliminary mach5 testing against 15 was clean but mach5 testing against jdk 14 is in progress.
>>
>> http://cr.openjdk.java.net/~never/8231515/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8231515
> 

From vladimir.kozlov at oracle.com  Wed Jan 22 18:47:06 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 22 Jan 2020 10:47:06 -0800
Subject: [14] RFR (M) 8231515: [Graal] Crash during exception throwing in
 InterpreterRuntime::resolve_invoke
In-Reply-To: <2c7e5bb5-9521-72c2-33cc-8552db5288c1@oracle.com>
References: <d85579b8-f324-c4c2-5959-e0925ca0a734@oracle.com>
 <E1DCF42C-90DB-4106-97E4-02278FE2263C@oracle.com>
 <2c7e5bb5-9521-72c2-33cc-8552db5288c1@oracle.com>
Message-ID: <e2b41ff3-68d2-0f3b-2206-95533010ce55@oracle.com>

On 1/22/20 9:45 AM, Tom Rodriguez wrote:
> Ok.? I'll add that.? Why wouldn't testing have shown this problem? Maybe this call path isn't currently exercised by any 
> AOT compiled code? ?I guess there's no sanity checking between these 2 lists of symbols either.
> 
> A delta webrev is at http://cr.openjdk.java.net/~never/8231515.delta/webrev with a full webrev at 
> http://cr.openjdk.java.net/~never/8231515_2/webrev

Good.

> 
> Should I redo any of the testing?? A local build worked fine.

Sync with latest JDK 14 and run tier1 - it will run AOT tests too. I think it should be enough for this incremental change.

Thanks,
Vladimir

PS: testing results you got are good.

> 
> tom
> 
> Igor Veresov wrote on 1/21/20 4:12 PM:
>> I think you need to add setting of _aot_deopt_blob_unpack_with_exception_in_tls in 
>> AOTCodeHeap::link_graal_runtime_symbols() in aotCodeHeap.cpp.
>>
>> igor
>>
>>
>>
>>> On Jan 17, 2020, at 1:10 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>>>
>>> This fixes two separate but related issues. The primary crash is the JVMTI crash when using the post on exceptions 
>>> support. In that case we use a FrameState which isn't suitable for deopt and we will crash if that deopt is taken. 
>>> The second issue is related but more rare where our support for explicit exception throwing uses a stub that has a 
>>> FrameState which is also not suitable for deopt. It's more rare because deoptimization in that path is much less 
>>> likely. New logic was added to Graal to verify the FrameStates used for deopt which caught both of these problems. 
>>> Minor changes to JVMCI were made to expose information to Graal but there are no changes that would affect anything 
>>> besides Graal. New unit tests exercise these paths explicitly and local kitchensink testing of the fix inidicates 
>>> that there were no more crashes with Graal. preliminary mach5 testing against 15 was clean but mach5 testing against 
>>> jdk 14 is in progress.
>>>
>>> http://cr.openjdk.java.net/~never/8231515/webrev
>>> https://bugs.openjdk.java.net/browse/JDK-8231515
>>

From igor.veresov at oracle.com  Wed Jan 22 19:50:02 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 22 Jan 2020 11:50:02 -0800
Subject: RFR(XXS): 8237724 Add org.graalvm.compiler.asm.amd64 to the list of
 packages to be processed by the options annotation processor
Message-ID: <51F4D05E-B1D9-4E78-B994-48A0487D39D1@oracle.com>

This is needed to reduce the noise in the integration testing with the upstream Graal.

Webrev: http://cr.openjdk.java.net/~iveresov/8237724/webrev.00/ <http://cr.openjdk.java.net/~iveresov/8237724/webrev.00/>

Thanks,
igor




From vladimir.kozlov at oracle.com  Wed Jan 22 21:53:53 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 22 Jan 2020 13:53:53 -0800
Subject: RFR(XXS): 8237724 Add org.graalvm.compiler.asm.amd64 to the list
 of packages to be processed by the options annotation processor
In-Reply-To: <51F4D05E-B1D9-4E78-B994-48A0487D39D1@oracle.com>
References: <51F4D05E-B1D9-4E78-B994-48A0487D39D1@oracle.com>
Message-ID: <7F445835-8BD1-46F1-BB74-98C25D3FD224@oracle.com>

Looks good.

Thanks
Vladimir

> On Jan 22, 2020, at 11:50 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> ?This is needed to reduce the noise in the integration testing with the upstream Graal.
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/8237724/webrev.00/ <http://cr.openjdk.java.net/~iveresov/8237724/webrev.00/>
> 
> Thanks,
> igor
> 
> 
> 


From igor.veresov at oracle.com  Wed Jan 22 23:32:05 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 22 Jan 2020 15:32:05 -0800
Subject: RFR(XXS): 8237724 Add org.graalvm.compiler.asm.amd64 to the list
 of packages to be processed by the options annotation processor
In-Reply-To: <7F445835-8BD1-46F1-BB74-98C25D3FD224@oracle.com>
References: <51F4D05E-B1D9-4E78-B994-48A0487D39D1@oracle.com>
 <7F445835-8BD1-46F1-BB74-98C25D3FD224@oracle.com>
Message-ID: <5F4E9B7E-B3EB-4B44-98C7-E8DA6196BB50@oracle.com>

Thanks, Vladimir!

igor



> On Jan 22, 2020, at 1:53 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Looks good.
> 
> Thanks
> Vladimir
> 
>> On Jan 22, 2020, at 11:50 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
>> 
>> ?This is needed to reduce the noise in the integration testing with the upstream Graal.
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8237724/webrev.00/ <http://cr.openjdk.java.net/~iveresov/8237724/webrev.00/>
>> 
>> Thanks,
>> igor
>> 
>> 
>> 
> 


From rwestrel at redhat.com  Thu Jan 23 08:05:57 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 23 Jan 2020 09:05:57 +0100
Subject: [15] RFR (L): 7175279: Don't use x87 FPU on x86-64
In-Reply-To: <16d75ed8-896b-25fe-0a0a-babc9087e631@oracle.com>
References: <0b0897e0-1dbc-306d-b2cb-31de13fb8b34@oracle.com>
 <7063EB29-D415-4A48-BA4F-B16C5A1F52F8@oracle.com>
 <16d75ed8-896b-25fe-0a0a-babc9087e631@oracle.com>
Message-ID: <87h80my4uy.fsf@redhat.com>


>    http://cr.openjdk.java.net/~vlivanov/7175279/webrev.00/
>    +
>    http://cr.openjdk.java.net/~vlivanov/7175279/webrev.01-00/

Looks good to me.

Roland.


From adinn at redhat.com  Thu Jan 23 09:48:44 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 23 Jan 2020 09:48:44 +0000
Subject: RFR(XXS): 8237724 Add org.graalvm.compiler.asm.amd64 to the list
 of packages to be processed by the options annotation processor
In-Reply-To: <51F4D05E-B1D9-4E78-B994-48A0487D39D1@oracle.com>
References: <51F4D05E-B1D9-4E78-B994-48A0487D39D1@oracle.com>
Message-ID: <7dfa8f6f-97ca-13c8-3854-348756b60851@redhat.com>

Hi Igor,

On 22/01/2020 19:50, Igor Veresov wrote:
> This is needed to reduce the noise in the integration testing with the upstream Graal.
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/8237724/webrev.00/ <http://cr.openjdk.java.net/~iveresov/8237724/webrev.00/>
 PROC_SRC_SUBDIRS := \
+    org.graalvm.compiler.asm.amd64 \
     org.graalvm.compiler.code \
     org.graalvm.compiler.core \
     org.graalvm.compiler.core.aarch64 \
     org.graalvm.compiler.core.amd64 \

Is there not a similar need to add package org.graalvm.compiler.asm.amd64?

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


From dean.long at oracle.com  Thu Jan 23 10:51:36 2020
From: dean.long at oracle.com (Dean Long)
Date: Thu, 23 Jan 2020 02:51:36 -0800
Subject: Fix potential bug in jaotc
In-Reply-To: <MWHPR21MB05114A4DA539DC03C41F825DB03F0@MWHPR21MB0511.namprd21.prod.outlook.com>
References: <MWHPR21MB05114A4DA539DC03C41F825DB03F0@MWHPR21MB0511.namprd21.prod.outlook.com>
Message-ID: <c5fa0d91-39b3-c983-8450-1c86b95c3bf3@oracle.com>

Hi Ludovic.? Good catch noticing this issue!? It may not be obvious, but 
the code is written this way because the master version of 
MetadataBuilder.java that JDK syncs with is upstream in the github Graal 
repo, and it supports multiple versions of JDK, some of which don't 
support that field.? For example:

https://github.com/oracle/graal/blob/d8d41988d0438e28df94ef08d5b8573db8f42a81/compiler/src/org.graalvm.compiler.hotspot.jdk12/src/org/graalvm/compiler/hotspot/HotSpotGraalServices.java#L38
http://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/hotspot/share/aot/aotCompiledMethod.hpp#l53

Notice that there is a different HotSpotGraalServices for almost every 
JDK version, and that JDK versions older than 13 don't have that 
aot_metadata _nul_chk_table_begin field.

dl

On 1/7/20 2:16 PM, Ludovic Henry wrote:
> Hello,
>
> As I was learning and reading over the codebase of src/jdk.aot and src/hotspot/share/aot, I discovered a discrepancy which might lead to future bugs. The issue is around how some of the metadata is generated and loaded between jaotc and the runtime.
>
> In the runtime, `aot_metadata` (src/hotspot/share/aot/aotCompiledMethod.hpp) contains metadata about each method that is compiled in the AOT image - for example, information like the implicit and explicit exception table, or the oop map. Because the size of this data is specific to each method, `aot_metadata` contains fields that store offsets to the `this` pointer, and the data is stored right after the `aot_metadata` structure in the AOT image.
>
> The structure of `aot_metadata` is the following:
>
> class aot_metadata {
>    int _size;
>    int _code_size;
>    int _entry;
>    int _verified_entry;
>    int _exception_handler_offset;
>    int _deopt_handler_offset;
>    int _stubs_offset;
>    int _frame_size;
>    int _orig_pc_offset;
>    int _unsafe_access;
>
>    // contain the offset to the `this` pointer
>    int _pc_desc_begin;
>    int _scopes_begin;
>    int _reloc_begin;
>    int _exception_table_begin;
>    int _nul_chk_table_begin;
>    int _oopmap_begin;
> }
>
> When creating the AOT image and generating the information in `jdk.tools.jaotc.MetadataBuilder` (src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java), the `aot_metadata._nul_chk_table_begin` field is conditionally generated. In the case where there is no implicit exceptions in the method, no data/field is generated in the AOT image. However, there is no check for the existence of this field when loading the `aot_metadata` from the AOT image.
>
> This issue is mitigated by the fact that the `HotSpotMetaData.implicitExceptionBytes` is always set, even if only with an empty `byte[]`. Nonetheless, this field is populated in the runtime in `getMetadata` (in src/hotspot/share/jvmci/jvmciCompilerToVM.cpp), making the initialization and usage of this field far apart, complexifying the overall solution.
>
> The following patch proposes to always generate the `aot_metadata._nul_chk_table_begin` field. It also has the advantage to unify how this field and the others are generated.
>
> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> index 34ce4d8c8b..fa89d34796 100644
> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> @@ -98,7 +98,8 @@ final class MetadataBuilder {
>               byte[] scopeDesc = metaData.scopesDescBytes();
>               byte[] relocationInfo = metaData.relocBytes();
>               byte[] oopMapInfo = metaData.oopMaps();
> -            byte[] implicitExceptionBytes = HotSpotGraalServices.getImplicitExceptionBytes(metaData);
> +            byte[] exceptionBytes = metaData.exceptionBytes();
> +            byte[] implicitExceptionBytes = metaData.implicitExceptionBytes();
>
>               // create a global symbol at this position for this method
>               NativeOrderOutputStream metadataStream = new NativeOrderOutputStream();
> @@ -143,10 +144,7 @@ final class MetadataBuilder {
>                   NativeOrderOutputStream.PatchableInt scopeOffset = metadataStream.patchableInt();
>                   NativeOrderOutputStream.PatchableInt relocationOffset = metadataStream.patchableInt();
>                   NativeOrderOutputStream.PatchableInt exceptionOffset = metadataStream.patchableInt();
> -                NativeOrderOutputStream.PatchableInt implictTableOffset = null;
> -                if (implicitExceptionBytes != null) {
> -                    implictTableOffset = metadataStream.patchableInt();
> -                }
> +                NativeOrderOutputStream.PatchableInt implictTableOffset = metadataStream.patchableInt();
>                   NativeOrderOutputStream.PatchableInt oopMapOffset = metadataStream.patchableInt();
>                   metadataStream.align(8);
>
> @@ -160,12 +158,10 @@ final class MetadataBuilder {
>                   metadataStream.put(relocationInfo).align(8);
>
>                   exceptionOffset.set(metadataStream.position());
> -                metadataStream.put(metaData.exceptionBytes()).align(8);
> +                metadataStream.put(exceptionBytes).align(8);
>
> -                if (implicitExceptionBytes != null) {
> -                    implictTableOffset.set(metadataStream.position());
> -                    metadataStream.put(implicitExceptionBytes).align(8);
> -                }
> +                implictTableOffset.set(metadataStream.position());
> +                metadataStream.put(implicitExceptionBytes).align(8);
>
>                   // oopmaps should be last
>                   oopMapOffset.set(metadataStream.position());
> diff --git a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
> index fc54c41312..3acb6191b9 100644
> --- a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
> +++ b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
> @@ -41,6 +41,7 @@ public class HotSpotMetaData {
>           scopesDescBytes = new byte[0];
>           relocBytes = new byte[0];
>           exceptionBytes = new byte[0];
> +        implicitExceptionBytes = new byte[0];
>           oopMaps = new byte[0];
>           metadata = new String[0];
>           // ...some of them will be overwritten by the VM:
>
> Thank you,
>
> --
> Ludovic
>
>
>
>
>
>


From boris.ulasevich at bell-sw.com  Thu Jan 23 12:38:26 2020
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Thu, 23 Jan 2020 15:38:26 +0300
Subject: RFR: 8231118: ARM32: Math tests failures
Message-ID: <ae7a9f52-0cd8-214b-d68d-8e371ac0a2ad@bell-sw.com>

Hi,

Please review the fix for floating point Math functions fails reproduced 
on ARM32 fastdebug build run on Raspbian 10. The issue is a call to 
runtime from c2i_adapter (function arguments stays on FPU at this point) 
without proper register saving.

http://cr.openjdk.java.net/~bulasevich/8231118/webrev.01
http://bugs.openjdk.java.net/browse/JDK-8231118

thanks,
Boris

From vladimir.x.ivanov at oracle.com  Thu Jan 23 13:23:20 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 23 Jan 2020 16:23:20 +0300
Subject: [15] RFR (L): 7175279: Don't use x87 FPU on x86-64
In-Reply-To: <87h80my4uy.fsf@redhat.com>
References: <0b0897e0-1dbc-306d-b2cb-31de13fb8b34@oracle.com>
 <7063EB29-D415-4A48-BA4F-B16C5A1F52F8@oracle.com>
 <16d75ed8-896b-25fe-0a0a-babc9087e631@oracle.com> <87h80my4uy.fsf@redhat.com>
Message-ID: <c8556d91-af15-64b6-4f82-127e67003a1a@oracle.com>

Thanks, Roland.

Best regards,
Vladimir Ivanov

On 23.01.2020 11:05, Roland Westrelin wrote:
> 
>>     http://cr.openjdk.java.net/~vlivanov/7175279/webrev.00/
>>     +
>>     http://cr.openjdk.java.net/~vlivanov/7175279/webrev.01-00/
> 
> Looks good to me.
> 
> Roland.
> 

From ekaterina.pavlova at oracle.com  Thu Jan 23 16:44:58 2020
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Thu, 23 Jan 2020 08:44:58 -0800
Subject: RFR(T/XXS): 8206113 "Troubles configuring graal tests"
Message-ID: <1926d59a-0489-5815-fcbb-50a4ec9ae033@oracle.com>

Hello,

Please review the trivial fix which removes useless message.
Other configure/product issues mentioned in the bug were
addressed by JDK-8206135.

       JBS: https://bugs.openjdk.java.net/browse/JDK-8206113
    webrev: http://cr.openjdk.java.net/~epavlova//8206113/webrev.00/index.html
   testing: graal tiers


thanks,
-katya

From vladimir.kozlov at oracle.com  Thu Jan 23 17:26:17 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 23 Jan 2020 09:26:17 -0800
Subject: RFR(T/XXS): 8206113 "Troubles configuring graal tests"
In-Reply-To: <1926d59a-0489-5815-fcbb-50a4ec9ae033@oracle.com>
References: <1926d59a-0489-5815-fcbb-50a4ec9ae033@oracle.com>
Message-ID: <8C47ED25-96BE-45BF-8313-0FB70E5B0DFC@oracle.com>

Good.

Thanks
Vladimir

> On Jan 23, 2020, at 8:45 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
> 
> ?Hello,
> 
> Please review the trivial fix which removes useless message.
> Other configure/product issues mentioned in the bug were
> addressed by JDK-8206135.
> 
>      JBS: https://bugs.openjdk.java.net/browse/JDK-8206113
>   webrev: http://cr.openjdk.java.net/~epavlova//8206113/webrev.00/index.html
>  testing: graal tiers
> 
> 
> thanks,
> -katya


From ekaterina.pavlova at oracle.com  Thu Jan 23 18:24:31 2020
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Thu, 23 Jan 2020 10:24:31 -0800
Subject: RFR(T/XXS): 8206113 "Troubles configuring graal tests"
In-Reply-To: <8C47ED25-96BE-45BF-8313-0FB70E5B0DFC@oracle.com>
References: <1926d59a-0489-5815-fcbb-50a4ec9ae033@oracle.com>
 <8C47ED25-96BE-45BF-8313-0FB70E5B0DFC@oracle.com>
Message-ID: <b51714c4-00b9-c87f-925b-05000b861661@oracle.com>

Thanks Vladimir, pushed.

-katya


On 1/23/20 9:26 AM, Vladimir Kozlov wrote:
> Good.
> 
> Thanks
> Vladimir
> 
>> On Jan 23, 2020, at 8:45 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
>>
>> ?Hello,
>>
>> Please review the trivial fix which removes useless message.
>> Other configure/product issues mentioned in the bug were
>> addressed by JDK-8206135.
>>
>>       JBS: https://bugs.openjdk.java.net/browse/JDK-8206113
>>    webrev: http://cr.openjdk.java.net/~epavlova//8206113/webrev.00/index.html
>>   testing: graal tiers
>>
>>
>> thanks,
>> -katya
> 


From igor.ignatyev at oracle.com  Thu Jan 23 22:21:53 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 23 Jan 2020 14:21:53 -0800
Subject: RFR(S) : 8237787 : rewrite vmTestbase/vm/compiler/CodeCacheInfo* from
 shell to java
Message-ID: <8AB60BC1-0228-43FA-9D44-3E1DDAF8A129@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
> 177 lines changed: 56 ins; 117 del; 4 mod; 7

Hi all,

could you please review the patch which rewrites vmTestbase/vm/compiler/CodeCacheInfo and CodeCacheInfoOnCompilation tests from shell to java?

the only difference b/w java and shell versions are:
 - instead of skipping execution if there isn't -Xcomp, CodeCacheInfoOnCompilation adds -Xcomp to command line
 - instead of checking the value of SegmentedCodeCache flag, CodeCacheInfo runs two cases w/ +SegmentedCodeCache and w/ -SegmentedCodeCache


webrev: http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
JBS: https://bugs.openjdk.java.net/browse/JDK-8237787
testing: the changed tests on linux-x64, windows-x64, and macosx-x64

Thanks,
-- Igor 

From luhenry at microsoft.com  Fri Jan 24 06:06:57 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Fri, 24 Jan 2020 06:06:57 +0000
Subject: Fix potential bug in jaotc
In-Reply-To: <c5fa0d91-39b3-c983-8450-1c86b95c3bf3@oracle.com>
References: <MWHPR21MB05114A4DA539DC03C41F825DB03F0@MWHPR21MB0511.namprd21.prod.outlook.com>
 <c5fa0d91-39b3-c983-8450-1c86b95c3bf3@oracle.com>
Message-ID: <MWHPR21MB05119AC1A024C809560B5BFBB00E0@MWHPR21MB0511.namprd21.prod.outlook.com>

Hi Dean,

That indeed makes a lot more sense! Would it then be possible to add a comment in `src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java` explaining just that, so it's not confusing for anyone else? I am thinking of something like the following:

diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
index 34ce4d8c8b..3cb4c4b65d 100644
--- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
+++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
@@ -98,7 +98,9 @@ final class MetadataBuilder {
             byte[] scopeDesc = metaData.scopesDescBytes();
             byte[] relocationInfo = metaData.relocBytes();
             byte[] oopMapInfo = metaData.oopMaps();
+            // this may be null as the field does not exist before JDK 13
             byte[] implicitExceptionBytes = HotSpotGraalServices.getImplicitExceptionBytes(metaData);
+            byte[] exceptionBytes = metaData.exceptionBytes();
 
             // create a global symbol at this position for this method
             NativeOrderOutputStream metadataStream = new NativeOrderOutputStream();
@@ -160,7 +162,7 @@ final class MetadataBuilder {
                 metadataStream.put(relocationInfo).align(8);
 
                 exceptionOffset.set(metadataStream.position());
-                metadataStream.put(metaData.exceptionBytes()).align(8);
+                metadataStream.put(exceptionBytes).align(8);
 
                 if (implicitExceptionBytes != null) {
                     implictTableOffset.set(metadataStream.position());

Thank you,

--
Ludovic

-----Original Message-----
From: Dean Long <dean.long at oracle.com> 
Sent: Thursday, January 23, 2020 2:52 AM
To: Ludovic Henry <luhenry at microsoft.com>; hotspot-compiler-dev at openjdk.java.net; graal-dev <graal-dev at openjdk.java.net>
Subject: Re: Fix potential bug in jaotc

Hi Ludovic.? Good catch noticing this issue!? It may not be obvious, but 
the code is written this way because the master version of 
MetadataBuilder.java that JDK syncs with is upstream in the github Graal 
repo, and it supports multiple versions of JDK, some of which don't 
support that field.? For example:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foracle%2Fgraal%2Fblob%2Fd8d41988d0438e28df94ef08d5b8573db8f42a81%2Fcompiler%2Fsrc%2Forg.graalvm.compiler.hotspot.jdk12%2Fsrc%2Forg%2Fgraalvm%2Fcompiler%2Fhotspot%2FHotSpotGraalServices.java%23L38&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C3f3fd93631df446c5b2108d79ff23d3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637153735067898897&amp;sdata=8nBmvFbwZYGzDElkx2jJhLW980hamEFwhh2DbzFgv%2Bw%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk12%2Ffile%2F06222165c35f%2Fsrc%2Fhotspot%2Fshare%2Faot%2FaotCompiledMethod.hpp%23l53&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C3f3fd93631df446c5b2108d79ff23d3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637153735067898897&amp;sdata=P%2BzgyEw1VTfz8b790ac8KOjYdYNR5n%2FAv5WFylN%2BsPo%3D&amp;reserved=0

Notice that there is a different HotSpotGraalServices for almost every 
JDK version, and that JDK versions older than 13 don't have that 
aot_metadata _nul_chk_table_begin field.

dl

On 1/7/20 2:16 PM, Ludovic Henry wrote:
> Hello,
>
> As I was learning and reading over the codebase of src/jdk.aot and src/hotspot/share/aot, I discovered a discrepancy which might lead to future bugs. The issue is around how some of the metadata is generated and loaded between jaotc and the runtime.
>
> In the runtime, `aot_metadata` (src/hotspot/share/aot/aotCompiledMethod.hpp) contains metadata about each method that is compiled in the AOT image - for example, information like the implicit and explicit exception table, or the oop map. Because the size of this data is specific to each method, `aot_metadata` contains fields that store offsets to the `this` pointer, and the data is stored right after the `aot_metadata` structure in the AOT image.
>
> The structure of `aot_metadata` is the following:
>
> class aot_metadata {
>    int _size;
>    int _code_size;
>    int _entry;
>    int _verified_entry;
>    int _exception_handler_offset;
>    int _deopt_handler_offset;
>    int _stubs_offset;
>    int _frame_size;
>    int _orig_pc_offset;
>    int _unsafe_access;
>
>    // contain the offset to the `this` pointer
>    int _pc_desc_begin;
>    int _scopes_begin;
>    int _reloc_begin;
>    int _exception_table_begin;
>    int _nul_chk_table_begin;
>    int _oopmap_begin;
> }
>
> When creating the AOT image and generating the information in `jdk.tools.jaotc.MetadataBuilder` (src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java), the `aot_metadata._nul_chk_table_begin` field is conditionally generated. In the case where there is no implicit exceptions in the method, no data/field is generated in the AOT image. However, there is no check for the existence of this field when loading the `aot_metadata` from the AOT image.
>
> This issue is mitigated by the fact that the `HotSpotMetaData.implicitExceptionBytes` is always set, even if only with an empty `byte[]`. Nonetheless, this field is populated in the runtime in `getMetadata` (in src/hotspot/share/jvmci/jvmciCompilerToVM.cpp), making the initialization and usage of this field far apart, complexifying the overall solution.
>
> The following patch proposes to always generate the `aot_metadata._nul_chk_table_begin` field. It also has the advantage to unify how this field and the others are generated.
>
> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> index 34ce4d8c8b..fa89d34796 100644
> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> @@ -98,7 +98,8 @@ final class MetadataBuilder {
>               byte[] scopeDesc = metaData.scopesDescBytes();
>               byte[] relocationInfo = metaData.relocBytes();
>               byte[] oopMapInfo = metaData.oopMaps();
> -            byte[] implicitExceptionBytes = HotSpotGraalServices.getImplicitExceptionBytes(metaData);
> +            byte[] exceptionBytes = metaData.exceptionBytes();
> +            byte[] implicitExceptionBytes = metaData.implicitExceptionBytes();
>
>               // create a global symbol at this position for this method
>               NativeOrderOutputStream metadataStream = new NativeOrderOutputStream();
> @@ -143,10 +144,7 @@ final class MetadataBuilder {
>                   NativeOrderOutputStream.PatchableInt scopeOffset = metadataStream.patchableInt();
>                   NativeOrderOutputStream.PatchableInt relocationOffset = metadataStream.patchableInt();
>                   NativeOrderOutputStream.PatchableInt exceptionOffset = metadataStream.patchableInt();
> -                NativeOrderOutputStream.PatchableInt implictTableOffset = null;
> -                if (implicitExceptionBytes != null) {
> -                    implictTableOffset = metadataStream.patchableInt();
> -                }
> +                NativeOrderOutputStream.PatchableInt implictTableOffset = metadataStream.patchableInt();
>                   NativeOrderOutputStream.PatchableInt oopMapOffset = metadataStream.patchableInt();
>                   metadataStream.align(8);
>
> @@ -160,12 +158,10 @@ final class MetadataBuilder {
>                   metadataStream.put(relocationInfo).align(8);
>
>                   exceptionOffset.set(metadataStream.position());
> -                metadataStream.put(metaData.exceptionBytes()).align(8);
> +                metadataStream.put(exceptionBytes).align(8);
>
> -                if (implicitExceptionBytes != null) {
> -                    implictTableOffset.set(metadataStream.position());
> -                    metadataStream.put(implicitExceptionBytes).align(8);
> -                }
> +                implictTableOffset.set(metadataStream.position());
> +                metadataStream.put(implicitExceptionBytes).align(8);
>
>                   // oopmaps should be last
>                   oopMapOffset.set(metadataStream.position());
> diff --git a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
> index fc54c41312..3acb6191b9 100644
> --- a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
> +++ b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
> @@ -41,6 +41,7 @@ public class HotSpotMetaData {
>           scopesDescBytes = new byte[0];
>           relocBytes = new byte[0];
>           exceptionBytes = new byte[0];
> +        implicitExceptionBytes = new byte[0];
>           oopMaps = new byte[0];
>           metadata = new String[0];
>           // ...some of them will be overwritten by the VM:
>
> Thank you,
>
> --
> Ludovic
>
>
>
>
>
>


From nils.eliasson at oracle.com  Fri Jan 24 08:36:10 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 24 Jan 2020 09:36:10 +0100
Subject: [15] RFR (M): 8237581: Improve allocation expansion
Message-ID: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>

Hi,

This patch improves expand_allocate_common when there is no use of the 
allocation.

Three cases are improved:

- With unknown allocation length - don't expand the fast path. No 
allocation is needed when it isn't used. NegativeArraySizeException will 
still be caught by the slowpath.
- With known length inside the legal range - No fast path or slow path 
is needed. The allocation node is removed.
- With known length outside the legal range - only a slow path is needed.

I also refactored the code a bit, keeping the general structure for easy 
diff, but extracting some routines too make it more readable.

Bug: https://bugs.openjdk.java.net/browse/JDK-8237581
Webrev: http://cr.openjdk.java.net/~neliasso/8237581/webrev.03/

Please review!

Best regards,
Nils Eliasson



From ekaterina.pavlova at oracle.com  Fri Jan 24 16:12:35 2020
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Fri, 24 Jan 2020 08:12:35 -0800
Subject: RFR(T/XS): 8236211 [Graal] compiler/graalunit/GraphTest.java is
 skipped in all testing
Message-ID: <df5b4600-892f-fecb-cee6-293f90b66682@oracle.com>

Hi All,

Please review the small patch which adds required --add-opens required for
org.graalvm.compiler.graph tests (compiler/graalunit/GraphTest.java).
Also removed unnecessary "@requires vm.graal.enabled" from compiler/graalunit/NodesTest.java.
Both tests will start running in graal tiers after this fix
(these tests are now skipped because graalunit tests are tested only in non Graal as JIT mode).

       JBS: https://bugs.openjdk.java.net/browse/JDK-8236211
    webrev: http://cr.openjdk.java.net/~epavlova/8236211/webrev.00/index.html
   testing: graal tiers


thanks,
-katya

From ekaterina.pavlova at oracle.com  Fri Jan 24 16:18:29 2020
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Fri, 24 Jan 2020 08:18:29 -0800
Subject: RFR(S) : 8237787 : rewrite vmTestbase/vm/compiler/CodeCacheInfo*
 from shell to java
In-Reply-To: <8AB60BC1-0228-43FA-9D44-3E1DDAF8A129@oracle.com>
References: <8AB60BC1-0228-43FA-9D44-3E1DDAF8A129@oracle.com>
Message-ID: <4d1d2e33-019d-36ed-9fed-b4bc177d59bc@oracle.com>

On 1/23/20 2:21 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>> 177 lines changed: 56 ins; 117 del; 4 mod; 7
> 
> Hi all,
> 
> could you please review the patch which rewrites vmTestbase/vm/compiler/CodeCacheInfo and CodeCacheInfoOnCompilation tests from shell to java?
> 
> the only difference b/w java and shell versions are:
>   - instead of skipping execution if there isn't -Xcomp, CodeCacheInfoOnCompilation adds -Xcomp to command line

Igor, I don't see -Xcomp is added. Am I missing something?

>   - instead of checking the value of SegmentedCodeCache flag, CodeCacheInfo runs two cases w/ +SegmentedCodeCache and w/ -SegmentedCodeCache
> 
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
> JBS: https://bugs.openjdk.java.net/browse/JDK-8237787
> testing: the changed tests on linux-x64, windows-x64, and macosx-x64
> 
> Thanks,
> -- Igor
> 


From igor.ignatyev at oracle.com  Fri Jan 24 23:06:05 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 24 Jan 2020 15:06:05 -0800
Subject: RFR(S) : 8237787 : rewrite vmTestbase/vm/compiler/CodeCacheInfo*
 from shell to java
In-Reply-To: <4d1d2e33-019d-36ed-9fed-b4bc177d59bc@oracle.com>
References: <8AB60BC1-0228-43FA-9D44-3E1DDAF8A129@oracle.com>
 <4d1d2e33-019d-36ed-9fed-b4bc177d59bc@oracle.com>
Message-ID: <4F60F060-7848-4050-A47F-C97590ECBFF4@oracle.com>

no, you are right. it seems I uploaded not the latest version of my patch. fixed and uploaded .01 which has -Xcomp -- http://cr.openjdk.java.net/~iignatyev//8237787/webrev.01 <http://cr.openjdk.java.net/~iignatyev//8237787/webrev.01>

-- Igor

> On Jan 24, 2020, at 8:18 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
> 
> On 1/23/20 2:21 PM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>> 177 lines changed: 56 ins; 117 del; 4 mod; 7
>> Hi all,
>> could you please review the patch which rewrites vmTestbase/vm/compiler/CodeCacheInfo and CodeCacheInfoOnCompilation tests from shell to java?
>> the only difference b/w java and shell versions are:
>>  - instead of skipping execution if there isn't -Xcomp, CodeCacheInfoOnCompilation adds -Xcomp to command line
> 
> Igor, I don't see -Xcomp is added. Am I missing something?
> 
>>  - instead of checking the value of SegmentedCodeCache flag, CodeCacheInfo runs two cases w/ +SegmentedCodeCache and w/ -SegmentedCodeCache
>> webrev: http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237787
>> testing: the changed tests on linux-x64, windows-x64, and macosx-x64
>> Thanks,
>> -- Igor
> 


From ekaterina.pavlova at oracle.com  Fri Jan 24 23:26:31 2020
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Fri, 24 Jan 2020 15:26:31 -0800
Subject: RFR(S) : 8237787 : rewrite vmTestbase/vm/compiler/CodeCacheInfo*
 from shell to java
In-Reply-To: <4F60F060-7848-4050-A47F-C97590ECBFF4@oracle.com>
References: <8AB60BC1-0228-43FA-9D44-3E1DDAF8A129@oracle.com>
 <4d1d2e33-019d-36ed-9fed-b4bc177d59bc@oracle.com>
 <4F60F060-7848-4050-A47F-C97590ECBFF4@oracle.com>
Message-ID: <9079dc9a-65d4-92fd-513f-19f87bfc6404@oracle.com>

Seems to be good now.

thanks,
-katya

On 1/24/20 3:06 PM, Igor Ignatyev wrote:
> no, you are right. it seems I uploaded not the latest version of my patch. fixed and uploaded .01 which has -Xcomp -- http://cr.openjdk.java.net/~iignatyev//8237787/webrev.01
> 
> -- Igor
> 
>> On Jan 24, 2020, at 8:18 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com <mailto:ekaterina.pavlova at oracle.com>> wrote:
>>
>> On 1/23/20 2:21 PM, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>>> 177 lines changed: 56 ins; 117 del; 4 mod; 7
>>> Hi all,
>>> could you please review the patch which rewrites vmTestbase/vm/compiler/CodeCacheInfo and CodeCacheInfoOnCompilation tests from shell to java?
>>> the only difference b/w java and shell versions are:
>>> ?- instead of skipping execution if there isn't -Xcomp, CodeCacheInfoOnCompilation adds -Xcomp to command line
>>
>> Igor, I don't see -Xcomp is added. Am I missing something?
>>
>>> ?- instead of checking the value of SegmentedCodeCache flag, CodeCacheInfo runs two cases w/ +SegmentedCodeCache and w/ -SegmentedCodeCache
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237787
>>> testing: the changed tests on linux-x64, windows-x64, and macosx-x64
>>> Thanks,
>>> -- Igor
>>
> 


From dean.long at oracle.com  Sat Jan 25 01:06:40 2020
From: dean.long at oracle.com (Dean Long)
Date: Fri, 24 Jan 2020 17:06:40 -0800
Subject: Fix potential bug in jaotc
In-Reply-To: <MWHPR21MB05119AC1A024C809560B5BFBB00E0@MWHPR21MB0511.namprd21.prod.outlook.com>
References: <MWHPR21MB05114A4DA539DC03C41F825DB03F0@MWHPR21MB0511.namprd21.prod.outlook.com>
 <c5fa0d91-39b3-c983-8450-1c86b95c3bf3@oracle.com>
 <MWHPR21MB05119AC1A024C809560B5BFBB00E0@MWHPR21MB0511.namprd21.prod.outlook.com>
Message-ID: <507b8790-d708-51c1-8e68-ccfd7b2a3d05@oracle.com>

Yes, that's a great idea.? If you'd like to get involved yourself, you 
can create a Pull Request here:

https://github.com/oracle/graal/tree/master/compiler

If you need any help with that, you can email me directly.

thanks,

dl

On 1/23/20 10:06 PM, Ludovic Henry wrote:
> Hi Dean,
>
> That indeed makes a lot more sense! Would it then be possible to add a comment in `src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java` explaining just that, so it's not confusing for anyone else? I am thinking of something like the following:
>
> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> index 34ce4d8c8b..3cb4c4b65d 100644
> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> @@ -98,7 +98,9 @@ final class MetadataBuilder {
>               byte[] scopeDesc = metaData.scopesDescBytes();
>               byte[] relocationInfo = metaData.relocBytes();
>               byte[] oopMapInfo = metaData.oopMaps();
> +            // this may be null as the field does not exist before JDK 13
>               byte[] implicitExceptionBytes = HotSpotGraalServices.getImplicitExceptionBytes(metaData);
> +            byte[] exceptionBytes = metaData.exceptionBytes();
>   
>               // create a global symbol at this position for this method
>               NativeOrderOutputStream metadataStream = new NativeOrderOutputStream();
> @@ -160,7 +162,7 @@ final class MetadataBuilder {
>                   metadataStream.put(relocationInfo).align(8);
>   
>                   exceptionOffset.set(metadataStream.position());
> -                metadataStream.put(metaData.exceptionBytes()).align(8);
> +                metadataStream.put(exceptionBytes).align(8);
>   
>                   if (implicitExceptionBytes != null) {
>                       implictTableOffset.set(metadataStream.position());
>
> Thank you,
>
> --
> Ludovic
>
> -----Original Message-----
> From: Dean Long <dean.long at oracle.com>
> Sent: Thursday, January 23, 2020 2:52 AM
> To: Ludovic Henry <luhenry at microsoft.com>; hotspot-compiler-dev at openjdk.java.net; graal-dev <graal-dev at openjdk.java.net>
> Subject: Re: Fix potential bug in jaotc
>
> Hi Ludovic.? Good catch noticing this issue!? It may not be obvious, but
> the code is written this way because the master version of
> MetadataBuilder.java that JDK syncs with is upstream in the github Graal
> repo, and it supports multiple versions of JDK, some of which don't
> support that field.? For example:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foracle%2Fgraal%2Fblob%2Fd8d41988d0438e28df94ef08d5b8573db8f42a81%2Fcompiler%2Fsrc%2Forg.graalvm.compiler.hotspot.jdk12%2Fsrc%2Forg%2Fgraalvm%2Fcompiler%2Fhotspot%2FHotSpotGraalServices.java%23L38&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C3f3fd93631df446c5b2108d79ff23d3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637153735067898897&amp;sdata=8nBmvFbwZYGzDElkx2jJhLW980hamEFwhh2DbzFgv%2Bw%3D&amp;reserved=0
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk12%2Ffile%2F06222165c35f%2Fsrc%2Fhotspot%2Fshare%2Faot%2FaotCompiledMethod.hpp%23l53&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C3f3fd93631df446c5b2108d79ff23d3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637153735067898897&amp;sdata=P%2BzgyEw1VTfz8b790ac8KOjYdYNR5n%2FAv5WFylN%2BsPo%3D&amp;reserved=0
>
> Notice that there is a different HotSpotGraalServices for almost every
> JDK version, and that JDK versions older than 13 don't have that
> aot_metadata _nul_chk_table_begin field.
>
> dl
>
> On 1/7/20 2:16 PM, Ludovic Henry wrote:
>> Hello,
>>
>> As I was learning and reading over the codebase of src/jdk.aot and src/hotspot/share/aot, I discovered a discrepancy which might lead to future bugs. The issue is around how some of the metadata is generated and loaded between jaotc and the runtime.
>>
>> In the runtime, `aot_metadata` (src/hotspot/share/aot/aotCompiledMethod.hpp) contains metadata about each method that is compiled in the AOT image - for example, information like the implicit and explicit exception table, or the oop map. Because the size of this data is specific to each method, `aot_metadata` contains fields that store offsets to the `this` pointer, and the data is stored right after the `aot_metadata` structure in the AOT image.
>>
>> The structure of `aot_metadata` is the following:
>>
>> class aot_metadata {
>>     int _size;
>>     int _code_size;
>>     int _entry;
>>     int _verified_entry;
>>     int _exception_handler_offset;
>>     int _deopt_handler_offset;
>>     int _stubs_offset;
>>     int _frame_size;
>>     int _orig_pc_offset;
>>     int _unsafe_access;
>>
>>     // contain the offset to the `this` pointer
>>     int _pc_desc_begin;
>>     int _scopes_begin;
>>     int _reloc_begin;
>>     int _exception_table_begin;
>>     int _nul_chk_table_begin;
>>     int _oopmap_begin;
>> }
>>
>> When creating the AOT image and generating the information in `jdk.tools.jaotc.MetadataBuilder` (src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java), the `aot_metadata._nul_chk_table_begin` field is conditionally generated. In the case where there is no implicit exceptions in the method, no data/field is generated in the AOT image. However, there is no check for the existence of this field when loading the `aot_metadata` from the AOT image.
>>
>> This issue is mitigated by the fact that the `HotSpotMetaData.implicitExceptionBytes` is always set, even if only with an empty `byte[]`. Nonetheless, this field is populated in the runtime in `getMetadata` (in src/hotspot/share/jvmci/jvmciCompilerToVM.cpp), making the initialization and usage of this field far apart, complexifying the overall solution.
>>
>> The following patch proposes to always generate the `aot_metadata._nul_chk_table_begin` field. It also has the advantage to unify how this field and the others are generated.
>>
>> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
>> index 34ce4d8c8b..fa89d34796 100644
>> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
>> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
>> @@ -98,7 +98,8 @@ final class MetadataBuilder {
>>                byte[] scopeDesc = metaData.scopesDescBytes();
>>                byte[] relocationInfo = metaData.relocBytes();
>>                byte[] oopMapInfo = metaData.oopMaps();
>> -            byte[] implicitExceptionBytes = HotSpotGraalServices.getImplicitExceptionBytes(metaData);
>> +            byte[] exceptionBytes = metaData.exceptionBytes();
>> +            byte[] implicitExceptionBytes = metaData.implicitExceptionBytes();
>>
>>                // create a global symbol at this position for this method
>>                NativeOrderOutputStream metadataStream = new NativeOrderOutputStream();
>> @@ -143,10 +144,7 @@ final class MetadataBuilder {
>>                    NativeOrderOutputStream.PatchableInt scopeOffset = metadataStream.patchableInt();
>>                    NativeOrderOutputStream.PatchableInt relocationOffset = metadataStream.patchableInt();
>>                    NativeOrderOutputStream.PatchableInt exceptionOffset = metadataStream.patchableInt();
>> -                NativeOrderOutputStream.PatchableInt implictTableOffset = null;
>> -                if (implicitExceptionBytes != null) {
>> -                    implictTableOffset = metadataStream.patchableInt();
>> -                }
>> +                NativeOrderOutputStream.PatchableInt implictTableOffset = metadataStream.patchableInt();
>>                    NativeOrderOutputStream.PatchableInt oopMapOffset = metadataStream.patchableInt();
>>                    metadataStream.align(8);
>>
>> @@ -160,12 +158,10 @@ final class MetadataBuilder {
>>                    metadataStream.put(relocationInfo).align(8);
>>
>>                    exceptionOffset.set(metadataStream.position());
>> -                metadataStream.put(metaData.exceptionBytes()).align(8);
>> +                metadataStream.put(exceptionBytes).align(8);
>>
>> -                if (implicitExceptionBytes != null) {
>> -                    implictTableOffset.set(metadataStream.position());
>> -                    metadataStream.put(implicitExceptionBytes).align(8);
>> -                }
>> +                implictTableOffset.set(metadataStream.position());
>> +                metadataStream.put(implicitExceptionBytes).align(8);
>>
>>                    // oopmaps should be last
>>                    oopMapOffset.set(metadataStream.position());
>> diff --git a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
>> index fc54c41312..3acb6191b9 100644
>> --- a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
>> +++ b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
>> @@ -41,6 +41,7 @@ public class HotSpotMetaData {
>>            scopesDescBytes = new byte[0];
>>            relocBytes = new byte[0];
>>            exceptionBytes = new byte[0];
>> +        implicitExceptionBytes = new byte[0];
>>            oopMaps = new byte[0];
>>            metadata = new String[0];
>>            // ...some of them will be overwritten by the VM:
>>
>> Thank you,
>>
>> --
>> Ludovic
>>
>>
>>
>>
>>
>>


From luhenry at microsoft.com  Sat Jan 25 01:47:30 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Sat, 25 Jan 2020 01:47:30 +0000
Subject: Fix potential bug in jaotc
In-Reply-To: <507b8790-d708-51c1-8e68-ccfd7b2a3d05@oracle.com>
References: <MWHPR21MB05114A4DA539DC03C41F825DB03F0@MWHPR21MB0511.namprd21.prod.outlook.com>
 <c5fa0d91-39b3-c983-8450-1c86b95c3bf3@oracle.com>
 <MWHPR21MB05119AC1A024C809560B5BFBB00E0@MWHPR21MB0511.namprd21.prod.outlook.com>
 <507b8790-d708-51c1-8e68-ccfd7b2a3d05@oracle.com>
Message-ID: <CY4PR21MB05028075144D7F2160728A62B0090@CY4PR21MB0502.namprd21.prod.outlook.com>

I've created https://github.com/oracle/graal/pull/2096. Thanks for the feedback :)

--
Ludovic

-----Original Message-----
From: Dean Long <dean.long at oracle.com> 
Sent: Friday, January 24, 2020 5:07 PM
To: Ludovic Henry <luhenry at microsoft.com>; hotspot-compiler-dev at openjdk.java.net; graal-dev <graal-dev at openjdk.java.net>
Subject: Re: Fix potential bug in jaotc

Yes, that's a great idea.? If you'd like to get involved yourself, you 
can create a Pull Request here:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foracle%2Fgraal%2Ftree%2Fmaster%2Fcompiler&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C50869631ba974939d17708d7a13322c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637155113313150283&amp;sdata=K9EJLJChV%2BOz35kjoTZeVoh%2F7WHg80UeWEuw26HgMzE%3D&amp;reserved=0

If you need any help with that, you can email me directly.

thanks,

dl

On 1/23/20 10:06 PM, Ludovic Henry wrote:
> Hi Dean,
>
> That indeed makes a lot more sense! Would it then be possible to add a comment in `src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java` explaining just that, so it's not confusing for anyone else? I am thinking of something like the following:
>
> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> index 34ce4d8c8b..3cb4c4b65d 100644
> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
> @@ -98,7 +98,9 @@ final class MetadataBuilder {
>               byte[] scopeDesc = metaData.scopesDescBytes();
>               byte[] relocationInfo = metaData.relocBytes();
>               byte[] oopMapInfo = metaData.oopMaps();
> +            // this may be null as the field does not exist before JDK 13
>               byte[] implicitExceptionBytes = HotSpotGraalServices.getImplicitExceptionBytes(metaData);
> +            byte[] exceptionBytes = metaData.exceptionBytes();
>   
>               // create a global symbol at this position for this method
>               NativeOrderOutputStream metadataStream = new NativeOrderOutputStream();
> @@ -160,7 +162,7 @@ final class MetadataBuilder {
>                   metadataStream.put(relocationInfo).align(8);
>   
>                   exceptionOffset.set(metadataStream.position());
> -                metadataStream.put(metaData.exceptionBytes()).align(8);
> +                metadataStream.put(exceptionBytes).align(8);
>   
>                   if (implicitExceptionBytes != null) {
>                       implictTableOffset.set(metadataStream.position());
>
> Thank you,
>
> --
> Ludovic
>
> -----Original Message-----
> From: Dean Long <dean.long at oracle.com>
> Sent: Thursday, January 23, 2020 2:52 AM
> To: Ludovic Henry <luhenry at microsoft.com>; hotspot-compiler-dev at openjdk.java.net; graal-dev <graal-dev at openjdk.java.net>
> Subject: Re: Fix potential bug in jaotc
>
> Hi Ludovic.? Good catch noticing this issue!? It may not be obvious, but
> the code is written this way because the master version of
> MetadataBuilder.java that JDK syncs with is upstream in the github Graal
> repo, and it supports multiple versions of JDK, some of which don't
> support that field.? For example:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foracle%2Fgraal%2Fblob%2Fd8d41988d0438e28df94ef08d5b8573db8f42a81%2Fcompiler%2Fsrc%2Forg.graalvm.compiler.hotspot.jdk12%2Fsrc%2Forg%2Fgraalvm%2Fcompiler%2Fhotspot%2FHotSpotGraalServices.java%23L38&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C50869631ba974939d17708d7a13322c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637155113313150283&amp;sdata=jRRK1eMS0kRYufdygtPQIbru%2F2HN1nhJujDEDS3%2FuSE%3D&amp;reserved=0
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk12%2Ffile%2F06222165c35f%2Fsrc%2Fhotspot%2Fshare%2Faot%2FaotCompiledMethod.hpp%23l53&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C50869631ba974939d17708d7a13322c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637155113313150283&amp;sdata=keaNvbokdui6jUhpnG0veJR4r4rGn8b%2Bb8irOSLUEy0%3D&amp;reserved=0
>
> Notice that there is a different HotSpotGraalServices for almost every
> JDK version, and that JDK versions older than 13 don't have that
> aot_metadata _nul_chk_table_begin field.
>
> dl
>
> On 1/7/20 2:16 PM, Ludovic Henry wrote:
>> Hello,
>>
>> As I was learning and reading over the codebase of src/jdk.aot and src/hotspot/share/aot, I discovered a discrepancy which might lead to future bugs. The issue is around how some of the metadata is generated and loaded between jaotc and the runtime.
>>
>> In the runtime, `aot_metadata` (src/hotspot/share/aot/aotCompiledMethod.hpp) contains metadata about each method that is compiled in the AOT image - for example, information like the implicit and explicit exception table, or the oop map. Because the size of this data is specific to each method, `aot_metadata` contains fields that store offsets to the `this` pointer, and the data is stored right after the `aot_metadata` structure in the AOT image.
>>
>> The structure of `aot_metadata` is the following:
>>
>> class aot_metadata {
>>     int _size;
>>     int _code_size;
>>     int _entry;
>>     int _verified_entry;
>>     int _exception_handler_offset;
>>     int _deopt_handler_offset;
>>     int _stubs_offset;
>>     int _frame_size;
>>     int _orig_pc_offset;
>>     int _unsafe_access;
>>
>>     // contain the offset to the `this` pointer
>>     int _pc_desc_begin;
>>     int _scopes_begin;
>>     int _reloc_begin;
>>     int _exception_table_begin;
>>     int _nul_chk_table_begin;
>>     int _oopmap_begin;
>> }
>>
>> When creating the AOT image and generating the information in `jdk.tools.jaotc.MetadataBuilder` (src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java), the `aot_metadata._nul_chk_table_begin` field is conditionally generated. In the case where there is no implicit exceptions in the method, no data/field is generated in the AOT image. However, there is no check for the existence of this field when loading the `aot_metadata` from the AOT image.
>>
>> This issue is mitigated by the fact that the `HotSpotMetaData.implicitExceptionBytes` is always set, even if only with an empty `byte[]`. Nonetheless, this field is populated in the runtime in `getMetadata` (in src/hotspot/share/jvmci/jvmciCompilerToVM.cpp), making the initialization and usage of this field far apart, complexifying the overall solution.
>>
>> The following patch proposes to always generate the `aot_metadata._nul_chk_table_begin` field. It also has the advantage to unify how this field and the others are generated.
>>
>> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
>> index 34ce4d8c8b..fa89d34796 100644
>> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
>> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
>> @@ -98,7 +98,8 @@ final class MetadataBuilder {
>>                byte[] scopeDesc = metaData.scopesDescBytes();
>>                byte[] relocationInfo = metaData.relocBytes();
>>                byte[] oopMapInfo = metaData.oopMaps();
>> -            byte[] implicitExceptionBytes = HotSpotGraalServices.getImplicitExceptionBytes(metaData);
>> +            byte[] exceptionBytes = metaData.exceptionBytes();
>> +            byte[] implicitExceptionBytes = metaData.implicitExceptionBytes();
>>
>>                // create a global symbol at this position for this method
>>                NativeOrderOutputStream metadataStream = new NativeOrderOutputStream();
>> @@ -143,10 +144,7 @@ final class MetadataBuilder {
>>                    NativeOrderOutputStream.PatchableInt scopeOffset = metadataStream.patchableInt();
>>                    NativeOrderOutputStream.PatchableInt relocationOffset = metadataStream.patchableInt();
>>                    NativeOrderOutputStream.PatchableInt exceptionOffset = metadataStream.patchableInt();
>> -                NativeOrderOutputStream.PatchableInt implictTableOffset = null;
>> -                if (implicitExceptionBytes != null) {
>> -                    implictTableOffset = metadataStream.patchableInt();
>> -                }
>> +                NativeOrderOutputStream.PatchableInt implictTableOffset = metadataStream.patchableInt();
>>                    NativeOrderOutputStream.PatchableInt oopMapOffset = metadataStream.patchableInt();
>>                    metadataStream.align(8);
>>
>> @@ -160,12 +158,10 @@ final class MetadataBuilder {
>>                    metadataStream.put(relocationInfo).align(8);
>>
>>                    exceptionOffset.set(metadataStream.position());
>> -                metadataStream.put(metaData.exceptionBytes()).align(8);
>> +                metadataStream.put(exceptionBytes).align(8);
>>
>> -                if (implicitExceptionBytes != null) {
>> -                    implictTableOffset.set(metadataStream.position());
>> -                    metadataStream.put(implicitExceptionBytes).align(8);
>> -                }
>> +                implictTableOffset.set(metadataStream.position());
>> +                metadataStream.put(implicitExceptionBytes).align(8);
>>
>>                    // oopmaps should be last
>>                    oopMapOffset.set(metadataStream.position());
>> diff --git a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
>> index fc54c41312..3acb6191b9 100644
>> --- a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
>> +++ b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
>> @@ -41,6 +41,7 @@ public class HotSpotMetaData {
>>            scopesDescBytes = new byte[0];
>>            relocBytes = new byte[0];
>>            exceptionBytes = new byte[0];
>> +        implicitExceptionBytes = new byte[0];
>>            oopMaps = new byte[0];
>>            metadata = new String[0];
>>            // ...some of them will be overwritten by the VM:
>>
>> Thank you,
>>
>> --
>> Ludovic
>>
>>
>>
>>
>>
>>


From igor.ignatyev at oracle.com  Sat Jan 25 03:02:07 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 24 Jan 2020 19:02:07 -0800
Subject: RFR(S) : 8237798 : rewrite vmTestbase/jit/tiered from shell to java
Message-ID: <7B34F407-C396-48B5-ADFB-C1076DEDF77D@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8237798/webrev.00
> 109 lines changed: 35 ins; 71 del; 3 mod;

Hi all,

could you please review the small patch which rewrites vmTestbase/jit/tiered from shell to java?
the only difference compared to the shell version is explicit and separate executions for +TieredCompilation and -TieredCompilation case. 

JBS: https://bugs.openjdk.java.net/browse/JDK-8237798
webrev: http://cr.openjdk.java.net/~iignatyev//8237798/webrev.00l
testing: the changed test on {linux,windows,macosx}-x64

Thanks,
-- Igor

From igor.ignatyev at oracle.com  Sat Jan 25 03:06:28 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 24 Jan 2020 19:06:28 -0800
Subject: RFR(S) : 8237800 : rewrite vmTestbase/jit/escape/LockCoarsening from
 shell to java
Message-ID: <E6E9FA9F-0349-46D7-9803-948E3F13E5E4@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8237800/webrev.00
> 99 lines changed: 6 ins; 80 del; 13 mod;

Hi all,

could you please review rewriting of vmTestbase/jit/escape/LockCoarsening tests from shell to java?

JBS: https://bugs.openjdk.java.net/browse/JDK-8237800
webrev: http://cr.openjdk.java.net/~iignatyev//8237800/webrev.00
testing: vmTestbase/jit/escape/LockCoarsening tests on {linux,windows,macosx}-x64 (w/ tests temporary removed from the problem list) 

Thanks,
-- Igor

From rwestrel at redhat.com  Mon Jan 27 08:52:54 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 27 Jan 2020 09:52:54 +0100
Subject: RFR(S) : 8237798 : rewrite vmTestbase/jit/tiered from shell to
 java
In-Reply-To: <7B34F407-C396-48B5-ADFB-C1076DEDF77D@oracle.com>
References: <7B34F407-C396-48B5-ADFB-C1076DEDF77D@oracle.com>
Message-ID: <87o8upwaah.fsf@redhat.com>


> webrev: http://cr.openjdk.java.net/~iignatyev//8237798/webrev.00

Looks good to me.

Roland.


From rwestrel at redhat.com  Mon Jan 27 08:55:26 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 27 Jan 2020 09:55:26 +0100
Subject: RFR(S) : 8237800 : rewrite vmTestbase/jit/escape/LockCoarsening
 from shell to java
In-Reply-To: <E6E9FA9F-0349-46D7-9803-948E3F13E5E4@oracle.com>
References: <E6E9FA9F-0349-46D7-9803-948E3F13E5E4@oracle.com>
Message-ID: <87lfptwa69.fsf@redhat.com>


> webrev: http://cr.openjdk.java.net/~iignatyev//8237800/webrev.00

Looks good to me.

Roland.


From nils.eliasson at oracle.com  Mon Jan 27 10:01:26 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 27 Jan 2020 11:01:26 +0100
Subject: [15] RFR (M): 8237581: Improve allocation expansion
In-Reply-To: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>
References: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>
Message-ID: <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>

Hi,

I split the patch into two parts for easier review:

Refactoring:

http://cr.openjdk.java.net/~neliasso/8237581/webrev.refactor/

The actual change (on top of the refactoring)

http://cr.openjdk.java.net/~neliasso/8237581/webrev.change/


Best regards,
Nils Eliasson

On 2020-01-24 09:36, Nils Eliasson wrote:
> Hi,
>
> This patch improves expand_allocate_common when there is no use of the 
> allocation.
>
> Three cases are improved:
>
> - With unknown allocation length - don't expand the fast path. No 
> allocation is needed when it isn't used. NegativeArraySizeException 
> will still be caught by the slowpath.
> - With known length inside the legal range - No fast path or slow path 
> is needed. The allocation node is removed.
> - With known length outside the legal range - only a slow path is needed.
>
> I also refactored the code a bit, keeping the general structure for 
> easy diff, but extracting some routines too make it more readable.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8237581
> Webrev: http://cr.openjdk.java.net/~neliasso/8237581/webrev.03/
>
> Please review!
>
> Best regards,
> Nils Eliasson
>
>


From nils.eliasson at oracle.com  Mon Jan 27 12:55:37 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 27 Jan 2020 13:55:37 +0100
Subject: RFR(S) : 8237800 : rewrite vmTestbase/jit/escape/LockCoarsening
 from shell to java
In-Reply-To: <87lfptwa69.fsf@redhat.com>
References: <E6E9FA9F-0349-46D7-9803-948E3F13E5E4@oracle.com>
 <87lfptwa69.fsf@redhat.com>
Message-ID: <7855823d-e88c-c916-1277-4a68b0504fa2@oracle.com>

+1

Regards,
Nils

On 2020-01-27 09:55, Roland Westrelin wrote:
>> webrev: http://cr.openjdk.java.net/~iignatyev//8237800/webrev.00
> Looks good to me.
>
> Roland.
>


From nils.eliasson at oracle.com  Mon Jan 27 12:56:25 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 27 Jan 2020 13:56:25 +0100
Subject: RFR(S) : 8237798 : rewrite vmTestbase/jit/tiered from shell to
 java
In-Reply-To: <87o8upwaah.fsf@redhat.com>
References: <7B34F407-C396-48B5-ADFB-C1076DEDF77D@oracle.com>
 <87o8upwaah.fsf@redhat.com>
Message-ID: <de08bf69-ae56-aec0-dd8f-b510d4840af7@oracle.com>

+1

Regards,
Nils

On 2020-01-27 09:52, Roland Westrelin wrote:
>> webrev: http://cr.openjdk.java.net/~iignatyev//8237798/webrev.00
> Looks good to me.
>
> Roland.
>


From Charlie.Gracie at microsoft.com  Mon Jan 27 15:58:43 2020
From: Charlie.Gracie at microsoft.com (Charlie Gracie)
Date: Mon, 27 Jan 2020 15:58:43 +0000
Subject: Stack allocation prototype for C2
Message-ID: <CF2C656C-10C1-43F2-A73A-D656B06E3B68@microsoft.com>

Hi,

We have been prototyping Stack Allocation in C2. We are hoping to start a conversation on our approach
and to see if there is interest in the community for us to submit our work as a patch set. We would
appreciate any comments, concerns or feedback on our current approach or the idea in general. Thanks!

Background on why we are investigating Stack Allocation:
While investigating the performance of different workloads (a lot of Scala but some plain Java), we noticed
a lot of GC and heap pressure due to transient object allocations. Upon further digging we were able to see
that C2?s Escape Analysis phase was correctly recognizing these allocations as Non Escaping. The allocations
were not being Scalar Replaced due to a few different restrictions but the most common was due to control
flow merge points before accessing the objects. Here is a simplified example of a case where an allocation
cannot be Scalar Replaced even though it is recognized as Non Escaping.

int foo(int x, MyObject[] vals) {
   MyObject bar;
   If (x > 127) {
      bar = new MyObject(x);
   } else {
      bar = vals[x];
   }
   return bar.x;
}

In the above example the allocation could successfully be replaced with a Stack Allocation. We believe that
a lot of code has control flow merge points that cause Scalar Replacement to be rejected but Stack Allocation
could work for many of them. The obvious benefit is the reduction in GC/heap pressure, but you also get the
added benefit of improved cache hit rate since the stack allocated objects will likely be in the cache memory.
There are costs with Stack Allocation including increased compilation times and increased code cache size.
These would have to be carefully measured fully understand the benefits and costs.

Our current approach:
1. Only allow stack allocation in non-compressed oops mode (-XX:-UseCompressedOops)
	1.1 This simplifies the prototype and we believe there are solutions for compressed oops
2. Focus on ParallelGC and G1GC for prototype
	2.1 Support for other collectors needs to be investigated
3. Current prototype is based on JDK 11
	3.1 We are going to work on moving it up to tip shortly
	3.2 We have been following the changes in tip and this work should apply easily
4. Use the results from Escape Analysis to decide which objects are eligible for Stack Allocation
	4.1 Scalar Replacement is the most important, so allow that to happen first
	4.2 Arrays cannot be stack allocated in the current prototype.
		4.2.1 Straight forward to implement
	4.3 Stack allocated objects cannot reference other stack allocated objects.
		4.3.1 More difficult than arrays but should be doable
	4.4 Reject allocations based on the reasons listed below in the details section
5. In macro expansion during expand allocation replace allocations eligible for Stack Allocation.
	5.1 Replace the AllocNode with a BoxLockNode with the correct stack location and remove the slow
path and other unused IR
	5.2 Repurpose BoxLock nodes to represent the stack location for the object
	5.3 No Stack Allocation in methods that contain synchronization. 
		5.3.1 This restriction should be easy to remove.
	5.4 Remove write barriers on stores into stack allocated objects
6. Grow the frame size to handle the stack allocated objects
7. Modify OopMap scanning to handle stack allocated objects
	7.1 Currently handled via a generic OopClosure for all GCs
	7.2 More work required for full GC collector coverage 
8. Safepoint support reuses SafePointScalarObject
	8.1 De-optimization is working and correctly allocating heap objects and initializing their fields

Current Results:
1. Microbenchmarks using JMH simply replace all allocations using Stack Allocation where Scalar Replacement
2. Workloads in DeCapo and Renaissance are showing benefits
3. We have not measured any negative impacts on application throughput
4. More detailed analysis on compilation times and code cache size are required

Benchmark                                  % Improvement
DeCapo tmt                                           15
Renaissance db-shootout                   10
Renaissance fj-kmeans                          5
Renaissance future-genetic                10
Renaissance movie-lens                        5
Renaissance neo4j-analytics              45

Details on why allocations should not be replaced with Stack Allocation:
Not all Non Escaping objects can be Stack Allocated so there will still be cases where Non Escaping allocations
will need to be allocated on the heap:
1. Large arrays and objects should likely be ignored as they could significantly impact the stack frame size
2. Similar to 1 limit the total amount of stack memory per frame that should be used for Stack Allocations
3. Objects and arrays without constant sizes/lengths
4. Allocations with over lapping lifetimes from different loop iterations
5. A stack allocated object cannot be referenced by any other Non Escaping objects that are not scalar replaced
or stack allocated as that would count as an escape

Here is a simple example of what I was describing in 4.
int method(int[] vals) {
   MyObject o1 = new MyObject(vals[0]);
   for (int i =1; i < vals.length; ++) {
      MyObject o2 = new MyObject(vals[i]);
      if (!o1.equals(o2)) {
         o1 = o2;
         ?
      }
      ?
   }
   ?
}

In the above example if o2 was stack allocated and you ever entered the ?if? from that point on o1 and o2 would
always be the same object. This is incorrect so o2 cannot be stack allocated.

Thanks for reading and we look forward to your feedback!
Charlie Gracie & Nikola Grcevski



From adinn at redhat.com  Mon Jan 27 16:26:56 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 27 Jan 2020 16:26:56 +0000
Subject: Stack allocation prototype for C2
In-Reply-To: <CF2C656C-10C1-43F2-A73A-D656B06E3B68@microsoft.com>
References: <CF2C656C-10C1-43F2-A73A-D656B06E3B68@microsoft.com>
Message-ID: <4141eab3-e921-3b09-94a9-4486049a3d35@redhat.com>

Hi Charlie,

On 27/01/2020 15:58, Charlie Gracie wrote:
> We have been prototyping Stack Allocation in C2. We are hoping to start a conversation on our approach
> and to see if there is interest in the community for us to submit our work as a patch set. We would
> appreciate any comments, concerns or feedback on our current approach or the idea in general. Thanks!
> 
> Background on why we are investigating Stack Allocation:
> . . .
> Thanks for reading and we look forward to your feedback!
> Charlie Gracie & Nikola Grcevski

Thanks for offering this. It sounds very interesting. Looking forward to
seeing your 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


From simonisv at amazon.de  Mon Jan 27 23:18:39 2020
From: simonisv at amazon.de (Simonis, Volker)
Date: Mon, 27 Jan 2020 23:18:39 +0000
Subject: Stack allocation prototype for C2
In-Reply-To: <CF2C656C-10C1-43F2-A73A-D656B06E3B68@microsoft.com>
References: <CF2C656C-10C1-43F2-A73A-D656B06E3B68@microsoft.com>
Message-ID: <5870f82f-874e-4a95-978f-c2f2b97e88fd@amazon.de>


Am 27.01.2020 17:00 schrieb Charlie Gracie <Charlie.Gracie at microsoft.com>:
>
> Hi,
>
> We have been prototyping Stack Allocation in C2. We are hoping to start a conversation on our approach
> and to see if there is interest in the community for us to submit our work as a patch set. We would
> appreciate any comments, concerns or feedback on our current approach or the idea in general. Thanks!
>

Hi Charlie, Nikola

this looks really very interesting and the performance gains are impressive!

If you need help with uploading a version of your patch to cr.openjdk.java.net please let me know. I'll be happy to assist.

Looking forward hearing Nikola's talk about the details at FOSDEM.

Save travels,
Volker

> Background on why we are investigating Stack Allocation:
> While investigating the performance of different workloads (a lot of Scala but some plain Java), we noticed
> a lot of GC and heap pressure due to transient object allocations. Upon further digging we were able to see
> that C2?s Escape Analysis phase was correctly recognizing these allocations as Non Escaping. The allocations
> were not being Scalar Replaced due to a few different restrictions but the most common was due to control
> flow merge points before accessing the objects. Here is a simplified example of a case where an allocation
> cannot be Scalar Replaced even though it is recognized as Non Escaping.
>
> int foo(int x, MyObject[] vals) {
>    MyObject bar;
>    If (x > 127) {
>       bar = new MyObject(x);
>    } else {
>       bar = vals[x];
>    }
>    return bar.x;
> }
>
> In the above example the allocation could successfully be replaced with a Stack Allocation. We believe that
> a lot of code has control flow merge points that cause Scalar Replacement to be rejected but Stack Allocation
> could work for many of them. The obvious benefit is the reduction in GC/heap pressure, but you also get the
> added benefit of improved cache hit rate since the stack allocated objects will likely be in the cache memory.
> There are costs with Stack Allocation including increased compilation times and increased code cache size.
> These would have to be carefully measured fully understand the benefits and costs.
>
> Our current approach:
> 1. Only allow stack allocation in non-compressed oops mode (-XX:-UseCompressedOops)
>         1.1 This simplifies the prototype and we believe there are solutions for compressed oops
> 2. Focus on ParallelGC and G1GC for prototype
>         2.1 Support for other collectors needs to be investigated
> 3. Current prototype is based on JDK 11
>         3.1 We are going to work on moving it up to tip shortly
>         3.2 We have been following the changes in tip and this work should apply easily
> 4. Use the results from Escape Analysis to decide which objects are eligible for Stack Allocation
>         4.1 Scalar Replacement is the most important, so allow that to happen first
>         4.2 Arrays cannot be stack allocated in the current prototype.
>                 4.2.1 Straight forward to implement
>         4.3 Stack allocated objects cannot reference other stack allocated objects.
>                 4.3.1 More difficult than arrays but should be doable
>         4.4 Reject allocations based on the reasons listed below in the details section
> 5. In macro expansion during expand allocation replace allocations eligible for Stack Allocation.
>         5.1 Replace the AllocNode with a BoxLockNode with the correct stack location and remove the slow
> path and other unused IR
>         5.2 Repurpose BoxLock nodes to represent the stack location for the object
>         5.3 No Stack Allocation in methods that contain synchronization.
>                 5.3.1 This restriction should be easy to remove.
>         5.4 Remove write barriers on stores into stack allocated objects
> 6. Grow the frame size to handle the stack allocated objects
> 7. Modify OopMap scanning to handle stack allocated objects
>         7.1 Currently handled via a generic OopClosure for all GCs
>         7.2 More work required for full GC collector coverage
> 8. Safepoint support reuses SafePointScalarObject
>         8.1 De-optimization is working and correctly allocating heap objects and initializing their fields
>
> Current Results:
> 1. Microbenchmarks using JMH simply replace all allocations using Stack Allocation where Scalar Replacement
> 2. Workloads in DeCapo and Renaissance are showing benefits
> 3. We have not measured any negative impacts on application throughput
> 4. More detailed analysis on compilation times and code cache size are required
>
> Benchmark                                  % Improvement
> DeCapo tmt                                           15
> Renaissance db-shootout                   10
> Renaissance fj-kmeans                          5
> Renaissance future-genetic                10
> Renaissance movie-lens                        5
> Renaissance neo4j-analytics              45
>
> Details on why allocations should not be replaced with Stack Allocation:
> Not all Non Escaping objects can be Stack Allocated so there will still be cases where Non Escaping allocations
> will need to be allocated on the heap:
> 1. Large arrays and objects should likely be ignored as they could significantly impact the stack frame size
> 2. Similar to 1 limit the total amount of stack memory per frame that should be used for Stack Allocations
> 3. Objects and arrays without constant sizes/lengths
> 4. Allocations with over lapping lifetimes from different loop iterations
> 5. A stack allocated object cannot be referenced by any other Non Escaping objects that are not scalar replaced
> or stack allocated as that would count as an escape
>
> Here is a simple example of what I was describing in 4.
> int method(int[] vals) {
>    MyObject o1 = new MyObject(vals[0]);
>    for (int i =1; i < vals.length; ++) {
>       MyObject o2 = new MyObject(vals[i]);
>       if (!o1.equals(o2)) {
>          o1 = o2;
>          ?
>       }
>       ?
>    }
>    ?
> }
>
> In the above example if o2 was stack allocated and you ever entered the ?if? from that point on o1 and o2 would
> always be the same object. This is incorrect so o2 cannot be stack allocated.
>
> Thanks for reading and we look forward to your feedback!
> Charlie Gracie & Nikola Grcevski
>
>




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From igor.ignatyev at oracle.com  Mon Jan 27 23:37:58 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 27 Jan 2020 15:37:58 -0800
Subject: RFR(S) : 8237800 : rewrite vmTestbase/jit/escape/LockCoarsening
 from shell to java
In-Reply-To: <7855823d-e88c-c916-1277-4a68b0504fa2@oracle.com>
References: <E6E9FA9F-0349-46D7-9803-948E3F13E5E4@oracle.com>
 <87lfptwa69.fsf@redhat.com> <7855823d-e88c-c916-1277-4a68b0504fa2@oracle.com>
Message-ID: <AAD66468-700C-4530-B4FD-BF83C9B7EA31@oracle.com>

Nils, Roland,

thanks for review, pushed.

-- Igor

> On Jan 27, 2020, at 4:55 AM, Nils Eliasson <nils.eliasson at oracle.com> wrote:
> 
> +1
> 
> Regards,
> Nils
> 
> On 2020-01-27 09:55, Roland Westrelin wrote:
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8237800/webrev.00
>> Looks good to me.
>> 
>> Roland.
>> 
> 


From igor.ignatyev at oracle.com  Mon Jan 27 23:38:29 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 27 Jan 2020 15:38:29 -0800
Subject: RFR(S) : 8237798 : rewrite vmTestbase/jit/tiered from shell to
 java
In-Reply-To: <de08bf69-ae56-aec0-dd8f-b510d4840af7@oracle.com>
References: <7B34F407-C396-48B5-ADFB-C1076DEDF77D@oracle.com>
 <87o8upwaah.fsf@redhat.com> <de08bf69-ae56-aec0-dd8f-b510d4840af7@oracle.com>
Message-ID: <2A8853BB-19AF-4EAC-AA40-D2A62141B09A@oracle.com>

Nils, Roland,

thanks for review, pushed.

-- Igor


> On Jan 27, 2020, at 4:56 AM, Nils Eliasson <nils.eliasson at oracle.com> wrote:
> 
> +1
> 
> Regards,
> Nils
> 
> On 2020-01-27 09:52, Roland Westrelin wrote:
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8237798/webrev.00
>> Looks good to me.
>> 
>> Roland.
>> 
> 


From igor.ignatyev at oracle.com  Mon Jan 27 23:39:48 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 27 Jan 2020 15:39:48 -0800
Subject: RFR(S) : 8237787 : rewrite vmTestbase/vm/compiler/CodeCacheInfo*
 from shell to java
In-Reply-To: <9079dc9a-65d4-92fd-513f-19f87bfc6404@oracle.com>
References: <8AB60BC1-0228-43FA-9D44-3E1DDAF8A129@oracle.com>
 <4d1d2e33-019d-36ed-9fed-b4bc177d59bc@oracle.com>
 <4F60F060-7848-4050-A47F-C97590ECBFF4@oracle.com>
 <9079dc9a-65d4-92fd-513f-19f87bfc6404@oracle.com>
Message-ID: <686A9255-BF7A-4956-BFD4-C969203347C6@oracle.com>

@Katya,

thank you!

@list
can I get a 2nd Review?

-- Igor

> On Jan 24, 2020, at 3:26 PM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
> 
> Seems to be good now.
> 
> thanks,
> -katya
> 
> On 1/24/20 3:06 PM, Igor Ignatyev wrote:
>> no, you are right. it seems I uploaded not the latest version of my patch. fixed and uploaded .01 which has -Xcomp -- http://cr.openjdk.java.net/~iignatyev//8237787/webrev.01
>> -- Igor
>>> On Jan 24, 2020, at 8:18 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com <mailto:ekaterina.pavlova at oracle.com>> wrote:
>>> 
>>> On 1/23/20 2:21 PM, Igor Ignatyev wrote:
>>>> http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>>>> 177 lines changed: 56 ins; 117 del; 4 mod; 7
>>>> Hi all,
>>>> could you please review the patch which rewrites vmTestbase/vm/compiler/CodeCacheInfo and CodeCacheInfoOnCompilation tests from shell to java?
>>>> the only difference b/w java and shell versions are:
>>>>  - instead of skipping execution if there isn't -Xcomp, CodeCacheInfoOnCompilation adds -Xcomp to command line
>>> 
>>> Igor, I don't see -Xcomp is added. Am I missing something?
>>> 
>>>>  - instead of checking the value of SegmentedCodeCache flag, CodeCacheInfo runs two cases w/ +SegmentedCodeCache and w/ -SegmentedCodeCache
>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237787
>>>> testing: the changed tests on linux-x64, windows-x64, and macosx-x64
>>>> Thanks,
>>>> -- Igor
>>> 
> 


From rwestrel at redhat.com  Tue Jan 28 10:43:24 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 28 Jan 2020 11:43:24 +0100
Subject: RFR(S): 8237837: Shenandoah: assert(mem == __null) failed: only one
 safepoint
Message-ID: <87imkvx3n7.fsf@redhat.com>


http://cr.openjdk.java.net/~roland/8237837/webrev.00/

At barrier expansion, raw memory needs to be correctly wired around
expanded barriers. For that, the raw memory subgraph is walked starting
from the Root node. When there's an infinite loop, the loop is connected
to the Root node through a NeverBranch. So that logic looks for a
NeverBranch from the Root node and if it finds one, it needs to find the
memory state in the loop. The current logic looks for the SafePoint in
the infinite loop. That breaks when the infinite loop has a SATB barrier
because then the loop body has a runtime call for which is_SafePoint()
returns true (eventhough the call doesn't safepoint). I've reworked the
logic so it ignores non safepointing runtime call and is more robust for
infinite loops.

Roland.


From nils.eliasson at oracle.com  Tue Jan 28 11:15:50 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 28 Jan 2020 12:15:50 +0100
Subject: [15] RFR (M): 8237581: Improve allocation expansion
In-Reply-To: <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>
References: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>
 <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>
Message-ID: <76b9ffce-8167-6337-cefd-24c18813ce18@oracle.com>

Hi,

I added a simple micro that triggers the optimization.

Micro:
http://cr.openjdk.java.net/~neliasso/8237581/webrev.micro/

On my workstation I get these numbers:

JDK/JDK:

Benchmark????????????????????????????????? (size)? Mode? Cnt Score?? 
Error? Units
ArrayAllocation.eliminateArrayConstLength???? 128 avgt????? 
61.178????????? ns/op
ArrayAllocation.eliminateArrayVarLength?????? 128 avgt????? 
55.109????????? ns/op

JDK/JDK + path for 8237581:

Benchmark????????????????????????????????? (size)? Mode? Cnt Score?? 
Error? Units
ArrayAllocation.eliminateArrayConstLength???? 128 avgt?????? 
0.841????????? ns/op
ArrayAllocation.eliminateArrayVarLength?????? 128 avgt?????? 
1.897????????? ns/op

Speedup 30-70x

Please review,

Regards,
Nils


On 2020-01-27 11:01, Nils Eliasson wrote:
> Hi,
>
> I split the patch into two parts for easier review:
>
> Refactoring:
>
> http://cr.openjdk.java.net/~neliasso/8237581/webrev.refactor/
>
> The actual change (on top of the refactoring)
>
> http://cr.openjdk.java.net/~neliasso/8237581/webrev.change/
>
>
> Best regards,
> Nils Eliasson
>
> On 2020-01-24 09:36, Nils Eliasson wrote:
>> Hi,
>>
>> This patch improves expand_allocate_common when there is no use of 
>> the allocation.
>>
>> Three cases are improved:
>>
>> - With unknown allocation length - don't expand the fast path. No 
>> allocation is needed when it isn't used. NegativeArraySizeException 
>> will still be caught by the slowpath.
>> - With known length inside the legal range - No fast path or slow 
>> path is needed. The allocation node is removed.
>> - With known length outside the legal range - only a slow path is 
>> needed.
>>
>> I also refactored the code a bit, keeping the general structure for 
>> easy diff, but extracting some routines too make it more readable.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237581
>> Webrev: http://cr.openjdk.java.net/~neliasso/8237581/webrev.03/
>>
>> Please review!
>>
>> Best regards,
>> Nils Eliasson
>>
>>
>


From Pengfei.Li at arm.com  Tue Jan 28 13:40:58 2020
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Tue, 28 Jan 2020 13:40:58 +0000
Subject: [aarch64-port-dev ] RFR(S): 8237524: AArch64: String.compareTo()
 may return incorrect result
In-Reply-To: <56670d62-defa-4192-c084-bfa130adde41@redhat.com>
References: <DB7PR08MB3115A91957168FF38760DC47960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <5111fcc0-9c3a-6f1b-9d6a-b666a41f4453@redhat.com>
 <b5469d1a-82c8-1346-e658-0157a4a95da9@arm.com>
 <56670d62-defa-4192-c084-bfa130adde41@redhat.com>
Message-ID: <DB7PR08MB3115C39DCFEB449A5FA53D90960A0@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi,

Can any committer help push this fix? http://cr.openjdk.java.net/~pli/rfr/8237524/webrev.00/

Patch is reviewed by aph. See below review thread.

> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Tuesday, January 21, 2020 18:13
> To: Nick Gasson <Nick.Gasson at arm.com>; Pengfei Li <Pengfei.Li at arm.com>;
> hotspot-compiler-dev at openjdk.java.net; aarch64-port-
> dev at openjdk.java.net
> Cc: nd <nd at arm.com>
> Subject: Re: [aarch64-port-dev ] RFR(S): 8237524: AArch64:
> String.compareTo() may return incorrect result
> 
> On 1/21/20 10:11 AM, Nick Gasson wrote:
> > On 21/01/2020 17:33, Andrew Haley wrote:
> >> On 1/21/20 8:40 AM, Pengfei Li wrote:
> >>> Root cause is in the AArch64 String.compareTo intrinsics. In the
> >>> code of MacroAssembler::string_compare(), we have a fast path that
> >>> compares the addresses of initial bytes of the two arrays. If the
> >>> result is equal, we skip the inflation of the Latin one and the byte-wise
> comparison part.
> >>> But we shouldn't do in this way if the encodings of the two strings
> >>> are different (the LU/UL cases). This patch removes the incorrect
> >>> fast path check.
> >>
> >> Is this really a bug? The test case is violating the protections
> >> provided by the Java runtime, and the programmer deserves everything
> >> that happens.
> >
> > Even if it's not strictly a bug, the pointer equality checks in the
> > LU/UL branches are unnecessary: the only time they succeed is when the
> > Strings were constructed in this backdoor way, and in that case they
> > give the wrong result. So it seems better to just remove them.
> 
> True enough; OK.
> 

Thanks,
Pengfei

From ron.pressler at oracle.com  Tue Jan 28 13:45:46 2020
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 28 Jan 2020 13:45:46 +0000
Subject: Stack allocation prototype for C2
Message-ID: <etPan.5e303b0b.bf9ccf5.158@oracle.com>

?
Hi.

Reading between the lines, the difference between scalar replacement and what  
you call "stack allocation" is that the latter creates an oop pointing into the
stack frame. Is that correct?

If so, there is another consideration to take into account. Loom continuations  
can relocate stack frames in memory, and currently, compiled frames do not
contain pointers into the stack. This relocation can potentially happen at any
safepoint, but the continuation algorithm has two modes. In the slow mode --
used when there are interpreted frames or, for forced preemption, at any
arbitrary safepoint -- the stack frames are parsed and walked, and so pointers
in the stack that point into the stack could be patched (I assume, from your
description that you do not allow oops outside the stack to point into the
stack). In the fast mode, we avoid parsing the stack and we just copy the frames
as-is, and it can occur at any nmethod call. If your "stack-oops" can currently
live across nmethod calls, how much would this optimization be compromised if
you disallowed that (i.e. stack oops to stack-allocated objects would not live
across nmethod calls)?

Also, if my understanding is correct, I'm not sure you need to limit the  
optimization to -UseCompressedOops. I believe that even when compressed oops are
used, stack oops can be wide; i.e. we do find frames with mixed narrow and wide
oops in them, and the oopmaps allow for that possibility.

Ron  


On 27 January 2020 at 15:58:43, Charlie Gracie wrote:  

>  
> Hi,
>
> We have been prototyping Stack Allocation in C2. We are hoping to start a conversation on our approach
> and to see if there is interest in the community for us to submit our work as a patch set. We would
> appreciate any comments, concerns or feedback on our current approach or the idea in general. Thanks!
>
> Background on why we are investigating Stack Allocation:
> While investigating the performance of different workloads (a lot of Scala but some plain Java), we noticed
> a lot of GC and heap pressure due to transient object allocations. Upon further digging we were able to see
> that C2?s Escape Analysis phase was correctly recognizing these allocations as Non Escaping. The allocations
> were not being Scalar Replaced due to a few different restrictions but the most common was due to control
> flow merge points before accessing the objects. Here is a simplified example of a case where an allocation
> cannot be Scalar Replaced even though it is recognized as Non Escaping.
>
> int foo(int x, MyObject[] vals) {
> MyObject bar;
> If (x > 127) {
> bar = new MyObject(x);
> } else {
> bar = vals[x];
> }
> return bar.x;
> }
>
> In the above example the allocation could successfully be replaced with a Stack Allocation. We believe that
> a lot of code has control flow merge points that cause Scalar Replacement to be rejected but Stack Allocation
> could work for many of them. The obvious benefit is the reduction in GC/heap pressure, but you also get the
> added benefit of improved cache hit rate since the stack allocated objects will likely be in the cache memory.
> There are costs with Stack Allocation including increased compilation times and increased code cache size.
> These would have to be carefully measured fully understand the benefits and costs.
>
> Our current approach:
> 1. Only allow stack allocation in non-compressed oops mode (-XX:-UseCompressedOops)
> 1.1 This simplifies the prototype and we believe there are solutions for compressed oops
> 2. Focus on ParallelGC and G1GC for prototype
> 2.1 Support for other collectors needs to be investigated
> 3. Current prototype is based on JDK 11
> 3.1 We are going to work on moving it up to tip shortly
> 3.2 We have been following the changes in tip and this work should apply easily
> 4. Use the results from Escape Analysis to decide which objects are eligible for Stack Allocation
> 4.1 Scalar Replacement is the most important, so allow that to happen first
> 4.2 Arrays cannot be stack allocated in the current prototype.
> 4.2.1 Straight forward to implement
> 4.3 Stack allocated objects cannot reference other stack allocated objects.
> 4.3.1 More difficult than arrays but should be doable
> 4.4 Reject allocations based on the reasons listed below in the details section
> 5. In macro expansion during expand allocation replace allocations eligible for Stack Allocation.
> 5.1 Replace the AllocNode with a BoxLockNode with the correct stack location and remove the slow
> path and other unused IR
> 5.2 Repurpose BoxLock nodes to represent the stack location for the object
> 5.3 No Stack Allocation in methods that contain synchronization.
> 5.3.1 This restriction should be easy to remove.
> 5.4 Remove write barriers on stores into stack allocated objects
> 6. Grow the frame size to handle the stack allocated objects
> 7. Modify OopMap scanning to handle stack allocated objects
> 7.1 Currently handled via a generic OopClosure for all GCs
> 7.2 More work required for full GC collector coverage
> 8. Safepoint support reuses SafePointScalarObject
> 8.1 De-optimization is working and correctly allocating heap objects and initializing their fields
>
> Current Results:
> 1. Microbenchmarks using JMH simply replace all allocations using Stack Allocation where Scalar Replacement
> 2. Workloads in DeCapo and Renaissance are showing benefits
> 3. We have not measured any negative impacts on application throughput
> 4. More detailed analysis on compilation times and code cache size are required
>
> Benchmark % Improvement
> DeCapo tmt 15
> Renaissance db-shootout 10
> Renaissance fj-kmeans 5
> Renaissance future-genetic 10
> Renaissance movie-lens 5
> Renaissance neo4j-analytics 45
>
> Details on why allocations should not be replaced with Stack Allocation:
> Not all Non Escaping objects can be Stack Allocated so there will still be cases where Non Escaping allocations
> will need to be allocated on the heap:
> 1. Large arrays and objects should likely be ignored as they could significantly impact the stack frame size
> 2. Similar to 1 limit the total amount of stack memory per frame that should be used for Stack Allocations
> 3. Objects and arrays without constant sizes/lengths
> 4. Allocations with over lapping lifetimes from different loop iterations
> 5. A stack allocated object cannot be referenced by any other Non Escaping objects that are not scalar replaced
> or stack allocated as that would count as an escape
>
> Here is a simple example of what I was describing in 4.
> int method(int[] vals) {
> MyObject o1 = new MyObject(vals[0]);
> for (int i =1; i < vals.length; ++) {
> MyObject o2 = new MyObject(vals[i]);
> if (!o1.equals(o2)) {
> o1 = o2;
> ?
> }
> ?
> }
> ?
> }
>
> In the above example if o2 was stack allocated and you ever entered the ?if? from that point on o1 and o2 would
> always be the same object. This is incorrect so o2 cannot be stack allocated.
>
> Thanks for reading and we look forward to your feedback!
> Charlie Gracie & Nikola Grcevski
>
>



From claes.redestad at oracle.com  Tue Jan 28 15:17:29 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 28 Jan 2020 16:17:29 +0100
Subject: [15] RFR (M): 8237581: Improve allocation expansion
In-Reply-To: <76b9ffce-8167-6337-cefd-24c18813ce18@oracle.com>
References: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>
 <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>
 <76b9ffce-8167-6337-cefd-24c18813ce18@oracle.com>
Message-ID: <4d06f2af-ab40-8158-d984-ae87e4233c02@oracle.com>



On 2020-01-28 12:15, Nils Eliasson wrote:
> Hi,
> 
> I added a simple micro that triggers the optimization.
> 
> Micro:
> http://cr.openjdk.java.net/~neliasso/8237581/webrev.micro/
> 
> On my workstation I get these numbers:
> 
> JDK/JDK:
> 
> Benchmark????????????????????????????????? (size)? Mode? Cnt Score 
> Error? Units
> ArrayAllocation.eliminateArrayConstLength???? 128 avgt 61.178          
> ns/op
> ArrayAllocation.eliminateArrayVarLength?????? 128 avgt 55.109          
> ns/op
> 
> JDK/JDK + path for 8237581:
> 
> Benchmark????????????????????????????????? (size)? Mode? Cnt Score 
> Error? Units
> ArrayAllocation.eliminateArrayConstLength???? 128 avgt 0.841????????? ns/op
> ArrayAllocation.eliminateArrayVarLength?????? 128 avgt 1.897????????? ns/op
> 
> Speedup 30-70x

Nice!

Micro looks good and to the point. I think the {}'s around "128" is
redundant for a single parameter value.

Can't really review the compiler code changes but it all looks
reasonable to me.

/Claes

From richard.reingruber at sap.com  Tue Jan 28 15:31:31 2020
From: richard.reingruber at sap.com (Reingruber, Richard)
Date: Tue, 28 Jan 2020 15:31:31 +0000
Subject: VM_EnterInterpOnlyMode: why make compiled methods on stack
 not_entrant?
Message-ID: <AM0PR0202MB3331C331B51D301C8AEB482D9B0A0@AM0PR0202MB3331.eurprd02.prod.outlook.com>

Hi,

I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack not_entrant. To me this
seems unnecessary. I think it would be sufficient to patch the return pc of compiled frames and
let them return to their deopt handler. Or what would be the reason to make the compiled methods
not_entrant?

VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native methods get
marked.

Deoptimization::deoptimize_all_marked(): all marked methods are made not_entrant.

Maybe this is for historical reasons? If I remember correctly, many years ago, deoptimizing a
compiled frame used to require making the corresponding nmethod not_entrant. And making a nmethod
not_entrant meant overriding its code with a slide of nops that led to the deopt handler.

I'd like to change this and just apply Deoptimization::deoptimize() on every compiled frame on
stack. I've done this locally and tested the change without issues.

Thanks,
Richard.

From ekaterina.pavlova at oracle.com  Tue Jan 28 18:33:35 2020
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Tue, 28 Jan 2020 10:33:35 -0800
Subject: RFR(T/XS): 8236211 [Graal] compiler/graalunit/GraphTest.java is
 skipped in all testing
In-Reply-To: <df5b4600-892f-fecb-cee6-293f90b66682@oracle.com>
References: <df5b4600-892f-fecb-cee6-293f90b66682@oracle.com>
Message-ID: <7eb0c680-08fd-211d-5ee3-ce52cbb468e3@oracle.com>

Hi,

can I please get one review?

thanks,
-katya

On 1/24/20 8:12 AM, Ekaterina Pavlova wrote:
> Hi All,
> 
> Please review the small patch which adds required --add-opens required for
> org.graalvm.compiler.graph tests (compiler/graalunit/GraphTest.java).
> Also removed unnecessary "@requires vm.graal.enabled" from compiler/graalunit/NodesTest.java.
> Both tests will start running in graal tiers after this fix
> (these tests are now skipped because graalunit tests are tested only in non Graal as JIT mode).
> 
>  ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8236211
>  ?? webrev: http://cr.openjdk.java.net/~epavlova/8236211/webrev.00/index.html
>  ? testing: graal tiers
> 
> 
> thanks,
> -katya


From Charlie.Gracie at microsoft.com  Tue Jan 28 22:45:42 2020
From: Charlie.Gracie at microsoft.com (Charlie Gracie)
Date: Tue, 28 Jan 2020 22:45:42 +0000
Subject: [EXTERNAL] Stack allocation prototype for C2
Message-ID: <50FAFF89-E32C-4155-965D-E8CEA9C299F2@microsoft.com>

Hi Volker,

That would be great! We will reach out at FOSDEM to learn about uploading a patch to cr.openjdk.java.net. After we return from Europe we will look into getting the patch uploaded for viewing, suggestions, refinements and testing.

Cheers,
Charlie

From: "Simonis, Volker" <simonisv at amazon.de>
Date: Monday, January 27, 2020 at 6:18 PM
To: Nikola Grcevski <Nikola.Grcevski at microsoft.com>, "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-dev at openjdk.java.net>, Charlie Gracie <Charlie.Gracie at microsoft.com>
Subject: [EXTERNAL] Stack allocation prototype for C2


Am 27.01.2020 17:00 schrieb Charlie Gracie <Charlie.Gracie at microsoft.com>: 
>
> Hi, 
>
> We have been prototyping Stack Allocation in C2. We are hoping to start a conversation on our approach 
> and to see if there is interest in the community for us to submit our work as a patch set. We would 
> appreciate any comments, concerns or feedback on our current approach or the idea in general. Thanks! 
>

Hi Charlie, Nikola

this looks really very interesting and the performance gains are impressive!

If you need help with uploading a version of your patch to cr.openjdk.java.net please let me know. I'll be happy to assist.

Looking forward hearing Nikola's talk about the details at FOSDEM.

Save travels,
Volker

> Background on why we are investigating Stack Allocation: 
> While investigating the performance of different workloads (a lot of Scala but some plain Java), we noticed 
> a lot of GC and heap pressure due to transient object allocations. Upon further digging we were able to see 
> that C2?s Escape Analysis phase was correctly recognizing these allocations as Non Escaping. The allocations 
> were not being Scalar Replaced due to a few different restrictions but the most common was due to control 
> flow merge points before accessing the objects. Here is a simplified example of a case where an allocation 
> cannot be Scalar Replaced even though it is recognized as Non Escaping. 
>
> int foo(int x, MyObject[] vals) { 
> ?? MyObject bar; 
> ?? If (x > 127) { 
> ????? bar = new MyObject(x); 
> ?? } else { 
> ????? bar = vals[x]; 
> ?? } 
> ?? return bar.x; 
> } 
>
> In the above example the allocation could successfully be replaced with a Stack Allocation. We believe that 
> a lot of code has control flow merge points that cause Scalar Replacement to be rejected but Stack Allocation 
> could work for many of them. The obvious benefit is the reduction in GC/heap pressure, but you also get the 
> added benefit of improved cache hit rate since the stack allocated objects will likely be in the cache memory. 
> There are costs with Stack Allocation including increased compilation times and increased code cache size. 
> These would have to be carefully measured fully understand the benefits and costs. 
>
> Our current approach: 
> 1. Only allow stack allocation in non-compressed oops mode (-XX:-UseCompressedOops) 
> ??????? 1.1 This simplifies the prototype and we believe there are solutions for compressed oops 
> 2. Focus on ParallelGC and G1GC for prototype 
> ??????? 2.1 Support for other collectors needs to be investigated 
> 3. Current prototype is based on JDK 11 
> ??????? 3.1 We are going to work on moving it up to tip shortly 
> ??????? 3.2 We have been following the changes in tip and this work should apply easily 
> 4. Use the results from Escape Analysis to decide which objects are eligible for Stack Allocation 
> ??????? 4.1 Scalar Replacement is the most important, so allow that to happen first 
> ??????? 4.2 Arrays cannot be stack allocated in the current prototype. 
> ??????????????? 4.2.1 Straight forward to implement 
> ??????? 4.3 Stack allocated objects cannot reference other stack allocated objects. 
> ??????????????? 4.3.1 More difficult than arrays but should be doable 
> ??????? 4.4 Reject allocations based on the reasons listed below in the details section 
> 5. In macro expansion during expand allocation replace allocations eligible for Stack Allocation. 
> ??????? 5.1 Replace the AllocNode with a BoxLockNode with the correct stack location and remove the slow 
> path and other unused IR 
> ??????? 5.2 Repurpose BoxLock nodes to represent the stack location for the object 
> ??????? 5.3 No Stack Allocation in methods that contain synchronization. 
> ??????????????? 5.3.1 This restriction should be easy to remove. 
> ??????? 5.4 Remove write barriers on stores into stack allocated objects 
> 6. Grow the frame size to handle the stack allocated objects 
> 7. Modify OopMap scanning to handle stack allocated objects 
> ??????? 7.1 Currently handled via a generic OopClosure for all GCs 
> ??????? 7.2 More work required for full GC collector coverage 
> 8. Safepoint support reuses SafePointScalarObject 
> ??????? 8.1 De-optimization is working and correctly allocating heap objects and initializing their fields 
>
> Current Results: 
> 1. Microbenchmarks using JMH simply replace all allocations using Stack Allocation where Scalar Replacement 
> 2. Workloads in DeCapo and Renaissance are showing benefits 
> 3. We have not measured any negative impacts on application throughput 
> 4. More detailed analysis on compilation times and code cache size are required 
>
> Benchmark????????????????????????????????? % Improvement 
> DeCapo tmt?????????????????????????????????????????? 15 
> Renaissance db-shootout?????????????????? 10 
> Renaissance fj-kmeans????????????????????????? 5 
> Renaissance future-genetic??????????????? 10 
> Renaissance movie-lens??????????????????????? 5 
> Renaissance neo4j-analytics????????????? 45 
>
> Details on why allocations should not be replaced with Stack Allocation: 
> Not all Non Escaping objects can be Stack Allocated so there will still be cases where Non Escaping allocations 
> will need to be allocated on the heap: 
> 1. Large arrays and objects should likely be ignored as they could significantly impact the stack frame size 
> 2. Similar to 1 limit the total amount of stack memory per frame that should be used for Stack Allocations 
> 3. Objects and arrays without constant sizes/lengths 
> 4. Allocations with over lapping lifetimes from different loop iterations 
> 5. A stack allocated object cannot be referenced by any other Non Escaping objects that are not scalar replaced 
> or stack allocated as that would count as an escape 
>
> Here is a simple example of what I was describing in 4. 
> int method(int[] vals) { 
> ?? MyObject o1 = new MyObject(vals[0]); 
> ?? for (int i =1; i < vals.length; ++) { 
> ????? MyObject o2 = new MyObject(vals[i]); 
> ????? if (!o1.equals(o2)) { 
> ???????? o1 = o2; 
> ???????? ? 
> ????? } 
> ????? ? 
> ?? } 
> ?? ? 
> } 
>
> In the above example if o2 was stack allocated and you ever entered the ?if? from that point on o1 and o2 would 
> always be the same object. This is incorrect so o2 cannot be stack allocated. 
>
> Thanks for reading and we look forward to your feedback! 
> Charlie Gracie & Nikola Grcevski 
>
>




Amazon Development Center Germany GmbH 
Krausenstr. 38 
10117 Berlin 
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss 
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B 
Sitz: Berlin 
Ust-ID: DE 289 237 879 





From Nikola.Grcevski at microsoft.com  Tue Jan 28 22:50:33 2020
From: Nikola.Grcevski at microsoft.com (Nikola Grcevski)
Date: Tue, 28 Jan 2020 22:50:33 +0000
Subject: Stack allocation prototype for C2
In-Reply-To: <etPan.5e303b0b.bf9ccf5.158@oracle.com>
References: <etPan.5e303b0b.bf9ccf5.158@oracle.com>
Message-ID: <MN2PR21MB1261BCF6350B4A89A684F113F50A0@MN2PR21MB1261.namprd21.prod.outlook.com>

Hi Ron, 

> Reading between the lines, the difference between scalar replacement and what you call "stack allocation" is that the latter creates an oop pointing into the stack frame. Is that correct? 

Yes, you are correct. There will be oops on the stack that will point to stack locations in the same nmethod frame. We used the BoxLockNode in C2 and these stack allocated objects end up at the bottom of the frame.

> If so, there is another consideration to take into account. Loom continuations can relocate stack frames in memory, and currently, compiled frames do not contain pointers into the stack. This relocation can potentially happen at any safepoint, but the continuation algorithm has two modes. In the slow mode -- used when there are interpreted frames or, for forced preemption, at any arbitrary safepoint -- the stack frames are parsed and walked, and so pointers in the stack that point into the stack could be patched (I assume, from your description that you do not allow oops outside the stack to point into the stack). In the fast mode, we avoid parsing the stack and we just copy the frames as-is, and it can occur at any nmethod call. If your "stack-oops" can currently live across nmethod calls, how much would this optimization be compromised if you disallowed that (i.e. stack oops to stack-allocated objects would not live across nmethod calls)?

Thanks so much for this insight. It seems that we would have to add some code to fix-up/patch the stack oops only in the fast relocation mode, unless that's a dealbreaker? We currently describe the stack allocated object for deoptimization purposes on every safepoint where the objects are live, so perhaps we can use the same information to fix-up the stack on relocation. We initially disallowed stack allocating any objects that lived across safepoints until we implemented the deoptimization support, so yes the optimization would definitely be compromised with that limitation, quite a bit of opportunities will be rejected. Some of the benchmarks we quoted still improve with this limitation around safepoints, but we'd have to remeasure for final numbers. 

> Also, if my understanding is correct, I'm not sure you need to limit the optimization to -UseCompressedOops. I believe that even when compressed oops are used, stack oops can be wide; i.e. we do find frames with mixed narrow and wide oops in them, and the oopmaps allow for that possibility.

Our present limitation was mainly related to autos that can point to either stack allocated object or heap object, depending on the context. With compressed oops enabled we saw the oop always undergo an EncodeP before it was stored on the stack, after a merge point. It would be great if there's a way to overcome this in the IR, we are both new to OpenJDK and could use guidance on how to approach the problem.

Thanks a lot for your insights and feedback!

Nikola

-----Original Message-----
From: Ron Pressler <ron.pressler at oracle.com> 
Sent: January 28, 2020 8:46 AM
To: hotspot-compiler-dev at openjdk.java.net; Charlie Gracie <Charlie.Gracie at microsoft.com>; Nikola Grcevski <Nikola.Grcevski at microsoft.com>
Subject: Re: Stack allocation prototype for C2

?
Hi.

Reading between the lines, the difference between scalar replacement and what you call "stack allocation" is that the latter creates an oop pointing into the stack frame. Is that correct?

If so, there is another consideration to take into account. Loom continuations can relocate stack frames in memory, and currently, compiled frames do not contain pointers into the stack. This relocation can potentially happen at any safepoint, but the continuation algorithm has two modes. In the slow mode -- used when there are interpreted frames or, for forced preemption, at any arbitrary safepoint -- the stack frames are parsed and walked, and so pointers in the stack that point into the stack could be patched (I assume, from your description that you do not allow oops outside the stack to point into the stack). In the fast mode, we avoid parsing the stack and we just copy the frames as-is, and it can occur at any nmethod call. If your "stack-oops" can currently live across nmethod calls, how much would this optimization be compromised if you disallowed that (i.e. stack oops to stack-allocated objects would not live across nmethod calls)?

Also, if my understanding is correct, I'm not sure you need to limit the optimization to -UseCompressedOops. I believe that even when compressed oops are used, stack oops can be wide; i.e. we do find frames with mixed narrow and wide oops in them, and the oopmaps allow for that possibility.

Ron  


On 27 January 2020 at 15:58:43, Charlie Gracie wrote:  

>  
> Hi,
>
> We have been prototyping Stack Allocation in C2. We are hoping to 
> start a conversation on our approach and to see if there is interest 
> in the community for us to submit our work as a patch set. We would appreciate any comments, concerns or feedback on our current approach or the idea in general. Thanks!
>
> Background on why we are investigating Stack Allocation:
> While investigating the performance of different workloads (a lot of 
> Scala but some plain Java), we noticed a lot of GC and heap pressure 
> due to transient object allocations. Upon further digging we were able 
> to see that C2?s Escape Analysis phase was correctly recognizing these 
> allocations as Non Escaping. The allocations were not being Scalar 
> Replaced due to a few different restrictions but the most common was due to control flow merge points before accessing the objects. Here is a simplified example of a case where an allocation cannot be Scalar Replaced even though it is recognized as Non Escaping.
>
> int foo(int x, MyObject[] vals) {
> MyObject bar;
> If (x > 127) {
> bar = new MyObject(x);
> } else {
> bar = vals[x];
> }
> return bar.x;
> }
>
> In the above example the allocation could successfully be replaced 
> with a Stack Allocation. We believe that a lot of code has control 
> flow merge points that cause Scalar Replacement to be rejected but 
> Stack Allocation could work for many of them. The obvious benefit is the reduction in GC/heap pressure, but you also get the added benefit of improved cache hit rate since the stack allocated objects will likely be in the cache memory.
> There are costs with Stack Allocation including increased compilation times and increased code cache size.
> These would have to be carefully measured fully understand the benefits and costs.
>
> Our current approach:
> 1. Only allow stack allocation in non-compressed oops mode 
> (-XX:-UseCompressedOops)
> 1.1 This simplifies the prototype and we believe there are solutions 
> for compressed oops 2. Focus on ParallelGC and G1GC for prototype
> 2.1 Support for other collectors needs to be investigated 3. Current 
> prototype is based on JDK 11
> 3.1 We are going to work on moving it up to tip shortly
> 3.2 We have been following the changes in tip and this work should 
> apply easily 4. Use the results from Escape Analysis to decide which 
> objects are eligible for Stack Allocation
> 4.1 Scalar Replacement is the most important, so allow that to happen 
> first
> 4.2 Arrays cannot be stack allocated in the current prototype.
> 4.2.1 Straight forward to implement
> 4.3 Stack allocated objects cannot reference other stack allocated objects.
> 4.3.1 More difficult than arrays but should be doable
> 4.4 Reject allocations based on the reasons listed below in the 
> details section 5. In macro expansion during expand allocation replace allocations eligible for Stack Allocation.
> 5.1 Replace the AllocNode with a BoxLockNode with the correct stack 
> location and remove the slow path and other unused IR
> 5.2 Repurpose BoxLock nodes to represent the stack location for the 
> object
> 5.3 No Stack Allocation in methods that contain synchronization.
> 5.3.1 This restriction should be easy to remove.
> 5.4 Remove write barriers on stores into stack allocated objects 6. 
> Grow the frame size to handle the stack allocated objects 7. Modify 
> OopMap scanning to handle stack allocated objects
> 7.1 Currently handled via a generic OopClosure for all GCs
> 7.2 More work required for full GC collector coverage 8. Safepoint 
> support reuses SafePointScalarObject
> 8.1 De-optimization is working and correctly allocating heap objects 
> and initializing their fields
>
> Current Results:
> 1. Microbenchmarks using JMH simply replace all allocations using 
> Stack Allocation where Scalar Replacement 2. Workloads in DeCapo and 
> Renaissance are showing benefits 3. We have not measured any negative 
> impacts on application throughput 4. More detailed analysis on 
> compilation times and code cache size are required
>
> Benchmark % Improvement
> DeCapo tmt 15
> Renaissance db-shootout 10
> Renaissance fj-kmeans 5
> Renaissance future-genetic 10
> Renaissance movie-lens 5
> Renaissance neo4j-analytics 45
>
> Details on why allocations should not be replaced with Stack Allocation:
> Not all Non Escaping objects can be Stack Allocated so there will 
> still be cases where Non Escaping allocations will need to be allocated on the heap:
> 1. Large arrays and objects should likely be ignored as they could 
> significantly impact the stack frame size 2. Similar to 1 limit the 
> total amount of stack memory per frame that should be used for Stack 
> Allocations 3. Objects and arrays without constant sizes/lengths 4. 
> Allocations with over lapping lifetimes from different loop iterations 
> 5. A stack allocated object cannot be referenced by any other Non 
> Escaping objects that are not scalar replaced or stack allocated as 
> that would count as an escape
>
> Here is a simple example of what I was describing in 4.
> int method(int[] vals) {
> MyObject o1 = new MyObject(vals[0]);
> for (int i =1; i < vals.length; ++) {
> MyObject o2 = new MyObject(vals[i]);
> if (!o1.equals(o2)) {
> o1 = o2;
> ?
> }
> ?
> }
> ?
> }
>
> In the above example if o2 was stack allocated and you ever entered 
> the ?if? from that point on o1 and o2 would always be the same object. This is incorrect so o2 cannot be stack allocated.
>
> Thanks for reading and we look forward to your feedback!
> Charlie Gracie & Nikola Grcevski
>
>



From igor.ignatyev at oracle.com  Tue Jan 28 22:52:00 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 28 Jan 2020 14:52:00 -0800
Subject: RFR(S) : 8238049 : TieredCompilation shouldn't be re-enabled if
 CompilationMode is high-only
Message-ID: <9A0AFE73-06BA-447A-B75E-72C4B3DF5238@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
> 9 lines changed: 3 ins; 2 del; 4 mod;


Hi all,

could you please review the small and trivial-ish patch?
from JBS:
> currently, if you run java w/ -XX:-TieredCompilation -XX:+UseJVMCICompiler, TieredCompilation will be set back to true and change CompilationMode from "default" to "high-only-quick-internal" (w/o actually changing the value of the flag though). if you run it w/ '-XX:-TieredCompilation -XX:+UseJVMCICompile -XX:CompilationMode=high-only', TieredCompilation will be changed to true, but CompilationMode will remain high-only, so effectively it just needlessly enables TieredCompilation.

the patch not only leaves TieredCompilation disabled when CompilationMode is high-only, but also changes the actual value of CompilationMode flag, so it will be properly reported.

JBS: https://bugs.openjdk.java.net/browse/JDK-8238049
webrev: http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
testing: manual by java -XX:+PrintFlagsFinal w/ {-TieredCompilation,+TieredCompilation}x{CompilationMode=default,CompilationMode=high-only,""}

Thanks,
-- Igor
 

From ron.pressler at oracle.com  Tue Jan 28 23:05:46 2020
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 28 Jan 2020 23:05:46 +0000
Subject: Stack allocation prototype for C2
In-Reply-To: <MN2PR21MB1261BCF6350B4A89A684F113F50A0@MN2PR21MB1261.namprd21.prod.outlook.com>
References: <etPan.5e303b0b.bf9ccf5.158@oracle.com>
 <MN2PR21MB1261BCF6350B4A89A684F113F50A0@MN2PR21MB1261.namprd21.prod.outlook.com>
Message-ID: <etPan.5e30be4a.59c994bd.158@oracle.com>

In the fast mode we cannot patch any frame contents because we don?t know what the frames are
(or even where they begin and end) ? that?s why that mode is fast. However, that mode is?
only relevant at nmethod calls, not any other kind of safepoint. So the only limitation is
stack oops living across nmethod calls. If even that limitation significantly harms performance,
we can weigh our options.

Ron





On 28 January 2020 at 22:52:38, Nikola Grcevski (nikola.grcevski at microsoft.com(mailto:nikola.grcevski at microsoft.com)) wrote:

> Hi Ron,
>  
> > Reading between the lines, the difference between scalar replacement and what you call "stack allocation" is that the latter creates an oop pointing into the stack frame. Is that correct?
>  
> Yes, you are correct. There will be oops on the stack that will point to stack locations in the same nmethod frame. We used the BoxLockNode in C2 and these stack allocated objects end up at the bottom of the frame.
>  
> > If so, there is another consideration to take into account. Loom continuations can relocate stack frames in memory, and currently, compiled frames do not contain pointers into the stack. This relocation can potentially happen at any safepoint, but the continuation algorithm has two modes. In the slow mode -- used when there are interpreted frames or, for forced preemption, at any arbitrary safepoint -- the stack frames are parsed and walked, and so pointers in the stack that point into the stack could be patched (I assume, from your description that you do not allow oops outside the stack to point into the stack). In the fast mode, we avoid parsing the stack and we just copy the frames as-is, and it can occur at any nmethod call. If your "stack-oops" can currently live across nmethod calls, how much would this optimization be compromised if you disallowed that (i.e. stack oops to stack-allocated objects would not live across nmethod calls)?
>  
> Thanks so much for this insight. It seems that we would have to add some code to fix-up/patch the stack oops only in the fast relocation mode, unless that's a dealbreaker? We currently describe the stack allocated object for deoptimization purposes on every safepoint where the objects are live, so perhaps we can use the same information to fix-up the stack on relocation. We initially disallowed stack allocating any objects that lived across safepoints until we implemented the deoptimization support, so yes the optimization would definitely be compromised with that limitation, quite a bit of opportunities will be rejected. Some of the benchmarks we quoted still improve with this limitation around safepoints, but we'd have to remeasure for final numbers.
>  
> > Also, if my understanding is correct, I'm not sure you need to limit the optimization to -UseCompressedOops. I believe that even when compressed oops are used, stack oops can be wide; i.e. we do find frames with mixed narrow and wide oops in them, and the oopmaps allow for that possibility.
>  
> Our present limitation was mainly related to autos that can point to either stack allocated object or heap object, depending on the context. With compressed oops enabled we saw the oop always undergo an EncodeP before it was stored on the stack, after a merge point. It would be great if there's a way to overcome this in the IR, we are both new to OpenJDK and could use guidance on how to approach the problem.
>  
> Thanks a lot for your insights and feedback!
>  
> Nikola
>  
> -----Original Message-----
> From: Ron Pressler  
> Sent: January 28, 2020 8:46 AM
> To: hotspot-compiler-dev at openjdk.java.net; Charlie Gracie ; Nikola Grcevski  
> Subject: Re: Stack allocation prototype for C2
>  
>  
> Hi.
>  
> Reading between the lines, the difference between scalar replacement and what you call "stack allocation" is that the latter creates an oop pointing into the stack frame. Is that correct?
>  
> If so, there is another consideration to take into account. Loom continuations can relocate stack frames in memory, and currently, compiled frames do not contain pointers into the stack. This relocation can potentially happen at any safepoint, but the continuation algorithm has two modes. In the slow mode -- used when there are interpreted frames or, for forced preemption, at any arbitrary safepoint -- the stack frames are parsed and walked, and so pointers in the stack that point into the stack could be patched (I assume, from your description that you do not allow oops outside the stack to point into the stack). In the fast mode, we avoid parsing the stack and we just copy the frames as-is, and it can occur at any nmethod call. If your "stack-oops" can currently live across nmethod calls, how much would this optimization be compromised if you disallowed that (i.e. stack oops to stack-allocated objects would not live across nmethod calls)?
>  
> Also, if my understanding is correct, I'm not sure you need to limit the optimization to -UseCompressedOops. I believe that even when compressed oops are used, stack oops can be wide; i.e. we do find frames with mixed narrow and wide oops in them, and the oopmaps allow for that possibility.
>  
> Ron
>  
>  
> On 27 January 2020 at 15:58:43, Charlie Gracie wrote:
>  
> >
> > Hi,
> >
> > We have been prototyping Stack Allocation in C2. We are hoping to
> > start a conversation on our approach and to see if there is interest
> > in the community for us to submit our work as a patch set. We would appreciate any comments, concerns or feedback on our current approach or the idea in general. Thanks!
> >
> > Background on why we are investigating Stack Allocation:
> > While investigating the performance of different workloads (a lot of
> > Scala but some plain Java), we noticed a lot of GC and heap pressure
> > due to transient object allocations. Upon further digging we were able
> > to see that C2?s Escape Analysis phase was correctly recognizing these
> > allocations as Non Escaping. The allocations were not being Scalar
> > Replaced due to a few different restrictions but the most common was due to control flow merge points before accessing the objects. Here is a simplified example of a case where an allocation cannot be Scalar Replaced even though it is recognized as Non Escaping.
> >
> > int foo(int x, MyObject[] vals) {
> > MyObject bar;
> > If (x > 127) {
> > bar = new MyObject(x);
> > } else {
> > bar = vals[x];
> > }
> > return bar.x;
> > }
> >
> > In the above example the allocation could successfully be replaced
> > with a Stack Allocation. We believe that a lot of code has control
> > flow merge points that cause Scalar Replacement to be rejected but
> > Stack Allocation could work for many of them. The obvious benefit is the reduction in GC/heap pressure, but you also get the added benefit of improved cache hit rate since the stack allocated objects will likely be in the cache memory.
> > There are costs with Stack Allocation including increased compilation times and increased code cache size.
> > These would have to be carefully measured fully understand the benefits and costs.
> >
> > Our current approach:
> > 1. Only allow stack allocation in non-compressed oops mode
> > (-XX:-UseCompressedOops)
> > 1.1 This simplifies the prototype and we believe there are solutions
> > for compressed oops 2. Focus on ParallelGC and G1GC for prototype
> > 2.1 Support for other collectors needs to be investigated 3. Current
> > prototype is based on JDK 11
> > 3.1 We are going to work on moving it up to tip shortly
> > 3.2 We have been following the changes in tip and this work should
> > apply easily 4. Use the results from Escape Analysis to decide which
> > objects are eligible for Stack Allocation
> > 4.1 Scalar Replacement is the most important, so allow that to happen
> > first
> > 4.2 Arrays cannot be stack allocated in the current prototype.
> > 4.2.1 Straight forward to implement
> > 4.3 Stack allocated objects cannot reference other stack allocated objects.
> > 4.3.1 More difficult than arrays but should be doable
> > 4.4 Reject allocations based on the reasons listed below in the
> > details section 5. In macro expansion during expand allocation replace allocations eligible for Stack Allocation.
> > 5.1 Replace the AllocNode with a BoxLockNode with the correct stack
> > location and remove the slow path and other unused IR
> > 5.2 Repurpose BoxLock nodes to represent the stack location for the
> > object
> > 5.3 No Stack Allocation in methods that contain synchronization.
> > 5.3.1 This restriction should be easy to remove.
> > 5.4 Remove write barriers on stores into stack allocated objects 6.
> > Grow the frame size to handle the stack allocated objects 7. Modify
> > OopMap scanning to handle stack allocated objects
> > 7.1 Currently handled via a generic OopClosure for all GCs
> > 7.2 More work required for full GC collector coverage 8. Safepoint
> > support reuses SafePointScalarObject
> > 8.1 De-optimization is working and correctly allocating heap objects
> > and initializing their fields
> >
> > Current Results:
> > 1. Microbenchmarks using JMH simply replace all allocations using
> > Stack Allocation where Scalar Replacement 2. Workloads in DeCapo and
> > Renaissance are showing benefits 3. We have not measured any negative
> > impacts on application throughput 4. More detailed analysis on
> > compilation times and code cache size are required
> >
> > Benchmark % Improvement
> > DeCapo tmt 15
> > Renaissance db-shootout 10
> > Renaissance fj-kmeans 5
> > Renaissance future-genetic 10
> > Renaissance movie-lens 5
> > Renaissance neo4j-analytics 45
> >
> > Details on why allocations should not be replaced with Stack Allocation:
> > Not all Non Escaping objects can be Stack Allocated so there will
> > still be cases where Non Escaping allocations will need to be allocated on the heap:
> > 1. Large arrays and objects should likely be ignored as they could
> > significantly impact the stack frame size 2. Similar to 1 limit the
> > total amount of stack memory per frame that should be used for Stack
> > Allocations 3. Objects and arrays without constant sizes/lengths 4.
> > Allocations with over lapping lifetimes from different loop iterations
> > 5. A stack allocated object cannot be referenced by any other Non
> > Escaping objects that are not scalar replaced or stack allocated as
> > that would count as an escape
> >
> > Here is a simple example of what I was describing in 4.
> > int method(int[] vals) {
> > MyObject o1 = new MyObject(vals[0]);
> > for (int i =1; i < vals.length; ++) {
> > MyObject o2 = new MyObject(vals[i]);
> > if (!o1.equals(o2)) {
> > o1 = o2;
> > ?
> > }
> > ?
> > }
> > ?
> > }
> >
> > In the above example if o2 was stack allocated and you ever entered
> > the ?if? from that point on o1 and o2 would always be the same object. This is incorrect so o2 cannot be stack allocated.
> >
> > Thanks for reading and we look forward to your feedback!
> > Charlie Gracie & Nikola Grcevski
> >
> >
>  
>  


From Nikola.Grcevski at microsoft.com  Wed Jan 29 00:26:07 2020
From: Nikola.Grcevski at microsoft.com (Nikola Grcevski)
Date: Wed, 29 Jan 2020 00:26:07 +0000
Subject: Stack allocation prototype for C2
In-Reply-To: <etPan.5e30be4a.59c994bd.158@oracle.com>
References: <etPan.5e303b0b.bf9ccf5.158@oracle.com>
 <MN2PR21MB1261BCF6350B4A89A684F113F50A0@MN2PR21MB1261.namprd21.prod.outlook.com>
 <etPan.5e30be4a.59c994bd.158@oracle.com>
Message-ID: <MN2PR21MB12618461DBE4C9663C7E4702F5050@MN2PR21MB1261.namprd21.prod.outlook.com>

Thanks for the explanation Ron, that makes sense. We'll change the protype code and run an experiment where we reject only safepoints that are nmethod calls. We should be able to produce some numbers soon and share with everyone.

Cheers,
Nikola

-----Original Message-----
From: Ron Pressler <ron.pressler at oracle.com> 
Sent: January 28, 2020 6:06 PM
To: Nikola Grcevski <Nikola.Grcevski at microsoft.com>; hotspot-compiler-dev at openjdk.java.net; Charlie Gracie <Charlie.Gracie at microsoft.com>
Subject: RE: Stack allocation prototype for C2

In the fast mode we cannot patch any frame contents because we don?t know what the frames are (or even where they begin and end) ? that?s why that mode is fast. However, that mode is only relevant at nmethod calls, not any other kind of safepoint. So the only limitation is stack oops living across nmethod calls. If even that limitation significantly harms performance, we can weigh our options.

Ron





On 28 January 2020 at 22:52:38, Nikola Grcevski (nikola.grcevski at microsoft.com(mailto:nikola.grcevski at microsoft.com)) wrote:

> Hi Ron,
>  
> > Reading between the lines, the difference between scalar replacement and what you call "stack allocation" is that the latter creates an oop pointing into the stack frame. Is that correct?
>  
> Yes, you are correct. There will be oops on the stack that will point to stack locations in the same nmethod frame. We used the BoxLockNode in C2 and these stack allocated objects end up at the bottom of the frame.
>  
> > If so, there is another consideration to take into account. Loom continuations can relocate stack frames in memory, and currently, compiled frames do not contain pointers into the stack. This relocation can potentially happen at any safepoint, but the continuation algorithm has two modes. In the slow mode -- used when there are interpreted frames or, for forced preemption, at any arbitrary safepoint -- the stack frames are parsed and walked, and so pointers in the stack that point into the stack could be patched (I assume, from your description that you do not allow oops outside the stack to point into the stack). In the fast mode, we avoid parsing the stack and we just copy the frames as-is, and it can occur at any nmethod call. If your "stack-oops" can currently live across nmethod calls, how much would this optimization be compromised if you disallowed that (i.e. stack oops to stack-allocated objects would not live across nmethod calls)?
>  
> Thanks so much for this insight. It seems that we would have to add some code to fix-up/patch the stack oops only in the fast relocation mode, unless that's a dealbreaker? We currently describe the stack allocated object for deoptimization purposes on every safepoint where the objects are live, so perhaps we can use the same information to fix-up the stack on relocation. We initially disallowed stack allocating any objects that lived across safepoints until we implemented the deoptimization support, so yes the optimization would definitely be compromised with that limitation, quite a bit of opportunities will be rejected. Some of the benchmarks we quoted still improve with this limitation around safepoints, but we'd have to remeasure for final numbers.
>  
> > Also, if my understanding is correct, I'm not sure you need to limit the optimization to -UseCompressedOops. I believe that even when compressed oops are used, stack oops can be wide; i.e. we do find frames with mixed narrow and wide oops in them, and the oopmaps allow for that possibility.
>  
> Our present limitation was mainly related to autos that can point to either stack allocated object or heap object, depending on the context. With compressed oops enabled we saw the oop always undergo an EncodeP before it was stored on the stack, after a merge point. It would be great if there's a way to overcome this in the IR, we are both new to OpenJDK and could use guidance on how to approach the problem.
>  
> Thanks a lot for your insights and feedback!
>  
> Nikola
>  
> -----Original Message-----
> From: Ron Pressler
> Sent: January 28, 2020 8:46 AM
> To: hotspot-compiler-dev at openjdk.java.net; Charlie Gracie ; Nikola 
> Grcevski
> Subject: Re: Stack allocation prototype for C2
>  
>  
> Hi.
>  
> Reading between the lines, the difference between scalar replacement and what you call "stack allocation" is that the latter creates an oop pointing into the stack frame. Is that correct?
>  
> If so, there is another consideration to take into account. Loom continuations can relocate stack frames in memory, and currently, compiled frames do not contain pointers into the stack. This relocation can potentially happen at any safepoint, but the continuation algorithm has two modes. In the slow mode -- used when there are interpreted frames or, for forced preemption, at any arbitrary safepoint -- the stack frames are parsed and walked, and so pointers in the stack that point into the stack could be patched (I assume, from your description that you do not allow oops outside the stack to point into the stack). In the fast mode, we avoid parsing the stack and we just copy the frames as-is, and it can occur at any nmethod call. If your "stack-oops" can currently live across nmethod calls, how much would this optimization be compromised if you disallowed that (i.e. stack oops to stack-allocated objects would not live across nmethod calls)?
>  
> Also, if my understanding is correct, I'm not sure you need to limit the optimization to -UseCompressedOops. I believe that even when compressed oops are used, stack oops can be wide; i.e. we do find frames with mixed narrow and wide oops in them, and the oopmaps allow for that possibility.
>  
> Ron
>  
>  
> On 27 January 2020 at 15:58:43, Charlie Gracie wrote:
>  
> >
> > Hi,
> >
> > We have been prototyping Stack Allocation in C2. We are hoping to 
> > start a conversation on our approach and to see if there is interest 
> > in the community for us to submit our work as a patch set. We would appreciate any comments, concerns or feedback on our current approach or the idea in general. Thanks!
> >
> > Background on why we are investigating Stack Allocation:
> > While investigating the performance of different workloads (a lot of 
> > Scala but some plain Java), we noticed a lot of GC and heap pressure 
> > due to transient object allocations. Upon further digging we were 
> > able to see that C2?s Escape Analysis phase was correctly 
> > recognizing these allocations as Non Escaping. The allocations were 
> > not being Scalar Replaced due to a few different restrictions but the most common was due to control flow merge points before accessing the objects. Here is a simplified example of a case where an allocation cannot be Scalar Replaced even though it is recognized as Non Escaping.
> >
> > int foo(int x, MyObject[] vals) {
> > MyObject bar;
> > If (x > 127) {
> > bar = new MyObject(x);
> > } else {
> > bar = vals[x];
> > }
> > return bar.x;
> > }
> >
> > In the above example the allocation could successfully be replaced 
> > with a Stack Allocation. We believe that a lot of code has control 
> > flow merge points that cause Scalar Replacement to be rejected but 
> > Stack Allocation could work for many of them. The obvious benefit is the reduction in GC/heap pressure, but you also get the added benefit of improved cache hit rate since the stack allocated objects will likely be in the cache memory.
> > There are costs with Stack Allocation including increased compilation times and increased code cache size.
> > These would have to be carefully measured fully understand the benefits and costs.
> >
> > Our current approach:
> > 1. Only allow stack allocation in non-compressed oops mode
> > (-XX:-UseCompressedOops)
> > 1.1 This simplifies the prototype and we believe there are solutions 
> > for compressed oops 2. Focus on ParallelGC and G1GC for prototype
> > 2.1 Support for other collectors needs to be investigated 3. Current 
> > prototype is based on JDK 11
> > 3.1 We are going to work on moving it up to tip shortly
> > 3.2 We have been following the changes in tip and this work should 
> > apply easily 4. Use the results from Escape Analysis to decide which 
> > objects are eligible for Stack Allocation
> > 4.1 Scalar Replacement is the most important, so allow that to 
> > happen first
> > 4.2 Arrays cannot be stack allocated in the current prototype.
> > 4.2.1 Straight forward to implement
> > 4.3 Stack allocated objects cannot reference other stack allocated objects.
> > 4.3.1 More difficult than arrays but should be doable
> > 4.4 Reject allocations based on the reasons listed below in the 
> > details section 5. In macro expansion during expand allocation replace allocations eligible for Stack Allocation.
> > 5.1 Replace the AllocNode with a BoxLockNode with the correct stack 
> > location and remove the slow path and other unused IR
> > 5.2 Repurpose BoxLock nodes to represent the stack location for the 
> > object
> > 5.3 No Stack Allocation in methods that contain synchronization.
> > 5.3.1 This restriction should be easy to remove.
> > 5.4 Remove write barriers on stores into stack allocated objects 6.
> > Grow the frame size to handle the stack allocated objects 7. Modify 
> > OopMap scanning to handle stack allocated objects
> > 7.1 Currently handled via a generic OopClosure for all GCs
> > 7.2 More work required for full GC collector coverage 8. Safepoint 
> > support reuses SafePointScalarObject
> > 8.1 De-optimization is working and correctly allocating heap objects 
> > and initializing their fields
> >
> > Current Results:
> > 1. Microbenchmarks using JMH simply replace all allocations using 
> > Stack Allocation where Scalar Replacement 2. Workloads in DeCapo and 
> > Renaissance are showing benefits 3. We have not measured any 
> > negative impacts on application throughput 4. More detailed analysis 
> > on compilation times and code cache size are required
> >
> > Benchmark % Improvement
> > DeCapo tmt 15
> > Renaissance db-shootout 10
> > Renaissance fj-kmeans 5
> > Renaissance future-genetic 10
> > Renaissance movie-lens 5
> > Renaissance neo4j-analytics 45
> >
> > Details on why allocations should not be replaced with Stack Allocation:
> > Not all Non Escaping objects can be Stack Allocated so there will 
> > still be cases where Non Escaping allocations will need to be allocated on the heap:
> > 1. Large arrays and objects should likely be ignored as they could 
> > significantly impact the stack frame size 2. Similar to 1 limit the 
> > total amount of stack memory per frame that should be used for Stack 
> > Allocations 3. Objects and arrays without constant sizes/lengths 4.
> > Allocations with over lapping lifetimes from different loop 
> > iterations 5. A stack allocated object cannot be referenced by any 
> > other Non Escaping objects that are not scalar replaced or stack 
> > allocated as that would count as an escape
> >
> > Here is a simple example of what I was describing in 4.
> > int method(int[] vals) {
> > MyObject o1 = new MyObject(vals[0]); for (int i =1; i < vals.length; 
> > ++) { MyObject o2 = new MyObject(vals[i]); if (!o1.equals(o2)) {
> > o1 = o2;
> > ?
> > }
> > ?
> > }
> > ?
> > }
> >
> > In the above example if o2 was stack allocated and you ever entered 
> > the ?if? from that point on o1 and o2 would always be the same object. This is incorrect so o2 cannot be stack allocated.
> >
> > Thanks for reading and we look forward to your feedback!
> > Charlie Gracie & Nikola Grcevski
> >
> >
>  
>  


From igor.ignatyev at oracle.com  Wed Jan 29 04:17:56 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 28 Jan 2020 20:17:56 -0800
Subject: RFR(T/XS): 8236211 [Graal] compiler/graalunit/GraphTest.java is
 skipped in all testing
In-Reply-To: <7eb0c680-08fd-211d-5ee3-ce52cbb468e3@oracle.com>
References: <df5b4600-892f-fecb-cee6-293f90b66682@oracle.com>
 <7eb0c680-08fd-211d-5ee3-ce52cbb468e3@oracle.com>
Message-ID: <03BD513C-E719-4994-ACC7-4FF284D273C5@oracle.com>

LGTM.

-- Igor

> On Jan 28, 2020, at 10:33 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
> 
> Hi,
> 
> can I please get one review?
> 
> thanks,
> -katya
> 
> On 1/24/20 8:12 AM, Ekaterina Pavlova wrote:
>> Hi All,
>> Please review the small patch which adds required --add-opens required for
>> org.graalvm.compiler.graph tests (compiler/graalunit/GraphTest.java).
>> Also removed unnecessary "@requires vm.graal.enabled" from compiler/graalunit/NodesTest.java.
>> Both tests will start running in graal tiers after this fix
>> (these tests are now skipped because graalunit tests are tested only in non Graal as JIT mode).
>>       JBS: https://bugs.openjdk.java.net/browse/JDK-8236211
>>    webrev: http://cr.openjdk.java.net/~epavlova/8236211/webrev.00/index.html
>>   testing: graal tiers
>> thanks,
>> -katya
> 


From rwestrel at redhat.com  Wed Jan 29 08:42:40 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 29 Jan 2020 09:42:40 +0100
Subject: RFR(XS): CTW: C2 compilation fails with "malformed control flow"
Message-ID: <87ftfywt4v.fsf@redhat.com>


http://cr.openjdk.java.net/~roland/8237951/webrev.00/

CatchNode::Value() makes the fallthrough path of a virtual or interface
call dead if the receiver is null. This failure occurs because the
fallthrough is erroneously killed during CCP. When CCP is executed, the
type of the receiver is first set to top which causes CatchNode::Value()
to make the fallthrough path dead then the type of the receiver changes
to non null but the CatchNode is not reprocessed by CCP. That happens
because:

1758         // If we changed the receiver type to a call, we need to revisit
1759         // the Catch following the call.  It's looking for a non-NULL
1760         // receiver to know when to enable the regular fall-through path
1761         // in addition to the NullPtrException path
1762         if (m->is_Call()) {
1763           for (DUIterator_Fast i2max, i2 = m->fast_outs(i2max); i2 < i2max; i2++) {
1764             Node* p = m->fast_out(i2);  // Propagate changes to uses
1765             if (p->is_Proj() && p->as_Proj()->_con == TypeFunc::Control && p->outcnt() == 1) {
1766               worklist.push(p->unique_out());

the ProjNode has more than one use: a Load is pinned there. I could
write a test case that causes a Load to be pinned on a Proj after a Call
but couldn't have the test case trigger the failure (most likely because
node processing order during CCP matters). The fix is to enqueue the
CatchNode even if p doesn't have a single use.

Note: this triggered with Shenandoah but is not specific to Shenandoah.

Roland.


From adinn at redhat.com  Wed Jan 29 10:17:10 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 29 Jan 2020 10:17:10 +0000
Subject: [aarch64-port-dev ] RFR(S): 8237524: AArch64: String.compareTo()
 may return incorrect result
In-Reply-To: <DB7PR08MB3115C39DCFEB449A5FA53D90960A0@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115A91957168FF38760DC47960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <5111fcc0-9c3a-6f1b-9d6a-b666a41f4453@redhat.com>
 <b5469d1a-82c8-1346-e658-0157a4a95da9@arm.com>
 <56670d62-defa-4192-c084-bfa130adde41@redhat.com>
 <DB7PR08MB3115C39DCFEB449A5FA53D90960A0@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <ff4704ea-3747-6e7b-0293-58c8a635bbc8@redhat.com>

On 28/01/2020 13:40, Pengfei Li wrote:
> Hi,
> 
> Can any committer help push this fix? http://cr.openjdk.java.net/~pli/rfr/8237524/webrev.00/
> 
> Patch is reviewed by aph. See below review thread.
Thanks Pengfei. I just pushed it.

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


From shade at redhat.com  Wed Jan 29 10:51:08 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 29 Jan 2020 11:51:08 +0100
Subject: RFR (XS) 8238153: CTW: C2 (Shenandoah) compilation fails with
 "Unknown node in get_load_addr: CreateEx"
Message-ID: <ca2edf87-2514-5d13-bd91-6b5c6ed26ac6@redhat.com>

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8238153

CTW tests caught this failure. I believe CreateEx should just be explicitly excepted, for the same
reason we did JDK-8229350: CreateEx has no useful inputs for us. This patch is safe, because it does
what "default" case does in release bits anyway.

diff -r e7c4199e4d32 src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
--- a/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp  Mon Jan 27 09:58:27 2020 -0500
+++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp  Wed Jan 29 11:44:59 2020 +0100
@@ -1796,12 +1796,13 @@
     case Op_CallDynamicJava:
     case Op_CallLeaf:
     case Op_CallStaticJava:
     case Op_ConN:
     case Op_ConP:
     case Op_Parm:
+    case Op_CreateEx:
       return phase->igvn().zerocon(T_OBJECT);
     default:
 #ifdef ASSERT
       fatal("Unknown node in get_load_addr: %s", NodeClassNames[in->Opcode()]);
 #endif
       return phase->igvn().zerocon(T_OBJECT);

Testing: affected CTW tests; will run hotspot_gc_shenandoah before push

-- 
Thanks,
-Aleksey


From rwestrel at redhat.com  Wed Jan 29 12:57:17 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 29 Jan 2020 13:57:17 +0100
Subject: RFR (XS) 8238153: CTW: C2 (Shenandoah) compilation fails with
 "Unknown node in get_load_addr: CreateEx"
In-Reply-To: <ca2edf87-2514-5d13-bd91-6b5c6ed26ac6@redhat.com>
References: <ca2edf87-2514-5d13-bd91-6b5c6ed26ac6@redhat.com>
Message-ID: <87ftfyh13m.fsf@redhat.com>


> CTW tests caught this failure. I believe CreateEx should just be explicitly excepted, for the same
> reason we did JDK-8229350: CreateEx has no useful inputs for us. This patch is safe, because it does
> what "default" case does in release bits anyway.
>
> diff -r e7c4199e4d32 src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
> --- a/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp  Mon Jan 27 09:58:27 2020 -0500
> +++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp  Wed Jan 29 11:44:59 2020 +0100
> @@ -1796,12 +1796,13 @@
>      case Op_CallDynamicJava:
>      case Op_CallLeaf:
>      case Op_CallStaticJava:
>      case Op_ConN:
>      case Op_ConP:
>      case Op_Parm:
> +    case Op_CreateEx:
>        return phase->igvn().zerocon(T_OBJECT);
>      default:
>  #ifdef ASSERT
>        fatal("Unknown node in get_load_addr: %s", NodeClassNames[in->Opcode()]);
>  #endif
>        return phase->igvn().zerocon(T_OBJECT);
>
> Testing: affected CTW tests; will run hotspot_gc_shenandoah before push

Looks good to me.

Roland.


From rkennke at redhat.com  Wed Jan 29 13:03:46 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 29 Jan 2020 14:03:46 +0100
Subject: RFR (XS) 8238153: CTW: C2 (Shenandoah) compilation fails with
 "Unknown node in get_load_addr: CreateEx"
In-Reply-To: <ca2edf87-2514-5d13-bd91-6b5c6ed26ac6@redhat.com>
References: <ca2edf87-2514-5d13-bd91-6b5c6ed26ac6@redhat.com>
Message-ID: <95003e3d-d12a-9a77-6993-d1be890acc51@redhat.com>

Yes, that makes sense. Thank you!

Roman


> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8238153
> 
> CTW tests caught this failure. I believe CreateEx should just be explicitly excepted, for the same
> reason we did JDK-8229350: CreateEx has no useful inputs for us. This patch is safe, because it does
> what "default" case does in release bits anyway.
> 
> diff -r e7c4199e4d32 src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
> --- a/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp  Mon Jan 27 09:58:27 2020 -0500
> +++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp  Wed Jan 29 11:44:59 2020 +0100
> @@ -1796,12 +1796,13 @@
>      case Op_CallDynamicJava:
>      case Op_CallLeaf:
>      case Op_CallStaticJava:
>      case Op_ConN:
>      case Op_ConP:
>      case Op_Parm:
> +    case Op_CreateEx:
>        return phase->igvn().zerocon(T_OBJECT);
>      default:
>  #ifdef ASSERT
>        fatal("Unknown node in get_load_addr: %s", NodeClassNames[in->Opcode()]);
>  #endif
>        return phase->igvn().zerocon(T_OBJECT);
> 
> Testing: affected CTW tests; will run hotspot_gc_shenandoah before push
> 


From Pengfei.Li at arm.com  Wed Jan 29 13:07:40 2020
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Wed, 29 Jan 2020 13:07:40 +0000
Subject: [aarch64-port-dev ] RFR(S): 8237524: AArch64: String.compareTo()
 may return incorrect result
In-Reply-To: <ff4704ea-3747-6e7b-0293-58c8a635bbc8@redhat.com>
References: <DB7PR08MB3115A91957168FF38760DC47960D0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <5111fcc0-9c3a-6f1b-9d6a-b666a41f4453@redhat.com>
 <b5469d1a-82c8-1346-e658-0157a4a95da9@arm.com>
 <56670d62-defa-4192-c084-bfa130adde41@redhat.com>
 <DB7PR08MB3115C39DCFEB449A5FA53D90960A0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <ff4704ea-3747-6e7b-0293-58c8a635bbc8@redhat.com>
Message-ID: <DB7PR08MB311573A243743A3E8690D96296050@DB7PR08MB3115.eurprd08.prod.outlook.com>

Thanks a lot.

> -----Original Message-----
> From: Andrew Dinn <adinn at redhat.com>
> Sent: Wednesday, January 29, 2020 18:17
> To: Pengfei Li <Pengfei.Li at arm.com>; Andrew Haley <aph at redhat.com>;
> Nick Gasson <Nick.Gasson at arm.com>; hotspot-compiler-
> dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net
> Cc: nd <nd at arm.com>
> Subject: Re: [aarch64-port-dev ] RFR(S): 8237524: AArch64:
> String.compareTo() may return incorrect result
> 
> On 28/01/2020 13:40, Pengfei Li wrote:
> > Hi,
> >
> > Can any committer help push this fix?
> http://cr.openjdk.java.net/~pli/rfr/8237524/webrev.00/
> >
> > Patch is reviewed by aph. See below review thread.
> Thanks Pengfei. I just pushed it.
> 
> 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


From vladimir.x.ivanov at oracle.com  Wed Jan 29 13:45:05 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 29 Jan 2020 16:45:05 +0300
Subject: RFR(XS): CTW: C2 compilation fails with "malformed control flow"
In-Reply-To: <87ftfywt4v.fsf@redhat.com>
References: <87ftfywt4v.fsf@redhat.com>
Message-ID: <a7de93f5-76e4-e80d-8746-0d60efb2c77e@oracle.com>


> http://cr.openjdk.java.net/~roland/8237951/webrev.00/

Looks good.

Best regards,
Vladimir Ivanov

> CatchNode::Value() makes the fallthrough path of a virtual or interface
> call dead if the receiver is null. This failure occurs because the
> fallthrough is erroneously killed during CCP. When CCP is executed, the
> type of the receiver is first set to top which causes CatchNode::Value()
> to make the fallthrough path dead then the type of the receiver changes
> to non null but the CatchNode is not reprocessed by CCP. That happens
> because:
> 
> 1758         // If we changed the receiver type to a call, we need to revisit
> 1759         // the Catch following the call.  It's looking for a non-NULL
> 1760         // receiver to know when to enable the regular fall-through path
> 1761         // in addition to the NullPtrException path
> 1762         if (m->is_Call()) {
> 1763           for (DUIterator_Fast i2max, i2 = m->fast_outs(i2max); i2 < i2max; i2++) {
> 1764             Node* p = m->fast_out(i2);  // Propagate changes to uses
> 1765             if (p->is_Proj() && p->as_Proj()->_con == TypeFunc::Control && p->outcnt() == 1) {
> 1766               worklist.push(p->unique_out());
> 
> the ProjNode has more than one use: a Load is pinned there. I could
> write a test case that causes a Load to be pinned on a Proj after a Call
> but couldn't have the test case trigger the failure (most likely because
> node processing order during CCP matters). The fix is to enqueue the
> CatchNode even if p doesn't have a single use.
> 
> Note: this triggered with Shenandoah but is not specific to Shenandoah.
> 
> Roland.
> 

From vladimir.x.ivanov at oracle.com  Wed Jan 29 18:18:28 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 29 Jan 2020 21:18:28 +0300
Subject: [15] RFR (M): 8237581: Improve allocation expansion
In-Reply-To: <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>
References: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>
 <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>
Message-ID: <b2bdf17b-ad2f-9072-dafa-cbea5f1fd731@oracle.com>

Thanks for separating the fix from the refactoring.

> Refactoring:
> 
> http://cr.openjdk.java.net/~neliasso/8237581/webrev.refactor/

Looks good.

> The actual change (on top of the refactoring)
> 
> http://cr.openjdk.java.net/~neliasso/8237581/webrev.change/

Overall, looks good.

I'd prefer to see yank_alloc_node(alloc) case separated.

What do you think about the following?

  if (!allocation_has_use) {
    InitializeNode* init = alloc->initialization();
    if (init != NULL) {
      yank_initalize_node(init);
      assert(init->outcnt() == 0, "all uses must be deleted");
      _igvn.remove_dead_node(init);
    }
    if (!always_slow) {
       // Remove allocation node and return.
       // Size is a non-negative constant -> no initial check needed -> 
directly to fast path.
       // Also, no usages -> empty fast path -> no fall out to slow path 
-> nothing left.
      yank_alloc_node(alloc);
      return;
    }
  }

Best regards,
Vladimir Ivanov

> 
> 
> Best regards,
> Nils Eliasson
> 
> On 2020-01-24 09:36, Nils Eliasson wrote:
>> Hi,
>>
>> This patch improves expand_allocate_common when there is no use of the 
>> allocation.
>>
>> Three cases are improved:
>>
>> - With unknown allocation length - don't expand the fast path. No 
>> allocation is needed when it isn't used. NegativeArraySizeException 
>> will still be caught by the slowpath.
>> - With known length inside the legal range - No fast path or slow path 
>> is needed. The allocation node is removed.
>> - With known length outside the legal range - only a slow path is needed.
>>
>> I also refactored the code a bit, keeping the general structure for 
>> easy diff, but extracting some routines too make it more readable.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237581
>> Webrev: http://cr.openjdk.java.net/~neliasso/8237581/webrev.03/
>>
>> Please review!
>>
>> Best regards,
>> Nils Eliasson
>>
>>
> 

From ekaterina.pavlova at oracle.com  Wed Jan 29 18:34:20 2020
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Wed, 29 Jan 2020 10:34:20 -0800
Subject: RFR(T/XS): 8236211 [Graal] compiler/graalunit/GraphTest.java is
 skipped in all testing
In-Reply-To: <03BD513C-E719-4994-ACC7-4FF284D273C5@oracle.com>
References: <df5b4600-892f-fecb-cee6-293f90b66682@oracle.com>
 <7eb0c680-08fd-211d-5ee3-ce52cbb468e3@oracle.com>
 <03BD513C-E719-4994-ACC7-4FF284D273C5@oracle.com>
Message-ID: <19402dd4-1e2a-eb38-6b94-91b92b3d219b@oracle.com>

Thanks Igor, pushed.

-katya

On 1/28/20 8:17 PM, Igor Ignatyev wrote:
> LGTM.
> 
> -- Igor
> 
>> On Jan 28, 2020, at 10:33 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
>>
>> Hi,
>>
>> can I please get one review?
>>
>> thanks,
>> -katya
>>
>> On 1/24/20 8:12 AM, Ekaterina Pavlova wrote:
>>> Hi All,
>>> Please review the small patch which adds required --add-opens required for
>>> org.graalvm.compiler.graph tests (compiler/graalunit/GraphTest.java).
>>> Also removed unnecessary "@requires vm.graal.enabled" from compiler/graalunit/NodesTest.java.
>>> Both tests will start running in graal tiers after this fix
>>> (these tests are now skipped because graalunit tests are tested only in non Graal as JIT mode).
>>>        JBS: https://bugs.openjdk.java.net/browse/JDK-8236211
>>>     webrev: http://cr.openjdk.java.net/~epavlova/8236211/webrev.00/index.html
>>>    testing: graal tiers
>>> thanks,
>>> -katya
>>
> 


From igor.ignatyev at oracle.com  Wed Jan 29 19:20:31 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 29 Jan 2020 11:20:31 -0800
Subject: RFR(T) : 8237953 : vmTestbase/jit/tiered/Test.java failure after
 JDK-8237798
Message-ID: <E2BD35A9-E8F2-4812-8823-67B71DD06FE8@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00
> 2 lines changed: 2 ins; 0 del; 0 mod; 


Hi all,

could you please review the small fix for vmTestbase/jit/tiered/Test? "TieredCompilation is disabled" case fails when the test is run w/ a JVMCI compiler b/c TieredCompilation is reenabled. to make test more robust, the patch explicitly sets CompilationMode to "high-only" in -TieredCompilation case and to "default" in +TieredCompilation. the patch depends on 8238049[1-3].

webrev: http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00
JBS: https://bugs.openjdk.java.net/browse/JDK-8237953
testing: vmTestbase/jit/tiered/Test on {linux, windows, macosx}-x64 w/ and w/o JVMCI compiler

[1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036850.html
[2] https://bugs.openjdk.java.net/browse/JDK-8238049
[3] http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/

Thanks,
-- Igor


From vladimir.kozlov at oracle.com  Wed Jan 29 19:23:45 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 29 Jan 2020 11:23:45 -0800
Subject: RFR(T) : 8237953 : vmTestbase/jit/tiered/Test.java failure after
 JDK-8237798
In-Reply-To: <E2BD35A9-E8F2-4812-8823-67B71DD06FE8@oracle.com>
References: <E2BD35A9-E8F2-4812-8823-67B71DD06FE8@oracle.com>
Message-ID: <97704cc4-7a07-5d5b-3c5f-435f82d02ff9@oracle.com>

Good.

Vladimir K

On 1/29/20 11:20 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00
>> 2 lines changed: 2 ins; 0 del; 0 mod;
> 
> 
> Hi all,
> 
> could you please review the small fix for vmTestbase/jit/tiered/Test? "TieredCompilation is disabled" case fails when the test is run w/ a JVMCI compiler b/c TieredCompilation is reenabled. to make test more robust, the patch explicitly sets CompilationMode to "high-only" in -TieredCompilation case and to "default" in +TieredCompilation. the patch depends on 8238049[1-3].
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00
> JBS: https://bugs.openjdk.java.net/browse/JDK-8237953
> testing: vmTestbase/jit/tiered/Test on {linux, windows, macosx}-x64 w/ and w/o JVMCI compiler
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036850.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8238049
> [3] http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
> 
> Thanks,
> -- Igor
> 

From vladimir.kozlov at oracle.com  Wed Jan 29 20:08:27 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 29 Jan 2020 12:08:27 -0800
Subject: RFR(XS): CTW: C2 compilation fails with "malformed control flow"
In-Reply-To: <a7de93f5-76e4-e80d-8746-0d60efb2c77e@oracle.com>
References: <87ftfywt4v.fsf@redhat.com>
 <a7de93f5-76e4-e80d-8746-0d60efb2c77e@oracle.com>
Message-ID: <a2349454-6129-900b-5664-3969d39ea8c5@oracle.com>

+1

Vladimir K

On 1/29/20 5:45 AM, Vladimir Ivanov wrote:
> 
>> http://cr.openjdk.java.net/~roland/8237951/webrev.00/
> 
> Looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
>> CatchNode::Value() makes the fallthrough path of a virtual or interface
>> call dead if the receiver is null. This failure occurs because the
>> fallthrough is erroneously killed during CCP. When CCP is executed, the
>> type of the receiver is first set to top which causes CatchNode::Value()
>> to make the fallthrough path dead then the type of the receiver changes
>> to non null but the CatchNode is not reprocessed by CCP. That happens
>> because:
>>
>> 1758???????? // If we changed the receiver type to a call, we need to revisit
>> 1759???????? // the Catch following the call.? It's looking for a non-NULL
>> 1760???????? // receiver to know when to enable the regular fall-through path
>> 1761???????? // in addition to the NullPtrException path
>> 1762???????? if (m->is_Call()) {
>> 1763?????????? for (DUIterator_Fast i2max, i2 = m->fast_outs(i2max); i2 < i2max; i2++) {
>> 1764???????????? Node* p = m->fast_out(i2);? // Propagate changes to uses
>> 1765???????????? if (p->is_Proj() && p->as_Proj()->_con == TypeFunc::Control && p->outcnt() == 1) {
>> 1766?????????????? worklist.push(p->unique_out());
>>
>> the ProjNode has more than one use: a Load is pinned there. I could
>> write a test case that causes a Load to be pinned on a Proj after a Call
>> but couldn't have the test case trigger the failure (most likely because
>> node processing order during CCP matters). The fix is to enqueue the
>> CatchNode even if p doesn't have a single use.
>>
>> Note: this triggered with Shenandoah but is not specific to Shenandoah.
>>
>> Roland.
>>

From igor.veresov at oracle.com  Wed Jan 29 21:10:38 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 29 Jan 2020 13:10:38 -0800
Subject: RFR(S) : 8238049 : TieredCompilation shouldn't be re-enabled if
 CompilationMode is high-only
In-Reply-To: <9A0AFE73-06BA-447A-B75E-72C4B3DF5238@oracle.com>
References: <9A0AFE73-06BA-447A-B75E-72C4B3DF5238@oracle.com>
Message-ID: <83B1BB7C-C70F-4E71-AA6E-340EA8774416@oracle.com>

Setting CompilationMode actually requires tiered to be on in order to be meaningful. It's a mode of tiered compilation. The ultimate goal is to remove the old compilation policies, so long term, assume that tiered is always on.
It seems to me that the command line you quoted is actually working as intended. Does it cause any problems?


igor



> On Jan 28, 2020, at 2:52 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
>> 9 lines changed: 3 ins; 2 del; 4 mod;
> 
> 
> Hi all,
> 
> could you please review the small and trivial-ish patch?
> from JBS:
>> currently, if you run java w/ -XX:-TieredCompilation -XX:+UseJVMCICompiler, TieredCompilation will be set back to true and change CompilationMode from "default" to "high-only-quick-internal" (w/o actually changing the value of the flag though). if you run it w/ '-XX:-TieredCompilation -XX:+UseJVMCICompile -XX:CompilationMode=high-only', TieredCompilation will be changed to true, but CompilationMode will remain high-only, so effectively it just needlessly enables TieredCompilation.
> 
> the patch not only leaves TieredCompilation disabled when CompilationMode is high-only, but also changes the actual value of CompilationMode flag, so it will be properly reported.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8238049
> webrev: http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
> testing: manual by java -XX:+PrintFlagsFinal w/ {-TieredCompilation,+TieredCompilation}x{CompilationMode=default,CompilationMode=high-only,""}
> 
> Thanks,
> -- Igor


From igor.ignatyev at oracle.com  Wed Jan 29 23:52:48 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 29 Jan 2020 15:52:48 -0800
Subject: RFR(S) : 8238049 : TieredCompilation shouldn't be re-enabled if
 CompilationMode is high-only
Message-ID: <9E743EB8-0D57-43A8-823D-FB6F6C6CEE59@oracle.com>

?

> On Jan 29, 2020, at 1:10 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> Setting CompilationMode actually requires tiered to be on in order to be meaningful. It's a mode of tiered compilation.
I'd not call 'CompilationMode=high-only' a mode of tiered compilation, as there are no tiers and most of machinery of tiered compilation policies is useless.

> The ultimate goal is to remove the old compilation policies, so long term, assume that tiered is always on.
> It seems to me that the command line you quoted is actually working as intended. Does it cause any problems?

in a sense, I was trying to fix 8237953[1,2], where vmTestbase/jit/tiered/Test.java fails w/ graal enabled. the test checks that a tiered only flag has no affect when tiered compilation is disabled, but w/ JVMCI compiler being enabled there is no way to get tiered compilation really disabled, and from end users? perspective, I?d expect tiered not being reenabled when CompilationMode is high-only and the warning message (Turning on tiered compilation and disabling intermediate compilation levels instead) is irrelevant. 


[1] https://bugs.openjdk.java.net/browse/JDK-8237953 <https://bugs.openjdk.java.net/browse/JDK-8237953>
[2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036863.html <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036863.html>

? Igor

> 
> 
> igor
> 
> 
> 
>> On Jan 28, 2020, at 2:52 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
>>> 9 lines changed: 3 ins; 2 del; 4 mod;
>> 
>> 
>> Hi all,
>> 
>> could you please review the small and trivial-ish patch?
>> from JBS:
>>> currently, if you run java w/ -XX:-TieredCompilation -XX:+UseJVMCICompiler, TieredCompilation will be set back to true and change CompilationMode from "default" to "high-only-quick-internal" (w/o actually changing the value of the flag though). if you run it w/ '-XX:-TieredCompilation -XX:+UseJVMCICompile -XX:CompilationMode=high-only', TieredCompilation will be changed to true, but CompilationMode will remain high-only, so effectively it just needlessly enables TieredCompilation.
>> 
>> the patch not only leaves TieredCompilation disabled when CompilationMode is high-only, but also changes the actual value of CompilationMode flag, so it will be properly reported.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238049
>> webrev: http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
>> testing: manual by java -XX:+PrintFlagsFinal w/ {-TieredCompilation,+TieredCompilation}x{CompilationMode=default,CompilationMode=high-only,""}
>> 
>> Thanks,
>> -- Igor
> 


From igor.ignatyev at oracle.com  Thu Jan 30 00:49:13 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 29 Jan 2020 16:49:13 -0800
Subject: RFR(S) : 8237787 : rewrite vmTestbase/vm/compiler/CodeCacheInfo*
 from shell to java
In-Reply-To: <686A9255-BF7A-4956-BFD4-C969203347C6@oracle.com>
References: <8AB60BC1-0228-43FA-9D44-3E1DDAF8A129@oracle.com>
 <4d1d2e33-019d-36ed-9fed-b4bc177d59bc@oracle.com>
 <4F60F060-7848-4050-A47F-C97590ECBFF4@oracle.com>
 <9079dc9a-65d4-92fd-513f-19f87bfc6404@oracle.com>
 <686A9255-BF7A-4956-BFD4-C969203347C6@oracle.com>
Message-ID: <092B7A89-3DBF-4052-A1F2-C4C03DF72A02@oracle.com>

> @list
> can I get a 2nd Review?
ping?

-- Igor

> On Jan 27, 2020, at 3:39 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> @Katya,
> 
> thank you!
> 
> @list
> can I get a 2nd Review?
> 
> -- Igor
> 
>> On Jan 24, 2020, at 3:26 PM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
>> 
>> Seems to be good now.
>> 
>> thanks,
>> -katya
>> 
>> On 1/24/20 3:06 PM, Igor Ignatyev wrote:
>>> no, you are right. it seems I uploaded not the latest version of my patch. fixed and uploaded .01 which has -Xcomp -- http://cr.openjdk.java.net/~iignatyev//8237787/webrev.01
>>> -- Igor
>>>> On Jan 24, 2020, at 8:18 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com <mailto:ekaterina.pavlova at oracle.com>> wrote:
>>>> 
>>>> On 1/23/20 2:21 PM, Igor Ignatyev wrote:
>>>>> http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>>>>> 177 lines changed: 56 ins; 117 del; 4 mod; 7
>>>>> Hi all,
>>>>> could you please review the patch which rewrites vmTestbase/vm/compiler/CodeCacheInfo and CodeCacheInfoOnCompilation tests from shell to java?
>>>>> the only difference b/w java and shell versions are:
>>>>> - instead of skipping execution if there isn't -Xcomp, CodeCacheInfoOnCompilation adds -Xcomp to command line
>>>> 
>>>> Igor, I don't see -Xcomp is added. Am I missing something?
>>>> 
>>>>> - instead of checking the value of SegmentedCodeCache flag, CodeCacheInfo runs two cases w/ +SegmentedCodeCache and w/ -SegmentedCodeCache
>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237787
>>>>> testing: the changed tests on linux-x64, windows-x64, and macosx-x64
>>>>> Thanks,
>>>>> -- Igor
>>>> 
>> 
> 


From vladimir.kozlov at oracle.com  Thu Jan 30 02:08:41 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 29 Jan 2020 18:08:41 -0800
Subject: RFR(S) : 8237787 : rewrite vmTestbase/vm/compiler/CodeCacheInfo*
 from shell to java
In-Reply-To: <092B7A89-3DBF-4052-A1F2-C4C03DF72A02@oracle.com>
References: <8AB60BC1-0228-43FA-9D44-3E1DDAF8A129@oracle.com>
 <4d1d2e33-019d-36ed-9fed-b4bc177d59bc@oracle.com>
 <4F60F060-7848-4050-A47F-C97590ECBFF4@oracle.com>
 <9079dc9a-65d4-92fd-513f-19f87bfc6404@oracle.com>
 <686A9255-BF7A-4956-BFD4-C969203347C6@oracle.com>
 <092B7A89-3DBF-4052-A1F2-C4C03DF72A02@oracle.com>
Message-ID: <9a9609e7-dd4a-16ed-73c5-29cbfa373f27@oracle.com>

Seems good.

Thanks,
Vladimir

On 1/29/20 4:49 PM, Igor Ignatyev wrote:
>> @list
>> can I get a 2nd Review?
> ping?
> 
> -- Igor
> 
>> On Jan 27, 2020, at 3:39 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>> @Katya,
>>
>> thank you!
>>
>> @list
>> can I get a 2nd Review?
>>
>> -- Igor
>>
>>> On Jan 24, 2020, at 3:26 PM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
>>>
>>> Seems to be good now.
>>>
>>> thanks,
>>> -katya
>>>
>>> On 1/24/20 3:06 PM, Igor Ignatyev wrote:
>>>> no, you are right. it seems I uploaded not the latest version of my patch. fixed and uploaded .01 which has -Xcomp -- http://cr.openjdk.java.net/~iignatyev//8237787/webrev.01
>>>> -- Igor
>>>>> On Jan 24, 2020, at 8:18 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com <mailto:ekaterina.pavlova at oracle.com>> wrote:
>>>>>
>>>>> On 1/23/20 2:21 PM, Igor Ignatyev wrote:
>>>>>> http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>>>>>> 177 lines changed: 56 ins; 117 del; 4 mod; 7
>>>>>> Hi all,
>>>>>> could you please review the patch which rewrites vmTestbase/vm/compiler/CodeCacheInfo and CodeCacheInfoOnCompilation tests from shell to java?
>>>>>> the only difference b/w java and shell versions are:
>>>>>> - instead of skipping execution if there isn't -Xcomp, CodeCacheInfoOnCompilation adds -Xcomp to command line
>>>>>
>>>>> Igor, I don't see -Xcomp is added. Am I missing something?
>>>>>
>>>>>> - instead of checking the value of SegmentedCodeCache flag, CodeCacheInfo runs two cases w/ +SegmentedCodeCache and w/ -SegmentedCodeCache
>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237787
>>>>>> testing: the changed tests on linux-x64, windows-x64, and macosx-x64
>>>>>> Thanks,
>>>>>> -- Igor
>>>>>
>>>
>>
> 

From igor.veresov at oracle.com  Thu Jan 30 02:09:56 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 29 Jan 2020 18:09:56 -0800
Subject: RFR(S) : 8238049 : TieredCompilation shouldn't be re-enabled if
 CompilationMode is high-only
In-Reply-To: <9E743EB8-0D57-43A8-823D-FB6F6C6CEE59@oracle.com>
References: <9E743EB8-0D57-43A8-823D-FB6F6C6CEE59@oracle.com>
Message-ID: <45C68B44-85E3-42E7-8352-F2EFE612434E@oracle.com>

No, that?s not the case. -XX:CompilationMode=high-only switches on a mode within the tiered policy that tries to mimic ?-XX:-TieredCompilation?.
So that instead of turning tiered off we can just use -XX:CompilationMode=high-only.  It actually has some tiers, since it supports AOT. 

Long term goal is to deprecate the non-tiered policy. When that happens -XX:-TieredCompilation will just imply -XX:CompilationMode=high-only and there will be just one compilation policy (tiered). So, in preparation to this (especially with new tests) we should probably start using -XX:CompilationMode=high-only instead of -XX:-TieredCompilation.


igor



> On Jan 29, 2020, at 3:52 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> ?
> 
>> On Jan 29, 2020, at 1:10 PM, Igor Veresov <igor.veresov at oracle.com <mailto:igor.veresov at oracle.com>> wrote:
>> 
>> Setting CompilationMode actually requires tiered to be on in order to be meaningful. It's a mode of tiered compilation.
> I'd not call 'CompilationMode=high-only' a mode of tiered compilation, as there are no tiers and most of machinery of tiered compilation policies is useless.
> 
>> The ultimate goal is to remove the old compilation policies, so long term, assume that tiered is always on.
>> It seems to me that the command line you quoted is actually working as intended. Does it cause any problems?
> 
> in a sense, I was trying to fix 8237953[1,2], where vmTestbase/jit/tiered/Test.java fails w/ graal enabled. the test checks that a tiered only flag has no affect when tiered compilation is disabled, but w/ JVMCI compiler being enabled there is no way to get tiered compilation really disabled, and from end users? perspective, I?d expect tiered not being reenabled when CompilationMode is high-only and the warning message (Turning on tiered compilation and disabling intermediate compilation levels instead) is irrelevant. 
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8237953 <https://bugs.openjdk.java.net/browse/JDK-8237953>
> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036863.html <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036863.html>
> 
> ? Igor
> 
>> 
>> 
>> igor
>> 
>> 
>> 
>>> On Jan 28, 2020, at 2:52 PM, Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>>> 
>>> http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/ <http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/>
>>>> 9 lines changed: 3 ins; 2 del; 4 mod;
>>> 
>>> 
>>> Hi all,
>>> 
>>> could you please review the small and trivial-ish patch?
>>> from JBS:
>>>> currently, if you run java w/ -XX:-TieredCompilation -XX:+UseJVMCICompiler, TieredCompilation will be set back to true and change CompilationMode from "default" to "high-only-quick-internal" (w/o actually changing the value of the flag though). if you run it w/ '-XX:-TieredCompilation -XX:+UseJVMCICompile -XX:CompilationMode=high-only', TieredCompilation will be changed to true, but CompilationMode will remain high-only, so effectively it just needlessly enables TieredCompilation.
>>> 
>>> the patch not only leaves TieredCompilation disabled when CompilationMode is high-only, but also changes the actual value of CompilationMode flag, so it will be properly reported.
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238049
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
>>> testing: manual by java -XX:+PrintFlagsFinal w/ {-TieredCompilation,+TieredCompilation}x{CompilationMode=default,CompilationMode=high-only,""}
>>> 
>>> Thanks,
>>> -- Igor
>> 
> 


From igor.ignatyev at oracle.com  Thu Jan 30 03:45:01 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 29 Jan 2020 19:45:01 -0800
Subject: RFR(S) : 8238049 : TieredCompilation shouldn't be re-enabled if
 CompilationMode is high-only
In-Reply-To: <45C68B44-85E3-42E7-8352-F2EFE612434E@oracle.com>
References: <9E743EB8-0D57-43A8-823D-FB6F6C6CEE59@oracle.com>
 <45C68B44-85E3-42E7-8352-F2EFE612434E@oracle.com>
Message-ID: <708A2C05-CB46-4401-BCBA-14D98AC0DCAB@oracle.com>

ok... then I'm withdrawing this RFR, closing 8238049 as NAI and will fix 8237953 differently.

-- Igor

> On Jan 29, 2020, at 6:09 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> No, that?s not the case. -XX:CompilationMode=high-only switches on a mode within the tiered policy that tries to mimic ?-XX:-TieredCompilation?.
> So that instead of turning tiered off we can just use -XX:CompilationMode=high-only.  It actually has some tiers, since it supports AOT. 
> 
> Long term goal is to deprecate the non-tiered policy. When that happens -XX:-TieredCompilation will just imply -XX:CompilationMode=high-only and there will be just one compilation policy (tiered). So, in preparation to this (especially with new tests) we should probably start using -XX:CompilationMode=high-only instead of -XX:-TieredCompilation.
> 
> 
> igor
> 
> 
> 
>> On Jan 29, 2020, at 3:52 PM, Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>> 
>> ?
>> 
>>> On Jan 29, 2020, at 1:10 PM, Igor Veresov <igor.veresov at oracle.com <mailto:igor.veresov at oracle.com>> wrote:
>>> 
>>> Setting CompilationMode actually requires tiered to be on in order to be meaningful. It's a mode of tiered compilation. 
>> I'd not call 'CompilationMode=high-only' a mode of tiered compilation, as there are no tiers and most of machinery of tiered compilation policies is useless.
>> 
>>> The ultimate goal is to remove the old compilation policies, so long term, assume that tiered is always on.
>>> It seems to me that the command line you quoted is actually working as intended. Does it cause any problems?
>> 
>> in a sense, I was trying to fix 8237953[1,2], where vmTestbase/jit/tiered/Test.java fails w/ graal enabled. the test checks that a tiered only flag has no affect when tiered compilation is disabled, but w/ JVMCI compiler being enabled there is no way to get tiered compilation really disabled, and from end users? perspective, I?d expect tiered not being reenabled when CompilationMode is high-only and the warning message (Turning on tiered compilation and disabling intermediate compilation levels instead) is irrelevant. 
>> 
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8237953 <https://bugs.openjdk.java.net/browse/JDK-8237953>
>> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036863.html <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036863.html>
>> 
>> ? Igor
>> 
>>> 
>>> 
>>> igor
>>> 
>>> 
>>> 
>>>> On Jan 28, 2020, at 2:52 PM, Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>>>> 
>>>> http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/ <http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/>
>>>>> 9 lines changed: 3 ins; 2 del; 4 mod;
>>>> 
>>>> 
>>>> Hi all,
>>>> 
>>>> could you please review the small and trivial-ish patch?
>>>> from JBS:
>>>>> currently, if you run java w/ -XX:-TieredCompilation -XX:+UseJVMCICompiler, TieredCompilation will be set back to true and change CompilationMode from "default" to "high-only-quick-internal" (w/o actually changing the value of the flag though). if you run it w/ '-XX:-TieredCompilation -XX:+UseJVMCICompile -XX:CompilationMode=high-only', TieredCompilation will be changed to true, but CompilationMode will remain high-only, so effectively it just needlessly enables TieredCompilation.
>>>> 
>>>> the patch not only leaves TieredCompilation disabled when CompilationMode is high-only, but also changes the actual value of CompilationMode flag, so it will be properly reported.
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238049 <https://bugs.openjdk.java.net/browse/JDK-8238049>
>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/ <http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/>
>>>> testing: manual by java -XX:+PrintFlagsFinal w/ {-TieredCompilation,+TieredCompilation}x{CompilationMode=default,CompilationMode=high-only,""}
>>>> 
>>>> Thanks,
>>>> -- Igor


From igor.ignatyev at oracle.com  Thu Jan 30 04:03:37 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 29 Jan 2020 20:03:37 -0800
Subject: RFR(T) : 8237953 : vmTestbase/jit/tiered/Test.java failure after
 JDK-8237798
In-Reply-To: <97704cc4-7a07-5d5b-3c5f-435f82d02ff9@oracle.com>
References: <E2BD35A9-E8F2-4812-8823-67B71DD06FE8@oracle.com>
 <97704cc4-7a07-5d5b-3c5f-435f82d02ff9@oracle.com>
Message-ID: <CE520B9E-8664-425E-A080-1683F2D890C8@oracle.com>

as 8238049 got withdrawn, this is to be solved differently. http://cr.openjdk.java.net/~iignatyev//8237953/webrev.01 <http://cr.openjdk.java.net/~iignatyev//8237953/webrev.01> adds @requires to exclude the test from execution when JVMCI compiler is enabled.

-- Igor

> On Jan 29, 2020, at 11:23 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Good.
> 
> Vladimir K
> 
> On 1/29/20 11:20 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00
>>> 2 lines changed: 2 ins; 0 del; 0 mod;
>> Hi all,
>> could you please review the small fix for vmTestbase/jit/tiered/Test? "TieredCompilation is disabled" case fails when the test is run w/ a JVMCI compiler b/c TieredCompilation is reenabled. to make test more robust, the patch explicitly sets CompilationMode to "high-only" in -TieredCompilation case and to "default" in +TieredCompilation. the patch depends on 8238049[1-3].
>> webrev: http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237953
>> testing: vmTestbase/jit/tiered/Test on {linux, windows, macosx}-x64 w/ and w/o JVMCI compiler
>> [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036850.html
>> [2] https://bugs.openjdk.java.net/browse/JDK-8238049
>> [3] http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
>> Thanks,
>> -- Igor


From igor.ignatyev at oracle.com  Thu Jan 30 04:27:44 2020
From: igor.ignatyev at oracle.com (Igor Ignatev)
Date: Wed, 29 Jan 2020 20:27:44 -0800
Subject: RFR(S) : 8237787 : rewrite vmTestbase/vm/compiler/CodeCacheInfo*
 from shell to java
In-Reply-To: <9a9609e7-dd4a-16ed-73c5-29cbfa373f27@oracle.com>
References: <9a9609e7-dd4a-16ed-73c5-29cbfa373f27@oracle.com>
Message-ID: <A6E765BC-F83B-483A-9C60-A1E946933BF5@oracle.com>

Thanks Vladimir, pushed. 

? Igor

> On Jan 29, 2020, at 6:07 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> ?Seems good.
> 
> Thanks,
> Vladimir
> 
> On 1/29/20 4:49 PM, Igor Ignatyev wrote:
>>> @list
>>> can I get a 2nd Review?
>> ping?
>> -- Igor
>>>> On Jan 27, 2020, at 3:39 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>> 
>>> @Katya,
>>> 
>>> thank you!
>>> 
>>> @list
>>> can I get a 2nd Review?
>>> 
>>> -- Igor
>>> 
>>>> On Jan 24, 2020, at 3:26 PM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
>>>> 
>>>> Seems to be good now.
>>>> 
>>>> thanks,
>>>> -katya
>>>> 
>>>> On 1/24/20 3:06 PM, Igor Ignatyev wrote:
>>>>> no, you are right. it seems I uploaded not the latest version of my patch. fixed and uploaded .01 which has -Xcomp -- http://cr.openjdk.java.net/~iignatyev//8237787/webrev.01
>>>>> -- Igor
>>>>>> On Jan 24, 2020, at 8:18 AM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com <mailto:ekaterina.pavlova at oracle.com>> wrote:
>>>>>> 
>>>>>> On 1/23/20 2:21 PM, Igor Ignatyev wrote:
>>>>>>> http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>>>>>>> 177 lines changed: 56 ins; 117 del; 4 mod; 7
>>>>>>> Hi all,
>>>>>>> could you please review the patch which rewrites vmTestbase/vm/compiler/CodeCacheInfo and CodeCacheInfoOnCompilation tests from shell to java?
>>>>>>> the only difference b/w java and shell versions are:
>>>>>>> - instead of skipping execution if there isn't -Xcomp, CodeCacheInfoOnCompilation adds -Xcomp to command line
>>>>>> 
>>>>>> Igor, I don't see -Xcomp is added. Am I missing something?
>>>>>> 
>>>>>>> - instead of checking the value of SegmentedCodeCache flag, CodeCacheInfo runs two cases w/ +SegmentedCodeCache and w/ -SegmentedCodeCache
>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8237787/webrev.00
>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237787
>>>>>>> testing: the changed tests on linux-x64, windows-x64, and macosx-x64
>>>>>>> Thanks,
>>>>>>> -- Igor
>>>>>> 
>>>> 
>>> 


From nils.eliasson at oracle.com  Thu Jan 30 10:41:25 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 30 Jan 2020 11:41:25 +0100
Subject: [15] RFR(S): 8235332: TestInstanceCloneAsLoadsStores.java fails
 with -XX:+StressGCM
In-Reply-To: <d2189e04-b4e1-a502-910a-cf14b466fb01@oracle.com>
References: <2ef5e2fd-d73c-5e1f-e50f-8ea36cd24029@oracle.com>
 <87zheqyuj2.fsf@redhat.com> <3f4d0542-5d72-dca4-d14d-7a13402fbf1c@oracle.com>
 <87eew1yqum.fsf@redhat.com> <d2189e04-b4e1-a502-910a-cf14b466fb01@oracle.com>
Message-ID: <6c85c632-350a-2136-8782-b30c6ca20fcb@oracle.com>

Hi Christian,

Change looks good,

Thanks for fixing!

// Nils

On 2020-01-15 12:02, Christian Hagedorn wrote:
>>>> If there's no GC barrier then:
>>>>
>>>> Node* control_proj_ac = bs->step_over_gc_barrier(proj_in->in(0));
>>>>
>>>> control_proj_ac is not a projection, it's proj_in->in(0) so the test
>>>> below can never succeed?
>>>
>>> If there is no GC barrier, then proj_in is a membar with its control
>>> input being a control projection from the ArrayCopyNode.
>>>
>>> As an example, I have taken the test case TestEliminatedCloneBadMemEdge
>>> [1] which does not disable ReduceInitialCardMarks and has no GC 
>>> barrier.
>>> We have the following situation at [2]:
>>>
>>> proj_in is 132 MemBarCPUOrder. The original code then looked at the
>>> MergeMem 100 input following in(Compile::AliasIdxRaw) which is 101 Proj
>>> and its input 98 ArrayCopy. This passes the check.
>>>
>>> My fix now directly looks at the control input of 132 MemBarCPUOrder
>>> which is the projection 99 Proj coming from the 98 ArrayCopy. This also
>>> passes the check.
>>
>> Ah! Right. I wonder if there's a reason why the current code follows the
>> control graph (as you do) instead of the memory graph. I couldn't find
>> one and your change looks good to me.
>
> Thank you for your review Roland! Was wondering about that, too.
>
> Best regards,
> Christian


From christian.hagedorn at oracle.com  Thu Jan 30 12:55:44 2020
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Thu, 30 Jan 2020 13:55:44 +0100
Subject: [15] RFR(S): 8235332: TestInstanceCloneAsLoadsStores.java fails
 with -XX:+StressGCM
In-Reply-To: <6c85c632-350a-2136-8782-b30c6ca20fcb@oracle.com>
References: <2ef5e2fd-d73c-5e1f-e50f-8ea36cd24029@oracle.com>
 <87zheqyuj2.fsf@redhat.com> <3f4d0542-5d72-dca4-d14d-7a13402fbf1c@oracle.com>
 <87eew1yqum.fsf@redhat.com> <d2189e04-b4e1-a502-910a-cf14b466fb01@oracle.com>
 <6c85c632-350a-2136-8782-b30c6ca20fcb@oracle.com>
Message-ID: <5462f46b-4d5f-85ee-2ae8-45f8fdef9981@oracle.com>

Hi Nils

Thank you for the review!

Best regards,
Christian

On 30.01.20 11:41, Nils Eliasson wrote:
> Hi Christian,
> 
> Change looks good,
> 
> Thanks for fixing!
> 
> // Nils
> 
> On 2020-01-15 12:02, Christian Hagedorn wrote:
>>>>> If there's no GC barrier then:
>>>>>
>>>>> Node* control_proj_ac = bs->step_over_gc_barrier(proj_in->in(0));
>>>>>
>>>>> control_proj_ac is not a projection, it's proj_in->in(0) so the test
>>>>> below can never succeed?
>>>>
>>>> If there is no GC barrier, then proj_in is a membar with its control
>>>> input being a control projection from the ArrayCopyNode.
>>>>
>>>> As an example, I have taken the test case TestEliminatedCloneBadMemEdge
>>>> [1] which does not disable ReduceInitialCardMarks and has no GC 
>>>> barrier.
>>>> We have the following situation at [2]:
>>>>
>>>> proj_in is 132 MemBarCPUOrder. The original code then looked at the
>>>> MergeMem 100 input following in(Compile::AliasIdxRaw) which is 101 Proj
>>>> and its input 98 ArrayCopy. This passes the check.
>>>>
>>>> My fix now directly looks at the control input of 132 MemBarCPUOrder
>>>> which is the projection 99 Proj coming from the 98 ArrayCopy. This also
>>>> passes the check.
>>>
>>> Ah! Right. I wonder if there's a reason why the current code follows the
>>> control graph (as you do) instead of the memory graph. I couldn't find
>>> one and your change looks good to me.
>>
>> Thank you for your review Roland! Was wondering about that, too.
>>
>> Best regards,
>> Christian
> 

From igor.veresov at oracle.com  Thu Jan 30 14:44:46 2020
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 30 Jan 2020 06:44:46 -0800
Subject: RFR(T) : 8237953 : vmTestbase/jit/tiered/Test.java failure after
 JDK-8237798
In-Reply-To: <CE520B9E-8664-425E-A080-1683F2D890C8@oracle.com>
References: <E2BD35A9-E8F2-4812-8823-67B71DD06FE8@oracle.com>
 <97704cc4-7a07-5d5b-3c5f-435f82d02ff9@oracle.com>
 <CE520B9E-8664-425E-A080-1683F2D890C8@oracle.com>
Message-ID: <80190DFD-BE7A-4C5A-885B-CBEEB8D39EBE@oracle.com>

Looks good.

igor



> On Jan 29, 2020, at 8:03 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> as 8238049 got withdrawn, this is to be solved differently. http://cr.openjdk.java.net/~iignatyev//8237953/webrev.01 <http://cr.openjdk.java.net/~iignatyev//8237953/webrev.01> adds @requires to exclude the test from execution when JVMCI compiler is enabled.
> 
> -- Igor
> 
>> On Jan 29, 2020, at 11:23 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>> Good.
>> 
>> Vladimir K
>> 
>> On 1/29/20 11:20 AM, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00
>>>> 2 lines changed: 2 ins; 0 del; 0 mod;
>>> Hi all,
>>> could you please review the small fix for vmTestbase/jit/tiered/Test? "TieredCompilation is disabled" case fails when the test is run w/ a JVMCI compiler b/c TieredCompilation is reenabled. to make test more robust, the patch explicitly sets CompilationMode to "high-only" in -TieredCompilation case and to "default" in +TieredCompilation. the patch depends on 8238049[1-3].
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237953
>>> testing: vmTestbase/jit/tiered/Test on {linux, windows, macosx}-x64 w/ and w/o JVMCI compiler
>>> [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036850.html
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8238049
>>> [3] http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
>>> Thanks,
>>> -- Igor
> 


From nils.eliasson at oracle.com  Thu Jan 30 15:19:14 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 30 Jan 2020 16:19:14 +0100
Subject: [15] RFR (M): 8237581: Improve allocation expansion
In-Reply-To: <b2bdf17b-ad2f-9072-dafa-cbea5f1fd731@oracle.com>
References: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>
 <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>
 <b2bdf17b-ad2f-9072-dafa-cbea5f1fd731@oracle.com>
Message-ID: <31615df3-3f1d-9a5e-3308-37e652590b80@oracle.com>

Hi Vladimir,

Thanks for having a look.

On 2020-01-29 19:18, Vladimir Ivanov wrote:
> Thanks for separating the fix from the refactoring.
>
>> Refactoring:
>>
>> http://cr.openjdk.java.net/~neliasso/8237581/webrev.refactor/
>
> Looks good.
>
>> The actual change (on top of the refactoring)
>>
>> http://cr.openjdk.java.net/~neliasso/8237581/webrev.change/
>
> Overall, looks good.
>
> I'd prefer to see yank_alloc_node(alloc) case separated.
>
> What do you think about the following?
>
> ?if (!allocation_has_use) {
> ?? InitializeNode* init = alloc->initialization();
> ?? if (init != NULL) {
> ???? yank_initalize_node(init);
> ???? assert(init->outcnt() == 0, "all uses must be deleted");
> ???? _igvn.remove_dead_node(init);
> ?? }
> ?? if (!always_slow) {
> ????? // Remove allocation node and return.
> ????? // Size is a non-negative constant -> no initial check needed -> 
> directly to fast path.
> ????? // Also, no usages -> empty fast path -> no fall out to slow 
> path -> nothing left.
> ???? yank_alloc_node(alloc);
> ???? return;
> ?? }
> ?}

Good, but not complete. The "if (!always_slow) {" line also needs to 
check if 'initial_slow_test == NULL' (Meaning: We need no initial check, 
because we know the allocation size is positive and will fit in the 
TLAB, so we can go directly to the fast path), which is computed further 
down, so I moved the block down.

Also, with the risk of complicating things - I changed '!always_slow' to 
'expand_fast_path' because that conveys the meaning better.

http://cr.openjdk.java.net/~neliasso/8237581/webrev.change.2/

Best regards,
Nils Eliasson

>
> Best regards,
> Vladimir Ivanov
>
>>
>>
>> Best regards,
>> Nils Eliasson
>>
>> On 2020-01-24 09:36, Nils Eliasson wrote:
>>> Hi,
>>>
>>> This patch improves expand_allocate_common when there is no use of 
>>> the allocation.
>>>
>>> Three cases are improved:
>>>
>>> - With unknown allocation length - don't expand the fast path. No 
>>> allocation is needed when it isn't used. NegativeArraySizeException 
>>> will still be caught by the slowpath.
>>> - With known length inside the legal range - No fast path or slow 
>>> path is needed. The allocation node is removed.
>>> - With known length outside the legal range - only a slow path is 
>>> needed.
>>>
>>> I also refactored the code a bit, keeping the general structure for 
>>> easy diff, but extracting some routines too make it more readable.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237581
>>> Webrev: http://cr.openjdk.java.net/~neliasso/8237581/webrev.03/
>>>
>>> Please review!
>>>
>>> Best regards,
>>> Nils Eliasson
>>>
>>>
>>


From vladimir.x.ivanov at oracle.com  Thu Jan 30 15:55:17 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 30 Jan 2020 18:55:17 +0300
Subject: [15] RFR (M): 8237581: Improve allocation expansion
In-Reply-To: <31615df3-3f1d-9a5e-3308-37e652590b80@oracle.com>
References: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>
 <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>
 <b2bdf17b-ad2f-9072-dafa-cbea5f1fd731@oracle.com>
 <31615df3-3f1d-9a5e-3308-37e652590b80@oracle.com>
Message-ID: <720ac716-80d6-fb4f-a95e-8dd8a4aae7e6@oracle.com>


> Good, but not complete. The "if (!always_slow) {" line also needs to 
> check if 'initial_slow_test == NULL' (Meaning: We need no initial check, 
> because we know the allocation size is positive and will fit in the 
> TLAB, so we can go directly to the fast path), which is computed further 
> down, so I moved the block down.

Looks good.

> Also, with the risk of complicating things - I changed '!always_slow' to 
> 'expand_fast_path' because that conveys the meaning better.

Not sure it improves readability, but I'm fine with it.

> http://cr.openjdk.java.net/~neliasso/8237581/webrev.change.2/

Looks good.

PS: made slight modifications to the comment:

       // Remove allocation node and return.
       // Size is a non-negative constant -> no initial check needed -> 
directly to fast path.
       // Also, no usages -> empty fast path -> no fall out to slow path 
-> nothing left.

Best regards,
Vladimir Ivanov

>>> On 2020-01-24 09:36, Nils Eliasson wrote:
>>>> Hi,
>>>>
>>>> This patch improves expand_allocate_common when there is no use of 
>>>> the allocation.
>>>>
>>>> Three cases are improved:
>>>>
>>>> - With unknown allocation length - don't expand the fast path. No 
>>>> allocation is needed when it isn't used. NegativeArraySizeException 
>>>> will still be caught by the slowpath.
>>>> - With known length inside the legal range - No fast path or slow 
>>>> path is needed. The allocation node is removed.
>>>> - With known length outside the legal range - only a slow path is 
>>>> needed.
>>>>
>>>> I also refactored the code a bit, keeping the general structure for 
>>>> easy diff, but extracting some routines too make it more readable.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237581
>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8237581/webrev.03/
>>>>
>>>> Please review!
>>>>
>>>> Best regards,
>>>> Nils Eliasson
>>>>
>>>>
>>>
> 

From vladimir.x.ivanov at oracle.com  Thu Jan 30 16:55:25 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 30 Jan 2020 19:55:25 +0300
Subject: VM_EnterInterpOnlyMode: why make compiled methods on stack
 not_entrant?
In-Reply-To: <AM0PR0202MB3331C331B51D301C8AEB482D9B0A0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3331C331B51D301C8AEB482D9B0A0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
Message-ID: <7dd97d12-dc9f-99cc-384a-4d1ccfe516dd@oracle.com>

Hi Richard,

> I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack not_entrant. To me this
> seems unnecessary. I think it would be sufficient to patch the return pc of compiled frames and
> let them return to their deopt handler. Or what would be the reason to make the compiled methods
> not_entrant?
> 
> VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native methods get
> marked.
> 
> Deoptimization::deoptimize_all_marked(): all marked methods are made not_entrant.
> 
> Maybe this is for historical reasons? If I remember correctly, many years ago, deoptimizing a
> compiled frame used to require making the corresponding nmethod not_entrant. And making a nmethod
> not_entrant meant overriding its code with a slide of nops that led to the deopt handler.
> 
> I'd like to change this and just apply Deoptimization::deoptimize() on every compiled frame on
> stack. I've done this locally and tested the change without issues.

I'm not a JVMTI expert, but considering VM_EnterInterpOnlyMode is 
performed on per-thread basis [1], it looks like per-frame 
deoptimization (instead of per-nmethod) should be enough to do the job.

So, from JIT-compiler perspective, your suggestion to use 
Deoptimization::deoptimize() instead of 
CompiledMethod::mark_for_deoptimization()/Deoptimization::deoptimize_all_marked() 
sounds good.

PS: also, it looks like handshakes become a perfect fit for 
VM_EnterInterpOnlyMode: once you don't need to deoptimize on per-nmethod 
basis, there's no need to trigger global safepoint.

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/prims/jvmtiEventController.cpp#l227

     // If running in fullspeed mode, single stepping is implemented
     // as follows: first, the interpreter does not dispatch to
     // compiled code for threads that have single stepping enabled;
     // second, we deoptimize all methods on the thread's stack when
     // interpreted-only mode is enabled the first time for a given
     // thread (nothing to do if no Java frames yet).

From igor.ignatyev at oracle.com  Thu Jan 30 16:59:02 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 30 Jan 2020 08:59:02 -0800
Subject: RFR(T) : 8237953 : vmTestbase/jit/tiered/Test.java failure after
 JDK-8237798
In-Reply-To: <80190DFD-BE7A-4C5A-885B-CBEEB8D39EBE@oracle.com>
References: <E2BD35A9-E8F2-4812-8823-67B71DD06FE8@oracle.com>
 <97704cc4-7a07-5d5b-3c5f-435f82d02ff9@oracle.com>
 <CE520B9E-8664-425E-A080-1683F2D890C8@oracle.com>
 <80190DFD-BE7A-4C5A-885B-CBEEB8D39EBE@oracle.com>
Message-ID: <CEF11F3D-7E1E-4220-9308-A863BF308002@oracle.com>

thanks Igor, pushed.
-- Igor

> On Jan 30, 2020, at 6:44 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> Looks good.
> 
> igor
> 
> 
> 
>> On Jan 29, 2020, at 8:03 PM, Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>> 
>> as 8238049 got withdrawn, this is to be solved differently. http://cr.openjdk.java.net/~iignatyev//8237953/webrev.01 <http://cr.openjdk.java.net/~iignatyev//8237953/webrev.01> <http://cr.openjdk.java.net/~iignatyev//8237953/webrev.01 <http://cr.openjdk.java.net/~iignatyev//8237953/webrev.01>> adds @requires to exclude the test from execution when JVMCI compiler is enabled.
>> 
>> -- Igor
>> 
>>> On Jan 29, 2020, at 11:23 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>> 
>>> Good.
>>> 
>>> Vladimir K
>>> 
>>> On 1/29/20 11:20 AM, Igor Ignatyev wrote:
>>>> http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00 <http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00>
>>>>> 2 lines changed: 2 ins; 0 del; 0 mod;
>>>> Hi all,
>>>> could you please review the small fix for vmTestbase/jit/tiered/Test? "TieredCompilation is disabled" case fails when the test is run w/ a JVMCI compiler b/c TieredCompilation is reenabled. to make test more robust, the patch explicitly sets CompilationMode to "high-only" in -TieredCompilation case and to "default" in +TieredCompilation. the patch depends on 8238049[1-3].
>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8237953/webrev.00
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237953
>>>> testing: vmTestbase/jit/tiered/Test on {linux, windows, macosx}-x64 w/ and w/o JVMCI compiler
>>>> [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-January/036850.html
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8238049
>>>> [3] http://cr.openjdk.java.net/~iignatyev/8238049/webrev.00/
>>>> Thanks,
>>>> -- Igor
>> 
> 


From david.leopoldseder at oracle.com  Fri Jan 31 08:49:09 2020
From: david.leopoldseder at oracle.com (David Leopoldseder)
Date: Fri, 31 Jan 2020 09:49:09 +0100
Subject: RFR: 8238190 : [JVMCI] Fix single implementor speculation for diamond
 shapes.
Message-ID: <ab1343c2-c5d9-f166-d10c-24a4afbe96c3@oracle.com>

Hi,

Please review this tiny change (+ a new test case exercising the pattern) to
fix the single implementor logic in instanceKlass for diamond shaped 
class hierarchies.

This bug was revealed in Graal where we use the single implementor logic 
for invokeinterface devirtualization.

https://bugs.openjdk.java.net/browse/JDK-8238190
http://cr.openjdk.java.net/~davleopo/JDK-8238190/webrev.001/

Thank you.

- david


From nils.eliasson at oracle.com  Fri Jan 31 14:30:25 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 31 Jan 2020 15:30:25 +0100
Subject: [15] RFR (M): 8237581: Improve allocation expansion
In-Reply-To: <720ac716-80d6-fb4f-a95e-8dd8a4aae7e6@oracle.com>
References: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>
 <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>
 <b2bdf17b-ad2f-9072-dafa-cbea5f1fd731@oracle.com>
 <31615df3-3f1d-9a5e-3308-37e652590b80@oracle.com>
 <720ac716-80d6-fb4f-a95e-8dd8a4aae7e6@oracle.com>
Message-ID: <565e2cfb-e027-39f9-0553-6e19135d4fb4@oracle.com>

Thanks Vladimir!

I added your modifications and created a new webrev:

http://cr.openjdk.java.net/~neliasso/8237581/webrev.04/

Best regards,
Nils



On 2020-01-30 16:55, Vladimir Ivanov wrote:
>
>> Good, but not complete. The "if (!always_slow) {" line also needs to 
>> check if 'initial_slow_test == NULL' (Meaning: We need no initial 
>> check, because we know the allocation size is positive and will fit 
>> in the TLAB, so we can go directly to the fast path), which is 
>> computed further down, so I moved the block down.
>
> Looks good.
>
>> Also, with the risk of complicating things - I changed '!always_slow' 
>> to 'expand_fast_path' because that conveys the meaning better.
>
> Not sure it improves readability, but I'm fine with it.
>
>> http://cr.openjdk.java.net/~neliasso/8237581/webrev.change.2/
>
> Looks good.
>
> PS: made slight modifications to the comment:
>
> ????? // Remove allocation node and return.
> ????? // Size is a non-negative constant -> no initial check needed -> 
> directly to fast path.
> ????? // Also, no usages -> empty fast path -> no fall out to slow 
> path -> nothing left.
>
> Best regards,
> Vladimir Ivanov
>
>>>> On 2020-01-24 09:36, Nils Eliasson wrote:
>>>>> Hi,
>>>>>
>>>>> This patch improves expand_allocate_common when there is no use of 
>>>>> the allocation.
>>>>>
>>>>> Three cases are improved:
>>>>>
>>>>> - With unknown allocation length - don't expand the fast path. No 
>>>>> allocation is needed when it isn't used. 
>>>>> NegativeArraySizeException will still be caught by the slowpath.
>>>>> - With known length inside the legal range - No fast path or slow 
>>>>> path is needed. The allocation node is removed.
>>>>> - With known length outside the legal range - only a slow path is 
>>>>> needed.
>>>>>
>>>>> I also refactored the code a bit, keeping the general structure 
>>>>> for easy diff, but extracting some routines too make it more 
>>>>> readable.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237581
>>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8237581/webrev.03/
>>>>>
>>>>> Please review!
>>>>>
>>>>> Best regards,
>>>>> Nils Eliasson
>>>>>
>>>>>
>>>>
>>


From nils.eliasson at oracle.com  Fri Jan 31 14:34:15 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 31 Jan 2020 15:34:15 +0100
Subject: [15] RFR (M): 8237581: Improve allocation expansion
In-Reply-To: <4d06f2af-ab40-8158-d984-ae87e4233c02@oracle.com>
References: <2d79a359-6b0b-c576-518c-388a8ffc4890@oracle.com>
 <921f00aa-ecbc-f838-5a4b-6acb6b62215d@oracle.com>
 <76b9ffce-8167-6337-cefd-24c18813ce18@oracle.com>
 <4d06f2af-ab40-8158-d984-ae87e4233c02@oracle.com>
Message-ID: <004bbfdb-5fd7-9f8d-6662-3bb33b88c8f2@oracle.com>

Thanks Claes!

I removed the redundant {} from the micro.

Best regards,
Nils Eliasson

On 2020-01-28 16:17, Claes Redestad wrote:
>
>
> On 2020-01-28 12:15, Nils Eliasson wrote:
>> Hi,
>>
>> I added a simple micro that triggers the optimization.
>>
>> Micro:
>> http://cr.openjdk.java.net/~neliasso/8237581/webrev.micro/
>>
>> On my workstation I get these numbers:
>>
>> JDK/JDK:
>>
>> Benchmark????????????????????????????????? (size)? Mode? Cnt Score 
>> Error? Units
>> ArrayAllocation.eliminateArrayConstLength???? 128 avgt 
>> 61.178????????? ns/op
>> ArrayAllocation.eliminateArrayVarLength?????? 128 avgt 
>> 55.109????????? ns/op
>>
>> JDK/JDK + path for 8237581:
>>
>> Benchmark????????????????????????????????? (size)? Mode? Cnt Score 
>> Error? Units
>> ArrayAllocation.eliminateArrayConstLength???? 128 avgt 0.841????????? 
>> ns/op
>> ArrayAllocation.eliminateArrayVarLength?????? 128 avgt 1.897????????? 
>> ns/op
>>
>> Speedup 30-70x
>
> Nice!
>
> Micro looks good and to the point. I think the {}'s around "128" is
> redundant for a single parameter value.
>
> Can't really review the compiler code changes but it all looks
> reasonable to me.
>
> /Claes


From richard.reingruber at sap.com  Fri Jan 31 17:24:50 2020
From: richard.reingruber at sap.com (Reingruber, Richard)
Date: Fri, 31 Jan 2020 17:24:50 +0000
Subject: VM_EnterInterpOnlyMode: why make compiled methods on stack
 not_entrant?
In-Reply-To: <7dd97d12-dc9f-99cc-384a-4d1ccfe516dd@oracle.com>
References: <AM0PR0202MB3331C331B51D301C8AEB482D9B0A0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <7dd97d12-dc9f-99cc-384a-4d1ccfe516dd@oracle.com>
Message-ID: <AM0PR0202MB333193D74B901D4B97BB94E39B070@AM0PR0202MB3331.eurprd02.prod.outlook.com>

Hi Vladimir,

thanks for looking at this and providing feedback.

I though as well about using a handshake there. I'll try it.

Thanks, Richard.

-----Original Message-----
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com> 
Sent: Donnerstag, 30. Januar 2020 17:55
To: Reingruber, Richard <richard.reingruber at sap.com>; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
Subject: Re: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant?

Hi Richard,

> I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack not_entrant. To me this
> seems unnecessary. I think it would be sufficient to patch the return pc of compiled frames and
> let them return to their deopt handler. Or what would be the reason to make the compiled methods
> not_entrant?
> 
> VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native methods get
> marked.
> 
> Deoptimization::deoptimize_all_marked(): all marked methods are made not_entrant.
> 
> Maybe this is for historical reasons? If I remember correctly, many years ago, deoptimizing a
> compiled frame used to require making the corresponding nmethod not_entrant. And making a nmethod
> not_entrant meant overriding its code with a slide of nops that led to the deopt handler.
> 
> I'd like to change this and just apply Deoptimization::deoptimize() on every compiled frame on
> stack. I've done this locally and tested the change without issues.

I'm not a JVMTI expert, but considering VM_EnterInterpOnlyMode is 
performed on per-thread basis [1], it looks like per-frame 
deoptimization (instead of per-nmethod) should be enough to do the job.

So, from JIT-compiler perspective, your suggestion to use 
Deoptimization::deoptimize() instead of 
CompiledMethod::mark_for_deoptimization()/Deoptimization::deoptimize_all_marked() 
sounds good.

PS: also, it looks like handshakes become a perfect fit for 
VM_EnterInterpOnlyMode: once you don't need to deoptimize on per-nmethod 
basis, there's no need to trigger global safepoint.

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/prims/jvmtiEventController.cpp#l227

     // If running in fullspeed mode, single stepping is implemented
     // as follows: first, the interpreter does not dispatch to
     // compiled code for threads that have single stepping enabled;
     // second, we deoptimize all methods on the thread's stack when
     // interpreted-only mode is enabled the first time for a given
     // thread (nothing to do if no Java frames yet).

From vladimir.kozlov at oracle.com  Fri Jan 31 17:47:57 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 31 Jan 2020 09:47:57 -0800
Subject: RFR: 8238190 : [JVMCI] Fix single implementor speculation for
 diamond shapes.
In-Reply-To: <ab1343c2-c5d9-f166-d10c-24a4afbe96c3@oracle.com>
References: <ab1343c2-c5d9-f166-d10c-24a4afbe96c3@oracle.com>
Message-ID: <c468a920-351b-905d-afc4-ddc1e9f47962@oracle.com>

CCing to Runtime group since it is runtime code. Coleen already looked on this fix but we need 
official review here.

David, it seems you did not pull latest fixes from JDK. Most of failures in your testing should be 
fixed already. There are testing infra "red" failures which are nothing to do with changes.
I would suggest to pull latest changes before push (after reviews) and run tier1-2 again.

In short, I don't see new failures in tier1-2 testing and tier3-graal. Fix looks good to me.

Thanks,
Vladimir

On 1/31/20 12:49 AM, David Leopoldseder wrote:
> Hi,
> 
> Please review this tiny change (+ a new test case exercising the pattern) to
> fix the single implementor logic in instanceKlass for diamond shaped class hierarchies.
> 
> This bug was revealed in Graal where we use the single implementor logic for invokeinterface 
> devirtualization.
> 
> https://bugs.openjdk.java.net/browse/JDK-8238190
> http://cr.openjdk.java.net/~davleopo/JDK-8238190/webrev.001/
> 
> Thank you.
> 
> - david
>