From felix.yang at huawei.com  Fri Mar  1 01:23:25 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Fri, 1 Mar 2019 01:23:25 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
 detection code for HiSilicon TSV110
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BD66@dggeml527-mbx.china.huawei.com>

Hi,

    Please review this trivial patch adding support for HiSilicon TSV110.  
    Bug: https://bugs.openjdk.java.net/browse/JDK-8219888  
    Webrev: http://cr.openjdk.java.net/~fyang/8219888/webrev.00/  
    
    Tested on Huawei Kunpeng 920 server platform.  OK to push?  

Thanks,
Felix

From jatin.bhateja at intel.com  Fri Mar  1 02:35:02 2019
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Fri, 1 Mar 2019 02:35:02 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <04476179-590e-9315-667c-cc6885477194@oracle.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <45438f90-dcac-7941-1cf5-366555821e2e@redhat.com>
 <CAEgw74BBNoSWnBWqVYvVXJ1=qYQUD2MjeQ9iO8PZrZNm76B9hQ@mail.gmail.com>
 <3eb77fb3-db71-8e57-a9f3-ebf635a0291c@redhat.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <DB7PR08MB3115E9E5A0D0676FADEFC0B596750@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <04476179-590e-9315-667c-cc6885477194@oracle.com>
Message-ID: <A66BBE673E08E1428E3A918AE4D5B32CEEA237@BGSMSX106.gar.corp.intel.com>

Hi Pengfei,

Please find my response in following mail.

Best Regards,
Jatin

> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Friday, March 1, 2019 12:57 AM
> To: Pengfei Li (Arm Technology China) <Pengfei.Li at arm.com>; Bhateja, Jatin
> <jatin.bhateja at intel.com>; B. Blaser <bsrbnd at gmail.com>; aarch64-port-
> dev at openjdk.java.net
> Cc: hotspot-compiler-dev at openjdk.java.net; Viswanathan, Sandhya
> <sandhya.viswanathan at intel.com>
> Subject: Re: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
> Math.min/max intrinsics, approval request
> 
> Thank you, Pengfei
> 
> Then lets keep branch prediction heuristic shared. I take back my previous
> suggestion to have a function for it.
> 
> Jatin, can you Pengfei's question about your change?
> 
> Thanks,
> Vladimir
> 
> On 2/27/19 10:45 PM, Pengfei Li (Arm Technology China) wrote:
> > Hi Vladimir, Jatin and All,
> >
> >> So I have question for aarch64 developers. Are aarch64 fmin/fmax
> >> instructions are always faster than code generated by default? If
> >> this is true new conditions should be x86 specific. To have a
> >> separate function to do these checks. We have precedent -
> >> clear_upper_avx(). May be later we have to add other conditions for
> other platforms too.
> >
> > I am the author of original AArch64 fmin/fmax intrinsics patch[1], but not a
> reviewer.
> >
> > Both Andrew Haley and I have tested the performance of AArch64
> fmin/fmax instructions before. As far as I could remember, the result is
> similar to what we have seen here on x86. If selecting the min/max values
> from an array of random numbers, fmin/fmax instructions show better
> performance. But for an already (almost) sorted array, fmin/fmax
> instructions do make the performance worse, but not too much. So
> personally I think, adding heuristic in shared code would benefit AArch64 as
> well.
> >
> > I didn't quite understand Jatin's additional code below.
> > --
> > +#ifdef X86
> > +  // Being conservative since all the phi edges may not be set
> > +  // by now. This is done to skip over reduction scenarios.
> > +  if (a->is_Phi() || b->is_Phi())
> > +    return false;
> > +#endif
> > --
> > Is it going to black out *all* reduction scenarios? I see the intrinsics benefit
> the reduction in some cases. And in my opinion, adding this kind of platform-
> dependent macros in hotspot shared code is not so good.

Proposed check was added based on the common reduction scenario cases which showed 
performance degradation with new intrinsic sequence for X86.

> >
> > [1] http://hg.openjdk.java.net/jdk/jdk/rev/f15af1e2c683
> >
> > --
> > Thanks,
> > Pengfei
> >

From patrick at os.amperecomputing.com  Fri Mar  1 02:47:19 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Fri, 1 Mar 2019 02:47:19 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
 detection code for HiSilicon TSV110
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BD66@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BD66@dggeml527-mbx.china.huawei.com>
Message-ID: <BYAPR01MB5046C67F5069AF5D72A74E348F760@BYAPR01MB5046.prod.exchangelabs.com>

The top comment ?says? this if-clause was for ThunderX2, which looks a little strange.

I would suggest either we place all vendor specific descriptions together at the top, or have a new if-clause for each (much cleaner).


  // ThunderX2
  if ((_cpu == CPU_CAVIUM && (_model == 0xAF)) ||
      (_cpu == CPU_BROADCOM && (_model == 0x516)) ||
  // HiSilicon TSV110
      (_cpu == CPU_HISILICON && (_model == 0xd01))) {
    if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) {
      FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true);
    }
    if (FLAG_IS_DEFAULT(UseSIMDForMemoryOps)) {
      FLAG_SET_DEFAULT(UseSIMDForMemoryOps, true);
    }
  }



Regards

Patrick



-----Original Message-----

From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On Behalf Of Yangfei (Felix)

Sent: Friday, March 1, 2019 9:23 AM

To: hotspot-runtime-dev at openjdk.java.net

Cc: aarch64-port-dev <aarch64-port-dev at openjdk.java.net>

Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU detection code for HiSilicon TSV110



Hi,



    Please review this trivial patch adding support for HiSilicon TSV110.

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

    Webrev: http://cr.openjdk.java.net/~fyang/8219888/webrev.00/



    Tested on Huawei Kunpeng 920 server platform.  OK to push?



Thanks,

Felix

From felix.yang at huawei.com  Fri Mar  1 03:07:48 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Fri, 1 Mar 2019 03:07:48 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
 detection code for HiSilicon TSV110
In-Reply-To: <BYAPR01MB5046C67F5069AF5D72A74E348F760@BYAPR01MB5046.prod.exchangelabs.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BD66@dggeml527-mbx.china.huawei.com>
 <BYAPR01MB5046C67F5069AF5D72A74E348F760@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BDC7@dggeml527-mbx.china.huawei.com>

I am afraid we are duplicating code having one if-clause for each CPU.
Here, we have three different CPUs sharing this if-cause: CAVIUM, BROADCOM and HISILICON.
It?s OK to place all vendor specific description together at the top, but I am not clear about the model of BRAODCOM.
So I am going this way: separate description for each model.



The top comment ?says? this if-clause was for ThunderX2, which looks a little strange.

I would suggest either we place all vendor specific descriptions together at the top, or have a new if-clause for each (much cleaner).


  // ThunderX2
  if ((_cpu == CPU_CAVIUM && (_model == 0xAF)) ||
      (_cpu == CPU_BROADCOM && (_model == 0x516)) ||
  // HiSilicon TSV110
      (_cpu == CPU_HISILICON && (_model == 0xd01))) {
    if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) {
      FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true);
    }
    if (FLAG_IS_DEFAULT(UseSIMDForMemoryOps)) {
      FLAG_SET_DEFAULT(UseSIMDForMemoryOps, true);
    }
  }



Regards

Patrick



-----Original Message-----

From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On Behalf Of Yangfei (Felix)

Sent: Friday, March 1, 2019 9:23 AM

To: hotspot-runtime-dev at openjdk.java.net

Cc: aarch64-port-dev <aarch64-port-dev at openjdk.java.net>

Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU detection code for HiSilicon TSV110



Hi,



    Please review this trivial patch adding support for HiSilicon TSV110.

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

    Webrev: http://cr.openjdk.java.net/~fyang/8219888/webrev.00/



    Tested on Huawei Kunpeng 920 server platform.  OK to push?



Thanks,

Felix

From derekw at marvell.com  Fri Mar  1 05:34:21 2019
From: derekw at marvell.com (Derek White)
Date: Fri, 1 Mar 2019 05:34:21 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
 detection code for HiSilicon TSV110
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BDC7@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BD66@dggeml527-mbx.china.huawei.com>
 <BYAPR01MB5046C67F5069AF5D72A74E348F760@BYAPR01MB5046.prod.exchangelabs.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F6BDC7@dggeml527-mbx.china.huawei.com>
Message-ID: <MN2PR18MB2733429BABDFB98926F60DC8D2760@MN2PR18MB2733.namprd18.prod.outlook.com>

Hi Felix,

I think I agree with your 2nd approach - a separate if-clause for each model. Even though a little code may be duplicated, it allows each vendor to make changes independently.

The Cavium/Broadcom block is a special case because they are essentially the same chip. The "Broadcom" versions were early manufacturing releases that are no longer relevant, so we might want to simplify this in future. 

 - Derek
 Cavium Inc. Oops, I mean Marvell Semiconductor Inc.

> -----Original Message-----
> From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On
> Behalf Of Yangfei (Felix)
> Sent: Thursday, February 28, 2019 10:08 PM
> To: Patrick Zhang OS <patrick at os.amperecomputing.com>; hotspot-
> runtime-dev at openjdk.java.net
> Cc: aarch64-port-dev <aarch64-port-dev at openjdk.java.net>
> Subject: [EXT] Re: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add
> CPU detection code for HiSilicon TSV110
> 
> External Email
> 
> ----------------------------------------------------------------------
> I am afraid we are duplicating code having one if-clause for each CPU.
> Here, we have three different CPUs sharing this if-cause: CAVIUM,
> BROADCOM and HISILICON.
> It?s OK to place all vendor specific description together at the top, but I am
> not clear about the model of BRAODCOM.
> So I am going this way: separate description for each model.
> 
> 
> 
> The top comment ?says? this if-clause was for ThunderX2, which looks a little
> strange.
> 
> I would suggest either we place all vendor specific descriptions together at
> the top, or have a new if-clause for each (much cleaner).
> 
> 
>   // ThunderX2
>   if ((_cpu == CPU_CAVIUM && (_model == 0xAF)) ||
>       (_cpu == CPU_BROADCOM && (_model == 0x516)) ||
>   // HiSilicon TSV110
>       (_cpu == CPU_HISILICON && (_model == 0xd01))) {
>     if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) {
>       FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true);
>     }
>     if (FLAG_IS_DEFAULT(UseSIMDForMemoryOps)) {
>       FLAG_SET_DEFAULT(UseSIMDForMemoryOps, true);
>     }
>   }
> 
> 
> 
> Regards
> 
> Patrick
> 
> 
> 
> -----Original Message-----
> 
> From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On
> Behalf Of Yangfei (Felix)
> 
> Sent: Friday, March 1, 2019 9:23 AM
> 
> To: hotspot-runtime-dev at openjdk.java.net
> 
> Cc: aarch64-port-dev <aarch64-port-dev at openjdk.java.net>
> 
> Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
> detection code for HiSilicon TSV110
> 
> 
> 
> Hi,
> 
> 
> 
>     Please review this trivial patch adding support for HiSilicon TSV110.
> 
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8219888
> 
>     Webrev: http://cr.openjdk.java.net/~fyang/8219888/webrev.00/
> 
> 
> 
>     Tested on Huawei Kunpeng 920 server platform.  OK to push?
> 
> 
> 
> Thanks,
> 
> Felix

From felix.yang at huawei.com  Fri Mar  1 06:01:08 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Fri, 1 Mar 2019 06:01:08 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
 detection code for HiSilicon TSV110
In-Reply-To: <MN2PR18MB2733429BABDFB98926F60DC8D2760@MN2PR18MB2733.namprd18.prod.outlook.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BD66@dggeml527-mbx.china.huawei.com>
 <BYAPR01MB5046C67F5069AF5D72A74E348F760@BYAPR01MB5046.prod.exchangelabs.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F6BDC7@dggeml527-mbx.china.huawei.com>
 <MN2PR18MB2733429BABDFB98926F60DC8D2760@MN2PR18MB2733.namprd18.prod.outlook.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BDE9@dggeml527-mbx.china.huawei.com>

Hi,

    Now it looks reasonable for Cavium and Broadcom sharing the same if-clause.  I was thinking they are totally different CPUs.  
    I can propose a v2 patch creating another if-clause for the HiSilicon one.  

Thanks,
Felix

> 
> Hi Felix,
> 
> I think I agree with your 2nd approach - a separate if-clause for each model. Even
> though a little code may be duplicated, it allows each vendor to make changes
> independently.
> 
> The Cavium/Broadcom block is a special case because they are essentially the
> same chip. The "Broadcom" versions were early manufacturing releases that are
> no longer relevant, so we might want to simplify this in future.
> 
>  - Derek
>  Cavium Inc. Oops, I mean Marvell Semiconductor Inc.
> 
> > -----Original Message-----
> > From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On
> > Behalf Of Yangfei (Felix)
> > Sent: Thursday, February 28, 2019 10:08 PM
> > To: Patrick Zhang OS <patrick at os.amperecomputing.com>; hotspot-
> > runtime-dev at openjdk.java.net
> > Cc: aarch64-port-dev <aarch64-port-dev at openjdk.java.net>
> > Subject: [EXT] Re: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add
> > CPU detection code for HiSilicon TSV110
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > I am afraid we are duplicating code having one if-clause for each CPU.
> > Here, we have three different CPUs sharing this if-cause: CAVIUM,
> > BROADCOM and HISILICON.
> > It?s OK to place all vendor specific description together at the top, but I am
> > not clear about the model of BRAODCOM.
> > So I am going this way: separate description for each model.
> >
> >
> >
> > The top comment ?says? this if-clause was for ThunderX2, which looks a little
> > strange.
> >
> > I would suggest either we place all vendor specific descriptions together at
> > the top, or have a new if-clause for each (much cleaner).
> >
> >
> >   // ThunderX2
> >   if ((_cpu == CPU_CAVIUM && (_model == 0xAF)) ||
> >       (_cpu == CPU_BROADCOM && (_model == 0x516)) ||
> >   // HiSilicon TSV110
> >       (_cpu == CPU_HISILICON && (_model == 0xd01))) {
> >     if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) {
> >       FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true);
> >     }
> >     if (FLAG_IS_DEFAULT(UseSIMDForMemoryOps)) {
> >       FLAG_SET_DEFAULT(UseSIMDForMemoryOps, true);
> >     }
> >   }
> >
> >
> >
> > Regards
> >
> > Patrick
> >
> >
> >
> > -----Original Message-----
> >
> > From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On
> > Behalf Of Yangfei (Felix)
> >
> > Sent: Friday, March 1, 2019 9:23 AM
> >
> > To: hotspot-runtime-dev at openjdk.java.net
> >
> > Cc: aarch64-port-dev <aarch64-port-dev at openjdk.java.net>
> >
> > Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
> > detection code for HiSilicon TSV110
> >
> >
> >
> > Hi,
> >
> >
> >
> >     Please review this trivial patch adding support for HiSilicon TSV110.
> >
> >     Bug: https://bugs.openjdk.java.net/browse/JDK-8219888
> >
> >     Webrev: http://cr.openjdk.java.net/~fyang/8219888/webrev.00/
> >
> >
> >
> >     Tested on Huawei Kunpeng 920 server platform.  OK to push?
> >
> >
> >
> > Thanks,
> >
> > Felix

From aph at redhat.com  Fri Mar  1 08:57:40 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 1 Mar 2019 08:57:40 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
 detection code for HiSilicon TSV110
In-Reply-To: <MN2PR18MB2733429BABDFB98926F60DC8D2760@MN2PR18MB2733.namprd18.prod.outlook.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BD66@dggeml527-mbx.china.huawei.com>
 <BYAPR01MB5046C67F5069AF5D72A74E348F760@BYAPR01MB5046.prod.exchangelabs.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F6BDC7@dggeml527-mbx.china.huawei.com>
 <MN2PR18MB2733429BABDFB98926F60DC8D2760@MN2PR18MB2733.namprd18.prod.outlook.com>
Message-ID: <70f34d14-89e6-3262-013b-6d0444dad47a@redhat.com>

On 3/1/19 5:34 AM, Derek White wrote:

> I think I agree with your 2nd approach - a separate if-clause for
> each model. Even though a little code may be duplicated, it allows
> each vendor to make changes independently.

Yes, I agree. There's duplication, but the control flow is much simpler.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Fri Mar  1 09:44:31 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 1 Mar 2019 09:44:31 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <A66BBE673E08E1428E3A918AE4D5B32CEEA237@BGSMSX106.gar.corp.intel.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <DB7PR08MB3115E9E5A0D0676FADEFC0B596750@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <04476179-590e-9315-667c-cc6885477194@oracle.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEEA237@BGSMSX106.gar.corp.intel.com>
Message-ID: <ede32438-ef93-34a1-ad0b-6f7e673466f7@redhat.com>

On 01/03/2019 02:35, Bhateja, Jatin wrote:

>>> I didn't quite understand Jatin's additional code below.
>>> --
>>> +#ifdef X86
>>> +  // Being conservative since all the phi edges may not be set
>>> +  // by now. This is done to skip over reduction scenarios.
>>> +  if (a->is_Phi() || b->is_Phi())
>>> +    return false;
>>> +#endif
>>> --
>>> Is it going to black out *all* reduction scenarios? I see the intrinsics benefit
>> the reduction in some cases. And in my opinion, adding this kind of platform-
>> dependent macros in hotspot shared code is not so good.
> 
> Proposed check was added based on the common reduction scenario cases which showed 
> performance degradation with new intrinsic sequence for X86.
That doesn't actually clarify things very well. Are you saying:

1a) your patch disables FPMinMax reduction for all architectures?

or

1b) your patch disables FPMinMax reduction for x86?

and

2a) it does so because when reduction is enabled x86 fails to show
performance improvement for applications of reduction?

or

2b) it does so because when reduction is enabled x86 fails to show
performance improvement for selection of the FPMin/Max intrinsic?

I think you are saying 1a and 2b but I'd prefer to be sure. I would like
a clear answer because Pengfei has a pending patch which shows
significant benefit on AArch64 using first the FPMin/Max intrinsic and
then, for extra gain, FPMin/Max reduction. My own investigations have
not show any detrimental effect to using the intrinsic or reduction and
Andrew Haley seems to have withdrawn the claim that the intrinsic can
worsen performance. So, it is quite important to understand what your
patch does and why.

If there is some other way to avoid the slowdown on x86 (whether that
comes with use of the intrinsic or with use of reduction) without
clobbering the gains to be had on AArch64 then that would be preferable.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From jatin.bhateja at intel.com  Fri Mar  1 10:20:56 2019
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Fri, 1 Mar 2019 10:20:56 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <ede32438-ef93-34a1-ad0b-6f7e673466f7@redhat.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <DB7PR08MB3115E9E5A0D0676FADEFC0B596750@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <04476179-590e-9315-667c-cc6885477194@oracle.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEEA237@BGSMSX106.gar.corp.intel.com>
 <ede32438-ef93-34a1-ad0b-6f7e673466f7@redhat.com>
Message-ID: <A66BBE673E08E1428E3A918AE4D5B32CEEA41F@BGSMSX106.gar.corp.intel.com>

Hi Andrew,

Please see my response embedded in following mail.

Thanks,
Jatin

> -----Original Message-----
> From: Andrew Dinn [mailto:adinn at redhat.com]
> Sent: Friday, March 1, 2019 3:15 PM
> To: Bhateja, Jatin <jatin.bhateja at intel.com>; Vladimir Kozlov
> <vladimir.kozlov at oracle.com>; Pengfei Li (Arm Technology China)
> <Pengfei.Li at arm.com>; B. Blaser <bsrbnd at gmail.com>; aarch64-port-
> dev at openjdk.java.net
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
> Math.min/max intrinsics, approval request
> 
> On 01/03/2019 02:35, Bhateja, Jatin wrote:
> 
> >>> I didn't quite understand Jatin's additional code below.
> >>> --
> >>> +#ifdef X86
> >>> +  // Being conservative since all the phi edges may not be set
> >>> +  // by now. This is done to skip over reduction scenarios.
> >>> +  if (a->is_Phi() || b->is_Phi())
> >>> +    return false;
> >>> +#endif
> >>> --
> >>> Is it going to black out *all* reduction scenarios? I see the
> >>> intrinsics benefit
> >> the reduction in some cases. And in my opinion, adding this kind of
> >> platform- dependent macros in hotspot shared code is not so good.
> >
> > Proposed check was added based on the common reduction scenario cases
> > which showed performance degradation with new intrinsic sequence for
> X86.
> That doesn't actually clarify things very well. Are you saying:
> 
> 1a) your patch disables FPMinMax reduction for all architectures?
> 
> or
> 
> 1b) your patch disables FPMinMax reduction for x86?
> 
> and
> 
> 2a) it does so because when reduction is enabled x86 fails to show
> performance improvement for applications of reduction?
> 
> or
> 
> 2b) it does so because when reduction is enabled x86 fails to show
> performance improvement for selection of the FPMin/Max intrinsic?
> 

Current patch which is under review does not contain above code change to bypass intrinsic creation for reduction patterns.
For X86 performance degrades with intrinsic w.r.t to non-intrinsic implementation in reduction
scenarios with and without data variance (i.e. with and without branch predication effects). 

I  could not find right hooks which can be called from common code for adding any such target specific checks during ideal(DAG) construction. 
Please share if you know any.

> I think you are saying 1a and 2b but I'd prefer to be sure. I would like a clear
> answer because Pengfei has a pending patch which shows significant benefit
> on AArch64 using first the FPMin/Max intrinsic and then, for extra gain,
> FPMin/Max reduction. My own investigations have not show any detrimental
> effect to using the intrinsic or reduction and Andrew Haley seems to have
> withdrawn the claim that the intrinsic can worsen performance. So, it is quite
> important to understand what your patch does and why.
> 
> If there is some other way to avoid the slowdown on x86 (whether that
> comes with use of the intrinsic or with use of reduction) without clobbering
> the gains to be had on AArch64 then that would be preferable.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From adinn at redhat.com  Fri Mar  1 16:01:07 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 1 Mar 2019 16:01:07 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <8bf4cc54-6e66-fab4-b3fe-4b026780924d@redhat.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <CAEgw74BBNoSWnBWqVYvVXJ1=qYQUD2MjeQ9iO8PZrZNm76B9hQ@mail.gmail.com>
 <3eb77fb3-db71-8e57-a9f3-ebf635a0291c@redhat.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <7194e0cc-0f4f-7348-7b50-1347acbf9f92@redhat.com>
 <8bf4cc54-6e66-fab4-b3fe-4b026780924d@redhat.com>
Message-ID: <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>

On 28/02/2019 12:38, Andrew Haley wrote:
> On 2/28/19 9:54 AM, Andrew Haley wrote:
>> On 2/27/19 8:21 PM, Vladimir Kozlov wrote:
>>
>>> So I have question for aarch64 developers. Are aarch64 fmin/fmax
>>> instructions are always faster than code generated by default?
>> Be aware that AArch64 is an abstract architecture, so it cannot be
>> said to have performance properties.
>>
>> In real hardware, however, the answer is no. Nothing like. I have seen
>> the fmin/fmax instructions cause a 3x slowdown on a reduction loop.
> 
> So Andrew Dinn asked me what machine, and what test. After some time
> trying I confess that I cannot reproduce this result. I didn't think
> much of it at the time, which was why I didn't record that
> information. My apologies.

Ok, that's good to know. The tests I ran to check the benefits of
FPMax/Min intrinsics were for 3 different AArch64 CPUs (AppliedMicro,
Qualcomm and AMD) and they only showed a small degradation in
performance for the intrinsic with sorted data and a good improvement
with random data.

Also, I can now provide some details including timings the tests
fpmin/max reduction tests I tried on Qualcomm and AMD. I tested 3
separate implementations:

1) only Pengfei's fpmin/max intrinsics no reduction rules (novec)
2) Pengfei's fpmin/max intrinsics plus reduction rules (vec)
3) Pengfei's fpmin/max intrinsics plus my upgraded reduction rules (vecplus)

The difference between vec and vecplus is that Pengfei only uses the
vector reduction instruction fmaxv for reducing a 4 float vector (T4S).

instruct reduce_max4F(vRegF dst, vRegF src1, vecX src2) %{
  . . .
  ins_encode %{
    __ fmaxv(as_FloatRegister($dst$$reg), __ T4S,
as_FloatRegister($src2$$reg));
    __ fmaxs(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg),
as_FloatRegister($src1$$reg));
  %}
  . . .

The fmaxv vector operation picks the max of the 4 new vector elements in
one step. The subsequent scalar compare picks it or the current
reduction value for the next cycle round the loop.

For the 2 float and 2 double reduction rules (T2S and T2D) Pengfei's
rules compare  of the 2 vector entries independently using a vector
element pick two scalar comparisons. Here is the double version of
Pengfei's encoding (the float version simply replaces D with F and d with f)

instruct reduce_max2D(vRegD dst, vRegD src1, vecX src2, vecX tmp) %{
  . . .
  ins_encode %{
    __ fmaxd(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg),
as_FloatRegister($src2$$reg));
    __ ins(as_FloatRegister($tmp$$reg), __ D,
as_FloatRegister($src2$$reg), 0, 1);
    __ fmaxd(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg),
as_FloatRegister($tmp$$reg));
  %}
  . . .

My alternative patch modifies the 2D rule to work like the 4S rule i.e.

instruct reduce_max2D(vRegD dst, vRegD src1, vecX src2, vecX tmp) %{
  . . .
  ins_encode %{
    __ fmaxv(as_FloatRegister($dst$$reg), __ T2D,
as_FloatRegister($src2$$reg));
    __ fmaxd(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg),
as_FloatRegister($src1$$reg));
  %}
  . . .

There is a corresponding tweak to the 2F rule but it is somewhat
immaterial since I could not produce a test that would cause it to be
applied.

In fact, like Pengfei, I found it hard to come up with tests that caused
the reduction to be performed.

The obvious example one would want to work would be something like this:

  double da[] = ...
  doubel db[] = ...

  @Benchmark
  public void testVecMaxDoubleReduce2() {
      double max = 0.0;
      for (int z = 0; z < COUNT; z++) {
	  for (int i = 0; i < LENGTH; i++) {
	      max = Math.max(max, da[i]);
	  }
      }
      dc[0] = max;
  }

Obviously there are 3 more equivalent benchmarks obtained by
substituting Math.min for Math.max and.or float for double.

For this test the max operations are translated to the FPMax intrinsic.
However, the reduction is not applied.  That's because the compiler
never considers performing the da[i] loads in the loop body as vector loads.

Vectorized loading is only performed when two arrays are loaded and
combined using a binary operator. So, the following test does get
vectorized and, as a consequence, is then vector reduced.

  @Benchmark
  public void testVecMaxDoubleReduce3() {
      double max = 0.0;
      for (int z = 0; z < COUNT; z++) {
	  for (int i = 0; i < LENGTH; i++) {
	      max = Math.max(max, da[i] + db[i]);
	  }
      }
      dc[0] = max;
  }

In this case the compiler spots that the adds refer to two elements of
da and db using the same index and decides that it can perform the add
as a 2D vector op. Now that it has the sum as a 2D value it is able to
use the 2D FPMax reduction rule to compute the value of the Math.max
call. This also works for the other 3 cases where a min and/or float
type is substituted.

I got the following result (i us/op) from running these tests on the AMD box

Benchmark                  No Redn       Redn           Full Redn
testVecMaxDoubleReduce2    6042 ? 0.47   6041 ?  0.17   6042 ?   0.37
testVecMaxDoubleReduce3    6042 ? 0.57   6042 ?  0.55   3576 ? 143.86

testVecMaxFloatReduce2     6041 ? 0.05   6042 ?  0.47   6042 ?   0.38
testVecMaxFloatReduce3     6042 ? 0.31   1556 ? 17.25   1562 ?  21.96

testVecMinDoubleReduce2    6041 ? 0.05   6042 ?  0.34   6042 ?   0.39
testVecMinDoubleReduce3    6042 ? 0.36   6050 ?  7.20   3322 ?  23.41

testVecMinFloatReduce2     6042 ? 0.49   6042 ?  0.58   6042 ?   0.30
testVecMinFloatReduce3     6042 ? 0.44   1535 ?  3.24   1581 ?  61.56


The 3 columns show no reduction, reduction using Pengfei's T4S rule and
reduction using both T4S and T2D rules. In all 3 cases the FpMin/Max
intrinsic is enabled. As you can see the Reduce2 tests don't get
reduced. The Reduce3 tests do get reduced with both sets of reduction
rules (I verified this in the debugger and by eyeballing the generated
code). for the T4S cases there is a clear improvement with both sets of
rules. For the 2D case Pengfei's rules don't give a better result but
mine do (when you look at the generated code it is clear that Pengfei's
reduction rule is not going to give a better result over the no
reduction case).

Results on the Qualcomm box were pretty much identical.

n.b. the variation in the average values and spreads for some of the
float and double runs are misleading. My machine crashed while running
the tests remotely and I ended up perturbing the box I was running the
tests on when I re-established a login session and checked the progress
of the runs. Previous tests provided more consistent results where the
FloatReduce3 values for vec and vecplus were very close and had a very
small spread (as you would expect) and where the DoubleReduce3 values
for vecplus were also both close to 3300 with a very small spread.

So, these figures seem to show that the use of fmaxv reduction for both
T4S and T2D saves cycles by avoiding the need for extra vector register
element transfers and fpmax/min comparisons.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From adinn at redhat.com  Fri Mar  1 16:06:13 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 1 Mar 2019 16:06:13 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <3eb77fb3-db71-8e57-a9f3-ebf635a0291c@redhat.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <7194e0cc-0f4f-7348-7b50-1347acbf9f92@redhat.com>
 <8bf4cc54-6e66-fab4-b3fe-4b026780924d@redhat.com>
 <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>
Message-ID: <9033fb77-b4c8-8e69-cbc2-9bc3afcdd6bb@redhat.com>

On 01/03/2019 16:01, Andrew Dinn wrote:
> My alternative patch modifies the 2D rule to work like the 4S rule i.e.
> 
> instruct reduce_max2D(vRegD dst, vRegD src1, vecX src2, vecX tmp) %{
>   . . .
>   ins_encode %{
>     __ fmaxv(as_FloatRegister($dst$$reg), __ T2D,
> as_FloatRegister($src2$$reg));
>     __ fmaxd(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg),
> as_FloatRegister($src1$$reg));
>   %}
>   . . .

Doh! One more tweak that could be applied here is, of course, to get rid
of that redundant 'vecX tmp' argument. It almost certainly won't affect
the current benchmark figures but it does free up another vector
register which might help some real FP code.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From bsrbnd at gmail.com  Fri Mar  1 16:39:03 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 1 Mar 2019 17:39:03 +0100
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <ede32438-ef93-34a1-ad0b-6f7e673466f7@redhat.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <DB7PR08MB3115E9E5A0D0676FADEFC0B596750@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <04476179-590e-9315-667c-cc6885477194@oracle.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEEA237@BGSMSX106.gar.corp.intel.com>
 <ede32438-ef93-34a1-ad0b-6f7e673466f7@redhat.com>
Message-ID: <CAEgw74DqcbQOak0ss1L-vmOvdZzji3GG7NMx6iwDYKBzrLTXMQ@mail.gmail.com>

On Fri, 1 Mar 2019 at 10:44, Andrew Dinn <adinn at redhat.com> wrote:
>
> If there is some other way to avoid the slowdown on x86 (whether that
> comes with use of the intrinsic or with use of reduction) without
> clobbering the gains to be had on AArch64 then that would be preferable.

Then, I'd like to suggest another alternative here under.

This is an optimization of the API generated code using only one
'ucomis[s/d]' vs five before.
There's between 5-10% gain with the current benchmark [1] for
predictable, unpredictable and reduction scenarios.

Before:

Benchmark                      Mode  Cnt     Score   Error  Units
FpMinMaxIntrinsics.dMax        avgt       8633.782          ns/op
FpMinMaxIntrinsics.dMin        avgt       8694.123          ns/op
FpMinMaxIntrinsics.dMinReduce  avgt        710.493          ns/op
FpMinMaxIntrinsics.fMax        avgt       8578.784          ns/op
FpMinMaxIntrinsics.fMin        avgt       8734.432          ns/op
FpMinMaxIntrinsics.fMinReduce  avgt        719.532          ns/op


After:

Benchmark                      Mode  Cnt     Score   Error  Units
FpMinMaxIntrinsics.dMax        avgt       8050.014          ns/op
FpMinMaxIntrinsics.dMin        avgt       8027.534          ns/op
FpMinMaxIntrinsics.dMinReduce  avgt        675.791          ns/op
FpMinMaxIntrinsics.fMax        avgt       8022.847          ns/op
FpMinMaxIntrinsics.fMin        avgt       7945.885          ns/op
FpMinMaxIntrinsics.fMinReduce  avgt        659.173          ns/op


I haven't observed any regression until now, so statistics aren't
necessary any more.
There's no need to deal with legacy 'xmm' registers and only one
temporary integer register is necessary.

Any feedback would be more than welcome (hotspot:tier1 is OK on x86_64 xeon).

Thanks,
Bernard

[1] http://hg.openjdk.java.net/jdk/submit/rev/ab2b1418f0db

diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad
--- a/src/hotspot/cpu/x86/x86_64.ad
+++ b/src/hotspot/cpu/x86/x86_64.ad
@@ -808,6 +808,57 @@
   __ bind(done);
 }

+// fp min      # max
+// ucomis[s/d]
+// ja -> b     # a
+// jp -> NaN   # NaN
+// je -> a | b # a & b
+// jb -> a     # b
+void emit_fp_min_max(MacroAssembler& _masm, XMMRegister dst,
XMMRegister a, XMMRegister b, Register tmp, bool min, bool single) {
+  Label nan, equal, above, done;
+
+  if (single)
+    __ ucomiss(a, b);
+  else
+    __ ucomisd(a, b);
+
+  __ jccb(Assembler::above, above); // CF=0 & ZF=0
+  __ jccb(Assembler::parity, nan);  // PF=1
+  __ jccb(Assembler::equal, equal); // ZF=1
+
+  // below
+  if (single)
+    __ movflt(dst, min ? a : b);
+  else
+    __ movdbl(dst, min ? a : b);
+  __ jmp(done);
+
+  __ bind(nan);
+  if (single) {
+    __ movl(tmp, 0x7fc00000); // Float.NaN
+    __ movdl(dst, tmp);
+  }
+  else {
+    __ mov64(tmp, 0x7ff8000000000000L); // Double.NaN
+    __ movdq(dst, tmp);
+  }
+  __ jmp(done);
+
+  __ bind(equal);
+  if (min)
+    __ vpor(dst, a, b, Assembler::AVX_128bit);
+  else
+    __ vpand(dst, a, b, Assembler::AVX_128bit);
+  __ jmp(done);
+
+  __ bind(above);
+  if (single)
+    __ movflt(dst, min ? b : a);
+  else
+    __ movdbl(dst, min ? b : a);
+
+  __ bind(done);
+}

 //=============================================================================
 const RegMask& MachConstantBaseNode::_out_RegMask = RegMask::Empty;
@@ -5470,6 +5521,63 @@
   ins_pipe( fpu_reg_reg );
 %}

+// max = java.lang.Math.max(float a, float b)
+instruct maxF_reg(regF dst, regF a, regF b, rRegI tmp) %{
+  predicate(UseAVX > 0);
+  match(Set dst (MaxF a b));
+  effect(USE a, USE b, TEMP tmp);
+
+  format %{ "$dst = max($a, $b)\t# intrinsic (float)" %}
+  ins_encode %{
+    emit_fp_min_max(_masm, $dst$$XMMRegister, $a$$XMMRegister,
$b$$XMMRegister, $tmp$$Register,
+                    false /*min*/, true /*single*/);
+  %}
+  ins_pipe( pipe_slow );
+%}
+
+// max = java.lang.Math.max(double a, double b)
+instruct maxD_reg(regD dst, regD a, regD b, rRegL tmp) %{
+  predicate(UseAVX > 0);
+  match(Set dst (MaxD a b));
+  effect(USE a, USE b, TEMP tmp);
+
+  format %{ "$dst = max($a, $b)\t# intrinsic (double)" %}
+  ins_encode %{
+    emit_fp_min_max(_masm, $dst$$XMMRegister, $a$$XMMRegister,
$b$$XMMRegister, $tmp$$Register,
+                    false /*min*/, false /*single*/);
+  %}
+  ins_pipe( pipe_slow );
+%}
+
+
+// min = java.lang.Math.min(float a, float b)
+instruct minF_reg(regF dst, regF a, regF b, rRegI tmp) %{
+  predicate(UseAVX > 0);
+  match(Set dst (MinF a b));
+  effect(USE a, USE b, TEMP tmp);
+
+  format %{ "$dst = min($a, $b)\t# intrinsic (float)" %}
+  ins_encode %{
+    emit_fp_min_max(_masm, $dst$$XMMRegister, $a$$XMMRegister,
$b$$XMMRegister, $tmp$$Register,
+                    true /*min*/, true /*single*/);
+  %}
+  ins_pipe( pipe_slow );
+%}
+
+// min = java.lang.Math.min(double a, double b)
+instruct minD_reg(regD dst, regD a, regD b, rRegL tmp) %{
+  predicate(UseAVX > 0);
+  match(Set dst (MinD a b));
+  effect(USE a, USE b, TEMP tmp);
+
+  format %{ "$dst = min($a, $b)\t# intrinsic (double)" %}
+  ins_encode %{
+    emit_fp_min_max(_masm, $dst$$XMMRegister, $a$$XMMRegister,
$b$$XMMRegister, $tmp$$Register,
+                    true /*min*/, false /*single*/);
+  %}
+  ins_pipe( pipe_slow );
+%}
+
 // Load Effective Address
 instruct leaP8(rRegP dst, indOffset8 mem)
 %{

From ci_notify at linaro.org  Fri Mar  1 22:14:46 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Fri, 1 Mar 2019 22:14:46 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <2039573346.1264.1551478486868.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/060/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/24 pass: 5,520; fail: 5; error: 1; not run: 93
Build 1: aarch64/2019/jan/25 pass: 5,533; fail: 6; error: 1; not run: 93
Build 2: aarch64/2019/jan/28 pass: 5,533; fail: 6; error: 1; not run: 93
Build 3: aarch64/2019/jan/30 pass: 5,527; fail: 5; error: 2; not run: 93
Build 4: aarch64/2019/feb/04 pass: 5,527; fail: 7; error: 2; not run: 93
Build 5: aarch64/2019/feb/06 pass: 5,532; fail: 4; error: 1; not run: 93
Build 6: aarch64/2019/feb/08 pass: 5,519; fail: 19; error: 2; not run: 93
Build 7: aarch64/2019/feb/11 pass: 5,527; fail: 11; error: 2; not run: 93
Build 8: aarch64/2019/feb/13 pass: 5,537; fail: 4; not run: 93
Build 9: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 10: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 11: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 12: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 13: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 14: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93

1 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/24 pass: 8,533; fail: 503; error: 18
Build 1: aarch64/2019/jan/25 pass: 8,538; fail: 500; error: 20
Build 2: aarch64/2019/jan/28 pass: 8,543; fail: 496; error: 20
Build 3: aarch64/2019/jan/30 pass: 8,541; fail: 503; error: 19
Build 4: aarch64/2019/feb/04 pass: 8,539; fail: 506; error: 18
Build 5: aarch64/2019/feb/06 pass: 8,537; fail: 499; error: 27
Build 6: aarch64/2019/feb/08 pass: 8,530; fail: 515; error: 23
Build 7: aarch64/2019/feb/11 pass: 8,559; fail: 490; error: 15
Build 8: aarch64/2019/feb/13 pass: 8,534; fail: 512; error: 18
Build 9: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 10: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 11: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 12: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 13: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 14: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20

5 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/24 pass: 3,993; fail: 1
Build 1: aarch64/2019/jan/25 pass: 3,993; fail: 1
Build 2: aarch64/2019/jan/28 pass: 3,994; fail: 1
Build 3: aarch64/2019/jan/30 pass: 3,994; fail: 1
Build 4: aarch64/2019/feb/04 pass: 3,994; fail: 1
Build 5: aarch64/2019/feb/06 pass: 3,994; fail: 1
Build 6: aarch64/2019/feb/08 pass: 3,994; fail: 1
Build 7: aarch64/2019/feb/11 pass: 3,994; fail: 1
Build 8: aarch64/2019/feb/13 pass: 3,994; fail: 1
Build 9: aarch64/2019/feb/15 pass: 3,995
Build 10: aarch64/2019/feb/18 pass: 3,996
Build 11: aarch64/2019/feb/20 pass: 3,996
Build 12: aarch64/2019/feb/25 pass: 3,931
Build 13: aarch64/2019/feb/27 pass: 3,931
Build 14: aarch64/2019/mar/01 pass: 3,931

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.46x
Relative performance: Server critical-jOPS (nc): 9.30x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 210.67

Server 210.67 / Server 2014-04-01 (71.00): 2.97x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-01-24 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/024/results/
2019-01-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/025/results/
2019-01-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/028/results/
2019-01-31 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/030/results/
2019-02-05 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/035/results/
2019-02-07 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/037/results/
2019-02-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/039/results/
2019-02-12 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/042/results/
2019-02-14 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/044/results/
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From patrick at os.amperecomputing.com  Sat Mar  2 03:13:20 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Sat, 2 Mar 2019 03:13:20 +0000
Subject: [aarch64-port-dev ] [NEW BUG]Missing LoadStore barrier
	in	interpreter?
In-Reply-To: <CADim6awT1Z0jhSfqL_4wkVdL-HF_XFtMo--PY_NcGSh0TrfJ2A@mail.gmail.com>
References: <CADim6axCe+iWV7nqzPf7Q9G-syGK-mwD_o4rpD=dHKE=mcgcRQ@mail.gmail.com>
 <07ce7183-e57c-dc68-9391-3d1369c67e77@redhat.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F57614@dggeml527-mbx.china.huawei.com>
 <f9106a71-4783-8c45-4564-c7d6c5b0b6b6@redhat.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F58677@dggeml527-mbx.china.huawei.com>
 <1880b8f1-7563-f50e-aef9-5c6032672844@redhat.com>
 <CADim6awT1Z0jhSfqL_4wkVdL-HF_XFtMo--PY_NcGSh0TrfJ2A@mail.gmail.com>
Message-ID: <BYAPR01MB5046289433D5B4541853A2B58F770@BYAPR01MB5046.prod.exchangelabs.com>

Hi Lun

The similar problem in fast_storefield has been fixed in jdk/jdk and aarch64-port/jdk8u-shenandoah respectively.  

Regards
Patrick

-----Original Message-----
From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On Behalf Of Lun Liu
Sent: Friday, February 22, 2019 7:15 PM
To: Andrew Haley <aph at redhat.com>
Cc: aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] [NEW BUG]Missing LoadStore barrier in interpreter?

Thanks for confirming and posting the patch. Just realized void TemplateTable::fast_storefield(TosState state) in the same file has the same problem. Could someone help fix that too?

Best,

On Tue, Feb 12, 2019 at 1:28 AM Andrew Haley <aph at redhat.com> wrote:

> On 2/12/19 9:05 AM, Yangfei (Felix) wrote:
> > This is aarch64-specific and is supposed to be merged into:
> aarch64-port/jdk8u-shenandoah and aarch64-port/jdk8u repos.
> >
> > Do we still need to send this to the 8u list ? If true, should I 
> > simply
> CC to that list?
>
> Sorry, of course. No, don't post to 8u. Please forget I said that!  
> :-)
>
> Only halfway down my first cup of coffee...
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>


--
Lun Liu
PhD Candidate
Computer Science Department
University of California, Los Angeles

From bsrbnd at gmail.com  Fri Mar  1 19:58:19 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 1 Mar 2019 20:58:19 +0100
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <CAEgw74DqcbQOak0ss1L-vmOvdZzji3GG7NMx6iwDYKBzrLTXMQ@mail.gmail.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <DB7PR08MB3115E9E5A0D0676FADEFC0B596750@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <04476179-590e-9315-667c-cc6885477194@oracle.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEEA237@BGSMSX106.gar.corp.intel.com>
 <ede32438-ef93-34a1-ad0b-6f7e673466f7@redhat.com>
 <CAEgw74DqcbQOak0ss1L-vmOvdZzji3GG7NMx6iwDYKBzrLTXMQ@mail.gmail.com>
Message-ID: <CAEgw74AjVAm5Anjrhg5yGjaet+2++YW7fvHwXNWbj0US59sZsw@mail.gmail.com>

On Fri, 1 Mar 2019 at 17:39, B. Blaser <bsrbnd at gmail.com> wrote:
>
> On Fri, 1 Mar 2019 at 10:44, Andrew Dinn <adinn at redhat.com> wrote:
> >
> > If there is some other way to avoid the slowdown on x86 (whether that
> > comes with use of the intrinsic or with use of reduction) without
> > clobbering the gains to be had on AArch64 then that would be preferable.
>
> Then, I'd like to suggest another alternative here under.
>
> This is an optimization of the API generated code using only one
> 'ucomis[s/d]' vs five before.
> There's between 5-10% gain with the current benchmark [1] for
> predictable, unpredictable and reduction scenarios.
>
> Before:
>
> Benchmark                      Mode  Cnt     Score   Error  Units
> FpMinMaxIntrinsics.dMax        avgt       8633.782          ns/op
> FpMinMaxIntrinsics.dMin        avgt       8694.123          ns/op
> FpMinMaxIntrinsics.dMinReduce  avgt        710.493          ns/op
> FpMinMaxIntrinsics.fMax        avgt       8578.784          ns/op
> FpMinMaxIntrinsics.fMin        avgt       8734.432          ns/op
> FpMinMaxIntrinsics.fMinReduce  avgt        719.532          ns/op
>
>
> After:
>
> Benchmark                      Mode  Cnt     Score   Error  Units
> FpMinMaxIntrinsics.dMax        avgt       8050.014          ns/op
> FpMinMaxIntrinsics.dMin        avgt       8027.534          ns/op
> FpMinMaxIntrinsics.dMinReduce  avgt        675.791          ns/op
> FpMinMaxIntrinsics.fMax        avgt       8022.847          ns/op
> FpMinMaxIntrinsics.fMin        avgt       7945.885          ns/op
> FpMinMaxIntrinsics.fMinReduce  avgt        659.173          ns/op
>
>
> I haven't observed any regression until now, so statistics aren't
> necessary any more.
> There's no need to deal with legacy 'xmm' registers and only one
> temporary integer register is necessary.
>
> Any feedback would be more than welcome (hotspot:tier1 is OK on x86_64 xeon).

Small correction below as equivalent fp values might have different
representations, see JLS ?4.2.3.
The gain is still roughly 5-10%.

Bernard

diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad
--- a/src/hotspot/cpu/x86/x86_64.ad
+++ b/src/hotspot/cpu/x86/x86_64.ad
@@ -808,6 +808,81 @@
   __ bind(done);
 }

+// Math.min()    # Math.max()
+// --------------------------
+// ucomis[s/d]   #
+// ja   -> b     # a
+// jp   -> NaN   # NaN
+// jb   -> a     # b
+// je            #
+// |-jz -> a | b # a & b
+// |    -> a     #
+void emit_fp_min_max(MacroAssembler& _masm, XMMRegister dst,
+                     XMMRegister a, XMMRegister b, Register tmp,
+                     bool min, bool single) {
+
+  Label nan, zero, below, above, done;
+
+  if (single)
+    __ ucomiss(a, b);
+  else
+    __ ucomisd(a, b);
+
+  __ jccb(Assembler::above, above); // CF=0 & ZF=0
+  __ jccb(Assembler::parity, nan);  // PF=1
+  __ jccb(Assembler::below, below); // CF=1
+
+  // equal
+  if (single) {
+    __ movdl(tmp, a);
+    __ shll(tmp, 1); // skip sign bit
+    __ testl(tmp, tmp);
+    __ jccb(Assembler::zero, zero);
+    __ movflt(dst, a);
+    __ jmp(done);
+  }
+  else {
+    __ movdq(tmp, a);
+    __ shlq(tmp, 1); // skip sign bit
+    __ testq(tmp, tmp);
+    __ jccb(Assembler::zero, zero);
+    __ movdbl(dst, a);
+    __ jmp(done);
+  }
+
+  __ bind(zero);
+  if (min)
+    __ vpor(dst, a, b, Assembler::AVX_128bit);
+  else
+    __ vpand(dst, a, b, Assembler::AVX_128bit);
+  __ jmp(done);
+
+  __ bind(above);
+  if (single)
+    __ movflt(dst, min ? b : a);
+  else
+    __ movdbl(dst, min ? b : a);
+  __ jmp(done);
+
+  __ bind(nan);
+  if (single) {
+    __ movl(tmp, 0x7fc00000); // Float.NaN
+    __ movdl(dst, tmp);
+  }
+  else {
+    __ mov64(tmp, 0x7ff8000000000000L); // Double.NaN
+    __ movdq(dst, tmp);
+  }
+  __ jmp(done);
+
+  __ bind(below);
+  if (single)
+    __ movflt(dst, min ? a : b);
+  else
+    __ movdbl(dst, min ? a : b);
+
+  __ bind(done);
+}

 //=============================================================================
 const RegMask& MachConstantBaseNode::_out_RegMask = RegMask::Empty;
@@ -5470,6 +5545,63 @@
   ins_pipe( fpu_reg_reg );
 %}

+// max = java.lang.Math.max(float a, float b)
+instruct maxF_reg(regF dst, regF a, regF b, rRegI tmp) %{
+  predicate(UseAVX > 0);
+  match(Set dst (MaxF a b));
+  effect(USE a, USE b, TEMP tmp);
+
+  format %{ "$dst = max($a, $b)\t# intrinsic (float)" %}
+  ins_encode %{
+    emit_fp_min_max(_masm, $dst$$XMMRegister, $a$$XMMRegister,
$b$$XMMRegister, $tmp$$Register,
+                    false /*min*/, true /*single*/);
+  %}
+  ins_pipe( pipe_slow );
+%}
+
+// max = java.lang.Math.max(double a, double b)
+instruct maxD_reg(regD dst, regD a, regD b, rRegL tmp) %{
+  predicate(UseAVX > 0);
+  match(Set dst (MaxD a b));
+  effect(USE a, USE b, TEMP tmp);
+
+  format %{ "$dst = max($a, $b)\t# intrinsic (double)" %}
+  ins_encode %{
+    emit_fp_min_max(_masm, $dst$$XMMRegister, $a$$XMMRegister,
$b$$XMMRegister, $tmp$$Register,
+                    false /*min*/, false /*single*/);
+  %}
+  ins_pipe( pipe_slow );
+%}
+
+
+// min = java.lang.Math.min(float a, float b)
+instruct minF_reg(regF dst, regF a, regF b, rRegI tmp) %{
+  predicate(UseAVX > 0);
+  match(Set dst (MinF a b));
+  effect(USE a, USE b, TEMP tmp);
+
+  format %{ "$dst = min($a, $b)\t# intrinsic (float)" %}
+  ins_encode %{
+    emit_fp_min_max(_masm, $dst$$XMMRegister, $a$$XMMRegister,
$b$$XMMRegister, $tmp$$Register,
+                    true /*min*/, true /*single*/);
+  %}
+  ins_pipe( pipe_slow );
+%}
+
+// min = java.lang.Math.min(double a, double b)
+instruct minD_reg(regD dst, regD a, regD b, rRegL tmp) %{
+  predicate(UseAVX > 0);
+  match(Set dst (MinD a b));
+  effect(USE a, USE b, TEMP tmp);
+
+  format %{ "$dst = min($a, $b)\t# intrinsic (double)" %}
+  ins_encode %{
+    emit_fp_min_max(_masm, $dst$$XMMRegister, $a$$XMMRegister,
$b$$XMMRegister, $tmp$$Register,
+                    true /*min*/, false /*single*/);
+  %}
+  ins_pipe( pipe_slow );
+%}
+
 // Load Effective Address
 instruct leaP8(rRegP dst, indOffset8 mem)
 %{

From jatin.bhateja at intel.com  Sat Mar  2 19:51:07 2019
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Sat, 2 Mar 2019 19:51:07 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <CAEgw74DQqxznUisUQ4um6XEe1QKiboP9c=kPyxEXHbvGEqDAYA@mail.gmail.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <DB7PR08MB3115E9E5A0D0676FADEFC0B596750@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <04476179-590e-9315-667c-cc6885477194@oracle.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEEA237@BGSMSX106.gar.corp.intel.com>
 <ede32438-ef93-34a1-ad0b-6f7e673466f7@redhat.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEEA41F@BGSMSX106.gar.corp.intel.com>
 <CAEgw74DQqxznUisUQ4um6XEe1QKiboP9c=kPyxEXHbvGEqDAYA@mail.gmail.com>
Message-ID: <A66BBE673E08E1428E3A918AE4D5B32CEEA8ED@BGSMSX106.gar.corp.intel.com>



> -----Original Message-----
> From: B. Blaser [mailto:bsrbnd at gmail.com]
> Sent: Saturday, March 2, 2019 8:26 PM
> To: Bhateja, Jatin <jatin.bhateja at intel.com>
> Cc: Andrew Dinn <adinn at redhat.com>; Vladimir Kozlov
> <vladimir.kozlov at oracle.com>; Pengfei Li (Arm Technology China)
> <Pengfei.Li at arm.com>; aarch64-port-dev at openjdk.java.net; hotspot-
> compiler-dev at openjdk.java.net
> Subject: Re: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
> Math.min/max intrinsics, approval request
> 
> On Fri, 1 Mar 2019 at 11:21, Bhateja, Jatin <jatin.bhateja at intel.com> wrote:
> >
> > Current patch which is under review does not contain above code change
> to bypass intrinsic creation for reduction patterns.
> > For X86 performance degrades with intrinsic w.r.t to non-intrinsic
> > implementation in reduction scenarios with and without data variance (i.e.
> with and without branch predication effects).
> >
> > I  could not find right hooks which can be called from common code for
> adding any such target specific checks during ideal(DAG) construction.
> > Please share if you know any.
> 
> I guess if you want to back out all reduction scenarios, a probably better way
> to do this would be to add predicates to your matching
> rules:

Having multiple selection patterns based on node properties is good if we have
optimized selection patterns with and without properties (in this case reduction) , what I was asking
for was a target specific hook at the ideal construction level which can be used to generate
different graphs based on target requirements e.g. one target may see intrinsic creation 
beneficial where as other may not under some cases.

> 
> instruct minF_random_reg(legRegF dst, legRegF a, legRegF b, legRegF tmp,
> legRegF atmp, legRegF btmp) %{
>   predicate(UseAVX > 0 && !n->is_reduction());
> 
> Reductions being computed properly here:
> 
> diff --git a/src/hotspot/share/opto/loopTransform.cpp
> b/src/hotspot/share/opto/loopTransform.cpp
> --- a/src/hotspot/share/opto/loopTransform.cpp
> +++ b/src/hotspot/share/opto/loopTransform.cpp
> @@ -2039,7 +2039,8 @@
>          if (n_ctrl != NULL && loop->is_member(get_loop(n_ctrl))) {
>            // Now test it to see if it fits the standard pattern for a reduction
> operator.
>            int opc = def_node->Opcode();
> -          if (opc != ReductionNode::opcode(opc,
> def_node->bottom_type()->basic_type())) {
> +          if (opc != ReductionNode::opcode(opc,
> def_node->bottom_type()->basic_type())
> +              || opc == Op_MinD || opc == Op_MinF || opc == Op_MaxD
> || opc == Op_MaxF) {
>              if (!def_node->is_reduction()) { // Not marked yet
>                // To be a reduction, the arithmetic node must have the phi as input
> and provide a def to it
>                bool ok = false;
> 
> And if this is a reduction you could use alternative rules, see [0]:
> 
> instruct minF_reg(regF dst, regF a, regF b, rRegI tmp) %{
>   predicate(UseAVX > 0 && n->is_reduction());
> 
> But I'm not sure if 'blend/min/max' is really preferable to a single 'ucomisd'?
> 
> To summarize:
> 
>               | blend/min/max | one ucomisd
> --------------|---------------|------------
> predictable   | ! tiny loss ! | 10% gain
> unpredictable |   50% gain    | 10% gain
> reduction     | !!high loss!! | 10% gain

I tried reduction with multiple combination of data (NaN , signed zeros and strict FP).  
I'm not sure if we will see 10% gains for reduction in all the cases, but performance
won't degrade as with blend/min/max.

> 
> If we'd like to maximize the unpredictable gain we find in examples like
> random search trees [1], we'd have to choose the 'blend/min/max'
> variant. To avoid regressions, we'd have to use statistics which might be
> shared between architectures [2]. However, data isn't collected per call-site
> [3] and the prediction might be wrong [4] in which case we'd have a tiny loss.
> For reduction scenarios, it'd be safer to back out all of them when using
> 'blend/min/max'.
> 
> A safer variant would be to optimize the current compiled code of the API
> using only one 'ucomisd' [0] vs several before [5]. The gain would be stable
> of about 10% in every scenarios. So, no need to do predictions and no need
> to bail out any more!
> 
> The discussion is still open... any opinion?
> 
> Thanks,
> Bernard
> 
> 
> [0] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-
> March/033011.html
> [1]
> http://hg.openjdk.java.net/jdk/submit/file/d164e0b595e6/test/hotspot/jtreg
> /compiler/intrinsics/math/TestFpMinMaxIntrinsics.java#l185
> [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-
> February/032973.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8015416
> [4]
> http://hg.openjdk.java.net/jdk/submit/file/d164e0b595e6/src/hotspot/shar
> e/opto/library_call.cpp#l6612
> [5] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-
> January/032564.html

From ci_notify at linaro.org  Sun Mar  3 02:02:04 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Sun, 3 Mar 2019 02:02:04 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64
Message-ID: <447709242.1434.1551578525504.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/061/summary.html
 
-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/15 pass: 5,705; fail: 9; not run: 11,618
Build 1: aarch64/2019/jan/17 pass: 5,709; fail: 9; not run: 11,618
Build 2: aarch64/2019/jan/22 pass: 5,709; fail: 9; not run: 11,618
Build 3: aarch64/2019/jan/24 pass: 5,708; fail: 10; not run: 11,618
Build 4: aarch64/2019/jan/29 pass: 5,709; fail: 9; not run: 11,618
Build 5: aarch64/2019/jan/31 pass: 5,707; fail: 11; not run: 11,618
Build 6: aarch64/2019/feb/02 pass: 5,708; fail: 10; not run: 11,618
Build 7: aarch64/2019/feb/07 pass: 5,710; fail: 9; not run: 11,618
Build 8: aarch64/2019/feb/09 pass: 5,710; fail: 9; not run: 11,618
Build 9: aarch64/2019/feb/12 pass: 5,709; fail: 10; not run: 11,618
Build 10: aarch64/2019/feb/16 pass: 5,713; fail: 10; not run: 11,618
Build 11: aarch64/2019/feb/19 pass: 5,715; fail: 10; not run: 11,618
Build 12: aarch64/2019/feb/21 pass: 5,714; fail: 11; not run: 11,618
Build 13: aarch64/2019/feb/26 pass: 5,717; fail: 9; not run: 11,618
Build 14: aarch64/2019/mar/02 pass: 5,717; fail: 11; not run: 11,618

1 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/15 pass: 8,353; fail: 510; error: 32
Build 1: aarch64/2019/jan/17 pass: 8,386; fail: 493; error: 19
Build 2: aarch64/2019/jan/22 pass: 8,369; fail: 506; error: 23
Build 3: aarch64/2019/jan/24 pass: 8,366; fail: 507; error: 25
Build 4: aarch64/2019/jan/29 pass: 8,353; fail: 524; error: 22
Build 5: aarch64/2019/jan/31 pass: 8,372; fail: 502; error: 25
Build 6: aarch64/2019/feb/02 pass: 8,378; fail: 501; error: 21
Build 7: aarch64/2019/feb/07 pass: 8,364; fail: 507; error: 29
Build 8: aarch64/2019/feb/09 pass: 8,354; fail: 523; error: 23
Build 9: aarch64/2019/feb/12 pass: 8,358; fail: 519; error: 24
Build 10: aarch64/2019/feb/16 pass: 8,356; fail: 520; error: 25
Build 11: aarch64/2019/feb/19 pass: 8,375; fail: 506; error: 24
Build 12: aarch64/2019/feb/21 pass: 8,377; fail: 513; error: 22
Build 13: aarch64/2019/feb/26 pass: 8,387; fail: 501; error: 26
Build 14: aarch64/2019/mar/02 pass: 8,400; fail: 487; error: 29

2 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/15 pass: 3,903
Build 1: aarch64/2019/jan/17 pass: 3,903
Build 2: aarch64/2019/jan/22 pass: 3,903
Build 3: aarch64/2019/jan/24 pass: 3,903
Build 4: aarch64/2019/jan/29 pass: 3,903
Build 5: aarch64/2019/jan/31 pass: 3,903
Build 6: aarch64/2019/feb/02 pass: 3,903
Build 7: aarch64/2019/feb/07 pass: 3,903
Build 8: aarch64/2019/feb/09 pass: 3,903
Build 9: aarch64/2019/feb/12 pass: 3,903
Build 10: aarch64/2019/feb/16 pass: 3,903
Build 11: aarch64/2019/feb/19 pass: 3,903
Build 12: aarch64/2019/feb/21 pass: 3,904
Build 13: aarch64/2019/feb/26 pass: 3,904
Build 14: aarch64/2019/mar/02 pass: 3,904

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.12x
Relative performance: Server critical-jOPS (nc): 6.84x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 204.57

Server 204.57 / Server 2014-04-01 (71.00): 2.88x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-01-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/015/results/
2019-01-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/017/results/
2019-01-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/022/results/
2019-01-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/024/results/
2019-01-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/029/results/
2019-02-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/031/results/
2019-02-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/033/results/
2019-02-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/038/results/
2019-02-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/040/results/
2019-02-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/043/results/
2019-02-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/047/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/050/results/
2019-02-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/052/results/
2019-02-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/057/results/
2019-03-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/061/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/

From bsrbnd at gmail.com  Sat Mar  2 14:55:55 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Sat, 2 Mar 2019 15:55:55 +0100
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <A66BBE673E08E1428E3A918AE4D5B32CEEA41F@BGSMSX106.gar.corp.intel.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <DB7PR08MB3115E9E5A0D0676FADEFC0B596750@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <04476179-590e-9315-667c-cc6885477194@oracle.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEEA237@BGSMSX106.gar.corp.intel.com>
 <ede32438-ef93-34a1-ad0b-6f7e673466f7@redhat.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEEA41F@BGSMSX106.gar.corp.intel.com>
Message-ID: <CAEgw74DQqxznUisUQ4um6XEe1QKiboP9c=kPyxEXHbvGEqDAYA@mail.gmail.com>

On Fri, 1 Mar 2019 at 11:21, Bhateja, Jatin <jatin.bhateja at intel.com> wrote:
>
> Current patch which is under review does not contain above code change to bypass intrinsic creation for reduction patterns.
> For X86 performance degrades with intrinsic w.r.t to non-intrinsic implementation in reduction
> scenarios with and without data variance (i.e. with and without branch predication effects).
>
> I  could not find right hooks which can be called from common code for adding any such target specific checks during ideal(DAG) construction.
> Please share if you know any.

I guess if you want to back out all reduction scenarios, a probably
better way to do this would be to add predicates to your matching
rules:

instruct minF_random_reg(legRegF dst, legRegF a, legRegF b, legRegF
tmp, legRegF atmp, legRegF btmp) %{
  predicate(UseAVX > 0 && !n->is_reduction());

Reductions being computed properly here:

diff --git a/src/hotspot/share/opto/loopTransform.cpp
b/src/hotspot/share/opto/loopTransform.cpp
--- a/src/hotspot/share/opto/loopTransform.cpp
+++ b/src/hotspot/share/opto/loopTransform.cpp
@@ -2039,7 +2039,8 @@
         if (n_ctrl != NULL && loop->is_member(get_loop(n_ctrl))) {
           // Now test it to see if it fits the standard pattern for a
reduction operator.
           int opc = def_node->Opcode();
-          if (opc != ReductionNode::opcode(opc,
def_node->bottom_type()->basic_type())) {
+          if (opc != ReductionNode::opcode(opc,
def_node->bottom_type()->basic_type())
+              || opc == Op_MinD || opc == Op_MinF || opc == Op_MaxD
|| opc == Op_MaxF) {
             if (!def_node->is_reduction()) { // Not marked yet
               // To be a reduction, the arithmetic node must have the
phi as input and provide a def to it
               bool ok = false;

And if this is a reduction you could use alternative rules, see [0]:

instruct minF_reg(regF dst, regF a, regF b, rRegI tmp) %{
  predicate(UseAVX > 0 && n->is_reduction());

But I'm not sure if 'blend/min/max' is really preferable to a single 'ucomisd'?

To summarize:

              | blend/min/max | one ucomisd
--------------|---------------|------------
predictable   | ! tiny loss ! | 10% gain
unpredictable |   50% gain    | 10% gain
reduction     | !!high loss!! | 10% gain

If we'd like to maximize the unpredictable gain we find in examples
like random search trees [1], we'd have to choose the 'blend/min/max'
variant. To avoid regressions, we'd have to use statistics which might
be shared between architectures [2]. However, data isn't collected per
call-site [3] and the prediction might be wrong [4] in which case we'd
have a tiny loss. For reduction scenarios, it'd be safer to back out
all of them when using 'blend/min/max'.

A safer variant would be to optimize the current compiled code of the
API using only one 'ucomisd' [0] vs several before [5]. The gain would
be stable of about 10% in every scenarios. So, no need to do
predictions and no need to bail out any more!

The discussion is still open... any opinion?

Thanks,
Bernard


[0] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-March/033011.html
[1] http://hg.openjdk.java.net/jdk/submit/file/d164e0b595e6/test/hotspot/jtreg/compiler/intrinsics/math/TestFpMinMaxIntrinsics.java#l185
[2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-February/032973.html
[3] https://bugs.openjdk.java.net/browse/JDK-8015416
[4] http://hg.openjdk.java.net/jdk/submit/file/d164e0b595e6/src/hotspot/share/opto/library_call.cpp#l6612
[5] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032564.html

From felix.yang at huawei.com  Mon Mar  4 01:16:36 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Mon, 4 Mar 2019 01:16:36 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
 detection code for HiSilicon TSV110
In-Reply-To: <70f34d14-89e6-3262-013b-6d0444dad47a@redhat.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BD66@dggeml527-mbx.china.huawei.com>
 <BYAPR01MB5046C67F5069AF5D72A74E348F760@BYAPR01MB5046.prod.exchangelabs.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F6BDC7@dggeml527-mbx.china.huawei.com>
 <MN2PR18MB2733429BABDFB98926F60DC8D2760@MN2PR18MB2733.namprd18.prod.outlook.com>
 <70f34d14-89e6-3262-013b-6d0444dad47a@redhat.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820ED5F6C092@dggeml527-mbx.china.huawei.com>

v2 patch: http://cr.openjdk.java.net/~fyang/8219888/webrev.01/ 

Verified. OK? 

Thanks,
Felix

> 
> On 3/1/19 5:34 AM, Derek White wrote:
> 
> > I think I agree with your 2nd approach - a separate if-clause for
> > each model. Even though a little code may be duplicated, it allows
> > each vendor to make changes independently.
> 
> Yes, I agree. There's duplication, but the control flow is much simpler.
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From Pengfei.Li at arm.com  Mon Mar  4 10:06:16 2019
From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China))
Date: Mon, 4 Mar 2019 10:06:16 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <CAEgw74BBNoSWnBWqVYvVXJ1=qYQUD2MjeQ9iO8PZrZNm76B9hQ@mail.gmail.com>
 <3eb77fb3-db71-8e57-a9f3-ebf635a0291c@redhat.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <7194e0cc-0f4f-7348-7b50-1347acbf9f92@redhat.com>
 <8bf4cc54-6e66-fab4-b3fe-4b026780924d@redhat.com>
 <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>
Message-ID: <DB7PR08MB31155785E141FD50CF00B84C96710@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi Andrew Dinn,

Thanks for your work on testing my pending patch. But I have to say the 3rd implementation (vecplus) is buggy. The main reason I didn't use FMAXV/FMINV for 2 doubles is the architecture doesn't support that.

> instruct reduce_max4F(vRegF dst, vRegF src1, vecX src2) %{
>   . . .
>   ins_encode %{
>     __ fmaxv(as_FloatRegister($dst$$reg), __ T4S,
> as_FloatRegister($src2$$reg));
>     __ fmaxs(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg),
> as_FloatRegister($src1$$reg));
>   %}
>   . . .

Above matching rule for the float reduction node is correct.

> instruct reduce_max2D(vRegD dst, vRegD src1, vecX src2, vecX tmp) %{
>   . . .
>   ins_encode %{
>     __ fmaxv(as_FloatRegister($dst$$reg), __ T2D,
> as_FloatRegister($src2$$reg));
>     __ fmaxd(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg),
> as_FloatRegister($src1$$reg));
>   %}
>   . . .

But this one for the double reduction node is *not* correct.

From page 1502 of the Arm Architecture Reference Manual, we could see that the arrangement specifier for the floating-point min/max reduction instructions can only be 4S. It cannot be anything else. So below is the code I added in assembler_aarch64.hpp in my patch.

+#define INSN(NAME, opc) \
+  void NAME(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn) {                  \
+    starti;                                                                            \
+    assert(T == T4S, "arrangement must be T4S");                                       \
+    f(0b01101110, 31, 24), f(opc, 23), f(0b0110000111110, 22, 10);                     \
+    rf(Vn, 5), rf(Vd, 0);                                                              \
+  }
+
+  INSN(fmaxv, 0);
+  INSN(fminv, 1);
+
+#undef INSN
+

I hard-coded the arrangement bits in the encoding and added an assert (T == T4S) before that.

So if you use "__ fmaxv(as_FloatRegister($dst$$reg), __ T2D, as_FloatRegister($src2$$reg));" in the ad file. The code generated will still be something like "fmaxv     s21, v16.4s" (with 4S arrangement). And if you run the test with fastdebug build JDK, the assertion failure will be hit.

Maybe I shouldn't hard-code the arrangement bits in the encoding as it may hide problems. I will modify my previous webrev and post it in a new thread if you think so.

--
Thanks,
Pengfei


From aph at redhat.com  Mon Mar  4 11:39:25 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 4 Mar 2019 11:39:25 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8219888: aarch64 : add CPU
 detection code for HiSilicon TSV110
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820ED5F6C092@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED5F6BD66@dggeml527-mbx.china.huawei.com>
 <BYAPR01MB5046C67F5069AF5D72A74E348F760@BYAPR01MB5046.prod.exchangelabs.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F6BDC7@dggeml527-mbx.china.huawei.com>
 <MN2PR18MB2733429BABDFB98926F60DC8D2760@MN2PR18MB2733.namprd18.prod.outlook.com>
 <70f34d14-89e6-3262-013b-6d0444dad47a@redhat.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F6C092@dggeml527-mbx.china.huawei.com>
Message-ID: <6b28f507-f991-1a28-a4f6-ad63d0250f22@redhat.com>

On 3/4/19 1:16 AM, Yangfei (Felix) wrote:
> v2 patch: http://cr.openjdk.java.net/~fyang/8219888/webrev.01/ 
> 
> Verified. OK? 

OK, thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From ci_notify at linaro.org  Mon Mar  4 22:07:50 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Mon, 4 Mar 2019 22:07:50 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <153528136.1776.1551737270623.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/063/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/25 pass: 5,533; fail: 6; error: 1; not run: 93
Build 1: aarch64/2019/jan/28 pass: 5,533; fail: 6; error: 1; not run: 93
Build 2: aarch64/2019/jan/30 pass: 5,527; fail: 5; error: 2; not run: 93
Build 3: aarch64/2019/feb/04 pass: 5,527; fail: 7; error: 2; not run: 93
Build 4: aarch64/2019/feb/06 pass: 5,532; fail: 4; error: 1; not run: 93
Build 5: aarch64/2019/feb/08 pass: 5,519; fail: 19; error: 2; not run: 93
Build 6: aarch64/2019/feb/11 pass: 5,527; fail: 11; error: 2; not run: 93
Build 7: aarch64/2019/feb/13 pass: 5,537; fail: 4; not run: 93
Build 8: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 9: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 10: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 11: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 12: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 13: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93
Build 14: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93

2 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/25 pass: 8,538; fail: 500; error: 20
Build 1: aarch64/2019/jan/28 pass: 8,543; fail: 496; error: 20
Build 2: aarch64/2019/jan/30 pass: 8,541; fail: 503; error: 19
Build 3: aarch64/2019/feb/04 pass: 8,539; fail: 506; error: 18
Build 4: aarch64/2019/feb/06 pass: 8,537; fail: 499; error: 27
Build 5: aarch64/2019/feb/08 pass: 8,530; fail: 515; error: 23
Build 6: aarch64/2019/feb/11 pass: 8,559; fail: 490; error: 15
Build 7: aarch64/2019/feb/13 pass: 8,534; fail: 512; error: 18
Build 8: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 9: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 10: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 11: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 12: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 13: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20
Build 14: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20

2 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/25 pass: 3,993; fail: 1
Build 1: aarch64/2019/jan/28 pass: 3,994; fail: 1
Build 2: aarch64/2019/jan/30 pass: 3,994; fail: 1
Build 3: aarch64/2019/feb/04 pass: 3,994; fail: 1
Build 4: aarch64/2019/feb/06 pass: 3,994; fail: 1
Build 5: aarch64/2019/feb/08 pass: 3,994; fail: 1
Build 6: aarch64/2019/feb/11 pass: 3,994; fail: 1
Build 7: aarch64/2019/feb/13 pass: 3,994; fail: 1
Build 8: aarch64/2019/feb/15 pass: 3,995
Build 9: aarch64/2019/feb/18 pass: 3,996
Build 10: aarch64/2019/feb/20 pass: 3,996
Build 11: aarch64/2019/feb/25 pass: 3,931
Build 12: aarch64/2019/feb/27 pass: 3,931
Build 13: aarch64/2019/mar/01 pass: 3,931
Build 14: aarch64/2019/mar/04 pass: 3,931

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.80x
Relative performance: Server critical-jOPS (nc): 9.04x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 204.57

Server 204.57 / Server 2014-04-01 (71.00): 2.88x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-01-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/025/results/
2019-01-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/028/results/
2019-01-31 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/030/results/
2019-02-05 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/035/results/
2019-02-07 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/037/results/
2019-02-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/039/results/
2019-02-12 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/042/results/
2019-02-14 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/044/results/
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From patrick at os.amperecomputing.com  Tue Mar  5 07:58:14 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Tue, 5 Mar 2019 07:58:14 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8215976: backport a patch to
 jdk8u-shenandoah/jdk,
 fix gmtime_r declaration conflicts in zip.cpp with linux header files
Message-ID: <BYAPR01MB5046E8511CE1FE55CF216FC18F720@BYAPR01MB5046.prod.exchangelabs.com>

Hi Reviewers,

This issue (belongs to core libs) was exposed by building OpenJDK with ampere toolchains (gcc 8.2) on an aarch64 platform, and the fix has been verified on jdk/submit, pushed into jdk/jdk, backported to jdk8u-dev respectively, see below for details.
May I request to backport it to aarch64-port/jdk8u-shenandoah/jdk as well? 

https://bugs.openjdk.java.net/browse/JDK-8215976, http://hg.openjdk.java.net/jdk/jdk/rev/06862c019f3f   
https://bugs.openjdk.java.net/browse/JDK-8217901, http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/db7a698be165 
Tests: this patch does not impact functions, build jdk/jdk has been verified at jdk/submit, build aarch64 verified at ampere platforms.

Attached is the diff, please help review, thanks.

Regards
Patrick

-----Original Message-----
From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On Behalf Of Patrick Zhang OS
Sent: Wednesday, February 27, 2019 1:26 PM
To: aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] Request to port a patch to aarch64-port/jdk8u-shenandoah, fix gmtime_r declaration conflicts in zip.cpp with linux header files

Hi

Can I ask for porting this (simple) patch from jdk8u-dev to aarch64-port/jdk8u-shenandoah? I supposed it would be in via 'bulk merge' but haven't found so in the latest merge. 
Please kindly approve this, thanks in advance.

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/db7a698be165
JBS: https://bugs.openjdk.java.net/browse/JDK-8217901
(Btw, I found "Fix Version/s: openjdk8u211", when will this accutally happen? April release? or already done? I am confused here...)

Regards
Patrick

-----Original Message-----
From: Patrick Zhang
Sent: Tuesday, January 29, 2019 11:29 AM
To: 'Andrew Hughes' <gnu.andrew at redhat.com>; Andrew Haley <aph at redhat.com>
Cc: aarch64-port-dev at openjdk.java.net
Subject: RE: [aarch64-port-dev ] Request to cherry-pick JDK-8215976, fix gmtime_r declaration conflicts in zip.cpp with linux header files

Many thanks for the help. I saw it is in jdk8u now and suppose will be in aarch64-port/jdk8u-shenandoah soon.

Regards
Patrick

-----Original Message-----
From: Andrew Hughes <gnu.andrew at redhat.com>
Sent: Wednesday, January 23, 2019 11:40 PM
To: Andrew Haley <aph at redhat.com>
Cc: Patrick Zhang <patrick at os.amperecomputing.com>; aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] Request to cherry-pick JDK-8215976, fix gmtime_r declaration conflicts in zip.cpp with linux header files

On Wed, 23 Jan 2019 at 09:37, Andrew Haley <aph at redhat.com> wrote:
>
> On 1/23/19 3:18 AM, Patrick Zhang wrote:
> > Would there be any proper process to follow, please let me know. Appreciate your help.
>
> I'm fine with this being put into the aarch64-port/jdk8u-shenandoah 
> port, but it should be sent to jdk8u-dev.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Please get the fix into upstream jdk8u, via the 8u-dev list, and we will then pick it up in aarch64-port/jdk8u-shenandoah when we merge.

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gmtime_aarch64.patch.txt
URL: <https://mail.openjdk.java.net/pipermail/aarch64-port-dev/attachments/20190305/df80bcc4/gmtime_aarch64.patch.txt>

From adinn at redhat.com  Tue Mar  5 08:57:10 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 5 Mar 2019 08:57:10 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <DB7PR08MB31155785E141FD50CF00B84C96710@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <7194e0cc-0f4f-7348-7b50-1347acbf9f92@redhat.com>
 <8bf4cc54-6e66-fab4-b3fe-4b026780924d@redhat.com>
 <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>
 <DB7PR08MB31155785E141FD50CF00B84C96710@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <adb09e5c-b314-b203-9c58-5daafb8e2002@redhat.com>

Hi Pengfei,

On 04/03/2019 10:06, Pengfei Li (Arm Technology China) wrote:
> 
> Thanks for your work on testing my pending patch. But I have to say
> the 3rd implementation (vecplus) is buggy. The main reason I didn't
> use FMAXV/FMINV for 2 doubles is the architecture doesn't support
> that.
> . . .
> So if you use "__ fmaxv(as_FloatRegister($dst$$reg), __ T2D,
> as_FloatRegister($src2$$reg));" in the ad file. The code generated
> will still be something like "fmaxv     s21, v16.4s" (with 4S
> arrangement). And if you run the test with fastdebug build JDK, the
> assertion failure will be hit.

Thank you for pointing this out. I had not noticed the warning about
this encoding being reserved in the ARM ARM nor that your encoding was
forcing the Q and sz bits to be 1 0.

What seems very odd to me is the difference between fmaxv and fminv.
Both Q == 1 encodings (i.e. with sz in {0, 1}) are reserved for fmaxv.
However, the encoding for fminv accepts both Q == 1 encodings with the
expected interpretation.

> Maybe I shouldn't hard-code the arrangement bits in the encoding as
> it may hide problems. I will modify my previous webrev and post it in
> a new thread if you think so.

Yes, I think it would probably be better to leave the assert in place
and use the encoding implied by the SIMD_Arrangement parameter i.e. T2S
==> Q=1,sz=0 and T2D ==> Q=1, sz=1. That way the assert will catch
errors in debug builds and non-debug builds should be stopped by a
SIGILL exception.

Also, if you adjust the assert to only apply to the fmax case then we
can still translate 2D FMIN reduction using the fminv instruction.

  assert(opc == 1 || T == T4S, "fmaxv arrangement must be T4S");

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From ci_notify at linaro.org  Tue Mar  5 11:08:08 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Tue, 5 Mar 2019 11:08:08 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 886 Failure
Message-ID: <2129691941.1842.1551784089113.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Failure
Build details -  https://ci.linaro.org/job/jdkX-ci-build/886/

Changes -
  aoqi: 35a30b432396c58e764711c0201df9400c549d89 
	- doc/testing.html
	- doc/testing.md 
--"8219906: Update test documentation with default test jobs settings
Reviewed-by: ihse
"  ihse: ecc2bcc3beb0dc0b83f0bdc707aa38943a9bc7f6 
	- make/common/Execute.gmk
	- make/CreateJmods.gmk
	- make/Docs.gmk
	- make/ExplodedImageOptimize.gmk
	- make/Images.gmk
	- make/Main.gmk
	- make/UpdateX11Wrappers.gmk
	- make/gensrc/GensrcCommonJdk.gmk
	- make/gensrc/GensrcX11Wrappers.gmk
	- make/hotspot/gensrc/GenerateSources.gmk
	- make/hotspot/gensrc/GensrcAdlc.gmk
	- make/hotspot/gensrc/GensrcDtrace.gmk
	- make/hotspot/gensrc/GensrcJfr.gmk
	- make/hotspot/gensrc/GensrcJvmti.gmk
	- make/hotspot/ide/CreateVSProject.gmk 
--"8219971: Introduce SetupExecute in build system
Reviewed-by: erikj
"

Build output -
   Building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'
   Compiling 8 files for BUILD_TOOLS_LANGTOOLS
   Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
   Compiling 2 files for BUILD_JVMTI_TOOLS
   Parsing 2 properties into enum-like class for jdk.compiler
   Compiling 10 properties into resource bundles for jdk.javadoc
   Compiling 12 properties into resource bundles for jdk.jdeps
   Compiling 19 properties into resource bundles for jdk.compiler
   Compiling 7 properties into resource bundles for jdk.jshell
   Compiling 117 files for BUILD_java.compiler.interim
   Creating support/modules_libs/java.base/server/libjvm.so from 917 file(s)
   Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s)
   Creating hotspot/variant-server/libjvm/gtest/libjvm.so from 108 file(s)
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp:29:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/classfile/classLoaderData.hpp:37,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/precompiled/precompiled.hpp:34:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/utilities/jfrTypes.hpp:28:36: fatal error: jfrfiles/jfrEventIds.hpp: No such file or directory
   compilation terminated.
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp:29:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/classfile/classLoaderData.hpp:37,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/precompiled/precompiled.hpp:34:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/utilities/jfrTypes.hpp:28:36: fatal error: jfrfiles/jfrEventIds.hpp: No such file or directory
   compilation terminated.
   lib/CompileJvm.gmk:172: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch' failed
   make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch] Error 1
   make[3]: *** Waiting for unfinished jobs....
   make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/gtest/objs/precompiled/precompiled.hpp.gch] Error 1
   lib/CompileGtest.gmk:58: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/gtest/objs/precompiled/precompiled.hpp.gch' failed
   make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
   make[2]: *** [hotspot-server-libs] Error 1
   make[2]: *** Waiting for unfinished jobs....
   Compiling 396 files for BUILD_jdk.compiler.interim
   Compiling 226 files for BUILD_jdk.javadoc.interim
   
   ERROR: Build failed for target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2) 
   
   === Output from failing command(s) repeated here ===
   * For target hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch:
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp:29:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/classfile/classLoaderData.hpp:37,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/precompiled/precompiled.hpp:34:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/utilities/jfrTypes.hpp:28:36: fatal error: jfrfiles/jfrEventIds.hpp: No such file or directory
   compilation terminated.
   * For target hotspot_variant-server_libjvm_objs_precompiled_precompiled.hpp.gch:
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp:29:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/classfile/classLoaderData.hpp:37,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/precompiled/precompiled.hpp:34:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/utilities/jfrTypes.hpp:28:36: fatal error: jfrfiles/jfrEventIds.hpp: No such file or directory
   compilation terminated.
   
   * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs.
   === End of repeated output ===
   
   === Make failed targets repeated here ===
   lib/CompileJvm.gmk:172: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch' failed
   lib/CompileGtest.gmk:58: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/gtest/objs/precompiled/precompiled.hpp.gch' failed
   make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
   === End of repeated output ===
   
   Hint: Try searching the build log for the name of the first failed target.
   Hint: See doc/building.html#troubleshooting for assistance.
   
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:305: recipe for target 'main' failed
   make[1]: *** [main] Error 1
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed
   make: *** [images] Error 2

From dmitrij.pochepko at bell-sw.com  Tue Mar  5 12:32:48 2019
From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko)
Date: Tue, 5 Mar 2019 15:32:48 +0300
Subject: [aarch64-port-dev ] RFR: 8218749 - AARCH64: String compress
 intrinsic documentation and maintenance improvement
Message-ID: <899ed098-8179-0df3-41e4-b6ff5b5e73c6@bell-sw.com>

Hi all,

please review patch for JDK-8218749: AARCH64: String compress intrinsic 
documentation and maintenance improvement
webrev: http://cr.openjdk.java.net/~dpochepk/8218749/webrev.01/

This patch adds documentation with test and moves equivalent code 
generation into separate method. Documentation is both added into 
documentation block and inlined into code.

Testing:

- hotspot jtreg tests: compiler/*, gc/* and runtime/*
- jdk jtreg tests: tier1-tier3
- jck tests

No regression found.

I'd like to thank Pengfei Li for help in pre-review.

CR: https://bugs.openjdk.java.net/browse/JDK-8218749

Thanks,
Dmitrij


From ci_notify at linaro.org  Tue Mar  5 13:36:10 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Tue, 5 Mar 2019 13:36:10 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 887 Fixed
In-Reply-To: <2129691941.1842.1551784089113.JavaMail.jenkins@a6c5c67cda76>
References: <2129691941.1842.1551784089113.JavaMail.jenkins@a6c5c67cda76>
Message-ID: <1094654603.1852.1551792971469.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Fixed
Build details -  https://ci.linaro.org/job/jdkX-ci-build/887/

Changes -
  ihse: 4ae746de6b86575a9f8fb47876215e9ccbf3fc7a 
	- make/hotspot/gensrc/GensrcAdlc.gmk 
--"8220155: JDK-8219971 broke hotspot build
Reviewed-by: dholmes
"

Build output -
   Creating jdk.internal.le.jmod
   Creating jdk.internal.opt.jmod
   Creating jdk.internal.vm.ci.jmod
   Creating jdk.internal.vm.compiler.jmod
   Creating jdk.internal.vm.compiler.management.jmod
   Creating jdk.jartool.jmod
   Creating jdk.javadoc.jmod
   Creating jdk.jcmd.jmod
   Creating jdk.jconsole.jmod
   Creating jdk.jdeps.jmod
   Creating jdk.jdi.jmod
   Creating jdk.jdwp.agent.jmod
   Creating jdk.jfr.jmod
   Creating jdk.jshell.jmod
   Creating jdk.jsobject.jmod
   Creating jdk.jstatd.jmod
   Creating jdk.localedata.jmod
   Creating jdk.management.jmod
   Creating jdk.management.agent.jmod
   Creating jdk.management.jfr.jmod
   Creating jdk.naming.dns.jmod
   Creating jdk.naming.rmi.jmod
   Creating jdk.net.jmod
   Creating jdk.pack.jmod
   Creating jdk.rmic.jmod
   Creating jdk.scripting.nashorn.jmod
   Creating jdk.scripting.nashorn.shell.jmod
   Creating jdk.sctp.jmod
   Creating jdk.security.auth.jmod
   Creating jdk.security.jgss.jmod
   Creating jdk.unsupported.jmod
   Creating jdk.unsupported.desktop.jmod
   Creating jdk.xml.dom.jmod
   Creating jdk.zipfs.jmod
   Creating interim jimage
   Compiling 3 files for BUILD_DEMO_CodePointIM
   Updating support/demos/image/jfc/CodePointIM/src.zip
   Compiling 3 files for BUILD_DEMO_FileChooserDemo
   Updating support/demos/image/jfc/FileChooserDemo/src.zip
   Compiling 30 files for BUILD_DEMO_SwingSet2
   Updating support/demos/image/jfc/SwingSet2/src.zip
   Compiling 4 files for BUILD_DEMO_Font2DTest
   Updating support/demos/image/jfc/Font2DTest/src.zip
   Compiling 64 files for BUILD_DEMO_J2Ddemo
   Updating support/demos/image/jfc/J2Ddemo/src.zip
   Compiling 15 files for BUILD_DEMO_Metalworks
   Updating support/demos/image/jfc/Metalworks/src.zip
   Compiling 2 files for BUILD_DEMO_Notepad
   Updating support/demos/image/jfc/Notepad/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 5 files for BUILD_DEMO_Stylepad
   Updating support/demos/image/jfc/Stylepad/src.zip
   Compiling 5 files for BUILD_DEMO_SampleTree
   Updating support/demos/image/jfc/SampleTree/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 8 files for BUILD_DEMO_TableExample
   Updating support/demos/image/jfc/TableExample/src.zip
   Compiling 1 files for BUILD_DEMO_TransparentRuler
   Updating support/demos/image/jfc/TransparentRuler/src.zip
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar
   Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar
   Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar
   Creating support/demos/image/jfc/Metalworks/Metalworks.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/Notepad/Notepad.jar
   Creating support/demos/image/jfc/Stylepad/Stylepad.jar
   Creating support/demos/image/jfc/SampleTree/SampleTree.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/TableExample/TableExample.jar
   Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
   Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar
   Compiling 1 files for CLASSLIST_JAR
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar
   Creating support/classlist.jar
   Creating jdk.jlink.jmod
   Creating java.base.jmod
   Creating jdk image
   Creating CDS archive for jdk image
   Stopping sjavac server
   Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'

From derekw at marvell.com  Tue Mar  5 23:22:53 2019
From: derekw at marvell.com (Derek White)
Date: Tue, 5 Mar 2019 23:22:53 +0000
Subject: [aarch64-port-dev ] FYI: RFR: 8216350: AArch64: monitor unlock fast
 path not called
Message-ID: <MN2PR18MB2733AAE8008FF01AF0632B2FD2720@MN2PR18MB2733.namprd18.prod.outlook.com>

Hi Nick + Arm China Team,

This is to tie together some issues we've been following related to this fix.

We've been looking at a major performance regression in JDK 9 of more than 10% (SPECjbb critical) on ThunderX2. Andrey Sudnik tracked this down to support for ObjectInputFilters in JDK 9. This added a global lock in object deserialization. It was a very short lock ? basically a synchronized getter. This only gets painful under contention on many-core machines, where the lock definitely gets inflated and sometimes contended (even when the new feature is not used).

Your fix for JDK-8216350 reduced the regression in SPECjbb to only 4% or so (after back-porting to JDK 9+139). The new code in JDK 9 exactly matched the path that you fixed! I.E. a global lock eventually gets inflated given enough cores to hit the getter method, and from then on they take the slower (and broken) path.

So I wanted to acknowledge that your fix didn't just help some microbenchmarks, but also a fairly realistic transaction processing benchmark, and likely many actual applications. Great work!

For the remaining 4%:
I was able to identify a similar 4-6% regression on a 112 HW thread 2-socket Xeon Pentium due to the same global lock. Roger Riggs agrees that the global lock is not actually needed in the getter, and will be removing it. See JDK-8220166 ?Performance regression in deserialization (4-6% in SPECjbb)? for details: https://bugs.openjdk.java.net/browse/JDK-8220166

Note that this regression was not detected by Oracle's internal performance tracking system, mostly likely run on smaller x86 servers. This is a great example of the core-scaling issues that we'll keep running into on many-core Arm server chips.

I'm not sure if the fixes for JDK-8216350 or JDK-8220166 would qualify for a backport to JDK 11, but they would certainly help performance.

Thanks again,
 - Derek



From Pengfei.Li at arm.com  Wed Mar  6 02:05:58 2019
From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China))
Date: Wed, 6 Mar 2019 02:05:58 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <adb09e5c-b314-b203-9c58-5daafb8e2002@redhat.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <1341b8ab-1ab1-0270-86c4-5a4ac4945d03@oracle.com>
 <CAEgw74AK_0S1gUytmprHn9m3Sia35fMVTaS-SMrR8=7R8ksZLQ@mail.gmail.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <7194e0cc-0f4f-7348-7b50-1347acbf9f92@redhat.com>
 <8bf4cc54-6e66-fab4-b3fe-4b026780924d@redhat.com>
 <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>
 <DB7PR08MB31155785E141FD50CF00B84C96710@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <adb09e5c-b314-b203-9c58-5daafb8e2002@redhat.com>
Message-ID: <DB7PR08MB3115AC390426737D55ECA79496730@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi Andrew Dinn,

> What seems very odd to me is the difference between fmaxv and fminv.
> Both Q == 1 encodings (i.e. with sz in {0, 1}) are reserved for fmaxv.
> However, the encoding for fminv accepts both Q == 1 encodings with the
> expected interpretation.

In the latest published version of the ArmARM doc, I don't see such difference between fmaxv and fminv.
I guess what you have seen might be a bug of the previous version docs.

> Yes, I think it would probably be better to leave the assert in place and use
> the encoding implied by the SIMD_Arrangement parameter i.e. T2S ==>
> Q=1,sz=0 and T2D ==> Q=1, sz=1. That way the assert will catch errors in
> debug builds and non-debug builds should be stopped by a SIGILL exception.

Thanks, I will do this and post a new webrev in a new thread then.

--
Thanks,
Pengfei


From nick.gasson at arm.com  Wed Mar  6 08:42:13 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Wed, 6 Mar 2019 16:42:13 +0800
Subject: [aarch64-port-dev ] FYI: RFR: 8216350: AArch64: monitor unlock
 fast path not called
In-Reply-To: <MN2PR18MB2733AAE8008FF01AF0632B2FD2720@MN2PR18MB2733.namprd18.prod.outlook.com>
References: <MN2PR18MB2733AAE8008FF01AF0632B2FD2720@MN2PR18MB2733.namprd18.prod.outlook.com>
Message-ID: <76d6930e-c993-7018-e44e-a5d5232b583d@arm.com>

Hi Derek,

Thanks for doing this testing!

 > I'm not sure if the fixes for JDK-8216350 or JDK-8220166 would 
qualify for a backport to JDK 11, but they would certainly help performance.

The patch for 8216350 doesn't apply cleanly on 11u, but it should be 
easy to fix up. It's up to Andrew of course to decide whether it's worth 
backporting though...

Thanks,
Nick

On 06/03/2019 07:22, Derek White wrote:
> Hi Nick + Arm China Team,
> 
> This is to tie together some issues we've been following related to this fix.
> 
> We've been looking at a major performance regression in JDK 9 of more than 10% (SPECjbb critical) on ThunderX2. Andrey Sudnik tracked this down to support for ObjectInputFilters in JDK 9. This added a global lock in object deserialization. It was a very short lock ? basically a synchronized getter. This only gets painful under contention on many-core machines, where the lock definitely gets inflated and sometimes contended (even when the new feature is not used).
> 
> Your fix for JDK-8216350 reduced the regression in SPECjbb to only 4% or so (after back-porting to JDK 9+139). The new code in JDK 9 exactly matched the path that you fixed! I.E. a global lock eventually gets inflated given enough cores to hit the getter method, and from then on they take the slower (and broken) path.
> 
> So I wanted to acknowledge that your fix didn't just help some microbenchmarks, but also a fairly realistic transaction processing benchmark, and likely many actual applications. Great work!
> 
> For the remaining 4%:
> I was able to identify a similar 4-6% regression on a 112 HW thread 2-socket Xeon Pentium due to the same global lock. Roger Riggs agrees that the global lock is not actually needed in the getter, and will be removing it. See JDK-8220166 ?Performance regression in deserialization (4-6% in SPECjbb)? for details: https://bugs.openjdk.java.net/browse/JDK-8220166
> 
> Note that this regression was not detected by Oracle's internal performance tracking system, mostly likely run on smaller x86 servers. This is a great example of the core-scaling issues that we'll keep running into on many-core Arm server chips.
> 
> I'm not sure if the fixes for JDK-8216350 or JDK-8220166 would qualify for a backport to JDK 11, but they would certainly help performance.
> 
> Thanks again,
>   - Derek
> 
> 

From tobias.hartmann at oracle.com  Wed Mar  6 09:08:25 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 6 Mar 2019 10:08:25 +0100
Subject: [aarch64-port-dev ] RFR (trivial): 8219519: Remove
 linux_sparc.ad and linux_aarch64.ad
In-Reply-To: <d7596b55-68e7-0218-c06d-26c8c6ba39e8@loongson.cn>
References: <900ea372-d9fd-e1fd-051d-3d96e1ec2c66@loongson.cn>
 <9c080917-84eb-ba84-5951-f159b103e6ed@oracle.com>
 <44494f4f-26ef-3b9e-b38e-eca8178aba89@loongson.cn>
 <DB7PR08MB3115571D0D02DC1CABAC7DE696740@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <dcfe1b85-68c9-ee1a-b715-2b70f5eaef6f@loongson.cn>
 <3134c5a6-0a16-5091-6e09-b6c3c347c84c@oracle.com>
 <d9b00192-2643-5828-7fdc-600f4b19f0e6@loongson.cn>
 <d7596b55-68e7-0218-c06d-26c8c6ba39e8@loongson.cn>
Message-ID: <f797ab6b-3f08-746e-2934-388ce4430b4f@oracle.com>

Hi Jie,

sorry, I was out of the office. Pushed.

Best regards,
Tobias

On 28.02.19 02:57, Jie Fu wrote:
> Hi Tobias,
> 
> I have exported the patch in the attachment.
> Could you please push it for me?
> Thanks a lot.
> 
> Best regards,
> Jie
> 
> On 2019/2/27 ??9:05, Jie Fu wrote:
>> Hi Tobias,
>>
>> Thanks for your review.
>> Could you please sponsor it or find a sponsor for me?
>> Thanks a lot.
>>
>> Best regards,
>> Jie
>>
>>
>> On 2019?02?27? 18:03, Tobias Hartmann wrote:
>>> On 27.02.19 06:31, Jie Fu wrote:
>>>> As for the linux_sparc.ad, it is actually empty for the adlc compiler.
>>>> It should be safe too.
>>>>
>>>> Tobias, is it still required to test it on the sparc platform?
>>>> Thanks.
>>> No, I think it's good to go.
>>>
>>> Best regards,
>>> Tobias
>>

From fujie at loongson.cn  Wed Mar  6 09:14:03 2019
From: fujie at loongson.cn (Jie Fu)
Date: Wed, 6 Mar 2019 17:14:03 +0800
Subject: [aarch64-port-dev ] RFR (trivial): 8219519: Remove
 linux_sparc.ad and linux_aarch64.ad
In-Reply-To: <f797ab6b-3f08-746e-2934-388ce4430b4f@oracle.com>
References: <900ea372-d9fd-e1fd-051d-3d96e1ec2c66@loongson.cn>
 <9c080917-84eb-ba84-5951-f159b103e6ed@oracle.com>
 <44494f4f-26ef-3b9e-b38e-eca8178aba89@loongson.cn>
 <DB7PR08MB3115571D0D02DC1CABAC7DE696740@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <dcfe1b85-68c9-ee1a-b715-2b70f5eaef6f@loongson.cn>
 <3134c5a6-0a16-5091-6e09-b6c3c347c84c@oracle.com>
 <d9b00192-2643-5828-7fdc-600f4b19f0e6@loongson.cn>
 <d7596b55-68e7-0218-c06d-26c8c6ba39e8@loongson.cn>
 <f797ab6b-3f08-746e-2934-388ce4430b4f@oracle.com>
Message-ID: <9d9d6f36-2eec-bd9d-0f74-98af70506e5f@loongson.cn>

Thank you so much, Tobias.

On 2019/3/6 ??5:08, Tobias Hartmann wrote:
> Hi Jie,
>
> sorry, I was out of the office. Pushed.
>
> Best regards,
> Tobias
>
> On 28.02.19 02:57, Jie Fu wrote:
>> Hi Tobias,
>>
>> I have exported the patch in the attachment.
>> Could you please push it for me?
>> Thanks a lot.
>>
>> Best regards,
>> Jie
>>
>> On 2019/2/27 ??9:05, Jie Fu wrote:
>>> Hi Tobias,
>>>
>>> Thanks for your review.
>>> Could you please sponsor it or find a sponsor for me?
>>> Thanks a lot.
>>>
>>> Best regards,
>>> Jie
>>>
>>>
>>> On 2019?02?27? 18:03, Tobias Hartmann wrote:
>>>> On 27.02.19 06:31, Jie Fu wrote:
>>>>> As for the linux_sparc.ad, it is actually empty for the adlc compiler.
>>>>> It should be safe too.
>>>>>
>>>>> Tobias, is it still required to test it on the sparc platform?
>>>>> Thanks.
>>>> No, I think it's good to go.
>>>>
>>>> Best regards,
>>>> Tobias


From aph at redhat.com  Wed Mar  6 09:16:27 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 6 Mar 2019 09:16:27 +0000
Subject: [aarch64-port-dev ] FYI: RFR: 8216350: AArch64: monitor unlock
 fast path not called
In-Reply-To: <MN2PR18MB2733AAE8008FF01AF0632B2FD2720@MN2PR18MB2733.namprd18.prod.outlook.com>
References: <MN2PR18MB2733AAE8008FF01AF0632B2FD2720@MN2PR18MB2733.namprd18.prod.outlook.com>
Message-ID: <a7560210-1de9-3a41-5db9-5e823a450b7a@redhat.com>

On 3/5/19 11:22 PM, Derek White wrote:
> I'm not sure if the fixes for JDK-8216350 or JDK-8220166 would qualify for a backport to JDK 11, but they would certainly help performance.

Great work! Yes, they would qualify.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From dmitrij.pochepko at bell-sw.com  Wed Mar  6 15:17:58 2019
From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko)
Date: Wed, 6 Mar 2019 18:17:58 +0300
Subject: [aarch64-port-dev ] RFR: 8219366: AARCH64: String inflate intrinsic
 documentation and maintenance improvement
Message-ID: <7d875294-dbb4-1e15-4064-2d801c7b6f8d@bell-sw.com>

Hi all,

Please review patch for 8219366: AARCH64: String inflate intrinsic 
documentation and maintenance improvement
webrev: http://cr.openjdk.java.net/~dpochepk/8219366/webrev.01/

Patch includes:
- documentation
- new jtreg test
- label names are now uppercase

Since no code was changed, only sanity tests were executed (hotspot 
jtreg compiler/* including new test).
No regressions found.

I'd like to thank Pengfei Li for help in pre-review.

CR: https://bugs.openjdk.java.net/browse/JDK-8219366

Thanks,
Dmitrij


From aph at redhat.com  Wed Mar  6 15:23:22 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 6 Mar 2019 15:23:22 +0000
Subject: [aarch64-port-dev ] 8219993: AArch64: Compiled CI stubs are
	unsafely modified
Message-ID: <3abc4b04-a6d4-62f7-4cd9-36a89fe020e4@redhat.com>

According to the Arm manual, except in a few limited cases it is not
safe to modify code while it is being executed. We mostly get this
right, but our CompiledStaticCall stubs are patched at runtime by
rewriting immediate loads. We can fix this by moving the rewritable
data fields into memory so that they are loaded by means of load(mem)
rather than mov(immediate data).

After this patch, CI stubs look like:

      dmb ld
      ldr rmethod, L1
      ldr rscratch1, L2
      br [rscratch1]
L1:   .data 0
L2:   .data 0

When we modify such a stub we rewrite the two data fields to the
method metadata and the interpreter entry point, execute a memory
fence, then rewrite the compiled jump to point to the stub.

http://cr.openjdk.java.net/~aph/8219006.1/

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From ci_notify at linaro.org  Wed Mar  6 22:19:17 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Wed, 6 Mar 2019 22:19:17 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <1844084614.2062.1551910758289.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/065/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/28 pass: 5,533; fail: 6; error: 1; not run: 93
Build 1: aarch64/2019/jan/30 pass: 5,527; fail: 5; error: 2; not run: 93
Build 2: aarch64/2019/feb/04 pass: 5,527; fail: 7; error: 2; not run: 93
Build 3: aarch64/2019/feb/06 pass: 5,532; fail: 4; error: 1; not run: 93
Build 4: aarch64/2019/feb/08 pass: 5,519; fail: 19; error: 2; not run: 93
Build 5: aarch64/2019/feb/11 pass: 5,527; fail: 11; error: 2; not run: 93
Build 6: aarch64/2019/feb/13 pass: 5,537; fail: 4; not run: 93
Build 7: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 8: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 9: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 10: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 11: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 12: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93
Build 13: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93
Build 14: aarch64/2019/mar/06 pass: 5,544; fail: 3; not run: 93

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/28 pass: 8,543; fail: 496; error: 20
Build 1: aarch64/2019/jan/30 pass: 8,541; fail: 503; error: 19
Build 2: aarch64/2019/feb/04 pass: 8,539; fail: 506; error: 18
Build 3: aarch64/2019/feb/06 pass: 8,537; fail: 499; error: 27
Build 4: aarch64/2019/feb/08 pass: 8,530; fail: 515; error: 23
Build 5: aarch64/2019/feb/11 pass: 8,559; fail: 490; error: 15
Build 6: aarch64/2019/feb/13 pass: 8,534; fail: 512; error: 18
Build 7: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 8: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 9: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 10: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 11: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 12: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20
Build 13: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20
Build 14: aarch64/2019/mar/06 pass: 8,541; fail: 506; error: 21

2 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/28 pass: 3,994; fail: 1
Build 1: aarch64/2019/jan/30 pass: 3,994; fail: 1
Build 2: aarch64/2019/feb/04 pass: 3,994; fail: 1
Build 3: aarch64/2019/feb/06 pass: 3,994; fail: 1
Build 4: aarch64/2019/feb/08 pass: 3,994; fail: 1
Build 5: aarch64/2019/feb/11 pass: 3,994; fail: 1
Build 6: aarch64/2019/feb/13 pass: 3,994; fail: 1
Build 7: aarch64/2019/feb/15 pass: 3,995
Build 8: aarch64/2019/feb/18 pass: 3,996
Build 9: aarch64/2019/feb/20 pass: 3,996
Build 10: aarch64/2019/feb/25 pass: 3,931
Build 11: aarch64/2019/feb/27 pass: 3,931
Build 12: aarch64/2019/mar/01 pass: 3,931
Build 13: aarch64/2019/mar/04 pass: 3,931
Build 14: aarch64/2019/mar/06 pass: 3,931

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.80x
Relative performance: Server critical-jOPS (nc): 9.45x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 207.57

Server 207.57 / Server 2014-04-01 (71.00): 2.92x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-01-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/028/results/
2019-01-31 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/030/results/
2019-02-05 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/035/results/
2019-02-07 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/037/results/
2019-02-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/039/results/
2019-02-12 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/042/results/
2019-02-14 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/044/results/
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/065/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From Pengfei.Li at arm.com  Thu Mar  7 09:26:46 2019
From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China))
Date: Thu, 7 Mar 2019 09:26:46 +0000
Subject: [aarch64-port-dev ] RFR(S): 8214922: Add vectorization support
 for fmin/fmax
In-Reply-To: <DB7PR08MB3115418F2B1993557DF7EA6196840@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115055477478B62D825C36196BE0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <87d0pv2iow.fsf@redhat.com> <c836cf2e-20a9-0ec4-212d-72326fb144a6@redhat.com>
 <877eg32bzq.fsf@redhat.com> <b91e56a1-dd8f-d9f1-40e8-af5d8c3c0d9d@redhat.com>
 <871s6a3map.fsf@redhat.com>
 <DB7PR08MB3115C5F108D17017B98A1FF796B40@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <87va371n6b.fsf@redhat.com>
 <DB7PR08MB3115836C7236BFBDC988D729968E0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <DB7PR08MB3115E7B38864A31A1F60DE50968B0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <40d1a9a7-47f3-4e13-032d-70932b03d215@redhat.com>
 <DB7PR08MB3115418F2B1993557DF7EA6196840@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <DB7PR08MB311513257A35EC4057EECD28964C0@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi Andrew Dinn,

Please see below updated webrev for the pending patch of fmin/fmax vectorization.
The only difference between webrev.03 and webrev.02 is the hard-coded arrangement bits in fmaxv/fminv encodings are replaced.

webrev: http://cr.openjdk.java.net/~pli/rfr/8214922/webrev.03/
JBS: https://bugs.openjdk.java.net/browse/JDK-8214922

--
Thanks,
Pengfei


From stuart.monteith at linaro.org  Thu Mar  7 11:36:07 2019
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Thu, 7 Mar 2019 11:36:07 +0000
Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far
In-Reply-To: <875zw9k63l.fsf@redhat.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com>
 <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
Message-ID: <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>

Hello,
   I've put here the three patches required for ZGC on Aarch64:

https://cr.openjdk.java.net/~smonteith/zgc/20190307/

In order of application they are:
 oop64-20190307/  - Which introduces the Use64BitLiteralAddresses
option, which make the generated code use 64-bit literals, rather than
48-bit literals.
 zgc-20190307/    - Which implements the missing code for implementing
ZGC on aarch64.
 roland-membar-20190307/   - Is a fix for handling memory barriers in
C2 by Roland Westerlin.

The zgc patch matches the x86 code pretty closely - since the last
round of reviews it has removed a lot of unnecessary code. There is
still some questionable code tagged "SRDM". Specficially the envvar
"SRDM_STORE_BREAK" can be set to generate a trap in the ZGC store
barrier., and the cache line size is assumed to be 64 bit, whereas
this can be a variable, etc.

The code has been updated to match the latest changes. However,
concurrent class unloading is currently unimplemented, and so is
disabled when ZGC is enabled.

There is an issue with C1 - the changes in "8217717: ZGC: Broken oop
map in C1 load barrier stub" did regress things somewhat causing
crashes with stale references. However, As patching on aarch64 C1
isn't really supported, I'm not satisfied it was working correctly
before. Patching lea may impractical as things stand today.

Passing -XX:+UseZGC doens't disable C1, so you'll need to also pass
-XX:-TieredCompilation , if you want to avoid the C1 problems. There
is code to make sure AOT/JVMCI is not enabled.

With SPECjbb2015 on my particular hardware, the results are broadly in
line with what was presented by Oracle on x86. With ZGC, critical-jOPS
is almost 80% of max-jOPS, On G1GC on my machine that figure is about
35%. The max-jOPS of both are within 2% of each other.

BR,
   Stuart



On Tue, 4 Dec 2018 at 09:13, Roland Westrelin <rwestrel at redhat.com> wrote:
>
>
> > Which two cas do you mean are the same?
>
> As I understand, with ZGC, Unsafe.compareAndSetReference() is compiled
> as a cas followed by a test for the result of the cas and on failure,
> ZGC barriers are applied and the cas is attempted again.
>
> Roland.

From ci_notify at linaro.org  Fri Mar  8 02:11:16 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Fri, 8 Mar 2019 02:11:16 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64
Message-ID: <385615344.2292.1552011076664.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/066/summary.html
 
-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/22 pass: 5,709; fail: 9; not run: 11,618
Build 1: aarch64/2019/jan/24 pass: 5,708; fail: 10; not run: 11,618
Build 2: aarch64/2019/jan/29 pass: 5,709; fail: 9; not run: 11,618
Build 3: aarch64/2019/jan/31 pass: 5,707; fail: 11; not run: 11,618
Build 4: aarch64/2019/feb/02 pass: 5,708; fail: 10; not run: 11,618
Build 5: aarch64/2019/feb/07 pass: 5,710; fail: 9; not run: 11,618
Build 6: aarch64/2019/feb/09 pass: 5,710; fail: 9; not run: 11,618
Build 7: aarch64/2019/feb/12 pass: 5,709; fail: 10; not run: 11,618
Build 8: aarch64/2019/feb/16 pass: 5,713; fail: 10; not run: 11,618
Build 9: aarch64/2019/feb/19 pass: 5,715; fail: 10; not run: 11,618
Build 10: aarch64/2019/feb/21 pass: 5,714; fail: 11; not run: 11,618
Build 11: aarch64/2019/feb/26 pass: 5,717; fail: 9; not run: 11,618
Build 12: aarch64/2019/mar/02 pass: 5,717; fail: 11; not run: 11,618
Build 13: aarch64/2019/mar/05 pass: 5,719; fail: 9; not run: 11,618
Build 14: aarch64/2019/mar/07 pass: 5,719; fail: 9; not run: 11,618

1 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/22 pass: 8,369; fail: 506; error: 23
Build 1: aarch64/2019/jan/24 pass: 8,366; fail: 507; error: 25
Build 2: aarch64/2019/jan/29 pass: 8,353; fail: 524; error: 22
Build 3: aarch64/2019/jan/31 pass: 8,372; fail: 502; error: 25
Build 4: aarch64/2019/feb/02 pass: 8,378; fail: 501; error: 21
Build 5: aarch64/2019/feb/07 pass: 8,364; fail: 507; error: 29
Build 6: aarch64/2019/feb/09 pass: 8,354; fail: 523; error: 23
Build 7: aarch64/2019/feb/12 pass: 8,358; fail: 519; error: 24
Build 8: aarch64/2019/feb/16 pass: 8,356; fail: 520; error: 25
Build 9: aarch64/2019/feb/19 pass: 8,375; fail: 506; error: 24
Build 10: aarch64/2019/feb/21 pass: 8,377; fail: 513; error: 22
Build 11: aarch64/2019/feb/26 pass: 8,387; fail: 501; error: 26
Build 12: aarch64/2019/mar/02 pass: 8,400; fail: 487; error: 29
Build 13: aarch64/2019/mar/05 pass: 8,413; fail: 487; error: 16
Build 14: aarch64/2019/mar/07 pass: 8,388; fail: 502; error: 26

2 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/22 pass: 3,903
Build 1: aarch64/2019/jan/24 pass: 3,903
Build 2: aarch64/2019/jan/29 pass: 3,903
Build 3: aarch64/2019/jan/31 pass: 3,903
Build 4: aarch64/2019/feb/02 pass: 3,903
Build 5: aarch64/2019/feb/07 pass: 3,903
Build 6: aarch64/2019/feb/09 pass: 3,903
Build 7: aarch64/2019/feb/12 pass: 3,903
Build 8: aarch64/2019/feb/16 pass: 3,903
Build 9: aarch64/2019/feb/19 pass: 3,903
Build 10: aarch64/2019/feb/21 pass: 3,904
Build 11: aarch64/2019/feb/26 pass: 3,904
Build 12: aarch64/2019/mar/02 pass: 3,904
Build 13: aarch64/2019/mar/05 pass: 3,904
Build 14: aarch64/2019/mar/07 pass: 3,904

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 6.96x
Relative performance: Server critical-jOPS (nc): 7.60x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 207.57

Server 207.57 / Server 2014-04-01 (71.00): 2.92x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-01-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/022/results/
2019-01-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/024/results/
2019-01-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/029/results/
2019-02-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/031/results/
2019-02-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/033/results/
2019-02-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/038/results/
2019-02-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/040/results/
2019-02-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/043/results/
2019-02-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/047/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/050/results/
2019-02-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/052/results/
2019-02-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/057/results/
2019-03-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/061/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/064/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/066/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/

From aph at redhat.com  Fri Mar  8 16:19:01 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Mar 2019 16:19:01 +0000
Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far
In-Reply-To: <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com> <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
Message-ID: <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>

On 3/7/19 11:36 AM, Stuart Monteith wrote:
> There is an issue with C1 - the changes in "8217717: ZGC: Broken oop
> map in C1 load barrier stub" did regress things somewhat causing
> crashes with stale references. However, As patching on aarch64 C1
> isn't really supported, I'm not satisfied it was working correctly
> before. Patching lea may impractical as things stand today.

I can't get it to fail. Please tell me exactly what I have to do to
demonstrate the C1 failure.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Fri Mar  8 16:32:55 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Mar 2019 16:32:55 +0000
Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far
In-Reply-To: <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com> <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
Message-ID: <8ce9b487-dea0-cafe-f909-f6581834d23a@redhat.com>

On 3/8/19 4:19 PM, Andrew Haley wrote:
> I can't get it to fail. 

NM, found a case now.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From stuart.monteith at linaro.org  Fri Mar  8 16:34:38 2019
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Fri, 8 Mar 2019 16:34:38 +0000
Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far
In-Reply-To: <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com>
 <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
Message-ID: <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>

Hi,
   I find when running with -XX:TieredStopAtLevel=1 and ZGC enabled it
fails when running with Lucene's indexing demo
"org.apache.lucene.demo.IndexFiles" or SPECjbb2015.
I tried javac, and other simple examples, but I haven't managed to
find anything simple that provokes the issue.

I've uploaded this here:
  http://cr.openjdk.java.net/~smonteith/zgc/Lucene-demo.tar.xz

If you have the appropriate java command on your patch, if you run
"index.sh" with a directory of files index as the parameter, it will
reproduce the problem.


BR,
   Stuart

On Fri, 8 Mar 2019 at 16:19, Andrew Haley <aph at redhat.com> wrote:
>
> On 3/7/19 11:36 AM, Stuart Monteith wrote:
> > There is an issue with C1 - the changes in "8217717: ZGC: Broken oop
> > map in C1 load barrier stub" did regress things somewhat causing
> > crashes with stale references. However, As patching on aarch64 C1
> > isn't really supported, I'm not satisfied it was working correctly
> > before. Patching lea may impractical as things stand today.
>
> I can't get it to fail. Please tell me exactly what I have to do to
> demonstrate the C1 failure.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From ci_notify at linaro.org  Fri Mar  8 22:09:53 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Fri, 8 Mar 2019 22:09:53 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <55884777.2437.1552082994204.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/067/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/30 pass: 5,527; fail: 5; error: 2; not run: 93
Build 1: aarch64/2019/feb/04 pass: 5,527; fail: 7; error: 2; not run: 93
Build 2: aarch64/2019/feb/06 pass: 5,532; fail: 4; error: 1; not run: 93
Build 3: aarch64/2019/feb/08 pass: 5,519; fail: 19; error: 2; not run: 93
Build 4: aarch64/2019/feb/11 pass: 5,527; fail: 11; error: 2; not run: 93
Build 5: aarch64/2019/feb/13 pass: 5,537; fail: 4; not run: 93
Build 6: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 7: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 8: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 9: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 10: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 11: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93
Build 12: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93
Build 13: aarch64/2019/mar/06 pass: 5,544; fail: 3; not run: 93
Build 14: aarch64/2019/mar/08 pass: 5,546; fail: 3; not run: 93

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/30 pass: 8,541; fail: 503; error: 19
Build 1: aarch64/2019/feb/04 pass: 8,539; fail: 506; error: 18
Build 2: aarch64/2019/feb/06 pass: 8,537; fail: 499; error: 27
Build 3: aarch64/2019/feb/08 pass: 8,530; fail: 515; error: 23
Build 4: aarch64/2019/feb/11 pass: 8,559; fail: 490; error: 15
Build 5: aarch64/2019/feb/13 pass: 8,534; fail: 512; error: 18
Build 6: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 7: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 8: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 9: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 10: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 11: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20
Build 12: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20
Build 13: aarch64/2019/mar/06 pass: 8,541; fail: 506; error: 21
Build 14: aarch64/2019/mar/08 pass: 8,538; fail: 512; error: 20

2 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/30 pass: 3,994; fail: 1
Build 1: aarch64/2019/feb/04 pass: 3,994; fail: 1
Build 2: aarch64/2019/feb/06 pass: 3,994; fail: 1
Build 3: aarch64/2019/feb/08 pass: 3,994; fail: 1
Build 4: aarch64/2019/feb/11 pass: 3,994; fail: 1
Build 5: aarch64/2019/feb/13 pass: 3,994; fail: 1
Build 6: aarch64/2019/feb/15 pass: 3,995
Build 7: aarch64/2019/feb/18 pass: 3,996
Build 8: aarch64/2019/feb/20 pass: 3,996
Build 9: aarch64/2019/feb/25 pass: 3,931
Build 10: aarch64/2019/feb/27 pass: 3,931
Build 11: aarch64/2019/mar/01 pass: 3,931
Build 12: aarch64/2019/mar/04 pass: 3,931
Build 13: aarch64/2019/mar/06 pass: 3,931
Build 14: aarch64/2019/mar/08 pass: 3,931

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.71x
Relative performance: Server critical-jOPS (nc): 9.24x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 204.57

Server 204.57 / Server 2014-04-01 (71.00): 2.88x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-01-31 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/030/results/
2019-02-05 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/035/results/
2019-02-07 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/037/results/
2019-02-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/039/results/
2019-02-12 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/042/results/
2019-02-14 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/044/results/
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/065/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/067/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From adinn at redhat.com  Mon Mar 11 09:51:57 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 11 Mar 2019 09:51:57 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <DB7PR08MB3115AC390426737D55ECA79496730@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <7194e0cc-0f4f-7348-7b50-1347acbf9f92@redhat.com>
 <8bf4cc54-6e66-fab4-b3fe-4b026780924d@redhat.com>
 <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>
 <DB7PR08MB31155785E141FD50CF00B84C96710@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <adb09e5c-b314-b203-9c58-5daafb8e2002@redhat.com>
 <DB7PR08MB3115AC390426737D55ECA79496730@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <553b872f-786c-951c-5c98-7db6993f02be@redhat.com>

On 06/03/2019 02:05, Pengfei Li (Arm Technology China) wrote:
> Hi Andrew Dinn,
> 
>> What seems very odd to me is the difference between fmaxv and
>> fminv. Both Q == 1 encodings (i.e. with sz in {0, 1}) are reserved
>> for fmaxv. However, the encoding for fminv accepts both Q == 1
>> encodings with the expected interpretation.
> 
> In the latest published version of the ArmARM doc, I don't see such
> difference between fmaxv and fminv. I guess what you have seen might
> be a bug of the previous version docs.

Ok, I'm not sure what documentation you are looking at so I need to
explain where I am getting my information. Up until today I have been
using the Arm ARM C.a which is dated 20 December 2017. I just downloaded
and checked the Arm ARM D.a dated 31 October 2018 which i think is the
latest version. It shows the same difference between fmaxv and fminv in
the same section of the manual.

Looking at the 2018 manual (D.a) the details are on pages C7-1501
onwards. For fmaxv it says under this heading:

  Single-precision and double-precision variant

  . . .

  Decode for this encoding
  integer d = UInt(Rd);
  integer n = UInt(Rn);
  if sz:Q != '01' then UNDEFINED;
  integer esize = 32 << UInt(sz);
  integer datasize = if Q == '1' then 128 else 64;

  . . .

and then on page C7-1502 it says

  <T>
    . . .
   For the single-precision and double-precision variant: is an
arrangement specifier, encoded in the "Q:sz" field. It can have the
following values:
    4S     when Q = 1 , sz = 0
    The following encodings are reserved:
    ? Q = 0 , sz = x .
    ? Q = 1 , sz = 1 .

However, for fminv on page C7-1502 it says under the following heading

  Single-precision and double-precision variant

  Decode for this encoding
  integer d = UInt(Rd);
  integer n = UInt(Rn);
  integer m = UInt(Rm);
  if sz:Q == '10' then UNDEFINED;
  integer esize = 32 << UInt(sz);
  integer datasize = if Q == '1' then 128 else 64;
  integer elements = datasize DIV esize;

and later on page C7-1503 it says

  <T>
    . . .
    For the single-precision and double-precision variant: is an
arrangement specifier, encoded in the "sz:Q" field. It can have the
following values:
    2S     when sz = 0 , Q = 0
    4S     when sz = 0 , Q = 1
    2D     when sz = 1 , Q = 1
    The encoding sz = 1 , Q = 0 is reserved.

Do you have a later version of the manual than D.a? If not, are you
looking at some other part of the manual? Note that the first decode is
undefined if sz:Q != '01' and the second is UNDEFINED if sz:Q == '01'.

>> Yes, I think it would probably be better to leave the assert in
>> place and use the encoding implied by the SIMD_Arrangement
>> parameter i.e. T2S ==> Q=1,sz=0 and T2D ==> Q=1, sz=1. That way the
>> assert will catch errors in debug builds and non-debug builds
>> should be stopped by a SIGILL exception.
> 
> Thanks, I will do this and post a new webrev in a new thread then.

Ok, thank you.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From Pengfei.Li at arm.com  Mon Mar 11 10:32:37 2019
From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China))
Date: Mon, 11 Mar 2019 10:32:37 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <553b872f-786c-951c-5c98-7db6993f02be@redhat.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <CAEgw74DUAfDpu6a3H9rbKFV3rtmJ7nFRO1sz14j93SkwyhPCpw@mail.gmail.com>
 <35c1db6b-a238-1e1e-9986-3d1a31b00bc2@redhat.com>
 <CAEgw74Dq=JUt4wirHpgMKstT93Y5ACxPbv==2w+1GzZHVRrJbg@mail.gmail.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <7194e0cc-0f4f-7348-7b50-1347acbf9f92@redhat.com>
 <8bf4cc54-6e66-fab4-b3fe-4b026780924d@redhat.com>
 <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>
 <DB7PR08MB31155785E141FD50CF00B84C96710@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <adb09e5c-b314-b203-9c58-5daafb8e2002@redhat.com>
 <DB7PR08MB3115AC390426737D55ECA79496730@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <553b872f-786c-951c-5c98-7db6993f02be@redhat.com>
Message-ID: <DB7PR08MB31153BE396B057489D9D8EC396480@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi Andrew Dinn,

> Do you have a later version of the manual than D.a? If not, are you looking at
> some other part of the manual? Note that the first decode is undefined if
> sz:Q != '01' and the second is UNDEFINED if sz:Q == '01'.

Ah~ Perhaps the armARM doc is hard to read sometimes.

In the D.a version:
- The FMAXV instruction is defined in section C7.2.103 on page 1501-1502.
- The FMINV instruction is defined in section C7.2.113 on page 1521-1522.
- Section C7.2.104 which follows the FMAXV section defines the "FMIN (vector)" instruction. This is actually the binary vector operation, not used for reduction fmin.

The armARM just sorts these sections in alphabetical order. Opposite instructions are not necessarily adjacent.

> > Thanks, I will do this and post a new webrev in a new thread then.
> 
> Ok, thank you.

I've already posted it in a new thread. See
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-March/007039.html

--
Thanks,
Pengfei


From adinn at redhat.com  Mon Mar 11 11:30:59 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 11 Mar 2019 11:30:59 +0000
Subject: [aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point
 Math.min/max intrinsics, approval request
In-Reply-To: <DB7PR08MB31153BE396B057489D9D8EC396480@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB1A70A33@FMSMSX126.amr.corp.intel.com>
 <3a850f71-0c13-135b-5150-4bdf46654a74@oracle.com>
 <CAEgw74A8pnn7kqgLE_1T878y3skpFAaa7fDvHREC6cOHYWcc8g@mail.gmail.com>
 <806a3da6-7125-0ce3-4ec5-d352d7bdcf50@oracle.com>
 <CAEgw74BvwxB0BepZdffZxuckOT=xau9_rMioAUP32NPkbjRn8g@mail.gmail.com>
 <A66BBE673E08E1428E3A918AE4D5B32CEE9AB1@BGSMSX106.gar.corp.intel.com>
 <0ebdb182-2b44-207d-81b7-e1dc1d19150e@oracle.com>
 <7194e0cc-0f4f-7348-7b50-1347acbf9f92@redhat.com>
 <8bf4cc54-6e66-fab4-b3fe-4b026780924d@redhat.com>
 <a5521e42-c1f5-2996-1e89-6268f34356ea@redhat.com>
 <DB7PR08MB31155785E141FD50CF00B84C96710@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <adb09e5c-b314-b203-9c58-5daafb8e2002@redhat.com>
 <DB7PR08MB3115AC390426737D55ECA79496730@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <553b872f-786c-951c-5c98-7db6993f02be@redhat.com>
 <DB7PR08MB31153BE396B057489D9D8EC396480@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <606ea437-99f4-1d0a-f03b-28f069c9e20d@redhat.com>

Hi Pengfei,

On 11/03/2019 10:32, Pengfei Li (Arm Technology China) wrote:
> Ah~ Perhaps the armARM doc is hard to read sometimes.

Doh! It is obviously difficult for me to read :-)

> In the D.a version: - The FMAXV instruction is defined in section
> C7.2.103 on page 1501-1502. - The FMINV instruction is defined in
> section C7.2.113 on page 1521-1522. - Section C7.2.104 which follows
> the FMAXV section defines the "FMIN (vector)" instruction. This is
> actually the binary vector operation, not used for reduction fmin.
> 
> The armARM just sorts these sections in alphabetical order. Opposite
> instructions are not necessarily adjacent.

Thank you for the correction!

> I've already posted it in a new thread. See 
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-March/007039.html

Yes, got it. I will reply in that thread.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From adinn at redhat.com  Mon Mar 11 11:39:20 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 11 Mar 2019 11:39:20 +0000
Subject: [aarch64-port-dev ] RFR(S): 8214922: Add vectorization support
 for fmin/fmax
In-Reply-To: <DB7PR08MB311513257A35EC4057EECD28964C0@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115055477478B62D825C36196BE0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <87d0pv2iow.fsf@redhat.com> <c836cf2e-20a9-0ec4-212d-72326fb144a6@redhat.com>
 <877eg32bzq.fsf@redhat.com> <b91e56a1-dd8f-d9f1-40e8-af5d8c3c0d9d@redhat.com>
 <871s6a3map.fsf@redhat.com>
 <DB7PR08MB3115C5F108D17017B98A1FF796B40@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <87va371n6b.fsf@redhat.com>
 <DB7PR08MB3115836C7236BFBDC988D729968E0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <DB7PR08MB3115E7B38864A31A1F60DE50968B0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <40d1a9a7-47f3-4e13-032d-70932b03d215@redhat.com>
 <DB7PR08MB3115418F2B1993557DF7EA6196840@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <DB7PR08MB311513257A35EC4057EECD28964C0@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <954d6760-a914-747b-aab5-b928490510a4@redhat.com>

hI pENGFEI,

On 07/03/2019 09:26, Pengfei Li (Arm Technology China) wrote:
> Please see below updated webrev for the pending patch of fmin/fmax
> vectorization.
> The only difference between webrev.03 and webrev.02 is the
> hard-coded
> arrangement bits in fmaxv/fminv encodings are replaced.
>  
> webrev: http://cr.openjdk.java.net/~pli/rfr/8214922/webrev.03/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8214922
Yes, that looks good to push. Thanks.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From aph at redhat.com  Mon Mar 11 15:04:12 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 11 Mar 2019 15:04:12 +0000
Subject: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u
Message-ID: <90f87ab9-5a96-eb2c-dbaa-f9e0cb3eea48@redhat.com>

I'm thinking about what to do about backport approvals. For 11u it's clear:
add the label "jdk11u-fix-request" to the bug database entry. For 8u it's
not so clear because AArch64 is not in the 8u mainline. We could just use the
"jdk8u-fix-request" anyway, even so. Thoughts?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From shade at redhat.com  Mon Mar 11 15:09:22 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 11 Mar 2019 16:09:22 +0100
Subject: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u
In-Reply-To: <90f87ab9-5a96-eb2c-dbaa-f9e0cb3eea48@redhat.com>
References: <90f87ab9-5a96-eb2c-dbaa-f9e0cb3eea48@redhat.com>
Message-ID: <0b22004e-65da-b614-5f31-1f4cb189f404@redhat.com>

On 3/11/19 4:04 PM, Andrew Haley wrote:
> I'm thinking about what to do about backport approvals. For 11u it's clear:
> add the label "jdk11u-fix-request" to the bug database entry. For 8u it's
> not so clear because AArch64 is not in the 8u mainline. We could just use the
> "jdk8u-fix-request" anyway, even so. Thoughts?

That would be confusing, because backport tracking (either in JIRA or external) would look for the
backports resolved in openjdk8u*, which is jdk8u/*, not aarch64-port.

We have the same problem in Shenandoah 11u and 8u, and we "just" backport stuff into development
versions without requesting backports via JDK Updates process. Because, in retrospect, these
downstream repositories are not related to JDK Updates project at all.

-Aleksey



From ci_notify at linaro.org  Mon Mar 11 21:35:53 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Mon, 11 Mar 2019 21:35:53 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <875207276.2741.1552340153965.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/070/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/04 pass: 5,527; fail: 7; error: 2; not run: 93
Build 1: aarch64/2019/feb/06 pass: 5,532; fail: 4; error: 1; not run: 93
Build 2: aarch64/2019/feb/08 pass: 5,519; fail: 19; error: 2; not run: 93
Build 3: aarch64/2019/feb/11 pass: 5,527; fail: 11; error: 2; not run: 93
Build 4: aarch64/2019/feb/13 pass: 5,537; fail: 4; not run: 93
Build 5: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 6: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 7: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 8: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 9: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 10: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93
Build 11: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93
Build 12: aarch64/2019/mar/06 pass: 5,544; fail: 3; not run: 93
Build 13: aarch64/2019/mar/08 pass: 5,546; fail: 3; not run: 93
Build 14: aarch64/2019/mar/11 pass: 5,547; fail: 3; not run: 93

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/04 pass: 8,539; fail: 506; error: 18
Build 1: aarch64/2019/feb/06 pass: 8,537; fail: 499; error: 27
Build 2: aarch64/2019/feb/08 pass: 8,530; fail: 515; error: 23
Build 3: aarch64/2019/feb/11 pass: 8,559; fail: 490; error: 15
Build 4: aarch64/2019/feb/13 pass: 8,534; fail: 512; error: 18
Build 5: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 6: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 7: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 8: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 9: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 10: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20
Build 11: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20
Build 12: aarch64/2019/mar/06 pass: 8,541; fail: 506; error: 21
Build 13: aarch64/2019/mar/08 pass: 8,538; fail: 512; error: 20
Build 14: aarch64/2019/mar/11 pass: 8,531; fail: 520; error: 19

3 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/04 pass: 3,994; fail: 1
Build 1: aarch64/2019/feb/06 pass: 3,994; fail: 1
Build 2: aarch64/2019/feb/08 pass: 3,994; fail: 1
Build 3: aarch64/2019/feb/11 pass: 3,994; fail: 1
Build 4: aarch64/2019/feb/13 pass: 3,994; fail: 1
Build 5: aarch64/2019/feb/15 pass: 3,995
Build 6: aarch64/2019/feb/18 pass: 3,996
Build 7: aarch64/2019/feb/20 pass: 3,996
Build 8: aarch64/2019/feb/25 pass: 3,931
Build 9: aarch64/2019/feb/27 pass: 3,931
Build 10: aarch64/2019/mar/01 pass: 3,931
Build 11: aarch64/2019/mar/04 pass: 3,931
Build 12: aarch64/2019/mar/06 pass: 3,931
Build 13: aarch64/2019/mar/08 pass: 3,931
Build 14: aarch64/2019/mar/11 pass: 3,931

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.46x
Relative performance: Server critical-jOPS (nc): 9.06x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 210.67

Server 210.67 / Server 2014-04-01 (71.00): 2.97x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-02-05 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/035/results/
2019-02-07 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/037/results/
2019-02-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/039/results/
2019-02-12 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/042/results/
2019-02-14 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/044/results/
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/065/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/067/results/
2019-03-11 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/070/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From Ningsheng.Jian at arm.com  Tue Mar 12 04:28:36 2019
From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China))
Date: Tue, 12 Mar 2019 04:28:36 +0000
Subject: [aarch64-port-dev ] RFR(S): 8214922: Add vectorization support
 for fmin/fmax
In-Reply-To: <954d6760-a914-747b-aab5-b928490510a4@redhat.com>
References: <DB7PR08MB3115055477478B62D825C36196BE0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <87d0pv2iow.fsf@redhat.com> <c836cf2e-20a9-0ec4-212d-72326fb144a6@redhat.com>
 <877eg32bzq.fsf@redhat.com> <b91e56a1-dd8f-d9f1-40e8-af5d8c3c0d9d@redhat.com>
 <871s6a3map.fsf@redhat.com>
 <DB7PR08MB3115C5F108D17017B98A1FF796B40@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <87va371n6b.fsf@redhat.com>
 <DB7PR08MB3115836C7236BFBDC988D729968E0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <DB7PR08MB3115E7B38864A31A1F60DE50968B0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <40d1a9a7-47f3-4e13-032d-70932b03d215@redhat.com>
 <DB7PR08MB3115418F2B1993557DF7EA6196840@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <DB7PR08MB311513257A35EC4057EECD28964C0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <954d6760-a914-747b-aab5-b928490510a4@redhat.com>
Message-ID: <371872d2-4b07-f1bd-cadc-7758d5ac698e@arm.com>

Hi Andrew,

On 03/11/2019 07:39 PM, Andrew Dinn wrote:
> hI pENGFEI,
>
> On 07/03/2019 09:26, Pengfei Li (Arm Technology China) wrote:
>> Please see below updated webrev for the pending patch of fmin/fmax
>> vectorization.
>> The only difference between webrev.03 and webrev.02 is the
>> hard-coded
>> arrangement bits in fmaxv/fminv encodings are replaced.
>>
>> webrev: http://cr.openjdk.java.net/~pli/rfr/8214922/webrev.03/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8214922
> Yes, that looks good to push. Thanks.
>

Thanks! It passed the submit repo tests and our local jtreg tests. Pushed.

Regards,
Ningsheng

From nick.gasson at arm.com  Tue Mar 12 06:06:29 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Tue, 12 Mar 2019 14:06:29 +0800
Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock
	fast path not called
Message-ID: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com>

Hi,

Please review this backport of the fix for 8216350 to 11u:

Original bug: https://bugs.openjdk.java.net/browse/JDK-8216350
Webrev: http://cr.openjdk.java.net/~ngasson/8216350/webrev.11u.0/

Justification is that it improves performance in non-micro benchmarks 
(SPECjbb).

The original patch has been modified slightly so it applies cleanly on 
11u. Most of the conflicts were from checking the EmitSync flag in 11 
which has been removed in 12/13. I've also removed the change to the 
micro benchmark as these files are not in 11u.

Testing: jtreg, jcstress (*), and ran the micro benchmark to check the 
performance regression is fixed.

* Note that some jcstress tests are failing on 11u (with and without 
this patch). You can reproduce this easily by running jcstress with "-t 
varHandles.*GetAndSetTest". This was fixed in 12/13 by:

   8211320: Aarch64: unsafe.compareAndSetByte() and 
unsafe.compareAndSetShort() c2 intrinsics broken with negative expected 
value

I suggest we also backport the above to 11u?

Thanks,
Nick

From aph at redhat.com  Tue Mar 12 08:26:09 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 12 Mar 2019 08:26:09 +0000
Subject: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u
In-Reply-To: <0b22004e-65da-b614-5f31-1f4cb189f404@redhat.com>
References: <90f87ab9-5a96-eb2c-dbaa-f9e0cb3eea48@redhat.com>
 <0b22004e-65da-b614-5f31-1f4cb189f404@redhat.com>
Message-ID: <198e497f-1246-76d3-cfc5-6b2cf76eb762@redhat.com>

On 3/11/19 3:09 PM, Aleksey Shipilev wrote:
> On 3/11/19 4:04 PM, Andrew Haley wrote:
>> I'm thinking about what to do about backport approvals. For 11u
>> it's clear: add the label "jdk11u-fix-request" to the bug database
>> entry. For 8u it's not so clear because AArch64 is not in the 8u
>> mainline. We could just use the "jdk8u-fix-request" anyway, even
>> so. Thoughts?
> 
> That would be confusing, because backport tracking (either in JIRA
> or external) would look for the backports resolved in openjdk8u*,
> which is jdk8u/*, not aarch64-port.

OK. that makes sense.

> We have the same problem in Shenandoah 11u and 8u, and we "just"
> backport stuff into development versions without requesting
> backports via JDK Updates process. Because, in retrospect, these
> downstream repositories are not related to JDK Updates project at
> all.

Well, I'd disagree with that: they are related in the same way that A
is a child of B.

How about "jdk8u-aarch64-fix-request" etc. ?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Tue Mar 12 08:36:50 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 12 Mar 2019 08:36:50 +0000
Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock
 fast path not called
In-Reply-To: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com>
References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com>
Message-ID: <5fa7634c-4de7-1f0b-6730-e849293c90e3@redhat.com>

On 3/12/19 6:06 AM, Nick Gasson wrote:
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8216350
> Webrev: http://cr.openjdk.java.net/~ngasson/8216350/webrev.11u.0/
> 
> Justification is that it improves performance in non-micro benchmarks 
> (SPECjbb).

Looks good.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Tue Mar 12 08:43:23 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 12 Mar 2019 08:43:23 +0000
Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock
 fast path not called
In-Reply-To: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com>
References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com>
Message-ID: <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com>

On 3/12/19 6:06 AM, Nick Gasson wrote:
> Hi,
> 
> Please review this backport of the fix for 8216350 to 11u:
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8216350
> Webrev: http://cr.openjdk.java.net/~ngasson/8216350/webrev.11u.0/
> 
> Justification is that it improves performance in non-micro benchmarks 
> (SPECjbb).
> 
> The original patch has been modified slightly so it applies cleanly on 
> 11u. Most of the conflicts were from checking the EmitSync flag in 11 
> which has been removed in 12/13. I've also removed the change to the 
> micro benchmark as these files are not in 11u.
> 
> Testing: jtreg, jcstress (*), and ran the micro benchmark to check the 
> performance regression is fixed.

OK.

> * Note that some jcstress tests are failing on 11u (with and without 
> this patch). You can reproduce this easily by running jcstress with "-t 
> varHandles.*GetAndSetTest". This was fixed in 12/13 by:
> 
>    8211320: Aarch64: unsafe.compareAndSetByte() and 
> unsafe.compareAndSetShort() c2 intrinsics broken with negative expected 
> value
> 
> I suggest we also backport the above to 11u?

Yes, thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From patrick at os.amperecomputing.com  Tue Mar 12 09:05:18 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Tue, 12 Mar 2019 09:05:18 +0000
Subject: [aarch64-port-dev ] RFR (trivial): 8215976: backport a patch to
 jdk8u-shenandoah/jdk,
 fix gmtime_r declaration conflicts in zip.cpp with linux header files
In-Reply-To: <BYAPR01MB5046E8511CE1FE55CF216FC18F720@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB5046E8511CE1FE55CF216FC18F720@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <BYAPR01MB50462BAF14A049F95CA7162F8F490@BYAPR01MB5046.prod.exchangelabs.com>

Please help review this backport request, thanks.

http://cr.openjdk.java.net/~qpzhang/rawpatches/gmtime_aarch64.patch.txt 

Regards
Patrick

-----Original Message-----
From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On Behalf Of Patrick Zhang OS
Sent: Tuesday, March 5, 2019 3:58 PM
To: aarch64-port-dev at openjdk.java.net
Subject: [aarch64-port-dev ] RFR (trivial): 8215976: backport a patch to jdk8u-shenandoah/jdk, fix gmtime_r declaration conflicts in zip.cpp with linux header files

Hi Reviewers,

This issue (belongs to core libs) was exposed by building OpenJDK with ampere toolchains (gcc 8.2) on an aarch64 platform, and the fix has been verified on jdk/submit, pushed into jdk/jdk, backported to jdk8u-dev respectively, see below for details.
May I request to backport it to aarch64-port/jdk8u-shenandoah/jdk as well? 

https://bugs.openjdk.java.net/browse/JDK-8215976, http://hg.openjdk.java.net/jdk/jdk/rev/06862c019f3f   
https://bugs.openjdk.java.net/browse/JDK-8217901, http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/db7a698be165
Tests: this patch does not impact functions, build jdk/jdk has been verified at jdk/submit, build aarch64 verified at ampere platforms.

Attached is the diff, please help review, thanks.

Regards
Patrick

-----Original Message-----
From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On Behalf Of Patrick Zhang OS
Sent: Wednesday, February 27, 2019 1:26 PM
To: aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] Request to port a patch to aarch64-port/jdk8u-shenandoah, fix gmtime_r declaration conflicts in zip.cpp with linux header files

Hi

Can I ask for porting this (simple) patch from jdk8u-dev to aarch64-port/jdk8u-shenandoah? I supposed it would be in via 'bulk merge' but haven't found so in the latest merge. 
Please kindly approve this, thanks in advance.

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/db7a698be165
JBS: https://bugs.openjdk.java.net/browse/JDK-8217901
(Btw, I found "Fix Version/s: openjdk8u211", when will this accutally happen? April release? or already done? I am confused here...)

Regards
Patrick

-----Original Message-----
From: Patrick Zhang
Sent: Tuesday, January 29, 2019 11:29 AM
To: 'Andrew Hughes' <gnu.andrew at redhat.com>; Andrew Haley <aph at redhat.com>
Cc: aarch64-port-dev at openjdk.java.net
Subject: RE: [aarch64-port-dev ] Request to cherry-pick JDK-8215976, fix gmtime_r declaration conflicts in zip.cpp with linux header files

Many thanks for the help. I saw it is in jdk8u now and suppose will be in aarch64-port/jdk8u-shenandoah soon.

Regards
Patrick

-----Original Message-----
From: Andrew Hughes <gnu.andrew at redhat.com>
Sent: Wednesday, January 23, 2019 11:40 PM
To: Andrew Haley <aph at redhat.com>
Cc: Patrick Zhang <patrick at os.amperecomputing.com>; aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] Request to cherry-pick JDK-8215976, fix gmtime_r declaration conflicts in zip.cpp with linux header files

On Wed, 23 Jan 2019 at 09:37, Andrew Haley <aph at redhat.com> wrote:
>
> On 1/23/19 3:18 AM, Patrick Zhang wrote:
> > Would there be any proper process to follow, please let me know. Appreciate your help.
>
> I'm fine with this being put into the aarch64-port/jdk8u-shenandoah 
> port, but it should be sent to jdk8u-dev.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Please get the fix into upstream jdk8u, via the 8u-dev list, and we will then pick it up in aarch64-port/jdk8u-shenandoah when we merge.

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From ci_notify at linaro.org  Tue Mar 12 15:11:05 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Tue, 12 Mar 2019 15:11:05 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 939 Failure
Message-ID: <668727257.3024.1552403465669.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Failure
Build details -  https://ci.linaro.org/job/jdkX-ci-build/939/

Changes -
  erikj: 4b4745d185eb42d09c9573ca8bf8d7bddae47315 
	- make/CompileJavaModules.gmk
	- make/Images.gmk
	- make/common/NativeCompilation.gmk
	- make/common/ProcessMarkdown.gmk
	- make/common/TestFilesCompilation.gmk
	- make/hotspot/lib/CompileJvm.gmk
	- make/test/JtregGraalUnit.gmk
	- make/test/JtregNativeHotspot.gmk
	- make/test/JtregNativeJdk.gmk 
--"8220383: Incremental build is broken and inefficient
Reviewed-by: tbell
"  dfuchs: daec95ed6795e21d53d3ac1112611b1f1724188c 
	- src/java.logging/share/classes/java/util/logging/LogManager.java 
--"8220262: fix headings in java.logging
Reviewed-by: lancea
"  redestad: 9c6508806663497b84f9902947471210e026f7ef 
	- src/hotspot/share/c1/c1_ValueStack.cpp
	- src/hotspot/share/c1/c1_ValueStack.hpp 
--"8220501: Improve c1_ValueStack locks handling
Reviewed-by: thartmann, neliasso
"  zgu: ee53a278b9d8dbf90081da6f8d578a99cd6ce7a0 
	- src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
	- src/hotspot/share/jvmci/vmStructs_jvmci.cpp 
--"8220344: Build failures when using --with-jvm-features=-g1gc,-jfr
Reviewed-by: tschatzl, zgu
Contributed-by: Ao Qi <aoqi at loongson.cn>
"  rschmelter: 9911f18d6a40062c7e1add1d22e07d6c9676b216 
	- make/hotspot/ide/CreateVSProject.gmk 
--"8220363: hotspot-ide project fails
Reviewed-by: clanger, erikj
"  sgehwolf: ab17708ec5c31ebb7c63a3232a450325a18c6cd3 
	- src/hotspot/share/gc/z/zStat.cpp 
--"8220294: ZGC fails to build on GCC 4.4.7: Type parameter issue
Summary: Specify explicit type in the constructor
Reviewed-by: shade, pliden
"

Build output -
   Building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'
   Compiling 8 files for BUILD_TOOLS_LANGTOOLS
   Compiling 1 files for BUILD_JFR_TOOLS
   Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
   Compiling 2 files for BUILD_JVMTI_TOOLS
   Compiling 10 properties into resource bundles for jdk.javadoc
   Parsing 2 properties into enum-like class for jdk.compiler
   Compiling 7 properties into resource bundles for jdk.jshell
   Compiling 12 properties into resource bundles for jdk.jdeps
   Compiling 19 properties into resource bundles for jdk.compiler
   Compiling 117 files for BUILD_java.compiler.interim
   Compiling 396 files for BUILD_jdk.compiler.interim
   Creating support/modules_libs/java.base/server/libjvm.so from 917 file(s)
   Creating hotspot/variant-server/libjvm/gtest/libjvm.so from 108 file(s)
   Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s)
   Compiling 225 files for BUILD_jdk.javadoc.interim
   Compiling 162 files for BUILD_TOOLS_JDK
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 2 files for COMPILE_DEPEND
   Compiling 3 files for BUILD_VM_COMPILER_MATCH_PROCESSOR
   Compiling 5 files for BUILD_VM_COMPILER_NODEINFO_PROCESSOR
   Compiling 3 files for BUILD_VM_COMPILER_OPTIONS_PROCESSOR
   Compiling 14 files for BUILD_VM_COMPILER_REPLACEMENTS_PROCESSOR
   Compiling 3 files for BUILD_VM_COMPILER_SERVICEPROVIDER_PROCESSOR
   Creating buildtools/jdk.vm.compiler.match.processor.jar
   Creating buildtools/jdk.vm.compiler.nodeinfo.processor.jar
   Creating buildtools/jdk.vm.compiler.options.processor.jar
   Creating buildtools/jdk.vm.compiler.replacements.verifier.jar
   Creating buildtools/jdk.vm.compiler.serviceprovider.processor.jar
   Compiling 11 properties into resource bundles for jdk.jartool
   Compiling 11 properties into resource bundles for jdk.management.agent
   Compiling 3 properties into resource bundles for jdk.jdi
   Compiling 4 properties into resource bundles for jdk.jlink
   Compiling 3 properties into resource bundles for jdk.jlink
   Compiling 1 properties into resource bundles for jdk.jlink
   Compiling 224 properties into resource bundles for jdk.localedata
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/c1/c1_CFGPrinter.cpp: In member function ?void CFGPrinterOutput::print_state(BlockBegin*)?:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/c1/c1_CFGPrinter.cpp:169:46: error: ?for_each_lock_value? was not declared in this scope
          for_each_lock_value(state, index, value) {
                                                 ^
   At global scope:
   cc1plus: error: unrecognized command line option ?-Wno-misleading-indentation? [-Werror]
   cc1plus: error: unrecognized command line option ?-Wno-implicit-fallthrough? [-Werror]
   cc1plus: error: unrecognized command line option ?-Wno-int-in-bool-context? [-Werror]
   cc1plus: all warnings being treated as errors
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/c1_CFGPrinter.o' failed
   make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/c1_CFGPrinter.o] Error 1
   make[3]: *** Waiting for unfinished jobs....
   Compiling 188 files for BUILD_jdk.rmic.interim
   Compiling 31 files for BUILD_JRTFS
   Creating support/modules_libs/java.base/jrt-fs.jar
   make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
   make[2]: *** [hotspot-server-libs] Error 1
   make[2]: *** Waiting for unfinished jobs....
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   
   ERROR: Build failed for target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2) 
   Stopping sjavac server
   
   === Output from failing command(s) repeated here ===
   * For target hotspot_variant-server_libjvm_objs_c1_CFGPrinter.o:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/c1/c1_CFGPrinter.cpp: In member function ?void CFGPrinterOutput::print_state(BlockBegin*)?:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/c1/c1_CFGPrinter.cpp:169:46: error: ?for_each_lock_value? was not declared in this scope
          for_each_lock_value(state, index, value) {
                                                 ^
   At global scope:
   cc1plus: error: unrecognized command line option ?-Wno-misleading-indentation? [-Werror]
   cc1plus: error: unrecognized command line option ?-Wno-implicit-fallthrough? [-Werror]
   cc1plus: error: unrecognized command line option ?-Wno-int-in-bool-context? [-Werror]
   cc1plus: all warnings being treated as errors
   
   * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs.
   === End of repeated output ===
   
   === Make failed targets repeated here ===
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/c1_CFGPrinter.o' failed
   make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
   === End of repeated output ===
   
   Hint: Try searching the build log for the name of the first failed target.
   Hint: See doc/building.html#troubleshooting for assistance.
   
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:305: recipe for target 'main' failed
   make[1]: *** [main] Error 1
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed
   make: *** [images] Error 2

From derekw at marvell.com  Tue Mar 12 15:54:37 2019
From: derekw at marvell.com (Derek White)
Date: Tue, 12 Mar 2019 15:54:37 +0000
Subject: [aarch64-port-dev ] [EXT] Linaro OpenJDK AArch64 jdk/jdk build
 939 Failure
In-Reply-To: <668727257.3024.1552403465669.JavaMail.jenkins@a6c5c67cda76>
References: <668727257.3024.1552403465669.JavaMail.jenkins@a6c5c67cda76>
Message-ID: <MN2PR18MB27337D1CFE2A895A0FD5D034D2490@MN2PR18MB2733.namprd18.prod.outlook.com>

Looks like fix just checked in:
RFR (urgent, trivial): 8220515: Revert removal of for_each_lock_value removal
 - Derek

> -----Original Message-----
> From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On
> Behalf Of ci_notify at linaro.org
> Sent: Tuesday, March 12, 2019 11:11 AM
> To: stuart.monteith at linaro.org; aarch64-port-dev at openjdk.java.net
> Subject: [EXT] [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 939
> Failure
> 
> External Email
> 
> ----------------------------------------------------------------------
> OpenJDK AArch64 jdk/jdk build status is Failure Build details -
> https://ci.linaro.org/job/jdkX-ci-build/939/
> 
> Changes -
>   erikj: 4b4745d185eb42d09c9573ca8bf8d7bddae47315
> 	- make/CompileJavaModules.gmk
> 	- make/Images.gmk
> 	- make/common/NativeCompilation.gmk
> 	- make/common/ProcessMarkdown.gmk
> 	- make/common/TestFilesCompilation.gmk
> 	- make/hotspot/lib/CompileJvm.gmk
> 	- make/test/JtregGraalUnit.gmk
> 	- make/test/JtregNativeHotspot.gmk
> 	- make/test/JtregNativeJdk.gmk
> --"8220383: Incremental build is broken and inefficient
> Reviewed-by: tbell
> "  dfuchs: daec95ed6795e21d53d3ac1112611b1f1724188c
> 	- src/java.logging/share/classes/java/util/logging/LogManager.java
> --"8220262: fix headings in java.logging
> Reviewed-by: lancea
> "  redestad: 9c6508806663497b84f9902947471210e026f7ef
> 	- src/hotspot/share/c1/c1_ValueStack.cpp
> 	- src/hotspot/share/c1/c1_ValueStack.hpp
> --"8220501: Improve c1_ValueStack locks handling
> Reviewed-by: thartmann, neliasso
> "  zgu: ee53a278b9d8dbf90081da6f8d578a99cd6ce7a0
> 	- src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
> 	- src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> --"8220344: Build failures when using --with-jvm-features=-g1gc,-jfr
> Reviewed-by: tschatzl, zgu
> Contributed-by: Ao Qi <aoqi at loongson.cn> "  rschmelter:
> 9911f18d6a40062c7e1add1d22e07d6c9676b216
> 	- make/hotspot/ide/CreateVSProject.gmk
> --"8220363: hotspot-ide project fails
> Reviewed-by: clanger, erikj
> "  sgehwolf: ab17708ec5c31ebb7c63a3232a450325a18c6cd3
> 	- src/hotspot/share/gc/z/zStat.cpp
> --"8220294: ZGC fails to build on GCC 4.4.7: Type parameter issue
> Summary: Specify explicit type in the constructor
> Reviewed-by: shade, pliden
> "
> 
> Build output -
>    Building target 'images' in configuration
> '/home/buildslave/workspace/jdkX-ci-build/build'
>    Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>    Compiling 1 files for BUILD_JFR_TOOLS
>    Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
>    Compiling 2 files for BUILD_JVMTI_TOOLS
>    Compiling 10 properties into resource bundles for jdk.javadoc
>    Parsing 2 properties into enum-like class for jdk.compiler
>    Compiling 7 properties into resource bundles for jdk.jshell
>    Compiling 12 properties into resource bundles for jdk.jdeps
>    Compiling 19 properties into resource bundles for jdk.compiler
>    Compiling 117 files for BUILD_java.compiler.interim
>    Compiling 396 files for BUILD_jdk.compiler.interim
>    Creating support/modules_libs/java.base/server/libjvm.so from 917 file(s)
>    Creating hotspot/variant-server/libjvm/gtest/libjvm.so from 108 file(s)
>    Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s)
>    Compiling 225 files for BUILD_jdk.javadoc.interim
>    Compiling 162 files for BUILD_TOOLS_JDK
>    Note: Some input files use or override a deprecated API.
>    Note: Recompile with -Xlint:deprecation for details.
>    Note: Some input files use unchecked or unsafe operations.
>    Note: Recompile with -Xlint:unchecked for details.
>    Compiling 2 files for COMPILE_DEPEND
>    Compiling 3 files for BUILD_VM_COMPILER_MATCH_PROCESSOR
>    Compiling 5 files for BUILD_VM_COMPILER_NODEINFO_PROCESSOR
>    Compiling 3 files for BUILD_VM_COMPILER_OPTIONS_PROCESSOR
>    Compiling 14 files for BUILD_VM_COMPILER_REPLACEMENTS_PROCESSOR
>    Compiling 3 files for
> BUILD_VM_COMPILER_SERVICEPROVIDER_PROCESSOR
>    Creating buildtools/jdk.vm.compiler.match.processor.jar
>    Creating buildtools/jdk.vm.compiler.nodeinfo.processor.jar
>    Creating buildtools/jdk.vm.compiler.options.processor.jar
>    Creating buildtools/jdk.vm.compiler.replacements.verifier.jar
>    Creating buildtools/jdk.vm.compiler.serviceprovider.processor.jar
>    Compiling 11 properties into resource bundles for jdk.jartool
>    Compiling 11 properties into resource bundles for jdk.management.agent
>    Compiling 3 properties into resource bundles for jdk.jdi
>    Compiling 4 properties into resource bundles for jdk.jlink
>    Compiling 3 properties into resource bundles for jdk.jlink
>    Compiling 1 properties into resource bundles for jdk.jlink
>    Compiling 224 properties into resource bundles for jdk.localedata
>    /home/buildslave/workspace/jdkX-ci-
> build/jdkX/src/hotspot/share/c1/c1_CFGPrinter.cpp: In member function
> ?void CFGPrinterOutput::print_state(BlockBegin*)?:
>    /home/buildslave/workspace/jdkX-ci-
> build/jdkX/src/hotspot/share/c1/c1_CFGPrinter.cpp:169:46: error:
> ?for_each_lock_value? was not declared in this scope
>           for_each_lock_value(state, index, value) {
>                                                  ^
>    At global scope:
>    cc1plus: error: unrecognized command line option ?-Wno-misleading-
> indentation? [-Werror]
>    cc1plus: error: unrecognized command line option ?-Wno-implicit-
> fallthrough? [-Werror]
>    cc1plus: error: unrecognized command line option ?-Wno-int-in-bool-
> context? [-Werror]
>    cc1plus: all warnings being treated as errors
>    lib/CompileJvm.gmk:175: recipe for target
> '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-
> server/libjvm/objs/c1_CFGPrinter.o' failed
>    make[3]: *** [/home/buildslave/workspace/jdkX-ci-
> build/build/hotspot/variant-server/libjvm/objs/c1_CFGPrinter.o] Error 1
>    make[3]: *** Waiting for unfinished jobs....
>    Compiling 188 files for BUILD_jdk.rmic.interim
>    Compiling 31 files for BUILD_JRTFS
>    Creating support/modules_libs/java.base/jrt-fs.jar
>    make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
>    make[2]: *** [hotspot-server-libs] Error 1
>    make[2]: *** Waiting for unfinished jobs....
>    Note: Some input files use or override a deprecated API.
>    Note: Recompile with -Xlint:deprecation for details.
> 
>    ERROR: Build failed for target 'images' in configuration
> '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2)
>    Stopping sjavac server
> 
>    === Output from failing command(s) repeated here ===
>    * For target hotspot_variant-server_libjvm_objs_c1_CFGPrinter.o:
>    /home/buildslave/workspace/jdkX-ci-
> build/jdkX/src/hotspot/share/c1/c1_CFGPrinter.cpp: In member function
> ?void CFGPrinterOutput::print_state(BlockBegin*)?:
>    /home/buildslave/workspace/jdkX-ci-
> build/jdkX/src/hotspot/share/c1/c1_CFGPrinter.cpp:169:46: error:
> ?for_each_lock_value? was not declared in this scope
>           for_each_lock_value(state, index, value) {
>                                                  ^
>    At global scope:
>    cc1plus: error: unrecognized command line option ?-Wno-misleading-
> indentation? [-Werror]
>    cc1plus: error: unrecognized command line option ?-Wno-implicit-
> fallthrough? [-Werror]
>    cc1plus: error: unrecognized command line option ?-Wno-int-in-bool-
> context? [-Werror]
>    cc1plus: all warnings being treated as errors
> 
>    * All command lines available in /home/buildslave/workspace/jdkX-ci-
> build/build/make-support/failure-logs.
>    === End of repeated output ===
> 
>    === Make failed targets repeated here ===
>    lib/CompileJvm.gmk:175: recipe for target
> '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-
> server/libjvm/objs/c1_CFGPrinter.o' failed
>    make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
>    === End of repeated output ===
> 
>    Hint: Try searching the build log for the name of the first failed target.
>    Hint: See doc/building.html#troubleshooting for assistance.
> 
>    /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:305: recipe
> for target 'main' failed
>    make[1]: *** [main] Error 1
>    /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe
> for target 'images' failed
>    make: *** [images] Error 2

From ci_notify at linaro.org  Tue Mar 12 16:36:27 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Tue, 12 Mar 2019 16:36:27 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 940 Fixed
In-Reply-To: <668727257.3024.1552403465669.JavaMail.jenkins@a6c5c67cda76>
References: <668727257.3024.1552403465669.JavaMail.jenkins@a6c5c67cda76>
Message-ID: <1852511487.3055.1552408587826.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Fixed
Build details -  https://ci.linaro.org/job/jdkX-ci-build/940/

Changes -
  gadams: 75268d993deb2969cdb4a8a821bbd50fa0014d75 
	- src/java.instrument/share/classes/java/lang/instrument/package-info.java 
--"8220474: Incorrect GPL header in src/java.instrument/share/classes/java/lang/instrument/package-info.java
Reviewed-by: dholmes
"  gadams: 018217e30f5c3762ed1f64ff464adf342c19e027 
	- src/java.instrument/share/classes/java/lang/instrument/package-info.java 
--"8220257: fix headings in java.instrument
Reviewed-by: dfuchs
"  kbarrett: 085309069d3c41ac471146c4b6fc8bd4f4e054fb 
	- src/hotspot/share/c1/c1_LIRGenerator.cpp 
--"8217576: C1 atomic access handlers use incorrect decorators
Summary: Fix decorator defaulting.
Reviewed-by: tschatzl, eosterlund
"  redestad: b4f4778cf3d9c86d500a528653098ca5278d7b61 
	- src/hotspot/share/c1/c1_ValueStack.hpp 
--"8220515: Revert removal of for_each_lock_value removal
Reviewed-by: thartmann
"

Build output -
   Creating jdk.internal.le.jmod
   Creating jdk.internal.opt.jmod
   Creating jdk.internal.vm.ci.jmod
   Creating jdk.internal.vm.compiler.jmod
   Creating jdk.internal.vm.compiler.management.jmod
   Creating jdk.jartool.jmod
   Creating jdk.javadoc.jmod
   Creating jdk.jcmd.jmod
   Creating jdk.jconsole.jmod
   Creating jdk.jdeps.jmod
   Creating jdk.jdi.jmod
   Creating jdk.jdwp.agent.jmod
   Creating jdk.jfr.jmod
   Creating jdk.jshell.jmod
   Creating jdk.jsobject.jmod
   Creating jdk.jstatd.jmod
   Creating jdk.localedata.jmod
   Creating jdk.management.jmod
   Creating jdk.management.agent.jmod
   Creating jdk.management.jfr.jmod
   Creating jdk.naming.dns.jmod
   Creating jdk.naming.rmi.jmod
   Creating jdk.net.jmod
   Creating jdk.pack.jmod
   Creating jdk.rmic.jmod
   Creating jdk.scripting.nashorn.jmod
   Creating jdk.scripting.nashorn.shell.jmod
   Creating jdk.sctp.jmod
   Creating jdk.security.auth.jmod
   Creating jdk.security.jgss.jmod
   Creating jdk.unsupported.jmod
   Creating jdk.unsupported.desktop.jmod
   Creating jdk.xml.dom.jmod
   Creating jdk.zipfs.jmod
   Creating interim jimage
   Compiling 3 files for BUILD_DEMO_CodePointIM
   Updating support/demos/image/jfc/CodePointIM/src.zip
   Compiling 3 files for BUILD_DEMO_FileChooserDemo
   Updating support/demos/image/jfc/FileChooserDemo/src.zip
   Compiling 30 files for BUILD_DEMO_SwingSet2
   Updating support/demos/image/jfc/SwingSet2/src.zip
   Compiling 4 files for BUILD_DEMO_Font2DTest
   Updating support/demos/image/jfc/Font2DTest/src.zip
   Compiling 64 files for BUILD_DEMO_J2Ddemo
   Updating support/demos/image/jfc/J2Ddemo/src.zip
   Compiling 15 files for BUILD_DEMO_Metalworks
   Updating support/demos/image/jfc/Metalworks/src.zip
   Compiling 2 files for BUILD_DEMO_Notepad
   Updating support/demos/image/jfc/Notepad/src.zip
   Compiling 5 files for BUILD_DEMO_Stylepad
   Updating support/demos/image/jfc/Stylepad/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 5 files for BUILD_DEMO_SampleTree
   Updating support/demos/image/jfc/SampleTree/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 8 files for BUILD_DEMO_TableExample
   Updating support/demos/image/jfc/TableExample/src.zip
   Compiling 1 files for BUILD_DEMO_TransparentRuler
   Updating support/demos/image/jfc/TransparentRuler/src.zip
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar
   Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar
   Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar
   Creating support/demos/image/jfc/Metalworks/Metalworks.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/Notepad/Notepad.jar
   Creating support/demos/image/jfc/Stylepad/Stylepad.jar
   Creating support/demos/image/jfc/SampleTree/SampleTree.jar
   Creating support/demos/image/jfc/TableExample/TableExample.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 1 files for CLASSLIST_JAR
   Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
   Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar
   Creating support/classlist.jar
   Creating jdk.jlink.jmod
   Creating java.base.jmod
   Creating jdk image
   Creating CDS archive for jdk image
   Stopping sjavac server
   Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'

From ci_notify at linaro.org  Wed Mar 13 02:01:38 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Wed, 13 Mar 2019 02:01:38 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64
Message-ID: <1763549748.3163.1552442499470.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/071/summary.html
 
-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/24 pass: 5,708; fail: 10; not run: 11,618
Build 1: aarch64/2019/jan/29 pass: 5,709; fail: 9; not run: 11,618
Build 2: aarch64/2019/jan/31 pass: 5,707; fail: 11; not run: 11,618
Build 3: aarch64/2019/feb/02 pass: 5,708; fail: 10; not run: 11,618
Build 4: aarch64/2019/feb/07 pass: 5,710; fail: 9; not run: 11,618
Build 5: aarch64/2019/feb/09 pass: 5,710; fail: 9; not run: 11,618
Build 6: aarch64/2019/feb/12 pass: 5,709; fail: 10; not run: 11,618
Build 7: aarch64/2019/feb/16 pass: 5,713; fail: 10; not run: 11,618
Build 8: aarch64/2019/feb/19 pass: 5,715; fail: 10; not run: 11,618
Build 9: aarch64/2019/feb/21 pass: 5,714; fail: 11; not run: 11,618
Build 10: aarch64/2019/feb/26 pass: 5,717; fail: 9; not run: 11,618
Build 11: aarch64/2019/mar/02 pass: 5,717; fail: 11; not run: 11,618
Build 12: aarch64/2019/mar/05 pass: 5,719; fail: 9; not run: 11,618
Build 13: aarch64/2019/mar/07 pass: 5,719; fail: 9; not run: 11,618
Build 14: aarch64/2019/mar/12 pass: 5,719; fail: 9; not run: 11,618

1 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/24 pass: 8,366; fail: 507; error: 25
Build 1: aarch64/2019/jan/29 pass: 8,353; fail: 524; error: 22
Build 2: aarch64/2019/jan/31 pass: 8,372; fail: 502; error: 25
Build 3: aarch64/2019/feb/02 pass: 8,378; fail: 501; error: 21
Build 4: aarch64/2019/feb/07 pass: 8,364; fail: 507; error: 29
Build 5: aarch64/2019/feb/09 pass: 8,354; fail: 523; error: 23
Build 6: aarch64/2019/feb/12 pass: 8,358; fail: 519; error: 24
Build 7: aarch64/2019/feb/16 pass: 8,356; fail: 520; error: 25
Build 8: aarch64/2019/feb/19 pass: 8,375; fail: 506; error: 24
Build 9: aarch64/2019/feb/21 pass: 8,377; fail: 513; error: 22
Build 10: aarch64/2019/feb/26 pass: 8,387; fail: 501; error: 26
Build 11: aarch64/2019/mar/02 pass: 8,400; fail: 487; error: 29
Build 12: aarch64/2019/mar/05 pass: 8,413; fail: 487; error: 16
Build 13: aarch64/2019/mar/07 pass: 8,388; fail: 502; error: 26
Build 14: aarch64/2019/mar/12 pass: 8,370; fail: 520; error: 26

7 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/24 pass: 3,903
Build 1: aarch64/2019/jan/29 pass: 3,903
Build 2: aarch64/2019/jan/31 pass: 3,903
Build 3: aarch64/2019/feb/02 pass: 3,903
Build 4: aarch64/2019/feb/07 pass: 3,903
Build 5: aarch64/2019/feb/09 pass: 3,903
Build 6: aarch64/2019/feb/12 pass: 3,903
Build 7: aarch64/2019/feb/16 pass: 3,903
Build 8: aarch64/2019/feb/19 pass: 3,903
Build 9: aarch64/2019/feb/21 pass: 3,904
Build 10: aarch64/2019/feb/26 pass: 3,904
Build 11: aarch64/2019/mar/02 pass: 3,904
Build 12: aarch64/2019/mar/05 pass: 3,904
Build 13: aarch64/2019/mar/07 pass: 3,904
Build 14: aarch64/2019/mar/12 pass: 3,904

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.04x
Relative performance: Server critical-jOPS (nc): 7.80x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 204.57

Server 204.57 / Server 2014-04-01 (71.00): 2.88x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-01-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/024/results/
2019-01-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/029/results/
2019-02-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/031/results/
2019-02-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/033/results/
2019-02-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/038/results/
2019-02-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/040/results/
2019-02-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/043/results/
2019-02-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/047/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/050/results/
2019-02-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/052/results/
2019-02-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/057/results/
2019-03-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/061/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/064/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/066/results/
2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/071/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/

From nick.gasson at arm.com  Wed Mar 13 09:18:19 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Wed, 13 Mar 2019 17:18:19 +0800
Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock
 fast path not called
In-Reply-To: <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com>
References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com>
 <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com>
Message-ID: <f0081309-ea59-a57d-d251-bff95d1cae54@arm.com>

Thanks Andrew. Is anyone able to sponsor this patch for me?

Nick

On 12/03/2019 16:43, Andrew Haley wrote:
> On 3/12/19 6:06 AM, Nick Gasson wrote:
>> Hi,
>>
>> Please review this backport of the fix for 8216350 to 11u:
>>
>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8216350
>> Webrev: http://cr.openjdk.java.net/~ngasson/8216350/webrev.11u.0/
>>
>> Justification is that it improves performance in non-micro benchmarks
>> (SPECjbb).
>>
>> The original patch has been modified slightly so it applies cleanly on
>> 11u. Most of the conflicts were from checking the EmitSync flag in 11
>> which has been removed in 12/13. I've also removed the change to the
>> micro benchmark as these files are not in 11u.
>>
>> Testing: jtreg, jcstress (*), and ran the micro benchmark to check the
>> performance regression is fixed.
> 
> OK.
> 
>> * Note that some jcstress tests are failing on 11u (with and without
>> this patch). You can reproduce this easily by running jcstress with "-t
>> varHandles.*GetAndSetTest". This was fixed in 12/13 by:
>>
>>     8211320: Aarch64: unsafe.compareAndSetByte() and
>> unsafe.compareAndSetShort() c2 intrinsics broken with negative expected
>> value
>>
>> I suggest we also backport the above to 11u?
> 
> Yes, thanks.
> 

From patrick at os.amperecomputing.com  Wed Mar 13 10:11:05 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Wed, 13 Mar 2019 10:11:05 +0000
Subject: [aarch64-port-dev ] RFR: 8220566: AArch64: Set default vm features
	for Ampere eMAG CPUs
Message-ID: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>

Hi,

Please help review this patch for setting default vm features specifically for Ampere eMAG CPUs.

Webrev: http://cr.openjdk.java.net/~qpzhang/8220566/webrev.01
JBS: https://bugs.openjdk.java.net/browse/JDK-8220566

Tested with Ampere eMAG platforms, jtreg jdk_core and jcstress, etc.

Regards
Patrick


From adinn at redhat.com  Wed Mar 13 10:26:38 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 13 Mar 2019 10:26:38 +0000
Subject: [aarch64-port-dev ] RFR: 8220566: AArch64: Set default vm
 features for Ampere eMAG CPUs
In-Reply-To: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <894e63a2-4669-c803-ca37-de9129109acc@redhat.com>

Hi Patrick,

On 13/03/2019 10:11, Patrick Zhang OS wrote:
> Please help review this patch for setting default vm features specifically for Ampere eMAG CPUs.
> 
> Webrev: http://cr.openjdk.java.net/~qpzhang/8220566/webrev.01
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220566
> 
> Tested with Ampere eMAG platforms, jtreg jdk_core and jcstress, etc.
The patch looks like it might be ok. However, that's hard to say because
the JIRA issue simply restates what is in the  patch i.e. that these
specific code changes are needed.

Could you add a note on the JIRA issue explaining why these
configuration options are preferred? At that point it will be possible
to review the patch.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From rkennke at redhat.com  Wed Mar 13 17:52:35 2019
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 13 Mar 2019 18:52:35 +0100
Subject: [aarch64-port-dev ] RFR: RFR: Bulk integration shenandoah/jdk8u
 -> aarch64-port/jdk8u-shenandoah 2018-12-13
In-Reply-To: <CABi63P4oEK58RkDUDXNBhv+e43cOhu_xrbQq+dFkHkphFyoQYA@mail.gmail.com>
References: <2ef19d5c-e524-3d9b-a52a-6c968926f868@redhat.com>
 <CABi63P7VzPVpzg9f-f7fJSBAim5eU-6P9Ef68=kGwdYGk2oQ3g@mail.gmail.com>
 <a94b7a7c-edcb-e209-52d0-916994bdc03e@redhat.com>
 <CABi63P4H5XfzydeNGDb=oO=Px_9nrJn6=Og5KLwwVdFf2zu3sg@mail.gmail.com>
 <f8a963b9-85d7-9863-ccd1-7173f027bbc5@redhat.com>
 <CABi63P4CFEmx+i7bHHmcvjya_4qoVqc3=kRD=hw+oFhgH6OzPg@mail.gmail.com>
 <509ab726-539e-bc34-8cf9-45afb44855ad@redhat.com>
 <CABi63P7yEqzAGU0_U1tJt9tRStAQ4npixFVmdjCmnS5qYPixKQ@mail.gmail.com>
 <6c7ef38b-678d-4cdc-49d9-c6c03163ceb4@redhat.com>
 <CABi63P4oEK58RkDUDXNBhv+e43cOhu_xrbQq+dFkHkphFyoQYA@mail.gmail.com>
Message-ID: <3e9d63ad-80eb-9474-7c51-7a10448ae61e@redhat.com>

Hi there,

I still couldn't integrate this into the repo. Last time we discussed, 
the plan was to integrate after 8u202 landed. It doesn't seem to be 
there yet:

http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/

When would be a good time to finally push this? I'm already working on 
the next 3 months worth of backports ;-)

Roman

> On Mon, 7 Jan 2019 at 08:36, Aleksey Shipilev <shade at redhat.com> wrote:
>>
>> On 1/7/19 6:35 AM, Andrew Hughes wrote:
>>> On Fri, 28 Dec 2018 at 21:13, Roman Kennke <rkennke at redhat.com> wrote:
>>>> I don't think that the fix is needed in 11 or 8u upstream, because
>>>> JDK-8212603 isn't there?
>>>>
>>>> Can I push the Shenandoah integration?
>>>
>>> I get that, but it's not what I'm asking.
>>>
>>> My question is: would it be harmful to push 8212603 to upstream 8u/11u to reduce
>>> our divergence from upstream?
>>
>> No. JDK-8212603 is also not in upstream, it was reverted by JDK-8212673.
>>
>>> I would prefer that, if possible, to only carrying the fix in the
>>> shenandoah tree.
>>
>> ...and without GC interface (which was introduced in 10 and 11), JDK-8212673 would unavoidably be
>> GC-specific, and mentioning the concrete GC.
>>
>> You'll need to "upstream" things like:
>>
>> -       if (lock->obj_node()->eqv_uncast(unlock->obj_node()) &&
>> +       Node* lock_obj = ShenandoahBarrierNode::skip_through_barrier(lock->obj_node());
>> +       Node* unlock_obj = ShenandoahBarrierNode::skip_through_barrier(unlock->obj_node());
>> +       if (lock_obj->eqv_uncast(unlock_obj) &&
>>
>> Therefore, there is no added benefit to push it through upstream first, and I cannot even see how
>> that would be possible given there is no Shenandoah in upstream 8u.
>>
> 
> Right, so although it's using the upstream bug ID, the backport to
> shenandoah-8u is effectively
> Shenandoah-specific?
> If so, then that's fine by me. I just don't want us to diverge where
> we don't have to.
> 
>> -Aleksey
>>
> 
> Thanks,
> 

From ci_notify at linaro.org  Wed Mar 13 22:42:10 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Wed, 13 Mar 2019 22:42:10 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <1727030482.3341.1552516930720.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/072/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/06 pass: 5,532; fail: 4; error: 1; not run: 93
Build 1: aarch64/2019/feb/08 pass: 5,519; fail: 19; error: 2; not run: 93
Build 2: aarch64/2019/feb/11 pass: 5,527; fail: 11; error: 2; not run: 93
Build 3: aarch64/2019/feb/13 pass: 5,537; fail: 4; not run: 93
Build 4: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 5: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 6: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 7: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 8: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 9: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93
Build 10: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93
Build 11: aarch64/2019/mar/06 pass: 5,544; fail: 3; not run: 93
Build 12: aarch64/2019/mar/08 pass: 5,546; fail: 3; not run: 93
Build 13: aarch64/2019/mar/11 pass: 5,547; fail: 3; not run: 93
Build 14: aarch64/2019/mar/13 pass: 5,549; fail: 3; not run: 93

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/06 pass: 8,537; fail: 499; error: 27
Build 1: aarch64/2019/feb/08 pass: 8,530; fail: 515; error: 23
Build 2: aarch64/2019/feb/11 pass: 8,559; fail: 490; error: 15
Build 3: aarch64/2019/feb/13 pass: 8,534; fail: 512; error: 18
Build 4: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 5: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 6: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 7: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 8: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 9: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20
Build 10: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20
Build 11: aarch64/2019/mar/06 pass: 8,541; fail: 506; error: 21
Build 12: aarch64/2019/mar/08 pass: 8,538; fail: 512; error: 20
Build 13: aarch64/2019/mar/11 pass: 8,531; fail: 520; error: 19
Build 14: aarch64/2019/mar/13 pass: 8,533; fail: 514; error: 22

3 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/06 pass: 3,994; fail: 1
Build 1: aarch64/2019/feb/08 pass: 3,994; fail: 1
Build 2: aarch64/2019/feb/11 pass: 3,994; fail: 1
Build 3: aarch64/2019/feb/13 pass: 3,994; fail: 1
Build 4: aarch64/2019/feb/15 pass: 3,995
Build 5: aarch64/2019/feb/18 pass: 3,996
Build 6: aarch64/2019/feb/20 pass: 3,996
Build 7: aarch64/2019/feb/25 pass: 3,931
Build 8: aarch64/2019/feb/27 pass: 3,931
Build 9: aarch64/2019/mar/01 pass: 3,931
Build 10: aarch64/2019/mar/04 pass: 3,931
Build 11: aarch64/2019/mar/06 pass: 3,931
Build 12: aarch64/2019/mar/08 pass: 3,931
Build 13: aarch64/2019/mar/11 pass: 3,931
Build 14: aarch64/2019/mar/13 pass: 3,931

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.71x
Relative performance: Server critical-jOPS (nc): 9.19x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 207.57

Server 207.57 / Server 2014-04-01 (71.00): 2.92x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-02-07 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/037/results/
2019-02-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/039/results/
2019-02-12 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/042/results/
2019-02-14 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/044/results/
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/065/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/067/results/
2019-03-11 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/070/results/
2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/072/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From patrick at os.amperecomputing.com  Thu Mar 14 04:05:21 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Thu, 14 Mar 2019 04:05:21 +0000
Subject: [aarch64-port-dev ] RFR: 8220566: AArch64: Set default vm
 features for Ampere eMAG CPUs
In-Reply-To: <894e63a2-4669-c803-ca37-de9129109acc@redhat.com>
References: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>
 <894e63a2-4669-c803-ca37-de9129109acc@redhat.com>
Message-ID: <BYAPR01MB504665B7F0FD42ABE2C838418F4B0@BYAPR01MB5046.prod.exchangelabs.com>

Hi Andrew

I added below comments in JIRA, also copied here. Thanks for your review.

https://bugs.openjdk.java.net/browse/JDK-8220566?focusedCommentId=14251292&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14251292 
These three flags had been verified on Ampere eMAG platform with a couple of benchmarks and apps
AvoidUnalignedAccesses=TRUE, UseSIMDForMemoryOps=TRUE can bring positive impact consistently, since access to odd alignment memory is not what we expect, and simd instructions replacement for mem/array copying practically helps performance.
While for UseSIMDForArrayEquals=TRUE (default), I am not quite sure yet what took more execution time, either ld1 or umov, or the sequence generated inside generate_large_array_equals_loop_simd. Therefore I make it FALSE within a stricter condition for CPU revisions I have so far.

Regards
Patrick

-----Original Message-----
From: Andrew Dinn <adinn at redhat.com> 
Sent: Wednesday, March 13, 2019 6:27 PM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR: 8220566: AArch64: Set default vm features for Ampere eMAG CPUs

Hi Patrick,

On 13/03/2019 10:11, Patrick Zhang OS wrote:
> Please help review this patch for setting default vm features specifically for Ampere eMAG CPUs.
> 
> Webrev: http://cr.openjdk.java.net/~qpzhang/8220566/webrev.01
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220566
> 
> Tested with Ampere eMAG platforms, jtreg jdk_core and jcstress, etc.
The patch looks like it might be ok. However, that's hard to say because the JIRA issue simply restates what is in the  patch i.e. that these specific code changes are needed.

Could you add a note on the JIRA issue explaining why these configuration options are preferred? At that point it will be possible to review the patch.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From adinn at redhat.com  Thu Mar 14 09:03:11 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 14 Mar 2019 09:03:11 +0000
Subject: [aarch64-port-dev ] RFR: 8220566: AArch64: Set default vm
 features for Ampere eMAG CPUs
In-Reply-To: <BYAPR01MB504665B7F0FD42ABE2C838418F4B0@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>
 <894e63a2-4669-c803-ca37-de9129109acc@redhat.com>
 <BYAPR01MB504665B7F0FD42ABE2C838418F4B0@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <c6d07dd4-ffa9-0fb0-4f54-c8d792e12c9c@redhat.com>

Hi Patrick,

On 14/03/2019 04:05, Patrick Zhang OS wrote:
> I added below comments in JIRA, also copied here. Thanks for your
> review.
> 
> https://bugs.openjdk.java.net/browse/JDK-8220566?focusedCommentId=14251292&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14251292
>  These three flags had been verified on Ampere eMAG platform with a
> couple of benchmarks and apps AvoidUnalignedAccesses=TRUE,
> UseSIMDForMemoryOps=TRUE can bring positive impact consistently,
> since access to odd alignment memory is not what we expect, and simd
> instructions replacement for mem/array copying practically helps
> performance. While for UseSIMDForArrayEquals=TRUE (default), I am not
> quite sure yet what took more execution time, either ld1 or umov, or
> the sequence generated inside generate_large_array_equals_loop_simd.
> Therefore I make it FALSE within a stricter condition for CPU
> revisions I have so far.

Thank you for making your decisions clear. I am happy to accept your
choice of defaults so this patch can be pushed. Do you need me to do
that for you?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From patrick at os.amperecomputing.com  Thu Mar 14 09:10:44 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Thu, 14 Mar 2019 09:10:44 +0000
Subject: [aarch64-port-dev ] RFR: 8220566: AArch64: Set default vm
 features for Ampere eMAG CPUs
In-Reply-To: <c6d07dd4-ffa9-0fb0-4f54-c8d792e12c9c@redhat.com>
References: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>
 <894e63a2-4669-c803-ca37-de9129109acc@redhat.com>
 <BYAPR01MB504665B7F0FD42ABE2C838418F4B0@BYAPR01MB5046.prod.exchangelabs.com>
 <c6d07dd4-ffa9-0fb0-4f54-c8d792e12c9c@redhat.com>
Message-ID: <BYAPR01MB5046CFE8B1E614A64036B4DE8F4B0@BYAPR01MB5046.prod.exchangelabs.com>

Hi Andrew,
Sure, please, thank you very much for sponsoring this.

Regards
Patrick

-----Original Message-----
From: Andrew Dinn <adinn at redhat.com> 
Sent: Thursday, March 14, 2019 5:03 PM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>
Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR: 8220566: AArch64: Set default vm features for Ampere eMAG CPUs

Hi Patrick,

On 14/03/2019 04:05, Patrick Zhang OS wrote:
> I added below comments in JIRA, also copied here. Thanks for your 
> review.
> 
> https://bugs.openjdk.java.net/browse/JDK-8220566?focusedCommentId=1425
> 1292&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabp
> anel#comment-14251292  These three flags had been verified on Ampere 
> eMAG platform with a couple of benchmarks and apps 
> AvoidUnalignedAccesses=TRUE, UseSIMDForMemoryOps=TRUE can bring 
> positive impact consistently, since access to odd alignment memory is 
> not what we expect, and simd instructions replacement for mem/array 
> copying practically helps performance. While for 
> UseSIMDForArrayEquals=TRUE (default), I am not quite sure yet what 
> took more execution time, either ld1 or umov, or the sequence 
> generated inside generate_large_array_equals_loop_simd.
> Therefore I make it FALSE within a stricter condition for CPU 
> revisions I have so far.

Thank you for making your decisions clear. I am happy to accept your choice of defaults so this patch can be pushed. Do you need me to do that for you?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From shade at redhat.com  Thu Mar 14 09:10:03 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Mar 2019 10:10:03 +0100
Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock
 fast path not called
In-Reply-To: <f0081309-ea59-a57d-d251-bff95d1cae54@arm.com>
References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com>
 <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com>
 <f0081309-ea59-a57d-d251-bff95d1cae54@arm.com>
Message-ID: <fd3e67ee-2d60-086d-3923-b99324e001e1@redhat.com>

On 3/13/19 10:18 AM, Nick Gasson wrote:
> Thanks Andrew. Is anyone able to sponsor this patch for me?

I can sponsor this for you.

I imagine you need a sponsor for this one too?
  https://bugs.openjdk.java.net/browse/JDK-8215951

-Aleksey


From nick.gasson at arm.com  Thu Mar 14 09:12:51 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Thu, 14 Mar 2019 17:12:51 +0800
Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock
 fast path not called
In-Reply-To: <fd3e67ee-2d60-086d-3923-b99324e001e1@redhat.com>
References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com>
 <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com>
 <f0081309-ea59-a57d-d251-bff95d1cae54@arm.com>
 <fd3e67ee-2d60-086d-3923-b99324e001e1@redhat.com>
Message-ID: <5cf3922f-4fa7-6577-639a-da871d29332d@arm.com>

On 14/03/2019 17:10, Aleksey Shipilev wrote:
> On 3/13/19 10:18 AM, Nick Gasson wrote:
>> Thanks Andrew. Is anyone able to sponsor this patch for me?
> 
> I can sponsor this for you.

Thanks Aleksey!

> 
> I imagine you need a sponsor for this one too?
>    https://bugs.openjdk.java.net/browse/JDK-8215951
> 

Yes please :-)


Nick

From adinn at redhat.com  Thu Mar 14 11:18:23 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 14 Mar 2019 11:18:23 +0000
Subject: [aarch64-port-dev ] RFR: 8220566: AArch64: Set default vm
 features for Ampere eMAG CPUs
In-Reply-To: <BYAPR01MB5046CFE8B1E614A64036B4DE8F4B0@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>
 <894e63a2-4669-c803-ca37-de9129109acc@redhat.com>
 <BYAPR01MB504665B7F0FD42ABE2C838418F4B0@BYAPR01MB5046.prod.exchangelabs.com>
 <c6d07dd4-ffa9-0fb0-4f54-c8d792e12c9c@redhat.com>
 <BYAPR01MB5046CFE8B1E614A64036B4DE8F4B0@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <2b177cd3-4589-84bb-8831-3c12af80f5fa@redhat.com>

On 14/03/2019 09:10, Patrick Zhang OS wrote:
> Sure, please, thank you very much for sponsoring this.
You are welcome. The patch has been pushed.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From stuart.monteith at linaro.org  Thu Mar 14 17:26:25 2019
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Thu, 14 Mar 2019 17:26:25 +0000
Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far
In-Reply-To: <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com>
 <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
 <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>
Message-ID: <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>

Hello,
   Thanks to Andrew, C1 is now working. I've updated the patches to as
they are today.

The patches are here:

http://cr.openjdk.java.net/~smonteith/zgc/20190314/

I'm doing some more testing and then move onto RFRs.

I have a choice of rolling Roland's membar patch into the ZGC patch
and adding him as a contributor, or I can raise a separate Java bug
and submit it as a separate patch. Are there preferences?

BR,
   Stuart

On Fri, 8 Mar 2019 at 16:34, Stuart Monteith <stuart.monteith at linaro.org> wrote:
>
> Hi,
>    I find when running with -XX:TieredStopAtLevel=1 and ZGC enabled it
> fails when running with Lucene's indexing demo
> "org.apache.lucene.demo.IndexFiles" or SPECjbb2015.
> I tried javac, and other simple examples, but I haven't managed to
> find anything simple that provokes the issue.
>
> I've uploaded this here:
>   http://cr.openjdk.java.net/~smonteith/zgc/Lucene-demo.tar.xz
>
> If you have the appropriate java command on your patch, if you run
> "index.sh" with a directory of files index as the parameter, it will
> reproduce the problem.
>
>
> BR,
>    Stuart
>
> On Fri, 8 Mar 2019 at 16:19, Andrew Haley <aph at redhat.com> wrote:
> >
> > On 3/7/19 11:36 AM, Stuart Monteith wrote:
> > > There is an issue with C1 - the changes in "8217717: ZGC: Broken oop
> > > map in C1 load barrier stub" did regress things somewhat causing
> > > crashes with stale references. However, As patching on aarch64 C1
> > > isn't really supported, I'm not satisfied it was working correctly
> > > before. Patching lea may impractical as things stand today.
> >
> > I can't get it to fail. Please tell me exactly what I have to do to
> > demonstrate the C1 failure.
> >
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From derekw at marvell.com  Thu Mar 14 20:56:13 2019
From: derekw at marvell.com (Derek White)
Date: Thu, 14 Mar 2019 20:56:13 +0000
Subject: [aarch64-port-dev ] [EXT] Re: [Roland Westrelin] Re: Aarch64
 port for ZGC, so far
In-Reply-To: <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com> <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
 <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>
 <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>
Message-ID: <MN2PR18MB273354D50A1231BF5670A1C8D24B0@MN2PR18MB2733.namprd18.prod.outlook.com>

Hi Stuart,

That's great news!

My vote is for separate patches where possible.  It will make pinpointing any potential bugs in the checkins easier, as well as reviewing.

Actually, I hate to do this, but I'll go further...

I think that the oop64 patch could be broken up into patch (A) that adds the patch_info_offset() method, and patch (B) that supports oop64 on aarch64.

Patch (A) is a small fix across many files, and if it's correct(*), it's Correct by Trivial Inspection (CBTI). Could be checked in soon with the understanding that this is required for upcoming patch.

Patch (B) requires some deeper thought, and reviewing is a bit easier with a smaller file set to track. And it should be (mostly) in aarch64 code, not shared.

I'm not sure if the compiler folks need this level of factoring, but it is quite common in the GC team.

 - Derek

(*) I went looking for a caller of new patch_info_offset() method and didn't find one across any of the patches. It looks like it was used in an earlier version of the patch?

> -----Original Message-----
> From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On
> Behalf Of Stuart Monteith
> Sent: Thursday, March 14, 2019 1:26 PM
> To: Andrew Haley <aph at redhat.com>; Roland Westrelin
> <rwestrel at redhat.com>
> Cc: zgc-dev at openjdk.java.net; aarch64-port-dev <aarch64-port-
> dev at openjdk.java.net>
> Subject: [EXT] Re: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port
> for ZGC, so far
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hello,
>    Thanks to Andrew, C1 is now working. I've updated the patches to as they
> are today.
> 
> The patches are here:
> 
> http://cr.openjdk.java.net/~smonteith/zgc/20190314/
> 
> I'm doing some more testing and then move onto RFRs.
> 
> I have a choice of rolling Roland's membar patch into the ZGC patch and
> adding him as a contributor, or I can raise a separate Java bug and submit it
> as a separate patch. Are there preferences?
> 
> BR,
>    Stuart
> 
> On Fri, 8 Mar 2019 at 16:34, Stuart Monteith <stuart.monteith at linaro.org>
> wrote:
> >
> > Hi,
> >    I find when running with -XX:TieredStopAtLevel=1 and ZGC enabled it
> > fails when running with Lucene's indexing demo
> > "org.apache.lucene.demo.IndexFiles" or SPECjbb2015.
> > I tried javac, and other simple examples, but I haven't managed to
> > find anything simple that provokes the issue.
> >
> > I've uploaded this here:
> >   http://cr.openjdk.java.net/~smonteith/zgc/Lucene-demo.tar.xz
> >
> > If you have the appropriate java command on your patch, if you run
> > "index.sh" with a directory of files index as the parameter, it will
> > reproduce the problem.
> >
> >
> > BR,
> >    Stuart
> >
> > On Fri, 8 Mar 2019 at 16:19, Andrew Haley <aph at redhat.com> wrote:
> > >
> > > On 3/7/19 11:36 AM, Stuart Monteith wrote:
> > > > There is an issue with C1 - the changes in "8217717: ZGC: Broken
> > > > oop map in C1 load barrier stub" did regress things somewhat
> > > > causing crashes with stale references. However, As patching on
> > > > aarch64 C1 isn't really supported, I'm not satisfied it was
> > > > working correctly before. Patching lea may impractical as things stand
> today.
> > >
> > > I can't get it to fail. Please tell me exactly what I have to do to
> > > demonstrate the C1 failure.
> > >
> > > --
> > > Andrew Haley
> > > Java Platform Lead Engineer
> > > Red Hat UK Ltd. <https://www.redhat.com>
> > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From patrick at os.amperecomputing.com  Fri Mar 15 02:14:51 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Fri, 15 Mar 2019 02:14:51 +0000
Subject: [aarch64-port-dev ] RFR: 8220566: AArch64: Set default vm
 features for Ampere eMAG CPUs
In-Reply-To: <2b177cd3-4589-84bb-8831-3c12af80f5fa@redhat.com>
References: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>
 <894e63a2-4669-c803-ca37-de9129109acc@redhat.com>
 <BYAPR01MB504665B7F0FD42ABE2C838418F4B0@BYAPR01MB5046.prod.exchangelabs.com>
 <c6d07dd4-ffa9-0fb0-4f54-c8d792e12c9c@redhat.com>
 <BYAPR01MB5046CFE8B1E614A64036B4DE8F4B0@BYAPR01MB5046.prod.exchangelabs.com>
 <2b177cd3-4589-84bb-8831-3c12af80f5fa@redhat.com>
Message-ID: <BYAPR01MB50469272CB2729E73ACD122C8F440@BYAPR01MB5046.prod.exchangelabs.com>

Thanks. http://hg.openjdk.java.net/jdk/jdk/rev/a6221f993616 
Just one trivial problem, I am 'qpzhang' instead of 'pzhang' in census. Luckily we have the same name, so it might confuse people.. :)

Regards
Patrick

-----Original Message-----
From: Andrew Dinn <adinn at redhat.com> 
Sent: Thursday, March 14, 2019 7:18 PM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>
Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR: 8220566: AArch64: Set default vm features for Ampere eMAG CPUs

On 14/03/2019 09:10, Patrick Zhang OS wrote:
> Sure, please, thank you very much for sponsoring this.
You are welcome. The patch has been pushed.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From adinn at redhat.com  Fri Mar 15 09:08:32 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 15 Mar 2019 09:08:32 +0000
Subject: [aarch64-port-dev ] RFR: 8220566: AArch64: Set default vm
 features for Ampere eMAG CPUs
In-Reply-To: <BYAPR01MB50469272CB2729E73ACD122C8F440@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>
 <894e63a2-4669-c803-ca37-de9129109acc@redhat.com>
 <BYAPR01MB504665B7F0FD42ABE2C838418F4B0@BYAPR01MB5046.prod.exchangelabs.com>
 <c6d07dd4-ffa9-0fb0-4f54-c8d792e12c9c@redhat.com>
 <BYAPR01MB5046CFE8B1E614A64036B4DE8F4B0@BYAPR01MB5046.prod.exchangelabs.com>
 <2b177cd3-4589-84bb-8831-3c12af80f5fa@redhat.com>
 <BYAPR01MB50469272CB2729E73ACD122C8F440@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <ab753c60-fb31-48fe-cd8d-81773f130954@redhat.com>

Hi Patrick,

On 15/03/2019 02:14, Patrick Zhang OS wrote:
> Thanks. http://hg.openjdk.java.net/jdk/jdk/rev/a6221f993616 Just one
> trivial problem, I am 'qpzhang' instead of 'pzhang' in census.
> Luckily we have the same name, so it might confuse people.. :)

Oh dear, I am very sorry for using the wrong name. Unfortunately, I am
unable to correct this now that the patch has been pushed. I'll make
sure to use the correct name next time you provide a patch. Also, I'll
remind others to include this patch as yours if in future you want to
apply for committer status.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From aph at redhat.com  Fri Mar 15 09:37:15 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 15 Mar 2019 09:37:15 +0000
Subject: [aarch64-port-dev ] RFR: 8220566: AArch64: Set default vm
 features for Ampere eMAG CPUs
In-Reply-To: <ab753c60-fb31-48fe-cd8d-81773f130954@redhat.com>
References: <BYAPR01MB5046BCDA5EB7EAF6B820FA0E8F4A0@BYAPR01MB5046.prod.exchangelabs.com>
 <894e63a2-4669-c803-ca37-de9129109acc@redhat.com>
 <BYAPR01MB504665B7F0FD42ABE2C838418F4B0@BYAPR01MB5046.prod.exchangelabs.com>
 <c6d07dd4-ffa9-0fb0-4f54-c8d792e12c9c@redhat.com>
 <BYAPR01MB5046CFE8B1E614A64036B4DE8F4B0@BYAPR01MB5046.prod.exchangelabs.com>
 <2b177cd3-4589-84bb-8831-3c12af80f5fa@redhat.com>
 <BYAPR01MB50469272CB2729E73ACD122C8F440@BYAPR01MB5046.prod.exchangelabs.com>
 <ab753c60-fb31-48fe-cd8d-81773f130954@redhat.com>
Message-ID: <eb36301d-f1cf-1901-0354-dcb7be16056a@redhat.com>

On 3/15/19 9:08 AM, Andrew Dinn wrote:
> 
> On 15/03/2019 02:14, Patrick Zhang OS wrote:
>> Thanks. http://hg.openjdk.java.net/jdk/jdk/rev/a6221f993616 Just one
>> trivial problem, I am 'qpzhang' instead of 'pzhang' in census.
>> Luckily we have the same name, so it might confuse people.. :)
> 
> Oh dear, I am very sorry for using the wrong name.

You can use "hg import" on the patch: it does the right thing.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From stuart.monteith at linaro.org  Fri Mar 15 14:10:07 2019
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Fri, 15 Mar 2019 14:10:07 +0000
Subject: [aarch64-port-dev ] [EXT] Re: [Roland Westrelin] Re: Aarch64
 port for ZGC, so far
In-Reply-To: <MN2PR18MB273354D50A1231BF5670A1C8D24B0@MN2PR18MB2733.namprd18.prod.outlook.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com>
 <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
 <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>
 <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>
 <MN2PR18MB273354D50A1231BF5670A1C8D24B0@MN2PR18MB2733.namprd18.prod.outlook.com>
Message-ID: <CAEGA6kbDN1JL6FvDXM6+nOUZDRhFf5ds_68RWcUQ-gqYymVzBQ@mail.gmail.com>

Thanks for taking a look. I agree with the separation, so I'll split
out the refactoring from the functional change for 64-bit literals.

BR,
   Stuart

On Thu, 14 Mar 2019 at 20:58, Derek White <derekw at marvell.com> wrote:
>
> Hi Stuart,
>
> That's great news!
>
> My vote is for separate patches where possible.  It will make pinpointing any potential bugs in the checkins easier, as well as reviewing.
>
> Actually, I hate to do this, but I'll go further...
>
> I think that the oop64 patch could be broken up into patch (A) that adds the patch_info_offset() method, and patch (B) that supports oop64 on aarch64.
>
> Patch (A) is a small fix across many files, and if it's correct(*), it's Correct by Trivial Inspection (CBTI). Could be checked in soon with the understanding that this is required for upcoming patch.
>
> Patch (B) requires some deeper thought, and reviewing is a bit easier with a smaller file set to track. And it should be (mostly) in aarch64 code, not shared.
>
> I'm not sure if the compiler folks need this level of factoring, but it is quite common in the GC team.
>
>  - Derek
>
> (*) I went looking for a caller of new patch_info_offset() method and didn't find one across any of the patches. It looks like it was used in an earlier version of the patch?
>
> > -----Original Message-----
> > From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On
> > Behalf Of Stuart Monteith
> > Sent: Thursday, March 14, 2019 1:26 PM
> > To: Andrew Haley <aph at redhat.com>; Roland Westrelin
> > <rwestrel at redhat.com>
> > Cc: zgc-dev at openjdk.java.net; aarch64-port-dev <aarch64-port-
> > dev at openjdk.java.net>
> > Subject: [EXT] Re: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port
> > for ZGC, so far
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > Hello,
> >    Thanks to Andrew, C1 is now working. I've updated the patches to as they
> > are today.
> >
> > The patches are here:
> >
> > http://cr.openjdk.java.net/~smonteith/zgc/20190314/
> >
> > I'm doing some more testing and then move onto RFRs.
> >
> > I have a choice of rolling Roland's membar patch into the ZGC patch and
> > adding him as a contributor, or I can raise a separate Java bug and submit it
> > as a separate patch. Are there preferences?
> >
> > BR,
> >    Stuart
> >
> > On Fri, 8 Mar 2019 at 16:34, Stuart Monteith <stuart.monteith at linaro.org>
> > wrote:
> > >
> > > Hi,
> > >    I find when running with -XX:TieredStopAtLevel=1 and ZGC enabled it
> > > fails when running with Lucene's indexing demo
> > > "org.apache.lucene.demo.IndexFiles" or SPECjbb2015.
> > > I tried javac, and other simple examples, but I haven't managed to
> > > find anything simple that provokes the issue.
> > >
> > > I've uploaded this here:
> > >   http://cr.openjdk.java.net/~smonteith/zgc/Lucene-demo.tar.xz
> > >
> > > If you have the appropriate java command on your patch, if you run
> > > "index.sh" with a directory of files index as the parameter, it will
> > > reproduce the problem.
> > >
> > >
> > > BR,
> > >    Stuart
> > >
> > > On Fri, 8 Mar 2019 at 16:19, Andrew Haley <aph at redhat.com> wrote:
> > > >
> > > > On 3/7/19 11:36 AM, Stuart Monteith wrote:
> > > > > There is an issue with C1 - the changes in "8217717: ZGC: Broken
> > > > > oop map in C1 load barrier stub" did regress things somewhat
> > > > > causing crashes with stale references. However, As patching on
> > > > > aarch64 C1 isn't really supported, I'm not satisfied it was
> > > > > working correctly before. Patching lea may impractical as things stand
> > today.
> > > >
> > > > I can't get it to fail. Please tell me exactly what I have to do to
> > > > demonstrate the C1 failure.
> > > >
> > > > --
> > > > Andrew Haley
> > > > Java Platform Lead Engineer
> > > > Red Hat UK Ltd. <https://www.redhat.com>
> > > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Fri Mar 15 15:54:44 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 15 Mar 2019 15:54:44 +0000
Subject: [aarch64-port-dev ] [EXT] Re: [Roland Westrelin] Re: Aarch64
 port for ZGC, so far
In-Reply-To: <MN2PR18MB273354D50A1231BF5670A1C8D24B0@MN2PR18MB2733.namprd18.prod.outlook.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com> <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
 <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>
 <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>
 <MN2PR18MB273354D50A1231BF5670A1C8D24B0@MN2PR18MB2733.namprd18.prod.outlook.com>
Message-ID: <1f4b6e0a-f850-2aba-d2cc-e0d37f75dbb0@redhat.com>

On 3/14/19 8:56 PM, Derek White wrote:
> I think that the oop64 patch could be broken up into patch (A) that adds the patch_info_offset() method

We should delete that part. AFAICS it isn't used for anything.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Fri Mar 15 16:07:32 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 15 Mar 2019 16:07:32 +0000
Subject: [aarch64-port-dev ] [EXT] Re: [Roland Westrelin] Re: Aarch64
 port for ZGC, so far
In-Reply-To: <1f4b6e0a-f850-2aba-d2cc-e0d37f75dbb0@redhat.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com> <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
 <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>
 <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>
 <MN2PR18MB273354D50A1231BF5670A1C8D24B0@MN2PR18MB2733.namprd18.prod.outlook.com>
 <1f4b6e0a-f850-2aba-d2cc-e0d37f75dbb0@redhat.com>
Message-ID: <a1a78389-627b-7e3b-dc6a-62ce9f824b22@redhat.com>

On 3/15/19 3:54 PM, Andrew Haley wrote:
> On 3/14/19 8:56 PM, Derek White wrote:
>> I think that the oop64 patch could be broken up into patch (A) that adds the patch_info_offset() method
> 
> We should delete that part. AFAICS it isn't used for anything.

In fact I'm certain it isn't used for anything: I just deleted it, and it makes
no difference.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Fri Mar 15 18:52:12 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 15 Mar 2019 18:52:12 +0000
Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far
In-Reply-To: <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com> <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
 <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>
 <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>
Message-ID: <ac034004-1438-1683-ac7c-38d579f61830@redhat.com>

On 3/14/19 5:26 PM, Stuart Monteith wrote:
> The patches are here:
> 
> http://cr.openjdk.java.net/~smonteith/zgc/20190314/
> 
> I'm doing some more testing and then move onto RFRs.

After https://www.jetbrains.com/idea/ starts up, I get an exit in the "AWT-XAWT" thread:

#0  0x000003ff7eea77d8 in exit () from /lib64/libc.so.6
#1  0x000003fd40a14bac in _XIOError () from /lib64/libX11.so.6
#2  0x000003fd40a125ec in _XEventsQueued () from /lib64/libX11.so.6
#3  0x000003fd40a0452c in XEventsQueued () from /lib64/libX11.so.6
#4  0x000003fd40bb773c in Java_sun_awt_X11_XlibWrapper_XEventsQueued (env=0x3fcf032bc10,
    clazz=0x3fd4146e0f0, display=4384894979008, mode=1)
    at /local/jdk-zgc-new/src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c:804

 0x000003fd4146e1b0: 0x000003fd4146e250 #2 method sun.awt.X11.XToolkit.run(Z)V @ 63
                                        - 8 locals 7 max stack

If I had to guess I'd say something was leaking. The nice thing is, though,
that the failure is entirely repeatable.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From ci_notify at linaro.org  Fri Mar 15 23:54:51 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Fri, 15 Mar 2019 23:54:51 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <1756631069.3708.1552694091726.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/074/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/08 pass: 5,519; fail: 19; error: 2; not run: 93
Build 1: aarch64/2019/feb/11 pass: 5,527; fail: 11; error: 2; not run: 93
Build 2: aarch64/2019/feb/13 pass: 5,537; fail: 4; not run: 93
Build 3: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 4: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 5: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 6: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 7: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 8: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93
Build 9: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93
Build 10: aarch64/2019/mar/06 pass: 5,544; fail: 3; not run: 93
Build 11: aarch64/2019/mar/08 pass: 5,546; fail: 3; not run: 93
Build 12: aarch64/2019/mar/11 pass: 5,547; fail: 3; not run: 93
Build 13: aarch64/2019/mar/13 pass: 5,549; fail: 3; not run: 93
Build 14: aarch64/2019/mar/15 pass: 5,567; fail: 3; not run: 93

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/08 pass: 8,530; fail: 515; error: 23
Build 1: aarch64/2019/feb/11 pass: 8,559; fail: 490; error: 15
Build 2: aarch64/2019/feb/13 pass: 8,534; fail: 512; error: 18
Build 3: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 4: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 5: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 6: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 7: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 8: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20
Build 9: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20
Build 10: aarch64/2019/mar/06 pass: 8,541; fail: 506; error: 21
Build 11: aarch64/2019/mar/08 pass: 8,538; fail: 512; error: 20
Build 12: aarch64/2019/mar/11 pass: 8,531; fail: 520; error: 19
Build 13: aarch64/2019/mar/13 pass: 8,533; fail: 514; error: 22
Build 14: aarch64/2019/mar/15 pass: 8,519; fail: 513; error: 23

2 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/08 pass: 3,994; fail: 1
Build 1: aarch64/2019/feb/11 pass: 3,994; fail: 1
Build 2: aarch64/2019/feb/13 pass: 3,994; fail: 1
Build 3: aarch64/2019/feb/15 pass: 3,995
Build 4: aarch64/2019/feb/18 pass: 3,996
Build 5: aarch64/2019/feb/20 pass: 3,996
Build 6: aarch64/2019/feb/25 pass: 3,931
Build 7: aarch64/2019/feb/27 pass: 3,931
Build 8: aarch64/2019/mar/01 pass: 3,931
Build 9: aarch64/2019/mar/04 pass: 3,931
Build 10: aarch64/2019/mar/06 pass: 3,931
Build 11: aarch64/2019/mar/08 pass: 3,931
Build 12: aarch64/2019/mar/11 pass: 3,931
Build 13: aarch64/2019/mar/13 pass: 3,931
Build 14: aarch64/2019/mar/15 pass: 3,932

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.54x
Relative performance: Server critical-jOPS (nc): 9.69x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 213.86

Server 213.86 / Server 2014-04-01 (71.00): 3.01x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-02-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/039/results/
2019-02-12 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/042/results/
2019-02-14 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/044/results/
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/065/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/067/results/
2019-03-11 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/070/results/
2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/072/results/
2019-03-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/074/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From ci_notify at linaro.org  Sun Mar 17 01:28:23 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Sun, 17 Mar 2019 01:28:23 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64
Message-ID: <1105997140.3806.1552786103972.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/075/summary.html
 
-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/29 pass: 5,709; fail: 9; not run: 11,618
Build 1: aarch64/2019/jan/31 pass: 5,707; fail: 11; not run: 11,618
Build 2: aarch64/2019/feb/02 pass: 5,708; fail: 10; not run: 11,618
Build 3: aarch64/2019/feb/07 pass: 5,710; fail: 9; not run: 11,618
Build 4: aarch64/2019/feb/09 pass: 5,710; fail: 9; not run: 11,618
Build 5: aarch64/2019/feb/12 pass: 5,709; fail: 10; not run: 11,618
Build 6: aarch64/2019/feb/16 pass: 5,713; fail: 10; not run: 11,618
Build 7: aarch64/2019/feb/19 pass: 5,715; fail: 10; not run: 11,618
Build 8: aarch64/2019/feb/21 pass: 5,714; fail: 11; not run: 11,618
Build 9: aarch64/2019/feb/26 pass: 5,717; fail: 9; not run: 11,618
Build 10: aarch64/2019/mar/02 pass: 5,717; fail: 11; not run: 11,618
Build 11: aarch64/2019/mar/05 pass: 5,719; fail: 9; not run: 11,618
Build 12: aarch64/2019/mar/07 pass: 5,719; fail: 9; not run: 11,618
Build 13: aarch64/2019/mar/12 pass: 5,719; fail: 9; not run: 11,618
Build 14: aarch64/2019/mar/16 pass: 5,721; fail: 8; not run: 11,618

1 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/29 pass: 8,353; fail: 524; error: 22
Build 1: aarch64/2019/jan/31 pass: 8,372; fail: 502; error: 25
Build 2: aarch64/2019/feb/02 pass: 8,378; fail: 501; error: 21
Build 3: aarch64/2019/feb/07 pass: 8,364; fail: 507; error: 29
Build 4: aarch64/2019/feb/09 pass: 8,354; fail: 523; error: 23
Build 5: aarch64/2019/feb/12 pass: 8,358; fail: 519; error: 24
Build 6: aarch64/2019/feb/16 pass: 8,356; fail: 520; error: 25
Build 7: aarch64/2019/feb/19 pass: 8,375; fail: 506; error: 24
Build 8: aarch64/2019/feb/21 pass: 8,377; fail: 513; error: 22
Build 9: aarch64/2019/feb/26 pass: 8,387; fail: 501; error: 26
Build 10: aarch64/2019/mar/02 pass: 8,400; fail: 487; error: 29
Build 11: aarch64/2019/mar/05 pass: 8,413; fail: 487; error: 16
Build 12: aarch64/2019/mar/07 pass: 8,388; fail: 502; error: 26
Build 13: aarch64/2019/mar/12 pass: 8,370; fail: 520; error: 26
Build 14: aarch64/2019/mar/16 pass: 8,397; fail: 497; error: 22

6 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/29 pass: 3,903
Build 1: aarch64/2019/jan/31 pass: 3,903
Build 2: aarch64/2019/feb/02 pass: 3,903
Build 3: aarch64/2019/feb/07 pass: 3,903
Build 4: aarch64/2019/feb/09 pass: 3,903
Build 5: aarch64/2019/feb/12 pass: 3,903
Build 6: aarch64/2019/feb/16 pass: 3,903
Build 7: aarch64/2019/feb/19 pass: 3,903
Build 8: aarch64/2019/feb/21 pass: 3,904
Build 9: aarch64/2019/feb/26 pass: 3,904
Build 10: aarch64/2019/mar/02 pass: 3,904
Build 11: aarch64/2019/mar/05 pass: 3,904
Build 12: aarch64/2019/mar/07 pass: 3,904
Build 13: aarch64/2019/mar/12 pass: 3,904
Build 14: aarch64/2019/mar/16 pass: 3,904

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.21x
Relative performance: Server critical-jOPS (nc): 7.95x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 201.64

Server 201.64 / Server 2014-04-01 (71.00): 2.84x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-01-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/029/results/
2019-02-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/031/results/
2019-02-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/033/results/
2019-02-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/038/results/
2019-02-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/040/results/
2019-02-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/043/results/
2019-02-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/047/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/050/results/
2019-02-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/052/results/
2019-02-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/057/results/
2019-03-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/061/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/064/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/066/results/
2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/071/results/
2019-03-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/075/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/

From dmitrij.pochepko at bell-sw.com  Mon Mar 18 17:03:04 2019
From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko)
Date: Mon, 18 Mar 2019 20:03:04 +0300
Subject: [aarch64-port-dev ] RFR(S): 8216989 -
 CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not
 check for zero length on AARCH64
Message-ID: <2f857512-c206-a977-1c48-118f9c9d9a63@bell-sw.com>

Hi all,

please review patch for JDK-8216989 
CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does 
not check for zero length on AARCH64
webrev: http://cr.openjdk.java.net/~dpochepk/8216989/webrev.01/

All platforms except AARCH64 performs zero length check in arraycopy 
post barrier and skip card marking for zero length arrays. Missing check 
can lead to wrong card marking. This patch adds such check.

Testing (using parallel gc, because default g1 is not affected):

- JCK
- jtreg hotspot tests: compiler/*, gc/* and runtime/*
- jtreg jdk tier1-3 tests

no regressions found.

CR: https://bugs.openjdk.java.net/browse/JDK-8216989

Thanks,
Dmitrij


From stuart.monteith at linaro.org  Mon Mar 18 21:55:11 2019
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Mon, 18 Mar 2019 21:55:11 +0000
Subject: [aarch64-port-dev ] [EXT] Re: [Roland Westrelin] Re: Aarch64
 port for ZGC, so far
In-Reply-To: <a1a78389-627b-7e3b-dc6a-62ce9f824b22@redhat.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com>
 <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
 <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>
 <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>
 <MN2PR18MB273354D50A1231BF5670A1C8D24B0@MN2PR18MB2733.namprd18.prod.outlook.com>
 <1f4b6e0a-f850-2aba-d2cc-e0d37f75dbb0@redhat.com>
 <a1a78389-627b-7e3b-dc6a-62ce9f824b22@redhat.com>
Message-ID: <CAEGA6kaX9gMQPHKrjPgVH6Y26gGUYrEfhwpv6s1A68XHAmiP_g@mail.gmail.com>

Hello,
   I don't think that is too surprising. It is called in
Runtime1::patch_code and elsewhere it is only present in asserts - are
you calling trying this with assertions enabled?
As for Runtime1::patch_code, I don't know how likely it is we'll call
that on aarch64, or whether it'll behave differently on other
platforms.

On Fri, 15 Mar 2019 at 16:07, Andrew Haley <aph at redhat.com> wrote:
>
> On 3/15/19 3:54 PM, Andrew Haley wrote:
> > On 3/14/19 8:56 PM, Derek White wrote:
> >> I think that the oop64 patch could be broken up into patch (A) that adds the patch_info_offset() method
> >
> > We should delete that part. AFAICS it isn't used for anything.
>
> In fact I'm certain it isn't used for anything: I just deleted it, and it makes
> no difference.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From ci_notify at linaro.org  Mon Mar 18 23:40:48 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Mon, 18 Mar 2019 23:40:48 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <541194738.3930.1552952449477.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/077/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/11 pass: 5,527; fail: 11; error: 2; not run: 93
Build 1: aarch64/2019/feb/13 pass: 5,537; fail: 4; not run: 93
Build 2: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 3: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 4: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 5: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 6: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 7: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93
Build 8: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93
Build 9: aarch64/2019/mar/06 pass: 5,544; fail: 3; not run: 93
Build 10: aarch64/2019/mar/08 pass: 5,546; fail: 3; not run: 93
Build 11: aarch64/2019/mar/11 pass: 5,547; fail: 3; not run: 93
Build 12: aarch64/2019/mar/13 pass: 5,549; fail: 3; not run: 93
Build 13: aarch64/2019/mar/15 pass: 5,567; fail: 3; not run: 93
Build 14: aarch64/2019/mar/18 pass: 5,568; fail: 3; not run: 93

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/11 pass: 8,559; fail: 490; error: 15
Build 1: aarch64/2019/feb/13 pass: 8,534; fail: 512; error: 18
Build 2: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 3: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 4: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 5: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 6: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 7: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20
Build 8: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20
Build 9: aarch64/2019/mar/06 pass: 8,541; fail: 506; error: 21
Build 10: aarch64/2019/mar/08 pass: 8,538; fail: 512; error: 20
Build 11: aarch64/2019/mar/11 pass: 8,531; fail: 520; error: 19
Build 12: aarch64/2019/mar/13 pass: 8,533; fail: 514; error: 22
Build 13: aarch64/2019/mar/15 pass: 8,519; fail: 513; error: 23
Build 14: aarch64/2019/mar/18 pass: 8,510; fail: 523; error: 24

3 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/11 pass: 3,994; fail: 1
Build 1: aarch64/2019/feb/13 pass: 3,994; fail: 1
Build 2: aarch64/2019/feb/15 pass: 3,995
Build 3: aarch64/2019/feb/18 pass: 3,996
Build 4: aarch64/2019/feb/20 pass: 3,996
Build 5: aarch64/2019/feb/25 pass: 3,931
Build 6: aarch64/2019/feb/27 pass: 3,931
Build 7: aarch64/2019/mar/01 pass: 3,931
Build 8: aarch64/2019/mar/04 pass: 3,931
Build 9: aarch64/2019/mar/06 pass: 3,931
Build 10: aarch64/2019/mar/08 pass: 3,931
Build 11: aarch64/2019/mar/11 pass: 3,931
Build 12: aarch64/2019/mar/13 pass: 3,931
Build 13: aarch64/2019/mar/15 pass: 3,932
Build 14: aarch64/2019/mar/18 pass: 3,932

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.63x
Relative performance: Server critical-jOPS (nc): 8.73x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 207.57

Server 207.57 / Server 2014-04-01 (71.00): 2.92x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-02-12 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/042/results/
2019-02-14 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/044/results/
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/065/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/067/results/
2019-03-11 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/070/results/
2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/072/results/
2019-03-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/074/results/
2019-03-18 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/077/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From patrick at os.amperecomputing.com  Tue Mar 19 02:54:51 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Tue, 19 Mar 2019 02:54:51 +0000
Subject: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u
In-Reply-To: <198e497f-1246-76d3-cfc5-6b2cf76eb762@redhat.com>
References: <90f87ab9-5a96-eb2c-dbaa-f9e0cb3eea48@redhat.com>
 <0b22004e-65da-b614-5f31-1f4cb189f404@redhat.com>
 <198e497f-1246-76d3-cfc5-6b2cf76eb762@redhat.com>
Message-ID: <BYAPR01MB50466DDDC14DD9BD05168E978F400@BYAPR01MB5046.prod.exchangelabs.com>

"jdk8u-aarch64-fix-request" looks nice to me, could I start to use it to ask for approval if no objection? 
I had a practical case for this, https://bugs.openjdk.java.net/browse/JDK-8215976, a backport request to aarch64-port/jdk8u-shenandoah/jdk, but no progress for days. https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-March/007025.html  

There is "jdk8u-critical-request", do we need "jdk8u-aarch64-critical-request" similarly?

Regards
Patrick

-----Original Message-----
From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On Behalf Of Andrew Haley
Sent: Tuesday, March 12, 2019 4:26 PM
To: Aleksey Shipilev <shade at redhat.com>; aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u

On 3/11/19 3:09 PM, Aleksey Shipilev wrote:
> On 3/11/19 4:04 PM, Andrew Haley wrote:
>> I'm thinking about what to do about backport approvals. For 11u it's 
>> clear: add the label "jdk11u-fix-request" to the bug database entry. 
>> For 8u it's not so clear because AArch64 is not in the 8u mainline. 
>> We could just use the "jdk8u-fix-request" anyway, even so. Thoughts?
> 
> That would be confusing, because backport tracking (either in JIRA or 
> external) would look for the backports resolved in openjdk8u*, which 
> is jdk8u/*, not aarch64-port.

OK. that makes sense.

> We have the same problem in Shenandoah 11u and 8u, and we "just"
> backport stuff into development versions without requesting backports 
> via JDK Updates process. Because, in retrospect, these downstream 
> repositories are not related to JDK Updates project at all.

Well, I'd disagree with that: they are related in the same way that A is a child of B.

How about "jdk8u-aarch64-fix-request" etc. ?

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Tue Mar 19 09:14:51 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Mar 2019 09:14:51 +0000
Subject: [aarch64-port-dev ] [EXT] Re: [Roland Westrelin] Re: Aarch64
 port for ZGC, so far
In-Reply-To: <CAEGA6kaX9gMQPHKrjPgVH6Y26gGUYrEfhwpv6s1A68XHAmiP_g@mail.gmail.com>
References: <877egxmpx4.fsf@redhat.com>
 <bdedf1a6-94f7-89de-1b6f-a86902cfd0ca@redhat.com> <87d0qokk25.fsf@redhat.com>
 <CAEGA6kY-pi=uKCJF3uuTqz5Kjxv=OUzu6LOuGd+hsH2dFaoEiA@mail.gmail.com>
 <87o9a6k55g.fsf@redhat.com>
 <CAEGA6kaPEpWk_hqP2vOTtbia+12UGEoGjLZZNu5W1bNfqif_-Q@mail.gmail.com>
 <875zw9k63l.fsf@redhat.com>
 <CAEGA6kZfKvNNFxBgEuXb6g9+mA=Op_=9NhdCi+LoOHtO9czfSA@mail.gmail.com>
 <090f5722-daa7-bbb0-cff4-f017514a46fb@redhat.com>
 <CAEGA6kaR3Rbp7jKABTayxGtbnPZ8OYbUDo5k-bqFVP6-se4bwA@mail.gmail.com>
 <CAEGA6kaUG_aZrKpnD0sk47_FJv9P2tC_NTSqBGduNfhToA523Q@mail.gmail.com>
 <MN2PR18MB273354D50A1231BF5670A1C8D24B0@MN2PR18MB2733.namprd18.prod.outlook.com>
 <1f4b6e0a-f850-2aba-d2cc-e0d37f75dbb0@redhat.com>
 <a1a78389-627b-7e3b-dc6a-62ce9f824b22@redhat.com>
 <CAEGA6kaX9gMQPHKrjPgVH6Y26gGUYrEfhwpv6s1A68XHAmiP_g@mail.gmail.com>
Message-ID: <a6f611dd-8c62-57c6-e976-ded8e608977f@redhat.com>

On 3/18/19 9:55 PM, Stuart Monteith wrote:
>    I don't think that is too surprising. It is called in
> Runtime1::patch_code and elsewhere it is only present in asserts - are
> you calling trying this with assertions enabled?

Yes.

> As for Runtime1::patch_code, I don't know how likely it is we'll call
> that on aarch64, or whether it'll behave differently on other
> platforms.

I do, because I write it! We don't do C1 patching on AArch64.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Tue Mar 19 09:21:29 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Mar 2019 09:21:29 +0000
Subject: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u
In-Reply-To: <BYAPR01MB50466DDDC14DD9BD05168E978F400@BYAPR01MB5046.prod.exchangelabs.com>
References: <90f87ab9-5a96-eb2c-dbaa-f9e0cb3eea48@redhat.com>
 <0b22004e-65da-b614-5f31-1f4cb189f404@redhat.com>
 <198e497f-1246-76d3-cfc5-6b2cf76eb762@redhat.com>
 <BYAPR01MB50466DDDC14DD9BD05168E978F400@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <f906f866-b3ab-53d1-bfc4-979cf9f5f97b@redhat.com>

On 3/19/19 2:54 AM, Patrick Zhang OS wrote:
> I had a practical case for this, https://bugs.openjdk.java.net/browse/JDK-8215976, a backport request to aarch64-port/jdk8u-shenandoah/jdk, but no progress for days. https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-March/007025.html  
> 
> There is "jdk8u-critical-request", do we need "jdk8u-aarch64-critical-request" similarly?

Not for this one, no: aarch64-port/jdk8u-shenandoah/jdk pulls from jdk8u,
and the bug is approved for 8u backport.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From patrick at os.amperecomputing.com  Tue Mar 19 09:50:59 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Tue, 19 Mar 2019 09:50:59 +0000
Subject: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u
In-Reply-To: <f906f866-b3ab-53d1-bfc4-979cf9f5f97b@redhat.com>
References: <90f87ab9-5a96-eb2c-dbaa-f9e0cb3eea48@redhat.com>
 <0b22004e-65da-b614-5f31-1f4cb189f404@redhat.com>
 <198e497f-1246-76d3-cfc5-6b2cf76eb762@redhat.com>
 <BYAPR01MB50466DDDC14DD9BD05168E978F400@BYAPR01MB5046.prod.exchangelabs.com>
 <f906f866-b3ab-53d1-bfc4-979cf9f5f97b@redhat.com>
Message-ID: <BYAPR01MB50464F895A1464478076EA0C8F400@BYAPR01MB5046.prod.exchangelabs.com>

Hi Andrew,
I am confused, jdk8u-aarch64-fix-request is for managing backports from jdk/jdk to where?
By the way, about the bug I mentioned, I know 8u backport has been done (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/db7a698be165), do you mean "aarch64-port/jdk8u-shenandoah/jdk pulls from jdk8u" for it would happen automatically soon? or per request?

Thanks
Patrick

-----Original Message-----
From: Andrew Haley <aph at redhat.com> 
Sent: Tuesday, March 19, 2019 5:21 PM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>; Aleksey Shipilev <shade at redhat.com>; aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u

On 3/19/19 2:54 AM, Patrick Zhang OS wrote:
> I had a practical case for this, 
> https://bugs.openjdk.java.net/browse/JDK-8215976, a backport request 
> to aarch64-port/jdk8u-shenandoah/jdk, but no progress for days. 
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-March/00
> 7025.html
> 
> There is "jdk8u-critical-request", do we need "jdk8u-aarch64-critical-request" similarly?

Not for this one, no: aarch64-port/jdk8u-shenandoah/jdk pulls from jdk8u, and the bug is approved for 8u backport.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Tue Mar 19 10:04:47 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 19 Mar 2019 10:04:47 +0000
Subject: [aarch64-port-dev ] RFR(S): 8216989 -
 CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not
 check for zero length on AARCH64
In-Reply-To: <2f857512-c206-a977-1c48-118f9c9d9a63@bell-sw.com>
References: <2f857512-c206-a977-1c48-118f9c9d9a63@bell-sw.com>
Message-ID: <ff8849a2-684c-aa98-14b3-4aae0c252744@redhat.com>

Hello Dmitrij,

On 18/03/2019 17:03, Dmitrij Pochepko wrote:
> Hi all,
> 
> please review patch for JDK-8216989
> CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does
> not check for zero length on AARCH64
> webrev: http://cr.openjdk.java.net/~dpochepk/8216989/webrev.01/
> 
> All platforms except AARCH64 performs zero length check in arraycopy
> post barrier and skip card marking for zero length arrays. Missing check
> can lead to wrong card marking. This patch adds such check.
> 
> Testing (using parallel gc, because default g1 is not affected):
> 
> - JCK
> - jtreg hotspot tests: compiler/*, gc/* and runtime/*
> - jtreg jdk tier1-3 tests
> 
> no regressions found.
> 
> CR: https://bugs.openjdk.java.net/browse/JDK-8216989

The patch looks good on its own. However, I think there is a bigger
problem here and a better solution is available.

On x86_64 the stub code calls arraycopy_prologue passing in a start +
dest address (dst) and count (cnt). The implementation in
ShenandoahBarrierSetAssembler calls out to a C runtime handler
(ShenandoahRuntime::write_ref_array_post_entry), passing dst and cnt.
The one in ModRefBarrierSetAssembler virtually invokes either
G1BarrierSetAssembler::gen_write_ref_array_post_barrier or
CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier, passing
in dst and count.

The G1 implementation calls out to C runtime code passing dst and count.
The CardTable implementation subtracts 1 from count and then adds dst to
cnt to get an inclusive end address and then processes the dst entries
in a loop. So, the latter bails out at the start if cnt == 0 as there is
no work to do.

On AArch64 for some unexplained reason it is the stub code which
modifies cnt, performing the decrement and address add. So, cnt is
passed in to the ModRef and Shenandoah barrier set implementations of
arraycopy_prologue as an inclusive end pointer. The implementation of
arraycopy_prologue in ModRefBarrierSetAssembler passes these values on
through to G1BarrierSetAssembler::gen_write_ref_array_post_barrier and
CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier -- the
AArch64 versions -- using a virtual invoke, just as for x86

So, the AArch64 CardTable implementation now needs to bail out if end <
start where the x86 version bails out if cnt == 0. And, of course, it
doesn't include code for the decrement and pointer add. However, the
AArch64 ShenandoahBarrierSetAssembler::arraycopy_epilogue implementation
now has to convert its inclusive end pointer argument back to a count.
So, it adds BytesPerHeapOop to end, subtracts start and then shifts by
LogBytesPerHeapOop. Similarly, the G1 implementation of
gen_write_ref_array_post_barrier has to convert its end pointer back to
a count performing the same operations.

This looks like a pointless divergence from x86_64 that simply adds more
work and complicates the code. So, I suggest fixing AArch64 by following
x86_64 i.e.

  relocating the conversion of count to an inclusive end pointer back
into the CardTable implementation of gen_write_ref_array_post_barrier

  removing the pointer arithmetic to re-establish the count in
ShenandoahBarrierSetAssembler::arraycopy_epilogue and
G1BarrierSetAssembler::gen_write_ref_array_post_barrier

  rewriting your bail out test to detect cnt == 0

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From aph at redhat.com  Tue Mar 19 10:16:11 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Mar 2019 10:16:11 +0000
Subject: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u
In-Reply-To: <BYAPR01MB50464F895A1464478076EA0C8F400@BYAPR01MB5046.prod.exchangelabs.com>
References: <90f87ab9-5a96-eb2c-dbaa-f9e0cb3eea48@redhat.com>
 <0b22004e-65da-b614-5f31-1f4cb189f404@redhat.com>
 <198e497f-1246-76d3-cfc5-6b2cf76eb762@redhat.com>
 <BYAPR01MB50466DDDC14DD9BD05168E978F400@BYAPR01MB5046.prod.exchangelabs.com>
 <f906f866-b3ab-53d1-bfc4-979cf9f5f97b@redhat.com>
 <BYAPR01MB50464F895A1464478076EA0C8F400@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <aa1921f6-430b-fe51-1bdf-965af22bbffc@redhat.com>

On 3/19/19 9:50 AM, Patrick Zhang OS wrote:
> I am confused, jdk8u-aarch64-fix-request is for managing backports from jdk/jdk to where?

aarch64-port/jdk8u-shenandoah/jdk

> By the way, about the bug I mentioned, I know 8u backport has been done (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/db7a698be165), do you mean "aarch64-port/jdk8u-shenandoah/jdk pulls from jdk8u" for it would happen automatically soon?

That's right. aarch64-port/jdk8u-shenandoah/jdk pulls *everything* from
jdk8u/jdk8u. We're due to do a release in April.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From patrick at os.amperecomputing.com  Tue Mar 19 10:30:39 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Tue, 19 Mar 2019 10:30:39 +0000
Subject: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u
In-Reply-To: <aa1921f6-430b-fe51-1bdf-965af22bbffc@redhat.com>
References: <90f87ab9-5a96-eb2c-dbaa-f9e0cb3eea48@redhat.com>
 <0b22004e-65da-b614-5f31-1f4cb189f404@redhat.com>
 <198e497f-1246-76d3-cfc5-6b2cf76eb762@redhat.com>
 <BYAPR01MB50466DDDC14DD9BD05168E978F400@BYAPR01MB5046.prod.exchangelabs.com>
 <f906f866-b3ab-53d1-bfc4-979cf9f5f97b@redhat.com>
 <BYAPR01MB50464F895A1464478076EA0C8F400@BYAPR01MB5046.prod.exchangelabs.com>
 <aa1921f6-430b-fe51-1bdf-965af22bbffc@redhat.com>
Message-ID: <BYAPR01MB5046B1A5526B89046B78818D8F400@BYAPR01MB5046.prod.exchangelabs.com>

Understood, thanks for your patient explanation.

Regards
Patrick

-----Original Message-----
From: Andrew Haley <aph at redhat.com> 
Sent: Tuesday, March 19, 2019 6:16 PM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>
Cc: Aleksey Shipilev <shade at redhat.com>; aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] Pending AArch64 patches for 8u and 11u

On 3/19/19 9:50 AM, Patrick Zhang OS wrote:
> I am confused, jdk8u-aarch64-fix-request is for managing backports from jdk/jdk to where?

aarch64-port/jdk8u-shenandoah/jdk

> By the way, about the bug I mentioned, I know 8u backport has been done (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/db7a698be165), do you mean "aarch64-port/jdk8u-shenandoah/jdk pulls from jdk8u" for it would happen automatically soon?

That's right. aarch64-port/jdk8u-shenandoah/jdk pulls *everything* from jdk8u/jdk8u. We're due to do a release in April.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Tue Mar 19 10:52:43 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Mar 2019 10:52:43 +0000
Subject: [aarch64-port-dev ] RFR(S): 8216989 -
 CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not
 check for zero length on AARCH64
In-Reply-To: <ff8849a2-684c-aa98-14b3-4aae0c252744@redhat.com>
References: <2f857512-c206-a977-1c48-118f9c9d9a63@bell-sw.com>
 <ff8849a2-684c-aa98-14b3-4aae0c252744@redhat.com>
Message-ID: <288f6d65-5aff-0ba1-1a1c-890700b985db@redhat.com>

On 3/19/19 10:04 AM, Andrew Dinn wrote:
> On AArch64 for some unexplained reason it is the stub code which
> modifies cnt, performing the decrement and address add.

That's how x86 did it back then. x86 got fixed by
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/3f281b313240

We should look at that patch *extremely* *carefully*, and make sure we've
got all the fixes. The AArch64 version is based on that code, so it will
probably have inherited its bugs.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Tue Mar 19 11:16:02 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 19 Mar 2019 11:16:02 +0000
Subject: [aarch64-port-dev ] RFR(S): 8216989 -
 CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not
 check for zero length on AARCH64
In-Reply-To: <288f6d65-5aff-0ba1-1a1c-890700b985db@redhat.com>
References: <2f857512-c206-a977-1c48-118f9c9d9a63@bell-sw.com>
 <ff8849a2-684c-aa98-14b3-4aae0c252744@redhat.com>
 <288f6d65-5aff-0ba1-1a1c-890700b985db@redhat.com>
Message-ID: <f0f11975-0771-b331-6652-7cb3c4881e76@redhat.com>

On 19/03/2019 10:52, Andrew Haley wrote:
> On 3/19/19 10:04 AM, Andrew Dinn wrote:
>> On AArch64 for some unexplained reason it is the stub code which
>> modifies cnt, performing the decrement and address add.
> 
> That's how x86 did it back then. x86 got fixed by
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/3f281b313240
> 
> We should look at that patch *extremely* *carefully*, and make sure we've
> got all the fixes. The AArch64 version is based on that code, so it will
> probably have inherited its bugs.
Ok, noted.

Dmitrij, please prepare a revised patch to re-align AArch64 with x86_64
as previously recommended and then check it is consistent with the above
commit. I'll do the same at re-review to ensure that we have two sets of
eyes on the problem.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From ci_notify at linaro.org  Wed Mar 20 01:32:33 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Wed, 20 Mar 2019 01:32:33 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64
Message-ID: <1029866236.4049.1553045554150.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/078/summary.html
 
-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/31 pass: 5,707; fail: 11; not run: 11,618
Build 1: aarch64/2019/feb/02 pass: 5,708; fail: 10; not run: 11,618
Build 2: aarch64/2019/feb/07 pass: 5,710; fail: 9; not run: 11,618
Build 3: aarch64/2019/feb/09 pass: 5,710; fail: 9; not run: 11,618
Build 4: aarch64/2019/feb/12 pass: 5,709; fail: 10; not run: 11,618
Build 5: aarch64/2019/feb/16 pass: 5,713; fail: 10; not run: 11,618
Build 6: aarch64/2019/feb/19 pass: 5,715; fail: 10; not run: 11,618
Build 7: aarch64/2019/feb/21 pass: 5,714; fail: 11; not run: 11,618
Build 8: aarch64/2019/feb/26 pass: 5,717; fail: 9; not run: 11,618
Build 9: aarch64/2019/mar/02 pass: 5,717; fail: 11; not run: 11,618
Build 10: aarch64/2019/mar/05 pass: 5,719; fail: 9; not run: 11,618
Build 11: aarch64/2019/mar/07 pass: 5,719; fail: 9; not run: 11,618
Build 12: aarch64/2019/mar/12 pass: 5,719; fail: 9; not run: 11,618
Build 13: aarch64/2019/mar/16 pass: 5,721; fail: 8; not run: 11,618
Build 14: aarch64/2019/mar/19 pass: 5,721; fail: 9; not run: 11,618

1 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/31 pass: 8,372; fail: 502; error: 25
Build 1: aarch64/2019/feb/02 pass: 8,378; fail: 501; error: 21
Build 2: aarch64/2019/feb/07 pass: 8,364; fail: 507; error: 29
Build 3: aarch64/2019/feb/09 pass: 8,354; fail: 523; error: 23
Build 4: aarch64/2019/feb/12 pass: 8,358; fail: 519; error: 24
Build 5: aarch64/2019/feb/16 pass: 8,356; fail: 520; error: 25
Build 6: aarch64/2019/feb/19 pass: 8,375; fail: 506; error: 24
Build 7: aarch64/2019/feb/21 pass: 8,377; fail: 513; error: 22
Build 8: aarch64/2019/feb/26 pass: 8,387; fail: 501; error: 26
Build 9: aarch64/2019/mar/02 pass: 8,400; fail: 487; error: 29
Build 10: aarch64/2019/mar/05 pass: 8,413; fail: 487; error: 16
Build 11: aarch64/2019/mar/07 pass: 8,388; fail: 502; error: 26
Build 12: aarch64/2019/mar/12 pass: 8,370; fail: 520; error: 26
Build 13: aarch64/2019/mar/16 pass: 8,397; fail: 497; error: 22
Build 14: aarch64/2019/mar/19 pass: 8,365; fail: 527; error: 24

3 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/31 pass: 3,903
Build 1: aarch64/2019/feb/02 pass: 3,903
Build 2: aarch64/2019/feb/07 pass: 3,903
Build 3: aarch64/2019/feb/09 pass: 3,903
Build 4: aarch64/2019/feb/12 pass: 3,903
Build 5: aarch64/2019/feb/16 pass: 3,903
Build 6: aarch64/2019/feb/19 pass: 3,903
Build 7: aarch64/2019/feb/21 pass: 3,904
Build 8: aarch64/2019/feb/26 pass: 3,904
Build 9: aarch64/2019/mar/02 pass: 3,904
Build 10: aarch64/2019/mar/05 pass: 3,904
Build 11: aarch64/2019/mar/07 pass: 3,904
Build 12: aarch64/2019/mar/12 pass: 3,904
Build 13: aarch64/2019/mar/16 pass: 3,904
Build 14: aarch64/2019/mar/19 pass: 3,904

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.29x
Relative performance: Server critical-jOPS (nc): 8.09x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 204.57

Server 204.57 / Server 2014-04-01 (71.00): 2.88x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-02-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/031/results/
2019-02-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/033/results/
2019-02-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/038/results/
2019-02-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/040/results/
2019-02-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/043/results/
2019-02-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/047/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/050/results/
2019-02-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/052/results/
2019-02-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/057/results/
2019-03-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/061/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/064/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/066/results/
2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/071/results/
2019-03-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/075/results/
2019-03-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/078/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/

From Zheng.Xu at arm.com  Wed Mar 20 01:58:13 2019
From: Zheng.Xu at arm.com (Zheng Xu (Arm Technology China))
Date: Wed, 20 Mar 2019 01:58:13 +0000
Subject: [aarch64-port-dev ] lost your emails to the OpenJDK mail list
Message-ID: <VI1PR08MB29769EBCC828639EF6505E8F96410@VI1PR08MB2976.eurprd08.prod.outlook.com>

Hi Dmitry,

Sorry for bothering you. But we(Arm) lost the emails you sent to OpenJDK mail list. So far we don't know the reason why that happens.
Would you mind to do me a favor to send a test mail to "Nick Gasson (Arm Technology China) <Nick.Gasson at arm.com>; Ramya Kolagi Vittal <Ramya.KolagiVittal at arm.com>; aarch64-port-dev at openjdk.java.net; Zheng Xu <Zheng.Xu at arm.com>" including aarch64-port-dev mail list? So that it may help our IT to triage the problem.

Thanks,
Zheng

From Zheng.Xu at arm.com  Wed Mar 20 02:14:47 2019
From: Zheng.Xu at arm.com (Zheng Xu (Arm Technology China))
Date: Wed, 20 Mar 2019 02:14:47 +0000
Subject: [aarch64-port-dev ] lost your emails to the OpenJDK mail list
In-Reply-To: <VI1PR08MB29769EBCC828639EF6505E8F96410@VI1PR08MB2976.eurprd08.prod.outlook.com>
References: <VI1PR08MB29769EBCC828639EF6505E8F96410@VI1PR08MB2976.eurprd08.prod.outlook.com>
Message-ID: <VI1PR08MB297609E116605804BC7E9BE396410@VI1PR08MB2976.eurprd08.prod.outlook.com>

Sorry for spamming. I don't mean to send this to aarch64-port-dev mail list.

From: Zheng Xu (Arm Technology China)
Sent: Wednesday, March 20, 2019 9:58
To: 'Dmitry Samersoff' <dms at samersoff.net>
Cc: Nick Gasson (Arm Technology China) <Nick.Gasson at arm.com>; Ramya Kolagi Vittal <Ramya.KolagiVittal at arm.com>; aarch64-port-dev at openjdk.java.net; Zheng Xu (Zheng.Xu at arm.com) <Zheng.Xu at arm.com>
Subject: lost your emails to the OpenJDK mail list

Hi Dmitry,

Sorry for bothering you. But we(Arm) lost the emails you sent to OpenJDK mail list. So far we don't know the reason why that happens.

Would you mind to do me a favor to send a test mail to "Nick Gasson (Arm Technology China) <Nick.Gasson at arm.com<mailto:Nick.Gasson at arm.com>>; Ramya Kolagi Vittal <Ramya.KolagiVittal at arm.com<mailto:Ramya.KolagiVittal at arm.com>>; aarch64-port-dev at openjdk.java.net<mailto:aarch64-port-dev at openjdk.java.net>; Zheng Xu <Zheng.Xu at arm.com<mailto:Zheng.Xu at arm.com>>" including aarch64-port-dev mail list? So that it may help our IT to triage the problem.

Thanks,
Zheng

From dmitrij.pochepko at bell-sw.com  Wed Mar 20 17:29:47 2019
From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko)
Date: Wed, 20 Mar 2019 20:29:47 +0300
Subject: [aarch64-port-dev ] RFR(S): 8216989 -
 CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not
 check for zero length on AARCH64
In-Reply-To: <f0f11975-0771-b331-6652-7cb3c4881e76@redhat.com>
References: <2f857512-c206-a977-1c48-118f9c9d9a63@bell-sw.com>
 <ff8849a2-684c-aa98-14b3-4aae0c252744@redhat.com>
 <288f6d65-5aff-0ba1-1a1c-890700b985db@redhat.com>
 <f0f11975-0771-b331-6652-7cb3c4881e76@redhat.com>
Message-ID: <cb8775ec-bdbf-ff84-c79b-ce9b2150a8a7@bell-sw.com>


On 19/03/2019 2:16 PM, Andrew Dinn wrote:
> On 19/03/2019 10:52, Andrew Haley wrote:
>> On 3/19/19 10:04 AM, Andrew Dinn wrote:
>>> On AArch64 for some unexplained reason it is the stub code which
>>> modifies cnt, performing the decrement and address add.
>> That's how x86 did it back then. x86 got fixed by
>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/3f281b313240
>>
>> We should look at that patch *extremely* *carefully*, and make sure we've
>> got all the fixes. The AArch64 version is based on that code, so it will
>> probably have inherited its bugs.
> Ok, noted.
>
> Dmitrij, please prepare a revised patch to re-align AArch64 with x86_64
> as previously recommended and then check it is consistent with the above
> commit. I'll do the same at re-review to ensure that we have two sets of
> eyes on the problem.
>
Hi,

Please take a look at 
http://cr.openjdk.java.net/~dpochepk/8216989/webrev.02/
I changed patch according to x86 fix and current code layout:

- renamed methods parameters from "end" to "count" to avoid confusing 
names and match x86
- updated G1BarrierSetAssembler::gen_write_ref_array_post_barrier 
implementation: removed code with calculation of "count" value and using 
"count" directly instead
- updated ShenandoahBarrierSetAssembler::arraycopy_epilogue in same way 
as G1 code
- updated CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier 
with zero length branch and calculation of inclusive end pointer to 
match original logic
- updated arraycopy_epilogue usage by removing unnecessary end pointer 
calculation and providing array length (count) instead

I also run jtreg hotspot/compiler, hotspot/gc, hotspot/runtime and jck 
with G1GC, ParallelGC and ShenandoahGC
No regressions found.

Thanks,
Dmitrij


From ci_notify at linaro.org  Wed Mar 20 23:15:27 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Wed, 20 Mar 2019 23:15:27 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <1216238675.4176.1553123727703.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/079/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/13 pass: 5,537; fail: 4; not run: 93
Build 1: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 2: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 3: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 4: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 5: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 6: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93
Build 7: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93
Build 8: aarch64/2019/mar/06 pass: 5,544; fail: 3; not run: 93
Build 9: aarch64/2019/mar/08 pass: 5,546; fail: 3; not run: 93
Build 10: aarch64/2019/mar/11 pass: 5,547; fail: 3; not run: 93
Build 11: aarch64/2019/mar/13 pass: 5,549; fail: 3; not run: 93
Build 12: aarch64/2019/mar/15 pass: 5,567; fail: 3; not run: 93
Build 13: aarch64/2019/mar/18 pass: 5,568; fail: 3; not run: 93
Build 14: aarch64/2019/mar/20 pass: 5,568; fail: 3; not run: 93

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/13 pass: 8,534; fail: 512; error: 18
Build 1: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 2: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 3: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 4: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 5: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 6: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20
Build 7: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20
Build 8: aarch64/2019/mar/06 pass: 8,541; fail: 506; error: 21
Build 9: aarch64/2019/mar/08 pass: 8,538; fail: 512; error: 20
Build 10: aarch64/2019/mar/11 pass: 8,531; fail: 520; error: 19
Build 11: aarch64/2019/mar/13 pass: 8,533; fail: 514; error: 22
Build 12: aarch64/2019/mar/15 pass: 8,519; fail: 513; error: 23
Build 13: aarch64/2019/mar/18 pass: 8,510; fail: 523; error: 24
Build 14: aarch64/2019/mar/20 pass: 8,513; fail: 522; error: 25

1 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/13 pass: 3,994; fail: 1
Build 1: aarch64/2019/feb/15 pass: 3,995
Build 2: aarch64/2019/feb/18 pass: 3,996
Build 3: aarch64/2019/feb/20 pass: 3,996
Build 4: aarch64/2019/feb/25 pass: 3,931
Build 5: aarch64/2019/feb/27 pass: 3,931
Build 6: aarch64/2019/mar/01 pass: 3,931
Build 7: aarch64/2019/mar/04 pass: 3,931
Build 8: aarch64/2019/mar/06 pass: 3,931
Build 9: aarch64/2019/mar/08 pass: 3,931
Build 10: aarch64/2019/mar/11 pass: 3,931
Build 11: aarch64/2019/mar/13 pass: 3,931
Build 12: aarch64/2019/mar/15 pass: 3,932
Build 13: aarch64/2019/mar/18 pass: 3,932
Build 14: aarch64/2019/mar/20 pass: 3,933

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.63x
Relative performance: Server critical-jOPS (nc): 8.94x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 207.57

Server 207.57 / Server 2014-04-01 (71.00): 2.92x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-02-14 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/044/results/
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/065/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/067/results/
2019-03-11 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/070/results/
2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/072/results/
2019-03-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/074/results/
2019-03-18 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/077/results/
2019-03-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/079/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From ci_notify at linaro.org  Thu Mar 21 19:27:16 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Thu, 21 Mar 2019 19:27:16 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 1011
	Failure
Message-ID: <1835693315.4387.1553196437994.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Failure
Build details -  https://ci.linaro.org/job/jdkX-ci-build/1011/

Changes -
  bchristi: 3fe41815505c3454b90e869f26321152b7c693b2 
	- src/java.base/share/classes/jdk/internal/loader/URLClassPath.java 
--"8211941: Enable checking/ignoring of non-conforming Class-Path entries
Reviewed-by: alanb, mchung
"  bobv: 98a01c1344aaf2cfc77e3a2a6462c0c5b3315575 
	- test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java
	- test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java 
--"8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs
Reviewed-by: sspitsyn, sgehwolf
"

Build output -
   Building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'
   Compiling 8 files for BUILD_TOOLS_LANGTOOLS
   Compiling 1 files for BUILD_JFR_TOOLS
   Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
   Compiling 2 files for BUILD_JVMTI_TOOLS
   Compiling 10 properties into resource bundles for jdk.javadoc
   Compiling 7 properties into resource bundles for jdk.jshell
   Parsing 2 properties into enum-like class for jdk.compiler
   Compiling 19 properties into resource bundles for jdk.compiler
   Compiling 12 properties into resource bundles for jdk.jdeps
   Compiling 117 files for BUILD_java.compiler.interim
   Compiling 396 files for BUILD_jdk.compiler.interim
   Creating support/modules_libs/java.base/server/libjvm.so from 919 file(s)
   Creating hotspot/variant-server/libjvm/gtest/libjvm.so from 110 file(s)
   Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s)
   Compiling 225 files for BUILD_jdk.javadoc.interim
   Compiling 162 files for BUILD_TOOLS_JDK
   Compiling 3 files for BUILD_VM_COMPILER_MATCH_PROCESSOR
   Compiling 5 files for BUILD_VM_COMPILER_NODEINFO_PROCESSOR
   Compiling 3 files for BUILD_VM_COMPILER_OPTIONS_PROCESSOR
   Compiling 14 files for BUILD_VM_COMPILER_REPLACEMENTS_PROCESSOR
   Compiling 3 files for BUILD_VM_COMPILER_SERVICEPROVIDER_PROCESSOR
   Creating buildtools/jdk.vm.compiler.match.processor.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 2 files for COMPILE_DEPEND
   Creating buildtools/jdk.vm.compiler.nodeinfo.processor.jar
   Compiling 188 files for BUILD_jdk.rmic.interim
   Creating buildtools/jdk.vm.compiler.options.processor.jar
   Creating buildtools/jdk.vm.compiler.replacements.verifier.jar
   Creating buildtools/jdk.vm.compiler.serviceprovider.processor.jar
   Compiling 31 files for BUILD_JRTFS
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Creating support/modules_libs/java.base/jrt-fs.jar
   Compiling 2 files for BUILD_BREAKITERATOR_BASE
   Compiling 2 files for BUILD_BREAKITERATOR_LD
   Compiling 11 properties into resource bundles for java.base
   Compiling 11 properties into resource bundles for java.logging
   Compiling 11 properties into resource bundles for jdk.jartool
   Compiling 11 properties into resource bundles for jdk.management.agent
   Compiling 3 properties into resource bundles for jdk.jdi
   Compiling 6 properties into resource bundles for java.base
   Compiling 4 properties into resource bundles for jdk.jlink
   Compiling 3 properties into resource bundles for jdk.jlink
   Compiling 1 properties into resource bundles for jdk.jlink
   Compiling 224 properties into resource bundles for jdk.localedata
   Compiling 3010 files for java.base
   Connection attempt failed: Connection refused (Connection refused)
   Connection attempt failed: Connection refused (Connection refused)
   Connection attempt failed: Connection refused (Connection refused)
   Giving up
   IOException caught during compilation: Could not connect to server
   CompileJavaModules.gmk:599: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/jdk/modules/java.base/_the.java.base_batch' failed
   make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/jdk/modules/java.base/_the.java.base_batch] Error 1
   make[2]: *** [java.base-java] Error 1
   make[2]: *** Waiting for unfinished jobs....
   make/Main.gmk:199: recipe for target 'java.base-java' failed
   Compiling 89 properties into resource bundles for java.desktop
   
   ERROR: Build failed for target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2) 
   
   === Output from failing command(s) repeated here ===
   * For target jdk_modules_java.base__the.java.base_batch:
   Connection attempt failed: Connection refused (Connection refused)
   Connection attempt failed: Connection refused (Connection refused)
   Connection attempt failed: Connection refused (Connection refused)
   Giving up
   IOException caught during compilation: Could not connect to server
   
   * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs.
   === End of repeated output ===
   
   === Make failed targets repeated here ===
   CompileJavaModules.gmk:599: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/jdk/modules/java.base/_the.java.base_batch' failed
   make/Main.gmk:199: recipe for target 'java.base-java' failed
   === End of repeated output ===
   
   Hint: Try searching the build log for the name of the first failed target.
   Hint: See doc/building.html#troubleshooting for assistance.
   
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:305: recipe for target 'main' failed
   make[1]: *** [main] Error 1
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed
   make: *** [images] Error 2

From ci_notify at linaro.org  Thu Mar 21 20:34:21 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Thu, 21 Mar 2019 20:34:21 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 1012 Fixed
In-Reply-To: <1835693315.4387.1553196437994.JavaMail.jenkins@a6c5c67cda76>
References: <1835693315.4387.1553196437994.JavaMail.jenkins@a6c5c67cda76>
Message-ID: <961067274.4402.1553200461957.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Fixed
Build details -  https://ci.linaro.org/job/jdkX-ci-build/1012/

Changes -
  dtitov: 7fbb4340b125bd00e8a6ad73ff895999051b3a6f 
	- test/hotspot/jtreg/vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/breakpoint001.cpp
	- test/hotspot/jtreg/vmTestbase/nsk/jvmti/FramePop/framepop002/framepop002.cpp
	- test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep003/singlestep003.cpp 
--"8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash
Reviewed-by: sspitsyn, jcbeyler
"  igerasim: 35e8d1eb4040c12e968f505fcba6e79a923b4772 
	- src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c 
--"8170494: JNI exception pending in PlainDatagramSocketImpl.c
Reviewed-by: clanger, vtewari
"

Build output -
   Creating jdk.internal.le.jmod
   Creating jdk.internal.opt.jmod
   Creating jdk.internal.vm.ci.jmod
   Creating jdk.internal.vm.compiler.jmod
   Creating jdk.internal.vm.compiler.management.jmod
   Creating jdk.jartool.jmod
   Creating jdk.javadoc.jmod
   Creating jdk.jcmd.jmod
   Creating jdk.jconsole.jmod
   Creating jdk.jdeps.jmod
   Creating jdk.jdi.jmod
   Creating jdk.jdwp.agent.jmod
   Creating jdk.jfr.jmod
   Creating jdk.jsobject.jmod
   Creating jdk.jshell.jmod
   Creating jdk.jstatd.jmod
   Creating jdk.localedata.jmod
   Creating jdk.management.agent.jmod
   Creating jdk.management.jmod
   Creating jdk.management.jfr.jmod
   Creating jdk.naming.dns.jmod
   Creating jdk.naming.rmi.jmod
   Creating jdk.net.jmod
   Creating jdk.pack.jmod
   Creating jdk.rmic.jmod
   Creating jdk.scripting.nashorn.jmod
   Creating jdk.scripting.nashorn.shell.jmod
   Creating jdk.sctp.jmod
   Creating jdk.security.auth.jmod
   Creating jdk.security.jgss.jmod
   Creating jdk.unsupported.jmod
   Creating jdk.unsupported.desktop.jmod
   Creating jdk.xml.dom.jmod
   Creating jdk.zipfs.jmod
   Creating interim jimage
   Compiling 3 files for BUILD_DEMO_CodePointIM
   Updating support/demos/image/jfc/CodePointIM/src.zip
   Compiling 3 files for BUILD_DEMO_FileChooserDemo
   Updating support/demos/image/jfc/FileChooserDemo/src.zip
   Compiling 30 files for BUILD_DEMO_SwingSet2
   Updating support/demos/image/jfc/SwingSet2/src.zip
   Compiling 4 files for BUILD_DEMO_Font2DTest
   Updating support/demos/image/jfc/Font2DTest/src.zip
   Compiling 64 files for BUILD_DEMO_J2Ddemo
   Updating support/demos/image/jfc/J2Ddemo/src.zip
   Compiling 15 files for BUILD_DEMO_Metalworks
   Updating support/demos/image/jfc/Metalworks/src.zip
   Compiling 2 files for BUILD_DEMO_Notepad
   Updating support/demos/image/jfc/Notepad/src.zip
   Compiling 5 files for BUILD_DEMO_Stylepad
   Updating support/demos/image/jfc/Stylepad/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 5 files for BUILD_DEMO_SampleTree
   Updating support/demos/image/jfc/SampleTree/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 8 files for BUILD_DEMO_TableExample
   Updating support/demos/image/jfc/TableExample/src.zip
   Compiling 1 files for BUILD_DEMO_TransparentRuler
   Updating support/demos/image/jfc/TransparentRuler/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar
   Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar
   Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar
   Creating support/demos/image/jfc/Metalworks/Metalworks.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/Notepad/Notepad.jar
   Creating support/demos/image/jfc/Stylepad/Stylepad.jar
   Creating support/demos/image/jfc/SampleTree/SampleTree.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/TableExample/TableExample.jar
   Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
   Compiling 1 files for CLASSLIST_JAR
   Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar
   Creating support/classlist.jar
   Creating jdk.jlink.jmod
   Creating java.base.jmod
   Creating jdk image
   Creating CDS archive for jdk image
   Stopping sjavac server
   Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'

From patrick at os.amperecomputing.com  Fri Mar 22 08:39:31 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Fri, 22 Mar 2019 08:39:31 +0000
Subject: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add StoreStore
 membar explicitly for Volatile Writes in TemplateTable
Message-ID: <BYAPR01MB5046BB7E30D80CE38A4C35488F430@BYAPR01MB5046.prod.exchangelabs.com>

Hi,

This is a simple patch to make the barriers (used for volatile writes in TemplateTable::fast_storefield and TemplateTable::putfield_or_static) more *self-documented* than before. See more details in JIRA please.

JBS: https://bugs.openjdk.java.net/browse/JDK-8221220
Webrev (jdk/jdk): http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00/
Webrev (aarch64-port/jdk8u-shenandoah/hotspot) http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00.jdk8u/
Tests: no impact to practical functions in theory, ran jcstress as sanity checking, no regression found.

Regards
Patrick


From patrick at os.amperecomputing.com  Fri Mar 22 08:43:07 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Fri, 22 Mar 2019 08:43:07 +0000
Subject: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add
 StoreStore membar explicitly for Volatile Writes in TemplateTable
In-Reply-To: <BYAPR01MB5046BB7E30D80CE38A4C35488F430@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB5046BB7E30D80CE38A4C35488F430@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <BYAPR01MB504607C5BC0BFB6FB2B5D58C8F430@BYAPR01MB5046.prod.exchangelabs.com>

+ hotspot-runtime-dev

Regards
Patrick

-----Original Message-----
From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On Behalf Of Patrick Zhang OS
Sent: Friday, March 22, 2019 4:40 PM
To: aarch64-port-dev at openjdk.java.net
Subject: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable

Hi,

This is a simple patch to make the barriers (used for volatile writes in TemplateTable::fast_storefield and TemplateTable::putfield_or_static) more *self-documented* than before. See more details in JIRA please.

JBS: https://bugs.openjdk.java.net/browse/JDK-8221220
Webrev (jdk/jdk): http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00/
Webrev (aarch64-port/jdk8u-shenandoah/hotspot) http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00.jdk8u/
Tests: no impact to practical functions in theory, ran jcstress as sanity checking, no regression found.

Regards
Patrick


From aph at redhat.com  Fri Mar 22 09:13:34 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 Mar 2019 09:13:34 +0000
Subject: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add
 StoreStore membar explicitly for Volatile Writes in TemplateTable
In-Reply-To: <BYAPR01MB504607C5BC0BFB6FB2B5D58C8F430@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB5046BB7E30D80CE38A4C35488F430@BYAPR01MB5046.prod.exchangelabs.com>
 <BYAPR01MB504607C5BC0BFB6FB2B5D58C8F430@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <d187cec9-6d6e-ce93-5da6-712b3b473a01@redhat.com>

On 3/22/19 8:43 AM, Patrick Zhang OS wrote:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8221220
> Webrev (jdk/jdk): http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00/
> Webrev (aarch64-port/jdk8u-shenandoah/hotspot) http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00.jdk8u/

OK.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From ci_notify at linaro.org  Fri Mar 22 21:07:39 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Fri, 22 Mar 2019 21:07:39 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 1022
	Failure
Message-ID: <954085191.4631.1553288860279.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Failure
Build details -  https://ci.linaro.org/job/jdkX-ci-build/1022/

Changes -
  kbarrett: c81fbf340cebf49f940716754a9a7945aceedb68 
	- src/hotspot/share/gc/g1/g1SharedDirtyCardQueue.cpp
	- src/hotspot/share/gc/g1/g1SharedDirtyCardQueue.hpp
	- src/hotspot/share/gc/g1/g1BarrierSet.cpp
	- src/hotspot/share/gc/g1/g1BarrierSet.hpp
	- src/hotspot/share/gc/g1/g1CollectedHeap.cpp
	- src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
	- src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
	- src/hotspot/share/gc/g1/g1RemSet.cpp
	- src/hotspot/share/gc/shared/ptrQueue.cpp
	- src/hotspot/share/gc/shared/ptrQueue.hpp
	- src/hotspot/share/gc/shared/satbMarkQueue.cpp
	- src/hotspot/share/gc/shared/satbMarkQueue.hpp 
--"8220240: Refactor shared dirty card queue
Summary: Add G1SharedDirtyCardQueue class.
Reviewed-by: tschatzl, lkorinth
"  coleenp: a2956337451b0458da6a9ff880e2721adfdb9b67 
	- test/hotspot/jtreg/ProblemList-graal.txt
	- test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestRedefineObject.java 
--"8218399: runtime/RedefineObject/TestRedefineObject.java timeout
Summary: exclude this test for graal
Reviewed-by: hseigel, lfoltan
"  xuelei: 01d8eae542ffd9f5efdf801701c468d1038a3718 
	- src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java
	- src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java
	- src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
	- src/java.base/share/classes/sun/security/ssl/ServerHello.java 
--"8218889: Improperly use of the Optional API
Reviewed-by: jnimeh, wetmore
"

Build output -
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp: In constructor ?ShenandoahSATBMarkQueue::ShenandoahSATBMarkQueue(SATBMarkQueueSet*)?:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp:34:96: error: no matching function for call to ?SATBMarkQueue::SATBMarkQueue(SATBMarkQueueSet*&, bool)?
      ShenandoahSATBMarkQueue(SATBMarkQueueSet* qset) : SATBMarkQueue(qset, /* permanent = */ false) {}
                                                                                                   ^
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp:28:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/g1/g1BarrierSet.hpp:29,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp:28,
      ... (rest of output omitted)
   * For target hotspot_variant-server_libjvm_objs_accessBackend.o:
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp:30:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp:40,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/access.inline.hpp:29,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/oop.inline.hpp:29,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/accessBackend.cpp:28:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp: In constructor ?ShenandoahSATBMarkQueue::ShenandoahSATBMarkQueue(SATBMarkQueueSet*)?:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp:34:96: error: no matching function for call to ?SATBMarkQueue::SATBMarkQueue(SATBMarkQueueSet*&, bool)?
      ShenandoahSATBMarkQueue(SATBMarkQueueSet* qset) : SATBMarkQueue(qset, /* permanent = */ false) {}
                                                                                                   ^
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp:28:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/g1/g1BarrierSet.hpp:29,
      ... (rest of output omitted)
   * For target hotspot_variant-server_libjvm_objs_accessBarrierSupport.o:
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp:30:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp:40,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/access.inline.hpp:29,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/classfile/javaClasses.inline.hpp:29,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shared/accessBarrierSupport.cpp:26:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp: In constructor ?ShenandoahSATBMarkQueue::ShenandoahSATBMarkQueue(SATBMarkQueueSet*)?:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp:34:96: error: no matching function for call to ?SATBMarkQueue::SATBMarkQueue(SATBMarkQueueSet*&, bool)?
      ShenandoahSATBMarkQueue(SATBMarkQueueSet* qset) : SATBMarkQueue(qset, /* permanent = */ false) {}
                                                                                                   ^
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp:28:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/g1/g1BarrierSet.hpp:29,
      ... (rest of output omitted)
   * For target hotspot_variant-server_libjvm_objs_accessFlags.o:
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp:30:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp:40,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/access.inline.hpp:29,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/oop.inline.hpp:29,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/utilities/accessFlags.cpp:26:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp: In constructor ?ShenandoahSATBMarkQueue::ShenandoahSATBMarkQueue(SATBMarkQueueSet*)?:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp:34:96: error: no matching function for call to ?SATBMarkQueue::SATBMarkQueue(SATBMarkQueueSet*&, bool)?
      ShenandoahSATBMarkQueue(SATBMarkQueueSet* qset) : SATBMarkQueue(qset, /* permanent = */ false) {}
                                                                                                   ^
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp:28:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/g1/g1BarrierSet.hpp:29,
      ... (rest of output omitted)
   * For target hotspot_variant-server_libjvm_objs_ad_aarch64.o:
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp:30:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp:40,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/access.inline.hpp:29,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/typeArrayOop.inline.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp:36,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/writers/jfrEventWriterHost.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/writers/jfrEventWriterHost.inline.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/writers/jfrNativeEventWriter.hpp:30,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/recorder/service/jfrEvent.hpp:32,
                    from /home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/gensrc/jfrfiles/jfrEventClasses.hpp:12,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/jfrEvents.hpp:32,
      ... (rest of output omitted)
   * For target hotspot_variant-server_libjvm_objs_ad_aarch64_clone.o:
   In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp:30:0,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp:40,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/access.inline.hpp:29,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/oops/typeArrayOop.inline.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp:36,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/writers/jfrEventWriterHost.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/writers/jfrEventWriterHost.inline.hpp:28,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/writers/jfrNativeEventWriter.hpp:30,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/recorder/service/jfrEvent.hpp:32,
                    from /home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/gensrc/jfrfiles/jfrEventClasses.hpp:12,
                    from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/jfr/jfrEvents.hpp:32,
      ... (rest of output omitted)
   
   * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs.
   === End of repeated output ===
   
   === Make failed targets repeated here ===
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/accessBackend.o' failed
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/access.o' failed
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/abstractInterpreter.o' failed
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/accessBarrierSupport.o' failed
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/accessFlags.o' failed
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/ad_aarch64_clone.o' failed
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/ad_aarch64.o' failed
   make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
   === End of repeated output ===
   
   Hint: Try searching the build log for the name of the first failed target.
   Hint: See doc/building.html#troubleshooting for assistance.
   
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:305: recipe for target 'main' failed
   make[1]: *** [main] Error 1
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed
   make: *** [images] Error 2

From ci_notify at linaro.org  Sat Mar 23 17:36:22 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Sat, 23 Mar 2019 17:36:22 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 1023 Fixed
In-Reply-To: <954085191.4631.1553288860279.JavaMail.jenkins@a6c5c67cda76>
References: <954085191.4631.1553288860279.JavaMail.jenkins@a6c5c67cda76>
Message-ID: <199794852.4814.1553362582790.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Fixed
Build details -  https://ci.linaro.org/job/jdkX-ci-build/1023/

Changes -
  shade: aa937fac07f38a91ac4938dd82b42a35c294ed21 
	- src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp 
--"8221363: Build failure after JDK-8220240 (Refactor shared dirty card queue)
Reviewed-by: stuefe
"

Build output -
   Creating jdk.internal.le.jmod
   Creating jdk.internal.opt.jmod
   Creating jdk.internal.vm.ci.jmod
   Creating jdk.internal.vm.compiler.jmod
   Creating jdk.internal.vm.compiler.management.jmod
   Creating jdk.jartool.jmod
   Creating jdk.javadoc.jmod
   Creating jdk.jcmd.jmod
   Creating jdk.jconsole.jmod
   Creating jdk.jdeps.jmod
   Creating jdk.jdi.jmod
   Creating jdk.jdwp.agent.jmod
   Creating jdk.jfr.jmod
   Creating jdk.jshell.jmod
   Creating jdk.jsobject.jmod
   Creating jdk.jstatd.jmod
   Creating jdk.localedata.jmod
   Creating jdk.management.jmod
   Creating jdk.management.agent.jmod
   Creating jdk.management.jfr.jmod
   Creating jdk.naming.dns.jmod
   Creating jdk.naming.rmi.jmod
   Creating jdk.net.jmod
   Creating jdk.pack.jmod
   Creating jdk.rmic.jmod
   Creating jdk.scripting.nashorn.shell.jmod
   Creating jdk.scripting.nashorn.jmod
   Creating jdk.security.auth.jmod
   Creating jdk.sctp.jmod
   Creating jdk.security.jgss.jmod
   Creating jdk.unsupported.jmod
   Creating jdk.unsupported.desktop.jmod
   Creating jdk.xml.dom.jmod
   Creating jdk.zipfs.jmod
   Creating interim jimage
   Compiling 3 files for BUILD_DEMO_CodePointIM
   Updating support/demos/image/jfc/CodePointIM/src.zip
   Compiling 3 files for BUILD_DEMO_FileChooserDemo
   Updating support/demos/image/jfc/FileChooserDemo/src.zip
   Compiling 30 files for BUILD_DEMO_SwingSet2
   Updating support/demos/image/jfc/SwingSet2/src.zip
   Compiling 4 files for BUILD_DEMO_Font2DTest
   Updating support/demos/image/jfc/Font2DTest/src.zip
   Compiling 64 files for BUILD_DEMO_J2Ddemo
   Updating support/demos/image/jfc/J2Ddemo/src.zip
   Compiling 15 files for BUILD_DEMO_Metalworks
   Updating support/demos/image/jfc/Metalworks/src.zip
   Compiling 2 files for BUILD_DEMO_Notepad
   Updating support/demos/image/jfc/Notepad/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 5 files for BUILD_DEMO_Stylepad
   Updating support/demos/image/jfc/Stylepad/src.zip
   Compiling 5 files for BUILD_DEMO_SampleTree
   Updating support/demos/image/jfc/SampleTree/src.zip
   Compiling 8 files for BUILD_DEMO_TableExample
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Updating support/demos/image/jfc/TableExample/src.zip
   Compiling 1 files for BUILD_DEMO_TransparentRuler
   Updating support/demos/image/jfc/TransparentRuler/src.zip
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar
   Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar
   Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar
   Creating support/demos/image/jfc/Metalworks/Metalworks.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/Notepad/Notepad.jar
   Creating support/demos/image/jfc/Stylepad/Stylepad.jar
   Compiling 1 files for CLASSLIST_JAR
   Creating support/demos/image/jfc/SampleTree/SampleTree.jar
   Creating support/demos/image/jfc/TableExample/TableExample.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
   Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar
   Creating support/classlist.jar
   Creating jdk.jlink.jmod
   Creating java.base.jmod
   Creating jdk image
   Creating CDS archive for jdk image
   Stopping sjavac server
   Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'

From Ningsheng.Jian at arm.com  Mon Mar 25 03:26:09 2019
From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China))
Date: Mon, 25 Mar 2019 03:26:09 +0000
Subject: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add
 StoreStore membar explicitly for Volatile Writes in TemplateTable
In-Reply-To: <d187cec9-6d6e-ce93-5da6-712b3b473a01@redhat.com>
References: <BYAPR01MB5046BB7E30D80CE38A4C35488F430@BYAPR01MB5046.prod.exchangelabs.com>
 <BYAPR01MB504607C5BC0BFB6FB2B5D58C8F430@BYAPR01MB5046.prod.exchangelabs.com>
 <d187cec9-6d6e-ce93-5da6-712b3b473a01@redhat.com>
Message-ID: <ca4e5311-652e-136b-6f3f-c3a3837d57c4@arm.com>

Hi Patrick,

This looks good to me. As this trivial AArch64 only patch has been 
reviewed by Andrew. I can help to push to jdk/jdk. But you need to find 
someone else to help for jdk8u-shenandoah.

Thanks,
Ningsheng

On 03/22/2019 05:13 PM, Andrew Haley wrote:
> On 3/22/19 8:43 AM, Patrick Zhang OS wrote:
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8221220
>> Webrev (jdk/jdk): http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00/
>> Webrev (aarch64-port/jdk8u-shenandoah/hotspot) http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00.jdk8u/
>
> OK.
>

From felix.yang at huawei.com  Mon Mar 25 08:17:48 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Mon, 25 Mar 2019 08:17:48 +0000
Subject: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add
 StoreStore membar explicitly for Volatile Writes in TemplateTable
In-Reply-To: <ca4e5311-652e-136b-6f3f-c3a3837d57c4@arm.com>
References: <BYAPR01MB5046BB7E30D80CE38A4C35488F430@BYAPR01MB5046.prod.exchangelabs.com>
 <BYAPR01MB504607C5BC0BFB6FB2B5D58C8F430@BYAPR01MB5046.prod.exchangelabs.com>
 <d187cec9-6d6e-ce93-5da6-712b3b473a01@redhat.com>
 <ca4e5311-652e-136b-6f3f-c3a3837d57c4@arm.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820ED5F78D96@dggeml527-mbx.china.huawei.com>

Hmm, it looks to me not qualified for a aarch64-8u backport.  Aph?


> 
> Hi Patrick,
> 
> This looks good to me. As this trivial AArch64 only patch has been
> reviewed by Andrew. I can help to push to jdk/jdk. But you need to find
> someone else to help for jdk8u-shenandoah.
> 
> Thanks,
> Ningsheng
> 
> On 03/22/2019 05:13 PM, Andrew Haley wrote:
> > On 3/22/19 8:43 AM, Patrick Zhang OS wrote:
> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8221220
> >> Webrev (jdk/jdk): http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00/
> >> Webrev (aarch64-port/jdk8u-shenandoah/hotspot)
> http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00.jdk8u/
> >
> > OK.
> >

From aph at redhat.com  Mon Mar 25 09:04:30 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 25 Mar 2019 09:04:30 +0000
Subject: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add
 StoreStore membar explicitly for Volatile Writes in TemplateTable
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820ED5F78D96@dggeml527-mbx.china.huawei.com>
References: <BYAPR01MB5046BB7E30D80CE38A4C35488F430@BYAPR01MB5046.prod.exchangelabs.com>
 <BYAPR01MB504607C5BC0BFB6FB2B5D58C8F430@BYAPR01MB5046.prod.exchangelabs.com>
 <d187cec9-6d6e-ce93-5da6-712b3b473a01@redhat.com>
 <ca4e5311-652e-136b-6f3f-c3a3837d57c4@arm.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F78D96@dggeml527-mbx.china.huawei.com>
Message-ID: <f3a40b9e-3036-f691-6d1f-5a69ddd23638@redhat.com>

On 3/25/19 8:17 AM, Yangfei (Felix) wrote:
> Hmm, it looks to me not qualified for a aarch64-8u backport.  Aph?

It's fine, if it applies cleanly.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From felix.yang at huawei.com  Mon Mar 25 09:15:22 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Mon, 25 Mar 2019 09:15:22 +0000
Subject: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add
 StoreStore membar explicitly for Volatile Writes in TemplateTable
In-Reply-To: <f3a40b9e-3036-f691-6d1f-5a69ddd23638@redhat.com>
References: <BYAPR01MB5046BB7E30D80CE38A4C35488F430@BYAPR01MB5046.prod.exchangelabs.com>
 <BYAPR01MB504607C5BC0BFB6FB2B5D58C8F430@BYAPR01MB5046.prod.exchangelabs.com>
 <d187cec9-6d6e-ce93-5da6-712b3b473a01@redhat.com>
 <ca4e5311-652e-136b-6f3f-c3a3837d57c4@arm.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F78D96@dggeml527-mbx.china.huawei.com>
 <f3a40b9e-3036-f691-6d1f-5a69ddd23638@redhat.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820ED5F79DDC@dggeml527-mbx.china.huawei.com>

OK.  Will push the aarch64 8u patch: http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00.jdk8u/


> 
> On 3/25/19 8:17 AM, Yangfei (Felix) wrote:
> > Hmm, it looks to me not qualified for a aarch64-8u backport.  Aph?
> 
> It's fine, if it applies cleanly.
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Mon Mar 25 10:01:08 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 25 Mar 2019 10:01:08 +0000
Subject: [aarch64-port-dev ] RFR(S): 8216989 -
 CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not
 check for zero length on AARCH64
In-Reply-To: <cb8775ec-bdbf-ff84-c79b-ce9b2150a8a7@bell-sw.com>
References: <2f857512-c206-a977-1c48-118f9c9d9a63@bell-sw.com>
 <ff8849a2-684c-aa98-14b3-4aae0c252744@redhat.com>
 <288f6d65-5aff-0ba1-1a1c-890700b985db@redhat.com>
 <f0f11975-0771-b331-6652-7cb3c4881e76@redhat.com>
 <cb8775ec-bdbf-ff84-c79b-ce9b2150a8a7@bell-sw.com>
Message-ID: <077381e1-34e4-8857-32e8-740bbd4df882@redhat.com>

Hi Dmitrij,

On 20/03/2019 17:29, Dmitrij Pochepko wrote:
> Please take a look at
> http://cr.openjdk.java.net/~dpochepk/8216989/webrev.02/
> I changed patch according to x86 fix and current code layout:
> 
> - renamed methods parameters from "end" to "count" to avoid confusing
> names and match x86
> - updated G1BarrierSetAssembler::gen_write_ref_array_post_barrier
> implementation: removed code with calculation of "count" value and using
> "count" directly instead
> - updated ShenandoahBarrierSetAssembler::arraycopy_epilogue in same way
> as G1 code
> - updated CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier
> with zero length branch and calculation of inclusive end pointer to
> match original logic
> - updated arraycopy_epilogue usage by removing unnecessary end pointer
> calculation and providing array length (count) instead
> 
> I also run jtreg hotspot/compiler, hotspot/gc, hotspot/runtime and jck
> with G1GC, ParallelGC and ShenandoahGC
> No regressions found.
Yes, with that change AArch64 matches the x86 code and the changes are
consistent with the JDK8 change set that Andrew identified as the reason
why AArch64 and x86 diverged. So, it's ok to push.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From felix.yang at huawei.com  Mon Mar 25 14:46:31 2019
From: felix.yang at huawei.com (felix.yang at huawei.com)
Date: Mon, 25 Mar 2019 14:46:31 +0000
Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot:
 8221220: AArch64: Add StoreStore membar explicitly for Volatile Writes in
 TemplateTable
Message-ID: <201903251446.x2PEkV0W019842@aojmv0008.oracle.com>

Changeset: 06dccf7653c0
Author:    qpzhang
Date:      2019-03-25 18:48 +0800
URL:       http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/06dccf7653c0

8221220: AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable
Reviewed-by: aph

! src/cpu/aarch64/vm/templateTable_aarch64.cpp


From dmitrij.pochepko at bell-sw.com  Mon Mar 25 16:53:33 2019
From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko)
Date: Mon, 25 Mar 2019 19:53:33 +0300
Subject: [aarch64-port-dev ] RFR(S): 8216989 -
 CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not
 check for zero length on AARCH64
In-Reply-To: <077381e1-34e4-8857-32e8-740bbd4df882@redhat.com>
References: <2f857512-c206-a977-1c48-118f9c9d9a63@bell-sw.com>
 <ff8849a2-684c-aa98-14b3-4aae0c252744@redhat.com>
 <288f6d65-5aff-0ba1-1a1c-890700b985db@redhat.com>
 <f0f11975-0771-b331-6652-7cb3c4881e76@redhat.com>
 <cb8775ec-bdbf-ff84-c79b-ce9b2150a8a7@bell-sw.com>
 <077381e1-34e4-8857-32e8-740bbd4df882@redhat.com>
Message-ID: <a7707362-9ad4-d242-8418-b01cef9ffd02@bell-sw.com>

Hi Andrew,

Thank you for review.
pushed to jdk/jdk (had to resolve 1 hunk, because of 
http://hg.openjdk.java.net/jdk/jdk/rev/f4f0dce5d0bb).

And I'm going to propose this patch for backporting into 11u and 12u 
(Final jdk/jdk patch doesn't apply cleanly for both. Separate webrevs 
and testing will be provided later).

Thanks,
Dmitrij

On 25/03/2019 1:01 PM, Andrew Dinn wrote:
> Hi Dmitrij,
>
> On 20/03/2019 17:29, Dmitrij Pochepko wrote:
>> Please take a look at
>> http://cr.openjdk.java.net/~dpochepk/8216989/webrev.02/
>> I changed patch according to x86 fix and current code layout:
>>
>> - renamed methods parameters from "end" to "count" to avoid confusing
>> names and match x86
>> - updated G1BarrierSetAssembler::gen_write_ref_array_post_barrier
>> implementation: removed code with calculation of "count" value and using
>> "count" directly instead
>> - updated ShenandoahBarrierSetAssembler::arraycopy_epilogue in same way
>> as G1 code
>> - updated CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier
>> with zero length branch and calculation of inclusive end pointer to
>> match original logic
>> - updated arraycopy_epilogue usage by removing unnecessary end pointer
>> calculation and providing array length (count) instead
>>
>> I also run jtreg hotspot/compiler, hotspot/gc, hotspot/runtime and jck
>> with G1GC, ParallelGC and ShenandoahGC
>> No regressions found.
> Yes, with that change AArch64 matches the x86 code and the changes are
> consistent with the JDK8 change set that Andrew identified as the reason
> why AArch64 and x86 diverged. So, it's ok to push.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From adinn at redhat.com  Mon Mar 25 17:16:49 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 25 Mar 2019 17:16:49 +0000
Subject: [aarch64-port-dev ] RFR(S): 8216989 -
 CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not
 check for zero length on AARCH64
In-Reply-To: <a7707362-9ad4-d242-8418-b01cef9ffd02@bell-sw.com>
References: <2f857512-c206-a977-1c48-118f9c9d9a63@bell-sw.com>
 <ff8849a2-684c-aa98-14b3-4aae0c252744@redhat.com>
 <288f6d65-5aff-0ba1-1a1c-890700b985db@redhat.com>
 <f0f11975-0771-b331-6652-7cb3c4881e76@redhat.com>
 <cb8775ec-bdbf-ff84-c79b-ce9b2150a8a7@bell-sw.com>
 <077381e1-34e4-8857-32e8-740bbd4df882@redhat.com>
 <a7707362-9ad4-d242-8418-b01cef9ffd02@bell-sw.com>
Message-ID: <fcd88bb9-7ae4-bcc3-6727-cdd39192fdf4@redhat.com>

On 25/03/2019 16:53, Dmitrij Pochepko wrote:
> Thank you for review.
> pushed to jdk/jdk (had to resolve 1 hunk, because of
> http://hg.openjdk.java.net/jdk/jdk/rev/f4f0dce5d0bb).

Thank you!

> And I'm going to propose this patch for backporting into 11u and 12u
> (Final jdk/jdk patch doesn't apply cleanly for both. Separate webrevs
> and testing will be provided later).
This conversation really needs to happen on the updates list so please
raise it there. However, since we are already talking about it:

Backporting to 11u sounds to me like a worthwhile precaution.

I'm not sure it is worth worrying about 12u. The bug does not appear to
have crashed anything yet (at least not as far as we know :-) and 12u
offers a very limited window for a problem to manifest.

I think it is more important to backport it to the jdk8u aarch64 tree
(which will probably be around for <mumble, mumble> ... some time).

However, let's defer any decision on that to those managing the updates
projects.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From patrick at os.amperecomputing.com  Tue Mar 26 02:09:59 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Tue, 26 Mar 2019 02:09:59 +0000
Subject: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add
 StoreStore membar explicitly for Volatile Writes in TemplateTable
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820ED5F79DDC@dggeml527-mbx.china.huawei.com>
References: <BYAPR01MB5046BB7E30D80CE38A4C35488F430@BYAPR01MB5046.prod.exchangelabs.com>
 <BYAPR01MB504607C5BC0BFB6FB2B5D58C8F430@BYAPR01MB5046.prod.exchangelabs.com>
 <d187cec9-6d6e-ce93-5da6-712b3b473a01@redhat.com>
 <ca4e5311-652e-136b-6f3f-c3a3837d57c4@arm.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F78D96@dggeml527-mbx.china.huawei.com>
 <f3a40b9e-3036-f691-6d1f-5a69ddd23638@redhat.com>
 <DA41BE1DDCA941489001C7FBD7A8820ED5F79DDC@dggeml527-mbx.china.huawei.com>
Message-ID: <BL0PR01MB50443520A371BFC08F9F9FEE8F5F0@BL0PR01MB5044.prod.exchangelabs.com>

Thanks to Felix, Ningsheng, and Andrew.

http://hg.openjdk.java.net/jdk/jdk/rev/0db90e99f13b 
http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/06dccf7653c0

Regards
Patrick

-----Original Message-----
From: Yangfei (Felix) <felix.yang at huawei.com> 
Sent: Monday, March 25, 2019 5:15 PM
To: Andrew Haley <aph at redhat.com>; Ningsheng Jian (Arm Technology China) <Ningsheng.Jian at arm.com>; Patrick Zhang OS <patrick at os.amperecomputing.com>; aarch64-port-dev at openjdk.java.net
Cc: hotspot-runtime-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR(trivial): 8221220 AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable

OK.  Will push the aarch64 8u patch: http://cr.openjdk.java.net/~qpzhang/8221220/webrev.00.jdk8u/


> 
> On 3/25/19 8:17 AM, Yangfei (Felix) wrote:
> > Hmm, it looks to me not qualified for a aarch64-8u backport.  Aph?
> 
> It's fine, if it applies cleanly.
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From patrick at os.amperecomputing.com  Tue Mar 26 05:12:05 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Tue, 26 Mar 2019 05:12:05 +0000
Subject: [aarch64-port-dev ] Bring AArch64 into jdk8u mainline, pros/cons?
Message-ID: <BYAPR01MB5046DDAADA104E212D82605B8F5F0@BYAPR01MB5046.prod.exchangelabs.com>

Hi Andrew and aarch64-port folks,

I am not sure whether there had been similar discussion before. It seems to me bringing aarch64 into jdk8u mainline can be a positive.
The sustaining efficiency of patches/features among jdk/jdk, jdk8u main, and aarch64-port/jdk8u-shenandoah can be improved, whilst the process could be well aligned with those of other jdk updates, i.e., 11u, 12u, etc. While we would have to take care of patches (ported to aarch64-port/jdk8u-shenandoah) more strictly, allow fewer customizations, than before, to ensure a low rate of potential side-effects to main and other ports.

Recently I personally reviewed and tested some jdk8u open source projects, derived from OpenJDK 8u mainline, it is a pity that initially aarch64 was not in (someone did the porting later on). This situation should/would be improved if so.

Regards
Patrick


From aph at redhat.com  Tue Mar 26 09:20:41 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Mar 2019 09:20:41 +0000
Subject: [aarch64-port-dev ] Bring AArch64 into jdk8u mainline,
	pros/cons?
In-Reply-To: <BYAPR01MB5046DDAADA104E212D82605B8F5F0@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB5046DDAADA104E212D82605B8F5F0@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <5157adae-572c-42f4-6082-12ff3e94c4ad@redhat.com>

Hi,

On 3/26/19 5:12 AM, Patrick Zhang OS wrote:

> I am not sure whether there had been similar discussion before. It
> seems to me bringing aarch64 into jdk8u mainline can be a positive.
> 
> The sustaining efficiency of patches/features among jdk/jdk, jdk8u
> main, and aarch64-port/jdk8u-shenandoah can be improved, whilst the
> process could be well aligned with those of other jdk updates, i.e.,
> 11u, 12u, etc. While we would have to take care of patches (ported
> to aarch64-port/jdk8u-shenandoah) more strictly, allow fewer
> customizations, than before, to ensure a low rate of potential
> side-effects to main and other ports.

Sure, it'd save some work, especially at CPU time, but it's not a huge
amount of work. It's on the list of things to consider, but not at the
top of the list.

> Recently I personally reviewed and tested some jdk8u open source
> projects, derived from OpenJDK 8u mainline, it is a pity that
> initially aarch64 was not in (someone did the porting later
> on).

"Someone" was initially Andrew Dinn and me. The patch wasn't ready at
JDK 8 time. It's not a pity, it just is.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From patrick at os.amperecomputing.com  Tue Mar 26 09:56:32 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Tue, 26 Mar 2019 09:56:32 +0000
Subject: [aarch64-port-dev ] Bring AArch64 into jdk8u mainline,
	pros/cons?
In-Reply-To: <5157adae-572c-42f4-6082-12ff3e94c4ad@redhat.com>
References: <BYAPR01MB5046DDAADA104E212D82605B8F5F0@BYAPR01MB5046.prod.exchangelabs.com>
 <5157adae-572c-42f4-6082-12ff3e94c4ad@redhat.com>
Message-ID: <BYAPR01MB5046909390AFFD339D1503D68F5F0@BYAPR01MB5046.prod.exchangelabs.com>

Hi Andrew,
Thanks for the replies.
Could I undertand this as: there was a partially done patch for merging aarch64 into jdk8u main, however we don't have a fixed timeline yet due to priroites? or do we have a rough schdule for it now?
About the jdk8u open source projects, I meant not only those in openjdk.java.net but also at external repos, e.g. github.com  

Regards
Patrick

-----Original Message-----
From: Andrew Haley <aph at redhat.com> 
Sent: Tuesday, March 26, 2019 5:21 PM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>; aarch64-port-dev at openjdk.java.net
Subject: Re: Bring AArch64 into jdk8u mainline, pros/cons?

Hi,

On 3/26/19 5:12 AM, Patrick Zhang OS wrote:

> I am not sure whether there had been similar discussion before. It 
> seems to me bringing aarch64 into jdk8u mainline can be a positive.
> 
> The sustaining efficiency of patches/features among jdk/jdk, jdk8u 
> main, and aarch64-port/jdk8u-shenandoah can be improved, whilst the 
> process could be well aligned with those of other jdk updates, i.e., 
> 11u, 12u, etc. While we would have to take care of patches (ported to 
> aarch64-port/jdk8u-shenandoah) more strictly, allow fewer 
> customizations, than before, to ensure a low rate of potential 
> side-effects to main and other ports.

Sure, it'd save some work, especially at CPU time, but it's not a huge amount of work. It's on the list of things to consider, but not at the top of the list.

> Recently I personally reviewed and tested some jdk8u open source 
> projects, derived from OpenJDK 8u mainline, it is a pity that 
> initially aarch64 was not in (someone did the porting later on).

"Someone" was initially Andrew Dinn and me. The patch wasn't ready at JDK 8 time. It's not a pity, it just is.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Tue Mar 26 10:45:18 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Mar 2019 10:45:18 +0000
Subject: [aarch64-port-dev ] Bring AArch64 into jdk8u mainline,
	pros/cons?
In-Reply-To: <BYAPR01MB5046909390AFFD339D1503D68F5F0@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB5046DDAADA104E212D82605B8F5F0@BYAPR01MB5046.prod.exchangelabs.com>
 <5157adae-572c-42f4-6082-12ff3e94c4ad@redhat.com>
 <BYAPR01MB5046909390AFFD339D1503D68F5F0@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <7ce0b729-cbb3-1bb9-caff-0d4c7bf961bc@redhat.com>

On 3/26/19 9:56 AM, Patrick Zhang OS wrote:
> Could I undertand this as: there was a partially done patch for merging aarch64 into jdk8u main, however we don't have a fixed timeline yet due to priroites?

Pretty much. We merge mainline into aarch64-port/jdk8u-shenandoah at every
release, so we know how to do it. That's not really the problem. Reviewing
it as a patch would take time and effort.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From ci_notify at linaro.org  Tue Mar 26 14:07:49 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Tue, 26 Mar 2019 14:07:49 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64
Message-ID: <1267072525.5385.1553609270251.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2019/085/summary.html
 
-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/24 pass: 792; fail: 16; error: 3
Build 1: aarch64/2019/feb/03 pass: 800; fail: 9; error: 2
Build 2: aarch64/2019/feb/14 pass: 799; fail: 9; error: 3
Build 3: aarch64/2019/feb/26 pass: 799; fail: 9; error: 3
Build 4: aarch64/2019/feb/28 pass: 803; fail: 9; error: 2
Build 5: aarch64/2019/mar/26 pass: 799; fail: 13; error: 2

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/24 pass: 5,778; fail: 236; error: 28
Build 1: aarch64/2019/feb/03 pass: 5,756; fail: 261; error: 25
Build 2: aarch64/2019/feb/14 pass: 5,761; fail: 257; error: 24
Build 3: aarch64/2019/feb/26 pass: 5,756; fail: 259; error: 27
Build 4: aarch64/2019/feb/28 pass: 5,749; fail: 268; error: 26
Build 5: aarch64/2019/mar/26 pass: 5,768; fail: 246; error: 29

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/jan/24 pass: 3,114; fail: 2
Build 1: aarch64/2019/feb/03 pass: 3,114; fail: 2
Build 2: aarch64/2019/feb/14 pass: 3,114; fail: 2
Build 3: aarch64/2019/feb/26 pass: 3,114; fail: 2
Build 4: aarch64/2019/feb/28 pass: 3,114; fail: 2
Build 5: aarch64/2019/mar/26 pass: 3,114; fail: 2

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 6.73x
Relative performance: Server critical-jOPS (nc): 8.93x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 174.26

Server 174.26 / Server 2014-04-01 (71.00): 2.45x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-02-04 pass rate: 8491/8491, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/034/results/
2019-02-14 pass rate: 8491/8491, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/045/results/
2019-02-27 pass rate: 8491/8491, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/057/results/
2019-02-28 pass rate: 8491/8491, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/059/results/
2019-03-26 pass rate: 8490/8491, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/085/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/

From ci_notify at linaro.org  Tue Mar 26 17:06:36 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Tue, 26 Mar 2019 17:06:36 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 1044
	Failure
Message-ID: <41781710.5419.1553619997061.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Failure
Build details -  https://ci.linaro.org/job/jdkX-ci-build/1044/

Changes -
  chegar: 6183f835b9b671b90f7c47302da1e90ad2552512 
	- src/java.base/share/classes/java/net/ServerSocket.java
	- src/java.base/share/classes/java/net/Socket.java
	- test/jdk/java/net/Socket/Timeouts.java 
--"8219446: Specify behaviour of timeout accepting methods of Socket and ServerSocket if timeout is negative
Reviewed-by: alanb, dfuchs
"  erikj: c12b897021ea95f2f0c5738788b93fe90aad3755 
	- make/autoconf/version-numbers
	- make/conf/jib-profiles.js 
--"8221414: Bump required boot jdk version to 12
Reviewed-by: mikael, tbell
"

Build output -
   Creating jdk.internal.opt.jmod
   Creating jdk.internal.le.jmod
   Creating jdk.internal.vm.ci.jmod
   Creating jdk.internal.vm.compiler.management.jmod
   Creating jdk.internal.vm.compiler.jmod
   Creating jdk.jartool.jmod
   Creating jdk.javadoc.jmod
   Creating jdk.jcmd.jmod
   Creating jdk.jconsole.jmod
   Creating jdk.jdeps.jmod
   Creating jdk.jdi.jmod
   Creating jdk.jdwp.agent.jmod
   Creating jdk.jfr.jmod
   Creating jdk.jshell.jmod
   Creating jdk.jsobject.jmod
   Creating jdk.jstatd.jmod
   Creating jdk.localedata.jmod
   Creating jdk.management.jmod
   Creating jdk.management.agent.jmod
   Creating jdk.management.jfr.jmod
   Creating jdk.naming.dns.jmod
   Creating jdk.naming.rmi.jmod
   Creating jdk.net.jmod
   Creating jdk.pack.jmod
   Creating jdk.rmic.jmod
   Creating jdk.scripting.nashorn.jmod
   Creating jdk.scripting.nashorn.shell.jmod
   Creating jdk.sctp.jmod
   Creating jdk.security.auth.jmod
   Creating jdk.security.jgss.jmod
   Creating jdk.unsupported.jmod
   Creating jdk.unsupported.desktop.jmod
   Creating jdk.xml.dom.jmod
   Creating jdk.zipfs.jmod
   Creating interim jimage
   Compiling 3 files for BUILD_DEMO_CodePointIM
   Updating support/demos/image/jfc/CodePointIM/src.zip
   Compiling 3 files for BUILD_DEMO_FileChooserDemo
   Updating support/demos/image/jfc/FileChooserDemo/src.zip
   Compiling 30 files for BUILD_DEMO_SwingSet2
   Updating support/demos/image/jfc/SwingSet2/src.zip
   Compiling 4 files for BUILD_DEMO_Font2DTest
   Updating support/demos/image/jfc/Font2DTest/src.zip
   Compiling 64 files for BUILD_DEMO_J2Ddemo
   Updating support/demos/image/jfc/J2Ddemo/src.zip
   Compiling 15 files for BUILD_DEMO_Metalworks
   Updating support/demos/image/jfc/Metalworks/src.zip
   Compiling 2 files for BUILD_DEMO_Notepad
   Updating support/demos/image/jfc/Notepad/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 5 files for BUILD_DEMO_Stylepad
   Updating support/demos/image/jfc/Stylepad/src.zip
   Compiling 5 files for BUILD_DEMO_SampleTree
   Updating support/demos/image/jfc/SampleTree/src.zip
   Compiling 8 files for BUILD_DEMO_TableExample
   Updating support/demos/image/jfc/TableExample/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 1 files for BUILD_DEMO_TransparentRuler
   Updating support/demos/image/jfc/TransparentRuler/src.zip
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar
   Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar
   Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar
   Creating support/demos/image/jfc/Metalworks/Metalworks.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/Notepad/Notepad.jar
   Creating support/demos/image/jfc/Stylepad/Stylepad.jar
   Creating support/demos/image/jfc/SampleTree/SampleTree.jar
   Compiling 1 files for CLASSLIST_JARCreating support/demos/image/jfc/TableExample/TableExample.jar
   
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
   Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar
   Creating support/classlist.jar
   Creating jdk.jlink.jmod
   Creating java.base.jmod
   Creating jdk image
   Creating CDS archive for jdk image
   Stopping sjavac server
   Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'

From aph at redhat.com  Tue Mar 26 18:26:03 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Mar 2019 18:26:03 +0000
Subject: [aarch64-port-dev ] 8219993: AArch64: Compiled CI stubs are
	unsafely modified
In-Reply-To: <3abc4b04-a6d4-62f7-4cd9-36a89fe020e4@redhat.com>
References: <3abc4b04-a6d4-62f7-4cd9-36a89fe020e4@redhat.com>
Message-ID: <2fa5fcb0-3bcc-f490-4948-405e23c10e40@redhat.com>

Here's a simpler patch. All I do this time is insert an ISB between the
call and the load instructions so that we don't have a stale instruction
buffer.

I also took the opportunity to unify some code which was duplicated in
C1 and compiledIC_aarch64.

Andrew Dinn, please approve this one. :-)

http://cr.openjdk.java.net/~aph/8219993.2/

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Wed Mar 27 09:39:52 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 27 Mar 2019 09:39:52 +0000
Subject: [aarch64-port-dev ] 8219993: AArch64: Compiled CI stubs are
	unsafely modified
In-Reply-To: <2fa5fcb0-3bcc-f490-4948-405e23c10e40@redhat.com>
References: <3abc4b04-a6d4-62f7-4cd9-36a89fe020e4@redhat.com>
 <2fa5fcb0-3bcc-f490-4948-405e23c10e40@redhat.com>
Message-ID: <e601b9a1-4a9b-2433-3790-63ef7ab6db75@redhat.com>

On 26/03/2019 18:26, Andrew Haley wrote:
> Here's a simpler patch. All I do this time is insert an ISB between the
> call and the load instructions so that we don't have a stale instruction
> buffer.
> 
> I also took the opportunity to unify some code which was duplicated in
> C1 and compiledIC_aarch64.
> 
> Andrew Dinn, please approve this one. :-)
> 
> http://cr.openjdk.java.net/~aph/8219993.2/
That looks ok modulo one detail I don't really understand which, I
think, applies to both old and new code.

The stub target address gets updated by NativeMovConstReg::set_data
which calls pd_patch_instruction. When that is called in some patching
thread how is it guaranteed that some other reading/executing thread
does not observe partial writes of the movz+movk+movk sequence?

I understand that the patching thread will flush the icache after
completing all 3 writes and that threads executing the stub will do an
isb to update their view of the code. What stops the icache getting
flushed in mid-write for some other reason (e.g. prefetch of
instructions in the patching thread) allowing the reader -- or indeed
another thread competing to set the stub data -- to see an invalid address?

I suppose the same question applies for the write of the constant loaded
into rscratch1.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From aph at redhat.com  Wed Mar 27 09:56:23 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 27 Mar 2019 09:56:23 +0000
Subject: [aarch64-port-dev ] 8219993: AArch64: Compiled CI stubs are
	unsafely modified
In-Reply-To: <e601b9a1-4a9b-2433-3790-63ef7ab6db75@redhat.com>
References: <3abc4b04-a6d4-62f7-4cd9-36a89fe020e4@redhat.com>
 <2fa5fcb0-3bcc-f490-4948-405e23c10e40@redhat.com>
 <e601b9a1-4a9b-2433-3790-63ef7ab6db75@redhat.com>
Message-ID: <72275f80-303c-36c6-0a96-08977f808d29@redhat.com>

On 3/27/19 9:39 AM, Andrew Dinn wrote:
> On 26/03/2019 18:26, Andrew Haley wrote:
>> Here's a simpler patch. All I do this time is insert an ISB between the
>> call and the load instructions so that we don't have a stale instruction
>> buffer.
>>
>> I also took the opportunity to unify some code which was duplicated in
>> C1 and compiledIC_aarch64.
>>
>> Andrew Dinn, please approve this one. :-)
>>
>> http://cr.openjdk.java.net/~aph/8219993.2/
> That looks ok modulo one detail I don't really understand which, I
> think, applies to both old and new code.
> 
> The stub target address gets updated by NativeMovConstReg::set_data
> which calls pd_patch_instruction. When that is called in some patching
> thread how is it guaranteed that some other reading/executing thread
> does not observe partial writes of the movz+movk+movk sequence?

It's only written once, when the c2i stub is first used. After that it
is only rewritten at a safepoint, and we assert this. It's written
synchronously by the first thread that encounters it, and there is a
lock to prevent races.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Wed Mar 27 10:04:53 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 27 Mar 2019 10:04:53 +0000
Subject: [aarch64-port-dev ] 8219993: AArch64: Compiled CI stubs are
	unsafely modified
In-Reply-To: <72275f80-303c-36c6-0a96-08977f808d29@redhat.com>
References: <3abc4b04-a6d4-62f7-4cd9-36a89fe020e4@redhat.com>
 <2fa5fcb0-3bcc-f490-4948-405e23c10e40@redhat.com>
 <e601b9a1-4a9b-2433-3790-63ef7ab6db75@redhat.com>
 <72275f80-303c-36c6-0a96-08977f808d29@redhat.com>
Message-ID: <dda98168-3500-2390-8c52-f3c93522ebdb@redhat.com>

On 27/03/2019 09:56, Andrew Haley wrote:
> On 3/27/19 9:39 AM, Andrew Dinn wrote:
>> On 26/03/2019 18:26, Andrew Haley wrote:
>>> Here's a simpler patch. All I do this time is insert an ISB between the
>>> call and the load instructions so that we don't have a stale instruction
>>> buffer.
>>>
>>> I also took the opportunity to unify some code which was duplicated in
>>> C1 and compiledIC_aarch64.
>>>
>>> Andrew Dinn, please approve this one. :-)
>>>
>>> http://cr.openjdk.java.net/~aph/8219993.2/
>> That looks ok modulo one detail I don't really understand which, I
>> think, applies to both old and new code.
>>
>> The stub target address gets updated by NativeMovConstReg::set_data
>> which calls pd_patch_instruction. When that is called in some patching
>> thread how is it guaranteed that some other reading/executing thread
>> does not observe partial writes of the movz+movk+movk sequence?
> 
> It's only written once, when the c2i stub is first used. After that it
> is only rewritten at a safepoint, and we assert this. It's written
> synchronously by the first thread that encounters it, and there is a
> lock to prevent races.
Ok, looks good then.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From dmitrij.pochepko at bell-sw.com  Wed Mar 27 13:33:17 2019
From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko)
Date: Wed, 27 Mar 2019 16:33:17 +0300
Subject: [aarch64-port-dev ] RFR: 8219654: AARCH64: Arrays:equals intrinsic
 documentation and maintenance improvement
Message-ID: <04c0ba39-ff65-ea31-6b7e-cc7132f51e32@bell-sw.com>

Hi all,

please review patch for 8219654: AARCH64: Arrays:equals intrinsic 
documentation and maintenance improvement

webrev: http://cr.openjdk.java.net/~dpochepk/8219654/webrev.01/

Changes:
- added documentation and variable renaming
- added stub prerequisites checks for debug build to guard against 
incorrect stub usage
- removed unused code block (EARLY_OUT)
- changed loop threshold constant calculation for stub code. It could be 
incorrect in several cases when non-default SoftwarePrefetchHintDistance 
value is specified
- added test to cover all code branches

Testing:

- jtreg tests: hotspot/compiler, hotspot/runtime, hotspot/gc, jdk tier1-3
- jck

no regressions found

CR: https://bugs.openjdk.java.net/browse/JDK-8219654

I'd like to thank Pengfei Li for help with prereview.

I have only one more documentation patch left to be sent (hasNegatives 
intrinsic) and would like to remind that unreviewed patch queue is 
already quite large:

https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-January/006795.html
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-February/006940.html
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-February/006956.html
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-March/007028.html
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-March/007036.html

Thanks,
Dmitrij

From dms at samersoff.net  Wed Mar 27 15:14:01 2019
From: dms at samersoff.net (Dmitry Samersoff)
Date: Wed, 27 Mar 2019 18:14:01 +0300
Subject: [aarch64-port-dev ] RFR(L) Take 2 of Valhalla support for AArch64
In-Reply-To: <d43539d1-b3c0-93d8-1f6b-071cab7c06d9@samersoff.net>
References: <d43539d1-b3c0-93d8-1f6b-071cab7c06d9@samersoff.net>
Message-ID: <a7f9376a-e3fa-133c-b227-9aec557c1eda@samersoff.net>

Hello Everybody,

Please, review the next version of the changes against lworld branch:

http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.04

*What is done:*

*  Shared interface changes are adopted.

*  24 tests of 24 from runtime/valhalla/valuetypes are passed.

*   11 of 14 tests from compiler/valhalla/valuetypes are passed with
ValueTypePassFieldsAsArgs=Off, ValueTypeReturnedAsFields=Off

*  Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields
is implemented, but not complete.


*Open points:*

1. Tests:

  compiler/valhalla/valuetypes/TestMethodHandles.java
  compiler/valhalla/valuetypes/TestBasicFunctionality.java (partially)

  Fails because the count of ALLOC doesn't match to the count expected
by the test. I'm looking into it.


2. Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields
is implemented but there are some issues

  I'll send a separate letter about it. I'll be happy if someone with
good C2 knowledge chimes in with thoughts on it

  Temporary, I forced these flags to OFF for AArch64


3. One test still fails

   compiler/valhalla/valuetypes/TestNewAcmp.java (one test within it)

   Fails with:
   Test failed: should return false


4. JNI tests doesn't run.

   Plan to address it on the next turn.


Regards,
-Dmitry



From ci_notify at linaro.org  Thu Mar 28 11:36:02 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Thu, 28 Mar 2019 11:36:02 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 1069 Fixed
Message-ID: <2006855241.5913.1553772963114.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Fixed
Build details -  https://ci.linaro.org/job/jdkX-ci-build/1069/

Changes -
  rehn: 846bc643f4ef92840e69ff6d0283d6d6f62ab0d7 
	- src/hotspot/os_cpu/aix_ppc/orderAccess_aix_ppc.hpp
	- src/hotspot/os_cpu/bsd_x86/orderAccess_bsd_x86.hpp
	- src/hotspot/os_cpu/bsd_zero/orderAccess_bsd_zero.hpp
	- src/hotspot/os_cpu/linux_aarch64/orderAccess_linux_aarch64.hpp
	- src/hotspot/os_cpu/linux_arm/orderAccess_linux_arm.hpp
	- src/hotspot/os_cpu/linux_ppc/orderAccess_linux_ppc.hpp
	- src/hotspot/os_cpu/linux_s390/orderAccess_linux_s390.hpp
	- src/hotspot/os_cpu/linux_sparc/orderAccess_linux_sparc.hpp
	- src/hotspot/os_cpu/linux_x86/orderAccess_linux_x86.hpp
	- src/hotspot/os_cpu/linux_zero/orderAccess_linux_zero.hpp
	- src/hotspot/os_cpu/solaris_sparc/orderAccess_solaris_sparc.hpp
	- src/hotspot/os_cpu/solaris_x86/orderAccess_solaris_x86.hpp
	- src/hotspot/os_cpu/windows_x86/orderAccess_windows_x86.hpp
	- src/hotspot/share/runtime/handshake.cpp
	- src/hotspot/share/runtime/interfaceSupport.inline.hpp
	- src/hotspot/share/runtime/orderAccess.hpp
	- src/hotspot/share/runtime/safepoint.cpp
	- src/hotspot/share/runtime/safepointMechanism.cpp
	- src/hotspot/share/runtime/safepointMechanism.hpp
	- src/hotspot/share/runtime/safepointMechanism.inline.hpp
	- src/hotspot/share/runtime/thread.cpp 
--"8220351: Cross-modifying code
Reviewed-by: rrich, mdoerr, dholmes, eosterlund
"

Build output -
   Creating jdk.internal.le.jmod
   Creating jdk.internal.opt.jmod
   Creating jdk.internal.vm.ci.jmod
   Creating jdk.internal.vm.compiler.jmod
   Creating jdk.internal.vm.compiler.management.jmod
   Creating jdk.jartool.jmod
   Creating jdk.javadoc.jmod
   Creating jdk.jcmd.jmod
   Creating jdk.jconsole.jmod
   Creating jdk.jdeps.jmod
   Creating jdk.jdi.jmod
   Creating jdk.jdwp.agent.jmod
   Creating jdk.jfr.jmod
   Creating jdk.jshell.jmod
   Creating jdk.jsobject.jmod
   Creating jdk.jstatd.jmod
   Creating jdk.localedata.jmod
   Creating jdk.management.jmod
   Creating jdk.management.jfr.jmod
   Creating jdk.management.agent.jmod
   Creating jdk.naming.dns.jmod
   Creating jdk.naming.rmi.jmod
   Creating jdk.net.jmod
   Creating jdk.pack.jmod
   Creating jdk.rmic.jmod
   Creating jdk.scripting.nashorn.jmod
   Creating jdk.scripting.nashorn.shell.jmod
   Creating jdk.sctp.jmod
   Creating jdk.security.auth.jmod
   Creating jdk.security.jgss.jmod
   Creating jdk.unsupported.jmod
   Creating jdk.unsupported.desktop.jmod
   Creating jdk.xml.dom.jmod
   Creating jdk.zipfs.jmod
   Creating interim jimage
   Compiling 3 files for BUILD_DEMO_CodePointIM
   Updating support/demos/image/jfc/CodePointIM/src.zip
   Compiling 3 files for BUILD_DEMO_FileChooserDemo
   Updating support/demos/image/jfc/FileChooserDemo/src.zip
   Compiling 30 files for BUILD_DEMO_SwingSet2
   Updating support/demos/image/jfc/SwingSet2/src.zip
   Compiling 4 files for BUILD_DEMO_Font2DTest
   Updating support/demos/image/jfc/Font2DTest/src.zip
   Compiling 64 files for BUILD_DEMO_J2Ddemo
   Updating support/demos/image/jfc/J2Ddemo/src.zip
   Compiling 15 files for BUILD_DEMO_Metalworks
   Updating support/demos/image/jfc/Metalworks/src.zip
   Compiling 2 files for BUILD_DEMO_Notepad
   Updating support/demos/image/jfc/Notepad/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 5 files for BUILD_DEMO_Stylepad
   Updating support/demos/image/jfc/Stylepad/src.zip
   Compiling 5 files for BUILD_DEMO_SampleTree
   Updating support/demos/image/jfc/SampleTree/src.zip
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 8 files for BUILD_DEMO_TableExample
   Updating support/demos/image/jfc/TableExample/src.zip
   Compiling 1 files for BUILD_DEMO_TransparentRuler
   Updating support/demos/image/jfc/TransparentRuler/src.zip
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar
   Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar
   Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar
   Compiling 1 files for CLASSLIST_JAR
   Creating support/demos/image/jfc/Metalworks/Metalworks.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/Notepad/Notepad.jar
   Creating support/demos/image/jfc/Stylepad/Stylepad.jar
   Creating support/demos/image/jfc/SampleTree/SampleTree.jar
   Creating support/demos/image/jfc/TableExample/TableExample.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
   Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar
   Creating support/classlist.jar
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar
   Creating jdk.jlink.jmod
   Creating java.base.jmod
   Creating jdk image
   Creating CDS archive for jdk image
   Stopping sjavac server
   Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'

From stuart.monteith at linaro.org  Thu Mar 28 11:54:21 2019
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Thu, 28 Mar 2019 11:54:21 +0000
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 1069
	Fixed
In-Reply-To: <2006855241.5913.1553772963114.JavaMail.jenkins@a6c5c67cda76>
References: <2006855241.5913.1553772963114.JavaMail.jenkins@a6c5c67cda76>
Message-ID: <CAEGA6kaCqjq905w6o=kutLdvDPUQ=m9jXniAR8tyDCP33bCP+g@mail.gmail.com>

Hi,
   This break was simply the requirement for jdk/jdk to be builds with
a JDK 12 boot-jdk.

BR,
    Stuart

On Thu, 28 Mar 2019 at 11:36, <ci_notify at linaro.org> wrote:
>
> OpenJDK AArch64 jdk/jdk build status is Fixed
> Build details -  https://ci.linaro.org/job/jdkX-ci-build/1069/
>
> Changes -
>   rehn: 846bc643f4ef92840e69ff6d0283d6d6f62ab0d7
>         - src/hotspot/os_cpu/aix_ppc/orderAccess_aix_ppc.hpp
>         - src/hotspot/os_cpu/bsd_x86/orderAccess_bsd_x86.hpp
>         - src/hotspot/os_cpu/bsd_zero/orderAccess_bsd_zero.hpp
>         - src/hotspot/os_cpu/linux_aarch64/orderAccess_linux_aarch64.hpp
>         - src/hotspot/os_cpu/linux_arm/orderAccess_linux_arm.hpp
>         - src/hotspot/os_cpu/linux_ppc/orderAccess_linux_ppc.hpp
>         - src/hotspot/os_cpu/linux_s390/orderAccess_linux_s390.hpp
>         - src/hotspot/os_cpu/linux_sparc/orderAccess_linux_sparc.hpp
>         - src/hotspot/os_cpu/linux_x86/orderAccess_linux_x86.hpp
>         - src/hotspot/os_cpu/linux_zero/orderAccess_linux_zero.hpp
>         - src/hotspot/os_cpu/solaris_sparc/orderAccess_solaris_sparc.hpp
>         - src/hotspot/os_cpu/solaris_x86/orderAccess_solaris_x86.hpp
>         - src/hotspot/os_cpu/windows_x86/orderAccess_windows_x86.hpp
>         - src/hotspot/share/runtime/handshake.cpp
>         - src/hotspot/share/runtime/interfaceSupport.inline.hpp
>         - src/hotspot/share/runtime/orderAccess.hpp
>         - src/hotspot/share/runtime/safepoint.cpp
>         - src/hotspot/share/runtime/safepointMechanism.cpp
>         - src/hotspot/share/runtime/safepointMechanism.hpp
>         - src/hotspot/share/runtime/safepointMechanism.inline.hpp
>         - src/hotspot/share/runtime/thread.cpp
> --"8220351: Cross-modifying code
> Reviewed-by: rrich, mdoerr, dholmes, eosterlund
> "
>
> Build output -
>    Creating jdk.internal.le.jmod
>    Creating jdk.internal.opt.jmod
>    Creating jdk.internal.vm.ci.jmod
>    Creating jdk.internal.vm.compiler.jmod
>    Creating jdk.internal.vm.compiler.management.jmod
>    Creating jdk.jartool.jmod
>    Creating jdk.javadoc.jmod
>    Creating jdk.jcmd.jmod
>    Creating jdk.jconsole.jmod
>    Creating jdk.jdeps.jmod
>    Creating jdk.jdi.jmod
>    Creating jdk.jdwp.agent.jmod
>    Creating jdk.jfr.jmod
>    Creating jdk.jshell.jmod
>    Creating jdk.jsobject.jmod
>    Creating jdk.jstatd.jmod
>    Creating jdk.localedata.jmod
>    Creating jdk.management.jmod
>    Creating jdk.management.jfr.jmod
>    Creating jdk.management.agent.jmod
>    Creating jdk.naming.dns.jmod
>    Creating jdk.naming.rmi.jmod
>    Creating jdk.net.jmod
>    Creating jdk.pack.jmod
>    Creating jdk.rmic.jmod
>    Creating jdk.scripting.nashorn.jmod
>    Creating jdk.scripting.nashorn.shell.jmod
>    Creating jdk.sctp.jmod
>    Creating jdk.security.auth.jmod
>    Creating jdk.security.jgss.jmod
>    Creating jdk.unsupported.jmod
>    Creating jdk.unsupported.desktop.jmod
>    Creating jdk.xml.dom.jmod
>    Creating jdk.zipfs.jmod
>    Creating interim jimage
>    Compiling 3 files for BUILD_DEMO_CodePointIM
>    Updating support/demos/image/jfc/CodePointIM/src.zip
>    Compiling 3 files for BUILD_DEMO_FileChooserDemo
>    Updating support/demos/image/jfc/FileChooserDemo/src.zip
>    Compiling 30 files for BUILD_DEMO_SwingSet2
>    Updating support/demos/image/jfc/SwingSet2/src.zip
>    Compiling 4 files for BUILD_DEMO_Font2DTest
>    Updating support/demos/image/jfc/Font2DTest/src.zip
>    Compiling 64 files for BUILD_DEMO_J2Ddemo
>    Updating support/demos/image/jfc/J2Ddemo/src.zip
>    Compiling 15 files for BUILD_DEMO_Metalworks
>    Updating support/demos/image/jfc/Metalworks/src.zip
>    Compiling 2 files for BUILD_DEMO_Notepad
>    Updating support/demos/image/jfc/Notepad/src.zip
>    Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API.
>    Note: Recompile with -Xlint:deprecation for details.
>    Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations.
>    Note: Recompile with -Xlint:unchecked for details.
>    Compiling 5 files for BUILD_DEMO_Stylepad
>    Updating support/demos/image/jfc/Stylepad/src.zip
>    Compiling 5 files for BUILD_DEMO_SampleTree
>    Updating support/demos/image/jfc/SampleTree/src.zip
>    Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations.
>    Note: Recompile with -Xlint:unchecked for details.
>    Compiling 8 files for BUILD_DEMO_TableExample
>    Updating support/demos/image/jfc/TableExample/src.zip
>    Compiling 1 files for BUILD_DEMO_TransparentRuler
>    Updating support/demos/image/jfc/TransparentRuler/src.zip
>    Note: Some input files use or override a deprecated API.
>    Note: Recompile with -Xlint:deprecation for details.
>    Note: Some input files use unchecked or unsafe operations.
>    Note: Recompile with -Xlint:unchecked for details.
>    Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations.
>    Note: Recompile with -Xlint:unchecked for details.
>    Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar
>    Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar
>    Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar
>    Compiling 1 files for CLASSLIST_JAR
>    Creating support/demos/image/jfc/Metalworks/Metalworks.jar
>    Note: Some input files use or override a deprecated API.
>    Note: Recompile with -Xlint:deprecation for details.
>    Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations.
>    Note: Recompile with -Xlint:unchecked for details.
>    Creating support/demos/image/jfc/Notepad/Notepad.jar
>    Creating support/demos/image/jfc/Stylepad/Stylepad.jar
>    Creating support/demos/image/jfc/SampleTree/SampleTree.jar
>    Creating support/demos/image/jfc/TableExample/TableExample.jar
>    Note: Some input files use or override a deprecated API.
>    Note: Recompile with -Xlint:deprecation for details.
>    Note: Some input files use unchecked or unsafe operations.
>    Note: Recompile with -Xlint:unchecked for details.
>    Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
>    Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar
>    Creating support/classlist.jar
>    Note: Some input files use or override a deprecated API.
>    Note: Recompile with -Xlint:deprecation for details.
>    Note: Some input files use unchecked or unsafe operations.
>    Note: Recompile with -Xlint:unchecked for details.
>    Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar
>    Creating jdk.jlink.jmod
>    Creating java.base.jmod
>    Creating jdk image
>    Creating CDS archive for jdk image
>    Stopping sjavac server
>    Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'

From ci_notify at linaro.org  Fri Mar 29 01:06:41 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Fri, 29 Mar 2019 01:06:41 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64
Message-ID: <362092922.6151.1553821602487.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/087/summary.html
 
-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/02 pass: 5,708; fail: 10; not run: 11,618
Build 1: aarch64/2019/feb/07 pass: 5,710; fail: 9; not run: 11,618
Build 2: aarch64/2019/feb/09 pass: 5,710; fail: 9; not run: 11,618
Build 3: aarch64/2019/feb/12 pass: 5,709; fail: 10; not run: 11,618
Build 4: aarch64/2019/feb/16 pass: 5,713; fail: 10; not run: 11,618
Build 5: aarch64/2019/feb/19 pass: 5,715; fail: 10; not run: 11,618
Build 6: aarch64/2019/feb/21 pass: 5,714; fail: 11; not run: 11,618
Build 7: aarch64/2019/feb/26 pass: 5,717; fail: 9; not run: 11,618
Build 8: aarch64/2019/mar/02 pass: 5,717; fail: 11; not run: 11,618
Build 9: aarch64/2019/mar/05 pass: 5,719; fail: 9; not run: 11,618
Build 10: aarch64/2019/mar/07 pass: 5,719; fail: 9; not run: 11,618
Build 11: aarch64/2019/mar/12 pass: 5,719; fail: 9; not run: 11,618
Build 12: aarch64/2019/mar/16 pass: 5,721; fail: 8; not run: 11,618
Build 13: aarch64/2019/mar/19 pass: 5,721; fail: 9; not run: 11,618
Build 14: aarch64/2019/mar/28 pass: 5,722; fail: 8; not run: 11,618

1 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/02 pass: 8,378; fail: 501; error: 21
Build 1: aarch64/2019/feb/07 pass: 8,364; fail: 507; error: 29
Build 2: aarch64/2019/feb/09 pass: 8,354; fail: 523; error: 23
Build 3: aarch64/2019/feb/12 pass: 8,358; fail: 519; error: 24
Build 4: aarch64/2019/feb/16 pass: 8,356; fail: 520; error: 25
Build 5: aarch64/2019/feb/19 pass: 8,375; fail: 506; error: 24
Build 6: aarch64/2019/feb/21 pass: 8,377; fail: 513; error: 22
Build 7: aarch64/2019/feb/26 pass: 8,387; fail: 501; error: 26
Build 8: aarch64/2019/mar/02 pass: 8,400; fail: 487; error: 29
Build 9: aarch64/2019/mar/05 pass: 8,413; fail: 487; error: 16
Build 10: aarch64/2019/mar/07 pass: 8,388; fail: 502; error: 26
Build 11: aarch64/2019/mar/12 pass: 8,370; fail: 520; error: 26
Build 12: aarch64/2019/mar/16 pass: 8,397; fail: 497; error: 22
Build 13: aarch64/2019/mar/19 pass: 8,365; fail: 527; error: 24
Build 14: aarch64/2019/mar/28 pass: 8,374; fail: 521; error: 21

3 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/02 pass: 3,903
Build 1: aarch64/2019/feb/07 pass: 3,903
Build 2: aarch64/2019/feb/09 pass: 3,903
Build 3: aarch64/2019/feb/12 pass: 3,903
Build 4: aarch64/2019/feb/16 pass: 3,903
Build 5: aarch64/2019/feb/19 pass: 3,903
Build 6: aarch64/2019/feb/21 pass: 3,904
Build 7: aarch64/2019/feb/26 pass: 3,904
Build 8: aarch64/2019/mar/02 pass: 3,904
Build 9: aarch64/2019/mar/05 pass: 3,904
Build 10: aarch64/2019/mar/07 pass: 3,904
Build 11: aarch64/2019/mar/12 pass: 3,904
Build 12: aarch64/2019/mar/16 pass: 3,904
Build 13: aarch64/2019/mar/19 pass: 3,904
Build 14: aarch64/2019/mar/28 pass: 3,904

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.46x
Relative performance: Server critical-jOPS (nc): 7.93x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 204.57

Server 204.57 / Server 2014-04-01 (71.00): 2.88x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-02-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/033/results/
2019-02-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/038/results/
2019-02-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/040/results/
2019-02-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/043/results/
2019-02-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/047/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/050/results/
2019-02-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/052/results/
2019-02-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/057/results/
2019-03-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/061/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/064/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/066/results/
2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/071/results/
2019-03-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/075/results/
2019-03-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/078/results/
2019-03-29 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/087/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/

From ci_notify at linaro.org  Fri Mar 29 08:12:41 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Fri, 29 Mar 2019 08:12:41 +0000 (UTC)
Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 1076
	Failure
Message-ID: <1732558144.6270.1553847161536.JavaMail.jenkins@a6c5c67cda76>

OpenJDK AArch64 jdk/jdk build status is Failure
Build details -  https://ci.linaro.org/job/jdkX-ci-build/1076/

Changes -
  stuefe: d9f6d16299b16bc5cb35772ff3d780fe1d83968f 
	- src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp
	- src/hotspot/share/classfile/classFileParser.cpp
	- src/hotspot/share/oops/markOop.hpp 
--"8221408: Windows 32bit build build errors/warnings in hotspot
Reviewed-by: kbarrett, dholmes
"

Build output -
   Building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build'
   Compiling 8 files for BUILD_TOOLS_LANGTOOLS
   Compiling 1 files for BUILD_JFR_TOOLS
   Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
   Compiling 2 files for BUILD_JVMTI_TOOLS
   Parsing 2 properties into enum-like class for jdk.compiler
   Compiling 10 properties into resource bundles for jdk.javadoc
   Compiling 19 properties into resource bundles for jdk.compiler
   Compiling 12 properties into resource bundles for jdk.jdeps
   Compiling 7 properties into resource bundles for jdk.jshell
   Compiling 117 files for BUILD_java.compiler.interim
   Creating support/modules_libs/java.base/server/libjvm.so from 921 file(s)
   Creating hotspot/variant-server/libjvm/gtest/libjvm.so from 110 file(s)
   Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s)
   Compiling 396 files for BUILD_jdk.compiler.interim
   Compiling 225 files for BUILD_jdk.javadoc.interim
   Compiling 162 files for BUILD_TOOLS_JDK
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Note: Some input files use unchecked or unsafe operations.
   Note: Recompile with -Xlint:unchecked for details.
   Compiling 2 files for COMPILE_DEPEND
   Compiling 3 files for BUILD_VM_COMPILER_MATCH_PROCESSOR
   Compiling 5 files for BUILD_VM_COMPILER_NODEINFO_PROCESSOR
   Compiling 3 files for BUILD_VM_COMPILER_OPTIONS_PROCESSOR
   Compiling 14 files for BUILD_VM_COMPILER_REPLACEMENTS_PROCESSOR
   Compiling 3 files for BUILD_VM_COMPILER_SERVICEPROVIDER_PROCESSOR
   Creating buildtools/jdk.vm.compiler.match.processor.jar
   Creating buildtools/jdk.vm.compiler.nodeinfo.processor.jar
   Creating buildtools/jdk.vm.compiler.options.processor.jar
   Creating buildtools/jdk.vm.compiler.replacements.verifier.jar
   Creating buildtools/jdk.vm.compiler.serviceprovider.processor.jar
   Compiling 11 properties into resource bundles for jdk.jartool
   Compiling 11 properties into resource bundles for jdk.management.agent
   Compiling 3 properties into resource bundles for jdk.jdi
   Compiling 4 properties into resource bundles for jdk.jlink
   Compiling 3 properties into resource bundles for jdk.jlink
   Compiling 1 properties into resource bundles for jdk.jlink
   Compiling 224 properties into resource bundles for jdk.localedata
   Compiling 188 files for BUILD_jdk.rmic.interim
   Note: Some input files use or override a deprecated API.
   Note: Recompile with -Xlint:deprecation for details.
   Compiling 31 files for BUILD_JRTFS
   Creating support/modules_libs/java.base/jrt-fs.jar
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/cpu/aarch64/aarch64.ad: In member function ?virtual void cmpFastLockNode::emit(CodeBuffer&, PhaseRegAlloc*) const?:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/cpu/aarch64/aarch64.ad:3448:85: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
        __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place));
                                                                                        ^
   Compiling 11 properties into resource bundles for java.base
   Compiling 6 properties into resource bundles for java.base
   Compiling 2 files for BUILD_BREAKITERATOR_BASE
   Compiling 2 files for BUILD_BREAKITERATOR_LD
   Compiling 11 properties into resource bundles for java.logging
   At global scope:
   cc1plus: error: unrecognized command line option ?-Wno-misleading-indentation? [-Werror]
   cc1plus: error: unrecognized command line option ?-Wno-implicit-fallthrough? [-Werror]
   cc1plus: error: unrecognized command line option ?-Wno-int-in-bool-context? [-Werror]
   cc1plus: all warnings being treated as errors
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/ad_aarch64.o' failed
   make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/ad_aarch64.o] Error 1
   make[3]: *** Waiting for unfinished jobs....
   Compiling 89 properties into resource bundles for java.desktop
   Compiling 3010 files for java.base
   make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
   make[2]: *** [hotspot-server-libs] Error 1
   make[2]: *** Waiting for unfinished jobs....
   
   ERROR: Build failed for target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2) 
   Stopping sjavac server
   
   === Output from failing command(s) repeated here ===
   * For target hotspot_variant-server_libjvm_objs_ad_aarch64.o:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/cpu/aarch64/aarch64.ad: In member function ?virtual void cmpFastLockNode::emit(CodeBuffer&, PhaseRegAlloc*) const?:
   /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/cpu/aarch64/aarch64.ad:3448:85: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
        __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place));
                                                                                        ^
   At global scope:
   cc1plus: error: unrecognized command line option ?-Wno-misleading-indentation? [-Werror]
   cc1plus: error: unrecognized command line option ?-Wno-implicit-fallthrough? [-Werror]
   cc1plus: error: unrecognized command line option ?-Wno-int-in-bool-context? [-Werror]
   cc1plus: all warnings being treated as errors
   
   * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs.
   === End of repeated output ===
   
   === Make failed targets repeated here ===
   lib/CompileJvm.gmk:175: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/ad_aarch64.o' failed
   make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
   === End of repeated output ===
   
   Hint: Try searching the build log for the name of the first failed target.
   Hint: See doc/building.html#troubleshooting for assistance.
   
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:305: recipe for target 'main' failed
   make[1]: *** [main] Error 1
   /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed
   make: *** [images] Error 2

From tobias.hartmann at oracle.com  Fri Mar 29 08:13:18 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 29 Mar 2019 09:13:18 +0100
Subject: [aarch64-port-dev ] RFR(L) Take 2 of Valhalla support for
	AArch64
In-Reply-To: <a7f9376a-e3fa-133c-b227-9aec557c1eda@samersoff.net>
References: <d43539d1-b3c0-93d8-1f6b-071cab7c06d9@samersoff.net>
 <a7f9376a-e3fa-133c-b227-9aec557c1eda@samersoff.net>
Message-ID: <1a9c9e52-7d94-e34a-23cb-69dde05d3d42@oracle.com>

Hi Dmitry,

this looks good to me but probably someone more familiar with the aarch64 architecture should have a
look as well.

Please don't completely remove the @requires os.simpleArch from the tests because we still don't
want to run them on other architectures like Sparc or ppc.

On 27.03.19 16:14, Dmitry Samersoff wrote:
> 2. Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields
> is implemented but there are some issues
> 
>   I'll send a separate letter about it. I'll be happy if someone with
> good C2 knowledge chimes in with thoughts on it

I can help with that.

Unfortunately, the implementation is quite complex and things might change depending on how we
decide to handle null-ok value types in the feature. I also have some cleanup/refactoring related to
the calling convention on my To-Do list.

> 3. One test still fails
> 
>    compiler/valhalla/valuetypes/TestNewAcmp.java (one test within it)

We also see failures in our testing that are due to the interpreter not yet implementing the
substitutability test (only C2) does.

Best regards,
Tobias

From aph at redhat.com  Fri Mar 29 17:38:59 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 29 Mar 2019 17:38:59 +0000
Subject: [aarch64-port-dev ] RFR(L) Take 2 of Valhalla support for
	AArch64
In-Reply-To: <a7f9376a-e3fa-133c-b227-9aec557c1eda@samersoff.net>
References: <d43539d1-b3c0-93d8-1f6b-071cab7c06d9@samersoff.net>
 <a7f9376a-e3fa-133c-b227-9aec557c1eda@samersoff.net>
Message-ID: <9fbdc45c-a5b0-fa02-a83a-7b7be6835a1d@redhat.com>

On 3/27/19 3:14 PM, Dmitry Samersoff wrote:
> Please, review the next version of the changes against lworld branch:
> 
> http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.04

+  ins_encode %{
+    if ($dst$$reg != $src$$reg) {
+      __ mov(as_Register($dst$$reg), as_Register($src$$reg));
+    }
+  %}

MacroAssembler::mov() doesn't generate any code if src == dst.

+        f.load_argument(1, r0); // rax,: array
+        f.load_argument(0, r1); // rbx,: index
+        int call_offset = __ call_RT(r0, noreg, CAST_FROM_FN_PTR(address, load_flattened_array), r0, r1);

rax? Are you sure about that? :-)

+void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm)  {
+// DMS CHECK: 8210498: nmethod entry barriers, should we implement it?
+#if 0

I think you should decide what to do here.


+void MacroAssembler::test_field_is_flattenable(Register flags, Register temp_reg, Label& is_flattenable) {
+  (void) temp_reg; // keep signature uniform with x86
+  tbnz(flags, ConstantPoolCacheEntry::is_flattenable_field_shift, is_flattenable);
+}
+

Rather than casting to void, you can just say

 void MacroAssembler::test_field_is_flattenable(Register flags, Register, Label& is_flattenable) {

+  // Check if we need to extend the stack for unpacking
+  int sp_inc = (args_on_stack_cc - args_on_stack) * VMRegImpl::stack_slot_size;
+  if (sp_inc > 0) {
+    // Save the return address, adjust the stack (make sure it is properly
+    // 16-byte aligned) and copy the return address to the new top of the stack.
+    // pop(r13);
+    sp_inc = align_up(sp_inc, StackAlignmentInBytes);
+    // DMS CHECK: subptr(rsp, sp_inc);
+    sub(sp, sp, sp_inc);
+    // push(r13);
+  } else {
+    // The scalarized calling convention needs less stack space than the unscalarized one.
+    // No need to extend the stack, the caller will take care of these adjustments.
+    sp_inc = 0;

Comments in here seem wrong: you're  not saving the return address.

I haven't tested any of this, but it all looks basically OK. Good work.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From ci_notify at linaro.org  Fri Mar 29 22:54:38 2019
From: ci_notify at linaro.org (ci_notify at linaro.org)
Date: Fri, 29 Mar 2019 22:54:38 +0000 (UTC)
Subject: [aarch64-port-dev ] JTREG, JCStress,
 SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
Message-ID: <2013740787.6492.1553900079300.JavaMail.jenkins@a6c5c67cda76>

This is a summary of the JTREG test results
===========================================
 
The build and test results are cycled every 15 days.
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/088/summary.html
 
-------------------------------------------------------------------------------
client-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90

-------------------------------------------------------------------------------
client-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23

-------------------------------------------------------------------------------
client-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

-------------------------------------------------------------------------------
release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/15 pass: 5,538; fail: 4; not run: 93
Build 1: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93
Build 2: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93
Build 3: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93
Build 4: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93
Build 5: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93
Build 6: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93
Build 7: aarch64/2019/mar/06 pass: 5,544; fail: 3; not run: 93
Build 8: aarch64/2019/mar/08 pass: 5,546; fail: 3; not run: 93
Build 9: aarch64/2019/mar/11 pass: 5,547; fail: 3; not run: 93
Build 10: aarch64/2019/mar/13 pass: 5,549; fail: 3; not run: 93
Build 11: aarch64/2019/mar/15 pass: 5,567; fail: 3; not run: 93
Build 12: aarch64/2019/mar/18 pass: 5,568; fail: 3; not run: 93
Build 13: aarch64/2019/mar/20 pass: 5,568; fail: 3; not run: 93
Build 14: aarch64/2019/mar/29 pass: 5,572; fail: 3; not run: 93

-------------------------------------------------------------------------------
release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16
Build 1: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20
Build 2: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17
Build 3: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23
Build 4: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20
Build 5: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20
Build 6: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20
Build 7: aarch64/2019/mar/06 pass: 8,541; fail: 506; error: 21
Build 8: aarch64/2019/mar/08 pass: 8,538; fail: 512; error: 20
Build 9: aarch64/2019/mar/11 pass: 8,531; fail: 520; error: 19
Build 10: aarch64/2019/mar/13 pass: 8,533; fail: 514; error: 22
Build 11: aarch64/2019/mar/15 pass: 8,519; fail: 513; error: 23
Build 12: aarch64/2019/mar/18 pass: 8,510; fail: 523; error: 24
Build 13: aarch64/2019/mar/20 pass: 8,513; fail: 522; error: 25
Build 14: aarch64/2019/mar/29 pass: 8,519; fail: 532; error: 22

3 fatal errors were detected; please follow the link above for more detail.

-------------------------------------------------------------------------------
release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2019/feb/15 pass: 3,995
Build 1: aarch64/2019/feb/18 pass: 3,996
Build 2: aarch64/2019/feb/20 pass: 3,996
Build 3: aarch64/2019/feb/25 pass: 3,931
Build 4: aarch64/2019/feb/27 pass: 3,931
Build 5: aarch64/2019/mar/01 pass: 3,931
Build 6: aarch64/2019/mar/04 pass: 3,931
Build 7: aarch64/2019/mar/06 pass: 3,931
Build 8: aarch64/2019/mar/08 pass: 3,931
Build 9: aarch64/2019/mar/11 pass: 3,931
Build 10: aarch64/2019/mar/13 pass: 3,931
Build 11: aarch64/2019/mar/15 pass: 3,932
Build 12: aarch64/2019/mar/18 pass: 3,932
Build 13: aarch64/2019/mar/20 pass: 3,933
Build 14: aarch64/2019/mar/29 pass: 3,935

-------------------------------------------------------------------------------
server-release/hotspot
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90

-------------------------------------------------------------------------------
server-release/jdk
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27

-------------------------------------------------------------------------------
server-release/langtools
-------------------------------------------------------------------------------
Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5

Previous results can be found here: 
 
  http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html
 

SPECjbb2015 composite regression test completed
===============================================

This test measures the relative performance of the server
compiler running the SPECjbb2015 composite tests and compares
the performance against the baseline performance of the server
compiler taken on 2016-11-21.

In accordance with [1], the SPECjbb2015 tests are run on a system
which is not production ready and does not meet all the
requirements for publishing compliant results. The numbers below
shall be treated as non-compliant (nc) and are for experimental
purposes only.

Relative performance: Server max-jOPS (nc): 7.63x
Relative performance: Server critical-jOPS (nc): 9.30x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/SPECjbb2015-results/

[1] http://www.spec.org/fairuse.html#Academic

Regression test Hadoop-Terasort completed
=========================================

This test measures the performance of the server and client compilers
running Hadoop sorting a 1GB file using Terasort and compares
the performance against the baseline performance of the Zero interpreter
and against the baseline performance of the server compiler
on 2014-04-01.

Relative performance: Zero: 1.0, Server: 207.57

Server 207.57 / Server 2014-04-01 (71.00): 2.92x

Details of the test setup and historical results may be found here:

    http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/

This is a summary of the jcstress test results
==============================================
 
The build and test results are cycled every 15 days.
 
2019-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/
2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/
2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/
2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/
2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/
2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/
2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/
2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/065/results/
2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/067/results/
2019-03-11 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/070/results/
2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/072/results/
2019-03-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/074/results/
2019-03-18 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/077/results/
2019-03-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/079/results/
2019-03-29 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/088/results/
 
For detailed information on the test output please refer to: 
 
  http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

From felix.yang at huawei.com  Sat Mar 30 00:58:53 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Sat, 30 Mar 2019 00:58:53 +0000
Subject: [aarch64-port-dev ] RFR: 8221658: aarch64: add necessary predicate
	for ubfx patterns
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820ED5F7EBCC@dggeml507-mbs.china.huawei.com>

Hi,

    Please review this patch adding necessary predicate for ubfx patterns in aarch64.ad.
    Bug: https://bugs.openjdk.java.net/browse/JDK-8221658
    Webrev: http://cr.openjdk.java.net/~fyang/8221658/webrev.00
    
    Currently, this issue is only reproduced with an aarch64 8u jdk. 
    Although it is not reproduced with aarch64 jdk11 or newer versions, it's better for them to have this fix. 
    Jtreg tested with aarch64 jdk8u & jdk13 fastdebug build.  Also passed the private fuzz test. 

Thanks,
Felix


From aph at redhat.com  Sun Mar 31 08:52:28 2019
From: aph at redhat.com (Andrew Haley)
Date: Sun, 31 Mar 2019 09:52:28 +0100
Subject: [aarch64-port-dev ] RFR: 8221658: aarch64: add necessary
 predicate for ubfx patterns
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820ED5F7EBCC@dggeml507-mbs.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED5F7EBCC@dggeml507-mbs.china.huawei.com>
Message-ID: <130fbe62-4fac-5a8d-aade-74e340459e23@redhat.com>

On 3/30/19 12:58 AM, Yangfei (Felix) wrote:
>     Please review this patch adding necessary predicate for ubfx patterns in aarch64.ad.
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8221658
>     Webrev: http://cr.openjdk.java.net/~fyang/8221658/webrev.00
>     
>     Currently, this issue is only reproduced with an aarch64 8u jdk. 
>     Although it is not reproduced with aarch64 jdk11 or newer versions, it's better for them to have this fix. 
>     Jtreg tested with aarch64 jdk8u & jdk13 fastdebug build.  Also passed the private fuzz test. 

Can't this be done by using a match operand?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From shade at redhat.com  Sun Mar 31 21:35:38 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Sun, 31 Mar 2019 23:35:38 +0200
Subject: [aarch64-port-dev ] RFR (XS) 8221725: AArch64 build failures after
 JDK-8221408 (Windows 32bit build build errors/warnings in hotspot)
Message-ID: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com>

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

Fix:

diff -r f062188117ad src/hotspot/cpu/aarch64/aarch64.ad
--- a/src/hotspot/cpu/aarch64/aarch64.ad        Sat Mar 30 21:29:37 2019 +0100
+++ b/src/hotspot/cpu/aarch64/aarch64.ad        Sun Mar 31 23:30:41 2019 +0200
@@ -3443,11 +3443,11 @@
     // Check if the owner is self by comparing the value in the
     // markOop of object (disp_hdr) with the stack pointer.
     __ mov(rscratch1, sp);
     __ sub(disp_hdr, disp_hdr, rscratch1);
-    __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place));
+    __ mov(tmp, (address) (~(os::vm_page_size()-1) | (uintptr_t)markOopDesc::lock_mask_in_place));
     // If condition is true we are cont and hence we can store 0 as the
     // displaced header in the box, which indicates that it is a recursive lock.
     __ ands(tmp/*==0?*/, disp_hdr, tmp);   // Sets flags for result

The offending change pulled some enum constants out, which apparently made enum representation much
smaller. Not sure if putting the constants back does not break Win32 build again. So, instead, fix
it up in one place that blows up with build warning-as-error. The fix has some level of ewwness, but
it seems to be the same as what bytecodeInterpreter.cpp is doing. The alternative is to cast to
uintx, as macroAssembler_arm.cpp is doing.

Testing: Linux aarch64 fastdebug build, ad-hoc tests

-- 
Thanks,
-Aleksey



From david.holmes at oracle.com  Sun Mar 31 22:18:24 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 1 Apr 2019 08:18:24 +1000
Subject: [aarch64-port-dev ] RFR (XS) 8221725: AArch64 build failures
 after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot)
In-Reply-To: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com>
References: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com>
Message-ID: <a5644971-a38d-2cef-a13b-10286cdb953b@oracle.com>

Hi Aleksey,

On 1/04/2019 7:35 am, Aleksey Shipilev wrote:
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8221725
> 
> Fix:
> 
> diff -r f062188117ad src/hotspot/cpu/aarch64/aarch64.ad
> --- a/src/hotspot/cpu/aarch64/aarch64.ad        Sat Mar 30 21:29:37 2019 +0100
> +++ b/src/hotspot/cpu/aarch64/aarch64.ad        Sun Mar 31 23:30:41 2019 +0200
> @@ -3443,11 +3443,11 @@
>       // Check if the owner is self by comparing the value in the
>       // markOop of object (disp_hdr) with the stack pointer.
>       __ mov(rscratch1, sp);
>       __ sub(disp_hdr, disp_hdr, rscratch1);
> -    __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place));
> +    __ mov(tmp, (address) (~(os::vm_page_size()-1) | (uintptr_t)markOopDesc::lock_mask_in_place));
>       // If condition is true we are cont and hence we can store 0 as the
>       // displaced header in the box, which indicates that it is a recursive lock.
>       __ ands(tmp/*==0?*/, disp_hdr, tmp);   // Sets flags for result
> 
> The offending change pulled some enum constants out, which apparently made enum representation much
> smaller. Not sure if putting the constants back does not break Win32 build again. So, instead, fix
> it up in one place that blows up with build warning-as-error. The fix has some level of ewwness, but
> it seems to be the same as what bytecodeInterpreter.cpp is doing. The alternative is to cast to
> uintx, as macroAssembler_arm.cpp is doing.

The fix seems quite reasonable (and again trivial - but I'm not an 
Aarch64 expert ...)

Thanks,
David

> Testing: Linux aarch64 fastdebug build, ad-hoc tests
> 

From ioi.lam at oracle.com  Fri Mar 29 04:32:30 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 28 Mar 2019 21:32:30 -0700
Subject: [aarch64-port-dev ] RFR(L) Take 2 of Valhalla support for
	AArch64
In-Reply-To: <a7f9376a-e3fa-133c-b227-9aec557c1eda@samersoff.net>
References: <d43539d1-b3c0-93d8-1f6b-071cab7c06d9@samersoff.net>
 <a7f9376a-e3fa-133c-b227-9aec557c1eda@samersoff.net>
Message-ID: <f7104dca-90c3-ddbd-bb9e-6d78aad0da39@oracle.com>

Hi Dmitry,

The C1 changes look OK to me. I guess they are like 80% similar to the 
x64 code. I wish we had better organization in the C1 code so we can 
avoid the duplication :-(

BTW, (you may know this already) to validate C1 changes, you can do this:

 ??????? cd test/hotspot/jtreg/compiler/valhalla/valuetypes
 ??????? jtreg -Dtest.c1=true \
 ??????????? -vmoptions:-XX:+EnableValhallaC1 \
 ??????????? -vmoptions:-XX:TieredStopAtLevel=1 \
 ??????????? -vmoptions:-XX:-ValueTypePassFieldsAsArgs \
 ??????????? -vmoptions:-XX:-ValueTypeReturnedAsFields \
 ??????????? .

Currently all the tests passed on x64 in this mode.

Thanks
- Ioi


On 3/27/19 8:14 AM, Dmitry Samersoff wrote:
> Hello Everybody,
>
> Please, review the next version of the changes against lworld branch:
>
> http://cr.openjdk.java.net/~dsamersoff/valhalla_lworld_aarch64/webrev.04
>
> *What is done:*
>
> *  Shared interface changes are adopted.
>
> *  24 tests of 24 from runtime/valhalla/valuetypes are passed.
>
> *   11 of 14 tests from compiler/valhalla/valuetypes are passed with
> ValueTypePassFieldsAsArgs=Off, ValueTypeReturnedAsFields=Off
>
> *  Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields
> is implemented, but not complete.
>
>
> *Open points:*
>
> 1. Tests:
>
>    compiler/valhalla/valuetypes/TestMethodHandles.java
>    compiler/valhalla/valuetypes/TestBasicFunctionality.java (partially)
>
>    Fails because the count of ALLOC doesn't match to the count expected
> by the test. I'm looking into it.
>
>
> 2. Support for ValueTypePassFieldsAsArgs and ValueTypeReturnedAsFields
> is implemented but there are some issues
>
>    I'll send a separate letter about it. I'll be happy if someone with
> good C2 knowledge chimes in with thoughts on it
>
>    Temporary, I forced these flags to OFF for AArch64
>
>
> 3. One test still fails
>
>     compiler/valhalla/valuetypes/TestNewAcmp.java (one test within it)
>
>     Fails with:
>     Test failed: should return false
>
>
> 4. JNI tests doesn't run.
>
>     Plan to address it on the next turn.
>
>
> Regards,
> -Dmitry
>
>