From github.com+25214855+casparcwang at openjdk.java.net  Mon Feb  1 01:31:49 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Mon, 1 Feb 2021 01:31:49 GMT
Subject: [jdk16] Integrated: 8260473: [vector] ZGC: VectorReshape test
 produces incorrect results with ZGC enabled
In-Reply-To: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
Message-ID: <EyuPoiRB0-fFBmXIxnExQ_5ewJ7L4zCo4Uuo_pfZJUQ=.22a94f6c-e703-418c-a4ff-89ee98e8425c@github.com>

On Sat, 30 Jan 2021 12:02:25 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> Testing: all Vector API related tests have passed.
> 
> Original pr: https://github.com/openjdk/jdk/pull/2253

This pull request has now been integrated.

Changeset: 0fdf9cdd
Author:    casparcwang <casparcwang at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/0fdf9cdd
Stats:     174 lines in 2 files changed: 165 ins; 0 del; 9 mod

8260473: [vector] ZGC: VectorReshape test produces incorrect results with ZGC enabled

Co-authored-by: Stuart Monteith <smonteith at openjdk.org>
Co-authored-by: Wang Chao <casparcwang at tencent.com>
Reviewed-by: vlivanov, neliasso

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

PR: https://git.openjdk.java.net/jdk16/pull/139

From github.com+25214855+casparcwang at openjdk.java.net  Mon Feb  1 01:45:46 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Mon, 1 Feb 2021 01:45:46 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <aEy95Uxy52lpFSDzmlCE9nilQ-S0G_W40FLOe-Z4THA=.16c0bb89-412c-43d6-a241-6125698d453a@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
 <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
 <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
 <aEy95Uxy52lpFSDzmlCE9nilQ-S0G_W40FLOe-Z4THA=.16c0bb89-412c-43d6-a241-6125698d453a@github.com>
Message-ID: <hq9UsmzvK-_4dgi2AkWEncvI__Rqienw-yubv0ErfUs=.ca0b61a1-cf08-4d3d-9fe4-285c4301143f@github.com>

On Fri, 29 Jan 2021 16:47:53 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> > ArrayCopyNode::load performs the same work as it does here in PhaseVector::optimize_vector_boxes .
>>> > Is there a need to provide a similar function in PhaseVector or GraphKit?
>>> 
>>> My point is since PhaseVector effectively enters the parsing phase (by signaling about the possibility of post-parse inlining), technically I don't see why `GraphKit::access_load_at` won't work. But I need to spend more time looking into the details.
>>> 
>>> So far, I took a look at the review thread of 8212243 (which introduced `ArrayCopyNode::load`) and found the following discussion between Roland and Erik:
>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030971.html
>>> 
>>> ```
>>> > ... Also it beats  me that this is strictly speaking a load barrier for loads performed in 
>>> > arraycopy. Would it be possible to use something like access_load_at  instead? ...
>>> ...
>>> GraphKit is a parse time only thing. So the existing gc interface
>>> doesn't offer any way to add barriers once parsing is over. This code
>>> runs after parsing in optimization phases.
>>> ...
>>> ```
>>> 
>>> Considering `PhaseVector::optimize_vector_boxes()` already has access to a usable `GraphKit` instance, it is possible that `GraphKit::access_load_at` will "just work".
>> 
>> As far as I can see, during the parse phase, GraphKit contains the jvm state info which can be used to get the control and memory for creating new nodes. But during optimization, the jvm state info may be missing like the situation in `PhaseVector::optimize_vector_boxes` or Macro Expansion. So it should use C2OptAccess to create the Load Node directly by providing control and memory nodes.
>> 
>> I think a similar api like `GraphKit::access_load_at ` should be provided for usage during optimization stages,  but where should the API be placed? GraphKit or PhaseIterGVN or somewhere else?
>
>> As far as I can see, during the parse phase, GraphKit contains the jvm state info which can be used to get the control and memory for creating new nodes. But during optimization, the jvm state info may be missing like the situation in PhaseVector::optimize_vector_boxes or Macro Expansion.
> 
> JVM state is irrelevant here (otherwise, `VectorUnbox` node would have captured relevant info during construction). What is actually missing is `GraphKit` instance lacks info about control and memory. You need to explicitly set it using `GraphKit::set_control()` and `GraphKit::set_all_memory()`.

Thanks @iwanowww @neliasso @pliden @stooart-mo @XiaohongGong @fisk @DamonFool for the reviews and helping.
The patch has integrated in jdk16 (https://github.com/openjdk/jdk16/pull/139), and this pr should be closed.

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

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Mon Feb  1 01:45:45 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Mon, 1 Feb 2021 01:45:45 GMT
Subject: RFR: 8260473: [vector] ZGC: VectorReshape test produces incorrect
 results with ZGC enabled [v4]
In-Reply-To: <HlJ7HD6M8hxuxNESS13iBnk8-r5MTRfVNk_oYvzckB8=.a309986a-f7bd-4ec8-a0b7-80ef136bfd01@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
 <rdtmz-1qWqPh036NjaVt6BXeVZdHuIJOFCpnVIkoI4I=.e503ab3b-5259-40f6-b056-976d0efa5ae5@github.com>
 <zBnzf7Me1OV3TVIDvrbNQrr-pxgFSeRcTASH6wNCXGs=.81d032d4-2503-47b1-8c48-651ecf35f7fa@github.com>
 <iYbXJvVqZy-ZetNKrrbPTT0jLTCrj_DEjBKPv8ckHVs=.b2263634-62a4-40a4-9ab8-248e3081dbb4@github.com>
 <Sm5e0TdFCKQztHlJGCs6Tsxc5AEpv711D_XBy_iLDs4=.940eabf1-69e9-4c67-a758-55f564f102dd@github.com>
 <j3eZ95EoTA292mgew_cghhGuaFTfJW0J5Fon27G2ibQ=.fa233153-a19e-4b28-869a-2299786178eb@github.com>
 <6nZPJh_IZbeLrS2D1lrwq7NIIry0zGQ8EzAXD6fkSrE=.4b476693-5877-434e-9e97-b26f73870e33@github.com>
 <A6jtvTa_8BpHED_dbtsQZk3gdUNAMPw2QSTtVG5Tzxo=.6ed5dbc6-a786-4753-b217-3f762917f34a@github.com>
 <HlJ7HD6M8hxuxNESS13iBnk8-r5MTRfVNk_oYvzckB8=.a309986a-f7bd-4ec8-a0b7-80ef136bfd01@github.com>
Message-ID: <Co4SRK1Hhjp8Qg-hEZo_ZQGv5sZeR6V4TvVd88945yQ=.03e86034-1179-458b-a563-488bc23ee312@github.com>

On Fri, 29 Jan 2021 16:43:54 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > I suggest you keep this CR as it is since 16 is in rampdown and we need to get approval and push it before Feb 4th (and we do want some margin).
> 
> I agree. @casparcwang, please, file an RFE.

Jie Fu @DamonFool  has helped to create an RFE. https://bugs.openjdk.java.net/browse/JDK-8260682

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

PR: https://git.openjdk.java.net/jdk/pull/2253

From github.com+25214855+casparcwang at openjdk.java.net  Mon Feb  1 01:45:46 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Mon, 1 Feb 2021 01:45:46 GMT
Subject: Withdrawn: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
References: <tCPzDoIpk5dH1cGZkE75B0l8CsNO0zygu-K25Fkocxs=.1a8412a3-181c-4eb5-8ca4-a0fd12e31f42@github.com>
Message-ID: <JiclDVhThS_B8rqrU7FrJMN3VNlrPTwbx_nF1k_8rhc=.e686f3dc-97a8-41bd-8152-f57cffb5712f@github.com>

On Wed, 27 Jan 2021 10:05:56 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8260473
> 
> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
> 
> 
> Testing: all Vector API related tests have passed.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/2253

From thartmann at openjdk.java.net  Mon Feb  1 06:35:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 06:35:42 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <B8t5ruExmEo4411CcQk_ayBlPGCGZt7d59faCYc_ZQo=.baac30f3-a5b8-4195-969b-542216a3dd75@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
 <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
 <B8t5ruExmEo4411CcQk_ayBlPGCGZt7d59faCYc_ZQo=.baac30f3-a5b8-4195-969b-542216a3dd75@github.com>
Message-ID: <GfbJMJLQxlJhO4EMbK7u2-GInPH8mNfPynbyYKMhpUw=.1f4d9a64-dc88-4b1e-92b5-13000a187b09@github.com>

On Fri, 29 Jan 2021 19:27:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove late ctrl update
>
> Good.

Thanks for the review, Vladimir!

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

PR: https://git.openjdk.java.net/jdk/pull/2315

From thartmann at openjdk.java.net  Mon Feb  1 06:36:44 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 06:36:44 GMT
Subject: RFR: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal [v3]
In-Reply-To: <6Dzr-rCwYfZsFCZGf-JhNzlDqyqtQWRziOKTtvFbqNY=.ea8aeb54-eb1c-49e8-b3ed-bfb4d3fb047f@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
 <s7UfO16vOyl_f08N2yiUwQ31eNj3l3TAAzcI1q_WXAg=.143764f1-8273-4c38-8b76-5e8bf9445c0a@github.com>
 <6Dzr-rCwYfZsFCZGf-JhNzlDqyqtQWRziOKTtvFbqNY=.ea8aeb54-eb1c-49e8-b3ed-bfb4d3fb047f@github.com>
Message-ID: <S3lalX1vl-T6Qi9Dyek_Zw_EkBh9bnPJ-GwUvcyF8dU=.5d73c9bc-9a5b-4a60-b941-c1ed8e628d2b@github.com>

On Fri, 29 Jan 2021 19:28:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Removed CICompileNatives and CICompileOSR"
>>   
>>   This reverts commit a95c358687495ee1ed701cd10d48a3a9c6a45f26.
>
> Looks good.

Thanks Vladimir!

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

PR: https://git.openjdk.java.net/jdk/pull/2281

From thartmann at openjdk.java.net  Mon Feb  1 06:36:45 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 06:36:45 GMT
Subject: Integrated: 8260577: Unused code in AbstractCompiler after Shark
 compiler removal
In-Reply-To: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
References: <CPa6az52TajrWcI_bwAFHcRRS-4srQNbc0EjakDpgHY=.33ad0d64-904d-455f-913d-51a4fd405bc3@github.com>
Message-ID: <6oglD9I7sXAsM6ZxVoAwucgjW6P1CJn5XCWWDyZBX_E=.0323b32d-a65d-4352-8e30-26523a4986b2@github.com>

On Thu, 28 Jan 2021 09:41:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After removal of the Shark compiler with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853) in JDK 10, some methods in AbstractCompiler are unused.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 039affc8
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/039affc8
Stats:     19 lines in 4 files changed: 0 ins; 16 del; 3 mod

8260577: Unused code in AbstractCompiler after Shark compiler removal

Reviewed-by: shade, chagedorn, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/2281

From eric.c.liu at arm.com  Mon Feb  1 07:21:52 2021
From: eric.c.liu at arm.com (Eric Liu)
Date: Mon, 1 Feb 2021 07:21:52 +0000
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <0f770a11-e235-d2ab-e927-8f192e80638b@redhat.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <WDQ0yZR8gbP6aLt1qOEIMsSOrwiSMdS4V8l4pi4RBmc=.b201fce0-ed3e-4319-b96b-9651bd4ecdd7@github.com>
 <KxrCbTo3Or4kTUEau7IYHc0FUkI2Sa6a8hPzk8mjLME=.00f5dd6f-ed0d-4298-80d6-baeae8b66490@github.com>
 <813ca59c-59a8-7fca-7566-0472017681ab@redhat.com>
 <0f770a11-e235-d2ab-e927-8f192e80638b@redhat.com>
Message-ID: <AM7PR08MB55265A9C3A707E7C5157A78AC5B69@AM7PR08MB5526.eurprd08.prod.outlook.com>

Hi Andrew,

Thanks for your feedback.

I refined those benchmarks and on two platforms could have a better performance. 
One can get about 100% gain, and 30% for another one. Other platforms were hard to 
see any performance changes.

Before:
  Benchmark                Mode  Cnt     Score   Error  Units
  Rotation.andRotateRight  avgt   15  3860.994 ? 3.409  ns/op
  Rotation.bicRotateRight  avgt   15  3861.247 ? 3.321  ns/op
  Rotation.eonRotateRight  avgt   15  3860.865 ? 3.003  ns/op
  Rotation.ornRotateRight  avgt   15  3860.884 ? 3.260  ns/op
  Rotation.xorRotateRight  avgt   15  3860.886 ? 2.728  ns/op

After:
  Benchmark                 Mode  Cnt     Score    Error  Units
  Rotation.andRotateRight   avgt   15  1933.495 ? 0.263  ns/op
  Rotation.bicRotateRight   avgt   15  1933.436 ? 0.244  ns/op
  Rotation.eonRotateRight   avgt   15  1933.459 ? 0.255  ns/op
  Rotation.ornRotateRight   avgt   15  1933.559 ? 0.316  ns/op
  Rotation.xorRotateRight   avgt   15  1933.467 ? 0.245  ns/op

I would update my patch with the benchmark tests after finishing the whole tests.

--Eric

-----Original Message-----
From: hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Andrew Haley
Sent: Saturday, January 30, 2021 12:30 AM
To: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR: 8256438: AArch64: Implement match rules with ROR shift register value

On 29/01/2021 10:11, Andrew Haley wrote:
> On 1/29/21 8:35 AM, Eric Liu wrote:
>> I benchmarked on 7 platforms with jmh test[1], most of them were hard to see any performance changes. On one platform the performance become bad, and seems a little unstable.

Your benchmark did not work for me. It did not generate the correct instructions.

Please try with this or similar:

    @Benchmark
    public void xorRotateRight(MyState s, Blackhole blackhole) {
        int x = s.xi;
        int y = s.yi;
        for (int i = 0; i < COUNT; i++) {
            y = x ^ ((y >>> 5) | (y << -5));
            x = y ^ ((x >>> 5) | (x << -5));
        }
        blackhole.consume(x);
    }

I get:

Benchmark                             Mode  Cnt     Score    Error  Units
Rotation.xorRotateRight   (before)    avgt    3  6142.575 ? 15.940  ns/op
Rotation.xorRotateRight   (after)     avgt    3  4081.587 ? 33.904  ns/op

Please integrate the corrected benchmark into your patch.

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


From njian at openjdk.java.net  Mon Feb  1 07:51:45 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 1 Feb 2021 07:51:45 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <HvyAy7ZfnJLdl7NkO98VwCOX9Ju4zQiJZ7AV2lNznmQ=.20283243-c16f-4e56-8153-72702a818495@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <HvyAy7ZfnJLdl7NkO98VwCOX9Ju4zQiJZ7AV2lNznmQ=.20283243-c16f-4e56-8153-72702a818495@github.com>
Message-ID: <DkxP64SKhG9uHwYwxLgC-xwmtfpDoqpaHSPMGw1Kz6w=.63f9c3d2-22c2-435c-8b95-e0171166854b@github.com>

On Sun, 31 Jan 2021 10:30:06 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> This is a typo introduced by JDK-8255949.
>> Compiler will generate `ushr` for shifting right and accumulating four short integers.
>> It produces wrong results for specific case. The instruction should be `usra`.
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make empty ins_encode when shift >= 16 (chars)

Looks good to me.

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

Marked as reviewed by njian (Committer).

PR: https://git.openjdk.java.net/jdk16/pull/136

From thartmann at openjdk.java.net  Mon Feb  1 07:58:40 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 07:58:40 GMT
Subject: RFR: 8259398: Super word not applied to a loop with
 byteArrayViewVarHandle
In-Reply-To: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
References: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
Message-ID: <6BX-WlBPwAXUI8a94MD_Rj0i1ldtyUnDu64SCoW4pfU=.2d96a7c6-00bf-45df-91c4-19b19e7bba97@github.com>

On Fri, 29 Jan 2021 17:40:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Address expressing in this case has CastII which is not range check related.
> I think it is safe to skip any CastII nodes (similar to ConvI2L nodes) when parsing address for vectors - vectors will be constructed only if the same loop's variable and invariant are used for all memory operations regardless casts. Also vectors address depends on loop's variable so they will not be moved outside loop.
> In 32-bit VM there is no ConvI2L nodes so I moved CastII checks from under ConvI2L check.
> 
> New regression case added to TestBufferVectorization.java test.
> 
> Testing hs-tier1-7, RenaissanceStressTest. Run all vectorizing tests locally to make sure no regression.

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2317

From dongbo4 at huawei.com  Mon Feb  1 08:11:35 2021
From: dongbo4 at huawei.com (dongbo (E))
Date: Mon, 1 Feb 2021 16:11:35 +0800
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <6a306bd0-19a9-f8d2-a285-1239371f389e@redhat.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
 <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
 <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>
 <AQEAN6KcNC9S4AHg2Voyu9SsUlNXDh5ThUDOailTFMA=.3b9c1a70-7436-4306-bc6d-a5e3d91f9166@github.com>
 <OrMeQJItXcusPEf031k8wbL5j74RbyynGSQ3HM-1S0E=.9d440961-d955-4935-9dd8-8621052d1a35@github.com>
 <6a306bd0-19a9-f8d2-a285-1239371f389e@redhat.com>
Message-ID: <c922d3ba-40f1-447c-5cd4-daf1226719da@huawei.com>


On 2021/1/31 19:49, Andrew Haley wrote:
> On 1/31/21 10:34 AM, Dong Bo wrote:
>> This was wrong, both src and dst should have the same value as before.
>> Actually, when the shift is `>= 16`, the URShift is optimized to zero by the compiler.
>> So we don't have a `vsrla4S_imm` match if `shift >= 16`, the wrong `eor` is not generated.
>> Check the assembly code of the following test:
>> # test
>> public void shiftURightAccumulateChar() {
>>        for (int i = 0; i < count; i++) {
>>             charsD[i] = (char) (charsA[i] + (charsB[i] >>> 16));
>>        }
>> }
> We need to make sure this is in a regression test. Also, please make
> sure that a shift if e.g. 35 works correctly.

Hi,


Added regresstion tests for serveral shift counts.
The tests passed with the newest version and still can catch the typo.
Also tested a few of injected errors, the tests failed as expected.


From dongbo at openjdk.java.net  Mon Feb  1 08:12:58 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 1 Feb 2021 08:12:58 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v4]
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <eEPktjWXn54U-2XHYwZSAiJ5c2i5Nam-LAFQMG2EvIE=.e5bd6172-f254-4bea-b63f-969c51a4a232@github.com>

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

Dong Bo has updated the pull request incrementally with two additional commits since the last revision:

 - fix trailing whitespace
 - add tests for shifting counts

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/136/files
  - new: https://git.openjdk.java.net/jdk16/pull/136/files/b7ef8fb8..f2e490a3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=02-03

  Stats: 286 lines in 1 file changed: 245 ins; 6 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/136/head:pull/136

PR: https://git.openjdk.java.net/jdk16/pull/136

From roland at openjdk.java.net  Mon Feb  1 08:18:41 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 1 Feb 2021 08:18:41 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
 <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
Message-ID: <eRMcQwt6vY0CMJR_QOFserPiT0Cj1ZuPUxlrb7Mpf0g=.cdad2a77-dc24-48ed-b420-64480b41beb3@github.com>

On Fri, 29 Jan 2021 14:59:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Loop strip mining verification fails because a `LoadNode` with no safepoint use ends up in the `OuterStripMinedLoop`. The root cause is very similar to [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): A `LoadNode` with two uses (a field store and a return, see `test2`) is cloned by `PhaseIdealLoop::split_if_with_blocks_post()` for each use, to allow it to flow out of the loop. Both clones end up in the `OuterStripMinedLoop`, the clone for the field store because the store has a safepoint use and the clone for the return because `late_load_ctrl` is too conservative by taking all initial uses into account.
>> 
>> Now the load without a safepoint use is always detected by loop strip mining verification but without verification (for example, in a product build), we still hit several different issues depending on the exact use of the load (compare `test2/3/4`). The main issue is that loads without a safepoint use are not correctly wired when creating pre/main/post loops. Christian described this well in his RFR for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039638.html
>> 
>> Therefore, relaxing loop strip mining verification is not an option.
>> 
>> The problem with the fix for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607) is that it relies on IGVN being executed before pre/main/post loops are created, merging the two clones such that the remaining one has a safepoint use and is therefore correctly handled. However, this is not guaranteed. In fact, if `major_progress` is not set, pre/main/post loops could be created in the same round of loop opts without IGVN in-between (`IdealLoopTree::iteration_split` is executed right after `PhaseIdealLoop::split_if_with_blocks`).
>> 
>> I think we have the following options:
>> 1) Bail out if the loop is strip mined. I think that would be too conservative.
>> 
>> 2) Simply set `major_progress` when pinning a `LoadNode` to the `OuterStripMinedLoop` to make sure IGVN is executed and duplicate `LoadNodes` are merged. That seems quite invasive though.
>> 
>> 3) Allow the cloned load without a safepoint use (and therefore no usages in the `OuterStripMinedLoop`) to completely flow out of the loop. Currently, this is blocked by `late_load_ctrl` being computed on the initial `LoadNode` instead of the clone and therefore also taking into account the store that is referenced by the safepoint. We could simply re-compute the late ctrl for the cloned load, allowing it to flow out of the `OuterStripMinedLoop`. However, that only works if there is no anti-dependency in the `OuterStripMinedLoop`.
>> 
>> 4) Detect duplicate loads in the `OuterStripMinedLoop` on creation in `PhaseIdealLoop::split_if_with_blocks` and merge them right away.
>> 
>> I've decided to go with 4) and also reverted the fix for JDK-8249607 which is no longer required.
>> 
>> As Roland and Christian already noticed, there are various other issues with that code that hopefully will be addressed at some point by [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove late ctrl update

Changes requested by roland (Reviewer).

src/hotspot/share/opto/loopopts.cpp line 1516:

> 1514:             // address expression) and the AddP and StoreP have
> 1515:             // different controls.
> 1516:             if (!x->is_Load() && !x->is_DecodeNarrowPtr()) {

why this change?

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

PR: https://git.openjdk.java.net/jdk/pull/2315

From ogatak at openjdk.java.net  Mon Feb  1 08:28:06 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Mon, 1 Feb 2021 08:28:06 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v3]
In-Reply-To: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
Message-ID: <owXqOZWxdbUC-J5GxERy4zjPk5Ifb1xCsslCBqfxL_Y=.08191ff0-a579-4267-b033-2bf3e5de6752@github.com>

> The POWER10 processor, which implements Power ISA 3.1 [1], supports new instruction formats where an instruction takes two 32bit words.  The first word is called prefix, and the instructions with prefix are called prefixed instructions.  With more bits in opcode and operand fields, POWER10 supports larger immediate value in an operand, as well as many new instructions.
> 
> This is the first changes to handle prefixed instructions, and this adds support of prefixed addi (= paddi) instruction as an example of prefix usage.  paddi accepts 34bit immediate value, while original addi accepts 16bit value.
> 
> [1] https://ibm.ent.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0

Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:

  Update (2nd round) based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2095/files
  - new: https://git.openjdk.java.net/jdk/pull/2095/files/9a7ef64e..a8770539

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2095&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2095&range=01-02

  Stats: 32 lines in 3 files changed: 6 ins; 23 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2095.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2095/head:pull/2095

PR: https://git.openjdk.java.net/jdk/pull/2095

From ogatak at openjdk.java.net  Mon Feb  1 08:32:40 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Mon, 1 Feb 2021 08:32:40 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v3]
In-Reply-To: <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
Message-ID: <i2ZikVAwlOB8EOkGttyNExAyYwxgetKUHMNrKYQx48o=.ff0156d4-fd15-43cd-980f-854b7558b137@github.com>

On Thu, 21 Jan 2021 01:53:02 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update (2nd round) based on review comments
>
> This looks good overall.  I'm looking forward to being able to utilize this capability.

@CoreyAshford Thank you for your comment.  Regarding the unused code, I agree that unused code won't be tested enough, so I removed paddi_or_addi(), pli_or_li(), and is_pli().

For the comment on predicate in loadConI32 and loadConL34, I couldn't find the reason why it caused build error.  So I added comments describing they are only for Power 10 and up but can't add predicate.  I also added comments in is_paddi() as you suggested.

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

PR: https://git.openjdk.java.net/jdk/pull/2095

From redestad at openjdk.java.net  Mon Feb  1 08:32:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 1 Feb 2021 08:32:57 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v3]
In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
Message-ID: <TqzJ_xlqeIkJzmB2a66wWt3NAYYk369U0fWvQhV-yCE=.e9bca0bb-a805-4277-bee7-10ab940b0fa5@github.com>

> - Remove unused code
> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
> - Apply pattern matching to make some code more readable

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  More cleanup, reduce allocations in InvokerBytecodeGenerator

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2300/files
  - new: https://git.openjdk.java.net/jdk/pull/2300/files/68d3475a..aa88b6fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=01-02

  Stats: 45 lines in 1 file changed: 19 ins; 6 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300

PR: https://git.openjdk.java.net/jdk/pull/2300

From rcastanedalo at openjdk.java.net  Mon Feb  1 08:38:55 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 1 Feb 2021 08:38:55 GMT
Subject: RFR: 8260581: IGV: enhance node search [v3]
In-Reply-To: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
Message-ID: <99IPHcis01UPgM4dVdz0VQ9zhVBAwuOJOUl9APAhjOQ=.4746a6b2-95ab-4605-b567-d45354ba48bb@github.com>

> Apply several enhancements to the quick node search functionality: 
> 
> - Allow users to search by node id or name by default (i.e. when no property is specified) instead of name only.
> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>     1. **5** AddI
>     2. **5**54 MulI
>     3. 2**5** AddL
>     4. 2**5**3 AddL
> 
> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
> 
> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
> 
> and after:
> 
> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
> 
> 
> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
> 
> As part of the review, please evaluate not just the code changes but also the usability.

Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:

  Use Integer.compare()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2285/files
  - new: https://git.openjdk.java.net/jdk/pull/2285/files/73d0ed02..537d023b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2285&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2285&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2285/head:pull/2285

PR: https://git.openjdk.java.net/jdk/pull/2285

From rcastanedalo at openjdk.java.net  Mon Feb  1 08:38:56 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 1 Feb 2021 08:38:56 GMT
Subject: RFR: 8260581: IGV: enhance node search [v2]
In-Reply-To: <Bi-IBOh27-CpVV2BhAnfs7tRDTaVRIlPwfEBsf28-yo=.2852a85a-970d-4426-a6fe-75db4cde79e8@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <1OvXkUZq1-wp42Ik4uO1Po77am92EVM99S9JWB4mf4I=.32748364-a89f-4002-b7a7-378ca2623422@github.com>
 <Bi-IBOh27-CpVV2BhAnfs7tRDTaVRIlPwfEBsf28-yo=.2852a85a-970d-4426-a6fe-75db4cde79e8@github.com>
Message-ID: <HJtXE7McFDxS0TLleiFZJjmzxCsHCSBkjwk_4j1TfOc=.98d61c32-d49f-49aa-a1cf-cf19c2e218db@github.com>

On Fri, 29 Jan 2021 15:11:40 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug print
>
> src/utils/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/NodeQuickSearch.java line 140:
> 
>> 138:                                  (InputNode a, InputNode b) ->
>> 139:                                  Integer.valueOf(rankMatch(rawValue, a.getProperties().get(name)))
>> 140:                                  .compareTo(rankMatch(rawValue, b.getProperties().get(name))));
> 
> You can use `Integer.compare()` which directly takes two `ints` instead of `compareTo()`.

Thanks, done!

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

PR: https://git.openjdk.java.net/jdk/pull/2285

From rcastanedalo at openjdk.java.net  Mon Feb  1 08:41:43 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 1 Feb 2021 08:41:43 GMT
Subject: RFR: 8260581: IGV: enhance node search [v2]
In-Reply-To: <XLrxv_fFDXIdNYi_35tIT5UhbbIayuY9mYDPVfGjOvU=.3066e6fc-b523-4368-8e09-2977c5b90c34@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <1OvXkUZq1-wp42Ik4uO1Po77am92EVM99S9JWB4mf4I=.32748364-a89f-4002-b7a7-378ca2623422@github.com>
 <XLrxv_fFDXIdNYi_35tIT5UhbbIayuY9mYDPVfGjOvU=.3066e6fc-b523-4368-8e09-2977c5b90c34@github.com>
Message-ID: <j9fFNv8eRd8KYYQysJBUMT66mOr4-8XCQnpTdd9xxU0=.7097eb05-7d44-4fe8-a11c-826e2d343ebc@github.com>

On Fri, 29 Jan 2021 15:36:11 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug print
>
> Awesome! Finally!

Thanks Christian and Vladimir for reviewing! I will wait a couple more days in case anyone else has comments.

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

PR: https://git.openjdk.java.net/jdk/pull/2285

From jrose at openjdk.java.net  Mon Feb  1 08:57:43 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 1 Feb 2021 08:57:43 GMT
Subject: RFR: 8259609: C2: optimize long range checks in long counted
 loops [v3]
In-Reply-To: <PCbmTFPyAeI7nSOM_CTrLz_6CoL9S42R0G_qxHqhSiQ=.e8f8017a-824a-4e5f-8129-ab118e1cbaa1@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
 <iFQyPXcZCNA6TDoZUxHgLNy1t3pBuqcrONWmLkZnuw4=.c4cc12d2-a337-49d2-99ee-f567fd2295b2@github.com>
 <r3bRcbUoILjstUn96_s76Sk7aUa8KtOcG5NqS2oUPQc=.bc2edfa0-d3e3-4015-9441-02fb72e024c4@github.com>
 <PCbmTFPyAeI7nSOM_CTrLz_6CoL9S42R0G_qxHqhSiQ=.e8f8017a-824a-4e5f-8129-ab118e1cbaa1@github.com>
Message-ID: <mjoTcANLPO4gYYyjuXPIVt-43RlfaymLMr6sUTieSRY=.c8d4295f-84ee-4432-aed0-fe5d73d24803@github.com>

On Wed, 27 Jan 2021 08:32:42 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I did a first pass over the changes and added some comments but I need more time to review.
>
> @TobiHartmann thanks for the comments. I pushed a change that should address them.

Partial review:
Yes, good cleanups along with great new functionality for big data!  I
like the refactorings which use the new generic factory methods from
JDK-8255150.

The comment in `PhaseIdealLoop::transform_long_range_checks` is very
good.

PhaseTransform::integercon has a bug left over from JDK-8256655,
the cast in `assert(((long)int_con) == l, "not an int")` is wrong.
Just use `intcon(checked_cast<jint>(l))` as you already do elsewhere.

(I also noticed also that `PhaseIdealLoop::exact_limit` and
`LoopLimitNode::value` have similar asserts which could be replaced
with `checked_cast`.  In fact, `PhaseIdealLoop::exact_limit` is a
duplicated from `LoopLimitNode::value` just to avoid creating a node,
yuck.  That fiddly stuff should have been written as few times as
possible.  I suggest putting it into a static inline in the class
`LoopLimitNode`, where it will also serve as documentation.)

typo:  /had a change to be hoisted yet/s/change/chance/

Also there are unusually long comment lines there and inside
`transform_long_range_checks`. 130 columns plus is longer than my
widest laptop window holds unless I aggravate my presbyopia with
a smaller font size.  Maybe, consider reflowing?  I know some
of those lines are intrinsically long.

This variable is unused:  `Node* long_stride = head->stride();`

The argument `signed_int` is unused in `MulNode::operates_on`.

Well done adapting `is_scaled_iv` and friends to T_LONG!

The logic for turning a shift amount into a scale factor looks
flawed, at least if `shift_amount` is ever out of range for the
corresponding basic type.  I suggest being safe rather than
sorry:   `shift_amount &= (bt == T_INT ? 31 : 63);  //clip`
(There are about 3 possible bugs with out-of-range shifts.)
Even better:  Use both overloadings of `java_shift_left`
from `globalDefinitions.hpp`; I think that would be the
best practice.

> I realize
  there's some code duplication but I didn't see a way to share logic
  between IdealLoopTree::may_have_range_check()
  IdealLoopTree::policy_range_check() that would feel right.

I did a direct `diff -w` of the two function bodies and they are
so similar that I think it is better to maintain them as one copy
of the code.  I suggest adding a boolean flag `provisional`
that activates the changed bits of logic:

bool IdealLoopTree::policy_range_check(PhaseIdealLoop *phase, bool provisional = false) const {
+ if (_head->is_CountedLoop()) {
    CountedLoopNode *cl = _head->as_CountedLoop();
    ...existing stuff about unroll_only etc...
+ }
+ BaseCountedLoopNode *cl = _head->as_BaseCountedLoop();
  Node *trip_counter = cl->phi();
+ BasicType bt = cl->bt();
  for (...) {
      ...
      Node *cmp = bol->in(1);
      Node *rc_exp = cmp->in(1);
      Node *limit = cmp->in(2);
+     if (provisional) {
+       // Try to pattern match with either cmp inputs, do not check whether one of the
+       // inputs is loop independent as it may not have had a chance to be hoisted yet.
+       if (!phase->is_scaled_iv_plus_offset(rc_exp, trip_counter, NULL, NULL, bt) &&
+           !phase->is_scaled_iv_plus_offset(limit,  trip_counter, NULL, NULL, bt)) {
        continue;
+     } else {  // check loop independence if non-provisional
         Node *limit_c = phase->get_ctrl(limit);
         ...existing checks & swap of rc_exp and limit...
         if (!phase->is_scaled_iv_plus_offset(rc_exp, trip_counter, NULL, NULL)) {
           continue;
         }
+     }
      if (is_loop_exit(iff)) {
        // Found valid reason to split iterations (if there is room).
        // NOTE: Usually a gross overestimate.
        return provisional || phase->may_require_nodes(est_loop_clone_sz(2));
      }
  }
}

Now for the biggest part:  You are replacing long range checks with
32-bit range checks which then can be RCE-ed.  You dial back the
strip-mining count as needed to make sure the various scaled index
computations don't suffer overflow.  Very clever!

I suggest placing `extract_long_range_checks` before
`transform_long_range_checks` because that's the order they are
executed.  That way the two can be read more easily in sequence.

The variable `jlong stride_con` should be `int`.  It is never used
for anything bigger, or else an assert would fire.

IMO the expression `scale > 0 != stride_con > 0` needs parens around
each of the two comparisons.  This is a case of relying on obscure
C language precedence rules.  (I had to look it up myself!)

This group of definitions is loop-invariant, and should probably
be set up once outside of the for-loop:

// Compute lower and upper
Node* last = new LoopLimitNode(C, int_zero, inner_iters_actual_int, int_stride);
register_new_node(last, entry_control);
last = new SubINode(last, int_stride);
register_new_node(last, entry_control);

Node* lower = outer_phi;
Node* upper = new ConvI2LNode(last);
register_new_node(upper, entry_control);
upper = new AddLNode(lower, upper);
register_new_node(upper, entry_control);

In `new AddLNode(upper, long_one)`, I think `long_one` should
have the same sign as the stride.  But I'm not sure (yet).

You have an expression for accumulating the maximum scale:
`max_scale = MAX2(max_scale, scale)`.  I think that the
accumulated value should not be negative, so you probably
want `max_scale = MAX2(max_scale, ABS(scale))`.

But, I suggest getting rid of `max_scale` altogether.
The logic will be simpler if it works like this:

jlong original_iters_limit = iters_limit;
jlong reduced_iters_limit = iters_limit;
for (...) {
  ... jlong new_limit = original_iters_limit / ABS(scale * stride_con)
  if (new_limit >= min_iters) { // ??? or > ???
    reduced_iters_limit = MIN2(reduced_iters_limit, new_limit);
    range_checks.push(c);

  }
}
return checked_cast<int>(reduced_iters_limit);

If you do this you won't need that delicate assert at the end.

More later.  I'm still working through the core logic in
`transform_long_range_checks`, and I will propose more changes
there.

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

PR: https://git.openjdk.java.net/jdk/pull/2045

From thartmann at openjdk.java.net  Mon Feb  1 08:57:54 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 08:57:54 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <eRMcQwt6vY0CMJR_QOFserPiT0Cj1ZuPUxlrb7Mpf0g=.cdad2a77-dc24-48ed-b420-64480b41beb3@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
 <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
 <eRMcQwt6vY0CMJR_QOFserPiT0Cj1ZuPUxlrb7Mpf0g=.cdad2a77-dc24-48ed-b420-64480b41beb3@github.com>
Message-ID: <hRc-v3z3ykUGOvDyJOz3Ox_pShcx54HbdFG1DfEn4vI=.aab717b7-0824-4f52-85c3-898d6d13225d@github.com>

On Mon, 1 Feb 2021 08:16:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove late ctrl update
>
> src/hotspot/share/opto/loopopts.cpp line 1516:
> 
>> 1514:             // address expression) and the AddP and StoreP have
>> 1515:             // different controls.
>> 1516:             if (!x->is_Load() && !x->is_DecodeNarrowPtr()) {
> 
> why this change?

This reverts Christian's fix for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607) which is no longer required.

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

PR: https://git.openjdk.java.net/jdk/pull/2315

From roland at openjdk.java.net  Mon Feb  1 09:07:41 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 1 Feb 2021 09:07:41 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
 <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
Message-ID: <LC-96NXU4QynpkUojsvqbBvGf_-nZFBsXoA0B7qykSY=.83918af3-f882-4e0f-ad66-17c1f29e097b@github.com>

On Fri, 29 Jan 2021 14:59:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Loop strip mining verification fails because a `LoadNode` with no safepoint use ends up in the `OuterStripMinedLoop`. The root cause is very similar to [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): A `LoadNode` with two uses (a field store and a return, see `test2`) is cloned by `PhaseIdealLoop::split_if_with_blocks_post()` for each use, to allow it to flow out of the loop. Both clones end up in the `OuterStripMinedLoop`, the clone for the field store because the store has a safepoint use and the clone for the return because `late_load_ctrl` is too conservative by taking all initial uses into account.
>> 
>> Now the load without a safepoint use is always detected by loop strip mining verification but without verification (for example, in a product build), we still hit several different issues depending on the exact use of the load (compare `test2/3/4`). The main issue is that loads without a safepoint use are not correctly wired when creating pre/main/post loops. Christian described this well in his RFR for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039638.html
>> 
>> Therefore, relaxing loop strip mining verification is not an option.
>> 
>> The problem with the fix for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607) is that it relies on IGVN being executed before pre/main/post loops are created, merging the two clones such that the remaining one has a safepoint use and is therefore correctly handled. However, this is not guaranteed. In fact, if `major_progress` is not set, pre/main/post loops could be created in the same round of loop opts without IGVN in-between (`IdealLoopTree::iteration_split` is executed right after `PhaseIdealLoop::split_if_with_blocks`).
>> 
>> I think we have the following options:
>> 1) Bail out if the loop is strip mined. I think that would be too conservative.
>> 
>> 2) Simply set `major_progress` when pinning a `LoadNode` to the `OuterStripMinedLoop` to make sure IGVN is executed and duplicate `LoadNodes` are merged. That seems quite invasive though.
>> 
>> 3) Allow the cloned load without a safepoint use (and therefore no usages in the `OuterStripMinedLoop`) to completely flow out of the loop. Currently, this is blocked by `late_load_ctrl` being computed on the initial `LoadNode` instead of the clone and therefore also taking into account the store that is referenced by the safepoint. We could simply re-compute the late ctrl for the cloned load, allowing it to flow out of the `OuterStripMinedLoop`. However, that only works if there is no anti-dependency in the `OuterStripMinedLoop`.
>> 
>> 4) Detect duplicate loads in the `OuterStripMinedLoop` on creation in `PhaseIdealLoop::split_if_with_blocks` and merge them right away.
>> 
>> I've decided to go with 4) and also reverted the fix for JDK-8249607 which is no longer required.
>> 
>> As Roland and Christian already noticed, there are various other issues with that code that hopefully will be addressed at some point by [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove late ctrl update

Marked as reviewed by roland (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2315

From roland at openjdk.java.net  Mon Feb  1 09:07:43 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 1 Feb 2021 09:07:43 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <hRc-v3z3ykUGOvDyJOz3Ox_pShcx54HbdFG1DfEn4vI=.aab717b7-0824-4f52-85c3-898d6d13225d@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
 <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
 <eRMcQwt6vY0CMJR_QOFserPiT0Cj1ZuPUxlrb7Mpf0g=.cdad2a77-dc24-48ed-b420-64480b41beb3@github.com>
 <hRc-v3z3ykUGOvDyJOz3Ox_pShcx54HbdFG1DfEn4vI=.aab717b7-0824-4f52-85c3-898d6d13225d@github.com>
Message-ID: <zxCGx6AJEPimU1T6yA8IOs3LGWIeJbzljEIVVgFdTtg=.e324f68e-9de3-481a-a57f-c25f4ec8e5f0@github.com>

On Mon, 1 Feb 2021 08:54:43 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/hotspot/share/opto/loopopts.cpp line 1516:
>> 
>>> 1514:             // address expression) and the AddP and StoreP have
>>> 1515:             // different controls.
>>> 1516:             if (!x->is_Load() && !x->is_DecodeNarrowPtr()) {
>> 
>> why this change?
>
> This reverts Christian's fix for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607) which is no longer required.

Ok.

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

PR: https://git.openjdk.java.net/jdk/pull/2315

From thartmann at openjdk.java.net  Mon Feb  1 09:13:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 09:13:42 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <LC-96NXU4QynpkUojsvqbBvGf_-nZFBsXoA0B7qykSY=.83918af3-f882-4e0f-ad66-17c1f29e097b@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
 <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
 <LC-96NXU4QynpkUojsvqbBvGf_-nZFBsXoA0B7qykSY=.83918af3-f882-4e0f-ad66-17c1f29e097b@github.com>
Message-ID: <8UPWuUAvL3fek6f7PmX_oJ-ycGw4jWyy-Vy2FZDt-u4=.632b5304-18ba-4ab5-86ee-5569acb64d5b@github.com>

On Mon, 1 Feb 2021 09:05:23 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove late ctrl update
>
> Marked as reviewed by roland (Reviewer).

Thanks for the review, Roland!

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

PR: https://git.openjdk.java.net/jdk/pull/2315

From chagedorn at openjdk.java.net  Mon Feb  1 09:25:52 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 1 Feb 2021 09:25:52 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
 <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
Message-ID: <mzbolClFHUh2GYgTh4DjcO6N1chPxYQQjIXuShykZPA=.da0e2e2c-9213-421b-8d25-ad44eb214e18@github.com>

On Fri, 29 Jan 2021 14:59:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Loop strip mining verification fails because a `LoadNode` with no safepoint use ends up in the `OuterStripMinedLoop`. The root cause is very similar to [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): A `LoadNode` with two uses (a field store and a return, see `test2`) is cloned by `PhaseIdealLoop::split_if_with_blocks_post()` for each use, to allow it to flow out of the loop. Both clones end up in the `OuterStripMinedLoop`, the clone for the field store because the store has a safepoint use and the clone for the return because `late_load_ctrl` is too conservative by taking all initial uses into account.
>> 
>> Now the load without a safepoint use is always detected by loop strip mining verification but without verification (for example, in a product build), we still hit several different issues depending on the exact use of the load (compare `test2/3/4`). The main issue is that loads without a safepoint use are not correctly wired when creating pre/main/post loops. Christian described this well in his RFR for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039638.html
>> 
>> Therefore, relaxing loop strip mining verification is not an option.
>> 
>> The problem with the fix for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607) is that it relies on IGVN being executed before pre/main/post loops are created, merging the two clones such that the remaining one has a safepoint use and is therefore correctly handled. However, this is not guaranteed. In fact, if `major_progress` is not set, pre/main/post loops could be created in the same round of loop opts without IGVN in-between (`IdealLoopTree::iteration_split` is executed right after `PhaseIdealLoop::split_if_with_blocks`).
>> 
>> I think we have the following options:
>> 1) Bail out if the loop is strip mined. I think that would be too conservative.
>> 
>> 2) Simply set `major_progress` when pinning a `LoadNode` to the `OuterStripMinedLoop` to make sure IGVN is executed and duplicate `LoadNodes` are merged. That seems quite invasive though.
>> 
>> 3) Allow the cloned load without a safepoint use (and therefore no usages in the `OuterStripMinedLoop`) to completely flow out of the loop. Currently, this is blocked by `late_load_ctrl` being computed on the initial `LoadNode` instead of the clone and therefore also taking into account the store that is referenced by the safepoint. We could simply re-compute the late ctrl for the cloned load, allowing it to flow out of the `OuterStripMinedLoop`. However, that only works if there is no anti-dependency in the `OuterStripMinedLoop`.
>> 
>> 4) Detect duplicate loads in the `OuterStripMinedLoop` on creation in `PhaseIdealLoop::split_if_with_blocks` and merge them right away.
>> 
>> I've decided to go with 4) and also reverted the fix for JDK-8249607 which is no longer required.
>> 
>> As Roland and Christian already noticed, there are various other issues with that code that hopefully will be addressed at some point by [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove late ctrl update

Nice summary! I agree that is better to go with 4) and try option 3) in a general clean up of this code (JDK-8252372). Looks good to me!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2315

From thartmann at openjdk.java.net  Mon Feb  1 09:36:43 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 09:36:43 GMT
Subject: RFR: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint [v2]
In-Reply-To: <mzbolClFHUh2GYgTh4DjcO6N1chPxYQQjIXuShykZPA=.da0e2e2c-9213-421b-8d25-ad44eb214e18@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
 <ssckgvy5QHhClePOXmNCSk41EaeYbmZgAMIxlVFOys4=.b5245a3b-c332-4f84-9384-ec2e23d06369@github.com>
 <mzbolClFHUh2GYgTh4DjcO6N1chPxYQQjIXuShykZPA=.da0e2e2c-9213-421b-8d25-ad44eb214e18@github.com>
Message-ID: <W8-w_bTohD25Cxmt3dJ9CqV7DgJ5ryBXyjmqU4J1MAA=.0901e3ce-2d22-45ee-adb4-99e55985a2f7@github.com>

On Mon, 1 Feb 2021 09:22:52 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove late ctrl update
>
> Nice summary! I agree that is better to go with 4) and try option 3) in a general clean up of this code (JDK-8252372). Looks good to me!

Thanks Christian!

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

PR: https://git.openjdk.java.net/jdk/pull/2315

From chagedorn at openjdk.java.net  Mon Feb  1 09:43:44 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 1 Feb 2021 09:43:44 GMT
Subject: Integrated: 8257498: Remove useless skeleton predicates
In-Reply-To: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
References: <6dUhcj2h_EaBfFa41hTfaiGtSNRPXG4HFSEhQq8MGaw=.3a769ef8-5d0a-4264-9e08-e2598f6974bf@github.com>
Message-ID: <htpzfW7e7nDKBasmalmo5hXf8_KAMBnr2pXi7YHiJ9E=.9a58ebe3-c449-4d17-a873-79e4bce10376@github.com>

On Thu, 14 Jan 2021 08:14:18 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in `PhaseIdealLoop::eliminate_useless_predicates()`.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: aec03772
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aec03772
Stats:     101 lines in 6 files changed: 66 ins; 16 del; 19 mod

8257498: Remove useless skeleton predicates

Reviewed-by: roland, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2075

From redestad at openjdk.java.net  Mon Feb  1 10:00:02 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 1 Feb 2021 10:00:02 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v4]
In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
Message-ID: <1gjeWjb-j-3CQq9cCgNw82cScyMdqXoSL7bWBgfrjEQ=.31e19c6b-56cf-45ae-b83d-0894c39c1d77@github.com>

> - Remove unused code
> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
> - Apply pattern matching to make some code more readable

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Missing .values

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2300/files
  - new: https://git.openjdk.java.net/jdk/pull/2300/files/aa88b6fd..0e3768b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300

PR: https://git.openjdk.java.net/jdk/pull/2300

From chagedorn at openjdk.java.net  Mon Feb  1 10:40:42 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 1 Feb 2021 10:40:42 GMT
Subject: RFR: 8259398: Super word not applied to a loop with
 byteArrayViewVarHandle
In-Reply-To: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
References: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
Message-ID: <nWvSn2CzuSWLYlcp_BxuBoc0PkFl102EyVZG6rmyics=.a90ced7c-ebd6-4971-98d7-18b930754d67@github.com>

On Fri, 29 Jan 2021 17:40:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Address expressing in this case has CastII which is not range check related.
> I think it is safe to skip any CastII nodes (similar to ConvI2L nodes) when parsing address for vectors - vectors will be constructed only if the same loop's variable and invariant are used for all memory operations regardless casts. Also vectors address depends on loop's variable so they will not be moved outside loop.
> In 32-bit VM there is no ConvI2L nodes so I moved CastII checks from under ConvI2L check.
> 
> New regression case added to TestBufferVectorization.java test.
> 
> Testing hs-tier1-7, RenaissanceStressTest. Run all vectorizing tests locally to make sure no regression.

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2317

From github.com+10482586+therealeliu at openjdk.java.net  Mon Feb  1 11:14:11 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Mon, 1 Feb 2021 11:14:11 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v2]
In-Reply-To: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
Message-ID: <RACrN4NM2hfj0NafSr9LzZaJ1VB_WPOOMKxSPL4qXUg=.e54621d5-c672-496b-9349-83e858d4cf18@github.com>

> This patch transforms '(x >>> rshift) + (x << lshift)' into
> 'RotateRight(x, rshift)' during GVN phase when both the shift exponents
> are constants and their sum equals to the number of bits for the type
> of shift base.
> 
> This patch implements some new match rules for AArch64 instructions
> which can take ROR as the optional shift. Such instructions are 'and',
> 'or', 'eor', 'eon', 'bic' and 'orn'.
> 
>   ror     w11, w2, #5
>   eor     w0, w1, w11
> 
> With this patch, above code could be optimized to below:
> 
>   eor     w0, w1, w2, ror #5
> 
> Finally, the patch refactors TestRotate.java[1][2].
> 
> Tested jtreg TestRotate.java, hotspot::hotspot_all_no_apps,
> jdk::jdk_core, langtools::tier1.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8252776
> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039911.html

Eric Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8256438
   
   Change-Id: Ia357074efc8488a57030863b3eab7b27839cd3d0
 - 8256438: AArch64: Implement match rules with ROR shift register value
   
   This patch transforms '(x >>> rshift) + (x << lshift)' into
   'RotateRight(x, rshift)' during GVN phase when both the shift exponents
   are constants and their sum equals to the number of bits for the type
   of shift base.
   
   This patch implements some new match rules for AArch64 instructions
   which can take ROR as the optional shift. Such instructions are 'and',
   'or', 'eor', 'eon', 'bic' and 'orn'.
   
     ror     w11, w2, #5
     eor     w0, w1, w11
   
   With this patch, above code could be optimized to below:
   
     eor     w0, w1, w2, ror #5
   
   Finally, the patch refactors TestRotate.java[1][2].
   
   Tested jtreg TestRotate.java, hotspot::hotspot_all_no_apps,
   jdk::jdk_core, langtools::tier1.
   
   [1] https://bugs.openjdk.java.net/browse/JDK-8252776
   [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039911.html
   
   Change-Id: I70842bcdb7cbc31bdf261c3223ea882076c2c66b

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1858/files
  - new: https://git.openjdk.java.net/jdk/pull/1858/files/6135975d..afc68c27

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1858&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1858&range=00-01

  Stats: 116364 lines in 2912 files changed: 46136 ins; 41070 del; 29158 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1858.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1858/head:pull/1858

PR: https://git.openjdk.java.net/jdk/pull/1858

From github.com+10482586+therealeliu at openjdk.java.net  Mon Feb  1 11:20:20 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Mon, 1 Feb 2021 11:20:20 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
Message-ID: <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>

> This patch transforms '(x >>> rshift) + (x << lshift)' into
> 'RotateRight(x, rshift)' during GVN phase when both the shift exponents
> are constants and their sum equals to the number of bits for the type
> of shift base.
> 
> This patch implements some new match rules for AArch64 instructions
> which can take ROR as the optional shift. Such instructions are 'and',
> 'or', 'eor', 'eon', 'bic' and 'orn'.
> 
>   ror     w11, w2, #5
>   eor     w0, w1, w11
> 
> With this patch, above code could be optimized to below:
> 
>   eor     w0, w1, w2, ror #5
> 
> Finally, the patch refactors TestRotate.java[1][2].
> 
> Tested jtreg TestRotate.java, hotspot::hotspot_all_no_apps,
> jdk::jdk_core, langtools::tier1.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8252776
> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039911.html

Eric Liu has updated the pull request incrementally with one additional commit since the last revision:

  Add benchmark test
  
  Change-Id: I63ca51d06070a07e5c20daf4b42d2c8d7237a1da

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1858/files
  - new: https://git.openjdk.java.net/jdk/pull/1858/files/afc68c27..492f4ca4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1858&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1858&range=01-02

  Stats: 110 lines in 3 files changed: 108 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1858.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1858/head:pull/1858

PR: https://git.openjdk.java.net/jdk/pull/1858

From rcastanedalo at openjdk.java.net  Mon Feb  1 11:34:59 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 1 Feb 2021 11:34:59 GMT
Subject: RFR: 8260581: IGV: enhance node search [v4]
In-Reply-To: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
Message-ID: <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>

> Apply several enhancements to the quick node search functionality: 
> 
> - Allow users to search by node id or name by default (i.e. when no property is specified) instead of name only.
> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>     1. **5** AddI
>     2. **5**54 MulI
>     3. 2**5** AddL
>     4. 2**5**3 AddL
> 
> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
> 
> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
> 
> and after:
> 
> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
> 
> 
> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
> 
> As part of the review, please evaluate not just the code changes but also the usability.

Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:

  Sort same-rank matches by first-word numeric value
  
  Sort otherwise equally relevant matches by node id, which is by default the
  first word in node labels. Thanks to Christian Hagedorn for the suggestion and
  (slightly adapted) patch.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2285/files
  - new: https://git.openjdk.java.net/jdk/pull/2285/files/537d023b..981e9038

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2285&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2285&range=02-03

  Stats: 24 lines in 1 file changed: 22 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2285/head:pull/2285

PR: https://git.openjdk.java.net/jdk/pull/2285

From vlivanov at openjdk.java.net  Mon Feb  1 11:38:49 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 1 Feb 2021 11:38:49 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <INg3qtMQAPPNQZ30DZm9XqB-7BKjgh3nigpQVzlP1pE=.99521b3a-8f2b-4c66-9ae8-c83a0007f53c@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
 <AnmJJ1iKY2JuCYo2Ks5scQIteJOxfEqw2FdN7c2j8cE=.fb5329d5-2973-40d1-83c6-ad5f09ab188b@github.com>
 <INg3qtMQAPPNQZ30DZm9XqB-7BKjgh3nigpQVzlP1pE=.99521b3a-8f2b-4c66-9ae8-c83a0007f53c@github.com>
Message-ID: <p0rv864nXBQBEH5Ig3EZ8YIZHsLj4bcehOr3GqRCVVY=.b8a19c52-bf2c-4016-9549-4baef9fc8253@github.com>

On Sun, 31 Jan 2021 00:41:11 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> compileonly and compilercount=1 will let the VM run slow enough to wait for a gc to be finished.

That's a strange way to provoke the bug. You could just increase the number of iterations instead.

But the right way to fix it is to stress ZGC to continuously run in the background while the test case aggressively unboxes vectors in compiled code. `-Xmx256m` helps with that while `-XX:CICompilerCount=1` is irrelevant.

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

PR: https://git.openjdk.java.net/jdk16/pull/139

From rcastanedalo at openjdk.java.net  Mon Feb  1 11:41:43 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 1 Feb 2021 11:41:43 GMT
Subject: RFR: 8260581: IGV: enhance node search [v2]
In-Reply-To: <Bi-IBOh27-CpVV2BhAnfs7tRDTaVRIlPwfEBsf28-yo=.2852a85a-970d-4426-a6fe-75db4cde79e8@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <1OvXkUZq1-wp42Ik4uO1Po77am92EVM99S9JWB4mf4I=.32748364-a89f-4002-b7a7-378ca2623422@github.com>
 <Bi-IBOh27-CpVV2BhAnfs7tRDTaVRIlPwfEBsf28-yo=.2852a85a-970d-4426-a6fe-75db4cde79e8@github.com>
Message-ID: <UzRHjgXR9thVOYTYd4hIbFM7Q0UrORC26482Pxzg00E=.2a426223-96d2-43d6-9183-04d60227a6e7@github.com>

On Fri, 29 Jan 2021 15:21:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug print
>
> Otherwise, it looks good to me.
> 
> I applied your patch and tested the new features in the IGV. They work as expected. Good to see the search being improved!

Commit 981e903 adds a match sorting refinement contributed by @chhagedorn (numeric sorting of same-rank matches), please re-review.

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

PR: https://git.openjdk.java.net/jdk/pull/2285

From github.com+25214855+casparcwang at openjdk.java.net  Mon Feb  1 12:10:45 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Mon, 1 Feb 2021 12:10:45 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <p0rv864nXBQBEH5Ig3EZ8YIZHsLj4bcehOr3GqRCVVY=.b8a19c52-bf2c-4016-9549-4baef9fc8253@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
 <AnmJJ1iKY2JuCYo2Ks5scQIteJOxfEqw2FdN7c2j8cE=.fb5329d5-2973-40d1-83c6-ad5f09ab188b@github.com>
 <INg3qtMQAPPNQZ30DZm9XqB-7BKjgh3nigpQVzlP1pE=.99521b3a-8f2b-4c66-9ae8-c83a0007f53c@github.com>
 <p0rv864nXBQBEH5Ig3EZ8YIZHsLj4bcehOr3GqRCVVY=.b8a19c52-bf2c-4016-9549-4baef9fc8253@github.com>
Message-ID: <_Wm-fi9j4TZ41F0G_92f7ioKQeDNgZiOEMmLkZ0lvvE=.0a9beba5-5089-4368-b4bc-73faf9d5e858@github.com>

On Mon, 1 Feb 2021 11:35:13 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > compileonly and compilercount=1 will let the VM run slow enough to wait for a gc to be finished.
> 
> That's a strange way to provoke the bug. You could just increase the number of iterations instead.
> 
> But the right way to fix it is to stress ZGC to continuously run in the background while the test case aggressively unboxes vectors in compiled code. `-Xmx256m` helps with that while `-XX:CICompilerCount=1` is irrelevant.

Yes, it's very weird to provoke the bug like this. If CICompilerCount=1 is removed, the test failed 60% roughly on my machine.
And the iteration has already changed from 100 to 1000,  the run time of the test is nearly 30s on release version of jvm.

If I add the following patch, the test always fails on my machine,

diff --git a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
index 1843ec0..959b29a 100644
--- a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
+++ b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
@@ -44,7 +44,7 @@ import jdk.internal.vm.annotation.ForceInline;
  * @modules jdk.incubator.vector
  * @modules java.base/jdk.internal.vm.annotation
  * @run testng/othervm -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer
- *      -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseZGC -Xbatch -Xmx256m VectorRebracket128Test
+ *      -XX:-TieredCompilation -XX:+UseZGC -Xmx256m VectorRebracket128Test
  */
 
 @Test
@@ -125,6 +125,14 @@ public class VectorRebracket128Test {
     @ForceInline
     static <E,F>
     void testVectorRebracket(VectorSpecies<E> a, VectorSpecies<F> b, byte[] input, byte[] output) {
+        new Thread(() -> {
+            while (true) {
+                try {
+                    System.gc();
+                    Thread.sleep(100);
+                } catch (Exception e) {}
+            }
+        }).start();
         Vector<E> av = a.fromByteArray(input, 0, ByteOrder.nativeOrder());
         int block;
         assert(input.length == output.length);

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

PR: https://git.openjdk.java.net/jdk16/pull/139

From github.com+25214855+casparcwang at openjdk.java.net  Mon Feb  1 12:18:44 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Mon, 1 Feb 2021 12:18:44 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <_Wm-fi9j4TZ41F0G_92f7ioKQeDNgZiOEMmLkZ0lvvE=.0a9beba5-5089-4368-b4bc-73faf9d5e858@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
 <AnmJJ1iKY2JuCYo2Ks5scQIteJOxfEqw2FdN7c2j8cE=.fb5329d5-2973-40d1-83c6-ad5f09ab188b@github.com>
 <INg3qtMQAPPNQZ30DZm9XqB-7BKjgh3nigpQVzlP1pE=.99521b3a-8f2b-4c66-9ae8-c83a0007f53c@github.com>
 <p0rv864nXBQBEH5Ig3EZ8YIZHsLj4bcehOr3GqRCVVY=.b8a19c52-bf2c-4016-9549-4baef9fc8253@github.com>
 <_Wm-fi9j4TZ41F0G_92f7ioKQeDNgZiOEMmLkZ0lvvE=.0a9beba5-5089-4368-b4bc-73faf9d5e858@github.com>
Message-ID: <RxsmBy3QMxbmHEF9nq2kZvq6QSVY7pwNqEeaNC7Ukwo=.b9774de4-2bf2-44b0-a882-f6f2dbf1639c@github.com>

On Mon, 1 Feb 2021 12:06:26 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>>> compileonly and compilercount=1 will let the VM run slow enough to wait for a gc to be finished.
>> 
>> That's a strange way to provoke the bug. You could just increase the number of iterations instead.
>> 
>> But the right way to fix it is to stress ZGC to continuously run in the background while the test case aggressively unboxes vectors in compiled code. `-Xmx256m` helps with that while `-XX:CICompilerCount=1` is irrelevant.
>
>> > compileonly and compilercount=1 will let the VM run slow enough to wait for a gc to be finished.
>> 
>> That's a strange way to provoke the bug. You could just increase the number of iterations instead.
>> 
>> But the right way to fix it is to stress ZGC to continuously run in the background while the test case aggressively unboxes vectors in compiled code. `-Xmx256m` helps with that while `-XX:CICompilerCount=1` is irrelevant.
> 
> Yes, it's very weird to provoke the bug like this. If CICompilerCount=1 is removed, the test failed 60% roughly on my machine.
> And the iteration has already changed from 100 to 1000,  the run time of the test is nearly 30s on release version of jvm.
> 
> If I add the following patch, the test always fails on my machine,
> 
> diff --git a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
> index 1843ec0..959b29a 100644
> --- a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
> +++ b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
> @@ -44,7 +44,7 @@ import jdk.internal.vm.annotation.ForceInline;
>   * @modules jdk.incubator.vector
>   * @modules java.base/jdk.internal.vm.annotation
>   * @run testng/othervm -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer
> - *      -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseZGC -Xbatch -Xmx256m VectorRebracket128Test
> + *      -XX:-TieredCompilation -XX:+UseZGC -Xmx256m VectorRebracket128Test
>   */
>  
>  @Test
> @@ -125,6 +125,14 @@ public class VectorRebracket128Test {
>      @ForceInline
>      static <E,F>
>      void testVectorRebracket(VectorSpecies<E> a, VectorSpecies<F> b, byte[] input, byte[] output) {
> +        new Thread(() -> {
> +            while (true) {
> +                try {
> +                    System.gc();
> +                    Thread.sleep(100);
> +                } catch (Exception e) {}
> +            }
> +        }).start();
>          Vector<E> av = a.fromByteArray(input, 0, ByteOrder.nativeOrder());
>          int block;
>          assert(input.length == output.length);

sorry for the wrong patch above,  the failed reason of the patch above is due to stack creation failure (create 1000 threads). The following is the right stress gc patch.

diff --git a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
index 6b266db..a761ea2 100644
--- a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
+++ b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
@@ -44,7 +44,7 @@ import jdk.internal.vm.annotation.ForceInline;
  * @modules jdk.incubator.vector
  * @modules java.base/jdk.internal.vm.annotation
  * @run testng/othervm -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer
- *      -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseZGC -Xbatch -Xmx256m VectorRebracket128Test
+ *      -XX:-TieredCompilation -XX:+UseZGC -Xmx256m VectorRebracket128Test
  */
 
 @Test
@@ -59,6 +59,19 @@ public class VectorRebracket128Test {
     static final VectorSpecies<Byte> bspec128 = ByteVector.SPECIES_128;
     static final VectorSpecies<Short> sspec128 = ShortVector.SPECIES_128;
 
+    static {
+        Thread t = new Thread(() -> {
+            while (true) {
+                try {
+                    System.gc();
+                    Thread.sleep(100);
+                } catch (Exception e) {}
+            }
+        });
+        t.setDaemon(true);
+        t.start();
+    }
+
     static <T> IntFunction<T> withToString(String s, IntFunction<T> f) {
         return new IntFunction<T>() {
             @Override

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

PR: https://git.openjdk.java.net/jdk16/pull/139

From aph at redhat.com  Mon Feb  1 12:32:00 2021
From: aph at redhat.com (Andrew Haley)
Date: Mon, 1 Feb 2021 12:32:00 +0000
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <c922d3ba-40f1-447c-5cd4-daf1226719da@huawei.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
 <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
 <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>
 <AQEAN6KcNC9S4AHg2Voyu9SsUlNXDh5ThUDOailTFMA=.3b9c1a70-7436-4306-bc6d-a5e3d91f9166@github.com>
 <OrMeQJItXcusPEf031k8wbL5j74RbyynGSQ3HM-1S0E=.9d440961-d955-4935-9dd8-8621052d1a35@github.com>
 <6a306bd0-19a9-f8d2-a285-1239371f389e@redhat.com>
 <c922d3ba-40f1-447c-5cd4-daf1226719da@huawei.com>
Message-ID: <bb6bb02c-50bf-9f6c-d268-260416ee64b0@redhat.com>

On 2/1/21 8:11 AM, dongbo (E) wrote:
> The tests passed with the newest version and still can catch the typo.
> Also tested a few of injected errors, the tests failed as expected.

One oddity has come up.

I'm running compiler/c2/TestShiftRightAndAccumulate
and the generated code I see for compiler.c2.TestShiftRightAndAccumulate::test_shorts
looks like:

;; B313: #     out( B313 B314 ) <- in( B312 B313 ) Loop( B313-B313 inner main of N1776 strip mined) Freq: 1006.03
  0x0000ffff70394cb0:   sbfiz   x16, x13, #1, #32           ;*saload {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - compiler.c2.TestShiftRightAndAccumulate::test_shorts at 268 (line 156)
  0x0000ffff70394cb4:   add     xmethod, xbcp, x16          ;*saload {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - jdk.internal.util.ArraysSupport::mismatch at 9 (line 362)
                                                            ; - java.util.Arrays::equals at 31 (line 2518)
                                                            ; - compiler.c2.TestShiftRightAndAccumulate::test_shorts at 286 (line 158)
  0x0000ffff70394cb8:   add     x14, xdispatch, x16         ;*iconst_m1 {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - jdk.internal.util.ArraysSupport::mismatch at 70 (line 376)
                                                            ; - java.util.Arrays::equals at 31 (line 2518)
                                                            ; - compiler.c2.TestShiftRightAndAccumulate::test_shorts at 213 (line 152)
  0x0000ffff70394cbc:   ldrsh   w11, [xmethod,#16]
  0x0000ffff70394cc0:   ldrsh   w15, [x14,#16]
  0x0000ffff70394cc4:   add     w11, w15, w11, lsr #23      ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - jdk.internal.util.ArraysSupport::mismatch at 50 (line 372)
                                                            ; - java.util.Arrays::equals at 31 (line 2518)
                                                            ; - compiler.c2.TestShiftRightAndAccumulate::test_shorts at 213 (line 152)
  0x0000ffff70394cc8:   add     x16, xesp, x16              ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - compiler.c2.TestShiftRightAndAccumulate::test_shorts at 226 (line 154)
  0x0000ffff70394ccc:   strh    w11, [x16,#16]              ;*aaload {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - compiler.c2.TestShiftRightAndAccumulate::test_shorts at 212 (line 152)
  0x0000ffff70394cd0:   ldrsh   w15, [xmethod,#16]
  0x0000ffff70394cd4:   ldrsh   w17, [x14,#16]
  0x0000ffff70394cd8:   add     x11, x17, w11, sxth
  0x0000ffff70394cdc:   add     w11, w11, w15
  0x0000ffff70394ce0:   strh    w11, [x16,#16]              ;*ifeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - jdk.internal.util.ArraysSupport::vectorizedMismatch at 62 (line 128)
                                                            ; - jdk.internal.util.ArraysSupport::mismatch at 32 (line 364)
                                                            ; - java.util.Arrays::equals at 31 (line 2518)
                                                            ; - compiler.c2.TestShiftRightAndAccumulate::test_shorts at 140 (line 146)
  0x0000ffff70394ce4:   ldrsh   w11, [xmethod,#18]

No vector instructions here. As far as I can see vectors are never used
for jshort, just for jchar. All very strange, and probably not your fault,
but since I'm looking I had to mention it.

The other weird thing is that {u,s}sra is never generated with the .8B form.

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


From chagedorn at openjdk.java.net  Mon Feb  1 12:41:43 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 1 Feb 2021 12:41:43 GMT
Subject: RFR: 8260581: IGV: enhance node search [v4]
In-Reply-To: <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>
Message-ID: <o1d4oaQ4MYmDa07I0Nbgpr8HQZRlTENgttapNi692Lc=.8456cdcb-d262-4757-8266-4c540c978726@github.com>

On Mon, 1 Feb 2021 11:34:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Apply several enhancements to the quick node search functionality: 
>> 
>> - Allow users to search by node id or name by default (i.e. when no property is specified) instead of name only.
>> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
>> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
>> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. Numeric matches with the same rank are sorted increasingly. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>>     1. **5** AddI
>>     2. **5**54 MulI
>>     3. 2**5** AddL
>>     4. 2**5**3 AddL
>> 
>> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
>> 
>> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
>> 
>> and after:
>> 
>> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
>> 
>> 
>> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
>> 
>> As part of the review, please evaluate not just the code changes but also the usability.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort same-rank matches by first-word numeric value
>   
>   Sort otherwise equally relevant matches by node id, which is by default the
>   first word in node labels. Thanks to Christian Hagedorn for the suggestion and
>   (slightly adapted) patch.

Thanks for adding the additional sorting suggestion! Looks good to me.

I applied the patch again and everything works as expected in the IGV.

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2285

From vlivanov at openjdk.java.net  Mon Feb  1 12:47:46 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 1 Feb 2021 12:47:46 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <RxsmBy3QMxbmHEF9nq2kZvq6QSVY7pwNqEeaNC7Ukwo=.b9774de4-2bf2-44b0-a882-f6f2dbf1639c@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
 <AnmJJ1iKY2JuCYo2Ks5scQIteJOxfEqw2FdN7c2j8cE=.fb5329d5-2973-40d1-83c6-ad5f09ab188b@github.com>
 <INg3qtMQAPPNQZ30DZm9XqB-7BKjgh3nigpQVzlP1pE=.99521b3a-8f2b-4c66-9ae8-c83a0007f53c@github.com>
 <p0rv864nXBQBEH5Ig3EZ8YIZHsLj4bcehOr3GqRCVVY=.b8a19c52-bf2c-4016-9549-4baef9fc8253@github.com>
 <_Wm-fi9j4TZ41F0G_92f7ioKQeDNgZiOEMmLkZ0lvvE=.0a9beba5-5089-4368-b4bc-73faf9d5e858@github.com>
 <RxsmBy3QMxbmHEF9nq2kZvq6QSVY7pwNqEeaNC7Ukwo=.b9774de4-2bf2-44b0-a882-f6f2dbf1639c@github.com>
Message-ID: <226iFOsl1hXrEoSe9uzgBb1Z75wxQEv5azlJIfzCO4k=.69d5ed3a-7337-472d-b106-1ce2e5d361bf@github.com>

On Mon, 1 Feb 2021 12:15:38 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>>> > compileonly and compilercount=1 will let the VM run slow enough to wait for a gc to be finished.
>>> 
>>> That's a strange way to provoke the bug. You could just increase the number of iterations instead.
>>> 
>>> But the right way to fix it is to stress ZGC to continuously run in the background while the test case aggressively unboxes vectors in compiled code. `-Xmx256m` helps with that while `-XX:CICompilerCount=1` is irrelevant.
>> 
>> Yes, it's very weird to provoke the bug like this. If CICompilerCount=1 is removed, the test failed 60% roughly on my machine.
>> And the iteration has already changed from 100 to 1000,  the run time of the test is nearly 30s on release version of jvm.
>> 
>> If I add the following patch, the test always fails on my machine,
>> 
>> diff --git a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
>> index 1843ec0..959b29a 100644
>> --- a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
>> +++ b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
>> @@ -44,7 +44,7 @@ import jdk.internal.vm.annotation.ForceInline;
>>   * @modules jdk.incubator.vector
>>   * @modules java.base/jdk.internal.vm.annotation
>>   * @run testng/othervm -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer
>> - *      -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseZGC -Xbatch -Xmx256m VectorRebracket128Test
>> + *      -XX:-TieredCompilation -XX:+UseZGC -Xmx256m VectorRebracket128Test
>>   */
>>  
>>  @Test
>> @@ -125,6 +125,14 @@ public class VectorRebracket128Test {
>>      @ForceInline
>>      static <E,F>
>>      void testVectorRebracket(VectorSpecies<E> a, VectorSpecies<F> b, byte[] input, byte[] output) {
>> +        new Thread(() -> {
>> +            while (true) {
>> +                try {
>> +                    System.gc();
>> +                    Thread.sleep(100);
>> +                } catch (Exception e) {}
>> +            }
>> +        }).start();
>>          Vector<E> av = a.fromByteArray(input, 0, ByteOrder.nativeOrder());
>>          int block;
>>          assert(input.length == output.length);
>
> sorry for the wrong patch above,  the failed reason of the patch above is due to stack creation failure (create 1000 threads). The following is the right stress gc patch.
> 
> diff --git a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
> index 6b266db..a761ea2 100644
> --- a/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
> +++ b/test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
> @@ -44,7 +44,7 @@ import jdk.internal.vm.annotation.ForceInline;
>   * @modules jdk.incubator.vector
>   * @modules java.base/jdk.internal.vm.annotation
>   * @run testng/othervm -XX:CompileCommand=compileonly,jdk/incubator/vector/ByteVector.fromByteBuffer
> - *      -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseZGC -Xbatch -Xmx256m VectorRebracket128Test
> + *      -XX:-TieredCompilation -XX:+UseZGC -Xmx256m VectorRebracket128Test
>   */
>  
>  @Test
> @@ -59,6 +59,19 @@ public class VectorRebracket128Test {
>      static final VectorSpecies<Byte> bspec128 = ByteVector.SPECIES_128;
>      static final VectorSpecies<Short> sspec128 = ShortVector.SPECIES_128;
>  
> +    static {
> +        Thread t = new Thread(() -> {
> +            while (true) {
> +                try {
> +                    System.gc();
> +                    Thread.sleep(100);
> +                } catch (Exception e) {}
> +            }
> +        });
> +        t.setDaemon(true);
> +        t.start();
> +    }
> +
>      static <T> IntFunction<T> withToString(String s, IntFunction<T> f) {
>          return new IntFunction<T>() {
>              @Override

Good. Please, file a follow-up RFE to improve the test.

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

PR: https://git.openjdk.java.net/jdk16/pull/139

From dongbo4 at huawei.com  Mon Feb  1 14:35:09 2021
From: dongbo4 at huawei.com (dongbo (E))
Date: Mon, 1 Feb 2021 22:35:09 +0800
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <bb6bb02c-50bf-9f6c-d268-260416ee64b0@redhat.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
 <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
 <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>
 <AQEAN6KcNC9S4AHg2Voyu9SsUlNXDh5ThUDOailTFMA=.3b9c1a70-7436-4306-bc6d-a5e3d91f9166@github.com>
 <OrMeQJItXcusPEf031k8wbL5j74RbyynGSQ3HM-1S0E=.9d440961-d955-4935-9dd8-8621052d1a35@github.com>
 <6a306bd0-19a9-f8d2-a285-1239371f389e@redhat.com>
 <c922d3ba-40f1-447c-5cd4-daf1226719da@huawei.com>
 <bb6bb02c-50bf-9f6c-d268-260416ee64b0@redhat.com>
Message-ID: <324d99d5-3fdb-084c-1ab8-4a2282aaa447@huawei.com>


On 2021/2/1 20:32, Andrew Haley wrote:
> On 2/1/21 8:11 AM, dongbo (E) wrote:
>> The tests passed with the newest version and still can catch the typo.
>> Also tested a few of injected errors, the tests failed as expected.
> One oddity has come up.
>
> I'm running compiler/c2/TestShiftRightAndAccumulate
> and the generated code I see for compiler.c2.TestShiftRightAndAccumulate::test_shorts
>
> No vector instructions here. As far as I can see vectors are never used
> for jshort, just for jchar. All very strange, and probably not your fault,
> but since I'm looking I had to mention it.
>
> The other weird thing is that {u,s}sra is never generated with the .8B form.

I guess the `usra` is not generated for `byte` and `short` because:
```
src/hotspot/share/opto/vectornode.cpp, line 182:
 ? case Op_URShiftI:
 ??? switch (bt) {
 ??? case T_BOOLEAN:return Op_URShiftVB;
 ??? case T_CHAR:?? return Op_URShiftVS;
 ??? case T_BYTE:
 ??? case T_SHORT:? return 0; // Vector logical right shift for signed short
 ???????????????????????????? // values produces incorrect Java result for
 ???????????????????????????? // negative data because java code should 
convert
 ???????????????????????????? // a short value into int value with sign
 ???????????????????????????? // extension before a shift.
 ??? case T_INT:??? return Op_URShiftVI;
 ??? default:?????? ShouldNotReachHere(); return 0;
 ??? }
```

For `byte` and `short`, we can have `ssra` for the code below:

```

 ??????? for (int i = 0; i < count; i++) {
 ??????????? shortsC[i] = (short) (shortsA[i] + (shortsB[i] >> 5));
 ??????????? shortsD[i] = (short) (shortsA[i] + shortsB[i]);
 ??????? }

```

I updated the tests to use this code, although I don't know why the 
similar pattern of `char` does not works for `short`.

For `.8B` form, we only have `sshr + add`:

```

 ????????? ??? 0x0000ffff90085664:?? sshr??????? v16.8b, v16.8b, #1
 ????????? ??? 0x0000ffff90085668:?? add v16.8b, v16.8b, v17.8b

```

According to the current implementation, it is strange that they are not 
combined into a `ssra`:

```

AddVB:??? match(Set dst (AddVB src1 src2))
RShiftVB: match(Set dst (RShiftVB src (RShiftCntV shift)))
SSRA_VB: match(Set dst (AddVB dst (RShiftVB src (RShiftCntV shift))))

```

I think we need further investigate the last two issues.






From dongbo at openjdk.java.net  Mon Feb  1 14:36:04 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 1 Feb 2021 14:36:04 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v5]
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <3CKNS6J7Rr4dq69Vw5-PofaIvMgZulMUZCYk1N9Hy9E=.e6dc1c3f-080c-4d30-9f94-2f149613d9a0@github.com>

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  update tests for bytes and shorts

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/136/files
  - new: https://git.openjdk.java.net/jdk16/pull/136/files/f2e490a3..ca3d2192

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=03-04

  Stats: 74 lines in 1 file changed: 19 ins; 0 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/136/head:pull/136

PR: https://git.openjdk.java.net/jdk16/pull/136

From kvn at openjdk.java.net  Mon Feb  1 15:51:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 15:51:46 GMT
Subject: RFR: 8259398: Super word not applied to a loop with
 byteArrayViewVarHandle
In-Reply-To: <nWvSn2CzuSWLYlcp_BxuBoc0PkFl102EyVZG6rmyics=.a90ced7c-ebd6-4971-98d7-18b930754d67@github.com>
References: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
 <nWvSn2CzuSWLYlcp_BxuBoc0PkFl102EyVZG6rmyics=.a90ced7c-ebd6-4971-98d7-18b930754d67@github.com>
Message-ID: <zYY4ASSogxYHqEDA4zgrh61kC4KK7tVPt3xK1HcNE-I=.24898781-78c8-4687-aabd-a70357c72779@github.com>

On Mon, 1 Feb 2021 10:37:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Address expressing in this case has CastII which is not range check related.
>> I think it is safe to skip any CastII nodes (similar to ConvI2L nodes) when parsing address for vectors - vectors will be constructed only if the same loop's variable and invariant are used for all memory operations regardless casts. Also vectors address depends on loop's variable so they will not be moved outside loop.
>> In 32-bit VM there is no ConvI2L nodes so I moved CastII checks from under ConvI2L check.
>> 
>> New regression case added to TestBufferVectorization.java test.
>> 
>> Testing hs-tier1-7, RenaissanceStressTest. Run all vectorizing tests locally to make sure no regression.
>
> Looks good!

Thank you all

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

PR: https://git.openjdk.java.net/jdk/pull/2317

From kvn at openjdk.java.net  Mon Feb  1 15:51:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 15:51:46 GMT
Subject: RFR: 8259398: Super word not applied to a loop with
 byteArrayViewVarHandle
In-Reply-To: <zYY4ASSogxYHqEDA4zgrh61kC4KK7tVPt3xK1HcNE-I=.24898781-78c8-4687-aabd-a70357c72779@github.com>
References: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
 <nWvSn2CzuSWLYlcp_BxuBoc0PkFl102EyVZG6rmyics=.a90ced7c-ebd6-4971-98d7-18b930754d67@github.com>
 <zYY4ASSogxYHqEDA4zgrh61kC4KK7tVPt3xK1HcNE-I=.24898781-78c8-4687-aabd-a70357c72779@github.com>
Message-ID: <Bl8zZj5kUUy_dwZXuHXKfeflTHTGVKnIO0adv9RURA0=.ca2df723-5fe1-42de-a1ac-cbfae85e54fe@github.com>

On Mon, 1 Feb 2021 15:47:17 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Looks good!
>
> Thank you all

Thank you all for reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/2317

From kvn at openjdk.java.net  Mon Feb  1 15:51:47 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 15:51:47 GMT
Subject: Integrated: 8259398: Super word not applied to a loop with
 byteArrayViewVarHandle
In-Reply-To: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
References: <I0ExHviPyb7ZzxqBZh6lkvpUtl35ghRzDdI1Oq57RYA=.4bfd8809-78be-49a0-b7bb-03ff9d60f3fa@github.com>
Message-ID: <KenmR629UDPe1plJEHqYmCybsSv6FN3ruTolTlggbf4=.69c03b72-51b4-42b9-ba15-088774dd1660@github.com>

On Fri, 29 Jan 2021 17:40:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Address expressing in this case has CastII which is not range check related.
> I think it is safe to skip any CastII nodes (similar to ConvI2L nodes) when parsing address for vectors - vectors will be constructed only if the same loop's variable and invariant are used for all memory operations regardless casts. Also vectors address depends on loop's variable so they will not be moved outside loop.
> In 32-bit VM there is no ConvI2L nodes so I moved CastII checks from under ConvI2L check.
> 
> New regression case added to TestBufferVectorization.java test.
> 
> Testing hs-tier1-7, RenaissanceStressTest. Run all vectorizing tests locally to make sure no regression.

This pull request has now been integrated.

Changeset: 02d586e1
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02d586e1
Stats:     57 lines in 2 files changed: 41 ins; 6 del; 10 mod

8259398: Super word not applied to a loop with byteArrayViewVarHandle

Reviewed-by: vlivanov, thartmann, chagedorn

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

PR: https://git.openjdk.java.net/jdk/pull/2317

From github.com+7837910+xpbob at openjdk.java.net  Mon Feb  1 18:46:53 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Mon, 1 Feb 2021 18:46:53 GMT
Subject: RFR: 8260576: Typo in
 compiler/runtime/safepoints/TestRegisterRestoring.java
Message-ID: <ZMtvZEdCYfZ2gYgg_SL8yG5w1_Sz8By0ukKHdSiIK8w=.125a3eb0-7d8b-4b1a-abbe-16f31bec78b7@github.com>

8260576: Typo in compiler/runtime/safepoints/TestRegisterRestoring.java

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

Commit messages:
 - 8260576: Typo in compiler/runtime/safepoints/TestRegisterRestoring.java

Changes: https://git.openjdk.java.net/jdk/pull/2286/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2286&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260576
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2286/head:pull/2286

PR: https://git.openjdk.java.net/jdk/pull/2286

From thartmann at openjdk.java.net  Mon Feb  1 18:46:53 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 18:46:53 GMT
Subject: RFR: 8260576: Typo in
 compiler/runtime/safepoints/TestRegisterRestoring.java
In-Reply-To: <ZMtvZEdCYfZ2gYgg_SL8yG5w1_Sz8By0ukKHdSiIK8w=.125a3eb0-7d8b-4b1a-abbe-16f31bec78b7@github.com>
References: <ZMtvZEdCYfZ2gYgg_SL8yG5w1_Sz8By0ukKHdSiIK8w=.125a3eb0-7d8b-4b1a-abbe-16f31bec78b7@github.com>
Message-ID: <9jFka1iZIXLM0WVXVx2pH7XT9X9QNlYvI8hj5QyrDuY=.cb0b079b-e089-4360-b765-78b087a0ee4d@github.com>

On Thu, 28 Jan 2021 11:23:22 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> 8260576: Typo in compiler/runtime/safepoints/TestRegisterRestoring.java

Changes requested by thartmann (Reviewer).

Marked as reviewed by thartmann (Reviewer).

test/hotspot/jtreg/compiler/runtime/safepoints/TestRegisterRestoring.java line 50:

> 48:             for (int i = 0; i < array.length; i++) {
> 49:                 if (array[i] != 10_000) {
> 50:                     throw new RuntimeException("Test failed: array[" + i + "] = " + array[i] + " but should be 10,000");

`.` is simply the (German) thousands separator. Not sure it's really worth it changing it to a `,`. But given the exception message is in English, looks good to me.

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

PR: https://git.openjdk.java.net/jdk/pull/2286

From github.com+51754783+coreyashford at openjdk.java.net  Mon Feb  1 18:51:47 2021
From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford)
Date: Mon, 1 Feb 2021 18:51:47 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v3]
In-Reply-To: <owXqOZWxdbUC-J5GxERy4zjPk5Ifb1xCsslCBqfxL_Y=.08191ff0-a579-4267-b033-2bf3e5de6752@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <owXqOZWxdbUC-J5GxERy4zjPk5Ifb1xCsslCBqfxL_Y=.08191ff0-a579-4267-b033-2bf3e5de6752@github.com>
Message-ID: <LL-lHvcJnaBRj-glM0u759tBNQZsyp46zpInu-vC0iw=.9b413d6e-9cc3-4ee0-abb3-47f986de7e80@github.com>

On Mon, 1 Feb 2021 08:28:06 GMT, Kazunori Ogata <ogatak at openjdk.org> wrote:

>> The POWER10 processor, which implements Power ISA 3.1 [1], supports new instruction formats where an instruction takes two 32bit words.  The first word is called prefix, and the instructions with prefix are called prefixed instructions.  With more bits in opcode and operand fields, POWER10 supports larger immediate value in an operand, as well as many new instructions.
>> 
>> This is the first changes to handle prefixed instructions, and this adds support of prefixed addi (= paddi) instruction as an example of prefix usage.  paddi accepts 34bit immediate value, while original addi accepts 16bit value.
>> 
>> [1] https://ibm.ent.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0
>
> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update (2nd round) based on review comments

Just a few more minor things... several defined-but-not-used functions, and some little formatting issues.

src/hotspot/cpu/ppc/assembler_ppc.inline.hpp line 43:

> 41:   // Add nop if a prefixed (two-word) instruction is going to cross a 64-byte boundary.
> 42:   // (See Section 1.6 of Power ISA Version 3.1)
> 43:   if(is_aligned(reinterpret_cast<uintptr_t>(pc()) + sizeof(int32_t), 64) ||

add space after 'if'

src/hotspot/cpu/ppc/assembler_ppc.inline.hpp line 149:

> 147: inline void Assembler::paddi(  Register d, Register a, long si34, bool r = false) {
> 148:   assert(a != R0 || r, "r0 not allowed, unless R is set (CIA relative)");
> 149:   paddi_r0ok( d, a, si34, r);

The space after the ( isn't needed here, since it's not aligning with a similar call above or below.

src/hotspot/cpu/ppc/assembler_ppc.hpp line 1322:

> 1320: 
> 1321:   static inline int hi18_signed(  int x) { return hi16_signed(x); }
> 1322:   static inline int hi18_signed( long x) { return (int)((x << 30) >> 46); }

The extra spaces for alignment look a bit strange here.  I think it should be:
static inline int hi18_signed( int x) ...
static inline int hi18_signed(long x) ...
Basically, remove the leading space from the ( long x) one and delete one from (  int x) to match.

src/hotspot/cpu/ppc/assembler_ppc.hpp line 1389:

> 1387:   inline void pla(  Register d, long si34);
> 1388:   inline void pla(  Register d, Register a, long si34);
> 1389:   inline void psubi(Register d, Register a, long si34);

pla and psubi are defined but not used.

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

Changes requested by CoreyAshford at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/2095

From github.com+51754783+coreyashford at openjdk.java.net  Mon Feb  1 18:51:47 2021
From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford)
Date: Mon, 1 Feb 2021 18:51:47 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v3]
In-Reply-To: <MzaJSTGiqCkZINAqOWRnig7-kUCmxBLGNU_CjvqTiBY=.60911a12-97ef-4068-81e8-c7ec83d21a06@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <AtBNdURD637gt2Uq0UtN6SGzcslSsWs7ZLC4TrOTXPQ=.65482e3d-1db6-4772-bfd2-771ec0fbbdf6@github.com>
 <cLMlamzeU3HzSZVUMSgz0AkOIryBxRfUChh-WxX-g6M=.9358d16c-1645-4cca-8ac6-fe860cee0eba@github.com>
 <MzaJSTGiqCkZINAqOWRnig7-kUCmxBLGNU_CjvqTiBY=.60911a12-97ef-4068-81e8-c7ec83d21a06@github.com>
Message-ID: <sN6oIhaU6od_s2eFC6m9yJPReVwDRvDL3a5fi7b1jbc=.e448de63-b74b-46f1-8241-94b645d2840d@github.com>

On Wed, 27 Jan 2021 17:50:57 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> "is_<instr>()" are the functions for testing instructions in the generated code and they are usually called in "assert()" or complex combination of if statements.  So if this function returns false when p points at nop, the assertions or the if-conditions need to handle the nop case and the code will become difficult to read.  Since the padding nop is a non-common case, I'd like to hide the existence of nop in this function.
>
> Ok, got it.  Thanks for the explanation.  Maybe an extra comment in the code saying essentially what you said here would be appropriate?

Looks good!

>> If predicate is added, adlc fails with an error message: "Syntax Error: :ADLC does not support instruction chain rules with predicates"  I think addL_reg_imm34 allows predicate because it is not called from other rules.  Is it better to leave some comments?  (BTW, immI32 is only for POWER10 or higher.  POWER9 version uses immI16 or immI16hi.)
>
> Hmm, I'm confused.  I don't see any other reference to loadConL34 in ppc.ad.

I wish we knew why this predicate is causing an issue, but I guess it's not important because the operand type provides sufficient limiting of the instruct.

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

PR: https://git.openjdk.java.net/jdk/pull/2095

From jiefu at openjdk.java.net  Tue Feb  2 00:04:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 2 Feb 2021 00:04:41 GMT
Subject: RFR: 8260576: Typo in
 compiler/runtime/safepoints/TestRegisterRestoring.java
In-Reply-To: <ZMtvZEdCYfZ2gYgg_SL8yG5w1_Sz8By0ukKHdSiIK8w=.125a3eb0-7d8b-4b1a-abbe-16f31bec78b7@github.com>
References: <ZMtvZEdCYfZ2gYgg_SL8yG5w1_Sz8By0ukKHdSiIK8w=.125a3eb0-7d8b-4b1a-abbe-16f31bec78b7@github.com>
Message-ID: <MiRIityAiZlIcDXR-Esnuhr9YqwdTYa82UMlDZcTtJc=.d508f11b-41ff-4883-978e-29fe3aca4983@github.com>

On Thu, 28 Jan 2021 11:23:22 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> 8260576: Typo in compiler/runtime/safepoints/TestRegisterRestoring.java

Looks good and trivial.
Will sponsor it.

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

Marked as reviewed by jiefu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2286

From xliu at openjdk.java.net  Tue Feb  2 00:57:39 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 2 Feb 2021 00:57:39 GMT
Subject: RFR: 8260581: IGV: enhance node search [v4]
In-Reply-To: <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>
Message-ID: <lFiva2V5jzUTH5Yv42kBdWeEe4LHXlhRHZVTv4NmrLc=.df389a50-7096-42b7-9c29-3e41add10a4d@github.com>

On Mon, 1 Feb 2021 11:34:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Apply several enhancements to the quick node search functionality: 
>> 
>> - Allow users to search by node id or name by default (i.e. when no property is specified) instead of name only.
>> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
>> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
>> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. Numeric matches with the same rank are sorted increasingly. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>>     1. **5** AddI
>>     2. **5**54 MulI
>>     3. 2**5** AddL
>>     4. 2**5**3 AddL
>> 
>> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
>> 
>> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
>> 
>> and after:
>> 
>> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
>> 
>> 
>> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
>> 
>> As part of the review, please evaluate not just the code changes but also the usability.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort same-rank matches by first-word numeric value
>   
>   Sort otherwise equally relevant matches by node id, which is by default the
>   first word in node labels. Thanks to Christian Hagedorn for the suggestion and
>   (slightly adapted) patch.

LGTM. I ran it with your patch. it works as expected.

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

Marked as reviewed by xliu (no project role).

PR: https://git.openjdk.java.net/jdk/pull/2285

From jiefu at openjdk.java.net  Tue Feb  2 02:01:48 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 2 Feb 2021 02:01:48 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <226iFOsl1hXrEoSe9uzgBb1Z75wxQEv5azlJIfzCO4k=.69d5ed3a-7337-472d-b106-1ce2e5d361bf@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
 <AnmJJ1iKY2JuCYo2Ks5scQIteJOxfEqw2FdN7c2j8cE=.fb5329d5-2973-40d1-83c6-ad5f09ab188b@github.com>
 <INg3qtMQAPPNQZ30DZm9XqB-7BKjgh3nigpQVzlP1pE=.99521b3a-8f2b-4c66-9ae8-c83a0007f53c@github.com>
 <p0rv864nXBQBEH5Ig3EZ8YIZHsLj4bcehOr3GqRCVVY=.b8a19c52-bf2c-4016-9549-4baef9fc8253@github.com>
 <_Wm-fi9j4TZ41F0G_92f7ioKQeDNgZiOEMmLkZ0lvvE=.0a9beba5-5089-4368-b4bc-73faf9d5e858@github.com>
 <RxsmBy3QMxbmHEF9nq2kZvq6QSVY7pwNqEeaNC7Ukwo=.b9774de4-2bf2-44b0-a882-f6f2dbf1639c@github.com>
 <226iFOsl1hXrEoSe9uzgBb1Z75wxQEv5azlJIfzCO4k=.69d5ed3a-7337-472d-b106-1ce2e5d361bf@github.com>
Message-ID: <JBocBhTuVYoDaykHPBrn8Cs_ZRY56SH-5oAkFBGE-uM=.8178a00d-b078-49d5-831a-e2ef4eae3aba@github.com>

On Mon, 1 Feb 2021 12:44:59 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Good. Please, file a follow-up RFE to improve the test.

OK.
I will help to file a JBS bug once the fix has been merged into the jdk mainline.
It will be only fixed in the jdk17, right?
Thanks.

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

PR: https://git.openjdk.java.net/jdk16/pull/139

From github.com+7837910+xpbob at openjdk.java.net  Tue Feb  2 02:19:42 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Tue, 2 Feb 2021 02:19:42 GMT
Subject: Integrated: 8260576: Typo in
 compiler/runtime/safepoints/TestRegisterRestoring.java
In-Reply-To: <ZMtvZEdCYfZ2gYgg_SL8yG5w1_Sz8By0ukKHdSiIK8w=.125a3eb0-7d8b-4b1a-abbe-16f31bec78b7@github.com>
References: <ZMtvZEdCYfZ2gYgg_SL8yG5w1_Sz8By0ukKHdSiIK8w=.125a3eb0-7d8b-4b1a-abbe-16f31bec78b7@github.com>
Message-ID: <JqOw6vw4BECVVTpjeP-uDG6q6TzypqzYDXUHmLWkHC0=.ae56552b-2d6b-438f-8c5c-57e4df00342d@github.com>

On Thu, 28 Jan 2021 11:23:22 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> 8260576: Typo in compiler/runtime/safepoints/TestRegisterRestoring.java

This pull request has now been integrated.

Changeset: 54e7a642
Author:    bobpengxie <bobpengxie at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/54e7a642
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8260576: Typo in compiler/runtime/safepoints/TestRegisterRestoring.java

Reviewed-by: thartmann, jiefu

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

PR: https://git.openjdk.java.net/jdk/pull/2286

From dongbo at openjdk.java.net  Tue Feb  2 07:08:11 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 2 Feb 2021 07:08:11 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v6]
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <nFcPvW2T_zeaOAprjqRJk2aHjb6KP1T0NivpnGdWBFk=.41e5058c-e15a-42b7-80a0-50d9745445d9@github.com>

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  Update tests to match .2I. Still cannot match ssra for .8B, sshr+add are not combined.

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/136/files
  - new: https://git.openjdk.java.net/jdk16/pull/136/files/ca3d2192..693f8cbd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=04-05

  Stats: 88 lines in 1 file changed: 39 ins; 41 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/136/head:pull/136

PR: https://git.openjdk.java.net/jdk16/pull/136

From thartmann at openjdk.java.net  Tue Feb  2 07:26:48 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 07:26:48 GMT
Subject: Integrated: 8260420: C2 compilation fails with assert(found_sfpt)
 failed: no node in loop that's not input to safepoint
In-Reply-To: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
References: <JeYENql3vZ7iilXYXlwo4PPfj0-7Egz35hwCmZhGMKE=.6f5ab863-9d1b-4b1a-a1a6-6adeb8bb2b86@github.com>
Message-ID: <wLjn5KYa8gMA_6rokg8INKoQ1NPDwIW2tbLn9_nXo0I=.23622580-b6b7-4d6e-a4f5-8f5f0d94acd4@github.com>

On Fri, 29 Jan 2021 14:35:35 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Loop strip mining verification fails because a `LoadNode` with no safepoint use ends up in the `OuterStripMinedLoop`. The root cause is very similar to [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): A `LoadNode` with two uses (a field store and a return, see `test2`) is cloned by `PhaseIdealLoop::split_if_with_blocks_post()` for each use, to allow it to flow out of the loop. Both clones end up in the `OuterStripMinedLoop`, the clone for the field store because the store has a safepoint use and the clone for the return because `late_load_ctrl` is too conservative by taking all initial uses into account.
> 
> Now the load without a safepoint use is always detected by loop strip mining verification but without verification (for example, in a product build), we still hit several different issues depending on the exact use of the load (compare `test2/3/4`). The main issue is that loads without a safepoint use are not correctly wired when creating pre/main/post loops. Christian described this well in his RFR for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039638.html
> 
> Therefore, relaxing loop strip mining verification is not an option.
> 
> The problem with the fix for [JDK-8249607](https://bugs.openjdk.java.net/browse/JDK-8249607) is that it relies on IGVN being executed before pre/main/post loops are created, merging the two clones such that the remaining one has a safepoint use and is therefore correctly handled. However, this is not guaranteed. In fact, if `major_progress` is not set, pre/main/post loops could be created in the same round of loop opts without IGVN in-between (`IdealLoopTree::iteration_split` is executed right after `PhaseIdealLoop::split_if_with_blocks`).
> 
> I think we have the following options:
> 1) Bail out if the loop is strip mined. I think that would be too conservative.
> 
> 2) Simply set `major_progress` when pinning a `LoadNode` to the `OuterStripMinedLoop` to make sure IGVN is executed and duplicate `LoadNodes` are merged. That seems quite invasive though.
> 
> 3) Allow the cloned load without a safepoint use (and therefore no usages in the `OuterStripMinedLoop`) to completely flow out of the loop. Currently, this is blocked by `late_load_ctrl` being computed on the initial `LoadNode` instead of the clone and therefore also taking into account the store that is referenced by the safepoint. We could simply re-compute the late ctrl for the cloned load, allowing it to flow out of the `OuterStripMinedLoop`. However, that only works if there is no anti-dependency in the `OuterStripMinedLoop`.
> 
> 4) Detect duplicate loads in the `OuterStripMinedLoop` on creation in `PhaseIdealLoop::split_if_with_blocks` and merge them right away.
> 
> I've decided to go with 4) and also reverted the fix for JDK-8249607 which is no longer required.
> 
> As Roland and Christian already noticed, there are various other issues with that code that hopefully will be addressed at some point by [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: fe407cf1
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fe407cf1
Stats:     91 lines in 2 files changed: 75 ins; 1 del; 15 mod

8260420: C2 compilation fails with assert(found_sfpt) failed: no node in loop that's not input to safepoint

Reviewed-by: kvn, roland, chagedorn

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

PR: https://git.openjdk.java.net/jdk/pull/2315

From rcastanedalo at openjdk.java.net  Tue Feb  2 08:14:54 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 2 Feb 2021 08:14:54 GMT
Subject: RFR: 8260581: IGV: enhance node search [v4]
In-Reply-To: <o1d4oaQ4MYmDa07I0Nbgpr8HQZRlTENgttapNi692Lc=.8456cdcb-d262-4757-8266-4c540c978726@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>
 <o1d4oaQ4MYmDa07I0Nbgpr8HQZRlTENgttapNi692Lc=.8456cdcb-d262-4757-8266-4c540c978726@github.com>
Message-ID: <T0rTEpRNmyNebW5yaYLGv9sx9nGqXXoZhDtzhLskFMM=.02860816-6ec7-4060-bf26-e032dafcbde4@github.com>

On Mon, 1 Feb 2021 12:39:16 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Thanks for adding the additional sorting suggestion! Looks good to me.
> 
> I applied the patch again and everything works as expected in the IGV.

Thanks again, Christian!

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

PR: https://git.openjdk.java.net/jdk/pull/2285

From rcastanedalo at openjdk.java.net  Tue Feb  2 08:14:54 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 2 Feb 2021 08:14:54 GMT
Subject: RFR: 8260581: IGV: enhance node search [v4]
In-Reply-To: <lFiva2V5jzUTH5Yv42kBdWeEe4LHXlhRHZVTv4NmrLc=.df389a50-7096-42b7-9c29-3e41add10a4d@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>
 <lFiva2V5jzUTH5Yv42kBdWeEe4LHXlhRHZVTv4NmrLc=.df389a50-7096-42b7-9c29-3e41add10a4d@github.com>
Message-ID: <3mWXw-F3HmKKfHoRkt1RfIqYPn-G_moCdkx1F-wZ658=.7a5d49fd-33a2-4e85-9530-9b40b2ced589@github.com>

On Tue, 2 Feb 2021 00:55:16 GMT, Xin Liu <xliu at openjdk.org> wrote:

> LGTM. I ran it with your patch. it works as expected.

Thanks for reviewing, Xin!

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

PR: https://git.openjdk.java.net/jdk/pull/2285

From dongbo at openjdk.java.net  Tue Feb  2 08:21:48 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 2 Feb 2021 08:21:48 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <DkxP64SKhG9uHwYwxLgC-xwmtfpDoqpaHSPMGw1Kz6w=.63f9c3d2-22c2-435c-8b95-e0171166854b@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <HvyAy7ZfnJLdl7NkO98VwCOX9Ju4zQiJZ7AV2lNznmQ=.20283243-c16f-4e56-8153-72702a818495@github.com>
 <DkxP64SKhG9uHwYwxLgC-xwmtfpDoqpaHSPMGw1Kz6w=.63f9c3d2-22c2-435c-8b95-e0171166854b@github.com>
Message-ID: <LOvcOMFmNMY2HsSR7pkFajsVbF2ceR8Yr85qdbD1E-o=.c5998d49-d305-4f2b-add2-b79b9305de73@github.com>

On Mon, 1 Feb 2021 07:48:35 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make empty ins_encode when shift >= 16 (chars)
>
> Looks good to me.

Hi, Andrew.

The reason `ssra` is not generated with .8B form is that if loop size is 16, the vector length is not 8 but 4.
Because we only have `predicate(n->as_Vector()->length() == 8)` in `vsraa8B_imm`, so they are not matched.
We should fix this with the following code:
 instruct vsraa8B_imm(vecD dst, vecD src, immI shift) %{
-  predicate(n->as_Vector()->length() == 8);
+  predicate(n->as_Vector()->length() == 4 || n->as_Vector()->length() == 8);
   match(Set dst (AddVB dst (RShiftVB src (RShiftCntV shift))));
   ins_cost(INSN_COST);
   format %{ "ssra    $dst, $src, $shift\t# vector (8B)" %}
@@ -18782,7 +18782,7 @@ instruct vsraa16B_imm(vecX dst, vecX src, immI shift) %{
 %}

 instruct vsraa4S_imm(vecD dst, vecD src, immI shift) %{
-  predicate(n->as_Vector()->length() == 4);
+  predicate(n->as_Vector()->length() == 2 || n->as_Vector()->length() == 4);
   match(Set dst (AddVS dst (RShiftVS src (RShiftCntV shift))));
   ins_cost(INSN_COST);
   format %{ "ssra    $dst, $src, $shift\t# vector (4H)" %}
@@ -18849,7 +18849,7 @@ instruct vsraa2L_imm(vecX dst, vecX src, immI shift) %{
 %}

 instruct vsrla8B_imm(vecD dst, vecD src, immI shift) %{
-  predicate(n->as_Vector()->length() == 8);
+  predicate(n->as_Vector()->length() == 4 || n->as_Vector()->length() == 8);
   match(Set dst (AddVB dst (URShiftVB src (RShiftCntV shift))));
   ins_cost(INSN_COST);
   format %{ "usra    $dst, $src, $shift\t# vector (8B)" %}
@@ -18879,7 +18879,7 @@ instruct vsrla16B_imm(vecX dst, vecX src, immI shift) %{
 %}

 instruct vsrla4S_imm(vecD dst, vecD src, immI shift) %{
-  predicate(n->as_Vector()->length() == 4);
+  predicate(n->as_Vector()->length() == 2 || n->as_Vector()->length() == 4);
   match(Set dst (AddVS dst (URShiftVS src (RShiftCntV shift))));
   ins_cost(INSN_COST);
   format %{ "usra    $dst, $src, $shift\t# vector (4H)" %}

How do you think if we do this modification together via this PR?

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

PR: https://git.openjdk.java.net/jdk16/pull/136

From shade at openjdk.java.net  Tue Feb  2 09:29:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 2 Feb 2021 09:29:53 GMT
Subject: RFR: 8260899: ARM32: SyncOnValueBasedClassTest fails with
 assert(is_valid()) failed: invalid register
Message-ID: <3kcU-WrscBpRvHSepNBZWu4CNsBaP6pdeYTyIUT2z1E=.180e2e1d-7dec-4c28-b9c4-058627b12419@github.com>

$ CONF=linux-arm-server-fastdebug make run-test TEST=runtime/Monitor/SyncOnValueBasedClassTest.java
...

#  Internal Error (/home/pi/jdk/src/hotspot/cpu/arm/register_arm.hpp:155), pid=3793, tid=3808
#  assert(is_valid()) failed: invalid register
#
# JRE version: OpenJDK Runtime Environment (17.0) (fastdebug build 17-internal+0-adhoc.pi.jdk)
# Java VM: OpenJDK Server VM (fastdebug 17-internal+0-adhoc.pi.jdk, compiled mode, emulated-client, g1 gc, linux-arm)
# Problematic frame:
# V  [libjvm.so+0xe1a6a8]  MacroAssembler::load_klass(RegisterImpl*, RegisterImpl*, AsmCondition)+0xa4

Current CompileTask:
C1:    318    2   !b        java.lang.Class::desiredAssertionStatus (54 bytes)

Stack: [0x72580000,0x72600000],  sp=0x725fe170,  free space=504k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xe1a6a8]  MacroAssembler::load_klass(RegisterImpl*, RegisterImpl*, AsmCondition)+0xa4
V  [libjvm.so+0x43b6b4]  C1_MacroAssembler::lock_object(RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, Label&)+0xcf8
V  [libjvm.so+0x3d731c]  LIR_Assembler::emit_lock(LIR_OpLock*)+0x160


The problem is in this code:

  if (DiagnoseSyncOnValueBasedClasses != 0) {
    load_klass(tmp1, obj); <--- asserts
    ldr_u32(tmp1, Address(tmp1, Klass::access_flags_offset()));
    tst(tmp1, JVM_ACC_IS_VALUE_BASED_CLASS);
    b(slow_case, ne);
  }

`tmp1` is `noreg` when `!BiasedLocking`, because `c1_LIRGenerator_arm.cpp` provides it only when `UseBiasedLocking` is enabled:

void LIRGenerator::do_MonitorEnter(MonitorEnter* x) {
  ...
  // Need a scratch register for biased locking on arm
  LIR_Opr scratch = LIR_OprFact::illegalOpr;
  if(UseBiasedLocking) {
    scratch = new_pointer_register();
  } else {
    scratch = atomicLockOpr(); // <--- actually illegalOpr
  }

  ...

  monitor_enter(obj.result(), lock, hdr, scratch,
                x->monitor_no(), info_for_exception, info);
}

The way out is to use `tmp2`, which is the alias for `Rtemp` and always available.

Additional testing:
 - [x] Linux ARM32 `SyncOnValueBasedClassTest`, `-XX:+UseBiasedLocking`
 - [x] Linux ARM32 `SyncOnValueBasedClassTest`, `-XX:-UseBiasedLocking`

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

Commit messages:
 - 8260899: ARM32: SyncOnValueBasedClassTest fails with assert(is_valid()) failed: invalid register

Changes: https://git.openjdk.java.net/jdk/pull/2349/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2349&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260899
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2349.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2349/head:pull/2349

PR: https://git.openjdk.java.net/jdk/pull/2349

From ningsheng.jian at arm.com  Tue Feb  2 10:53:34 2021
From: ningsheng.jian at arm.com (Ningsheng Jian)
Date: Tue, 2 Feb 2021 18:53:34 +0800
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <324d99d5-3fdb-084c-1ab8-4a2282aaa447@huawei.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
 <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
 <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>
 <AQEAN6KcNC9S4AHg2Voyu9SsUlNXDh5ThUDOailTFMA=.3b9c1a70-7436-4306-bc6d-a5e3d91f9166@github.com>
 <OrMeQJItXcusPEf031k8wbL5j74RbyynGSQ3HM-1S0E=.9d440961-d955-4935-9dd8-8621052d1a35@github.com>
 <6a306bd0-19a9-f8d2-a285-1239371f389e@redhat.com>
 <c922d3ba-40f1-447c-5cd4-daf1226719da@huawei.com>
 <bb6bb02c-50bf-9f6c-d268-260416ee64b0@redhat.com>
 <324d99d5-3fdb-084c-1ab8-4a2282aaa447@huawei.com>
Message-ID: <b731571c-d116-24b7-8ca3-4a359fd427cd@arm.com>

Hi,

On 2/1/21 10:35 PM, dongbo (E) wrote:
> 
> On 2021/2/1 20:32, Andrew Haley wrote:
>> On 2/1/21 8:11 AM, dongbo (E) wrote:
>>> The tests passed with the newest version and still can catch the typo.
>>> Also tested a few of injected errors, the tests failed as expected.
>> One oddity has come up.
>>
>> I'm running compiler/c2/TestShiftRightAndAccumulate
>> and the generated code I see for 
>> compiler.c2.TestShiftRightAndAccumulate::test_shorts
>>
>> No vector instructions here. As far as I can see vectors are never used
>> for jshort, just for jchar. All very strange, and probably not your 
>> fault,
>> but since I'm looking I had to mention it.
>>
>> The other weird thing is that {u,s}sra is never generated with the .8B 
>> form.
> 
> I guess the `usra` is not generated for `byte` and `short` because:
> ```
> src/hotspot/share/opto/vectornode.cpp, line 182:
>  ? case Op_URShiftI:
>  ??? switch (bt) {
>  ??? case T_BOOLEAN:return Op_URShiftVB;
>  ??? case T_CHAR:?? return Op_URShiftVS;
>  ??? case T_BYTE:
>  ??? case T_SHORT:? return 0; // Vector logical right shift for signed 
> short
>  ???????????????????????????? // values produces incorrect Java result for
>  ???????????????????????????? // negative data because java code should 
> convert
>  ???????????????????????????? // a short value into int value with sign
>  ???????????????????????????? // extension before a shift.
>  ??? case T_INT:??? return Op_URShiftVI;
>  ??? default:?????? ShouldNotReachHere(); return 0;
>  ??? }
> ```
> 

They can be used in vector api. E.g.

var vba = ByteVector.fromArray(ByteVector.SPECIES_PREFERRED, ba, i);
vba.add(vba.lanewise(VectorOperators.LSHR, 3)).intoArray(ba, i);

Thanks,
Ningsheng


From thartmann at openjdk.java.net  Tue Feb  2 11:44:58 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 11:44:58 GMT
Subject: RFR: 8260928: InitArrayShortSize constraint func should print a
 helpful error message
Message-ID: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>

The `InitArrayShortSize` flag requires a value that is a multiple of `BytesPerLong` but no corresponding error message is printed:
java -XX:InitArrayShortSize=7
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Thanks,
Tobias

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

Commit messages:
 - 8260928: InitArrayShortSize constraint func should print a helpful error message

Changes: https://git.openjdk.java.net/jdk/pull/2351/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2351&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260928
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2351.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2351/head:pull/2351

PR: https://git.openjdk.java.net/jdk/pull/2351

From njian at openjdk.java.net  Tue Feb  2 11:44:58 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Tue, 2 Feb 2021 11:44:58 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <LOvcOMFmNMY2HsSR7pkFajsVbF2ceR8Yr85qdbD1E-o=.c5998d49-d305-4f2b-add2-b79b9305de73@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <HvyAy7ZfnJLdl7NkO98VwCOX9Ju4zQiJZ7AV2lNznmQ=.20283243-c16f-4e56-8153-72702a818495@github.com>
 <DkxP64SKhG9uHwYwxLgC-xwmtfpDoqpaHSPMGw1Kz6w=.63f9c3d2-22c2-435c-8b95-e0171166854b@github.com>
 <LOvcOMFmNMY2HsSR7pkFajsVbF2ceR8Yr85qdbD1E-o=.c5998d49-d305-4f2b-add2-b79b9305de73@github.com>
Message-ID: <4KBCYEYrcTMEqEo89p3m4OfqSolqi2agyexH-k1vZrU=.813f7a97-b7ef-4cc0-809b-91e4c5f3c7fd@github.com>

On Tue, 2 Feb 2021 08:19:21 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> Because we only have predicate(n->as_Vector()->length() == 8) in vsraa8B_imm, so they are not matched.
> We should fix this with the following code:

I think this is an enhancement, and should be done in a separate patch in jdk mainline.

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

PR: https://git.openjdk.java.net/jdk16/pull/136

From vlivanov at openjdk.java.net  Tue Feb  2 11:45:43 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 2 Feb 2021 11:45:43 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <AGPNulG71oV0KAbLal6q7QtAD3p40phvXbPRAqBiu_w=.ddbd5b10-5b9a-49db-a644-5e6bf35ff5ee@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
 <AGPNulG71oV0KAbLal6q7QtAD3p40phvXbPRAqBiu_w=.ddbd5b10-5b9a-49db-a644-5e6bf35ff5ee@github.com>
Message-ID: <ca8onKO-F5Qypjy9fzY4ctcAaD2ual1-3C1EsBO-tIM=.c2e1e17a-5eea-409b-99d7-81bcae319851@github.com>

On Sun, 31 Jan 2021 21:29:40 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8260473
>> 
>> Function "PhaseVector::expand_vunbox_node" creates a LoadNode, but forgets to make the LoadNode to pass gc barriers.
>> 
>> Testing: all Vector API related tests have passed.
>> 
>> Original pr: https://github.com/openjdk/jdk/pull/2253
>
> Approved. 
> 
> Now awaiting release team approval.

> It will be only fixed in the jdk17, right?

Yes, I'm OK with that.

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

PR: https://git.openjdk.java.net/jdk16/pull/139

From shade at openjdk.java.net  Tue Feb  2 11:53:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 2 Feb 2021 11:53:45 GMT
Subject: RFR: 8260928: InitArrayShortSize constraint func should print a
 helpful error message
In-Reply-To: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>
References: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>
Message-ID: <1Jm-oUtc2u-utHK3mkc8rZ0wO8V1A58x_7HN4FsPj90=.a80551e9-6c1d-418a-8537-1eeec8b0c9ce@github.com>

On Tue, 2 Feb 2021 11:31:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The `InitArrayShortSize` flag requires a value that is a multiple of `BytesPerLong` but no corresponding error message is printed:
> java -XX:InitArrayShortSize=7
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> Thanks,
> Tobias

Looks fine to me.

Marked as reviewed by shade (Reviewer).

src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp line 307:

> 305:     JVMFlag::printError(verbose,
> 306:                        "InitArrayShortSize (" INTX_FORMAT ") must be "
> 307:                         "a multiple of %d\n", value, BytesPerLong);

Consider indenting them a bit. I think the line starting from `"a...` has one excess whitespace.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2351

From thartmann at openjdk.java.net  Tue Feb  2 12:10:56 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 12:10:56 GMT
Subject: RFR: 8260928: InitArrayShortSize constraint func should print a
 helpful error message [v2]
In-Reply-To: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>
References: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>
Message-ID: <D6CCSFbJDJbBniAQ86RWPuFuslK5B7KZ389jkXnK6zA=.c289bcba-e311-4769-896e-10cbb07abcde@github.com>

> The `InitArrayShortSize` flag requires a value that is a multiple of `BytesPerLong` but no corresponding error message is printed:
> java -XX:InitArrayShortSize=7
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Fixed intendation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2351/files
  - new: https://git.openjdk.java.net/jdk/pull/2351/files/92dd1316..bb87bdd8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2351&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2351&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2351.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2351/head:pull/2351

PR: https://git.openjdk.java.net/jdk/pull/2351

From thartmann at openjdk.java.net  Tue Feb  2 12:10:57 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 12:10:57 GMT
Subject: RFR: 8260928: InitArrayShortSize constraint func should print a
 helpful error message [v2]
In-Reply-To: <1Jm-oUtc2u-utHK3mkc8rZ0wO8V1A58x_7HN4FsPj90=.a80551e9-6c1d-418a-8537-1eeec8b0c9ce@github.com>
References: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>
 <1Jm-oUtc2u-utHK3mkc8rZ0wO8V1A58x_7HN4FsPj90=.a80551e9-6c1d-418a-8537-1eeec8b0c9ce@github.com>
Message-ID: <Bpe9glqp6eguC-20tJKvPOzI0Xb29kJ-V3zFtJzlWCI=.9835b9fb-1877-4dd6-b43b-b33243e4e434@github.com>

On Tue, 2 Feb 2021 11:50:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed intendation
>
> src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp line 307:
> 
>> 305:     JVMFlag::printError(verbose,
>> 306:                        "InitArrayShortSize (" INTX_FORMAT ") must be "
>> 307:                         "a multiple of %d\n", value, BytesPerLong);
> 
> Consider indenting them a bit. I think the line starting from `"a...` has one excess whitespace.

Good catch. Fixed. Thanks for the review!

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

PR: https://git.openjdk.java.net/jdk/pull/2351

From ogatak at openjdk.java.net  Tue Feb  2 12:45:03 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 2 Feb 2021 12:45:03 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v4]
In-Reply-To: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
Message-ID: <2CXH3zvUkBfqLrr8SPpD-x3RcSbFzw0S6NGLWgtirQ8=.0df1a0c8-3ac2-4e21-9e6a-f0b43a3ae20c@github.com>

> The POWER10 processor, which implements Power ISA 3.1 [1], supports new instruction formats where an instruction takes two 32bit words.  The first word is called prefix, and the instructions with prefix are called prefixed instructions.  With more bits in opcode and operand fields, POWER10 supports larger immediate value in an operand, as well as many new instructions.
> 
> This is the first changes to handle prefixed instructions, and this adds support of prefixed addi (= paddi) instruction as an example of prefix usage.  paddi accepts 34bit immediate value, while original addi accepts 16bit value.
> 
> [1] https://ibm.ent.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0

Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:

  Removed pla and psubi and adjusted spacing based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2095/files
  - new: https://git.openjdk.java.net/jdk/pull/2095/files/a8770539..9d606d67

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2095&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2095&range=02-03

  Stats: 23 lines in 3 files changed: 2 ins; 6 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2095.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2095/head:pull/2095

PR: https://git.openjdk.java.net/jdk/pull/2095

From ogatak at openjdk.java.net  Tue Feb  2 12:45:04 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Tue, 2 Feb 2021 12:45:04 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v3]
In-Reply-To: <LL-lHvcJnaBRj-glM0u759tBNQZsyp46zpInu-vC0iw=.9b413d6e-9cc3-4ee0-abb3-47f986de7e80@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <owXqOZWxdbUC-J5GxERy4zjPk5Ifb1xCsslCBqfxL_Y=.08191ff0-a579-4267-b033-2bf3e5de6752@github.com>
 <LL-lHvcJnaBRj-glM0u759tBNQZsyp46zpInu-vC0iw=.9b413d6e-9cc3-4ee0-abb3-47f986de7e80@github.com>
Message-ID: <2gvv0ZqsA7SbK0VL5OScVLHNxicDeD153h42QOrR-wk=.46adcc11-2808-4d1f-88f1-3848a8162fbe@github.com>

On Mon, 1 Feb 2021 18:49:20 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update (2nd round) based on review comments
>
> Just a few more minor things... several defined-but-not-used functions, and some little formatting issues.

@CoreyAshford Thank you for your review.  I went through my  changes to check spacing, as well as removed unused pla and psubi as you pointed out.

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

PR: https://git.openjdk.java.net/jdk/pull/2095

From chagedorn at openjdk.java.net  Tue Feb  2 13:26:42 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 2 Feb 2021 13:26:42 GMT
Subject: RFR: 8260928: InitArrayShortSize constraint func should print a
 helpful error message [v2]
In-Reply-To: <D6CCSFbJDJbBniAQ86RWPuFuslK5B7KZ389jkXnK6zA=.c289bcba-e311-4769-896e-10cbb07abcde@github.com>
References: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>
 <D6CCSFbJDJbBniAQ86RWPuFuslK5B7KZ389jkXnK6zA=.c289bcba-e311-4769-896e-10cbb07abcde@github.com>
Message-ID: <19kujjbusieRxoz19CY4GCh0HORyefuHk6uBILYsUcM=.7c0ee83a-9a49-465f-a575-0b3eb010ba6c@github.com>

On Tue, 2 Feb 2021 12:10:56 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The `InitArrayShortSize` flag requires a value that is a multiple of `BytesPerLong` but no corresponding error message is printed:
>> java -XX:InitArrayShortSize=7
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed intendation

Looks good.

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2351

From thartmann at openjdk.java.net  Tue Feb  2 13:39:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 13:39:42 GMT
Subject: RFR: 8260928: InitArrayShortSize constraint func should print a
 helpful error message [v2]
In-Reply-To: <19kujjbusieRxoz19CY4GCh0HORyefuHk6uBILYsUcM=.7c0ee83a-9a49-465f-a575-0b3eb010ba6c@github.com>
References: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>
 <D6CCSFbJDJbBniAQ86RWPuFuslK5B7KZ389jkXnK6zA=.c289bcba-e311-4769-896e-10cbb07abcde@github.com>
 <19kujjbusieRxoz19CY4GCh0HORyefuHk6uBILYsUcM=.7c0ee83a-9a49-465f-a575-0b3eb010ba6c@github.com>
Message-ID: <qj2vVOGkRYm84FqmX-EwMuCDho5JAb9rICJDVm1-Dyw=.3b65117b-6692-4338-9a37-26436a9bd166@github.com>

On Tue, 2 Feb 2021 13:24:21 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed intendation
>
> Looks good.

Thanks for the review, Christian!

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

PR: https://git.openjdk.java.net/jdk/pull/2351

From dongbo4 at huawei.com  Tue Feb  2 14:05:34 2021
From: dongbo4 at huawei.com (dongbo (E))
Date: Tue, 2 Feb 2021 22:05:34 +0800
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <b731571c-d116-24b7-8ca3-4a359fd427cd@arm.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <gkYDr4l-AQBjXzC3Te7uQhPj9obSHmknNeZm-8BRKfk=.4df1dab4-cc3a-45f3-a4d9-160e72088553@github.com>
 <hNpWahWQY5FuYv1v768j0T8PQICpq6SDRiahJP41IfY=.a5f4f53e-6476-4879-9e54-53a63e796cfc@github.com>
 <dcfzzX2_xV6ZrSLkIZdJoL03fj1_BeO6CrIk-f-XZ0w=.b8a4f4f6-094a-475f-9ee8-ccd491ec9042@github.com>
 <AQEAN6KcNC9S4AHg2Voyu9SsUlNXDh5ThUDOailTFMA=.3b9c1a70-7436-4306-bc6d-a5e3d91f9166@github.com>
 <OrMeQJItXcusPEf031k8wbL5j74RbyynGSQ3HM-1S0E=.9d440961-d955-4935-9dd8-8621052d1a35@github.com>
 <6a306bd0-19a9-f8d2-a285-1239371f389e@redhat.com>
 <c922d3ba-40f1-447c-5cd4-daf1226719da@huawei.com>
 <bb6bb02c-50bf-9f6c-d268-260416ee64b0@redhat.com>
 <324d99d5-3fdb-084c-1ab8-4a2282aaa447@huawei.com>
 <b731571c-d116-24b7-8ca3-4a359fd427cd@arm.com>
Message-ID: <7a52499a-eacc-f5ad-c573-15a1ea3101b4@huawei.com>

On 2021/2/2 18:53, Ningsheng Jian wrote:
> Hi,
>
> On 2/1/21 10:35 PM, dongbo (E) wrote:
>>
>> On 2021/2/1 20:32, Andrew Haley wrote:
>>> On 2/1/21 8:11 AM, dongbo (E) wrote:
>>>> The tests passed with the newest version and still can catch the typo.
>>>> Also tested a few of injected errors, the tests failed as expected.
>>> One oddity has come up.
>>>
>>> I'm running compiler/c2/TestShiftRightAndAccumulate
>>> and the generated code I see for 
>>> compiler.c2.TestShiftRightAndAccumulate::test_shorts
>>>
>>> No vector instructions here. As far as I can see vectors are never used
>>> for jshort, just for jchar. All very strange, and probably not your 
>>> fault,
>>> but since I'm looking I had to mention it.
>>>
>>> The other weird thing is that {u,s}sra is never generated with the 
>>> .8B form.
>>
>> I guess the `usra` is not generated for `byte` and `short` because:
>> ```
>> src/hotspot/share/opto/vectornode.cpp, line 182:
>> ?? case Op_URShiftI:
>> ???? switch (bt) {
>> ???? case T_BOOLEAN:return Op_URShiftVB;
>> ???? case T_CHAR:?? return Op_URShiftVS;
>> ???? case T_BYTE:
>> ???? case T_SHORT:? return 0; // Vector logical right shift for 
>> signed short
>> ????????????????????????????? // values produces incorrect Java 
>> result for
>> ????????????????????????????? // negative data because java code 
>> should convert
>> ????????????????????????????? // a short value into int value with sign
>> ????????????????????????????? // extension before a shift.
>> ???? case T_INT:??? return Op_URShiftVI;
>> ???? default:?????? ShouldNotReachHere(); return 0;
>> ???? }
>> ```
>>
>
> They can be used in vector api. E.g.
>
> var vba = ByteVector.fromArray(ByteVector.SPECIES_PREFERRED, ba, i);
> vba.add(vba.lanewise(VectorOperators.LSHR, 3)).intoArray(ba, i);
>
> Thanks,
> Ningsheng
>
I ran local tests with the code you mentioned, it does use the unsigned 
shift for byte and short.

Thank you.



From roland at openjdk.java.net  Tue Feb  2 14:58:03 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 2 Feb 2021 14:58:03 GMT
Subject: [jdk16] RFR: 8260709: C2: assert(false) failed: unscheduable graph
Message-ID: <idSFSTp4bGL2c4znWfecVpXWSAzvXDir_gtEdF5Mvnk=.32bb33e0-5aca-48b6-84a2-75ad293f4c4c@github.com>

The v = field load in the test case is found anti-dependent with the
memory phi that merges the exception state of the 2 array
allocation. Since JDK-8258393, anti-dependence computation only
considers the Phi inputs that are reachable from the memory input of a
load. As a consequence, the late control for the load is the control
projection of the array allocation in the loop. When loop opts run,
PhaseIdealLoop::split_if_with_blocks_post() finds that the load's late
control is different from its current control (which is inside the
outer loop). It tries to sink the load out of loop but ends up pinning
it at its late control, the projection of the second AllocateNode.

The logic that expands the AllocateNode doesn't expect a pinned node
on the control projection and the result is a broken graph. I think
the fix for this would be to clone the load along both the exception
and the fallthrough paths. But as noted in JDK-8252372, the whole
process of sinking loads out of loops doesn't seem to work as expected
(for instance in this case it sinks the load from the outer loop into
the inner loop). So instead of going with a complicated fix, I propose
simply to detect this corner and that no attempt be made to sink the
load. Note that the current logic computes the late control for the
load (which should be in the loop), will create a clone for each use
and assign the dom_lca of the use's control and the load late control
to that use, that is the load late control. So all uses end up at the
same location, the load late control. So to detect that case, it's
sufficient to test the load late control.

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

Commit messages:
 - test & fix

Changes: https://git.openjdk.java.net/jdk16/pull/144/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=144&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260709
  Stats: 70 lines in 3 files changed: 69 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/144.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/144/head:pull/144

PR: https://git.openjdk.java.net/jdk16/pull/144

From neliasso at openjdk.java.net  Tue Feb  2 22:06:53 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 2 Feb 2021 22:06:53 GMT
Subject: RFR: 8258799 : [Testbug] RandomCommandsTest must check if tested
 directive is added via jcmd
Message-ID: <oNE9DgoOhpHAqiZwsEiU6Qfxv4At7gvMVieXC2g8_7E=.905ad208-b7ad-4820-94b3-fcebb9850bf9@github.com>

RandomCommandsTest.java is checking a mix of valid and invalid compilecommands and compiler directives. When they fail they have different behaviour:

A compilecommand that is malformed will result in a printed error, and then the VM continues. 
A compiler directive that is malformed, that is added via commandline, will abort the VM, much like any other VM-flag would. 
A compiler directive that is malformed, that is added via jcmd will print an error, and the VM continues - just like with any other jcmd.

The RandomCommandsTest fails when generating a malformed compiler directive and adding it via jcmd - because it expects the VM to abort.

This patch fixes that.

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

Commit messages:
 - fix whitespace
 - remove tabs
 - Check if directive added via jcmd is valid

Changes: https://git.openjdk.java.net/jdk/pull/2364/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2364&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258799
  Stats: 19 lines in 2 files changed: 16 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2364/head:pull/2364

PR: https://git.openjdk.java.net/jdk/pull/2364

From kvn at openjdk.java.net  Tue Feb  2 22:31:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 2 Feb 2021 22:31:46 GMT
Subject: RFR: 8258799 : [Testbug] RandomCommandsTest must check if tested
 directive is added via jcmd
In-Reply-To: <oNE9DgoOhpHAqiZwsEiU6Qfxv4At7gvMVieXC2g8_7E=.905ad208-b7ad-4820-94b3-fcebb9850bf9@github.com>
References: <oNE9DgoOhpHAqiZwsEiU6Qfxv4At7gvMVieXC2g8_7E=.905ad208-b7ad-4820-94b3-fcebb9850bf9@github.com>
Message-ID: <1dZCUYqdkzHmU2Bsz0c8Oxq8UPw_E9GBX6JvdOVeG6k=.f32f8e34-35ae-45b6-af15-d8be4cdefe77@github.com>

On Tue, 2 Feb 2021 21:55:17 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> RandomCommandsTest.java is checking a mix of valid and invalid compilecommands and compiler directives. When they fail they have different behaviour:
> 
> A compilecommand that is malformed will result in a printed error, and then the VM continues. 
> A compiler directive that is malformed, that is added via commandline, will abort the VM, much like any other VM-flag would. 
> A compiler directive that is malformed, that is added via jcmd will print an error, and the VM continues - just like with any other jcmd.
> 
> The RandomCommandsTest fails when generating a malformed compiler directive and adding it via jcmd - because it expects the VM to abort.
> 
> This patch fixes that.

Looks good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2364

From iignatyev at openjdk.java.net  Tue Feb  2 23:00:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 2 Feb 2021 23:00:48 GMT
Subject: RFR: 8258799 : [Testbug] RandomCommandsTest must check if tested
 directive is added via jcmd
In-Reply-To: <oNE9DgoOhpHAqiZwsEiU6Qfxv4At7gvMVieXC2g8_7E=.905ad208-b7ad-4820-94b3-fcebb9850bf9@github.com>
References: <oNE9DgoOhpHAqiZwsEiU6Qfxv4At7gvMVieXC2g8_7E=.905ad208-b7ad-4820-94b3-fcebb9850bf9@github.com>
Message-ID: <ipYn9MGeaY5Yrg_WgTNtnaaMuOyPXo_pqyntXZsDIY0=.8d1fe338-7558-4b48-b567-d07d80b953a7@github.com>

On Tue, 2 Feb 2021 21:55:17 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> RandomCommandsTest.java is checking a mix of valid and invalid compilecommands and compiler directives. When they fail they have different behaviour:
> 
> A compilecommand that is malformed will result in a printed error, and then the VM continues. 
> A compiler directive that is malformed, that is added via commandline, will abort the VM, much like any other VM-flag would. 
> A compiler directive that is malformed, that is added via jcmd will print an error, and the VM continues - just like with any other jcmd.
> 
> The RandomCommandsTest fails when generating a malformed compiler directive and adding it via jcmd - because it expects the VM to abort.
> 
> This patch fixes that.

Marked as reviewed by iignatyev (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2364

From dongbo at openjdk.java.net  Wed Feb  3 02:04:03 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 3 Feb 2021 02:04:03 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v7]
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <Ft8meJwlUEk8U15Em2tv0X-AecHSZvQAKwShzW4dNGQ=.8444df13-169a-4d46-a377-b7cee6442985@github.com>

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  match ssra with 8B

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/136/files
  - new: https://git.openjdk.java.net/jdk16/pull/136/files/693f8cbd..9e71e0f5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=136&range=05-06

  Stats: 32 lines in 1 file changed: 15 ins; 9 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/136/head:pull/136

PR: https://git.openjdk.java.net/jdk16/pull/136

From dongbo at openjdk.java.net  Wed Feb  3 02:04:03 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 3 Feb 2021 02:04:03 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <4KBCYEYrcTMEqEo89p3m4OfqSolqi2agyexH-k1vZrU=.813f7a97-b7ef-4cc0-809b-91e4c5f3c7fd@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <HvyAy7ZfnJLdl7NkO98VwCOX9Ju4zQiJZ7AV2lNznmQ=.20283243-c16f-4e56-8153-72702a818495@github.com>
 <DkxP64SKhG9uHwYwxLgC-xwmtfpDoqpaHSPMGw1Kz6w=.63f9c3d2-22c2-435c-8b95-e0171166854b@github.com>
 <LOvcOMFmNMY2HsSR7pkFajsVbF2ceR8Yr85qdbD1E-o=.c5998d49-d305-4f2b-add2-b79b9305de73@github.com>
 <4KBCYEYrcTMEqEo89p3m4OfqSolqi2agyexH-k1vZrU=.813f7a97-b7ef-4cc0-809b-91e4c5f3c7fd@github.com>
Message-ID: <htelF4oZzzSSUFbPucIV1s-7XZ-E4hjGTfHZwng1nXg=.cf328270-cbf0-4ced-8a9f-72b1e5c06c85@github.com>

On Tue, 2 Feb 2021 11:04:24 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> > Because we only have predicate(n->as_Vector()->length() == 8) in vsraa8B_imm, so they are not matched.
> > We should fix this with the following code:
> 
> I think this is an enhancement, and should be done in a separate patch in jdk mainline.

OK, I update a test with loop size 80 for bytes so that `ssra` for 8B can be matched now.

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

PR: https://git.openjdk.java.net/jdk16/pull/136

From dongbo at openjdk.java.net  Wed Feb  3 02:20:51 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 3 Feb 2021 02:20:51 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v3]
In-Reply-To: <htelF4oZzzSSUFbPucIV1s-7XZ-E4hjGTfHZwng1nXg=.cf328270-cbf0-4ced-8a9f-72b1e5c06c85@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <HvyAy7ZfnJLdl7NkO98VwCOX9Ju4zQiJZ7AV2lNznmQ=.20283243-c16f-4e56-8153-72702a818495@github.com>
 <DkxP64SKhG9uHwYwxLgC-xwmtfpDoqpaHSPMGw1Kz6w=.63f9c3d2-22c2-435c-8b95-e0171166854b@github.com>
 <LOvcOMFmNMY2HsSR7pkFajsVbF2ceR8Yr85qdbD1E-o=.c5998d49-d305-4f2b-add2-b79b9305de73@github.com>
 <4KBCYEYrcTMEqEo89p3m4OfqSolqi2agyexH-k1vZrU=.813f7a97-b7ef-4cc0-809b-91e4c5f3c7fd@github.com>
 <htelF4oZzzSSUFbPucIV1s-7XZ-E4hjGTfHZwng1nXg=.cf328270-cbf0-4ced-8a9f-72b1e5c06c85@github.com>
Message-ID: <FA35IUgZB7INAehmBDxCkxpoBcnIFPKTuqRtIcT-Va0=.23d20dde-60e6-4cee-ab76-bd1d97277337@github.com>

On Wed, 3 Feb 2021 01:59:38 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>>> Because we only have predicate(n->as_Vector()->length() == 8) in vsraa8B_imm, so they are not matched.
>>> We should fix this with the following code:
>> 
>> I think this is an enhancement, and should be done in a separate patch in jdk mainline.
>
>> > Because we only have predicate(n->as_Vector()->length() == 8) in vsraa8B_imm, so they are not matched.
>> > We should fix this with the following code:
>> 
>> I think this is an enhancement, and should be done in a separate patch in jdk mainline.
> 
> OK, I update a test with loop size 80 for bytes so that `ssra` for 8B can be matched now.

Ping... Can I get a review for the newest changes? Please let me know if we are ready to go.

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

PR: https://git.openjdk.java.net/jdk16/pull/136

From dlong at openjdk.java.net  Wed Feb  3 03:17:41 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 3 Feb 2021 03:17:41 GMT
Subject: RFR: 8260301: misc gc/g1/unloading tests fails with
 "RuntimeException: Method could not be enqueued for compilation at level N"
In-Reply-To: <sDxa_4hC7Snidwr3uaQ2YsIzMzIG5x7K2L1VnIE8TyU=.6d777a20-0159-494d-8c55-dbf10ab22cbf@github.com>
References: <sDxa_4hC7Snidwr3uaQ2YsIzMzIG5x7K2L1VnIE8TyU=.6d777a20-0159-494d-8c55-dbf10ab22cbf@github.com>
Message-ID: <DNHanOZf82Ky02T_FqECKah7RPDgHREfFUU_PN59EY4=.e77d88dc-dee3-4b9e-b1f8-e0f335e37326@github.com>

On Tue, 2 Feb 2021 15:44:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> On return WB wait to acquire Compile_lock before checking compilation status
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/whitebox.cpp#L988 
> 
> This lock is used by ciEnv for compiled code publishing:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciEnv.cpp#L981
> 
> So while WB waits the lock compiler thread can finish compilation, register nmethod and clear method's queued_for_compilation bit.
> 
> The problem is that WB check `nm` value (compiled code) which it got before the lock and when method compilation is not finished.
> 
> The fix is to check compiled code again similar to check in CompileBroker:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L1501 
> 
> Passed hs-tier1-4 testing and 100 x vmTestbase/gc/g1/unloading/tests/unloading_compilation_*.

Looks good.

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

Marked as reviewed by dlong (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2356

From serb at openjdk.java.net  Wed Feb  3 04:13:52 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Feb 2021 04:13:52 GMT
Subject: RFR: 8261010: Delete the Netbeans "default" license header
Message-ID: <zfSI9-g2hnFktpcaiOMCPnoIZ-l3Xn7gojA238J3ZFs=.25f4a0c3-30b1-4bfd-acd7-abd17cc5345c@github.com>

Trivial cleanup, the "default" license header is removed in a few components.

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

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/2368/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2368&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261010
  Stats: 14 lines in 3 files changed: 0 ins; 14 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2368.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2368/head:pull/2368

PR: https://git.openjdk.java.net/jdk/pull/2368

From iris at openjdk.java.net  Wed Feb  3 04:22:41 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 3 Feb 2021 04:22:41 GMT
Subject: RFR: 8261010: Delete the Netbeans "default" license header
In-Reply-To: <zfSI9-g2hnFktpcaiOMCPnoIZ-l3Xn7gojA238J3ZFs=.25f4a0c3-30b1-4bfd-acd7-abd17cc5345c@github.com>
References: <zfSI9-g2hnFktpcaiOMCPnoIZ-l3Xn7gojA238J3ZFs=.25f4a0c3-30b1-4bfd-acd7-abd17cc5345c@github.com>
Message-ID: <g0qUXojSoWFBhKzUNkEyjhPM5cgdzg6c9YaLbZrL2Q0=.4785ea39-a6f1-4e66-bb19-d9d7fb82e606@github.com>

On Wed, 3 Feb 2021 04:01:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Trivial cleanup, the "default" license header is removed in a few components.

Trivial removal of template instructions.

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2368

From psadhukhan at openjdk.java.net  Wed Feb  3 04:41:40 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 3 Feb 2021 04:41:40 GMT
Subject: RFR: 8261010: Delete the Netbeans "default" license header
In-Reply-To: <zfSI9-g2hnFktpcaiOMCPnoIZ-l3Xn7gojA238J3ZFs=.25f4a0c3-30b1-4bfd-acd7-abd17cc5345c@github.com>
References: <zfSI9-g2hnFktpcaiOMCPnoIZ-l3Xn7gojA238J3ZFs=.25f4a0c3-30b1-4bfd-acd7-abd17cc5345c@github.com>
Message-ID: <CVxwVfPVdVIr-vU9r0-T-H4kPuiiWCXN4lSYn4N1Bxs=.5be72b62-ab2e-4269-95c6-bbb749942cc7@github.com>

On Wed, 3 Feb 2021 04:01:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Trivial cleanup, the "default" license header is removed in a few components.

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2368

From iignatyev at openjdk.java.net  Wed Feb  3 05:42:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 3 Feb 2021 05:42:52 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
Message-ID: <0M7K991qRJQOhQfLlm--GlAwOzO8I77h51gWG4Frk28=.73b8361c-1673-4a09-8e08-7752a3ba5363@github.com>

On Wed, 27 Jan 2021 08:07:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I noticed that the SA's dumpreplaydata command fails with:
>> 
>> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
>> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
>> 
>> with a simple test program. This happens because the SA can't find the
>> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
>> there's nothing in our build system that hides that symbol. I had to
>> move one method's definition from the header file to the cpp file for
>> the symbol to be visible again.
>> 
>> We have a test that checks dumpreplaydata but it doesn't catch that
>> problem. The test produces a replay file from a core file with the SA
>> by running a simple test with -Xcomp and CICrash=1. So the replay data
>> has very little or no profile data (which is what causes the problem
>> above). I propose running a slightly more complicated test method and
>> crashing after the method has had time to run for long enough to
>> collect profile data.
>> 
>> The other shortcoming of the test is that it doesn't look at the
>> content of the replay file. It only warns if they differ. The replay
>> file produced by the VM and the one produced by the SA should be
>> identical (except for comment lines). So I propose we check that.
>> 
>> Finally, I can't run that test on my system because core files are
>> handled by systemd (I'm running some recent version of fedora). I
>> suppose, the system can be configured differently but having the test
>> work out the box is nice. I extended the test case to handle that.
>> 
>> With the improved test, there are a few differences between the VM and
>> SA replay files caused by VM changes that were not mirrored in the
>> SA. I fixed those.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - convert all tests
>  - Merge branch 'master' into JDK-8260296
>  - use CoreUtils
>  - whitespaces
>  - SA fixes
>  - VM fix
>  - test

test/lib/jdk/test/lib/util/CoreUtils.java line 166:

> 164:                                 for (int i = 0; i < 10; i++) {
> 165:                                     Thread.sleep(5000);
> 166:                                     OutputAnalyzer out = ProcessTools.executeProcess("coredumpctl", "dump",  "-1",  "-o", core, Long.valueOf(pid).toString());

you can use `String::valueOf` to a string represenatation of `long`:
Suggestion:

                                    OutputAnalyzer out = ProcessTools.executeProcess("coredumpctl", "dump",  "-1",  "-o", core, String.valueOf(pid));

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

PR: https://git.openjdk.java.net/jdk/pull/2195

From iignatyev at openjdk.java.net  Wed Feb  3 05:57:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 3 Feb 2021 05:57:48 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
Message-ID: <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>

On Wed, 27 Jan 2021 08:07:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I noticed that the SA's dumpreplaydata command fails with:
>> 
>> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
>> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
>> 
>> with a simple test program. This happens because the SA can't find the
>> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
>> there's nothing in our build system that hides that symbol. I had to
>> move one method's definition from the header file to the cpp file for
>> the symbol to be visible again.
>> 
>> We have a test that checks dumpreplaydata but it doesn't catch that
>> problem. The test produces a replay file from a core file with the SA
>> by running a simple test with -Xcomp and CICrash=1. So the replay data
>> has very little or no profile data (which is what causes the problem
>> above). I propose running a slightly more complicated test method and
>> crashing after the method has had time to run for long enough to
>> collect profile data.
>> 
>> The other shortcoming of the test is that it doesn't look at the
>> content of the replay file. It only warns if they differ. The replay
>> file produced by the VM and the one produced by the SA should be
>> identical (except for comment lines). So I propose we check that.
>> 
>> Finally, I can't run that test on my system because core files are
>> handled by systemd (I'm running some recent version of fedora). I
>> suppose, the system can be configured differently but having the test
>> work out the box is nice. I extended the test case to handle that.
>> 
>> With the improved test, there are a few differences between the VM and
>> SA replay files caused by VM changes that were not mirrored in the
>> SA. I fixed those.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - convert all tests
>  - Merge branch 'master' into JDK-8260296
>  - use CoreUtils
>  - whitespaces
>  - SA fixes
>  - VM fix
>  - test

a few more nits

test/lib/jdk/test/lib/process/ProcessTools.java line 461:

> 459:     }
> 460: 
> 461:     static public class OutputAnalyzerAndPID {

Suggestion:

    public static class OutputAnalyzerAndPID {

test/lib/jdk/test/lib/process/ProcessTools.java line 461:

> 459:     }
> 460: 
> 461:     static public class OutputAnalyzerAndPID {

can we either change `OutputAnalyzer` to store pid (and use -1 for cases when there is no one) or make `OutputAnalyzer` non-final and have `OutputAnalyzerAndPID` extending `OutputAnalyzer`?

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

Changes requested by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2195

From kvn at openjdk.java.net  Wed Feb  3 07:19:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 3 Feb 2021 07:19:39 GMT
Subject: RFR: 8260301: misc gc/g1/unloading tests fails with
 "RuntimeException: Method could not be enqueued for compilation at level N"
In-Reply-To: <DNHanOZf82Ky02T_FqECKah7RPDgHREfFUU_PN59EY4=.e77d88dc-dee3-4b9e-b1f8-e0f335e37326@github.com>
References: <sDxa_4hC7Snidwr3uaQ2YsIzMzIG5x7K2L1VnIE8TyU=.6d777a20-0159-494d-8c55-dbf10ab22cbf@github.com>
 <DNHanOZf82Ky02T_FqECKah7RPDgHREfFUU_PN59EY4=.e77d88dc-dee3-4b9e-b1f8-e0f335e37326@github.com>
Message-ID: <E75UpF1Py-ODiu4LWsVA9asUOKuvwV2ld7QjvhKv-3k=.7a49cab8-ee76-4e77-adc5-adcddbffffc2@github.com>

On Wed, 3 Feb 2021 03:15:16 GMT, Dean Long <dlong at openjdk.org> wrote:

>> On return WB wait to acquire Compile_lock before checking compilation status
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/whitebox.cpp#L988 
>> 
>> This lock is used by ciEnv for compiled code publishing:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciEnv.cpp#L981
>> 
>> So while WB waits the lock compiler thread can finish compilation, register nmethod and clear method's queued_for_compilation bit.
>> 
>> The problem is that WB check `nm` value (compiled code) which it got before the lock and when method compilation is not finished.
>> 
>> The fix is to check compiled code again similar to check in CompileBroker:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L1501 
>> 
>> Passed hs-tier1-4 testing and 100 x vmTestbase/gc/g1/unloading/tests/unloading_compilation_*.
>
> Looks good.

Thank you, Dean

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

PR: https://git.openjdk.java.net/jdk/pull/2356

From chagedorn at openjdk.java.net  Wed Feb  3 07:37:57 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 3 Feb 2021 07:37:57 GMT
Subject: RFR: 8260581: IGV: enhance node search [v4]
In-Reply-To: <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>
Message-ID: <GMUoMZhIdVyNIatNQoP3Gvp0mVL04r8jksT_8A5-IfU=.291100b0-73bb-43c5-b0ae-0d7dc6f0944b@github.com>

On Mon, 1 Feb 2021 11:34:59 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Apply several enhancements to the quick node search functionality: 
>> 
>> - Allow users to search by node id or name by default (i.e. when no property is specified) instead of name only.
>> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
>> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
>> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. Numeric matches with the same rank are sorted increasingly. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>>     1. **5** AddI
>>     2. **5**54 MulI
>>     3. 2**5** AddL
>>     4. 2**5**3 AddL
>> 
>> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
>> 
>> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
>> 
>> and after:
>> 
>> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
>> 
>> 
>> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
>> 
>> As part of the review, please evaluate not just the code changes but also the usability.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort same-rank matches by first-word numeric value
>   
>   Sort otherwise equally relevant matches by node id, which is by default the
>   first word in node labels. Thanks to Christian Hagedorn for the suggestion and
>   (slightly adapted) patch.

Marked as reviewed by chagedorn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2285

From neliasso at openjdk.java.net  Wed Feb  3 08:06:54 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 3 Feb 2021 08:06:54 GMT
Subject: RFR: 8258799 : [Testbug] RandomCommandsTest must check if tested
 directive is added via jcmd
In-Reply-To: <ipYn9MGeaY5Yrg_WgTNtnaaMuOyPXo_pqyntXZsDIY0=.8d1fe338-7558-4b48-b567-d07d80b953a7@github.com>
References: <oNE9DgoOhpHAqiZwsEiU6Qfxv4At7gvMVieXC2g8_7E=.905ad208-b7ad-4820-94b3-fcebb9850bf9@github.com>
 <ipYn9MGeaY5Yrg_WgTNtnaaMuOyPXo_pqyntXZsDIY0=.8d1fe338-7558-4b48-b567-d07d80b953a7@github.com>
Message-ID: <yInDW4w-_d-t3cizPS7SRQnV8vfdrZI3F_HOllrkUPQ=.3129a6b0-3f0c-4cf1-8118-93ac3fb7b099@github.com>

On Tue, 2 Feb 2021 22:58:19 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> RandomCommandsTest.java is checking a mix of valid and invalid compilecommands and compiler directives. When they fail they have different behaviour:
>> 
>> A compilecommand that is malformed will result in a printed error, and then the VM continues. 
>> A compiler directive that is malformed, that is added via commandline, will abort the VM, much like any other VM-flag would. 
>> A compiler directive that is malformed, that is added via jcmd will print an error, and the VM continues - just like with any other jcmd.
>> 
>> The RandomCommandsTest fails when generating a malformed compiler directive and adding it via jcmd - because it expects the VM to abort.
>> 
>> This patch fixes that.
>
> Marked as reviewed by iignatyev (Reviewer).

Thank you Igor and Vladimir!

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

PR: https://git.openjdk.java.net/jdk/pull/2364

From thartmann at openjdk.java.net  Wed Feb  3 08:13:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 3 Feb 2021 08:13:42 GMT
Subject: Integrated: 8260928: InitArrayShortSize constraint func should print
 a helpful error message
In-Reply-To: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>
References: <oCSNJn3fir2Za2J9EUzpPiKn6q8d7eneVfa-8JkTZ1k=.e4420916-527f-40df-8807-e3df4b21b0fd@github.com>
Message-ID: <dsQ7hfRA6LHhmMk383KVGIhtMLRNPgk0Jdq0HWsSTz0=.677d010d-1f1e-4587-b110-afed10667442@github.com>

On Tue, 2 Feb 2021 11:31:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The `InitArrayShortSize` flag requires a value that is a multiple of `BytesPerLong` but no corresponding error message is printed:
> java -XX:InitArrayShortSize=7
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 91e6c755
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/91e6c755
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8260928: InitArrayShortSize constraint func should print a helpful error message

Reviewed-by: shade, chagedorn

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

PR: https://git.openjdk.java.net/jdk/pull/2351

From thartmann at openjdk.java.net  Wed Feb  3 08:28:53 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 3 Feb 2021 08:28:53 GMT
Subject: [jdk16] RFR: 8260709: C2: assert(false) failed: unscheduable graph
In-Reply-To: <idSFSTp4bGL2c4znWfecVpXWSAzvXDir_gtEdF5Mvnk=.32bb33e0-5aca-48b6-84a2-75ad293f4c4c@github.com>
References: <idSFSTp4bGL2c4znWfecVpXWSAzvXDir_gtEdF5Mvnk=.32bb33e0-5aca-48b6-84a2-75ad293f4c4c@github.com>
Message-ID: <rUiJyg0nMW1iXUwoYnIIA5q_J-AjP-vsOsjidt0loJE=.418b8a6f-33ef-4545-82e1-adf4d50ea81e@github.com>

On Tue, 2 Feb 2021 14:53:15 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The v = field load in the test case is found anti-dependent with the
> memory phi that merges the exception state of the 2 array
> allocation. Since JDK-8258393, anti-dependence computation only
> considers the Phi inputs that are reachable from the memory input of a
> load. As a consequence, the late control for the load is the control
> projection of the array allocation in the loop. When loop opts run,
> PhaseIdealLoop::split_if_with_blocks_post() finds that the load's late
> control is different from its current control (which is inside the
> outer loop). It tries to sink the load out of loop but ends up pinning
> it at its late control, the projection of the second AllocateNode.
> 
> The logic that expands the AllocateNode doesn't expect a pinned node
> on the control projection and the result is a broken graph. I think
> the fix for this would be to clone the load along both the exception
> and the fallthrough paths. But as noted in JDK-8252372, the whole
> process of sinking loads out of loops doesn't seem to work as expected
> (for instance in this case it sinks the load from the outer loop into
> the inner loop). So instead of going with a complicated fix, I propose
> simply to detect this corner and that no attempt be made to sink the
> load. Note that the current logic computes the late control for the
> load (which should be in the loop), will create a clone for each use
> and assign the dom_lca of the use's control and the load late control
> to that use, that is the load late control. So all uses end up at the
> same location, the load late control. So to detect that case, it's
> sufficient to test the load late control.

This looks reasonable to me as a point fix for JDK 16, given the plan is to rework that code for JDK 17 with [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/144

From aph at openjdk.java.net  Wed Feb  3 09:10:47 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 3 Feb 2021 09:10:47 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v7]
In-Reply-To: <Ft8meJwlUEk8U15Em2tv0X-AecHSZvQAKwShzW4dNGQ=.8444df13-169a-4d46-a377-b7cee6442985@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <Ft8meJwlUEk8U15Em2tv0X-AecHSZvQAKwShzW4dNGQ=.8444df13-169a-4d46-a377-b7cee6442985@github.com>
Message-ID: <YjF-cfwEbmcCd8ov07dQ_qN5XTeBTnoQYuDH2tvu3IU=.d95a8139-fef8-4f5e-b3dd-536fada8e624@github.com>

On Wed, 3 Feb 2021 02:04:03 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> This is a typo introduced by JDK-8255949.
>> Compiler will generate `ushr` for shifting right and accumulating four short integers.
>> It produces wrong results for specific case. The instruction should be `usra`.
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   match ssra with 8B

OK, thanks.

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

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/136

From dongbo at openjdk.java.net  Wed Feb  3 09:31:45 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 3 Feb 2021 09:31:45 GMT
Subject: [jdk16] RFR: 8260585: AArch64: Wrong code generated for shifting
 right and accumulating four unsigned short integers [v7]
In-Reply-To: <YjF-cfwEbmcCd8ov07dQ_qN5XTeBTnoQYuDH2tvu3IU=.d95a8139-fef8-4f5e-b3dd-536fada8e624@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
 <Ft8meJwlUEk8U15Em2tv0X-AecHSZvQAKwShzW4dNGQ=.8444df13-169a-4d46-a377-b7cee6442985@github.com>
 <YjF-cfwEbmcCd8ov07dQ_qN5XTeBTnoQYuDH2tvu3IU=.d95a8139-fef8-4f5e-b3dd-536fada8e624@github.com>
Message-ID: <9WisRAG9qBk4FL87nQy3kNCLUyhKanVfnc_ZY2ZxkB8=.abf07896-4b00-4769-85b4-670d88f25aa3@github.com>

On Wed, 3 Feb 2021 09:07:36 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   match ssra with 8B
>
> OK, thanks.

Thank you all for the review.

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

PR: https://git.openjdk.java.net/jdk16/pull/136

From rcastanedalo at openjdk.java.net  Wed Feb  3 09:59:43 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 3 Feb 2021 09:59:43 GMT
Subject: RFR: 8260581: IGV: enhance node search [v4]
In-Reply-To: <GMUoMZhIdVyNIatNQoP3Gvp0mVL04r8jksT_8A5-IfU=.291100b0-73bb-43c5-b0ae-0d7dc6f0944b@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
 <PX-wlhHRXc1tK_AWQUY83UN2V1PPscs2VHM53IfZP40=.2ba8da90-be59-4ec3-95c7-8b367eae27cf@github.com>
 <GMUoMZhIdVyNIatNQoP3Gvp0mVL04r8jksT_8A5-IfU=.291100b0-73bb-43c5-b0ae-0d7dc6f0944b@github.com>
Message-ID: <iq_DMVRaJnF1XngOS9J9Eg5t3De55zgmgdgzGtnDyDM=.d6634bc9-ead7-44de-ba09-9c05d59457ae@github.com>

On Wed, 3 Feb 2021 07:34:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sort same-rank matches by first-word numeric value
>>   
>>   Sort otherwise equally relevant matches by node id, which is by default the
>>   first word in node labels. Thanks to Christian Hagedorn for the suggestion and
>>   (slightly adapted) patch.
>
> Marked as reviewed by chagedorn (Reviewer).

Please sponsor.

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

PR: https://git.openjdk.java.net/jdk/pull/2285

From rcastanedalo at openjdk.java.net  Wed Feb  3 11:14:50 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 3 Feb 2021 11:14:50 GMT
Subject: Integrated: 8260581: IGV: enhance node search
In-Reply-To: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
References: <kUDD4-DNLYCwtTqZWp0XFAvgLk0YQ_Da5-iGGmNKaDw=.d0d53d57-7085-408d-b821-9359987bc66a@github.com>
Message-ID: <xTJ0it7DWWA7CCoFUULU1xA3NU5wSDJUr1GMFbrVYF0=.375c6f86-61db-4870-b868-dacc71ec4e4d@github.com>

On Thu, 28 Jan 2021 11:07:38 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Apply several enhancements to the quick node search functionality: 
> 
> - Allow users to search by node id or name by default (i.e. when no property is specified) instead of name only.
> - Show partial matches when searching for a specific property (e.g. so that searching "type=con" lists all "control"-type nodes).
> - Avoid showing the "All _N_ matching nodes" entry if there is a single match, or the user is searching a numeric value.
> - Rank matches so that full matches are listed first, followed by matches at the beginning of the partially matched value, followed by the rest of matches in increasing size of the partially matched value. Numeric matches with the same rank are sorted increasingly. For example, searching "5" on a set of nodes with labels {"5 AddI", "25 AddL", "253 AddL", "554 MulI"} should list the matches as follows:
>     1. **5** AddI
>     2. **5**54 MulI
>     3. 2**5** AddL
>     4. 2**5**3 AddL
> 
> As an illustration of some of these enhancements, this screenshot shows the behavior of the quick node search functionality before the changes:
> 
> ![search-before](https://user-images.githubusercontent.com/8792647/106283438-374ba500-6242-11eb-8ef4-d18117eabcbb.png)
> 
> and after:
> 
> ![search-after](https://user-images.githubusercontent.com/8792647/106282880-7e856600-6241-11eb-8cb5-48fae5582cc2.png)
> 
> 
> Tested manually on small and large (~10000 nodes) graphs. Thanks to Christian Hagedorn for feedback on several iterations of the enhancements.
> 
> As part of the review, please evaluate not just the code changes but also the usability.

This pull request has now been integrated.

Changeset: ae2c5f07
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Committer: Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ae2c5f07
Stats:     100 lines in 3 files changed: 76 ins; 5 del; 19 mod

8260581: IGV: enhance node search

Allow users to search by node id or name by default, show partial matches when
searching for a specific property, show 'All N matching nodes' entry only if
relevant, and rank results by level of matching.

Co-authored-by: Christian Hagedorn <chagedorn at openjdk.org>
Reviewed-by: chagedorn, vlivanov, xliu

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

PR: https://git.openjdk.java.net/jdk/pull/2285

From chagedorn at openjdk.java.net  Wed Feb  3 11:20:47 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 3 Feb 2021 11:20:47 GMT
Subject: [jdk16] RFR: 8260709: C2: assert(false) failed: unscheduable graph
In-Reply-To: <idSFSTp4bGL2c4znWfecVpXWSAzvXDir_gtEdF5Mvnk=.32bb33e0-5aca-48b6-84a2-75ad293f4c4c@github.com>
References: <idSFSTp4bGL2c4znWfecVpXWSAzvXDir_gtEdF5Mvnk=.32bb33e0-5aca-48b6-84a2-75ad293f4c4c@github.com>
Message-ID: <mpnSatYifMZrYysskq2kdOQKmHMqmunJrGpsCYZfPbk=.efc8cdbf-99ec-46f5-8b0b-eff154167170@github.com>

On Tue, 2 Feb 2021 14:53:15 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The v = field load in the test case is found anti-dependent with the
> memory phi that merges the exception state of the 2 array
> allocation. Since JDK-8258393, anti-dependence computation only
> considers the Phi inputs that are reachable from the memory input of a
> load. As a consequence, the late control for the load is the control
> projection of the array allocation in the loop. When loop opts run,
> PhaseIdealLoop::split_if_with_blocks_post() finds that the load's late
> control is different from its current control (which is inside the
> outer loop). It tries to sink the load out of loop but ends up pinning
> it at its late control, the projection of the second AllocateNode.
> 
> The logic that expands the AllocateNode doesn't expect a pinned node
> on the control projection and the result is a broken graph. I think
> the fix for this would be to clone the load along both the exception
> and the fallthrough paths. But as noted in JDK-8252372, the whole
> process of sinking loads out of loops doesn't seem to work as expected
> (for instance in this case it sinks the load from the outer loop into
> the inner loop). So instead of going with a complicated fix, I propose
> simply to detect this corner and that no attempt be made to sink the
> load. Note that the current logic computes the late control for the
> load (which should be in the loop), will create a clone for each use
> and assign the dom_lca of the use's control and the load late control
> to that use, that is the load late control. So all uses end up at the
> same location, the load late control. So to detect that case, it's
> sufficient to test the load late control.

That sounds reasonable and looks good to me.

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/144

From roland at openjdk.java.net  Wed Feb  3 11:55:51 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 3 Feb 2021 11:55:51 GMT
Subject: [jdk16] RFR: 8260709: C2: assert(false) failed: unscheduable graph
In-Reply-To: <rUiJyg0nMW1iXUwoYnIIA5q_J-AjP-vsOsjidt0loJE=.418b8a6f-33ef-4545-82e1-adf4d50ea81e@github.com>
References: <idSFSTp4bGL2c4znWfecVpXWSAzvXDir_gtEdF5Mvnk=.32bb33e0-5aca-48b6-84a2-75ad293f4c4c@github.com>
 <rUiJyg0nMW1iXUwoYnIIA5q_J-AjP-vsOsjidt0loJE=.418b8a6f-33ef-4545-82e1-adf4d50ea81e@github.com>
Message-ID: <JGWqWwm52jLDcLZnMU-IkOo14AtWpCTndnR3vxIclL0=.0a7fea3c-d51e-4560-9268-545de2bf3fd7@github.com>

On Wed, 3 Feb 2021 08:25:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The v = field load in the test case is found anti-dependent with the
>> memory phi that merges the exception state of the 2 array
>> allocation. Since JDK-8258393, anti-dependence computation only
>> considers the Phi inputs that are reachable from the memory input of a
>> load. As a consequence, the late control for the load is the control
>> projection of the array allocation in the loop. When loop opts run,
>> PhaseIdealLoop::split_if_with_blocks_post() finds that the load's late
>> control is different from its current control (which is inside the
>> outer loop). It tries to sink the load out of loop but ends up pinning
>> it at its late control, the projection of the second AllocateNode.
>> 
>> The logic that expands the AllocateNode doesn't expect a pinned node
>> on the control projection and the result is a broken graph. I think
>> the fix for this would be to clone the load along both the exception
>> and the fallthrough paths. But as noted in JDK-8252372, the whole
>> process of sinking loads out of loops doesn't seem to work as expected
>> (for instance in this case it sinks the load from the outer loop into
>> the inner loop). So instead of going with a complicated fix, I propose
>> simply to detect this corner and that no attempt be made to sink the
>> load. Note that the current logic computes the late control for the
>> load (which should be in the loop), will create a clone for each use
>> and assign the dom_lca of the use's control and the load late control
>> to that use, that is the load late control. So all uses end up at the
>> same location, the load late control. So to detect that case, it's
>> sufficient to test the load late control.
>
> This looks reasonable to me as a point fix for JDK 16, given the plan is to rework that code for JDK 17 with [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).

thanks for the reviews @TobiHartmann @chhagedorn

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

PR: https://git.openjdk.java.net/jdk16/pull/144

From roland at openjdk.java.net  Wed Feb  3 12:06:45 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 3 Feb 2021 12:06:45 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
 <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
Message-ID: <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>

On Wed, 3 Feb 2021 05:45:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - convert all tests
>>  - Merge branch 'master' into JDK-8260296
>>  - use CoreUtils
>>  - whitespaces
>>  - SA fixes
>>  - VM fix
>>  - test
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 461:
> 
>> 459:     }
>> 460: 
>> 461:     static public class OutputAnalyzerAndPID {
> 
> can we either change `OutputAnalyzer` to store pid (and use -1 for cases when there is no one) or make `OutputAnalyzer` non-final and have `OutputAnalyzerAndPID` extending `OutputAnalyzer`?

Thanks for reviewing this. I did not store the pid in the OutputAnalyzer because it doesn't seem to belong there as it has nothing to do with the text output of a test. But if you think that's ok. that's fine with me too. Do you prefer an extra field in OutputAnalyzer or a new subclass?

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

PR: https://git.openjdk.java.net/jdk/pull/2195

From redestad at openjdk.java.net  Wed Feb  3 12:14:05 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Feb 2021 12:14:05 GMT
Subject: RFR: 8261030: Avoid loading GenerateJLIClassesHelper at runtime
Message-ID: <V3C_G-wR64zethUZUpr-nuqy-Jr0S2PFN5IiMnO1F-Q=.b0ddf573-d664-4241-869d-50e2da934446@github.com>

This moves the tracing methods added to GenerateJLIClassesHelper in JDK-8252725 to MethodHandleStatics, which avoids loading at runtime some code meant for jlink.

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

Commit messages:
 - Remove unused import, copyrights
 - Move tracing methods and constants from GenerateJLIClassesHelper to MethodHandleStatics

Changes: https://git.openjdk.java.net/jdk/pull/2376/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2376&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261030
  Stats: 69 lines in 4 files changed: 34 ins; 30 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2376/head:pull/2376

PR: https://git.openjdk.java.net/jdk/pull/2376

From neliasso at openjdk.java.net  Wed Feb  3 16:04:55 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 3 Feb 2021 16:04:55 GMT
Subject: Integrated: 8258799 : [Testbug] RandomCommandsTest must check if
 tested directive is added via jcmd
In-Reply-To: <oNE9DgoOhpHAqiZwsEiU6Qfxv4At7gvMVieXC2g8_7E=.905ad208-b7ad-4820-94b3-fcebb9850bf9@github.com>
References: <oNE9DgoOhpHAqiZwsEiU6Qfxv4At7gvMVieXC2g8_7E=.905ad208-b7ad-4820-94b3-fcebb9850bf9@github.com>
Message-ID: <RXJyDZBFvp0eDcu2toeSKLsJNH-uaIxV3-h97TwUlA0=.88418703-6570-4dfa-b290-09a1f2787f37@github.com>

On Tue, 2 Feb 2021 21:55:17 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> RandomCommandsTest.java is checking a mix of valid and invalid compilecommands and compiler directives. When they fail they have different behaviour:
> 
> A compilecommand that is malformed will result in a printed error, and then the VM continues. 
> A compiler directive that is malformed, that is added via commandline, will abort the VM, much like any other VM-flag would. 
> A compiler directive that is malformed, that is added via jcmd will print an error, and the VM continues - just like with any other jcmd.
> 
> The RandomCommandsTest fails when generating a malformed compiler directive and adding it via jcmd - because it expects the VM to abort.
> 
> This patch fixes that.

This pull request has now been integrated.

Changeset: 472bf629
Author:    Nils Eliasson <neliasso at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/472bf629
Stats:     19 lines in 2 files changed: 16 ins; 0 del; 3 mod

8258799: [Testbug] RandomCommandsTest must check if tested directive is added via jcmd

Reviewed-by: kvn, iignatyev

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

PR: https://git.openjdk.java.net/jdk/pull/2364

From iignatyev at openjdk.java.net  Wed Feb  3 16:30:41 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 3 Feb 2021 16:30:41 GMT
Subject: RFR: 8260301: misc gc/g1/unloading tests fails with
 "RuntimeException: Method could not be enqueued for compilation at level N"
In-Reply-To: <sDxa_4hC7Snidwr3uaQ2YsIzMzIG5x7K2L1VnIE8TyU=.6d777a20-0159-494d-8c55-dbf10ab22cbf@github.com>
References: <sDxa_4hC7Snidwr3uaQ2YsIzMzIG5x7K2L1VnIE8TyU=.6d777a20-0159-494d-8c55-dbf10ab22cbf@github.com>
Message-ID: <UOvJicDc81ARo7iJUiSUFzmcWUS3zxY5JGoJKVyDifY=.f5f4ff97-fa5a-417e-add1-aff6ba73a128@github.com>

On Tue, 2 Feb 2021 15:44:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> On return WB wait to acquire Compile_lock before checking compilation status
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/whitebox.cpp#L988 
> 
> This lock is used by ciEnv for compiled code publishing:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciEnv.cpp#L981
> 
> So while WB waits the lock compiler thread can finish compilation, register nmethod and clear method's queued_for_compilation bit.
> 
> The problem is that WB check `nm` value (compiled code) which it got before the lock and when method compilation is not finished.
> 
> The fix is to check compiled code again similar to check in CompileBroker:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L1501 
> 
> Passed hs-tier1-4 testing and 100 x vmTestbase/gc/g1/unloading/tests/unloading_compilation_*.

LGTM

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

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2356

From github.com+51754783+coreyashford at openjdk.java.net  Wed Feb  3 17:38:45 2021
From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford)
Date: Wed, 3 Feb 2021 17:38:45 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v4]
In-Reply-To: <2CXH3zvUkBfqLrr8SPpD-x3RcSbFzw0S6NGLWgtirQ8=.0df1a0c8-3ac2-4e21-9e6a-f0b43a3ae20c@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <2CXH3zvUkBfqLrr8SPpD-x3RcSbFzw0S6NGLWgtirQ8=.0df1a0c8-3ac2-4e21-9e6a-f0b43a3ae20c@github.com>
Message-ID: <CY6bEpMoh7F1l66dSrJoeO0GcAK4x77a4zHfDVtgtig=.eb836926-4db4-4d70-bf4c-a0e4d44c938b@github.com>

On Tue, 2 Feb 2021 12:45:03 GMT, Kazunori Ogata <ogatak at openjdk.org> wrote:

>> The POWER10 processor, which implements Power ISA 3.1 [1], supports new instruction formats where an instruction takes two 32bit words.  The first word is called prefix, and the instructions with prefix are called prefixed instructions.  With more bits in opcode and operand fields, POWER10 supports larger immediate value in an operand, as well as many new instructions.
>> 
>> This is the first changes to handle prefixed instructions, and this adds support of prefixed addi (= paddi) instruction as an example of prefix usage.  paddi accepts 34bit immediate value, while original addi accepts 16bit value.
>> 
>> [1] https://ibm.ent.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0
>
> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed pla and psubi and adjusted spacing based on review comments

Looks good!  Thanks for the additional formatting cleanup

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

Marked as reviewed by CoreyAshford at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/2095

From kvn at openjdk.java.net  Wed Feb  3 18:08:44 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 3 Feb 2021 18:08:44 GMT
Subject: RFR: 8260301: misc gc/g1/unloading tests fails with
 "RuntimeException: Method could not be enqueued for compilation at level N"
In-Reply-To: <UOvJicDc81ARo7iJUiSUFzmcWUS3zxY5JGoJKVyDifY=.f5f4ff97-fa5a-417e-add1-aff6ba73a128@github.com>
References: <sDxa_4hC7Snidwr3uaQ2YsIzMzIG5x7K2L1VnIE8TyU=.6d777a20-0159-494d-8c55-dbf10ab22cbf@github.com>
 <UOvJicDc81ARo7iJUiSUFzmcWUS3zxY5JGoJKVyDifY=.f5f4ff97-fa5a-417e-add1-aff6ba73a128@github.com>
Message-ID: <dtdecYDUY4LvmyDyBp5uxsZXiehzCkFe25D9tl-axK8=.3a86acb5-2edb-46cd-9bd0-faf58e252e79@github.com>

On Wed, 3 Feb 2021 16:27:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> On return WB wait to acquire Compile_lock before checking compilation status
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/whitebox.cpp#L988 
>> 
>> This lock is used by ciEnv for compiled code publishing:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciEnv.cpp#L981
>> 
>> So while WB waits the lock compiler thread can finish compilation, register nmethod and clear method's queued_for_compilation bit.
>> 
>> The problem is that WB check `nm` value (compiled code) which it got before the lock and when method compilation is not finished.
>> 
>> The fix is to check compiled code again similar to check in CompileBroker:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L1501 
>> 
>> Passed hs-tier1-4 testing and 100 x vmTestbase/gc/g1/unloading/tests/unloading_compilation_*.
>
> LGTM

Thank you, Igor

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

PR: https://git.openjdk.java.net/jdk/pull/2356

From kvn at openjdk.java.net  Wed Feb  3 18:08:45 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 3 Feb 2021 18:08:45 GMT
Subject: Integrated: 8260301: misc gc/g1/unloading tests fails with
 "RuntimeException: Method could not be enqueued for compilation at level N"
In-Reply-To: <sDxa_4hC7Snidwr3uaQ2YsIzMzIG5x7K2L1VnIE8TyU=.6d777a20-0159-494d-8c55-dbf10ab22cbf@github.com>
References: <sDxa_4hC7Snidwr3uaQ2YsIzMzIG5x7K2L1VnIE8TyU=.6d777a20-0159-494d-8c55-dbf10ab22cbf@github.com>
Message-ID: <fjFMk8cuInjyH9Zx6ptAMsJkRwgEzhzQpDlOOcbldhk=.c6397833-88d8-4563-9e97-c8042342af0f@github.com>

On Tue, 2 Feb 2021 15:44:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> On return WB wait to acquire Compile_lock before checking compilation status
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/whitebox.cpp#L988 
> 
> This lock is used by ciEnv for compiled code publishing:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciEnv.cpp#L981
> 
> So while WB waits the lock compiler thread can finish compilation, register nmethod and clear method's queued_for_compilation bit.
> 
> The problem is that WB check `nm` value (compiled code) which it got before the lock and when method compilation is not finished.
> 
> The fix is to check compiled code again similar to check in CompileBroker:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L1501 
> 
> Passed hs-tier1-4 testing and 100 x vmTestbase/gc/g1/unloading/tests/unloading_compilation_*.

This pull request has now been integrated.

Changeset: f025bc1d
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f025bc1d
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8260301: misc gc/g1/unloading tests fails with "RuntimeException: Method could not be enqueued for compilation at level N"

Reviewed-by: dlong, iignatyev

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

PR: https://git.openjdk.java.net/jdk/pull/2356

From iignatyev at openjdk.java.net  Wed Feb  3 18:54:43 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 3 Feb 2021 18:54:43 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
 <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
 <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>
Message-ID: <szyKVJwJZABJzqj8BOKjMfGo7rn8KLUfzrTdE1l0SNQ=.2ea62edd-dc83-4da2-8a16-6cb86076a46b@github.com>

On Wed, 3 Feb 2021 12:04:00 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/ProcessTools.java line 461:
>> 
>>> 459:     }
>>> 460: 
>>> 461:     static public class OutputAnalyzerAndPID {
>> 
>> can we either change `OutputAnalyzer` to store pid (and use -1 for cases when there is no one) or make `OutputAnalyzer` non-final and have `OutputAnalyzerAndPID` extending `OutputAnalyzer`?
>
> Thanks for reviewing this. I did not store the pid in the OutputAnalyzer because it doesn't seem to belong there as it has nothing to do with the text output of a test. But if you think that's ok. that's fine with me too. Do you prefer an extra field in OutputAnalyzer or a new subclass?

`OutputAnalyzer`/ `OutputBuffer` already have an exit value, which arguable has nothing to do w/ the text output either, so I think it's ok to add a pid into `OutputBuffer` i-face and both of its implementations.

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

PR: https://git.openjdk.java.net/jdk/pull/2195

From mdoerr at openjdk.java.net  Wed Feb  3 21:03:42 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 3 Feb 2021 21:03:42 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v4]
In-Reply-To: <CY6bEpMoh7F1l66dSrJoeO0GcAK4x77a4zHfDVtgtig=.eb836926-4db4-4d70-bf4c-a0e4d44c938b@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <2CXH3zvUkBfqLrr8SPpD-x3RcSbFzw0S6NGLWgtirQ8=.0df1a0c8-3ac2-4e21-9e6a-f0b43a3ae20c@github.com>
 <CY6bEpMoh7F1l66dSrJoeO0GcAK4x77a4zHfDVtgtig=.eb836926-4db4-4d70-bf4c-a0e4d44c938b@github.com>
Message-ID: <d36AHtgBmsfBVbdxGYLJ9pfiwevv_bnSDj3YqkMu4_0=.65dfdb5d-9a22-486d-9a6e-41e3a542fa1e@github.com>

On Wed, 3 Feb 2021 17:35:33 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed pla and psubi and adjusted spacing based on review comments
>
> Looks good!  Thanks for the additional formatting cleanup

Sorry that I didn't review it, yet. I didn't have enough time.

Please note that C2 already has a mechanism to handle alignment:

Insert "ins_alignment(n);" into the instruct. This allows C2 to insert up to n-1 nop instructions. 
Add a "compute_padding" function to determine the actual number of nops to insert given the current offset.
They are used in s390.ad. Please take a look.

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

PR: https://git.openjdk.java.net/jdk/pull/2095

From dongbo at openjdk.java.net  Wed Feb  3 21:43:50 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 3 Feb 2021 21:43:50 GMT
Subject: [jdk16] Integrated: 8260585: AArch64: Wrong code generated for
 shifting right and accumulating four unsigned short integers
In-Reply-To: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
References: <qpKJ1aCdNOjcvC-KuQS6xhut_wTt7jiK2IKLWnxWlb4=.059e3a1e-a3c4-4eba-a42a-9c0df73f8258@github.com>
Message-ID: <NiVgWP0VW_rrlgUQiru_FlNv_kXstROOEI_BdFVSfVc=.8453fd38-0af8-4297-ba74-bd521a973df2@github.com>

On Thu, 28 Jan 2021 13:01:07 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> This is a typo introduced by JDK-8255949.
> Compiler will generate `ushr` for shifting right and accumulating four short integers.
> It produces wrong results for specific case. The instruction should be `usra`.

This pull request has now been integrated.

Changeset: 5307afa9
Author:    Dong Bo <dongbo at openjdk.org>
Committer: Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/5307afa9
Stats:     479 lines in 2 files changed: 458 ins; 16 del; 5 mod

8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers

Reviewed-by: iveresov, dlong, njian, aph

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

PR: https://git.openjdk.java.net/jdk16/pull/136

From serb at openjdk.java.net  Wed Feb  3 23:54:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Feb 2021 23:54:51 GMT
Subject: Integrated: 8261010: Delete the Netbeans "default" license header
In-Reply-To: <zfSI9-g2hnFktpcaiOMCPnoIZ-l3Xn7gojA238J3ZFs=.25f4a0c3-30b1-4bfd-acd7-abd17cc5345c@github.com>
References: <zfSI9-g2hnFktpcaiOMCPnoIZ-l3Xn7gojA238J3ZFs=.25f4a0c3-30b1-4bfd-acd7-abd17cc5345c@github.com>
Message-ID: <R_N8RlIZUp0z5rIjwd0RLuSKhS-uP_pj0pC-vjri0I8=.7468c6af-204f-4602-82e5-7a4c9f5f7d85@github.com>

On Wed, 3 Feb 2021 04:01:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Trivial cleanup, the "default" license header is removed in a few components.

This pull request has now been integrated.

Changeset: f279ff9d
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f279ff9d
Stats:     14 lines in 3 files changed: 0 ins; 14 del; 0 mod

8261010: Delete the Netbeans "default" license header

Reviewed-by: iris, psadhukhan

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

PR: https://git.openjdk.java.net/jdk/pull/2368

From roland at openjdk.java.net  Thu Feb  4 08:43:08 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 4 Feb 2021 08:43:08 GMT
Subject: RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during C2
 compilation
Message-ID: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>

Another shenandoah bug with a fix in shared code.

LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
but non scalarizable. As a result, the null check for a3.f is
optimized out but the CastPP is left in the graph. That CastPP becomes
control dependent on the o2 == null check which is later hoisted out
of the loop. The CastPP is then right after the membar of the barrier = 0x42
volatile access but with an out of loop control. Because the node is
considered pinned by loopopts, it is assigned the membar as
control. The input of the CastPP is a shenandoah barrier that's
sandwiched between the membar and the CastPP and so expanded right
after the membar (that is between the membar and its control
projection). That causes the crash. I don't think cast nodes need to
be pinned so I propose that as a fix.

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

Commit messages:
 - test & fix

Changes: https://git.openjdk.java.net/jdk/pull/2400/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2400&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260637
  Stats: 33 lines in 2 files changed: 27 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2400.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2400/head:pull/2400

PR: https://git.openjdk.java.net/jdk/pull/2400

From whuang at openjdk.java.net  Thu Feb  4 08:55:07 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 4 Feb 2021 08:55:07 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap
Message-ID: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>

JDK-8075052 have removed useless autobox. However, in some cases, the box is still saved. For instance:
@Benchmark
public void testMethod(Blackhole bh) {
  int sum = 0;
  for (int i = 0; i < data.length; i++) {
      Integer ii = Integer.valueOf(data[i]);
      if (i < data.length) {
          sum += ii.intValue();
      }
  }
  bh.consume(sum);
}
Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
The uncommon_trap is generated by the optimized "if", because its condition is always true.

We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
and deleting the use of box:

There is no additional fail/error(s) of jtreg after this patch.

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

Commit messages:
 - 8261137: Optimization of Box nodes in uncommon_trap

Changes: https://git.openjdk.java.net/jdk/pull/2401/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261137
  Stats: 46 lines in 1 file changed: 45 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2401/head:pull/2401

PR: https://git.openjdk.java.net/jdk/pull/2401

From roland at openjdk.java.net  Thu Feb  4 09:44:13 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 4 Feb 2021 09:44:13 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v4]
In-Reply-To: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
Message-ID: <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>

> I noticed that the SA's dumpreplaydata command fails with:
> 
> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
> 
> with a simple test program. This happens because the SA can't find the
> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
> there's nothing in our build system that hides that symbol. I had to
> move one method's definition from the header file to the cpp file for
> the symbol to be visible again.
> 
> We have a test that checks dumpreplaydata but it doesn't catch that
> problem. The test produces a replay file from a core file with the SA
> by running a simple test with -Xcomp and CICrash=1. So the replay data
> has very little or no profile data (which is what causes the problem
> above). I propose running a slightly more complicated test method and
> crashing after the method has had time to run for long enough to
> collect profile data.
> 
> The other shortcoming of the test is that it doesn't look at the
> content of the replay file. It only warns if they differ. The replay
> file produced by the VM and the one produced by the SA should be
> identical (except for comment lines). So I propose we check that.
> 
> Finally, I can't run that test on my system because core files are
> handled by systemd (I'm running some recent version of fedora). I
> suppose, the system can be configured differently but having the test
> work out the box is nice. I extended the test case to handle that.
> 
> With the improved test, there are a few differences between the VM and
> SA replay files caused by VM changes that were not mirrored in the
> SA. I fixed those.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - pid in OutputAnalyzer
 - pid in OutputAnalyzer
 - Merge branch 'master' into JDK-8260296
 - convert all tests
 - Merge branch 'master' into JDK-8260296
 - use CoreUtils
 - whitespaces
 - SA fixes
 - VM fix
 - test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2195/files
  - new: https://git.openjdk.java.net/jdk/pull/2195/files/d1e9381c..da2fe2be

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2195&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2195&range=02-03

  Stats: 30246 lines in 796 files changed: 11471 ins; 7752 del; 11023 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2195.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2195/head:pull/2195

PR: https://git.openjdk.java.net/jdk/pull/2195

From roland at openjdk.java.net  Thu Feb  4 09:44:13 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 4 Feb 2021 09:44:13 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <szyKVJwJZABJzqj8BOKjMfGo7rn8KLUfzrTdE1l0SNQ=.2ea62edd-dc83-4da2-8a16-6cb86076a46b@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
 <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
 <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>
 <szyKVJwJZABJzqj8BOKjMfGo7rn8KLUfzrTdE1l0SNQ=.2ea62edd-dc83-4da2-8a16-6cb86076a46b@github.com>
Message-ID: <ba-Xnb7Fj1KwMez4GsvQXbKP8HrC0VGGdDFyn14zclc=.ba00c708-b580-4904-b4a5-de91e6c7e181@github.com>

On Wed, 3 Feb 2021 18:51:57 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Thanks for reviewing this. I did not store the pid in the OutputAnalyzer because it doesn't seem to belong there as it has nothing to do with the text output of a test. But if you think that's ok. that's fine with me too. Do you prefer an extra field in OutputAnalyzer or a new subclass?
>
> `OutputAnalyzer`/ `OutputBuffer` already have an exit value, which arguable has nothing to do w/ the text output either, so I think it's ok to add a pid into `OutputBuffer` i-face and both of its implementations.

I just pushed a change that does this. Does that look ok to you?

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

PR: https://git.openjdk.java.net/jdk/pull/2195

From github.com+10482586+therealeliu at openjdk.java.net  Thu Feb  4 10:04:39 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Thu, 4 Feb 2021 10:04:39 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap
In-Reply-To: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
Message-ID: <bLyRf5fLACZqgGvxO9Ad-YdjioIaqPYAyRxR0rsGDbc=.e9d0040a-c216-419e-aed2-5ac197060797@github.com>

On Thu, 4 Feb 2021 08:43:35 GMT, Wang Huang <whuang at openjdk.org> wrote:

> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
> @Benchmark
> public void testMethod(Blackhole bh) {
>   int sum = 0;
>   for (int i = 0; i < data.length; i++) {
>       Integer ii = Integer.valueOf(data[i]);
>       if (i < data.length) {
>           sum += ii.intValue();
>       }
>   }
>   bh.consume(sum);
> }
> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
> The uncommon_trap is generated by the optimized "if", because its condition is always true.
> 
> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
> and deleting the use of box:
> 
> There is no additional fail/error(s) of jtreg after this patch.

I was wandering if we can remove the useless `if` as it's always true in this case. Do you know why this kind of `if` haven't been eliminated by GVN phase?

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From jiefu at openjdk.java.net  Thu Feb  4 11:00:49 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 4 Feb 2021 11:00:49 GMT
Subject: [jdk16] RFR: 8260473: [vector] ZGC: VectorReshape test produces
 incorrect results with ZGC enabled
In-Reply-To: <JBocBhTuVYoDaykHPBrn8Cs_ZRY56SH-5oAkFBGE-uM=.8178a00d-b078-49d5-831a-e2ef4eae3aba@github.com>
References: <5OfnHC5N00VVv3pWcU9gsAHa23RbAAX7ReEw9Ct6eug=.4f095083-7050-487d-94e0-3befce6744c5@github.com>
 <AnmJJ1iKY2JuCYo2Ks5scQIteJOxfEqw2FdN7c2j8cE=.fb5329d5-2973-40d1-83c6-ad5f09ab188b@github.com>
 <INg3qtMQAPPNQZ30DZm9XqB-7BKjgh3nigpQVzlP1pE=.99521b3a-8f2b-4c66-9ae8-c83a0007f53c@github.com>
 <p0rv864nXBQBEH5Ig3EZ8YIZHsLj4bcehOr3GqRCVVY=.b8a19c52-bf2c-4016-9549-4baef9fc8253@github.com>
 <_Wm-fi9j4TZ41F0G_92f7ioKQeDNgZiOEMmLkZ0lvvE=.0a9beba5-5089-4368-b4bc-73faf9d5e858@github.com>
 <RxsmBy3QMxbmHEF9nq2kZvq6QSVY7pwNqEeaNC7Ukwo=.b9774de4-2bf2-44b0-a882-f6f2dbf1639c@github.com>
 <226iFOsl1hXrEoSe9uzgBb1Z75wxQEv5azlJIfzCO4k=.69d5ed3a-7337-472d-b106-1ce2e5d361bf@github.com>
 <JBocBhTuVYoDaykHPBrn8Cs_ZRY56SH-5oAkFBGE-uM=.8178a00d-b078-49d5-831a-e2ef4eae3aba@github.com>
Message-ID: <tZlZiJS3AdmB8wChiO57MuzH-1LIygl8BUlOot0IexM=.1e17d6f9-583c-400c-8ab6-75bfe62a00ab@github.com>

On Tue, 2 Feb 2021 01:58:56 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Good. Please, file a follow-up RFE to improve the test.

The RFE has been filed here: https://bugs.openjdk.java.net/browse/JDK-8261152
Thanks.

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

PR: https://git.openjdk.java.net/jdk16/pull/139

From neliasso at openjdk.java.net  Thu Feb  4 12:44:42 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 4 Feb 2021 12:44:42 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap
In-Reply-To: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
Message-ID: <TZr1xHXJc1tCzUrqRm77vBcC6tdq9ehjpAfxPQgE51Q=.d7d1cb43-ae58-4751-9abc-17126ad8ce01@github.com>

On Thu, 4 Feb 2021 08:43:35 GMT, Wang Huang <whuang at openjdk.org> wrote:

> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
> @Benchmark
> public void testMethod(Blackhole bh) {
>   int sum = 0;
>   for (int i = 0; i < data.length; i++) {
>       Integer ii = Integer.valueOf(data[i]);
>       if (i < data.length) {
>           sum += ii.intValue();
>       }
>   }
>   bh.consume(sum);
> }
> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
> The uncommon_trap is generated by the optimized "if", because its condition is always true.
> 
> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
> and deleting the use of box:
> 
> There is no additional fail/error(s) of jtreg after this patch.

src/hotspot/share/opto/callGenerator.cpp line 606:

> 604:   }
> 605: 
> 606:   if (callprojs.resproj != NULL && call->is_CallStaticJava() &&

Please extract the new code into a method with a descriptive name.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From roland at openjdk.java.net  Thu Feb  4 15:14:54 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 4 Feb 2021 15:14:54 GMT
Subject: [jdk16] Integrated: 8260709: C2: assert(false) failed: unscheduable
 graph
In-Reply-To: <idSFSTp4bGL2c4znWfecVpXWSAzvXDir_gtEdF5Mvnk=.32bb33e0-5aca-48b6-84a2-75ad293f4c4c@github.com>
References: <idSFSTp4bGL2c4znWfecVpXWSAzvXDir_gtEdF5Mvnk=.32bb33e0-5aca-48b6-84a2-75ad293f4c4c@github.com>
Message-ID: <6YVllOtZR6uA1BONaiOKCdow7or4K4S0V52fLw6nWHs=.5dd58a60-95cd-4eee-8df0-fc4e9c35d090@github.com>

On Tue, 2 Feb 2021 14:53:15 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The v = field load in the test case is found anti-dependent with the
> memory phi that merges the exception state of the 2 array
> allocation. Since JDK-8258393, anti-dependence computation only
> considers the Phi inputs that are reachable from the memory input of a
> load. As a consequence, the late control for the load is the control
> projection of the array allocation in the loop. When loop opts run,
> PhaseIdealLoop::split_if_with_blocks_post() finds that the load's late
> control is different from its current control (which is inside the
> outer loop). It tries to sink the load out of loop but ends up pinning
> it at its late control, the projection of the second AllocateNode.
> 
> The logic that expands the AllocateNode doesn't expect a pinned node
> on the control projection and the result is a broken graph. I think
> the fix for this would be to clone the load along both the exception
> and the fallthrough paths. But as noted in JDK-8252372, the whole
> process of sinking loads out of loops doesn't seem to work as expected
> (for instance in this case it sinks the load from the outer loop into
> the inner loop). So instead of going with a complicated fix, I propose
> simply to detect this corner and that no attempt be made to sink the
> load. Note that the current logic computes the late control for the
> load (which should be in the loop), will create a clone for each use
> and assign the dom_lca of the use's control and the load late control
> to that use, that is the load late control. So all uses end up at the
> same location, the load late control. So to detect that case, it's
> sufficient to test the load late control.

This pull request has now been integrated.

Changeset: 4de3a6be
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/4de3a6be
Stats:     70 lines in 3 files changed: 69 ins; 0 del; 1 mod

8260709: C2: assert(false) failed: unscheduable graph

Reviewed-by: thartmann, chagedorn

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

PR: https://git.openjdk.java.net/jdk16/pull/144

From iignatyev at openjdk.java.net  Thu Feb  4 18:28:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 4 Feb 2021 18:28:48 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v4]
In-Reply-To: <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>
Message-ID: <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>

On Thu, 4 Feb 2021 09:44:13 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I noticed that the SA's dumpreplaydata command fails with:
>> 
>> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
>> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
>> 
>> with a simple test program. This happens because the SA can't find the
>> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
>> there's nothing in our build system that hides that symbol. I had to
>> move one method's definition from the header file to the cpp file for
>> the symbol to be visible again.
>> 
>> We have a test that checks dumpreplaydata but it doesn't catch that
>> problem. The test produces a replay file from a core file with the SA
>> by running a simple test with -Xcomp and CICrash=1. So the replay data
>> has very little or no profile data (which is what causes the problem
>> above). I propose running a slightly more complicated test method and
>> crashing after the method has had time to run for long enough to
>> collect profile data.
>> 
>> The other shortcoming of the test is that it doesn't look at the
>> content of the replay file. It only warns if they differ. The replay
>> file produced by the VM and the one produced by the SA should be
>> identical (except for comment lines). So I propose we check that.
>> 
>> Finally, I can't run that test on my system because core files are
>> handled by systemd (I'm running some recent version of fedora). I
>> suppose, the system can be configured differently but having the test
>> work out the box is nice. I extended the test case to handle that.
>> 
>> With the improved test, there are a few differences between the VM and
>> SA replay files caused by VM changes that were not mirrored in the
>> SA. I fixed those.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - pid in OutputAnalyzer
>  - pid in OutputAnalyzer
>  - Merge branch 'master' into JDK-8260296
>  - convert all tests
>  - Merge branch 'master' into JDK-8260296
>  - use CoreUtils
>  - whitespaces
>  - SA fixes
>  - VM fix
>  - test

LGTM, you still need to update the copyright years as @plummercj [mentioned](https://github.com/openjdk/jdk/pull/2195#issuecomment-768115732).

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

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2195

From iignatyev at openjdk.java.net  Thu Feb  4 18:28:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 4 Feb 2021 18:28:48 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <ba-Xnb7Fj1KwMez4GsvQXbKP8HrC0VGGdDFyn14zclc=.ba00c708-b580-4904-b4a5-de91e6c7e181@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
 <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
 <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>
 <szyKVJwJZABJzqj8BOKjMfGo7rn8KLUfzrTdE1l0SNQ=.2ea62edd-dc83-4da2-8a16-6cb86076a46b@github.com>
 <ba-Xnb7Fj1KwMez4GsvQXbKP8HrC0VGGdDFyn14zclc=.ba00c708-b580-4904-b4a5-de91e6c7e181@github.com>
Message-ID: <ppXJxks_xkkYNh50ehTLGHyHjgsTxCBSaJGN7yvWTS0=.866e3059-0074-4dcd-9e6d-31e8e32f8381@github.com>

On Thu, 4 Feb 2021 09:40:33 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> `OutputAnalyzer`/ `OutputBuffer` already have an exit value, which arguable has nothing to do w/ the text output either, so I think it's ok to add a pid into `OutputBuffer` i-face and both of its implementations.
>
> I just pushed a change that does this. Does that look ok to you?

yes, thank you.

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

PR: https://git.openjdk.java.net/jdk/pull/2195

From cjplummer at openjdk.java.net  Thu Feb  4 19:18:46 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Feb 2021 19:18:46 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v4]
In-Reply-To: <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>
 <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>
Message-ID: <brSRUCTWuBzI7zRElceeBNFI8_LXQEy4fAnl6yIg9pc=.b5087e9d-005f-401a-a563-61950ffec345@github.com>

On Thu, 4 Feb 2021 18:25:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - pid in OutputAnalyzer
>>  - pid in OutputAnalyzer
>>  - Merge branch 'master' into JDK-8260296
>>  - convert all tests
>>  - Merge branch 'master' into JDK-8260296
>>  - use CoreUtils
>>  - whitespaces
>>  - SA fixes
>>  - VM fix
>>  - test
>
> LGTM, you still need to update the copyright years as @plummercj [mentioned](https://github.com/openjdk/jdk/pull/2195#issuecomment-768115732).

Yes, this is a much better solution for getting the pid.

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

PR: https://git.openjdk.java.net/jdk/pull/2195

From pli at openjdk.java.net  Fri Feb  5 02:33:54 2021
From: pli at openjdk.java.net (Pengfei Li)
Date: Fri, 5 Feb 2021 02:33:54 GMT
Subject: RFR: 8261022: Fix incorrect result of Math.abs() with char type
Message-ID: <kysXfJ4zGQ184XiAWdxDWrbDwo20G8cfKDs17P2wIWQ=.c26b40d7-6fbe-4d43-8633-3e92f2b997bb@github.com>

Math.abs() with char type may return incorrect result after C2 superword optimization. It can be reproduced by below Java code and commands.

public class Bug {
    private static int SIZE = 60000;
    private static char[] a = new char[SIZE];
    private static char[] b = new char[SIZE];

    public static void main(String[] args) {
        for (int i = 0; i < SIZE; i++) {
            a[i] = b[i] = (char) i;
        }
        for (int i = 0; i < SIZE; i++) {
            a[i] = (char) Math.abs(a[i]);
        }
        for (int i = 0; i < SIZE; i++) {
            if (a[i] != b[i]) {
                throw new RuntimeException("Broken!");
            }
        }
        System.out.println("OK");
    }
}

// $ java -Xint Bug
// OK

// $ java -Xcomp -XX:-TieredCompilation Bug
// Exception in thread "main" java.lang.RuntimeException: Broken!
//         at Bug.main(Bug.java:15)

In Java, 'char' is a 16-bit unsigned integer type and the abs() method should always return the value of its input. But with C2 vectorization, the sign bit of the 16-bit value is cleared because it's regarded as a signed value.

Root cause is that we get an imprecise vector element type for AbsINode from SuperWord::compute_vector_element_type(). In any Java arithmetic operation, operands of small integer types (boolean, byte, char & short) should be promoted to int first. As vector elements of small types don't have upper bits of int, for RShiftI or AbsI operations, the compiler has to know the precise signedness info of the 1st operand. These operations shouldn't be vectorized if the signedness info is imprecise.

In code SuperWord::compute_vector_element_type(), we have some special handling for right shift. It limited the vectorization of small integer right shift to operations only after loads. The reason is that in the C2 compiler, only LoadNode has precise signedness info of its value. When JDK-8222074 enabled abs vectorization, it didn't involve AbsI operation into the special handling and thus introduced this bug. This patch just does the fix at this point.

Tested hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1, no new failure is found. Also created a new jtreg with this fix.

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

Commit messages:
 - 8261022: Fix incorrect result of Math.abs() with char type

Changes: https://git.openjdk.java.net/jdk/pull/2419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2419&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261022
  Stats: 76 lines in 2 files changed: 66 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2419/head:pull/2419

PR: https://git.openjdk.java.net/jdk/pull/2419

From github.com+2249648+johntortugo at openjdk.java.net  Fri Feb  5 03:35:56 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Fri, 5 Feb 2021 03:35:56 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler
Message-ID: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>

Relates to: https://bugs.openjdk.java.net/browse/JDK-8241502
Tested on: Linux tier1, 2 and 3

Can you please take a look whether these changes are going in the direction expected or not? If it is, I'll continue working on the `JDK-8241502` but I'd like to split it in a few PRs since it's a lot of changes.

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

Commit messages:
 - Merge branch 'jdk-8241502' of https://github.com/JohnTortugo/jdk into jdk-8241502
 - First part of Migrate x86_64 to MacroAssembler
 - First part of Migrate x86_64 to MacroAssembler
 - Merge pull request #1 from openjdk/master

Changes: https://git.openjdk.java.net/jdk/pull/2420/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8241502
  Stats: 174 lines in 1 file changed: 44 ins; 21 del; 109 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2420.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2420/head:pull/2420

PR: https://git.openjdk.java.net/jdk/pull/2420

From github.com+25214855+casparcwang at openjdk.java.net  Fri Feb  5 04:47:47 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 5 Feb 2021 04:47:47 GMT
Subject: RFR: 8261152: Refine the
 compiler/vectorapi/VectorRebracket128Test.java test
Message-ID: <ijYvvhPffp5v8U3EnIGxxGuJUANXnfBMG6mlh-u62JU=.500e5845-b6d0-4d0e-9732-fb32ed214ea4@github.com>

Refine test VectorRebracket128Test.java as discussed here https://github.com/openjdk/jdk16/pull/139#discussion_r567796847

1, Explicit trigger gc in the test
2, Remove redundant imports
3, Remove weird java options

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

Commit messages:
 - 8261152: Refine the compiler/vectorapi/VectorRebracket128Test.java test

Changes: https://git.openjdk.java.net/jdk/pull/2422/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2422&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261152
  Stats: 26 lines in 1 file changed: 17 ins; 7 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2422.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2422/head:pull/2422

PR: https://git.openjdk.java.net/jdk/pull/2422

From whuang at openjdk.java.net  Fri Feb  5 06:49:42 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 5 Feb 2021 06:49:42 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap
In-Reply-To: <TZr1xHXJc1tCzUrqRm77vBcC6tdq9ehjpAfxPQgE51Q=.d7d1cb43-ae58-4751-9abc-17126ad8ce01@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <TZr1xHXJc1tCzUrqRm77vBcC6tdq9ehjpAfxPQgE51Q=.d7d1cb43-ae58-4751-9abc-17126ad8ce01@github.com>
Message-ID: <aX2awu7YJq1353GFVeNF35kD4SP08TKwZ7ES3cKWfqs=.5afdb099-8f90-43ef-a203-8dd4f355f261@github.com>

On Thu, 4 Feb 2021 12:41:50 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
>> @Benchmark
>> public void testMethod(Blackhole bh) {
>>   int sum = 0;
>>   for (int i = 0; i < data.length; i++) {
>>       Integer ii = Integer.valueOf(data[i]);
>>       if (i < data.length) {
>>           sum += ii.intValue();
>>       }
>>   }
>>   bh.consume(sum);
>> }
>> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
>> The uncommon_trap is generated by the optimized "if", because its condition is always true.
>> 
>> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
>> and deleting the use of box:
>> 
>> There is no additional fail/error(s) of jtreg after this patch.
>
> src/hotspot/share/opto/callGenerator.cpp line 606:
> 
>> 604:   }
>> 605: 
>> 606:   if (callprojs.resproj != NULL && call->is_CallStaticJava() &&
> 
> Please extract the new code into a method with a descriptive name.

OK. I will refactor these codes ASAP.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From whuang at openjdk.java.net  Fri Feb  5 07:18:43 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 5 Feb 2021 07:18:43 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap
In-Reply-To: <bLyRf5fLACZqgGvxO9Ad-YdjioIaqPYAyRxR0rsGDbc=.e9d0040a-c216-419e-aed2-5ac197060797@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <bLyRf5fLACZqgGvxO9Ad-YdjioIaqPYAyRxR0rsGDbc=.e9d0040a-c216-419e-aed2-5ac197060797@github.com>
Message-ID: <JEEX1TPNO8BU_OINsIJ6PJ1_-474D6j-66GjkjsIwsk=.0a7dd429-937f-4e6b-afff-fcfc6b2fbef5@github.com>

On Thu, 4 Feb 2021 10:01:50 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

> I was wandering if we can remove the useless `if` as it's always true in this case. Do you know why this kind of `if` haven't been eliminated by GVN phase?
It is a good idea . However, C2 might not optimize some `if` for many reasons: 
*  This situation can also be triggered in calling other method. For example :
  ```
public class MyBenchmark {

    static int[] data = new int[10000];

    static {
        for(int i = 0; i < data.length; ++i) {
            data[i] = 299;
        }
    }

    @Benchmark
    public void testMethod(Blackhole bh) {
      int sum = 0;
      for (int i = 0; i < data.length; i++) {
        Integer ii = Integer.valueOf(data[i]);
        sum += abs(ii);
      }
      bh.consume(sum);
    }

    public int abs(Integer ii) {
      if (ii.intValue() > 0) {
        return ii.intValue();
      } else {
        return 0 - ii.intValue();
      }
    }
}
 The method `abs` will be inlined when it is hot enough. However, this `If` can not be eliminated.
*  The case in the JDK-8261137 is just like this case: 
public class MyBenchmark {

    static int[] data = new int[10000];

    static {
        for(int i = 0; i < data.length; ++i) {
            data[i] = i * 1337 % 7331;
        }
    }

    @Benchmark
    public void testMethod(Blackhole bh) {
      int sum = 0;
      for (int i = 0; i < data.length; i++) {
          Integer ii = Integer.valueOf(data[i]);
          if (i < 100000) {
              sum += ii.intValue();
          }
      }
      bh.consume(sum);
    }
}

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From whuang at openjdk.java.net  Fri Feb  5 07:29:00 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 5 Feb 2021 07:29:00 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
Message-ID: <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>

> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
> @Benchmark
> public void testMethod(Blackhole bh) {
>   int sum = 0;
>   for (int i = 0; i < data.length; i++) {
>       Integer ii = Integer.valueOf(data[i]);
>       if (i < data.length) {
>           sum += ii.intValue();
>       }
>   }
>   bh.consume(sum);
> }
> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
> The uncommon_trap is generated by the optimized "if", because its condition is always true.
> 
> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
> and deleting the use of box:
> 
> There is no additional fail/error(s) of jtreg after this patch.

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  refactor codes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2401/files
  - new: https://git.openjdk.java.net/jdk/pull/2401/files/73be94ce..4dfee52a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=00-01

  Stats: 91 lines in 1 file changed: 47 ins; 43 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2401/head:pull/2401

PR: https://git.openjdk.java.net/jdk/pull/2401

From thartmann at openjdk.java.net  Fri Feb  5 07:41:46 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 5 Feb 2021 07:41:46 GMT
Subject: RFR: 8261022: Fix incorrect result of Math.abs() with char type
In-Reply-To: <kysXfJ4zGQ184XiAWdxDWrbDwo20G8cfKDs17P2wIWQ=.c26b40d7-6fbe-4d43-8633-3e92f2b997bb@github.com>
References: <kysXfJ4zGQ184XiAWdxDWrbDwo20G8cfKDs17P2wIWQ=.c26b40d7-6fbe-4d43-8633-3e92f2b997bb@github.com>
Message-ID: <maTv7d-17O9dwQ8NeBAMnv2LISnGahTuMwYjYRDQYkk=.d61e1f6a-3030-46b7-a616-4139334fb6cb@github.com>

On Fri, 5 Feb 2021 02:29:33 GMT, Pengfei Li <pli at openjdk.org> wrote:

> Math.abs() with char type may return incorrect result after C2 superword optimization. It can be reproduced by below Java code and commands.
> 
> public class Bug {
>     private static int SIZE = 60000;
>     private static char[] a = new char[SIZE];
>     private static char[] b = new char[SIZE];
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < SIZE; i++) {
>             a[i] = b[i] = (char) i;
>         }
>         for (int i = 0; i < SIZE; i++) {
>             a[i] = (char) Math.abs(a[i]);
>         }
>         for (int i = 0; i < SIZE; i++) {
>             if (a[i] != b[i]) {
>                 throw new RuntimeException("Broken!");
>             }
>         }
>         System.out.println("OK");
>     }
> }
> 
> // $ java -Xint Bug
> // OK
> 
> // $ java -Xcomp -XX:-TieredCompilation Bug
> // Exception in thread "main" java.lang.RuntimeException: Broken!
> //         at Bug.main(Bug.java:15)
> 
> In Java, 'char' is a 16-bit unsigned integer type and the abs() method should always return the value of its input. But with C2 vectorization, the sign bit of the 16-bit value is cleared because it's regarded as a signed value.
> 
> Root cause is that we get an imprecise vector element type for AbsINode from SuperWord::compute_vector_element_type(). In any Java arithmetic operation, operands of small integer types (boolean, byte, char & short) should be promoted to int first. As vector elements of small types don't have upper bits of int, for RShiftI or AbsI operations, the compiler has to know the precise signedness info of the 1st operand. These operations shouldn't be vectorized if the signedness info is imprecise.
> 
> In code SuperWord::compute_vector_element_type(), we have some special handling for right shift. It limited the vectorization of small integer right shift to operations only after loads. The reason is that in the C2 compiler, only LoadNode has precise signedness info of its value. When JDK-8222074 enabled abs vectorization, it didn't involve AbsI operation into the special handling and thus introduced this bug. This patch just does the fix at this point.
> 
> Tested hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1, no new failure is found. Also created a new jtreg with this fix.

Looks good to me.

src/hotspot/share/opto/superword.cpp line 3235:

> 3233:                 vt = velt_type(load);
> 3234:               } else if (in->Opcode() != Op_LShiftI) {
> 3235:                 // Widen type to int to avoid the creation of vector nodes. Note

`in->Opcode()` can be replaced by `op`

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2419

From pli at openjdk.java.net  Fri Feb  5 08:26:56 2021
From: pli at openjdk.java.net (Pengfei Li)
Date: Fri, 5 Feb 2021 08:26:56 GMT
Subject: RFR: 8261022: Fix incorrect result of Math.abs() with char type
 [v2]
In-Reply-To: <kysXfJ4zGQ184XiAWdxDWrbDwo20G8cfKDs17P2wIWQ=.c26b40d7-6fbe-4d43-8633-3e92f2b997bb@github.com>
References: <kysXfJ4zGQ184XiAWdxDWrbDwo20G8cfKDs17P2wIWQ=.c26b40d7-6fbe-4d43-8633-3e92f2b997bb@github.com>
Message-ID: <F-S_XOKm0oziI8m1LDB1QlKwcj6EPgHBAr6BVROis3s=.fcd238da-2c0d-48f7-933a-d9b9e033dc56@github.com>

> Math.abs() with char type may return incorrect result after C2 superword optimization. It can be reproduced by below Java code and commands.
> 
> public class Bug {
>     private static int SIZE = 60000;
>     private static char[] a = new char[SIZE];
>     private static char[] b = new char[SIZE];
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < SIZE; i++) {
>             a[i] = b[i] = (char) i;
>         }
>         for (int i = 0; i < SIZE; i++) {
>             a[i] = (char) Math.abs(a[i]);
>         }
>         for (int i = 0; i < SIZE; i++) {
>             if (a[i] != b[i]) {
>                 throw new RuntimeException("Broken!");
>             }
>         }
>         System.out.println("OK");
>     }
> }
> 
> // $ java -Xint Bug
> // OK
> 
> // $ java -Xcomp -XX:-TieredCompilation Bug
> // Exception in thread "main" java.lang.RuntimeException: Broken!
> //         at Bug.main(Bug.java:15)
> 
> In Java, 'char' is a 16-bit unsigned integer type and the abs() method should always return the value of its input. But with C2 vectorization, the sign bit of the 16-bit value is cleared because it's regarded as a signed value.
> 
> Root cause is that we get an imprecise vector element type for AbsINode from SuperWord::compute_vector_element_type(). In any Java arithmetic operation, operands of small integer types (boolean, byte, char & short) should be promoted to int first. As vector elements of small types don't have upper bits of int, for RShiftI or AbsI operations, the compiler has to know the precise signedness info of the 1st operand. These operations shouldn't be vectorized if the signedness info is imprecise.
> 
> In code SuperWord::compute_vector_element_type(), we have some special handling for right shift. It limited the vectorization of small integer right shift to operations only after loads. The reason is that in the C2 compiler, only LoadNode has precise signedness info of its value. When JDK-8222074 enabled abs vectorization, it didn't involve AbsI operation into the special handling and thus introduced this bug. This patch just does the fix at this point.
> 
> Tested hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1, no new failure is found. Also created a new jtreg with this fix.

Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2419/files
  - new: https://git.openjdk.java.net/jdk/pull/2419/files/7ec48429..cf5659b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2419&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2419&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2419/head:pull/2419

PR: https://git.openjdk.java.net/jdk/pull/2419

From pli at openjdk.java.net  Fri Feb  5 08:26:57 2021
From: pli at openjdk.java.net (Pengfei Li)
Date: Fri, 5 Feb 2021 08:26:57 GMT
Subject: RFR: 8261022: Fix incorrect result of Math.abs() with char type
 [v2]
In-Reply-To: <maTv7d-17O9dwQ8NeBAMnv2LISnGahTuMwYjYRDQYkk=.d61e1f6a-3030-46b7-a616-4139334fb6cb@github.com>
References: <kysXfJ4zGQ184XiAWdxDWrbDwo20G8cfKDs17P2wIWQ=.c26b40d7-6fbe-4d43-8633-3e92f2b997bb@github.com>
 <maTv7d-17O9dwQ8NeBAMnv2LISnGahTuMwYjYRDQYkk=.d61e1f6a-3030-46b7-a616-4139334fb6cb@github.com>
Message-ID: <ylEUHXlA9g8MwFv_sc5hp9wa5z9gb_2zY6ibk6Kpmmw=.9167bab1-496a-40a3-a8d8-8f4d2e65ff73@github.com>

On Fri, 5 Feb 2021 07:32:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/hotspot/share/opto/superword.cpp line 3235:
> 
>> 3233:                 vt = velt_type(load);
>> 3234:               } else if (in->Opcode() != Op_LShiftI) {
>> 3235:                 // Widen type to int to avoid the creation of vector nodes. Note
> 
> `in->Opcode()` can be replaced by `op`

Fixed, thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/2419

From neliasso at openjdk.java.net  Fri Feb  5 08:32:43 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 5 Feb 2021 08:32:43 GMT
Subject: RFR: 8261022: Fix incorrect result of Math.abs() with char type
 [v2]
In-Reply-To: <F-S_XOKm0oziI8m1LDB1QlKwcj6EPgHBAr6BVROis3s=.fcd238da-2c0d-48f7-933a-d9b9e033dc56@github.com>
References: <kysXfJ4zGQ184XiAWdxDWrbDwo20G8cfKDs17P2wIWQ=.c26b40d7-6fbe-4d43-8633-3e92f2b997bb@github.com>
 <F-S_XOKm0oziI8m1LDB1QlKwcj6EPgHBAr6BVROis3s=.fcd238da-2c0d-48f7-933a-d9b9e033dc56@github.com>
Message-ID: <af9duySqmk6-yk4iZAgFDurB3ynSrKnr0eIA-wZjvIY=.0c5b6f79-2b34-4d09-9bd1-f4a43a31af73@github.com>

On Fri, 5 Feb 2021 08:26:56 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> Math.abs() with char type may return incorrect result after C2 superword optimization. It can be reproduced by below Java code and commands.
>> 
>> public class Bug {
>>     private static int SIZE = 60000;
>>     private static char[] a = new char[SIZE];
>>     private static char[] b = new char[SIZE];
>> 
>>     public static void main(String[] args) {
>>         for (int i = 0; i < SIZE; i++) {
>>             a[i] = b[i] = (char) i;
>>         }
>>         for (int i = 0; i < SIZE; i++) {
>>             a[i] = (char) Math.abs(a[i]);
>>         }
>>         for (int i = 0; i < SIZE; i++) {
>>             if (a[i] != b[i]) {
>>                 throw new RuntimeException("Broken!");
>>             }
>>         }
>>         System.out.println("OK");
>>     }
>> }
>> 
>> // $ java -Xint Bug
>> // OK
>> 
>> // $ java -Xcomp -XX:-TieredCompilation Bug
>> // Exception in thread "main" java.lang.RuntimeException: Broken!
>> //         at Bug.main(Bug.java:15)
>> 
>> In Java, 'char' is a 16-bit unsigned integer type and the abs() method should always return the value of its input. But with C2 vectorization, the sign bit of the 16-bit value is cleared because it's regarded as a signed value.
>> 
>> Root cause is that we get an imprecise vector element type for AbsINode from SuperWord::compute_vector_element_type(). In any Java arithmetic operation, operands of small integer types (boolean, byte, char & short) should be promoted to int first. As vector elements of small types don't have upper bits of int, for RShiftI or AbsI operations, the compiler has to know the precise signedness info of the 1st operand. These operations shouldn't be vectorized if the signedness info is imprecise.
>> 
>> In code SuperWord::compute_vector_element_type(), we have some special handling for right shift. It limited the vectorization of small integer right shift to operations only after loads. The reason is that in the C2 compiler, only LoadNode has precise signedness info of its value. When JDK-8222074 enabled abs vectorization, it didn't involve AbsI operation into the special handling and thus introduced this bug. This patch just does the fix at this point.
>> 
>> Tested hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1, no new failure is found. Also created a new jtreg with this fix.
>
> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good.

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

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2419

From linuxhippy at gmail.com  Fri Feb  5 08:39:13 2021
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 5 Feb 2021 09:39:13 +0100
Subject: Frequent c1 compiler errors running IntelliJ with Openjdk 15
 (JavaCallWrapper::JavaCallWrapper - failed: cannot make java calls from the
 native compiler)
In-Reply-To: <1632ce78-f490-d586-fe47-c254561e6cd8@oracle.com>
References: <CAFvQSYThOqet7TK56B=qwFqEy=bbQjb3asEm0UwEd_Gsfdn2xA@mail.gmail.com>
 <1632ce78-f490-d586-fe47-c254561e6cd8@oracle.com>
Message-ID: <CAFvQSYTvC5hvFUjZJbq9DqV08fe5xz=44gWmP9Njr8n5ottf3g@mail.gmail.com>

Hi Vladimir,

It does look very similar to JDK-8217765 [1], but the bug was fixed long
> time ago.
> Please, file new bug.
>

I've just filed bug 9068933 - after I was able to reproduce the crash also
with the official 15.0.2 openjdk builds.

Thanks & best regards, Clemens

From roland at openjdk.java.net  Fri Feb  5 09:36:58 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 5 Feb 2021 09:36:58 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v5]
In-Reply-To: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
Message-ID: <BiiS5KckTFlkD2zzj_j0PWQSWYFBABbvt4WrsnG77OQ=.09fa12dc-2349-4634-a3cf-591d924febb7@github.com>

> I noticed that the SA's dumpreplaydata command fails with:
> 
> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
> 
> with a simple test program. This happens because the SA can't find the
> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
> there's nothing in our build system that hides that symbol. I had to
> move one method's definition from the header file to the cpp file for
> the symbol to be visible again.
> 
> We have a test that checks dumpreplaydata but it doesn't catch that
> problem. The test produces a replay file from a core file with the SA
> by running a simple test with -Xcomp and CICrash=1. So the replay data
> has very little or no profile data (which is what causes the problem
> above). I propose running a slightly more complicated test method and
> crashing after the method has had time to run for long enough to
> collect profile data.
> 
> The other shortcoming of the test is that it doesn't look at the
> content of the replay file. It only warns if they differ. The replay
> file produced by the VM and the one produced by the SA should be
> identical (except for comment lines). So I propose we check that.
> 
> Finally, I can't run that test on my system because core files are
> handled by systemd (I'm running some recent version of fedora). I
> suppose, the system can be configured differently but having the test
> work out the box is nice. I extended the test case to handle that.
> 
> With the improved test, there are a few differences between the VM and
> SA replay files caused by VM changes that were not mirrored in the
> SA. I fixed those.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  copyrights

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2195/files
  - new: https://git.openjdk.java.net/jdk/pull/2195/files/da2fe2be..150ea54c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2195&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2195&range=03-04

  Stats: 18 lines in 18 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2195.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2195/head:pull/2195

PR: https://git.openjdk.java.net/jdk/pull/2195

From roland at openjdk.java.net  Fri Feb  5 09:37:02 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 5 Feb 2021 09:37:02 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v4]
In-Reply-To: <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>
 <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>
Message-ID: <pYD7U1pPmAebbSIa7IdCekEV8xNMzIsf-VBD39wQN_Q=.3158ff68-0244-476c-8bbf-31a3d9192d95@github.com>

On Thu, 4 Feb 2021 18:25:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - pid in OutputAnalyzer
>>  - pid in OutputAnalyzer
>>  - Merge branch 'master' into JDK-8260296
>>  - convert all tests
>>  - Merge branch 'master' into JDK-8260296
>>  - use CoreUtils
>>  - whitespaces
>>  - SA fixes
>>  - VM fix
>>  - test
>
> LGTM, you still need to update the copyright years as @plummercj [mentioned](https://github.com/openjdk/jdk/pull/2195#issuecomment-768115732).

@iignatev thanks for the review. I updated the copyrights.

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

PR: https://git.openjdk.java.net/jdk/pull/2195

From roland at openjdk.java.net  Fri Feb  5 09:37:03 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 5 Feb 2021 09:37:03 GMT
Subject: Integrated: 8260296: SA's dumpreplaydata fails
In-Reply-To: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
Message-ID: <cz2TXinyn_GsLSonWLj_FAaSMjBPMppj3va6h8kCdxU=.5f3061a5-52d3-45f3-93d3-ab0cc126307d@github.com>

On Fri, 22 Jan 2021 14:21:52 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> I noticed that the SA's dumpreplaydata command fails with:
> 
> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
> 
> with a simple test program. This happens because the SA can't find the
> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
> there's nothing in our build system that hides that symbol. I had to
> move one method's definition from the header file to the cpp file for
> the symbol to be visible again.
> 
> We have a test that checks dumpreplaydata but it doesn't catch that
> problem. The test produces a replay file from a core file with the SA
> by running a simple test with -Xcomp and CICrash=1. So the replay data
> has very little or no profile data (which is what causes the problem
> above). I propose running a slightly more complicated test method and
> crashing after the method has had time to run for long enough to
> collect profile data.
> 
> The other shortcoming of the test is that it doesn't look at the
> content of the replay file. It only warns if they differ. The replay
> file produced by the VM and the one produced by the SA should be
> identical (except for comment lines). So I propose we check that.
> 
> Finally, I can't run that test on my system because core files are
> handled by systemd (I'm running some recent version of fedora). I
> suppose, the system can be configured differently but having the test
> work out the box is nice. I extended the test case to handle that.
> 
> With the improved test, there are a few differences between the VM and
> SA replay files caused by VM changes that were not mirrored in the
> SA. I fixed those.

This pull request has now been integrated.

Changeset: 3495febf
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3495febf
Stats:     228 lines in 20 files changed: 109 ins; 55 del; 64 mod

8260296: SA's dumpreplaydata fails

Reviewed-by: kvn, cjplummer, iignatyev

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

PR: https://git.openjdk.java.net/jdk/pull/2195

From eirbjo at gmail.com  Fri Feb  5 09:51:33 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 5 Feb 2021 10:51:33 +0100
Subject: C1 crash in LinearScan::eliminate_spill_moves
Message-ID: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>

Hi,

While developing a Java agent which does some instrumentation, I'm
observing the following C1 compilation crash quite reliably on 11, 15 and
17:

Current CompileTask:
C1:   1468  434   !   3       org.jaxen.saxpath.base.Verifier::isXMLLetter
(7201 bytes)

Stack: [0x000070000f92d000,0x000070000fa2d000],  sp=0x000070000fa2c3e0,
 free space=1020k
Native frames: (J=compiled Java code, A=aot compiled Java code,
j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x1fb1d0]  LinearScan::eliminate_spill_moves()+0x230
V  [libjvm.dylib+0x203ae0]  LinearScan::do_linear_scan()+0xc0
V  [libjvm.dylib+0x197093]  Compilation::emit_lir()+0x213
V  [libjvm.dylib+0x197dee]  Compilation::compile_java_method()+0x29e
V  [libjvm.dylib+0x1980cc]  Compilation::compile_method()+0x11c
V  [libjvm.dylib+0x1984ee]  Compilation::Compilation(AbstractCompiler*,
ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22e
V  [libjvm.dylib+0x199bde]  Compiler::compile_method(ciEnv*, ciMethod*,
int, DirectiveSet*)+0x5e
V  [libjvm.dylib+0x2d8292]
 CompileBroker::invoke_compiler_on_method(CompileTask*)+0x5b2
V  [libjvm.dylib+0x2d7bb2]  CompileBroker::compiler_thread_loop()+0x4c2

With a Java 17 fastdebug build, I observe this assertion fail:

V  [libjvm.dylib+0x123e8dd]  VMError::report_and_die(int, char const*, char
const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*,
int, unsigned long)+0x6cd
V  [libjvm.dylib+0x123eefb]  VMError::report_and_die(Thread*, void*, char
const*, int, char const*, char const*, __va_list_tag*)+0x3b
V  [libjvm.dylib+0x62a7ad]  report_vm_error(char const*, int, char const*,
char const*, ...)+0xdd
V  [libjvm.dylib+0x42c132]  LIR_OprFact::virtual_register(int,
BasicType)+0x132
V  [libjvm.dylib+0x4692a7]  MoveResolver::insert_move(Interval*,
Interval*)+0x1e7
V  [libjvm.dylib+0x469800]  MoveResolver::resolve_mappings()+0x250
V  [libjvm.dylib+0x469f02]  MoveResolver::move_insert_position(LIR_List*,
int)+0x72
V  [libjvm.dylib+0x46d40b]  LinearScanWalker::insert_move(int, Interval*,
Interval*)+0x26b
V  [libjvm.dylib+0x470ba1]  LinearScanWalker::activate_current()+0x371
V  [libjvm.dylib+0x46c682]  IntervalWalker::walk_to(int)+0xe2
V  [libjvm.dylib+0x45963d]  LinearScan::allocate_registers()+0x4ad
V  [libjvm.dylib+0x46298d]  LinearScan::do_linear_scan()+0x46d
V  [libjvm.dylib+0x3c2630]  Compilation::emit_lir()+0x150
V  [libjvm.dylib+0x3c3694]  Compilation::compile_java_method()+0x344


Some context:

As seen in the Java source file [1] for the class, the uninstrumented
method is quite large and has an unusual number of returns per instruction.

The agent is basically a code coverage instrumenter which inserts a local
variable per line of code in the beginning of the method, increments the
count on each line number and reports the total counts by calling methods
in a catch block.

To reduce the amount of instrumented code, the agent also replaces *RETURN
instructions with GOTOs to a common target where the count reporting
happens. The catch handler also jumps to this target.

If I limit the number of code lines which are allowed to be instrumented,
the compilation no longer crashes. So seems to be related to code size /
complexity somehow.

I can provide core files on request.

Cheers,
Eirik.

[1]
https://github.com/jenkinsci/jaxen/blob/V_1_1_6_Final/src/java/main/org/jaxen/saxpath/base/Verifier.java#L95

From eirbjo at gmail.com  Fri Feb  5 10:16:51 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 5 Feb 2021 11:16:51 +0100
Subject: C1 crash in LinearScan::eliminate_spill_moves
In-Reply-To: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
References: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
Message-ID: <CA+pBWhunER0hNMY4QjhyvnKBKCKdmk898ZFV7wCMd4b0wcxHhQ@mail.gmail.com>

>
>
> With a Java 17 fastdebug build, I observe this assertion fail:
>
> V  [libjvm.dylib+0x123e8dd]  VMError::report_and_die(int, char const*,
> char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char
> const*, int, unsigned long)+0x6cd
> V  [libjvm.dylib+0x123eefb]  VMError::report_and_die(Thread*, void*, char
> const*, int, char const*, char const*, __va_list_tag*)+0x3b
> V  [libjvm.dylib+0x62a7ad]  report_vm_error(char const*, int, char const*,
> char const*, ...)+0xdd
> V  [libjvm.dylib+0x42c132]  LIR_OprFact::virtual_register(int,
> BasicType)+0x132
> V  [libjvm.dylib+0x4692a7]  MoveResolver::insert_move(Interval*,
> Interval*)+0x1e7
> V  [libjvm.dylib+0x469800]  MoveResolver::resolve_mappings()+0x250
> V  [libjvm.dylib+0x469f02]  MoveResolver::move_insert_position(LIR_List*,
> int)+0x72
> V  [libjvm.dylib+0x46d40b]  LinearScanWalker::insert_move(int, Interval*,
> Interval*)+0x26b
> V  [libjvm.dylib+0x470ba1]  LinearScanWalker::activate_current()+0x371
> V  [libjvm.dylib+0x46c682]  IntervalWalker::walk_to(int)+0xe2
> V  [libjvm.dylib+0x45963d]  LinearScan::allocate_registers()+0x4ad
> V  [libjvm.dylib+0x46298d]  LinearScan::do_linear_scan()+0x46d
> V  [libjvm.dylib+0x3c2630]  Compilation::emit_lir()+0x150
> V  [libjvm.dylib+0x3c3694]  Compilation::compile_java_method()+0x344
>
>
Forgot to include the actual assertion failure message:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error ([..]/jdk/src/hotspot/share/c1/c1_LIR.hpp:732), pid=5366,
tid=23811
#  assert(res->vreg_number() == index) failed: conversion check

From vlivanov at openjdk.java.net  Fri Feb  5 10:32:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 5 Feb 2021 10:32:41 GMT
Subject: RFR: 8261152: Refine the
 compiler/vectorapi/VectorRebracket128Test.java test
In-Reply-To: <ijYvvhPffp5v8U3EnIGxxGuJUANXnfBMG6mlh-u62JU=.500e5845-b6d0-4d0e-9732-fb32ed214ea4@github.com>
References: <ijYvvhPffp5v8U3EnIGxxGuJUANXnfBMG6mlh-u62JU=.500e5845-b6d0-4d0e-9732-fb32ed214ea4@github.com>
Message-ID: <AFRkmpVsRdgwtq1Udu_k4lKKRaJHRDu6nx-Tqu_ctR4=.4edfcd9e-1396-46e1-93e2-3c95e47dfcb9@github.com>

On Fri, 5 Feb 2021 04:42:30 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> Refine test VectorRebracket128Test.java as discussed here https://github.com/openjdk/jdk16/pull/139#discussion_r567796847
> 
> 1, Explicit trigger gc in the test
> 2, Remove redundant imports
> 3, Remove weird java options

test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java line 63:

> 61:             while (true) {
> 62:                 try {
> 63:                     System.gc();

Please, give the following options a try: `-XX:ZCollectionInterval=0.01 -XX:ZFragmentationLimit=0`.
According to ZGC folks, it should force continuous GC cycles w/ ZGC.

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

PR: https://git.openjdk.java.net/jdk/pull/2422

From vlivanov at openjdk.java.net  Fri Feb  5 11:04:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 5 Feb 2021 11:04:40 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler
In-Reply-To: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
Message-ID: <vP-nQAbUU0P54kYGCK8R2cc_OBIRCk0P3TX_mgM4th8=.5cdfad98-051b-489c-9546-8f967ce2c720@github.com>

On Fri, 5 Feb 2021 03:15:15 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

> Can you please take a look whether these changes are going in the direction expected or not?

Yes, the patch is perfectly aligned with what JDK-8241502 proposes. Thanks for taking care of it.

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

PR: https://git.openjdk.java.net/jdk/pull/2420

From tobias.hartmann at oracle.com  Fri Feb  5 12:57:49 2021
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 5 Feb 2021 13:57:49 +0100
Subject: C1 crash in LinearScan::eliminate_spill_moves
In-Reply-To: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
References: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
Message-ID: <00626958-1740-ff4b-9520-51b59485a27b@oracle.com>

Hi Eirik,

thanks for reporting this issue. Could you provide the instrumented .class file and the
replay_pid*.log file that should have been generated by the crashing VM?

Thanks,
Tobias

On 05.02.21 10:51, Eirik Bj?rsn?s wrote:
> Hi,
> 
> While developing a Java agent which does some instrumentation, I'm
> observing the following C1 compilation crash quite reliably on 11, 15 and
> 17:
> 
> Current CompileTask:
> C1:   1468  434   !   3       org.jaxen.saxpath.base.Verifier::isXMLLetter
> (7201 bytes)
> 
> Stack: [0x000070000f92d000,0x000070000fa2d000],  sp=0x000070000fa2c3e0,
>  free space=1020k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.dylib+0x1fb1d0]  LinearScan::eliminate_spill_moves()+0x230
> V  [libjvm.dylib+0x203ae0]  LinearScan::do_linear_scan()+0xc0
> V  [libjvm.dylib+0x197093]  Compilation::emit_lir()+0x213
> V  [libjvm.dylib+0x197dee]  Compilation::compile_java_method()+0x29e
> V  [libjvm.dylib+0x1980cc]  Compilation::compile_method()+0x11c
> V  [libjvm.dylib+0x1984ee]  Compilation::Compilation(AbstractCompiler*,
> ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22e
> V  [libjvm.dylib+0x199bde]  Compiler::compile_method(ciEnv*, ciMethod*,
> int, DirectiveSet*)+0x5e
> V  [libjvm.dylib+0x2d8292]
>  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x5b2
> V  [libjvm.dylib+0x2d7bb2]  CompileBroker::compiler_thread_loop()+0x4c2
> 
> With a Java 17 fastdebug build, I observe this assertion fail:
> 
> V  [libjvm.dylib+0x123e8dd]  VMError::report_and_die(int, char const*, char
> const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*,
> int, unsigned long)+0x6cd
> V  [libjvm.dylib+0x123eefb]  VMError::report_and_die(Thread*, void*, char
> const*, int, char const*, char const*, __va_list_tag*)+0x3b
> V  [libjvm.dylib+0x62a7ad]  report_vm_error(char const*, int, char const*,
> char const*, ...)+0xdd
> V  [libjvm.dylib+0x42c132]  LIR_OprFact::virtual_register(int,
> BasicType)+0x132
> V  [libjvm.dylib+0x4692a7]  MoveResolver::insert_move(Interval*,
> Interval*)+0x1e7
> V  [libjvm.dylib+0x469800]  MoveResolver::resolve_mappings()+0x250
> V  [libjvm.dylib+0x469f02]  MoveResolver::move_insert_position(LIR_List*,
> int)+0x72
> V  [libjvm.dylib+0x46d40b]  LinearScanWalker::insert_move(int, Interval*,
> Interval*)+0x26b
> V  [libjvm.dylib+0x470ba1]  LinearScanWalker::activate_current()+0x371
> V  [libjvm.dylib+0x46c682]  IntervalWalker::walk_to(int)+0xe2
> V  [libjvm.dylib+0x45963d]  LinearScan::allocate_registers()+0x4ad
> V  [libjvm.dylib+0x46298d]  LinearScan::do_linear_scan()+0x46d
> V  [libjvm.dylib+0x3c2630]  Compilation::emit_lir()+0x150
> V  [libjvm.dylib+0x3c3694]  Compilation::compile_java_method()+0x344
> 
> 
> Some context:
> 
> As seen in the Java source file [1] for the class, the uninstrumented
> method is quite large and has an unusual number of returns per instruction.
> 
> The agent is basically a code coverage instrumenter which inserts a local
> variable per line of code in the beginning of the method, increments the
> count on each line number and reports the total counts by calling methods
> in a catch block.
> 
> To reduce the amount of instrumented code, the agent also replaces *RETURN
> instructions with GOTOs to a common target where the count reporting
> happens. The catch handler also jumps to this target.
> 
> If I limit the number of code lines which are allowed to be instrumented,
> the compilation no longer crashes. So seems to be related to code size /
> complexity somehow.
> 
> I can provide core files on request.
> 
> Cheers,
> Eirik.
> 
> [1]
> https://github.com/jenkinsci/jaxen/blob/V_1_1_6_Final/src/java/main/org/jaxen/saxpath/base/Verifier.java#L95
> 

From eirbjo at gmail.com  Fri Feb  5 13:28:41 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 5 Feb 2021 14:28:41 +0100
Subject: C1 crash in LinearScan::eliminate_spill_moves
In-Reply-To: <00626958-1740-ff4b-9520-51b59485a27b@oracle.com>
References: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
 <00626958-1740-ff4b-9520-51b59485a27b@oracle.com>
Message-ID: <CA+pBWhs_Eyp5eny4Xn+tb_Jtmur_CoeU4DYpYyOb11XX-FhbWA@mail.gmail.com>

Tobias,

Thanks for looking into this! I've sent you the instrumented class file and
replay file off-list.

I'm also trying to create a more minimal reproducer that I can share, but
having a hard time getting that to crash in the same way.

Thanks,
Eirik.

On Fri, Feb 5, 2021 at 1:58 PM Tobias Hartmann <tobias.hartmann at oracle.com>
wrote:

> Hi Eirik,
>
> thanks for reporting this issue. Could you provide the instrumented .class
> file and the
> replay_pid*.log file that should have been generated by the crashing VM?
>
> Thanks,
> Tobias
>
> On 05.02.21 10:51, Eirik Bj?rsn?s wrote:
> > Hi,
> >
> > While developing a Java agent which does some instrumentation, I'm
> > observing the following C1 compilation crash quite reliably on 11, 15 and
> > 17:
> >
> > Current CompileTask:
> > C1:   1468  434   !   3
>  org.jaxen.saxpath.base.Verifier::isXMLLetter
> > (7201 bytes)
> >
> > Stack: [0x000070000f92d000,0x000070000fa2d000],  sp=0x000070000fa2c3e0,
> >  free space=1020k
> > Native frames: (J=compiled Java code, A=aot compiled Java code,
> > j=interpreted, Vv=VM code, C=native code)
> > V  [libjvm.dylib+0x1fb1d0]  LinearScan::eliminate_spill_moves()+0x230
> > V  [libjvm.dylib+0x203ae0]  LinearScan::do_linear_scan()+0xc0
> > V  [libjvm.dylib+0x197093]  Compilation::emit_lir()+0x213
> > V  [libjvm.dylib+0x197dee]  Compilation::compile_java_method()+0x29e
> > V  [libjvm.dylib+0x1980cc]  Compilation::compile_method()+0x11c
> > V  [libjvm.dylib+0x1984ee]  Compilation::Compilation(AbstractCompiler*,
> > ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22e
> > V  [libjvm.dylib+0x199bde]  Compiler::compile_method(ciEnv*, ciMethod*,
> > int, DirectiveSet*)+0x5e
> > V  [libjvm.dylib+0x2d8292]
> >  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x5b2
> > V  [libjvm.dylib+0x2d7bb2]  CompileBroker::compiler_thread_loop()+0x4c2
> >
> > With a Java 17 fastdebug build, I observe this assertion fail:
> >
> > V  [libjvm.dylib+0x123e8dd]  VMError::report_and_die(int, char const*,
> char
> > const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char
> const*,
> > int, unsigned long)+0x6cd
> > V  [libjvm.dylib+0x123eefb]  VMError::report_and_die(Thread*, void*, char
> > const*, int, char const*, char const*, __va_list_tag*)+0x3b
> > V  [libjvm.dylib+0x62a7ad]  report_vm_error(char const*, int, char
> const*,
> > char const*, ...)+0xdd
> > V  [libjvm.dylib+0x42c132]  LIR_OprFact::virtual_register(int,
> > BasicType)+0x132
> > V  [libjvm.dylib+0x4692a7]  MoveResolver::insert_move(Interval*,
> > Interval*)+0x1e7
> > V  [libjvm.dylib+0x469800]  MoveResolver::resolve_mappings()+0x250
> > V  [libjvm.dylib+0x469f02]  MoveResolver::move_insert_position(LIR_List*,
> > int)+0x72
> > V  [libjvm.dylib+0x46d40b]  LinearScanWalker::insert_move(int, Interval*,
> > Interval*)+0x26b
> > V  [libjvm.dylib+0x470ba1]  LinearScanWalker::activate_current()+0x371
> > V  [libjvm.dylib+0x46c682]  IntervalWalker::walk_to(int)+0xe2
> > V  [libjvm.dylib+0x45963d]  LinearScan::allocate_registers()+0x4ad
> > V  [libjvm.dylib+0x46298d]  LinearScan::do_linear_scan()+0x46d
> > V  [libjvm.dylib+0x3c2630]  Compilation::emit_lir()+0x150
> > V  [libjvm.dylib+0x3c3694]  Compilation::compile_java_method()+0x344
> >
> >
> > Some context:
> >
> > As seen in the Java source file [1] for the class, the uninstrumented
> > method is quite large and has an unusual number of returns per
> instruction.
> >
> > The agent is basically a code coverage instrumenter which inserts a local
> > variable per line of code in the beginning of the method, increments the
> > count on each line number and reports the total counts by calling methods
> > in a catch block.
> >
> > To reduce the amount of instrumented code, the agent also replaces
> *RETURN
> > instructions with GOTOs to a common target where the count reporting
> > happens. The catch handler also jumps to this target.
> >
> > If I limit the number of code lines which are allowed to be instrumented,
> > the compilation no longer crashes. So seems to be related to code size /
> > complexity somehow.
> >
> > I can provide core files on request.
> >
> > Cheers,
> > Eirik.
> >
> > [1]
> >
> https://github.com/jenkinsci/jaxen/blob/V_1_1_6_Final/src/java/main/org/jaxen/saxpath/base/Verifier.java#L95
> >
>

From tobias.hartmann at oracle.com  Fri Feb  5 13:33:53 2021
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 5 Feb 2021 14:33:53 +0100
Subject: [External] : Re: C1 crash in LinearScan::eliminate_spill_moves
In-Reply-To: <CA+pBWhs_Eyp5eny4Xn+tb_Jtmur_CoeU4DYpYyOb11XX-FhbWA@mail.gmail.com>
References: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
 <00626958-1740-ff4b-9520-51b59485a27b@oracle.com>
 <CA+pBWhs_Eyp5eny4Xn+tb_Jtmur_CoeU4DYpYyOb11XX-FhbWA@mail.gmail.com>
Message-ID: <e478a2f6-d053-50e6-ee0c-7d174255eb2a@oracle.com>

Hi Eirik,

On 05.02.21 14:28, Eirik Bj?rsn?s wrote:
> Thanks for looking into this! I've sent you the instrumented class file and replay file off-list.

Perfect, thanks a lot! I can reproduce the issue and filed
https://bugs.openjdk.java.net/browse/JDK-8261235 to investigate.

Best regards,
Tobias


From eirbjo at gmail.com  Fri Feb  5 15:20:17 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 5 Feb 2021 16:20:17 +0100
Subject: C1 crash in LinearScan::eliminate_spill_moves
In-Reply-To: <CA+pBWhs_Eyp5eny4Xn+tb_Jtmur_CoeU4DYpYyOb11XX-FhbWA@mail.gmail.com>
References: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
 <00626958-1740-ff4b-9520-51b59485a27b@oracle.com>
 <CA+pBWhs_Eyp5eny4Xn+tb_Jtmur_CoeU4DYpYyOb11XX-FhbWA@mail.gmail.com>
Message-ID: <CA+pBWhtifnYOtLJ7v2ZtEARDUZfOOgd5VRxFt2pf=io075+Mzg@mail.gmail.com>

>
> I'm also trying to create a more minimal reproducer that I can share, but
> having a hard time getting that to crash in the same way.
>

Here's a self contained Maven project with a minimal (or at least
"reduced") reproducer for JDK-8261235:

https://github.com/eirbjo/jdk-8261235-reproducer

Here's the main method:

https://github.com/eirbjo/jdk-8261235-reproducer/blob/main/src/main/java/com/github/eirbjo/JDK8261235Reproducer.java

Tobias: This produces an instrumented class file with a lot less cruft than
the one I sent you so could possibly simplify analysis.

Thanks,
Eirik.

From vlivanov at openjdk.java.net  Fri Feb  5 17:35:52 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 5 Feb 2021 17:35:52 GMT
Subject: RFR: 8259430: C2: assert(in_vt->length() == out_vt->length()) failed:
 mismatch on number of elements
Message-ID: <q5UXCU4eIfYEiJuz8odYLk2nUDnSxC5cliVDon2Dy4I=.624aab36-5104-40be-8c4c-29f26df15c88@github.com>

Another problem caused by pathological cases (in effectively dead code): `VectorUnboxNode::Ideal()/Value()` ignore cast nodes (even the ones carrying control dependency) to reveal `VectorBox` and sometimes it exposes type mismatches between box/unbox operations which are impossible in practice. 

Proposed fix turns the assert into a runtime check to ignore problematic IR shape.

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

Commit messages:
 - 8259430: C2: assert(in_vt->length() == out_vt->length()) failed: mismatch on number of elements

Changes: https://git.openjdk.java.net/jdk/pull/2353/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2353&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259430
  Stats: 23 lines in 2 files changed: 6 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2353.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2353/head:pull/2353

PR: https://git.openjdk.java.net/jdk/pull/2353

From kvn at openjdk.java.net  Fri Feb  5 17:49:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 5 Feb 2021 17:49:42 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler
In-Reply-To: <vP-nQAbUU0P54kYGCK8R2cc_OBIRCk0P3TX_mgM4th8=.5cdfad98-051b-489c-9546-8f967ce2c720@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <vP-nQAbUU0P54kYGCK8R2cc_OBIRCk0P3TX_mgM4th8=.5cdfad98-051b-489c-9546-8f967ce2c720@github.com>
Message-ID: <0azhJ4pD5Tq_lkpPtYMpQBjokflcSQEdWP2Rz9HBm6k=.c3ece6fd-1ae7-49ea-a6eb-ec88a9fbd54d@github.com>

On Fri, 5 Feb 2021 11:02:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Relates to: https://bugs.openjdk.java.net/browse/JDK-8241502
>> Tested on: Linux tier1, 2 and 3
>> 
>> Can you please take a look whether these changes are going in the direction expected or not? If it is, I'll continue working on the `JDK-8241502` but I'd like to split it in a few PRs since it's a lot of changes.
>
>> Can you please take a look whether these changes are going in the direction expected or not?
> 
> Yes, the patch is perfectly aligned with what JDK-8241502 proposes. Thanks for taking care of it.

I agree. We wanted to do that for long time.

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

PR: https://git.openjdk.java.net/jdk/pull/2420

From kvn at openjdk.java.net  Fri Feb  5 17:56:48 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 5 Feb 2021 17:56:48 GMT
Subject: RFR: 8259430: C2: assert(in_vt->length() == out_vt->length())
 failed: mismatch on number of elements
In-Reply-To: <q5UXCU4eIfYEiJuz8odYLk2nUDnSxC5cliVDon2Dy4I=.624aab36-5104-40be-8c4c-29f26df15c88@github.com>
References: <q5UXCU4eIfYEiJuz8odYLk2nUDnSxC5cliVDon2Dy4I=.624aab36-5104-40be-8c4c-29f26df15c88@github.com>
Message-ID: <WjK9rTIqYIQ9eiQXJi-Gs6_mPT1TLhWtIYbDGiZGrlc=.c166cd58-fbc0-4c97-8f1a-c4f16b7c6d42@github.com>

On Tue, 2 Feb 2021 12:57:11 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Another problem caused by pathological cases (in effectively dead code): `VectorUnboxNode::Ideal()/Value()` ignore cast nodes (even the ones carrying control dependency) to reveal `VectorBox` and sometimes it exposes type mismatches between box/unbox operations which are impossible in practice. 
> 
> Proposed fix turns the assert into a runtime check to ignore problematic IR shape.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2353

From vlivanov at openjdk.java.net  Fri Feb  5 18:08:52 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 5 Feb 2021 18:08:52 GMT
Subject: RFR: 8261250: Dependencies: Remove unused dependency types
Message-ID: <2-SBc7bcjQnndYbBWgQFNs4nY_OjM-5_E5f3g2-OEiA=.d235e241-adc8-4f51-8bf9-66915f068a95@github.com>

Remove support of unused dependency types from Dependencies.

Testing: 
- [x] hs-precheckin-comp, hs-tier1, hs-tier2.

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

Commit messages:
 - Formatting
 - Formatting cleanups
 - Remove assert_common_3
 - Remove find_exclusive_concrete_subtypes
 - Remove concrete_with_no_concrete_subtype
 - Remove abstract_with_no_concrete_subtype
 - Remove abstract_with_exclusive_concrete_subtype
 - Remove exclusive_concrete_methods

Changes: https://git.openjdk.java.net/jdk/pull/2431/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2431&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261250
  Stats: 253 lines in 2 files changed: 1 ins; 238 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2431.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2431/head:pull/2431

PR: https://git.openjdk.java.net/jdk/pull/2431

From iklam at openjdk.java.net  Fri Feb  5 18:46:43 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 5 Feb 2021 18:46:43 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler
In-Reply-To: <0azhJ4pD5Tq_lkpPtYMpQBjokflcSQEdWP2Rz9HBm6k=.c3ece6fd-1ae7-49ea-a6eb-ec88a9fbd54d@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <vP-nQAbUU0P54kYGCK8R2cc_OBIRCk0P3TX_mgM4th8=.5cdfad98-051b-489c-9546-8f967ce2c720@github.com>
 <0azhJ4pD5Tq_lkpPtYMpQBjokflcSQEdWP2Rz9HBm6k=.c3ece6fd-1ae7-49ea-a6eb-ec88a9fbd54d@github.com>
Message-ID: <d40n9RxaYEqp-6UU7qDQ9rJYrSZ0gXKTT9jqTlylfvU=.8fbcfe20-5f2e-48e8-a189-771701645d9b@github.com>

On Fri, 5 Feb 2021 17:47:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> Can you please take a look whether these changes are going in the direction expected or not?
>> 
>> Yes, the patch is perfectly aligned with what JDK-8241502 proposes. Thanks for taking care of it.
>
> I agree. We wanted to do that for long time.

I am curious if the x86_64.o file changes in any significant way (speed of size).

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

PR: https://git.openjdk.java.net/jdk/pull/2420

From kvn at openjdk.java.net  Fri Feb  5 19:02:41 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 5 Feb 2021 19:02:41 GMT
Subject: RFR: 8261250: Dependencies: Remove unused dependency types
In-Reply-To: <2-SBc7bcjQnndYbBWgQFNs4nY_OjM-5_E5f3g2-OEiA=.d235e241-adc8-4f51-8bf9-66915f068a95@github.com>
References: <2-SBc7bcjQnndYbBWgQFNs4nY_OjM-5_E5f3g2-OEiA=.d235e241-adc8-4f51-8bf9-66915f068a95@github.com>
Message-ID: <pn91h-0ZO4MpLo0cTzcUmDI7CIVov4tQMXXpEsJWaDE=.14ecce39-c938-4ef8-b2de-6e2a1c076873@github.com>

On Fri, 5 Feb 2021 17:58:06 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Remove support of unused dependency types from Dependencies.
> 
> Testing: 
> - [x] hs-precheckin-comp, hs-tier1, hs-tier2.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2431

From ogatak at openjdk.java.net  Fri Feb  5 21:21:43 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Fri, 5 Feb 2021 21:21:43 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v4]
In-Reply-To: <CY6bEpMoh7F1l66dSrJoeO0GcAK4x77a4zHfDVtgtig=.eb836926-4db4-4d70-bf4c-a0e4d44c938b@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <2CXH3zvUkBfqLrr8SPpD-x3RcSbFzw0S6NGLWgtirQ8=.0df1a0c8-3ac2-4e21-9e6a-f0b43a3ae20c@github.com>
 <CY6bEpMoh7F1l66dSrJoeO0GcAK4x77a4zHfDVtgtig=.eb836926-4db4-4d70-bf4c-a0e4d44c938b@github.com>
Message-ID: <Uk6ZzTbKkozsmxyRdosh_WS9NgFK7WDmtnD-VyaY__Q=.6b9996d2-e3b5-470e-b520-8e9ff00c9b36@github.com>

On Wed, 3 Feb 2021 17:35:33 GMT, Corey Ashford <cashford at openjdk.org> wrote:

>> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed pla and psubi and adjusted spacing based on review comments
>
> Looks good!  Thanks for the additional formatting cleanup

@CoreyAshford Thank you for your review.

@TheRealMDoerr Thank you for your suggestion.  I think I understand the mechanism.  I'll update my patch after verifing my change and running jtreg.

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

PR: https://git.openjdk.java.net/jdk/pull/2095

From enikitin at openjdk.java.net  Fri Feb  5 22:20:00 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 5 Feb 2021 22:20:00 GMT
Subject: RFR: 8058176: [mlvm] Tests should tolerate exceptions caused by code
 cache exhaustion.
Message-ID: <WF4zjGC1xoxvLj1yoz3JSWjVnjf1py8k5JVn5cfUbv4=.8ca36940-de1e-480b-a32c-07f63bc173ea@github.com>

A repetition of the #1622.

1. Normalise meth/stress/compiler/i2c_c2i/Test.java to use MultiThreadedTest framework;
2. Adjust MultiThreadedTest in order to accomodate the i2c_c2i test (add prepareThread method and logic);
3. Add ThrowableTolerance and DefaultThrowableTolerance as ways to control what Throwables are accepted;
4. Adjust MultiThreadedTest to catch Throwables and check if they are accepted;
5. Adjust individual tests to catch possible Throwables and check if they are accepted;
6. Un-problemlist the failing tests.

Testing vmTestBase/vm/mlvm/meth/stress run on macos-linux-windows (30 runs each) in x64 configurations, rebased on top of latest code base. Code cache was limited `-XX:ReservedCodeCacheSize=8M` as suggested in the case.

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

Commit messages:
 - 8058176: [mlvm] tests should tolerate exceptions caused by code cache exhaustion

Changes: https://git.openjdk.java.net/jdk/pull/2440/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2440&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8058176
  Stats: 340 lines in 12 files changed: 245 ins; 31 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2440.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2440/head:pull/2440

PR: https://git.openjdk.java.net/jdk/pull/2440

From jwilhelm at openjdk.java.net  Sat Feb  6 00:26:03 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sat, 6 Feb 2021 00:26:03 GMT
Subject: RFR: Merge jdk16
Message-ID: <ZxlL0N_-9HAJN2rlL4g61FMB918hkZlnqdjzKe3rEus=.f21d4fb2-192e-4238-8f7c-a9a75e6356ad@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8260709: C2: assert(false) failed: unscheduable graph
 - 8260585: AArch64: Wrong code generated for shifting right and accumulating four unsigned short integers

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2441&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2441&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2441/files
  Stats: 549 lines in 5 files changed: 527 ins; 16 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2441.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2441/head:pull/2441

PR: https://git.openjdk.java.net/jdk/pull/2441

From jwilhelm at openjdk.java.net  Sat Feb  6 00:32:44 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sat, 6 Feb 2021 00:32:44 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <ZxlL0N_-9HAJN2rlL4g61FMB918hkZlnqdjzKe3rEus=.f21d4fb2-192e-4238-8f7c-a9a75e6356ad@github.com>
References: <ZxlL0N_-9HAJN2rlL4g61FMB918hkZlnqdjzKe3rEus=.f21d4fb2-192e-4238-8f7c-a9a75e6356ad@github.com>
Message-ID: <PAZdXHKqkJjQdvpdHL8gTRtN_R0IQBfpP-dPJy80Ki0=.83b16490-aad1-43ae-8543-fbccbe9b105d@github.com>

On Sat, 6 Feb 2021 00:19:38 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: d7acfae3
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d7acfae3
Stats:     549 lines in 5 files changed: 527 ins; 16 del; 6 mod

Merge

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

PR: https://git.openjdk.java.net/jdk/pull/2441

From iveresov at openjdk.java.net  Sat Feb  6 01:38:48 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Sat, 6 Feb 2021 01:38:48 GMT
Subject: RFR: 8261270: MakeMethodNotCompilableTest fails with
 -XX:TieredStopAtLevel={1, 2, 3}
Message-ID: <rCGhy21lDc9GNl7rFFRejIHqLv2vRKzC9KQLJzS4KaI=.180085ac-a7c7-466b-a603-a037736c5f48@github.com>

JDK-8251462 changed semantics of CompilationPolicy::highest_compile_level() and CompilationPolicy::can_be_compiled() to take into the account compiler availability due to command line flags restrictions. For example, if C2 is not available because of the TieredStopAtLevel setting, the answer to these queries will be that the highest level is 3, and that methods can't be compiled at level 4. 

MakeMethodNotCompilableTest.java assumes (even in the presence of the mentioned restrictions) that with tiered compilation it is always the case that both compilers can be used.

This change fixes the test to take this into account.

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

Commit messages:
 - Adjust the test to support new semantics

Changes: https://git.openjdk.java.net/jdk/pull/2443/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2443&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261270
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2443.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2443/head:pull/2443

PR: https://git.openjdk.java.net/jdk/pull/2443

From kvn at openjdk.java.net  Sat Feb  6 04:01:41 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 6 Feb 2021 04:01:41 GMT
Subject: RFR: 8261270: MakeMethodNotCompilableTest fails with
 -XX:TieredStopAtLevel={1, 2, 3}
In-Reply-To: <rCGhy21lDc9GNl7rFFRejIHqLv2vRKzC9KQLJzS4KaI=.180085ac-a7c7-466b-a603-a037736c5f48@github.com>
References: <rCGhy21lDc9GNl7rFFRejIHqLv2vRKzC9KQLJzS4KaI=.180085ac-a7c7-466b-a603-a037736c5f48@github.com>
Message-ID: <9Lu_O8QDeuZ0Zn8MQcMnXs0X3Kxw9IXpVqmosXlyrmo=.5d89a8aa-7e20-435f-b21c-bc16c00f49d5@github.com>

On Sat, 6 Feb 2021 01:34:15 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> JDK-8251462 changed semantics of CompilationPolicy::highest_compile_level() and CompilationPolicy::can_be_compiled() to take into the account compiler availability due to command line flags restrictions. For example, if C2 is not available because of the TieredStopAtLevel setting, the answer to these queries will be that the highest level is 3, and that methods can't be compiled at level 4. 
> 
> MakeMethodNotCompilableTest.java assumes (even in the presence of the mentioned restrictions) that with tiered compilation it is always the case that both compilers can be used.
> 
> This change fixes the test to take this into account.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2443

From iveresov at openjdk.java.net  Sat Feb  6 20:47:00 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Sat, 6 Feb 2021 20:47:00 GMT
Subject: RFR: 8261229: MethodData is not correctly initialized with
 TieredStopAtLevel=3 [v2]
In-Reply-To: <-ReDb8Jf-EIuYNyQltIaKSF1tUPmswp6kx_mciU5Fvk=.31d8565c-26fe-4f7f-8b88-55bcc996bfca@github.com>
References: <-ReDb8Jf-EIuYNyQltIaKSF1tUPmswp6kx_mciU5Fvk=.31d8565c-26fe-4f7f-8b88-55bcc996bfca@github.com>
Message-ID: <-RNQ0M9cHiIX7na2DnUnhucXZ35JILV8sdMO0oAeaOI=.42b67e78-71c8-4bcf-aaa7-22889fbfbba5@github.com>

> Mostly a typo in compilation mode ergonomics that selected a quick-only mode essentially when the user specified TieredStopAtLevel={1,2,3}. The quick-only mode has an optimization that eliminates parts of the MDO since they are not needed. Meanwhile, the WB API considered it a fair game to request a level 3 compile, that requires a full MDO.
> 
> The fix corrects the original issue and also tries to be extra defensive with WB API (since it's semantics is not clearly specified) by always allocating full MDO if WB API is on.

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Remove WB defence

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2444/files
  - new: https://git.openjdk.java.net/jdk/pull/2444/files/4086df33..c57457b2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2444&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2444&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2444.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2444/head:pull/2444

PR: https://git.openjdk.java.net/jdk/pull/2444

From iveresov at openjdk.java.net  Sat Feb  6 20:47:00 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Sat, 6 Feb 2021 20:47:00 GMT
Subject: RFR: 8261229: MethodData is not correctly initialized with
 TieredStopAtLevel=3
In-Reply-To: <QJhHWxNqC6Vc3Iqrj-xkKRWhXerf1L_29TpLTPl3Xts=.ae95d056-9694-4fdc-bd17-a60af0eaa99e@github.com>
References: <-ReDb8Jf-EIuYNyQltIaKSF1tUPmswp6kx_mciU5Fvk=.31d8565c-26fe-4f7f-8b88-55bcc996bfca@github.com>
 <QJhHWxNqC6Vc3Iqrj-xkKRWhXerf1L_29TpLTPl3Xts=.ae95d056-9694-4fdc-bd17-a60af0eaa99e@github.com>
Message-ID: <cMRyv1tdm45SJoJtR09B-ZxG-QZ2p7e5Dz9j0ErTFIQ=.220831f0-eb3c-44b9-ae48-ee94ad6229a5@github.com>

On Sat, 6 Feb 2021 17:49:43 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> I don't think we should adjust the product code to behave differently just to satisfy the incorrect assumptions of WhiteBox. it also kinda defeats the purpose of WhiteBox API as we won't be able to go thru the same code path.
> 
> -- Igor

Ok, fair enough, I'll remove it. But we should probably make WB more robust in this department - it needs to be throwing exceptions in cases when the user tries to submit compilation requests for unsupported levels.

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

PR: https://git.openjdk.java.net/jdk/pull/2444

From github.com+2249648+johntortugo at openjdk.java.net  Sat Feb  6 23:56:00 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Sat, 6 Feb 2021 23:56:00 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler [v2]
In-Reply-To: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
Message-ID: <q1adSlQPrjYAB8q48fgfhPVAlCAgt7MY8vj0oeEwRZI=.459bee39-08a1-4dd1-af7b-38b93578473b@github.com>

> Relates to: https://bugs.openjdk.java.net/browse/JDK-8241502
> Tested on: Linux tier1, 2 and 3
> 
> Can you please take a look whether these changes are going in the direction expected or not? If it is, I'll continue working on the `JDK-8241502` but I'd like to split it in a few PRs since it's a lot of changes.

John Tortugo has updated the pull request incrementally with one additional commit since the last revision:

  Second part of conversions.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2420/files
  - new: https://git.openjdk.java.net/jdk/pull/2420/files/8198a988..25824fde

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=00-01

  Stats: 141 lines in 1 file changed: 45 ins; 0 del; 96 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2420.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2420/head:pull/2420

PR: https://git.openjdk.java.net/jdk/pull/2420

From pli at openjdk.java.net  Sun Feb  7 01:18:43 2021
From: pli at openjdk.java.net (Pengfei Li)
Date: Sun, 7 Feb 2021 01:18:43 GMT
Subject: Integrated: 8261022: Fix incorrect result of Math.abs() with char type
In-Reply-To: <kysXfJ4zGQ184XiAWdxDWrbDwo20G8cfKDs17P2wIWQ=.c26b40d7-6fbe-4d43-8633-3e92f2b997bb@github.com>
References: <kysXfJ4zGQ184XiAWdxDWrbDwo20G8cfKDs17P2wIWQ=.c26b40d7-6fbe-4d43-8633-3e92f2b997bb@github.com>
Message-ID: <1aUM7cENTBMCGaw2vbRyhhFRSD2vZsQ44nYpqZAiKuc=.89115373-caf7-465a-b723-50d00a0592e5@github.com>

On Fri, 5 Feb 2021 02:29:33 GMT, Pengfei Li <pli at openjdk.org> wrote:

> Math.abs() with char type may return incorrect result after C2 superword optimization. It can be reproduced by below Java code and commands.
> 
> public class Bug {
>     private static int SIZE = 60000;
>     private static char[] a = new char[SIZE];
>     private static char[] b = new char[SIZE];
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < SIZE; i++) {
>             a[i] = b[i] = (char) i;
>         }
>         for (int i = 0; i < SIZE; i++) {
>             a[i] = (char) Math.abs(a[i]);
>         }
>         for (int i = 0; i < SIZE; i++) {
>             if (a[i] != b[i]) {
>                 throw new RuntimeException("Broken!");
>             }
>         }
>         System.out.println("OK");
>     }
> }
> 
> // $ java -Xint Bug
> // OK
> 
> // $ java -Xcomp -XX:-TieredCompilation Bug
> // Exception in thread "main" java.lang.RuntimeException: Broken!
> //         at Bug.main(Bug.java:15)
> 
> In Java, 'char' is a 16-bit unsigned integer type and the abs() method should always return the value of its input. But with C2 vectorization, the sign bit of the 16-bit value is cleared because it's regarded as a signed value.
> 
> Root cause is that we get an imprecise vector element type for AbsINode from SuperWord::compute_vector_element_type(). In any Java arithmetic operation, operands of small integer types (boolean, byte, char & short) should be promoted to int first. As vector elements of small types don't have upper bits of int, for RShiftI or AbsI operations, the compiler has to know the precise signedness info of the 1st operand. These operations shouldn't be vectorized if the signedness info is imprecise.
> 
> In code SuperWord::compute_vector_element_type(), we have some special handling for right shift. It limited the vectorization of small integer right shift to operations only after loads. The reason is that in the C2 compiler, only LoadNode has precise signedness info of its value. When JDK-8222074 enabled abs vectorization, it didn't involve AbsI operation into the special handling and thus introduced this bug. This patch just does the fix at this point.
> 
> Tested hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1, no new failure is found. Also created a new jtreg with this fix.

This pull request has now been integrated.

Changeset: 7a2db858
Author:    Pengfei Li <pli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7a2db858
Stats:     77 lines in 2 files changed: 66 ins; 1 del; 10 mod

8261022: Fix incorrect result of Math.abs() with char type

Reviewed-by: thartmann, neliasso

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

PR: https://git.openjdk.java.net/jdk/pull/2419

From iveresov at openjdk.java.net  Sun Feb  7 02:27:43 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Sun, 7 Feb 2021 02:27:43 GMT
Subject: Integrated: 8261270: MakeMethodNotCompilableTest fails with
 -XX:TieredStopAtLevel={1, 2, 3}
In-Reply-To: <rCGhy21lDc9GNl7rFFRejIHqLv2vRKzC9KQLJzS4KaI=.180085ac-a7c7-466b-a603-a037736c5f48@github.com>
References: <rCGhy21lDc9GNl7rFFRejIHqLv2vRKzC9KQLJzS4KaI=.180085ac-a7c7-466b-a603-a037736c5f48@github.com>
Message-ID: <BuWPEATVGMILvb46pIfjlXv8ha7mngkPcBfFnlBs46o=.448a8024-cd05-4820-97d0-07638323cb05@github.com>

On Sat, 6 Feb 2021 01:34:15 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> JDK-8251462 changed semantics of CompilationPolicy::highest_compile_level() and CompilationPolicy::can_be_compiled() to take into the account compiler availability due to command line flags restrictions. For example, if C2 is not available because of the TieredStopAtLevel setting, the answer to these queries will be that the highest level is 3, and that methods can't be compiled at level 4. 
> 
> MakeMethodNotCompilableTest.java assumes (even in the presence of the mentioned restrictions) that with tiered compilation it is always the case that both compilers can be used.
> 
> This change fixes the test to take this into account.

This pull request has now been integrated.

Changeset: 0e18634b
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0e18634b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8261270: MakeMethodNotCompilableTest fails with -XX:TieredStopAtLevel={1,2,3}

Reviewed-by: kvn

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

PR: https://git.openjdk.java.net/jdk/pull/2443

From dongbo at openjdk.java.net  Sun Feb  7 07:57:57 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sun, 7 Feb 2021 07:57:57 GMT
Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
 [v2]
In-Reply-To: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
References: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
Message-ID: <ab1pyz3Iyiwh9tDlS9y5QbZuivhe2qNs9BFetreqWcA=.5388a0f3-5b0d-4620-96ce-9f747ddb2097@github.com>

> As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`.
> 
> In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`.
> I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found.
> The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4].
> 
> This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`.
> 
> [1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803
> [2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95
> [3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e
> [4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070

Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8258953: AArch64: move NEON instructions to aarch64_neon.ad

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

Changes: https://git.openjdk.java.net/jdk/pull/2273/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2273&range=01
  Stats: 5661 lines in 3 files changed: 3216 ins; 2435 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2273/head:pull/2273

PR: https://git.openjdk.java.net/jdk/pull/2273

From dongbo at openjdk.java.net  Sun Feb  7 08:05:43 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sun, 7 Feb 2021 08:05:43 GMT
Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
 [v2]
In-Reply-To: <lbQOLnB1EvIN27mCZWlifjwnE9kdN5IJSz74O1ibTZI=.9e94cfda-09a4-4ed3-add0-25f3ef0896fb@github.com>
References: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
 <MfYLgDMBJtH0UqijF2WEWSJ6odtcEa65J28e83IH5wU=.cd4cd6ce-546b-4c6b-b078-001b5b9e94ea@github.com>
 <lbQOLnB1EvIN27mCZWlifjwnE9kdN5IJSz74O1ibTZI=.9e94cfda-09a4-4ed3-add0-25f3ef0896fb@github.com>
Message-ID: <nwBQXOD01FOyGk4D_7-dKmtRYwiv0lMZ6r0s7QIlvlU=.78dea815-4f91-4f15-a74a-f2e882de1589@github.com>

On Thu, 28 Jan 2021 12:09:36 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> I managed to sort all the instructs and compare them with and without the patch. They are general the same except for some trailing whitespaces and typos you mentioned.
>
>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_
>> 
>> On 1/28/21 10:40 AM, Ningsheng Jian wrote:
>> 
>> > I see you have fixed this typo, from ushr to usra. I presume original version generates wrong code and produces wrong results for specific case? If so, do you think it deserves a separate fix, e.g. for jdk16?
>> 
>> It does. This patch should change nothing at all, except moving
>> text from A to B.
>> 
>> --
>> Andrew Haley (he/him)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> https://keybase.io/andrewhaley
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
> @nsjian @theRealAph Thank you for the comments. I'll raise a seperate PR to fix this right now.
> 
> BTW, since Andrew says we should change nothing at all in this move, do you think we should also do the things below in separtate PRs?
> 1. fix the typo of `vor8B`.
> 2. supporting vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`.

Updated. The whitespaces mentioned are addressed.
The format typo fix in `vor8B` is kept, other instructions are appended to aarch64_neon.ad.

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

PR: https://git.openjdk.java.net/jdk/pull/2273

From github.com+25214855+casparcwang at openjdk.java.net  Sun Feb  7 10:01:46 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Sun, 7 Feb 2021 10:01:46 GMT
Subject: RFR: 8261152: Refine the
 compiler/vectorapi/VectorRebracket128Test.java test
In-Reply-To: <AFRkmpVsRdgwtq1Udu_k4lKKRaJHRDu6nx-Tqu_ctR4=.4edfcd9e-1396-46e1-93e2-3c95e47dfcb9@github.com>
References: <ijYvvhPffp5v8U3EnIGxxGuJUANXnfBMG6mlh-u62JU=.500e5845-b6d0-4d0e-9732-fb32ed214ea4@github.com>
 <AFRkmpVsRdgwtq1Udu_k4lKKRaJHRDu6nx-Tqu_ctR4=.4edfcd9e-1396-46e1-93e2-3c95e47dfcb9@github.com>
Message-ID: <kezJbxGH2AECdEXk-i_5iM6Px1n-5weB11qVmoMrxlA=.81569c78-34c6-4474-b0d0-313e689d3c06@github.com>

On Fri, 5 Feb 2021 10:29:34 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Refine test VectorRebracket128Test.java as discussed here https://github.com/openjdk/jdk16/pull/139#discussion_r567796847
>> 
>> 1, Explicit trigger gc in the test
>> 2, Remove redundant imports
>> 3, Remove weird java options
>
> test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java line 63:
> 
>> 61:             while (true) {
>> 62:                 try {
>> 63:                     System.gc();
> 
> Please, give the following options a try: `-XX:ZCollectionInterval=0.01 -XX:ZFragmentationLimit=0`.
> According to ZGC folks, it should force continuous GC cycles w/ ZGC.

The original version with option 'CICompilerCount' passed (passed means the bug is not triggered) 5 times in 100 runs, the background gc version passed 8 times in 100 runs. `ZCollectionInterval` passed 44 in 100 runs. 

Explicit trigger gc in the background thread and timer-based gc triggering perform the same thing, it's really strange to    behave differently in triggering the bug. The reason I guess is: the load barrier missing bug will only be triggered when the object is relocated and the pointer in another object is not remapped, which means the time window is very short, different options may pose different execution path (which creates different objects, threads, etc.).

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

PR: https://git.openjdk.java.net/jdk/pull/2422

From github.com+10482586+therealeliu at openjdk.java.net  Sun Feb  7 10:08:42 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Sun, 7 Feb 2021 10:08:42 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap
In-Reply-To: <JEEX1TPNO8BU_OINsIJ6PJ1_-474D6j-66GjkjsIwsk=.0a7dd429-937f-4e6b-afff-fcfc6b2fbef5@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <bLyRf5fLACZqgGvxO9Ad-YdjioIaqPYAyRxR0rsGDbc=.e9d0040a-c216-419e-aed2-5ac197060797@github.com>
 <JEEX1TPNO8BU_OINsIJ6PJ1_-474D6j-66GjkjsIwsk=.0a7dd429-937f-4e6b-afff-fcfc6b2fbef5@github.com>
Message-ID: <O4kdK5jmzrvUF1qSmNeGMP5avsUOqBfWg4BS7sJLixo=.d618d76d-141b-4cc0-ba52-8bdddc0a0217@github.com>

On Fri, 5 Feb 2021 07:15:55 GMT, Wang Huang <whuang at openjdk.org> wrote:

> > I was wandering if we can remove the useless `if` as it's always true in this case. Do you know why this kind of `if` haven't been eliminated by GVN phase?

> It is a good idea . However, C2 might not optimize some `if` for many reasons:
> 
> * This situation can also be triggered in calling other method. For example :
> 
> ```
> public class MyBenchmark {
> 
>   static int[] data = new int[10000];
> 
>   static {
>       for(int i = 0; i < data.length; ++i) {
>           data[i] = 299;
>       }
>   }
> 
>   @Benchmark
>   public void testMethod(Blackhole bh) {
>     int sum = 0;
>     for (int i = 0; i < data.length; i++) {
>       Integer ii = Integer.valueOf(data[i]);
>       sum += abs(ii);
>     }
>     bh.consume(sum);
>   }
> 
>   public int abs(Integer ii) {
>     if (ii.intValue() > 0) {
>       return ii.intValue();
>     } else {
>       return 0 - ii.intValue();
>     }
>   }
> }
> ```
> 
> The method `abs` will be inlined when it is hot enough. However, this `If` can not be eliminated.
> 
> * The case in the JDK-8261137 is just like this case:
> 
> ```
> public class MyBenchmark {
> 
>     static int[] data = new int[10000];
> 
>     static {
>         for(int i = 0; i < data.length; ++i) {
>             data[i] = i * 1337 % 7331;
>         }
>     }
> 
>     @Benchmark
>     public void testMethod(Blackhole bh) {
>       int sum = 0;
>       for (int i = 0; i < data.length; i++) {
>           Integer ii = Integer.valueOf(data[i]);
>           if (i < 100000) {
>               sum += ii.intValue();
>           }
>       }
>       bh.consume(sum);
>     }
> }
> ```

Thanks for your explanation. This makes more sense to me now.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From aph at openjdk.java.net  Sun Feb  7 10:58:44 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sun, 7 Feb 2021 10:58:44 GMT
Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
 [v2]
In-Reply-To: <ab1pyz3Iyiwh9tDlS9y5QbZuivhe2qNs9BFetreqWcA=.5388a0f3-5b0d-4620-96ce-9f747ddb2097@github.com>
References: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
 <ab1pyz3Iyiwh9tDlS9y5QbZuivhe2qNs9BFetreqWcA=.5388a0f3-5b0d-4620-96ce-9f747ddb2097@github.com>
Message-ID: <H-dosjc_bntzD3jWXQja4M263fXIXQjXTUWQStZdTB0=.4b7cf009-bc0c-44eb-843a-fc1cb1e0007c@github.com>

On Sun, 7 Feb 2021 07:57:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`.
>> 
>> In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`.
>> I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found.
>> The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4].
>> 
>> This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`.
>> 
>> [1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803
>> [2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95
>> [3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e
>> [4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070
>
> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8258953: AArch64: move NEON instructions to aarch64_neon.ad

That looks fine. I haven't been able to check that all this patch does is move code from aarch64.ad to aarch64_neon.ad, but I believe you.

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

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2273

From njian at openjdk.java.net  Mon Feb  8 02:08:41 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 8 Feb 2021 02:08:41 GMT
Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
 [v2]
In-Reply-To: <ab1pyz3Iyiwh9tDlS9y5QbZuivhe2qNs9BFetreqWcA=.5388a0f3-5b0d-4620-96ce-9f747ddb2097@github.com>
References: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
 <ab1pyz3Iyiwh9tDlS9y5QbZuivhe2qNs9BFetreqWcA=.5388a0f3-5b0d-4620-96ce-9f747ddb2097@github.com>
Message-ID: <HYn0pFJyu5_2rzUVn0A0wIKla3aaKyR0ADOBT37OVHo=.1a13178d-9d34-408c-ae26-d65fce95d20a@github.com>

On Sun, 7 Feb 2021 07:57:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`.
>> 
>> In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`.
>> I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found.
>> The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4].
>> 
>> This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`.
>> 
>> [1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803
>> [2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95
>> [3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e
>> [4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070
>
> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8258953: AArch64: move NEON instructions to aarch64_neon.ad

I compared all-ad-src.ad with and without the patch, and it looked good to me.

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

Marked as reviewed by njian (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2273

From dongbo at openjdk.java.net  Mon Feb  8 02:15:44 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 8 Feb 2021 02:15:44 GMT
Subject: RFR: 8258953: AArch64: move NEON instructions to aarch64_neon.ad
 [v2]
In-Reply-To: <HYn0pFJyu5_2rzUVn0A0wIKla3aaKyR0ADOBT37OVHo=.1a13178d-9d34-408c-ae26-d65fce95d20a@github.com>
References: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
 <ab1pyz3Iyiwh9tDlS9y5QbZuivhe2qNs9BFetreqWcA=.5388a0f3-5b0d-4620-96ce-9f747ddb2097@github.com>
 <HYn0pFJyu5_2rzUVn0A0wIKla3aaKyR0ADOBT37OVHo=.1a13178d-9d34-408c-ae26-d65fce95d20a@github.com>
Message-ID: <lQXDrtwIq01LU03XhQ119XU_XqK-7spfFUcW6lgL0Fw=.58bf82f1-7fea-4700-b383-6a50856c6738@github.com>

On Mon, 8 Feb 2021 02:05:59 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8258953: AArch64: move NEON instructions to aarch64_neon.ad
>
> I compared all-ad-src.ad with and without the patch, and it looked good to me.

Thanks for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/2273

From dongbo at openjdk.java.net  Mon Feb  8 02:15:45 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 8 Feb 2021 02:15:45 GMT
Subject: Integrated: 8258953: AArch64: move NEON instructions to
 aarch64_neon.ad
In-Reply-To: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
References: <XGTLq2Pqnu1FU70iDyaAaSQkEYH4rtKbj_wqJHRWv7s=.dbfd57ad-5d5d-4b90-b5fb-e3da2acc5df6@github.com>
Message-ID: <WyoFY2mg7mQmSTLxKRq1q-JNknc_vjshhKRG7EpnBGc=.8a2cea22-9aa5-4a17-910d-b2314cce2d2d@github.com>

On Thu, 28 Jan 2021 01:37:33 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> As discussed in [1], all NEON instructions should be moved from `aarch64.ad` to `aarch64_neon.ad`.
> 
> In the first commit [2] of this PR, the NEON instructions are deleted from `aarch64.ad` and appended to `aarch64_neon.ad`.
> I compared the generated code in `aarch64_neon.ad` with original code in `aarch64.ad`, no suspicious differences found.
> The last two commits just simply move code around in `aarch64_neon.ad` to put related instructions together, i.e. `LoadStore` [3], `Reduction` [4].
> 
> This also supports vector length 4 for `vsraa8B_imm` and `vsrla8B_imm`, vector length 2 for `vsraa4S_imm` and `vsrla4S_imm`, fixes few typos, e.g. `vor8B`, `vsrla4S_imm`.
> 
> [1] https://github.com/openjdk/jdk/pull/1215#issuecomment-728186803
> [2] https://github.com/dgbo/jdk/commit/40cbe99e647cdf93712edf8f77ab3b5b30ea0a95
> [3] https://github.com/dgbo/jdk/commit/695fb8f8ef009b733a8f804e791347f4bfe2572e
> [4] https://github.com/dgbo/jdk/commit/e0c38aa9aaa6af9925a3821328384b1e2b2c2070

This pull request has now been integrated.

Changeset: aa5bc6ed
Author:    Dong Bo <dongbo at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aa5bc6ed
Stats:     5661 lines in 3 files changed: 3216 ins; 2435 del; 10 mod

8258953: AArch64: move NEON instructions to aarch64_neon.ad

Reviewed-by: njian, aph

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

PR: https://git.openjdk.java.net/jdk/pull/2273

From thartmann at openjdk.java.net  Mon Feb  8 07:05:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 8 Feb 2021 07:05:42 GMT
Subject: RFR: 8261229: MethodData is not correctly initialized with
 TieredStopAtLevel=3 [v2]
In-Reply-To: <-RNQ0M9cHiIX7na2DnUnhucXZ35JILV8sdMO0oAeaOI=.42b67e78-71c8-4bcf-aaa7-22889fbfbba5@github.com>
References: <-ReDb8Jf-EIuYNyQltIaKSF1tUPmswp6kx_mciU5Fvk=.31d8565c-26fe-4f7f-8b88-55bcc996bfca@github.com>
 <-RNQ0M9cHiIX7na2DnUnhucXZ35JILV8sdMO0oAeaOI=.42b67e78-71c8-4bcf-aaa7-22889fbfbba5@github.com>
Message-ID: <wPud3HjxCMbPSnlmlaCuNlriwDLqepv7-MJbC5kxT4g=.01d0efa4-cacb-439a-a7c9-3c0b045a76bc@github.com>

On Sat, 6 Feb 2021 20:47:00 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Mostly a typo in compilation mode ergonomics that selected a quick-only mode essentially when the user specified TieredStopAtLevel={1,2,3}. The quick-only mode has an optimization that eliminates parts of the MDO since they are not needed. Meanwhile, the WB API considered it a fair game to request a level 3 compile, that requires a full MDO.
>> 
>> The fix corrects the original issue and also tries to be extra defensive with WB API (since it's semantics is not clearly specified) by always allocating full MDO if WB API is on.
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove WB defence

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2444

From thartmann at openjdk.java.net  Mon Feb  8 07:08:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 8 Feb 2021 07:08:42 GMT
Subject: RFR: 8261229: MethodData is not correctly initialized with
 TieredStopAtLevel=3 [v2]
In-Reply-To: <wPud3HjxCMbPSnlmlaCuNlriwDLqepv7-MJbC5kxT4g=.01d0efa4-cacb-439a-a7c9-3c0b045a76bc@github.com>
References: <-ReDb8Jf-EIuYNyQltIaKSF1tUPmswp6kx_mciU5Fvk=.31d8565c-26fe-4f7f-8b88-55bcc996bfca@github.com>
 <-RNQ0M9cHiIX7na2DnUnhucXZ35JILV8sdMO0oAeaOI=.42b67e78-71c8-4bcf-aaa7-22889fbfbba5@github.com>
 <wPud3HjxCMbPSnlmlaCuNlriwDLqepv7-MJbC5kxT4g=.01d0efa4-cacb-439a-a7c9-3c0b045a76bc@github.com>
Message-ID: <HquRahpcuka-FtiFMgLk8MgVXiLWqJyduIfJNxnx2XY=.e6b849fb-2320-4f66-93d6-1d600e274929@github.com>

On Mon, 8 Feb 2021 07:02:46 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove WB defence
>
> Looks good to me.

Just wondering if we should add a regression test (i.e. add a `TieredStopAtLeveL=3`) run to the test(s) you've mentioned in the bug comments?

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

PR: https://git.openjdk.java.net/jdk/pull/2444

From iveresov at openjdk.java.net  Mon Feb  8 07:13:41 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Mon, 8 Feb 2021 07:13:41 GMT
Subject: RFR: 8261229: MethodData is not correctly initialized with
 TieredStopAtLevel=3 [v2]
In-Reply-To: <HquRahpcuka-FtiFMgLk8MgVXiLWqJyduIfJNxnx2XY=.e6b849fb-2320-4f66-93d6-1d600e274929@github.com>
References: <-ReDb8Jf-EIuYNyQltIaKSF1tUPmswp6kx_mciU5Fvk=.31d8565c-26fe-4f7f-8b88-55bcc996bfca@github.com>
 <-RNQ0M9cHiIX7na2DnUnhucXZ35JILV8sdMO0oAeaOI=.42b67e78-71c8-4bcf-aaa7-22889fbfbba5@github.com>
 <wPud3HjxCMbPSnlmlaCuNlriwDLqepv7-MJbC5kxT4g=.01d0efa4-cacb-439a-a7c9-3c0b045a76bc@github.com>
 <HquRahpcuka-FtiFMgLk8MgVXiLWqJyduIfJNxnx2XY=.e6b849fb-2320-4f66-93d6-1d600e274929@github.com>
Message-ID: <ATiimNlvBKqQNEQS_UU7vS5aJuRLcJqPgCDK9KWegC4=.f53f0b8a-52a8-4576-a8a3-643077f2f808@github.com>

On Mon, 8 Feb 2021 07:06:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Just wondering if we should add a regression test (i.e. add a `TieredStopAtLeveL=3`) run to the test(s) you've mentioned in the bug comments?

I think we should rather start running the existing tests in compiler/whitebox and compiler/tiered with TieredStopAtLevel={1, 2,3} instead. Many of them failed when I did that, 3 of them failed because of this particular problem.

Many of these tests are specifically crafted to be run with different TieredStopAtLevel values.

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

PR: https://git.openjdk.java.net/jdk/pull/2444

From thartmann at openjdk.java.net  Mon Feb  8 07:23:41 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 8 Feb 2021 07:23:41 GMT
Subject: RFR: 8261229: MethodData is not correctly initialized with
 TieredStopAtLevel=3 [v2]
In-Reply-To: <ATiimNlvBKqQNEQS_UU7vS5aJuRLcJqPgCDK9KWegC4=.f53f0b8a-52a8-4576-a8a3-643077f2f808@github.com>
References: <-ReDb8Jf-EIuYNyQltIaKSF1tUPmswp6kx_mciU5Fvk=.31d8565c-26fe-4f7f-8b88-55bcc996bfca@github.com>
 <-RNQ0M9cHiIX7na2DnUnhucXZ35JILV8sdMO0oAeaOI=.42b67e78-71c8-4bcf-aaa7-22889fbfbba5@github.com>
 <wPud3HjxCMbPSnlmlaCuNlriwDLqepv7-MJbC5kxT4g=.01d0efa4-cacb-439a-a7c9-3c0b045a76bc@github.com>
 <HquRahpcuka-FtiFMgLk8MgVXiLWqJyduIfJNxnx2XY=.e6b849fb-2320-4f66-93d6-1d600e274929@github.com>
 <ATiimNlvBKqQNEQS_UU7vS5aJuRLcJqPgCDK9KWegC4=.f53f0b8a-52a8-4576-a8a3-643077f2f808@github.com>
Message-ID: <ZibRhSCyiEu9nmPMOyQwiFPX72DiUdhipi06vT3NDRo=.af84b6fd-9a0f-4058-a991-1c704f25188c@github.com>

On Mon, 8 Feb 2021 07:09:24 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Just wondering if we should add a regression test (i.e. add a `TieredStopAtLeveL=3`) run to the test(s) you've mentioned in the bug comments?
>
>> Just wondering if we should add a regression test (i.e. add a `TieredStopAtLeveL=3`) run to the test(s) you've mentioned in the bug comments?
> 
> I think we should rather start running the existing tests in compiler/whitebox and compiler/tiered with TieredStopAtLevel={1, 2,3} instead. Many of them failed when I did that, 3 of them failed because of this particular problem.
> 
> Many of these tests are specifically crafted to be run with different TieredStopAtLevel values.

Okay, even better.

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

PR: https://git.openjdk.java.net/jdk/pull/2444

From iveresov at openjdk.java.net  Mon Feb  8 17:11:40 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Mon, 8 Feb 2021 17:11:40 GMT
Subject: Integrated: 8261229: MethodData is not correctly initialized with
 TieredStopAtLevel=3
In-Reply-To: <-ReDb8Jf-EIuYNyQltIaKSF1tUPmswp6kx_mciU5Fvk=.31d8565c-26fe-4f7f-8b88-55bcc996bfca@github.com>
References: <-ReDb8Jf-EIuYNyQltIaKSF1tUPmswp6kx_mciU5Fvk=.31d8565c-26fe-4f7f-8b88-55bcc996bfca@github.com>
Message-ID: <eVXFPucp28cCeIMLoiLqaln483EWHDfEoO_ZlUEQtTE=.25493977-250e-447d-b373-32cca9dbea44@github.com>

On Sat, 6 Feb 2021 06:16:45 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Mostly a typo in compilation mode ergonomics that selected a quick-only mode essentially when the user specified TieredStopAtLevel={1,2,3}. The quick-only mode has an optimization that eliminates parts of the MDO since they are not needed. Meanwhile, the WB API considered it a fair game to request a level 3 compile, that requires a full MDO.
> 
> The fix corrects the original issue and also tries to be extra defensive with WB API (since it's semantics is not clearly specified) by always allocating full MDO if WB API is on.

This pull request has now been integrated.

Changeset: 29a428f5
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/29a428f5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8261229: MethodData is not correctly initialized with TieredStopAtLevel=3

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2444

From kvn at openjdk.java.net  Mon Feb  8 18:48:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 8 Feb 2021 18:48:46 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
Message-ID: <A4DIcIM6EGwSqzCytISMY0EvWc-D09fobC15PJS3HWw=.7829876e-26ab-4e7b-b2a3-d8a9d6d4a81f@github.com>

On Fri, 5 Feb 2021 07:29:00 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
>> @Benchmark
>> public void testMethod(Blackhole bh) {
>>   int sum = 0;
>>   for (int i = 0; i < data.length; i++) {
>>       Integer ii = Integer.valueOf(data[i]);
>>       if (i < data.length) {
>>           sum += ii.intValue();
>>       }
>>   }
>>   bh.consume(sum);
>> }
>> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
>> The uncommon_trap is generated by the optimized "if", because its condition is always true.
>> 
>> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
>> and deleting the use of box:
>> 
>> There is no additional fail/error(s) of jtreg after this patch.
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor codes

I am a little concern about stretching uses of input value outside scope where it is created (for example, loop's variable or a value depending on it).
This optimization may work only because boxed values are immutable.
I will run our tests with this changes.

src/hotspot/share/opto/callGenerator.cpp line 582:

> 580:         Node* uncommon_trap_node = delay_boxes.pop();
> 581:         int in_edge = uncommon_trap_node->find_edge(res);
> 582:         assert(in_edge > 0, "sanity");

If there are several references you need to replace all of them.

src/hotspot/share/opto/callGenerator.cpp line 591:

> 589:         Node* sobj = new SafePointScalarObjectNode(gvn.type(res)->isa_oopptr(),
> 590: #ifdef ASSERT
> 591:                                                   NULL,

I would suggest to record `call` node here treating it as allocation.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From enikitin at openjdk.java.net  Mon Feb  8 20:01:42 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Mon, 8 Feb 2021 20:01:42 GMT
Subject: RFR: 8058176: [mlvm] Tests should tolerate exceptions caused by
 code cache exhaustion.
In-Reply-To: <WF4zjGC1xoxvLj1yoz3JSWjVnjf1py8k5JVn5cfUbv4=.8ca36940-de1e-480b-a32c-07f63bc173ea@github.com>
References: <WF4zjGC1xoxvLj1yoz3JSWjVnjf1py8k5JVn5cfUbv4=.8ca36940-de1e-480b-a32c-07f63bc173ea@github.com>
Message-ID: <cddjxaWz5OOo2NeN9Cd6Q0z1_P8SjSFk8DFYKpU1ZmA=.e901b923-6e87-45ee-b049-276eb4dcf9e7@github.com>

On Fri, 5 Feb 2021 22:16:14 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> A repetition of the #1622.
> 
> 1. Normalise meth/stress/compiler/i2c_c2i/Test.java to use MultiThreadedTest framework;
> 2. Adjust MultiThreadedTest in order to accomodate the i2c_c2i test (add prepareThread method and logic);
> 3. Add ThrowableTolerance and DefaultThrowableTolerance as ways to control what Throwables are accepted;
> 4. Adjust MultiThreadedTest to catch Throwables and check if they are accepted;
> 5. Adjust individual tests to catch possible Throwables and check if they are accepted;
> 6. Un-problemlist the failing tests.
> 
> Testing vmTestBase/vm/mlvm/meth/stress run on macos-linux-windows (30 runs each) in x64 configurations, rebased on top of latest code base. Code cache was limited `-XX:ReservedCodeCacheSize=8M` as suggested in the case.

Needs reworking.

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

PR: https://git.openjdk.java.net/jdk/pull/2440

From enikitin at openjdk.java.net  Mon Feb  8 20:01:43 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Mon, 8 Feb 2021 20:01:43 GMT
Subject: Withdrawn: 8058176: [mlvm] Tests should tolerate exceptions caused by
 code cache exhaustion.
In-Reply-To: <WF4zjGC1xoxvLj1yoz3JSWjVnjf1py8k5JVn5cfUbv4=.8ca36940-de1e-480b-a32c-07f63bc173ea@github.com>
References: <WF4zjGC1xoxvLj1yoz3JSWjVnjf1py8k5JVn5cfUbv4=.8ca36940-de1e-480b-a32c-07f63bc173ea@github.com>
Message-ID: <k9riuvz4u8NLvsXWcgGXhxdquXgEfXR36IBNkb5-G9I=.00a225d9-435a-413d-909b-a4d32ea04d1f@github.com>

On Fri, 5 Feb 2021 22:16:14 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> A repetition of the #1622.
> 
> 1. Normalise meth/stress/compiler/i2c_c2i/Test.java to use MultiThreadedTest framework;
> 2. Adjust MultiThreadedTest in order to accomodate the i2c_c2i test (add prepareThread method and logic);
> 3. Add ThrowableTolerance and DefaultThrowableTolerance as ways to control what Throwables are accepted;
> 4. Adjust MultiThreadedTest to catch Throwables and check if they are accepted;
> 5. Adjust individual tests to catch possible Throwables and check if they are accepted;
> 6. Un-problemlist the failing tests.
> 
> Testing vmTestBase/vm/mlvm/meth/stress run on macos-linux-windows (30 runs each) in x64 configurations, rebased on top of latest code base. Code cache was limited `-XX:ReservedCodeCacheSize=8M` as suggested in the case.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/2440

From kvn at openjdk.java.net  Mon Feb  8 22:50:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 8 Feb 2021 22:50:42 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <A4DIcIM6EGwSqzCytISMY0EvWc-D09fobC15PJS3HWw=.7829876e-26ab-4e7b-b2a3-d8a9d6d4a81f@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
 <A4DIcIM6EGwSqzCytISMY0EvWc-D09fobC15PJS3HWw=.7829876e-26ab-4e7b-b2a3-d8a9d6d4a81f@github.com>
Message-ID: <MiHXYS8Oq_1d6iXa4f95tm3B_E4Il9jHgyoThaQl8cw=.090691e5-beec-444e-a5c3-64416eb5c047@github.com>

On Mon, 8 Feb 2021 18:45:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor codes
>
> I am a little concern about stretching uses of input value outside scope where it is created (for example, loop's variable or a value depending on it).
> This optimization may work only because boxed values are immutable.
> I will run our tests with this changes.

Our tier1-4 testing passed

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From xliu at openjdk.java.net  Tue Feb  9 00:33:51 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 9 Feb 2021 00:33:51 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <MiHXYS8Oq_1d6iXa4f95tm3B_E4Il9jHgyoThaQl8cw=.090691e5-beec-444e-a5c3-64416eb5c047@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
 <A4DIcIM6EGwSqzCytISMY0EvWc-D09fobC15PJS3HWw=.7829876e-26ab-4e7b-b2a3-d8a9d6d4a81f@github.com>
 <MiHXYS8Oq_1d6iXa4f95tm3B_E4Il9jHgyoThaQl8cw=.090691e5-beec-444e-a5c3-64416eb5c047@github.com>
Message-ID: <dUQ9FBEk9rIPuRCMO6YyprN_CgRHAxjujjVHPwWap0U=.361ec440-42bb-4867-a6b2-75d8ee142ce5@github.com>

On Mon, 8 Feb 2021 22:47:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I am a little concern about stretching uses of input value outside scope where it is created (for example, loop's variable or a value depending on it).
>> This optimization may work only because boxed values are immutable.
>> I will run our tests with this changes.
>
> Our tier1-4 testing passed

> I was wandering if we can remove the useless `if` as it's always true in this case. Do you know why this kind of `if` haven't been eliminated by GVN phase?

Eventually, c2 should know that `i < data.length' is true. it should be done by GCP later. 

The example is a special case.  you can remove this " if (i < data.length)"  here.  Generally, target code can look like this. c2 speculatively generates an uncommon_trap of "unstable_if".

  for (int i = 0; i < data.length; i++) {
      Integer ii = Integer.valueOf(data[i]);
      if (cond) { //likely
          sum += ii.intValue();
      }
  }

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From xliu at openjdk.java.net  Tue Feb  9 00:59:43 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 9 Feb 2021 00:59:43 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
Message-ID: <doyhn0k7V_F4yEj4GE_vhuGwLTeWA7qZHkyLfAHB9BE=.27014166-5ca9-44d1-a0a2-38cb805f46e8@github.com>

On Fri, 5 Feb 2021 07:29:00 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
>> @Benchmark
>> public void testMethod(Blackhole bh) {
>>   int sum = 0;
>>   for (int i = 0; i < data.length; i++) {
>>       Integer ii = Integer.valueOf(data[i]);
>>       if (i < data.length) {
>>           sum += ii.intValue();
>>       }
>>   }
>>   bh.consume(sum);
>> }
>> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
>> The uncommon_trap is generated by the optimized "if", because its condition is always true.
>> 
>> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
>> and deleting the use of box:
>> 
>> There is no additional fail/error(s) of jtreg after this patch.
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor codes

src/hotspot/share/opto/callGenerator.cpp line 558:

> 556: 
> 557: static void delay_box_in_uncommon_trap(CallNode* call, Node* resproj) {
> 558:   if (resproj != NULL && call->is_CallStaticJava() &&

IMHO, we should use nullptr here because hotspot now is using c++14.

src/hotspot/share/opto/callGenerator.cpp line 560:

> 558:   if (resproj != NULL && call->is_CallStaticJava() &&
> 559:       call->as_CallStaticJava()->is_boxing_method()) {
> 560:     GraphKit kit(call->jvms());

you can postpone to construct this object in if(no_use).

src/hotspot/share/opto/callGenerator.cpp line 586:

> 584:         ciInstanceKlass* klass = call->as_CallStaticJava()->method()->holder();
> 585:         int n_fields = klass->nof_nonstatic_fields();
> 586:         assert(n_fields == 1, "sanity");

I think you  also need to check the only non-static field of klass must be a scalar.
"sanity" is too concise. I think we should leave a message to say it's an auto-boxing class.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From xliu at openjdk.java.net  Tue Feb  9 00:59:44 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 9 Feb 2021 00:59:44 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <A4DIcIM6EGwSqzCytISMY0EvWc-D09fobC15PJS3HWw=.7829876e-26ab-4e7b-b2a3-d8a9d6d4a81f@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
 <A4DIcIM6EGwSqzCytISMY0EvWc-D09fobC15PJS3HWw=.7829876e-26ab-4e7b-b2a3-d8a9d6d4a81f@github.com>
Message-ID: <3eCQyq3X_TP8Si_Dok_DEsAWGLpy94RM00iOmWo03ao=.7b2b4d17-7656-4c24-8fea-eb0976d98359@github.com>

On Mon, 8 Feb 2021 18:15:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor codes
>
> src/hotspot/share/opto/callGenerator.cpp line 582:
> 
>> 580:         Node* uncommon_trap_node = delay_boxes.pop();
>> 581:         int in_edge = uncommon_trap_node->find_edge(res);
>> 582:         assert(in_edge > 0, "sanity");
> 
> If there are several references you need to replace all of them.

+1
scalar replacement uses range substitution
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/macro.cpp#L892

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From dlong at openjdk.java.net  Tue Feb  9 01:38:52 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 9 Feb 2021 01:38:52 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler
In-Reply-To: <d40n9RxaYEqp-6UU7qDQ9rJYrSZ0gXKTT9jqTlylfvU=.8fbcfe20-5f2e-48e8-a189-771701645d9b@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <vP-nQAbUU0P54kYGCK8R2cc_OBIRCk0P3TX_mgM4th8=.5cdfad98-051b-489c-9546-8f967ce2c720@github.com>
 <0azhJ4pD5Tq_lkpPtYMpQBjokflcSQEdWP2Rz9HBm6k=.c3ece6fd-1ae7-49ea-a6eb-ec88a9fbd54d@github.com>
 <d40n9RxaYEqp-6UU7qDQ9rJYrSZ0gXKTT9jqTlylfvU=.8fbcfe20-5f2e-48e8-a189-771701645d9b@github.com>
Message-ID: <ZFXn-510nHc4-xULSEQooZYTQ2Uou6FM58KtImAUSsQ=.bf925331-cef6-4708-b49d-754df02fe8e1@github.com>

On Fri, 5 Feb 2021 18:43:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I agree. We wanted to do that for long time.
>
> I am curious if the x86_64.o file changes in any significant way (speed of size).

I wish there was a way for the old and new versions to co-exist at the same time, so we could generate the code the old way and and the new way, then compare, for automatic verification of the MacroAssember version.

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

PR: https://git.openjdk.java.net/jdk/pull/2420

From whuang at openjdk.java.net  Tue Feb  9 01:43:43 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Tue, 9 Feb 2021 01:43:43 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <doyhn0k7V_F4yEj4GE_vhuGwLTeWA7qZHkyLfAHB9BE=.27014166-5ca9-44d1-a0a2-38cb805f46e8@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
 <doyhn0k7V_F4yEj4GE_vhuGwLTeWA7qZHkyLfAHB9BE=.27014166-5ca9-44d1-a0a2-38cb805f46e8@github.com>
Message-ID: <XRQRkuYTHK_N2nYJJJUgxtBc3qupqbh7nNtlqBVeznE=.70a0fd3f-1070-433e-9c69-1bed57a0cd18@github.com>

On Tue, 9 Feb 2021 00:35:08 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor codes
>
> src/hotspot/share/opto/callGenerator.cpp line 558:
> 
>> 556: 
>> 557: static void delay_box_in_uncommon_trap(CallNode* call, Node* resproj) {
>> 558:   if (resproj != NULL && call->is_CallStaticJava() &&
> 
> IMHO, we should use nullptr here because hotspot now is using c++14.

Thank you for your review. I will change that.

> src/hotspot/share/opto/callGenerator.cpp line 560:
> 
>> 558:   if (resproj != NULL && call->is_CallStaticJava() &&
>> 559:       call->as_CallStaticJava()->is_boxing_method()) {
>> 560:     GraphKit kit(call->jvms());
> 
> you can postpone to construct this object in if(no_use).

Sure. I will change that.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From whuang at openjdk.java.net  Tue Feb  9 02:36:42 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Tue, 9 Feb 2021 02:36:42 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <3eCQyq3X_TP8Si_Dok_DEsAWGLpy94RM00iOmWo03ao=.7b2b4d17-7656-4c24-8fea-eb0976d98359@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
 <A4DIcIM6EGwSqzCytISMY0EvWc-D09fobC15PJS3HWw=.7829876e-26ab-4e7b-b2a3-d8a9d6d4a81f@github.com>
 <3eCQyq3X_TP8Si_Dok_DEsAWGLpy94RM00iOmWo03ao=.7b2b4d17-7656-4c24-8fea-eb0976d98359@github.com>
Message-ID: <Y60qm7azioHPV6Bp6nEqmkWi0ouuQx01ETiA05pg-as=.a6153b0a-9eef-4910-9b07-3a477ef312fd@github.com>

On Tue, 9 Feb 2021 00:52:31 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/opto/callGenerator.cpp line 582:
>> 
>>> 580:         Node* uncommon_trap_node = delay_boxes.pop();
>>> 581:         int in_edge = uncommon_trap_node->find_edge(res);
>>> 582:         assert(in_edge > 0, "sanity");
>> 
>> If there are several references you need to replace all of them.
>
> +1
> scalar replacement uses range substitution
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/macro.cpp#L892

Thank you for your review. It's my fault. I will revise this in next commit.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From github.com+10482586+therealeliu at openjdk.java.net  Tue Feb  9 03:10:40 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Tue, 9 Feb 2021 03:10:40 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <WDQ0yZR8gbP6aLt1qOEIMsSOrwiSMdS4V8l4pi4RBmc=.b201fce0-ed3e-4319-b96b-9651bd4ecdd7@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <WDQ0yZR8gbP6aLt1qOEIMsSOrwiSMdS4V8l4pi4RBmc=.b201fce0-ed3e-4319-b96b-9651bd4ecdd7@github.com>
Message-ID: <fQyVXCbS6JtucneiuQdQ7SVeL81Lag2w4ZnBWVGxO2I=.d8cc9664-2d4a-4a96-bf94-c774bbab83ab@github.com>

On Thu, 28 Jan 2021 14:26:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Eric Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add benchmark test
>>   
>>   Change-Id: I63ca51d06070a07e5c20daf4b42d2c8d7237a1da
>
> All that remains to do is the benchmarks.

@theRealAph Could you help to take a look ?

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From Pengfei.Li at arm.com  Tue Feb  9 03:21:32 2021
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Tue, 9 Feb 2021 03:21:32 +0000
Subject: [11u] RFR(S): 8261022: Fix incorrect result of Math.abs() with char
 type
Message-ID: <PR3PR08MB58505A8740860AE313B7FAFA968E9@PR3PR08MB5850.eurprd08.prod.outlook.com>

Hi,

I'd like to backport JDK-8261022 to jdk11u.

Original JBS: https://bugs.openjdk.java.net/browse/JDK-8261022
Modified webrev: http://cr.openjdk.java.net/~pli/rfr/8261022/backport11u/

This issue causes vectorized abs generate incorrect result when the argument has char type. Root cause is that the vector abs operation is not specially handled in computing vector element types after we enabled that in JDK-8222074 in jdk13. As JDK-8222074 was backported to jdk11u, jdk11u is also affected.

The patch to fix this is in jdk17 now. The fix does not apply to jdk11u cleanly, as VectorNode::is_shift_opcode() is not defined in jdk11u. I have modified the patch a little bit to fit this difference.

Tested jtreg hotspot::tier1 and the newly added jtreg case. No failure after the modified patch.

--
Thanks,
Pengfei


From dongbo at openjdk.java.net  Tue Feb  9 07:03:58 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 9 Feb 2021 07:03:58 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width
Message-ID: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>

In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
    /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
    public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);

The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 8`, but `ushr dst.4H, src.4H, 16` instead.
According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);

The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en

This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

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

Commit messages:
 - fix trailing whitespaces
 - 8261142: AArch64: Incorrect instruction encoding when right-shifting vectors with shift amount equals to the element width

Changes: https://git.openjdk.java.net/jdk/pull/2472/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261142
  Stats: 771 lines in 3 files changed: 641 ins; 17 del; 113 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From njian at openjdk.java.net  Tue Feb  9 07:55:43 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Tue, 9 Feb 2021 07:55:43 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>

On Tue, 9 Feb 2021 06:55:50 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Thanks for the fix.

src/hotspot/cpu/aarch64/aarch64_neon.ad line 5285:

> 5283:   ins_encode %{
> 5284:     int sh = (int)$shift$$constant;
> 5285:     if (sh == 0) {

If src and dst are the same reg, no need to emit code. Or maybe c2 can even be improved to optimize this (sh=0 case) out?

src/hotspot/cpu/aarch64/aarch64_neon.ad line 5271:

> 5269:     } else {
> 5270:       if (sh >= 8) sh = 7;
> 5271:       __ sshr(as_FloatRegister($dst$$reg), __ T8B,

I think we should add an assert to make sure 0 is not passed to the assembler.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From dongbo at openjdk.java.net  Tue Feb  9 08:57:12 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 9 Feb 2021 08:57:12 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width
In-Reply-To: <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
Message-ID: <gWuqR_sAXa6kmMK0Bq30niUdeQZK7NmfussgQk9MnlY=.c987503a-453a-4a1c-ae72-c56c156dc9ca@github.com>

On Tue, 9 Feb 2021 07:47:57 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> If src and dst are the same reg, no need to emit code. 

If we want to do this enhancement, I think we need do it for left shifting and all SVE left/right shifting as well for completeness.

> Or maybe c2 can even be improved to optimize this (sh=0 case) out?

We can add code in `Ideal` to optimize it to ORR, but I'm not sure `orr` performs better than `shift` on other platforms.
Seems we have to created a generic new node to do `vector move` here.

> src/hotspot/cpu/aarch64/aarch64_neon.ad line 5271:
> 
>> 5269:     } else {
>> 5270:       if (sh >= 8) sh = 7;
>> 5271:       __ sshr(as_FloatRegister($dst$$reg), __ T8B,
> 
> I think we should add an assert to make sure 0 is not passed to the assembler.

Agree, I'll do this.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From dongbo at openjdk.java.net  Tue Feb  9 09:13:47 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 9 Feb 2021 09:13:47 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v2]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <qIGtN0hEKBfKOpYy-SKt1vieC15bF4juBfwfKMRGI3g=.53123dda-a8ca-49b9-b925-6ed85f3f9e6f@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  add assertion in the assembler

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/c44bebb0..8439f167

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From aph at openjdk.java.net  Tue Feb  9 09:32:37 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 9 Feb 2021 09:32:37 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v2]
In-Reply-To: <qIGtN0hEKBfKOpYy-SKt1vieC15bF4juBfwfKMRGI3g=.53123dda-a8ca-49b9-b925-6ed85f3f9e6f@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <qIGtN0hEKBfKOpYy-SKt1vieC15bF4juBfwfKMRGI3g=.53123dda-a8ca-49b9-b925-6ed85f3f9e6f@github.com>
Message-ID: <_ach7OekIqkqmFRW3JqA5h4Q_HQUbRni0vkFzx5q3MA=.536a9faa-98c9-4dd9-9798-dcc794e23cd0@github.com>

On Tue, 9 Feb 2021 09:13:47 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
>> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
>> 
>> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
>> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
>> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
>> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
>> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
>> 
>> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
>> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
>> 
>> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
>> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add assertion in the assembler

src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 line 2057:

> 2055:              as_FloatRegister($src$$reg), as_FloatRegister($src$$reg));
> 2056:     } else {ifelse($4, B,`
> 2057:       if (sh >= 8) sh = 7;

I think it would be possible to move some of this logic from the AD file into MacroAssembler, with macros to generate the appropriate instruction based on their arguments. This might be cleaner: the logic here is very hard to follow.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From sjohanss at openjdk.java.net  Tue Feb  9 15:06:05 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Feb 2021 15:06:05 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
Message-ID: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>

When adding a code heap the page size used with the underlying mapping is traced using `os::trace_page_sizes`. The old code tried to estimate the page-size based on the size, but the mapping has already been done so it is better to check the passed in `ReservedSpace`. Today we don't record the page size in the ReservedSpace, but we have a helper to do a good estimate: `ReservedSpace::actual_reserved_page_size()`. The proposal is to use this function.

When changing this I also realized that the traced min-size used un-aligned value while the actual `initialize`-call correctly uses the aligned size. Changed so that we also use the aligned size for tracing.

I'm currently doing some more work in this area and while I haven't added a specific test for this issue I have created a test I plan to integrate separately when a few more needed changes have gone in. The test is Linux-only and validates the output from `os::trace_page_sizes` against the information in `/proc/self/smaps`.

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

Commit messages:
 - 8261029: Code heap page sizes not traced correctly using os::trace_page_sizes

Changes: https://git.openjdk.java.net/jdk/pull/2481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2481&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261029
  Stats: 9 lines in 1 file changed: 1 ins; 6 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2481/head:pull/2481

PR: https://git.openjdk.java.net/jdk/pull/2481

From kvn at openjdk.java.net  Tue Feb  9 18:47:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 9 Feb 2021 18:47:39 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
Message-ID: <2Z_5m14VBbD6IWQz17vzBfXu0UQm1m0SByRvxv2K91I=.ee206e21-0fb1-4170-9ab8-4df2d478f5bc@github.com>

On Tue, 9 Feb 2021 13:45:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> When adding a code heap the page size used with the underlying mapping is traced using `os::trace_page_sizes`. The old code tried to estimate the page-size based on the size, but the mapping has already been done so it is better to check the passed in `ReservedSpace`. Today we don't record the page size in the ReservedSpace, but we have a helper to do a good estimate: `ReservedSpace::actual_reserved_page_size()`. The proposal is to use this function.
> 
> When changing this I also realized that the traced min-size used un-aligned value while the actual `initialize`-call correctly uses the aligned size. Changed so that we also use the aligned size for tracing.
> 
> I'm currently doing some more work in this area and while I haven't added a specific test for this issue I have created a test I plan to integrate separately when a few more needed changes have gone in. The test is Linux-only and validates the output from `os::trace_page_sizes` against the information in `/proc/self/smaps`.

I think the difference comes from JDK-8087339 changes which did not update this code:
https://github.com/openjdk/jdk/commit/925a508b2bb1600909418405e9e5ea1a93a94580

I agree that alignment here should match one used in CodeCache::reserve_heap_memory() and not recalculated. But I am not sure actual_reserved_page_size() returns correct value.
May be we should record value in CodeHeap object when it is created.

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

PR: https://git.openjdk.java.net/jdk/pull/2481

From sjohanss at openjdk.java.net  Tue Feb  9 19:25:37 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Feb 2021 19:25:37 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <2Z_5m14VBbD6IWQz17vzBfXu0UQm1m0SByRvxv2K91I=.ee206e21-0fb1-4170-9ab8-4df2d478f5bc@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
 <2Z_5m14VBbD6IWQz17vzBfXu0UQm1m0SByRvxv2K91I=.ee206e21-0fb1-4170-9ab8-4df2d478f5bc@github.com>
Message-ID: <uJrrHAJ13zxu0t2ceoJJsGDm7KlNaqAk6tIHEsEfrSI=.245f9fb3-8c81-476b-b6f3-82924e2ca1f2@github.com>

On Tue, 9 Feb 2021 18:44:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I agree that alignment here should match one used in CodeCache::reserve_heap_memory() and not recalculated. But I am not sure actual_reserved_page_size() returns correct value.
> May be we should record value in CodeHeap object when it is created.

Yes, the `actual_reserved_page_size()` is far from perfect and I plan to update `ReservedSpace` to have a page size member that can be queried in places like this and then we can remove this helper. This will be required once we allow multiple large page sizes ([PR#1153](https://github.com/openjdk/jdk/pull/1153)). That said, `actual_reserved_page_size()` is currently doing a good job returning the correct page size since it is considering both if the space is "special", what alignment it used and if transparent huge pages are enabled.

I would prefer doing the change that records the page size i `ReservedSpace` as a separate patch and in that patch also remove all uses of `actual_reserved_page_size()`. Doing this change now is required to be able to integrate the [new test](https://github.com/openjdk/jdk/compare/master...kstefanj:test-for-trace-page-sizes) I mentioned, and I think it will be helpful for work in this area going forward.

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

PR: https://git.openjdk.java.net/jdk/pull/2481

From njian at openjdk.java.net  Wed Feb 10 01:38:39 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Wed, 10 Feb 2021 01:38:39 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v2]
In-Reply-To: <gWuqR_sAXa6kmMK0Bq30niUdeQZK7NmfussgQk9MnlY=.c987503a-453a-4a1c-ae72-c56c156dc9ca@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
 <gWuqR_sAXa6kmMK0Bq30niUdeQZK7NmfussgQk9MnlY=.c987503a-453a-4a1c-ae72-c56c156dc9ca@github.com>
Message-ID: <pjWmTPulZ62Pr_5oTbl2vGXxzeMgqf6jSuxugEMKGZA=.43130e6d-32af-4fdf-83fc-9bb46db40857@github.com>

On Tue, 9 Feb 2021 08:53:14 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/aarch64_neon.ad line 5285:
>> 
>>> 5283:   ins_encode %{
>>> 5284:     int sh = (int)$shift$$constant;
>>> 5285:     if (sh == 0) {
>> 
>> If src and dst are the same reg, no need to emit code. Or maybe c2 can even be improved to optimize this (sh=0 case) out?
>
>> If src and dst are the same reg, no need to emit code. 
> 
> If we want to do this enhancement, I think we need do it for left shifting and all SVE left/right shifting as well for completeness.
> 
>> Or maybe c2 can even be improved to optimize this (sh=0 case) out?
> 
> We can add code in `Ideal` to optimize it to ORR, but I'm not sure `orr` performs better than `shift` on other platforms.
> Seems we have to created a generic new node to do `vector move` here.

I think with proper optimization, no move is required. But I agree it's beyond the scope of this patch. I will have a look.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From dongbo at openjdk.java.net  Wed Feb 10 02:56:57 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 10 Feb 2021 02:56:57 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v3]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <rAnrE6b2RqLV7f3zZpZ2luPMYQnWMbocsv7LgRGeNCk=.d9987645-0916-4d22-82b9-c71eecfd1281@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  back out AD modifications and handle zero shift in assembler

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/8439f167..af3f2a15

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=01-02

  Stats: 284 lines in 3 files changed: 19 ins; 143 del; 122 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From dongbo at openjdk.java.net  Wed Feb 10 03:02:41 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 10 Feb 2021 03:02:41 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v2]
In-Reply-To: <_ach7OekIqkqmFRW3JqA5h4Q_HQUbRni0vkFzx5q3MA=.536a9faa-98c9-4dd9-9798-dcc794e23cd0@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <qIGtN0hEKBfKOpYy-SKt1vieC15bF4juBfwfKMRGI3g=.53123dda-a8ca-49b9-b925-6ed85f3f9e6f@github.com>
 <_ach7OekIqkqmFRW3JqA5h4Q_HQUbRni0vkFzx5q3MA=.536a9faa-98c9-4dd9-9798-dcc794e23cd0@github.com>
Message-ID: <0wUxJ4QUIzC-Hg4qSPtf8nFP0ov9J69nA3gjaoEJcWY=.ede23adb-4010-460d-8ac4-d560ace8ffc0@github.com>

On Tue, 9 Feb 2021 09:29:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 line 2057:
> 
>> 2055:              as_FloatRegister($src$$reg), as_FloatRegister($src$$reg));
>> 2056:     } else {ifelse($4, B,`
>> 2057:       if (sh >= 8) sh = 7;
> 
> I think it would be possible to move some of this logic from the AD file into MacroAssembler, with macros to generate the appropriate instruction based on their arguments. This might be cleaner: the logic here is very hard to follow.

I backed out the modifications of `aarch64_neon.ad` and `aarch64_neon_ad.m4`.
The `shift == 0` case is handled by the assembler now. Verified with the regression tests.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From whuang at openjdk.java.net  Wed Feb 10 06:45:53 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Wed, 10 Feb 2021 06:45:53 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v3]
In-Reply-To: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
Message-ID: <g15m7C82dL41yO-DjKUmQ56FhlTzs8JBTq0YIK9ZM_s=.b9615a5d-bf6f-452a-8a96-7b75cfde68bb@github.com>

> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
> @Benchmark
> public void testMethod(Blackhole bh) {
>   int sum = 0;
>   for (int i = 0; i < data.length; i++) {
>       Integer ii = Integer.valueOf(data[i]);
>       if (i < data.length) {
>           sum += ii.intValue();
>       }
>   }
>   bh.consume(sum);
> }
> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
> The uncommon_trap is generated by the optimized "if", because its condition is always true.
> 
> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
> and deleting the use of box:
> 
> There is no additional fail/error(s) of jtreg after this patch.

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  fix some bugs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2401/files
  - new: https://git.openjdk.java.net/jdk/pull/2401/files/4dfee52a..4c62ec8d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=01-02

  Stats: 20 lines in 1 file changed: 6 ins; 5 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2401/head:pull/2401

PR: https://git.openjdk.java.net/jdk/pull/2401

From stuefe at openjdk.java.net  Wed Feb 10 06:48:37 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 10 Feb 2021 06:48:37 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
Message-ID: <x0p4uWJvCN_XF_i3OAUZekWl8_Q8s6dEC9dd7snWYw8=.95eba846-9474-44d3-8a2d-2221b7ad18da@github.com>

On Tue, 9 Feb 2021 13:45:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> When adding a code heap the page size used with the underlying mapping is traced using `os::trace_page_sizes`. The old code tried to estimate the page-size based on the size, but the mapping has already been done so it is better to check the passed in `ReservedSpace`. Today we don't record the page size in the ReservedSpace, but we have a helper to do a good estimate: `ReservedSpace::actual_reserved_page_size()`. The proposal is to use this function.
> 
> When changing this I also realized that the traced min-size used un-aligned value while the actual `initialize`-call correctly uses the aligned size. Changed so that we also use the aligned size for tracing.
> 
> I'm currently doing some more work in this area and while I haven't added a specific test for this issue I have created a test I plan to integrate separately when a few more needed changes have gone in. The test is Linux-only and validates the output from `os::trace_page_sizes` against the information in `/proc/self/smaps`.

Hi Stefan,

I think this is okay if we keep in mind that `ReservedSpace::actual_reserved_page_size` needs fixing up. At the latest after JDK-8256155 hits. Rather use one function than to have to hunt down all the places where caller code tries to guess the page size.

Are you currently working on this? If yes, what are your plans? I have a half finished prototype where I changed os::reserve_xxx() to return meta information about the reservation alongside the pointer, one of them the reserved page size.

Have you guys decided whether its okay to remove the "multiple page sizes per reservation" feature?

There is also another possible simplification I was thinking about, which is to remove the "UseSHM" feature from Linux. I honestly do not know why we still need it. That would simplify rework of large page handling on Linux a lot. I did ask around in December: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/046885.html , but did not get many answers.

Cheers, Thomas

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2481

From dongbo at openjdk.java.net  Wed Feb 10 06:56:53 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 10 Feb 2021 06:56:53 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v4]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <FCG8pFQuX4Ku8dXNtjZhdqOCJIdA8mr74B3VFGPC06o=.e2cdd5eb-f89e-4b6e-979c-3160e10334b0@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  generate add if shift == 0 for accumulation and fix some test code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/af3f2a15..a7b72b0a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=02-03

  Stats: 127 lines in 2 files changed: 27 ins; 0 del; 100 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From whuang at openjdk.java.net  Wed Feb 10 06:58:57 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Wed, 10 Feb 2021 06:58:57 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v4]
In-Reply-To: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
Message-ID: <YHhV9N7mnJDt9mDDw4M9IOVQXSeFJLu4Qool9IneJmw=.3f214ae6-a077-47a5-bc5a-7a6f7d944d6c@github.com>

> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
> @Benchmark
> public void testMethod(Blackhole bh) {
>   int sum = 0;
>   for (int i = 0; i < data.length; i++) {
>       Integer ii = Integer.valueOf(data[i]);
>       if (i < data.length) {
>           sum += ii.intValue();
>       }
>   }
>   bh.consume(sum);
> }
> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
> The uncommon_trap is generated by the optimized "if", because its condition is always true.
> 
> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
> and deleting the use of box:
> 
> There is no additional fail/error(s) of jtreg after this patch.

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  delete useless line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2401/files
  - new: https://git.openjdk.java.net/jdk/pull/2401/files/4c62ec8d..e80e4959

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2401/head:pull/2401

PR: https://git.openjdk.java.net/jdk/pull/2401

From chagedorn at openjdk.java.net  Wed Feb 10 09:02:55 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 10 Feb 2021 09:02:55 GMT
Subject: RFR: 8240281: Remove failing assertion code when selecting first
 memory state in SuperWord::co_locate_pack
Message-ID: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>

While working on [JDK-8238438](https://bugs.openjdk.java.net/browse/JDK-8238438), it was not clear if there is a case where `SuperWord::co_locate_pack()` should pick the memory state of the first load of a pack. We could not find an example and therefore added an `assert(false)` and left the code there to clean it up at some point if the assert was never hit. 

Now, a newly found fuzzer test showed that are cases where we need to pick the first memory state, triggering the `assert(false)`. In the test case `test()`, a store and a load pack are created but the store pack is filtered in `SuperWord::filter_packs()`. The load `x += iArrFld[j]` must read the old value before the store `iArrFld[j] = j` overrides it. Therefore, the load vector must be executed before any of the stores to `iArrFld[j]`. This, however, is not the case if we pick the memory state of the last load which results in wrong values for `iArrFld`: The stores and the loads are dependent and some of the stores are already executed before the load vector. 

The fix is to remove the assertion code added by JDK-8238438 and keep the code for selecting the first memory state of a load pack.

Thanks,
Christian

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

Commit messages:
 - Remove trailing whitespaces
 - 8240281: Remove failing assertion code when selecting first memory state in SuperWord::co_locate_pack

Changes: https://git.openjdk.java.net/jdk/pull/2495/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2495&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8240281
  Stats: 146 lines in 2 files changed: 134 ins; 5 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2495.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2495/head:pull/2495

PR: https://git.openjdk.java.net/jdk/pull/2495

From roland at openjdk.java.net  Wed Feb 10 09:40:38 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 10 Feb 2021 09:40:38 GMT
Subject: RFR: 8240281: Remove failing assertion code when selecting first
 memory state in SuperWord::co_locate_pack
In-Reply-To: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
References: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
Message-ID: <epWNaO4UODLd8YPvlfZ2VzzGN17k8R8jdNqD8EpUhCM=.556c5e1c-9059-4059-811a-02ada24344e2@github.com>

On Wed, 10 Feb 2021 08:49:10 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> While working on [JDK-8238438](https://bugs.openjdk.java.net/browse/JDK-8238438), it was not clear if there is a case where `SuperWord::co_locate_pack()` should pick the memory state of the first load of a pack. We could not find an example and therefore added an `assert(false)` and left the code there to clean it up at some point if the assert was never hit. 
> 
> Now, a newly found fuzzer test showed that are cases where we need to pick the first memory state, triggering the `assert(false)`. In the test case `test()`, a store and a load pack are created but the store pack is filtered in `SuperWord::filter_packs()`. The load `x += iArrFld[j]` must read the old value before the store `iArrFld[j] = j` overrides it. Therefore, the load vector must be executed before any of the stores to `iArrFld[j]`. This, however, is not the case if we pick the memory state of the last load which results in wrong values for `iArrFld`: The stores and the loads are dependent and some of the stores are already executed before the load vector. 
> 
> The fix is to remove the assertion code added by JDK-8238438 and keep the code for selecting the first memory state of a load pack.
> 
> Thanks,
> Christian

Looks good to me.

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

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2495

From chagedorn at openjdk.java.net  Wed Feb 10 09:58:38 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 10 Feb 2021 09:58:38 GMT
Subject: RFR: 8240281: Remove failing assertion code when selecting first
 memory state in SuperWord::co_locate_pack
In-Reply-To: <epWNaO4UODLd8YPvlfZ2VzzGN17k8R8jdNqD8EpUhCM=.556c5e1c-9059-4059-811a-02ada24344e2@github.com>
References: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
 <epWNaO4UODLd8YPvlfZ2VzzGN17k8R8jdNqD8EpUhCM=.556c5e1c-9059-4059-811a-02ada24344e2@github.com>
Message-ID: <kvv66XgsPnobDZNBzDWUJvE3-TlmNPC6LsEvF8ze5Rk=.3def0adb-2214-4298-b970-028d3bd7cd5d@github.com>

On Wed, 10 Feb 2021 09:37:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> While working on [JDK-8238438](https://bugs.openjdk.java.net/browse/JDK-8238438), it was not clear if there is a case where `SuperWord::co_locate_pack()` should pick the memory state of the first load of a pack. We could not find an example and therefore added an `assert(false)` and left the code there to clean it up at some point if the assert was never hit. 
>> 
>> Now, a newly found fuzzer test showed that are cases where we need to pick the first memory state, triggering the `assert(false)`. In the test case `test()`, a store and a load pack are created but the store pack is filtered in `SuperWord::filter_packs()`. The load `x += iArrFld[j]` must read the old value before the store `iArrFld[j] = j` overrides it. Therefore, the load vector must be executed before any of the stores to `iArrFld[j]`. This, however, is not the case if we pick the memory state of the last load which results in wrong values for `iArrFld`: The stores and the loads are dependent and some of the stores are already executed before the load vector. 
>> 
>> The fix is to remove the assertion code added by JDK-8238438 and keep the code for selecting the first memory state of a load pack.
>> 
>> Thanks,
>> Christian
>
> Looks good to me.

Thank you Roland for your review!

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

PR: https://git.openjdk.java.net/jdk/pull/2495

From dongbo at openjdk.java.net  Wed Feb 10 09:59:55 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 10 Feb 2021 09:59:55 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v5]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <pMQxKNOOmth_6jU9gCp87t1aB92mY1BZG7KfMKhcuas=.dcc39977-fc88-42f4-a650-4fa410a2ae8f@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  fix windows build failure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/a7b72b0a..d75ee99e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From sjohanss at openjdk.java.net  Wed Feb 10 10:28:38 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 10 Feb 2021 10:28:38 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <x0p4uWJvCN_XF_i3OAUZekWl8_Q8s6dEC9dd7snWYw8=.95eba846-9474-44d3-8a2d-2221b7ad18da@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
 <x0p4uWJvCN_XF_i3OAUZekWl8_Q8s6dEC9dd7snWYw8=.95eba846-9474-44d3-8a2d-2221b7ad18da@github.com>
Message-ID: <cIM82YOgkdoufKdTd7KB7LOKxU0KoB8sVfmQTaCCzl4=.84b29763-bf38-49b4-9d6d-c276d04754bb@github.com>

On Wed, 10 Feb 2021 06:45:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Are you currently working on this? If yes, what are your plans? I have a half finished prototype where I changed os::reserve_xxx() to return meta information about the reservation alongside the pointer, one of them the reserved page size.
> 

Yes, I also have a prototype that I've been playing around with. It currently uses an out-parameter to return the page size from `os::reserve_memory_special*` calls. The page sizes is then saved in the ReservedSpace for later use. 

> Have you guys decided whether its okay to remove the "multiple page sizes per reservation" feature?
> 

I've done some investigations but nothing have been decided. For now my prototype will return the smallest page size used by a mapping. Going forward I would like to do this, but it feels more urgent to get the other things in place first. 

> There is also another possible simplification I was thinking about, which is to remove the "UseSHM" feature from Linux. I honestly do not know why we still need it. That would simplify rework of large page handling on Linux a lot. I did ask around in December: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/046885.html , but did not get many answers.
> 

I know and I've been digging around in this area and agree even more now that it would be great to get rid of `UseSHM`. Not sure how if everybody agrees though and I'm currently working on small fix for `UseSHM` so that at least we don't leave it enabled everytime someone sets `+UseLargePages` without having any explicit large pages enabled ([PR#2488](https://github.com/openjdk/jdk/pull/2488)).

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

PR: https://git.openjdk.java.net/jdk/pull/2481

From eirbjo at gmail.com  Wed Feb 10 12:50:29 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 10 Feb 2021 13:50:29 +0100
Subject: C1 crash in LinearScan::eliminate_spill_moves
In-Reply-To: <CA+pBWhunER0hNMY4QjhyvnKBKCKdmk898ZFV7wCMd4b0wcxHhQ@mail.gmail.com>
References: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
 <CA+pBWhunER0hNMY4QjhyvnKBKCKdmk898ZFV7wCMd4b0wcxHhQ@mail.gmail.com>
Message-ID: <CA+pBWhtE=8DsyoTfP48P9dogGkDz+xFiGA5ck4Ja3PCXMpwj3Q@mail.gmail.com>

>
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error ([..]/jdk/src/hotspot/share/c1/c1_LIR.hpp:732),
> pid=5366, tid=23811
> #  assert(res->vreg_number() == index) failed: conversion check
>

FWIW, I added some print statements to see what  res->vreg_number() and
index are when this assertion fails:

CONVERSION CHECK FAILED
vreg_number: -131071
index: 131073

Does a negative vreg_number make any sense here?

Eirik.

From eirbjo at gmail.com  Wed Feb 10 14:24:39 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 10 Feb 2021 15:24:39 +0100
Subject: C1 crash in LinearScan::eliminate_spill_moves
In-Reply-To: <CA+pBWhtE=8DsyoTfP48P9dogGkDz+xFiGA5ck4Ja3PCXMpwj3Q@mail.gmail.com>
References: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
 <CA+pBWhunER0hNMY4QjhyvnKBKCKdmk898ZFV7wCMd4b0wcxHhQ@mail.gmail.com>
 <CA+pBWhtE=8DsyoTfP48P9dogGkDz+xFiGA5ck4Ja3PCXMpwj3Q@mail.gmail.com>
Message-ID: <CA+pBWhuBgkKZSdBia2CwnobDH6NX5Hb8m6cwNPCaPZZo5G-4GQ@mail.gmail.com>

> Does a negative vreg_number make any sense here?
>

c1_LIR.hpp:673 does the following:

(index << LIR_OprDesc::data_shift)

LIR_OprDesc::data_shift is 14 in this case and index is 131073. The left
shift results in an integer overflow where the result is -2147467264.

Having no idea what this function actually does, I'm not sure where to
proceed debugging from here. (My C++ skills are that of a four-year)

What does the index represent anyway? Some kind of virtual register? Why
would there be 131073 indexes? Seems a tad excessive?

Eirik.

From stuefe at openjdk.java.net  Wed Feb 10 14:48:37 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 10 Feb 2021 14:48:37 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <cIM82YOgkdoufKdTd7KB7LOKxU0KoB8sVfmQTaCCzl4=.84b29763-bf38-49b4-9d6d-c276d04754bb@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
 <x0p4uWJvCN_XF_i3OAUZekWl8_Q8s6dEC9dd7snWYw8=.95eba846-9474-44d3-8a2d-2221b7ad18da@github.com>
 <cIM82YOgkdoufKdTd7KB7LOKxU0KoB8sVfmQTaCCzl4=.84b29763-bf38-49b4-9d6d-c276d04754bb@github.com>
Message-ID: <6bnV1cycpmBBCDixEal0b-BcuNRtKgYjr0oogXAzDNE=.3daa8c6e-9155-4fd8-a915-bd4fc157f94f@github.com>

On Wed, 10 Feb 2021 10:25:43 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > Are you currently working on this? If yes, what are your plans? I have a half finished prototype where I changed os::reserve_xxx() to return meta information about the reservation alongside the pointer, one of them the reserved page size.
> 
> Yes, I also have a prototype that I've been playing around with. It currently uses an out-parameter to return the page size from `os::reserve_memory_special*` calls. The page sizes is then saved in the ReservedSpace for later use.

I think that makes sense as a solution for this. My attempt was along this:
void* os::reserve_xxx(size, ... blabla..., reservation_info_t* info = NULL);
with reservation_info_t being a holder for information both "public" and opaque: e.g. whether this is executable memory (e.g. for MacOS MAP_JIT issue on committiong), the page size of course, as well as a way for platforms to piggyback internal information (eg. memory type used on AIX).

But your solution sounds simpler, and its sufficient at least for now. So I don't think we work at cross purposes.

> 
> > Have you guys decided whether its okay to remove the "multiple page sizes per reservation" feature?
> 
> I've done some investigations but nothing have been decided. For now my prototype will return the smallest page size used by a mapping. Going forward I would like to do this, but it feels more urgent to get the other things in place first.

No problem, but good to know its not forgotten.

> 
> > There is also another possible simplification I was thinking about, which is to remove the "UseSHM" feature from Linux. I honestly do not know why we still need it. That would simplify rework of large page handling on Linux a lot. I did ask around in December: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/046885.html , but did not get many answers.
> 
> I know and I've been digging around in this area and agree even more now that it would be great to get rid of `UseSHM`. Not sure how if everybody agrees though and I'm currently working on small fix for `UseSHM` so that at least we don't leave it enabled everytime someone sets `+UseLargePages` without having any explicit large pages enabled ([PR#2488](https://github.com/openjdk/jdk/pull/2488)).

Nice that you think the same. I am not sure many people are around which know the history. Maybe we should ask Andrew Haley, I believe he wrote some of that coding. 

I commented on your PR in your PR.

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/2481

From kvn at openjdk.java.net  Wed Feb 10 17:36:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 10 Feb 2021 17:36:39 GMT
Subject: RFR: 8240281: Remove failing assertion code when selecting first
 memory state in SuperWord::co_locate_pack
In-Reply-To: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
References: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
Message-ID: <TlXX1o_iDKbir8vpN1WJGf4nmHBLOBY8aagv0PdpP_A=.de9ff1bb-ad39-4340-9589-fca568c343aa@github.com>

On Wed, 10 Feb 2021 08:49:10 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> While working on [JDK-8238438](https://bugs.openjdk.java.net/browse/JDK-8238438), it was not clear if there is a case where `SuperWord::co_locate_pack()` should pick the memory state of the first load of a pack. We could not find an example and therefore added an `assert(false)` and left the code there to clean it up at some point if the assert was never hit. 
> 
> Now, a newly found fuzzer test showed that are cases where we need to pick the first memory state, triggering the `assert(false)`. In the test case `test()`, a store and a load pack are created but the store pack is filtered in `SuperWord::filter_packs()`. The load `x += iArrFld[j]` must read the old value before the store `iArrFld[j] = j` overrides it. Therefore, the load vector must be executed before any of the stores to `iArrFld[j]`. This, however, is not the case if we pick the memory state of the last load which results in wrong values for `iArrFld`: The stores and the loads are dependent and some of the stores are already executed before the load vector. 
> 
> The fix is to remove the assertion code added by JDK-8238438 and keep the code for selecting the first memory state of a load pack.
> 
> Thanks,
> Christian

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2495

From kvn at openjdk.java.net  Wed Feb 10 17:57:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 10 Feb 2021 17:57:40 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <6bnV1cycpmBBCDixEal0b-BcuNRtKgYjr0oogXAzDNE=.3daa8c6e-9155-4fd8-a915-bd4fc157f94f@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
 <x0p4uWJvCN_XF_i3OAUZekWl8_Q8s6dEC9dd7snWYw8=.95eba846-9474-44d3-8a2d-2221b7ad18da@github.com>
 <cIM82YOgkdoufKdTd7KB7LOKxU0KoB8sVfmQTaCCzl4=.84b29763-bf38-49b4-9d6d-c276d04754bb@github.com>
 <6bnV1cycpmBBCDixEal0b-BcuNRtKgYjr0oogXAzDNE=.3daa8c6e-9155-4fd8-a915-bd4fc157f94f@github.com>
Message-ID: <D8jp-WqvTp0hVQL3pGy203VQg3xAiKCCme9rVlesZys=.2c4c22f7-c0d4-4e72-ac2b-685e9f607900@github.com>

On Wed, 10 Feb 2021 14:45:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Are you currently working on this? If yes, what are your plans? I have a half finished prototype where I changed os::reserve_xxx() to return meta information about the reservation alongside the pointer, one of them the reserved page size.
>>> 
>> 
>> Yes, I also have a prototype that I've been playing around with. It currently uses an out-parameter to return the page size from `os::reserve_memory_special*` calls. The page sizes is then saved in the ReservedSpace for later use. 
>> 
>>> Have you guys decided whether its okay to remove the "multiple page sizes per reservation" feature?
>>> 
>> 
>> I've done some investigations but nothing have been decided. For now my prototype will return the smallest page size used by a mapping. Going forward I would like to do this, but it feels more urgent to get the other things in place first. 
>> 
>>> There is also another possible simplification I was thinking about, which is to remove the "UseSHM" feature from Linux. I honestly do not know why we still need it. That would simplify rework of large page handling on Linux a lot. I did ask around in December: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/046885.html , but did not get many answers.
>>> 
>> 
>> I know and I've been digging around in this area and agree even more now that it would be great to get rid of `UseSHM`. Not sure how if everybody agrees though and I'm currently working on small fix for `UseSHM` so that at least we don't leave it enabled everytime someone sets `+UseLargePages` without having any explicit large pages enabled ([PR#2488](https://github.com/openjdk/jdk/pull/2488)).
>
>> > Are you currently working on this? If yes, what are your plans? I have a half finished prototype where I changed os::reserve_xxx() to return meta information about the reservation alongside the pointer, one of them the reserved page size.
>> 
>> Yes, I also have a prototype that I've been playing around with. It currently uses an out-parameter to return the page size from `os::reserve_memory_special*` calls. The page sizes is then saved in the ReservedSpace for later use.
> 
> I think that makes sense as a solution for this. My attempt was along this:
> void* os::reserve_xxx(size, ... blabla..., reservation_info_t* info = NULL);
> with reservation_info_t being a holder for information both "public" and opaque: e.g. whether this is executable memory (e.g. for MacOS MAP_JIT issue on committiong), the page size of course, as well as a way for platforms to piggyback internal information (eg. memory type used on AIX).
> 
> But your solution sounds simpler, and its sufficient at least for now. So I don't think we work at cross purposes.
> 
>> 
>> > Have you guys decided whether its okay to remove the "multiple page sizes per reservation" feature?
>> 
>> I've done some investigations but nothing have been decided. For now my prototype will return the smallest page size used by a mapping. Going forward I would like to do this, but it feels more urgent to get the other things in place first.
> 
> No problem, but good to know its not forgotten.
> 
>> 
>> > There is also another possible simplification I was thinking about, which is to remove the "UseSHM" feature from Linux. I honestly do not know why we still need it. That would simplify rework of large page handling on Linux a lot. I did ask around in December: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/046885.html , but did not get many answers.
>> 
>> I know and I've been digging around in this area and agree even more now that it would be great to get rid of `UseSHM`. Not sure how if everybody agrees though and I'm currently working on small fix for `UseSHM` so that at least we don't leave it enabled everytime someone sets `+UseLargePages` without having any explicit large pages enabled ([PR#2488](https://github.com/openjdk/jdk/pull/2488)).
> 
> Nice that you think the same. I am not sure many people are around which know the history. Maybe we should ask Andrew Haley, I believe he wrote some of that coding. 
> 
> I commented on your PR in your PR.
> 
> Cheers, Thomas

> > I agree that alignment here should match one used in CodeCache::reserve_heap_memory() and not recalculated. But I am not sure actual_reserved_page_size() returns correct value.
> > May be we should record value in CodeHeap object when it is created.
> 
> Yes, the `actual_reserved_page_size()` is far from perfect and I plan to update `ReservedSpace` to have a page size member that can be queried in places like this and then we can remove this helper. This will be required once we allow multiple large page sizes ([PR#1153](https://github.com/openjdk/jdk/pull/1153)). That said, `actual_reserved_page_size()` is currently doing a good job returning the correct page size since it is considering both if the space is "special", what alignment it used and if transparent huge pages are enabled.
> 
> I would prefer doing the change that records the page size i `ReservedSpace` as a separate patch and in that patch also remove all uses of `actual_reserved_page_size()`. Doing this change now is required to be able to integrate the [new test](https://github.com/openjdk/jdk/compare/master...kstefanj:test-for-trace-page-sizes) I mentioned, and I think it will be helpful for work in this area going forward.

Are you talking about [8261230](https://bugs.openjdk.java.net/browse/JDK-8261230) to do recording?
Okay, then I am fine with this change.

What testing you did for current changes?

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

PR: https://git.openjdk.java.net/jdk/pull/2481

From sjohanss at openjdk.java.net  Wed Feb 10 17:57:41 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 10 Feb 2021 17:57:41 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <6bnV1cycpmBBCDixEal0b-BcuNRtKgYjr0oogXAzDNE=.3daa8c6e-9155-4fd8-a915-bd4fc157f94f@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
 <x0p4uWJvCN_XF_i3OAUZekWl8_Q8s6dEC9dd7snWYw8=.95eba846-9474-44d3-8a2d-2221b7ad18da@github.com>
 <cIM82YOgkdoufKdTd7KB7LOKxU0KoB8sVfmQTaCCzl4=.84b29763-bf38-49b4-9d6d-c276d04754bb@github.com>
 <6bnV1cycpmBBCDixEal0b-BcuNRtKgYjr0oogXAzDNE=.3daa8c6e-9155-4fd8-a915-bd4fc157f94f@github.com>
Message-ID: <isMN5fiRv7Td67WxtbqMF5igucdM7s9Q7AjU6QDRMC8=.1acde195-8f4f-475b-8eb3-bd7d940d3f1a@github.com>

On Wed, 10 Feb 2021 14:45:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 
> ```
> void* os::reserve_xxx(size, ... blabla..., reservation_info_t* info = NULL);
> ```
> 
> with reservation_info_t being a holder for information both "public" and opaque: e.g. whether this is executable memory (e.g. for MacOS MAP_JIT issue on committiong), the page size of course, as well as a way for platforms to piggyback internal information (eg. memory type used on AIX).
> 
> But your solution sounds simpler, and its sufficient at least for now. So I don't think we work at cross purposes.
> 

Yes, we'll see who gets around to making it happen first :)

> > > There is also another possible simplification I was thinking about, which is to remove the "UseSHM" feature from Linux. I honestly do not know why we still need it. That would simplify rework of large page handling on Linux a lot. I did ask around in December: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/046885.html , but did not get many answers.
> > 
> > 
> > I know and I've been digging around in this area and agree even more now that it would be great to get rid of `UseSHM`. Not sure how if everybody agrees though and I'm currently working on small fix for `UseSHM` so that at least we don't leave it enabled everytime someone sets `+UseLargePages` without having any explicit large pages enabled ([PR#2488](https://github.com/openjdk/jdk/pull/2488)).
> 
> Nice that you think the same. I am not sure many people are around which know the history. Maybe we should ask Andrew Haley, I believe he wrote some of that coding.
> 
> I commented on your PR in your PR.

Thanks for all your input, very helpful =)

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

PR: https://git.openjdk.java.net/jdk/pull/2481

From sjohanss at openjdk.java.net  Wed Feb 10 19:21:38 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 10 Feb 2021 19:21:38 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <D8jp-WqvTp0hVQL3pGy203VQg3xAiKCCme9rVlesZys=.2c4c22f7-c0d4-4e72-ac2b-685e9f607900@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
 <x0p4uWJvCN_XF_i3OAUZekWl8_Q8s6dEC9dd7snWYw8=.95eba846-9474-44d3-8a2d-2221b7ad18da@github.com>
 <cIM82YOgkdoufKdTd7KB7LOKxU0KoB8sVfmQTaCCzl4=.84b29763-bf38-49b4-9d6d-c276d04754bb@github.com>
 <6bnV1cycpmBBCDixEal0b-BcuNRtKgYjr0oogXAzDNE=.3daa8c6e-9155-4fd8-a915-bd4fc157f94f@github.com>
 <D8jp-WqvTp0hVQL3pGy203VQg3xAiKCCme9rVlesZys=.2c4c22f7-c0d4-4e72-ac2b-685e9f607900@github.com>
Message-ID: <xLR-Bhh1oqKsUgLx4AFgOtuiDEpiLLO5bKzBi_fBVHE=.4b76c0d9-098c-4c68-b7cc-f23945f47204@github.com>

On Wed, 10 Feb 2021 17:55:00 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > I would prefer doing the change that records the page size i `ReservedSpace` as a separate patch and in that patch also remove all uses of `actual_reserved_page_size()`. Doing this change now is required to be able to integrate the [new test](https://github.com/openjdk/jdk/compare/master...kstefanj:test-for-trace-page-sizes) I mentioned, and I think it will be helpful for work in this area going forward.
> 
> Are you talking about [8261230](https://bugs.openjdk.java.net/browse/JDK-8261230) to do recording?
> Okay, then I am fine with this change.
> 

No that change is also just fixing places where the traced page size is incorrect. Recording the page size in `ReservedSpace` will be handled by [JDK-8261527](https://bugs.openjdk.java.net/browse/JDK-8261527) going forward.

> What testing you did for current changes?

I've done a fair amount of local JTREG testing as well as manual testing to verify we get the correct result with and without explicit large pages enabled. Are there any specific compiler tests you know of that rely on the output from this tracing?

I've also done mach5 tier 1-3 but we have few to none systems in there with explicit huge pages enabled, so that is mostly for sanity.

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

PR: https://git.openjdk.java.net/jdk/pull/2481

From vlivanov at openjdk.java.net  Wed Feb 10 21:28:39 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 10 Feb 2021 21:28:39 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v4]
In-Reply-To: <YHhV9N7mnJDt9mDDw4M9IOVQXSeFJLu4Qool9IneJmw=.3f214ae6-a077-47a5-bc5a-7a6f7d944d6c@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YHhV9N7mnJDt9mDDw4M9IOVQXSeFJLu4Qool9IneJmw=.3f214ae6-a077-47a5-bc5a-7a6f7d944d6c@github.com>
Message-ID: <PJDUKJhVANb0loI2wutc-mE3Dm4Q_RaPIE1d6arkZEo=.3931249f-fa3e-449b-9afd-318af1fa4837@github.com>

On Wed, 10 Feb 2021 06:58:57 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
>> @Benchmark
>> public void testMethod(Blackhole bh) {
>>   int sum = 0;
>>   for (int i = 0; i < data.length; i++) {
>>       Integer ii = Integer.valueOf(data[i]);
>>       if (i < data.length) {
>>           sum += ii.intValue();
>>       }
>>   }
>>   bh.consume(sum);
>> }
>> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
>> The uncommon_trap is generated by the optimized "if", because its condition is always true.
>> 
>> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
>> and deleting the use of box:
>> 
>> There is no additional fail/error(s) of jtreg after this patch.
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete useless line

The improvement you are proposing is not specific to uncommon traps, but can be generalized to any debug usage at safepoints.

The downside is that, in general, rematerialization logic has to use the corresponding pure function in order to materialize the eliminated instance. In this particular case (primitive boxing), it has to take into account the caching effects of primitive box factories. Otherwise, user code can encounter identity paradoxes with rematerialized primitive box instances.

I don't see how the scalarization logic you propose preserves identity constraints imposed by `valueOf` factories.

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

Changes requested by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2401

From xliu at openjdk.java.net  Wed Feb 10 21:58:43 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 10 Feb 2021 21:58:43 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v4]
In-Reply-To: <YHhV9N7mnJDt9mDDw4M9IOVQXSeFJLu4Qool9IneJmw=.3f214ae6-a077-47a5-bc5a-7a6f7d944d6c@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YHhV9N7mnJDt9mDDw4M9IOVQXSeFJLu4Qool9IneJmw=.3f214ae6-a077-47a5-bc5a-7a6f7d944d6c@github.com>
Message-ID: <bf8ckZZvZEGAck-nMGSH3Ef2f4zt1dgFS_LsSLDqhNc=.05904184-0f94-4605-b241-bb70deb2b8d0@github.com>

On Wed, 10 Feb 2021 06:58:57 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
>> @Benchmark
>> public void testMethod(Blackhole bh) {
>>   int sum = 0;
>>   for (int i = 0; i < data.length; i++) {
>>       Integer ii = Integer.valueOf(data[i]);
>>       if (i < data.length) {
>>           sum += ii.intValue();
>>       }
>>   }
>>   bh.consume(sum);
>> }
>> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
>> The uncommon_trap is generated by the optimized "if", because its condition is always true.
>> 
>> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
>> and deleting the use of box:
>> 
>> There is no additional fail/error(s) of jtreg after this patch.
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete useless line

src/hotspot/share/opto/callGenerator.cpp line 588:

> 586:         Node* sobj = new SafePointScalarObjectNode(gvn.type(res)->isa_oopptr(),
> 587: #ifdef ASSERT
> 588:                                                   (AllocateNode*)call,

You can use call->isa_Allocate();  It utilizes node's ad-hoc RTTI  to do type casting.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From kvn at openjdk.java.net  Wed Feb 10 23:00:45 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 10 Feb 2021 23:00:45 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
Message-ID: <7bUn1l-RNEYH7LE-4NzMdUU1EVOVE3brf7KQaQ9lzL4=.bc261d90-cbbb-4a79-9765-ab0a886e1e2d@github.com>

On Tue, 9 Feb 2021 13:45:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> When adding a code heap the page size used with the underlying mapping is traced using `os::trace_page_sizes`. The old code tried to estimate the page-size based on the size, but the mapping has already been done so it is better to check the passed in `ReservedSpace`. Today we don't record the page size in the ReservedSpace, but we have a helper to do a good estimate: `ReservedSpace::actual_reserved_page_size()`. The proposal is to use this function.
> 
> When changing this I also realized that the traced min-size used un-aligned value while the actual `initialize`-call correctly uses the aligned size. Changed so that we also use the aligned size for tracing.
> 
> I'm currently doing some more work in this area and while I haven't added a specific test for this issue I have created a test I plan to integrate separately when a few more needed changes have gone in. The test is Linux-only and validates the output from `os::trace_page_sizes` against the information in `/proc/self/smaps`.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2481

From kvn at openjdk.java.net  Wed Feb 10 23:21:43 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 10 Feb 2021 23:21:43 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v4]
In-Reply-To: <PJDUKJhVANb0loI2wutc-mE3Dm4Q_RaPIE1d6arkZEo=.3931249f-fa3e-449b-9afd-318af1fa4837@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YHhV9N7mnJDt9mDDw4M9IOVQXSeFJLu4Qool9IneJmw=.3f214ae6-a077-47a5-bc5a-7a6f7d944d6c@github.com>
 <PJDUKJhVANb0loI2wutc-mE3Dm4Q_RaPIE1d6arkZEo=.3931249f-fa3e-449b-9afd-318af1fa4837@github.com>
Message-ID: <hgo2_ZSrSDvbOg1xq9wAk34EW4G6PStzYZo-Meg5Zrc=.d600cbf3-0b3e-48bc-8b28-f41ce73e8537@github.com>

On Wed, 10 Feb 2021 21:26:17 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> The improvement you are proposing is not specific to uncommon traps, but can be generalized to any debug usage at safepoints.
> 
> The downside is that, in general, rematerialization logic has to use the corresponding pure function in order to materialize the eliminated instance. In this particular case (primitive boxing), it has to take into account the caching effects of primitive box factories. Otherwise, user code can encounter identity paradoxes with rematerialized primitive box instances.
> 
> I don't see how the scalarization logic you propose preserves identity constraints imposed by `valueOf` factories.

Yes, it seems this optimization introduces the issue we had with Graal (8223320):
"C2 doesn't model Integer.valueOf() as anything special. It just inlines it. So the check that determines whether to allocate a new Integer or take one from the cache always happens at runtime. Graal models it as a BoxNode. It is correctly lowered, however, if it needs to be present in a JVM state, it is described as an allocation. So the decision whether to allocate or take the cached value has to happen during the deopt."
There is code in deoptimizer for JVMCI which looks for cached Boxed values. We may need to adopt it for C2 EA for this optimization to work.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From github.com+2249648+johntortugo at openjdk.java.net  Thu Feb 11 05:12:55 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 11 Feb 2021 05:12:55 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler [v3]
In-Reply-To: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
Message-ID: <Lk9JSJ2eB-Iiw__EgRJVVpQgni0-PvdyI0b43xLTY_s=.a3ab3648-d838-4ed7-921d-cc36bbd3ecad@github.com>

> Relates to: https://bugs.openjdk.java.net/browse/JDK-8241502
> Tested on: Linux tier1, 2 and 3
> 
> Can you please take a look whether these changes are going in the direction expected or not? If it is, I'll continue working on the `JDK-8241502` but I'd like to split it in a few PRs since it's a lot of changes.

John Tortugo has updated the pull request incrementally with one additional commit since the last revision:

  Third part of conversions. Small fix in Assembler::cmovl.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2420/files
  - new: https://git.openjdk.java.net/jdk/pull/2420/files/25824fde..1e8361cc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=01-02

  Stats: 156 lines in 2 files changed: 46 ins; 13 del; 97 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2420.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2420/head:pull/2420

PR: https://git.openjdk.java.net/jdk/pull/2420

From github.com+2249648+johntortugo at openjdk.java.net  Thu Feb 11 05:15:37 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 11 Feb 2021 05:15:37 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler
In-Reply-To: <ZFXn-510nHc4-xULSEQooZYTQ2Uou6FM58KtImAUSsQ=.bf925331-cef6-4708-b49d-754df02fe8e1@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <vP-nQAbUU0P54kYGCK8R2cc_OBIRCk0P3TX_mgM4th8=.5cdfad98-051b-489c-9546-8f967ce2c720@github.com>
 <0azhJ4pD5Tq_lkpPtYMpQBjokflcSQEdWP2Rz9HBm6k=.c3ece6fd-1ae7-49ea-a6eb-ec88a9fbd54d@github.com>
 <d40n9RxaYEqp-6UU7qDQ9rJYrSZ0gXKTT9jqTlylfvU=.8fbcfe20-5f2e-48e8-a189-771701645d9b@github.com>
 <ZFXn-510nHc4-xULSEQooZYTQ2Uou6FM58KtImAUSsQ=.bf925331-cef6-4708-b49d-754df02fe8e1@github.com>
Message-ID: <EWOKWpa98hBLypluJEurop0QC8n-mjDhklaW0cMgh0k=.2ed3d200-a559-47d2-abda-e711898f3fd2@github.com>

On Tue, 9 Feb 2021 01:35:35 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I am curious if the x86_64.o file changes in any significant way (speed of size).
>
> I wish there was a way for the old and new versions to co-exist at the same time, so we could generate the code the old way and and the new way, then compare, for automatic verification of the MacroAssember version.

Thank you all for the feedback!

@iklam - I'll check that and let you know once I make more conversions.

@dean-long - That would be great. I'm all ears for the best way to test this!

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

PR: https://git.openjdk.java.net/jdk/pull/2420

From thartmann at openjdk.java.net  Thu Feb 11 07:47:37 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 11 Feb 2021 07:47:37 GMT
Subject: RFR: 8240281: Remove failing assertion code when selecting first
 memory state in SuperWord::co_locate_pack
In-Reply-To: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
References: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
Message-ID: <mwZpTP9L8mKlCy-W_n1GxzPh7Anoz1F8-GRBYt870lY=.c66c7d59-2571-4062-a07e-5137734ece29@github.com>

On Wed, 10 Feb 2021 08:49:10 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> While working on [JDK-8238438](https://bugs.openjdk.java.net/browse/JDK-8238438), it was not clear if there is a case where `SuperWord::co_locate_pack()` should pick the memory state of the first load of a pack. We could not find an example and therefore added an `assert(false)` and left the code there to clean it up at some point if the assert was never hit. 
> 
> Now, a newly found fuzzer test showed that are cases where we need to pick the first memory state, triggering the `assert(false)`. In the test case `test()`, a store and a load pack are created but the store pack is filtered in `SuperWord::filter_packs()`. The load `x += iArrFld[j]` must read the old value before the store `iArrFld[j] = j` overrides it. Therefore, the load vector must be executed before any of the stores to `iArrFld[j]`. This, however, is not the case if we pick the memory state of the last load which results in wrong values for `iArrFld`: The stores and the loads are dependent and some of the stores are already executed before the load vector. 
> 
> The fix is to remove the assertion code added by JDK-8238438 and keep the code for selecting the first memory state of a load pack.
> 
> Thanks,
> Christian

Looks good. Great that we finally have a test for this case!

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2495

From thartmann at openjdk.java.net  Thu Feb 11 07:49:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 11 Feb 2021 07:49:39 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
Message-ID: <DNT3GNMxK16JpHxM1kdqWO70TQba9Fj8pVE2p5dceS0=.110a7de9-9cd9-46f5-ae33-3c063785f5d6@github.com>

On Tue, 9 Feb 2021 13:45:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> When adding a code heap the page size used with the underlying mapping is traced using `os::trace_page_sizes`. The old code tried to estimate the page-size based on the size, but the mapping has already been done so it is better to check the passed in `ReservedSpace`. Today we don't record the page size in the ReservedSpace, but we have a helper to do a good estimate: `ReservedSpace::actual_reserved_page_size()`. The proposal is to use this function.
> 
> When changing this I also realized that the traced min-size used un-aligned value while the actual `initialize`-call correctly uses the aligned size. Changed so that we also use the aligned size for tracing.
> 
> I'm currently doing some more work in this area and while I haven't added a specific test for this issue I have created a test I plan to integrate separately when a few more needed changes have gone in. The test is Linux-only and validates the output from `os::trace_page_sizes` against the information in `/proc/self/smaps`.

Looks good to me, thanks for fixing!

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2481

From thartmann at openjdk.java.net  Thu Feb 11 07:54:38 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 11 Feb 2021 07:54:38 GMT
Subject: RFR: 8259430: C2: assert(in_vt->length() == out_vt->length())
 failed: mismatch on number of elements
In-Reply-To: <q5UXCU4eIfYEiJuz8odYLk2nUDnSxC5cliVDon2Dy4I=.624aab36-5104-40be-8c4c-29f26df15c88@github.com>
References: <q5UXCU4eIfYEiJuz8odYLk2nUDnSxC5cliVDon2Dy4I=.624aab36-5104-40be-8c4c-29f26df15c88@github.com>
Message-ID: <t_VxnMGraVaXxIRxGrVpdHH2WRZAYuerTFIE3yhGEPU=.364b1eed-509b-4f8d-9325-5f5e1925bad4@github.com>

On Tue, 2 Feb 2021 12:57:11 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Another problem caused by pathological cases (in effectively dead code): `VectorUnboxNode::Ideal()/Value()` ignore cast nodes (even the ones carrying control dependency) to reveal `VectorBox` and sometimes it exposes type mismatches between box/unbox operations which are impossible in practice. 
> 
> Proposed fix turns the assert into a runtime check to ignore problematic IR shape.

Looks reasonable to me.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2353

From thartmann at openjdk.java.net  Thu Feb 11 07:55:38 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 11 Feb 2021 07:55:38 GMT
Subject: RFR: 8261250: Dependencies: Remove unused dependency types
In-Reply-To: <2-SBc7bcjQnndYbBWgQFNs4nY_OjM-5_E5f3g2-OEiA=.d235e241-adc8-4f51-8bf9-66915f068a95@github.com>
References: <2-SBc7bcjQnndYbBWgQFNs4nY_OjM-5_E5f3g2-OEiA=.d235e241-adc8-4f51-8bf9-66915f068a95@github.com>
Message-ID: <suFY6kKvp-25cStpzCnmz_FTQEl7UOdjoG2fyNlzWpo=.516720d4-77f3-49d6-9e90-f67c20a3f634@github.com>

On Fri, 5 Feb 2021 17:58:06 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Remove support of unused dependency types from Dependencies.
> 
> Testing: 
> - [x] hs-precheckin-comp, hs-tier1, hs-tier2.

Nice cleanup, looks good!

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2431

From jbhateja at openjdk.java.net  Thu Feb 11 08:38:49 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 11 Feb 2021 08:38:49 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI instruction
Message-ID: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>

BMI2 BHZI instruction can be used to optimize the instruction sequence
used for mask generation at various place in array copy stubs and partial in-lining for small copy operations.

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

Commit messages:
 - 8261553: Efficient mask generation using BMI2 BZHI instruction.

Changes: https://git.openjdk.java.net/jdk/pull/2522/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2522&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261553
  Stats: 30 lines in 5 files changed: 8 ins; 11 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2522/head:pull/2522

PR: https://git.openjdk.java.net/jdk/pull/2522

From vlivanov at openjdk.java.net  Thu Feb 11 10:19:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 11 Feb 2021 10:19:40 GMT
Subject: RFR: 8259430: C2: assert(in_vt->length() == out_vt->length())
 failed: mismatch on number of elements
In-Reply-To: <t_VxnMGraVaXxIRxGrVpdHH2WRZAYuerTFIE3yhGEPU=.364b1eed-509b-4f8d-9325-5f5e1925bad4@github.com>
References: <q5UXCU4eIfYEiJuz8odYLk2nUDnSxC5cliVDon2Dy4I=.624aab36-5104-40be-8c4c-29f26df15c88@github.com>
 <t_VxnMGraVaXxIRxGrVpdHH2WRZAYuerTFIE3yhGEPU=.364b1eed-509b-4f8d-9325-5f5e1925bad4@github.com>
Message-ID: <BliuJRgfqxBMu-e5VnqFjEJH7GswowG6blWBcTGmCeQ=.dde6ab7b-88d1-43e0-86e9-8abbb7af6dea@github.com>

On Thu, 11 Feb 2021 07:51:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Another problem caused by pathological cases (in effectively dead code): `VectorUnboxNode::Ideal()/Value()` ignore cast nodes (even the ones carrying control dependency) to reveal `VectorBox` and sometimes it exposes type mismatches between box/unbox operations which are impossible in practice. 
>> 
>> Proposed fix turns the assert into a runtime check to ignore problematic IR shape.
>
> Looks reasonable to me.

Thanks for the reviews, Vladimir and Tobias.

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

PR: https://git.openjdk.java.net/jdk/pull/2353

From vlivanov at openjdk.java.net  Thu Feb 11 10:19:39 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 11 Feb 2021 10:19:39 GMT
Subject: RFR: 8261250: Dependencies: Remove unused dependency types
In-Reply-To: <suFY6kKvp-25cStpzCnmz_FTQEl7UOdjoG2fyNlzWpo=.516720d4-77f3-49d6-9e90-f67c20a3f634@github.com>
References: <2-SBc7bcjQnndYbBWgQFNs4nY_OjM-5_E5f3g2-OEiA=.d235e241-adc8-4f51-8bf9-66915f068a95@github.com>
 <suFY6kKvp-25cStpzCnmz_FTQEl7UOdjoG2fyNlzWpo=.516720d4-77f3-49d6-9e90-f67c20a3f634@github.com>
Message-ID: <MiyZWQznfu_6em8_77KDl1-cv6Rw3mHQEjTVEdDt53o=.a35b9ee5-c4e8-47ec-89f5-e782908b00d9@github.com>

On Thu, 11 Feb 2021 07:53:08 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Remove support of unused dependency types from Dependencies.
>> 
>> Testing: 
>> - [x] hs-precheckin-comp, hs-tier1, hs-tier2.
>
> Nice cleanup, looks good!

Thanks for the reviews, Vladimir and Tobias.

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

PR: https://git.openjdk.java.net/jdk/pull/2431

From vlivanov at openjdk.java.net  Thu Feb 11 10:19:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 11 Feb 2021 10:19:41 GMT
Subject: Integrated: 8259430: C2: assert(in_vt->length() == out_vt->length())
 failed: mismatch on number of elements
In-Reply-To: <q5UXCU4eIfYEiJuz8odYLk2nUDnSxC5cliVDon2Dy4I=.624aab36-5104-40be-8c4c-29f26df15c88@github.com>
References: <q5UXCU4eIfYEiJuz8odYLk2nUDnSxC5cliVDon2Dy4I=.624aab36-5104-40be-8c4c-29f26df15c88@github.com>
Message-ID: <dQipx59P8rtL-2g08iDz_XBuHp62vJgi808JCEKtFH0=.4c9df345-7d75-44cf-9d6a-880045ea0535@github.com>

On Tue, 2 Feb 2021 12:57:11 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Another problem caused by pathological cases (in effectively dead code): `VectorUnboxNode::Ideal()/Value()` ignore cast nodes (even the ones carrying control dependency) to reveal `VectorBox` and sometimes it exposes type mismatches between box/unbox operations which are impossible in practice. 
> 
> Proposed fix turns the assert into a runtime check to ignore problematic IR shape.

This pull request has now been integrated.

Changeset: 3ede231d
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3ede231d
Stats:     23 lines in 2 files changed: 6 ins; 2 del; 15 mod

8259430: C2: assert(in_vt->length() == out_vt->length()) failed: mismatch on number of elements

Reviewed-by: kvn, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2353

From vlivanov at openjdk.java.net  Thu Feb 11 10:19:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 11 Feb 2021 10:19:41 GMT
Subject: Integrated: 8261250: Dependencies: Remove unused dependency types
In-Reply-To: <2-SBc7bcjQnndYbBWgQFNs4nY_OjM-5_E5f3g2-OEiA=.d235e241-adc8-4f51-8bf9-66915f068a95@github.com>
References: <2-SBc7bcjQnndYbBWgQFNs4nY_OjM-5_E5f3g2-OEiA=.d235e241-adc8-4f51-8bf9-66915f068a95@github.com>
Message-ID: <kMaOsa8TMTyKDKdn7hTATccyOTLqEpg9wUscNzWtQr0=.9b0841b6-39b6-46d6-bd69-2cc06c4bc998@github.com>

On Fri, 5 Feb 2021 17:58:06 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Remove support of unused dependency types from Dependencies.
> 
> Testing: 
> - [x] hs-precheckin-comp, hs-tier1, hs-tier2.

This pull request has now been integrated.

Changeset: a9c36805
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a9c36805
Stats:     253 lines in 2 files changed: 1 ins; 238 del; 14 mod

8261250: Dependencies: Remove unused dependency types

Reviewed-by: kvn, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2431

From redestad at openjdk.java.net  Thu Feb 11 10:30:38 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Feb 2021 10:30:38 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction
In-Reply-To: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
Message-ID: <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>

On Thu, 11 Feb 2021 08:31:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> BMI2 BHZI instruction can be used to optimize the instruction sequence
> used for mask generation at various place in array copy stubs and partial in-lining for small copy operations.

- Rather than removing the old code, I believe the code calling bzhiq needs to be in a branch checking `VM_Version::supports_bmi2`. Otherwise you'll hit asserts on older hardware without this extension
- Some demonstration of the performance benefit would be nice - either a new microbenchmark or a statistically significant result running some existing ones, e.g. `make test TEST=micro:ArrayCopy`

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

Changes requested by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2522

From eirbjo at gmail.com  Thu Feb 11 11:10:37 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 11 Feb 2021 12:10:37 +0100
Subject: C1 crash in LinearScan::eliminate_spill_moves
In-Reply-To: <CA+pBWhuBgkKZSdBia2CwnobDH6NX5Hb8m6cwNPCaPZZo5G-4GQ@mail.gmail.com>
References: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
 <CA+pBWhunER0hNMY4QjhyvnKBKCKdmk898ZFV7wCMd4b0wcxHhQ@mail.gmail.com>
 <CA+pBWhtE=8DsyoTfP48P9dogGkDz+xFiGA5ck4Ja3PCXMpwj3Q@mail.gmail.com>
 <CA+pBWhuBgkKZSdBia2CwnobDH6NX5Hb8m6cwNPCaPZZo5G-4GQ@mail.gmail.com>
Message-ID: <CA+pBWhv-Po7f-5pp-wT9CHP7Hnkxzx--WKoA87813KMk0Tg5Rg@mail.gmail.com>

>
> Why would there be 131073 indexes? Seems a tad excessive?
>

Some further analysis reveals what I think leads to the pathological case.
It's somehow tripped by replacing RETURNs with GOTOs

First a bit of context:

The agent instruments methods by injecting a local variable for each unique
line number of the line number table using a pair or ICONST_0, ISTORE N for
each line N:

    ICONST_0
    ISTORE 1
    [..]
    ICONST_0
    ISTORE N

This counter is then incremented at each line entry using IINC:

    IINC 1 1
    [..]
    IINC N 1

Finally, before each RETURN we report each line count by calling out ILOAD
X/ INVOKESTATIC (X):

    ILOAD 1
    INVOKESTATIC com/github/eirbjo/JDK8261235Reproducer.countVisits (I)V
    [..]
    ILOAD N
    INVOKESTATIC com/github/eirbjo/JDK8261235Reproducer.countVisits (I)V

This works nicely for methods with one (or a few) RETURNs. For methods with
many returns, the byte code size grows dramatically because the (ILOAD X,
INVOKESTATIC X) sequence is repeated  for every RETURN. (In the agent
actually uses INVOKEVIRTUAL instead, and the method takes the line number
as an additional argument, adding an extra bycode code to load or DUP the
receiver object and a ICONST/BIPUSH/SIPUSH to put the line number on the
stack).

Our example method (org.jaxen.saxpath.base.Verifier::isXMLLetter) has 206
line numbers and 358 IRETURNs.

Each ILOAD, INVOKESTATIC consumes 2 + 3 = 5 bytes. For isXMLLetter, that
means 1040 bytes per RETURN, adding up to a total of 372320 bytes for the
reporting part, bringing us well above the 64K byte code limit.

By replacing each RETURN with a GOTO, we can instead inject the 1040 bytes
only once, which is a considerable saving.

This of course changes the control flow graph of the method considerably,
which is what I think might be tripping up C1's register allocation.

I used -XX:TraceLinearScanLevel=1 to compare the compilations (without the
reporting for the RETURN case, since it would hit the 64K roof).

Here's a compilation using RETURNs:

  518   93       2       org.jaxen.saxpath.base.Verifier::isXMLLetter (5414
bytes)
----- linear-scan block order:
   0: B716    loop: -1  depth:  0                dom: NULL     sux: B717
   1: B717    loop: -1  depth:  0                dom: B716     preds: B716
    sux: B0
   2: B 0    loop: -1  depth:  0                dom: B717     preds: B717
  sux: B2 B1
       [..]
716: B 1    loop: -1  depth:  0                dom: B0     preds: B0

Compare this with a GOTO compilation:

  437   95       3       org.jaxen.saxpath.base.Verifier::isXMLLetter (6130
bytes)
----- linear-scan block order:
   0: B1106    loop: -1  depth:  0                dom: NULL     sux: B1107
   1: B1107    loop: -1  depth:  0                dom: B1106     preds:
B1106     sux: B0
   2: B 0    loop: -1  depth:  0                dom: B1107     preds: B1107
    sux: B2 B1
       [..]
716: B 1    loop: -1  depth:  0                dom: B0     preds: B0
sux: B3
717: B 3    loop: -1  depth:  0                dom: B0     preds: B1 B4 B6
B8 B10 B12 B14 B16 B18 B20 B22 B24 B26 B28 B30 B32 B34 B36 B38 B40 B42 B44
B46 B48 B50 B52 B54 B56 B58 B60 B62 B64 B66 B68 B70 B72 B74 B76 B78 B80 B82
B84 B86 B88 B90 B92 B94 B96 B98 B100 B102 B104 B106 B108 B110 B112 B114
B116 B118 B120 B122 B124 B126 B128 B130 B132 B134 B136 B138 B140 B142 B144
B146 B148 B150 B152 B154 B156 B158 B160 B162 B164 B166 B168 B170 B172 B174
B176 B178 B180 B182 B184 B186 B188 B190 B192 B194 B196 B198 B200 B202 B204
B206 B208 B210 B212 B214 B216 B218 B220 B222 B224 B226 B228 B230 B232 B234
B236 B238 B240 B242 B244 B246 B248 B250 B252 B254 B256 B258 B260 B262 B264
B266 B268 B270 B272 B274 B276 B278 B280 B282 B284 B286 B288 B290 B292 B294
B296 B298 B300 B302 B304 B306 B308 B310 B312 B314 B316 B318 B320 B322 B324
B326 B328 B330 B332 B334 B336 B338 B340 B342 B344 B346 B348 B350 B352 B354
B356 B358 B360 B362 B364 B366 B368 B370 B372 B374 B376 B378 B380 B382 B384
B386 B388 B390 B392 B394 B396 B398 B400 B402 B404 B406 B408 B410 B412 B414
B416 B418 B420 B422 B424 B426 B428 B430 B432 B434 B436 B438 B440 B442 B444
B446 B448 B450 B452 B454 B456 B458 B460 B462 B464 B466 B468 B470 B472 B474
B476 B478 B480 B482 B484 B486 B488 B490 B492 B494 B496 B498 B500 B502 B504
B506 B508 B510 B512 B514 B516 B518 B520 B522 B524 B526 B528 B530 B532 B534
B536 B538 B540 B542 B544 B546 B548 B550 B552 B554 B556 B558 B560 B562 B564
B566 B568 B570 B572 B574 B576 B578 B580 B582 B584 B586 B588 B590 B592 B594
B596 B598 B600 B602 B604 B606 B608 B610 B612 B614 B616 B618 B620 B622 B624
B626 B628 B630 B632 B634 B636 B638 B640 B642 B644 B646 B648 B650 B652 B654
B656 B658 B660 B662 B664 B666 B668 B670 B672 B674 B676 B678 B680 B682 B684
B686 B688 B690 B692 B694 B696 B698 B700 B702 B704 B706 B708 B710 B712 B714
B715

Notice the 717 line with 715 'preds'?

The next part of the trace shows 'Before Register Allocation', which looks
innocuous until we get to the 714 block:

B714 [5146, 5147] preds: B713 sux: B3
__id_Instruction___________________________________________
6454 label [label:0x00007fb855027ae0]
6456 move [metadata:0x0000000118878000|M] [R1643|M]
6458 add [Base:[R1643|M] Disp: 20320|J] [int:1|I] [Base:[R1643|M] Disp:
20320|J]
6460 move [int:1|I] [R1838|I]
6462 move [int:1|I] [R1837|I]

[..]     // move repeated 191 times!

6844 move [int:1|I] [R1646|I]
6846 move [int:1|I] [R1645|I]
6848 move [int:1|I] [R1644|I]
6850 branch [AL] [B3]

This then repeats for B715 and we get to B712:

B712 [5136, 5137] preds: B711 sux: B3
__id_Instruction___________________________________________
7250 label [label:0x00007fb8550274e0]
7252 move [metadata:0x0000000118878000|M] [R1840|M]
7254 add [Base:[R1840|M] Disp: 20264|J] [int:1|I] [Base:[R1840|M] Disp:
20264|J]
7256 move [int:1|I] [R1838|I]
7258 move [int:1|I] [R1837|I]
7260 move [int:1|I] [R1836|I]

And then in inverse order:

B710 [5123, 5124] preds: B709 sux: B3
(lots of moves)

B708 [5113, 5114] preds: B707 sux: B3
(lots of moves)
(continues for 4MBs)

B1 [624, 625] preds: B0 sux: B3
(lots of moves)

Finally, we get to B3 which actually seems to show some real code:

B3 [5157, 6129] preds: B1 B4 B6 B8 B10 B12 B14 B16 B18 B20 B22 B24 B26 B28
B30 B32 B34 B36 B38 B40 B42 B44 B46 B48 B50 B52 B54 B56 B58 B60 B62 B64 B66
B68 B70 B72 B74 B76 B78 B80 B82 B84 B86 B88 B90 B92 B94 B96 B98 B100 B102
B104 B106 B108 B110 B112 B114 B116 B118 B120 B122 B124 B126 B128 B130 B132
B134 B136 B138 B140 B142 B144 B146 B148 B150 B152 B154 B156 B158 B160 B162
B164 B166 B168 B170 B172 B174 B176 B178 B180 B182 B184 B186 B188 B190 B192
B194 B196 B198 B200 B202 B204 B206 B208 B210 B212 B214 B216 B218 B220 B222
B224 B226 B228 B230 B232 B234 B236 B238 B240 B242 B244 B246 B248 B250 B252
B254 B256 B258 B260 B262 B264 B266 B268 B270 B272 B274 B276 B278 B280 B282
B284 B286 B288 B290 B292 B294 B296 B298 B300 B302 B304 B306 B308 B310 B312
B314 B316 B318 B320 B322 B324 B326 B328 B330 B332 B334 B336 B338 B340 B342
B344 B346 B348 B350 B352 B354 B356 B358 B360 B362 B364 B366 B368 B370 B372
B374 B376 B378 B380 B382 B384 B386 B388 B390 B392 B394 B396 B398 B400 B402
B404 B406 B408 B410 B412 B414 B416 B418 B420 B422 B424 B426 B428 B430 B432
B434 B436 B438 B440 B442 B444 B446 B448 B450 B452 B454 B456 B458 B460 B462
B464 B466 B468 B470 B472 B474 B476 B478 B480 B482 B484 B486 B488 B490 B492
B494 B496 B498 B500 B502 B504 B506 B508 B510 B512 B514 B516 B518 B520 B522
B524 B526 B528 B530 B532 B534 B536 B538 B540 B542 B544 B546 B548 B550 B552
B554 B556 B558 B560 B562 B564 B566 B568 B570 B572 B574 B576 B578 B580 B582
B584 B586 B588 B590 B592 B594 B596 B598 B600 B602 B604 B606 B608 B610 B612
B614 B616 B618 B620 B622 B624 B626 B628 B630 B632 B634 B636 B638 B640 B642
B644 B646 B648 B650 B652 B654 B656 B658 B660 B662 B664 B666 B668 B670 B672
B674 B676 B678 B680 B682 B684 B686 B688 B690 B692 B694 B696 B698 B700 B702
B704 B706 B708 B710 B712 B714 B715
__id_Instruction___________________________________________
148938 label [label:0x00007fb854776bd0]
148940 profile_call isXMLLetter.org/jaxen/saxpath/base/Verifier @ 5158
[R2196|M]  [R2197|J]
148942 move [metadata:0x000000011886d478|M] [R2198|M]
148944 move [Base:[R2198|M] Disp: 284|I] [R2199|I]
148946 add [R2199|I] [int:2|I] [R2199|I]
148948 move [R2199|I] [Base:[R2198|M] Disp: 284|I]
148950 logic_and [R2199|I] [int:2097150|I] [R2199|I]
148952 cmp [EQ] [R2199|I] [int:0|I]
148954 branch [EQ] [CounterOverflowStub: 0x00007fb85715f4d0]
[etc..].


The output then continues with a wall of text which makes a beautiful
pattern if I get my terminal width exactly right, but otherwise makes no
sense to me :-)

Here's hoping that this analysis may be of some use.

Cheers,
Eirik.

From jbhateja at openjdk.java.net  Thu Feb 11 12:25:53 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 11 Feb 2021 12:25:53 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v2]
In-Reply-To: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
Message-ID: <7AXx69j_wscf8ENt98_apHTd1OKbeO80nNVpU68Z794=.7d776104-0f08-4e92-b229-bc210123fc4e@github.com>

> BMI2 BHZI instruction can be used to optimize the instruction sequence
> used for mask generation at various place in array copy stubs and partial in-lining for small copy operations.

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8261553: Adding BMI2 missing check for partial in-lining.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2522/files
  - new: https://git.openjdk.java.net/jdk/pull/2522/files/38495aec..84c9c2da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2522&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2522&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2522/head:pull/2522

PR: https://git.openjdk.java.net/jdk/pull/2522

From jbhateja at openjdk.java.net  Thu Feb 11 12:25:53 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 11 Feb 2021 12:25:53 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v2]
In-Reply-To: <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
Message-ID: <csbaOvyMeGK0-mJxDyJxhmdHa_HcocG7CQtw4XUtrfE=.35c9820d-964c-47e7-8cdb-db4e8f76d082@github.com>

On Thu, 11 Feb 2021 10:28:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261553: Adding BMI2 missing check for partial in-lining.
>
> - Rather than removing the old code, I believe the code calling bzhiq needs to be in a branch checking `VM_Version::supports_bmi2`. Otherwise you'll hit asserts on older hardware without this extension
> - Some demonstration of the performance benefit would be nice - either a new microbenchmark or a statistically significant result running some existing ones, e.g. `make test TEST=micro:ArrayCopy`

Hi Claes,

Here is the JMH performance data over CLX for arraycopy benchmarks:
http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_BASELINE.txt
http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_WITH_OPTS.txt

Regards,
Jatin

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From jbhateja at openjdk.java.net  Thu Feb 11 12:33:38 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 11 Feb 2021 12:33:38 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v2]
In-Reply-To: <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
Message-ID: <tbcbk9WWHobk7MHK3y8exYiS48GZ7X-6X-9SZjSY05s=.a0ef1d30-00de-439f-8793-0243d0c68e33@github.com>

On Thu, 11 Feb 2021 10:28:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> * Rather than removing the old code, I believe the code calling bzhiq needs to be in a branch checking `VM_Version::supports_bmi2`. Otherwise you'll hit asserts on older hardware without this extension

Hi Claes, added missing safely check for BMI2,  its in general  rare that a target supporting AVX-512 does not support BMI2

> * Some demonstration of the performance benefit would be nice - either a new microbenchmark or a statistically significant result running some existing ones, e.g. `make test TEST=micro:ArrayCopy`

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From christian.hagedorn at oracle.com  Thu Feb 11 12:56:02 2021
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Thu, 11 Feb 2021 13:56:02 +0100
Subject: C1 crash in LinearScan::eliminate_spill_moves
In-Reply-To: <CA+pBWhv-Po7f-5pp-wT9CHP7Hnkxzx--WKoA87813KMk0Tg5Rg@mail.gmail.com>
References: <CA+pBWht3KCYUT_9F5+9pTF3XDs21Ni_pd4fX3_FQ+gunW5VUxw@mail.gmail.com>
 <CA+pBWhunER0hNMY4QjhyvnKBKCKdmk898ZFV7wCMd4b0wcxHhQ@mail.gmail.com>
 <CA+pBWhtE=8DsyoTfP48P9dogGkDz+xFiGA5ck4Ja3PCXMpwj3Q@mail.gmail.com>
 <CA+pBWhuBgkKZSdBia2CwnobDH6NX5Hb8m6cwNPCaPZZo5G-4GQ@mail.gmail.com>
 <CA+pBWhv-Po7f-5pp-wT9CHP7Hnkxzx--WKoA87813KMk0Tg5Rg@mail.gmail.com>
Message-ID: <1a7cc007-8de7-5e86-7f34-0d2a17ea847b@oracle.com>

Hi Eirik

Thanks for investigating further. I had a look at it and I think we are 
just running out of virtual registers in the MoveResolver but do not 
handle it (thus the virtual register number overflow). We should 
probably just bail out in this case. We can handle it similarly as in 
LIRGenerator::new_register() where we also bail out if we need too many 
virtual registers. I'm working on such a fix for it.

Best regards,
Christian

On 11.02.21 12:10, Eirik Bj?rsn?s wrote:
>> Why would there be 131073 indexes? Seems a tad excessive?
>>
> Some further analysis reveals what I think leads to the pathological case.
> It's somehow tripped by replacing RETURNs with GOTOs
>
> First a bit of context:
>
> The agent instruments methods by injecting a local variable for each unique
> line number of the line number table using a pair or ICONST_0, ISTORE N for
> each line N:
>
>      ICONST_0
>      ISTORE 1
>      [..]
>      ICONST_0
>      ISTORE N
>
> This counter is then incremented at each line entry using IINC:
>
>      IINC 1 1
>      [..]
>      IINC N 1
>
> Finally, before each RETURN we report each line count by calling out ILOAD
> X/ INVOKESTATIC (X):
>
>      ILOAD 1
>      INVOKESTATIC com/github/eirbjo/JDK8261235Reproducer.countVisits (I)V
>      [..]
>      ILOAD N
>      INVOKESTATIC com/github/eirbjo/JDK8261235Reproducer.countVisits (I)V
>
> This works nicely for methods with one (or a few) RETURNs. For methods with
> many returns, the byte code size grows dramatically because the (ILOAD X,
> INVOKESTATIC X) sequence is repeated  for every RETURN. (In the agent
> actually uses INVOKEVIRTUAL instead, and the method takes the line number
> as an additional argument, adding an extra bycode code to load or DUP the
> receiver object and a ICONST/BIPUSH/SIPUSH to put the line number on the
> stack).
>
> Our example method (org.jaxen.saxpath.base.Verifier::isXMLLetter) has 206
> line numbers and 358 IRETURNs.
>
> Each ILOAD, INVOKESTATIC consumes 2 + 3 = 5 bytes. For isXMLLetter, that
> means 1040 bytes per RETURN, adding up to a total of 372320 bytes for the
> reporting part, bringing us well above the 64K byte code limit.
>
> By replacing each RETURN with a GOTO, we can instead inject the 1040 bytes
> only once, which is a considerable saving.
>
> This of course changes the control flow graph of the method considerably,
> which is what I think might be tripping up C1's register allocation.
>
> I used -XX:TraceLinearScanLevel=1 to compare the compilations (without the
> reporting for the RETURN case, since it would hit the 64K roof).
>
> Here's a compilation using RETURNs:
>
>    518   93       2       org.jaxen.saxpath.base.Verifier::isXMLLetter (5414
> bytes)
> ----- linear-scan block order:
>     0: B716    loop: -1  depth:  0                dom: NULL     sux: B717
>     1: B717    loop: -1  depth:  0                dom: B716     preds: B716
>      sux: B0
>     2: B 0    loop: -1  depth:  0                dom: B717     preds: B717
>    sux: B2 B1
>         [..]
> 716: B 1    loop: -1  depth:  0                dom: B0     preds: B0
>
> Compare this with a GOTO compilation:
>
>    437   95       3       org.jaxen.saxpath.base.Verifier::isXMLLetter (6130
> bytes)
> ----- linear-scan block order:
>     0: B1106    loop: -1  depth:  0                dom: NULL     sux: B1107
>     1: B1107    loop: -1  depth:  0                dom: B1106     preds:
> B1106     sux: B0
>     2: B 0    loop: -1  depth:  0                dom: B1107     preds: B1107
>      sux: B2 B1
>         [..]
> 716: B 1    loop: -1  depth:  0                dom: B0     preds: B0
> sux: B3
> 717: B 3    loop: -1  depth:  0                dom: B0     preds: B1 B4 B6
> B8 B10 B12 B14 B16 B18 B20 B22 B24 B26 B28 B30 B32 B34 B36 B38 B40 B42 B44
> B46 B48 B50 B52 B54 B56 B58 B60 B62 B64 B66 B68 B70 B72 B74 B76 B78 B80 B82
> B84 B86 B88 B90 B92 B94 B96 B98 B100 B102 B104 B106 B108 B110 B112 B114
> B116 B118 B120 B122 B124 B126 B128 B130 B132 B134 B136 B138 B140 B142 B144
> B146 B148 B150 B152 B154 B156 B158 B160 B162 B164 B166 B168 B170 B172 B174
> B176 B178 B180 B182 B184 B186 B188 B190 B192 B194 B196 B198 B200 B202 B204
> B206 B208 B210 B212 B214 B216 B218 B220 B222 B224 B226 B228 B230 B232 B234
> B236 B238 B240 B242 B244 B246 B248 B250 B252 B254 B256 B258 B260 B262 B264
> B266 B268 B270 B272 B274 B276 B278 B280 B282 B284 B286 B288 B290 B292 B294
> B296 B298 B300 B302 B304 B306 B308 B310 B312 B314 B316 B318 B320 B322 B324
> B326 B328 B330 B332 B334 B336 B338 B340 B342 B344 B346 B348 B350 B352 B354
> B356 B358 B360 B362 B364 B366 B368 B370 B372 B374 B376 B378 B380 B382 B384
> B386 B388 B390 B392 B394 B396 B398 B400 B402 B404 B406 B408 B410 B412 B414
> B416 B418 B420 B422 B424 B426 B428 B430 B432 B434 B436 B438 B440 B442 B444
> B446 B448 B450 B452 B454 B456 B458 B460 B462 B464 B466 B468 B470 B472 B474
> B476 B478 B480 B482 B484 B486 B488 B490 B492 B494 B496 B498 B500 B502 B504
> B506 B508 B510 B512 B514 B516 B518 B520 B522 B524 B526 B528 B530 B532 B534
> B536 B538 B540 B542 B544 B546 B548 B550 B552 B554 B556 B558 B560 B562 B564
> B566 B568 B570 B572 B574 B576 B578 B580 B582 B584 B586 B588 B590 B592 B594
> B596 B598 B600 B602 B604 B606 B608 B610 B612 B614 B616 B618 B620 B622 B624
> B626 B628 B630 B632 B634 B636 B638 B640 B642 B644 B646 B648 B650 B652 B654
> B656 B658 B660 B662 B664 B666 B668 B670 B672 B674 B676 B678 B680 B682 B684
> B686 B688 B690 B692 B694 B696 B698 B700 B702 B704 B706 B708 B710 B712 B714
> B715
>
> Notice the 717 line with 715 'preds'?
>
> The next part of the trace shows 'Before Register Allocation', which looks
> innocuous until we get to the 714 block:
>
> B714 [5146, 5147] preds: B713 sux: B3
> __id_Instruction___________________________________________
> 6454 label [label:0x00007fb855027ae0]
> 6456 move [metadata:0x0000000118878000|M] [R1643|M]
> 6458 add [Base:[R1643|M] Disp: 20320|J] [int:1|I] [Base:[R1643|M] Disp:
> 20320|J]
> 6460 move [int:1|I] [R1838|I]
> 6462 move [int:1|I] [R1837|I]
>
> [..]     // move repeated 191 times!
>
> 6844 move [int:1|I] [R1646|I]
> 6846 move [int:1|I] [R1645|I]
> 6848 move [int:1|I] [R1644|I]
> 6850 branch [AL] [B3]
>
> This then repeats for B715 and we get to B712:
>
> B712 [5136, 5137] preds: B711 sux: B3
> __id_Instruction___________________________________________
> 7250 label [label:0x00007fb8550274e0]
> 7252 move [metadata:0x0000000118878000|M] [R1840|M]
> 7254 add [Base:[R1840|M] Disp: 20264|J] [int:1|I] [Base:[R1840|M] Disp:
> 20264|J]
> 7256 move [int:1|I] [R1838|I]
> 7258 move [int:1|I] [R1837|I]
> 7260 move [int:1|I] [R1836|I]
>
> And then in inverse order:
>
> B710 [5123, 5124] preds: B709 sux: B3
> (lots of moves)
>
> B708 [5113, 5114] preds: B707 sux: B3
> (lots of moves)
> (continues for 4MBs)
>
> B1 [624, 625] preds: B0 sux: B3
> (lots of moves)
>
> Finally, we get to B3 which actually seems to show some real code:
>
> B3 [5157, 6129] preds: B1 B4 B6 B8 B10 B12 B14 B16 B18 B20 B22 B24 B26 B28
> B30 B32 B34 B36 B38 B40 B42 B44 B46 B48 B50 B52 B54 B56 B58 B60 B62 B64 B66
> B68 B70 B72 B74 B76 B78 B80 B82 B84 B86 B88 B90 B92 B94 B96 B98 B100 B102
> B104 B106 B108 B110 B112 B114 B116 B118 B120 B122 B124 B126 B128 B130 B132
> B134 B136 B138 B140 B142 B144 B146 B148 B150 B152 B154 B156 B158 B160 B162
> B164 B166 B168 B170 B172 B174 B176 B178 B180 B182 B184 B186 B188 B190 B192
> B194 B196 B198 B200 B202 B204 B206 B208 B210 B212 B214 B216 B218 B220 B222
> B224 B226 B228 B230 B232 B234 B236 B238 B240 B242 B244 B246 B248 B250 B252
> B254 B256 B258 B260 B262 B264 B266 B268 B270 B272 B274 B276 B278 B280 B282
> B284 B286 B288 B290 B292 B294 B296 B298 B300 B302 B304 B306 B308 B310 B312
> B314 B316 B318 B320 B322 B324 B326 B328 B330 B332 B334 B336 B338 B340 B342
> B344 B346 B348 B350 B352 B354 B356 B358 B360 B362 B364 B366 B368 B370 B372
> B374 B376 B378 B380 B382 B384 B386 B388 B390 B392 B394 B396 B398 B400 B402
> B404 B406 B408 B410 B412 B414 B416 B418 B420 B422 B424 B426 B428 B430 B432
> B434 B436 B438 B440 B442 B444 B446 B448 B450 B452 B454 B456 B458 B460 B462
> B464 B466 B468 B470 B472 B474 B476 B478 B480 B482 B484 B486 B488 B490 B492
> B494 B496 B498 B500 B502 B504 B506 B508 B510 B512 B514 B516 B518 B520 B522
> B524 B526 B528 B530 B532 B534 B536 B538 B540 B542 B544 B546 B548 B550 B552
> B554 B556 B558 B560 B562 B564 B566 B568 B570 B572 B574 B576 B578 B580 B582
> B584 B586 B588 B590 B592 B594 B596 B598 B600 B602 B604 B606 B608 B610 B612
> B614 B616 B618 B620 B622 B624 B626 B628 B630 B632 B634 B636 B638 B640 B642
> B644 B646 B648 B650 B652 B654 B656 B658 B660 B662 B664 B666 B668 B670 B672
> B674 B676 B678 B680 B682 B684 B686 B688 B690 B692 B694 B696 B698 B700 B702
> B704 B706 B708 B710 B712 B714 B715
> __id_Instruction___________________________________________
> 148938 label [label:0x00007fb854776bd0]
> 148940 profile_call isXMLLetter.org/jaxen/saxpath/base/Verifier @ 5158
> [R2196|M]  [R2197|J]
> 148942 move [metadata:0x000000011886d478|M] [R2198|M]
> 148944 move [Base:[R2198|M] Disp: 284|I] [R2199|I]
> 148946 add [R2199|I] [int:2|I] [R2199|I]
> 148948 move [R2199|I] [Base:[R2198|M] Disp: 284|I]
> 148950 logic_and [R2199|I] [int:2097150|I] [R2199|I]
> 148952 cmp [EQ] [R2199|I] [int:0|I]
> 148954 branch [EQ] [CounterOverflowStub: 0x00007fb85715f4d0]
> [etc..].
>
>
> The output then continues with a wall of text which makes a beautiful
> pattern if I get my terminal width exactly right, but otherwise makes no
> sense to me :-)
>
> Here's hoping that this analysis may be of some use.
>
> Cheers,
> Eirik.

From redestad at openjdk.java.net  Thu Feb 11 12:59:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Feb 2021 12:59:39 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v2]
In-Reply-To: <csbaOvyMeGK0-mJxDyJxhmdHa_HcocG7CQtw4XUtrfE=.35c9820d-964c-47e7-8cdb-db4e8f76d082@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
 <csbaOvyMeGK0-mJxDyJxhmdHa_HcocG7CQtw4XUtrfE=.35c9820d-964c-47e7-8cdb-db4e8f76d082@github.com>
Message-ID: <R5kRXNkycQgBML5b608AqyFJnKtn4ncKHvJBPSRTuqY=.5d9c9ab6-382c-4a87-b7a1-8df7bfb9c2bc@github.com>

On Thu, 11 Feb 2021 12:22:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi Claes,
> 
> Here is the JMH performance data over CLX for arraycopy benchmarks:
> http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_BASELINE.txt
> http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_WITH_OPTS.txt
> 
> Regards,
> Jatin

Thanks! Eyeballing the results it looks like a mixed bag. There even seems to be a few regressions such as this: 

o.o.b.java.lang.ArrayCopyUnalignedSrc.testLong                   1200     N/A   avgt    2     61.663           ns/op
--> 
o.o.b.java.lang.ArrayCopyUnalignedSrc.testLong                   1200     N/A   avgt    2     74.160           ns/op

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From chagedorn at openjdk.java.net  Thu Feb 11 13:03:38 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 11 Feb 2021 13:03:38 GMT
Subject: RFR: 8240281: Remove failing assertion code when selecting first
 memory state in SuperWord::co_locate_pack
In-Reply-To: <mwZpTP9L8mKlCy-W_n1GxzPh7Anoz1F8-GRBYt870lY=.c66c7d59-2571-4062-a07e-5137734ece29@github.com>
References: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
 <mwZpTP9L8mKlCy-W_n1GxzPh7Anoz1F8-GRBYt870lY=.c66c7d59-2571-4062-a07e-5137734ece29@github.com>
Message-ID: <dHrShoI6tMgmEmheFURyJ04uB_eYVA-k8hrLBXj314Y=.a0694a2c-2321-422e-b171-156bc8a436b5@github.com>

On Thu, 11 Feb 2021 07:44:30 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> While working on [JDK-8238438](https://bugs.openjdk.java.net/browse/JDK-8238438), it was not clear if there is a case where `SuperWord::co_locate_pack()` should pick the memory state of the first load of a pack. We could not find an example and therefore added an `assert(false)` and left the code there to clean it up at some point if the assert was never hit. 
>> 
>> Now, a newly found fuzzer test showed that are cases where we need to pick the first memory state, triggering the `assert(false)`. In the test case `test()`, a store and a load pack are created but the store pack is filtered in `SuperWord::filter_packs()`. The load `x += iArrFld[j]` must read the old value before the store `iArrFld[j] = j` overrides it. Therefore, the load vector must be executed before any of the stores to `iArrFld[j]`. This, however, is not the case if we pick the memory state of the last load which results in wrong values for `iArrFld`: The stores and the loads are dependent and some of the stores are already executed before the load vector. 
>> 
>> The fix is to remove the assertion code added by JDK-8238438 and keep the code for selecting the first memory state of a load pack.
>> 
>> Thanks,
>> Christian
>
> Looks good. Great that we finally have a test for this case!

Thanks Vladimir and Tobias for your reviews! Yes, it's good to finally have a testcase for it. Was already thinking about cleaning this code up soon - good that I've waited.

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

PR: https://git.openjdk.java.net/jdk/pull/2495

From chagedorn at openjdk.java.net  Thu Feb 11 13:03:41 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 11 Feb 2021 13:03:41 GMT
Subject: Integrated: 8240281: Remove failing assertion code when selecting
 first memory state in SuperWord::co_locate_pack
In-Reply-To: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
References: <caSQvYz-HW0WnFZZDE8VQ34EQsnj8q7ZsWHFt3V3beY=.463dd16d-49aa-4b5c-a38d-2c2c79fde0ed@github.com>
Message-ID: <wnjwjRNLgFw4vVjeKUNAY_tj8peSYAMKwu7dD3bFm1I=.3f46c45e-a537-4a93-b854-9edd1153b773@github.com>

On Wed, 10 Feb 2021 08:49:10 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> While working on [JDK-8238438](https://bugs.openjdk.java.net/browse/JDK-8238438), it was not clear if there is a case where `SuperWord::co_locate_pack()` should pick the memory state of the first load of a pack. We could not find an example and therefore added an `assert(false)` and left the code there to clean it up at some point if the assert was never hit. 
> 
> Now, a newly found fuzzer test showed that are cases where we need to pick the first memory state, triggering the `assert(false)`. In the test case `test()`, a store and a load pack are created but the store pack is filtered in `SuperWord::filter_packs()`. The load `x += iArrFld[j]` must read the old value before the store `iArrFld[j] = j` overrides it. Therefore, the load vector must be executed before any of the stores to `iArrFld[j]`. This, however, is not the case if we pick the memory state of the last load which results in wrong values for `iArrFld`: The stores and the loads are dependent and some of the stores are already executed before the load vector. 
> 
> The fix is to remove the assertion code added by JDK-8238438 and keep the code for selecting the first memory state of a load pack.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 0a89987a
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a89987a
Stats:     146 lines in 2 files changed: 134 ins; 5 del; 7 mod

8240281: Remove failing assertion code when selecting first memory state in SuperWord::co_locate_pack

Reviewed-by: roland, kvn, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2495

From Pengfei.Li at arm.com  Thu Feb 11 13:09:29 2021
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Thu, 11 Feb 2021 13:09:29 +0000
Subject: [11u] RFR(S): 8261022: Fix incorrect result of Math.abs() with char
 type
In-Reply-To: <PR3PR08MB58505A8740860AE313B7FAFA968E9@PR3PR08MB5850.eurprd08.prod.outlook.com>
References: <PR3PR08MB58505A8740860AE313B7FAFA968E9@PR3PR08MB5850.eurprd08.prod.outlook.com>
Message-ID: <PR3PR08MB5850DFB4DCEF1B2A1AEDBB56968C9@PR3PR08MB5850.eurprd08.prod.outlook.com>

Resend

> Hi,
> 
> I'd like to backport JDK-8261022 to jdk11u.
> 
> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8261022
> Modified webrev: http://cr.openjdk.java.net/~pli/rfr/8261022/backport11u/
> 
> This issue causes vectorized abs generate incorrect result when the argument
> has char type. Root cause is that the vector abs operation is not specially
> handled in computing vector element types after we enabled that in JDK-
> 8222074 in jdk13. As JDK-8222074 was backported to jdk11u, jdk11u is also
> affected.
> 
> The patch to fix this is in jdk17 now. The fix does not apply to jdk11u cleanly,
> as VectorNode::is_shift_opcode() is not defined in jdk11u. I have modified
> the patch a little bit to fit this difference.
> 
> Tested jtreg hotspot::tier1 and the newly added jtreg case. No failure after
> the modified patch.
> 
> --
> Thanks,
> Pengfei


From sjohanss at openjdk.java.net  Thu Feb 11 13:13:37 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 11 Feb 2021 13:13:37 GMT
Subject: RFR: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <7bUn1l-RNEYH7LE-4NzMdUU1EVOVE3brf7KQaQ9lzL4=.bc261d90-cbbb-4a79-9765-ab0a886e1e2d@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
 <7bUn1l-RNEYH7LE-4NzMdUU1EVOVE3brf7KQaQ9lzL4=.bc261d90-cbbb-4a79-9765-ab0a886e1e2d@github.com>
Message-ID: <IHlonzrFjs57wZYkcAoQtJt5hxsRikiTHJ2HavgTO4A=.fc4eb51e-883e-4893-8903-c95846886524@github.com>

On Wed, 10 Feb 2021 22:57:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> When adding a code heap the page size used with the underlying mapping is traced using `os::trace_page_sizes`. The old code tried to estimate the page-size based on the size, but the mapping has already been done so it is better to check the passed in `ReservedSpace`. Today we don't record the page size in the ReservedSpace, but we have a helper to do a good estimate: `ReservedSpace::actual_reserved_page_size()`. The proposal is to use this function.
>> 
>> When changing this I also realized that the traced min-size used un-aligned value while the actual `initialize`-call correctly uses the aligned size. Changed so that we also use the aligned size for tracing.
>> 
>> I'm currently doing some more work in this area and while I haven't added a specific test for this issue I have created a test I plan to integrate separately when a few more needed changes have gone in. The test is Linux-only and validates the output from `os::trace_page_sizes` against the information in `/proc/self/smaps`.
>
> Good.

Thanks for the reviews, @vnkozlov, @tstuefe and @TobiHartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2481

From sjohanss at openjdk.java.net  Thu Feb 11 13:13:38 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 11 Feb 2021 13:13:38 GMT
Subject: Integrated: 8261029: Code heap page sizes not traced correctly using
 os::trace_page_sizes
In-Reply-To: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
References: <D-_j35IcAMK9W60bnJMECHOQuBXWGN7pcG7pQNgSTns=.d89fc549-6f68-4eba-a23c-76616e3e02af@github.com>
Message-ID: <04a_J9upMfUVtRiu6-CB0_zeWUP7HtbzoEj-w8Nkkno=.d424b527-6798-4f1b-aa6a-c1221113256a@github.com>

On Tue, 9 Feb 2021 13:45:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> When adding a code heap the page size used with the underlying mapping is traced using `os::trace_page_sizes`. The old code tried to estimate the page-size based on the size, but the mapping has already been done so it is better to check the passed in `ReservedSpace`. Today we don't record the page size in the ReservedSpace, but we have a helper to do a good estimate: `ReservedSpace::actual_reserved_page_size()`. The proposal is to use this function.
> 
> When changing this I also realized that the traced min-size used un-aligned value while the actual `initialize`-call correctly uses the aligned size. Changed so that we also use the aligned size for tracing.
> 
> I'm currently doing some more work in this area and while I haven't added a specific test for this issue I have created a test I plan to integrate separately when a few more needed changes have gone in. The test is Linux-only and validates the output from `os::trace_page_sizes` against the information in `/proc/self/smaps`.

This pull request has now been integrated.

Changeset: eef86a80
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eef86a80
Stats:     9 lines in 1 file changed: 1 ins; 6 del; 2 mod

8261029: Code heap page sizes not traced correctly using os::trace_page_sizes

Reviewed-by: kvn, stuefe, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2481

From jbhateja at openjdk.java.net  Thu Feb 11 13:54:38 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 11 Feb 2021 13:54:38 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v2]
In-Reply-To: <R5kRXNkycQgBML5b608AqyFJnKtn4ncKHvJBPSRTuqY=.5d9c9ab6-382c-4a87-b7a1-8df7bfb9c2bc@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
 <csbaOvyMeGK0-mJxDyJxhmdHa_HcocG7CQtw4XUtrfE=.35c9820d-964c-47e7-8cdb-db4e8f76d082@github.com>
 <R5kRXNkycQgBML5b608AqyFJnKtn4ncKHvJBPSRTuqY=.5d9c9ab6-382c-4a87-b7a1-8df7bfb9c2bc@github.com>
Message-ID: <NMpSSPd-r--k7mTy64pp3v90_wVPT5-tBgRb09aerGI=.d7ed6c67-96b8-4ab1-9651-9f3fec43139d@github.com>

On Thu, 11 Feb 2021 12:56:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > Hi Claes,
> > Here is the JMH performance data over CLX for arraycopy benchmarks:
> > http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_BASELINE.txt
> > http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_WITH_OPTS.txt
> > Regards,
> > Jatin
> 
> Thanks! Eyeballing the results it looks like a mixed bag. There even seems to be a few regressions such as this:
> 
> ```
> o.o.b.java.lang.ArrayCopyUnalignedSrc.testLong                   1200     N/A   avgt    2     61.663           ns/op
> --> 
> o.o.b.java.lang.ArrayCopyUnalignedSrc.testLong                   1200     N/A   avgt    2     74.160           ns/op
> ```

Hi Claes, This could be a run to run variation, in general we are now having fewer number of instructions (one shift operation saved per mask computation) compared to previous masked generation sequence  and thus it will always offer better execution latencies.

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From sviswanathan at openjdk.java.net  Thu Feb 11 14:26:45 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 11 Feb 2021 14:26:45 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit byte/short
 vectors
Message-ID: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>

The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.

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

The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.

Before:
Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms

After:
Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms

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

Commit messages:
 - 8261542: X86 slice and unslice intrinsics for 256-bit byte/short vectors

Changes: https://git.openjdk.java.net/jdk/pull/2520/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2520&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261542
  Stats: 119 lines in 7 files changed: 99 ins; 5 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2520/head:pull/2520

PR: https://git.openjdk.java.net/jdk/pull/2520

From redestad at openjdk.java.net  Thu Feb 11 14:30:37 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Feb 2021 14:30:37 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v2]
In-Reply-To: <NMpSSPd-r--k7mTy64pp3v90_wVPT5-tBgRb09aerGI=.d7ed6c67-96b8-4ab1-9651-9f3fec43139d@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
 <csbaOvyMeGK0-mJxDyJxhmdHa_HcocG7CQtw4XUtrfE=.35c9820d-964c-47e7-8cdb-db4e8f76d082@github.com>
 <R5kRXNkycQgBML5b608AqyFJnKtn4ncKHvJBPSRTuqY=.5d9c9ab6-382c-4a87-b7a1-8df7bfb9c2bc@github.com>
 <NMpSSPd-r--k7mTy64pp3v90_wVPT5-tBgRb09aerGI=.d7ed6c67-96b8-4ab1-9651-9f3fec43139d@github.com>
Message-ID: <GumNspvDQjUjL6QiqPVddY5p6vn9aOpqPgq3uAw_rSo=.a5c33ff0-977b-4ec1-a245-c6a916fc0aa0@github.com>

On Thu, 11 Feb 2021 13:52:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi Claes, This could be a run to run variation, in general we are now having fewer number of instructions (one shift operation saved per mask computation) compared to previous masked generation sequence and thus it will always offer better execution latencies.

Run-to-run variation would be easy to rule out by running more forks and more iterations to attain statistically significant results. While the instruction manuals suggest latency should be better for this instruction on all CPUs where it's supported, it would be good if there was some clear proof - such as a significant benchmark win - to motivate the added complexity.

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From mdoerr at openjdk.java.net  Thu Feb 11 15:25:50 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 11 Feb 2021 15:25:50 GMT
Subject: RFR: 8261522: [PPC64] AES intrinsics write beyond the destination
 array
Message-ID: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>

I'd like to replace the read-modify-write implementation from aescrypt_encryptBlock / aescrypt_decryptBlock stubs. IT can cause severe problems (see bug description).

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

Commit messages:
 - 8261522: [PPC64] AES intrinsics write beyond the destination array

Changes: https://git.openjdk.java.net/jdk/pull/2514/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2514&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261522
  Stats: 48 lines in 1 file changed: 10 ins; 16 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2514.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2514/head:pull/2514

PR: https://git.openjdk.java.net/jdk/pull/2514

From roland at openjdk.java.net  Thu Feb 11 15:42:56 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 11 Feb 2021 15:42:56 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved register
 with native invoker
Message-ID: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>

We spotted this issue with Shenandoah and I managed to write a simple
test case that reproduces it reliably with Shenandoah but the issue is
independent of the GC.

The loop in the test case calls a native invoker with an oop live in
rbp. rbp is saved in the native invoker stub's frame. A safepoint is
triggered from the safepoint check in the native invoker. The stack
walking code sees that rbp contains an oop but can't find where that
oop is stored. That's because stack walking updates the caller's frame
with the location of rbp in the callee on calls to
frame::sender(). But the current code sets the last java frame to be
the compiled frame where rbp is live. So there's no call to
frame::sender() to update the location rbp. The fix I propose is that
the frame of the native invoker be visible by stack walking. On a
safepoint, stack walking starts from the native invoker thread, then
calls frame::sender() to move to the compiled frame. That causes rbp
to be properly recorded with its location in the native invoker frame.

Same problem affects both x86 and aarch64. I've tested this patch with:

make run-test TEST="java/foreign" TEST_VM_OPTS="-Xcomp" JTREG="TIMEOUT_FACTOR=10"

on both platforms.

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

Commit messages:
 - whitespaces
 - fix & test

Changes: https://git.openjdk.java.net/jdk/pull/2528/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2528&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259937
  Stats: 395 lines in 16 files changed: 264 ins; 53 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2528.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2528/head:pull/2528

PR: https://git.openjdk.java.net/jdk/pull/2528

From vladimir.kozlov at oracle.com  Thu Feb 11 18:05:30 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Feb 2021 10:05:30 -0800
Subject: [External] : Re: SuperWord loop optimization lost after method
 inlining
In-Reply-To: <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
References: <CAOqmmc0ue3bLMBgWLAvUOrHLe2iNtoSiBiq=+Beky-D=MkA+fw@mail.gmail.com>
 <b9184f85-c869-8088-a080-2d860dca5f9f@oracle.com>
 <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
Message-ID: <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>

Changing wide mailing list to JIT compiler only.

This deoptimization is normal in Tiered Compilation - it switched from profiling code (level='3') generated by C1 
compiler to new code generated by C2 (level='4') which does loop optimizations.

Thank you for posting inlining information:

     @ 17   com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69 bytes) inline (hot)
        \-> TypeProfile (14054/14054 counts) = com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding

I thought before that may be call site is not hot but it is not the case.

You can do an other experiment to collect log with disabled Tiered Compilation (only C2 is used): -XX:-TieredCompilation
Also print assembler code (as you did before) for final compilation to see if loop is still not vectorized.

Is it possible to post log file (on GitHub?) for me to look?

Thanks,
Vladimir K

On 2/11/21 6:28 AM, Nicolas Heutte wrote:
> Hi?Vladimir,
> 
> Thank you for your help.
> 
> I'm currently running Java 11.0.9, and I did not use any VM flag of note.
> 
> I checked the content of the compilation log, and it seems that ArrayFloatToArrayFloatVectorBinding::plus() was 
> deoptimized in order to allow AVector::plus() to be compiled:
> 
> <writer thread='11576'/>
> <task_queued compile_id='17280' method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V' bytes='23' 
> count='916' iicount='916' level='3' stamp='7394.056' comment='tiered' hot_count='896'/>
> <writer thread='15784'/>
> <deoptimized thread='15784' reason='constraint' pc='0x00000296d0785b94' compile_id='17257' compiler='c1' level='3'>
> <jvms bci='65' method='com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding plus 
> (Lcom/qfs/vector/IVector;Lcom/qfs/vector/IVector;)V' bytes='69' count='909' backedge_count='155602' iicount='910'/>
> </deoptimized>
> 
> The last compilation entry for AVector::plus() is:
> 
> <writer thread='16380'/>
> <nmethod compile_id='17317' compiler='c2' level='4' entry='0x00000296d6af32c0' size='1960' address='0x00000296d6af3110' 
> relocation_offset='376' insts_offset='432' stub_offset='1040' scopes_data_offset='1152' scopes_pcs_offset='1592' 
> dependencies_offset='1880' nul_chk_table_offset='1896' oops_offset='1064' metadata_offset='1072' 
> method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V' bytes='23' count='172425' iicount='172425' 
> stamp='7394.199'/>
> <make_not_entrant thread='16380' compile_id='17280' compiler='c1' level='2' stamp='7394.199'/>
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 1 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes) ? inline (hot)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14552/14552 counts) = com/qfs/vector/array/impl/ArrayFloatVector
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 7 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes) ? inline (hot)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14150/14150 counts) = com/qfs/vector/array/impl/ArrayFloatVector
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 10 ? com.qfs.vector.binding.impl.VectorBindings::getBinding (9 bytes) ? inline (hot)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 5 ? com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::getBinding (22 
> bytes) ? inline (hot)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 3 ? com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::hasBinding 
> (34 bytes) ? inline (hot)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 17 ? com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69 bytes)   
> inline (hot)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14054/14054 counts) = 
> com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 12 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes) ? inline (hot)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 22 ? com.qfs.vector.impl.AVector::checkIndex (37 bytes) ? inline (hot)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 6 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes) ? inline (hot)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 27 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes) ? accessor
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 34 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes) ? accessor
> <writer thread='15896'/>
> 
> Unfortunately, I do not have access to a debug VM build, so I cannot run the second test you recommend.
> 
> Best regards,
> Nicolas Heutte
> 
> On Wed, Feb 10, 2021 at 7:36 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>     Hi, Nicolas
> 
>     Looks like, when inlined, the loop from ArrayFloatToArrayFloatVectorBinding::plus() was not optimized at all: it is not
>     unrolled and has range checks. Such loops are not vectorized (you need unrolling and no checks).
> 
>     What Java version you are running? What HotSpot VM flags you are using when running application?
> 
>     Run application with -XX:+LogCompilation and look on compilation data in hotspot_pid<PID>.log file for caller
>     AVector::plus().
> 
>     VM also has several flags to trace loop optimizations but they are only available in debug VM build. If you have access
>     to such build run with -XX:+PrintCompilation -XX:+TraceLoopOpts flags.
> 
>     Thanks,
>     Vladimir K
> 
>     On 2/10/21 9:24 AM, Nicolas Heutte wrote:
>      > Hi all,
>      >
>      > I am encountering a performance issue caused by the interaction between
>      > method inlining and automatic vectorization.
>      >
>      > Our application aggregates arrays intensively using a method named
>      > ArrayFloatToArrayFloatVectorBinding.plus() with the following code:
>      >
>      >? ? ? for (int i = 0; i < srcLen; ++i) {
>      >
>      >? ? ? ? ? ? ? dstArray[i] += srcArray[i];
>      >
>      >? ? ? }
>      >
>      > When we microbenchmark this method we observe fast performance close to the
>      > practical memory bandwidth and when we print the assembly code we observe
>      > loop unrolling and automatic vectorization with SIMD instructions.
>      >
>      >? ? 0x000001ef4600abf0: vmovdqu 0x10(%r14,%r13,4),%ymm0
>      >
>      >? ? 0x000001ef4600abf7: vaddps 0x10(%rcx,%r13,4),%ymm0,%ymm0
>      >
>      >? ? 0x000001ef4600abfe: vmovdqu %ymm0,0x10(%r14,%r13,4)
>      >
>      >? ? 0x000001ef4600ac05: movslq %r13d,%r11
>      >
>      >? ? 0x000001ef4600ac08: vmovdqu 0x30(%r14,%r11,4),%ymm0
>      >
>      >? ? 0x000001ef4600ac0f: vaddps 0x30(%rcx,%r11,4),%ymm0,%ymm0
>      >
>      >? ? 0x000001ef4600ac16: vmovdqu %ymm0,0x30(%r14,%r11,4)
>      >
>      >? ? 0x000001ef4600ac1d: vmovdqu 0x50(%r14,%r11,4),%ymm0
>      >
>      >? ? 0x000001ef4600ac24: vaddps 0x50(%rcx,%r11,4),%ymm0,%ymm0
>      >
>      >? ? 0x000001ef4600ac2b: vmovdqu %ymm0,0x50(%r14,%r11,4)
>      >
>      >? ? 0x000001ef4600ac32: vmovdqu 0x70(%r14,%r11,4),%ymm0
>      >
>      >? ? 0x000001ef4600ac39: vaddps 0x70(%rcx,%r11,4),%ymm0,%ymm0
>      >
>      >? ? 0x000001ef4600ac40: vmovdqu %ymm0,0x70(%r14,%r11,4)
>      >
>      >? ? 0x000001ef4600ac47: vmovdqu 0x90(%r14,%r11,4),%ymm0
>      >
>      >? ? 0x000001ef4600ac51: vaddps 0x90(%rcx,%r11,4),%ymm0,%ymm0
>      >
>      >? ? 0x000001ef4600ac5b: vmovdqu %ymm0,0x90(%r14,%r11,4)
>      >
>      >? ? 0x000001ef4600ac65: vmovdqu 0xb0(%r14,%r11,4),%ymm0
>      >
>      >? ? 0x000001ef4600ac6f: vaddps 0xb0(%rcx,%r11,4),%ymm0,%ymm0
>      >
>      >? ? 0x000001ef4600ac79: vmovdqu %ymm0,0xb0(%r14,%r11,4)
>      >
>      >? ? 0x000001ef4600ac83: vmovdqu 0xd0(%r14,%r11,4),%ymm0
>      >
>      >? ? 0x000001ef4600ac8d: vaddps 0xd0(%rcx,%r11,4),%ymm0,%ymm0
>      >
>      >? ? 0x000001ef4600ac97: vmovdqu %ymm0,0xd0(%r14,%r11,4)
>      >
>      >? ? 0x000001ef4600aca1: vmovdqu 0xf0(%r14,%r11,4),%ymm0
>      >
>      >? ? 0x000001ef4600acab: vaddps 0xf0(%rcx,%r11,4),%ymm0,%ymm0
>      >
>      >? ? 0x000001ef4600acb5: vmovdqu %ymm0,0xf0(%r14,%r11,4)? ;*fastore
>      > {reexecute=0 rethrow=0 return_oop=0}
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>      > (line 41)
>      >
>      >? ? 0x000001ef4600acbf: add? ? $0x40,%r13d? ? ? ? ;*iinc {reexecute=0
>      > rethrow=0 return_oop=0}
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>      > (line 40)
>      >
>      >? ? 0x000001ef4600acc3: cmp? ? %eax,%r13d
>      >
>      >? ? 0x000001ef4600acc6: jl? ? ?0x000001ef4600abf0? ;*goto {reexecute=0
>      > rethrow=0 return_oop=0}
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>      > (line 40)
>      >
>      >
>      >
>      > In the real application, this method is actually inlined in a higher level
>      > method named AVector.plus(). Unfortunately, the inlined version of the
>      > aggregation code is not vectorized anymore:
>      >
>      >
>      >
>      >? ? 0x000001ef460180a0: cmp? ? %ebx,%r11d
>      >
>      >? ? 0x000001ef460180a3: jae? ? 0x000001ef460180e6
>      >
>      >? ? 0x000001ef460180a5: vmovss 0x10(%r8,%r11,4),%xmm1? ;*faload {reexecute=0
>      > rethrow=0 return_oop=0}
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
>      > (line 41)
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >
>      >? ? 0x000001ef460180ac: cmp? ? %ecx,%r11d
>      >
>      >? ? 0x000001ef460180af: jae? ? 0x000001ef46018104
>      >
>      >? ? 0x000001ef460180b1: vaddss 0x10(%r9,%r11,4),%xmm1,%xmm1
>      >
>      >? ? 0x000001ef460180b8: vmovss %xmm1,0x10(%r8,%r11,4)? ;*fastore {reexecute=0
>      > rethrow=0 return_oop=0}
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>      > (line 41)
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >
>      >? ? 0x000001ef460180bf: inc? ? %r11d? ? ? ? ? ? ? ;*iinc {reexecute=0
>      > rethrow=0 return_oop=0}
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>      > (line 40)
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >
>      >? ? 0x000001ef460180c2: cmp? ? %r10d,%r11d
>      >
>      >? ? 0x000001ef460180c5: jl? ? ?0x000001ef460180a0? ;*goto {reexecute=0
>      > rethrow=0 return_oop=0}
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>      > (line 40)
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >
>      >
>      >
>      > This causes a significant performance drop, compared to a run where we
>      > explicitly disable the inlining and observe automatically vectorized code
>      > again (
>      > -XX:CompileCommand=dontinline,com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding.plus
>      > ).
>      >
>      >
>      > How do you guys explain that behavior of the JIT compiler? Is this a known
>      > and tracked issue, could it be fixed in the JVM? Can we do something in the
>      > java code to prevent this from happening?
>      >
>      >
>      > Best regards,
>      >
>      > Nicolas Heutte
>      >
> 

From vladimir.kozlov at oracle.com  Thu Feb 11 18:18:11 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Feb 2021 10:18:11 -0800
Subject: [11u] RFR(S): 8261022: Fix incorrect result of Math.abs() with
 char type
In-Reply-To: <PR3PR08MB5850DFB4DCEF1B2A1AEDBB56968C9@PR3PR08MB5850.eurprd08.prod.outlook.com>
References: <PR3PR08MB58505A8740860AE313B7FAFA968E9@PR3PR08MB5850.eurprd08.prod.outlook.com>
 <PR3PR08MB5850DFB4DCEF1B2A1AEDBB56968C9@PR3PR08MB5850.eurprd08.prod.outlook.com>
Message-ID: <6e591fa9-27ba-4b69-8576-2540b5824471@oracle.com>

Backport patch looks good.

Thanks,
Vladimir K

On 2/11/21 5:09 AM, Pengfei Li wrote:
> Resend
> 
>> Hi,
>>
>> I'd like to backport JDK-8261022 to jdk11u.
>>
>> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8261022
>> Modified webrev: http://cr.openjdk.java.net/~pli/rfr/8261022/backport11u/
>>
>> This issue causes vectorized abs generate incorrect result when the argument
>> has char type. Root cause is that the vector abs operation is not specially
>> handled in computing vector element types after we enabled that in JDK-
>> 8222074 in jdk13. As JDK-8222074 was backported to jdk11u, jdk11u is also
>> affected.
>>
>> The patch to fix this is in jdk17 now. The fix does not apply to jdk11u cleanly,
>> as VectorNode::is_shift_opcode() is not defined in jdk11u. I have modified
>> the patch a little bit to fit this difference.
>>
>> Tested jtreg hotspot::tier1 and the newly added jtreg case. No failure after
>> the modified patch.
>>
>> --
>> Thanks,
>> Pengfei
> 

From kvn at openjdk.java.net  Thu Feb 11 18:52:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 11 Feb 2021 18:52:39 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker
In-Reply-To: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
Message-ID: <YSiKdYz8EzmJx77zajQ_sLCdIhA0xfHtuZTXbaOrBc8=.974f7741-7037-43e6-aee6-1075b1e2da70@github.com>

On Thu, 11 Feb 2021 15:31:11 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> We spotted this issue with Shenandoah and I managed to write a simple
> test case that reproduces it reliably with Shenandoah but the issue is
> independent of the GC.
> 
> The loop in the test case calls a native invoker with an oop live in
> rbp. rbp is saved in the native invoker stub's frame. A safepoint is
> triggered from the safepoint check in the native invoker. The stack
> walking code sees that rbp contains an oop but can't find where that
> oop is stored. That's because stack walking updates the caller's frame
> with the location of rbp in the callee on calls to
> frame::sender(). But the current code sets the last java frame to be
> the compiled frame where rbp is live. So there's no call to
> frame::sender() to update the location rbp. The fix I propose is that
> the frame of the native invoker be visible by stack walking. On a
> safepoint, stack walking starts from the native invoker thread, then
> calls frame::sender() to move to the compiled frame. That causes rbp
> to be properly recorded with its location in the native invoker frame.
> 
> Same problem affects both x86 and aarch64. I've tested this patch with:
> 
> make run-test TEST="java/foreign" TEST_VM_OPTS="-Xcomp" JTREG="TIMEOUT_FACTOR=10"
> 
> on both platforms.

Seems reasonable.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2528

From iveresov at openjdk.java.net  Fri Feb 12 02:59:39 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 12 Feb 2021 02:59:39 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v4]
In-Reply-To: <hgo2_ZSrSDvbOg1xq9wAk34EW4G6PStzYZo-Meg5Zrc=.d600cbf3-0b3e-48bc-8b28-f41ce73e8537@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YHhV9N7mnJDt9mDDw4M9IOVQXSeFJLu4Qool9IneJmw=.3f214ae6-a077-47a5-bc5a-7a6f7d944d6c@github.com>
 <PJDUKJhVANb0loI2wutc-mE3Dm4Q_RaPIE1d6arkZEo=.3931249f-fa3e-449b-9afd-318af1fa4837@github.com>
 <hgo2_ZSrSDvbOg1xq9wAk34EW4G6PStzYZo-Meg5Zrc=.d600cbf3-0b3e-48bc-8b28-f41ce73e8537@github.com>
Message-ID: <I1A3w-wwSnn6_IjGqrVNOQUFz-K3udHT715xELrO_j4=.4565c3eb-2b0e-4c6b-a43b-c4f5a2916675@github.com>

On Wed, 10 Feb 2021 23:18:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > The improvement you are proposing is not specific to uncommon traps, but can be generalized to any debug usage at safepoints.
> > The downside is that, in general, rematerialization logic has to use the corresponding pure function in order to materialize the eliminated instance. In this particular case (primitive boxing), it has to take into account the caching effects of primitive box factories. Otherwise, user code can encounter identity paradoxes with rematerialized primitive box instances.
> > I don't see how the scalarization logic you propose preserves identity constraints imposed by `valueOf` factories.
> 
> Yes, it seems this optimization introduces the issue we had with Graal (8223320):
> "C2 doesn't model Integer.valueOf() as anything special. It just inlines it. So the check that determines whether to allocate a new Integer or take one from the cache always happens at runtime. Graal models it as a BoxNode. It is correctly lowered, however, if it needs to be present in a JVM state, it is described as an allocation. So the decision whether to allocate or take the cached value has to happen during the deopt."
> There is code in deoptimizer for JVMCI which looks for cached Boxed values. We may need to adopt it for C2 EA for this optimization to work.

In addition to using the logic that we already have there for Graal (see ```Deoptimization::get_cached_box()```), you need to track where the box came from. If it comes as a result of ```valueOf()``` then it has to come from the caches, if it's something that the user allocates with ```new Integer(x)```, then it should be just a normal scalarized object.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From iveresov at openjdk.java.net  Fri Feb 12 04:50:40 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 12 Feb 2021 04:50:40 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v4]
In-Reply-To: <I1A3w-wwSnn6_IjGqrVNOQUFz-K3udHT715xELrO_j4=.4565c3eb-2b0e-4c6b-a43b-c4f5a2916675@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YHhV9N7mnJDt9mDDw4M9IOVQXSeFJLu4Qool9IneJmw=.3f214ae6-a077-47a5-bc5a-7a6f7d944d6c@github.com>
 <PJDUKJhVANb0loI2wutc-mE3Dm4Q_RaPIE1d6arkZEo=.3931249f-fa3e-449b-9afd-318af1fa4837@github.com>
 <hgo2_ZSrSDvbOg1xq9wAk34EW4G6PStzYZo-Meg5Zrc=.d600cbf3-0b3e-48bc-8b28-f41ce73e8537@github.com>
 <I1A3w-wwSnn6_IjGqrVNOQUFz-K3udHT715xELrO_j4=.4565c3eb-2b0e-4c6b-a43b-c4f5a2916675@github.com>
Message-ID: <t8B9IknKst3v-ZeGDkJ9bBVQVlfXNmmRsrqPZ1fMWuU=.ab9a4b1f-9502-4f58-866c-818f81bd08f0@github.com>

On Fri, 12 Feb 2021 02:54:31 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>>> The improvement you are proposing is not specific to uncommon traps, but can be generalized to any debug usage at safepoints.
>>> 
>>> The downside is that, in general, rematerialization logic has to use the corresponding pure function in order to materialize the eliminated instance. In this particular case (primitive boxing), it has to take into account the caching effects of primitive box factories. Otherwise, user code can encounter identity paradoxes with rematerialized primitive box instances.
>>> 
>>> I don't see how the scalarization logic you propose preserves identity constraints imposed by `valueOf` factories.
>> 
>> Yes, it seems this optimization introduces the issue we had with Graal (8223320):
>> "C2 doesn't model Integer.valueOf() as anything special. It just inlines it. So the check that determines whether to allocate a new Integer or take one from the cache always happens at runtime. Graal models it as a BoxNode. It is correctly lowered, however, if it needs to be present in a JVM state, it is described as an allocation. So the decision whether to allocate or take the cached value has to happen during the deopt."
>> There is code in deoptimizer for JVMCI which looks for cached Boxed values. We may need to adopt it for C2 EA for this optimization to work.
>
>> > The improvement you are proposing is not specific to uncommon traps, but can be generalized to any debug usage at safepoints.
>> > The downside is that, in general, rematerialization logic has to use the corresponding pure function in order to materialize the eliminated instance. In this particular case (primitive boxing), it has to take into account the caching effects of primitive box factories. Otherwise, user code can encounter identity paradoxes with rematerialized primitive box instances.
>> > I don't see how the scalarization logic you propose preserves identity constraints imposed by `valueOf` factories.
>> 
>> Yes, it seems this optimization introduces the issue we had with Graal (8223320):
>> "C2 doesn't model Integer.valueOf() as anything special. It just inlines it. So the check that determines whether to allocate a new Integer or take one from the cache always happens at runtime. Graal models it as a BoxNode. It is correctly lowered, however, if it needs to be present in a JVM state, it is described as an allocation. So the decision whether to allocate or take the cached value has to happen during the deopt."
>> There is code in deoptimizer for JVMCI which looks for cached Boxed values. We may need to adopt it for C2 EA for this optimization to work.
> 
> In addition to using the logic that we already have there for Graal (see ```Deoptimization::get_cached_box()```), you need to track where the box came from. If it comes as a result of ```valueOf()``` then it has to come from the caches, if it's something that the user allocates with ```new Integer(x)```, then it should be just a normal scalarized object.

Also, I don't know if EA can handle a case when an Integer that is coming from an allocation and from a valueOf() are both inputs to a phi.
Integer i = p ? new Integer(i1) : Integer.valueOf(i2);
deopt();
int use = i.intValue();
If it does, then we'd need to force materialization.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From kvn at openjdk.java.net  Fri Feb 12 05:36:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 12 Feb 2021 05:36:39 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v4]
In-Reply-To: <t8B9IknKst3v-ZeGDkJ9bBVQVlfXNmmRsrqPZ1fMWuU=.ab9a4b1f-9502-4f58-866c-818f81bd08f0@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YHhV9N7mnJDt9mDDw4M9IOVQXSeFJLu4Qool9IneJmw=.3f214ae6-a077-47a5-bc5a-7a6f7d944d6c@github.com>
 <PJDUKJhVANb0loI2wutc-mE3Dm4Q_RaPIE1d6arkZEo=.3931249f-fa3e-449b-9afd-318af1fa4837@github.com>
 <hgo2_ZSrSDvbOg1xq9wAk34EW4G6PStzYZo-Meg5Zrc=.d600cbf3-0b3e-48bc-8b28-f41ce73e8537@github.com>
 <I1A3w-wwSnn6_IjGqrVNOQUFz-K3udHT715xELrO_j4=.4565c3eb-2b0e-4c6b-a43b-c4f5a2916675@github.com>
 <t8B9IknKst3v-ZeGDkJ9bBVQVlfXNmmRsrqPZ1fMWuU=.ab9a4b1f-9502-4f58-866c-818f81bd08f0@github.com>
Message-ID: <YnCw5EvS9tK5ls4XzjfNIWqmoCN-YnMGPeejdFFZ9cc=.7656e15b-2b2a-4bc0-85c9-73694dd3e127@github.com>

On Fri, 12 Feb 2021 04:48:06 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Also, I don't know if EA can handle a case when an Integer that is coming from an allocation and from a valueOf() are both inputs to a phi.
> 
> ```
> Integer i = p ? new Integer(i1) : Integer.valueOf(i2);
> deopt();
> int use = i.intValue();
> ```
> 
> If it does, then we'd need to force materialization.

Currently C2 EA can't scalarize merged allocations. So this is not an issue for now but may be in a future. Also C2 does not replace valueOf() with scalar node - it inlines it. As result you have branches with allocation and load from cache.

Only this patch propose to use scalar node for valueOf() for the first time in C2. But it is replaced only in case it is directly referenced  by debug info (no Phi or other nodes in between). So I think it is safe if we use AutoBoxObjectValue for it.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From jbhateja at openjdk.java.net  Fri Feb 12 06:01:37 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 12 Feb 2021 06:01:37 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v2]
In-Reply-To: <GumNspvDQjUjL6QiqPVddY5p6vn9aOpqPgq3uAw_rSo=.a5c33ff0-977b-4ec1-a245-c6a916fc0aa0@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
 <csbaOvyMeGK0-mJxDyJxhmdHa_HcocG7CQtw4XUtrfE=.35c9820d-964c-47e7-8cdb-db4e8f76d082@github.com>
 <R5kRXNkycQgBML5b608AqyFJnKtn4ncKHvJBPSRTuqY=.5d9c9ab6-382c-4a87-b7a1-8df7bfb9c2bc@github.com>
 <NMpSSPd-r--k7mTy64pp3v90_wVPT5-tBgRb09aerGI=.d7ed6c67-96b8-4ab1-9651-9f3fec43139d@github.com>
 <GumNspvDQjUjL6QiqPVddY5p6vn9aOpqPgq3uAw_rSo=.a5c33ff0-977b-4ec1-a245-c6a916fc0aa0@github.com>
Message-ID: <lT4eXJDfZffgaSA1rd2h7HwywpQl0PkaqM-vrMoUWcs=.589a2a04-f5ab-42e3-878c-cc6612fc20d3@github.com>

On Thu, 11 Feb 2021 14:28:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > Hi Claes, This could be a run to run variation, in general we are now having fewer number of instructions (one shift operation saved per mask computation) compared to previous masked generation sequence and thus it will always offer better execution latencies.
> 
> Run-to-run variation would be easy to rule out by running more forks and more iterations to attain statistically significant results. While the instruction manuals suggest latency should be better for this instruction on all CPUs where it's supported, it would be good if there was some clear proof - such as a significant benchmark win - to motivate the added complexity.

BASELINE:
Result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong":
  61.037 ns/op

Secondary result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong:??perf":
Perf stats:
--------------------------------------------------

         19,739.21 msec task-clock                #    0.389 CPUs utilized          
               646      context-switches          #    0.033 K/sec                  
                12      cpu-migrations            #    0.001 K/sec                  
               150      page-faults               #    0.008 K/sec                  
   74,59,83,59,139      cycles                    #    3.779 GHz                      (30.73%)
 1,78,78,79,19,117      instructions              #    2.40  insn per cycle           (38.48%)
   24,79,81,63,651      branches                  # 1256.289 M/sec                    (38.55%)
      32,24,89,924      branch-misses             #    1.30% of all branches          (38.62%)
   52,56,88,28,472      L1-dcache-loads           # 2663.167 M/sec                    (38.65%)
         39,00,969      L1-dcache-load-misses     #    0.01% of all L1-dcache hits    (38.57%)
          3,74,131      LLC-loads                 #    0.019 M/sec                    (30.77%)
            22,315      LLC-load-misses           #    5.96% of all LL-cache hits     (30.72%)
   <not supported>      L1-icache-loads                                             
         17,49,997      L1-icache-load-misses                                         (30.72%)
   52,91,41,70,636      dTLB-loads                # 2680.663 M/sec                    (30.69%)
             3,315      dTLB-load-misses          #    0.00% of all dTLB cache hits   (30.67%)
             4,674      iTLB-loads                #    0.237 K/sec                    (30.65%)
            33,746      iTLB-load-misses          #  721.99% of all iTLB cache hits   (30.63%)
   <not supported>      L1-dcache-prefetches                                        
   <not supported>      L1-dcache-prefetch-misses                                   

      50.723759146 seconds time elapsed

      51.447054000 seconds user
       0.189949000 seconds sys


WITH OPT:
Result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong":
  74.356 ns/op

Secondary result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong:??perf":
Perf stats:
--------------------------------------------------

         19,741.09 msec task-clock                #    0.389 CPUs utilized          
               641      context-switches          #    0.032 K/sec                  
                17      cpu-migrations            #    0.001 K/sec                  
               164      page-faults               #    0.008 K/sec                  
   74,40,40,48,513      cycles                    #    3.769 GHz                      (30.81%)
 1,45,66,22,06,797      instructions              #    1.96  insn per cycle           (38.56%)
   20,31,28,43,577      branches                  # 1028.963 M/sec                    (38.65%)
         14,11,419      branch-misses             #    0.01% of all branches          (38.69%)
   43,07,86,33,662      L1-dcache-loads           # 2182.182 M/sec                    (38.72%)
         37,06,744      L1-dcache-load-misses     #    0.01% of all L1-dcache hits    (38.56%)
          1,34,292      LLC-loads                 #    0.007 M/sec                    (30.72%)
            30,627      LLC-load-misses           #   22.81% of all LL-cache hits     (30.68%)
   <not supported>      L1-icache-loads                                             
         14,49,145      L1-icache-load-misses                                         (30.65%)
   43,44,86,27,516      dTLB-loads                # 2200.924 M/sec                    (30.63%)
               218      dTLB-load-misses          #    0.00% of all dTLB cache hits   (30.63%)
             2,445      iTLB-loads                #    0.124 K/sec                    (30.63%)
            28,624      iTLB-load-misses          # 1170.72% of all iTLB cache hits   (30.63%)
   <not supported>      L1-dcache-prefetches                                        
   <not supported>      L1-dcache-prefetch-misses                                   

      50.716083931 seconds time elapsed

      51.467300000 seconds user
       0.200390000 seconds sys


JMH perf data for ArrayCopyUnalignedSrc.testLong with copy length  of 1200 shows degradation in LID accesses, it seems the benchmask got displaced from its sweet spot.

But, there is a significant reduction in instruction count  and cycles are almost comparable.  We are saving one shift per mask computation.

          OLD Sequence:
              0x00007f7fc1030ead:   movabs $0x1,%rax
              0x00007f7fc1030eb7:   shlx   %r8,%rax,%rax
              0x00007f7fc1030ebc:   dec    %rax
              0x00007f7fc1030ebf:   kmovq  %rax,%k2
          NEW Sequence:
              0x00007f775d030d51:   movabs $0xffffffffffffffff,%rax
              0x00007f775d030d5b:   bzhi   %r8,%rax,%rax
              0x00007f775d030d60:   kmovq  %rax,%k2

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From rcastanedalo at openjdk.java.net  Fri Feb 12 09:36:02 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 12 Feb 2021 09:36:02 GMT
Subject: RFR: 8261336: IGV: enhance default filters
Message-ID: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>

Redesign the filters shown by default in the "Filters" window:

- Add filters to color the graph by node category and execution frequency (if applicable), and to hide subgraphs or edges only by _category_. The category of a node can be one of {`data`, `memory`, `control`, `mixed`, `other`}, and is solely determined by its type. `mixed` nodes are those with a tuple type that has different categories, such as `CallStaticJavaNode`. The category of an edge is that of its source node.

- Instrument C2 to include the category and estimated execution frequency (if available) of each node in the graph dumps produced by `-XX:PrintIdealGraphLevel=N` (only in debug builds).

- Remove filters which depend on properties never emitted by C2 (e.g. 'Remove State') or which appear to be unused ('C2 Matcher Flags Coloring' and 'C2 Register Coloring'). Also remove the subsumed 'C2 Basic Coloring' filter. 

- Merge 'C2 Remove Filter' and 'C2 Structural' into a single filter with a clearer name ('Simplify graph').

### Screenshots

"Filters" window before (left) and after (right) the proposed change:
![filters-window](https://user-images.githubusercontent.com/8792647/107749859-7a664780-6d1b-11eb-84ba-fd43e13abd0e.png)
Default color scheme before (left) and after (right) the proposed change:
![color-scheme](https://user-images.githubusercontent.com/8792647/107517355-f3479100-6bad-11eb-9b0b-a71c18961dd8.png)
Examples of the new 'Color by execution frequency' filter:
![color-by-frequency-2](https://user-images.githubusercontent.com/8792647/107518492-5980e380-6baf-11eb-9e01-992b211d06e3.png)
![color-by-frequency-1](https://user-images.githubusercontent.com/8792647/107518477-54bc2f80-6baf-11eb-8c7b-7eb7c1d85cf7.png)
Example of the new 'Hide X subgraph'' filters, where only the data subgraph is shown:
![hide-all-but-data-subgraphs](https://user-images.githubusercontent.com/8792647/107750398-42133900-6d1c-11eb-8b27-264086b32bea.png)
Example of the new 'Hide X edges' filters, where all nodes remain in their position but only the memory edges are shown:
![hide-all-but-memory-edges](https://user-images.githubusercontent.com/8792647/107751137-49871200-6d1d-11eb-9df0-79747bf8d16e.png)


Tested IGV manually on a few graphs. Tested C2 instrumentation by running `hs-tier1` with `-Xbatch -XX:PrintIdealGraphLevel=3 -XX:PrintIdealGraphFile=graph.xml` on windows-x64, linux-x64, linux-aarch64, and macosx-x64 (all debug).

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

Commit messages:
 - Use 'subgraph' instead of 'nodes' in filter names, for clarity
 - Add filters to hide edges by category
 - Update year in headers
 - Adjust frequency precision
 - Improve color scale in 'Color by execution frequency' filter
 - Add filter to color nodes by estimated execution frequency
 - Lift simplification filter
 - Merge simplification filters into a single, more intuitive one
 - Add filters to hide nodes by category
 - Reorder filters to preserve the behavior of 'Show control flow only'
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/db0ca2b9...3ed1e3de

Changes: https://git.openjdk.java.net/jdk/pull/2499/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2499&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261336
  Stats: 359 lines in 25 files changed: 284 ins; 40 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2499.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2499/head:pull/2499

PR: https://git.openjdk.java.net/jdk/pull/2499

From roland at openjdk.java.net  Fri Feb 12 09:37:02 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 12 Feb 2021 09:37:02 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v2]
In-Reply-To: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
Message-ID: <W2n7gPVdLqZO4VRuhl8Eysyv-5GYBy04joFl3pFGt6U=.cb50513b-e5b4-47e5-b2da-d182f05f3238@github.com>

> We spotted this issue with Shenandoah and I managed to write a simple
> test case that reproduces it reliably with Shenandoah but the issue is
> independent of the GC.
> 
> The loop in the test case calls a native invoker with an oop live in
> rbp. rbp is saved in the native invoker stub's frame. A safepoint is
> triggered from the safepoint check in the native invoker. The stack
> walking code sees that rbp contains an oop but can't find where that
> oop is stored. That's because stack walking updates the caller's frame
> with the location of rbp in the callee on calls to
> frame::sender(). But the current code sets the last java frame to be
> the compiled frame where rbp is live. So there's no call to
> frame::sender() to update the location rbp. The fix I propose is that
> the frame of the native invoker be visible by stack walking. On a
> safepoint, stack walking starts from the native invoker thread, then
> calls frame::sender() to move to the compiled frame. That causes rbp
> to be properly recorded with its location in the native invoker frame.
> 
> Same problem affects both x86 and aarch64. I've tested this patch with:
> 
> make run-test TEST="java/foreign" TEST_VM_OPTS="-Xcomp" JTREG="TIMEOUT_FACTOR=10"
> 
> on both platforms.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  broken build

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2528/files
  - new: https://git.openjdk.java.net/jdk/pull/2528/files/88eb13d0..5b9dfff7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2528&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2528&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2528.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2528/head:pull/2528

PR: https://git.openjdk.java.net/jdk/pull/2528

From chagedorn at openjdk.java.net  Fri Feb 12 10:08:56 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 12 Feb 2021 10:08:56 GMT
Subject: RFR: 8261235: C1 compilation fails with assert(res->vreg_number() ==
 index) failed: conversion check
Message-ID: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>

The assertion is hit because we run out of virtual registers in the linear scan in C1 and do not handle it. I fixed it by applying the same bailout as in `LIRGenerator::new_register()`. 

There is also a second issue that `LIR_OprDesc::vreg_max` is too big. It is only used in this bailout code. `OprBits::vreg_max` is defined over `OprBits::data_bits` which uses `OprBits::non_data_bits`. But `OprBits::non_data_bits` does not consider `OprBits::pointer_bits` which results in a too large value for `LIR_OprDesc::vreg_max` and the assertion is hit because we don't bail out, yet. This needs to be fixed as well.

Thanks,
Christian

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

Commit messages:
 - 8261235: C1 compilation fails with assert(res->vreg_number() == index) failed: conversion check

Changes: https://git.openjdk.java.net/jdk/pull/2543/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2543&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261235
  Stats: 4151 lines in 6 files changed: 4137 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2543.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2543/head:pull/2543

PR: https://git.openjdk.java.net/jdk/pull/2543

From vlivanov at openjdk.java.net  Fri Feb 12 10:39:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 12 Feb 2021 10:39:40 GMT
Subject: RFR: 8261336: IGV: enhance default filters
In-Reply-To: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
Message-ID: <fVXeDSDJI-7jMGhiPOTNBGWqCG3bRGWtQaDRv2Lnsdo=.c0cfa2a5-9dba-4153-8c40-886569b2d916@github.com>

On Wed, 10 Feb 2021 10:00:00 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Redesign the filters shown by default in the "Filters" window:
> 
> - Add filters to color the graph by node category and execution frequency (if applicable), and to hide subgraphs or edges only by _category_. The category of a node can be one of {`data`, `memory`, `control`, `mixed`, `other`}, and is solely determined by its type. `mixed` nodes are those with a tuple type that has different categories, such as `CallStaticJavaNode`. The category of an edge is that of its source node.
> 
> - Instrument C2 to include the category and estimated execution frequency (if available) of each node in the graph dumps produced by `-XX:PrintIdealGraphLevel=N` (only in debug builds).
> 
> - Remove filters which depend on properties never emitted by C2 (e.g. 'Remove State') or which appear to be unused ('C2 Matcher Flags Coloring' and 'C2 Register Coloring'). Also remove the subsumed 'C2 Basic Coloring' filter. 
> 
> - Merge 'C2 Remove Filter' and 'C2 Structural' into a single filter with a clearer name ('Simplify graph').
> 
> ### Screenshots
> 
> "Filters" window before (left) and after (right) the proposed change:
> ![filters-window](https://user-images.githubusercontent.com/8792647/107749859-7a664780-6d1b-11eb-84ba-fd43e13abd0e.png)
> Default color scheme before (left) and after (right) the proposed change:
> ![color-scheme](https://user-images.githubusercontent.com/8792647/107517355-f3479100-6bad-11eb-9b0b-a71c18961dd8.png)
> Examples of the new 'Color by execution frequency' filter:
> ![color-by-frequency-2](https://user-images.githubusercontent.com/8792647/107518492-5980e380-6baf-11eb-9e01-992b211d06e3.png)
> ![color-by-frequency-1](https://user-images.githubusercontent.com/8792647/107518477-54bc2f80-6baf-11eb-8c7b-7eb7c1d85cf7.png)
> Example of the new 'Hide X subgraph'' filters, where only the data subgraph is shown:
> ![hide-all-but-data-subgraphs](https://user-images.githubusercontent.com/8792647/107750398-42133900-6d1c-11eb-8b27-264086b32bea.png)
> Example of the new 'Hide X edges' filters, where all nodes remain in their position but only the memory edges are shown:
> ![hide-all-but-memory-edges](https://user-images.githubusercontent.com/8792647/107751137-49871200-6d1d-11eb-9df0-79747bf8d16e.png)
> 
> 
> Tested IGV manually on a few graphs. Tested C2 instrumentation by running `hs-tier1` with `-Xbatch -XX:PrintIdealGraphLevel=3 -XX:PrintIdealGraphFile=graph.xml` on windows-x64, linux-x64, linux-aarch64, and macosx-x64 (all debug).

Very nice!

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

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2499

From rcastanedalo at openjdk.java.net  Fri Feb 12 10:39:41 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 12 Feb 2021 10:39:41 GMT
Subject: RFR: 8261336: IGV: enhance default filters
In-Reply-To: <fVXeDSDJI-7jMGhiPOTNBGWqCG3bRGWtQaDRv2Lnsdo=.c0cfa2a5-9dba-4153-8c40-886569b2d916@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <fVXeDSDJI-7jMGhiPOTNBGWqCG3bRGWtQaDRv2Lnsdo=.c0cfa2a5-9dba-4153-8c40-886569b2d916@github.com>
Message-ID: <0GoV80nCM_IyK5msCNKbEGVt6czX5ClV8-m1vd-tVNI=.dbc0eeb2-ada6-4ff9-b25a-6e5a87b58393@github.com>

On Fri, 12 Feb 2021 10:34:59 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Very nice!

Thanks Vladimir!

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From adinn at openjdk.java.net  Fri Feb 12 10:43:43 2021
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Fri, 12 Feb 2021 10:43:43 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v2]
In-Reply-To: <YSiKdYz8EzmJx77zajQ_sLCdIhA0xfHtuZTXbaOrBc8=.974f7741-7037-43e6-aee6-1075b1e2da70@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
 <YSiKdYz8EzmJx77zajQ_sLCdIhA0xfHtuZTXbaOrBc8=.974f7741-7037-43e6-aee6-1075b1e2da70@github.com>
Message-ID: <LhkF9ZhUYT2i1TkmQMCkwcx60evmnLU6nzhsEQQGqjQ=.2b773692-b3bd-4710-993f-ecd460451218@github.com>

On Thu, 11 Feb 2021 18:49:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   broken build
>
> Seems reasonable.

The code here looks ok. I'm slightly concerned about the consequences of adding a new stack frame visible to stack walking code. Does this have the potential to break serviceability code that reports and/or analyzes stack frames (whether that's code in OpenJDK or 3rd party code)?

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

PR: https://git.openjdk.java.net/jdk/pull/2528

From roland at openjdk.java.net  Fri Feb 12 12:22:39 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 12 Feb 2021 12:22:39 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v2]
In-Reply-To: <LhkF9ZhUYT2i1TkmQMCkwcx60evmnLU6nzhsEQQGqjQ=.2b773692-b3bd-4710-993f-ecd460451218@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
 <YSiKdYz8EzmJx77zajQ_sLCdIhA0xfHtuZTXbaOrBc8=.974f7741-7037-43e6-aee6-1075b1e2da70@github.com>
 <LhkF9ZhUYT2i1TkmQMCkwcx60evmnLU6nzhsEQQGqjQ=.2b773692-b3bd-4710-993f-ecd460451218@github.com>
Message-ID: <2Ud0NpZTLE6UXcQ3S_kz6nK3N5-XAjYnwczmmpgB-Io=.09af4289-8ce5-4886-9cd5-7f5888f3772f@github.com>

On Fri, 12 Feb 2021 10:41:18 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> The code here looks ok. I'm slightly concerned about the consequences of adding a new stack frame visible to stack walking code. Does this have the potential to break serviceability code that reports and/or analyzes stack frames (whether that's code in OpenJDK or 3rd party code)?

Thanks for the review. The native invoker code is new in jdk 16 so it's unlikely tools already rely of some specific layout.

@iwanowww are you the author of the native invoker code? What do you think?

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

PR: https://git.openjdk.java.net/jdk/pull/2528

From chagedorn at openjdk.java.net  Fri Feb 12 12:51:43 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 12 Feb 2021 12:51:43 GMT
Subject: RFR: 8261336: IGV: enhance default filters
In-Reply-To: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
Message-ID: <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>

On Wed, 10 Feb 2021 10:00:00 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Redesign the filters shown by default in the "Filters" window:
> 
> - Add filters to color the graph by node category and execution frequency (if applicable), and to hide subgraphs or edges only by _category_. The category of a node can be one of {`data`, `memory`, `control`, `mixed`, `other`}, and is solely determined by its type. `mixed` nodes are those with a tuple type that has different categories, such as `CallStaticJavaNode`. The category of an edge is that of its source node.
> 
> - Instrument C2 to include the category and estimated execution frequency (if available) of each node in the graph dumps produced by `-XX:PrintIdealGraphLevel=N` (only in debug builds).
> 
> - Remove filters which depend on properties never emitted by C2 (e.g. 'Remove State') or which appear to be unused ('C2 Matcher Flags Coloring' and 'C2 Register Coloring'). Also remove the subsumed 'C2 Basic Coloring' filter. 
> 
> - Merge 'C2 Remove Filter' and 'C2 Structural' into a single filter with a clearer name ('Simplify graph').
> 
> ### Screenshots
> 
> "Filters" window before (left) and after (right) the proposed change:
> ![filters-window](https://user-images.githubusercontent.com/8792647/107749859-7a664780-6d1b-11eb-84ba-fd43e13abd0e.png)
> Default color scheme before (left) and after (right) the proposed change:
> ![color-scheme](https://user-images.githubusercontent.com/8792647/107517355-f3479100-6bad-11eb-9b0b-a71c18961dd8.png)
> Examples of the new 'Color by execution frequency' filter:
> ![color-by-frequency-2](https://user-images.githubusercontent.com/8792647/107518492-5980e380-6baf-11eb-9e01-992b211d06e3.png)
> ![color-by-frequency-1](https://user-images.githubusercontent.com/8792647/107518477-54bc2f80-6baf-11eb-8c7b-7eb7c1d85cf7.png)
> Example of the new 'Hide X subgraph'' filters, where only the data subgraph is shown:
> ![hide-all-but-data-subgraphs](https://user-images.githubusercontent.com/8792647/107750398-42133900-6d1c-11eb-8b27-264086b32bea.png)
> Example of the new 'Hide X edges' filters, where all nodes remain in their position but only the memory edges are shown:
> ![hide-all-but-memory-edges](https://user-images.githubusercontent.com/8792647/107751137-49871200-6d1d-11eb-9df0-79747bf8d16e.png)
> 
> 
> Tested IGV manually on a few graphs. Tested C2 instrumentation by running `hs-tier1` with `-Xbatch -XX:PrintIdealGraphLevel=3 -XX:PrintIdealGraphFile=graph.xml` on windows-x64, linux-x64, linux-aarch64, and macosx-x64 (all debug).

Otherwise, very nice improvement! I applied the patch and played around with it in the IGV. Everything seems to work as expected. I like the new default filters and the new colors for the new categories. That makes it much more useful.

src/utils/IdealGraphVisualizer/ServerCompiler/src/com/sun/hotspot/igv/servercompiler/filters/onlyControlFlow.filter line 23:

> 21:   )
> 22: );
> 23: f.addRule(new RemoveFilter.RemoveRule(new MatcherSelector(new Properties.RegexpPropertyMatcher("name", "Phi|CreateEx|Cast.*|Load.|Store."))));

I tried the filter out on a graph and noticed that there are still some data and memory nodes shown. How about utilizing the newly added categories? I played around a bit and this seems to work quite nicely. What do you think?

var f = new RemoveFilter("Show only control flow");
f.addRule(
  new RemoveFilter.RemoveRule(
    new OrSelector(
      new InvertSelector(
        new MatcherSelector(
          new Properties.RegexpPropertyMatcher("category", "control|mixed|other")
        )
      ),
      new MatcherSelector(
        new Properties.StringPropertyMatcher("type", "abIO")
      )
    ), false
  )
);
f.addRule(new RemoveFilter.RemoveRule(new MatcherSelector(new Properties.RegexpPropertyMatcher("name", "Phi|Root|Con"))));
f.apply(graph);

src/hotspot/share/opto/idealGraphPrinter.hpp line 95:

> 93:   bool _traverse_outs;
> 94:   Compile *C;
> 95:   double max_freq;

Fields should have a leading underscore.

src/hotspot/share/opto/type.cpp line 1120:

> 1118: Type::CATEGORY Type::category() const {
> 1119:   const TypeTuple* tuple;
> 1120:   switch (base()) {

Might be more readable if switch cases are indented.

src/hotspot/share/opto/type.hpp line 374:

> 372:     CatControl,
> 373:     CatOther,   // {Type::Top, Type::Abio, Type::Bottom}.
> 374:     CatUndef    // {Type::Bad, Type::lastype}, for completeness.

Is "Cat" required when the enum is already called "CATEGORY"?

src/hotspot/share/opto/idealGraphPrinter.cpp line 394:

> 392:     }
> 393: 
> 394:     switch (t->category()) {

Might be more readable if switch cases are indented.

src/hotspot/share/opto/type.cpp line 1178:

> 1176:   }
> 1177:   assert(false, "unmatched base type");
> 1178:   return CatUndef;

You could add that to an explicit default case to the above switch statement to make it more clear.

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

Changes requested by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2499

From rcastanedalo at openjdk.java.net  Fri Feb 12 15:37:41 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 12 Feb 2021 15:37:41 GMT
Subject: RFR: 8261336: IGV: enhance default filters
In-Reply-To: <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
Message-ID: <RXFEG1h7QaXhWuQXPsmeuYEFDVUh1dIvYacpRME9JuU=.4d016b55-05b8-4905-b5d3-db6e547036dc@github.com>

On Fri, 12 Feb 2021 12:48:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Otherwise, very nice improvement! I applied the patch and played around with it in the IGV. Everything seems to work as expected. I like the new default filters and the new colors for the new categories. That makes it much more useful.

Thanks for reviewing Christian! I will have a look at your comments on Monday.

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From dcubed at openjdk.java.net  Fri Feb 12 16:08:44 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 12 Feb 2021 16:08:44 GMT
Subject: RFR: 8261659: JDK-8261027 causes a Tier1 validate-source failure
Message-ID: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>

A trivial fix to make Tier1 'validate-source' happy again.

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

Commit messages:
 - 8261659: JDK-8261027 causes a Tier1 validate-source failure

Changes: https://git.openjdk.java.net/jdk/pull/2551/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2551&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261659
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2551.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2551/head:pull/2551

PR: https://git.openjdk.java.net/jdk/pull/2551

From dcubed at openjdk.java.net  Fri Feb 12 16:08:44 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 12 Feb 2021 16:08:44 GMT
Subject: RFR: 8261659: JDK-8261027 causes a Tier1 validate-source failure
In-Reply-To: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>
References: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>
Message-ID: <c8UPzDOttyJuQsAshn296gsdu3-7Xe8j9OToqNnYFbI=.27b614c1-539c-4be1-befd-95ed77d35564@github.com>

On Fri, 12 Feb 2021 16:03:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to make Tier1 'validate-source' happy again.

@theRealAph - Just a heads up that I had to tweak one of your files (copyright header only).

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

PR: https://git.openjdk.java.net/jdk/pull/2551

From iignatyev at openjdk.java.net  Fri Feb 12 16:13:37 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 12 Feb 2021 16:13:37 GMT
Subject: RFR: 8261659: JDK-8261027 causes a Tier1 validate-source failure
In-Reply-To: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>
References: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>
Message-ID: <Qoa_wOUjwXqc-VSyI_ZGI7FAVa5pcbOAJEi8sPo1Uws=.e9cbb54e-c16d-4386-b25a-9b52ce136e4d@github.com>

On Fri, 12 Feb 2021 16:03:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to make Tier1 'validate-source' happy again.

??

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

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2551

From bpb at openjdk.java.net  Fri Feb 12 16:13:39 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 12 Feb 2021 16:13:39 GMT
Subject: RFR: 8261659: JDK-8261027 causes a Tier1 validate-source failure
In-Reply-To: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>
References: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>
Message-ID: <kb15v5n6tUqtD9n6nnYyQDhYLIGKWzpRESjF4Ilmx3Y=.ae35185c-9a36-4d76-aad6-8e19ae7cc947@github.com>

On Fri, 12 Feb 2021 16:03:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to make Tier1 'validate-source' happy again.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2551

From dcubed at openjdk.java.net  Fri Feb 12 16:20:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 12 Feb 2021 16:20:41 GMT
Subject: Integrated: 8261659: JDK-8261027 causes a Tier1 validate-source
 failure
In-Reply-To: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>
References: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>
Message-ID: <BJwQUZIerbm2H27FoWQLAU7Ar-OnGKNrn1RxUP3j8-8=.3f90bc1d-30be-478a-8dd9-ea530996c5bd@github.com>

On Fri, 12 Feb 2021 16:03:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to make Tier1 'validate-source' happy again.

This pull request has now been integrated.

Changeset: 33fcd325
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/33fcd325
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8261659: JDK-8261027 causes a Tier1 validate-source failure

Reviewed-by: iignatyev, bpb

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

PR: https://git.openjdk.java.net/jdk/pull/2551

From dcubed at openjdk.java.net  Fri Feb 12 16:20:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 12 Feb 2021 16:20:40 GMT
Subject: RFR: 8261659: JDK-8261027 causes a Tier1 validate-source failure
In-Reply-To: <Qoa_wOUjwXqc-VSyI_ZGI7FAVa5pcbOAJEi8sPo1Uws=.e9cbb54e-c16d-4386-b25a-9b52ce136e4d@github.com>
References: <aWh7DaZZoHri-SB5zSvyBu7Pc27uDANrb64M1I0nhA8=.c2bc32f2-5a58-4f27-9c84-b66c373cf2b1@github.com>
 <Qoa_wOUjwXqc-VSyI_ZGI7FAVa5pcbOAJEi8sPo1Uws=.e9cbb54e-c16d-4386-b25a-9b52ce136e4d@github.com>
Message-ID: <80idU4OfeAmNoSjd4k3g7PKCEav3mI5DG7ddt45KLnQ=.6a2650bd-b7e1-4d45-bc4f-cd4773685f8f@github.com>

On Fri, 12 Feb 2021 16:10:20 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> A trivial fix to make Tier1 'validate-source' happy again.
>
> ??

@iignatev and @bplb - Thanks for the fast reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/2551

From mdoerr at openjdk.java.net  Fri Feb 12 16:33:52 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 12 Feb 2021 16:33:52 GMT
Subject: RFR: 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal
Message-ID: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>

We only need one StoreCM node after CMS removal. CMS StoreStore barriers were already removed at other places.

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

Commit messages:
 - 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal

Changes: https://git.openjdk.java.net/jdk/pull/2554/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2554&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261657
  Stats: 55 lines in 1 file changed: 0 ins; 52 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2554.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2554/head:pull/2554

PR: https://git.openjdk.java.net/jdk/pull/2554

From github.com+300291+eirbjo at openjdk.java.net  Fri Feb 12 17:17:39 2021
From: github.com+300291+eirbjo at openjdk.java.net (Eirik Bjorsnos)
Date: Fri, 12 Feb 2021 17:17:39 GMT
Subject: RFR: 8261235: C1 compilation fails with assert(res->vreg_number()
 == index) failed: conversion check
In-Reply-To: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
References: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
Message-ID: <qFEPKbTJXq3ilDkZLb_DZlCP2FHfaNdsaaFToGazSlw=.ed786479-0821-46ac-b3a0-3e5e7cecf153@github.com>

On Fri, 12 Feb 2021 10:03:25 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The assertion is hit because we run out of virtual registers in the linear scan in C1 and do not handle it. I fixed it by applying the same bailout as in `LIRGenerator::new_register()`. 
> 
> There is also a second issue that `LIR_OprDesc::vreg_max` is too big. It is only used in this bailout code. `OprBits::vreg_max` is defined over `OprBits::data_bits` which uses `OprBits::non_data_bits`. But `OprBits::non_data_bits` does not consider `OprBits::pointer_bits` which results in a too large value for `LIR_OprDesc::vreg_max` and the assertion is hit because we don't bail out, yet. This needs to be fixed as well.
> 
> Thanks,
> Christian

I tested this branch on my reproducer and it works like a charm:

    776  302       3       org.jaxen.saxpath.base.Verifier::isXMLLetter (6130 bytes)
    [...]
    compilation bailout: out of virtual registers in linear scan
    4717  302       3       org.jaxen.saxpath.base.Verifier::isXMLLetter (6130 bytes)   COMPILE SKIPPED: out of virtual registers in linear scan (retry at different tier)
    4718  334       4       org.jaxen.saxpath.base.Verifier::isXMLLetter (6130 bytes)

Is it expected that the bailout is logged twice?

First, a log line says: "compilation bailout: out of virtual registers in linear scan", then at the end of the next line: "COMPILE SKIPPED: out of virtual registers in linear scan (retry at different tier)" ?

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

PR: https://git.openjdk.java.net/jdk/pull/2543

From xliu at openjdk.java.net  Sat Feb 13 01:56:53 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 13 Feb 2021 01:56:53 GMT
Subject: RFR: 8261675: ObjectValue::set_visited(bool) sets _visited false
Message-ID: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>

The setter is error-prone. it unconditionally sets _visited false.
this patch stores the argument to it.

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

Commit messages:
 - 8261675: ObjectValue::set_visited(bool) sets _visited false

Changes: https://git.openjdk.java.net/jdk/pull/2560/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2560&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261675
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2560/head:pull/2560

PR: https://git.openjdk.java.net/jdk/pull/2560

From github.com+670087+jrziviani at openjdk.java.net  Sat Feb 13 02:22:38 2021
From: github.com+670087+jrziviani at openjdk.java.net (Ziviani)
Date: Sat, 13 Feb 2021 02:22:38 GMT
Subject: RFR: 8261522: [PPC64] AES intrinsics write beyond the destination
 array
In-Reply-To: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
References: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
Message-ID: <UNx98d9ENeNqb29FdJKHgHbiKWEXNyOptfLRR9a2Ydk=.4195bafc-67fa-4592-895b-f6a3798665bd@github.com>

On Wed, 10 Feb 2021 17:05:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to replace the read-modify-write implementation from aescrypt_encryptBlock / aescrypt_decryptBlock stubs. IT can cause severe problems (see bug description).

Very good. +1

Tested on P8, P9, and P10. With this patch I don't reproduce the problem. (tested LE only)

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

Marked as reviewed by jrziviani at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/2514

From kvn at openjdk.java.net  Sat Feb 13 06:36:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 13 Feb 2021 06:36:38 GMT
Subject: RFR: 8261675: ObjectValue::set_visited(bool) sets _visited false
In-Reply-To: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
References: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
Message-ID: <LdJH_FyGHBSSWJrdNoTzCOBxGDi5a6QvfUDlTXltMGc=.4ced9266-f095-409c-ab31-c90fe625c323@github.com>

On Sat, 13 Feb 2021 01:51:39 GMT, Xin Liu <xliu at openjdk.org> wrote:

> The setter is error-prone. it unconditionally sets _visited false.
> this patch stores the argument to it.

Wow. This was original changes for first implementation of Escape Analysis 6558600.

But it works because the only place where `set_visited()` is called it sets to `false`:
[debugInfoRec.cpp#L358](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/debugInfoRec.cpp#L358)

`is_visited()` is not called at all - `_visited` field is accessed directly only in one place:
[debugInfo.cpp#L161](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/debugInfo.cpp#L161)

Would be nice to clean up this mess.

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

PR: https://git.openjdk.java.net/jdk/pull/2560

From kvn at openjdk.java.net  Sat Feb 13 08:12:37 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 13 Feb 2021 08:12:37 GMT
Subject: RFR: 8261675: ObjectValue::set_visited(bool) sets _visited false
In-Reply-To: <LdJH_FyGHBSSWJrdNoTzCOBxGDi5a6QvfUDlTXltMGc=.4ced9266-f095-409c-ab31-c90fe625c323@github.com>
References: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
 <LdJH_FyGHBSSWJrdNoTzCOBxGDi5a6QvfUDlTXltMGc=.4ced9266-f095-409c-ab31-c90fe625c323@github.com>
Message-ID: <spujlQ8rbD0mT6JLQBfeZ0s-X4phjBj58fDLPuvzW0E=.641843d5-d764-44be-83f3-f4d97872f99e@github.com>

On Sat, 13 Feb 2021 06:33:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The setter is error-prone. it unconditionally sets _visited false.
>> this patch stores the argument to it.
>
> Wow. This was original changes for first implementation of Escape Analysis 6558600.
> 
> But it works because the only place where `set_visited()` is called it sets to `false`:
> [debugInfoRec.cpp#L358](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/debugInfoRec.cpp#L358)
> 
> `is_visited()` is not called at all - `_visited` field is accessed directly only in one place:
> [debugInfo.cpp#L161](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/debugInfo.cpp#L161)
> 
> Would be nice to clean up this mess.

In addition to your fix you can consider next changes to avoid dumping unneeded data in debug info (deoptimizer reads objects data only from top frame [deoptimization.cpp#L190](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L190):
src/hotspot/share/opto/output.cpp
     // We dump the object pool first, since deoptimization reads it in first.
-    C->debug_info()->dump_object_pool(objs);
+    C->debug_info()->dump_object_pool(objs, (depth < max_depth));

src/hotspot/share/code/debugInfoRec.hpp
-  void dump_object_pool(GrowableArray<ScopeValue*>* objects);
+  void dump_object_pool(GrowableArray<ScopeValue*>* objects, bool visited = false);

src/hotspot/share/code/debugInfoRec.cpp
-void DebugInformationRecorder::dump_object_pool(GrowableArray<ScopeValue*>* objects) {
+void DebugInformationRecorder::dump_object_pool(GrowableArray<ScopeValue*>* objects, bool visited) {
   guarantee( _pcs_length > 0, "safepoint must exist before describing scopes");
   PcDesc* last_pd = &_pcs[_pcs_length-1];
   if (objects != NULL) {
     for (int i = objects->length() - 1; i >= 0; i--) {
-      objects->at(i)->as_ObjectValue()->set_visited(false);
+      objects->at(i)->as_ObjectValue()->set_visited(visited);
     }
   }

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

PR: https://git.openjdk.java.net/jdk/pull/2560

From xliu at openjdk.java.net  Sat Feb 13 21:24:38 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 13 Feb 2021 21:24:38 GMT
Subject: RFR: 8261675: ObjectValue::set_visited(bool) sets _visited false
In-Reply-To: <spujlQ8rbD0mT6JLQBfeZ0s-X4phjBj58fDLPuvzW0E=.641843d5-d764-44be-83f3-f4d97872f99e@github.com>
References: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
 <LdJH_FyGHBSSWJrdNoTzCOBxGDi5a6QvfUDlTXltMGc=.4ced9266-f095-409c-ab31-c90fe625c323@github.com>
 <spujlQ8rbD0mT6JLQBfeZ0s-X4phjBj58fDLPuvzW0E=.641843d5-d764-44be-83f3-f4d97872f99e@github.com>
Message-ID: <JhbeWjR28gm9k67P7dDcYpcjSjl02LrYayODFmb1xjs=.4e2e35c5-2efb-4ad9-b629-36c328e32b3b@github.com>

On Sat, 13 Feb 2021 08:10:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> In addition to your fix you can consider next changes to avoid dumping unneeded data in debug info (deoptimizer reads objects data only from top frame [deoptimization.cpp#L190](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L190):
> 
> ```
> src/hotspot/share/opto/output.cpp
>      // We dump the object pool first, since deoptimization reads it in first.
> -    C->debug_info()->dump_object_pool(objs);
> +    C->debug_info()->dump_object_pool(objs, (depth < max_depth));
> ```

hi, Vladimir, 

Thank you for reviewing this patch.

I don't understand why it's depth < max_depth instead of <=.  
Further, the effect of this optimization seems limited. this statement is in a loop like this. 
depth < max_depth is almost always true. 

  for (int depth = 1; depth <= max_depth; depth++) {
...
    C->debug_info()->dump_object_pool(objs, (depth < max_depth));
...
  }

but I get your point. It seems that `Process_OopMap_Node` may dump identical objects in the loop.  I am not sure there are objects overlap different jvmstates.  let me check and create another issue if so.

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

PR: https://git.openjdk.java.net/jdk/pull/2560

From xliu at openjdk.java.net  Sat Feb 13 21:46:56 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 13 Feb 2021 21:46:56 GMT
Subject: RFR: 8261675: ObjectValue::set_visited(bool) sets _visited false
 [v2]
In-Reply-To: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
References: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
Message-ID: <dQRUVec71t9NINICOM5SoZBL56ifvgJ0FnXLPYHpP3M=.4cc6ac86-5f49-41ab-8b73-6c18994de430@github.com>

> The setter is error-prone. it unconditionally sets _visited false.
> this patch stores the argument to it.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  8261675: ObjectValue::set_visited(bool) sets _visited false
  
  use getter and setter of _visited.
  update the year of copyright.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2560/files
  - new: https://git.openjdk.java.net/jdk/pull/2560/files/2d512adc..dce5bbf2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2560&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2560&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2560/head:pull/2560

PR: https://git.openjdk.java.net/jdk/pull/2560

From xliu at openjdk.java.net  Sun Feb 14 05:44:51 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 14 Feb 2021 05:44:51 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v4]
In-Reply-To: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
Message-ID: <w-2JkDuXk-wAeMBvrZm8MS2OI3jADcEEELDRmZ16S48=.84db5012-0b2a-49ce-adb4-038cf59ce423@github.com>

> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
> 
> Before:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
> - string: "a"
> :Constant:exact *
> 
> After:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *

Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
   
   reimplement this feature. withdraw my intrusive change in outputStream.
   use stringStream only for the constant OopPtr. after oop->print_on(st),
   delete all appearances of '\n'
 - Merge branch 'master' into JDK-8260198
 - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
   
   fix merge conflict.
 - Merge branch 'master' into JDK-8260198
 - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
   
   Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
   Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
   Remove the comment because Klass::oop_print_on() has emitted the address of oop.
   
   Before:
   689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
   {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
    - string: "a"
    :Constant:exact *
   
   After:
   689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *

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

Changes: https://git.openjdk.java.net/jdk/pull/2178/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=03
  Stats: 51 lines in 4 files changed: 45 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2178.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2178/head:pull/2178

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Sun Feb 14 05:53:40 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 14 Feb 2021 05:53:40 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set
In-Reply-To: <yiZVqonBxaefuevXsp6kflksoEkCBmSPOTyvL9jfDMA=.ea90d033-9471-48e9-b9c1-ff0a91b29861@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <1lfc5MjMIFUx-Q19CkfKJvP4yYoM6B5APuRsvevpuk8=.3ba9c333-74b6-4ba4-bb3c-66c4583701fb@github.com>
 <yiZVqonBxaefuevXsp6kflksoEkCBmSPOTyvL9jfDMA=.ea90d033-9471-48e9-b9c1-ff0a91b29861@github.com>
Message-ID: <V9s3CCYxVPVdO4CYhDRxeZGlgwMsFA_KdfhOR5hkpOo=.d4d7db1f-71a5-4bb8-86b1-27f7b097a712@github.com>

On Thu, 28 Jan 2021 18:03:43 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The result your are trying to achieve is good, but I'm not sure pushing supress_cr into outputstream is the right thing. I would like to just not emit the cr's instead - but do also I see that isn't simple, because adding an extra bool to print_on would cascade into the entire codebase.
>
> @neliasso  Thanks for reviewing this. 
> Exactly.  The first reason is I am not familiar with oops/ codebase.  I guess some clients expect to see multiple lines. The second reason is that there are [many places](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/klass.cpp#L783). I am not sure I can clean them up completely.  
> 
> That's why I modify outputStream and give it a 'suppress_cr' mode.  May I ask hotspot-dev's advice?  /cc hotspot-dev

I reimplement this feature using streamStream.

After change, a ConP of an Constant OopPtr  becomes a one-liner. eg. 
279  ConP  ===  0  [[ 1105 ]]   Oop:java/lang/String java.lang.String {0x000000010100e3d0} - klass: public final synchronized 'java/lang/String' - string: "":Constant:exact *
please note that I keep "Oop:java/lang/String".  It's the output   klass()->print_name_on(st);
The remaining part "java.lang.String {0x000000010100e3d0} - klass: public final synchronized 'java/lang/String' - string: "":Constant:exact *" is the output of oop->print_on(st).  because it's output with `:+Verbose`, I think it's okay to have a bit verbose.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Mon Feb 15 09:26:56 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 15 Feb 2021 09:26:56 GMT
Subject: RFR: 8261731: shallow copy the internal buffer of a scalar-replaced
 java.lang.String object
Message-ID: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>

There are 3 nodes involving in the construction of a java.lang.String object.
1. Allocate of itself, aka. alloc
2. AllocateArray of a byte array, which is value:byte[], aka. aa
3. ArrayCopyNode which copys in the contents of value, aka. ac

Lemma
When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.

Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.

It is possible to rewire `aa` to the source of ac with the correct offset. That is to say, we can replace both `aa` and `ac` with a ?shallow copy? of the source of `ac`. It?s safe if C2 keeps a reference of the source oop for all safepoints.

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

Commit messages:
 - fix regression for x86-32
 - add a statistical counter for OptimizeTempArray.
 - [SIM-JVM-450] support deoptimization v2
 - add a unit test for deoptimization
 - [SIM-JVM-450] support deoptimization part2
 - enable OptimizeTempArray by default
 - Merge branch 'master' into optimize_substring
 - Revert "8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set"
 - Revert "add a new bucket afterea_late_inlines"
 - [SIM-JVM-450] support deoptimization
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/4619f372...fd9ca4b8

Changes: https://git.openjdk.java.net/jdk/pull/2570/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2570&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261731
  Stats: 861 lines in 16 files changed: 844 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2570.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2570/head:pull/2570

PR: https://git.openjdk.java.net/jdk/pull/2570

From chagedorn at openjdk.java.net  Mon Feb 15 09:57:40 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 15 Feb 2021 09:57:40 GMT
Subject: RFR: 8261235: C1 compilation fails with assert(res->vreg_number()
 == index) failed: conversion check
In-Reply-To: <qFEPKbTJXq3ilDkZLb_DZlCP2FHfaNdsaaFToGazSlw=.ed786479-0821-46ac-b3a0-3e5e7cecf153@github.com>
References: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
 <qFEPKbTJXq3ilDkZLb_DZlCP2FHfaNdsaaFToGazSlw=.ed786479-0821-46ac-b3a0-3e5e7cecf153@github.com>
Message-ID: <20tIOLHtwmZjPQSDLZgq_6hjIxaz1Z-6c6JX13ecUYc=.f2677c8a-a6f9-4f77-8ba2-a7e3bc05ff91@github.com>

On Fri, 12 Feb 2021 17:15:01 GMT, Eirik Bjorsnos <github.com+300291+eirbjo at openjdk.org> wrote:

>> The assertion is hit because we run out of virtual registers in the linear scan in C1 and do not handle it. I fixed it by applying the same bailout as in `LIRGenerator::new_register()`. 
>> 
>> There is also a second issue that `LIR_OprDesc::vreg_max` is too big. It is only used in this bailout code. `OprBits::vreg_max` is defined over `OprBits::data_bits` which uses `OprBits::non_data_bits`. But `OprBits::non_data_bits` does not consider `OprBits::pointer_bits` which results in a too large value for `LIR_OprDesc::vreg_max` and the assertion is hit because we don't bail out, yet. This needs to be fixed as well.
>> 
>> Thanks,
>> Christian
>
> I tested this branch on my reproducer and it works like a charm:
> 
>     776  302       3       org.jaxen.saxpath.base.Verifier::isXMLLetter (6130 bytes)
>     [...]
>     compilation bailout: out of virtual registers in linear scan
>     4717  302       3       org.jaxen.saxpath.base.Verifier::isXMLLetter (6130 bytes)   COMPILE SKIPPED: out of virtual registers in linear scan (retry at different tier)
>     4718  334       4       org.jaxen.saxpath.base.Verifier::isXMLLetter (6130 bytes)
> 
> Is it expected that the bailout is logged twice?
> 
> First, a log line says: "compilation bailout: out of virtual registers in linear scan", then at the end of the next line: "COMPILE SKIPPED: out of virtual registers in linear scan (retry at different tier)" ?

Thanks for verifying it!

> Is it expected that the bailout is logged twice?
> 
> First, a log line says: "compilation bailout: out of virtual registers in linear scan", then at the end of the next line: "COMPILE SKIPPED: out of virtual registers in linear scan (retry at different tier)" ?

Yes, that is expected. We first log the bailout alone here:
https://github.com/openjdk/jdk/blob/3882fda83bebf4a8c8100fd59c37f04610491ce7/src/hotspot/share/c1/c1_Compilation.cpp#L620-L627

And then later, we log the entire failed task with the failure reason (in this case the bailout) here:
https://github.com/openjdk/jdk/blob/3882fda83bebf4a8c8100fd59c37f04610491ce7/src/hotspot/share/compiler/compileBroker.cpp#L2347-L2352

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

PR: https://git.openjdk.java.net/jdk/pull/2543

From rcastanedalo at openjdk.java.net  Mon Feb 15 11:15:11 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 15 Feb 2021 11:15:11 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
Message-ID: <e_SY5T187c3zMUZQKNEkF56gm1SU2PSiyyXgMEVzFJY=.0357f39f-11f7-477d-a942-14fe83761f24@github.com>

> Redesign the filters shown by default in the "Filters" window:
> 
> - Add filters to color the graph by node category and execution frequency (if applicable), and to hide subgraphs or edges only by _category_. The category of a node can be one of {`data`, `memory`, `control`, `mixed`, `other`}, and is solely determined by its type. `mixed` nodes are those with a tuple type that has different categories, such as `CallStaticJavaNode`. The category of an edge is that of its source node.
> 
> - Instrument C2 to include the category and estimated execution frequency (if available) of each node in the graph dumps produced by `-XX:PrintIdealGraphLevel=N` (only in debug builds).
> 
> - Remove filters which depend on properties never emitted by C2 (e.g. 'Remove State') or which appear to be unused ('C2 Matcher Flags Coloring' and 'C2 Register Coloring'). Also remove the subsumed 'C2 Basic Coloring' filter. 
> 
> - Merge 'C2 Remove Filter' and 'C2 Structural' into a single filter with a clearer name ('Simplify graph').
> 
> ### Screenshots
> 
> "Filters" window before (left) and after (right) the proposed change:
> ![filters-window](https://user-images.githubusercontent.com/8792647/107749859-7a664780-6d1b-11eb-84ba-fd43e13abd0e.png)
> Default color scheme before (left) and after (right) the proposed change:
> ![color-scheme](https://user-images.githubusercontent.com/8792647/107517355-f3479100-6bad-11eb-9b0b-a71c18961dd8.png)
> Examples of the new 'Color by execution frequency' filter:
> ![color-by-frequency-2](https://user-images.githubusercontent.com/8792647/107518492-5980e380-6baf-11eb-9e01-992b211d06e3.png)
> ![color-by-frequency-1](https://user-images.githubusercontent.com/8792647/107518477-54bc2f80-6baf-11eb-8c7b-7eb7c1d85cf7.png)
> Example of the new 'Hide X subgraph'' filters, where only the data subgraph is shown:
> ![hide-all-but-data-subgraphs](https://user-images.githubusercontent.com/8792647/107750398-42133900-6d1c-11eb-8b27-264086b32bea.png)
> Example of the new 'Hide X edges' filters, where all nodes remain in their position but only the memory edges are shown:
> ![hide-all-but-memory-edges](https://user-images.githubusercontent.com/8792647/107751137-49871200-6d1d-11eb-9df0-79747bf8d16e.png)
> 
> 
> Tested IGV manually on a few graphs. Tested C2 instrumentation by running `hs-tier1` with `-Xbatch -XX:PrintIdealGraphLevel=3 -XX:PrintIdealGraphFile=graph.xml` on windows-x64, linux-x64, linux-aarch64, and macosx-x64 (all debug).

Roberto Casta?eda Lozano has updated the pull request incrementally with five additional commits since the last revision:

 - Rewrite 'Show control flow only' filter using categories
 - Add leading underscore field
 - Move assertion to a default switch case
 - Indent switch statements
 - Use a scoped enum for type categories (as per the HotSpot style guide)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2499/files
  - new: https://git.openjdk.java.net/jdk/pull/2499/files/3ed1e3de..adcb9181

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2499&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2499&range=00-01

  Stats: 105 lines in 5 files changed: 9 ins; 5 del; 91 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2499.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2499/head:pull/2499

PR: https://git.openjdk.java.net/jdk/pull/2499

From rcastanedalo at openjdk.java.net  Mon Feb 15 11:15:12 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 15 Feb 2021 11:15:12 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
Message-ID: <7ttppJD2MhW_0CDz-JWjd_n8Cv5dVIvSm-YZPXUGmXY=.7241d924-d261-4f57-a289-9f0b2177a85b@github.com>

On Fri, 12 Feb 2021 12:14:53 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Rewrite 'Show control flow only' filter using categories
>>  - Add leading underscore field
>>  - Move assertion to a default switch case
>>  - Indent switch statements
>>  - Use a scoped enum for type categories (as per the HotSpot style guide)
>
> src/hotspot/share/opto/idealGraphPrinter.hpp line 95:
> 
>> 93:   bool _traverse_outs;
>> 94:   Compile *C;
>> 95:   double max_freq;
> 
> Fields should have a leading underscore.

Done.

> src/hotspot/share/opto/type.cpp line 1120:
> 
>> 1118: Type::CATEGORY Type::category() const {
>> 1119:   const TypeTuple* tuple;
>> 1120:   switch (base()) {
> 
> Might be more readable if switch cases are indented.

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From rcastanedalo at openjdk.java.net  Mon Feb 15 11:17:42 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 15 Feb 2021 11:17:42 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
Message-ID: <L1dsUfCe3xq7xeJfGcc3kj_h4Fzn9T2APqPJJClsniE=.e2e3302f-c1f6-4a39-a575-98cbd458add6@github.com>

On Fri, 12 Feb 2021 12:18:35 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Rewrite 'Show control flow only' filter using categories
>>  - Add leading underscore field
>>  - Move assertion to a default switch case
>>  - Indent switch statements
>>  - Use a scoped enum for type categories (as per the HotSpot style guide)
>
> src/hotspot/share/opto/type.hpp line 374:
> 
>> 372:     CatControl,
>> 373:     CatOther,   // {Type::Top, Type::Abio, Type::Bottom}.
>> 374:     CatUndef    // {Type::Bad, Type::lastype}, for completeness.
> 
> Is "Cat" required when the enum is already called "CATEGORY"?

Right, it was required in a C-style unscoped-enum because of collisions with other enums in type.hpp. But I found in the HotSpot Style Guide that scoped-enums are actually encouraged, so I changed to that.

> src/hotspot/share/opto/idealGraphPrinter.cpp line 394:
> 
>> 392:     }
>> 393: 
>> 394:     switch (t->category()) {
> 
> Might be more readable if switch cases are indented.

Done.

> src/hotspot/share/opto/type.cpp line 1178:
> 
>> 1176:   }
>> 1177:   assert(false, "unmatched base type");
>> 1178:   return CatUndef;
> 
> You could add that to an explicit default case to the above switch statement to make it more clear.

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From rcastanedalo at openjdk.java.net  Mon Feb 15 11:23:40 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 15 Feb 2021 11:23:40 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
Message-ID: <I0yYFxfiA2vLGz6ezjqiwass_C9ibiFAekNwxhFzmPA=.d3199195-3709-496f-9efb-c2a6dc7cda7b@github.com>

On Fri, 12 Feb 2021 12:13:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Rewrite 'Show control flow only' filter using categories
>>  - Add leading underscore field
>>  - Move assertion to a default switch case
>>  - Indent switch statements
>>  - Use a scoped enum for type categories (as per the HotSpot style guide)
>
> src/utils/IdealGraphVisualizer/ServerCompiler/src/com/sun/hotspot/igv/servercompiler/filters/onlyControlFlow.filter line 23:
> 
>> 21:   )
>> 22: );
>> 23: f.addRule(new RemoveFilter.RemoveRule(new MatcherSelector(new Properties.RegexpPropertyMatcher("name", "Phi|CreateEx|Cast.*|Load.|Store."))));
> 
> I tried the filter out on a graph and noticed that there are still some data and memory nodes shown. How about utilizing the newly added categories? I played around a bit and this seems to work quite nicely. What do you think?
> 
> var f = new RemoveFilter("Show only control flow");
> f.addRule(
>   new RemoveFilter.RemoveRule(
>     new OrSelector(
>       new InvertSelector(
>         new MatcherSelector(
>           new Properties.RegexpPropertyMatcher("category", "control|mixed|other")
>         )
>       ),
>       new MatcherSelector(
>         new Properties.StringPropertyMatcher("type", "abIO")
>       )
>     ), false
>   )
> );
> f.addRule(new RemoveFilter.RemoveRule(new MatcherSelector(new Properties.RegexpPropertyMatcher("name", "Phi|Root|Con"))));
> f.apply(graph);

Thanks for the suggestion, I adopted it with some variations to avoid having to explicitly list pinned nodes like "Phi".

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From rcastanedalo at openjdk.java.net  Mon Feb 15 11:23:38 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 15 Feb 2021 11:23:38 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <RXFEG1h7QaXhWuQXPsmeuYEFDVUh1dIvYacpRME9JuU=.4d016b55-05b8-4905-b5d3-db6e547036dc@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
 <RXFEG1h7QaXhWuQXPsmeuYEFDVUh1dIvYacpRME9JuU=.4d016b55-05b8-4905-b5d3-db6e547036dc@github.com>
Message-ID: <s5fBB3F6SKEug1-ryKDkqsvFoWAuE3y6nO859xRhWu0=.30ab8afd-56e7-47ac-bac4-0d569ad454ae@github.com>

On Fri, 12 Feb 2021 15:34:51 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> > Otherwise, very nice improvement! I applied the patch and played around with it in the IGV. Everything seems to work as expected. I like the new default filters and the new colors for the new categories. That makes it much more useful.
> 
> Thanks for reviewing Christian! I will have a look at your comments on Monday.

I have addressed them now, please re-review.

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From chagedorn at openjdk.java.net  Mon Feb 15 13:57:39 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 15 Feb 2021 13:57:39 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <e_SY5T187c3zMUZQKNEkF56gm1SU2PSiyyXgMEVzFJY=.0357f39f-11f7-477d-a942-14fe83761f24@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <e_SY5T187c3zMUZQKNEkF56gm1SU2PSiyyXgMEVzFJY=.0357f39f-11f7-477d-a942-14fe83761f24@github.com>
Message-ID: <QvB8rhOuu8JXiT1uLjEa9hHr_WxewLxHie4MjKhXeSA=.957f946a-f8b7-4e41-9619-37cedccc0d86@github.com>

On Mon, 15 Feb 2021 11:15:11 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Redesign the filters shown by default in the "Filters" window:
>> 
>> - Add filters to color the graph by node category and execution frequency (if applicable), and to hide subgraphs or edges only by _category_. The category of a node can be one of {`data`, `memory`, `control`, `mixed`, `other`}, and is solely determined by its type. `mixed` nodes are those with a tuple type that has different categories, such as `CallStaticJavaNode`. The category of an edge is that of its source node.
>> 
>> - Instrument C2 to include the category and estimated execution frequency (if available) of each node in the graph dumps produced by `-XX:PrintIdealGraphLevel=N` (only in debug builds).
>> 
>> - Remove filters which depend on properties never emitted by C2 (e.g. 'Remove State') or which appear to be unused ('C2 Matcher Flags Coloring' and 'C2 Register Coloring'). Also remove the subsumed 'C2 Basic Coloring' filter. 
>> 
>> - Merge 'C2 Remove Filter' and 'C2 Structural' into a single filter with a clearer name ('Simplify graph').
>> 
>> ### Screenshots
>> 
>> "Filters" window before (left) and after (right) the proposed change:
>> ![filters-window](https://user-images.githubusercontent.com/8792647/107749859-7a664780-6d1b-11eb-84ba-fd43e13abd0e.png)
>> Default color scheme before (left) and after (right) the proposed change:
>> ![color-scheme](https://user-images.githubusercontent.com/8792647/107517355-f3479100-6bad-11eb-9b0b-a71c18961dd8.png)
>> Examples of the new 'Color by execution frequency' filter:
>> ![color-by-frequency-2](https://user-images.githubusercontent.com/8792647/107518492-5980e380-6baf-11eb-9e01-992b211d06e3.png)
>> ![color-by-frequency-1](https://user-images.githubusercontent.com/8792647/107518477-54bc2f80-6baf-11eb-8c7b-7eb7c1d85cf7.png)
>> Example of the new 'Hide X subgraph'' filters, where only the data subgraph is shown:
>> ![hide-all-but-data-subgraphs](https://user-images.githubusercontent.com/8792647/107750398-42133900-6d1c-11eb-8b27-264086b32bea.png)
>> Example of the new 'Hide X edges' filters, where all nodes remain in their position but only the memory edges are shown:
>> ![hide-all-but-memory-edges](https://user-images.githubusercontent.com/8792647/107751137-49871200-6d1d-11eb-9df0-79747bf8d16e.png)
>> 
>> 
>> Tested IGV manually on a few graphs. Tested C2 instrumentation by running `hs-tier1` with `-Xbatch -XX:PrintIdealGraphLevel=3 -XX:PrintIdealGraphFile=graph.xml` on windows-x64, linux-x64, linux-aarch64, and macosx-x64 (all debug).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Rewrite 'Show control flow only' filter using categories
>  - Add leading underscore field
>  - Move assertion to a default switch case
>  - Indent switch statements
>  - Use a scoped enum for type categories (as per the HotSpot style guide)

Thanks for addressing my suggestions. I tested it again - looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2499

From chagedorn at openjdk.java.net  Mon Feb 15 13:57:41 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 15 Feb 2021 13:57:41 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <I0yYFxfiA2vLGz6ezjqiwass_C9ibiFAekNwxhFzmPA=.d3199195-3709-496f-9efb-c2a6dc7cda7b@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <0Fwnnxu5gJTYdq6zVX8pzH5U4H-daq9fFnSGX3hgV0E=.1d812d3d-cdcd-4c78-9130-bf2d7b795580@github.com>
 <I0yYFxfiA2vLGz6ezjqiwass_C9ibiFAekNwxhFzmPA=.d3199195-3709-496f-9efb-c2a6dc7cda7b@github.com>
Message-ID: <A2r6AOk93FNpxA6nkZO3vrf4e9yPAW8jP16ISCOqCT8=.96a8f5d6-deef-477a-8b7a-70ce6e5434b5@github.com>

On Mon, 15 Feb 2021 11:19:04 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> src/utils/IdealGraphVisualizer/ServerCompiler/src/com/sun/hotspot/igv/servercompiler/filters/onlyControlFlow.filter line 23:
>> 
>>> 21:   )
>>> 22: );
>>> 23: f.addRule(new RemoveFilter.RemoveRule(new MatcherSelector(new Properties.RegexpPropertyMatcher("name", "Phi|CreateEx|Cast.*|Load.|Store."))));
>> 
>> I tried the filter out on a graph and noticed that there are still some data and memory nodes shown. How about utilizing the newly added categories? I played around a bit and this seems to work quite nicely. What do you think?
>> 
>> var f = new RemoveFilter("Show only control flow");
>> f.addRule(
>>   new RemoveFilter.RemoveRule(
>>     new OrSelector(
>>       new InvertSelector(
>>         new MatcherSelector(
>>           new Properties.RegexpPropertyMatcher("category", "control|mixed|other")
>>         )
>>       ),
>>       new MatcherSelector(
>>         new Properties.StringPropertyMatcher("type", "abIO")
>>       )
>>     ), false
>>   )
>> );
>> f.addRule(new RemoveFilter.RemoveRule(new MatcherSelector(new Properties.RegexpPropertyMatcher("name", "Phi|Root|Con"))));
>> f.apply(graph);
>
> Thanks for the suggestion, I adopted it with some variations to avoid having to explicitly list pinned nodes like "Phi".

That's even better! Thanks for adopting that suggestion.

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From lucy at openjdk.java.net  Mon Feb 15 17:47:38 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 15 Feb 2021 17:47:38 GMT
Subject: RFR: 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal
In-Reply-To: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>
References: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>
Message-ID: <9llRP8rEfThe6mIPc57HbANvm7iyeyB2zJ73FNbWbNo=.1b07a60c-7722-4db4-bae8-4629ee3cba07@github.com>

On Fri, 12 Feb 2021 16:29:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We only need one StoreCM node after CMS removal. CMS StoreStore barriers were already removed at other places.

Changes look good to me. 
Thanks for cleaning up!

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

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2554

From jbhateja at openjdk.java.net  Mon Feb 15 18:55:03 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 15 Feb 2021 18:55:03 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v3]
In-Reply-To: <lT4eXJDfZffgaSA1rd2h7HwywpQl0PkaqM-vrMoUWcs=.589a2a04-f5ab-42e3-878c-cc6612fc20d3@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
 <csbaOvyMeGK0-mJxDyJxhmdHa_HcocG7CQtw4XUtrfE=.35c9820d-964c-47e7-8cdb-db4e8f76d082@github.com>
 <R5kRXNkycQgBML5b608AqyFJnKtn4ncKHvJBPSRTuqY=.5d9c9ab6-382c-4a87-b7a1-8df7bfb9c2bc@github.com>
 <NMpSSPd-r--k7mTy64pp3v90_wVPT5-tBgRb09aerGI=.d7ed6c67-96b8-4ab1-9651-9f3fec43139d@github.com>
 <GumNspvDQjUjL6QiqPVddY5p6vn9aOpqPgq3uAw_rSo=.a5c33ff0-977b-4ec1-a245-c6a916fc0aa0@github.com>
 <lT4eXJDfZffgaSA1rd2h7HwywpQl0PkaqM-vrMoUWcs=.589a2a04-f5ab-42e3-878c-cc6612fc20d3@github.com>
Message-ID: <qzGeCPVxgf_HOk-jGTJhflTSWIzzTDB7VlaV3P0ao1I=.7a74e563-d3ed-481c-8da4-5ae71e2a4e72@github.com>

On Fri, 12 Feb 2021 05:59:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Hi Claes, This could be a run to run variation, in general we are now having fewer number of instructions (one shift operation saved per mask computation) compared to previous masked generation sequence and thus it will always offer better execution latencies.
>> 
>> Run-to-run variation would be easy to rule out by running more forks and more iterations to attain statistically significant results. While the instruction manuals suggest latency should be better for this instruction on all CPUs where it's supported, it would be good if there was some clear proof - such as a significant benchmark win - to motivate the added complexity.
>
>> > Hi Claes, This could be a run to run variation, in general we are now having fewer number of instructions (one shift operation saved per mask computation) compared to previous masked generation sequence and thus it will always offer better execution latencies.
>> 
>> Run-to-run variation would be easy to rule out by running more forks and more iterations to attain statistically significant results. While the instruction manuals suggest latency should be better for this instruction on all CPUs where it's supported, it would be good if there was some clear proof - such as a significant benchmark win - to motivate the added complexity.
> 
> BASELINE:
> Result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong":
>   61.037 ns/op
> 
> Secondary result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong:??perf":
> Perf stats:
> --------------------------------------------------
> 
>          19,739.21 msec task-clock                #    0.389 CPUs utilized          
>                646      context-switches          #    0.033 K/sec                  
>                 12      cpu-migrations            #    0.001 K/sec                  
>                150      page-faults               #    0.008 K/sec                  
>    74,59,83,59,139      cycles                    #    3.779 GHz                      (30.73%)
>  1,78,78,79,19,117      instructions              #    2.40  insn per cycle           (38.48%)
>    24,79,81,63,651      branches                  # 1256.289 M/sec                    (38.55%)
>       32,24,89,924      branch-misses             #    1.30% of all branches          (38.62%)
>    52,56,88,28,472      L1-dcache-loads           # 2663.167 M/sec                    (38.65%)
>          39,00,969      L1-dcache-load-misses     #    0.01% of all L1-dcache hits    (38.57%)
>           3,74,131      LLC-loads                 #    0.019 M/sec                    (30.77%)
>             22,315      LLC-load-misses           #    5.96% of all LL-cache hits     (30.72%)
>    <not supported>      L1-icache-loads                                             
>          17,49,997      L1-icache-load-misses                                         (30.72%)
>    52,91,41,70,636      dTLB-loads                # 2680.663 M/sec                    (30.69%)
>              3,315      dTLB-load-misses          #    0.00% of all dTLB cache hits   (30.67%)
>              4,674      iTLB-loads                #    0.237 K/sec                    (30.65%)
>             33,746      iTLB-load-misses          #  721.99% of all iTLB cache hits   (30.63%)
>    <not supported>      L1-dcache-prefetches                                        
>    <not supported>      L1-dcache-prefetch-misses                                   
> 
>       50.723759146 seconds time elapsed
> 
>       51.447054000 seconds user
>        0.189949000 seconds sys
> 
> 
> WITH OPT:
> Result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong":
>   74.356 ns/op
> 
> Secondary result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong:??perf":
> Perf stats:
> --------------------------------------------------
> 
>          19,741.09 msec task-clock                #    0.389 CPUs utilized          
>                641      context-switches          #    0.032 K/sec                  
>                 17      cpu-migrations            #    0.001 K/sec                  
>                164      page-faults               #    0.008 K/sec                  
>    74,40,40,48,513      cycles                    #    3.769 GHz                      (30.81%)
>  1,45,66,22,06,797      instructions              #    1.96  insn per cycle           (38.56%)
>    20,31,28,43,577      branches                  # 1028.963 M/sec                    (38.65%)
>          14,11,419      branch-misses             #    0.01% of all branches          (38.69%)
>    43,07,86,33,662      L1-dcache-loads           # 2182.182 M/sec                    (38.72%)
>          37,06,744      L1-dcache-load-misses     #    0.01% of all L1-dcache hits    (38.56%)
>           1,34,292      LLC-loads                 #    0.007 M/sec                    (30.72%)
>             30,627      LLC-load-misses           #   22.81% of all LL-cache hits     (30.68%)
>    <not supported>      L1-icache-loads                                             
>          14,49,145      L1-icache-load-misses                                         (30.65%)
>    43,44,86,27,516      dTLB-loads                # 2200.924 M/sec                    (30.63%)
>                218      dTLB-load-misses          #    0.00% of all dTLB cache hits   (30.63%)
>              2,445      iTLB-loads                #    0.124 K/sec                    (30.63%)
>             28,624      iTLB-load-misses          # 1170.72% of all iTLB cache hits   (30.63%)
>    <not supported>      L1-dcache-prefetches                                        
>    <not supported>      L1-dcache-prefetch-misses                                   
> 
>       50.716083931 seconds time elapsed
> 
>       51.467300000 seconds user
>        0.200390000 seconds sys
> 
> 
> JMH perf data for ArrayCopyUnalignedSrc.testLong with copy length  of 1200 shows degradation in LID accesses, it seems the benchmask got displaced from its sweet spot.
> 
> But, there is a significant reduction in instruction count  and cycles are almost comparable.  We are saving one shift per mask computation.
> 
>           OLD Sequence:
>               0x00007f7fc1030ead:   movabs $0x1,%rax
>               0x00007f7fc1030eb7:   shlx   %r8,%rax,%rax
>               0x00007f7fc1030ebc:   dec    %rax
>               0x00007f7fc1030ebf:   kmovq  %rax,%k2
>           NEW Sequence:
>               0x00007f775d030d51:   movabs $0xffffffffffffffff,%rax
>               0x00007f775d030d5b:   bzhi   %r8,%rax,%rax
>               0x00007f775d030d60:   kmovq  %rax,%k2

Further analysis of perf degradation revealed that with new optimized instruction pattern, code alignment got disturbed. This led to increase in LSD misses, also it reduced the UOPs cashing in DSB.  
Aligning copy loops at 32 byte boundary prevents any adverse impact on UOP caching.
NOPs used for padding add up to the instruction count and thus may over shadow the code size gains due to new mask generation sequence in copy stubs.  

Baseline:
 ArrayCopyAligned.testLong   Length : 1200    61 ns/op (approx)
 1,93,44,43,11,622      cycles                                                      
 4,59,57,99,78,727      instructions              #    2.38  insn per cycle         
 1,83,68,75,68,255      idq.dsb_uops                                                
 2,08,32,43,71,906      lsd.uops                                                    
   37,12,54,60,211      idq.mite_uops                                               

With Opt:
 ArrayCopyAligned.testLong   Length : 1200   74 ns/op (approx)
 1,93,51,25,94,766      cycles                                                      
 3,75,11,57,91,917      instructions              #    1.94  insn per cycle         
   48,67,58,25,566      idq.dsb_uops                                                
      19,46,13,236      lsd.uops                                                    
 2,87,42,95,74,280      idq.mite_uops                                               

With Opt + main loop alignment(nop):         61 ns/op (approx)
 ArrayCopyAligned.testLong   Length : 1200 
 1,93,52,15,90,080      cycles                                                      
 4,60,89,14,06,528      instructions              #    2.38  insn per cycle         
 1,78,76,10,34,991      idq.dsb_uops                                                
 2,09,16,15,84,313      lsd.uops                                                    
   46,25,31,92,101      idq.mite_uops            


While computing the mask for partial in-lining of small copy calls ( currently enabled for sub-word types with copy length less than 32/64 bytes), new optimized sequence should always offer lower instruction count and latency path.


Baseline:
ArrayCopyAligned.testByte        Length : 20  avgt    2  2.635          ns/op
 1,97,76,75,18,052      cycles                                                      
 8,96,00,37,11,803      instructions              #    4.53  insn per cycle         
    2,71,83,79,035      idq.dsb_uops                                                
 7,54,82,43,63,409      lsd.uops                                                    
    3,92,55,74,395      idq.mite_uops                                               

ArrayCopyAligned.testByte        Length : 31  avgt    2  2.635          ns/op
 1,97,79,16,56,787      cycles                                                      
 8,96,13,15,69,780      instructions              #    4.53  insn per cycle         
    2,69,07,11,691      idq.dsb_uops                                                
 7,54,95,63,77,683      lsd.uops                                                    
    3,90,19,10,747      idq.mite_uops                                               

WithOpt:
ArrayCopyAligned.testByte        Length : 20  avgt    2  2.635          ns/op
 1,97,66,64,62,541      cycles                                                      
 8,92,03,95,00,236      instructions              #    4.51  insn per cycle         
    2,72,38,56,205      idq.dsb_uops                                                
 7,50,87,50,60,591      lsd.uops                                                    
    3,89,15,02,954      idq.mite_uops                                               

ArrayCopyAligned.testByte        Length : 31  avgt    2  2.635          ns/op
 1,97,54,21,61,110      cycles                                                      
 8,91,46,64,23,754      instructions              #    4.51  insn per cycle         
    2,78,12,19,544      idq.dsb_uops                                                
 7,50,35,88,95,843      lsd.uops                                                    
    3,90,41,97,276      idq.mite_uops                               
                

Following are the links to updated JMH perf data:
http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_BASELINE.txt
http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_WITH_OPTS_LOOP_ALIGN.txt

In general gains are not significant in case of copy stubs, but new sequence offers a optimal latency path for mask computation sequence.

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From jbhateja at openjdk.java.net  Mon Feb 15 18:55:02 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 15 Feb 2021 18:55:02 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v3]
In-Reply-To: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
Message-ID: <fOkYPC2KarulNUevhWhgG0gJ8Ki5P-zcsk1hGC9AG20=.ef56d06b-3432-425e-b853-a1896a7c154f@github.com>

> BMI2 BHZI instruction can be used to optimize the instruction sequence
> used for mask generation at various place in array copy stubs and partial in-lining for small copy operations.

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8261553 : Aligning main copy loop to prevent any penalty due to LSD and DSB misses.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2522/files
  - new: https://git.openjdk.java.net/jdk/pull/2522/files/84c9c2da..7012eed0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2522&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2522&range=01-02

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2522.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2522/head:pull/2522

PR: https://git.openjdk.java.net/jdk/pull/2522

From xliu at openjdk.java.net  Mon Feb 15 19:00:57 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 15 Feb 2021 19:00:57 GMT
Subject: RFR: 8261731: shallow copy the internal buffer of a
 scalar-replaced java.lang.String object [v2]
In-Reply-To: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
References: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
Message-ID: <3JNae6rXuxc_Q6YoALCH8Ku510Zne5ftqf1z8OCGkHQ=.2ebf5cd0-27e2-44e3-adf7-065179cc9ffd@github.com>

> There are 3 nodes involving in the construction of a java.lang.String object.
> 1. Allocate of itself, aka. alloc
> 2. AllocateArray of a byte array, which is value:byte[], aka. aa
> 3. ArrayCopyNode which copys in the contents of value, aka. ac
> 
> Lemma
> When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.
> 
> Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.
> 
> It is possible to rewire `aa` to the source of ac with the correct offset. That is to say, we can replace both `aa` and `ac` with a ?shallow copy? of the source of `ac`. It?s safe if C2 keeps a reference of the source oop for all safepoints.

Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - Merge branch 'master' into optimize_substring
 - fix regression for x86-32
   
   if LP64 is off, the offset of AddP must be I instead of L.
   x86 also doesn't emit encodeP/storeN. it use storeP instead.
 - add a statistical counter for OptimizeTempArray.
   
   -XX:+PrintOptoStatistics shows it
 - [SIM-JVM-450] support deoptimization v2
   
   because the src oop of scobj may be another scobj, deoptimization sort
   all objects in topological order.
   
   separate creation of dst oop and reassignment of it.
 - add a unit test for deoptimization
 - [SIM-JVM-450] support deoptimization part2
   
   if OptimizeTempArray eliminates an AllocateArrayNode, scalar replacement will
   create a nested SafePointScalarObjectNode for the field value:byte[] of j.l.String.
   we use the nested sobj and an ObjectValue an envelope. it consists of 3 fields:
   1. src 2. src_positio 3. length.
   
   deoptimizaton recognizes this ad-hoc ObjectValue and re-allocate an arrayOop
   for the String object.
 - enable OptimizeTempArray by default
 - Merge branch 'master' into optimize_substring
 - Revert "8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set"
   
   This reverts commit a49e34688d7d7c9d3c0d9c824d33f359613c2fc1.
 - Revert "add a new bucket afterea_late_inlines"
   
   afterea_late_inlines bucket is not useful. revert it and its relevant changes
 - ... and 26 more: https://git.openjdk.java.net/jdk/compare/849f4c0f...21693ddd

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

Changes: https://git.openjdk.java.net/jdk/pull/2570/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2570&range=01
  Stats: 861 lines in 16 files changed: 844 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2570.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2570/head:pull/2570

PR: https://git.openjdk.java.net/jdk/pull/2570

From mdoerr at openjdk.java.net  Mon Feb 15 19:47:54 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 15 Feb 2021 19:47:54 GMT
Subject: RFR: 8261522: [PPC64] AES intrinsics write beyond the destination
 array [v2]
In-Reply-To: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
References: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
Message-ID: <K2AZ5ew1HVUJsdEg66W6jMJefBtcCMbhM6SGIPtTc44=.916cef56-ea98-40d2-8c44-685b9c7ed51a@github.com>

> I'd like to replace the read-modify-write implementation from aescrypt_encryptBlock / aescrypt_decryptBlock stubs. It can cause severe problems (see bug description).

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Add comment and key length assertions. Minor improvement.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2514/files
  - new: https://git.openjdk.java.net/jdk/pull/2514/files/d933c2f7..725dd8c7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2514&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2514&range=00-01

  Stats: 42 lines in 1 file changed: 26 ins; 8 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2514.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2514/head:pull/2514

PR: https://git.openjdk.java.net/jdk/pull/2514

From nhe at activeviam.com  Mon Feb 15 13:19:05 2021
From: nhe at activeviam.com (Nicolas Heutte)
Date: Mon, 15 Feb 2021 14:19:05 +0100
Subject: [External] : Re: SuperWord loop optimization lost after method
 inlining
In-Reply-To: <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>
References: <CAOqmmc0ue3bLMBgWLAvUOrHLe2iNtoSiBiq=+Beky-D=MkA+fw@mail.gmail.com>
 <b9184f85-c869-8088-a080-2d860dca5f9f@oracle.com>
 <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
 <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>
Message-ID: <CAOqmmc2mWWr2mWoitEz71xc1PZ53ZLhyDfRQ+TjxKRcuGcxNkg@mail.gmail.com>

Hi Vladimir,

I've tried disabling tiered compilation, as you requested. It seems that
the inlining was performed slightly differently, but the issue remains. As
you can see in this excerpt, the main loop isn't properly vectorized:

  0x00000254b0d4bf54: cmp    %r11d,%r8d
  0x00000254b0d4bf57: jae    0x00000254b0d4c19e
  0x00000254b0d4bf5d: vmovss 0x10(%rcx,%r8,4),%xmm9  ;*faload {reexecute=0
rethrow=0 return_oop=0}
                                                ; -
com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
(line 41)
                                                ; -
com.qfs.vector.impl.AVector::plus at 17 (line 204)
                                                ; -
com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
                                                ; -
com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line
66)
                                                ; -
com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)

  0x00000254b0d4bf64: cmp    %ebx,%r8d
  0x00000254b0d4bf67: jae    0x00000254b0d4c1ec
  0x00000254b0d4bf6d: vaddss 0x10(%rdi,%r8,4),%xmm9,%xmm9
  0x00000254b0d4bf74: vmovss %xmm9,0x10(%rcx,%r8,4)  ;*fastore {reexecute=0
rethrow=0 return_oop=0}
                                                ; -
com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
(line 41)
                                                ; -
com.qfs.vector.impl.AVector::plus at 17 (line 204)
                                                ; -
com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
                                                ; -
com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line
66)
                                                ; -
com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)

  0x00000254b0d4bf7b: inc    %r8d               ;*iinc {reexecute=0
rethrow=0 return_oop=0}
                                                ; -
com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
(line 40)
                                                ; -
com.qfs.vector.impl.AVector::plus at 17 (line 204)
                                                ; -
com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
                                                ; -
com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line
66)
                                                ; -
com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)

  0x00000254b0d4bf7e: cmp    %r9d,%r8d
  0x00000254b0d4bf81: jl     0x00000254b0d4bf54  ;*goto {reexecute=0
rethrow=0 return_oop=0}
                                                ; -
com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
(line 40)
                                                ; -
com.qfs.vector.impl.AVector::plus at 17 (line 204)
                                                ; -
com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
                                                ; -
com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line
66)
                                                ; -
com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)



Here is the link to the full log, should you want to take a look at it:
https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing

Best regards,
Nicolas Heutte

On Thu, Feb 11, 2021 at 7:05 PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Changing wide mailing list to JIT compiler only.
>
> This deoptimization is normal in Tiered Compilation - it switched from
> profiling code (level='3') generated by C1
> compiler to new code generated by C2 (level='4') which does loop
> optimizations.
>
> Thank you for posting inlining information:
>
>      @ 17
>  com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
> bytes) inline (hot)
>         \-> TypeProfile (14054/14054 counts) =
> com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
>
> I thought before that may be call site is not hot but it is not the case.
>
> You can do an other experiment to collect log with disabled Tiered
> Compilation (only C2 is used): -XX:-TieredCompilation
> Also print assembler code (as you did before) for final compilation to see
> if loop is still not vectorized.
>
> Is it possible to post log file (on GitHub?) for me to look?
>
> Thanks,
> Vladimir K
>
> On 2/11/21 6:28 AM, Nicolas Heutte wrote:
> > Hi Vladimir,
> >
> > Thank you for your help.
> >
> > I'm currently running Java 11.0.9, and I did not use any VM flag of note.
> >
> > I checked the content of the compilation log, and it seems that
> ArrayFloatToArrayFloatVectorBinding::plus() was
> > deoptimized in order to allow AVector::plus() to be compiled:
> >
> > <writer thread='11576'/>
> > <task_queued compile_id='17280' method='com.qfs.vector.impl.AVector plus
> (Lcom/qfs/vector/IVector;)V' bytes='23'
> > count='916' iicount='916' level='3' stamp='7394.056' comment='tiered'
> hot_count='896'/>
> > <writer thread='15784'/>
> > <deoptimized thread='15784' reason='constraint' pc='0x00000296d0785b94'
> compile_id='17257' compiler='c1' level='3'>
> > <jvms bci='65'
> method='com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding
> plus
> > (Lcom/qfs/vector/IVector;Lcom/qfs/vector/IVector;)V' bytes='69'
> count='909' backedge_count='155602' iicount='910'/>
> > </deoptimized>
> >
> > The last compilation entry for AVector::plus() is:
> >
> > <writer thread='16380'/>
> > <nmethod compile_id='17317' compiler='c2' level='4'
> entry='0x00000296d6af32c0' size='1960' address='0x00000296d6af3110'
> > relocation_offset='376' insts_offset='432' stub_offset='1040'
> scopes_data_offset='1152' scopes_pcs_offset='1592'
> > dependencies_offset='1880' nul_chk_table_offset='1896'
> oops_offset='1064' metadata_offset='1072'
> > method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V'
> bytes='23' count='172425' iicount='172425'
> > stamp='7394.199'/>
> > <make_not_entrant thread='16380' compile_id='17280' compiler='c1'
> level='2' stamp='7394.199'/>
> >                                @ 1
> com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes)   inline
> (hot)
> >                                 \-&gt; TypeProfile (14552/14552 counts)
> = com/qfs/vector/array/impl/ArrayFloatVector
> >                                @ 7
> com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes)   inline
> (hot)
> >                                 \-&gt; TypeProfile (14150/14150 counts)
> = com/qfs/vector/array/impl/ArrayFloatVector
> >                                @ 10
> com.qfs.vector.binding.impl.VectorBindings::getBinding (9 bytes)   inline
> (hot)
> >                                  @ 5
> com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::getBinding
> (22
> > bytes)   inline (hot)
> >                                    @ 3
> com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::hasBinding
>
> > (34 bytes)   inline (hot)
> >                                @ 17
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
> bytes)
> > inline (hot)
> >                                 \-&gt; TypeProfile (14054/14054 counts)
> =
> > com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
> >                                  @ 12
> com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)   inline (hot)
> >                                  @ 22
> com.qfs.vector.impl.AVector::checkIndex (37 bytes)   inline (hot)
> >                                    @ 6
> com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)   inline (hot)
> >                                  @ 27
> com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)
> accessor
> >                                  @ 34
> com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)
> accessor
> > <writer thread='15896'/>
> >
> > Unfortunately, I do not have access to a debug VM build, so I cannot run
> the second test you recommend.
> >
> > Best regards,
> > Nicolas Heutte
> >
> > On Wed, Feb 10, 2021 at 7:36 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> >
> >     Hi, Nicolas
> >
> >     Looks like, when inlined, the loop from
> ArrayFloatToArrayFloatVectorBinding::plus() was not optimized at all: it is
> not
> >     unrolled and has range checks. Such loops are not vectorized (you
> need unrolling and no checks).
> >
> >     What Java version you are running? What HotSpot VM flags you are
> using when running application?
> >
> >     Run application with -XX:+LogCompilation and look on compilation
> data in hotspot_pid<PID>.log file for caller
> >     AVector::plus().
> >
> >     VM also has several flags to trace loop optimizations but they are
> only available in debug VM build. If you have access
> >     to such build run with -XX:+PrintCompilation -XX:+TraceLoopOpts
> flags.
> >
> >     Thanks,
> >     Vladimir K
> >
> >     On 2/10/21 9:24 AM, Nicolas Heutte wrote:
> >      > Hi all,
> >      >
> >      > I am encountering a performance issue caused by the interaction
> between
> >      > method inlining and automatic vectorization.
> >      >
> >      > Our application aggregates arrays intensively using a method named
> >      > ArrayFloatToArrayFloatVectorBinding.plus() with the following
> code:
> >      >
> >      >      for (int i = 0; i < srcLen; ++i) {
> >      >
> >      >              dstArray[i] += srcArray[i];
> >      >
> >      >      }
> >      >
> >      > When we microbenchmark this method we observe fast performance
> close to the
> >      > practical memory bandwidth and when we print the assembly code we
> observe
> >      > loop unrolling and automatic vectorization with SIMD instructions.
> >      >
> >      >    0x000001ef4600abf0: vmovdqu 0x10(%r14,%r13,4),%ymm0
> >      >
> >      >    0x000001ef4600abf7: vaddps 0x10(%rcx,%r13,4),%ymm0,%ymm0
> >      >
> >      >    0x000001ef4600abfe: vmovdqu %ymm0,0x10(%r14,%r13,4)
> >      >
> >      >    0x000001ef4600ac05: movslq %r13d,%r11
> >      >
> >      >    0x000001ef4600ac08: vmovdqu 0x30(%r14,%r11,4),%ymm0
> >      >
> >      >    0x000001ef4600ac0f: vaddps 0x30(%rcx,%r11,4),%ymm0,%ymm0
> >      >
> >      >    0x000001ef4600ac16: vmovdqu %ymm0,0x30(%r14,%r11,4)
> >      >
> >      >    0x000001ef4600ac1d: vmovdqu 0x50(%r14,%r11,4),%ymm0
> >      >
> >      >    0x000001ef4600ac24: vaddps 0x50(%rcx,%r11,4),%ymm0,%ymm0
> >      >
> >      >    0x000001ef4600ac2b: vmovdqu %ymm0,0x50(%r14,%r11,4)
> >      >
> >      >    0x000001ef4600ac32: vmovdqu 0x70(%r14,%r11,4),%ymm0
> >      >
> >      >    0x000001ef4600ac39: vaddps 0x70(%rcx,%r11,4),%ymm0,%ymm0
> >      >
> >      >    0x000001ef4600ac40: vmovdqu %ymm0,0x70(%r14,%r11,4)
> >      >
> >      >    0x000001ef4600ac47: vmovdqu 0x90(%r14,%r11,4),%ymm0
> >      >
> >      >    0x000001ef4600ac51: vaddps 0x90(%rcx,%r11,4),%ymm0,%ymm0
> >      >
> >      >    0x000001ef4600ac5b: vmovdqu %ymm0,0x90(%r14,%r11,4)
> >      >
> >      >    0x000001ef4600ac65: vmovdqu 0xb0(%r14,%r11,4),%ymm0
> >      >
> >      >    0x000001ef4600ac6f: vaddps 0xb0(%rcx,%r11,4),%ymm0,%ymm0
> >      >
> >      >    0x000001ef4600ac79: vmovdqu %ymm0,0xb0(%r14,%r11,4)
> >      >
> >      >    0x000001ef4600ac83: vmovdqu 0xd0(%r14,%r11,4),%ymm0
> >      >
> >      >    0x000001ef4600ac8d: vaddps 0xd0(%rcx,%r11,4),%ymm0,%ymm0
> >      >
> >      >    0x000001ef4600ac97: vmovdqu %ymm0,0xd0(%r14,%r11,4)
> >      >
> >      >    0x000001ef4600aca1: vmovdqu 0xf0(%r14,%r11,4),%ymm0
> >      >
> >      >    0x000001ef4600acab: vaddps 0xf0(%rcx,%r11,4),%ymm0,%ymm0
> >      >
> >      >    0x000001ef4600acb5: vmovdqu %ymm0,0xf0(%r14,%r11,4)  ;*fastore
> >      > {reexecute=0 rethrow=0 return_oop=0}
> >      >
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> >      > (line 41)
> >      >
> >      >    0x000001ef4600acbf: add    $0x40,%r13d        ;*iinc
> {reexecute=0
> >      > rethrow=0 return_oop=0}
> >      >
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> >      > (line 40)
> >      >
> >      >    0x000001ef4600acc3: cmp    %eax,%r13d
> >      >
> >      >    0x000001ef4600acc6: jl     0x000001ef4600abf0  ;*goto
> {reexecute=0
> >      > rethrow=0 return_oop=0}
> >      >
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> >      > (line 40)
> >      >
> >      >
> >      >
> >      > In the real application, this method is actually inlined in a
> higher level
> >      > method named AVector.plus(). Unfortunately, the inlined version
> of the
> >      > aggregation code is not vectorized anymore:
> >      >
> >      >
> >      >
> >      >    0x000001ef460180a0: cmp    %ebx,%r11d
> >      >
> >      >    0x000001ef460180a3: jae    0x000001ef460180e6
> >      >
> >      >    0x000001ef460180a5: vmovss 0x10(%r8,%r11,4),%xmm1  ;*faload
> {reexecute=0
> >      > rethrow=0 return_oop=0}
> >      >
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
> >      > (line 41)
> >      >
> >      >                                                  ; -
> >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >
> >      >    0x000001ef460180ac: cmp    %ecx,%r11d
> >      >
> >      >    0x000001ef460180af: jae    0x000001ef46018104
> >      >
> >      >    0x000001ef460180b1: vaddss 0x10(%r9,%r11,4),%xmm1,%xmm1
> >      >
> >      >    0x000001ef460180b8: vmovss %xmm1,0x10(%r8,%r11,4)  ;*fastore
> {reexecute=0
> >      > rethrow=0 return_oop=0}
> >      >
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> >      > (line 41)
> >      >
> >      >                                                  ; -
> >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >
> >      >    0x000001ef460180bf: inc    %r11d              ;*iinc
> {reexecute=0
> >      > rethrow=0 return_oop=0}
> >      >
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> >      > (line 40)
> >      >
> >      >                                                  ; -
> >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >
> >      >    0x000001ef460180c2: cmp    %r10d,%r11d
> >      >
> >      >    0x000001ef460180c5: jl     0x000001ef460180a0  ;*goto
> {reexecute=0
> >      > rethrow=0 return_oop=0}
> >      >
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> >      > (line 40)
> >      >
> >      >                                                  ; -
> >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >
> >      >
> >      >
> >      > This causes a significant performance drop, compared to a run
> where we
> >      > explicitly disable the inlining and observe automatically
> vectorized code
> >      > again (
> >      >
> -XX:CompileCommand=dontinline,com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding.plus
> >      > ).
> >      >
> >      >
> >      > How do you guys explain that behavior of the JIT compiler? Is
> this a known
> >      > and tracked issue, could it be fixed in the JVM? Can we do
> something in the
> >      > java code to prevent this from happening?
> >      >
> >      >
> >      > Best regards,
> >      >
> >      > Nicolas Heutte
> >      >
> >
>

From duke at openjdk.java.net  Tue Feb 16 01:29:44 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 16 Feb 2021 01:29:44 GMT
Subject: Withdrawn: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <91erxiMDb4ftvSomuJYHPi9SX-v8Z2VLD2qEwCbz5tk=.b9ed01b5-f0e0-4ed7-9c1a-b06bc0e64640@github.com>
References: <91erxiMDb4ftvSomuJYHPi9SX-v8Z2VLD2qEwCbz5tk=.b9ed01b5-f0e0-4ed7-9c1a-b06bc0e64640@github.com>
Message-ID: <YM0Ln83GVH5SpuNEAmGGO9T1NdUfpXB4QCJXUyn35eY=.46a0ae44-92f9-4e83-8da7-4e8e391ca550@github.com>

On Tue, 29 Sep 2020 04:36:16 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> When bringing up Hotspot onto new platforms, it is not always possible to compile hsdis because gcc is not yet available. For example, for Windows-AArch64 and macOS-AArch64.
> 
> For some such platforms, it is possible to use LLVM as an alternative backend as it also supports a disassembler feature.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/392

From rrich at openjdk.java.net  Tue Feb 16 08:17:43 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Tue, 16 Feb 2021 08:17:43 GMT
Subject: RFR: 8261731: shallow copy the internal buffer of a
 scalar-replaced java.lang.String object
In-Reply-To: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
References: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
Message-ID: <J428b0kfPbnDCzKiIX7-qDDXQ147AYWk_sJQmWLJuIo=.eedb676a-06d1-48a8-acd3-57f01f9ebd86@github.com>

On Mon, 15 Feb 2021 09:22:00 GMT, Xin Liu <xliu at openjdk.org> wrote:

> There are 3 nodes involving in the construction of a java.lang.String object.
> 1. Allocate of itself, aka. alloc
> 2. AllocateArray of a byte array, which is value:byte[], aka. aa
> 3. ArrayCopyNode which copys in the contents of value, aka. ac
> 
> Lemma
> When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.
> 
> Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.
> 
> It is possible to rewire `aa` to the source of ac with the correct offset. That is to say, we can replace both `aa` and `ac` with a ?shallow copy? of the source of `ac`. It?s safe if C2 keeps a reference of the source oop for all safepoints.

Hi,

this is a smart optimization.

> 
> 
> There are 3 nodes involving in the construction of a java.lang.String object.
> 
>     1. Allocate of itself, aka. alloc
> 
>     2. AllocateArray of a byte array, which is value:byte[], aka. aa
> 
>     3. ArrayCopyNode which copys in the contents of value, aka. ac
> 
> 
> Lemma
> When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.
> 
> Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.

Are you saying that the source of `ac` cannot be accessed by another thread because of the cloning in the constructor? But the resulting string instance which is used to construct the non-escape instance can be GlobalEscape and then the source of `ac` is accessible to other threads, isn't it?

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

PR: https://git.openjdk.java.net/jdk/pull/2570

From thartmann at openjdk.java.net  Tue Feb 16 11:35:55 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 16 Feb 2021 11:35:55 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <e_SY5T187c3zMUZQKNEkF56gm1SU2PSiyyXgMEVzFJY=.0357f39f-11f7-477d-a942-14fe83761f24@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <e_SY5T187c3zMUZQKNEkF56gm1SU2PSiyyXgMEVzFJY=.0357f39f-11f7-477d-a942-14fe83761f24@github.com>
Message-ID: <uNq2zz5zmbSQWyDcJz3cK-cL8pu8A9Io3CejnQtawDw=.55344167-68c3-40ef-b203-656af5349d71@github.com>

On Mon, 15 Feb 2021 11:15:11 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Redesign the filters shown by default in the "Filters" window:
>> 
>> - Add filters to color the graph by node category and execution frequency (if applicable), and to hide subgraphs or edges only by _category_. The category of a node can be one of {`data`, `memory`, `control`, `mixed`, `other`}, and is solely determined by its type. `mixed` nodes are those with a tuple type that has different categories, such as `CallStaticJavaNode`. The category of an edge is that of its source node.
>> 
>> - Instrument C2 to include the category and estimated execution frequency (if available) of each node in the graph dumps produced by `-XX:PrintIdealGraphLevel=N` (only in debug builds).
>> 
>> - Remove filters which depend on properties never emitted by C2 (e.g. 'Remove State') or which appear to be unused ('C2 Matcher Flags Coloring' and 'C2 Register Coloring'). Also remove the subsumed 'C2 Basic Coloring' filter. 
>> 
>> - Merge 'C2 Remove Filter' and 'C2 Structural' into a single filter with a clearer name ('Simplify graph').
>> 
>> ### Screenshots
>> 
>> "Filters" window before (left) and after (right) the proposed change:
>> ![filters-window](https://user-images.githubusercontent.com/8792647/107749859-7a664780-6d1b-11eb-84ba-fd43e13abd0e.png)
>> Default color scheme before (left) and after (right) the proposed change:
>> ![color-scheme](https://user-images.githubusercontent.com/8792647/107517355-f3479100-6bad-11eb-9b0b-a71c18961dd8.png)
>> Examples of the new 'Color by execution frequency' filter:
>> ![color-by-frequency-2](https://user-images.githubusercontent.com/8792647/107518492-5980e380-6baf-11eb-9e01-992b211d06e3.png)
>> ![color-by-frequency-1](https://user-images.githubusercontent.com/8792647/107518477-54bc2f80-6baf-11eb-8c7b-7eb7c1d85cf7.png)
>> Example of the new 'Hide X subgraph'' filters, where only the data subgraph is shown:
>> ![hide-all-but-data-subgraphs](https://user-images.githubusercontent.com/8792647/107750398-42133900-6d1c-11eb-8b27-264086b32bea.png)
>> Example of the new 'Hide X edges' filters, where all nodes remain in their position but only the memory edges are shown:
>> ![hide-all-but-memory-edges](https://user-images.githubusercontent.com/8792647/107751137-49871200-6d1d-11eb-9df0-79747bf8d16e.png)
>> 
>> 
>> Tested IGV manually on a few graphs. Tested C2 instrumentation by running `hs-tier1` with `-Xbatch -XX:PrintIdealGraphLevel=3 -XX:PrintIdealGraphFile=graph.xml` on windows-x64, linux-x64, linux-aarch64, and macosx-x64 (all debug).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Rewrite 'Show control flow only' filter using categories
>  - Add leading underscore field
>  - Move assertion to a default switch case
>  - Indent switch statements
>  - Use a scoped enum for type categories (as per the HotSpot style guide)

This is awesome. Thanks a lot for taking the time to improve the IGV. Looks good to me!

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2499

From chagedorn at openjdk.java.net  Tue Feb 16 11:36:14 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 16 Feb 2021 11:36:14 GMT
Subject: RFR: 8261235: C1 compilation fails with assert(res->vreg_number()
 == index) failed: conversion check [v2]
In-Reply-To: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
References: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
Message-ID: <ZAua39vvZ0Mn89VvYs5gZy5hDPlkqPMffV_7WKefXYM=.dab689d3-6e1a-46be-9c0c-971ac1d738ef@github.com>

> The assertion is hit because we run out of virtual registers in the linear scan in C1 and do not handle it. I fixed it by applying the same bailout as in `LIRGenerator::new_register()`. 
> 
> There is also a second issue that `LIR_OprDesc::vreg_max` is too big. It is only used in this bailout code. `OprBits::vreg_max` is defined over `OprBits::data_bits` which uses `OprBits::non_data_bits`. But `OprBits::non_data_bits` does not consider `OprBits::pointer_bits` which results in a too large value for `LIR_OprDesc::vreg_max` and the assertion is hit because we don't bail out, yet. This needs to be fixed as well.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:

  Fix order of non_data_bits

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2543/files
  - new: https://git.openjdk.java.net/jdk/pull/2543/files/5fd1b911..82df324a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2543&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2543&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2543.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2543/head:pull/2543

PR: https://git.openjdk.java.net/jdk/pull/2543

From thartmann at openjdk.java.net  Tue Feb 16 11:36:15 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 16 Feb 2021 11:36:15 GMT
Subject: RFR: 8261235: C1 compilation fails with assert(res->vreg_number()
 == index) failed: conversion check [v2]
In-Reply-To: <ZAua39vvZ0Mn89VvYs5gZy5hDPlkqPMffV_7WKefXYM=.dab689d3-6e1a-46be-9c0c-971ac1d738ef@github.com>
References: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
 <ZAua39vvZ0Mn89VvYs5gZy5hDPlkqPMffV_7WKefXYM=.dab689d3-6e1a-46be-9c0c-971ac1d738ef@github.com>
Message-ID: <8KAbnjufy-zo-KSGC3R8TebVYBQeAL7-M4u32Fe_bSQ=.fbc29b15-c1ff-4270-b5d4-3d0687cf4031@github.com>

On Tue, 16 Feb 2021 11:07:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The assertion is hit because we run out of virtual registers in the linear scan in C1 and do not handle it. I fixed it by applying the same bailout as in `LIRGenerator::new_register()`. 
>> 
>> There is also a second issue that `LIR_OprDesc::vreg_max` is too big. It is only used in this bailout code. `OprBits::vreg_max` is defined over `OprBits::data_bits` which uses `OprBits::non_data_bits`. But `OprBits::non_data_bits` does not consider `OprBits::pointer_bits` which results in a too large value for `LIR_OprDesc::vreg_max` and the assertion is hit because we don't bail out, yet. This needs to be fixed as well.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix order of non_data_bits

Looks good to me.

src/hotspot/share/c1/c1_LIR.hpp line 235:

> 233:     , is_fpu_stack_offset_bits = 1        // used in assertion checking on x86 for FPU stack slot allocation
> 234:     , non_data_bits  = kind_bits + type_bits + size_bits + destroys_bits + last_use_bits +
> 235:                        is_fpu_stack_offset_bits + virtual_bits + is_xmm_bits + pointer_bits

Would be nice to have this in the same order as the enum values.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2543

From chagedorn at openjdk.java.net  Tue Feb 16 11:36:15 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 16 Feb 2021 11:36:15 GMT
Subject: RFR: 8261235: C1 compilation fails with assert(res->vreg_number()
 == index) failed: conversion check [v2]
In-Reply-To: <8KAbnjufy-zo-KSGC3R8TebVYBQeAL7-M4u32Fe_bSQ=.fbc29b15-c1ff-4270-b5d4-3d0687cf4031@github.com>
References: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
 <ZAua39vvZ0Mn89VvYs5gZy5hDPlkqPMffV_7WKefXYM=.dab689d3-6e1a-46be-9c0c-971ac1d738ef@github.com>
 <8KAbnjufy-zo-KSGC3R8TebVYBQeAL7-M4u32Fe_bSQ=.fbc29b15-c1ff-4270-b5d4-3d0687cf4031@github.com>
Message-ID: <OqjVh6TB2wUScgj3ZexUag9vEYcTfiyukffYu9nznSI=.e8f4c360-e332-41a1-ae57-66ef0fbdc9b6@github.com>

On Tue, 16 Feb 2021 10:45:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix order of non_data_bits
>
> Looks good to me.

Thank you Tobias for your review!

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

PR: https://git.openjdk.java.net/jdk/pull/2543

From rcastanedalo at openjdk.java.net  Tue Feb 16 12:45:40 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 16 Feb 2021 12:45:40 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <uNq2zz5zmbSQWyDcJz3cK-cL8pu8A9Io3CejnQtawDw=.55344167-68c3-40ef-b203-656af5349d71@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <e_SY5T187c3zMUZQKNEkF56gm1SU2PSiyyXgMEVzFJY=.0357f39f-11f7-477d-a942-14fe83761f24@github.com>
 <uNq2zz5zmbSQWyDcJz3cK-cL8pu8A9Io3CejnQtawDw=.55344167-68c3-40ef-b203-656af5349d71@github.com>
Message-ID: <Z09A2Wcls8b7tItTlAdfvTU8IptZrfd23G6OzUR1BzA=.9bd80670-66c9-46ea-8a08-684f695d6f15@github.com>

On Tue, 16 Feb 2021 10:33:10 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Rewrite 'Show control flow only' filter using categories
>>  - Add leading underscore field
>>  - Move assertion to a default switch case
>>  - Indent switch statements
>>  - Use a scoped enum for type categories (as per the HotSpot style guide)
>
> This is awesome. Thanks a lot for taking the time to improve the IGV. Looks good to me!

Thanks Christian and Tobias for reviewing!

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From rcastanedalo at openjdk.java.net  Tue Feb 16 12:50:51 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 16 Feb 2021 12:50:51 GMT
Subject: RFR: 8261336: IGV: enhance default filters [v2]
In-Reply-To: <Z09A2Wcls8b7tItTlAdfvTU8IptZrfd23G6OzUR1BzA=.9bd80670-66c9-46ea-8a08-684f695d6f15@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
 <e_SY5T187c3zMUZQKNEkF56gm1SU2PSiyyXgMEVzFJY=.0357f39f-11f7-477d-a942-14fe83761f24@github.com>
 <uNq2zz5zmbSQWyDcJz3cK-cL8pu8A9Io3CejnQtawDw=.55344167-68c3-40ef-b203-656af5349d71@github.com>
 <Z09A2Wcls8b7tItTlAdfvTU8IptZrfd23G6OzUR1BzA=.9bd80670-66c9-46ea-8a08-684f695d6f15@github.com>
Message-ID: <qP2erT40jpZHYVcJNFHqcj7PgmpNu8v_eLIpVC_zN1k=.576e93f0-d8af-47d5-abe2-a8fc3c8cfcba@github.com>

On Tue, 16 Feb 2021 12:42:45 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This is awesome. Thanks a lot for taking the time to improve the IGV. Looks good to me!
>
> Thanks Christian and Tobias for reviewing!

Add filters to color and hide parts of the graph based on node categories or
estimated execution frequency, and simplify remaining filters.

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From rcastanedalo at openjdk.java.net  Tue Feb 16 12:50:52 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 16 Feb 2021 12:50:52 GMT
Subject: Integrated: 8261336: IGV: enhance default filters
In-Reply-To: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
References: <xUTFYi1xUoLlIB_GeDBnrQfDaM7sOL4S1NrnhQSErdk=.952f2b9b-227f-4b79-b387-ec91eb27b007@github.com>
Message-ID: <8dk6qu4lZzEthqpitvtkSzLwGFuf0SH80kMSK1kPP5I=.b2a802d1-1a9c-4b05-ba6e-e00bb18d936c@github.com>

On Wed, 10 Feb 2021 10:00:00 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Redesign the filters shown by default in the "Filters" window:
> 
> - Add filters to color the graph by node category and execution frequency (if applicable), and to hide subgraphs or edges only by _category_. The category of a node can be one of {`data`, `memory`, `control`, `mixed`, `other`}, and is solely determined by its type. `mixed` nodes are those with a tuple type that has different categories, such as `CallStaticJavaNode`. The category of an edge is that of its source node.
> 
> - Instrument C2 to include the category and estimated execution frequency (if available) of each node in the graph dumps produced by `-XX:PrintIdealGraphLevel=N` (only in debug builds).
> 
> - Remove filters which depend on properties never emitted by C2 (e.g. 'Remove State') or which appear to be unused ('C2 Matcher Flags Coloring' and 'C2 Register Coloring'). Also remove the subsumed 'C2 Basic Coloring' filter. 
> 
> - Merge 'C2 Remove Filter' and 'C2 Structural' into a single filter with a clearer name ('Simplify graph').
> 
> ### Screenshots
> 
> "Filters" window before (left) and after (right) the proposed change:
> ![filters-window](https://user-images.githubusercontent.com/8792647/107749859-7a664780-6d1b-11eb-84ba-fd43e13abd0e.png)
> Default color scheme before (left) and after (right) the proposed change:
> ![color-scheme](https://user-images.githubusercontent.com/8792647/107517355-f3479100-6bad-11eb-9b0b-a71c18961dd8.png)
> Examples of the new 'Color by execution frequency' filter:
> ![color-by-frequency-2](https://user-images.githubusercontent.com/8792647/107518492-5980e380-6baf-11eb-9e01-992b211d06e3.png)
> ![color-by-frequency-1](https://user-images.githubusercontent.com/8792647/107518477-54bc2f80-6baf-11eb-8c7b-7eb7c1d85cf7.png)
> Example of the new 'Hide X subgraph'' filters, where only the data subgraph is shown:
> ![hide-all-but-data-subgraphs](https://user-images.githubusercontent.com/8792647/107750398-42133900-6d1c-11eb-8b27-264086b32bea.png)
> Example of the new 'Hide X edges' filters, where all nodes remain in their position but only the memory edges are shown:
> ![hide-all-but-memory-edges](https://user-images.githubusercontent.com/8792647/107751137-49871200-6d1d-11eb-9df0-79747bf8d16e.png)
> 
> 
> Tested IGV manually on a few graphs. Tested C2 instrumentation by running `hs-tier1` with `-Xbatch -XX:PrintIdealGraphLevel=3 -XX:PrintIdealGraphFile=graph.xml` on windows-x64, linux-x64, linux-aarch64, and macosx-x64 (all debug).

This pull request has now been integrated.

Changeset: 16bd7d38
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/16bd7d38
Stats:     375 lines in 25 files changed: 292 ins; 44 del; 39 mod

8261336: IGV: enhance default filters

Add filters to color and hide parts of the graph based on node categories or
estimated execution frequency, and simplify remaining filters.

Co-authored-by: Christian Hagedorn <chagedorn at openjdk.org>
Reviewed-by: vlivanov, chagedorn, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2499

From github.com+670087+jrziviani at openjdk.java.net  Tue Feb 16 12:57:41 2021
From: github.com+670087+jrziviani at openjdk.java.net (Ziviani)
Date: Tue, 16 Feb 2021 12:57:41 GMT
Subject: RFR: 8261522: [PPC64] AES intrinsics write beyond the destination
 array [v2]
In-Reply-To: <K2AZ5ew1HVUJsdEg66W6jMJefBtcCMbhM6SGIPtTc44=.916cef56-ea98-40d2-8c44-685b9c7ed51a@github.com>
References: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
 <K2AZ5ew1HVUJsdEg66W6jMJefBtcCMbhM6SGIPtTc44=.916cef56-ea98-40d2-8c44-685b9c7ed51a@github.com>
Message-ID: <9RiCsBAS3URyQbPTCdAyZAIb-2gdFR4ttzyNhNC0Mpc=.4da8f3b2-d685-4d41-a921-5d0318467771@github.com>

On Mon, 15 Feb 2021 19:47:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to replace the read-modify-write implementation from aescrypt_encryptBlock / aescrypt_decryptBlock stubs. It can cause severe problems (see bug description).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment and key length assertions. Minor improvement.

+1

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

Marked as reviewed by jrziviani at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/2514

From lucy at openjdk.java.net  Tue Feb 16 13:58:40 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 16 Feb 2021 13:58:40 GMT
Subject: RFR: 8261522: [PPC64] AES intrinsics write beyond the destination
 array [v2]
In-Reply-To: <K2AZ5ew1HVUJsdEg66W6jMJefBtcCMbhM6SGIPtTc44=.916cef56-ea98-40d2-8c44-685b9c7ed51a@github.com>
References: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
 <K2AZ5ew1HVUJsdEg66W6jMJefBtcCMbhM6SGIPtTc44=.916cef56-ea98-40d2-8c44-685b9c7ed51a@github.com>
Message-ID: <RjPUd61AwRlTpqYJEmv0LrPpqCocf05ws-6b39tbvCU=.76d438e3-84a7-4475-9f85-c164444dda13@github.com>

On Mon, 15 Feb 2021 19:47:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to replace the read-modify-write implementation from aescrypt_encryptBlock / aescrypt_decryptBlock stubs. It can cause severe problems (see bug description).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment and key length assertions. Minor improvement.

Hi Martin, 
the changes look good to me. Thanks for tracking that down and fixing it. I know that wasn't trivial. 

One minor thing - it made me believe for a second I had missed something: in line 2631, the reference should be to vRet, not vsRet. Same is true further down in decryptBlock. 

Lutz

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

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2514

From mdoerr at openjdk.java.net  Tue Feb 16 15:20:58 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 16 Feb 2021 15:20:58 GMT
Subject: RFR: 8261522: [PPC64] AES intrinsics write beyond the destination
 array [v3]
In-Reply-To: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
References: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
Message-ID: <m94zeXcA0ihoRQXNZWq70HFPT7UX70MRCGCW2h_sGl4=.8444bc96-bdfe-453f-a0dd-b3ae725d7be6@github.com>

> I'd like to replace the read-modify-write implementation from aescrypt_encryptBlock / aescrypt_decryptBlock stubs. It can cause severe problems (see bug description).

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in comment.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2514/files
  - new: https://git.openjdk.java.net/jdk/pull/2514/files/725dd8c7..69188df5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2514&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2514&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2514.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2514/head:pull/2514

PR: https://git.openjdk.java.net/jdk/pull/2514

From mdoerr at openjdk.java.net  Tue Feb 16 15:20:58 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 16 Feb 2021 15:20:58 GMT
Subject: RFR: 8261522: [PPC64] AES intrinsics write beyond the destination
 array [v2]
In-Reply-To: <RjPUd61AwRlTpqYJEmv0LrPpqCocf05ws-6b39tbvCU=.76d438e3-84a7-4475-9f85-c164444dda13@github.com>
References: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
 <K2AZ5ew1HVUJsdEg66W6jMJefBtcCMbhM6SGIPtTc44=.916cef56-ea98-40d2-8c44-685b9c7ed51a@github.com>
 <RjPUd61AwRlTpqYJEmv0LrPpqCocf05ws-6b39tbvCU=.76d438e3-84a7-4475-9f85-c164444dda13@github.com>
Message-ID: <jQjREChmFSRiFXd8yc_YFD4WTlzn9BtldE8O9QxW4EQ=.aadb12f7-6f8b-410c-88c9-44b875d2a74c@github.com>

On Tue, 16 Feb 2021 13:56:19 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment and key length assertions. Minor improvement.
>
> Hi Martin, 
> the changes look good to me. Thanks for tracking that down and fixing it. I know that wasn't trivial. 
> 
> One minor thing - it made me believe for a second I had missed something: in line 2631, the reference should be to vRet, not vsRet. Same is true further down in decryptBlock. 
> 
> Lutz

Thanks a lot for the reviews!
I've fixed the typo in the comments as suggested by Lutz.

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

PR: https://git.openjdk.java.net/jdk/pull/2514

From mdoerr at openjdk.java.net  Tue Feb 16 15:24:43 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 16 Feb 2021 15:24:43 GMT
Subject: RFR: 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal
In-Reply-To: <9llRP8rEfThe6mIPc57HbANvm7iyeyB2zJ73FNbWbNo=.1b07a60c-7722-4db4-bae8-4629ee3cba07@github.com>
References: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>
 <9llRP8rEfThe6mIPc57HbANvm7iyeyB2zJ73FNbWbNo=.1b07a60c-7722-4db4-bae8-4629ee3cba07@github.com>
Message-ID: <49i6dtfgYn-S4lkLqm3zUihbjSjmScLNVu1I1klciPY=.b00d70f7-3264-4b6c-894d-fb5a11ad3be6@github.com>

On Mon, 15 Feb 2021 17:45:02 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> We only need one StoreCM node after CMS removal. CMS StoreStore barriers were already removed at other places.
>
> Changes look good to me. 
> Thanks for cleaning up!

Thanks for the review!
I guess this can be considered as trivial because we basically remove dead code.

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

PR: https://git.openjdk.java.net/jdk/pull/2554

From github.com+168222+mgkwill at openjdk.java.net  Tue Feb 16 16:19:01 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 16 Feb 2021 16:19:01 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain masked
 positive values
Message-ID: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>

8261671: X86 I2L conversion can be skipped for certain masked positive values

For the following expression:
 (long)(value & mask)
Where value is of int type and mask is constant (power of two ? 1), we can directly generate bzhi instruction to zero the upper bits instead of doing an andl, followed by movslq

Before:
Benchmark Mode Cnt Score Error Units
SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 10.679 ? 1.496 ns/op


After:
Benchmark Mode Cnt Score Error Units
SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 7.870 ? 0.067 ns/op

Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

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

Commit messages:
 - 8261671: Skip unnecessary Int2L conversions

Changes: https://git.openjdk.java.net/jdk/pull/2590/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2590&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261671
  Stats: 37 lines in 3 files changed: 37 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2590.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2590/head:pull/2590

PR: https://git.openjdk.java.net/jdk/pull/2590

From redestad at openjdk.java.net  Tue Feb 16 16:36:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Feb 2021 16:36:40 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v3]
In-Reply-To: <qzGeCPVxgf_HOk-jGTJhflTSWIzzTDB7VlaV3P0ao1I=.7a74e563-d3ed-481c-8da4-5ae71e2a4e72@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <aVn2pxHeGB9WXRGBqXToicyv900mq_xfyDj2HHjv12Q=.33165c1e-1053-4a05-a54d-a51095d2ea73@github.com>
 <csbaOvyMeGK0-mJxDyJxhmdHa_HcocG7CQtw4XUtrfE=.35c9820d-964c-47e7-8cdb-db4e8f76d082@github.com>
 <R5kRXNkycQgBML5b608AqyFJnKtn4ncKHvJBPSRTuqY=.5d9c9ab6-382c-4a87-b7a1-8df7bfb9c2bc@github.com>
 <NMpSSPd-r--k7mTy64pp3v90_wVPT5-tBgRb09aerGI=.d7ed6c67-96b8-4ab1-9651-9f3fec43139d@github.com>
 <GumNspvDQjUjL6QiqPVddY5p6vn9aOpqPgq3uAw_rSo=.a5c33ff0-977b-4ec1-a245-c6a916fc0aa0@github.com>
 <lT4eXJDfZffgaSA1rd2h7HwywpQl0PkaqM-vrMoUWcs=.589a2a04-f5ab-42e3-878c-cc6612fc20d3@github.com>
 <qzGeCPVxgf_HOk-jGTJhflTSWIzzTDB7VlaV3P0ao1I=.7a74e563-d3ed-481c-8da4-5ae71e2a4e72@github.com>
Message-ID: <cdlHOWOVtmqy6BlkGdpXo4wtSgI2Y7J4tOUn3wbr42I=.d6e0151c-8ebe-4da9-bf66-d2eb7fbcc3c3@github.com>

On Mon, 15 Feb 2021 18:51:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > Hi Claes, This could be a run to run variation, in general we are now having fewer number of instructions (one shift operation saved per mask computation) compared to previous masked generation sequence and thus it will always offer better execution latencies.
>>> 
>>> Run-to-run variation would be easy to rule out by running more forks and more iterations to attain statistically significant results. While the instruction manuals suggest latency should be better for this instruction on all CPUs where it's supported, it would be good if there was some clear proof - such as a significant benchmark win - to motivate the added complexity.
>> 
>> BASELINE:
>> Result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong":
>>   61.037 ns/op
>> 
>> Secondary result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong:??perf":
>> Perf stats:
>> --------------------------------------------------
>> 
>>          19,739.21 msec task-clock                #    0.389 CPUs utilized          
>>                646      context-switches          #    0.033 K/sec                  
>>                 12      cpu-migrations            #    0.001 K/sec                  
>>                150      page-faults               #    0.008 K/sec                  
>>    74,59,83,59,139      cycles                    #    3.779 GHz                      (30.73%)
>>  1,78,78,79,19,117      instructions              #    2.40  insn per cycle           (38.48%)
>>    24,79,81,63,651      branches                  # 1256.289 M/sec                    (38.55%)
>>       32,24,89,924      branch-misses             #    1.30% of all branches          (38.62%)
>>    52,56,88,28,472      L1-dcache-loads           # 2663.167 M/sec                    (38.65%)
>>          39,00,969      L1-dcache-load-misses     #    0.01% of all L1-dcache hits    (38.57%)
>>           3,74,131      LLC-loads                 #    0.019 M/sec                    (30.77%)
>>             22,315      LLC-load-misses           #    5.96% of all LL-cache hits     (30.72%)
>>    <not supported>      L1-icache-loads                                             
>>          17,49,997      L1-icache-load-misses                                         (30.72%)
>>    52,91,41,70,636      dTLB-loads                # 2680.663 M/sec                    (30.69%)
>>              3,315      dTLB-load-misses          #    0.00% of all dTLB cache hits   (30.67%)
>>              4,674      iTLB-loads                #    0.237 K/sec                    (30.65%)
>>             33,746      iTLB-load-misses          #  721.99% of all iTLB cache hits   (30.63%)
>>    <not supported>      L1-dcache-prefetches                                        
>>    <not supported>      L1-dcache-prefetch-misses                                   
>> 
>>       50.723759146 seconds time elapsed
>> 
>>       51.447054000 seconds user
>>        0.189949000 seconds sys
>> 
>> 
>> WITH OPT:
>> Result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong":
>>   74.356 ns/op
>> 
>> Secondary result "org.openjdk.bench.java.lang.ArrayCopyUnalignedSrc.testLong:??perf":
>> Perf stats:
>> --------------------------------------------------
>> 
>>          19,741.09 msec task-clock                #    0.389 CPUs utilized          
>>                641      context-switches          #    0.032 K/sec                  
>>                 17      cpu-migrations            #    0.001 K/sec                  
>>                164      page-faults               #    0.008 K/sec                  
>>    74,40,40,48,513      cycles                    #    3.769 GHz                      (30.81%)
>>  1,45,66,22,06,797      instructions              #    1.96  insn per cycle           (38.56%)
>>    20,31,28,43,577      branches                  # 1028.963 M/sec                    (38.65%)
>>          14,11,419      branch-misses             #    0.01% of all branches          (38.69%)
>>    43,07,86,33,662      L1-dcache-loads           # 2182.182 M/sec                    (38.72%)
>>          37,06,744      L1-dcache-load-misses     #    0.01% of all L1-dcache hits    (38.56%)
>>           1,34,292      LLC-loads                 #    0.007 M/sec                    (30.72%)
>>             30,627      LLC-load-misses           #   22.81% of all LL-cache hits     (30.68%)
>>    <not supported>      L1-icache-loads                                             
>>          14,49,145      L1-icache-load-misses                                         (30.65%)
>>    43,44,86,27,516      dTLB-loads                # 2200.924 M/sec                    (30.63%)
>>                218      dTLB-load-misses          #    0.00% of all dTLB cache hits   (30.63%)
>>              2,445      iTLB-loads                #    0.124 K/sec                    (30.63%)
>>             28,624      iTLB-load-misses          # 1170.72% of all iTLB cache hits   (30.63%)
>>    <not supported>      L1-dcache-prefetches                                        
>>    <not supported>      L1-dcache-prefetch-misses                                   
>> 
>>       50.716083931 seconds time elapsed
>> 
>>       51.467300000 seconds user
>>        0.200390000 seconds sys
>> 
>> 
>> JMH perf data for ArrayCopyUnalignedSrc.testLong with copy length  of 1200 shows degradation in LID accesses, it seems the benchmask got displaced from its sweet spot.
>> 
>> But, there is a significant reduction in instruction count  and cycles are almost comparable.  We are saving one shift per mask computation.
>> 
>>           OLD Sequence:
>>               0x00007f7fc1030ead:   movabs $0x1,%rax
>>               0x00007f7fc1030eb7:   shlx   %r8,%rax,%rax
>>               0x00007f7fc1030ebc:   dec    %rax
>>               0x00007f7fc1030ebf:   kmovq  %rax,%k2
>>           NEW Sequence:
>>               0x00007f775d030d51:   movabs $0xffffffffffffffff,%rax
>>               0x00007f775d030d5b:   bzhi   %r8,%rax,%rax
>>               0x00007f775d030d60:   kmovq  %rax,%k2
>
> Further analysis of perf degradation revealed that with new optimized instruction pattern, code alignment got disturbed. This led to increase in LSD misses, also it reduced the UOPs cashing in DSB.  
> Aligning copy loops at 32 byte boundary prevents any adverse impact on UOP caching.
> NOPs used for padding add up to the instruction count and thus may over shadow the code size gains due to new mask generation sequence in copy stubs.  
> 
> Baseline:
>  ArrayCopyAligned.testLong   Length : 1200    61 ns/op (approx)
>  1,93,44,43,11,622      cycles                                                      
>  4,59,57,99,78,727      instructions              #    2.38  insn per cycle         
>  1,83,68,75,68,255      idq.dsb_uops                                                
>  2,08,32,43,71,906      lsd.uops                                                    
>    37,12,54,60,211      idq.mite_uops                                               
> 
> With Opt:
>  ArrayCopyAligned.testLong   Length : 1200   74 ns/op (approx)
>  1,93,51,25,94,766      cycles                                                      
>  3,75,11,57,91,917      instructions              #    1.94  insn per cycle         
>    48,67,58,25,566      idq.dsb_uops                                                
>       19,46,13,236      lsd.uops                                                    
>  2,87,42,95,74,280      idq.mite_uops                                               
> 
> With Opt + main loop alignment(nop):         61 ns/op (approx)
>  ArrayCopyAligned.testLong   Length : 1200 
>  1,93,52,15,90,080      cycles                                                      
>  4,60,89,14,06,528      instructions              #    2.38  insn per cycle         
>  1,78,76,10,34,991      idq.dsb_uops                                                
>  2,09,16,15,84,313      lsd.uops                                                    
>    46,25,31,92,101      idq.mite_uops            
> 
> 
> While computing the mask for partial in-lining of small copy calls ( currently enabled for sub-word types with copy length less than 32/64 bytes), new optimized sequence should always offer lower instruction count and latency path.
> 
> 
> Baseline:
> ArrayCopyAligned.testByte        Length : 20  avgt    2  2.635          ns/op
>  1,97,76,75,18,052      cycles                                                      
>  8,96,00,37,11,803      instructions              #    4.53  insn per cycle         
>     2,71,83,79,035      idq.dsb_uops                                                
>  7,54,82,43,63,409      lsd.uops                                                    
>     3,92,55,74,395      idq.mite_uops                                               
> 
> ArrayCopyAligned.testByte        Length : 31  avgt    2  2.635          ns/op
>  1,97,79,16,56,787      cycles                                                      
>  8,96,13,15,69,780      instructions              #    4.53  insn per cycle         
>     2,69,07,11,691      idq.dsb_uops                                                
>  7,54,95,63,77,683      lsd.uops                                                    
>     3,90,19,10,747      idq.mite_uops                                               
> 
> WithOpt:
> ArrayCopyAligned.testByte        Length : 20  avgt    2  2.635          ns/op
>  1,97,66,64,62,541      cycles                                                      
>  8,92,03,95,00,236      instructions              #    4.51  insn per cycle         
>     2,72,38,56,205      idq.dsb_uops                                                
>  7,50,87,50,60,591      lsd.uops                                                    
>     3,89,15,02,954      idq.mite_uops                                               
> 
> ArrayCopyAligned.testByte        Length : 31  avgt    2  2.635          ns/op
>  1,97,54,21,61,110      cycles                                                      
>  8,91,46,64,23,754      instructions              #    4.51  insn per cycle         
>     2,78,12,19,544      idq.dsb_uops                                                
>  7,50,35,88,95,843      lsd.uops                                                    
>     3,90,41,97,276      idq.mite_uops                               
>                 
> 
> Following are the links to updated JMH perf data:
> http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_BASELINE.txt
> http://cr.openjdk.java.net/~jbhateja/8261553/JMH_PERF_CLX_WITH_OPTS_LOOP_ALIGN.txt
> 
> In general gains are not significant in case of copy stubs, but new sequence offers a optimal latency path for mask computation sequence.

Thanks for getting to the bottom of that regression.

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From fweimer at openjdk.java.net  Tue Feb 16 17:10:44 2021
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Tue, 16 Feb 2021 17:10:44 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values
In-Reply-To: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
Message-ID: <w1gx_PICRcRP7-gFat6a6FRZn8RuOm-yCU2prrhvGJQ=.335f6451-f279-4efc-b8c4-9ad02cd47d25@github.com>

On Tue, 16 Feb 2021 16:13:48 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

> 8261671: X86 I2L conversion can be skipped for certain masked positive values
> 
> For the following expression:
>  (long)(value & mask)
> Where value is of int type and mask is constant (power of two ? 1), we can directly generate bzhi instruction to zero the upper bits instead of doing an andl, followed by movslq
> 
> Before:
> Benchmark Mode Cnt Score Error Units
> SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 10.679 ? 1.496 ns/op
> 
> 
> After:
> Benchmark Mode Cnt Score Error Units
> SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 7.870 ? 0.067 ns/op
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/cpu/x86/x86_64.ad line 9172:

> 9170: instruct convI2LAndI_reg_immIbitmask(rRegL dst, rRegI src, immI_bitmask mask, rRegI tmp, rFlagsReg cr)
> 9171: %{
> 9172:   predicate(VM_Version::supports_bmi2());

Agner's optimization guide says that BZHI uses microcode on Zen 2 and earlier, so perhaps the predicate should reflect that?

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

PR: https://git.openjdk.java.net/jdk/pull/2590

From github.com+168222+mgkwill at openjdk.java.net  Tue Feb 16 17:43:08 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 16 Feb 2021 17:43:08 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values [v2]
In-Reply-To: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
Message-ID: <2ATJREylgmEnepqmA5TyGCwHG926B_0bkZoNMkNuKqI=.d596fb17-06a0-4761-a4bb-c32dae085ae2@github.com>

> 8261671: X86 I2L conversion can be skipped for certain masked positive values
> 
> For the following expression:
>  (long)(value & mask)
> Where value is of int type and mask is constant (power of two ? 1), we can directly generate bzhi instruction to zero the upper bits instead of doing an andl, followed by movslq
> 
> Before:
> Benchmark Mode Cnt Score Error Units
> SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 10.679 ? 1.496 ns/op
> 
> 
> After:
> Benchmark Mode Cnt Score Error Units
> SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 7.870 ? 0.067 ns/op
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Update convI2LAndI_reg_immIbitmask w/ is_Intel
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2590/files
  - new: https://git.openjdk.java.net/jdk/pull/2590/files/28cbd6cb..5dc976e2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2590&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2590&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2590.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2590/head:pull/2590

PR: https://git.openjdk.java.net/jdk/pull/2590

From github.com+168222+mgkwill at openjdk.java.net  Tue Feb 16 17:43:09 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 16 Feb 2021 17:43:09 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values [v2]
In-Reply-To: <w1gx_PICRcRP7-gFat6a6FRZn8RuOm-yCU2prrhvGJQ=.335f6451-f279-4efc-b8c4-9ad02cd47d25@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
 <w1gx_PICRcRP7-gFat6a6FRZn8RuOm-yCU2prrhvGJQ=.335f6451-f279-4efc-b8c4-9ad02cd47d25@github.com>
Message-ID: <9XBe7BRG8tFJ3ZHqmLa-MjmZWrJS0nIGKJzsjViGVoI=.007b2404-c93f-408e-a28e-c5491eeceb4e@github.com>

On Tue, 16 Feb 2021 17:08:13 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update convI2LAndI_reg_immIbitmask w/ is_Intel
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> src/hotspot/cpu/x86/x86_64.ad line 9172:
> 
>> 9170: instruct convI2LAndI_reg_immIbitmask(rRegL dst, rRegI src, immI_bitmask mask, rRegI tmp, rFlagsReg cr)
>> 9171: %{
>> 9172:   predicate(VM_Version::supports_bmi2());
> 
> Agner's optimization guide says that BZHI uses microcode on Zen 2 and earlier, so perhaps the predicate should reflect that?

Added `predicate(VM_Version::supports_bmi2() && VM_Version::is_intel());`

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

PR: https://git.openjdk.java.net/jdk/pull/2590

From github.com+2249648+johntortugo at openjdk.java.net  Tue Feb 16 18:02:58 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Tue, 16 Feb 2021 18:02:58 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler [v4]
In-Reply-To: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
Message-ID: <bIJ5vF190xXJjMysHqAhOt_YedsLWwvuuDOdPXDG88Y=.622e77a6-79dc-4ebe-a961-a6e6b4afddec@github.com>

> Relates to: https://bugs.openjdk.java.net/browse/JDK-8241502
> Tested on: Linux tier1, 2 and 3
> 
> Can you please take a look whether these changes are going in the direction expected or not? If it is, I'll continue working on the `JDK-8241502` but I'd like to split it in a few PRs since it's a lot of changes.

John Tortugo has updated the pull request incrementally with one additional commit since the last revision:

  Some div and shift instructions.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2420/files
  - new: https://git.openjdk.java.net/jdk/pull/2420/files/1e8361cc..0e72dfe0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=02-03

  Stats: 419 lines in 3 files changed: 221 ins; 136 del; 62 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2420.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2420/head:pull/2420

PR: https://git.openjdk.java.net/jdk/pull/2420

From headius at headius.com  Tue Feb 16 18:48:11 2021
From: headius at headius.com (Charles Oliver Nutter)
Date: Tue, 16 Feb 2021 12:48:11 -0600
Subject: Intermittent JRuby json issue related to tiered or G1
Message-ID: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>

Hello again folks, we seem to have stumbled on an issue with either
tiered compilation or G1 or both.

https://github.com/jruby/jruby/issues/6554

We have been trying to track down a sporadic parse error in JRuby's
json library, and it now seems likely that it is an issue at the JVM
level. The issue above describes the problem that at least two of our
users have been seeing. The issue manifests as JRuby's json library
suddenly failing to parse code that worked earlier in the run.

The main user contributing details here, "Freaky", has been able to
confirm that either turning off tiered compilation or switching away
from G1 (to Parallel or Shenandoah) makes the problem go away, and has
provided a small reproduction:

https://github.com/Freaky/jruby-issue-6554

Freaky has also been trying to correlate JIT and GC logs to the time
of failure and has posted his findings on the JRuby issue above.
Freaky has been running the latest Java 15 to reproduce, but other
users are seeing the same issue on 11.

I wanted to get some feedback here before opening an issue, mostly
because it seems to require both tiered and G1 to trigger. Anyone have
some cycles to help us investigate?

- Charlie

From shade at redhat.com  Tue Feb 16 19:10:52 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Feb 2021 20:10:52 +0100
Subject: Intermittent JRuby json issue related to tiered or G1
In-Reply-To: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>
References: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>
Message-ID: <1bac4d6a-e53d-075d-0209-6b737b7a2e77@redhat.com>

On 2/16/21 7:48 PM, Charles Oliver Nutter wrote:
> I wanted to get some feedback here before opening an issue, mostly
> because it seems to require both tiered and G1 to trigger. Anyone have
> some cycles to help us investigate?

I am struggling to reproduce this, reproducer requires fiddling with the actual JRuby installation 
path, installing Bundler, installing gems, etc. It would help if you can provide the reproducer that 
one can able to run from a blank machine.

As usual, running with fastdebug builds is the first step here: maybe VM would assert meaningfully, 
and then you can search JIRA for the assert message. My own fastdebug builds are here: 
https://builds.shipilev.net/

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Feb 16 19:50:46 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Feb 2021 20:50:46 +0100
Subject: Intermittent JRuby json issue related to tiered or G1
In-Reply-To: <1bac4d6a-e53d-075d-0209-6b737b7a2e77@redhat.com>
References: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>
 <1bac4d6a-e53d-075d-0209-6b737b7a2e77@redhat.com>
Message-ID: <b7f97cdf-7111-0b5f-78e1-7f760b5d860b@redhat.com>

On 2/16/21 8:10 PM, Aleksey Shipilev wrote:
> As usual, running with fastdebug builds is the first step here: maybe VM would assert meaningfully,
> and then you can search JIRA for the assert message. My own fastdebug builds are here:
> https://builds.shipilev.net/

Look:

$ export JAVA_HOME=./jdk15-fastdebug/; export PATH=$JAVA_HOME/bin:$PATH
$ while true; do ~/Install/jruby-9.2.14.0/bin/jruby -J-Xmx512m ./test.rb; done
Warming up --------------------------------------
             JSON gem# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/ifnode.cpp:952
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error 
(/home/buildbot/worker/build-jdk15u-linux/build/src/hotspot/share/opto/ifnode.cpp:952), pid=3795216, 
tid=3795432
#  assert(this_bool->_test.is_less() && !fail->_con) failed: incorrect test
#
# JRE version: OpenJDK Runtime Environment (15.0.2) (fastdebug build 
15.0.2-testing+0-builds.shipilev.net-openjdk-jdk15-b50-20210206)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 
15.0.2-testing+0-builds.shipilev.net-openjdk-jdk15-b50-20210206, mixed mode, sharing, tiered, 
compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xbf59ce]  IfNode::fold_compares_helper(ProjNode*, ProjNode*, ProjNode*, 
PhaseIterGVN*)+0x66e
#
# Core dump will be written. Default location: Core dumps may be processed with 
"/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to 
/home/shade/temp/jruby/jruby-issue-6554/core.3795216)
#
# An error report file with more information is saved as:
# /home/shade/temp/jruby/jruby-issue-6554/hs_err_pid3795216.log
#
# Compiler replay data is saved as:
# /home/shade/temp/jruby/jruby-issue-6554/replay_pid3795216.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp

------

This reliably reproduces with latest JDK 15 binaries from here:
   https://builds.shipilev.net/openjdk-jdk15/

There is a single hit in JIRA, for the bug that was fixed in JDK 9.

But! Neither JDK 16 nor JDK 17 fastdebug assert, which gives us an opportunity to reverse-bisect 
which change had fixed it.

-- 
Thanks,
-Aleksey


From headius at headius.com  Tue Feb 16 20:00:51 2021
From: headius at headius.com (Charles Oliver Nutter)
Date: Tue, 16 Feb 2021 14:00:51 -0600
Subject: Intermittent JRuby json issue related to tiered or G1
In-Reply-To: <b7f97cdf-7111-0b5f-78e1-7f760b5d860b@redhat.com>
References: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>
 <1bac4d6a-e53d-075d-0209-6b737b7a2e77@redhat.com>
 <b7f97cdf-7111-0b5f-78e1-7f760b5d860b@redhat.com>
Message-ID: <CAE-f1xRvKHzHDZQL3Nez+807ND6E=Pt0xE1BLxDfnxo72vWRDA@mail.gmail.com>

On Tue, Feb 16, 2021 at 1:50 PM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 2/16/21 8:10 PM, Aleksey Shipilev wrote:
> > As usual, running with fastdebug builds is the first step here: maybe VM would assert meaningfully,
> > and then you can search JIRA for the assert message. My own fastdebug builds are here:
> > https://builds.shipilev.net/
>
> Look:
>
> $ export JAVA_HOME=./jdk15-fastdebug/; export PATH=$JAVA_HOME/bin:$PATH
> $ while true; do ~/Install/jruby-9.2.14.0/bin/jruby -J-Xmx512m ./test.rb; done
> Warming up --------------------------------------
>              JSON gem# To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/ifnode.cpp:952
> #
> # A fatal error has been detected by the Java Runtime Environment:

Thanks for digging into this Aleksey... I will try to remember to
throw a fastdebug build at these issues in the future. This one has
largely been driven by our users since up until last week we had no
way to reproduce.

Those users are also monitoring this thread.

I am a bit confused about your JDK9 reference. If it was fixed in 9
why does it reliably reproduce in 15? Perhaps I am misunderstanding
the lineage of the fix you are referring to.

- Charlie

From shade at redhat.com  Tue Feb 16 20:05:07 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Feb 2021 21:05:07 +0100
Subject: Intermittent JRuby json issue related to tiered or G1
In-Reply-To: <CAE-f1xRvKHzHDZQL3Nez+807ND6E=Pt0xE1BLxDfnxo72vWRDA@mail.gmail.com>
References: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>
 <1bac4d6a-e53d-075d-0209-6b737b7a2e77@redhat.com>
 <b7f97cdf-7111-0b5f-78e1-7f760b5d860b@redhat.com>
 <CAE-f1xRvKHzHDZQL3Nez+807ND6E=Pt0xE1BLxDfnxo72vWRDA@mail.gmail.com>
Message-ID: <ead14606-cdfe-27fc-4bac-a9c5b5219e44@redhat.com>

On 2/16/21 9:00 PM, Charles Oliver Nutter wrote:
> I am a bit confused about your JDK9 reference. If it was fixed in 9
> why does it reliably reproduce in 15? Perhaps I am misunderstanding
> the lineage of the fix you are referring to.

I am saying that there are no direct JIRA hits that could explain why this is happening. The only 
hit I got is for fix already in JDK 9, so it should not happen again.

I am (slowly) bisecting between JDK 15 and JDK 16 to see which fix directly or accidentally fixed 
it. Then we would know what we are dealing with.

-- 
Thanks,
-Aleksey


From xliu at openjdk.java.net  Tue Feb 16 20:59:41 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 16 Feb 2021 20:59:41 GMT
Subject: RFR: 8261731: shallow copy the internal buffer of a
 scalar-replaced java.lang.String object
In-Reply-To: <J428b0kfPbnDCzKiIX7-qDDXQ147AYWk_sJQmWLJuIo=.eedb676a-06d1-48a8-acd3-57f01f9ebd86@github.com>
References: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
 <J428b0kfPbnDCzKiIX7-qDDXQ147AYWk_sJQmWLJuIo=.eedb676a-06d1-48a8-acd3-57f01f9ebd86@github.com>
Message-ID: <l79YkCEGsxhNFa0vyR-K2n6-_M_ftqpzP6zYxoSr_-M=.e59bf74d-93af-4ce8-85bf-c2f0e376801d@github.com>

On Tue, 16 Feb 2021 08:14:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Hi,
> 
> this is a smart optimization.
> 
> > There are 3 nodes involving in the construction of a java.lang.String object.
> > ```
> > 1. Allocate of itself, aka. alloc
> > 
> > 2. AllocateArray of a byte array, which is value:byte[], aka. aa
> > 
> > 3. ArrayCopyNode which copys in the contents of value, aka. ac
> > ```
> > 
> > 
> > Lemma
> > When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.
> > Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.
> 
> Are you saying that the source of `ac` cannot be accessed by another thread because of the cloning in the constructor? But the resulting string instance which is used to construct the non-escape instance can be GlobalEscape and then the source of `ac` is accessible to other threads, isn't it?

Hi, @reinrich 
You might not know, but I learn how to reallocate an object in deoptimization from your previous patches. Thank you!

You are right. The source of ac (`src`) might be escaped.  I didn't say other threads can't access it. I said we need to guarantee the `src` is stable,  or  it's a "frozen" array in JDK-8261007. 

To be honest, I didn't check the src is frozen. In practice, I only see ArrayCopy in construction [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L769).This method is creating a new substring from an established array, so its value is `stable`. 

After I read your comment, I went through String.java. I do find one open-ended constructor. yes, it's a problem!
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L395

If the frozen attribute is not present, what I can come up with. an array is "stable". What's do you think?
1) has annotation "stable" or
2) it's non-escaped and
3) can't find any store nodes along its mem stream.

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

PR: https://git.openjdk.java.net/jdk/pull/2570

From neliasso at openjdk.java.net  Tue Feb 16 21:44:46 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 16 Feb 2021 21:44:46 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v2]
In-Reply-To: <7AXx69j_wscf8ENt98_apHTd1OKbeO80nNVpU68Z794=.7d776104-0f08-4e92-b229-bc210123fc4e@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <7AXx69j_wscf8ENt98_apHTd1OKbeO80nNVpU68Z794=.7d776104-0f08-4e92-b229-bc210123fc4e@github.com>
Message-ID: <8ShwNGfn1vuWGuS_kjH2zXFGyW3pObvxBZt3KivpwYU=.55fb12d3-10bf-41a6-88a4-2fa665c892ea@github.com>

On Thu, 11 Feb 2021 12:25:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> BMI2 BHZI instruction can be used to optimize the instruction sequence
>> used for mask generation at various place in array copy stubs and partial in-lining for small copy operations.
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261553: Adding BMI2 missing check for partial in-lining.

Looks good.

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

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2522

From kvn at openjdk.java.net  Tue Feb 16 22:10:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 16 Feb 2021 22:10:52 GMT
Subject: RFR: 8261235: C1 compilation fails with assert(res->vreg_number()
 == index) failed: conversion check [v2]
In-Reply-To: <ZAua39vvZ0Mn89VvYs5gZy5hDPlkqPMffV_7WKefXYM=.dab689d3-6e1a-46be-9c0c-971ac1d738ef@github.com>
References: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
 <ZAua39vvZ0Mn89VvYs5gZy5hDPlkqPMffV_7WKefXYM=.dab689d3-6e1a-46be-9c0c-971ac1d738ef@github.com>
Message-ID: <gpWrUr1Rbsfe9IZ3cwWonwtgbiawn43lteIgo4PBxqo=.a02d45e7-a64f-4467-b44e-d9814c0f5cfa@github.com>

On Tue, 16 Feb 2021 11:36:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The assertion is hit because we run out of virtual registers in the linear scan in C1 and do not handle it. I fixed it by applying the same bailout as in `LIRGenerator::new_register()`. 
>> 
>> There is also a second issue that `LIR_OprDesc::vreg_max` is too big. It is only used in this bailout code. `OprBits::vreg_max` is defined over `OprBits::data_bits` which uses `OprBits::non_data_bits`. But `OprBits::non_data_bits` does not consider `OprBits::pointer_bits` which results in a too large value for `LIR_OprDesc::vreg_max` and the assertion is hit because we don't bail out, yet. This needs to be fixed as well.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix order of non_data_bits

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2543

From vladimir.kozlov at oracle.com  Tue Feb 16 22:34:55 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 16 Feb 2021 14:34:55 -0800
Subject: [External] : Re: SuperWord loop optimization lost after method
 inlining
In-Reply-To: <CAOqmmc2mWWr2mWoitEz71xc1PZ53ZLhyDfRQ+TjxKRcuGcxNkg@mail.gmail.com>
References: <CAOqmmc0ue3bLMBgWLAvUOrHLe2iNtoSiBiq=+Beky-D=MkA+fw@mail.gmail.com>
 <b9184f85-c869-8088-a080-2d860dca5f9f@oracle.com>
 <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
 <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>
 <CAOqmmc2mWWr2mWoitEz71xc1PZ53ZLhyDfRQ+TjxKRcuGcxNkg@mail.gmail.com>
Message-ID: <08ce2121-bbb4-3ea5-8f05-efeb33df7b74@oracle.com>

Hi Nicolas,

The file you shared has only assembler code. Yes, it shows that when ArrayFloatToArrayFloatVectorBinding::plus() is 
inlined into AVector::plus() it is not vectorized.

But I asked for an other file (hotspot_pid<PID>.log) which is generated when you run app with 
-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation flags. It should start with:

<?xml version='1.0' encoding='UTF-8'?>
<hotspot_log version='160 1' process='2302014' time_ms='1613514688748'>
<vm_version>
<name>
Java HotSpot(TM) 64-Bit Server VM
</name>
<release>
11.0.9+7-LTS
</release>

Thanks,
Vladimir K

On 2/15/21 5:19 AM, Nicolas Heutte wrote:
> Hi Vladimir,
> 
> I've tried disabling tiered compilation, as you requested. It seems that the inlining was performed slightly 
> differently, but the issue remains. As you can see in this excerpt, the main loop isn't properly vectorized:
> 
>  ? 0x00000254b0d4bf54: cmp ? ?%r11d,%r8d
>  ? 0x00000254b0d4bf57: jae ? ?0x00000254b0d4c19e
>  ? 0x00000254b0d4bf5d: vmovss 0x10(%rcx,%r8,4),%xmm9 ?;*faload {reexecute=0 rethrow=0 return_oop=0}
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - 
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54 (line 41)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - 
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)
> 
>  ? 0x00000254b0d4bf64: cmp ? ?%ebx,%r8d
>  ? 0x00000254b0d4bf67: jae ? ?0x00000254b0d4c1ec
>  ? 0x00000254b0d4bf6d: vaddss 0x10(%rdi,%r8,4),%xmm9,%xmm9
>  ? 0x00000254b0d4bf74: vmovss %xmm9,0x10(%rcx,%r8,4) ?;*fastore {reexecute=0 rethrow=0 return_oop=0}
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - 
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61 (line 41)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - 
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)
> 
>  ? 0x00000254b0d4bf7b: inc ? ?%r8d ? ? ? ? ? ? ? ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - 
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62 (line 40)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - 
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)
> 
>  ? 0x00000254b0d4bf7e: cmp ? ?%r9d,%r8d
>  ? 0x00000254b0d4bf81: jl ? ? 0x00000254b0d4bf54 ?;*goto {reexecute=0 rethrow=0 return_oop=0}
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - 
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65 (line 40)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - 
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)
> 
> 
> 
> Here is the link to the full log, should you want to take a look at it: 
> https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing 
> <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$>
> 
> Best regards,
> Nicolas Heutte
> 
> On Thu, Feb 11, 2021 at 7:05 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>     Changing wide mailing list to JIT compiler only.
> 
>     This deoptimization is normal in Tiered Compilation - it switched from profiling code (level='3') generated by C1
>     compiler to new code generated by C2 (level='4') which does loop optimizations.
> 
>     Thank you for posting inlining information:
> 
>      ? ? ?@ 17? ?com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69 bytes) inline (hot)
>      ? ? ? ? \-> TypeProfile (14054/14054 counts) = com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
> 
>     I thought before that may be call site is not hot but it is not the case.
> 
>     You can do an other experiment to collect log with disabled Tiered Compilation (only C2 is used): -XX:-TieredCompilation
>     Also print assembler code (as you did before) for final compilation to see if loop is still not vectorized.
> 
>     Is it possible to post log file (on GitHub?) for me to look?
> 
>     Thanks,
>     Vladimir K
> 
>     On 2/11/21 6:28 AM, Nicolas Heutte wrote:
>      > Hi?Vladimir,
>      >
>      > Thank you for your help.
>      >
>      > I'm currently running Java 11.0.9, and I did not use any VM flag of note.
>      >
>      > I checked the content of the compilation log, and it seems that ArrayFloatToArrayFloatVectorBinding::plus() was
>      > deoptimized in order to allow AVector::plus() to be compiled:
>      >
>      > <writer thread='11576'/>
>      > <task_queued compile_id='17280' method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V' bytes='23'
>      > count='916' iicount='916' level='3' stamp='7394.056' comment='tiered' hot_count='896'/>
>      > <writer thread='15784'/>
>      > <deoptimized thread='15784' reason='constraint' pc='0x00000296d0785b94' compile_id='17257' compiler='c1' level='3'>
>      > <jvms bci='65' method='com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding plus
>      > (Lcom/qfs/vector/IVector;Lcom/qfs/vector/IVector;)V' bytes='69' count='909' backedge_count='155602' iicount='910'/>
>      > </deoptimized>
>      >
>      > The last compilation entry for AVector::plus() is:
>      >
>      > <writer thread='16380'/>
>      > <nmethod compile_id='17317' compiler='c2' level='4' entry='0x00000296d6af32c0' size='1960'
>     address='0x00000296d6af3110'
>      > relocation_offset='376' insts_offset='432' stub_offset='1040' scopes_data_offset='1152' scopes_pcs_offset='1592'
>      > dependencies_offset='1880' nul_chk_table_offset='1896' oops_offset='1064' metadata_offset='1072'
>      > method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V' bytes='23' count='172425' iicount='172425'
>      > stamp='7394.199'/>
>      > <make_not_entrant thread='16380' compile_id='17280' compiler='c1' level='2' stamp='7394.199'/>
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 1 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes) ? inline
>     (hot)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14552/14552 counts) = com/qfs/vector/array/impl/ArrayFloatVector
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 7 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes) ? inline
>     (hot)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14150/14150 counts) = com/qfs/vector/array/impl/ArrayFloatVector
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 10 ? com.qfs.vector.binding.impl.VectorBindings::getBinding (9 bytes) ? inline (hot)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 5  
>     com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::getBinding (22
>      > bytes) ? inline (hot)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 3  
>     com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::hasBinding
>      > (34 bytes) ? inline (hot)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 17 ? com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
>     bytes)
>      > inline (hot)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14054/14054 counts) =
>      > com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 12 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes) ? inline (hot)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 22 ? com.qfs.vector.impl.AVector::checkIndex (37 bytes) ? inline (hot)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 6 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes) ? inline (hot)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 27 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)  
>     accessor
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 34 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)  
>     accessor
>      > <writer thread='15896'/>
>      >
>      > Unfortunately, I do not have access to a debug VM build, so I cannot run the second test you recommend.
>      >
>      > Best regards,
>      > Nicolas Heutte
>      >
>      > On Wed, Feb 10, 2021 at 7:36 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
>     <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>> wrote:
>      >
>      >? ? ?Hi, Nicolas
>      >
>      >? ? ?Looks like, when inlined, the loop from ArrayFloatToArrayFloatVectorBinding::plus() was not optimized at all:
>     it is not
>      >? ? ?unrolled and has range checks. Such loops are not vectorized (you need unrolling and no checks).
>      >
>      >? ? ?What Java version you are running? What HotSpot VM flags you are using when running application?
>      >
>      >? ? ?Run application with -XX:+LogCompilation and look on compilation data in hotspot_pid<PID>.log file for caller
>      >? ? ?AVector::plus().
>      >
>      >? ? ?VM also has several flags to trace loop optimizations but they are only available in debug VM build. If you
>     have access
>      >? ? ?to such build run with -XX:+PrintCompilation -XX:+TraceLoopOpts flags.
>      >
>      >? ? ?Thanks,
>      >? ? ?Vladimir K
>      >
>      >? ? ?On 2/10/21 9:24 AM, Nicolas Heutte wrote:
>      >? ? ? > Hi all,
>      >? ? ? >
>      >? ? ? > I am encountering a performance issue caused by the interaction between
>      >? ? ? > method inlining and automatic vectorization.
>      >? ? ? >
>      >? ? ? > Our application aggregates arrays intensively using a method named
>      >? ? ? > ArrayFloatToArrayFloatVectorBinding.plus() with the following code:
>      >? ? ? >
>      >? ? ? >? ? ? for (int i = 0; i < srcLen; ++i) {
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? dstArray[i] += srcArray[i];
>      >? ? ? >
>      >? ? ? >? ? ? }
>      >? ? ? >
>      >? ? ? > When we microbenchmark this method we observe fast performance close to the
>      >? ? ? > practical memory bandwidth and when we print the assembly code we observe
>      >? ? ? > loop unrolling and automatic vectorization with SIMD instructions.
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600abf0: vmovdqu 0x10(%r14,%r13,4),%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600abf7: vaddps 0x10(%rcx,%r13,4),%ymm0,%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600abfe: vmovdqu %ymm0,0x10(%r14,%r13,4)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac05: movslq %r13d,%r11
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac08: vmovdqu 0x30(%r14,%r11,4),%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac0f: vaddps 0x30(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac16: vmovdqu %ymm0,0x30(%r14,%r11,4)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac1d: vmovdqu 0x50(%r14,%r11,4),%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac24: vaddps 0x50(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac2b: vmovdqu %ymm0,0x50(%r14,%r11,4)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac32: vmovdqu 0x70(%r14,%r11,4),%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac39: vaddps 0x70(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac40: vmovdqu %ymm0,0x70(%r14,%r11,4)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac47: vmovdqu 0x90(%r14,%r11,4),%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac51: vaddps 0x90(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac5b: vmovdqu %ymm0,0x90(%r14,%r11,4)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac65: vmovdqu 0xb0(%r14,%r11,4),%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac6f: vaddps 0xb0(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac79: vmovdqu %ymm0,0xb0(%r14,%r11,4)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac83: vmovdqu 0xd0(%r14,%r11,4),%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac8d: vaddps 0xd0(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600ac97: vmovdqu %ymm0,0xd0(%r14,%r11,4)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600aca1: vmovdqu 0xf0(%r14,%r11,4),%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600acab: vaddps 0xf0(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600acb5: vmovdqu %ymm0,0xf0(%r14,%r11,4)? ;*fastore
>      >? ? ? > {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>      >? ? ? > (line 41)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600acbf: add? ? $0x40,%r13d? ? ? ? ;*iinc {reexecute=0
>      >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>      >? ? ? > (line 40)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600acc3: cmp? ? %eax,%r13d
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef4600acc6: jl? ? ?0x000001ef4600abf0? ;*goto {reexecute=0
>      >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>      >? ? ? > (line 40)
>      >? ? ? >
>      >? ? ? >
>      >? ? ? >
>      >? ? ? > In the real application, this method is actually inlined in a higher level
>      >? ? ? > method named AVector.plus(). Unfortunately, the inlined version of the
>      >? ? ? > aggregation code is not vectorized anymore:
>      >? ? ? >
>      >? ? ? >
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180a0: cmp? ? %ebx,%r11d
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180a3: jae? ? 0x000001ef460180e6
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180a5: vmovss 0x10(%r8,%r11,4),%xmm1? ;*faload {reexecute=0
>      >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
>      >? ? ? > (line 41)
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180ac: cmp? ? %ecx,%r11d
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180af: jae? ? 0x000001ef46018104
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180b1: vaddss 0x10(%r9,%r11,4),%xmm1,%xmm1
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180b8: vmovss %xmm1,0x10(%r8,%r11,4)? ;*fastore {reexecute=0
>      >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>      >? ? ? > (line 41)
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180bf: inc? ? %r11d? ? ? ? ? ? ? ;*iinc {reexecute=0
>      >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>      >? ? ? > (line 40)
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180c2: cmp? ? %r10d,%r11d
>      >? ? ? >
>      >? ? ? >? ? 0x000001ef460180c5: jl? ? ?0x000001ef460180a0? ;*goto {reexecute=0
>      >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>      >? ? ? > (line 40)
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >
>      >? ? ? >
>      >? ? ? >
>      >? ? ? > This causes a significant performance drop, compared to a run where we
>      >? ? ? > explicitly disable the inlining and observe automatically vectorized code
>      >? ? ? > again (
>      >? ? ? > -XX:CompileCommand=dontinline,com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding.plus
>      >? ? ? > ).
>      >? ? ? >
>      >? ? ? >
>      >? ? ? > How do you guys explain that behavior of the JIT compiler? Is this a known
>      >? ? ? > and tracked issue, could it be fixed in the JVM? Can we do something in the
>      >? ? ? > java code to prevent this from happening?
>      >? ? ? >
>      >? ? ? >
>      >? ? ? > Best regards,
>      >? ? ? >
>      >? ? ? > Nicolas Heutte
>      >? ? ? >
>      >
> 

From kvn at openjdk.java.net  Tue Feb 16 22:42:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 16 Feb 2021 22:42:39 GMT
Subject: RFR: 8261675: ObjectValue::set_visited(bool) sets _visited false
 [v2]
In-Reply-To: <dQRUVec71t9NINICOM5SoZBL56ifvgJ0FnXLPYHpP3M=.4cc6ac86-5f49-41ab-8b73-6c18994de430@github.com>
References: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
 <dQRUVec71t9NINICOM5SoZBL56ifvgJ0FnXLPYHpP3M=.4cc6ac86-5f49-41ab-8b73-6c18994de430@github.com>
Message-ID: <XcWd5FasoBi0C09DETEGKeWuzHEl9t9hnDLimU7Xu9k=.eaadb04f-76e5-4064-a190-a3322c5b878c@github.com>

On Sat, 13 Feb 2021 21:46:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The setter is error-prone. it unconditionally sets _visited false.
>> this patch stores the argument to it.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261675: ObjectValue::set_visited(bool) sets _visited false
>   
>   use getter and setter of _visited.
>   update the year of copyright.

I am fine with your current change (getter and setter). Let push it.
And I will work on suggested optimization/clean in separate RFE (change will need comments to avoid confusion, as you have).

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2560

From sdlin at google.com  Tue Feb 16 22:51:47 2021
From: sdlin at google.com (Spencer Lin)
Date: Tue, 16 Feb 2021 14:51:47 -0800
Subject: Intermittent JRuby json issue related to tiered or G1
Message-ID: <CAC4UBj0KePv_tq0gLhY9YJsCeNg-Ka-eMTt-nF9BUUAboRZhGQ@mail.gmail.com>

Hi Aleksey,

What was the JDK9 issue you were referring to?

Thanks,
Spencer

From xliu at openjdk.java.net  Tue Feb 16 23:58:50 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 16 Feb 2021 23:58:50 GMT
Subject: RFR: 8261675: ObjectValue::set_visited(bool) sets _visited false
 [v2]
In-Reply-To: <XcWd5FasoBi0C09DETEGKeWuzHEl9t9hnDLimU7Xu9k=.eaadb04f-76e5-4064-a190-a3322c5b878c@github.com>
References: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
 <dQRUVec71t9NINICOM5SoZBL56ifvgJ0FnXLPYHpP3M=.4cc6ac86-5f49-41ab-8b73-6c18994de430@github.com>
 <XcWd5FasoBi0C09DETEGKeWuzHEl9t9hnDLimU7Xu9k=.eaadb04f-76e5-4064-a190-a3322c5b878c@github.com>
Message-ID: <hA9d_40-SqNxYa52wELzjX03lVfO6_eNUS9FRBELeWs=.c24bd191-ad24-44a7-ae67-71eb9a55bd63@github.com>

On Tue, 16 Feb 2021 22:40:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261675: ObjectValue::set_visited(bool) sets _visited false
>>   
>>   use getter and setter of _visited.
>>   update the year of copyright.
>
> I am fine with your current change (getter and setter). Let push it.
> And I will work on suggested optimization/clean in separate RFE (change will need comments to avoid confusion, as you have).

Hi, Vladimir, 


> I am fine with your current change (getter and setter). Let push it.
> And I will work on suggested optimization/clean in separate RFE (change will need comments to avoid confusion, as you have).

Sounds good. Thank you for sponsoring it.

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

PR: https://git.openjdk.java.net/jdk/pull/2560

From kvn at openjdk.java.net  Wed Feb 17 00:27:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 17 Feb 2021 00:27:51 GMT
Subject: RFR: 8261675: ObjectValue::set_visited(bool) sets _visited false
 [v2]
In-Reply-To: <hA9d_40-SqNxYa52wELzjX03lVfO6_eNUS9FRBELeWs=.c24bd191-ad24-44a7-ae67-71eb9a55bd63@github.com>
References: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
 <dQRUVec71t9NINICOM5SoZBL56ifvgJ0FnXLPYHpP3M=.4cc6ac86-5f49-41ab-8b73-6c18994de430@github.com>
 <XcWd5FasoBi0C09DETEGKeWuzHEl9t9hnDLimU7Xu9k=.eaadb04f-76e5-4064-a190-a3322c5b878c@github.com>
 <hA9d_40-SqNxYa52wELzjX03lVfO6_eNUS9FRBELeWs=.c24bd191-ad24-44a7-ae67-71eb9a55bd63@github.com>
Message-ID: <bN-HYh-iAo7QCEvGWQcEIpK2uvDcF5H_-FcSYtpb2GM=.7164e6cc-d8f8-49f3-a674-774d1db77a6e@github.com>

On Tue, 16 Feb 2021 23:56:18 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> I am fine with your current change (getter and setter). Let push it.
>> And I will work on suggested optimization/clean in separate RFE (change will need comments to avoid confusion, as you have).
>
> Hi, Vladimir, 
> 
> 
>> I am fine with your current change (getter and setter). Let push it.
>> And I will work on suggested optimization/clean in separate RFE (change will need comments to avoid confusion, as you have).
> 
> Sounds good. Thank you for sponsoring it.

Note, I think it is trivial change and one review is enough.

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

PR: https://git.openjdk.java.net/jdk/pull/2560

From xliu at openjdk.java.net  Wed Feb 17 00:27:52 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 17 Feb 2021 00:27:52 GMT
Subject: Integrated: 8261675: ObjectValue::set_visited(bool) sets _visited
 false
In-Reply-To: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
References: <3qsdFKCRBP1rIh_Q_9JUQzd-LP43WZchNrFxajKp1lY=.eb22d8dd-dd57-4108-8e64-a7bedace6c99@github.com>
Message-ID: <DppWLsFuugxE4HWxAYoPNLNg8rAbNV3wQ0ZJvron9eQ=.5b600569-4845-4c19-b87a-8102e8e82d58@github.com>

On Sat, 13 Feb 2021 01:51:39 GMT, Xin Liu <xliu at openjdk.org> wrote:

> The setter is error-prone. it unconditionally sets _visited false.
> this patch stores the argument to it.

This pull request has now been integrated.

Changeset: 2677f6f4
Author:    Xin Liu <xliu at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2677f6f4
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8261675: ObjectValue::set_visited(bool) sets _visited false

Reviewed-by: kvn

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

PR: https://git.openjdk.java.net/jdk/pull/2560

From github.com+2249648+johntortugo at openjdk.java.net  Wed Feb 17 04:10:58 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Wed, 17 Feb 2021 04:10:58 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler [v5]
In-Reply-To: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
Message-ID: <IOHdA_dZBHrpsMKtoTY2ruKnRZsnFiRPHpMrBeN_PJg=.c28d66dc-4eb4-4bfb-a349-1fb4a88eb715@github.com>

> Relates to: https://bugs.openjdk.java.net/browse/JDK-8241502
> Tested on: Linux tier1, 2 and 3
> 
> Can you please take a look whether these changes are going in the direction expected or not? If it is, I'll continue working on the `JDK-8241502` but I'd like to split it in a few PRs since it's a lot of changes.

John Tortugo has updated the pull request incrementally with one additional commit since the last revision:

  More shifts; logic operations and movs.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2420/files
  - new: https://git.openjdk.java.net/jdk/pull/2420/files/0e72dfe0..b776b9f6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=03-04

  Stats: 117 lines in 3 files changed: 68 ins; 7 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2420.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2420/head:pull/2420

PR: https://git.openjdk.java.net/jdk/pull/2420

From fweimer at openjdk.java.net  Wed Feb 17 05:58:39 2021
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Wed, 17 Feb 2021 05:58:39 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values [v2]
In-Reply-To: <9XBe7BRG8tFJ3ZHqmLa-MjmZWrJS0nIGKJzsjViGVoI=.007b2404-c93f-408e-a28e-c5491eeceb4e@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
 <w1gx_PICRcRP7-gFat6a6FRZn8RuOm-yCU2prrhvGJQ=.335f6451-f279-4efc-b8c4-9ad02cd47d25@github.com>
 <9XBe7BRG8tFJ3ZHqmLa-MjmZWrJS0nIGKJzsjViGVoI=.007b2404-c93f-408e-a28e-c5491eeceb4e@github.com>
Message-ID: <oJiYz28iTQ_JktfAFJ5Nch_tpnAglj0_cQacicHviMA=.c3cfebbe-1b11-4c7f-925e-9133e7df1cfe@github.com>

On Tue, 16 Feb 2021 17:39:34 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 9172:
>> 
>>> 9170: instruct convI2LAndI_reg_immIbitmask(rRegL dst, rRegI src, immI_bitmask mask, rRegI tmp, rFlagsReg cr)
>>> 9171: %{
>>> 9172:   predicate(VM_Version::supports_bmi2());
>> 
>> Agner's optimization guide says that BZHI uses microcode on Zen 2 and earlier, so perhaps the predicate should reflect that?
>
> Added `predicate(VM_Version::supports_bmi2() && VM_Version::is_intel());`

I'm so sorry, I confused this with `PDEP` and `PEXT`. `BZHI` is actually fine on Zen. So the original code is correct.

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

PR: https://git.openjdk.java.net/jdk/pull/2590

From jbhateja at openjdk.java.net  Wed Feb 17 08:31:39 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 17 Feb 2021 08:31:39 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v2]
In-Reply-To: <8ShwNGfn1vuWGuS_kjH2zXFGyW3pObvxBZt3KivpwYU=.55fb12d3-10bf-41a6-88a4-2fa665c892ea@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <7AXx69j_wscf8ENt98_apHTd1OKbeO80nNVpU68Z794=.7d776104-0f08-4e92-b229-bc210123fc4e@github.com>
 <8ShwNGfn1vuWGuS_kjH2zXFGyW3pObvxBZt3KivpwYU=.55fb12d3-10bf-41a6-88a4-2fa665c892ea@github.com>
Message-ID: <DqOfrXHE72qtwz_-IlQsA6XKxBd7hxR5LU_kOe4HBxE=.dcd31764-386b-4380-93f4-7611698283bd@github.com>

On Tue, 16 Feb 2021 21:40:58 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261553: Adding BMI2 missing check for partial in-lining.
>
> Looks good.

> Thanks for getting to the bottom of that regression.

Thanks, since there is not a significant impact on performance, but having an optimum instruction sequence will still reduce the complexity. Should it be ok to check this in ?  We have one reviewer consent.

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From chagedorn at openjdk.java.net  Wed Feb 17 09:03:40 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 17 Feb 2021 09:03:40 GMT
Subject: RFR: 8261235: C1 compilation fails with assert(res->vreg_number()
 == index) failed: conversion check [v2]
In-Reply-To: <gpWrUr1Rbsfe9IZ3cwWonwtgbiawn43lteIgo4PBxqo=.a02d45e7-a64f-4467-b44e-d9814c0f5cfa@github.com>
References: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
 <ZAua39vvZ0Mn89VvYs5gZy5hDPlkqPMffV_7WKefXYM=.dab689d3-6e1a-46be-9c0c-971ac1d738ef@github.com>
 <gpWrUr1Rbsfe9IZ3cwWonwtgbiawn43lteIgo4PBxqo=.a02d45e7-a64f-4467-b44e-d9814c0f5cfa@github.com>
Message-ID: <HI7NOQY8V4pH80k49ktmO__PcqPXIqOs_eFu1SzKvTs=.20277472-118f-4e86-88a6-2339ed33c941@github.com>

On Tue, 16 Feb 2021 22:08:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix order of non_data_bits
>
> Good.

Thanks Vladimir for your review!

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

PR: https://git.openjdk.java.net/jdk/pull/2543

From chagedorn at openjdk.java.net  Wed Feb 17 09:03:43 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 17 Feb 2021 09:03:43 GMT
Subject: Integrated: 8261235: C1 compilation fails with
 assert(res->vreg_number() == index) failed: conversion check
In-Reply-To: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
References: <-uBsLA86fiUezxtSxF_GW9oT62EezgztzXPwSta8EAw=.cb63031d-3ab4-468c-9351-1f1e10c377a9@github.com>
Message-ID: <_SpE5MrexsYFrtkHPSClQSROJMMbuXi-NHhZVzuVrKQ=.17cfcad9-10ad-45eb-b694-5a1374e7bae8@github.com>

On Fri, 12 Feb 2021 10:03:25 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The assertion is hit because we run out of virtual registers in the linear scan in C1 and do not handle it. I fixed it by applying the same bailout as in `LIRGenerator::new_register()`. 
> 
> There is also a second issue that `LIR_OprDesc::vreg_max` is too big. It is only used in this bailout code. `OprBits::vreg_max` is defined over `OprBits::data_bits` which uses `OprBits::non_data_bits`. But `OprBits::non_data_bits` does not consider `OprBits::pointer_bits` which results in a too large value for `LIR_OprDesc::vreg_max` and the assertion is hit because we don't bail out, yet. This needs to be fixed as well.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 84182855
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/84182855
Stats:     4152 lines in 6 files changed: 4137 ins; 2 del; 13 mod

8261235: C1 compilation fails with assert(res->vreg_number() == index) failed: conversion check

Reviewed-by: thartmann, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/2543

From rrich at openjdk.java.net  Wed Feb 17 09:03:38 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 17 Feb 2021 09:03:38 GMT
Subject: RFR: 8261731: shallow copy the internal buffer of a
 scalar-replaced java.lang.String object
In-Reply-To: <l79YkCEGsxhNFa0vyR-K2n6-_M_ftqpzP6zYxoSr_-M=.e59bf74d-93af-4ce8-85bf-c2f0e376801d@github.com>
References: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
 <J428b0kfPbnDCzKiIX7-qDDXQ147AYWk_sJQmWLJuIo=.eedb676a-06d1-48a8-acd3-57f01f9ebd86@github.com>
 <l79YkCEGsxhNFa0vyR-K2n6-_M_ftqpzP6zYxoSr_-M=.e59bf74d-93af-4ce8-85bf-c2f0e376801d@github.com>
Message-ID: <xWO8n5S298BWeViO7Bx5NQwEdN7IFnZb_lGTqD7js3k=.f9f2aceb-4716-482e-8fdf-65e52b034f22@github.com>

On Tue, 16 Feb 2021 20:56:32 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Hi,
>> 
>> this is a smart optimization.
>> 
>>> 
>>> 
>>> There are 3 nodes involving in the construction of a java.lang.String object.
>>> 
>>>     1. Allocate of itself, aka. alloc
>>> 
>>>     2. AllocateArray of a byte array, which is value:byte[], aka. aa
>>> 
>>>     3. ArrayCopyNode which copys in the contents of value, aka. ac
>>> 
>>> 
>>> Lemma
>>> When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.
>>> 
>>> Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.
>> 
>> Are you saying that the source of `ac` cannot be accessed by another thread because of the cloning in the constructor? But the resulting string instance which is used to construct the non-escape instance can be GlobalEscape and then the source of `ac` is accessible to other threads, isn't it?
>
>> Hi,
>> 
>> this is a smart optimization.
>> 
>> > There are 3 nodes involving in the construction of a java.lang.String object.
>> > ```
>> > 1. Allocate of itself, aka. alloc
>> > 
>> > 2. AllocateArray of a byte array, which is value:byte[], aka. aa
>> > 
>> > 3. ArrayCopyNode which copys in the contents of value, aka. ac
>> > ```
>> > 
>> > 
>> > Lemma
>> > When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.
>> > Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.
>> 
>> Are you saying that the source of `ac` cannot be accessed by another thread because of the cloning in the constructor? But the resulting string instance which is used to construct the non-escape instance can be GlobalEscape and then the source of `ac` is accessible to other threads, isn't it?
> 
> Hi, @reinrich 
> You might not know, but I learn how to reallocate an object in deoptimization from your previous patches. Thank you!
> 
> You are right. The source of ac (`src`) might be escaped.  I didn't say other threads can't access it. I said we need to guarantee the `src` is stable,  or  it's a "frozen" array in JDK-8261007. 
> 
> To be honest, I didn't check the src is frozen. In practice, I only see ArrayCopy in construction [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L769).This method is creating a new substring from an established array, so its value is `stable`. 
> 
> After I read your comment, I went through String.java. I do find one open-ended constructor. yes, it's a problem!
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L395
> 
> If the frozen attribute is not present, what I can come up with. an array is "stable". What's do you think?
> 1) has annotation "stable" or
> 2) it's non-escaped and
> 3) can't find any store nodes along its mem stream.

Hi @navyxliu,

> You might not know, but I learn how to reallocate an object in deoptimization from your previous patches. Thank you!

Oh, great! :)

> You are right. The source of ac (`src`) might be escaped. I didn't say other threads can't access it. I said we need to guarantee the `src` is stable, or it's a "frozen" array in JDK-8261007.
> 
> To be honest, I didn't check the src is frozen. In practice, I only see ArrayCopy in construction [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L769).This method is creating a new substring from an established array, so its value is `stable`.

Sorry, I wasn't aware of the @Stable annotation on the value array.

https://github.com/openjdk/jdk/blob/d19503353e5c347ce393544a3a30d5caec53d133/src/java.base/share/classes/java/lang/String.java#L154

So my concern was that another thread could for example use reflection to modify
the value array but I reckon this is illegal then (I wonder if it is checked in
reflection...).

Also there is already UseStringDeduplication that relies on the value array being stable.

> After I read your comment, I went through String.java. I do find one open-ended constructor. yes, it's a problem!
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L395

I see this one is deprecated. Why do you think there's a problem?

> If the frozen attribute is not present, what I can come up with. an array is "stable". What's do you think?
> 
>     1. has annotation "stable" or
> 
>     2. it's non-escaped and
> 
>     3. can't find any store nodes along its mem stream.

Currently I'd think this is not necessary. `@Stable` is strong enough.

The optimization reminds me a bit of earlier Java versions where String
instances had an offset field and the value array could be shared among String
instances.

I guess the new String needs to be scalarized mostly because you cannot take
care of the offset otherwise.

Coincidentally I'm currently looking at
[LoadNode::can_see_arraycopy_value()](https://github.com/openjdk/jdk/blob/b955f85e03bafe8ce39677d0af06bf1ceb7e2cbb/src/hotspot/share/opto/memnode.cpp#L951)
which does something similar you want to do. There I don't see any concerns
about the src being stable. In fact I don't think this is correct. Just a side
mark...

These are my (somewhat random) thoughts so far. I'd think it is a legal and useful optimization (though haven't yet looked at the code yet).

Thanks, Richard.

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

PR: https://git.openjdk.java.net/jdk/pull/2570

From dlong at openjdk.java.net  Wed Feb 17 09:49:41 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 17 Feb 2021 09:49:41 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler
In-Reply-To: <EWOKWpa98hBLypluJEurop0QC8n-mjDhklaW0cMgh0k=.2ed3d200-a559-47d2-abda-e711898f3fd2@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <vP-nQAbUU0P54kYGCK8R2cc_OBIRCk0P3TX_mgM4th8=.5cdfad98-051b-489c-9546-8f967ce2c720@github.com>
 <0azhJ4pD5Tq_lkpPtYMpQBjokflcSQEdWP2Rz9HBm6k=.c3ece6fd-1ae7-49ea-a6eb-ec88a9fbd54d@github.com>
 <d40n9RxaYEqp-6UU7qDQ9rJYrSZ0gXKTT9jqTlylfvU=.8fbcfe20-5f2e-48e8-a189-771701645d9b@github.com>
 <ZFXn-510nHc4-xULSEQooZYTQ2Uou6FM58KtImAUSsQ=.bf925331-cef6-4708-b49d-754df02fe8e1@github.com>
 <EWOKWpa98hBLypluJEurop0QC8n-mjDhklaW0cMgh0k=.2ed3d200-a559-47d2-abda-e711898f3fd2@github.com>
Message-ID: <tkbrhYmDEyHlWeaFc4NOfOsw4Q2Fbtrb-8BJ5U-sE6Y=.3b3ad8d6-75cd-4f92-a7b3-775385f40e3a@github.com>

On Thu, 11 Feb 2021 05:12:55 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

>> I wish there was a way for the old and new versions to co-exist at the same time, so we could generate the code the old way and and the new way, then compare, for automatic verification of the MacroAssember version.
>
> Thank you all for the feedback!
> 
> @iklam - I'll check that and let you know once I make more conversions.
> 
> @dean-long - That would be great. I'm all ears for the best way to test this!

Here's one way to test both versions, using loadRange as an example.  It's not exactly pretty, but it seems to work.
[loadRange.txt](https://github.com/openjdk/jdk/files/5994725/loadRange.txt)

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

PR: https://git.openjdk.java.net/jdk/pull/2420

From mdoerr at openjdk.java.net  Wed Feb 17 10:30:52 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 17 Feb 2021 10:30:52 GMT
Subject: Integrated: 8261522: [PPC64] AES intrinsics write beyond the
 destination array
In-Reply-To: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
References: <jyCAZWg_7y3QCZ9kxrpNRXFcMoVHDklwi0x-4DGHZ9w=.9475bd34-aa53-44db-989e-00c647f73ea1@github.com>
Message-ID: <5zlfn8FhS8rhNbEsFSjApw6M0f-MEIDWN1U8CB8mWZw=.29ec88e5-b058-42df-9137-9b68844edde2@github.com>

On Wed, 10 Feb 2021 17:05:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I'd like to replace the read-modify-write implementation from aescrypt_encryptBlock / aescrypt_decryptBlock stubs. It can cause severe problems (see bug description).

This pull request has now been integrated.

Changeset: 05d59556
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/05d59556
Stats:     76 lines in 1 file changed: 32 ins; 20 del; 24 mod

8261522: [PPC64] AES intrinsics write beyond the destination array

Reviewed-by: lucy

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

PR: https://git.openjdk.java.net/jdk/pull/2514

From neliasso at openjdk.java.net  Wed Feb 17 10:32:59 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 17 Feb 2021 10:32:59 GMT
Subject: RFR: 8260653: Unreachable nodes keep speculative types alive
Message-ID: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>

8260653: Unreachable nodes keep speculative types alive

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

Commit messages:
 - Remove useless nodes

Changes: https://git.openjdk.java.net/jdk/pull/2606/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2606&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260653
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2606/head:pull/2606

PR: https://git.openjdk.java.net/jdk/pull/2606

From redestad at openjdk.java.net  Wed Feb 17 11:47:47 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Feb 2021 11:47:47 GMT
Subject: RFR: 8261553: Efficient mask generation using BMI2 BZHI
 instruction [v3]
In-Reply-To: <fOkYPC2KarulNUevhWhgG0gJ8Ki5P-zcsk1hGC9AG20=.ef56d06b-3432-425e-b853-a1896a7c154f@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
 <fOkYPC2KarulNUevhWhgG0gJ8Ki5P-zcsk1hGC9AG20=.ef56d06b-3432-425e-b853-a1896a7c154f@github.com>
Message-ID: <Mky14QKV72h3mLzR-DartdxVF04LbbJm-iq69HmjQEY=.157366f2-0627-447d-859d-34ce8af41d8a@github.com>

On Mon, 15 Feb 2021 18:55:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> BMI2 BHZI instruction can be used to optimize the instruction sequence
>> used for mask generation at various place in array copy stubs and partial in-lining for small copy operations.
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261553 : Aligning main copy loop to prevent any penalty due to LSD and DSB misses.

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From github.com+42899633+eastig at openjdk.java.net  Wed Feb 17 12:09:42 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 17 Feb 2021 12:09:42 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v4]
In-Reply-To: <w-2JkDuXk-wAeMBvrZm8MS2OI3jADcEEELDRmZ16S48=.84db5012-0b2a-49ce-adb4-038cf59ce423@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <w-2JkDuXk-wAeMBvrZm8MS2OI3jADcEEELDRmZ16S48=.84db5012-0b2a-49ce-adb4-038cf59ce423@github.com>
Message-ID: <AgJYY86bXzz7lUOV8DCLBFgMZfm_dqdcs1x8ytcARS8=.6da2a1ad-99c0-4328-9fb5-00978bcf5722@github.com>

On Sun, 14 Feb 2021 05:44:51 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
>> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
>> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
>> 
>> Before:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
>> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
>> - string: "a"
>> :Constant:exact *
>> 
>> After:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *
>
> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>    
>    reimplement this feature. withdraw my intrusive change in outputStream.
>    use stringStream only for the constant OopPtr. after oop->print_on(st),
>    delete all appearances of '\n'
>  - Merge branch 'master' into JDK-8260198
>  - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>    
>    fix merge conflict.
>  - Merge branch 'master' into JDK-8260198
>  - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>    
>    Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
>    Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
>    Remove the comment because Klass::oop_print_on() has emitted the address of oop.
>    
>    Before:
>    689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
>    {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
>     - string: "a"
>     :Constant:exact *
>    
>    After:
>    689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *

Changes requested by eastig at github.com (no known OpenJDK username).

src/hotspot/share/opto/type.cpp line 4049:

> 4047:       ss.print(" ");
> 4048:       const_oop()->print_oop(&ss);
> 4049:       ss.tr_delete('\n');

`tr_delete` is expensive. Also deleting something in a stream does not fit into a concept of streams.
I see that the content of `ss` is traversed many times.
What about this code:
for (const char *str = ss.base(); *str; ) {
  size_t i = 0;
  while (str[i] && str[i] != '\n' ) {
       ++i;
  }
  st->print_raw(str, i);
  str += i;
  while (*str == '\n') {
    ++str;
  }
}

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From neliasso at openjdk.java.net  Wed Feb 17 12:43:40 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 17 Feb 2021 12:43:40 GMT
Subject: RFR: 8260653: Unreachable nodes keep speculative types alive
In-Reply-To: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
References: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
Message-ID: <ZIAPBotGD-GwNUmFcmOqDFhI4goxlL0BKRIEXDT1OZw=.ad268ff6-2d4f-4940-b554-ca0756af506b@github.com>

On Wed, 17 Feb 2021 10:27:08 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> The RunThese test fails because after first igvn.optimize() (directly after parsing) there are unreachable nodes cycles left. Later when remove_speculative_types() is called - only reachable nodes will have their speculative type removed. At the end of remove_speculative_types() there is an assert that all speculative types have been removed that will fail.
> 
> This problem will not cause crashes in production - it is only a sanity test.
> 
> I suggest adding a call to PhaseRemoveUseless before remove_speculative_types. This will cost a few extra cycles but it is the only way we can guarantee that no unreachable nodes are left.
> 
> When debugging this I experimented with adding a call to verify_graph_edges to check for dead code at the same spot. This triggers failures in a lot of test. The conclusion is that it is very common that we have dead node cycles - but they very rarely keep speculative types alive.
> 
> A big thank you to Dean Long how created the reproducer for this bug.
> 
> Please review.

One reasonable alternative to adding one more pass of PhaseRemoveUseless is filtering out all non-reachable nodes from NodeHash::check_no_speculative_types. The unreachable nodes only live a short while before being removed in the renumbering phase.

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

PR: https://git.openjdk.java.net/jdk/pull/2606

From goetz at openjdk.java.net  Wed Feb 17 13:10:40 2021
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Wed, 17 Feb 2021 13:10:40 GMT
Subject: RFR: 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal
In-Reply-To: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>
References: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>
Message-ID: <SICUGIT65GVREYnQY-SWlmUqtMRBB9Z8MsGcpqFrtBk=.167729cf-6f79-44af-91ba-59060d5d147b@github.com>

On Fri, 12 Feb 2021 16:29:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We only need one StoreCM node after CMS removal. CMS StoreStore barriers were already removed at other places.

Marked as reviewed by goetz (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2554

From goetz at openjdk.java.net  Wed Feb 17 13:10:40 2021
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Wed, 17 Feb 2021 13:10:40 GMT
Subject: RFR: 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal
In-Reply-To: <SICUGIT65GVREYnQY-SWlmUqtMRBB9Z8MsGcpqFrtBk=.167729cf-6f79-44af-91ba-59060d5d147b@github.com>
References: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>
 <SICUGIT65GVREYnQY-SWlmUqtMRBB9Z8MsGcpqFrtBk=.167729cf-6f79-44af-91ba-59060d5d147b@github.com>
Message-ID: <cYDA2zYjH1A4OIoa3sXMZYQwj7SS_umWx5SzHB0egnI=.f7506431-74fd-4e37-bf12-a32080508ef2@github.com>

On Wed, 17 Feb 2021 13:07:19 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> We only need one StoreCM node after CMS removal. CMS StoreStore barriers were already removed at other places.
>
> Marked as reviewed by goetz (Reviewer).

LGTM

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

PR: https://git.openjdk.java.net/jdk/pull/2554

From mdoerr at openjdk.java.net  Wed Feb 17 13:14:47 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 17 Feb 2021 13:14:47 GMT
Subject: RFR: 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal
In-Reply-To: <cYDA2zYjH1A4OIoa3sXMZYQwj7SS_umWx5SzHB0egnI=.f7506431-74fd-4e37-bf12-a32080508ef2@github.com>
References: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>
 <SICUGIT65GVREYnQY-SWlmUqtMRBB9Z8MsGcpqFrtBk=.167729cf-6f79-44af-91ba-59060d5d147b@github.com>
 <cYDA2zYjH1A4OIoa3sXMZYQwj7SS_umWx5SzHB0egnI=.f7506431-74fd-4e37-bf12-a32080508ef2@github.com>
Message-ID: <Wq5Zss7qdkAu1BaDP5wOx82sM1D6zzuSpyH2tgMBYLc=.5f4b88de-31e2-4b47-a511-23c8683e829c@github.com>

On Wed, 17 Feb 2021 13:07:43 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> Marked as reviewed by goetz (Reviewer).
>
> LGTM

Thanks for the review!

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

PR: https://git.openjdk.java.net/jdk/pull/2554

From mdoerr at openjdk.java.net  Wed Feb 17 13:14:48 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 17 Feb 2021 13:14:48 GMT
Subject: Integrated: 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal
In-Reply-To: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>
References: <FYqjxMiWyqTwncTlk0b2gLCBk8JpM648fVw8aWG4-tE=.ebb913cb-4441-4fec-9c20-1234b629c5ae@github.com>
Message-ID: <YtjPiteoheNs57wjs1oKuL0DAanJ6WEVjFMjD_kCsJw=.0937b71b-d6d9-4de5-8913-e9b034bb73cb@github.com>

On Fri, 12 Feb 2021 16:29:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We only need one StoreCM node after CMS removal. CMS StoreStore barriers were already removed at other places.

This pull request has now been integrated.

Changeset: 9ba2b71a
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9ba2b71a
Stats:     55 lines in 1 file changed: 0 ins; 52 del; 3 mod

8261657: [PPC64] Cleanup StoreCM nodes after CMS removal

Reviewed-by: lucy, goetz

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

PR: https://git.openjdk.java.net/jdk/pull/2554

From rcastanedalo at openjdk.java.net  Wed Feb 17 13:31:53 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 17 Feb 2021 13:31:53 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM
Message-ID: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>

The block formation algorithm applied by IGV to schedule graphs without associated CFG information traverses the graph backwards. This makes it difficult to deal with block projection nodes, leading in some cases to double addition of block nodes and block edges, and ultimately causing assertion failures.

This fix replaces the backward traversal by a forward traversal that relies on node category information (introduced in [8261336](https://bugs.openjdk.java.net/browse/JDK-8261336)) to identify control successors. The forward traversal is arguably simpler and, besides avoiding the reported assertion failure, has two advantages:

- it places block projection nodes in the same block as their predecessors, and
- it numbers basic blocks more naturally.

The following screenshots illustrate the improvements (before the fix to the left, after the fix to the right):

![cfgs-before-after](https://user-images.githubusercontent.com/8792647/108204708-6dcf5e00-7124-11eb-956c-fb7f84229b50.png)

Tested automatically on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented version of IGV that schedules graphs eagerly. Checked manually that the CFGs of a few selected graphs (included the reported one) are well-formed. Also checked that the overall IGV graph scheduling time is not affected by the changes.

Thanks to Christian Hagedorn for checking the fix independently.

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

Commit messages:
 - Form basic blocks using a forward traversal
 - Connect orphan/widow CFG nodes to root
 - Mark CFG nodes before scheduling

Changes: https://git.openjdk.java.net/jdk/pull/2607/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2607&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259984
  Stats: 167 lines in 1 file changed: 90 ins; 19 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2607/head:pull/2607

PR: https://git.openjdk.java.net/jdk/pull/2607

From github.com+10482586+therealeliu at openjdk.java.net  Wed Feb 17 13:34:42 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Wed, 17 Feb 2021 13:34:42 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <fQyVXCbS6JtucneiuQdQ7SVeL81Lag2w4ZnBWVGxO2I=.d8cc9664-2d4a-4a96-bf94-c774bbab83ab@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <WDQ0yZR8gbP6aLt1qOEIMsSOrwiSMdS4V8l4pi4RBmc=.b201fce0-ed3e-4319-b96b-9651bd4ecdd7@github.com>
 <fQyVXCbS6JtucneiuQdQ7SVeL81Lag2w4ZnBWVGxO2I=.d8cc9664-2d4a-4a96-bf94-c774bbab83ab@github.com>
Message-ID: <SOiGTEJFUq5Lal7m_B7dxBsqF2N2HVWSWgVrrzUUqfY=.9fefa5fa-3761-42d7-b7dc-0bf90c071468@github.com>

On Tue, 9 Feb 2021 03:07:38 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

>> All that remains to do is the benchmarks.
>
> @theRealAph Could you help to take a look ?

Ping

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From jbhateja at openjdk.java.net  Wed Feb 17 14:12:39 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 17 Feb 2021 14:12:39 GMT
Subject: Integrated: 8261553: Efficient mask generation using BMI2 BZHI
 instruction
In-Reply-To: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
References: <kWK9iV8DzddSqw0IfycL1TaNpsy8PLFXPZl6r36fYkA=.48708a36-db7f-4157-b5fa-872ae7efd208@github.com>
Message-ID: <jPRGL2akIe9EMVioqT-tFLGphD8MZbpvrL-yso5shfE=.273431b1-17b1-4d8b-bac5-507b7d2bac6e@github.com>

On Thu, 11 Feb 2021 08:31:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> BMI2 BHZI instruction can be used to optimize the instruction sequence
> used for mask generation at various place in array copy stubs and partial in-lining for small copy operations.

This pull request has now been integrated.

Changeset: cb84539d
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cb84539d
Stats:     39 lines in 6 files changed: 12 ins; 11 del; 16 mod

8261553: Efficient mask generation using BMI2 BZHI instruction

Reviewed-by: redestad, neliasso

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

PR: https://git.openjdk.java.net/jdk/pull/2522

From neliasso at openjdk.java.net  Wed Feb 17 14:35:59 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 17 Feb 2021 14:35:59 GMT
Subject: RFR: 8260653: Unreachable nodes keep speculative types alive [v2]
In-Reply-To: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
References: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
Message-ID: <Zz6l0ZrId5aDC1TwCdPNJvIpyp1mjqT122vxiyzypeI=.7e6c7df3-fa0c-4fba-bf74-9f304a56b2ec@github.com>

> The RunThese test fails because after first igvn.optimize() (directly after parsing) there are unreachable nodes cycles left. Later when remove_speculative_types() is called - only reachable nodes will have their speculative type removed. At the end of remove_speculative_types() there is an assert that all speculative types have been removed that will fail.
> 
> This problem will not cause crashes in production - it is only a sanity test.
> 
> I suggest adding a call to PhaseRemoveUseless before remove_speculative_types. This will cost a few extra cycles but it is the only way we can guarantee that no unreachable nodes are left.
> 
> When debugging this I experimented with adding a call to verify_graph_edges to check for dead code at the same spot. This triggers failures in a lot of test. The conclusion is that it is very common that we have dead node cycles - but they very rarely keep speculative types alive.
> 
> A big thank you to Dean Long how created the reproducer for this bug.
> 
> Please review.

Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:

  Check if node is live before assert

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2606/files
  - new: https://git.openjdk.java.net/jdk/pull/2606/files/5f279179..82ab1066

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2606&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2606&range=00-01

  Stats: 10 lines in 2 files changed: 6 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2606/head:pull/2606

PR: https://git.openjdk.java.net/jdk/pull/2606

From shade at redhat.com  Wed Feb 17 14:50:44 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Feb 2021 15:50:44 +0100
Subject: Intermittent JRuby json issue related to tiered or G1
In-Reply-To: <ead14606-cdfe-27fc-4bac-a9c5b5219e44@redhat.com>
References: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>
 <1bac4d6a-e53d-075d-0209-6b737b7a2e77@redhat.com>
 <b7f97cdf-7111-0b5f-78e1-7f760b5d860b@redhat.com>
 <CAE-f1xRvKHzHDZQL3Nez+807ND6E=Pt0xE1BLxDfnxo72vWRDA@mail.gmail.com>
 <ead14606-cdfe-27fc-4bac-a9c5b5219e44@redhat.com>
Message-ID: <7110e0cf-8c77-1d6d-8854-3160d5c901f8@redhat.com>

On 2/16/21 9:05 PM, Aleksey Shipilev wrote:
> On 2/16/21 9:00 PM, Charles Oliver Nutter wrote:
>> I am a bit confused about your JDK9 reference. If it was fixed in 9
>> why does it reliably reproduce in 15? Perhaps I am misunderstanding
>> the lineage of the fix you are referring to.
> 
> I am saying that there are no direct JIRA hits that could explain why this is happening. The only
> hit I got is for fix already in JDK 9, so it should not happen again.
> 
> I am (slowly) bisecting between JDK 15 and JDK 16 to see which fix directly or accidentally fixed
> it. Then we would know what we are dealing with.

This thing is really hairy. Reverse bisects shows that this one:
   https://bugs.openjdk.java.net/browse/JDK-8257847

...makes failure in fastdebug much less likely. This explains why I have not seen the failures in 
JDK 16 and JDK 17 yesterday. I have managed to reliably crash the recent JDK by promoting the assert 
in question into guarantee:

diff --git a/src/hotspot/share/opto/ifnode.cpp b/src/hotspot/share/opto/ifnode.cpp
index 29624765324..467d8f19276 100644
--- a/src/hotspot/share/opto/ifnode.cpp
+++ b/src/hotspot/share/opto/ifnode.cpp
@@ -948,7 +948,9 @@ bool IfNode::fold_compares_helper(ProjNode* proj, ProjNode* success, ProjNode* f
      assert((dom_bool->_test.is_less() && proj->_con) ||
             (dom_bool->_test.is_greater() && !proj->_con), "incorrect test");
      // this test was canonicalized
-    assert(this_bool->_test.is_less() && !fail->_con, "incorrect test");
+    guarantee(this_bool->_test.is_less() && !fail->_con, "incorrect test: dom_bool.test=%d 
proj._con=%d this_bool.test=%d fail._con=%d",
+           dom_bool->_test._test, proj->_con,
+           this_bool->_test._test, fail->_con);

      cond = (hi_test == BoolTest::le || hi_test == BoolTest::gt) ? BoolTest::gt : BoolTest::ge;


...which then fails with:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (ifnode.cpp:955), pid=2438111, tid=2438182
#  guarantee(this_bool->_test.is_less() && !fail->_con) failed: incorrect test: dom_bool.test=3 
proj._con=1 this_bool.test=7 fail._con=1
#
# JRE version: OpenJDK Runtime Environment (17.0) (build 17-internal+0-adhoc.shade.jdk)
# Java VM: OpenJDK 64-Bit Server VM (17-internal+0-adhoc.shade.jdk, mixed mode, sharing, tiered, 
compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x7fc3ee]  IfNode::fold_compares_helper(ProjNode*, ProjNode*, ProjNode*, 
PhaseIterGVN*) [clone .part.0]+0x19e
#
# Core dump will be written. Default location: Core dumps may be processed with 
"/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to 
/home/shade/temp/jruby/jruby-issue-6554/core.2438111)
#
# An error report file with more information is saved as:
# /home/shade/temp/jruby/jruby-issue-6554/hs_err_pid2438111.log
#
# Compiler replay data is saved as:
# /home/shade/temp/jruby/jruby-issue-6554/replay_pid2438111.log


"this_bool.test=7" means the test is "GE". The downstream code does not expect this. It expects the 
test to be canonicalized. This minimal thing bails out on discovery of such bad test:

  diff --git a/src/hotspot/share/opto/ifnode.cpp b/src/hotspot/share/opto/ifnode.cpp
@@ -971,6 +973,9 @@ bool IfNode::fold_compares_helper(ProjNode* proj, ProjNode* success, ProjNode* f
          lo = igvn->transform(new AddINode(lo, igvn->intcon(1)));
          cond = BoolTest::ge;
        }
+    } else {
+      // Safety: something is broken, break away.
+      return false;
      }
    } else {
      const TypeInt* failtype = filtered_int_type(igvn, n, proj);


I think I'll submit two issues: one that codes fold_compares_helper more defensively like in the 
patch above (this would be backportable), and then the follow-up that targets to address the actual 
problem (why do we have uncanonicalized test).


-- 
Thanks,
-Aleksey


From github.com+10835776+stsypanov at openjdk.java.net  Wed Feb 17 14:51:52 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 17 Feb 2021 14:51:52 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible
Message-ID: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>

Non-static classes hold a link to their parent classes, which in many cases can be avoided.

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

Commit messages:
 - 8261880: Change nested classes in java.base to static nested classes where possible

Changes: https://git.openjdk.java.net/jdk/pull/2589/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261880
  Stats: 20 lines in 16 files changed: 0 ins; 0 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2589.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2589/head:pull/2589

PR: https://git.openjdk.java.net/jdk/pull/2589

From shade at redhat.com  Wed Feb 17 15:14:03 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Feb 2021 16:14:03 +0100
Subject: Intermittent JRuby json issue related to tiered or G1
In-Reply-To: <7110e0cf-8c77-1d6d-8854-3160d5c901f8@redhat.com>
References: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>
 <1bac4d6a-e53d-075d-0209-6b737b7a2e77@redhat.com>
 <b7f97cdf-7111-0b5f-78e1-7f760b5d860b@redhat.com>
 <CAE-f1xRvKHzHDZQL3Nez+807ND6E=Pt0xE1BLxDfnxo72vWRDA@mail.gmail.com>
 <ead14606-cdfe-27fc-4bac-a9c5b5219e44@redhat.com>
 <7110e0cf-8c77-1d6d-8854-3160d5c901f8@redhat.com>
Message-ID: <18a23eea-03a2-7f69-c4f4-4d22bddb3eb9@redhat.com>

On 2/17/21 3:50 PM, Aleksey Shipilev wrote:
> I think I'll submit two issues: one that codes fold_compares_helper more defensively like in the
> patch above (this would be backportable)

This would be:
   https://bugs.openjdk.java.net/browse/JDK-8261912

> and then the follow-up that targets to address the actual
> problem (why do we have uncanonicalized test).

And this would be:
   https://bugs.openjdk.java.net/browse/JDK-8261914

-- 
Thanks,
-Aleksey


From enikitin at openjdk.java.net  Wed Feb 17 15:46:58 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Wed, 17 Feb 2021 15:46:58 GMT
Subject: RFR: 8261666: [mlvm] Remove WhiteBoxHelper
Message-ID: <4pcln-55Xj11rpaV-DxVnxfjp5m0OAsXS2ribyvM96E=.6f45af64-eacc-4943-a31a-d5e117532b1f@github.com>

The mlvm test suite used this class for situations when WhiteBox was not available during the test's build time - therefore, the test tried to find the WhiteBox on runtime.

These days, the WhiteBox is always available so this is not the case. The said helper is to be removed and its only user adjusted.

Testing: test/hotspot/jtreg/vmTestBase/vm/mlvm on linux/mac/windows x64.

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

Commit messages:
 - 8261666: [mlvm] Remove WhiteBoxHelper

Changes: https://git.openjdk.java.net/jdk/pull/2609/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2609&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261666
  Stats: 85 lines in 2 files changed: 3 ins; 80 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2609.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2609/head:pull/2609

PR: https://git.openjdk.java.net/jdk/pull/2609

From nhe at activeviam.com  Wed Feb 17 10:34:04 2021
From: nhe at activeviam.com (Nicolas Heutte)
Date: Wed, 17 Feb 2021 11:34:04 +0100
Subject: [External] : Re: SuperWord loop optimization lost after method
 inlining
In-Reply-To: <08ce2121-bbb4-3ea5-8f05-efeb33df7b74@oracle.com>
References: <CAOqmmc0ue3bLMBgWLAvUOrHLe2iNtoSiBiq=+Beky-D=MkA+fw@mail.gmail.com>
 <b9184f85-c869-8088-a080-2d860dca5f9f@oracle.com>
 <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
 <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>
 <CAOqmmc2mWWr2mWoitEz71xc1PZ53ZLhyDfRQ+TjxKRcuGcxNkg@mail.gmail.com>
 <08ce2121-bbb4-3ea5-8f05-efeb33df7b74@oracle.com>
Message-ID: <CAOqmmc1PKCWgC0n+7WkFDz7vAzxfLpZH4ThQnSL=6yQO5Ghrxg@mail.gmail.com>

Hi Vladimir,

I have rerun the test with the appropriate options, the obtained logs are
in this folder:
https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing

Best regards,
Nicolas Heutte

On Tue, Feb 16, 2021 at 11:35 PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Hi Nicolas,
>
> The file you shared has only assembler code. Yes, it shows that when
> ArrayFloatToArrayFloatVectorBinding::plus() is
> inlined into AVector::plus() it is not vectorized.
>
> But I asked for an other file (hotspot_pid<PID>.log) which is generated
> when you run app with
> -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation flags. It should start
> with:
>
> <?xml version='1.0' encoding='UTF-8'?>
> <hotspot_log version='160 1' process='2302014' time_ms='1613514688748'>
> <vm_version>
> <name>
> Java HotSpot(TM) 64-Bit Server VM
> </name>
> <release>
> 11.0.9+7-LTS
> </release>
>
> Thanks,
> Vladimir K
>
> On 2/15/21 5:19 AM, Nicolas Heutte wrote:
> > Hi Vladimir,
> >
> > I've tried disabling tiered compilation, as you requested. It seems that
> the inlining was performed slightly
> > differently, but the issue remains. As you can see in this excerpt, the
> main loop isn't properly vectorized:
> >
> >    0x00000254b0d4bf54: cmp    %r11d,%r8d
> >    0x00000254b0d4bf57: jae    0x00000254b0d4c19e
> >    0x00000254b0d4bf5d: vmovss 0x10(%rcx,%r8,4),%xmm9  ;*faload
> {reexecute=0 rethrow=0 return_oop=0}
> >                                                  ; -
> > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
> (line 41)
> >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
> >                                                  ; -
> > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >                                                  ; -
> com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)
> >
> >    0x00000254b0d4bf64: cmp    %ebx,%r8d
> >    0x00000254b0d4bf67: jae    0x00000254b0d4c1ec
> >    0x00000254b0d4bf6d: vaddss 0x10(%rdi,%r8,4),%xmm9,%xmm9
> >    0x00000254b0d4bf74: vmovss %xmm9,0x10(%rcx,%r8,4)  ;*fastore
> {reexecute=0 rethrow=0 return_oop=0}
> >                                                  ; -
> > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> (line 41)
> >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
> >                                                  ; -
> > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >                                                  ; -
> com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)
> >
> >    0x00000254b0d4bf7b: inc    %r8d               ;*iinc {reexecute=0
> rethrow=0 return_oop=0}
> >                                                  ; -
> > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> (line 40)
> >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
> >                                                  ; -
> > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >                                                  ; -
> com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)
> >
> >    0x00000254b0d4bf7e: cmp    %r9d,%r8d
> >    0x00000254b0d4bf81: jl     0x00000254b0d4bf54  ;*goto {reexecute=0
> rethrow=0 return_oop=0}
> >                                                  ; -
> > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> (line 40)
> >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
> >                                                  ; -
> > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >                                                  ; -
> com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27 (line 118)
> >
> >
> >
> > Here is the link to the full log, should you want to take a look at it:
> >
> https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing
> > <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$
> >
> >
> > Best regards,
> > Nicolas Heutte
> >
> > On Thu, Feb 11, 2021 at 7:05 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> >
> >     Changing wide mailing list to JIT compiler only.
> >
> >     This deoptimization is normal in Tiered Compilation - it switched
> from profiling code (level='3') generated by C1
> >     compiler to new code generated by C2 (level='4') which does loop
> optimizations.
> >
> >     Thank you for posting inlining information:
> >
> >           @ 17
>  com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
> bytes) inline (hot)
> >              \-> TypeProfile (14054/14054 counts) =
> com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
> >
> >     I thought before that may be call site is not hot but it is not the
> case.
> >
> >     You can do an other experiment to collect log with disabled Tiered
> Compilation (only C2 is used): -XX:-TieredCompilation
> >     Also print assembler code (as you did before) for final compilation
> to see if loop is still not vectorized.
> >
> >     Is it possible to post log file (on GitHub?) for me to look?
> >
> >     Thanks,
> >     Vladimir K
> >
> >     On 2/11/21 6:28 AM, Nicolas Heutte wrote:
> >      > Hi Vladimir,
> >      >
> >      > Thank you for your help.
> >      >
> >      > I'm currently running Java 11.0.9, and I did not use any VM flag
> of note.
> >      >
> >      > I checked the content of the compilation log, and it seems that
> ArrayFloatToArrayFloatVectorBinding::plus() was
> >      > deoptimized in order to allow AVector::plus() to be compiled:
> >      >
> >      > <writer thread='11576'/>
> >      > <task_queued compile_id='17280'
> method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V'
> bytes='23'
> >      > count='916' iicount='916' level='3' stamp='7394.056'
> comment='tiered' hot_count='896'/>
> >      > <writer thread='15784'/>
> >      > <deoptimized thread='15784' reason='constraint'
> pc='0x00000296d0785b94' compile_id='17257' compiler='c1' level='3'>
> >      > <jvms bci='65'
> method='com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding plus
> >      > (Lcom/qfs/vector/IVector;Lcom/qfs/vector/IVector;)V' bytes='69'
> count='909' backedge_count='155602' iicount='910'/>
> >      > </deoptimized>
> >      >
> >      > The last compilation entry for AVector::plus() is:
> >      >
> >      > <writer thread='16380'/>
> >      > <nmethod compile_id='17317' compiler='c2' level='4'
> entry='0x00000296d6af32c0' size='1960'
> >     address='0x00000296d6af3110'
> >      > relocation_offset='376' insts_offset='432' stub_offset='1040'
> scopes_data_offset='1152' scopes_pcs_offset='1592'
> >      > dependencies_offset='1880' nul_chk_table_offset='1896'
> oops_offset='1064' metadata_offset='1072'
> >      > method='com.qfs.vector.impl.AVector plus
> (Lcom/qfs/vector/IVector;)V' bytes='23' count='172425' iicount='172425'
> >      > stamp='7394.199'/>
> >      > <make_not_entrant thread='16380' compile_id='17280' compiler='c1'
> level='2' stamp='7394.199'/>
> >      >                                @ 1
> com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes)   inline
> >     (hot)
> >      >                                 \-&gt; TypeProfile (14552/14552
> counts) = com/qfs/vector/array/impl/ArrayFloatVector
> >      >                                @ 7
> com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes)   inline
> >     (hot)
> >      >                                 \-&gt; TypeProfile (14150/14150
> counts) = com/qfs/vector/array/impl/ArrayFloatVector
> >      >                                @ 10
> com.qfs.vector.binding.impl.VectorBindings::getBinding (9 bytes)   inline
> (hot)
> >      >                                  @ 5
> >
>  com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::getBinding
> (22
> >      > bytes)   inline (hot)
> >      >                                    @ 3
> >
>  com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::hasBinding
> >      > (34 bytes)   inline (hot)
> >      >                                @ 17
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
> >     bytes)
> >      > inline (hot)
> >      >                                 \-&gt; TypeProfile (14054/14054
> counts) =
> >      > com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
> >      >                                  @ 12
> com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)   inline (hot)
> >      >                                  @ 22
> com.qfs.vector.impl.AVector::checkIndex (37 bytes)   inline (hot)
> >      >                                    @ 6
> com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)   inline (hot)
> >      >                                  @ 27
> com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)
> >     accessor
> >      >                                  @ 34
> com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)
> >     accessor
> >      > <writer thread='15896'/>
> >      >
> >      > Unfortunately, I do not have access to a debug VM build, so I
> cannot run the second test you recommend.
> >      >
> >      > Best regards,
> >      > Nicolas Heutte
> >      >
> >      > On Wed, Feb 10, 2021 at 7:36 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
> >     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com>>> wrote:
> >      >
> >      >     Hi, Nicolas
> >      >
> >      >     Looks like, when inlined, the loop from
> ArrayFloatToArrayFloatVectorBinding::plus() was not optimized at all:
> >     it is not
> >      >     unrolled and has range checks. Such loops are not vectorized
> (you need unrolling and no checks).
> >      >
> >      >     What Java version you are running? What HotSpot VM flags you
> are using when running application?
> >      >
> >      >     Run application with -XX:+LogCompilation and look on
> compilation data in hotspot_pid<PID>.log file for caller
> >      >     AVector::plus().
> >      >
> >      >     VM also has several flags to trace loop optimizations but
> they are only available in debug VM build. If you
> >     have access
> >      >     to such build run with -XX:+PrintCompilation
> -XX:+TraceLoopOpts flags.
> >      >
> >      >     Thanks,
> >      >     Vladimir K
> >      >
> >      >     On 2/10/21 9:24 AM, Nicolas Heutte wrote:
> >      >      > Hi all,
> >      >      >
> >      >      > I am encountering a performance issue caused by the
> interaction between
> >      >      > method inlining and automatic vectorization.
> >      >      >
> >      >      > Our application aggregates arrays intensively using a
> method named
> >      >      > ArrayFloatToArrayFloatVectorBinding.plus() with the
> following code:
> >      >      >
> >      >      >      for (int i = 0; i < srcLen; ++i) {
> >      >      >
> >      >      >              dstArray[i] += srcArray[i];
> >      >      >
> >      >      >      }
> >      >      >
> >      >      > When we microbenchmark this method we observe fast
> performance close to the
> >      >      > practical memory bandwidth and when we print the assembly
> code we observe
> >      >      > loop unrolling and automatic vectorization with SIMD
> instructions.
> >      >      >
> >      >      >    0x000001ef4600abf0: vmovdqu 0x10(%r14,%r13,4),%ymm0
> >      >      >
> >      >      >    0x000001ef4600abf7: vaddps 0x10(%rcx,%r13,4),%ymm0,%ymm0
> >      >      >
> >      >      >    0x000001ef4600abfe: vmovdqu %ymm0,0x10(%r14,%r13,4)
> >      >      >
> >      >      >    0x000001ef4600ac05: movslq %r13d,%r11
> >      >      >
> >      >      >    0x000001ef4600ac08: vmovdqu 0x30(%r14,%r11,4),%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac0f: vaddps 0x30(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac16: vmovdqu %ymm0,0x30(%r14,%r11,4)
> >      >      >
> >      >      >    0x000001ef4600ac1d: vmovdqu 0x50(%r14,%r11,4),%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac24: vaddps 0x50(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac2b: vmovdqu %ymm0,0x50(%r14,%r11,4)
> >      >      >
> >      >      >    0x000001ef4600ac32: vmovdqu 0x70(%r14,%r11,4),%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac39: vaddps 0x70(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac40: vmovdqu %ymm0,0x70(%r14,%r11,4)
> >      >      >
> >      >      >    0x000001ef4600ac47: vmovdqu 0x90(%r14,%r11,4),%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac51: vaddps 0x90(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac5b: vmovdqu %ymm0,0x90(%r14,%r11,4)
> >      >      >
> >      >      >    0x000001ef4600ac65: vmovdqu 0xb0(%r14,%r11,4),%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac6f: vaddps 0xb0(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac79: vmovdqu %ymm0,0xb0(%r14,%r11,4)
> >      >      >
> >      >      >    0x000001ef4600ac83: vmovdqu 0xd0(%r14,%r11,4),%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac8d: vaddps 0xd0(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >
> >      >      >    0x000001ef4600ac97: vmovdqu %ymm0,0xd0(%r14,%r11,4)
> >      >      >
> >      >      >    0x000001ef4600aca1: vmovdqu 0xf0(%r14,%r11,4),%ymm0
> >      >      >
> >      >      >    0x000001ef4600acab: vaddps 0xf0(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >
> >      >      >    0x000001ef4600acb5: vmovdqu %ymm0,0xf0(%r14,%r11,4)
> ;*fastore
> >      >      > {reexecute=0 rethrow=0 return_oop=0}
> >      >      >
> >      >      >                                                  ; -
> >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> >      >      > (line 41)
> >      >      >
> >      >      >    0x000001ef4600acbf: add    $0x40,%r13d        ;*iinc
> {reexecute=0
> >      >      > rethrow=0 return_oop=0}
> >      >      >
> >      >      >                                                  ; -
> >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> >      >      > (line 40)
> >      >      >
> >      >      >    0x000001ef4600acc3: cmp    %eax,%r13d
> >      >      >
> >      >      >    0x000001ef4600acc6: jl     0x000001ef4600abf0  ;*goto
> {reexecute=0
> >      >      > rethrow=0 return_oop=0}
> >      >      >
> >      >      >                                                  ; -
> >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> >      >      > (line 40)
> >      >      >
> >      >      >
> >      >      >
> >      >      > In the real application, this method is actually inlined
> in a higher level
> >      >      > method named AVector.plus(). Unfortunately, the inlined
> version of the
> >      >      > aggregation code is not vectorized anymore:
> >      >      >
> >      >      >
> >      >      >
> >      >      >    0x000001ef460180a0: cmp    %ebx,%r11d
> >      >      >
> >      >      >    0x000001ef460180a3: jae    0x000001ef460180e6
> >      >      >
> >      >      >    0x000001ef460180a5: vmovss 0x10(%r8,%r11,4),%xmm1
> ;*faload {reexecute=0
> >      >      > rethrow=0 return_oop=0}
> >      >      >
> >      >      >                                                  ; -
> >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
> >      >      > (line 41)
> >      >      >
> >      >      >                                                  ; -
> >      >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >      >
> >      >      >    0x000001ef460180ac: cmp    %ecx,%r11d
> >      >      >
> >      >      >    0x000001ef460180af: jae    0x000001ef46018104
> >      >      >
> >      >      >    0x000001ef460180b1: vaddss 0x10(%r9,%r11,4),%xmm1,%xmm1
> >      >      >
> >      >      >    0x000001ef460180b8: vmovss %xmm1,0x10(%r8,%r11,4)
> ;*fastore {reexecute=0
> >      >      > rethrow=0 return_oop=0}
> >      >      >
> >      >      >                                                  ; -
> >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> >      >      > (line 41)
> >      >      >
> >      >      >                                                  ; -
> >      >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >      >
> >      >      >    0x000001ef460180bf: inc    %r11d              ;*iinc
> {reexecute=0
> >      >      > rethrow=0 return_oop=0}
> >      >      >
> >      >      >                                                  ; -
> >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> >      >      > (line 40)
> >      >      >
> >      >      >                                                  ; -
> >      >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >      >
> >      >      >    0x000001ef460180c2: cmp    %r10d,%r11d
> >      >      >
> >      >      >    0x000001ef460180c5: jl     0x000001ef460180a0  ;*goto
> {reexecute=0
> >      >      > rethrow=0 return_oop=0}
> >      >      >
> >      >      >                                                  ; -
> >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> >      >      > (line 40)
> >      >      >
> >      >      >                                                  ; -
> >      >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >      >
> >      >      >
> >      >      >
> >      >      > This causes a significant performance drop, compared to a
> run where we
> >      >      > explicitly disable the inlining and observe automatically
> vectorized code
> >      >      > again (
> >      >      >
> -XX:CompileCommand=dontinline,com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding.plus
> >      >      > ).
> >      >      >
> >      >      >
> >      >      > How do you guys explain that behavior of the JIT compiler?
> Is this a known
> >      >      > and tracked issue, could it be fixed in the JVM? Can we do
> something in the
> >      >      > java code to prevent this from happening?
> >      >      >
> >      >      >
> >      >      > Best regards,
> >      >      >
> >      >      > Nicolas Heutte
> >      >      >
> >      >
> >
>

From aph at openjdk.java.net  Wed Feb 17 16:16:40 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 17 Feb 2021 16:16:40 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>
Message-ID: <eMXlyYEeHkAIqUy8JwPoq1qPoqWrP2z7RDw7e3u_V_s=.00c9dd59-a602-49bc-a397-88534a3e6c61@github.com>

On Mon, 1 Feb 2021 11:20:20 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

>> This patch transforms '(x >>> rshift) + (x << lshift)' into
>> 'RotateRight(x, rshift)' during GVN phase when both the shift exponents
>> are constants and their sum equals to the number of bits for the type
>> of shift base.
>> 
>> This patch implements some new match rules for AArch64 instructions
>> which can take ROR as the optional shift. Such instructions are 'and',
>> 'or', 'eor', 'eon', 'bic' and 'orn'.
>> 
>>   ror     w11, w2, #5
>>   eor     w0, w1, w11
>> 
>> With this patch, above code could be optimized to below:
>> 
>>   eor     w0, w1, w2, ror #5
>> 
>> Finally, the patch refactors TestRotate.java[1][2].
>> 
>> Tested jtreg TestRotate.java, hotspot::hotspot_all_no_apps,
>> jdk::jdk_core, langtools::tier1.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8252776
>> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039911.html
>
> Eric Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark test
>   
>   Change-Id: I63ca51d06070a07e5c20daf4b42d2c8d7237a1da

OK. For what it's worth, I doubt that this will be suitable for backporting to 8u or 11u.

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

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1858

From shade at openjdk.java.net  Wed Feb 17 16:24:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 17 Feb 2021 16:24:52 GMT
Subject: RFR: 8261912: Code IfNode::fold_compares_helper more defensively
Message-ID: <Rg0yooo3hewsAfa-xDbOeoFkalN00IP9QkzxSJlLPxE=.c9daa643-a16d-46b4-8f87-50565d6a0249@github.com>

As [JDK-8261914](https://bugs.openjdk.java.net/browse/JDK-8261914) indicates, there are cases that break the internal asserts in `IfNode::fold_compares_helper`, code added by JDK-8073480 in JDK 9. Unfortunately, release builds would happily miscompile when that happens. It would be better to code `IfNode::fold_compares_helper` more defensively, so it bails when asserts are violated. This implicitly works around the bug in JDK-8261914. The goal for this limited workaround is to be trivially backportable in order to quickly unbreak 11u, 16u and 17.

The alternative is, instead of the early returns is to do:

 lo = NULL;
 hi = NULL;

...and then wait for for the method epilog to handle it. I have no preference to either style, as the blocks this patch affects already has some early returns, and `lo/hi = NULL` are also used.

Additional testing:
 - [x] Linux x86_64 fastdebug `tier1`
 - [x]  Linux x86_64 fastdebug `tier2`
 - [x] Failing JRuby reproducer from JDK-8261914, now passing in release mode with hundreds of iterations

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

Commit messages:
 - 8261912: Code IfNode::fold_compares_helper more defensively

Changes: https://git.openjdk.java.net/jdk/pull/2610/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2610&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261912
  Stats: 23 lines in 1 file changed: 15 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2610.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2610/head:pull/2610

PR: https://git.openjdk.java.net/jdk/pull/2610

From redestad at openjdk.java.net  Wed Feb 17 16:27:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Feb 2021 16:27:40 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible
In-Reply-To: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
Message-ID: <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>

On Tue, 16 Feb 2021 14:30:58 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.

src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192:

> 190: 
> 191:     /* Placeholder class for DelegatingMethodHandles generated ahead of time */
> 192:     static final class Holder {}

For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not.

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

PR: https://git.openjdk.java.net/jdk/pull/2589

From vlivanov at openjdk.java.net  Wed Feb 17 16:37:44 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 17 Feb 2021 16:37:44 GMT
Subject: RFR: 8260653: Unreachable nodes keep speculative types alive [v2]
In-Reply-To: <Zz6l0ZrId5aDC1TwCdPNJvIpyp1mjqT122vxiyzypeI=.7e6c7df3-fa0c-4fba-bf74-9f304a56b2ec@github.com>
References: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
 <Zz6l0ZrId5aDC1TwCdPNJvIpyp1mjqT122vxiyzypeI=.7e6c7df3-fa0c-4fba-bf74-9f304a56b2ec@github.com>
Message-ID: <oN_y9d4fFOtpZiI1Kl3F80p5xIAMwuAOsz0adjKjwNQ=.2e68ed29-04eb-4b9d-ae2e-b336eed57ba9@github.com>

On Wed, 17 Feb 2021 14:35:59 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> The RunThese test fails because after first igvn.optimize() (directly after parsing) there are unreachable nodes cycles left. Later when remove_speculative_types() is called - only reachable nodes will have their speculative type removed. At the end of remove_speculative_types() there is an assert that all speculative types have been removed that will fail.
>> 
>> This problem will not cause crashes in production - it is only a sanity test.
>> 
>> I suggest adding a call to PhaseRemoveUseless before remove_speculative_types. This will cost a few extra cycles but it is the only way we can guarantee that no unreachable nodes are left.
>> 
>> When debugging this I experimented with adding a call to verify_graph_edges to check for dead code at the same spot. This triggers failures in a lot of test. The conclusion is that it is very common that we have dead node cycles - but they very rarely keep speculative types alive.
>> 
>> A big thank you to Dean Long how created the reproducer for this bug.
>> 
>> Please review.
>
> Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check if node is live before assert

Looks good.

src/hotspot/share/opto/phaseX.cpp line 341:

> 339:        n != sentinel_node &&
> 340:        n->is_Type() &&
> 341:        n->outcnt() > 0 &&

`live_nodes.member(n)` makes ` n->outcnt() > 0` redundant, doesn't it?

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

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2606

From github.com+10835776+stsypanov at openjdk.java.net  Wed Feb 17 16:38:04 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 17 Feb 2021 16:38:04 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
Message-ID: <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>

On Wed, 17 Feb 2021 16:24:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261880: Remove static from declarations of Holder nested classes
>
> src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192:
> 
>> 190: 
>> 191:     /* Placeholder class for DelegatingMethodHandles generated ahead of time */
>> 192:     static final class Holder {}
> 
> For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not.

I'll just revert them

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

PR: https://git.openjdk.java.net/jdk/pull/2589

From github.com+10835776+stsypanov at openjdk.java.net  Wed Feb 17 16:38:03 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 17 Feb 2021 16:38:03 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
Message-ID: <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8261880: Remove static from declarations of Holder nested classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2589/files
  - new: https://git.openjdk.java.net/jdk/pull/2589/files/5650cce4..c6f9cf6b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=00-01

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2589.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2589/head:pull/2589

PR: https://git.openjdk.java.net/jdk/pull/2589

From github.com+7806504+liach at openjdk.java.net  Wed Feb 17 16:38:04 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Wed, 17 Feb 2021 16:38:04 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
 <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>
Message-ID: <PPTUVPzAXS-n0tLmdpQjmkropBQ_O4VtLeTrxcU7wEY=.40ee9124-65f7-405c-9a7f-18a31e6a6871@github.com>

On Wed, 17 Feb 2021 16:32:39 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192:
>> 
>>> 190: 
>>> 191:     /* Placeholder class for DelegatingMethodHandles generated ahead of time */
>>> 192:     static final class Holder {}
>> 
>> For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not.
>
> I'll just revert them

For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors.

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

PR: https://git.openjdk.java.net/jdk/pull/2589

From redestad at openjdk.java.net  Wed Feb 17 17:27:56 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Feb 2021 17:27:56 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <PPTUVPzAXS-n0tLmdpQjmkropBQ_O4VtLeTrxcU7wEY=.40ee9124-65f7-405c-9a7f-18a31e6a6871@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
 <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>
 <PPTUVPzAXS-n0tLmdpQjmkropBQ_O4VtLeTrxcU7wEY=.40ee9124-65f7-405c-9a7f-18a31e6a6871@github.com>
Message-ID: <OtixXl1Wa5_9MCYwFiYnGzeMHGf-mNhmI2RYvKmxjP8=.66c14fad-5ee9-4332-b290-a0d56c99a990@github.com>

On Wed, 17 Feb 2021 16:35:02 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>> I'll just revert them
>
> For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors.

Incidentally, Java-the-language allows static methods in inner instance classes since JDK 16. And I'm not sure this was ever a restriction at the JVMS level since we've been generating static methods (using ASM) into these inner instance classes since at least JDK 9.

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

PR: https://git.openjdk.java.net/jdk/pull/2589

From headius at headius.com  Wed Feb 17 17:28:54 2021
From: headius at headius.com (Charles Oliver Nutter)
Date: Wed, 17 Feb 2021 11:28:54 -0600
Subject: Intermittent JRuby json issue related to tiered or G1
In-Reply-To: <18a23eea-03a2-7f69-c4f4-4d22bddb3eb9@redhat.com>
References: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>
 <1bac4d6a-e53d-075d-0209-6b737b7a2e77@redhat.com>
 <b7f97cdf-7111-0b5f-78e1-7f760b5d860b@redhat.com>
 <CAE-f1xRvKHzHDZQL3Nez+807ND6E=Pt0xE1BLxDfnxo72vWRDA@mail.gmail.com>
 <ead14606-cdfe-27fc-4bac-a9c5b5219e44@redhat.com>
 <7110e0cf-8c77-1d6d-8854-3160d5c901f8@redhat.com>
 <18a23eea-03a2-7f69-c4f4-4d22bddb3eb9@redhat.com>
Message-ID: <CAE-f1xTnrnUkGsTihYNwj08RYxwczOYomMyLqK7sBW65__1S+g@mail.gmail.com>

On Wed, Feb 17, 2021 at 9:14 AM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 2/17/21 3:50 PM, Aleksey Shipilev wrote:
> > I think I'll submit two issues: one that codes fold_compares_helper more defensively like in the
> > patch above (this would be backportable)
>
> This would be:
>    https://bugs.openjdk.java.net/browse/JDK-8261912
>
> > and then the follow-up that targets to address the actual
> > problem (why do we have uncanonicalized test).
>
> And this would be:
>    https://bugs.openjdk.java.net/browse/JDK-8261914

This is outstanding sleuthing, thank you Aleksey! I'm not happy that
there's a JVM issue but at least we can stop banging our heads against
this as a JRuby bug.

Given your discoveries, I would have felt safe saying this is purely a
tiered JIT issue... but our users have reported that switching away
from G1 also eliminates the problem. Were they just lucky? Could there
be a separate issue?

I'm trying to come up with a short-term workaround with minimal
impact. Switching GC may not be in the cards but disabling tiered
compilation would probably be acceptable for production
environments...if that is sufficient.

 As always let me know if we can provide any more information. The
affected JRuby users and I will continue monitoring.

- Charlie

From github.com+828220+forax at openjdk.java.net  Wed Feb 17 17:44:47 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 17 Feb 2021 17:44:47 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <OtixXl1Wa5_9MCYwFiYnGzeMHGf-mNhmI2RYvKmxjP8=.66c14fad-5ee9-4332-b290-a0d56c99a990@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
 <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>
 <PPTUVPzAXS-n0tLmdpQjmkropBQ_O4VtLeTrxcU7wEY=.40ee9124-65f7-405c-9a7f-18a31e6a6871@github.com>
 <OtixXl1Wa5_9MCYwFiYnGzeMHGf-mNhmI2RYvKmxjP8=.66c14fad-5ee9-4332-b290-a0d56c99a990@github.com>
Message-ID: <zBnyv_oN9SrC_4C-zuzrW2bh79mbX5BmujBk8MPLgL0=.bbcf56a4-1bc9-4bf7-9d54-0cfd8cbcd30d@github.com>

On Wed, 17 Feb 2021 17:24:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors.
>
> Incidentally, Java-the-language allows static methods in inner instance classes since JDK 16. And I'm not sure this was ever a restriction at the JVMS level since we've been generating static methods (using ASM) into these inner instance classes since at least JDK 9.

Inner classes doesn't really exist for the JVM, it's just an attribute (in fact, a pair of attributes) that is read/write by javac (it's very similar to the way generics work).
So it is Ok to have static methods in inner classes since Java 1.1 from the JVM POV with the caveat that you may not be all to call them from Java-the-language.
Also since Java 11, inner classes are also nestmate and those attributes (NestHost/NestMembers) change the behavior of the VM.

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

PR: https://git.openjdk.java.net/jdk/pull/2589

From simonis at openjdk.java.net  Wed Feb 17 17:45:44 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 17 Feb 2021 17:45:44 GMT
Subject: RFR: 8261731: shallow copy the internal buffer of a
 scalar-replaced java.lang.String object [v2]
In-Reply-To: <3JNae6rXuxc_Q6YoALCH8Ku510Zne5ftqf1z8OCGkHQ=.2ebf5cd0-27e2-44e3-adf7-065179cc9ffd@github.com>
References: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
 <3JNae6rXuxc_Q6YoALCH8Ku510Zne5ftqf1z8OCGkHQ=.2ebf5cd0-27e2-44e3-adf7-065179cc9ffd@github.com>
Message-ID: <5vIeI9zFvxAcG-dUY-8iQwXlXDyWJ3VFMUqKamIL4o4=.746707e1-9d41-4fc0-9162-1ac7ca5589f3@github.com>

On Mon, 15 Feb 2021 19:00:57 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> There are 3 nodes involving in the construction of a java.lang.String object.
>> 1. Allocate of itself, aka. alloc
>> 2. AllocateArray of a byte array, which is value:byte[], aka. aa
>> 3. ArrayCopyNode which copys in the contents of value, aka. ac
>> 
>> Lemma
>> When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.
>> 
>> Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.
>> 
>> It is possible to rewire `aa` to the source of ac with the correct offset. That is to say, we can replace both `aa` and `ac` with a ?shallow copy? of the source of `ac`. It?s safe if C2 keeps a reference of the source oop for all safepoints.
>
> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - Merge branch 'master' into optimize_substring
>  - fix regression for x86-32
>    
>    if LP64 is off, the offset of AddP must be I instead of L.
>    x86 also doesn't emit encodeP/storeN. it use storeP instead.
>  - add a statistical counter for OptimizeTempArray.
>    
>    -XX:+PrintOptoStatistics shows it
>  - [SIM-JVM-450] support deoptimization v2
>    
>    because the src oop of scobj may be another scobj, deoptimization sort
>    all objects in topological order.
>    
>    separate creation of dst oop and reassignment of it.
>  - add a unit test for deoptimization
>  - [SIM-JVM-450] support deoptimization part2
>    
>    if OptimizeTempArray eliminates an AllocateArrayNode, scalar replacement will
>    create a nested SafePointScalarObjectNode for the field value:byte[] of j.l.String.
>    we use the nested sobj and an ObjectValue an envelope. it consists of 3 fields:
>    1. src 2. src_positio 3. length.
>    
>    deoptimizaton recognizes this ad-hoc ObjectValue and re-allocate an arrayOop
>    for the String object.
>  - enable OptimizeTempArray by default
>  - Merge branch 'master' into optimize_substring
>  - Revert "8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set"
>    
>    This reverts commit a49e34688d7d7c9d3c0d9c824d33f359613c2fc1.
>  - Revert "add a new bucket afterea_late_inlines"
>    
>    afterea_late_inlines bucket is not useful. revert it and its relevant changes
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/849f4c0f...21693ddd

src/hotspot/share/opto/macro.cpp line 1317:

> 1315: //
> 1316: //
> 1317: //  EncodeP:  delele because we don't need storeN

"delete" not "delele"

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

PR: https://git.openjdk.java.net/jdk/pull/2570

From simonis at openjdk.java.net  Wed Feb 17 17:49:40 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 17 Feb 2021 17:49:40 GMT
Subject: RFR: 8261731: shallow copy the internal buffer of a
 scalar-replaced java.lang.String object
In-Reply-To: <xWO8n5S298BWeViO7Bx5NQwEdN7IFnZb_lGTqD7js3k=.f9f2aceb-4716-482e-8fdf-65e52b034f22@github.com>
References: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
 <J428b0kfPbnDCzKiIX7-qDDXQ147AYWk_sJQmWLJuIo=.eedb676a-06d1-48a8-acd3-57f01f9ebd86@github.com>
 <l79YkCEGsxhNFa0vyR-K2n6-_M_ftqpzP6zYxoSr_-M=.e59bf74d-93af-4ce8-85bf-c2f0e376801d@github.com>
 <xWO8n5S298BWeViO7Bx5NQwEdN7IFnZb_lGTqD7js3k=.f9f2aceb-4716-482e-8fdf-65e52b034f22@github.com>
Message-ID: <pae6kYj6-K2WlPhPAnYwDW1yX-L18_LdvKohnjAvjl8=.4a39da86-2145-4e13-a729-4239a7178cc2@github.com>

On Wed, 17 Feb 2021 09:00:25 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> Hi,
>>> 
>>> this is a smart optimization.
>>> 
>>> > There are 3 nodes involving in the construction of a java.lang.String object.
>>> > ```
>>> > 1. Allocate of itself, aka. alloc
>>> > 
>>> > 2. AllocateArray of a byte array, which is value:byte[], aka. aa
>>> > 
>>> > 3. ArrayCopyNode which copys in the contents of value, aka. ac
>>> > ```
>>> > 
>>> > 
>>> > Lemma
>>> > When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.
>>> > Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.
>>> 
>>> Are you saying that the source of `ac` cannot be accessed by another thread because of the cloning in the constructor? But the resulting string instance which is used to construct the non-escape instance can be GlobalEscape and then the source of `ac` is accessible to other threads, isn't it?
>> 
>> Hi, @reinrich 
>> You might not know, but I learn how to reallocate an object in deoptimization from your previous patches. Thank you!
>> 
>> You are right. The source of ac (`src`) might be escaped.  I didn't say other threads can't access it. I said we need to guarantee the `src` is stable,  or  it's a "frozen" array in JDK-8261007. 
>> 
>> To be honest, I didn't check the src is frozen. In practice, I only see ArrayCopy in construction [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L769).This method is creating a new substring from an established array, so its value is `stable`. 
>> 
>> After I read your comment, I went through String.java. I do find one open-ended constructor. yes, it's a problem!
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L395
>> 
>> If the frozen attribute is not present, what I can come up with. an array is "stable". What's do you think?
>> 1) has annotation "stable" or
>> 2) it's non-escaped and
>> 3) can't find any store nodes along its mem stream.
>
> Hi @navyxliu,
> 
>> You might not know, but I learn how to reallocate an object in deoptimization from your previous patches. Thank you!
> 
> Oh, great! :)
> 
>> You are right. The source of ac (`src`) might be escaped. I didn't say other threads can't access it. I said we need to guarantee the `src` is stable, or it's a "frozen" array in JDK-8261007.
>> 
>> To be honest, I didn't check the src is frozen. In practice, I only see ArrayCopy in construction [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L769).This method is creating a new substring from an established array, so its value is `stable`.
> 
> Sorry, I wasn't aware of the @Stable annotation on the value array.
> 
> https://github.com/openjdk/jdk/blob/d19503353e5c347ce393544a3a30d5caec53d133/src/java.base/share/classes/java/lang/String.java#L154
> 
> So my concern was that another thread could for example use reflection to modify
> the value array but I reckon this is illegal then (I wonder if it is checked in
> reflection...).
> 
> Also there is already UseStringDeduplication that relies on the value array being stable.
> 
>> After I read your comment, I went through String.java. I do find one open-ended constructor. yes, it's a problem!
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L395
> 
> I see this one is deprecated. Why do you think there's a problem?
> 
>> If the frozen attribute is not present, what I can come up with. an array is "stable". What's do you think?
>> 
>>     1. has annotation "stable" or
>> 
>>     2. it's non-escaped and
>> 
>>     3. can't find any store nodes along its mem stream.
> 
> Currently I'd think this is not necessary. `@Stable` is strong enough.
> 
> The optimization reminds me a bit of earlier Java versions where String
> instances had an offset field and the value array could be shared among String
> instances.
> 
> I guess the new String needs to be scalarized mostly because you cannot take
> care of the offset otherwise.
> 
> Coincidentally I'm currently looking at
> [LoadNode::can_see_arraycopy_value()](https://github.com/openjdk/jdk/blob/b955f85e03bafe8ce39677d0af06bf1ceb7e2cbb/src/hotspot/share/opto/memnode.cpp#L951)
> which does something similar you want to do. There I don't see any concerns
> about the src being stable. In fact I don't think this is correct. Just a side
> mark...
> 
> These are my (somewhat random) thoughts so far. I'd think it is a legal and useful optimization (though haven't yet looked at the code yet).
> 
> Thanks, Richard.

What about GC? What happens if the original String isn't reachable any more? Do you put a reference to the byte array into the corresponding oop maps to make sure it can't be garbage collected?

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

PR: https://git.openjdk.java.net/jdk/pull/2570

From github.com+168222+mgkwill at openjdk.java.net  Wed Feb 17 17:51:18 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 17 Feb 2021 17:51:18 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values [v3]
In-Reply-To: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
Message-ID: <mP0RKkzc_6IduDBE3Y1dEuGbqWfC-B8X5a7mD0R1mTQ=.98d572ee-02a3-485f-8653-9b035abb6908@github.com>

> 8261671: X86 I2L conversion can be skipped for certain masked positive values
> 
> For the following expression:
>  (long)(value & mask)
> Where value is of int type and mask is constant (power of two ? 1), we can directly generate bzhi instruction to zero the upper bits instead of doing an andl, followed by movslq
> 
> Before:
> Benchmark Mode Cnt Score Error Units
> SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 10.679 ? 1.496 ns/op
> 
> 
> After:
> Benchmark Mode Cnt Score Error Units
> SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 7.870 ? 0.067 ns/op
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Revert to predicate supports_bmi2
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2590/files
  - new: https://git.openjdk.java.net/jdk/pull/2590/files/5dc976e2..2717297b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2590&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2590&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2590.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2590/head:pull/2590

PR: https://git.openjdk.java.net/jdk/pull/2590

From shade at redhat.com  Wed Feb 17 17:54:45 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Feb 2021 18:54:45 +0100
Subject: Intermittent JRuby json issue related to tiered or G1
In-Reply-To: <CAE-f1xTnrnUkGsTihYNwj08RYxwczOYomMyLqK7sBW65__1S+g@mail.gmail.com>
References: <CAE-f1xQ6a7L6pgY3rx18wdsbVtOfm+veiLknvGeUfDicrYKQuQ@mail.gmail.com>
 <1bac4d6a-e53d-075d-0209-6b737b7a2e77@redhat.com>
 <b7f97cdf-7111-0b5f-78e1-7f760b5d860b@redhat.com>
 <CAE-f1xRvKHzHDZQL3Nez+807ND6E=Pt0xE1BLxDfnxo72vWRDA@mail.gmail.com>
 <ead14606-cdfe-27fc-4bac-a9c5b5219e44@redhat.com>
 <7110e0cf-8c77-1d6d-8854-3160d5c901f8@redhat.com>
 <18a23eea-03a2-7f69-c4f4-4d22bddb3eb9@redhat.com>
 <CAE-f1xTnrnUkGsTihYNwj08RYxwczOYomMyLqK7sBW65__1S+g@mail.gmail.com>
Message-ID: <e7aef455-d655-7842-bf12-67c4c467ce7d@redhat.com>

On 2/17/21 6:28 PM, Charles Oliver Nutter wrote:
> Given your discoveries, I would have felt safe saying this is purely a
> tiered JIT issue... but our users have reported that switching away
> from G1 also eliminates the problem. Were they just lucky? Could there
> be a separate issue?

Having spent a day trying to reproduce the issue, I think the conditions under which this reproduces 
are very flaky, and minor things can change the reproducibility. The bug is in C2 code, and that 
code apparently takes a path that leads to the error, under some conditions that are not yet clear 
to me. Profile taking different shapes I think affects it the most, this is why it lead me to the 
unsuccessful reverse bisect. That minor profiling code adjustment dropped the incidence for about 
10x for me! Argh.

Maybe switching the GC does indeed lead the application away from the bug, I have no firm evidence 
about this. Note that all this time JDK 9+ was running with G1 without us knowing about this problem.

> I'm trying to come up with a short-term workaround with minimal
> impact. Switching GC may not be in the cards but disabling tiered
> compilation would probably be acceptable for production
> environments...if that is sufficient.

The short-term workaround should really come with:
   https://bugs.openjdk.java.net/browse/JDK-8261914

I plan to propose it for 16u and 11u backports once it hopefully lands in mainline.

I cannot see any diagnostic/experimental flag that would disable the problematic path in C2 
specifically. So without JDK-8261914, we are left with several nuclear options:
  a) disabling C2 completely with -XX:TieredStopAtLevel=1, which *would* affect performance;
  b) falling back to 8u, which does not have this C2 code at all

There is the "usual" workaround of disabling the affected method compilation with 
-XX:CompileCommand=exclude,<...> -- but that kinda hopes that only one method compilation is affected.

>   As always let me know if we can provide any more information. The
> affected JRuby users and I will continue monitoring.

I had run thousands of runs of the JRuby reproducer, and it works fine with JDK-8261914 defensive 
patch. Without it, it fails about 1 time out of 10 with the error that Freaky reported. So I am 
pretty confident it is the same issue. You might want to test it yourselves today, if you can build 
mainline JDK. Or wait for patches to land in mainline and pick up EA binaries to test.

-- 
Thanks,
-Aleksey


From github.com+168222+mgkwill at openjdk.java.net  Wed Feb 17 17:59:38 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 17 Feb 2021 17:59:38 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values [v3]
In-Reply-To: <oJiYz28iTQ_JktfAFJ5Nch_tpnAglj0_cQacicHviMA=.c3cfebbe-1b11-4c7f-925e-9133e7df1cfe@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
 <w1gx_PICRcRP7-gFat6a6FRZn8RuOm-yCU2prrhvGJQ=.335f6451-f279-4efc-b8c4-9ad02cd47d25@github.com>
 <9XBe7BRG8tFJ3ZHqmLa-MjmZWrJS0nIGKJzsjViGVoI=.007b2404-c93f-408e-a28e-c5491eeceb4e@github.com>
 <oJiYz28iTQ_JktfAFJ5Nch_tpnAglj0_cQacicHviMA=.c3cfebbe-1b11-4c7f-925e-9133e7df1cfe@github.com>
Message-ID: <y4WAlGqe4U8UmmL3xxJC-FNpDIsJ4XCMGx-C7ONC5xo=.558fd575-5034-4440-bd21-d85fad0e4a76@github.com>

On Wed, 17 Feb 2021 05:56:04 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> Added `predicate(VM_Version::supports_bmi2() && VM_Version::is_intel());`
>
> I'm so sorry, I confused this with `PDEP` and `PEXT`. `BZHI` is actually fine on Zen. So the original code is correct.

No worries @fweimer. I've reverted to the original. I looked at Agner's Optimization Guide but I couldn't find a place that said Zen 2 and earlier used microcode for BZHI. I guess we know why now ??. 

Happy to hear any other review comments.

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

PR: https://git.openjdk.java.net/jdk/pull/2590

From neliasso at openjdk.java.net  Wed Feb 17 18:16:02 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 17 Feb 2021 18:16:02 GMT
Subject: RFR: 8260653: Unreachable nodes keep speculative types alive [v3]
In-Reply-To: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
References: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
Message-ID: <x8meqvULp56xWEH4ObAN1-xHJ8t6FBwiBqo-M4ZjQSQ=.0ddd5297-1604-40dc-8618-e5f20f59aae3@github.com>

> The RunThese test fails because after first igvn.optimize() (directly after parsing) there are unreachable nodes cycles left. Later when remove_speculative_types() is called - only reachable nodes will have their speculative type removed. At the end of remove_speculative_types() there is an assert that all speculative types have been removed that will fail.
> 
> This problem will not cause crashes in production - it is only a sanity test.
> 
> I suggest adding a call to PhaseRemoveUseless before remove_speculative_types. This will cost a few extra cycles but it is the only way we can guarantee that no unreachable nodes are left.
> 
> When debugging this I experimented with adding a call to verify_graph_edges to check for dead code at the same spot. This triggers failures in a lot of test. The conclusion is that it is very common that we have dead node cycles - but they very rarely keep speculative types alive.
> 
> A big thank you to Dean Long how created the reproducer for this bug.
> 
> Please review.

Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:

  Remove outcnt check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2606/files
  - new: https://git.openjdk.java.net/jdk/pull/2606/files/82ab1066..ac23dad8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2606&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2606&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2606/head:pull/2606

PR: https://git.openjdk.java.net/jdk/pull/2606

From neliasso at openjdk.java.net  Wed Feb 17 18:16:04 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 17 Feb 2021 18:16:04 GMT
Subject: RFR: 8260653: Unreachable nodes keep speculative types alive [v2]
In-Reply-To: <oN_y9d4fFOtpZiI1Kl3F80p5xIAMwuAOsz0adjKjwNQ=.2e68ed29-04eb-4b9d-ae2e-b336eed57ba9@github.com>
References: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
 <Zz6l0ZrId5aDC1TwCdPNJvIpyp1mjqT122vxiyzypeI=.7e6c7df3-fa0c-4fba-bf74-9f304a56b2ec@github.com>
 <oN_y9d4fFOtpZiI1Kl3F80p5xIAMwuAOsz0adjKjwNQ=.2e68ed29-04eb-4b9d-ae2e-b336eed57ba9@github.com>
Message-ID: <LCKA1855YBCqweiLaf06DXR2EXfR30eN_C9AeqYu8SI=.da73366a-f538-4824-b412-9554c98746dc@github.com>

On Wed, 17 Feb 2021 16:34:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check if node is live before assert
>
> src/hotspot/share/opto/phaseX.cpp line 341:
> 
>> 339:        n != sentinel_node &&
>> 340:        n->is_Type() &&
>> 341:        n->outcnt() > 0 &&
> 
> `live_nodes.member(n)` makes ` n->outcnt() > 0` redundant, doesn't it?

Yes it does. I've updated the patch.

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

PR: https://git.openjdk.java.net/jdk/pull/2606

From kvn at openjdk.java.net  Wed Feb 17 18:35:49 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 17 Feb 2021 18:35:49 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values [v3]
In-Reply-To: <mP0RKkzc_6IduDBE3Y1dEuGbqWfC-B8X5a7mD0R1mTQ=.98d572ee-02a3-485f-8653-9b035abb6908@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
 <mP0RKkzc_6IduDBE3Y1dEuGbqWfC-B8X5a7mD0R1mTQ=.98d572ee-02a3-485f-8653-9b035abb6908@github.com>
Message-ID: <f8irdDxXm7Y9ofiCIlNyC7IwXQ58fdVqY7K8dbtbCP4=.f48f559b-2ab1-48cc-bfd7-319fdfc34ca0@github.com>

On Wed, 17 Feb 2021 17:51:18 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> 8261671: X86 I2L conversion can be skipped for certain masked positive values
>> 
>> For the following expression:
>>  (long)(value & mask)
>> Where value is of int type and mask is constant (power of two ? 1), we can directly generate bzhi instruction to zero the upper bits instead of doing an andl, followed by movslq
>> 
>> Before:
>> Benchmark Mode Cnt Score Error Units
>> SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 10.679 ? 1.496 ns/op
>> 
>> 
>> After:
>> Benchmark Mode Cnt Score Error Units
>> SkipIntToLongCast.skipMaskedSmallPositiveCast avgt 15 7.870 ? 0.067 ns/op
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert to predicate supports_bmi2
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Please, add a test which verifies result of generated code for different ranges of mask (especially corner cases). See `compiler//codegen/BMI1.java`
There are also example of verification of generated assembler in `compiler//intrinsics/bmi/`

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

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2590

From github.com+2249648+johntortugo at openjdk.java.net  Wed Feb 17 18:41:39 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Wed, 17 Feb 2021 18:41:39 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler
In-Reply-To: <tkbrhYmDEyHlWeaFc4NOfOsw4Q2Fbtrb-8BJ5U-sE6Y=.3b3ad8d6-75cd-4f92-a7b3-775385f40e3a@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <vP-nQAbUU0P54kYGCK8R2cc_OBIRCk0P3TX_mgM4th8=.5cdfad98-051b-489c-9546-8f967ce2c720@github.com>
 <0azhJ4pD5Tq_lkpPtYMpQBjokflcSQEdWP2Rz9HBm6k=.c3ece6fd-1ae7-49ea-a6eb-ec88a9fbd54d@github.com>
 <d40n9RxaYEqp-6UU7qDQ9rJYrSZ0gXKTT9jqTlylfvU=.8fbcfe20-5f2e-48e8-a189-771701645d9b@github.com>
 <ZFXn-510nHc4-xULSEQooZYTQ2Uou6FM58KtImAUSsQ=.bf925331-cef6-4708-b49d-754df02fe8e1@github.com>
 <EWOKWpa98hBLypluJEurop0QC8n-mjDhklaW0cMgh0k=.2ed3d200-a559-47d2-abda-e711898f3fd2@github.com>
 <tkbrhYmDEyHlWeaFc4NOfOsw4Q2Fbtrb-8BJ5U-sE6Y=.3b3ad8d6-75cd-4f92-a7b3-775385f40e3a@github.com>
Message-ID: <7o74mtnumvPhVoz48udS6UTCoX39kjgfCU3jrogHQeg=.506c281b-38a4-42fa-bdf9-9214e49c5b8a@github.com>

On Wed, 17 Feb 2021 09:47:13 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Thank you all for the feedback!
>> 
>> @iklam - I'll check that and let you know once I make more conversions.
>> 
>> @dean-long - That would be great. I'm all ears for the best way to test this!
>
> Here's one way to test both versions, using loadRange as an example.  It's not exactly pretty, but it seems to work.
> [loadRange.txt](https://github.com/openjdk/jdk/files/5994725/loadRange.txt)

@dean-long - I recently hacked something pretty similar - basically, I added a flag to the CodeSection class to make it print emitted bytes whenever the flag was set, then I created two encoding classes in the AD file to toggle the print flag. That way I was able to _visually_ compare the output of the two versions of the code. Your approach with the CRC is much better. Thanks a lot!

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

PR: https://git.openjdk.java.net/jdk/pull/2420

From github.com+168222+mgkwill at openjdk.java.net  Wed Feb 17 18:57:41 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 17 Feb 2021 18:57:41 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values [v3]
In-Reply-To: <f8irdDxXm7Y9ofiCIlNyC7IwXQ58fdVqY7K8dbtbCP4=.f48f559b-2ab1-48cc-bfd7-319fdfc34ca0@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
 <mP0RKkzc_6IduDBE3Y1dEuGbqWfC-B8X5a7mD0R1mTQ=.98d572ee-02a3-485f-8653-9b035abb6908@github.com>
 <f8irdDxXm7Y9ofiCIlNyC7IwXQ58fdVqY7K8dbtbCP4=.f48f559b-2ab1-48cc-bfd7-319fdfc34ca0@github.com>
Message-ID: <BhCE_lJUnm9jvEhMDPMigwzSGUNIy-1E0VZ2njYHwzw=.4c534aae-4881-4939-8b2e-92a971c28003@github.com>

On Wed, 17 Feb 2021 18:33:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Please, add a test which verifies result of generated code for different ranges of mask (especially corner cases). See `compiler//codegen/BMI1.java`
> There are also example of verification of generated assembler in `compiler//intrinsics/bmi/`

I'm taking a look at a test to verify generated code like the BMI1 test you suggest above.

There is a current test that verifies operation indirectly (both long to int and int to long): test/hotspot/jtreg/compiler/c2/TestSkipLongToIntCast.java

Do we need both? A number of similar patches have been merged without, https://hg.openjdk.java.net/jdk/jdk/rev/d0f55423e913 for example.

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

PR: https://git.openjdk.java.net/jdk/pull/2590

From github.com+42899633+eastig at openjdk.java.net  Wed Feb 17 19:20:42 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 17 Feb 2021 19:20:42 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v4]
In-Reply-To: <AgJYY86bXzz7lUOV8DCLBFgMZfm_dqdcs1x8ytcARS8=.6da2a1ad-99c0-4328-9fb5-00978bcf5722@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <w-2JkDuXk-wAeMBvrZm8MS2OI3jADcEEELDRmZ16S48=.84db5012-0b2a-49ce-adb4-038cf59ce423@github.com>
 <AgJYY86bXzz7lUOV8DCLBFgMZfm_dqdcs1x8ytcARS8=.6da2a1ad-99c0-4328-9fb5-00978bcf5722@github.com>
Message-ID: <P-TsBeV-bxp6GFNqNhEW2l4401VEEsC6iM5MuJbmdoc=.5c0b1ac2-479f-49df-8b0a-765853b125a1@github.com>

On Wed, 17 Feb 2021 12:04:56 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>>    
>>    reimplement this feature. withdraw my intrusive change in outputStream.
>>    use stringStream only for the constant OopPtr. after oop->print_on(st),
>>    delete all appearances of '\n'
>>  - Merge branch 'master' into JDK-8260198
>>  - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>>    
>>    fix merge conflict.
>>  - Merge branch 'master' into JDK-8260198
>>  - 8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>>    
>>    Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
>>    Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
>>    Remove the comment because Klass::oop_print_on() has emitted the address of oop.
>>    
>>    Before:
>>    689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
>>    {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
>>     - string: "a"
>>     :Constant:exact *
>>    
>>    After:
>>    689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *
>
> src/hotspot/share/opto/type.cpp line 4049:
> 
>> 4047:       ss.print(" ");
>> 4048:       const_oop()->print_oop(&ss);
>> 4049:       ss.tr_delete('\n');
> 
> `tr_delete` is expensive. Also deleting something in a stream does not fit into a concept of streams.
> I see that the content of `ss` is traversed many times.
> What about this code:
> for (const char *str = ss.base(); *str; ) {
>   size_t i = 0;
>   while (str[i] && str[i] != '\n' ) {
>        ++i;
>   }
>   st->print_raw(str, i);
>   str += i;
>   while (*str == '\n') {
>     ++str;
>   }
> }

Another option:
class filterStringStream: public stringStream {
private:
  char ch;
public:
  filterStringStream(char ch_to_filter, size_t initial_bufsize = 256) : stringStream(initial_bufsize), ch(ch_to_filter) {}

  virtual void write(const char* c, size_t len) override {
    const char* e = c + len;
    while (c != e) {
      size_t i = 0;
      while ((c+i) != e && c[i] != ch ) {
        ++i;
      }
      stringStream::write(c, i);
      c += i;
      while (c != e && *ch == ch) {
        ++c;
      }
    }     
  }
};

Your code will be:
filterStringStream ss('\n');
ss.print(" ");
const_oop->print_oop(&ss);
st->print_raw(ss.base(), ss,size());

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From github.com+42899633+eastig at openjdk.java.net  Wed Feb 17 19:25:40 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 17 Feb 2021 19:25:40 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v4]
In-Reply-To: <P-TsBeV-bxp6GFNqNhEW2l4401VEEsC6iM5MuJbmdoc=.5c0b1ac2-479f-49df-8b0a-765853b125a1@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <w-2JkDuXk-wAeMBvrZm8MS2OI3jADcEEELDRmZ16S48=.84db5012-0b2a-49ce-adb4-038cf59ce423@github.com>
 <AgJYY86bXzz7lUOV8DCLBFgMZfm_dqdcs1x8ytcARS8=.6da2a1ad-99c0-4328-9fb5-00978bcf5722@github.com>
 <P-TsBeV-bxp6GFNqNhEW2l4401VEEsC6iM5MuJbmdoc=.5c0b1ac2-479f-49df-8b0a-765853b125a1@github.com>
Message-ID: <WK0tOkED6xG1ior27fuZNegOCndT-rNDX5pLFtW2lMU=.b6d0d67a-2bed-49bc-82aa-4262cdd383be@github.com>

On Wed, 17 Feb 2021 19:16:59 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> src/hotspot/share/opto/type.cpp line 4049:
>> 
>>> 4047:       ss.print(" ");
>>> 4048:       const_oop()->print_oop(&ss);
>>> 4049:       ss.tr_delete('\n');
>> 
>> `tr_delete` is expensive. Also deleting something in a stream does not fit into a concept of streams.
>> I see that the content of `ss` is traversed many times.
>> What about this code:
>> for (const char *str = ss.base(); *str; ) {
>>   size_t i = 0;
>>   while (str[i] && str[i] != '\n' ) {
>>        ++i;
>>   }
>>   st->print_raw(str, i);
>>   str += i;
>>   while (*str == '\n') {
>>     ++str;
>>   }
>> }
>
> Another option:
> class filterStringStream: public stringStream {
> private:
>   char ch;
> public:
>   filterStringStream(char ch_to_filter, size_t initial_bufsize = 256) : stringStream(initial_bufsize), ch(ch_to_filter) {}
> 
>   virtual void write(const char* c, size_t len) override {
>     const char* e = c + len;
>     while (c != e) {
>       size_t i = 0;
>       while ((c+i) != e && c[i] != ch ) {
>         ++i;
>       }
>       stringStream::write(c, i);
>       c += i;
>       while (c != e && *ch == ch) {
>         ++c;
>       }
>     }     
>   }
> };
> 
> Your code will be:
> filterStringStream ss('\n');
> ss.print(" ");
> const_oop->print_oop(&ss);
> st->print_raw(ss.base(), ss,size());

> `tr_delete` is expensive. Also deleting something in a stream does not fit into a concept of streams.
> I see that the content of `ss` is traversed many times.
> What about this code:
> 
> ```
> for (const char *str = ss.base(); *str; ) {
>   size_t i = 0;
>   while (str[i] && str[i] != '\n' ) {
>        ++i;
>   }
>   st->print_raw(str, i);
>   str += i;
>   while (*str == '\n') {
>     ++str;
>   }
> }
> ```

You can put this code in a function like `print_filtering_ch(char, const stringStream&, outputStream*)`

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From vladimir.kozlov at oracle.com  Wed Feb 17 20:05:13 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 17 Feb 2021 12:05:13 -0800
Subject: [External] : Re: SuperWord loop optimization lost after method
 inlining
In-Reply-To: <CAOqmmc1PKCWgC0n+7WkFDz7vAzxfLpZH4ThQnSL=6yQO5Ghrxg@mail.gmail.com>
References: <CAOqmmc0ue3bLMBgWLAvUOrHLe2iNtoSiBiq=+Beky-D=MkA+fw@mail.gmail.com>
 <b9184f85-c869-8088-a080-2d860dca5f9f@oracle.com>
 <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
 <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>
 <CAOqmmc2mWWr2mWoitEz71xc1PZ53ZLhyDfRQ+TjxKRcuGcxNkg@mail.gmail.com>
 <08ce2121-bbb4-3ea5-8f05-efeb33df7b74@oracle.com>
 <CAOqmmc1PKCWgC0n+7WkFDz7vAzxfLpZH4ThQnSL=6yQO5Ghrxg@mail.gmail.com>
Message-ID: <09a53249-00de-91c1-d88b-6c816ce6dd14@oracle.com>

Unfortunately it is still not the file I am looking for.

First, remove -XX:+PrintAssembly flag from command line. I have already files with assembler code.

Second, I see link to the file I am looking for:
<thread_logfile thread='16812' filename='C:\Users\NicolasHeutte\AppData\Local\Temp\\hs_c16812_pid15016.log'/>

If you still have it, please send it. If application stopped before normal exit that file is not merged into 
hotspot_pid<PID>.log file.

If you don't have it - do an other run with -XX:CICompilerCount=1 to use only one C2 compiler thread with Tiered off. It 
will simplify ordering of log.

You can also do an other experiment without collecting log. Run app with next flags to disable loop strip minning 
optimization:  -XX:-UseCountedLoopSafepoints -XX:LoopStripMiningIter=0

Thanks,
Vladimir K

On 2/17/21 2:34 AM, Nicolas Heutte wrote:
> Hi Vladimir,
> 
> I have rerun the test with the appropriate options, the obtained logs are in this folder: 
> https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing 
> <https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvvSUuoKhQ$>
> 
> Best regards,
> Nicolas Heutte
> 
> On Tue, Feb 16, 2021 at 11:35 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>     Hi Nicolas,
> 
>     The file you shared has only assembler code. Yes, it shows that when ArrayFloatToArrayFloatVectorBinding::plus() is
>     inlined into AVector::plus() it is not vectorized.
> 
>     But I asked for an other file (hotspot_pid<PID>.log) which is generated when you run app with
>     -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation flags. It should start with:
> 
>     <?xml version='1.0' encoding='UTF-8'?>
>     <hotspot_log version='160 1' process='2302014' time_ms='1613514688748'>
>     <vm_version>
>     <name>
>     Java HotSpot(TM) 64-Bit Server VM
>     </name>
>     <release>
>     11.0.9+7-LTS
>     </release>
> 
>     Thanks,
>     Vladimir K
> 
>     On 2/15/21 5:19 AM, Nicolas Heutte wrote:
>      > Hi Vladimir,
>      >
>      > I've tried disabling tiered compilation, as you requested. It seems that the inlining was performed slightly
>      > differently, but the issue remains. As you can see in this excerpt, the main loop isn't properly vectorized:
>      >
>      >? ? 0x00000254b0d4bf54: cmp ? ?%r11d,%r8d
>      >? ? 0x00000254b0d4bf57: jae ? ?0x00000254b0d4c19e
>      >? ? 0x00000254b0d4bf5d: vmovss 0x10(%rcx,%r8,4),%xmm9 ?;*faload {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54 (line 41)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>     (line 118)
>      >
>      >? ? 0x00000254b0d4bf64: cmp ? ?%ebx,%r8d
>      >? ? 0x00000254b0d4bf67: jae ? ?0x00000254b0d4c1ec
>      >? ? 0x00000254b0d4bf6d: vaddss 0x10(%rdi,%r8,4),%xmm9,%xmm9
>      >? ? 0x00000254b0d4bf74: vmovss %xmm9,0x10(%rcx,%r8,4) ?;*fastore {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61 (line 41)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>     (line 118)
>      >
>      >? ? 0x00000254b0d4bf7b: inc ? ?%r8d ? ? ? ? ? ? ? ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62 (line 40)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>     (line 118)
>      >
>      >? ? 0x00000254b0d4bf7e: cmp ? ?%r9d,%r8d
>      >? ? 0x00000254b0d4bf81: jl ? ? 0x00000254b0d4bf54 ?;*goto {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65 (line 40)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>     (line 118)
>      >
>      >
>      >
>      > Here is the link to the full log, should you want to take a look at it:
>      > https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing
>     <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvuMpg6inQ$>
> 
>      >
>     <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$
>     <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$>>
>      >
>      > Best regards,
>      > Nicolas Heutte
>      >
>      > On Thu, Feb 11, 2021 at 7:05 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
>     <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>> wrote:
>      >
>      >? ? ?Changing wide mailing list to JIT compiler only.
>      >
>      >? ? ?This deoptimization is normal in Tiered Compilation - it switched from profiling code (level='3') generated by C1
>      >? ? ?compiler to new code generated by C2 (level='4') which does loop optimizations.
>      >
>      >? ? ?Thank you for posting inlining information:
>      >
>      >? ? ? ? ? ?@ 17? ?com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69 bytes) inline (hot)
>      >? ? ? ? ? ? ? \-> TypeProfile (14054/14054 counts) = com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
>      >
>      >? ? ?I thought before that may be call site is not hot but it is not the case.
>      >
>      >? ? ?You can do an other experiment to collect log with disabled Tiered Compilation (only C2 is used):
>     -XX:-TieredCompilation
>      >? ? ?Also print assembler code (as you did before) for final compilation to see if loop is still not vectorized.
>      >
>      >? ? ?Is it possible to post log file (on GitHub?) for me to look?
>      >
>      >? ? ?Thanks,
>      >? ? ?Vladimir K
>      >
>      >? ? ?On 2/11/21 6:28 AM, Nicolas Heutte wrote:
>      >? ? ? > Hi?Vladimir,
>      >? ? ? >
>      >? ? ? > Thank you for your help.
>      >? ? ? >
>      >? ? ? > I'm currently running Java 11.0.9, and I did not use any VM flag of note.
>      >? ? ? >
>      >? ? ? > I checked the content of the compilation log, and it seems that
>     ArrayFloatToArrayFloatVectorBinding::plus() was
>      >? ? ? > deoptimized in order to allow AVector::plus() to be compiled:
>      >? ? ? >
>      >? ? ? > <writer thread='11576'/>
>      >? ? ? > <task_queued compile_id='17280' method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V'
>     bytes='23'
>      >? ? ? > count='916' iicount='916' level='3' stamp='7394.056' comment='tiered' hot_count='896'/>
>      >? ? ? > <writer thread='15784'/>
>      >? ? ? > <deoptimized thread='15784' reason='constraint' pc='0x00000296d0785b94' compile_id='17257' compiler='c1'
>     level='3'>
>      >? ? ? > <jvms bci='65' method='com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding plus
>      >? ? ? > (Lcom/qfs/vector/IVector;Lcom/qfs/vector/IVector;)V' bytes='69' count='909' backedge_count='155602'
>     iicount='910'/>
>      >? ? ? > </deoptimized>
>      >? ? ? >
>      >? ? ? > The last compilation entry for AVector::plus() is:
>      >? ? ? >
>      >? ? ? > <writer thread='16380'/>
>      >? ? ? > <nmethod compile_id='17317' compiler='c2' level='4' entry='0x00000296d6af32c0' size='1960'
>      >? ? ?address='0x00000296d6af3110'
>      >? ? ? > relocation_offset='376' insts_offset='432' stub_offset='1040' scopes_data_offset='1152'
>     scopes_pcs_offset='1592'
>      >? ? ? > dependencies_offset='1880' nul_chk_table_offset='1896' oops_offset='1064' metadata_offset='1072'
>      >? ? ? > method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V' bytes='23' count='172425'
>     iicount='172425'
>      >? ? ? > stamp='7394.199'/>
>      >? ? ? > <make_not_entrant thread='16380' compile_id='17280' compiler='c1' level='2' stamp='7394.199'/>
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 1 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes)  
>     inline
>      >? ? ?(hot)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14552/14552 counts) =
>     com/qfs/vector/array/impl/ArrayFloatVector
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 7 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes)  
>     inline
>      >? ? ?(hot)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14150/14150 counts) =
>     com/qfs/vector/array/impl/ArrayFloatVector
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 10 ? com.qfs.vector.binding.impl.VectorBindings::getBinding (9 bytes)  
>     inline (hot)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 5
>      >? ? ?com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::getBinding (22
>      >? ? ? > bytes) ? inline (hot)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 3
>      >? ? ?com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::hasBinding
>      >? ? ? > (34 bytes) ? inline (hot)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 17  
>     com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
>      >? ? ?bytes)
>      >? ? ? > inline (hot)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14054/14054 counts) =
>      >? ? ? > com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 12 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)  
>     inline (hot)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 22 ? com.qfs.vector.impl.AVector::checkIndex (37 bytes) ? inline (hot)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 6 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)  
>     inline (hot)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 27 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)
>      >? ? ?accessor
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 34 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)
>      >? ? ?accessor
>      >? ? ? > <writer thread='15896'/>
>      >? ? ? >
>      >? ? ? > Unfortunately, I do not have access to a debug VM build, so I cannot run the second test you recommend.
>      >? ? ? >
>      >? ? ? > Best regards,
>      >? ? ? > Nicolas Heutte
>      >? ? ? >
>      >? ? ? > On Wed, Feb 10, 2021 at 7:36 PM Vladimir Kozlov <vladimir.kozlov at oracle.com
>     <mailto:vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>
>      >? ? ?<mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com
>     <mailto:vladimir.kozlov at oracle.com>>>> wrote:
>      >? ? ? >
>      >? ? ? >? ? ?Hi, Nicolas
>      >? ? ? >
>      >? ? ? >? ? ?Looks like, when inlined, the loop from ArrayFloatToArrayFloatVectorBinding::plus() was not optimized
>     at all:
>      >? ? ?it is not
>      >? ? ? >? ? ?unrolled and has range checks. Such loops are not vectorized (you need unrolling and no checks).
>      >? ? ? >
>      >? ? ? >? ? ?What Java version you are running? What HotSpot VM flags you are using when running application?
>      >? ? ? >
>      >? ? ? >? ? ?Run application with -XX:+LogCompilation and look on compilation data in hotspot_pid<PID>.log file for
>     caller
>      >? ? ? >? ? ?AVector::plus().
>      >? ? ? >
>      >? ? ? >? ? ?VM also has several flags to trace loop optimizations but they are only available in debug VM build.
>     If you
>      >? ? ?have access
>      >? ? ? >? ? ?to such build run with -XX:+PrintCompilation -XX:+TraceLoopOpts flags.
>      >? ? ? >
>      >? ? ? >? ? ?Thanks,
>      >? ? ? >? ? ?Vladimir K
>      >? ? ? >
>      >? ? ? >? ? ?On 2/10/21 9:24 AM, Nicolas Heutte wrote:
>      >? ? ? >? ? ? > Hi all,
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > I am encountering a performance issue caused by the interaction between
>      >? ? ? >? ? ? > method inlining and automatic vectorization.
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > Our application aggregates arrays intensively using a method named
>      >? ? ? >? ? ? > ArrayFloatToArrayFloatVectorBinding.plus() with the following code:
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? for (int i = 0; i < srcLen; ++i) {
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? dstArray[i] += srcArray[i];
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? }
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > When we microbenchmark this method we observe fast performance close to the
>      >? ? ? >? ? ? > practical memory bandwidth and when we print the assembly code we observe
>      >? ? ? >? ? ? > loop unrolling and automatic vectorization with SIMD instructions.
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600abf0: vmovdqu 0x10(%r14,%r13,4),%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600abf7: vaddps 0x10(%rcx,%r13,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600abfe: vmovdqu %ymm0,0x10(%r14,%r13,4)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac05: movslq %r13d,%r11
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac08: vmovdqu 0x30(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac0f: vaddps 0x30(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac16: vmovdqu %ymm0,0x30(%r14,%r11,4)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac1d: vmovdqu 0x50(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac24: vaddps 0x50(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac2b: vmovdqu %ymm0,0x50(%r14,%r11,4)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac32: vmovdqu 0x70(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac39: vaddps 0x70(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac40: vmovdqu %ymm0,0x70(%r14,%r11,4)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac47: vmovdqu 0x90(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac51: vaddps 0x90(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac5b: vmovdqu %ymm0,0x90(%r14,%r11,4)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac65: vmovdqu 0xb0(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac6f: vaddps 0xb0(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac79: vmovdqu %ymm0,0xb0(%r14,%r11,4)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac83: vmovdqu 0xd0(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac8d: vaddps 0xd0(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600ac97: vmovdqu %ymm0,0xd0(%r14,%r11,4)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600aca1: vmovdqu 0xf0(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600acab: vaddps 0xf0(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600acb5: vmovdqu %ymm0,0xf0(%r14,%r11,4)? ;*fastore
>      >? ? ? >? ? ? > {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>      >? ? ? >? ? ? > (line 41)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600acbf: add? ? $0x40,%r13d? ? ? ? ;*iinc {reexecute=0
>      >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>      >? ? ? >? ? ? > (line 40)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600acc3: cmp? ? %eax,%r13d
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef4600acc6: jl? ? ?0x000001ef4600abf0? ;*goto {reexecute=0
>      >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>      >? ? ? >? ? ? > (line 40)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > In the real application, this method is actually inlined in a higher level
>      >? ? ? >? ? ? > method named AVector.plus(). Unfortunately, the inlined version of the
>      >? ? ? >? ? ? > aggregation code is not vectorized anymore:
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180a0: cmp? ? %ebx,%r11d
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180a3: jae? ? 0x000001ef460180e6
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180a5: vmovss 0x10(%r8,%r11,4),%xmm1? ;*faload {reexecute=0
>      >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
>      >? ? ? >? ? ? > (line 41)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180ac: cmp? ? %ecx,%r11d
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180af: jae? ? 0x000001ef46018104
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180b1: vaddss 0x10(%r9,%r11,4),%xmm1,%xmm1
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180b8: vmovss %xmm1,0x10(%r8,%r11,4)? ;*fastore {reexecute=0
>      >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>      >? ? ? >? ? ? > (line 41)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180bf: inc? ? %r11d? ? ? ? ? ? ? ;*iinc {reexecute=0
>      >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>      >? ? ? >? ? ? > (line 40)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180c2: cmp? ? %r10d,%r11d
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? 0x000001ef460180c5: jl? ? ?0x000001ef460180a0? ;*goto {reexecute=0
>      >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>      >? ? ? >? ? ? > (line 40)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > This causes a significant performance drop, compared to a run where we
>      >? ? ? >? ? ? > explicitly disable the inlining and observe automatically vectorized code
>      >? ? ? >? ? ? > again (
>      >? ? ? >? ? ? > -XX:CompileCommand=dontinline,com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding.plus
>      >? ? ? >? ? ? > ).
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > How do you guys explain that behavior of the JIT compiler? Is this a known
>      >? ? ? >? ? ? > and tracked issue, could it be fixed in the JVM? Can we do something in the
>      >? ? ? >? ? ? > java code to prevent this from happening?
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > Best regards,
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > Nicolas Heutte
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >
> 

From kvn at openjdk.java.net  Wed Feb 17 20:41:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 17 Feb 2021 20:41:39 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values [v3]
In-Reply-To: <BhCE_lJUnm9jvEhMDPMigwzSGUNIy-1E0VZ2njYHwzw=.4c534aae-4881-4939-8b2e-92a971c28003@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
 <mP0RKkzc_6IduDBE3Y1dEuGbqWfC-B8X5a7mD0R1mTQ=.98d572ee-02a3-485f-8653-9b035abb6908@github.com>
 <f8irdDxXm7Y9ofiCIlNyC7IwXQ58fdVqY7K8dbtbCP4=.f48f559b-2ab1-48cc-bfd7-319fdfc34ca0@github.com>
 <BhCE_lJUnm9jvEhMDPMigwzSGUNIy-1E0VZ2njYHwzw=.4c534aae-4881-4939-8b2e-92a971c28003@github.com>
Message-ID: <PoFfSVn36xb6ce7gS4FIStfkw33C8TFSBPHLF_cE5K8=.a33936a4-0be4-4209-ae06-23a11340e489@github.com>

On Wed, 17 Feb 2021 18:54:27 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

> > Please, add a test which verifies result of generated code for different ranges of mask (especially corner cases). See `compiler//codegen/BMI1.java`
> > There are also example of verification of generated assembler in `compiler//intrinsics/bmi/`
> 
> I'm taking a look at a test to verify generated code like the BMI1 test you suggest above.
> 
> There is a current test that verifies operation indirectly (both long to int and int to long): test/hotspot/jtreg/compiler/c2/TestSkipLongToIntCast.java

It does not cover your case which have `AND` operation.
But I am fine if you add your case to it (or to other test, like BMI1.java) instead of creating new test file.

> 
> Do we need both? A number of similar patches have been merged without, https://hg.openjdk.java.net/jdk/jdk/rev/d0f55423e913 for example.

Missing tests in previous changes does not mean we should never create one.

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

PR: https://git.openjdk.java.net/jdk/pull/2590

From kvn at openjdk.java.net  Wed Feb 17 20:58:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 17 Feb 2021 20:58:39 GMT
Subject: RFR: 8261912: Code IfNode::fold_compares_helper more defensively
In-Reply-To: <Rg0yooo3hewsAfa-xDbOeoFkalN00IP9QkzxSJlLPxE=.c9daa643-a16d-46b4-8f87-50565d6a0249@github.com>
References: <Rg0yooo3hewsAfa-xDbOeoFkalN00IP9QkzxSJlLPxE=.c9daa643-a16d-46b4-8f87-50565d6a0249@github.com>
Message-ID: <7HF5Z1YIB9wuETTkYCSUT390U6dmwodQWGM7_ieT8Jw=.c1aab00e-970d-4c26-8657-44785b3434b4@github.com>

On Wed, 17 Feb 2021 16:11:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As [JDK-8261914](https://bugs.openjdk.java.net/browse/JDK-8261914) indicates, there are cases that break the internal asserts in `IfNode::fold_compares_helper`, code added by JDK-8073480 in JDK 9. Unfortunately, release builds would happily miscompile when that happens. It would be better to code `IfNode::fold_compares_helper` more defensively, so it bails when asserts are violated. This implicitly works around the bug in JDK-8261914. The goal for this limited workaround is to be trivially backportable in order to quickly unbreak 11u, 16u and 17.
> 
> The alternative is, instead of the early returns is to do:
> 
>  lo = NULL;
>  hi = NULL;
> 
> ...and then wait for for the method epilog to handle it. I have no preference to either style, as the blocks this patch affects already has some early returns, and `lo/hi = NULL` are also used.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x]  Linux x86_64 fastdebug `tier2`
>  - [x] Failing JRuby reproducer from JDK-8261914, now passing in release mode with hundreds of iterations

I am fine with this defensive change.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2610

From github.com+168222+mgkwill at openjdk.java.net  Wed Feb 17 21:07:39 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 17 Feb 2021 21:07:39 GMT
Subject: RFR: 8261671: X86 I2L conversion can be skipped for certain
 masked positive values [v3]
In-Reply-To: <PoFfSVn36xb6ce7gS4FIStfkw33C8TFSBPHLF_cE5K8=.a33936a4-0be4-4209-ae06-23a11340e489@github.com>
References: <9PGauj5SuzWCyX7aTFHTUCEsK5kVH2ApKAurSK3o_To=.f20e9936-352f-47f0-a561-98dcdb7c842e@github.com>
 <mP0RKkzc_6IduDBE3Y1dEuGbqWfC-B8X5a7mD0R1mTQ=.98d572ee-02a3-485f-8653-9b035abb6908@github.com>
 <f8irdDxXm7Y9ofiCIlNyC7IwXQ58fdVqY7K8dbtbCP4=.f48f559b-2ab1-48cc-bfd7-319fdfc34ca0@github.com>
 <BhCE_lJUnm9jvEhMDPMigwzSGUNIy-1E0VZ2njYHwzw=.4c534aae-4881-4939-8b2e-92a971c28003@github.com>
 <PoFfSVn36xb6ce7gS4FIStfkw33C8TFSBPHLF_cE5K8=.a33936a4-0be4-4209-ae06-23a11340e489@github.com>
Message-ID: <We15djUGa32gIrTakMkPPi_J-gCjZyOVqbHqOZEC5DE=.2f589611-9f0f-4562-a3ba-ee294a49e493@github.com>

On Wed, 17 Feb 2021 20:38:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > > Please, add a test which verifies result of generated code for different ranges of mask (especially corner cases). See `compiler//codegen/BMI1.java`
> > > There are also example of verification of generated assembler in `compiler//intrinsics/bmi/`
> > 
> > 
> > I'm taking a look at a test to verify generated code like the BMI1 test you suggest above.
> > There is a current test that verifies operation indirectly (both long to int and int to long): test/hotspot/jtreg/compiler/c2/TestSkipLongToIntCast.java
> 
> It does not cover your case which have `AND` operation.
> But I am fine if you add your case to it (or to other test, like BMI1.java) instead of creating new test file.
> 
> > Do we need both? A number of similar patches have been merged without, https://hg.openjdk.java.net/jdk/jdk/rev/d0f55423e913 for example.
> 
> Missing tests in previous changes does not mean we should never create one.

Thanks @vnkozlov. 

In the process of testing both a BMI2.java and compiler/intrinsics/bmi/verifycode/BzhiTest.java addition I have written to test this change.

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

PR: https://git.openjdk.java.net/jdk/pull/2590

From github.com+10482586+therealeliu at openjdk.java.net  Thu Feb 18 02:02:39 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Thu, 18 Feb 2021 02:02:39 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <eMXlyYEeHkAIqUy8JwPoq1qPoqWrP2z7RDw7e3u_V_s=.00c9dd59-a602-49bc-a397-88534a3e6c61@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>
 <eMXlyYEeHkAIqUy8JwPoq1qPoqWrP2z7RDw7e3u_V_s=.00c9dd59-a602-49bc-a397-88534a3e6c61@github.com>
Message-ID: <R4v2kpBge_gW3SD0lNVv8JhWp3oUkx7yQDYd2soenNE=.3c2dd20c-95a3-4bb9-a159-744a1e61e41a@github.com>

On Wed, 17 Feb 2021 16:13:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> OK. For what it's worth, I doubt that this will be suitable for backporting to 8u or 11u.

Thanks for your review, I'd like to backport this.

BTW, Is there anyone could review those trivial shared code?

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From thartmann at openjdk.java.net  Thu Feb 18 07:19:41 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 18 Feb 2021 07:19:41 GMT
Subject: RFR: 8261912: Code IfNode::fold_compares_helper more defensively
In-Reply-To: <Rg0yooo3hewsAfa-xDbOeoFkalN00IP9QkzxSJlLPxE=.c9daa643-a16d-46b4-8f87-50565d6a0249@github.com>
References: <Rg0yooo3hewsAfa-xDbOeoFkalN00IP9QkzxSJlLPxE=.c9daa643-a16d-46b4-8f87-50565d6a0249@github.com>
Message-ID: <WFJBhZZuDbYC248g_hhDMHUtPX4B4qCazfkL3xxBmb0=.022907d0-6e2e-4b33-83d6-d8274b4da318@github.com>

On Wed, 17 Feb 2021 16:11:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As [JDK-8261914](https://bugs.openjdk.java.net/browse/JDK-8261914) indicates, there are cases that break the internal asserts in `IfNode::fold_compares_helper`, code added by JDK-8073480 in JDK 9. Unfortunately, release builds would happily miscompile when that happens. It would be better to code `IfNode::fold_compares_helper` more defensively, so it bails when asserts are violated. This implicitly works around the bug in JDK-8261914. The goal for this limited workaround is to be trivially backportable in order to quickly unbreak 11u, 16u and 17.
> 
> The alternative is, instead of the early returns is to do:
> 
>  lo = NULL;
>  hi = NULL;
> 
> ...and then wait for for the method epilog to handle it. I have no preference to either style, as the blocks this patch affects already has some early returns, and `lo/hi = NULL` are also used.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x]  Linux x86_64 fastdebug `tier2`
>  - [x] Failing JRuby reproducer from JDK-8261914, now passing in release mode with hundreds of iterations

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2610

From dongbo at openjdk.java.net  Thu Feb 18 07:57:25 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 18 Feb 2021 07:57:25 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v6]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <45gEz_9Vli1Mvby8SbtMsoEx65KL11RQnI-qKy6zfgo=.42933345-0086-466b-ae38-3add53fc1816@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - add tests in aarch64-asmtest.py
 - fix windows operator precedence error and cleanup testcase
 - Merge branch 'master' into aarch64_vector_api_shift
 - fix windows build failure
 - generate add if shift == 0 for accumulation and fix some test code
 - back out AD modifications and handle zero shift in assembler

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/d75ee99e..d746f209

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=04-05

  Stats: 22519 lines in 709 files changed: 13758 ins; 4768 del; 3993 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From dongbo at openjdk.java.net  Thu Feb 18 08:10:40 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 18 Feb 2021 08:10:40 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v2]
In-Reply-To: <0wUxJ4QUIzC-Hg4qSPtf8nFP0ov9J69nA3gjaoEJcWY=.ede23adb-4010-460d-8ac4-d560ace8ffc0@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <qIGtN0hEKBfKOpYy-SKt1vieC15bF4juBfwfKMRGI3g=.53123dda-a8ca-49b9-b925-6ed85f3f9e6f@github.com>
 <_ach7OekIqkqmFRW3JqA5h4Q_HQUbRni0vkFzx5q3MA=.536a9faa-98c9-4dd9-9798-dcc794e23cd0@github.com>
 <0wUxJ4QUIzC-Hg4qSPtf8nFP0ov9J69nA3gjaoEJcWY=.ede23adb-4010-460d-8ac4-d560ace8ffc0@github.com>
Message-ID: <YNQ3Aa1_HRLfYY-ux_ZwLdVmYNC8V-J7IpAuOtstFGI=.c2357502-6a55-45f3-a8e7-0cc05573e278@github.com>

On Wed, 10 Feb 2021 02:59:24 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 line 2057:
>> 
>>> 2055:              as_FloatRegister($src$$reg), as_FloatRegister($src$$reg));
>>> 2056:     } else {ifelse($4, B,`
>>> 2057:       if (sh >= 8) sh = 7;
>> 
>> I think it would be possible to move some of this logic from the AD file into MacroAssembler, with macros to generate the appropriate instruction based on their arguments. This might be cleaner: the logic here is very hard to follow.
>
> I backed out the modifications of `aarch64_neon.ad` and `aarch64_neon_ad.m4`.
> The `shift == 0` case is handled by the assembler now. Verified with the regression tests.

> I think it would be possible to move some of this logic from the AD file into MacroAssembler, with macros to generate the appropriate instruction based on their arguments. This might be cleaner: the logic here is very hard to follow.

Hi, I moved the logic to the assembler.
The assembler will generate different instructions based on the value of `shift`.
If `shift == 0` and need not to accumulte, generated a `mov`.
If `shift == 0` and need to accumulte, generated an `add`.

Also added tests in `aarch64-asmtest.py` to verify the assembler modifications.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From thartmann at openjdk.java.net  Thu Feb 18 08:12:40 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 18 Feb 2021 08:12:40 GMT
Subject: RFR: 8260653: Unreachable nodes keep speculative types alive [v3]
In-Reply-To: <x8meqvULp56xWEH4ObAN1-xHJ8t6FBwiBqo-M4ZjQSQ=.0ddd5297-1604-40dc-8618-e5f20f59aae3@github.com>
References: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
 <x8meqvULp56xWEH4ObAN1-xHJ8t6FBwiBqo-M4ZjQSQ=.0ddd5297-1604-40dc-8618-e5f20f59aae3@github.com>
Message-ID: <mhoLwqoIQ2Id0mkNs5xSrqTCrJy5VE7lJUXdkRb59gY=.1c1681f9-b469-4ecf-99be-c5c764f788d4@github.com>

On Wed, 17 Feb 2021 18:16:02 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> The RunThese test fails because after first igvn.optimize() (directly after parsing) there are unreachable nodes cycles left. Later when remove_speculative_types() is called - only reachable nodes will have their speculative type removed. At the end of remove_speculative_types() there is an assert that all speculative types have been removed that will fail.
>> 
>> This problem will not cause crashes in production - it is only a sanity test.
>> 
>> I suggest adding a call to PhaseRemoveUseless before remove_speculative_types. This will cost a few extra cycles but it is the only way we can guarantee that no unreachable nodes are left.
>> 
>> When debugging this I experimented with adding a call to verify_graph_edges to check for dead code at the same spot. This triggers failures in a lot of test. The conclusion is that it is very common that we have dead node cycles - but they very rarely keep speculative types alive.
>> 
>> A big thank you to Dean Long how created the reproducer for this bug.
>> 
>> Please review.
>
> Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove outcnt check

Otherwise looks good.

src/hotspot/share/opto/phaseX.cpp line 338:

> 336:   for (uint i = 0; i < max; ++i) {
> 337:     Node *n = at(i);
> 338:     if(n != NULL &&

Missing whitespace between `if` and `(`

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2606

From neliasso at openjdk.java.net  Thu Feb 18 08:36:07 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 18 Feb 2021 08:36:07 GMT
Subject: RFR: 8260653: Unreachable nodes keep speculative types alive [v4]
In-Reply-To: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
References: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
Message-ID: <Z77X_1zbkYsY83UKvzwJKr1JE9-RugyRlxXq29Q5q-Q=.83ceb6e4-066d-4490-90d6-7380815c3344@github.com>

> The RunThese test fails because after first igvn.optimize() (directly after parsing) there are unreachable nodes cycles left. Later when remove_speculative_types() is called - only reachable nodes will have their speculative type removed. At the end of remove_speculative_types() there is an assert that all speculative types have been removed that will fail.
> 
> This problem will not cause crashes in production - it is only a sanity test.
> 
> I suggest adding a call to PhaseRemoveUseless before remove_speculative_types. This will cost a few extra cycles but it is the only way we can guarantee that no unreachable nodes are left.
> 
> When debugging this I experimented with adding a call to verify_graph_edges to check for dead code at the same spot. This triggers failures in a lot of test. The conclusion is that it is very common that we have dead node cycles - but they very rarely keep speculative types alive.
> 
> A big thank you to Dean Long how created the reproducer for this bug.
> 
> Please review.

Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:

  Add missing ws

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2606/files
  - new: https://git.openjdk.java.net/jdk/pull/2606/files/ac23dad8..ae048cbc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2606&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2606&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2606/head:pull/2606

PR: https://git.openjdk.java.net/jdk/pull/2606

From aph at openjdk.java.net  Thu Feb 18 09:37:43 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 18 Feb 2021 09:37:43 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v6]
In-Reply-To: <45gEz_9Vli1Mvby8SbtMsoEx65KL11RQnI-qKy6zfgo=.42933345-0086-466b-ae38-3add53fc1816@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <45gEz_9Vli1Mvby8SbtMsoEx65KL11RQnI-qKy6zfgo=.42933345-0086-466b-ae38-3add53fc1816@github.com>
Message-ID: <tJeelhHivy4gyub1KwjSlMkoSlAA83wITauTXDUo4gQ=.a265eb39-7927-4413-8202-6f4b6ee4d6e1@github.com>

On Thu, 18 Feb 2021 07:57:25 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
>> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
>> 
>> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
>> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
>> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
>> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
>> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
>> 
>> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
>> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
>> 
>> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
>> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.
>
> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - add tests in aarch64-asmtest.py
>  - fix windows operator precedence error and cleanup testcase
>  - Merge branch 'master' into aarch64_vector_api_shift
>  - fix windows build failure
>  - generate add if shift == 0 for accumulation and fix some test code
>  - back out AD modifications and handle zero shift in assembler

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2709:

> 2707:       f(encodedShift, 22, 16); f(opc2, 15, 10), rf(Vn, 5), rf(Vd, 0);   \
> 2708:     }                                                                   \
> 2709:   }

Is this correct, according to the definition in the Architecture Reference Manual? It doesn't look like it to me. Assembler methods should generate bit patterns exactly as defined in the Manual. This logic should be in a MacroAssembler method.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From neliasso at openjdk.java.net  Thu Feb 18 10:26:40 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 18 Feb 2021 10:26:40 GMT
Subject: RFR: 8260653: Unreachable nodes keep speculative types alive [v3]
In-Reply-To: <mhoLwqoIQ2Id0mkNs5xSrqTCrJy5VE7lJUXdkRb59gY=.1c1681f9-b469-4ecf-99be-c5c764f788d4@github.com>
References: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
 <x8meqvULp56xWEH4ObAN1-xHJ8t6FBwiBqo-M4ZjQSQ=.0ddd5297-1604-40dc-8618-e5f20f59aae3@github.com>
 <mhoLwqoIQ2Id0mkNs5xSrqTCrJy5VE7lJUXdkRb59gY=.1c1681f9-b469-4ecf-99be-c5c764f788d4@github.com>
Message-ID: <ABaR3yoFugSTvXF8AklTq7Otd_xQ7h2rKpG5_LTcPAQ=.a87aa507-8698-48ec-a5d8-038c65e8392c@github.com>

On Thu, 18 Feb 2021 08:10:08 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove outcnt check
>
> Otherwise looks good.

Thanks for the reviews Vladimir and Tobias!

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

PR: https://git.openjdk.java.net/jdk/pull/2606

From neliasso at openjdk.java.net  Thu Feb 18 10:26:41 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 18 Feb 2021 10:26:41 GMT
Subject: Integrated: 8260653: Unreachable nodes keep speculative types alive
In-Reply-To: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
References: <TpY2PL7jpNnpZf0LsUgwMWIenN6m-G0V-VnDRrao8Ls=.e2d4cee4-3a2f-4d9b-a53c-319a32a9b5cb@github.com>
Message-ID: <qlQzaiLgYpu_6I0q9ntbVHulEDSJdiwHzvQ7wv3Leko=.1337d23d-2a98-4b8c-81bf-12157e1ff3c0@github.com>

On Wed, 17 Feb 2021 10:27:08 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> The RunThese test fails because after first igvn.optimize() (directly after parsing) there are unreachable nodes cycles left. Later when remove_speculative_types() is called - only reachable nodes will have their speculative type removed. At the end of remove_speculative_types() there is an assert that all speculative types have been removed that will fail.
> 
> This problem will not cause crashes in production - it is only a sanity test.
> 
> I suggest adding a call to PhaseRemoveUseless before remove_speculative_types. This will cost a few extra cycles but it is the only way we can guarantee that no unreachable nodes are left.
> 
> When debugging this I experimented with adding a call to verify_graph_edges to check for dead code at the same spot. This triggers failures in a lot of test. The conclusion is that it is very common that we have dead node cycles - but they very rarely keep speculative types alive.
> 
> A big thank you to Dean Long how created the reproducer for this bug.
> 
> Please review.

This pull request has now been integrated.

Changeset: 3a21e1df
Author:    Nils Eliasson <neliasso at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3a21e1df
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8260653: Unreachable nodes keep speculative types alive

Reviewed-by: vlivanov, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2606

From chagedorn at openjdk.java.net  Thu Feb 18 10:35:38 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 18 Feb 2021 10:35:38 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM
In-Reply-To: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
Message-ID: <UygGHIY2pSRcsIl1YkTN0XJDHJIP4jwxGZrZUpXs0_o=.85d0bdd2-69a6-4e14-abaf-6583d32fdb1a@github.com>

On Wed, 17 Feb 2021 12:23:55 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> The block formation algorithm applied by IGV to schedule graphs without associated CFG information traverses the graph backwards. This makes it difficult to deal with block projection nodes, leading in some cases to double addition of block nodes and block edges, and ultimately causing assertion failures.
> 
> This fix replaces the backward traversal by a forward traversal that relies on node category information (introduced in [8261336](https://bugs.openjdk.java.net/browse/JDK-8261336)) to identify control successors. The forward traversal is arguably simpler and, besides avoiding the reported assertion failure, has two advantages:
> 
> - it places block projection nodes in the same block as their predecessors, and
> - it numbers basic blocks more naturally.
> 
> The following screenshots illustrate the improvements (before the fix to the left, after the fix to the right):
> 
> ![cfgs-before-after](https://user-images.githubusercontent.com/8792647/108204708-6dcf5e00-7124-11eb-956c-fb7f84229b50.png)
> 
> Tested automatically on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented version of IGV that schedules graphs eagerly. Checked manually that the CFGs of a few selected graphs (included the reported one) are well-formed. Also checked that the overall IGV graph scheduling time is not affected by the changes.
> 
> Thanks to Christian Hagedorn for checking the fix independently.

Looks good to me! I played around with it in the IGV. I regularly got some assertion failure messages before - now they are gone now ??

src/utils/IdealGraphVisualizer/ServerCompiler/src/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java line 634:

> 632:             }
> 633:         }
> 634: 

Maybe you could extract the following code into 2 separate methods.

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2607

From neliasso at openjdk.java.net  Thu Feb 18 10:46:39 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 18 Feb 2021 10:46:39 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM
In-Reply-To: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
Message-ID: <Oir90iypuqiehcP1iAkuRuzNrKZODk9wpB0zk0X5gZc=.ac29c713-03fa-4be3-af00-6bd6c1d7899f@github.com>

On Wed, 17 Feb 2021 12:23:55 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> The block formation algorithm applied by IGV to schedule graphs without associated CFG information traverses the graph backwards. This makes it difficult to deal with block projection nodes, leading in some cases to double addition of block nodes and block edges, and ultimately causing assertion failures.
> 
> This fix replaces the backward traversal by a forward traversal that relies on node category information (introduced in [8261336](https://bugs.openjdk.java.net/browse/JDK-8261336)) to identify control successors. The forward traversal is arguably simpler and, besides avoiding the reported assertion failure, has two advantages:
> 
> - it places block projection nodes in the same block as their predecessors, and
> - it numbers basic blocks more naturally.
> 
> The following screenshots illustrate the improvements (before the fix to the left, after the fix to the right):
> 
> ![cfgs-before-after](https://user-images.githubusercontent.com/8792647/108204708-6dcf5e00-7124-11eb-956c-fb7f84229b50.png)
> 
> Tested automatically on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented version of IGV that schedules graphs eagerly. Checked manually that the CFGs of a few selected graphs (included the reported one) are well-formed. Also checked that the overall IGV graph scheduling time is not affected by the changes.
> 
> Thanks to Christian Hagedorn for checking the fix independently.

Excellent!

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

PR: https://git.openjdk.java.net/jdk/pull/2607

From shade at openjdk.java.net  Thu Feb 18 10:58:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 18 Feb 2021 10:58:45 GMT
Subject: RFR: 8261912: Code IfNode::fold_compares_helper more defensively
In-Reply-To: <WFJBhZZuDbYC248g_hhDMHUtPX4B4qCazfkL3xxBmb0=.022907d0-6e2e-4b33-83d6-d8274b4da318@github.com>
References: <Rg0yooo3hewsAfa-xDbOeoFkalN00IP9QkzxSJlLPxE=.c9daa643-a16d-46b4-8f87-50565d6a0249@github.com>
 <WFJBhZZuDbYC248g_hhDMHUtPX4B4qCazfkL3xxBmb0=.022907d0-6e2e-4b33-83d6-d8274b4da318@github.com>
Message-ID: <IIC0E_aYQwEfX9LPtguucAdsor04GdBfCuXQzQiDTuQ=.4d2c9fb7-b79b-45c2-84a8-2cfd8c64f32e@github.com>

On Thu, 18 Feb 2021 07:16:56 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> As [JDK-8261914](https://bugs.openjdk.java.net/browse/JDK-8261914) indicates, there are cases that break the internal asserts in `IfNode::fold_compares_helper`, code added by JDK-8073480 in JDK 9. Unfortunately, release builds would happily miscompile when that happens. It would be better to code `IfNode::fold_compares_helper` more defensively, so it bails when asserts are violated. This implicitly works around the bug in JDK-8261914. The goal for this limited workaround is to be trivially backportable in order to quickly unbreak 11u, 16u and 17.
>> 
>> The alternative is, instead of the early returns is to do:
>> 
>>  lo = NULL;
>>  hi = NULL;
>> 
>> ...and then wait for for the method epilog to handle it. I have no preference to either style, as the blocks this patch affects already has some early returns, and `lo/hi = NULL` are also used.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x]  Linux x86_64 fastdebug `tier2`
>>  - [x] Failing JRuby reproducer from JDK-8261914, now passing in release mode with hundreds of iterations
>
> Looks good.

The remaining test failure should be resolved with #2614. I'll integrate once this PR is 24 hours old.

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

PR: https://git.openjdk.java.net/jdk/pull/2610

From chegar at openjdk.java.net  Thu Feb 18 11:54:40 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 18 Feb 2021 11:54:40 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
Message-ID: <8erqBs2u14oRGdt-KmCGy9IGLZnv5k1tqwm57BSnjBQ=.4e8133b8-f287-43a0-94d3-da136336e56b@github.com>

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

The changes in java/net look ok to me.

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

PR: https://git.openjdk.java.net/jdk/pull/2589

From rcastanedalo at openjdk.java.net  Thu Feb 18 12:06:53 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 18 Feb 2021 12:06:53 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM [v2]
In-Reply-To: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
Message-ID: <lPfNhC5qyZOXkWNOHeI42Z35z1FgfxHUp26dVkkpnM4=.4a4221e0-a2b1-47bb-93a9-fa795527c5a4@github.com>

> The block formation algorithm applied by IGV to schedule graphs without associated CFG information traverses the graph backwards. This makes it difficult to deal with block projection nodes, leading in some cases to double addition of block nodes and block edges, and ultimately causing assertion failures.
> 
> This fix replaces the backward traversal by a forward traversal that relies on node category information (introduced in [8261336](https://bugs.openjdk.java.net/browse/JDK-8261336)) to identify control successors. The forward traversal is arguably simpler and, besides avoiding the reported assertion failure, has two advantages:
> 
> - it places block projection nodes in the same block as their predecessors, and
> - it numbers basic blocks more naturally.
> 
> The following screenshots illustrate the improvements (before the fix to the left, after the fix to the right):
> 
> ![cfgs-before-after](https://user-images.githubusercontent.com/8792647/108204708-6dcf5e00-7124-11eb-956c-fb7f84229b50.png)
> 
> Tested automatically on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented version of IGV that schedules graphs eagerly. Checked manually that the CFGs of a few selected graphs (included the reported one) are well-formed. Also checked that the overall IGV graph scheduling time is not affected by the changes.
> 
> Thanks to Christian Hagedorn for checking the fix independently.

Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:

  Extract new logic out of buildUpGraph()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2607/files
  - new: https://git.openjdk.java.net/jdk/pull/2607/files/69987721..9f6444ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2607&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2607&range=00-01

  Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2607/head:pull/2607

PR: https://git.openjdk.java.net/jdk/pull/2607

From rcastanedalo at openjdk.java.net  Thu Feb 18 12:06:53 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 18 Feb 2021 12:06:53 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM [v2]
In-Reply-To: <Oir90iypuqiehcP1iAkuRuzNrKZODk9wpB0zk0X5gZc=.ac29c713-03fa-4be3-af00-6bd6c1d7899f@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
 <Oir90iypuqiehcP1iAkuRuzNrKZODk9wpB0zk0X5gZc=.ac29c713-03fa-4be3-af00-6bd6c1d7899f@github.com>
Message-ID: <zHKyJZxpkG9hEJyn96ta8ySu3LuUHwDry1AtldndGBA=.6408cbbc-20eb-4188-9084-1073200f6fd4@github.com>

On Thu, 18 Feb 2021 10:43:27 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extract new logic out of buildUpGraph()
>
> Excellent!

Thanks Christian and Nils for reviewing! Christian, I refactored the code as per your suggestion, please have a look again.

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

PR: https://git.openjdk.java.net/jdk/pull/2607

From rcastanedalo at openjdk.java.net  Thu Feb 18 12:06:54 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 18 Feb 2021 12:06:54 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM [v2]
In-Reply-To: <UygGHIY2pSRcsIl1YkTN0XJDHJIP4jwxGZrZUpXs0_o=.85d0bdd2-69a6-4e14-abaf-6583d32fdb1a@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
 <UygGHIY2pSRcsIl1YkTN0XJDHJIP4jwxGZrZUpXs0_o=.85d0bdd2-69a6-4e14-abaf-6583d32fdb1a@github.com>
Message-ID: <nYo65pKCeX2sCFTFIWx8c_6ump1Uh4dgonEqrgZLucY=.f696b11e-197b-44f9-885f-581b2e970dbe@github.com>

On Thu, 18 Feb 2021 10:29:28 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extract new logic out of buildUpGraph()
>
> src/utils/IdealGraphVisualizer/ServerCompiler/src/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java line 634:
> 
>> 632:             }
>> 633:         }
>> 634: 
> 
> Maybe you could extract the following code into 2 separate methods.

Thanks, done!

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

PR: https://git.openjdk.java.net/jdk/pull/2607

From chagedorn at openjdk.java.net  Thu Feb 18 12:23:43 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 18 Feb 2021 12:23:43 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM [v2]
In-Reply-To: <lPfNhC5qyZOXkWNOHeI42Z35z1FgfxHUp26dVkkpnM4=.4a4221e0-a2b1-47bb-93a9-fa795527c5a4@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
 <lPfNhC5qyZOXkWNOHeI42Z35z1FgfxHUp26dVkkpnM4=.4a4221e0-a2b1-47bb-93a9-fa795527c5a4@github.com>
Message-ID: <-Qd5a0SApy6Cp07xQK_xyYmpsGEGxZ1vdAzaFQvmVDc=.df55812b-e6f4-4559-be03-9d4e06ed3f6e@github.com>

On Thu, 18 Feb 2021 12:06:53 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> The block formation algorithm applied by IGV to schedule graphs without associated CFG information traverses the graph backwards. This makes it difficult to deal with block projection nodes, leading in some cases to double addition of block nodes and block edges, and ultimately causing assertion failures.
>> 
>> This fix replaces the backward traversal by a forward traversal that relies on node category information (introduced in [8261336](https://bugs.openjdk.java.net/browse/JDK-8261336)) to identify control successors. The forward traversal is arguably simpler and, besides avoiding the reported assertion failure, has two advantages:
>> 
>> - it places block projection nodes in the same block as their predecessors, and
>> - it numbers basic blocks more naturally.
>> 
>> The following screenshots illustrate the improvements (before the fix to the left, after the fix to the right):
>> 
>> ![cfgs-before-after](https://user-images.githubusercontent.com/8792647/108204708-6dcf5e00-7124-11eb-956c-fb7f84229b50.png)
>> 
>> Tested automatically on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented version of IGV that schedules graphs eagerly. Checked manually that the CFGs of a few selected graphs (included the reported one) are well-formed. Also checked that the overall IGV graph scheduling time is not affected by the changes.
>> 
>> Thanks to Christian Hagedorn for checking the fix independently.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract new logic out of buildUpGraph()

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2607

From neliasso at openjdk.java.net  Thu Feb 18 12:41:39 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 18 Feb 2021 12:41:39 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM [v2]
In-Reply-To: <lPfNhC5qyZOXkWNOHeI42Z35z1FgfxHUp26dVkkpnM4=.4a4221e0-a2b1-47bb-93a9-fa795527c5a4@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
 <lPfNhC5qyZOXkWNOHeI42Z35z1FgfxHUp26dVkkpnM4=.4a4221e0-a2b1-47bb-93a9-fa795527c5a4@github.com>
Message-ID: <WBRje2yMIjkAHorNMY9fCXP8etyR9ovJE3_E_z3Daho=.0126a0f1-52e2-4f95-972d-679ac618e4ae@github.com>

On Thu, 18 Feb 2021 12:06:53 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> The block formation algorithm applied by IGV to schedule graphs without associated CFG information traverses the graph backwards. This makes it difficult to deal with block projection nodes, leading in some cases to double addition of block nodes and block edges, and ultimately causing assertion failures.
>> 
>> This fix replaces the backward traversal by a forward traversal that relies on node category information (introduced in [8261336](https://bugs.openjdk.java.net/browse/JDK-8261336)) to identify control successors. The forward traversal is arguably simpler and, besides avoiding the reported assertion failure, has two advantages:
>> 
>> - it places block projection nodes in the same block as their predecessors, and
>> - it numbers basic blocks more naturally.
>> 
>> The following screenshots illustrate the improvements (before the fix to the left, after the fix to the right):
>> 
>> ![cfgs-before-after](https://user-images.githubusercontent.com/8792647/108204708-6dcf5e00-7124-11eb-956c-fb7f84229b50.png)
>> 
>> Tested automatically on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented version of IGV that schedules graphs eagerly. Checked manually that the CFGs of a few selected graphs (included the reported one) are well-formed. Also checked that the overall IGV graph scheduling time is not affected by the changes.
>> 
>> Thanks to Christian Hagedorn for checking the fix independently.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract new logic out of buildUpGraph()

Marked as reviewed by neliasso (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2607

From shade at openjdk.java.net  Thu Feb 18 15:54:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 18 Feb 2021 15:54:40 GMT
Subject: Integrated: 8261912: Code IfNode::fold_compares_helper more
 defensively
In-Reply-To: <Rg0yooo3hewsAfa-xDbOeoFkalN00IP9QkzxSJlLPxE=.c9daa643-a16d-46b4-8f87-50565d6a0249@github.com>
References: <Rg0yooo3hewsAfa-xDbOeoFkalN00IP9QkzxSJlLPxE=.c9daa643-a16d-46b4-8f87-50565d6a0249@github.com>
Message-ID: <SDZkNtnjpu6ijnaOH0kdQ92ANGF07hJKryItXc5NTgQ=.aa19d940-6801-4bbb-a86a-83cbe3f72c7c@github.com>

On Wed, 17 Feb 2021 16:11:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As [JDK-8261914](https://bugs.openjdk.java.net/browse/JDK-8261914) indicates, there are cases that break the internal asserts in `IfNode::fold_compares_helper`, code added by JDK-8073480 in JDK 9. Unfortunately, release builds would happily miscompile when that happens. It would be better to code `IfNode::fold_compares_helper` more defensively, so it bails when asserts are violated. This implicitly works around the bug in JDK-8261914. The goal for this limited workaround is to be trivially backportable in order to quickly unbreak 11u, 16u and 17.
> 
> The alternative is, instead of the early returns is to do:
> 
>  lo = NULL;
>  hi = NULL;
> 
> ...and then wait for for the method epilog to handle it. I have no preference to either style, as the blocks this patch affects already has some early returns, and `lo/hi = NULL` are also used.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x]  Linux x86_64 fastdebug `tier2`
>  - [x] Failing JRuby reproducer from JDK-8261914, now passing in release mode with hundreds of iterations

This pull request has now been integrated.

Changeset: e9f3aab7
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e9f3aab7
Stats:     23 lines in 1 file changed: 15 ins; 4 del; 4 mod

8261912: Code IfNode::fold_compares_helper more defensively

Reviewed-by: kvn, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2610

From vlivanov at openjdk.java.net  Thu Feb 18 17:25:53 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 18 Feb 2021 17:25:53 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class hierarchy
 under context class
Message-ID: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>

Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.

Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.

Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 

(There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 

Testing:
- [x] hs-tier1 - hs-tier8
- [x] additional verification that CHA decisions aren't affected

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

Commit messages:
 - Refactor ClassHierarchyIterator
 - Revert verification
 - Verification
 - Cleanups in ClassHierarchyWalker::is_witness()
 - Migrate ClassHierarchyWalker::find_witness_in to ClassHierarchyIterator
 - ClassHierarchyIterator

Changes: https://git.openjdk.java.net/jdk/pull/2630/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2630&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261954
  Stats: 169 lines in 2 files changed: 64 ins; 69 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2630/head:pull/2630

PR: https://git.openjdk.java.net/jdk/pull/2630

From kvn at openjdk.java.net  Thu Feb 18 17:58:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 18 Feb 2021 17:58:40 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
Message-ID: <Xrc1--w9S9TCcMHGME5lWKoelcQUaawW8u55CncmCP0=.44e9effa-eb8a-44f0-bca5-ae500303a765@github.com>

On Thu, 18 Feb 2021 17:05:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
> 
> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
> 
> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
> 
> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
> 
> Testing:
> - [x] hs-tier1 - hs-tier8
> - [x] additional verification that CHA decisions aren't affected

Except `do_counts` changes seem fine to me.

src/hotspot/share/code/dependencies.cpp line 1329:

> 1327:   assert_locked_or_safepoint(Compile_lock);
> 1328: 
> 1329:   bool do_counts = count_find_witness_calls();

Does count_find_witness_calls() have side effects and required to be called here in product? If not,
`do_counts` is used only for not_product code, so consider enclose it into  NOT_PRODUCT() here and where it is used.

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From kvn at openjdk.java.net  Thu Feb 18 19:17:44 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 18 Feb 2021 19:17:44 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors
In-Reply-To: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
Message-ID: <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>

On Thu, 11 Feb 2021 02:37:35 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
> 
> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
> 
> Before:
> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
> 
> After:
> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms

Please, add a test which verifies correctness of results when this code is used. If we don't have it already.

src/hotspot/cpu/x86/x86.ad line 7506:

> 7504: instruct rearrangeB_avx(legVec dst, legVec src, vec shuffle, legVec vtmp1, legVec vtmp2, rRegP scratch) %{
> 7505:   predicate(vector_element_basic_type(n) == T_BYTE &&
> 7506:             vector_length(n) == 32 && !VM_Version::supports_avx512_vbmi());

Predicate matches bail-out condition in match_rule_supported_vector(). Does it mean this code never used before?
So you are implementing it now. Right?

src/hotspot/cpu/x86/x86.ad line 7550:

> 7548:     // only byte shuffle instruction available on these platforms
> 7549:     int vlen_in_bytes = vector_length_in_bytes(this);
> 7550:     if (UseAVX == 0) {

This code will not be executed with vector length 16 because match_rule_supported_vector() bailout with (size_in_bits == 256 && UseAVX < 2).

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

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2520

From vlivanov at openjdk.java.net  Thu Feb 18 20:45:38 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 18 Feb 2021 20:45:38 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <Xrc1--w9S9TCcMHGME5lWKoelcQUaawW8u55CncmCP0=.44e9effa-eb8a-44f0-bca5-ae500303a765@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <Xrc1--w9S9TCcMHGME5lWKoelcQUaawW8u55CncmCP0=.44e9effa-eb8a-44f0-bca5-ae500303a765@github.com>
Message-ID: <IPZyk2EvMsrQv0-CVeKbUG1FMi4uc35Z0sz03bN4eC8=.7d933e1a-4c98-41d1-904b-f67ac08eca09@github.com>

On Thu, 18 Feb 2021 17:53:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
>> 
>> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
>> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
>> 
>> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
>> 
>> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier8
>> - [x] additional verification that CHA decisions aren't affected
>
> src/hotspot/share/code/dependencies.cpp line 1329:
> 
>> 1327:   assert_locked_or_safepoint(Compile_lock);
>> 1328: 
>> 1329:   bool do_counts = count_find_witness_calls();
> 
> Does count_find_witness_calls() have side effects and required to be called here in product? If not,
> `do_counts` is used only for not_product code, so consider enclose it into  NOT_PRODUCT() here and where it is used.

`count_find_witness_calls()` is a no-op in product binaries:
#ifndef PRODUCT
...
static bool count_find_witness_calls() {
...
#else
#define count_find_witness_calls() (0)
#endif //PRODUCT

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From kvn at openjdk.java.net  Thu Feb 18 21:06:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 18 Feb 2021 21:06:38 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
Message-ID: <NktuTVDgwmvvRzL_RbkOvoE6ammif4A2hEideVXEzRA=.fcae4878-f1d3-40b2-8e17-8fb92bf3bcf8@github.com>

On Thu, 18 Feb 2021 17:05:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
> 
> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
> 
> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
> 
> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
> 
> Testing:
> - [x] hs-tier1 - hs-tier8
> - [x] additional verification that CHA decisions aren't affected

OK

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2630

From sviswanathan at openjdk.java.net  Thu Feb 18 21:26:41 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 18 Feb 2021 21:26:41 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors
In-Reply-To: <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>
Message-ID: <gw67s5Qv2iFMjIuGgMOkYvdxkQJPyCwu_yfqjezhqtI=.d33b8556-440d-4b7c-8546-8d24cc2ea880@github.com>

On Thu, 18 Feb 2021 19:14:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
>> 
>> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
>> 
>> Before:
>> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
>> 
>> After:
>> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms
>
> Please, add a test which verifies correctness of results when this code is used. If we don't have it already.

@vnkozlov thanks a lot for the review.  
The test for slice and unslice are already part of test/jdk/jdk/incubator/vector/Byte256VectorTests.java and Short256VectorTests.java.

> src/hotspot/cpu/x86/x86.ad line 7550:
> 
>> 7548:     // only byte shuffle instruction available on these platforms
>> 7549:     int vlen_in_bytes = vector_length_in_bytes(this);
>> 7550:     if (UseAVX == 0) {
> 
> This code will not be executed with vector length 16 because match_rule_supported_vector() bailout with (size_in_bits == 256 && UseAVX < 2).

Yes you are right, but this code will execute for vector length 16 when UseAVX ==2.
 It will also execure for vector length 16 when UseAVX == 3 &&
!VM_Version::supports_avx512bw.

> src/hotspot/cpu/x86/x86.ad line 7506:
> 
>> 7504: instruct rearrangeB_avx(legVec dst, legVec src, vec shuffle, legVec vtmp1, legVec vtmp2, rRegP scratch) %{
>> 7505:   predicate(vector_element_basic_type(n) == T_BYTE &&
>> 7506:             vector_length(n) == 32 && !VM_Version::supports_avx512_vbmi());
> 
> Predicate matches bail-out condition in match_rule_supported_vector(). Does it mean this code never used before?
> So you are implementing it now. Right?

Yes, this rule was not used before and I am implementing it now.

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From coleenp at openjdk.java.net  Thu Feb 18 22:44:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 18 Feb 2021 22:44:40 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
Message-ID: <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>

On Thu, 18 Feb 2021 17:05:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
> 
> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
> 
> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
> 
> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
> 
> Testing:
> - [x] hs-tier1 - hs-tier8
> - [x] additional verification that CHA decisions aren't affected

This seems like a nice change.  Some questions.

src/hotspot/share/oops/instanceKlass.hpp line 1486:

> 1484:   }
> 1485: };
> 1486: 

The _subklass and _next_sibling fields and implementation are in Klass (klass.hpp/cpp) but I always wonder why they are not in InstanceKlass (instanceKlass.hpp/cpp).  If this new class is in instanceKlass.hpp, these fields should be in the same.  If you agree, we should file an RFE and I will move them.  If the fields truly belong in klass.hpp, then this should be there too. ie. they should match.

src/hotspot/share/code/dependencies.cpp line 1345:

> 1343:     } else if (nof_impls == 1) { // unique implementor
> 1344:       assert(context_type != context_type->implementor(), "not unique");
> 1345:       context_type = InstanceKlass::cast(context_type->implementor());

There's no reason that implementor() should return Klass* rather than InstanceKlass* ? We can clean that up also later to reduce casts. (I thought I already tried to do this once).

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2630

From kvn at openjdk.java.net  Thu Feb 18 23:24:43 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 18 Feb 2021 23:24:43 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors
In-Reply-To: <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>
Message-ID: <sPCRhhlxL8s6CXcz6lJjNymPsMJZI17fzz0euBfY8_I=.e7963a21-b451-4c74-8e9c-70b60dcd7fad@github.com>

On Thu, 18 Feb 2021 19:14:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
>> 
>> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
>> 
>> Before:
>> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
>> 
>> After:
>> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms
>
> Please, add a test which verifies correctness of results when this code is used. If we don't have it already.

> @vnkozlov thanks a lot for the review.
> The test for slice and unslice are already part of test/jdk/jdk/incubator/vector/Byte256VectorTests.java and Short256VectorTests.java.

Good.

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From kvn at openjdk.java.net  Thu Feb 18 23:34:45 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 18 Feb 2021 23:34:45 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors
In-Reply-To: <gw67s5Qv2iFMjIuGgMOkYvdxkQJPyCwu_yfqjezhqtI=.d33b8556-440d-4b7c-8546-8d24cc2ea880@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>
 <gw67s5Qv2iFMjIuGgMOkYvdxkQJPyCwu_yfqjezhqtI=.d33b8556-440d-4b7c-8546-8d24cc2ea880@github.com>
Message-ID: <jWmSx7978dfrGJ8W6sulB2Hh6KUzk93PX0PloL5aEXQ=.d9dd196a-ad30-4fec-a426-8a774cf95de7@github.com>

On Thu, 18 Feb 2021 21:21:49 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 7550:
>> 
>>> 7548:     // only byte shuffle instruction available on these platforms
>>> 7549:     int vlen_in_bytes = vector_length_in_bytes(this);
>>> 7550:     if (UseAVX == 0) {
>> 
>> This code will not be executed with vector length 16 because match_rule_supported_vector() bailout with (size_in_bits == 256 && UseAVX < 2).
>
> Yes you are right, but this code will execute for vector length 16 when UseAVX ==2.
>  It will also execure for vector length 16 when UseAVX == 3 &&
> !VM_Version::supports_avx512bw.

Next assert checks <= 16 when code is guarded by (UseAVX == 0). It is not (UseAVX ==2).
Also } else { case is for UseAVX > 0 which includes AVX=1 but vpaddb() (avx3) is used there.
Seems UseAVX checks wrong here.

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From sviswanathan at openjdk.java.net  Fri Feb 19 00:35:54 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 19 Feb 2021 00:35:54 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v2]
In-Reply-To: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
Message-ID: <ozDkgbUYQbgKnB-E6TYQsAWFhXHT80x61urdHZYrp-4=.fb9a0676-ab72-4c26-8ba9-42c970de075c@github.com>

> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
> 
> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
> 
> Before:
> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
> 
> After:
> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  corrected assert

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2520/files
  - new: https://git.openjdk.java.net/jdk/pull/2520/files/77324374..55165cb5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2520&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2520&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2520/head:pull/2520

PR: https://git.openjdk.java.net/jdk/pull/2520

From sviswanathan at openjdk.java.net  Fri Feb 19 01:23:04 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 19 Feb 2021 01:23:04 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v3]
In-Reply-To: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
Message-ID: <4TNVM4VqqsezSVCJndS1RpM9EvIfICm5mv1AbZhthgg=.3943a37b-cce4-415e-989f-b9696ad6c008@github.com>

> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
> 
> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
> 
> Before:
> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
> 
> After:
> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  corrected assert

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2520/files
  - new: https://git.openjdk.java.net/jdk/pull/2520/files/55165cb5..fa13679a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2520&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2520&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2520/head:pull/2520

PR: https://git.openjdk.java.net/jdk/pull/2520

From sviswanathan at openjdk.java.net  Fri Feb 19 01:30:41 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 19 Feb 2021 01:30:41 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v3]
In-Reply-To: <jWmSx7978dfrGJ8W6sulB2Hh6KUzk93PX0PloL5aEXQ=.d9dd196a-ad30-4fec-a426-8a774cf95de7@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>
 <gw67s5Qv2iFMjIuGgMOkYvdxkQJPyCwu_yfqjezhqtI=.d33b8556-440d-4b7c-8546-8d24cc2ea880@github.com>
 <jWmSx7978dfrGJ8W6sulB2Hh6KUzk93PX0PloL5aEXQ=.d9dd196a-ad30-4fec-a426-8a774cf95de7@github.com>
Message-ID: <XmT-nJoZoORWTKBdE2frOsja8eb_CZeC-bpKM16p3jw=.f0e9b3f9-adde-4922-8cfa-30d8ffeed351@github.com>

On Thu, 18 Feb 2021 23:31:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Yes you are right, but this code will execute for vector length 16 when UseAVX ==2.
>>  It will also execure for vector length 16 when UseAVX == 3 &&
>> !VM_Version::supports_avx512bw.
>
> Next assert checks <= 16 when code is guarded by (UseAVX == 0). It is not (UseAVX ==2).
> Also } else { case is for UseAVX > 0 which includes AVX=1 but vpaddb() (avx3) is used there.
> Seems UseAVX checks wrong here.

The assert checks for  vlen_in_bytes <= 16 (128 bits) and so is a correct check for UseAVX=0.
vpaddb is supported on  AVX1/AVX2 as well.
vpaddb is supported on AVX1 for up to 128 bit and
on AVX2 for upto 256 bit and 
on AVX3 (512) for upto 512 bit vectors.
I have tested this for UseAVX=0, UseAVX=1, UseAVX=2, UseAVX=3 platform.

The check is for UseAVX as with any flavor of AVX, we can use less number of instructions to do this operation.
This is because AVX allows destination to be separate from both the sources. 

Please let me know if I am missing something.

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From kvn at openjdk.java.net  Fri Feb 19 01:58:44 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 19 Feb 2021 01:58:44 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v3]
In-Reply-To: <4TNVM4VqqsezSVCJndS1RpM9EvIfICm5mv1AbZhthgg=.3943a37b-cce4-415e-989f-b9696ad6c008@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <4TNVM4VqqsezSVCJndS1RpM9EvIfICm5mv1AbZhthgg=.3943a37b-cce4-415e-989f-b9696ad6c008@github.com>
Message-ID: <JnjDcrIcYReIwuPuGxNZowpke72Yv8KNn9C_xZaiSug=.80bf83d3-c0f2-442d-ab4f-344850e9acf8@github.com>

On Fri, 19 Feb 2021 01:23:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
>> 
>> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
>> 
>> Before:
>> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
>> 
>> After:
>> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected assert

src/hotspot/cpu/x86/x86.ad line 1695:

> 1693:       if(vlen == 2) {
> 1694:         return false; // Implementation limitation due to how shuffle is loaded
> 1695:       } else if (size_in_bits == 256 && UseAVX < 2) {

Should this be >= 256?

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From kvn at openjdk.java.net  Fri Feb 19 02:07:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 19 Feb 2021 02:07:40 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v3]
In-Reply-To: <XmT-nJoZoORWTKBdE2frOsja8eb_CZeC-bpKM16p3jw=.f0e9b3f9-adde-4922-8cfa-30d8ffeed351@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>
 <gw67s5Qv2iFMjIuGgMOkYvdxkQJPyCwu_yfqjezhqtI=.d33b8556-440d-4b7c-8546-8d24cc2ea880@github.com>
 <jWmSx7978dfrGJ8W6sulB2Hh6KUzk93PX0PloL5aEXQ=.d9dd196a-ad30-4fec-a426-8a774cf95de7@github.com>
 <XmT-nJoZoORWTKBdE2frOsja8eb_CZeC-bpKM16p3jw=.f0e9b3f9-adde-4922-8cfa-30d8ffeed351@github.com>
Message-ID: <Ie_5LHtB4KuVE9MUf9FckVHJ2SPFN4VkN_2-8evzFrk=.fca5106f-3019-4d10-b120-bab251017731@github.com>

On Fri, 19 Feb 2021 01:27:57 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Next assert checks <= 16 when code is guarded by (UseAVX == 0). It is not (UseAVX ==2).
>> Also } else { case is for UseAVX > 0 which includes AVX=1 but vpaddb() (avx3) is used there.
>> Seems UseAVX checks wrong here.
>
> The assert checks for  vlen_in_bytes <= 16 (128 bits) and so is a correct check for UseAVX=0.
> vpaddb is supported on  AVX1/AVX2 as well.
> vpaddb is supported on AVX1 for up to 128 bit and
> on AVX2 for upto 256 bit and 
> on AVX3 (512) for upto 512 bit vectors.
> I have tested this for UseAVX=0, UseAVX=1, UseAVX=2, UseAVX=3 platform.
> 
> The check is for UseAVX as with any flavor of AVX, we can use less number of instructions to do this operation.
> This is because AVX allows destination to be separate from both the sources. 
> 
> Please let me know if I am missing something.

My bad - I missed that size is in bytes in assert. The assert is correct, as you said.
And `} else {` part works for AVX1 because of match_rule_supported_vector() bailout 256-bit case.
May be add assert(UseAVX > 1 || vlen_in_bytes <= 16, ).

I only have one question left - about check >= 256 in  match_rule_supported_vector()

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From sviswanathan at openjdk.java.net  Fri Feb 19 02:33:40 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 19 Feb 2021 02:33:40 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v3]
In-Reply-To: <JnjDcrIcYReIwuPuGxNZowpke72Yv8KNn9C_xZaiSug=.80bf83d3-c0f2-442d-ab4f-344850e9acf8@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <4TNVM4VqqsezSVCJndS1RpM9EvIfICm5mv1AbZhthgg=.3943a37b-cce4-415e-989f-b9696ad6c008@github.com>
 <JnjDcrIcYReIwuPuGxNZowpke72Yv8KNn9C_xZaiSug=.80bf83d3-c0f2-442d-ab4f-344850e9acf8@github.com>
Message-ID: <lvswXG4miaKuicKDdydMQp8u0yA3UWvDoTEUQ4mdI2A=.485b327e-05b9-4637-ae8f-3df2ef06c196@github.com>

On Fri, 19 Feb 2021 01:56:19 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   corrected assert
>
> src/hotspot/cpu/x86/x86.ad line 1695:
> 
>> 1693:       if(vlen == 2) {
>> 1694:         return false; // Implementation limitation due to how shuffle is loaded
>> 1695:       } else if (size_in_bits == 256 && UseAVX < 2) {
> 
> Should this be >= 256?

The general >= 256 part is taken care of early on in match_rule_supported_vector as below:
  if (!vector_size_supported(bt, vlen)) {
    return false;
  }
The only additional check that is being done here is for float and double  256 bit vectors that are supported on AVX=1 and will pass the vector_size_supported check.
This is because the VectorLoadShuffle cannot be performed for 256 bit vectors on AVX1 platform as it needs "integer" 256 bit instructions which are only available on AVX2.

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From dongbo at openjdk.java.net  Fri Feb 19 03:13:12 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 19 Feb 2021 03:13:12 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v7]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <pr96wBAOH_0dbHHpJYmcmBKlPUIm8EXjiRjNHxTGN68=.4b42d8a4-3195-4f6b-bb98-d64786d632c7@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  handle zero shift in macro assembler

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/d746f209..1aba5629

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=05-06

  Stats: 530 lines in 4 files changed: 27 ins; 174 del; 329 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From dongbo at openjdk.java.net  Fri Feb 19 03:17:42 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 19 Feb 2021 03:17:42 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v6]
In-Reply-To: <tJeelhHivy4gyub1KwjSlMkoSlAA83wITauTXDUo4gQ=.a265eb39-7927-4413-8202-6f4b6ee4d6e1@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <45gEz_9Vli1Mvby8SbtMsoEx65KL11RQnI-qKy6zfgo=.42933345-0086-466b-ae38-3add53fc1816@github.com>
 <tJeelhHivy4gyub1KwjSlMkoSlAA83wITauTXDUo4gQ=.a265eb39-7927-4413-8202-6f4b6ee4d6e1@github.com>
Message-ID: <b_gQ7WH6077sAG33iFX8UBaNJY3dGJC5BC3SpWVx-Dc=.e587ca6c-6175-46c2-99d0-30c5f47d6804@github.com>

On Thu, 18 Feb 2021 09:35:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.
>
> src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2694:
> 
>> 2692:     assert((1 << ((T>>1)+3)) > shift, "Invalid Shift value");           \
>> 2693:     if (shift == 0) {                                                   \
>> 2694:       bool accumulate = ((opc2 & 0b100) != 0);                          \
> 
> Is this correct, according to the definition in the Architecture Reference Manual? It doesn't look like it to me. Assembler methods should generate bit patterns exactly as defined in the Manual. This logic should be in a MacroAssembler method.

Hi, I moved the logic into MacroAssembler.
The assert is kept to make sure that we would never pass a zero right shift to assemlber.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From sviswanathan at openjdk.java.net  Fri Feb 19 03:20:59 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 19 Feb 2021 03:20:59 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v4]
In-Reply-To: <Ie_5LHtB4KuVE9MUf9FckVHJ2SPFN4VkN_2-8evzFrk=.fca5106f-3019-4d10-b120-bab251017731@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>
 <gw67s5Qv2iFMjIuGgMOkYvdxkQJPyCwu_yfqjezhqtI=.d33b8556-440d-4b7c-8546-8d24cc2ea880@github.com>
 <jWmSx7978dfrGJ8W6sulB2Hh6KUzk93PX0PloL5aEXQ=.d9dd196a-ad30-4fec-a426-8a774cf95de7@github.com>
 <XmT-nJoZoORWTKBdE2frOsja8eb_CZeC-bpKM16p3jw=.f0e9b3f9-adde-4922-8cfa-30d8ffeed351@github.com>
 <Ie_5LHtB4KuVE9MUf9FckVHJ2SPFN4VkN_2-8evzFrk=.fca5106f-3019-4d10-b120-bab251017731@github.com>
Message-ID: <_0LW_Yx-ItDG7f-3kVjOTPa5BbcaN1FMRBbATLMwpmk=.da545e81-59a0-4d80-9f45-0714fe7bfc94@github.com>

On Fri, 19 Feb 2021 02:05:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The assert checks for  vlen_in_bytes <= 16 (128 bits) and so is a correct check for UseAVX=0.
>> vpaddb is supported on  AVX1/AVX2 as well.
>> vpaddb is supported on AVX1 for up to 128 bit and
>> on AVX2 for upto 256 bit and 
>> on AVX3 (512) for upto 512 bit vectors.
>> I have tested this for UseAVX=0, UseAVX=1, UseAVX=2, UseAVX=3 platform.
>> 
>> The check is for UseAVX as with any flavor of AVX, we can use less number of instructions to do this operation.
>> This is because AVX allows destination to be separate from both the sources. 
>> 
>> Please let me know if I am missing something.
>
> My bad - I missed that size is in bytes in assert. The assert is correct, as you said.
> And `} else {` part works for AVX1 because of match_rule_supported_vector() bailout 256-bit case.
> May be add assert(UseAVX > 1 || vlen_in_bytes <= 16, ).
> 
> I only have one question left - about check >= 256 in  match_rule_supported_vector()

Added the following assert on else path:
+      assert(UseAVX > 1 || vlen_in_bytes <= 16, "required");

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From sviswanathan at openjdk.java.net  Fri Feb 19 03:20:59 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 19 Feb 2021 03:20:59 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v4]
In-Reply-To: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
Message-ID: <oiXvsZVZ34pNFXgU217d1LsBGRWf1oemXm1EkzPqSX8=.e18b0607-d162-4784-9519-20e7aad4a382@github.com>

> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
> 
> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
> 
> Before:
> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
> 
> After:
> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  add assert on else path

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2520/files
  - new: https://git.openjdk.java.net/jdk/pull/2520/files/fa13679a..ad3ab2b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2520&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2520&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2520/head:pull/2520

PR: https://git.openjdk.java.net/jdk/pull/2520

From kvn at openjdk.java.net  Fri Feb 19 05:52:41 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 19 Feb 2021 05:52:41 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v3]
In-Reply-To: <lvswXG4miaKuicKDdydMQp8u0yA3UWvDoTEUQ4mdI2A=.485b327e-05b9-4637-ae8f-3df2ef06c196@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <4TNVM4VqqsezSVCJndS1RpM9EvIfICm5mv1AbZhthgg=.3943a37b-cce4-415e-989f-b9696ad6c008@github.com>
 <JnjDcrIcYReIwuPuGxNZowpke72Yv8KNn9C_xZaiSug=.80bf83d3-c0f2-442d-ab4f-344850e9acf8@github.com>
 <lvswXG4miaKuicKDdydMQp8u0yA3UWvDoTEUQ4mdI2A=.485b327e-05b9-4637-ae8f-3df2ef06c196@github.com>
Message-ID: <A-JNSAPUwgXxgkhwnXcNP2bwU4w0KyZcahLqaUQzOBg=.387a29ae-4eb9-4d5c-8ed2-758ce309abdb@github.com>

On Fri, 19 Feb 2021 02:30:58 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 1695:
>> 
>>> 1693:       if(vlen == 2) {
>>> 1694:         return false; // Implementation limitation due to how shuffle is loaded
>>> 1695:       } else if (size_in_bits == 256 && UseAVX < 2) {
>> 
>> Should this be >= 256?
>
> The general >= 256 part is taken care of early on in match_rule_supported_vector as below:
>   if (!vector_size_supported(bt, vlen)) {
>     return false;
>   }
> The only additional check that is being done here is for float and double  256 bit vectors that are supported on AVX=1 and will pass the vector_size_supported check.
> This is because the VectorLoadShuffle cannot be performed for 256 bit vectors on AVX1 platform as it needs "integer" 256 bit instructions which are only available on AVX2.

Okay.

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From kvn at openjdk.java.net  Fri Feb 19 05:52:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 19 Feb 2021 05:52:39 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v4]
In-Reply-To: <oiXvsZVZ34pNFXgU217d1LsBGRWf1oemXm1EkzPqSX8=.e18b0607-d162-4784-9519-20e7aad4a382@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <oiXvsZVZ34pNFXgU217d1LsBGRWf1oemXm1EkzPqSX8=.e18b0607-d162-4784-9519-20e7aad4a382@github.com>
Message-ID: <yWJLGc6QrSBQd6m6FgcL5DodZ1K-ZBm9yoC2hYDK154=.15c48777-076c-4a59-a1f1-711a337a5312@github.com>

On Fri, 19 Feb 2021 03:20:59 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
>> 
>> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
>> 
>> Before:
>> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
>> 
>> After:
>> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add assert on else path

Marked as reviewed by kvn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From kvn at openjdk.java.net  Fri Feb 19 05:52:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 19 Feb 2021 05:52:42 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v4]
In-Reply-To: <_0LW_Yx-ItDG7f-3kVjOTPa5BbcaN1FMRBbATLMwpmk=.da545e81-59a0-4d80-9f45-0714fe7bfc94@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <FI5CkAWEA32ePxgCnIgUeSACOpPBtjEv00k-nWXk7sE=.68fc3a19-c458-43a4-a153-e29935ebb670@github.com>
 <gw67s5Qv2iFMjIuGgMOkYvdxkQJPyCwu_yfqjezhqtI=.d33b8556-440d-4b7c-8546-8d24cc2ea880@github.com>
 <jWmSx7978dfrGJ8W6sulB2Hh6KUzk93PX0PloL5aEXQ=.d9dd196a-ad30-4fec-a426-8a774cf95de7@github.com>
 <XmT-nJoZoORWTKBdE2frOsja8eb_CZeC-bpKM16p3jw=.f0e9b3f9-adde-4922-8cfa-30d8ffeed351@github.com>
 <Ie_5LHtB4KuVE9MUf9FckVHJ2SPFN4VkN_2-8evzFrk=.fca5106f-3019-4d10-b120-bab251017731@github.com>
 <_0LW_Yx-ItDG7f-3kVjOTPa5BbcaN1FMRBbATLMwpmk=.da545e81-59a0-4d80-9f45-0714fe7bfc94@github.com>
Message-ID: <oCIQYOUz8jnax_zIr32nTbODeMKca2gDeUyJ7QMl_u0=.6a93be31-c4af-429e-b0b3-e8a037ca714c@github.com>

On Fri, 19 Feb 2021 03:17:56 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> My bad - I missed that size is in bytes in assert. The assert is correct, as you said.
>> And `} else {` part works for AVX1 because of match_rule_supported_vector() bailout 256-bit case.
>> May be add assert(UseAVX > 1 || vlen_in_bytes <= 16, ).
>> 
>> I only have one question left - about check >= 256 in  match_rule_supported_vector()
>
> Added the following assert on else path:
> +      assert(UseAVX > 1 || vlen_in_bytes <= 16, "required");

Good.

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From rcastanedalo at openjdk.java.net  Fri Feb 19 08:21:40 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 19 Feb 2021 08:21:40 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM [v2]
In-Reply-To: <WBRje2yMIjkAHorNMY9fCXP8etyR9ovJE3_E_z3Daho=.0126a0f1-52e2-4f95-972d-679ac618e4ae@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
 <lPfNhC5qyZOXkWNOHeI42Z35z1FgfxHUp26dVkkpnM4=.4a4221e0-a2b1-47bb-93a9-fa795527c5a4@github.com>
 <WBRje2yMIjkAHorNMY9fCXP8etyR9ovJE3_E_z3Daho=.0126a0f1-52e2-4f95-972d-679ac618e4ae@github.com>
Message-ID: <xZicjzilCigThGKFfyy9rjIM6iX1G5vZX9q9bnAZ5Wk=.2daa9bfd-2e91-4803-a236-8e2e6a4f45a5@github.com>

On Thu, 18 Feb 2021 12:38:46 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extract new logic out of buildUpGraph()
>
> Marked as reviewed by neliasso (Reviewer).

Replace backward traversal in the IGV block formation algorithm by forward
traversal guided by node category information. This change addresses the
reported assertion failures, places block projection nodes together with their
predecessors, and gives a more natural block numbering.

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

PR: https://git.openjdk.java.net/jdk/pull/2607

From rcastanedalo at openjdk.java.net  Fri Feb 19 08:21:40 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 19 Feb 2021 08:21:40 GMT
Subject: RFR: 8259984: IGV: Crash when drawing control flow before GCM [v2]
In-Reply-To: <-Qd5a0SApy6Cp07xQK_xyYmpsGEGxZ1vdAzaFQvmVDc=.df55812b-e6f4-4559-be03-9d4e06ed3f6e@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
 <lPfNhC5qyZOXkWNOHeI42Z35z1FgfxHUp26dVkkpnM4=.4a4221e0-a2b1-47bb-93a9-fa795527c5a4@github.com>
 <-Qd5a0SApy6Cp07xQK_xyYmpsGEGxZ1vdAzaFQvmVDc=.df55812b-e6f4-4559-be03-9d4e06ed3f6e@github.com>
Message-ID: <7RE9-JAx9l_fFB3TuY7N-YQJIjNiH11P3DYyOcI_H7k=.19c907f2-913e-4471-8324-3fa6fdde0565@github.com>

On Thu, 18 Feb 2021 12:21:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Looks good!

Thanks again, Christian.

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

PR: https://git.openjdk.java.net/jdk/pull/2607

From rcastanedalo at openjdk.java.net  Fri Feb 19 08:21:41 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 19 Feb 2021 08:21:41 GMT
Subject: Integrated: 8259984: IGV: Crash when drawing control flow before GCM
In-Reply-To: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
References: <WGd7s20vBXJXa0jjaRI0-HzbFW8x42WsFrmthWOt1Xo=.eb3efb09-088f-4fcb-8538-3442259f7315@github.com>
Message-ID: <ffAsH22bRZhuzUURZCLcfo9tXJjDqjXZINGJgrYy_vg=.ae83b20a-fd7d-448d-a7da-ccfa8a4ba969@github.com>

On Wed, 17 Feb 2021 12:23:55 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> The block formation algorithm applied by IGV to schedule graphs without associated CFG information traverses the graph backwards. This makes it difficult to deal with block projection nodes, leading in some cases to double addition of block nodes and block edges, and ultimately causing assertion failures.
> 
> This fix replaces the backward traversal by a forward traversal that relies on node category information (introduced in [8261336](https://bugs.openjdk.java.net/browse/JDK-8261336)) to identify control successors. The forward traversal is arguably simpler and, besides avoiding the reported assertion failure, has two advantages:
> 
> - it places block projection nodes in the same block as their predecessors, and
> - it numbers basic blocks more naturally.
> 
> The following screenshots illustrate the improvements (before the fix to the left, after the fix to the right):
> 
> ![cfgs-before-after](https://user-images.githubusercontent.com/8792647/108204708-6dcf5e00-7124-11eb-956c-fb7f84229b50.png)
> 
> Tested automatically on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented version of IGV that schedules graphs eagerly. Checked manually that the CFGs of a few selected graphs (included the reported one) are well-formed. Also checked that the overall IGV graph scheduling time is not affected by the changes.
> 
> Thanks to Christian Hagedorn for checking the fix independently.

This pull request has now been integrated.

Changeset: 61820b74
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/61820b74
Stats:     169 lines in 1 file changed: 92 ins; 15 del; 62 mod

8259984: IGV: Crash when drawing control flow before GCM

Replace backward traversal in the IGV block formation algorithm by forward
traversal guided by node category information. This change addresses the
reported assertion failures, places block projection nodes together with their
predecessors, and gives a more natural block numbering.

Reviewed-by: chagedorn, neliasso

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

PR: https://git.openjdk.java.net/jdk/pull/2607

From neliasso at openjdk.java.net  Fri Feb 19 09:31:41 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 19 Feb 2021 09:31:41 GMT
Subject: RFR: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors [v4]
In-Reply-To: <oiXvsZVZ34pNFXgU217d1LsBGRWf1oemXm1EkzPqSX8=.e18b0607-d162-4784-9519-20e7aad4a382@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
 <oiXvsZVZ34pNFXgU217d1LsBGRWf1oemXm1EkzPqSX8=.e18b0607-d162-4784-9519-20e7aad4a382@github.com>
Message-ID: <4j6fwKgy-WwLXNITZYeqzBVreGvoYli08IP4OxpnmUI=.7d07c386-7778-43e3-8245-5c13b411a63d@github.com>

On Fri, 19 Feb 2021 03:20:59 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
>> 
>> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
>> 
>> Before:
>> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
>> 
>> After:
>> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
>> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
>> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add assert on else path

Looks good.

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

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2520

From dnsimon at openjdk.java.net  Fri Feb 19 11:26:03 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Fri, 19 Feb 2021 11:26:03 GMT
Subject: RFR: 8262011: [JVMCI] allow printing to tty from unattached
 libgraal thread
In-Reply-To: <tTReCuJ52xHBFDb9nQRDySq9FiFCMFOY5QtIFGHWg-8=.d921d4cd-af3c-4b85-a75b-60fed6809408@github.com>
References: <tTReCuJ52xHBFDb9nQRDySq9FiFCMFOY5QtIFGHWg-8=.d921d4cd-af3c-4b85-a75b-60fed6809408@github.com>
Message-ID: <AgYZdxoUldoTuegRiupIDbPV6eXXtr4L00lMXzVfV5s=.09715e87-9aa2-4ef1-9c21-09a69a5cd2d5@github.com>

On Fri, 19 Feb 2021 10:10:17 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Currently, `HotSpotJVMCIRuntime.writeDebugOutput` does nothing if the current thread is not attached to HotSpot (i.e., `Thread::current_or_null() == NULL`). This means crucial debug info can be lost. For reference, an unattached libgraal thread is a thread started from within libgraal that has not yet attached itself to the VM (e.g., before [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L42)) or has already detached itself (e.g., after [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L46)).
> 
> The reason for the current behavior is that `HotSpotJVMCIRuntime.writeDebugOutput` passes a Java byte array to C++ code and the C++ code calls back into Java to decode the byte array into a native buffer. These call backs require the current thread to be attached to the VM.
> 
> This PR moves the Java-to-native-buffer decoding into Java and thus avoids the requirement for the current thread to be attached to the VM.
> 
> Tested in libgraal by patching Graal as follows:
> diff --git a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> index 36064767c95..352395dd59b 100644
> --- a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> +++ b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> @@ -43,7 +43,14 @@ public class GraalServiceThread extends Thread {
>          try {
>              runnable.run();
>          } finally {
> +            String debug = System.getenv("GraalServiceThread.debug");
>              afterRun();
> +            if ("true".equals(debug)) {
> +                throw new InternalError("THROWN AFTER DETACHING");
> +            }
>          }
>      }
> 
> Running without the changes in this PR:
>> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
> ===== DaCapo 9.12 avrora starting =====
> ===== DaCapo 9.12 avrora PASSED in 4270 msec =====
> 
> Running with the changes in this PR:
>> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
> ===== DaCapo 9.12 avrora starting =====
> Exception in thread "LibGraalHotSpotGraalManagement-init" java.lang.InternalError: THROWN AFTER DETACHING
> 	at org.graalvm.compiler.core.GraalServiceThread.run(GraalServiceThread.java:52)
> 	at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:519)
> 	at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)
> ===== DaCapo 9.12 avrora PASSED in 4688 msec =====

src/hotspot/share/jvmci/jvmci.cpp line 220:

> 218:     Thread* thread = Thread::current_or_null_safe();
> 219:     if (thread != NULL) {
> 220:       events->logv(thread, format, ap);

This fixes a bug found while testing this PR. The `StringEventLog::logv` method requires the current thread to not be NULL.

test/hotspot/jtreg/compiler/jvmci/compilerToVM/DebugOutputTest.java line 1:

> 1: /*

DebugOutputTest has been removed since it's redundant with TestHotSpotJVMCIRuntime.writeDebugOutputTest.

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

PR: https://git.openjdk.java.net/jdk/pull/2640

From dnsimon at openjdk.java.net  Fri Feb 19 11:26:02 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Fri, 19 Feb 2021 11:26:02 GMT
Subject: RFR: 8262011: [JVMCI] allow printing to tty from unattached libgraal
 thread
Message-ID: <tTReCuJ52xHBFDb9nQRDySq9FiFCMFOY5QtIFGHWg-8=.d921d4cd-af3c-4b85-a75b-60fed6809408@github.com>

Currently, `HotSpotJVMCIRuntime.writeDebugOutput` does nothing if the current thread is not attached to HotSpot (i.e., `Thread::current_or_null() == NULL`). This means crucial debug info can be lost. For reference, an unattached libgraal thread is a thread started from within libgraal that has not yet attached itself to the VM (e.g., before [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L42)) or has already detached itself (e.g., after [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L46)).

The reason for the current behavior is that `HotSpotJVMCIRuntime.writeDebugOutput` passes a Java byte array to C++ code and the C++ code calls back into Java to decode the byte array into a native buffer. These call backs require the current thread to be attached to the VM.

This PR moves the Java-to-native-buffer decoding into Java and thus avoids the requirement for the current thread to be attached to the VM.

Tested in libgraal by patching Graal as follows:
diff --git a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
index 36064767c95..352395dd59b 100644
--- a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
+++ b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
@@ -43,7 +43,14 @@ public class GraalServiceThread extends Thread {
         try {
             runnable.run();
         } finally {
+            String debug = System.getenv("GraalServiceThread.debug");
             afterRun();
+            if ("true".equals(debug)) {
+                throw new InternalError("THROWN AFTER DETACHING");
+            }
         }
     }

Running without the changes in this PR:
> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
===== DaCapo 9.12 avrora starting =====
===== DaCapo 9.12 avrora PASSED in 4270 msec =====

Running with the changes in this PR:
> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
===== DaCapo 9.12 avrora starting =====
Exception in thread "LibGraalHotSpotGraalManagement-init" java.lang.InternalError: THROWN AFTER DETACHING
	at org.graalvm.compiler.core.GraalServiceThread.run(GraalServiceThread.java:52)
	at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:519)
	at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)
===== DaCapo 9.12 avrora PASSED in 4688 msec =====

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

Commit messages:
 - 8262011: [JVMCI] allow printing to tty from unattached libgraal thread

Changes: https://git.openjdk.java.net/jdk/pull/2640/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2640&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262011
  Stats: 322 lines in 8 files changed: 49 ins; 246 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2640.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2640/head:pull/2640

PR: https://git.openjdk.java.net/jdk/pull/2640

From vlivanov at openjdk.java.net  Fri Feb 19 12:02:39 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 19 Feb 2021 12:02:39 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>
Message-ID: <Fa8id8vmDsDsmrVi5O9Y6y85Er4C8pbCIo2c5RYiIzo=.65679833-a5cb-4795-8b2d-32ac70184a73@github.com>

On Thu, 18 Feb 2021 22:36:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
>> 
>> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
>> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
>> 
>> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
>> 
>> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier8
>> - [x] additional verification that CHA decisions aren't affected
>
> src/hotspot/share/oops/instanceKlass.hpp line 1486:
> 
>> 1484:   }
>> 1485: };
>> 1486: 
> 
> The _subklass and _next_sibling fields and implementation are in Klass (klass.hpp/cpp) but I always wonder why they are not in InstanceKlass (instanceKlass.hpp/cpp).  If this new class is in instanceKlass.hpp, these fields should be in the same.  If you agree, we should file an RFE and I will move them.  If the fields truly belong in klass.hpp, then this should be there too. ie. they should match.

I think it's `java.lang.Object` which complicates things. All array classes are rooted at Object, so neither `_subklass` nor  `_next_sibling` can be changed to `InstanceKlass`. I put `ClassHierarchyIterator` in `instanceKlass.hpp` primarily because it accepts only `InstanceKlass` root class. But I'm fine with putting it into `klass.hpp`.

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From vlivanov at openjdk.java.net  Fri Feb 19 12:10:43 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 19 Feb 2021 12:10:43 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>
Message-ID: <YQYesacVHyBYzLeWQjGaIlzIG72VpO3rgT_CZh1vqi8=.48030076-3e32-4836-9c8f-0295bfbe65fa@github.com>

On Thu, 18 Feb 2021 22:40:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
>> 
>> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
>> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
>> 
>> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
>> 
>> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier8
>> - [x] additional verification that CHA decisions aren't affected
>
> src/hotspot/share/code/dependencies.cpp line 1345:
> 
>> 1343:     } else if (nof_impls == 1) { // unique implementor
>> 1344:       assert(context_type != context_type->implementor(), "not unique");
>> 1345:       context_type = InstanceKlass::cast(context_type->implementor());
> 
> There's no reason that implementor() should return Klass* rather than InstanceKlass* ? We can clean that up also later to reduce casts. (I thought I already tried to do this once).

Yes, I don't see a compelling reason for `implementor()` to return `Klass*` instead of `InstanceKlass*`. Would be nice to clean it up. Do you want me to file an RFE?

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From coleenp at openjdk.java.net  Fri Feb 19 13:00:43 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 19 Feb 2021 13:00:43 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <Fa8id8vmDsDsmrVi5O9Y6y85Er4C8pbCIo2c5RYiIzo=.65679833-a5cb-4795-8b2d-32ac70184a73@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>
 <Fa8id8vmDsDsmrVi5O9Y6y85Er4C8pbCIo2c5RYiIzo=.65679833-a5cb-4795-8b2d-32ac70184a73@github.com>
Message-ID: <hX5m-X_YWO0TGq-Vz97-ALBq1p2BETIcuuTkuqu-ey0=.f0779fe5-c2f9-4b1f-94c6-516af88152a9@github.com>

On Fri, 19 Feb 2021 12:00:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.hpp line 1486:
>> 
>>> 1484:   }
>>> 1485: };
>>> 1486: 
>> 
>> The _subklass and _next_sibling fields and implementation are in Klass (klass.hpp/cpp) but I always wonder why they are not in InstanceKlass (instanceKlass.hpp/cpp).  If this new class is in instanceKlass.hpp, these fields should be in the same.  If you agree, we should file an RFE and I will move them.  If the fields truly belong in klass.hpp, then this should be there too. ie. they should match.
>
> I think it's `java.lang.Object` which complicates things. All array classes are rooted at Object, so neither `_subklass` nor  `_next_sibling` can be changed to `InstanceKlass`. I put `ClassHierarchyIterator` in `instanceKlass.hpp` primarily because it accepts only `InstanceKlass` root class. But I'm fine with putting it into `klass.hpp`.

Does the compiler dependencies use the _subklass lists for array classes?  The only other use for this is vtable reinitialization.  It is fine to leave ClassHIerarchyIterator in instanceKlass.hpp since that's how it's used in this change. I might investigate this more some later time.

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From coleenp at openjdk.java.net  Fri Feb 19 13:03:42 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 19 Feb 2021 13:03:42 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <YQYesacVHyBYzLeWQjGaIlzIG72VpO3rgT_CZh1vqi8=.48030076-3e32-4836-9c8f-0295bfbe65fa@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>
 <YQYesacVHyBYzLeWQjGaIlzIG72VpO3rgT_CZh1vqi8=.48030076-3e32-4836-9c8f-0295bfbe65fa@github.com>
Message-ID: <guFwhcjAPT7Pr4PPPsBlqbTTnOaI_qFzr7xdtGVoKCU=.19471807-4ccf-45e7-bfe7-6637516d54be@github.com>

On Fri, 19 Feb 2021 12:07:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/code/dependencies.cpp line 1345:
>> 
>>> 1343:     } else if (nof_impls == 1) { // unique implementor
>>> 1344:       assert(context_type != context_type->implementor(), "not unique");
>>> 1345:       context_type = InstanceKlass::cast(context_type->implementor());
>> 
>> There's no reason that implementor() should return Klass* rather than InstanceKlass* ? We can clean that up also later to reduce casts. (I thought I already tried to do this once).
>
> Yes, I don't see a compelling reason for `implementor()` to return `Klass*` instead of `InstanceKlass*`. Would be nice to clean it up. Do you want me to file an RFE?

I just filed one.  We've been trying to make metadata types more specific for years and must have missed this one.

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From vlivanov at openjdk.java.net  Fri Feb 19 13:26:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 19 Feb 2021 13:26:42 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <hX5m-X_YWO0TGq-Vz97-ALBq1p2BETIcuuTkuqu-ey0=.f0779fe5-c2f9-4b1f-94c6-516af88152a9@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>
 <Fa8id8vmDsDsmrVi5O9Y6y85Er4C8pbCIo2c5RYiIzo=.65679833-a5cb-4795-8b2d-32ac70184a73@github.com>
 <hX5m-X_YWO0TGq-Vz97-ALBq1p2BETIcuuTkuqu-ey0=.f0779fe5-c2f9-4b1f-94c6-516af88152a9@github.com>
Message-ID: <V6MxBMWch5AU-5mT2c_ZJtkWY9f9xiBHJXWvcjmPXpI=.27cce847-ce85-4c8a-8c64-c3442b2b5ba8@github.com>

On Fri, 19 Feb 2021 12:57:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Does the compiler dependencies use the _subklass lists for array classes?

Arrays aren't interesting in the context of CHA (which `Dependencies` implements), so they are handled only because they are encountered during hierarchy traversal under `java.lang.Object`:
  bool is_witness(Klass* k) {
    if (doing_subtype_search()) {
      return Dependencies::is_concrete_klass(k);
    } else if (!k->is_instance_klass()) {
      return false; // no methods to find in an array type
    } else {
      ...

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From vlivanov at openjdk.java.net  Fri Feb 19 13:39:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 19 Feb 2021 13:39:40 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <OWnBFi159PzKTBb7VkJ3vjQTYDizhDnaMaiaTETqTGY=.14da164e-15a3-4da1-9a2b-06ef8be7e5e8@github.com>
Message-ID: <TJAtnRQC-eHt0zBDM2ddhbr9TpIdgJhxMoJn7nZpYnI=.4bc52d9e-889b-46c7-83b6-860819de5038@github.com>

On Thu, 18 Feb 2021 22:41:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
>> 
>> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
>> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
>> 
>> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
>> 
>> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier8
>> - [x] additional verification that CHA decisions aren't affected
>
> This seems like a nice change.  Some questions.

Thanks for the reviews, Vladimir and Coleen.

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From eosterlund at openjdk.java.net  Fri Feb 19 14:03:44 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 19 Feb 2021 14:03:44 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
Message-ID: <B3HdvH6MjazQ3IahZQqikaeBS15_Rd-0oS72uzWPJdM=.9df65965-0492-4bcf-8a9b-0e066123758f@github.com>

On Thu, 18 Feb 2021 17:05:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
> 
> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
> 
> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
> 
> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
> 
> Testing:
> - [x] hs-tier1 - hs-tier8
> - [x] additional verification that CHA decisions aren't affected

It looks like there is a traversal bug lurking here, unless I missed something. Looks great otherwise.

src/hotspot/share/oops/instanceKlass.hpp line 1457:

> 1455:   // Make a step iterating over the class hierarchy under the root class.
> 1456:   // Skips subclasses if requested.
> 1457:   void next() {

Since this method is a bit involved, I think it might want to move to the cpp file.

src/hotspot/share/oops/instanceKlass.hpp line 1461:

> 1459:     if (_visit_subclasses && _current->subklass() != NULL) {
> 1460:       _current = _current->subklass();
> 1461:       return; // visit next subclass

_visit_subclasses is initially true in the constructor. That seems to imply that after the first call to next(), we will take this path, just returning the subklass() without walking the siblings. The _visit_subclasses variable is never mutated away from the true state at all if it was already true, until we get to the bottom of the class hierarchy. That seems to imply that the next() iterator won't visit any siblings at all until we get to the bottom of the class hierarchy, essentially breaking the DFS traversal. Therefore, it looks to me like the use of the _visit_subclasses variable needs to be looked over a bit in this function in general, unless I misunderstood something.

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

Changes requested by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2630

From aph at openjdk.java.net  Fri Feb 19 14:46:41 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 19 Feb 2021 14:46:41 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v7]
In-Reply-To: <pr96wBAOH_0dbHHpJYmcmBKlPUIm8EXjiRjNHxTGN68=.4b42d8a4-3195-4f6b-bb98-d64786d632c7@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <pr96wBAOH_0dbHHpJYmcmBKlPUIm8EXjiRjNHxTGN68=.4b42d8a4-3195-4f6b-bb98-d64786d632c7@github.com>
Message-ID: <1zpEXArPUG-5mAnHqc7E-YBJ_whPIr0KWpSrgqV2mnQ=.d72ed309-938a-4d6a-9bbc-0a8f065c8411@github.com>

On Fri, 19 Feb 2021 03:13:12 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
>> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
>> 
>> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
>> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
>> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
>> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
>> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
>> 
>> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
>> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
>> 
>> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
>> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.
>
> Dong Bo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   handle zero shift in macro assembler

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 554:

> 552: 
> 553:   WRAP(usra) WRAP(ssra)
> 554: #undef WRAP

Are ssra and usra tested by anything? I don't seem them accessed in the test case.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 531:

> 529: 
> 530:   // NEON shift instructions
> 531: #define WRAP(INSN)                                                                \

This comment should  be

  // AdvSIMD shift by immediate.     
  // These are "user friendly" variants which allow a shift count of 0.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From vlivanov at openjdk.java.net  Fri Feb 19 15:23:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 19 Feb 2021 15:23:42 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <B3HdvH6MjazQ3IahZQqikaeBS15_Rd-0oS72uzWPJdM=.9df65965-0492-4bcf-8a9b-0e066123758f@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <B3HdvH6MjazQ3IahZQqikaeBS15_Rd-0oS72uzWPJdM=.9df65965-0492-4bcf-8a9b-0e066123758f@github.com>
Message-ID: <7QNflPk493_-jk-ajLWMWdFVmqFwS7uLOFramnT7a_U=.de35bc6b-c490-4351-bf76-4a37bcc4397d@github.com>

On Fri, 19 Feb 2021 13:52:35 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
>> 
>> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
>> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
>> 
>> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
>> 
>> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier8
>> - [x] additional verification that CHA decisions aren't affected
>
> src/hotspot/share/oops/instanceKlass.hpp line 1461:
> 
>> 1459:     if (_visit_subclasses && _current->subklass() != NULL) {
>> 1460:       _current = _current->subklass();
>> 1461:       return; // visit next subclass
> 
> _visit_subclasses is initially true in the constructor. That seems to imply that after the first call to next(), we will take this path, just returning the subklass() without walking the siblings. The _visit_subclasses variable is never mutated away from the true state at all if it was already true, until we get to the bottom of the class hierarchy. That seems to imply that the next() iterator won't visit any siblings at all until we get to the bottom of the class hierarchy, essentially breaking the DFS traversal. Therefore, it looks to me like the use of the _visit_subclasses variable needs to be looked over a bit in this function in general, unless I misunderstood something.

`_visit_subclasses` is mutated only from the outside (there's `ClassHierarchyIterator::skip_subclasses()` specificlaly for that) when user code needs to ignore subclasses:

https://github.com/openjdk/jdk/blob/ae78e51e4248c2ccfa73c772fb1db1baad2c2903/src/hotspot/share/code/dependencies.cpp#L1359:

  for (ClassHierarchyIterator iter(context_type); !iter.done(); iter.next()) {
    Klass* sub = iter.klass();

    // Do not report participant types.
    if (is_participant(sub)) {
      // Walk beneath a participant only when it doesn't hide witnesses.
      if (participants_hide_witnesses) {
        iter.skip_subclasses();
      }

And `_visit_subclasses` is cleared to the initial state on the very next call to `next()`.

> That seems to imply that the next() iterator won't visit any siblings at all until we get to the bottom of the class hierarchy, essentially breaking the DFS traversal.

Yes, that's the intended behavior. Why do think it doesn't obey depth-first order? `next_sibling()` points to a class on the same level of class hierarchy.

> src/hotspot/share/oops/instanceKlass.hpp line 1457:
> 
>> 1455:   // Make a step iterating over the class hierarchy under the root class.
>> 1456:   // Skips subclasses if requested.
>> 1457:   void next() {
> 
> Since this method is a bit involved, I think it might want to move to the cpp file.

Good point.

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From iveresov at openjdk.java.net  Fri Feb 19 15:45:58 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 19 Feb 2021 15:45:58 GMT
Subject: RFR: 8261225: TieredStopAtLevel should have no effect if
 TieredCompilation is disabled
Message-ID: <AveljBM2ujASJ9cw91-W7c0KQ9Mpx6oyUKkl60eNF2o=.dbcbdc4a-2acb-406b-8264-a0e77f8ad424@github.com>

Ignore TieredStopAtLevel flag is TieredCompilation is off for compatibility with the old compilation policy. Also did some polishing of things that came up in the process.

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

Commit messages:
 - Ignore TieredStopAtLevel flag is TieredCompilation is off, polish.

Changes: https://git.openjdk.java.net/jdk/pull/2647/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2647&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261225
  Stats: 137 lines in 3 files changed: 101 ins; 20 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2647.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2647/head:pull/2647

PR: https://git.openjdk.java.net/jdk/pull/2647

From eosterlund at openjdk.java.net  Fri Feb 19 15:55:42 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 19 Feb 2021 15:55:42 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <7QNflPk493_-jk-ajLWMWdFVmqFwS7uLOFramnT7a_U=.de35bc6b-c490-4351-bf76-4a37bcc4397d@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <B3HdvH6MjazQ3IahZQqikaeBS15_Rd-0oS72uzWPJdM=.9df65965-0492-4bcf-8a9b-0e066123758f@github.com>
 <7QNflPk493_-jk-ajLWMWdFVmqFwS7uLOFramnT7a_U=.de35bc6b-c490-4351-bf76-4a37bcc4397d@github.com>
Message-ID: <QundqEWthp2xpaGFIp5LcqByQxE8MUjq9MMtWpJzJq0=.f892fd29-6631-43c1-a0fb-428484ade9b1@github.com>

On Fri, 19 Feb 2021 15:20:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.hpp line 1461:
>> 
>>> 1459:     if (_visit_subclasses && _current->subklass() != NULL) {
>>> 1460:       _current = _current->subklass();
>>> 1461:       return; // visit next subclass
>> 
>> _visit_subclasses is initially true in the constructor. That seems to imply that after the first call to next(), we will take this path, just returning the subklass() without walking the siblings. The _visit_subclasses variable is never mutated away from the true state at all if it was already true, until we get to the bottom of the class hierarchy. That seems to imply that the next() iterator won't visit any siblings at all until we get to the bottom of the class hierarchy, essentially breaking the DFS traversal. Therefore, it looks to me like the use of the _visit_subclasses variable needs to be looked over a bit in this function in general, unless I misunderstood something.
>
> `_visit_subclasses` is mutated only from the outside (there's `ClassHierarchyIterator::skip_subclasses()` specificlaly for that) when user code needs to ignore subclasses:
> 
> https://github.com/openjdk/jdk/blob/ae78e51e4248c2ccfa73c772fb1db1baad2c2903/src/hotspot/share/code/dependencies.cpp#L1359:
> 
>   for (ClassHierarchyIterator iter(context_type); !iter.done(); iter.next()) {
>     Klass* sub = iter.klass();
> 
>     // Do not report participant types.
>     if (is_participant(sub)) {
>       // Walk beneath a participant only when it doesn't hide witnesses.
>       if (participants_hide_witnesses) {
>         iter.skip_subclasses();
>       }
> 
> And `_visit_subclasses` is cleared to the initial state on the very next call to `next()`.
> 
>> That seems to imply that the next() iterator won't visit any siblings at all until we get to the bottom of the class hierarchy, essentially breaking the DFS traversal.
> 
> Yes, that's the intended behavior. Why do think it doesn't obey depth-first order? `next_sibling()` points to a class on the same level of class hierarchy.

Okay, I see. So you traverse all the way down, following the subclass links until you can't go further, and then traverse the siblings on the way up. That makes sense. Thanks for the explanation.

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From eosterlund at openjdk.java.net  Fri Feb 19 15:55:40 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 19 Feb 2021 15:55:40 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
Message-ID: <Ns-Tfx2SKmW2ZgaUsm_Z3y_oUhWaTOsCDkecMYdSxHw=.a09fedc1-78ce-4c22-801e-a0d32b17a14d@github.com>

On Thu, 18 Feb 2021 17:05:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
> 
> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
> 
> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
> 
> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
> 
> Testing:
> - [x] hs-tier1 - hs-tier8
> - [x] additional verification that CHA decisions aren't affected

Looks good! (move next() to cpp file if you want to)

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

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2630

From nhe at activeviam.com  Fri Feb 19 16:54:37 2021
From: nhe at activeviam.com (Nicolas Heutte)
Date: Fri, 19 Feb 2021 17:54:37 +0100
Subject: [External] : Re: SuperWord loop optimization lost after method
 inlining
In-Reply-To: <09a53249-00de-91c1-d88b-6c816ce6dd14@oracle.com>
References: <CAOqmmc0ue3bLMBgWLAvUOrHLe2iNtoSiBiq=+Beky-D=MkA+fw@mail.gmail.com>
 <b9184f85-c869-8088-a080-2d860dca5f9f@oracle.com>
 <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
 <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>
 <CAOqmmc2mWWr2mWoitEz71xc1PZ53ZLhyDfRQ+TjxKRcuGcxNkg@mail.gmail.com>
 <08ce2121-bbb4-3ea5-8f05-efeb33df7b74@oracle.com>
 <CAOqmmc1PKCWgC0n+7WkFDz7vAzxfLpZH4ThQnSL=6yQO5Ghrxg@mail.gmail.com>
 <09a53249-00de-91c1-d88b-6c816ce6dd14@oracle.com>
Message-ID: <CAOqmmc3+Vw9uXJkx=N8dPX0iyRYmXNvj-iveSN+faoiojL+rwA@mail.gmail.com>

Hello Vladimir,

I've added the requested log to the shared folder (
https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing).
I've also tried disabling the strip mining optimization as you suggested,
but there was no significant performance change.

Best regards,
Nicolas Heutte

On Wed, Feb 17, 2021 at 9:05 PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Unfortunately it is still not the file I am looking for.
>
> First, remove -XX:+PrintAssembly flag from command line. I have already
> files with assembler code.
>
> Second, I see link to the file I am looking for:
> <thread_logfile thread='16812'
> filename='C:\Users\NicolasHeutte\AppData\Local\Temp\\hs_c16812_pid15016.log'/>
>
> If you still have it, please send it. If application stopped before normal
> exit that file is not merged into
> hotspot_pid<PID>.log file.
>
> If you don't have it - do an other run with -XX:CICompilerCount=1 to use
> only one C2 compiler thread with Tiered off. It
> will simplify ordering of log.
>
> You can also do an other experiment without collecting log. Run app with
> next flags to disable loop strip minning
> optimization:  -XX:-UseCountedLoopSafepoints -XX:LoopStripMiningIter=0
>
> Thanks,
> Vladimir K
>
> On 2/17/21 2:34 AM, Nicolas Heutte wrote:
> > Hi Vladimir,
> >
> > I have rerun the test with the appropriate options, the obtained logs
> are in this folder:
> >
> https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing
> > <
> https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvvSUuoKhQ$
> >
> >
> > Best regards,
> > Nicolas Heutte
> >
> > On Tue, Feb 16, 2021 at 11:35 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> >
> >     Hi Nicolas,
> >
> >     The file you shared has only assembler code. Yes, it shows that when
> ArrayFloatToArrayFloatVectorBinding::plus() is
> >     inlined into AVector::plus() it is not vectorized.
> >
> >     But I asked for an other file (hotspot_pid<PID>.log) which is
> generated when you run app with
> >     -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation flags. It should
> start with:
> >
> >     <?xml version='1.0' encoding='UTF-8'?>
> >     <hotspot_log version='160 1' process='2302014'
> time_ms='1613514688748'>
> >     <vm_version>
> >     <name>
> >     Java HotSpot(TM) 64-Bit Server VM
> >     </name>
> >     <release>
> >     11.0.9+7-LTS
> >     </release>
> >
> >     Thanks,
> >     Vladimir K
> >
> >     On 2/15/21 5:19 AM, Nicolas Heutte wrote:
> >      > Hi Vladimir,
> >      >
> >      > I've tried disabling tiered compilation, as you requested. It
> seems that the inlining was performed slightly
> >      > differently, but the issue remains. As you can see in this
> excerpt, the main loop isn't properly vectorized:
> >      >
> >      >    0x00000254b0d4bf54: cmp    %r11d,%r8d
> >      >    0x00000254b0d4bf57: jae    0x00000254b0d4c19e
> >      >    0x00000254b0d4bf5d: vmovss 0x10(%rcx,%r8,4),%xmm9  ;*faload
> {reexecute=0 rethrow=0 return_oop=0}
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
> (line 41)
> >      >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
> >      >                                                  ; -
> >      >
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >      >                                                  ; -
> com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
> >     (line 118)
> >      >
> >      >    0x00000254b0d4bf64: cmp    %ebx,%r8d
> >      >    0x00000254b0d4bf67: jae    0x00000254b0d4c1ec
> >      >    0x00000254b0d4bf6d: vaddss 0x10(%rdi,%r8,4),%xmm9,%xmm9
> >      >    0x00000254b0d4bf74: vmovss %xmm9,0x10(%rcx,%r8,4)  ;*fastore
> {reexecute=0 rethrow=0 return_oop=0}
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> (line 41)
> >      >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
> >      >                                                  ; -
> >      >
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >      >                                                  ; -
> com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
> >     (line 118)
> >      >
> >      >    0x00000254b0d4bf7b: inc    %r8d               ;*iinc
> {reexecute=0 rethrow=0 return_oop=0}
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> (line 40)
> >      >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
> >      >                                                  ; -
> >      >
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >      >                                                  ; -
> com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
> >     (line 118)
> >      >
> >      >    0x00000254b0d4bf7e: cmp    %r9d,%r8d
> >      >    0x00000254b0d4bf81: jl     0x00000254b0d4bf54  ;*goto
> {reexecute=0 rethrow=0 return_oop=0}
> >      >                                                  ; -
> >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> (line 40)
> >      >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2 (line 103)
> >      >                                                  ; -
> >      >
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >      >                                                  ; -
> com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
> >     (line 118)
> >      >
> >      >
> >      >
> >      > Here is the link to the full log, should you want to take a look
> at it:
> >      >
> https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing
> >     <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvuMpg6inQ$
> >
> >
> >      >
> >     <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$
> >     <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$
> >>
> >      >
> >      > Best regards,
> >      > Nicolas Heutte
> >      >
> >      > On Thu, Feb 11, 2021 at 7:05 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
> >     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com>>> wrote:
> >      >
> >      >     Changing wide mailing list to JIT compiler only.
> >      >
> >      >     This deoptimization is normal in Tiered Compilation - it
> switched from profiling code (level='3') generated by C1
> >      >     compiler to new code generated by C2 (level='4') which does
> loop optimizations.
> >      >
> >      >     Thank you for posting inlining information:
> >      >
> >      >           @ 17
>  com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
> bytes) inline (hot)
> >      >              \-> TypeProfile (14054/14054 counts) =
> com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
> >      >
> >      >     I thought before that may be call site is not hot but it is
> not the case.
> >      >
> >      >     You can do an other experiment to collect log with disabled
> Tiered Compilation (only C2 is used):
> >     -XX:-TieredCompilation
> >      >     Also print assembler code (as you did before) for final
> compilation to see if loop is still not vectorized.
> >      >
> >      >     Is it possible to post log file (on GitHub?) for me to look?
> >      >
> >      >     Thanks,
> >      >     Vladimir K
> >      >
> >      >     On 2/11/21 6:28 AM, Nicolas Heutte wrote:
> >      >      > Hi Vladimir,
> >      >      >
> >      >      > Thank you for your help.
> >      >      >
> >      >      > I'm currently running Java 11.0.9, and I did not use any
> VM flag of note.
> >      >      >
> >      >      > I checked the content of the compilation log, and it seems
> that
> >     ArrayFloatToArrayFloatVectorBinding::plus() was
> >      >      > deoptimized in order to allow AVector::plus() to be
> compiled:
> >      >      >
> >      >      > <writer thread='11576'/>
> >      >      > <task_queued compile_id='17280'
> method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V'
> >     bytes='23'
> >      >      > count='916' iicount='916' level='3' stamp='7394.056'
> comment='tiered' hot_count='896'/>
> >      >      > <writer thread='15784'/>
> >      >      > <deoptimized thread='15784' reason='constraint'
> pc='0x00000296d0785b94' compile_id='17257' compiler='c1'
> >     level='3'>
> >      >      > <jvms bci='65'
> method='com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding plus
> >      >      > (Lcom/qfs/vector/IVector;Lcom/qfs/vector/IVector;)V'
> bytes='69' count='909' backedge_count='155602'
> >     iicount='910'/>
> >      >      > </deoptimized>
> >      >      >
> >      >      > The last compilation entry for AVector::plus() is:
> >      >      >
> >      >      > <writer thread='16380'/>
> >      >      > <nmethod compile_id='17317' compiler='c2' level='4'
> entry='0x00000296d6af32c0' size='1960'
> >      >     address='0x00000296d6af3110'
> >      >      > relocation_offset='376' insts_offset='432'
> stub_offset='1040' scopes_data_offset='1152'
> >     scopes_pcs_offset='1592'
> >      >      > dependencies_offset='1880' nul_chk_table_offset='1896'
> oops_offset='1064' metadata_offset='1072'
> >      >      > method='com.qfs.vector.impl.AVector plus
> (Lcom/qfs/vector/IVector;)V' bytes='23' count='172425'
> >     iicount='172425'
> >      >      > stamp='7394.199'/>
> >      >      > <make_not_entrant thread='16380' compile_id='17280'
> compiler='c1' level='2' stamp='7394.199'/>
> >      >      >                                @ 1
> com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes)
> >     inline
> >      >     (hot)
> >      >      >                                 \-&gt; TypeProfile
> (14552/14552 counts) =
> >     com/qfs/vector/array/impl/ArrayFloatVector
> >      >      >                                @ 7
> com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4 bytes)
> >     inline
> >      >     (hot)
> >      >      >                                 \-&gt; TypeProfile
> (14150/14150 counts) =
> >     com/qfs/vector/array/impl/ArrayFloatVector
> >      >      >                                @ 10
> com.qfs.vector.binding.impl.VectorBindings::getBinding (9 bytes)
> >     inline (hot)
> >      >      >                                  @ 5
> >      >
>  com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::getBinding
> (22
> >      >      > bytes)   inline (hot)
> >      >      >                                    @ 3
> >      >
>  com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::hasBinding
> >      >      > (34 bytes)   inline (hot)
> >      >      >                                @ 17
> >
>  com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
> >      >     bytes)
> >      >      > inline (hot)
> >      >      >                                 \-&gt; TypeProfile
> (14054/14054 counts) =
> >      >      >
> com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
> >      >      >                                  @ 12
> com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)
> >     inline (hot)
> >      >      >                                  @ 22
> com.qfs.vector.impl.AVector::checkIndex (37 bytes)   inline (hot)
> >      >      >                                    @ 6
> com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)
> >     inline (hot)
> >      >      >                                  @ 27
> com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)
> >      >     accessor
> >      >      >                                  @ 34
> com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying (5 bytes)
> >      >     accessor
> >      >      > <writer thread='15896'/>
> >      >      >
> >      >      > Unfortunately, I do not have access to a debug VM build,
> so I cannot run the second test you recommend.
> >      >      >
> >      >      > Best regards,
> >      >      > Nicolas Heutte
> >      >      >
> >      >      > On Wed, Feb 10, 2021 at 7:36 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com
> >     <mailto:vladimir.kozlov at oracle.com> <mailto:
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>
> >      >     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com
> >     <mailto:vladimir.kozlov at oracle.com>>>> wrote:
> >      >      >
> >      >      >     Hi, Nicolas
> >      >      >
> >      >      >     Looks like, when inlined, the loop from
> ArrayFloatToArrayFloatVectorBinding::plus() was not optimized
> >     at all:
> >      >     it is not
> >      >      >     unrolled and has range checks. Such loops are not
> vectorized (you need unrolling and no checks).
> >      >      >
> >      >      >     What Java version you are running? What HotSpot VM
> flags you are using when running application?
> >      >      >
> >      >      >     Run application with -XX:+LogCompilation and look on
> compilation data in hotspot_pid<PID>.log file for
> >     caller
> >      >      >     AVector::plus().
> >      >      >
> >      >      >     VM also has several flags to trace loop optimizations
> but they are only available in debug VM build.
> >     If you
> >      >     have access
> >      >      >     to such build run with -XX:+PrintCompilation
> -XX:+TraceLoopOpts flags.
> >      >      >
> >      >      >     Thanks,
> >      >      >     Vladimir K
> >      >      >
> >      >      >     On 2/10/21 9:24 AM, Nicolas Heutte wrote:
> >      >      >      > Hi all,
> >      >      >      >
> >      >      >      > I am encountering a performance issue caused by the
> interaction between
> >      >      >      > method inlining and automatic vectorization.
> >      >      >      >
> >      >      >      > Our application aggregates arrays intensively using
> a method named
> >      >      >      > ArrayFloatToArrayFloatVectorBinding.plus() with the
> following code:
> >      >      >      >
> >      >      >      >      for (int i = 0; i < srcLen; ++i) {
> >      >      >      >
> >      >      >      >              dstArray[i] += srcArray[i];
> >      >      >      >
> >      >      >      >      }
> >      >      >      >
> >      >      >      > When we microbenchmark this method we observe fast
> performance close to the
> >      >      >      > practical memory bandwidth and when we print the
> assembly code we observe
> >      >      >      > loop unrolling and automatic vectorization with
> SIMD instructions.
> >      >      >      >
> >      >      >      >    0x000001ef4600abf0: vmovdqu
> 0x10(%r14,%r13,4),%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600abf7: vaddps
> 0x10(%rcx,%r13,4),%ymm0,%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600abfe: vmovdqu
> %ymm0,0x10(%r14,%r13,4)
> >      >      >      >
> >      >      >      >    0x000001ef4600ac05: movslq %r13d,%r11
> >      >      >      >
> >      >      >      >    0x000001ef4600ac08: vmovdqu
> 0x30(%r14,%r11,4),%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac0f: vaddps
> 0x30(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac16: vmovdqu
> %ymm0,0x30(%r14,%r11,4)
> >      >      >      >
> >      >      >      >    0x000001ef4600ac1d: vmovdqu
> 0x50(%r14,%r11,4),%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac24: vaddps
> 0x50(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac2b: vmovdqu
> %ymm0,0x50(%r14,%r11,4)
> >      >      >      >
> >      >      >      >    0x000001ef4600ac32: vmovdqu
> 0x70(%r14,%r11,4),%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac39: vaddps
> 0x70(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac40: vmovdqu
> %ymm0,0x70(%r14,%r11,4)
> >      >      >      >
> >      >      >      >    0x000001ef4600ac47: vmovdqu
> 0x90(%r14,%r11,4),%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac51: vaddps
> 0x90(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac5b: vmovdqu
> %ymm0,0x90(%r14,%r11,4)
> >      >      >      >
> >      >      >      >    0x000001ef4600ac65: vmovdqu
> 0xb0(%r14,%r11,4),%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac6f: vaddps
> 0xb0(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac79: vmovdqu
> %ymm0,0xb0(%r14,%r11,4)
> >      >      >      >
> >      >      >      >    0x000001ef4600ac83: vmovdqu
> 0xd0(%r14,%r11,4),%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac8d: vaddps
> 0xd0(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600ac97: vmovdqu
> %ymm0,0xd0(%r14,%r11,4)
> >      >      >      >
> >      >      >      >    0x000001ef4600aca1: vmovdqu
> 0xf0(%r14,%r11,4),%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600acab: vaddps
> 0xf0(%rcx,%r11,4),%ymm0,%ymm0
> >      >      >      >
> >      >      >      >    0x000001ef4600acb5: vmovdqu
> %ymm0,0xf0(%r14,%r11,4)  ;*fastore
> >      >      >      > {reexecute=0 rethrow=0 return_oop=0}
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> >      >      >      > (line 41)
> >      >      >      >
> >      >      >      >    0x000001ef4600acbf: add    $0x40,%r13d
> ;*iinc {reexecute=0
> >      >      >      > rethrow=0 return_oop=0}
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> >      >      >      > (line 40)
> >      >      >      >
> >      >      >      >    0x000001ef4600acc3: cmp    %eax,%r13d
> >      >      >      >
> >      >      >      >    0x000001ef4600acc6: jl     0x000001ef4600abf0
> ;*goto {reexecute=0
> >      >      >      > rethrow=0 return_oop=0}
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> >      >      >      > (line 40)
> >      >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >      > In the real application, this method is actually
> inlined in a higher level
> >      >      >      > method named AVector.plus(). Unfortunately, the
> inlined version of the
> >      >      >      > aggregation code is not vectorized anymore:
> >      >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >      >    0x000001ef460180a0: cmp    %ebx,%r11d
> >      >      >      >
> >      >      >      >    0x000001ef460180a3: jae    0x000001ef460180e6
> >      >      >      >
> >      >      >      >    0x000001ef460180a5: vmovss
> 0x10(%r8,%r11,4),%xmm1  ;*faload {reexecute=0
> >      >      >      > rethrow=0 return_oop=0}
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
> >      >      >      > (line 41)
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >      >      >
> >      >      >      >    0x000001ef460180ac: cmp    %ecx,%r11d
> >      >      >      >
> >      >      >      >    0x000001ef460180af: jae    0x000001ef46018104
> >      >      >      >
> >      >      >      >    0x000001ef460180b1: vaddss
> 0x10(%r9,%r11,4),%xmm1,%xmm1
> >      >      >      >
> >      >      >      >    0x000001ef460180b8: vmovss
> %xmm1,0x10(%r8,%r11,4)  ;*fastore {reexecute=0
> >      >      >      > rethrow=0 return_oop=0}
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> >      >      >      > (line 41)
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >      >      >
> >      >      >      >    0x000001ef460180bf: inc    %r11d
> ;*iinc {reexecute=0
> >      >      >      > rethrow=0 return_oop=0}
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> >      >      >      > (line 40)
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >      >      >
> >      >      >      >    0x000001ef460180c2: cmp    %r10d,%r11d
> >      >      >      >
> >      >      >      >    0x000001ef460180c5: jl     0x000001ef460180a0
> ;*goto {reexecute=0
> >      >      >      > rethrow=0 return_oop=0}
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> >      >      >      > (line 40)
> >      >      >      >
> >      >      >      >                                                  ; -
> >      >      >      > com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >      >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >      > This causes a significant performance drop,
> compared to a run where we
> >      >      >      > explicitly disable the inlining and observe
> automatically vectorized code
> >      >      >      > again (
> >      >      >      >
> -XX:CompileCommand=dontinline,com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding.plus
> >      >      >      > ).
> >      >      >      >
> >      >      >      >
> >      >      >      > How do you guys explain that behavior of the JIT
> compiler? Is this a known
> >      >      >      > and tracked issue, could it be fixed in the JVM?
> Can we do something in the
> >      >      >      > java code to prevent this from happening?
> >      >      >      >
> >      >      >      >
> >      >      >      > Best regards,
> >      >      >      >
> >      >      >      > Nicolas Heutte
> >      >      >      >
> >      >      >
> >      >
> >
>

From sviswanathan at openjdk.java.net  Fri Feb 19 18:13:41 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 19 Feb 2021 18:13:41 GMT
Subject: Integrated: 8261542: X86 slice and unslice intrinsics for 256-bit
 byte/short vectors
In-Reply-To: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
References: <I6gtjqr8ncsDL_8Jed9JTmyKvjRPGDHDR8ib893dxUk=.1b868622-520c-4f3a-862b-7efc09fef2cd@github.com>
Message-ID: <y2lI7oKA5F5JHIZb5t3jQvd8ijlGrE53n7jy_ZeESkA=.986286a8-b8c2-4a80-bb8f-e926eaf56b95@github.com>

On Thu, 11 Feb 2021 02:37:35 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> The slice and unslice intrinsics for 256-bit byte/short vectors can be implemented for x86 platforms supporting AVX2 using a sequence of instructions.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8261542
> 
> The PerfSliceOrigin.java jmh test attached to the JBS shows the following performance on AVX2 platform.
> 
> Before:
> Benchmark                                 (size)   Mode  Cnt   Score   Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  18.887 ? 1.128  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   9.374 ? 0.370  ops/ms
> 
> After:
> Benchmark                                 (size)   Mode  Cnt      Score     Error   Units
> PerfSliceOrigin.vectorSliceOrigin           1024  thrpt    5  13861.420 ?  19.071  ops/ms
> PerfSliceOrigin.vectorSliceUnsliceOrigin    1024  thrpt    5   7895.199 ? 142.580  ops/ms

This pull request has now been integrated.

Changeset: c53acc2a
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c53acc2a
Stats:     120 lines in 7 files changed: 100 ins; 5 del; 15 mod

8261542: X86 slice and unslice intrinsics for 256-bit byte/short vectors

Reviewed-by: kvn, neliasso

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

PR: https://git.openjdk.java.net/jdk/pull/2520

From kvn at openjdk.java.net  Fri Feb 19 18:55:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 19 Feb 2021 18:55:39 GMT
Subject: RFR: 8261225: TieredStopAtLevel should have no effect if
 TieredCompilation is disabled
In-Reply-To: <AveljBM2ujASJ9cw91-W7c0KQ9Mpx6oyUKkl60eNF2o=.dbcbdc4a-2acb-406b-8264-a0e77f8ad424@github.com>
References: <AveljBM2ujASJ9cw91-W7c0KQ9Mpx6oyUKkl60eNF2o=.dbcbdc4a-2acb-406b-8264-a0e77f8ad424@github.com>
Message-ID: <9BZwISNLE8FT3qrIO7F65ADtYBaNnN8dKp7PtFbE9w8=.7225d428-3156-4ae1-aa20-5b9f899a9d11@github.com>

On Fri, 19 Feb 2021 15:41:23 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Ignore TieredStopAtLevel flag is TieredCompilation is off for compatibility with the old compilation policy. Also did some polishing of things that came up in the process.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2647

From kvn at openjdk.java.net  Fri Feb 19 19:00:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 19 Feb 2021 19:00:40 GMT
Subject: RFR: 8262011: [JVMCI] allow printing to tty from unattached
 libgraal thread
In-Reply-To: <tTReCuJ52xHBFDb9nQRDySq9FiFCMFOY5QtIFGHWg-8=.d921d4cd-af3c-4b85-a75b-60fed6809408@github.com>
References: <tTReCuJ52xHBFDb9nQRDySq9FiFCMFOY5QtIFGHWg-8=.d921d4cd-af3c-4b85-a75b-60fed6809408@github.com>
Message-ID: <Y19a0TawX77mMnLn4lDsKvbL37f_lvPz_PGSbIY8pqM=.f5e6191b-8c68-4cf9-8ecf-4efcd9c60835@github.com>

On Fri, 19 Feb 2021 10:10:17 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Currently, `HotSpotJVMCIRuntime.writeDebugOutput` does nothing if the current thread is not attached to HotSpot (i.e., `Thread::current_or_null() == NULL`). This means crucial debug info can be lost. For reference, an unattached libgraal thread is a thread started from within libgraal that has not yet attached itself to the VM (e.g., before [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L42)) or has already detached itself (e.g., after [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L46)).
> 
> The reason for the current behavior is that `HotSpotJVMCIRuntime.writeDebugOutput` passes a Java byte array to C++ code and the C++ code calls back into Java to decode the byte array into a native buffer. These call backs require the current thread to be attached to the VM.
> 
> This PR moves the Java-to-native-buffer decoding into Java and thus avoids the requirement for the current thread to be attached to the VM.
> 
> Tested in libgraal by patching Graal as follows:
> diff --git a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> index 36064767c95..352395dd59b 100644
> --- a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> +++ b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> @@ -43,7 +43,14 @@ public class GraalServiceThread extends Thread {
>          try {
>              runnable.run();
>          } finally {
> +            String debug = System.getenv("GraalServiceThread.debug");
>              afterRun();
> +            if ("true".equals(debug)) {
> +                throw new InternalError("THROWN AFTER DETACHING");
> +            }
>          }
>      }
> 
> Running without the changes in this PR:
>> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
> ===== DaCapo 9.12 avrora starting =====
> ===== DaCapo 9.12 avrora PASSED in 4270 msec =====
> 
> Running with the changes in this PR:
>> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
> ===== DaCapo 9.12 avrora starting =====
> Exception in thread "LibGraalHotSpotGraalManagement-init" java.lang.InternalError: THROWN AFTER DETACHING
> 	at org.graalvm.compiler.core.GraalServiceThread.run(GraalServiceThread.java:52)
> 	at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:519)
> 	at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)
> ===== DaCapo 9.12 avrora PASSED in 4688 msec =====

Seems fine.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2640

From iveresov at openjdk.java.net  Fri Feb 19 19:47:41 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 19 Feb 2021 19:47:41 GMT
Subject: Integrated: 8261225: TieredStopAtLevel should have no effect if
 TieredCompilation is disabled
In-Reply-To: <AveljBM2ujASJ9cw91-W7c0KQ9Mpx6oyUKkl60eNF2o=.dbcbdc4a-2acb-406b-8264-a0e77f8ad424@github.com>
References: <AveljBM2ujASJ9cw91-W7c0KQ9Mpx6oyUKkl60eNF2o=.dbcbdc4a-2acb-406b-8264-a0e77f8ad424@github.com>
Message-ID: <iaH9vigB_cxEc_miXa7VQ79hL1vcwtxSSfqy_81cu74=.702f328a-ee71-4e77-9183-f3eed4a2722a@github.com>

On Fri, 19 Feb 2021 15:41:23 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Ignore TieredStopAtLevel flag is TieredCompilation is off for compatibility with the old compilation policy. Also did some polishing of things that came up in the process.

This pull request has now been integrated.

Changeset: 977a21ad
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/977a21ad
Stats:     137 lines in 3 files changed: 101 ins; 20 del; 16 mod

8261225: TieredStopAtLevel should have no effect if TieredCompilation is disabled

Reviewed-by: kvn

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

PR: https://git.openjdk.java.net/jdk/pull/2647

From vladimir.kozlov at oracle.com  Fri Feb 19 20:06:21 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Feb 2021 12:06:21 -0800
Subject: [External] : Re: SuperWord loop optimization lost after method
 inlining
In-Reply-To: <CAOqmmc3+Vw9uXJkx=N8dPX0iyRYmXNvj-iveSN+faoiojL+rwA@mail.gmail.com>
References: <CAOqmmc0ue3bLMBgWLAvUOrHLe2iNtoSiBiq=+Beky-D=MkA+fw@mail.gmail.com>
 <b9184f85-c869-8088-a080-2d860dca5f9f@oracle.com>
 <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
 <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>
 <CAOqmmc2mWWr2mWoitEz71xc1PZ53ZLhyDfRQ+TjxKRcuGcxNkg@mail.gmail.com>
 <08ce2121-bbb4-3ea5-8f05-efeb33df7b74@oracle.com>
 <CAOqmmc1PKCWgC0n+7WkFDz7vAzxfLpZH4ThQnSL=6yQO5Ghrxg@mail.gmail.com>
 <09a53249-00de-91c1-d88b-6c816ce6dd14@oracle.com>
 <CAOqmmc3+Vw9uXJkx=N8dPX0iyRYmXNvj-iveSN+faoiojL+rwA@mail.gmail.com>
Message-ID: <ebebc7a3-2c86-a926-d5c6-cbf73223fb42@oracle.com>

I need an other file C:\Users\NicolasHeutte\AppData\Local\Temp\\hs_c10212_pid15016.log created from second C2 compiler 
thread. It should have data for standalone ArrayFloatToArrayFloatVectorBinding::plus() method compilation. To see what 
is going on I have to compare these data.

Thanks,
Vladimir K

On 2/19/21 8:54 AM, Nicolas Heutte wrote:
> Hello Vladimir,
> 
> I've added the requested log to the shared folder 
> (https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing 
> <https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!IeK3TGC8Qf5eu0KH3LEkt26TEAWCirLIkTuJ2iAAmTkfBK4_Vnnr6gkOuOydizE_lFhl4g$>). 
> I've also tried disabling the strip mining optimization as you suggested, but there was no significant performance change.
> 
> Best regards,
> Nicolas Heutte
> 
> On Wed, Feb 17, 2021 at 9:05 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>     Unfortunately it is still not the file I am looking for.
> 
>     First, remove -XX:+PrintAssembly flag from command line. I have already files with assembler code.
> 
>     Second, I see link to the file I am looking for:
>     <thread_logfile thread='16812' filename='C:\Users\NicolasHeutte\AppData\Local\Temp\\hs_c16812_pid15016.log'/>
> 
>     If you still have it, please send it. If application stopped before normal exit that file is not merged into
>     hotspot_pid<PID>.log file.
> 
>     If you don't have it - do an other run with -XX:CICompilerCount=1 to use only one C2 compiler thread with Tiered
>     off. It
>     will simplify ordering of log.
> 
>     You can also do an other experiment without collecting log. Run app with next flags to disable loop strip minning
>     optimization:? -XX:-UseCountedLoopSafepoints -XX:LoopStripMiningIter=0
> 
>     Thanks,
>     Vladimir K
> 
>     On 2/17/21 2:34 AM, Nicolas Heutte wrote:
>      > Hi Vladimir,
>      >
>      > I have rerun the test with the appropriate options, the obtained logs are in this folder:
>      > https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing
>     <https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!IeK3TGC8Qf5eu0KH3LEkt26TEAWCirLIkTuJ2iAAmTkfBK4_Vnnr6gkOuOydizE_lFhl4g$>
> 
>      >
>     <https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvvSUuoKhQ$
>     <https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvvSUuoKhQ$>>
>      >
>      > Best regards,
>      > Nicolas Heutte
>      >
>      > On Tue, Feb 16, 2021 at 11:35 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
>     <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>> wrote:
>      >
>      >? ? ?Hi Nicolas,
>      >
>      >? ? ?The file you shared has only assembler code. Yes, it shows that when
>     ArrayFloatToArrayFloatVectorBinding::plus() is
>      >? ? ?inlined into AVector::plus() it is not vectorized.
>      >
>      >? ? ?But I asked for an other file (hotspot_pid<PID>.log) which is generated when you run app with
>      >? ? ?-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation flags. It should start with:
>      >
>      >? ? ?<?xml version='1.0' encoding='UTF-8'?>
>      >? ? ?<hotspot_log version='160 1' process='2302014' time_ms='1613514688748'>
>      >? ? ?<vm_version>
>      >? ? ?<name>
>      >? ? ?Java HotSpot(TM) 64-Bit Server VM
>      >? ? ?</name>
>      >? ? ?<release>
>      >? ? ?11.0.9+7-LTS
>      >? ? ?</release>
>      >
>      >? ? ?Thanks,
>      >? ? ?Vladimir K
>      >
>      >? ? ?On 2/15/21 5:19 AM, Nicolas Heutte wrote:
>      >? ? ? > Hi Vladimir,
>      >? ? ? >
>      >? ? ? > I've tried disabling tiered compilation, as you requested. It seems that the inlining was performed slightly
>      >? ? ? > differently, but the issue remains. As you can see in this excerpt, the main loop isn't properly vectorized:
>      >? ? ? >
>      >? ? ? >? ? 0x00000254b0d4bf54: cmp ? ?%r11d,%r8d
>      >? ? ? >? ? 0x00000254b0d4bf57: jae ? ?0x00000254b0d4c19e
>      >? ? ? >? ? 0x00000254b0d4bf5d: vmovss 0x10(%rcx,%r8,4),%xmm9 ?;*faload {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54 (line 41)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
>     (line 103)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>     com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>      >? ? ?(line 118)
>      >? ? ? >
>      >? ? ? >? ? 0x00000254b0d4bf64: cmp ? ?%ebx,%r8d
>      >? ? ? >? ? 0x00000254b0d4bf67: jae ? ?0x00000254b0d4c1ec
>      >? ? ? >? ? 0x00000254b0d4bf6d: vaddss 0x10(%rdi,%r8,4),%xmm9,%xmm9
>      >? ? ? >? ? 0x00000254b0d4bf74: vmovss %xmm9,0x10(%rcx,%r8,4) ?;*fastore {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61 (line 41)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
>     (line 103)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>     com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>      >? ? ?(line 118)
>      >? ? ? >
>      >? ? ? >? ? 0x00000254b0d4bf7b: inc ? ?%r8d ? ? ? ? ? ? ? ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62 (line 40)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
>     (line 103)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>     com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>      >? ? ?(line 118)
>      >? ? ? >
>      >? ? ? >? ? 0x00000254b0d4bf7e: cmp ? ?%r9d,%r8d
>      >? ? ? >? ? 0x00000254b0d4bf81: jl ? ? 0x00000254b0d4bf54 ?;*goto {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65 (line 40)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
>     (line 103)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>      >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>     com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>      >? ? ?(line 118)
>      >? ? ? >
>      >? ? ? >
>      >? ? ? >
>      >? ? ? > Here is the link to the full log, should you want to take a look at it:
>      >? ? ? > https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing
>     <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!IeK3TGC8Qf5eu0KH3LEkt26TEAWCirLIkTuJ2iAAmTkfBK4_Vnnr6gkOuOydizGvKpVqaQ$>
>      >   
>      ?<https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvuMpg6inQ$ <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvuMpg6inQ$>>
>      >
>      >? ? ? >
>      >   
>      ?<https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$ <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$>
>      >   
>      ?<https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$ <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$>>>
>      >? ? ? >
>      >? ? ? > Best regards,
>      >? ? ? > Nicolas Heutte
>      >? ? ? >
>      >? ? ? > On Thu, Feb 11, 2021 at 7:05 PM Vladimir Kozlov <vladimir.kozlov at oracle.com
>     <mailto:vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>
>      >? ? ?<mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com
>     <mailto:vladimir.kozlov at oracle.com>>>> wrote:
>      >? ? ? >
>      >? ? ? >? ? ?Changing wide mailing list to JIT compiler only.
>      >? ? ? >
>      >? ? ? >? ? ?This deoptimization is normal in Tiered Compilation - it switched from profiling code (level='3')
>     generated by C1
>      >? ? ? >? ? ?compiler to new code generated by C2 (level='4') which does loop optimizations.
>      >? ? ? >
>      >? ? ? >? ? ?Thank you for posting inlining information:
>      >? ? ? >
>      >? ? ? >? ? ? ? ? ?@ 17? ?com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69 bytes) inline (hot)
>      >? ? ? >? ? ? ? ? ? ? \-> TypeProfile (14054/14054 counts) =
>     com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
>      >? ? ? >
>      >? ? ? >? ? ?I thought before that may be call site is not hot but it is not the case.
>      >? ? ? >
>      >? ? ? >? ? ?You can do an other experiment to collect log with disabled Tiered Compilation (only C2 is used):
>      >? ? ?-XX:-TieredCompilation
>      >? ? ? >? ? ?Also print assembler code (as you did before) for final compilation to see if loop is still not
>     vectorized.
>      >? ? ? >
>      >? ? ? >? ? ?Is it possible to post log file (on GitHub?) for me to look?
>      >? ? ? >
>      >? ? ? >? ? ?Thanks,
>      >? ? ? >? ? ?Vladimir K
>      >? ? ? >
>      >? ? ? >? ? ?On 2/11/21 6:28 AM, Nicolas Heutte wrote:
>      >? ? ? >? ? ? > Hi?Vladimir,
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > Thank you for your help.
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > I'm currently running Java 11.0.9, and I did not use any VM flag of note.
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > I checked the content of the compilation log, and it seems that
>      >? ? ?ArrayFloatToArrayFloatVectorBinding::plus() was
>      >? ? ? >? ? ? > deoptimized in order to allow AVector::plus() to be compiled:
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > <writer thread='11576'/>
>      >? ? ? >? ? ? > <task_queued compile_id='17280' method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V'
>      >? ? ?bytes='23'
>      >? ? ? >? ? ? > count='916' iicount='916' level='3' stamp='7394.056' comment='tiered' hot_count='896'/>
>      >? ? ? >? ? ? > <writer thread='15784'/>
>      >? ? ? >? ? ? > <deoptimized thread='15784' reason='constraint' pc='0x00000296d0785b94' compile_id='17257'
>     compiler='c1'
>      >? ? ?level='3'>
>      >? ? ? >? ? ? > <jvms bci='65' method='com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding plus
>      >? ? ? >? ? ? > (Lcom/qfs/vector/IVector;Lcom/qfs/vector/IVector;)V' bytes='69' count='909' backedge_count='155602'
>      >? ? ?iicount='910'/>
>      >? ? ? >? ? ? > </deoptimized>
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > The last compilation entry for AVector::plus() is:
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > <writer thread='16380'/>
>      >? ? ? >? ? ? > <nmethod compile_id='17317' compiler='c2' level='4' entry='0x00000296d6af32c0' size='1960'
>      >? ? ? >? ? ?address='0x00000296d6af3110'
>      >? ? ? >? ? ? > relocation_offset='376' insts_offset='432' stub_offset='1040' scopes_data_offset='1152'
>      >? ? ?scopes_pcs_offset='1592'
>      >? ? ? >? ? ? > dependencies_offset='1880' nul_chk_table_offset='1896' oops_offset='1064' metadata_offset='1072'
>      >? ? ? >? ? ? > method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V' bytes='23' count='172425'
>      >? ? ?iicount='172425'
>      >? ? ? >? ? ? > stamp='7394.199'/>
>      >? ? ? >? ? ? > <make_not_entrant thread='16380' compile_id='17280' compiler='c1' level='2' stamp='7394.199'/>
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 1 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4
>     bytes)
>      >? ? ?inline
>      >? ? ? >? ? ?(hot)
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14552/14552 counts) =
>      >? ? ?com/qfs/vector/array/impl/ArrayFloatVector
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 7 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4
>     bytes)
>      >? ? ?inline
>      >? ? ? >? ? ?(hot)
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14150/14150 counts) =
>      >? ? ?com/qfs/vector/array/impl/ArrayFloatVector
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 10 ? com.qfs.vector.binding.impl.VectorBindings::getBinding (9 bytes)
>      >? ? ?inline (hot)
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 5
>      >? ? ? >? ? ?com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::getBinding (22
>      >? ? ? >? ? ? > bytes) ? inline (hot)
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 3
>      >? ? ? >? ? ?com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::hasBinding
>      >? ? ? >? ? ? > (34 bytes) ? inline (hot)
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 17
>      >? ? ?com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
>      >? ? ? >? ? ?bytes)
>      >? ? ? >? ? ? > inline (hot)
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14054/14054 counts) =
>      >? ? ? >? ? ? > com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 12 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)
>      >? ? ?inline (hot)
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 22 ? com.qfs.vector.impl.AVector::checkIndex (37 bytes) ? inline
>     (hot)
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 6 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)
>      >? ? ?inline (hot)
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 27 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying
>     (5 bytes)
>      >? ? ? >? ? ?accessor
>      >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 34 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying
>     (5 bytes)
>      >? ? ? >? ? ?accessor
>      >? ? ? >? ? ? > <writer thread='15896'/>
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > Unfortunately, I do not have access to a debug VM build, so I cannot run the second test you recommend.
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > Best regards,
>      >? ? ? >? ? ? > Nicolas Heutte
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > On Wed, Feb 10, 2021 at 7:36 PM Vladimir Kozlov <vladimir.kozlov at oracle.com
>     <mailto:vladimir.kozlov at oracle.com>
>      >? ? ?<mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> <mailto:vladimir.kozlov at oracle.com
>     <mailto:vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>>
>      >? ? ? >? ? ?<mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
>     <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> <mailto:vladimir.kozlov at oracle.com
>     <mailto:vladimir.kozlov at oracle.com>
>      >? ? ?<mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>>>> wrote:
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ?Hi, Nicolas
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ?Looks like, when inlined, the loop from ArrayFloatToArrayFloatVectorBinding::plus() was not
>     optimized
>      >? ? ?at all:
>      >? ? ? >? ? ?it is not
>      >? ? ? >? ? ? >? ? ?unrolled and has range checks. Such loops are not vectorized (you need unrolling and no checks).
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ?What Java version you are running? What HotSpot VM flags you are using when running application?
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ?Run application with -XX:+LogCompilation and look on compilation data in hotspot_pid<PID>.log
>     file for
>      >? ? ?caller
>      >? ? ? >? ? ? >? ? ?AVector::plus().
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ?VM also has several flags to trace loop optimizations but they are only available in debug VM
>     build.
>      >? ? ?If you
>      >? ? ? >? ? ?have access
>      >? ? ? >? ? ? >? ? ?to such build run with -XX:+PrintCompilation -XX:+TraceLoopOpts flags.
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ?Thanks,
>      >? ? ? >? ? ? >? ? ?Vladimir K
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ?On 2/10/21 9:24 AM, Nicolas Heutte wrote:
>      >? ? ? >? ? ? >? ? ? > Hi all,
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? > I am encountering a performance issue caused by the interaction between
>      >? ? ? >? ? ? >? ? ? > method inlining and automatic vectorization.
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? > Our application aggregates arrays intensively using a method named
>      >? ? ? >? ? ? >? ? ? > ArrayFloatToArrayFloatVectorBinding.plus() with the following code:
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? for (int i = 0; i < srcLen; ++i) {
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? dstArray[i] += srcArray[i];
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? }
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? > When we microbenchmark this method we observe fast performance close to the
>      >? ? ? >? ? ? >? ? ? > practical memory bandwidth and when we print the assembly code we observe
>      >? ? ? >? ? ? >? ? ? > loop unrolling and automatic vectorization with SIMD instructions.
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600abf0: vmovdqu 0x10(%r14,%r13,4),%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600abf7: vaddps 0x10(%rcx,%r13,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600abfe: vmovdqu %ymm0,0x10(%r14,%r13,4)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac05: movslq %r13d,%r11
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac08: vmovdqu 0x30(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac0f: vaddps 0x30(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac16: vmovdqu %ymm0,0x30(%r14,%r11,4)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac1d: vmovdqu 0x50(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac24: vaddps 0x50(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac2b: vmovdqu %ymm0,0x50(%r14,%r11,4)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac32: vmovdqu 0x70(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac39: vaddps 0x70(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac40: vmovdqu %ymm0,0x70(%r14,%r11,4)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac47: vmovdqu 0x90(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac51: vaddps 0x90(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac5b: vmovdqu %ymm0,0x90(%r14,%r11,4)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac65: vmovdqu 0xb0(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac6f: vaddps 0xb0(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac79: vmovdqu %ymm0,0xb0(%r14,%r11,4)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac83: vmovdqu 0xd0(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac8d: vaddps 0xd0(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac97: vmovdqu %ymm0,0xd0(%r14,%r11,4)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600aca1: vmovdqu 0xf0(%r14,%r11,4),%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acab: vaddps 0xf0(%rcx,%r11,4),%ymm0,%ymm0
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acb5: vmovdqu %ymm0,0xf0(%r14,%r11,4)? ;*fastore
>      >? ? ? >? ? ? >? ? ? > {reexecute=0 rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>      >? ? ? >? ? ? >? ? ? > (line 41)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acbf: add? ? $0x40,%r13d? ? ? ? ;*iinc {reexecute=0
>      >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>      >? ? ? >? ? ? >? ? ? > (line 40)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acc3: cmp? ? %eax,%r13d
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acc6: jl? ? ?0x000001ef4600abf0? ;*goto {reexecute=0
>      >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>      >? ? ? >? ? ? >? ? ? > (line 40)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? > In the real application, this method is actually inlined in a higher level
>      >? ? ? >? ? ? >? ? ? > method named AVector.plus(). Unfortunately, the inlined version of the
>      >? ? ? >? ? ? >? ? ? > aggregation code is not vectorized anymore:
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180a0: cmp? ? %ebx,%r11d
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180a3: jae? ? 0x000001ef460180e6
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180a5: vmovss 0x10(%r8,%r11,4),%xmm1? ;*faload {reexecute=0
>      >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
>      >? ? ? >? ? ? >? ? ? > (line 41)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180ac: cmp? ? %ecx,%r11d
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180af: jae? ? 0x000001ef46018104
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180b1: vaddss 0x10(%r9,%r11,4),%xmm1,%xmm1
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180b8: vmovss %xmm1,0x10(%r8,%r11,4)? ;*fastore {reexecute=0
>      >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>      >? ? ? >? ? ? >? ? ? > (line 41)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180bf: inc? ? %r11d? ? ? ? ? ? ? ;*iinc {reexecute=0
>      >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>      >? ? ? >? ? ? >? ? ? > (line 40)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180c2: cmp? ? %r10d,%r11d
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180c5: jl? ? ?0x000001ef460180a0? ;*goto {reexecute=0
>      >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>      >? ? ? >? ? ? >? ? ? > (line 40)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>      >? ? ? >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? > This causes a significant performance drop, compared to a run where we
>      >? ? ? >? ? ? >? ? ? > explicitly disable the inlining and observe automatically vectorized code
>      >? ? ? >? ? ? >? ? ? > again (
>      >? ? ? >? ? ? >? ? ? >
>     -XX:CompileCommand=dontinline,com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding.plus
>      >? ? ? >? ? ? >? ? ? > ).
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? > How do you guys explain that behavior of the JIT compiler? Is this a known
>      >? ? ? >? ? ? >? ? ? > and tracked issue, could it be fixed in the JVM? Can we do something in the
>      >? ? ? >? ? ? >? ? ? > java code to prevent this from happening?
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? > Best regards,
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? > Nicolas Heutte
>      >? ? ? >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >
> 

From vladimir.kozlov at oracle.com  Sat Feb 20 01:38:39 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Feb 2021 17:38:39 -0800
Subject: [External] : Re: SuperWord loop optimization lost after method
 inlining
In-Reply-To: <ebebc7a3-2c86-a926-d5c6-cbf73223fb42@oracle.com>
References: <CAOqmmc0ue3bLMBgWLAvUOrHLe2iNtoSiBiq=+Beky-D=MkA+fw@mail.gmail.com>
 <b9184f85-c869-8088-a080-2d860dca5f9f@oracle.com>
 <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
 <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>
 <CAOqmmc2mWWr2mWoitEz71xc1PZ53ZLhyDfRQ+TjxKRcuGcxNkg@mail.gmail.com>
 <08ce2121-bbb4-3ea5-8f05-efeb33df7b74@oracle.com>
 <CAOqmmc1PKCWgC0n+7WkFDz7vAzxfLpZH4ThQnSL=6yQO5Ghrxg@mail.gmail.com>
 <09a53249-00de-91c1-d88b-6c816ce6dd14@oracle.com>
 <CAOqmmc3+Vw9uXJkx=N8dPX0iyRYmXNvj-iveSN+faoiojL+rwA@mail.gmail.com>
 <ebebc7a3-2c86-a926-d5c6-cbf73223fb42@oracle.com>
Message-ID: <ec2f7fe3-c01e-e185-bd76-247fd0ad872b@oracle.com>

BTW, I filed bug to collect information:

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

This is very weird case which I can't reproduce with small test. It reminds me one case (Loop did not transform into 
Counted loop) which was fixed in JDK 11.0.3:

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

Thanks,
Vladimir K

On 2/19/21 12:06 PM, Vladimir Kozlov wrote:
> I need an other file C:\Users\NicolasHeutte\AppData\Local\Temp\\hs_c10212_pid15016.log created from second C2 compiler 
> thread. It should have data for standalone ArrayFloatToArrayFloatVectorBinding::plus() method compilation. To see what 
> is going on I have to compare these data.
> 
> Thanks,
> Vladimir K
> 
> On 2/19/21 8:54 AM, Nicolas Heutte wrote:
>> Hello Vladimir,
>>
>> I've added the requested log to the shared folder 
>> (https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing 
>> <https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!IeK3TGC8Qf5eu0KH3LEkt26TEAWCirLIkTuJ2iAAmTkfBK4_Vnnr6gkOuOydizE_lFhl4g$>). 
>> I've also tried disabling the strip mining optimization as you suggested, but there was no significant performance 
>> change.
>>
>> Best regards,
>> Nicolas Heutte
>>
>> On Wed, Feb 17, 2021 at 9:05 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>
>> ??? Unfortunately it is still not the file I am looking for.
>>
>> ??? First, remove -XX:+PrintAssembly flag from command line. I have already files with assembler code.
>>
>> ??? Second, I see link to the file I am looking for:
>> ??? <thread_logfile thread='16812' filename='C:\Users\NicolasHeutte\AppData\Local\Temp\\hs_c16812_pid15016.log'/>
>>
>> ??? If you still have it, please send it. If application stopped before normal exit that file is not merged into
>> ??? hotspot_pid<PID>.log file.
>>
>> ??? If you don't have it - do an other run with -XX:CICompilerCount=1 to use only one C2 compiler thread with Tiered
>> ??? off. It
>> ??? will simplify ordering of log.
>>
>> ??? You can also do an other experiment without collecting log. Run app with next flags to disable loop strip minning
>> ??? optimization:? -XX:-UseCountedLoopSafepoints -XX:LoopStripMiningIter=0
>>
>> ??? Thanks,
>> ??? Vladimir K
>>
>> ??? On 2/17/21 2:34 AM, Nicolas Heutte wrote:
>> ???? > Hi Vladimir,
>> ???? >
>> ???? > I have rerun the test with the appropriate options, the obtained logs are in this folder:
>> ???? > https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing
>>     
>> <https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!IeK3TGC8Qf5eu0KH3LEkt26TEAWCirLIkTuJ2iAAmTkfBK4_Vnnr6gkOuOydizE_lFhl4g$> 
>>
>>
>> ???? >
>>     
>> <https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvvSUuoKhQ$ 
>>
>>     
>> <https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvvSUuoKhQ$>> 
>>
>> ???? >
>> ???? > Best regards,
>> ???? > Nicolas Heutte
>> ???? >
>> ???? > On Tue, Feb 16, 2021 at 11:35 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
>> ??? <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>> wrote:
>> ???? >
>> ???? >? ? ?Hi Nicolas,
>> ???? >
>> ???? >? ? ?The file you shared has only assembler code. Yes, it shows that when
>> ??? ArrayFloatToArrayFloatVectorBinding::plus() is
>> ???? >? ? ?inlined into AVector::plus() it is not vectorized.
>> ???? >
>> ???? >? ? ?But I asked for an other file (hotspot_pid<PID>.log) which is generated when you run app with
>> ???? >? ? ?-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation flags. It should start with:
>> ???? >
>> ???? >? ? ?<?xml version='1.0' encoding='UTF-8'?>
>> ???? >? ? ?<hotspot_log version='160 1' process='2302014' time_ms='1613514688748'>
>> ???? >? ? ?<vm_version>
>> ???? >? ? ?<name>
>> ???? >? ? ?Java HotSpot(TM) 64-Bit Server VM
>> ???? >? ? ?</name>
>> ???? >? ? ?<release>
>> ???? >? ? ?11.0.9+7-LTS
>> ???? >? ? ?</release>
>> ???? >
>> ???? >? ? ?Thanks,
>> ???? >? ? ?Vladimir K
>> ???? >
>> ???? >? ? ?On 2/15/21 5:19 AM, Nicolas Heutte wrote:
>> ???? >? ? ? > Hi Vladimir,
>> ???? >? ? ? >
>> ???? >? ? ? > I've tried disabling tiered compilation, as you requested. It seems that the inlining was performed 
>> slightly
>> ???? >? ? ? > differently, but the issue remains. As you can see in this excerpt, the main loop isn't properly 
>> vectorized:
>> ???? >? ? ? >
>> ???? >? ? ? >? ? 0x00000254b0d4bf54: cmp ? ?%r11d,%r8d
>> ???? >? ? ? >? ? 0x00000254b0d4bf57: jae ? ?0x00000254b0d4c19e
>> ???? >? ? ? >? ? 0x00000254b0d4bf5d: vmovss 0x10(%rcx,%r8,4),%xmm9 ?;*faload {reexecute=0 rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54 (line 41)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
>> ??? (line 103)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ??? com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>> ???? >? ? ?(line 118)
>> ???? >? ? ? >
>> ???? >? ? ? >? ? 0x00000254b0d4bf64: cmp ? ?%ebx,%r8d
>> ???? >? ? ? >? ? 0x00000254b0d4bf67: jae ? ?0x00000254b0d4c1ec
>> ???? >? ? ? >? ? 0x00000254b0d4bf6d: vaddss 0x10(%rdi,%r8,4),%xmm9,%xmm9
>> ???? >? ? ? >? ? 0x00000254b0d4bf74: vmovss %xmm9,0x10(%rcx,%r8,4) ?;*fastore {reexecute=0 rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61 (line 41)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
>> ??? (line 103)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ??? com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>> ???? >? ? ?(line 118)
>> ???? >? ? ? >
>> ???? >? ? ? >? ? 0x00000254b0d4bf7b: inc ? ?%r8d ? ? ? ? ? ? ? ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62 (line 40)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
>> ??? (line 103)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ??? com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>> ???? >? ? ?(line 118)
>> ???? >? ? ? >
>> ???? >? ? ? >? ? 0x00000254b0d4bf7e: cmp ? ?%r9d,%r8d
>> ???? >? ? ? >? ? 0x00000254b0d4bf81: jl ? ? 0x00000254b0d4bf54 ?;*goto {reexecute=0 rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65 (line 40)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.vector.impl.AVector::plus at 17 (line 204)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; - com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
>> ??? (line 103)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? > com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70 (line 66)
>> ???? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ??? com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
>> ???? >? ? ?(line 118)
>> ???? >? ? ? >
>> ???? >? ? ? >
>> ???? >? ? ? >
>> ???? >? ? ? > Here is the link to the full log, should you want to take a look at it:
>> ???? >? ? ? > https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing
>>     
>> <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!IeK3TGC8Qf5eu0KH3LEkt26TEAWCirLIkTuJ2iAAmTkfBK4_Vnnr6gkOuOydizGvKpVqaQ$> 
>>
>> ???? >      
>> ?<https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvuMpg6inQ$ 
>> <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvuMpg6inQ$>> 
>>
>> ???? >
>> ???? >? ? ? >
>> ???? >      
>> ?<https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$ 
>> <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$> 
>>
>> ???? >      
>> ?<https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$ 
>> <https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$>>> 
>>
>> ???? >? ? ? >
>> ???? >? ? ? > Best regards,
>> ???? >? ? ? > Nicolas Heutte
>> ???? >? ? ? >
>> ???? >? ? ? > On Thu, Feb 11, 2021 at 7:05 PM Vladimir Kozlov <vladimir.kozlov at oracle.com
>> ??? <mailto:vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>
>> ???? >? ? ?<mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com
>> ??? <mailto:vladimir.kozlov at oracle.com>>>> wrote:
>> ???? >? ? ? >
>> ???? >? ? ? >? ? ?Changing wide mailing list to JIT compiler only.
>> ???? >? ? ? >
>> ???? >? ? ? >? ? ?This deoptimization is normal in Tiered Compilation - it switched from profiling code (level='3')
>> ??? generated by C1
>> ???? >? ? ? >? ? ?compiler to new code generated by C2 (level='4') which does loop optimizations.
>> ???? >? ? ? >
>> ???? >? ? ? >? ? ?Thank you for posting inlining information:
>> ???? >? ? ? >
>> ???? >? ? ? >? ? ? ? ? ?@ 17? ?com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69 bytes) inline 
>> (hot)
>> ???? >? ? ? >? ? ? ? ? ? ? \-> TypeProfile (14054/14054 counts) =
>> ??? com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
>> ???? >? ? ? >
>> ???? >? ? ? >? ? ?I thought before that may be call site is not hot but it is not the case.
>> ???? >? ? ? >
>> ???? >? ? ? >? ? ?You can do an other experiment to collect log with disabled Tiered Compilation (only C2 is used):
>> ???? >? ? ?-XX:-TieredCompilation
>> ???? >? ? ? >? ? ?Also print assembler code (as you did before) for final compilation to see if loop is still not
>> ??? vectorized.
>> ???? >? ? ? >
>> ???? >? ? ? >? ? ?Is it possible to post log file (on GitHub?) for me to look?
>> ???? >? ? ? >
>> ???? >? ? ? >? ? ?Thanks,
>> ???? >? ? ? >? ? ?Vladimir K
>> ???? >? ? ? >
>> ???? >? ? ? >? ? ?On 2/11/21 6:28 AM, Nicolas Heutte wrote:
>> ???? >? ? ? >? ? ? > Hi?Vladimir,
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? > Thank you for your help.
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? > I'm currently running Java 11.0.9, and I did not use any VM flag of note.
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? > I checked the content of the compilation log, and it seems that
>> ???? >? ? ?ArrayFloatToArrayFloatVectorBinding::plus() was
>> ???? >? ? ? >? ? ? > deoptimized in order to allow AVector::plus() to be compiled:
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? > <writer thread='11576'/>
>> ???? >? ? ? >? ? ? > <task_queued compile_id='17280' method='com.qfs.vector.impl.AVector plus 
>> (Lcom/qfs/vector/IVector;)V'
>> ???? >? ? ?bytes='23'
>> ???? >? ? ? >? ? ? > count='916' iicount='916' level='3' stamp='7394.056' comment='tiered' hot_count='896'/>
>> ???? >? ? ? >? ? ? > <writer thread='15784'/>
>> ???? >? ? ? >? ? ? > <deoptimized thread='15784' reason='constraint' pc='0x00000296d0785b94' compile_id='17257'
>> ??? compiler='c1'
>> ???? >? ? ?level='3'>
>> ???? >? ? ? >? ? ? > <jvms bci='65' method='com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding plus
>> ???? >? ? ? >? ? ? > (Lcom/qfs/vector/IVector;Lcom/qfs/vector/IVector;)V' bytes='69' count='909' backedge_count='155602'
>> ???? >? ? ?iicount='910'/>
>> ???? >? ? ? >? ? ? > </deoptimized>
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? > The last compilation entry for AVector::plus() is:
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? > <writer thread='16380'/>
>> ???? >? ? ? >? ? ? > <nmethod compile_id='17317' compiler='c2' level='4' entry='0x00000296d6af32c0' size='1960'
>> ???? >? ? ? >? ? ?address='0x00000296d6af3110'
>> ???? >? ? ? >? ? ? > relocation_offset='376' insts_offset='432' stub_offset='1040' scopes_data_offset='1152'
>> ???? >? ? ?scopes_pcs_offset='1592'
>> ???? >? ? ? >? ? ? > dependencies_offset='1880' nul_chk_table_offset='1896' oops_offset='1064' metadata_offset='1072'
>> ???? >? ? ? >? ? ? > method='com.qfs.vector.impl.AVector plus (Lcom/qfs/vector/IVector;)V' bytes='23' count='172425'
>> ???? >? ? ?iicount='172425'
>> ???? >? ? ? >? ? ? > stamp='7394.199'/>
>> ???? >? ? ? >? ? ? > <make_not_entrant thread='16380' compile_id='17280' compiler='c1' level='2' stamp='7394.199'/>
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 1 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4
>> ??? bytes)
>> ???? >? ? ?inline
>> ???? >? ? ? >? ? ?(hot)
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14552/14552 counts) =
>> ???? >? ? ?com/qfs/vector/array/impl/ArrayFloatVector
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 7 ? com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4
>> ??? bytes)
>> ???? >? ? ?inline
>> ???? >? ? ? >? ? ?(hot)
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14150/14150 counts) =
>> ???? >? ? ?com/qfs/vector/array/impl/ArrayFloatVector
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 10 ? com.qfs.vector.binding.impl.VectorBindings::getBinding (9 
>> bytes)
>> ???? >? ? ?inline (hot)
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 5
>> ???? >? ? ? >? ? ?com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::getBinding (22
>> ???? >? ? ? >? ? ? > bytes) ? inline (hot)
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 3
>> ???? >? ? ? >? ? ?com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::hasBinding
>> ???? >? ? ? >? ? ? > (34 bytes) ? inline (hot)
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 17
>> ???? >? ? ?com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
>> ???? >? ? ? >? ? ?bytes)
>> ???? >? ? ? >? ? ? > inline (hot)
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\-&gt; TypeProfile (14054/14054 counts) =
>> ???? >? ? ? >? ? ? > com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 12 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)
>> ???? >? ? ?inline (hot)
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 22 ? com.qfs.vector.impl.AVector::checkIndex (37 bytes) ? inline
>> ??? (hot)
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 6 ? com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)
>> ???? >? ? ?inline (hot)
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 27 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying
>> ??? (5 bytes)
>> ???? >? ? ? >? ? ?accessor
>> ???? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ 34 ? com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying
>> ??? (5 bytes)
>> ???? >? ? ? >? ? ?accessor
>> ???? >? ? ? >? ? ? > <writer thread='15896'/>
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? > Unfortunately, I do not have access to a debug VM build, so I cannot run the second test you 
>> recommend.
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? > Best regards,
>> ???? >? ? ? >? ? ? > Nicolas Heutte
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? > On Wed, Feb 10, 2021 at 7:36 PM Vladimir Kozlov <vladimir.kozlov at oracle.com
>> ??? <mailto:vladimir.kozlov at oracle.com>
>> ???? >? ? ?<mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> <mailto:vladimir.kozlov at oracle.com
>> ??? <mailto:vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>>
>> ???? >? ? ? >? ? ?<mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
>> ??? <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> <mailto:vladimir.kozlov at oracle.com
>> ??? <mailto:vladimir.kozlov at oracle.com>
>> ???? >? ? ?<mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>>>> wrote:
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ?Hi, Nicolas
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ?Looks like, when inlined, the loop from ArrayFloatToArrayFloatVectorBinding::plus() was not
>> ??? optimized
>> ???? >? ? ?at all:
>> ???? >? ? ? >? ? ?it is not
>> ???? >? ? ? >? ? ? >? ? ?unrolled and has range checks. Such loops are not vectorized (you need unrolling and no checks).
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ?What Java version you are running? What HotSpot VM flags you are using when running application?
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ?Run application with -XX:+LogCompilation and look on compilation data in hotspot_pid<PID>.log
>> ??? file for
>> ???? >? ? ?caller
>> ???? >? ? ? >? ? ? >? ? ?AVector::plus().
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ?VM also has several flags to trace loop optimizations but they are only available in debug VM
>> ??? build.
>> ???? >? ? ?If you
>> ???? >? ? ? >? ? ?have access
>> ???? >? ? ? >? ? ? >? ? ?to such build run with -XX:+PrintCompilation -XX:+TraceLoopOpts flags.
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ?Thanks,
>> ???? >? ? ? >? ? ? >? ? ?Vladimir K
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ?On 2/10/21 9:24 AM, Nicolas Heutte wrote:
>> ???? >? ? ? >? ? ? >? ? ? > Hi all,
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? > I am encountering a performance issue caused by the interaction between
>> ???? >? ? ? >? ? ? >? ? ? > method inlining and automatic vectorization.
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? > Our application aggregates arrays intensively using a method named
>> ???? >? ? ? >? ? ? >? ? ? > ArrayFloatToArrayFloatVectorBinding.plus() with the following code:
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? for (int i = 0; i < srcLen; ++i) {
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? dstArray[i] += srcArray[i];
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? }
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? > When we microbenchmark this method we observe fast performance close to the
>> ???? >? ? ? >? ? ? >? ? ? > practical memory bandwidth and when we print the assembly code we observe
>> ???? >? ? ? >? ? ? >? ? ? > loop unrolling and automatic vectorization with SIMD instructions.
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600abf0: vmovdqu 0x10(%r14,%r13,4),%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600abf7: vaddps 0x10(%rcx,%r13,4),%ymm0,%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600abfe: vmovdqu %ymm0,0x10(%r14,%r13,4)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac05: movslq %r13d,%r11
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac08: vmovdqu 0x30(%r14,%r11,4),%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac0f: vaddps 0x30(%rcx,%r11,4),%ymm0,%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac16: vmovdqu %ymm0,0x30(%r14,%r11,4)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac1d: vmovdqu 0x50(%r14,%r11,4),%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac24: vaddps 0x50(%rcx,%r11,4),%ymm0,%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac2b: vmovdqu %ymm0,0x50(%r14,%r11,4)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac32: vmovdqu 0x70(%r14,%r11,4),%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac39: vaddps 0x70(%rcx,%r11,4),%ymm0,%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac40: vmovdqu %ymm0,0x70(%r14,%r11,4)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac47: vmovdqu 0x90(%r14,%r11,4),%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac51: vaddps 0x90(%rcx,%r11,4),%ymm0,%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac5b: vmovdqu %ymm0,0x90(%r14,%r11,4)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac65: vmovdqu 0xb0(%r14,%r11,4),%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac6f: vaddps 0xb0(%rcx,%r11,4),%ymm0,%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac79: vmovdqu %ymm0,0xb0(%r14,%r11,4)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac83: vmovdqu 0xd0(%r14,%r11,4),%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac8d: vaddps 0xd0(%rcx,%r11,4),%ymm0,%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600ac97: vmovdqu %ymm0,0xd0(%r14,%r11,4)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600aca1: vmovdqu 0xf0(%r14,%r11,4),%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acab: vaddps 0xf0(%rcx,%r11,4),%ymm0,%ymm0
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acb5: vmovdqu %ymm0,0xf0(%r14,%r11,4)? ;*fastore
>> ???? >? ? ? >? ? ? >? ? ? > {reexecute=0 rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>> ???? >? ? ? >? ? ? >? ? ? > (line 41)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acbf: add? ? $0x40,%r13d? ? ? ? ;*iinc {reexecute=0
>> ???? >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>> ???? >? ? ? >? ? ? >? ? ? > (line 40)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acc3: cmp? ? %eax,%r13d
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef4600acc6: jl? ? ?0x000001ef4600abf0? ;*goto {reexecute=0
>> ???? >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>> ???? >? ? ? >? ? ? >? ? ? > (line 40)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? > In the real application, this method is actually inlined in a higher level
>> ???? >? ? ? >? ? ? >? ? ? > method named AVector.plus(). Unfortunately, the inlined version of the
>> ???? >? ? ? >? ? ? >? ? ? > aggregation code is not vectorized anymore:
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180a0: cmp? ? %ebx,%r11d
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180a3: jae? ? 0x000001ef460180e6
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180a5: vmovss 0x10(%r8,%r11,4),%xmm1? ;*faload {reexecute=0
>> ???? >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
>> ???? >? ? ? >? ? ? >? ? ? > (line 41)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180ac: cmp? ? %ecx,%r11d
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180af: jae? ? 0x000001ef46018104
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180b1: vaddss 0x10(%r9,%r11,4),%xmm1,%xmm1
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180b8: vmovss %xmm1,0x10(%r8,%r11,4)? ;*fastore {reexecute=0
>> ???? >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
>> ???? >? ? ? >? ? ? >? ? ? > (line 41)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180bf: inc? ? %r11d? ? ? ? ? ? ? ;*iinc {reexecute=0
>> ???? >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
>> ???? >? ? ? >? ? ? >? ? ? > (line 40)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180c2: cmp? ? %r10d,%r11d
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? 0x000001ef460180c5: jl? ? ?0x000001ef460180a0? ;*goto {reexecute=0
>> ???? >? ? ? >? ? ? >? ? ? > rethrow=0 return_oop=0}
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
>> ???? >? ? ? >? ? ? >? ? ? > (line 40)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ; -
>> ???? >? ? ? >? ? ? >? ? ? > com.qfs.vector.impl.AVector::plus at 17 (line 204)
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? > This causes a significant performance drop, compared to a run where we
>> ???? >? ? ? >? ? ? >? ? ? > explicitly disable the inlining and observe automatically vectorized code
>> ???? >? ? ? >? ? ? >? ? ? > again (
>> ???? >? ? ? >? ? ? >? ? ? >
>> ??? -XX:CompileCommand=dontinline,com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding.plus
>> ???? >? ? ? >? ? ? >? ? ? > ).
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? > How do you guys explain that behavior of the JIT compiler? Is this a known
>> ???? >? ? ? >? ? ? >? ? ? > and tracked issue, could it be fixed in the JVM? Can we do something in the
>> ???? >? ? ? >? ? ? >? ? ? > java code to prevent this from happening?
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? > Best regards,
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >? ? ? > Nicolas Heutte
>> ???? >? ? ? >? ? ? >? ? ? >
>> ???? >? ? ? >? ? ? >
>> ???? >? ? ? >
>> ???? >
>>

From cjashfor at linux.ibm.com  Sat Feb 20 02:31:37 2021
From: cjashfor at linux.ibm.com (Corey Ashford)
Date: Fri, 19 Feb 2021 18:31:37 -0800
Subject: Question about RegMask::is_aligned_sets()
Message-ID: <2269ddde-8084-3d97-a8f9-1996a2937622@linux.ibm.com>

Hello all,

First the question:

I'd like to understand the concept of "aligned sets" in RegMask.  I 
believe I understand the RegMask idea overall, but I don't understand 
the idea of alignment of sets (actually the concept of sets in this 
context is also fuzzy).  I've looked at the code that implements 
is_aligned_sets, and I just can't yet seem to grok what requirement it 
is trying to verify.  I read RegMask.hpp's comments on the method 
protoype, and it didn't help me much, I'm afraid.  If someone could give 
a paragraph or two of explanation, I'd really appreciate it.

Any additional insights into porting the Vector API to other arches 
would also be appreciated.  For example, maybe we've started the port at 
the wrong place.

Thanks for your consideration.


More background:

We have started working on adding support to the PPC64-LE hotspot code 
for the Vector API.  In order to support Vector Masks, it seems we need 
to change our current support for fixed-length, 128-bit vectors to 
something that can be as short as two booleans.  To do that we have 
changed the function min_vector_size in hotspot/cpu/ppc.ad to return 2 
when the type is T_BOOLEAN, otherwise it still returns 16.

My first task was to add support for vector masks, and so I added a new 
instruct to cpu/ppc/ppc.ad to match VectorLoadMask, which then 
necessitated adding some instructs for LoadVector and StoreVector of the 
appropriate lengths.

I have a test case that loads a vector mask for a vector of shorts:

import jdk.incubator.vector.ShortVector;
import jdk.incubator.vector.VectorSpecies;
import jdk.incubator.vector.VectorMask;
import java.util.Random;


class TestVectorMaskShort {
   private static final VectorSpecies<Short> SPECIES = 
ShortVector.SPECIES_128;

   public static VectorMask<Short> test(boolean[] bary) {
       VectorMask<Short> vmask = VectorMask.fromArray(SPECIES, bary, 0);
       return vmask;
   }

   public static void main(String args[]) {
     Random ran = new Random(100);
     int counter = 0;
     boolean[] bary = new boolean[8];
     for (int i = 0; i < 20_000; i++) {
       for (int j = 0; j < bary.length; j++) {
         bary[j] = ran.nextBoolean();
       }
       VectorMask<Short> vmask = test(bary);
       if (vmask.allTrue()) {
         counter++;
       }
     }
     System.out.printf("counter = %d\n", counter);
   }
}


When I run this test case, I get a runtime error:

#  Internal Error 
(/home/cjashfor/git-trees/jdk/src/hotspot/share/opto/chaitin.cpp:951), 
pid=1341588, tid=1341601
#  assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) failed: vector 
should be aligned


- Corey

Corey Ashford
Software Engineer
IBM Systems, LTC OpenJDK team

IBM

From github.com+10482586+therealeliu at openjdk.java.net  Sat Feb 20 06:25:39 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Sat, 20 Feb 2021 06:25:39 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <R4v2kpBge_gW3SD0lNVv8JhWp3oUkx7yQDYd2soenNE=.3c2dd20c-95a3-4bb9-a159-744a1e61e41a@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>
 <eMXlyYEeHkAIqUy8JwPoq1qPoqWrP2z7RDw7e3u_V_s=.00c9dd59-a602-49bc-a397-88534a3e6c61@github.com>
 <R4v2kpBge_gW3SD0lNVv8JhWp3oUkx7yQDYd2soenNE=.3c2dd20c-95a3-4bb9-a159-744a1e61e41a@github.com>
Message-ID: <SQkWWhRSNyu_v9wod3I0-FBq3E8cFOivTXCdsPlr3YQ=.7523e661-97c4-42fb-9b7d-7affc773918d@github.com>

On Thu, 18 Feb 2021 02:00:04 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

>> OK. For what it's worth, I doubt that this will be suitable for backporting to 8u or 11u.
>
>> OK. For what it's worth, I doubt that this will be suitable for backporting to 8u or 11u.
> 
> Thanks for your review, I'd like to backport this.
> 
> BTW, Is there anyone could review those trivial shared code?

@TobiHartmann Could you help to review those shared code?

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From dongbo at openjdk.java.net  Sat Feb 20 06:26:13 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sat, 20 Feb 2021 06:26:13 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v8]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <5Y24E2lvmpeh6Ke9LT-S74vUT2bf1-wE8AfRPyunycs=.8740560a-d8b1-4f25-a0c6-ad0117aa6aff@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has updated the pull request incrementally with two additional commits since the last revision:

 - fix trailing whitespace
 - split ssra/usra tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/1aba5629..ba8dc5ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=06-07

  Stats: 469 lines in 3 files changed: 352 ins; 112 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From dongbo at openjdk.java.net  Sat Feb 20 06:29:40 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sat, 20 Feb 2021 06:29:40 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v7]
In-Reply-To: <1zpEXArPUG-5mAnHqc7E-YBJ_whPIr0KWpSrgqV2mnQ=.d72ed309-938a-4d6a-9bbc-0a8f065c8411@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <pr96wBAOH_0dbHHpJYmcmBKlPUIm8EXjiRjNHxTGN68=.4b42d8a4-3195-4f6b-bb98-d64786d632c7@github.com>
 <1zpEXArPUG-5mAnHqc7E-YBJ_whPIr0KWpSrgqV2mnQ=.d72ed309-938a-4d6a-9bbc-0a8f065c8411@github.com>
Message-ID: <CginlU0dmRHJjwAkh0CNpKXqQAIq_lB0mIEaGShh7y4=.c6ec7a86-1c35-45d2-a7ad-ab4c3edfa620@github.com>

On Fri, 19 Feb 2021 14:42:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 554:
> 
>> 552: 
>> 553:   WRAP(usra) WRAP(ssra)
>> 554: #undef WRAP
> 
> Are ssra and usra tested by anything? I don't seem them accessed in the test case.

Updated. The `ssra/usra` are accessed by tests in `TestVectorShiftImmAndAccumulate.java`.
Manually injected error by changing `addv` to `subv` if shifting right and accumulating with 0, the tests failed as expected.

The `vba.add(vbb.lanewise(SHIFT, Imm))` pattern in `TestVectorShiftImmAndAccumulate.java` are actually the same with the original code in `TestVectorShiftImm.java`.
As of now, I have no idea why `ssra/usra` are not accessed by the previous test code.
The `vba.add(vbb.lanewise(SHIFT, Imm))` pattern should match `ssra/usra` anyway.
I think we need a separate investigation.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From xliu at openjdk.java.net  Sat Feb 20 08:30:00 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 20 Feb 2021 08:30:00 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v5]
In-Reply-To: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
Message-ID: <BITmsT8LrJ9iejBuDEd1M0LLxo_SZIoV4TTAq0qjIHU=.5fe27273-635e-4cba-8786-60614f5ae13a@github.com>

> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
> 
> Before:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
> - string: "a"
> :Constant:exact *
> 
> After:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
  
  move tr_delete in StringUtils.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2178/files
  - new: https://git.openjdk.java.net/jdk/pull/2178/files/cfd51fb3..edbd13bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=03-04

  Stats: 119 lines in 7 files changed: 89 ins; 19 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2178.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2178/head:pull/2178

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Sat Feb 20 08:35:38 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sat, 20 Feb 2021 08:35:38 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v4]
In-Reply-To: <WK0tOkED6xG1ior27fuZNegOCndT-rNDX5pLFtW2lMU=.b6d0d67a-2bed-49bc-82aa-4262cdd383be@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <w-2JkDuXk-wAeMBvrZm8MS2OI3jADcEEELDRmZ16S48=.84db5012-0b2a-49ce-adb4-038cf59ce423@github.com>
 <AgJYY86bXzz7lUOV8DCLBFgMZfm_dqdcs1x8ytcARS8=.6da2a1ad-99c0-4328-9fb5-00978bcf5722@github.com>
 <P-TsBeV-bxp6GFNqNhEW2l4401VEEsC6iM5MuJbmdoc=.5c0b1ac2-479f-49df-8b0a-765853b125a1@github.com>
 <WK0tOkED6xG1ior27fuZNegOCndT-rNDX5pLFtW2lMU=.b6d0d67a-2bed-49bc-82aa-4262cdd383be@github.com>
Message-ID: <pAW0mhXQpba9bi7xL54pHwm8UTRdLJ9cL_QM3KnrgSk=.6801a45d-cb7d-4c4c-9ca2-a1d784019fc7@github.com>

On Wed, 17 Feb 2021 19:23:14 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> Another option:
>> class filterStringStream: public stringStream {
>> private:
>>   char ch;
>> public:
>>   filterStringStream(char ch_to_filter, size_t initial_bufsize = 256) : stringStream(initial_bufsize), ch(ch_to_filter) {}
>> 
>>   virtual void write(const char* c, size_t len) override {
>>     const char* e = c + len;
>>     while (c != e) {
>>       size_t i = 0;
>>       while ((c+i) != e && c[i] != ch ) {
>>         ++i;
>>       }
>>       stringStream::write(c, i);
>>       c += i;
>>       while (c != e && *ch == ch) {
>>         ++c;
>>       }
>>     }     
>>   }
>> };
>> 
>> Your code will be:
>> filterStringStream ss('\n');
>> ss.print(" ");
>> const_oop->print_oop(&ss);
>> st->print_raw(ss.base(), ss,size());
>
>> `tr_delete` is expensive. Also deleting something in a stream does not fit into a concept of streams.
>> I see that the content of `ss` is traversed many times.
>> What about this code:
>> 
>> ```
>> for (const char *str = ss.base(); *str; ) {
>>   size_t i = 0;
>>   while (str[i] && str[i] != '\n' ) {
>>        ++i;
>>   }
>>   st->print_raw(str, i);
>>   str += i;
>>   while (*str == '\n') {
>>     ++str;
>>   }
>> }
>> ```
> 
> You can put this code in a function like `print_filtering_ch(char, const stringStream&, outputStream*)`

hi, @eastig ,
 
Thank you for reviewing this code. 

you are right, I shouldn't modify the contents of a stringStream. I treated it as a buffer instead of stream. 
I took you advice, I moved `tr_delete` logic to StringUtils, which is a toolkit class. 
Could you take a look again?

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Sun Feb 21 02:07:59 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 21 Feb 2021 02:07:59 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v6]
In-Reply-To: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
Message-ID: <y3yIDeFnuhNuQEpoZvYxHSEJhfJ57zsrQ4LGRAG2sN8=.80ebbed3-49d8-45a2-b2e7-e4c5fa474cd6@github.com>

> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
> 
> Before:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
> - string: "a"
> :Constant:exact *
> 
> After:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
  
  fix build failures on Windows. StringUtils::tr_delete returns size_of.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2178/files
  - new: https://git.openjdk.java.net/jdk/pull/2178/files/edbd13bd..077f9b60

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=04-05

  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2178.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2178/head:pull/2178

PR: https://git.openjdk.java.net/jdk/pull/2178

From jiefu at openjdk.java.net  Sun Feb 21 23:24:54 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 21 Feb 2021 23:24:54 GMT
Subject: RFR: 8262096: Vector API fails to work without C2
Message-ID: <avwP-L51q0RsaWVHLOem_B45vRxPOAtdxmr0eanzdy4=.ec2edabc-db79-4e75-8a47-9f6cd8487f79@github.com>

Hi all,

Vector API won't work without C2.
The reason is that VectorSupport_GetMaxLaneCount [1] always returns -1 if C2 is not present.
But it should work even there is no JIT compiler since it's Java-level's api.
So let's fix it.

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

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

Commit messages:
 - 8262096: Vector API fails to work without C2

Changes: https://git.openjdk.java.net/jdk/pull/2667/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2667&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262096
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2667.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2667/head:pull/2667

PR: https://git.openjdk.java.net/jdk/pull/2667

From jiefu at openjdk.java.net  Sun Feb 21 23:29:54 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 21 Feb 2021 23:29:54 GMT
Subject: RFR: 8262097: Improve CompilerConfig ergonomics to fix a VM crash
 after JDK-8261229
Message-ID: <iBD5PZkDX1PMPcqUz164MVvqpz_gq9PSonEm1qfBz9c=.26e4e5a3-9e79-4cda-828b-890f89ed9a4c@github.com>

Hi all,

This bug was found while I was verifying the fix for JDK-8262096.
It was exposed after JDK-8261229.

Testing:
  - tier1~3 on Linux/x64, no regression

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8262097: Improve CompilerConfig ergonomics to fix a VM crash after JDK-8261229

Changes: https://git.openjdk.java.net/jdk/pull/2668/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2668&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262097
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2668.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2668/head:pull/2668

PR: https://git.openjdk.java.net/jdk/pull/2668

From jiefu at openjdk.java.net  Mon Feb 22 03:04:03 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 22 Feb 2021 03:04:03 GMT
Subject: RFR: 8262096: Vector API fails to work without C2 [v2]
In-Reply-To: <avwP-L51q0RsaWVHLOem_B45vRxPOAtdxmr0eanzdy4=.ec2edabc-db79-4e75-8a47-9f6cd8487f79@github.com>
References: <avwP-L51q0RsaWVHLOem_B45vRxPOAtdxmr0eanzdy4=.ec2edabc-db79-4e75-8a47-9f6cd8487f79@github.com>
Message-ID: <AX3G9ShPv6XtR5fPoE6rgFkh9JX1XUZxLPFusNgqcew=.04e80e5a-68b8-451a-968d-237c98142dec@github.com>

> Hi all,
> 
> Vector API won't work without C2.
> The reason is that VectorSupport_GetMaxLaneCount [1] always returns -1 if C2 is not present.
> But it should work even there is no JIT compiler since it's Java-level's api.
> So let's fix it.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Fix zero and minimal build failure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2667/files
  - new: https://git.openjdk.java.net/jdk/pull/2667/files/0e0e03ab..059aa729

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2667&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2667&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2667.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2667/head:pull/2667

PR: https://git.openjdk.java.net/jdk/pull/2667

From xliu at openjdk.java.net  Mon Feb 22 05:13:43 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 22 Feb 2021 05:13:43 GMT
Subject: RFR: 8261731: shallow copy the internal buffer of a
 scalar-replaced java.lang.String object [v2]
In-Reply-To: <5vIeI9zFvxAcG-dUY-8iQwXlXDyWJ3VFMUqKamIL4o4=.746707e1-9d41-4fc0-9162-1ac7ca5589f3@github.com>
References: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
 <3JNae6rXuxc_Q6YoALCH8Ku510Zne5ftqf1z8OCGkHQ=.2ebf5cd0-27e2-44e3-adf7-065179cc9ffd@github.com>
 <5vIeI9zFvxAcG-dUY-8iQwXlXDyWJ3VFMUqKamIL4o4=.746707e1-9d41-4fc0-9162-1ac7ca5589f3@github.com>
Message-ID: <kPNAkzI000EQUP0mWo0iag2BSI8_0lUoLEN87YeiASA=.e4909c86-2d03-4ff4-8c84-11a1dda88c47@github.com>

On Wed, 17 Feb 2021 17:42:48 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
>> 
>>  - Merge branch 'master' into optimize_substring
>>  - fix regression for x86-32
>>    
>>    if LP64 is off, the offset of AddP must be I instead of L.
>>    x86 also doesn't emit encodeP/storeN. it use storeP instead.
>>  - add a statistical counter for OptimizeTempArray.
>>    
>>    -XX:+PrintOptoStatistics shows it
>>  - [SIM-JVM-450] support deoptimization v2
>>    
>>    because the src oop of scobj may be another scobj, deoptimization sort
>>    all objects in topological order.
>>    
>>    separate creation of dst oop and reassignment of it.
>>  - add a unit test for deoptimization
>>  - [SIM-JVM-450] support deoptimization part2
>>    
>>    if OptimizeTempArray eliminates an AllocateArrayNode, scalar replacement will
>>    create a nested SafePointScalarObjectNode for the field value:byte[] of j.l.String.
>>    we use the nested sobj and an ObjectValue an envelope. it consists of 3 fields:
>>    1. src 2. src_positio 3. length.
>>    
>>    deoptimizaton recognizes this ad-hoc ObjectValue and re-allocate an arrayOop
>>    for the String object.
>>  - enable OptimizeTempArray by default
>>  - Merge branch 'master' into optimize_substring
>>  - Revert "8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set"
>>    
>>    This reverts commit a49e34688d7d7c9d3c0d9c824d33f359613c2fc1.
>>  - Revert "add a new bucket afterea_late_inlines"
>>    
>>    afterea_late_inlines bucket is not useful. revert it and its relevant changes
>>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/849f4c0f...21693ddd
>
> src/hotspot/share/opto/macro.cpp line 1317:
> 
>> 1315: //
>> 1316: //
>> 1317: //  EncodeP:  delele because we don't need storeN
> 
> "delete" not "delele"

got it. thanks. I will update it.

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

PR: https://git.openjdk.java.net/jdk/pull/2570

From roland at openjdk.java.net  Mon Feb 22 09:08:43 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 22 Feb 2021 09:08:43 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>
Message-ID: <qjflXFSHcroKMVjsQevrU9Je1jUTcmIJ57BHZXxdj1E=.d8cfede9-ad0e-478d-b3f7-41b26c2cd294@github.com>

On Mon, 1 Feb 2021 11:20:20 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

>> This patch transforms '(x >>> rshift) + (x << lshift)' into
>> 'RotateRight(x, rshift)' during GVN phase when both the shift exponents
>> are constants and their sum equals to the number of bits for the type
>> of shift base.
>> 
>> This patch implements some new match rules for AArch64 instructions
>> which can take ROR as the optional shift. Such instructions are 'and',
>> 'or', 'eor', 'eon', 'bic' and 'orn'.
>> 
>>   ror     w11, w2, #5
>>   eor     w0, w1, w11
>> 
>> With this patch, above code could be optimized to below:
>> 
>>   eor     w0, w1, w2, ror #5
>> 
>> Finally, the patch refactors TestRotate.java[1][2].
>> 
>> Tested jtreg TestRotate.java, hotspot::hotspot_all_no_apps,
>> jdk::jdk_core, langtools::tier1.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8252776
>> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039911.html
>
> Eric Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark test
>   
>   Change-Id: I63ca51d06070a07e5c20daf4b42d2c8d7237a1da

Changes requested by roland (Reviewer).

src/hotspot/share/opto/addnode.cpp line 349:

> 347:     }
> 348:   }
> 349: 

Even though existing code in that method seems to assume node's inputs can't be NULL, it's a good practice to protect against unexpected NULLs as that can happen when sub-graphs die during IGVN. So in(1)->in(1), in(1)->in(2), in(2)->in(2) need to be tested for NULL.

That logic and the one for AddLNode are almost identical. So it would be good to have it in a shared method. I've been adding helper methods to make that possible but not all of that code is in yet. Could you file a bug to revisit this issue later and assign it to me?

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From xliu at openjdk.java.net  Mon Feb 22 10:19:54 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 22 Feb 2021 10:19:54 GMT
Subject: RFR: 8261731: shallow copy the internal buffer of a
 scalar-replaced java.lang.String object
In-Reply-To: <pae6kYj6-K2WlPhPAnYwDW1yX-L18_LdvKohnjAvjl8=.4a39da86-2145-4e13-a729-4239a7178cc2@github.com>
References: <MOly0P0CPrxlspPUrL-nKdKNqNOz6C4zYRF0ueIZqaU=.4d467f80-7ae3-48f5-9cf1-ef651a44a8a6@github.com>
 <J428b0kfPbnDCzKiIX7-qDDXQ147AYWk_sJQmWLJuIo=.eedb676a-06d1-48a8-acd3-57f01f9ebd86@github.com>
 <l79YkCEGsxhNFa0vyR-K2n6-_M_ftqpzP6zYxoSr_-M=.e59bf74d-93af-4ce8-85bf-c2f0e376801d@github.com>
 <xWO8n5S298BWeViO7Bx5NQwEdN7IFnZb_lGTqD7js3k=.f9f2aceb-4716-482e-8fdf-65e52b034f22@github.com>
 <pae6kYj6-K2WlPhPAnYwDW1yX-L18_LdvKohnjAvjl8=.4a39da86-2145-4e13-a729-4239a7178cc2@github.com>
Message-ID: <MFl0rZu14XMuT4v76sHT0eTHXTj8mAdqm_NP0kqxGcA=.eef04d7b-1850-4496-ad17-ed7e23541592@github.com>

On Wed, 17 Feb 2021 17:46:54 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> What about GC? What happens if the original String isn't reachable any more? Do you put a reference to the byte array into the corresponding oop maps to make sure it can't be garbage collected?

hi, Volker, 

I don't know OopMap very much.  IMHO, it should be discovered by GC because I put the byte array oop to `jvm->locals`
I do that for all safepoints nodes. 

          // 1. src oop
          sfpt->add_req(ac->in(ArrayCopyNode::Src));
https://github.com/openjdk/jdk/pull/2570/files#diff-2faebd05d08f9115f8d9ef771644cf05087a6986c2f9013d7163c6aa720169c3R995

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

PR: https://git.openjdk.java.net/jdk/pull/2570

From github.com+10482586+therealeliu at openjdk.java.net  Mon Feb 22 10:33:42 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Mon, 22 Feb 2021 10:33:42 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <qjflXFSHcroKMVjsQevrU9Je1jUTcmIJ57BHZXxdj1E=.d8cfede9-ad0e-478d-b3f7-41b26c2cd294@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>
 <qjflXFSHcroKMVjsQevrU9Je1jUTcmIJ57BHZXxdj1E=.d8cfede9-ad0e-478d-b3f7-41b26c2cd294@github.com>
Message-ID: <36Vj9yOC0pYOLdCa9ggd9Xg0WxY-O2psZMb86qwgqRI=.c158e853-6184-4790-af14-dc9dba2278cb@github.com>

On Mon, 22 Feb 2021 09:05:53 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Eric Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add benchmark test
>>   
>>   Change-Id: I63ca51d06070a07e5c20daf4b42d2c8d7237a1da
>
> src/hotspot/share/opto/addnode.cpp line 349:
> 
>> 347:     }
>> 348:   }
>> 349: 
> 
> Even though existing code in that method seems to assume node's inputs can't be NULL, it's a good practice to protect against unexpected NULLs as that can happen when sub-graphs die during IGVN. So in(1)->in(1), in(1)->in(2), in(2)->in(2) need to be tested for NULL.
> 
> That logic and the one for AddLNode are almost identical. So it would be good to have it in a shared method. I've been adding helper methods to make that possible but not all of that code is in yet. Could you file a bug to revisit this issue later and assign it to me?

Hi Roland,

Thanks for your feedback.

> Even though existing code in that method seems to assume node's inputs can't be NULL, it's a good practice to protect against unexpected NULLs as that can happen when sub-graphs die during IGVN. So in(1)->in(1), in(1)->in(2), in(2)->in(2) need to be tested for NULL.

Agree

> That logic and the one for AddLNode are almost identical. So it would be good to have it in a shared method. I've been adding helper methods to make that possible but not all of that code is in yet.

As this match rule is trivial enough, how about withdrawing these shared code in this PR for integrating backend first if your helper methods coming soon?  

> Could you file a bug to revisit this issue later and assign it to me?

Okay, it's on my queue now:P


-- Eric

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From eirbjo at gmail.com  Mon Feb 22 11:26:13 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 22 Feb 2021 12:26:13 +0100
Subject: ThreadLocal lookup elimination
Message-ID: <CA+pBWhsRSPhfV9MT_iz8Gddzz0jxU+f0U2sajvd5XNXum1kq0g@mail.gmail.com>

Hello,

ThreadLocals are commonly used to transfer state across method boundaries
in situations where passing them as method parameters is impractical.
Examples include crossing APIs you don't own, or instrumenting code you
don't own.

Consider the following pseudo-instrumented code (where the original code
calls a getter inside a loop):

public class Student {

    private int age;

    public int maxAge(Student[] students) {

        // Instrumented code:
        ExpensiveObject expensive = new ExpensiveObject();
        expensive.recordSomething();
        threadLocal.set(expensive);

        // Original code:
        int max = 0;
        for (Student student : students) {
            max = Math.max(max, student.getAge());
        }
        return max;
    }

    public int getAge() {
        // Instrumented code
        ExpensiveObject exp = threadLocal.get();
        exp.recordSomething();

        // Original code:
        return age;
    }

    // Instrumented field:
    private static ThreadLocal<ExpensiveObject> threadLocal = new
ThreadLocal<>();
}

The ThreadLocal is used here to avoid constructing ExpensiveObject
instances in each invocation of getAge.

However, once a compiler worth its salt sees this code, it immediately
wants to inline the getAge method:

// Instrumented code:
ExpensiveObject expensive = new ExpensiveObject();
expensive.recordSomething();
threadLocal.set(expensive);

for (Student student : students) {
    // Instrumented code
    ExpensiveObject exp = threadLocal.get();
    exp.recordSomething();
    // Original code
    max = Math.max(max, student.age);
}

At this point, we see that the last write to threadLocal is 'expensive', so
any following  'threadLocal.get()' should be substitutable for 'expensive'.
So we could do the following instead:

for (Student student : students) {
    // Instrumented code
    expensive.recordSomething();
    // Original code
    max = Math.max(max, student.age);
}

More generally, a compiler could record the first lookup of a ThreadLocal
in a scope and substitute any following lookup with the first read (until
the next write).

I'm pretty sure this would be immensely useful for my current use case
(which instruments methods to count invocations), but perhaps it is also a
useful optimization in a more general sense? Examples that come to mind are
enterprise apps where transaction and security contexts are passed around
using ThreadLocals.

Has this type of optimization been discussed before? Is it even possible to
implement, or did I miss some dragons hiding in the details? What would the
estimated work for an implementation look like? Are we looking at
bachelor's thesis? Master's thesis? PhD?

Would love to hear some thoughts on this idea.

Cheers,
Eirik.

From nhe at activeviam.com  Mon Feb 22 13:12:10 2021
From: nhe at activeviam.com (Nicolas Heutte)
Date: Mon, 22 Feb 2021 14:12:10 +0100
Subject: [External] : Re: SuperWord loop optimization lost after method
 inlining
In-Reply-To: <ec2f7fe3-c01e-e185-bd76-247fd0ad872b@oracle.com>
References: <CAOqmmc0ue3bLMBgWLAvUOrHLe2iNtoSiBiq=+Beky-D=MkA+fw@mail.gmail.com>
 <b9184f85-c869-8088-a080-2d860dca5f9f@oracle.com>
 <CAOqmmc0xkp86rbdcyyDec+GhR1ns5cmqcz=+QkuppnqgeEn63w@mail.gmail.com>
 <87dcb670-622f-6b05-7c06-289f9b4f3634@oracle.com>
 <CAOqmmc2mWWr2mWoitEz71xc1PZ53ZLhyDfRQ+TjxKRcuGcxNkg@mail.gmail.com>
 <08ce2121-bbb4-3ea5-8f05-efeb33df7b74@oracle.com>
 <CAOqmmc1PKCWgC0n+7WkFDz7vAzxfLpZH4ThQnSL=6yQO5Ghrxg@mail.gmail.com>
 <09a53249-00de-91c1-d88b-6c816ce6dd14@oracle.com>
 <CAOqmmc3+Vw9uXJkx=N8dPX0iyRYmXNvj-iveSN+faoiojL+rwA@mail.gmail.com>
 <ebebc7a3-2c86-a926-d5c6-cbf73223fb42@oracle.com>
 <ec2f7fe3-c01e-e185-bd76-247fd0ad872b@oracle.com>
Message-ID: <CAOqmmc1aEkF-gca-fPUaQzv_5shXOvrenjcOK1MCM-McHFm9fw@mail.gmail.com>

Hello Vladimir,
Thanks for filing the bug. It's indeed a very surprising one.
I've also added the missing file you needed to the shared folder.

Best regards,
Nicolas Heutte

On Sat, Feb 20, 2021 at 2:38 AM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> BTW, I filed bug to collect information:
>
> https://bugs.openjdk.java.net/browse/JDK-8262067
>
> This is very weird case which I can't reproduce with small test. It
> reminds me one case (Loop did not transform into
> Counted loop) which was fixed in JDK 11.0.3:
>
> https://bugs.openjdk.java.net/browse/JDK-8211451
>
> Thanks,
> Vladimir K
>
> On 2/19/21 12:06 PM, Vladimir Kozlov wrote:
> > I need an other file
> C:\Users\NicolasHeutte\AppData\Local\Temp\\hs_c10212_pid15016.log created
> from second C2 compiler
> > thread. It should have data for standalone
> ArrayFloatToArrayFloatVectorBinding::plus() method compilation. To see what
> > is going on I have to compare these data.
> >
> > Thanks,
> > Vladimir K
> >
> > On 2/19/21 8:54 AM, Nicolas Heutte wrote:
> >> Hello Vladimir,
> >>
> >> I've added the requested log to the shared folder
> >> (
> https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing
> >> <
> https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!IeK3TGC8Qf5eu0KH3LEkt26TEAWCirLIkTuJ2iAAmTkfBK4_Vnnr6gkOuOydizE_lFhl4g$>).
>
> >> I've also tried disabling the strip mining optimization as you
> suggested, but there was no significant performance
> >> change.
> >>
> >> Best regards,
> >> Nicolas Heutte
> >>
> >> On Wed, Feb 17, 2021 at 9:05 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> >>
> >>     Unfortunately it is still not the file I am looking for.
> >>
> >>     First, remove -XX:+PrintAssembly flag from command line. I have
> already files with assembler code.
> >>
> >>     Second, I see link to the file I am looking for:
> >>     <thread_logfile thread='16812'
> filename='C:\Users\NicolasHeutte\AppData\Local\Temp\\hs_c16812_pid15016.log'/>
> >>
> >>     If you still have it, please send it. If application stopped before
> normal exit that file is not merged into
> >>     hotspot_pid<PID>.log file.
> >>
> >>     If you don't have it - do an other run with -XX:CICompilerCount=1
> to use only one C2 compiler thread with Tiered
> >>     off. It
> >>     will simplify ordering of log.
> >>
> >>     You can also do an other experiment without collecting log. Run app
> with next flags to disable loop strip minning
> >>     optimization:  -XX:-UseCountedLoopSafepoints
> -XX:LoopStripMiningIter=0
> >>
> >>     Thanks,
> >>     Vladimir K
> >>
> >>     On 2/17/21 2:34 AM, Nicolas Heutte wrote:
> >>      > Hi Vladimir,
> >>      >
> >>      > I have rerun the test with the appropriate options, the obtained
> logs are in this folder:
> >>      >
> https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing
> >>
> >> <
> https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!IeK3TGC8Qf5eu0KH3LEkt26TEAWCirLIkTuJ2iAAmTkfBK4_Vnnr6gkOuOydizE_lFhl4g$>
>
> >>
> >>
> >>      >
> >>
> >> <
> https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvvSUuoKhQ$
> >>
> >>
> >> <
> https://urldefense.com/v3/__https://drive.google.com/drive/folders/1UczOggtTYp6TZ0QnBiwMxwdTBl3zuvqF?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvvSUuoKhQ$>>
>
> >>
> >>      >
> >>      > Best regards,
> >>      > Nicolas Heutte
> >>      >
> >>      > On Tue, Feb 16, 2021 at 11:35 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
> >>     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com>>> wrote:
> >>      >
> >>      >     Hi Nicolas,
> >>      >
> >>      >     The file you shared has only assembler code. Yes, it shows
> that when
> >>     ArrayFloatToArrayFloatVectorBinding::plus() is
> >>      >     inlined into AVector::plus() it is not vectorized.
> >>      >
> >>      >     But I asked for an other file (hotspot_pid<PID>.log) which
> is generated when you run app with
> >>      >     -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation flags. It
> should start with:
> >>      >
> >>      >     <?xml version='1.0' encoding='UTF-8'?>
> >>      >     <hotspot_log version='160 1' process='2302014'
> time_ms='1613514688748'>
> >>      >     <vm_version>
> >>      >     <name>
> >>      >     Java HotSpot(TM) 64-Bit Server VM
> >>      >     </name>
> >>      >     <release>
> >>      >     11.0.9+7-LTS
> >>      >     </release>
> >>      >
> >>      >     Thanks,
> >>      >     Vladimir K
> >>      >
> >>      >     On 2/15/21 5:19 AM, Nicolas Heutte wrote:
> >>      >      > Hi Vladimir,
> >>      >      >
> >>      >      > I've tried disabling tiered compilation, as you
> requested. It seems that the inlining was performed
> >> slightly
> >>      >      > differently, but the issue remains. As you can see in
> this excerpt, the main loop isn't properly
> >> vectorized:
> >>      >      >
> >>      >      >    0x00000254b0d4bf54: cmp    %r11d,%r8d
> >>      >      >    0x00000254b0d4bf57: jae    0x00000254b0d4c19e
> >>      >      >    0x00000254b0d4bf5d: vmovss 0x10(%rcx,%r8,4),%xmm9
>  ;*faload {reexecute=0 rethrow=0 return_oop=0}
> >>      >      >                                                  ; -
> >>      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
> (line 41)
> >>      >      >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >>      >      >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
> >>     (line 103)
> >>      >      >                                                  ; -
> >>      >      >
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >>      >      >                                                  ; -
> >>     com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
> >>      >     (line 118)
> >>      >      >
> >>      >      >    0x00000254b0d4bf64: cmp    %ebx,%r8d
> >>      >      >    0x00000254b0d4bf67: jae    0x00000254b0d4c1ec
> >>      >      >    0x00000254b0d4bf6d: vaddss 0x10(%rdi,%r8,4),%xmm9,%xmm9
> >>      >      >    0x00000254b0d4bf74: vmovss %xmm9,0x10(%rcx,%r8,4)
>  ;*fastore {reexecute=0 rethrow=0 return_oop=0}
> >>      >      >                                                  ; -
> >>      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> (line 41)
> >>      >      >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >>      >      >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
> >>     (line 103)
> >>      >      >                                                  ; -
> >>      >      >
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >>      >      >                                                  ; -
> >>     com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
> >>      >     (line 118)
> >>      >      >
> >>      >      >    0x00000254b0d4bf7b: inc    %r8d               ;*iinc
> {reexecute=0 rethrow=0 return_oop=0}
> >>      >      >                                                  ; -
> >>      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> (line 40)
> >>      >      >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >>      >      >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
> >>     (line 103)
> >>      >      >                                                  ; -
> >>      >      >
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >>      >      >                                                  ; -
> >>     com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
> >>      >     (line 118)
> >>      >      >
> >>      >      >    0x00000254b0d4bf7e: cmp    %r9d,%r8d
> >>      >      >    0x00000254b0d4bf81: jl     0x00000254b0d4bf54  ;*goto
> {reexecute=0 rethrow=0 return_oop=0}
> >>      >      >                                                  ; -
> >>      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> (line 40)
> >>      >      >                                                  ; -
> com.qfs.vector.impl.AVector::plus at 17 (line 204)
> >>      >      >                                                  ; -
> com.qfs.agg.impl.SumVectorAggregationBinding::plus at 2
> >>     (line 103)
> >>      >      >                                                  ; -
> >>      >      >
> com.qfs.agg.impl.SumVectorAggregationBinding::safeVectorAggregate at 70
> (line 66)
> >>      >      >                                                  ; -
> >>     com.qfs.agg.impl.AVectorAggregationBinding::safeAggregate at 27
> >>      >     (line 118)
> >>      >      >
> >>      >      >
> >>      >      >
> >>      >      > Here is the link to the full log, should you want to take
> a look at it:
> >>      >      >
> https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing
> >>
> >> <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!IeK3TGC8Qf5eu0KH3LEkt26TEAWCirLIkTuJ2iAAmTkfBK4_Vnnr6gkOuOydizGvKpVqaQ$>
>
> >>
> >>      >
> >>  <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvuMpg6inQ$
> >> <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBl1ZdyC5xtmVS0QG3dxZxEen0D1LP-mBM0KnvmRVbQXpL_VPOQ9OD-pVGBqNvuMpg6inQ$>>
>
> >>
> >>      >
> >>      >      >
> >>      >
> >>  <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$
> >> <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$>
>
> >>
> >>      >
> >>  <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$
> >> <
> https://urldefense.com/v3/__https://drive.google.com/file/d/1KQU7wI8NjeElFv6RrQmUsUPRMnAefzhb/view?usp=sharing__;!!GqivPVa7Brio!PBuP6MfDNWUOTe23SSXA0V5wn_VHjv2sjI8POWRwp6mr0wVdIzFhNoVZANb4FqCYKwzapw$>>>
>
> >>
> >>      >      >
> >>      >      > Best regards,
> >>      >      > Nicolas Heutte
> >>      >      >
> >>      >      > On Thu, Feb 11, 2021 at 7:05 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com
> >>     <mailto:vladimir.kozlov at oracle.com> <mailto:
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>
> >>      >     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com
> >>     <mailto:vladimir.kozlov at oracle.com>>>> wrote:
> >>      >      >
> >>      >      >     Changing wide mailing list to JIT compiler only.
> >>      >      >
> >>      >      >     This deoptimization is normal in Tiered Compilation -
> it switched from profiling code (level='3')
> >>     generated by C1
> >>      >      >     compiler to new code generated by C2 (level='4')
> which does loop optimizations.
> >>      >      >
> >>      >      >     Thank you for posting inlining information:
> >>      >      >
> >>      >      >           @ 17
>  com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
> bytes) inline
> >> (hot)
> >>      >      >              \-> TypeProfile (14054/14054 counts) =
> >>     com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
> >>      >      >
> >>      >      >     I thought before that may be call site is not hot but
> it is not the case.
> >>      >      >
> >>      >      >     You can do an other experiment to collect log with
> disabled Tiered Compilation (only C2 is used):
> >>      >     -XX:-TieredCompilation
> >>      >      >     Also print assembler code (as you did before) for
> final compilation to see if loop is still not
> >>     vectorized.
> >>      >      >
> >>      >      >     Is it possible to post log file (on GitHub?) for me
> to look?
> >>      >      >
> >>      >      >     Thanks,
> >>      >      >     Vladimir K
> >>      >      >
> >>      >      >     On 2/11/21 6:28 AM, Nicolas Heutte wrote:
> >>      >      >      > Hi Vladimir,
> >>      >      >      >
> >>      >      >      > Thank you for your help.
> >>      >      >      >
> >>      >      >      > I'm currently running Java 11.0.9, and I did not
> use any VM flag of note.
> >>      >      >      >
> >>      >      >      > I checked the content of the compilation log, and
> it seems that
> >>      >     ArrayFloatToArrayFloatVectorBinding::plus() was
> >>      >      >      > deoptimized in order to allow AVector::plus() to
> be compiled:
> >>      >      >      >
> >>      >      >      > <writer thread='11576'/>
> >>      >      >      > <task_queued compile_id='17280'
> method='com.qfs.vector.impl.AVector plus
> >> (Lcom/qfs/vector/IVector;)V'
> >>      >     bytes='23'
> >>      >      >      > count='916' iicount='916' level='3'
> stamp='7394.056' comment='tiered' hot_count='896'/>
> >>      >      >      > <writer thread='15784'/>
> >>      >      >      > <deoptimized thread='15784' reason='constraint'
> pc='0x00000296d0785b94' compile_id='17257'
> >>     compiler='c1'
> >>      >     level='3'>
> >>      >      >      > <jvms bci='65'
> method='com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding plus
> >>      >      >      >
> (Lcom/qfs/vector/IVector;Lcom/qfs/vector/IVector;)V' bytes='69' count='909'
> backedge_count='155602'
> >>      >     iicount='910'/>
> >>      >      >      > </deoptimized>
> >>      >      >      >
> >>      >      >      > The last compilation entry for AVector::plus() is:
> >>      >      >      >
> >>      >      >      > <writer thread='16380'/>
> >>      >      >      > <nmethod compile_id='17317' compiler='c2'
> level='4' entry='0x00000296d6af32c0' size='1960'
> >>      >      >     address='0x00000296d6af3110'
> >>      >      >      > relocation_offset='376' insts_offset='432'
> stub_offset='1040' scopes_data_offset='1152'
> >>      >     scopes_pcs_offset='1592'
> >>      >      >      > dependencies_offset='1880'
> nul_chk_table_offset='1896' oops_offset='1064' metadata_offset='1072'
> >>      >      >      > method='com.qfs.vector.impl.AVector plus
> (Lcom/qfs/vector/IVector;)V' bytes='23' count='172425'
> >>      >     iicount='172425'
> >>      >      >      > stamp='7394.199'/>
> >>      >      >      > <make_not_entrant thread='16380'
> compile_id='17280' compiler='c1' level='2' stamp='7394.199'/>
> >>      >      >      >                                @ 1
> com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4
> >>     bytes)
> >>      >     inline
> >>      >      >     (hot)
> >>      >      >      >                                 \-&gt; TypeProfile
> (14552/14552 counts) =
> >>      >     com/qfs/vector/array/impl/ArrayFloatVector
> >>      >      >      >                                @ 7
> com.qfs.vector.array.impl.ArrayFloatVector::getBindingId (4
> >>     bytes)
> >>      >     inline
> >>      >      >     (hot)
> >>      >      >      >                                 \-&gt; TypeProfile
> (14150/14150 counts) =
> >>      >     com/qfs/vector/array/impl/ArrayFloatVector
> >>      >      >      >                                @ 10
> com.qfs.vector.binding.impl.VectorBindings::getBinding (9
> >> bytes)
> >>      >     inline (hot)
> >>      >      >      >                                  @ 5
> >>      >      >
>  com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::getBinding
> (22
> >>      >      >      > bytes)   inline (hot)
> >>      >      >      >                                    @ 3
> >>      >      >
>  com.qfs.vector.binding.impl.VectorBindings$VectorBindingsProvider::hasBinding
> >>      >      >      > (34 bytes)   inline (hot)
> >>      >      >      >                                @ 17
> >>      >
>  com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus (69
> >>      >      >     bytes)
> >>      >      >      > inline (hot)
> >>      >      >      >                                 \-&gt; TypeProfile
> (14054/14054 counts) =
> >>      >      >      >
> com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding
> >>      >      >      >                                  @ 12
> com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)
> >>      >     inline (hot)
> >>      >      >      >                                  @ 22
> com.qfs.vector.impl.AVector::checkIndex (37 bytes)   inline
> >>     (hot)
> >>      >      >      >                                    @ 6
> com.qfs.vector.array.impl.ArrayFloatVector::size (6 bytes)
> >>      >     inline (hot)
> >>      >      >      >                                  @ 27
> com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying
> >>     (5 bytes)
> >>      >      >     accessor
> >>      >      >      >                                  @ 34
> com.qfs.vector.array.impl.ArrayFloatVector::getUnderlying
> >>     (5 bytes)
> >>      >      >     accessor
> >>      >      >      > <writer thread='15896'/>
> >>      >      >      >
> >>      >      >      > Unfortunately, I do not have access to a debug VM
> build, so I cannot run the second test you
> >> recommend.
> >>      >      >      >
> >>      >      >      > Best regards,
> >>      >      >      > Nicolas Heutte
> >>      >      >      >
> >>      >      >      > On Wed, Feb 10, 2021 at 7:36 PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com
> >>     <mailto:vladimir.kozlov at oracle.com>
> >>      >     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com>> <mailto:vladimir.kozlov at oracle.com
> >>     <mailto:vladimir.kozlov at oracle.com> <mailto:
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>>
> >>      >      >     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com>
> >>     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com>> <mailto:vladimir.kozlov at oracle.com
> >>     <mailto:vladimir.kozlov at oracle.com>
> >>      >     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com>>>>> wrote:
> >>      >      >      >
> >>      >      >      >     Hi, Nicolas
> >>      >      >      >
> >>      >      >      >     Looks like, when inlined, the loop from
> ArrayFloatToArrayFloatVectorBinding::plus() was not
> >>     optimized
> >>      >     at all:
> >>      >      >     it is not
> >>      >      >      >     unrolled and has range checks. Such loops are
> not vectorized (you need unrolling and no checks).
> >>      >      >      >
> >>      >      >      >     What Java version you are running? What
> HotSpot VM flags you are using when running application?
> >>      >      >      >
> >>      >      >      >     Run application with -XX:+LogCompilation and
> look on compilation data in hotspot_pid<PID>.log
> >>     file for
> >>      >     caller
> >>      >      >      >     AVector::plus().
> >>      >      >      >
> >>      >      >      >     VM also has several flags to trace loop
> optimizations but they are only available in debug VM
> >>     build.
> >>      >     If you
> >>      >      >     have access
> >>      >      >      >     to such build run with -XX:+PrintCompilation
> -XX:+TraceLoopOpts flags.
> >>      >      >      >
> >>      >      >      >     Thanks,
> >>      >      >      >     Vladimir K
> >>      >      >      >
> >>      >      >      >     On 2/10/21 9:24 AM, Nicolas Heutte wrote:
> >>      >      >      >      > Hi all,
> >>      >      >      >      >
> >>      >      >      >      > I am encountering a performance issue
> caused by the interaction between
> >>      >      >      >      > method inlining and automatic vectorization.
> >>      >      >      >      >
> >>      >      >      >      > Our application aggregates arrays
> intensively using a method named
> >>      >      >      >      > ArrayFloatToArrayFloatVectorBinding.plus()
> with the following code:
> >>      >      >      >      >
> >>      >      >      >      >      for (int i = 0; i < srcLen; ++i) {
> >>      >      >      >      >
> >>      >      >      >      >              dstArray[i] += srcArray[i];
> >>      >      >      >      >
> >>      >      >      >      >      }
> >>      >      >      >      >
> >>      >      >      >      > When we microbenchmark this method we
> observe fast performance close to the
> >>      >      >      >      > practical memory bandwidth and when we
> print the assembly code we observe
> >>      >      >      >      > loop unrolling and automatic vectorization
> with SIMD instructions.
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600abf0: vmovdqu
> 0x10(%r14,%r13,4),%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600abf7: vaddps
> 0x10(%rcx,%r13,4),%ymm0,%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600abfe: vmovdqu
> %ymm0,0x10(%r14,%r13,4)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac05: movslq %r13d,%r11
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac08: vmovdqu
> 0x30(%r14,%r11,4),%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac0f: vaddps
> 0x30(%rcx,%r11,4),%ymm0,%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac16: vmovdqu
> %ymm0,0x30(%r14,%r11,4)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac1d: vmovdqu
> 0x50(%r14,%r11,4),%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac24: vaddps
> 0x50(%rcx,%r11,4),%ymm0,%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac2b: vmovdqu
> %ymm0,0x50(%r14,%r11,4)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac32: vmovdqu
> 0x70(%r14,%r11,4),%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac39: vaddps
> 0x70(%rcx,%r11,4),%ymm0,%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac40: vmovdqu
> %ymm0,0x70(%r14,%r11,4)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac47: vmovdqu
> 0x90(%r14,%r11,4),%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac51: vaddps
> 0x90(%rcx,%r11,4),%ymm0,%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac5b: vmovdqu
> %ymm0,0x90(%r14,%r11,4)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac65: vmovdqu
> 0xb0(%r14,%r11,4),%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac6f: vaddps
> 0xb0(%rcx,%r11,4),%ymm0,%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac79: vmovdqu
> %ymm0,0xb0(%r14,%r11,4)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac83: vmovdqu
> 0xd0(%r14,%r11,4),%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac8d: vaddps
> 0xd0(%rcx,%r11,4),%ymm0,%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600ac97: vmovdqu
> %ymm0,0xd0(%r14,%r11,4)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600aca1: vmovdqu
> 0xf0(%r14,%r11,4),%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600acab: vaddps
> 0xf0(%rcx,%r11,4),%ymm0,%ymm0
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600acb5: vmovdqu
> %ymm0,0xf0(%r14,%r11,4)  ;*fastore
> >>      >      >      >      > {reexecute=0 rethrow=0 return_oop=0}
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> >>      >      >      >      > (line 41)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600acbf: add    $0x40,%r13d
>       ;*iinc {reexecute=0
> >>      >      >      >      > rethrow=0 return_oop=0}
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> >>      >      >      >      > (line 40)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600acc3: cmp    %eax,%r13d
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef4600acc6: jl
>  0x000001ef4600abf0  ;*goto {reexecute=0
> >>      >      >      >      > rethrow=0 return_oop=0}
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> >>      >      >      >      > (line 40)
> >>      >      >      >      >
> >>      >      >      >      >
> >>      >      >      >      >
> >>      >      >      >      > In the real application, this method is
> actually inlined in a higher level
> >>      >      >      >      > method named AVector.plus(). Unfortunately,
> the inlined version of the
> >>      >      >      >      > aggregation code is not vectorized anymore:
> >>      >      >      >      >
> >>      >      >      >      >
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180a0: cmp    %ebx,%r11d
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180a3: jae
> 0x000001ef460180e6
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180a5: vmovss
> 0x10(%r8,%r11,4),%xmm1  ;*faload {reexecute=0
> >>      >      >      >      > rethrow=0 return_oop=0}
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 54
> >>      >      >      >      > (line 41)
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      > com.qfs.vector.impl.AVector::plus at 17 (line
> 204)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180ac: cmp    %ecx,%r11d
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180af: jae
> 0x000001ef46018104
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180b1: vaddss
> 0x10(%r9,%r11,4),%xmm1,%xmm1
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180b8: vmovss
> %xmm1,0x10(%r8,%r11,4)  ;*fastore {reexecute=0
> >>      >      >      >      > rethrow=0 return_oop=0}
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 61
> >>      >      >      >      > (line 41)
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      > com.qfs.vector.impl.AVector::plus at 17 (line
> 204)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180bf: inc    %r11d
>       ;*iinc {reexecute=0
> >>      >      >      >      > rethrow=0 return_oop=0}
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 62
> >>      >      >      >      > (line 40)
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      > com.qfs.vector.impl.AVector::plus at 17 (line
> 204)
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180c2: cmp    %r10d,%r11d
> >>      >      >      >      >
> >>      >      >      >      >    0x000001ef460180c5: jl
>  0x000001ef460180a0  ;*goto {reexecute=0
> >>      >      >      >      > rethrow=0 return_oop=0}
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      >
> com.qfs.vector.binding.impl.ArrayFloatToArrayFloatVectorBinding::plus at 65
> >>      >      >      >      > (line 40)
> >>      >      >      >      >
> >>      >      >      >      >
>       ; -
> >>      >      >      >      > com.qfs.vector.impl.AVector::plus at 17 (line
> 204)
> >>      >      >      >      >
> >>      >      >      >      >
> >>      >      >      >      >
> >>      >      >      >      > This causes a significant performance drop,
> compared to a run where we
> >>      >      >      >      > explicitly disable the inlining and observe
> automatically vectorized code
> >>      >      >      >      > again (
> >>      >      >      >      >
> >>
> -XX:CompileCommand=dontinline,com/qfs/vector/binding/impl/ArrayFloatToArrayFloatVectorBinding.plus
> >>      >      >      >      > ).
> >>      >      >      >      >
> >>      >      >      >      >
> >>      >      >      >      > How do you guys explain that behavior of
> the JIT compiler? Is this a known
> >>      >      >      >      > and tracked issue, could it be fixed in the
> JVM? Can we do something in the
> >>      >      >      >      > java code to prevent this from happening?
> >>      >      >      >      >
> >>      >      >      >      >
> >>      >      >      >      > Best regards,
> >>      >      >      >      >
> >>      >      >      >      > Nicolas Heutte
> >>      >      >      >      >
> >>      >      >      >
> >>      >      >
> >>      >
> >>
>

From iveresov at openjdk.java.net  Mon Feb 22 18:03:39 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Mon, 22 Feb 2021 18:03:39 GMT
Subject: RFR: 8262097: Improve CompilerConfig ergonomics to fix a VM crash
 after JDK-8261229
In-Reply-To: <iBD5PZkDX1PMPcqUz164MVvqpz_gq9PSonEm1qfBz9c=.26e4e5a3-9e79-4cda-828b-890f89ed9a4c@github.com>
References: <iBD5PZkDX1PMPcqUz164MVvqpz_gq9PSonEm1qfBz9c=.26e4e5a3-9e79-4cda-828b-890f89ed9a4c@github.com>
Message-ID: <VU_9VRxKxefJtS3y_Uma9_vRGR2SoBNubU_sBt9WDdk=.212e3b10-d767-4859-8fa2-1809b20c7a89@github.com>

On Sun, 21 Feb 2021 23:25:26 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> This bug was found while I was verifying the fix for JDK-8262096.
> It was exposed after JDK-8261229.
> 
> Testing:
>   - tier1~3 on Linux/x64, no regression
> 
> Thanks.
> Best regards,
> Jie

I've indirectly fixed this assert that you noticed in JDK-8261225. But I agree, we should apply the client ergonomic settings as well. Looks good.

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

Marked as reviewed by iveresov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2668

From kvn at openjdk.java.net  Mon Feb 22 19:53:45 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 22 Feb 2021 19:53:45 GMT
Subject: RFR: 8262097: Improve CompilerConfig ergonomics to fix a VM crash
 after JDK-8261229
In-Reply-To: <iBD5PZkDX1PMPcqUz164MVvqpz_gq9PSonEm1qfBz9c=.26e4e5a3-9e79-4cda-828b-890f89ed9a4c@github.com>
References: <iBD5PZkDX1PMPcqUz164MVvqpz_gq9PSonEm1qfBz9c=.26e4e5a3-9e79-4cda-828b-890f89ed9a4c@github.com>
Message-ID: <JS7YRFvbddRUXIyNsif4Ej0fQu4BisNft42Dfx4xYFE=.0fb4501d-5e76-42c0-843b-73e6c1ae832c@github.com>

On Sun, 21 Feb 2021 23:25:26 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> This bug was found while I was verifying the fix for JDK-8262096.
> It was exposed after JDK-8261229.
> 
> Testing:
>   - tier1~3 on Linux/x64, no regression
> 
> Thanks.
> Best regards,
> Jie

Marked as reviewed by kvn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2668

From jiefu at openjdk.java.net  Mon Feb 22 23:46:38 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 22 Feb 2021 23:46:38 GMT
Subject: RFR: 8262097: Improve CompilerConfig ergonomics to fix a VM crash
 after JDK-8261229
In-Reply-To: <VU_9VRxKxefJtS3y_Uma9_vRGR2SoBNubU_sBt9WDdk=.212e3b10-d767-4859-8fa2-1809b20c7a89@github.com>
References: <iBD5PZkDX1PMPcqUz164MVvqpz_gq9PSonEm1qfBz9c=.26e4e5a3-9e79-4cda-828b-890f89ed9a4c@github.com>
 <VU_9VRxKxefJtS3y_Uma9_vRGR2SoBNubU_sBt9WDdk=.212e3b10-d767-4859-8fa2-1809b20c7a89@github.com>
Message-ID: <7zjJuLQzx9cH0bZJ-mqSx8t46AEsped-fjWroLfSB74=.ef0ad3c9-d1de-4fa2-b13d-f3bc4a5fdd50@github.com>

On Mon, 22 Feb 2021 18:00:57 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Hi all,
>> 
>> This bug was found while I was verifying the fix for JDK-8262096.
>> It was exposed after JDK-8261229.
>> 
>> Testing:
>>   - tier1~3 on Linux/x64, no regression
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> I've indirectly fixed this assert that you noticed in JDK-8261225. But I agree, we should apply the client ergonomic settings as well. Looks good.

Thanks @veresov and @vnkozlov for your review.

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

PR: https://git.openjdk.java.net/jdk/pull/2668

From jiefu at openjdk.java.net  Mon Feb 22 23:46:39 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 22 Feb 2021 23:46:39 GMT
Subject: Integrated: 8262097: Improve CompilerConfig ergonomics to fix a VM
 crash after JDK-8261229
In-Reply-To: <iBD5PZkDX1PMPcqUz164MVvqpz_gq9PSonEm1qfBz9c=.26e4e5a3-9e79-4cda-828b-890f89ed9a4c@github.com>
References: <iBD5PZkDX1PMPcqUz164MVvqpz_gq9PSonEm1qfBz9c=.26e4e5a3-9e79-4cda-828b-890f89ed9a4c@github.com>
Message-ID: <OUiDyzRxLT2KkH722FFxPbADhih9bDR106ns0q0IDuQ=.df2285fc-06f5-4f16-9127-dd78b0a4a443@github.com>

On Sun, 21 Feb 2021 23:25:26 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> This bug was found while I was verifying the fix for JDK-8262096.
> It was exposed after JDK-8261229.
> 
> Testing:
>   - tier1~3 on Linux/x64, no regression
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: f2bde05e
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f2bde05e
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8262097: Improve CompilerConfig ergonomics to fix a VM crash after JDK-8261229

Reviewed-by: iveresov, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/2668

From whuang at openjdk.java.net  Tue Feb 23 07:44:58 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Tue, 23 Feb 2021 07:44:58 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v5]
In-Reply-To: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
Message-ID: <39-V5pqzlgXaCnL3KTIBXvHwrt35rn4WuuknDv8dcuU=.178fe7a3-4b2b-415c-aaa5-ad63598daeb3@github.com>

> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
> @Benchmark
> public void testMethod(Blackhole bh) {
>   int sum = 0;
>   for (int i = 0; i < data.length; i++) {
>       Integer ii = Integer.valueOf(data[i]);
>       if (i < data.length) {
>           sum += ii.intValue();
>       }
>   }
>   bh.consume(sum);
> }
> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
> The uncommon_trap is generated by the optimized "if", because its condition is always true.
> 
> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
> and deleting the use of box:
> 
> There is no additional fail/error(s) of jtreg after this patch.

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  add debuginfo optimization

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2401/files
  - new: https://git.openjdk.java.net/jdk/pull/2401/files/e80e4959..84290aeb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=03-04

  Stats: 65 lines in 6 files changed: 15 ins; 6 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2401/head:pull/2401

PR: https://git.openjdk.java.net/jdk/pull/2401

From roland at openjdk.java.net  Tue Feb 23 08:05:39 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 23 Feb 2021 08:05:39 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <36Vj9yOC0pYOLdCa9ggd9Xg0WxY-O2psZMb86qwgqRI=.c158e853-6184-4790-af14-dc9dba2278cb@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>
 <qjflXFSHcroKMVjsQevrU9Je1jUTcmIJ57BHZXxdj1E=.d8cfede9-ad0e-478d-b3f7-41b26c2cd294@github.com>
 <36Vj9yOC0pYOLdCa9ggd9Xg0WxY-O2psZMb86qwgqRI=.c158e853-6184-4790-af14-dc9dba2278cb@github.com>
Message-ID: <opk-mcVWhreJs8gfEgGj8kN7kR0u9xI63eqaabiGt3Y=.446e3ca8-9efb-4aca-8d3a-b29dd79cdd0e@github.com>

On Mon, 22 Feb 2021 10:30:36 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

> As this match rule is trivial enough, how about withdrawing these shared code in this PR for integrating backend first if your helper methods coming soon?

https://github.com/openjdk/jdk/pull/2045 is the one I'm referring to. No idea when it's going to get in so I would suggest to move forward with the current change and revisit it later.

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From roland at openjdk.java.net  Tue Feb 23 08:09:38 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 23 Feb 2021 08:09:38 GMT
Subject: RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during
 C2 compilation
In-Reply-To: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>
References: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>
Message-ID: <igGZBR4-QxcXYznp0bUfgYU3CGWpKNAnkw5GbFBaNfU=.54bd4758-0d6a-4af8-8233-bd965336a9e7@github.com>

On Thu, 4 Feb 2021 08:34:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Another shenandoah bug with a fix in shared code.
> 
> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
> but non scalarizable. As a result, the null check for a3.f is
> optimized out but the CastPP is left in the graph. That CastPP becomes
> control dependent on the o2 == null check which is later hoisted out
> of the loop. The CastPP is then right after the membar of the barrier = 0x42
> volatile access but with an out of loop control. Because the node is
> considered pinned by loopopts, it is assigned the membar as
> control. The input of the CastPP is a shenandoah barrier that's
> sandwiched between the membar and the CastPP and so expanded right
> after the membar (that is between the membar and its control
> projection). That causes the crash. I don't think cast nodes need to
> be pinned so I propose that as a fix.

Anyone for this (simple) change to shared c2 code?

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

PR: https://git.openjdk.java.net/jdk/pull/2400

From roland at openjdk.java.net  Tue Feb 23 08:09:50 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 23 Feb 2021 08:09:50 GMT
Subject: RFR: 8261308: C2: assert(inner->is_valid_counted_loop(T_INT) &&
 inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
Message-ID: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>

The inner counted loop of the test case starts at 1 and stops at 1 so
runs for one iteration. A counted loop is created for it. The iv Phi
is found to be the constant 1 and its type is set by:

l->phi()->as_Phi()->set_type(l->phi()->Value(&_igvn));

in PhaseIdealLoop::is_counted_loop() but it's not replaced by the
constant 1 yet so the counted loop's shape is preserved.

IdealLoopTree::do_one_iteration_loop() runs but doesn't optimize the
loop because the trip count is not set to 1. The loop contains a range
check and range check elimination is applied. That causes the loop
exit test to be adjusted with a MinI(..) expression. When IGVN runs
next, the phi is replaced with 1 but because the exit test was
changed, IGVN can't prove it always fails. So the loop is not removed
which causes the assert failure as loop opts progress.

The fix I propose is for IdealLoopTree::do_one_iteration_loop() to
remove the 1 iteration loop. The reason it doesn't happen is that
IdealLoopTree::compute_trip_count() doesn't set the trip count because
it finds a zero trip count: limit - init = 1 - 1 = 0. All loops, once
entered execute at least once. So I think, it's safe to set the trip
count to 1 in those cases.

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

Commit messages:
 - whitespaces
 - test
 - fix

Changes: https://git.openjdk.java.net/jdk/pull/2529/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2529&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261308
  Stats: 66 lines in 2 files changed: 65 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2529.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2529/head:pull/2529

PR: https://git.openjdk.java.net/jdk/pull/2529

From github.com+10482586+therealeliu at openjdk.java.net  Tue Feb 23 08:24:58 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Tue, 23 Feb 2021 08:24:58 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v4]
In-Reply-To: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
Message-ID: <EB-8blrDZBa15XaXEIHjSmgVrSY3suRRzUyYCJJ3qnw=.94203eb6-b12e-4e59-99f7-e848c29e9d5a@github.com>

> This patch transforms '(x >>> rshift) + (x << lshift)' into
> 'RotateRight(x, rshift)' during GVN phase when both the shift exponents
> are constants and their sum equals to the number of bits for the type
> of shift base.
> 
> This patch implements some new match rules for AArch64 instructions
> which can take ROR as the optional shift. Such instructions are 'and',
> 'or', 'eor', 'eon', 'bic' and 'orn'.
> 
>   ror     w11, w2, #5
>   eor     w0, w1, w11
> 
> With this patch, above code could be optimized to below:
> 
>   eor     w0, w1, w2, ror #5
> 
> Finally, the patch refactors TestRotate.java[1][2].
> 
> Tested jtreg TestRotate.java, hotspot::hotspot_all_no_apps,
> jdk::jdk_core, langtools::tier1.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8252776
> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039911.html

Eric Liu has updated the pull request incrementally with one additional commit since the last revision:

  Add null check
  
  Change-Id: I18dda4a01154bce72fd4025685fa0721263092ce

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1858/files
  - new: https://git.openjdk.java.net/jdk/pull/1858/files/492f4ca4..93577236

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1858&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1858&range=02-03

  Stats: 22 lines in 1 file changed: 4 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1858.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1858/head:pull/1858

PR: https://git.openjdk.java.net/jdk/pull/1858

From github.com+10482586+therealeliu at openjdk.java.net  Tue Feb 23 08:37:39 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Tue, 23 Feb 2021 08:37:39 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v3]
In-Reply-To: <opk-mcVWhreJs8gfEgGj8kN7kR0u9xI63eqaabiGt3Y=.446e3ca8-9efb-4aca-8d3a-b29dd79cdd0e@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <lLR4YWjk3PBTcFQ8r3aPZv6MsQsO3qtsjRbhf894jnc=.0048f8f4-4628-4a74-8e22-7a4eb23c8c43@github.com>
 <qjflXFSHcroKMVjsQevrU9Je1jUTcmIJ57BHZXxdj1E=.d8cfede9-ad0e-478d-b3f7-41b26c2cd294@github.com>
 <36Vj9yOC0pYOLdCa9ggd9Xg0WxY-O2psZMb86qwgqRI=.c158e853-6184-4790-af14-dc9dba2278cb@github.com>
 <opk-mcVWhreJs8gfEgGj8kN7kR0u9xI63eqaabiGt3Y=.446e3ca8-9efb-4aca-8d3a-b29dd79cdd0e@github.com>
Message-ID: <Wl88DwyDS-PpMQE-BUzpuGo_R2up5gttOOu_vck2iNY=.fff23a1f-fe1f-431f-8f50-cd7f1bf1a83f@github.com>

On Tue, 23 Feb 2021 08:03:20 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Hi Roland,
>> 
>> Thanks for your feedback.
>> 
>>> Even though existing code in that method seems to assume node's inputs can't be NULL, it's a good practice to protect against unexpected NULLs as that can happen when sub-graphs die during IGVN. So in(1)->in(1), in(1)->in(2), in(2)->in(2) need to be tested for NULL.
>> 
>> Agree
>> 
>>> That logic and the one for AddLNode are almost identical. So it would be good to have it in a shared method. I've been adding helper methods to make that possible but not all of that code is in yet.
>> 
>> As this match rule is trivial enough, how about withdrawing these shared code in this PR for integrating backend first if your helper methods coming soon?  
>> 
>>> Could you file a bug to revisit this issue later and assign it to me?
>> 
>> Okay, it's on my queue now:P
>> 
>> 
>> -- Eric
>
>> As this match rule is trivial enough, how about withdrawing these shared code in this PR for integrating backend first if your helper methods coming soon?
> 
> https://github.com/openjdk/jdk/pull/2045 is the one I'm referring to. No idea when it's going to get in so I would suggest to move forward with the current change and revisit it later.

Got it. The patch has been updated.

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From roland at openjdk.java.net  Tue Feb 23 08:48:40 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 23 Feb 2021 08:48:40 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v4]
In-Reply-To: <EB-8blrDZBa15XaXEIHjSmgVrSY3suRRzUyYCJJ3qnw=.94203eb6-b12e-4e59-99f7-e848c29e9d5a@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <EB-8blrDZBa15XaXEIHjSmgVrSY3suRRzUyYCJJ3qnw=.94203eb6-b12e-4e59-99f7-e848c29e9d5a@github.com>
Message-ID: <dtLCGbSXOQwquUh_HaDxuPi5jcyroF-8HOrFfRmD5eU=.2404c4ef-3c68-4ff9-af2a-8f1ee7e8f50f@github.com>

On Tue, 23 Feb 2021 08:24:58 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

>> This patch transforms '(x >>> rshift) + (x << lshift)' into
>> 'RotateRight(x, rshift)' during GVN phase when both the shift exponents
>> are constants and their sum equals to the number of bits for the type
>> of shift base.
>> 
>> This patch implements some new match rules for AArch64 instructions
>> which can take ROR as the optional shift. Such instructions are 'and',
>> 'or', 'eor', 'eon', 'bic' and 'orn'.
>> 
>>   ror     w11, w2, #5
>>   eor     w0, w1, w11
>> 
>> With this patch, above code could be optimized to below:
>> 
>>   eor     w0, w1, w2, ror #5
>> 
>> Finally, the patch refactors TestRotate.java[1][2].
>> 
>> Tested jtreg TestRotate.java, hotspot::hotspot_all_no_apps,
>> jdk::jdk_core, langtools::tier1.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8252776
>> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039911.html
>
> Eric Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add null check
>   
>   Change-Id: I18dda4a01154bce72fd4025685fa0721263092ce

Shared code looks good to me.

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

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1858

From github.com+10482586+therealeliu at openjdk.java.net  Tue Feb 23 09:12:40 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Tue, 23 Feb 2021 09:12:40 GMT
Subject: RFR: 8256438: AArch64: Implement match rules with ROR shift
 register value [v4]
In-Reply-To: <dtLCGbSXOQwquUh_HaDxuPi5jcyroF-8HOrFfRmD5eU=.2404c4ef-3c68-4ff9-af2a-8f1ee7e8f50f@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
 <EB-8blrDZBa15XaXEIHjSmgVrSY3suRRzUyYCJJ3qnw=.94203eb6-b12e-4e59-99f7-e848c29e9d5a@github.com>
 <dtLCGbSXOQwquUh_HaDxuPi5jcyroF-8HOrFfRmD5eU=.2404c4ef-3c68-4ff9-af2a-8f1ee7e8f50f@github.com>
Message-ID: <frtD3HuxABGq7A5BvOWo32Ai5GJ2V8NLucA7IwknuQo=.17db7719-a223-45c6-a537-053adc63d0ee@github.com>

On Tue, 23 Feb 2021 08:46:10 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Eric Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add null check
>>   
>>   Change-Id: I18dda4a01154bce72fd4025685fa0721263092ce
>
> Shared code looks good to me.

Thanks for your review. I will integrate it after some tests were finished.

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From dongbo at openjdk.java.net  Tue Feb 23 10:21:02 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 23 Feb 2021 10:21:02 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v9]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <aMXYZf3oduznPWVyVeEG7UOol_AdXe4yEp_9EcHlJA4=.a55e2e5b-1ec6-474f-8d04-f0ca17fab3c5@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has updated the pull request incrementally with two additional commits since the last revision:

 - whitespace
 - Rebase tests so that sshr/ushr/sshl/ssra/usra are accessed in one jtreg case, assembly print verified.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/ba8dc5ac..e2dc7b83

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=07-08

  Stats: 903 lines in 2 files changed: 320 ins; 387 del; 196 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From dongbo at openjdk.java.net  Tue Feb 23 10:31:45 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 23 Feb 2021 10:31:45 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v9]
In-Reply-To: <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
Message-ID: <z_gVJyVbmos-6bUwGeSGWhqFz4Iku6ghuBC4CqE1ql4=.5cf04e1f-03b5-4b59-9b01-9db2e0082dde@github.com>

On Tue, 9 Feb 2021 07:50:45 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - Rebase tests so that sshr/ushr/sshl/ssra/usra are accessed in one jtreg case, assembly print verified.
>
> Thanks for the fix.

Hi, @theRealAph 

I've rebased the tests so that sshr/ushr/sshl/ssra/usra are accessed in one jtreg `test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java`.
Local tests by manually injected error shows all instructions are covered by the jtreg case. Suggestions?

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From jvernee at openjdk.java.net  Tue Feb 23 12:24:39 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 23 Feb 2021 12:24:39 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v2]
In-Reply-To: <LhkF9ZhUYT2i1TkmQMCkwcx60evmnLU6nzhsEQQGqjQ=.2b773692-b3bd-4710-993f-ecd460451218@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
 <YSiKdYz8EzmJx77zajQ_sLCdIhA0xfHtuZTXbaOrBc8=.974f7741-7037-43e6-aee6-1075b1e2da70@github.com>
 <LhkF9ZhUYT2i1TkmQMCkwcx60evmnLU6nzhsEQQGqjQ=.2b773692-b3bd-4710-993f-ecd460451218@github.com>
Message-ID: <kBUYkzg05lrRt0PkTYwIZKXE-7wNxk3hpZPlGWaCn8w=.077fd4d9-9e58-459b-969d-42d96b46b578@github.com>

On Fri, 12 Feb 2021 10:41:18 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Seems reasonable.
>
> The code here looks ok. I'm slightly concerned about the consequences of adding a new stack frame visible to stack walking code. Does this have the potential to break serviceability code that reports and/or analyzes stack frames (whether that's code in OpenJDK or 3rd party code)?

@adinn I'm not aware of any such use-cases (whether in the JDK or elsewhere). They would only be affected if they were using Panama native calls, which were introduce pretty recently, and are also still in incubator state. 

Inside the JDK the only place where this code is currently being used is in the jdk/java/foreign test stuite, as well as in the internal implementation of the Panama linker. If that test suite still passes I'm happy to call it safe.

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

PR: https://git.openjdk.java.net/jdk/pull/2528

From jvernee at openjdk.java.net  Tue Feb 23 13:02:42 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 23 Feb 2021 13:02:42 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v2]
In-Reply-To: <W2n7gPVdLqZO4VRuhl8Eysyv-5GYBy04joFl3pFGt6U=.cb50513b-e5b4-47e5-b2da-d182f05f3238@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
 <W2n7gPVdLqZO4VRuhl8Eysyv-5GYBy04joFl3pFGt6U=.cb50513b-e5b4-47e5-b2da-d182f05f3238@github.com>
Message-ID: <6NJDW9Yzgj-U0tRiPS1dscN7i3E27kdKuUDdREMA8lo=.81cd0ead-af88-4af3-bcf3-6025cff8f855@github.com>

On Fri, 12 Feb 2021 09:37:02 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> We spotted this issue with Shenandoah and I managed to write a simple
>> test case that reproduces it reliably with Shenandoah but the issue is
>> independent of the GC.
>> 
>> The loop in the test case calls a native invoker with an oop live in
>> rbp. rbp is saved in the native invoker stub's frame. A safepoint is
>> triggered from the safepoint check in the native invoker. The stack
>> walking code sees that rbp contains an oop but can't find where that
>> oop is stored. That's because stack walking updates the caller's frame
>> with the location of rbp in the callee on calls to
>> frame::sender(). But the current code sets the last java frame to be
>> the compiled frame where rbp is live. So there's no call to
>> frame::sender() to update the location rbp. The fix I propose is that
>> the frame of the native invoker be visible by stack walking. On a
>> safepoint, stack walking starts from the native invoker thread, then
>> calls frame::sender() to move to the compiled frame. That causes rbp
>> to be properly recorded with its location in the native invoker frame.
>> 
>> Same problem affects both x86 and aarch64. I've tested this patch with:
>> 
>> make run-test TEST="java/foreign" TEST_VM_OPTS="-Xcomp" JTREG="TIMEOUT_FACTOR=10"
>> 
>> on both platforms.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   broken build

LGTM, but I've left some suggestions in line.

Thanks for cleaning up the frame layout code. Having a fixed frame is much better than repeatedly modifying the stack pointer.

I've also done some downstream stress testing with jextract, and everything works as expected.

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 3514:

> 3512: 
> 3513:   OopMapSet* oop_maps() const {
> 3514:     return _oop_maps;

The `saved_rbp_address_offset` field was added to JavaFrameAnchor just to serve this particular use case. It should be cleaned up now that it is no longer used.

If you don't want to take care of that, we can file a followup.

There is code in `frame_*.cpp`, `thread_*.hpp`, and `javaFrameAnchor_*.hpp` that deals with this field (not on all platforms/archs though). See https://github.com/openjdk/jdk/pull/634/files & https://github.com/openjdk/jdk/pull/1711/files for the original diffs.

test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java line 50:

> 48: public class TestLinkToNativeRBP {
> 49:     final static CLinker abi = CLinker.getInstance();
> 50:     static final LibraryLookup lookup = LibraryLookup.ofDefault();

The default library can be unreliable (but we've kept it in lieu of something better, which is still in the pipeline). We've had problems with it in the past since it acts differently in different environments, so we try to avoid it in tests.

It would be more robust to add a small test library that defines a dummy function and then depend on that instead.

If you've not done this before; you can just add a `lib<Name>.c` file to the same directory as the main test file and the build system will compile it for you. You can then load it with `LibraryLookup.ofLibrary("<Name>")` in the test. See the [test/jdk/java/foreign/stackwalk](https://github.com/openjdk/jdk/tree/master/test/jdk/java/foreign/stackwalk) directory for an example (one noteworthy thing is that the function has to be explicitly exported in order to work on Windows. See the example).

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

Marked as reviewed by jvernee (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2528

From github.com+42899633+eastig at openjdk.java.net  Tue Feb 23 16:01:40 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 23 Feb 2021 16:01:40 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v6]
In-Reply-To: <y3yIDeFnuhNuQEpoZvYxHSEJhfJ57zsrQ4LGRAG2sN8=.80ebbed3-49d8-45a2-b2e7-e4c5fa474cd6@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <y3yIDeFnuhNuQEpoZvYxHSEJhfJ57zsrQ4LGRAG2sN8=.80ebbed3-49d8-45a2-b2e7-e4c5fa474cd6@github.com>
Message-ID: <aQCckSCZiYscSKrMXUP5hIKARc-VtS3K41pcAZAGdys=.49db2a6f-aba3-4d21-9275-4570a0f7cdb2@github.com>

On Sun, 21 Feb 2021 02:07:59 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
>> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
>> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
>> 
>> Before:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
>> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
>> - string: "a"
>> :Constant:exact *
>> 
>> After:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>   
>   fix build failures on Windows. StringUtils::tr_delete returns size_of.

Changes requested by eastig at github.com (no known OpenJDK username).

src/hotspot/share/opto/type.cpp line 4056:

> 4054:         StringUtils::tr_delete(buf, "\n");
> 4055:         st->print_raw(buf);
> 4056:         os::free(buf);

There is no need to use `os::strdup` because `as_string` creates a copy.
I've looked in stringUtils.cpp and found `replace_no_expand`.  The code can be rewritten:
char *buf = ss.as_string();
StringUtils::replace_no_expand(buf, "\n", "");
st->print_raw(buf);
With this code, `tr_delete` is redundant.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From chagedorn at openjdk.java.net  Tue Feb 23 16:14:45 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 23 Feb 2021 16:14:45 GMT
Subject: RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during
 C2 compilation
In-Reply-To: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>
References: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>
Message-ID: <p0m9NpJqw5Tv3ESY_9Cvqi3Gs9nWs4sZh0qE88mMesg=.37c5843a-4106-4f88-9b3a-eb543548b072@github.com>

On Thu, 4 Feb 2021 08:34:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Another shenandoah bug with a fix in shared code.
> 
> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
> but non scalarizable. As a result, the null check for a3.f is
> optimized out but the CastPP is left in the graph. That CastPP becomes
> control dependent on the o2 == null check which is later hoisted out
> of the loop. The CastPP is then right after the membar of the barrier = 0x42
> volatile access but with an out of loop control. Because the node is
> considered pinned by loopopts, it is assigned the membar as
> control. The input of the CastPP is a shenandoah barrier that's
> sandwiched between the membar and the CastPP and so expanded right
> after the membar (that is between the membar and its control
> projection). That causes the crash. I don't think cast nodes need to
> be pinned so I propose that as a fix.

Looks reasonable to me!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2400

From kvn at openjdk.java.net  Tue Feb 23 16:32:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 23 Feb 2021 16:32:39 GMT
Subject: RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during
 C2 compilation
In-Reply-To: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>
References: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>
Message-ID: <a-AGWx_M5F5zcZ5RN2Xop0Lb4DjI152rfKS7Vu78FXs=.c0968fe3-bfd5-48ca-8987-f0a7a1a86eec@github.com>

On Thu, 4 Feb 2021 08:34:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Another shenandoah bug with a fix in shared code.
> 
> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
> but non scalarizable. As a result, the null check for a3.f is
> optimized out but the CastPP is left in the graph. That CastPP becomes
> control dependent on the o2 == null check which is later hoisted out
> of the loop. The CastPP is then right after the membar of the barrier = 0x42
> volatile access but with an out of loop control. Because the node is
> considered pinned by loopopts, it is assigned the membar as
> control. The input of the CastPP is a shenandoah barrier that's
> sandwiched between the membar and the CastPP and so expanded right
> after the membar (that is between the membar and its control
> projection). That causes the crash. I don't think cast nodes need to
> be pinned so I propose that as a fix.

Ok

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2400

From roland at openjdk.java.net  Tue Feb 23 16:37:40 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 23 Feb 2021 16:37:40 GMT
Subject: RFR: 8260637: Shenandoah: assert(_base == Tuple) failure during
 C2 compilation
In-Reply-To: <a-AGWx_M5F5zcZ5RN2Xop0Lb4DjI152rfKS7Vu78FXs=.c0968fe3-bfd5-48ca-8987-f0a7a1a86eec@github.com>
References: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>
 <a-AGWx_M5F5zcZ5RN2Xop0Lb4DjI152rfKS7Vu78FXs=.c0968fe3-bfd5-48ca-8987-f0a7a1a86eec@github.com>
Message-ID: <HN1zgqDGF6Cmw-evOnbeJRplu9lkLNKuq60nXJwck7c=.842b5ce6-f14b-45ee-a20a-84a19c44f717@github.com>

On Tue, 23 Feb 2021 16:29:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Another shenandoah bug with a fix in shared code.
>> 
>> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
>> but non scalarizable. As a result, the null check for a3.f is
>> optimized out but the CastPP is left in the graph. That CastPP becomes
>> control dependent on the o2 == null check which is later hoisted out
>> of the loop. The CastPP is then right after the membar of the barrier = 0x42
>> volatile access but with an out of loop control. Because the node is
>> considered pinned by loopopts, it is assigned the membar as
>> control. The input of the CastPP is a shenandoah barrier that's
>> sandwiched between the membar and the CastPP and so expanded right
>> after the membar (that is between the membar and its control
>> projection). That causes the crash. I don't think cast nodes need to
>> be pinned so I propose that as a fix.
>
> Ok

@vnkozlov @chhagedorn thanks for the reviews

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

PR: https://git.openjdk.java.net/jdk/pull/2400

From roland at openjdk.java.net  Tue Feb 23 16:37:41 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 23 Feb 2021 16:37:41 GMT
Subject: Integrated: 8260637: Shenandoah: assert(_base == Tuple) failure
 during C2 compilation
In-Reply-To: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>
References: <lRsDMvlBgUlf7W6Os2rKTio2UeyV7e1tnq0Lx7vw2i4=.79f26841-fa5f-42ed-be03-8c82544efc37@github.com>
Message-ID: <IEleN7HdNqegFMWF4dSfW2CZI92PnnPLpWHLStNMx5I=.6a5eb582-d0b4-4177-8e44-c14c6106db0d@github.com>

On Thu, 4 Feb 2021 08:34:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Another shenandoah bug with a fix in shared code.
> 
> LRBRightAfterMemBar.test2() has 2 allocations that are non escaping
> but non scalarizable. As a result, the null check for a3.f is
> optimized out but the CastPP is left in the graph. That CastPP becomes
> control dependent on the o2 == null check which is later hoisted out
> of the loop. The CastPP is then right after the membar of the barrier = 0x42
> volatile access but with an out of loop control. Because the node is
> considered pinned by loopopts, it is assigned the membar as
> control. The input of the CastPP is a shenandoah barrier that's
> sandwiched between the membar and the CastPP and so expanded right
> after the membar (that is between the membar and its control
> projection). That causes the crash. I don't think cast nodes need to
> be pinned so I propose that as a fix.

This pull request has now been integrated.

Changeset: 8a2f5890
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8a2f5890
Stats:     33 lines in 2 files changed: 27 ins; 0 del; 6 mod

8260637: Shenandoah: assert(_base == Tuple) failure during C2 compilation

Reviewed-by: chagedorn, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/2400

From chagedorn at openjdk.java.net  Tue Feb 23 16:46:44 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 23 Feb 2021 16:46:44 GMT
Subject: RFR: 8261308: C2: assert(inner->is_valid_counted_loop(T_INT) &&
 inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
In-Reply-To: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
References: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
Message-ID: <_4YFKcN-AhcsKl3a4PPzD4Op466zqUlOkUQjWd1epC8=.6ebb4db2-1e7b-46ed-9a87-60f3b9c35e50@github.com>

On Thu, 11 Feb 2021 16:11:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The inner counted loop of the test case starts at 1 and stops at 1 so
> runs for one iteration. A counted loop is created for it. The iv Phi
> is found to be the constant 1 and its type is set by:
> 
> l->phi()->as_Phi()->set_type(l->phi()->Value(&_igvn));
> 
> in PhaseIdealLoop::is_counted_loop() but it's not replaced by the
> constant 1 yet so the counted loop's shape is preserved.
> 
> IdealLoopTree::do_one_iteration_loop() runs but doesn't optimize the
> loop because the trip count is not set to 1. The loop contains a range
> check and range check elimination is applied. That causes the loop
> exit test to be adjusted with a MinI(..) expression. When IGVN runs
> next, the phi is replaced with 1 but because the exit test was
> changed, IGVN can't prove it always fails. So the loop is not removed
> which causes the assert failure as loop opts progress.
> 
> The fix I propose is for IdealLoopTree::do_one_iteration_loop() to
> remove the 1 iteration loop. The reason it doesn't happen is that
> IdealLoopTree::compute_trip_count() doesn't set the trip count because
> it finds a zero trip count: limit - init = 1 - 1 = 0. All loops, once
> entered execute at least once. So I think, it's safe to set the trip
> count to 1 in those cases.

That's reasonable to do. Looks good to me!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2529

From never at openjdk.java.net  Tue Feb 23 17:04:47 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Tue, 23 Feb 2021 17:04:47 GMT
Subject: RFR: 8262011: [JVMCI] allow printing to tty from unattached
 libgraal thread
In-Reply-To: <tTReCuJ52xHBFDb9nQRDySq9FiFCMFOY5QtIFGHWg-8=.d921d4cd-af3c-4b85-a75b-60fed6809408@github.com>
References: <tTReCuJ52xHBFDb9nQRDySq9FiFCMFOY5QtIFGHWg-8=.d921d4cd-af3c-4b85-a75b-60fed6809408@github.com>
Message-ID: <TD2a12I1jufMi6AFH2yH0hlKDXLxNe1s0PjcLpDI9xw=.acf2503c-f706-4687-bbdd-ed3a2e4a66ed@github.com>

On Fri, 19 Feb 2021 10:10:17 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Currently, `HotSpotJVMCIRuntime.writeDebugOutput` does nothing if the current thread is not attached to HotSpot (i.e., `Thread::current_or_null() == NULL`). This means crucial debug info can be lost. For reference, an unattached libgraal thread is a thread started from within libgraal that has not yet attached itself to the VM (e.g., before [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L42)) or has already detached itself (e.g., after [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L46)).
> 
> The reason for the current behavior is that `HotSpotJVMCIRuntime.writeDebugOutput` passes a Java byte array to C++ code and the C++ code calls back into Java to decode the byte array into a native buffer. These call backs require the current thread to be attached to the VM.
> 
> This PR moves the Java-to-native-buffer decoding into Java and thus avoids the requirement for the current thread to be attached to the VM.
> 
> Tested in libgraal by patching Graal as follows:
> diff --git a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> index 36064767c95..352395dd59b 100644
> --- a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> +++ b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> @@ -43,7 +43,14 @@ public class GraalServiceThread extends Thread {
>          try {
>              runnable.run();
>          } finally {
> +            String debug = System.getenv("GraalServiceThread.debug");
>              afterRun();
> +            if ("true".equals(debug)) {
> +                throw new InternalError("THROWN AFTER DETACHING");
> +            }
>          }
>      }
> 
> Running without the changes in this PR:
>> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
> ===== DaCapo 9.12 avrora starting =====
> ===== DaCapo 9.12 avrora PASSED in 4270 msec =====
> 
> Running with the changes in this PR:
>> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
> ===== DaCapo 9.12 avrora starting =====
> Exception in thread "LibGraalHotSpotGraalManagement-init" java.lang.InternalError: THROWN AFTER DETACHING
> 	at org.graalvm.compiler.core.GraalServiceThread.run(GraalServiceThread.java:52)
> 	at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:519)
> 	at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)
> ===== DaCapo 9.12 avrora PASSED in 4688 msec =====

Looks good.

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

Marked as reviewed by never (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2640

From dnsimon at openjdk.java.net  Tue Feb 23 17:04:47 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 23 Feb 2021 17:04:47 GMT
Subject: Integrated: 8262011: [JVMCI] allow printing to tty from unattached
 libgraal thread
In-Reply-To: <tTReCuJ52xHBFDb9nQRDySq9FiFCMFOY5QtIFGHWg-8=.d921d4cd-af3c-4b85-a75b-60fed6809408@github.com>
References: <tTReCuJ52xHBFDb9nQRDySq9FiFCMFOY5QtIFGHWg-8=.d921d4cd-af3c-4b85-a75b-60fed6809408@github.com>
Message-ID: <5HnNCDmwGXnINtnvJUoPX4tPInEecrCwzEietDkKrl0=.7dbce5a9-779c-4712-b739-47a65b69f3c8@github.com>

On Fri, 19 Feb 2021 10:10:17 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Currently, `HotSpotJVMCIRuntime.writeDebugOutput` does nothing if the current thread is not attached to HotSpot (i.e., `Thread::current_or_null() == NULL`). This means crucial debug info can be lost. For reference, an unattached libgraal thread is a thread started from within libgraal that has not yet attached itself to the VM (e.g., before [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L42)) or has already detached itself (e.g., after [this line](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L46)).
> 
> The reason for the current behavior is that `HotSpotJVMCIRuntime.writeDebugOutput` passes a Java byte array to C++ code and the C++ code calls back into Java to decode the byte array into a native buffer. These call backs require the current thread to be attached to the VM.
> 
> This PR moves the Java-to-native-buffer decoding into Java and thus avoids the requirement for the current thread to be attached to the VM.
> 
> Tested in libgraal by patching Graal as follows:
> diff --git a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> index 36064767c95..352395dd59b 100644
> --- a/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> +++ b/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java
> @@ -43,7 +43,14 @@ public class GraalServiceThread extends Thread {
>          try {
>              runnable.run();
>          } finally {
> +            String debug = System.getenv("GraalServiceThread.debug");
>              afterRun();
> +            if ("true".equals(debug)) {
> +                throw new InternalError("THROWN AFTER DETACHING");
> +            }
>          }
>      }
> 
> Running without the changes in this PR:
>> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
> ===== DaCapo 9.12 avrora starting =====
> ===== DaCapo 9.12 avrora PASSED in 4270 msec =====
> 
> Running with the changes in this PR:
>> env GraalServiceThread.debug=true java -jar dacapo.jar avrora
> ===== DaCapo 9.12 avrora starting =====
> Exception in thread "LibGraalHotSpotGraalManagement-init" java.lang.InternalError: THROWN AFTER DETACHING
> 	at org.graalvm.compiler.core.GraalServiceThread.run(GraalServiceThread.java:52)
> 	at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:519)
> 	at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)
> ===== DaCapo 9.12 avrora PASSED in 4688 msec =====

This pull request has now been integrated.

Changeset: d2b9c227
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d2b9c227
Stats:     322 lines in 8 files changed: 49 ins; 246 del; 27 mod

8262011: [JVMCI] allow printing to tty from unattached libgraal thread

Reviewed-by: kvn, never

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

PR: https://git.openjdk.java.net/jdk/pull/2640

From aph at openjdk.java.net  Tue Feb 23 17:16:41 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Feb 2021 17:16:41 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v9]
In-Reply-To: <z_gVJyVbmos-6bUwGeSGWhqFz4Iku6ghuBC4CqE1ql4=.5cf04e1f-03b5-4b59-9b01-9db2e0082dde@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
 <z_gVJyVbmos-6bUwGeSGWhqFz4Iku6ghuBC4CqE1ql4=.5cf04e1f-03b5-4b59-9b01-9db2e0082dde@github.com>
Message-ID: <BlOlxuz8EYot1Utx13ETlVqmsVG-L5BNzAROHFTq8hA=.330113a8-fd0f-495b-925b-f14bf750aa43@github.com>

On Tue, 23 Feb 2021 10:29:05 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> Hi, @theRealAph
> 
> I've rebased the tests so that sshr/ushr/sshl/ssra/usra are accessed in one jtreg `test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java`.
> Local tests by manually injected error shows all instructions are covered by the jtreg case. Suggestions?

I'm not seeing ```sra``` used anywhere.

The problem I see with the tests is that the methods are large. This causes C2 to do a lot of spilling. Also, because the resuling code is intertwined and complex, it's very hard to debug.

It would be far better to do something like this:
    void long_shift_add(long arrLongs[][], LongVector vba, LongVector vbb, int i) {
        vba.add(vbb.lanewise(VectorOperators.LSHR, 37)).intoArray(arrLongs[op], 2 * i);
        vba.add(vbb.lanewise(VectorOperators.LSHR, 64)).intoArray(arrLongs[op  + 1], 2 * i);
        vba.add(vbb.lanewise(VectorOperators.LSHR, 99)).intoArray(arrLongs[op  + 2], 2 * i);
        vba.add(vbb.lanewise(VectorOperators.LSHR, 128)).intoArray(arrLongs[op + 3], 2 * i);
        vba.add(vbb.lanewise(VectorOperators.LSHR, 157)).intoArray(arrLongs[op + 4], 2 * i);
        vba.add(vbb.lanewise(VectorOperators.LSHR, 192)).intoArray(arrLongs[op + 5], 2 * i);
    }

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From kvn at openjdk.java.net  Tue Feb 23 17:19:44 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 23 Feb 2021 17:19:44 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v5]
In-Reply-To: <39-V5pqzlgXaCnL3KTIBXvHwrt35rn4WuuknDv8dcuU=.178fe7a3-4b2b-415c-aaa5-ad63598daeb3@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <39-V5pqzlgXaCnL3KTIBXvHwrt35rn4WuuknDv8dcuU=.178fe7a3-4b2b-415c-aaa5-ad63598daeb3@github.com>
Message-ID: <WSqyVKBG8l9U_-denWxoZbh3MVsIOWsb7nGXkML_NdE=.a40895b6-1de6-4a1e-a030-e7a42e980136@github.com>

On Tue, 23 Feb 2021 07:44:58 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
>> @Benchmark
>> public void testMethod(Blackhole bh) {
>>   int sum = 0;
>>   for (int i = 0; i < data.length; i++) {
>>       Integer ii = Integer.valueOf(data[i]);
>>       if (i < data.length) {
>>           sum += ii.intValue();
>>       }
>>   }
>>   bh.consume(sum);
>> }
>> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
>> The uncommon_trap is generated by the optimized "if", because its condition is always true.
>> 
>> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
>> and deleting the use of box:
>> 
>> There is no additional fail/error(s) of jtreg after this patch.
>> 
>> I adjust my codes and add a new benchmark
>> 
>> public class MyBenchmark {
>> 
>>     static int[] data = new int[10000];
>> 
>>     static {
>>         for(int i = 0; i < data.length; ++i) {
>>             data[i] = i * 1337 % 7331;
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void testMethod(Blackhole bh) {
>>       int sum = 0;
>>       for (int i = 0; i < data.length; i++) {
>>           Integer ii = Integer.valueOf(data[i]);
>>           black();
>>           if (i < 100000) {
>>               sum += ii.intValue();
>>           }
>>       }
>>       bh.consume(sum);
>>     }
>> 
>>     public void black(){}
>> }
>> 
>> 
>> aarch64:  
>> base line?
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  88.513        1.111  us/op
>> 
>> opt?
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  52.776        0.096  us/op
>> 
>> x86:  
>> base line?
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  81.066        3.156  us/op
>> 
>> opt:
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  55.596        0.775  us/op
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add debuginfo optimization

Please, add test case which verifies that Box is scalarized by forking process and checking output of run with `-XX:+PrintEliminateAllocations` flag.
You also need a test which triggers deoptimization and execute code for Box object reallocation/initialization or load from cache.
A test should also verifies that box object identity matches after deoptimization.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From kvn at openjdk.java.net  Tue Feb 23 19:18:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 23 Feb 2021 19:18:42 GMT
Subject: RFR: 8261308: C2: assert(inner->is_valid_counted_loop(T_INT) &&
 inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
In-Reply-To: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
References: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
Message-ID: <wcwypSAxvdGZ_P01UMfM7Xhvc0MMxXN5GTVHov2rxBg=.e3f54355-bfcf-430f-868f-d6f0aef5c82a@github.com>

On Thu, 11 Feb 2021 16:11:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The inner counted loop of the test case starts at 1 and stops at 1 so
> runs for one iteration. A counted loop is created for it. The iv Phi
> is found to be the constant 1 and its type is set by:
> 
> l->phi()->as_Phi()->set_type(l->phi()->Value(&_igvn));
> 
> in PhaseIdealLoop::is_counted_loop() but it's not replaced by the
> constant 1 yet so the counted loop's shape is preserved.
> 
> IdealLoopTree::do_one_iteration_loop() runs but doesn't optimize the
> loop because the trip count is not set to 1. The loop contains a range
> check and range check elimination is applied. That causes the loop
> exit test to be adjusted with a MinI(..) expression. When IGVN runs
> next, the phi is replaced with 1 but because the exit test was
> changed, IGVN can't prove it always fails. So the loop is not removed
> which causes the assert failure as loop opts progress.
> 
> The fix I propose is for IdealLoopTree::do_one_iteration_loop() to
> remove the 1 iteration loop. The reason it doesn't happen is that
> IdealLoopTree::compute_trip_count() doesn't set the trip count because
> it finds a zero trip count: limit - init = 1 - 1 = 0. All loops, once
> entered execute at least once. So I think, it's safe to set the trip
> count to 1 in those cases.

I think we need a test which verifies one_iteration loop optimization with different variations of init, limit and stride values to make sure `trip_count` formula is correct.

src/hotspot/share/opto/loopTransform.cpp line 126:

> 124:     jlong limit_con = (stride_con > 0) ? limit_type->_hi : limit_type->_lo;
> 125:     int stride_m = stride_con - (stride_con > 0 ? 1 : -1);
> 126:     jlong trip_count = (limit_con - init_con + stride_m)/stride_con;

Does it mean that before we execute do_one_iteration_loop() optimization for loops which do 2 trips?
This seems wrong. Can you check?
I agree that loop body executed at least once since it is exit check. But it means we have to generally adjust `trip_count` with `+1` and not do what you suggested.

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

PR: https://git.openjdk.java.net/jdk/pull/2529

From xliu at openjdk.java.net  Tue Feb 23 19:32:42 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 23 Feb 2021 19:32:42 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v6]
In-Reply-To: <aQCckSCZiYscSKrMXUP5hIKARc-VtS3K41pcAZAGdys=.49db2a6f-aba3-4d21-9275-4570a0f7cdb2@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <y3yIDeFnuhNuQEpoZvYxHSEJhfJ57zsrQ4LGRAG2sN8=.80ebbed3-49d8-45a2-b2e7-e4c5fa474cd6@github.com>
 <aQCckSCZiYscSKrMXUP5hIKARc-VtS3K41pcAZAGdys=.49db2a6f-aba3-4d21-9275-4570a0f7cdb2@github.com>
Message-ID: <-6o8O3AATyO7_tSm4zM4ztzGvjcQgCvFbk0NE7J9yJQ=.a452f241-9103-4408-b853-4befdb110358@github.com>

On Tue, 23 Feb 2021 15:59:03 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>>   
>>   fix build failures on Windows. StringUtils::tr_delete returns size_of.
>
> src/hotspot/share/opto/type.cpp line 4056:
> 
>> 4054:         StringUtils::tr_delete(buf, "\n");
>> 4055:         st->print_raw(buf);
>> 4056:         os::free(buf);
> 
> There is no need to use `os::strdup` because `as_string` creates a copy.
> I've looked in stringUtils.cpp and found `replace_no_expand`.  The code can be rewritten:
> char *buf = ss.as_string();
> StringUtils::replace_no_expand(buf, "\n", "");
> st->print_raw(buf);
> With this code, `tr_delete` is redundant.

oh, thanks for the head-up.  I'm happy to remove os::strdup and os::free pair. 
it seems that replace_no_expand is cumbersome to do what  tr_delete does.  let me see how it works.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From github.com+42899633+eastig at openjdk.java.net  Tue Feb 23 21:11:39 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 23 Feb 2021 21:11:39 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v6]
In-Reply-To: <-6o8O3AATyO7_tSm4zM4ztzGvjcQgCvFbk0NE7J9yJQ=.a452f241-9103-4408-b853-4befdb110358@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <y3yIDeFnuhNuQEpoZvYxHSEJhfJ57zsrQ4LGRAG2sN8=.80ebbed3-49d8-45a2-b2e7-e4c5fa474cd6@github.com>
 <aQCckSCZiYscSKrMXUP5hIKARc-VtS3K41pcAZAGdys=.49db2a6f-aba3-4d21-9275-4570a0f7cdb2@github.com>
 <-6o8O3AATyO7_tSm4zM4ztzGvjcQgCvFbk0NE7J9yJQ=.a452f241-9103-4408-b853-4befdb110358@github.com>
Message-ID: <_bbShtIislmHUrEyims35ijjL_jtvIdI3BgwSR-ZdD0=.d88d8516-d838-4c1b-9432-578836a32a40@github.com>

On Tue, 23 Feb 2021 19:30:00 GMT, Xin Liu <xliu at openjdk.org> wrote:

> oh, thanks for the head-up. I'm happy to remove os::strdup and os::free pair.
> it seems that replace_no_expand is cumbersome to do what tr_delete does. let me see how it works.

I don't see why it is cumbersome. IMHO, it is logically consistent: replace substring with an empty string without expanding the buffer. The main value is the amount of written code.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From zgu at openjdk.java.net  Tue Feb 23 21:58:52 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 23 Feb 2021 21:58:52 GMT
Subject: RFR: 8262259: Remove unused variable in
 MethodLiveness::BasicBlock::compute_gen_kill_single
Message-ID: <jwFKB6FYb56zx0iN1k1dbBugs7XuRKQzM2mJonyx4vU=.be436da7-fea2-4f19-9c8b-1f676d642d3f@github.com>

Please review this trivial patch that removes unused/dead local variable.

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

Commit messages:
 - Merge branch 'master' into JDK-8262259-rm-unused-localNum
 - JDK-8262259

Changes: https://git.openjdk.java.net/jdk/pull/2698/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2698&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262259
  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2698.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2698/head:pull/2698

PR: https://git.openjdk.java.net/jdk/pull/2698

From xliu at openjdk.java.net  Tue Feb 23 23:12:56 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 23 Feb 2021 23:12:56 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v7]
In-Reply-To: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
Message-ID: <W6ugHZBkrOsGnh9VzFYsnGl0-ElT0BAHw5QTfyBv1N0=.4c5d70ec-4403-4265-ad6a-6f9bf1ed57e7@github.com>

> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
> 
> Before:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
> - string: "a"
> :Constant:exact *
> 
> After:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
  
  use the existing api StringUtils::replace_no_expand to archive the same replace.
  don't need to invoke os::strdup because stringStream::as_string() has duplicated
  the internal buffer.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2178/files
  - new: https://git.openjdk.java.net/jdk/pull/2178/files/077f9b60..6df63fe1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=05-06

  Stats: 83 lines in 5 files changed: 0 ins; 75 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2178.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2178/head:pull/2178

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Tue Feb 23 23:18:41 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 23 Feb 2021 23:18:41 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v6]
In-Reply-To: <_bbShtIislmHUrEyims35ijjL_jtvIdI3BgwSR-ZdD0=.d88d8516-d838-4c1b-9432-578836a32a40@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <y3yIDeFnuhNuQEpoZvYxHSEJhfJ57zsrQ4LGRAG2sN8=.80ebbed3-49d8-45a2-b2e7-e4c5fa474cd6@github.com>
 <aQCckSCZiYscSKrMXUP5hIKARc-VtS3K41pcAZAGdys=.49db2a6f-aba3-4d21-9275-4570a0f7cdb2@github.com>
 <-6o8O3AATyO7_tSm4zM4ztzGvjcQgCvFbk0NE7J9yJQ=.a452f241-9103-4408-b853-4befdb110358@github.com>
 <_bbShtIislmHUrEyims35ijjL_jtvIdI3BgwSR-ZdD0=.d88d8516-d838-4c1b-9432-578836a32a40@github.com>
Message-ID: <aL39QC5QSBMryVotdAfJf-Re3bEo3zDA3v122k7VW7A=.ce2905af-bac6-40d0-a6c0-304fdef57174@github.com>

On Tue, 23 Feb 2021 21:09:15 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> oh, thanks for the head-up.  I'm happy to remove os::strdup and os::free pair. 
>> it seems that replace_no_expand is cumbersome to do what  tr_delete does.  let me see how it works.
>
>> oh, thanks for the head-up. I'm happy to remove os::strdup and os::free pair.
>> it seems that replace_no_expand is cumbersome to do what tr_delete does. let me see how it works.
> 
> I don't see why it is cumbersome. IMHO, it is logically consistent: replace substring with an empty string without expanding the buffer. The main value is the amount of written code.

oh, by means "cumbersome",  I just felt that it's easier to sweeping chars than substrings in my case.  but I has verified `replace_no_expand(buf, "\n", "")` has the same effect.  I took you advice.  less code is less chance to make mistake. 

Updated this PR. I also verified that it has the same results for `-XX:+Verbose -XX:+PrintIdeal`.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From stuefe at openjdk.java.net  Wed Feb 24 04:59:48 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 24 Feb 2021 04:59:48 GMT
Subject: RFR: 8262259: Remove unused variable in
 MethodLiveness::BasicBlock::compute_gen_kill_single
In-Reply-To: <jwFKB6FYb56zx0iN1k1dbBugs7XuRKQzM2mJonyx4vU=.be436da7-fea2-4f19-9c8b-1f676d642d3f@github.com>
References: <jwFKB6FYb56zx0iN1k1dbBugs7XuRKQzM2mJonyx4vU=.be436da7-fea2-4f19-9c8b-1f676d642d3f@github.com>
Message-ID: <YTJWH1amQ97ZEqNkPq2QEIl5i4MEmVXIoPBlM_gwIy8=.738e28ef-5558-4977-bd70-92dd7b288aa7@github.com>

On Tue, 23 Feb 2021 21:52:31 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch that removes unused/dead local variable.

Seems fine and trivial.
..Thomas

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2698

From thartmann at openjdk.java.net  Wed Feb 24 06:46:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 24 Feb 2021 06:46:39 GMT
Subject: RFR: 8262259: Remove unused variable in
 MethodLiveness::BasicBlock::compute_gen_kill_single
In-Reply-To: <jwFKB6FYb56zx0iN1k1dbBugs7XuRKQzM2mJonyx4vU=.be436da7-fea2-4f19-9c8b-1f676d642d3f@github.com>
References: <jwFKB6FYb56zx0iN1k1dbBugs7XuRKQzM2mJonyx4vU=.be436da7-fea2-4f19-9c8b-1f676d642d3f@github.com>
Message-ID: <EtQvyTaAdyZ5wwQngSpBcCX9s5LNLJP3or3iPuBhOZU=.d36547fb-38ca-4b61-9df4-bf27e250be8f@github.com>

On Tue, 23 Feb 2021 21:52:31 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch that removes unused/dead local variable.

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2698

From thartmann at openjdk.java.net  Wed Feb 24 06:56:41 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 24 Feb 2021 06:56:41 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v7]
In-Reply-To: <W6ugHZBkrOsGnh9VzFYsnGl0-ElT0BAHw5QTfyBv1N0=.4c5d70ec-4403-4265-ad6a-6f9bf1ed57e7@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <W6ugHZBkrOsGnh9VzFYsnGl0-ElT0BAHw5QTfyBv1N0=.4c5d70ec-4403-4265-ad6a-6f9bf1ed57e7@github.com>
Message-ID: <U93lV7GGLqRvTZh3KzIXNbGeB_YuAiTHYlrgI-VUB6c=.57682641-fab8-4f9e-8082-e047f2557dc4@github.com>

On Tue, 23 Feb 2021 23:12:56 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
>> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
>> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
>> 
>> Before:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
>> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
>> - string: "a"
>> :Constant:exact *
>> 
>> After:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>   
>   use the existing api StringUtils::replace_no_expand to archive the same replace.
>   don't need to invoke os::strdup because stringStream::as_string() has duplicated
>   the internal buffer.

Changes requested by thartmann (Reviewer).

src/hotspot/share/opto/type.cpp line 4052:

> 4050: 
> 4051:       {
> 4052:         ResourceMark rm;

Shouldn't the `ResourceMark` go to before `stringStream ss` which is a `ResourceObj` as well? Also, please add a small comment explaining that this code suppresses the new line emitted by `print_oop`.

src/hotspot/share/opto/type.cpp line 4040:

> 4038: // Dump oop Type
> 4039: #ifndef PRODUCT
> 4040: void TypeInstPtr::dump2( Dict &d, uint depth, outputStream* st ) const {

While you are at it, please also remove the excess whitespace after `(` and before `)`.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From dongbo at openjdk.java.net  Wed Feb 24 07:27:03 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 24 Feb 2021 07:27:03 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v10]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <DE-BECQyGkFhU34tXNQWMrY4ijA9C6QaT0izce2MtwU=.591bbc8a-f3a0-45c4-94ad-9e6f3c341de8@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  update tests as suggestions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/e2dc7b83..9290f27e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=08-09

  Stats: 465 lines in 1 file changed: 159 ins; 187 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From thartmann at openjdk.java.net  Wed Feb 24 07:31:47 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 24 Feb 2021 07:31:47 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v5]
In-Reply-To: <39-V5pqzlgXaCnL3KTIBXvHwrt35rn4WuuknDv8dcuU=.178fe7a3-4b2b-415c-aaa5-ad63598daeb3@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <39-V5pqzlgXaCnL3KTIBXvHwrt35rn4WuuknDv8dcuU=.178fe7a3-4b2b-415c-aaa5-ad63598daeb3@github.com>
Message-ID: <bDAHGAltLV3xaHlg-YprlnsVgYAZxk_nCSnjMBr5uWY=.04d47d7f-cdb7-46a5-a375-a8d4aa5616e4@github.com>

On Tue, 23 Feb 2021 07:44:58 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
>> @Benchmark
>> public void testMethod(Blackhole bh) {
>>   int sum = 0;
>>   for (int i = 0; i < data.length; i++) {
>>       Integer ii = Integer.valueOf(data[i]);
>>       if (i < data.length) {
>>           sum += ii.intValue();
>>       }
>>   }
>>   bh.consume(sum);
>> }
>> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
>> The uncommon_trap is generated by the optimized "if", because its condition is always true.
>> 
>> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
>> and deleting the use of box:
>> 
>> There is no additional fail/error(s) of jtreg after this patch.
>> 
>> I adjust my codes and add a new benchmark
>> 
>> public class MyBenchmark {
>> 
>>     static int[] data = new int[10000];
>> 
>>     static {
>>         for(int i = 0; i < data.length; ++i) {
>>             data[i] = i * 1337 % 7331;
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void testMethod(Blackhole bh) {
>>       int sum = 0;
>>       for (int i = 0; i < data.length; i++) {
>>           Integer ii = Integer.valueOf(data[i]);
>>           black();
>>           if (i < 100000) {
>>               sum += ii.intValue();
>>           }
>>       }
>>       bh.consume(sum);
>>     }
>> 
>>     public void black(){}
>> }
>> 
>> 
>> aarch64:  
>> base line?
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  88.513        1.111  us/op
>> 
>> opt?
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  52.776        0.096  us/op
>> 
>> x86:  
>> base line?
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  81.066        3.156  us/op
>> 
>> opt:
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  55.596        0.775  us/op
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add debuginfo optimization

I agree with Vladimir that tests are needed. I've added some comments to the code.

src/hotspot/share/opto/callGenerator.cpp line 561:

> 559:   if (resproj != nullptr && call->is_CallStaticJava() &&
> 560:       call->as_CallStaticJava()->is_boxing_method()) {
> 561:     Unique_Node_List debuginfo_node_list;

Maybe rename this to `safepoints`.

src/hotspot/share/opto/callGenerator.cpp line 569:

> 567:         for (uint i = 0; i < dbg_start; i++) {
> 568:           if (sfpt->in(i) == resproj) {
> 569:             return;

I think this code can be replaced by:
  if (!sfpt->is_Call() || !sfpt->as_Call()->has_non_debug_use(n)) {
    safepoints.push(sfpt);
  } else {
    ...
  }

src/hotspot/share/opto/callGenerator.cpp line 587:

> 585:       ciInstanceKlass* klass = call->as_CallStaticJava()->method()->holder();
> 586:       int n_fields = klass->nof_nonstatic_fields();
> 587:       assert(n_fields == 1, "the klass must be an auto-boxing klass");

This code can be put in `ifdef ASSERT` and `n_fields` below can be replaced by 1.

src/hotspot/share/opto/callGenerator.cpp line 656:

> 654:   }
> 655: 
> 656:   replace_box_to_scalar(call, callprojs.resproj);

Should this be guarded by `C->eliminate_boxing()`?

src/hotspot/share/opto/callnode.hpp line 503:

> 501:                      // It is relative to the last (youngest) jvms->_scloff.
> 502:   uint _n_fields;    // Number of non-static fields of the scalarized object.
> 503:   bool _is_auto_box; // is the scalarized object is auto box.

Typo in comment. Should be something like `// True if the scalarized object is an auto box`

src/hotspot/share/opto/callGenerator.cpp line 583:

> 581:     while (debuginfo_node_list.size() > 0) {
> 582:       ProjNode* res = resproj->as_Proj();
> 583:       Node* debuginfo_node = debuginfo_node_list.pop();

`debuginfo_node` -> `safepoint`

src/hotspot/share/opto/callGenerator.cpp line 596:

> 594:                                                   first_ind, n_fields, true);
> 595:       sobj->init_req(0, kit.root());
> 596:       debuginfo_node->add_req(call->in(res->_con));

I don't understand why you are selecting the input based on the result projection field `res->_con`?

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

Changes requested by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2401

From dongbo at openjdk.java.net  Wed Feb 24 07:33:40 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 24 Feb 2021 07:33:40 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v10]
In-Reply-To: <BlOlxuz8EYot1Utx13ETlVqmsVG-L5BNzAROHFTq8hA=.330113a8-fd0f-495b-925b-f14bf750aa43@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
 <z_gVJyVbmos-6bUwGeSGWhqFz4Iku6ghuBC4CqE1ql4=.5cf04e1f-03b5-4b59-9b01-9db2e0082dde@github.com>
 <BlOlxuz8EYot1Utx13ETlVqmsVG-L5BNzAROHFTq8hA=.330113a8-fd0f-495b-925b-f14bf750aa43@github.com>
Message-ID: <G61s0RHBJaH52Nt11W3l870l4BW_86OETpSmZAX3uWg=.66e1ba1b-0de6-462d-9c7d-4acd9e3b34b4@github.com>

On Tue, 23 Feb 2021 17:13:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Local tests by manually injected error shows all instructions are covered by the jtreg case. Suggestions?
> 
> I'm not seeing `sra` used anywhere.
> 
> The problem I see with the tests is that the methods are large. This causes C2 to do a lot of spilling. Also, because the resuling code is intertwined and complex, it's very hard to debug.
> 
> It would be far better to do something like this:
> 
> ```
>     void long_shift_add(long arrLongs[][], LongVector vba, LongVector vbb, int i) {
>         vba.add(vbb.lanewise(VectorOperators.LSHR, 37)).intoArray(arrLongs[op], 2 * i);
>         vba.add(vbb.lanewise(VectorOperators.LSHR, 64)).intoArray(arrLongs[op  + 1], 2 * i);
>         vba.add(vbb.lanewise(VectorOperators.LSHR, 99)).intoArray(arrLongs[op  + 2], 2 * i);
>         vba.add(vbb.lanewise(VectorOperators.LSHR, 128)).intoArray(arrLongs[op + 3], 2 * i);
>         vba.add(vbb.lanewise(VectorOperators.LSHR, 157)).intoArray(arrLongs[op + 4], 2 * i);
>         vba.add(vbb.lanewise(VectorOperators.LSHR, 192)).intoArray(arrLongs[op + 5], 2 * i);
>     }
> ```


Weird, I took a look at the the assembly, `ssra` did accessed by the tests on our server:
$ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 64 &> assembly_vlen64.txt
$ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 128 &> assembly_vlen128.txt
$ cat assembly_vlen*.txt | grep "ssra"
02c0    ssra    V18, V17, #37   # vector (2D)
02c8    ssra    V19, V17, #0    # vector (2D)
02d0    ssra    V20, V17, #35   # vector (2D)
0308    ssra    V18, V17, #29   # vector (2D)
0644    ssra    V18, V17, #37   # vector (2D)
064c    ssra    V19, V17, #0    # vector (2D)
0654    ssra    V20, V17, #35   # vector (2D)
0674    ssra    V18, V17, #29   # vector (2D)
0798    ssra    V18, V17, #37   # vector (2D)
07a0    ssra    V19, V17, #0    # vector (2D)
07a8    ssra    V20, V17, #35   # vector (2D)
07e0    ssra    V18, V17, #29   # vector (2D)
  0x0000ffff83f7e500:   ssra    v18.2d, v17.2d, #37         ;*aload_0 {reexecute=0 rethrow=0 return_oop=0}
  0x0000ffff83f7e510:   ssra    v20.2d, v17.2d, #35         ;*iand {reexecute=0 rethrow=0 return_oop=0}
  0x0000ffff83f7e548:   ssra    v18.2d, v17.2d, #29         ;*if_icmpne {reexecute=0 rethrow=0 return_oop=0}
  0x0000ffff83f7e884:   ssra    v18.2d, v17.2d, #37
  0x0000ffff83f7e894:   ssra    v20.2d, v17.2d, #35
  0x0000ffff83f7e8b4:   ssra    v18.2d, v17.2d, #29
  0x0000ffff83f7e9d8:   ssra    v18.2d, v17.2d, #37         ;*invokestatic broadcastInt {reexecute=0 rethrow=0 return_oop=0}
  0x0000ffff83f7e9e8:   ssra    v20.2d, v17.2d, #35         ;*invokestatic broadcastInt {reexecute=0 rethrow=0 return_oop=0}
  0x0000ffff83f7ea20:   ssra    v18.2d, v17.2d, #29         ;*checkcast {reexecute=0 rethrow=0 return_oop=0}
284     ssra    V18, V17, #9    # vector (4S)
28c     ssra    V19, V17, #0    # vector (4S)
294     ssra    V20, V17, #15   # vector (4S)
  0x0000ffff83f822c4:   ssra    v18.4s, v17.4s, #9          ;*invokedynamic {reexecute=0 rethrow=0 return_oop=0}
  0x0000ffff83f822d4:   ssra    v20.4s, v17.4s, #15
284     ssra    V18, V17, #1    # vector (8H)
28c     ssra    V19, V17, #8    # vector (8H)
...

Also injected error to `sshr+add` by:
--- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
+++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
@@ -545,7 +545,7 @@ public:
 #define WRAP(INSN)                                                                \
   void INSN(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn, int shift) {  \
     if (shift == 0) {                                                             \
-      Assembler::addv(Vd, T, Vd, Vn);                                             \
+      Assembler::subv(Vd, T, Vd, Vn);                                             \
     } else {                                                                      \
       Assembler::INSN(Vd, T, Vn, shift);                                          \
     }                                                                             \
The `shift+add` tests failed as expected:
$ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:-TieredCompilation test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 64
WARNING: Using incubator modules: jdk.incubator.vector
warning: using incubating module(s): jdk.incubator.vector
1 warning
Exception in thread "main" java.lang.RuntimeException: Test Failed, failed tests:
type SHORT index 19, operation ASHR_AND_ACCUMULATE, vector length 64.
type SHORT index 21, operation ASHR_AND_ACCUMULATE, vector length 64.
type SHORT index 23, operation ASHR_AND_ACCUMULATE, vector length 64.
type SHORT index 25, operation LSHR_AND_ACCUMULATE, vector length 64.
type SHORT index 27, operation LSHR_AND_ACCUMULATE, vector length 64.
type SHORT index 29, operation LSHR_AND_ACCUMULATE, vector length 64.
type INTEGER index 19, operation ASHR_AND_ACCUMULATE, vector length 64.
type INTEGER index 21, operation ASHR_AND_ACCUMULATE, vector length 64.
type INTEGER index 23, operation ASHR_AND_ACCUMULATE, vector length 64.
type INTEGER index 25, operation LSHR_AND_ACCUMULATE, vector length 64.
type INTEGER index 27, operation LSHR_AND_ACCUMULATE, vector length 64.
type INTEGER index 29, operation LSHR_AND_ACCUMULATE, vector length 64.
...
$ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:-TieredCompilation test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 128
WARNING: Using incubator modules: jdk.incubator.vector
warning: using incubating module(s): jdk.incubator.vector
1 warning
Exception in thread "main" java.lang.RuntimeException: Test Failed, failed tests:
type LONG index 49, operation ASHR_AND_ACCUMULATE, vector length 128.
type LONG index 51, operation ASHR_AND_ACCUMULATE, vector length 128.
type LONG index 53, operation ASHR_AND_ACCUMULATE, vector length 128.
type LONG index 55, operation LSHR_AND_ACCUMULATE, vector length 128.
type LONG index 57, operation LSHR_AND_ACCUMULATE, vector length 128.
type LONG index 59, operation LSHR_AND_ACCUMULATE, vector length 128.
type SHORT index 49, operation ASHR_AND_ACCUMULATE, vector length 128.
type SHORT index 51, operation ASHR_AND_ACCUMULATE, vector length 128.
type SHORT index 53, operation ASHR_AND_ACCUMULATE, vector length 128.
...

Anyway, I extracted operations you suggested into `shift_op_*` methods.
Performed the error-injected experiments with the new tests on Kunpeng916 and re-checked the assembly output, results looks good.

The test command I used to run the newest tests are:
$ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:-TieredCompilation -XX:CompileThreshold=1000 -Dvlen=64 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java &> assembly_vlen64.txt
$ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:-TieredCompilation -XX:CompileThreshold=1000 -Dvlen=128 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java &> assembly_vlen128.txt
$ cat assembly_vlen64.txt | grep ssra; cat assembly_vlen128.txt | grep ssra

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From alanb at openjdk.java.net  Wed Feb 24 08:54:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 24 Feb 2021 08:54:42 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
Message-ID: <MBMi2I0sim_z4rs9I1ISl4XaYOe45pDb7u-TxJbQIQc=.0472c0a4-8776-4714-9628-3623ca3fdda2@github.com>

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 67:

> 65:     private final SinkChannel sink;
> 66: 
> 67:     private static class Initializer

This one is okay to do.

src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java line 51:

> 49:      * Represents a service provider in the services catalog.
> 50:      */
> 51:     public static final class ServiceProvider {

This one is okay to do.

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

PR: https://git.openjdk.java.net/jdk/pull/2589

From xliu at openjdk.java.net  Wed Feb 24 09:50:04 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 24 Feb 2021 09:50:04 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v8]
In-Reply-To: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
Message-ID: <OqWDff-G81UpwvWSjhd8RKX5KP97tMGqlC8cIfR2L0g=.894571ca-7f64-4678-9156-591322bde4be@github.com>

> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
> 
> Before:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
> - string: "a"
> :Constant:exact *
> 
> After:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
  
  add comments and hoist ResourceMark

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2178/files
  - new: https://git.openjdk.java.net/jdk/pull/2178/files/6df63fe1..aeff9ecc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=06-07

  Stats: 10 lines in 1 file changed: 1 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2178.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2178/head:pull/2178

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Wed Feb 24 09:50:06 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 24 Feb 2021 09:50:06 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v7]
In-Reply-To: <U93lV7GGLqRvTZh3KzIXNbGeB_YuAiTHYlrgI-VUB6c=.57682641-fab8-4f9e-8082-e047f2557dc4@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <W6ugHZBkrOsGnh9VzFYsnGl0-ElT0BAHw5QTfyBv1N0=.4c5d70ec-4403-4265-ad6a-6f9bf1ed57e7@github.com>
 <U93lV7GGLqRvTZh3KzIXNbGeB_YuAiTHYlrgI-VUB6c=.57682641-fab8-4f9e-8082-e047f2557dc4@github.com>
Message-ID: <8TpdqWzAgwVycyBRzDWioTkDyoQ56DjsSmlaSf6Aqu0=.dd797e69-fed2-42ba-b2e6-22de2e83312d@github.com>

On Wed, 24 Feb 2021 06:50:51 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>>   
>>   use the existing api StringUtils::replace_no_expand to archive the same replace.
>>   don't need to invoke os::strdup because stringStream::as_string() has duplicated
>>   the internal buffer.
>
> src/hotspot/share/opto/type.cpp line 4052:
> 
>> 4050: 
>> 4051:       {
>> 4052:         ResourceMark rm;
> 
> Shouldn't the `ResourceMark` go to before `stringStream ss` which is a `ResourceObj` as well? Also, please add a small comment explaining that this code suppresses the new line emitted by `print_oop`.

hi, @TobiHartmann 
Thank you for reviewing this PR. 

stringStream allocates its dynamic buffer using `NEW_C_HEAP_ARRAY`.  IMHO, it's okay without a ResourceMark. 
Unlike `stringStream::grow`, stringStream::as_string(false) does use `NEW_RESOURCE_ARRAY`, which allocates an array on current thread's resource_area. That's why I put ResourceMark in a syntax scope. 

Actually, the current code still works even without that ResourceMark. It's because `Type::dump_on()` has  declared a rm. Let me hoist ResourceMark as you said. That makes code straight-forward locally and I shouldn't assume its context.

> src/hotspot/share/opto/type.cpp line 4040:
> 
>> 4038: // Dump oop Type
>> 4039: #ifndef PRODUCT
>> 4040: void TypeInstPtr::dump2( Dict &d, uint depth, outputStream* st ) const {
> 
> While you are at it, please also remove the excess whitespace after `(` and before `)`.

done.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From github.com+10482586+therealeliu at openjdk.java.net  Wed Feb 24 09:52:43 2021
From: github.com+10482586+therealeliu at openjdk.java.net (Eric Liu)
Date: Wed, 24 Feb 2021 09:52:43 GMT
Subject: Integrated: 8256438: AArch64: Implement match rules with ROR shift
 register value
In-Reply-To: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
References: <IokfVGmBVxZ4DMVVxTgmDnV9hD8F3NmjICpdpFH4Zyw=.cd97c23f-f84b-402a-87d4-3b19da1bcf60@github.com>
Message-ID: <4-4Q7-eJ3buKNVIYzCDip8NbTuAizZrw4RiB625P63E=.dd8a578b-a802-42c2-afb2-f13ac47a7ee3@github.com>

On Mon, 21 Dec 2020 10:10:10 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

> This patch transforms '(x >>> rshift) + (x << lshift)' into
> 'RotateRight(x, rshift)' during GVN phase when both the shift exponents
> are constants and their sum equals to the number of bits for the type
> of shift base.
> 
> This patch implements some new match rules for AArch64 instructions
> which can take ROR as the optional shift. Such instructions are 'and',
> 'or', 'eor', 'eon', 'bic' and 'orn'.
> 
>   ror     w11, w2, #5
>   eor     w0, w1, w11
> 
> With this patch, above code could be optimized to below:
> 
>   eor     w0, w1, w2, ror #5
> 
> Finally, the patch refactors TestRotate.java[1][2].
> 
> Tested jtreg TestRotate.java, hotspot::hotspot_all_no_apps,
> jdk::jdk_core, langtools::tier1.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8252776
> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039911.html

This pull request has now been integrated.

Changeset: 382e38dd
Author:    Eric Liu <eric.c.liu at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/382e38dd
Stats:     1067 lines in 5 files changed: 742 ins; 24 del; 301 mod

8256438: AArch64: Implement match rules with ROR shift register value

Reviewed-by: aph, roland

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

PR: https://git.openjdk.java.net/jdk/pull/1858

From thartmann at openjdk.java.net  Wed Feb 24 10:08:41 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 24 Feb 2021 10:08:41 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v8]
In-Reply-To: <OqWDff-G81UpwvWSjhd8RKX5KP97tMGqlC8cIfR2L0g=.894571ca-7f64-4678-9156-591322bde4be@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <OqWDff-G81UpwvWSjhd8RKX5KP97tMGqlC8cIfR2L0g=.894571ca-7f64-4678-9156-591322bde4be@github.com>
Message-ID: <3aukTZwD74tFD4GptC7mbqAnVCghVEK0PJJiz88opXI=.59055500-e950-4744-84c5-a4fd3695a858@github.com>

On Wed, 24 Feb 2021 09:50:04 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
>> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
>> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
>> 
>> Before:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
>> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
>> - string: "a"
>> :Constant:exact *
>> 
>> After:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>   
>   add comments and hoist ResourceMark

That looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2178

From aph at redhat.com  Wed Feb 24 10:55:04 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Feb 2021 10:55:04 +0000
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v10]
In-Reply-To: <G61s0RHBJaH52Nt11W3l870l4BW_86OETpSmZAX3uWg=.66e1ba1b-0de6-462d-9c7d-4acd9e3b34b4@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
 <z_gVJyVbmos-6bUwGeSGWhqFz4Iku6ghuBC4CqE1ql4=.5cf04e1f-03b5-4b59-9b01-9db2e0082dde@github.com>
 <BlOlxuz8EYot1Utx13ETlVqmsVG-L5BNzAROHFTq8hA=.330113a8-fd0f-495b-925b-f14bf750aa43@github.com>
 <G61s0RHBJaH52Nt11W3l870l4BW_86OETpSmZAX3uWg=.66e1ba1b-0de6-462d-9c7d-4acd9e3b34b4@github.com>
Message-ID: <3ff503da-bae1-45e3-fc29-06ff8c2bd8ff@redhat.com>

On 24/02/2021 07:33, Dong Bo wrote:
> Weird, I took a look at the the assembly, `ssra` did accessed by the tests on our server:

I don't doubt it, but the test code is so very complex that it can
fall foul of heuristics given slightly changed circumstances. That's
why good test cases are as simple as possible, and allow no room for
variations because they do only one thing. Precise targeting should
be the goal of HotSpot back-end test cases.

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


From github.com+42899633+eastig at openjdk.java.net  Wed Feb 24 12:13:43 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 24 Feb 2021 12:13:43 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v8]
In-Reply-To: <OqWDff-G81UpwvWSjhd8RKX5KP97tMGqlC8cIfR2L0g=.894571ca-7f64-4678-9156-591322bde4be@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <OqWDff-G81UpwvWSjhd8RKX5KP97tMGqlC8cIfR2L0g=.894571ca-7f64-4678-9156-591322bde4be@github.com>
Message-ID: <9QwSVEA-wKGBPSwUX0MSDAXGLLjCaSmLjtEyKshvdGI=.e9c410e8-5495-4ceb-affc-4590ebcd84d4@github.com>

On Wed, 24 Feb 2021 09:50:04 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
>> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
>> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
>> 
>> Before:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
>> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
>> - string: "a"
>> :Constant:exact *
>> 
>> After:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>   
>   add comments and hoist ResourceMark

Changes requested by eastig at github.com (no known OpenJDK username).

src/hotspot/share/opto/type.cpp line 4053:

> 4051:       const_oop()->print_oop(&ss);
> 4052:       // suppress new-lines('\n') in ss emitted by const_oop->print_oop()
> 4053:       // so each node is one-liner for -XX:+Verbose && -XX:+PrintIdeal

What about rewriting the comment in clearer way:
// 'const_oop->print_oop()' emits new-lines('\n') into ss.
// For -XX:+Verbose && -XX:+PrintIdeal, new-lines('\n') must be removed from
// the ss created string to have a node per line.

test/hotspot/gtest/utilities/test_ostream.cpp line 66:

> 64: 
> 65: static size_t count_char(const stringStream* ss, char ch) {
> 66:   return count_char(ss->as_string(), ss->size(), ch);

Am I correct `std:count` is not allowed?
No need to use `as_string`: `return count_char(ss->base(), ss->size(), ch);`
Or as `stringStream` is always zero-terminated: `return count_char(ss->base(), ch);`

test/hotspot/gtest/utilities/test_ostream.cpp line 72:

> 70:   ResourceMark rm;
> 71:   size_t whitespaces = count_char(ss, ' ');
> 72:   char* s2 = ss->as_string(false);

No need of `false` because `false` is the default value of `as_string`. If you want to be explicit here, I recommend: `char* s2 = ss->as_string(/* c_heap= */ false);`

test/hotspot/gtest/utilities/test_ostream.cpp line 63:

> 61:   }
> 62:   return cnt;
> 63: }

As the function is only used for zero-terminated strings, maybe it makes sense to use this property:
static size_t count_char(const char* s, char ch) {
   size_t cnt = 0;

   while (*s != '\0') {
      if (*s++ == ch) {
        ++cnt;
      }
   }
   return cnt;
}

test/hotspot/gtest/utilities/test_ostream.cpp line 69:

> 67: }
> 68: 
> 69: static void test_stringStream_tr_delete(stringStream* ss) {

I think this is a unit test for `StringUtils::replace_no_expand`. It checks that the function can be used to remove substrings. There is no dependency on `stringStream`. Any string can be used.
Could you please move the test to `test_stringUtils.cpp`?

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From thartmann at openjdk.java.net  Wed Feb 24 12:51:46 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 24 Feb 2021 12:51:46 GMT
Subject: RFR: 8262299: C2 compilation fails with "modified node was not
 processed by IGVN.transform_old()"
Message-ID: <sz17iaCL32d3qPjgs5q33b-OZufMoQez5HUZR850H3w=.d0d143ee-d0c5-4983-9a90-0a578b7c0d5d@github.com>

We hit an assert because a dead `MergeMemNode` was not removed. Make sure it's added to the IGVN worklist to give it a chance to be removed.

Thanks,
Tobias

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

Commit messages:
 - 8262299: C2 compilation fails with "modified node was not processed by IGVN.transform_old()"

Changes: https://git.openjdk.java.net/jdk/pull/2705/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2705&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262299
  Stats: 10 lines in 1 file changed: 6 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2705.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2705/head:pull/2705

PR: https://git.openjdk.java.net/jdk/pull/2705

From roland at openjdk.java.net  Wed Feb 24 12:56:39 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 24 Feb 2021 12:56:39 GMT
Subject: RFR: 8262299: C2 compilation fails with "modified node was not
 processed by IGVN.transform_old()"
In-Reply-To: <sz17iaCL32d3qPjgs5q33b-OZufMoQez5HUZR850H3w=.d0d143ee-d0c5-4983-9a90-0a578b7c0d5d@github.com>
References: <sz17iaCL32d3qPjgs5q33b-OZufMoQez5HUZR850H3w=.d0d143ee-d0c5-4983-9a90-0a578b7c0d5d@github.com>
Message-ID: <aDonBgqoNnZpGzKOxMCtguTsiDyxpwZ_NBA8iCpJQRU=.c3b49ee8-1a0d-4939-b316-db04a3408989@github.com>

On Wed, 24 Feb 2021 12:44:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We hit an assert because a dead `MergeMemNode` was not removed. Make sure it's added to the IGVN worklist to give it a chance to be removed.
> 
> Thanks,
> Tobias

Looks good to me

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

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2705

From zgu at openjdk.java.net  Wed Feb 24 12:57:39 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 24 Feb 2021 12:57:39 GMT
Subject: RFR: 8262259: Remove unused variable in
 MethodLiveness::BasicBlock::compute_gen_kill_single
In-Reply-To: <YTJWH1amQ97ZEqNkPq2QEIl5i4MEmVXIoPBlM_gwIy8=.738e28ef-5558-4977-bd70-92dd7b288aa7@github.com>
References: <jwFKB6FYb56zx0iN1k1dbBugs7XuRKQzM2mJonyx4vU=.be436da7-fea2-4f19-9c8b-1f676d642d3f@github.com>
 <YTJWH1amQ97ZEqNkPq2QEIl5i4MEmVXIoPBlM_gwIy8=.738e28ef-5558-4977-bd70-92dd7b288aa7@github.com>
Message-ID: <yK3t5RViR1eYuTe9TgElTa6WO1DeWXZmYpcU61KfwuE=.3eaf776a-a990-44a4-a415-14242bb0e1c1@github.com>

On Wed, 24 Feb 2021 04:56:39 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this trivial patch that removes unused/dead local variable.
>
> Seems fine and trivial.
> ..Thomas

Thanks, @tstuefe  @TobiHartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2698

From zgu at openjdk.java.net  Wed Feb 24 12:57:41 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 24 Feb 2021 12:57:41 GMT
Subject: Integrated: 8262259: Remove unused variable in
 MethodLiveness::BasicBlock::compute_gen_kill_single
In-Reply-To: <jwFKB6FYb56zx0iN1k1dbBugs7XuRKQzM2mJonyx4vU=.be436da7-fea2-4f19-9c8b-1f676d642d3f@github.com>
References: <jwFKB6FYb56zx0iN1k1dbBugs7XuRKQzM2mJonyx4vU=.be436da7-fea2-4f19-9c8b-1f676d642d3f@github.com>
Message-ID: <3r0uMCJEB8ZBnPX0FZLfu2M9RR1WlAyLmbkAHEcmijQ=.13c83fda-31a3-479f-afd2-7a38659ee4e5@github.com>

On Tue, 23 Feb 2021 21:52:31 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch that removes unused/dead local variable.

This pull request has now been integrated.

Changeset: 8c07063d
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8c07063d
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8262259: Remove unused variable in MethodLiveness::BasicBlock::compute_gen_kill_single

Reviewed-by: stuefe, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2698

From chagedorn at openjdk.java.net  Wed Feb 24 13:35:45 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 24 Feb 2021 13:35:45 GMT
Subject: RFR: 8262299: C2 compilation fails with "modified node was not
 processed by IGVN.transform_old()"
In-Reply-To: <sz17iaCL32d3qPjgs5q33b-OZufMoQez5HUZR850H3w=.d0d143ee-d0c5-4983-9a90-0a578b7c0d5d@github.com>
References: <sz17iaCL32d3qPjgs5q33b-OZufMoQez5HUZR850H3w=.d0d143ee-d0c5-4983-9a90-0a578b7c0d5d@github.com>
Message-ID: <Lv5_40maeXXQyAktYJlFb8S8HDdVLGnSy5a9I4JRC64=.99f02220-f088-41d1-a539-2c8a09e08640@github.com>

On Wed, 24 Feb 2021 12:44:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We hit an assert because a dead `MergeMemNode` was not removed. Make sure it's added to the IGVN worklist to give it a chance to be removed.
> 
> Thanks,
> Tobias

Looks good.

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2705

From roland at openjdk.java.net  Wed Feb 24 14:59:46 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 24 Feb 2021 14:59:46 GMT
Subject: RFR: 8261308: C2: assert(inner->is_valid_counted_loop(T_INT) &&
 inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
In-Reply-To: <wcwypSAxvdGZ_P01UMfM7Xhvc0MMxXN5GTVHov2rxBg=.e3f54355-bfcf-430f-868f-d6f0aef5c82a@github.com>
References: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
 <wcwypSAxvdGZ_P01UMfM7Xhvc0MMxXN5GTVHov2rxBg=.e3f54355-bfcf-430f-868f-d6f0aef5c82a@github.com>
Message-ID: <zB7rBSAxwVK87cUlApL56X-ytP31Hx1r5qqOMI8FZhQ=.dba92af8-145b-4581-8603-c2ed310d1bb7@github.com>

On Tue, 23 Feb 2021 19:13:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The inner counted loop of the test case starts at 1 and stops at 1 so
>> runs for one iteration. A counted loop is created for it. The iv Phi
>> is found to be the constant 1 and its type is set by:
>> 
>> l->phi()->as_Phi()->set_type(l->phi()->Value(&_igvn));
>> 
>> in PhaseIdealLoop::is_counted_loop() but it's not replaced by the
>> constant 1 yet so the counted loop's shape is preserved.
>> 
>> IdealLoopTree::do_one_iteration_loop() runs but doesn't optimize the
>> loop because the trip count is not set to 1. The loop contains a range
>> check and range check elimination is applied. That causes the loop
>> exit test to be adjusted with a MinI(..) expression. When IGVN runs
>> next, the phi is replaced with 1 but because the exit test was
>> changed, IGVN can't prove it always fails. So the loop is not removed
>> which causes the assert failure as loop opts progress.
>> 
>> The fix I propose is for IdealLoopTree::do_one_iteration_loop() to
>> remove the 1 iteration loop. The reason it doesn't happen is that
>> IdealLoopTree::compute_trip_count() doesn't set the trip count because
>> it finds a zero trip count: limit - init = 1 - 1 = 0. All loops, once
>> entered execute at least once. So I think, it's safe to set the trip
>> count to 1 in those cases.
>
> src/hotspot/share/opto/loopTransform.cpp line 126:
> 
>> 124:     jlong limit_con = (stride_con > 0) ? limit_type->_hi : limit_type->_lo;
>> 125:     int stride_m = stride_con - (stride_con > 0 ? 1 : -1);
>> 126:     jlong trip_count = (limit_con - init_con + stride_m)/stride_con;
> 
> Does it mean that before we execute do_one_iteration_loop() optimization for loops which do 2 trips?
> This seems wrong. Can you check?
> I agree that loop body executed at least once since it is exit check. But it means we have to generally adjust `trip_count` with `+1` and not do what you suggested.

Thanks for the comments.
A CountedLoopNode/CountedLoopEndNode is this in pseudo code:
int i = init;
do {
  i += stride;
} while (i < limit);
for stride > 0
We always enter the loop body so execute it at least once.
If limit > init, it's executed: (limit - init) / stride times if (limit - init) is a multiple of stride. 
if (limit - init) is not a multiple of stride then it's executed (limit - init) / stride + 1.
That matches the formula in the source code AFAICT.
In what case do you think we compute 1 for the trip count when it's actually 2?
How would you compute the trip count?

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

PR: https://git.openjdk.java.net/jdk/pull/2529

From thartmann at openjdk.java.net  Wed Feb 24 15:25:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 24 Feb 2021 15:25:39 GMT
Subject: RFR: 8262299: C2 compilation fails with "modified node was not
 processed by IGVN.transform_old()"
In-Reply-To: <Lv5_40maeXXQyAktYJlFb8S8HDdVLGnSy5a9I4JRC64=.99f02220-f088-41d1-a539-2c8a09e08640@github.com>
References: <sz17iaCL32d3qPjgs5q33b-OZufMoQez5HUZR850H3w=.d0d143ee-d0c5-4983-9a90-0a578b7c0d5d@github.com>
 <Lv5_40maeXXQyAktYJlFb8S8HDdVLGnSy5a9I4JRC64=.99f02220-f088-41d1-a539-2c8a09e08640@github.com>
Message-ID: <lG8Sh0afH33ab_Y_lESxceW-HMzA1Pc4GE5ewC1OSzI=.efabfc44-b8d2-4b80-987c-bedfa4ee9ad1@github.com>

On Wed, 24 Feb 2021 13:33:19 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> We hit an assert because a dead `MergeMemNode` was not removed. Make sure it's added to the IGVN worklist to give it a chance to be removed.
>> 
>> Thanks,
>> Tobias
>
> Looks good.

Roland, Christian, thanks for the reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/2705

From roland at openjdk.java.net  Wed Feb 24 15:26:54 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 24 Feb 2021 15:26:54 GMT
Subject: RFR: 8261914: IfNode::fold_compares_helper faces non-canonicalized
 bool when running JRuby JSON workload
Message-ID: <kN1wCpfeU-SQPUKtOEQL3t-e12ufqO_i2_W5znZcBFE=.027796bc-ba6d-450d-8bbd-4a93c556cb5e@github.com>

The assert fires because the current IfNode's condition was not
canonicalized when it's being folded with a dominating
IfNode. idealize_test() should have taken care of that because it
executed before fold_compares() but it didn't because:

  Node* new_b = phase->transform( new BoolNode(b->in(1), bt.negate()) );
  if( !new_b->is_Bool() ) return NULL;

caused it to bail out. new_b is a constant. This happens because of
the order in which nodes are processed by IGVN. The If's current Bool
would also constant fold but it's in the IGVN worklist and hasn't been
processed yet.

The fix I propose is to keep Aleksey's defensive fix but to check that
the Bool input is indeed about to be transformed by IGVN and that that
would cause the IfNode to be reprocessed.

I tried to write a test case but didn't succeed. The 2 If nodes come
from a tableswitch that's transformed into a series of If based on
profile data. I couldn't reproduce the profile data with a simple test
case.

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

Commit messages:
 - fix

Changes: https://git.openjdk.java.net/jdk/pull/2707/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2707&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261914
  Stats: 9 lines in 1 file changed: 3 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2707.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2707/head:pull/2707

PR: https://git.openjdk.java.net/jdk/pull/2707

From roland at openjdk.java.net  Wed Feb 24 16:06:05 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 24 Feb 2021 16:06:05 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v3]
In-Reply-To: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
Message-ID: <f1YSTwd74-2f6BnJc0zXMhfgyHpxzgrT5DNQb94iQTQ=.249eb37d-1adb-463e-8b46-b32d7173ccef@github.com>

> We spotted this issue with Shenandoah and I managed to write a simple
> test case that reproduces it reliably with Shenandoah but the issue is
> independent of the GC.
> 
> The loop in the test case calls a native invoker with an oop live in
> rbp. rbp is saved in the native invoker stub's frame. A safepoint is
> triggered from the safepoint check in the native invoker. The stack
> walking code sees that rbp contains an oop but can't find where that
> oop is stored. That's because stack walking updates the caller's frame
> with the location of rbp in the callee on calls to
> frame::sender(). But the current code sets the last java frame to be
> the compiled frame where rbp is live. So there's no call to
> frame::sender() to update the location rbp. The fix I propose is that
> the frame of the native invoker be visible by stack walking. On a
> safepoint, stack walking starts from the native invoker thread, then
> calls frame::sender() to move to the compiled frame. That causes rbp
> to be properly recorded with its location in the native invoker frame.
> 
> Same problem affects both x86 and aarch64. I've tested this patch with:
> 
> make run-test TEST="java/foreign" TEST_VM_OPTS="-Xcomp" JTREG="TIMEOUT_FACTOR=10"
> 
> on both platforms.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - improved test
 - cleanup
 - Merge branch 'master' into JDK-8259937
 - test & debug
 - broken build
 - whitespaces
 - fix & test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2528/files
  - new: https://git.openjdk.java.net/jdk/pull/2528/files/5b9dfff7..cef05b6f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2528&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2528&range=01-02

  Stats: 18656 lines in 546 files changed: 11988 ins; 3826 del; 2842 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2528.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2528/head:pull/2528

PR: https://git.openjdk.java.net/jdk/pull/2528

From roland at openjdk.java.net  Wed Feb 24 16:13:00 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 24 Feb 2021 16:13:00 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v2]
In-Reply-To: <6NJDW9Yzgj-U0tRiPS1dscN7i3E27kdKuUDdREMA8lo=.81cd0ead-af88-4af3-bcf3-6025cff8f855@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
 <W2n7gPVdLqZO4VRuhl8Eysyv-5GYBy04joFl3pFGt6U=.cb50513b-e5b4-47e5-b2da-d182f05f3238@github.com>
 <6NJDW9Yzgj-U0tRiPS1dscN7i3E27kdKuUDdREMA8lo=.81cd0ead-af88-4af3-bcf3-6025cff8f855@github.com>
Message-ID: <uO6XtWh2W7IyoF-LbI2_KXPTgcBqvzssxnlpxG2ylys=.8de52b01-0d59-42eb-8fb6-b6c7ac054d6e@github.com>

On Tue, 23 Feb 2021 12:59:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   broken build
>
> LGTM, but I've left some suggestions in line.
> 
> Thanks for cleaning up the frame layout code. Having a fixed frame is much better than repeatedly modifying the stack pointer.
> 
> I've also done some downstream stress testing with jextract, and everything works as expected.

@JornVernee thanks for the review and the comments. The new commits should address them (cb9dd24 was pushed by accident and reverted).

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

PR: https://git.openjdk.java.net/jdk/pull/2528

From roland at openjdk.java.net  Wed Feb 24 16:12:59 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 24 Feb 2021 16:12:59 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v4]
In-Reply-To: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
Message-ID: <5M1DPgw-V-j9acOvHLewPoTaxF-a6-9HMIpIzHjqavU=.55831da6-f888-4dc0-beee-19869c5eb638@github.com>

> We spotted this issue with Shenandoah and I managed to write a simple
> test case that reproduces it reliably with Shenandoah but the issue is
> independent of the GC.
> 
> The loop in the test case calls a native invoker with an oop live in
> rbp. rbp is saved in the native invoker stub's frame. A safepoint is
> triggered from the safepoint check in the native invoker. The stack
> walking code sees that rbp contains an oop but can't find where that
> oop is stored. That's because stack walking updates the caller's frame
> with the location of rbp in the callee on calls to
> frame::sender(). But the current code sets the last java frame to be
> the compiled frame where rbp is live. So there's no call to
> frame::sender() to update the location rbp. The fix I propose is that
> the frame of the native invoker be visible by stack walking. On a
> safepoint, stack walking starts from the native invoker thread, then
> calls frame::sender() to move to the compiled frame. That causes rbp
> to be properly recorded with its location in the native invoker frame.
> 
> Same problem affects both x86 and aarch64. I've tested this patch with:
> 
> make run-test TEST="java/foreign" TEST_VM_OPTS="-Xcomp" JTREG="TIMEOUT_FACTOR=10"
> 
> on both platforms.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  Revert "test & debug"
  
  This reverts commit cb9dd24c9fcccc6997e9fca874e2860f966b9576.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2528/files
  - new: https://git.openjdk.java.net/jdk/pull/2528/files/cef05b6f..9f80616f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2528&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2528&range=02-03

  Stats: 72 lines in 1 file changed: 0 ins; 72 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2528.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2528/head:pull/2528

PR: https://git.openjdk.java.net/jdk/pull/2528

From kvn at openjdk.java.net  Wed Feb 24 18:13:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 24 Feb 2021 18:13:38 GMT
Subject: RFR: 8261914: IfNode::fold_compares_helper faces
 non-canonicalized bool when running JRuby JSON workload
In-Reply-To: <kN1wCpfeU-SQPUKtOEQL3t-e12ufqO_i2_W5znZcBFE=.027796bc-ba6d-450d-8bbd-4a93c556cb5e@github.com>
References: <kN1wCpfeU-SQPUKtOEQL3t-e12ufqO_i2_W5znZcBFE=.027796bc-ba6d-450d-8bbd-4a93c556cb5e@github.com>
Message-ID: <bWLQVI-kgPiGk-z9A1k_kYv6dezVy_QqvUHJMgLoMf0=.03273322-b028-406f-8586-87fcd83ae9d6@github.com>

On Wed, 24 Feb 2021 15:22:26 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The assert fires because the current IfNode's condition was not
> canonicalized when it's being folded with a dominating
> IfNode. idealize_test() should have taken care of that because it
> executed before fold_compares() but it didn't because:
> 
>   Node* new_b = phase->transform( new BoolNode(b->in(1), bt.negate()) );
>   if( !new_b->is_Bool() ) return NULL;
> 
> caused it to bail out. new_b is a constant. This happens because of
> the order in which nodes are processed by IGVN. The If's current Bool
> would also constant fold but it's in the IGVN worklist and hasn't been
> processed yet.
> 
> The fix I propose is to keep Aleksey's defensive fix but to check that
> the Bool input is indeed about to be transformed by IGVN and that that
> would cause the IfNode to be reprocessed.
> 
> I tried to write a test case but didn't succeed. The 2 If nodes come
> from a tableswitch that's transformed into a series of If based on
> profile data. I couldn't reproduce the profile data with a simple test
> case.

okay

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2707

From kvn at openjdk.java.net  Wed Feb 24 19:35:47 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 24 Feb 2021 19:35:47 GMT
Subject: RFR: 8261308: C2: assert(inner->is_valid_counted_loop(T_INT) &&
 inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
In-Reply-To: <zB7rBSAxwVK87cUlApL56X-ytP31Hx1r5qqOMI8FZhQ=.dba92af8-145b-4581-8603-c2ed310d1bb7@github.com>
References: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
 <wcwypSAxvdGZ_P01UMfM7Xhvc0MMxXN5GTVHov2rxBg=.e3f54355-bfcf-430f-868f-d6f0aef5c82a@github.com>
 <zB7rBSAxwVK87cUlApL56X-ytP31Hx1r5qqOMI8FZhQ=.dba92af8-145b-4581-8603-c2ed310d1bb7@github.com>
Message-ID: <3QstFQo1-rnl899oN0deMIsmsV1g1DVZyf0_C5iijc4=.416e32d0-9e04-4e2f-b9c6-ea337efbdf39@github.com>

On Wed, 24 Feb 2021 14:57:15 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/hotspot/share/opto/loopTransform.cpp line 126:
>> 
>>> 124:     jlong limit_con = (stride_con > 0) ? limit_type->_hi : limit_type->_lo;
>>> 125:     int stride_m = stride_con - (stride_con > 0 ? 1 : -1);
>>> 126:     jlong trip_count = (limit_con - init_con + stride_m)/stride_con;
>> 
>> Does it mean that before we execute do_one_iteration_loop() optimization for loops which do 2 trips?
>> This seems wrong. Can you check?
>> I agree that loop body executed at least once since it is exit check. But it means we have to generally adjust `trip_count` with `+1` and not do what you suggested.
>
> Thanks for the comments.
> A CountedLoopNode/CountedLoopEndNode is this in pseudo code:
> int i = init;
> do {
>   i += stride;
> } while (i < limit);
> for stride > 0
> We always enter the loop body so execute it at least once.
> If limit > init, it's executed: (limit - init) / stride times if (limit - init) is a multiple of stride. 
> if (limit - init) is not a multiple of stride then it's executed (limit - init) / stride + 1.
> That matches the formula in the source code AFAICT.
> In what case do you think we compute 1 for the trip count when it's actually 2?
> How would you compute the trip count?

I looked on history and before your 8256655 changes we did not create counted loop for such case:
https://github.com/openjdk/jdk/blob/f504f419d3b377f0ccfd458026a2b57a9704bdff/src/hotspot/share/opto/loopnode.cpp#L1376
That is why we did not hit this issue before. After 8256655 we allow counted loops with `init >= limit`. Got it.

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

PR: https://git.openjdk.java.net/jdk/pull/2529

From kvn at openjdk.java.net  Wed Feb 24 19:45:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 24 Feb 2021 19:45:40 GMT
Subject: RFR: 8261308: C2: assert(inner->is_valid_counted_loop(T_INT) &&
 inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
In-Reply-To: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
References: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
Message-ID: <axZ4LSZiOvS12SeEfK7bmjb2wtW5H5EtxSulqyPAXFY=.ebf5a7a6-f0cb-4976-8b37-dc67f3687a15@github.com>

On Thu, 11 Feb 2021 16:11:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The inner counted loop of the test case starts at 1 and stops at 1 so
> runs for one iteration. A counted loop is created for it. The iv Phi
> is found to be the constant 1 and its type is set by:
> 
> l->phi()->as_Phi()->set_type(l->phi()->Value(&_igvn));
> 
> in PhaseIdealLoop::is_counted_loop() but it's not replaced by the
> constant 1 yet so the counted loop's shape is preserved.
> 
> IdealLoopTree::do_one_iteration_loop() runs but doesn't optimize the
> loop because the trip count is not set to 1. The loop contains a range
> check and range check elimination is applied. That causes the loop
> exit test to be adjusted with a MinI(..) expression. When IGVN runs
> next, the phi is replaced with 1 but because the exit test was
> changed, IGVN can't prove it always fails. So the loop is not removed
> which causes the assert failure as loop opts progress.
> 
> The fix I propose is for IdealLoopTree::do_one_iteration_loop() to
> remove the 1 iteration loop. The reason it doesn't happen is that
> IdealLoopTree::compute_trip_count() doesn't set the trip count because
> it finds a zero trip count: limit - init = 1 - 1 = 0. All loops, once
> entered execute at least once. So I think, it's safe to set the trip
> count to 1 in those cases.

src/hotspot/share/opto/loopTransform.cpp line 127:

> 125:     int stride_m = stride_con - (stride_con > 0 ? 1 : -1);
> 126:     jlong trip_count = (limit_con - init_con + stride_m)/stride_con;
> 127:     trip_count = MAX2(trip_count, (jlong)1);

Add comment here explaining this case (one trip when init >= limit).

BTW, this optimization seems only works for INT iv loops and not LONG. Do you plan to implement for LONG?

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

PR: https://git.openjdk.java.net/jdk/pull/2529

From richard.reingruber at sap.com  Wed Feb 24 20:03:41 2021
From: richard.reingruber at sap.com (Reingruber, Richard)
Date: Wed, 24 Feb 2021 20:03:41 +0000
Subject: RFC: 8262295: C2: Out-of-Bounds Array Load from Clone Source
Message-ID: <AM0PR02MB4273AD4F499F52FA0416F7DA9B9F9@AM0PR02MB4273.eurprd02.prod.outlook.com>

Hi,

I've been working on a fix for

JDK-8262295: C2: Out-of-Bounds Array Load from Clone Source
https://bugs.openjdk.java.net/browse/JDK-8262295

Now I'm not sure if the fix I found (compile time range check) is a good one.

I have created a draft PR with the fix not yet ready for proper review:

https://github.com/openjdk/jdk/pull/2708

Please let me know what you think and if this is the right approach.

My first attempt was to keep the original control for the cloned node in
LoadNode::can_see_arraycopy_value() but this seemd to confuse loop
optimizations. At least the test compiler/escapeAnalysis/TestMissingAntiDependency.java
failed with that change.

Another potential fix could be adding a runtime range check.

What do you think?

Thanks, Richard.

From jvernee at openjdk.java.net  Wed Feb 24 20:59:40 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 24 Feb 2021 20:59:40 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v4]
In-Reply-To: <5M1DPgw-V-j9acOvHLewPoTaxF-a6-9HMIpIzHjqavU=.55831da6-f888-4dc0-beee-19869c5eb638@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
 <5M1DPgw-V-j9acOvHLewPoTaxF-a6-9HMIpIzHjqavU=.55831da6-f888-4dc0-beee-19869c5eb638@github.com>
Message-ID: <NxLAxfTal2oKzbLe--PSJlA_3vGKR1TK5pS8dH5JMLc=.482881ea-0f16-4c33-b475-1d626e0e4939@github.com>

On Wed, 24 Feb 2021 16:12:59 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> We spotted this issue with Shenandoah and I managed to write a simple
>> test case that reproduces it reliably with Shenandoah but the issue is
>> independent of the GC.
>> 
>> The loop in the test case calls a native invoker with an oop live in
>> rbp. rbp is saved in the native invoker stub's frame. A safepoint is
>> triggered from the safepoint check in the native invoker. The stack
>> walking code sees that rbp contains an oop but can't find where that
>> oop is stored. That's because stack walking updates the caller's frame
>> with the location of rbp in the callee on calls to
>> frame::sender(). But the current code sets the last java frame to be
>> the compiled frame where rbp is live. So there's no call to
>> frame::sender() to update the location rbp. The fix I propose is that
>> the frame of the native invoker be visible by stack walking. On a
>> safepoint, stack walking starts from the native invoker thread, then
>> calls frame::sender() to move to the compiled frame. That causes rbp
>> to be properly recorded with its location in the native invoker frame.
>> 
>> Same problem affects both x86 and aarch64. I've tested this patch with:
>> 
>> make run-test TEST="java/foreign" TEST_VM_OPTS="-Xcomp" JTREG="TIMEOUT_FACTOR=10"
>> 
>> on both platforms.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "test & debug"
>   
>   This reverts commit cb9dd24c9fcccc6997e9fca874e2860f966b9576.

Thanks for addressing the comments! Looks good.

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

Marked as reviewed by jvernee (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2528

From github.com+16932759+shqking at openjdk.java.net  Thu Feb 25 01:24:56 2021
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Thu, 25 Feb 2021 01:24:56 GMT
Subject: RFR: 8257137: Revise smov and umov in aarch64 assembler [v3]
In-Reply-To: <aBE0Grc3Y0uclKhW-Sat4RtbvMJenZP2x9_7XbSOSLo=.5e76d0fb-c3ac-40b4-a31c-3a2e9ee28fa7@github.com>
References: <aBE0Grc3Y0uclKhW-Sat4RtbvMJenZP2x9_7XbSOSLo=.5e76d0fb-c3ac-40b4-a31c-3a2e9ee28fa7@github.com>
Message-ID: <42b0Skv5uZiAb7kKG3MutpokVFBM1Zf9vzM2A1no7MI=.9d345d82-519c-4a6a-8511-b8978e9d9fe1@github.com>

> 1. Both smov and umov lack of checking the register type validity.
>    Register type must be 'B', 'H' or 'S' for smov [1].
>    Register type can NOT be 'Q' for umov [2].
>    Such checks are added.
> 
> 2. smov and umov have different explanations on 'Q' field, i.e. bit 30
> of the insturction, but current assembler implementation mixed it up.
>    For umov, 'Q' field can only be set when register type 'D' is given
>    [2]. However, this field of smov must be set for register type 'S'
>    [1], that is, 'Q' field can be optional for register type 'B' or 'H'.
> 
>    Current implementation only took the umov scenario into account. As a
>    result, runtime error ILL_ILLOPN would occur if 'smov(Register,
> 		   FloatRegister, S, index)' is used.
> 
>    We put them into two separate functions and make 'Q' field always set
>    for smov. That means 'SMOVX' (64-bit register variant) is generated
>    for all cases since it's compatible with our current usages of 'SMOVW'.
>    Existing usages of smov have been double checked and this patch does
>    not affect them.
> 
> 3. Smoke tests are also added.
> 
> [1]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/smov-signed-move-vector-element-to-general-purpose-register
> [2]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/umov-unsigned-move-vector-element-to-general-purpose-register
> 
> 
> Note that Jtreg tier1 and jdk::tier3 have been tested and all tests passed without new failures.

Hao Sun has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into smov
   
   Temporally keep file test/hotspot/gtest/aarch64/asmtest.out.h same with
   branch mastger.
 - Update the copyright notice to 2021
   
   Update the copyright notice to 2021.
   
   Change-Id: I7fe485e768ccac45a4861cd3c061aedc13fef579
   CustomizedGitHooks: yes
 - 8257137: Revise smov and umov in aarch64 assembler.
   
   1. Both smov and umov lack of checking the register type validity.
      Register type must be 'B', 'H' or 'S' for smov [1].
      Register type can NOT be 'Q' for umov [2].
      Such checks are added.
   
   2. smov and umov have different explanations on 'Q' field, i.e. bit 30
   of the insturction, but current assembler implementation mixed it up.
      For umov, 'Q' field can only be set when register type 'D' is given
      [2]. However, this field of smov must be set for register type 'S'
      [1], that is, 'Q' field can be optional for register type 'B' or 'H'.
   
      Current implementation only took the umov scenario into account. As a
      result, runtime error ILL_ILLOPN would occur if 'smov(Register,
   		   FloatRegister, S, index)' is used.
   
      We put them into two separate functions and make 'Q' field always set
      for smov. That means 'SMOVX' (64-bit register variant) is generated
      for all cases since it's compatible with our current usages of 'SMOVW'.
      Existing usages of smov have been double checked and this patch does
      not affect them.
   
   3. Smoke tests are also added.
   
   [1]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/smov-signed-move-vector-element-to-general-purpose-register
   [2]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/umov-unsigned-move-vector-element-to-general-purpose-register

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

Changes: https://git.openjdk.java.net/jdk/pull/1586/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1586&range=02
  Stats: 29 lines in 3 files changed: 18 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1586.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1586/head:pull/1586

PR: https://git.openjdk.java.net/jdk/pull/1586

From github.com+16932759+shqking at openjdk.java.net  Thu Feb 25 01:27:52 2021
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Thu, 25 Feb 2021 01:27:52 GMT
Subject: RFR: 8257137: Revise smov and umov in aarch64 assembler [v4]
In-Reply-To: <aBE0Grc3Y0uclKhW-Sat4RtbvMJenZP2x9_7XbSOSLo=.5e76d0fb-c3ac-40b4-a31c-3a2e9ee28fa7@github.com>
References: <aBE0Grc3Y0uclKhW-Sat4RtbvMJenZP2x9_7XbSOSLo=.5e76d0fb-c3ac-40b4-a31c-3a2e9ee28fa7@github.com>
Message-ID: <KNtPuxkUmWubpLAjijuHZSL198M-JP7Hd36faBxy_No=.8c818a34-d860-4835-8770-be67913f6ccd@github.com>

> 1. Both smov and umov lack of checking the register type validity.
>    Register type must be 'B', 'H' or 'S' for smov [1].
>    Register type can NOT be 'Q' for umov [2].
>    Such checks are added.
> 
> 2. smov and umov have different explanations on 'Q' field, i.e. bit 30
> of the insturction, but current assembler implementation mixed it up.
>    For umov, 'Q' field can only be set when register type 'D' is given
>    [2]. However, this field of smov must be set for register type 'S'
>    [1], that is, 'Q' field can be optional for register type 'B' or 'H'.
> 
>    Current implementation only took the umov scenario into account. As a
>    result, runtime error ILL_ILLOPN would occur if 'smov(Register,
> 		   FloatRegister, S, index)' is used.
> 
>    We put them into two separate functions and make 'Q' field always set
>    for smov. That means 'SMOVX' (64-bit register variant) is generated
>    for all cases since it's compatible with our current usages of 'SMOVW'.
>    Existing usages of smov have been double checked and this patch does
>    not affect them.
> 
> 3. Smoke tests are also added.
> 
> [1]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/smov-signed-move-vector-element-to-general-purpose-register
> [2]. https://developer.arm.com/docs/ddi0602/f/simd-and-floating-point-instructions-alphabetic-order/umov-unsigned-move-vector-element-to-general-purpose-register
> 
> 
> Note that Jtreg tier1 and jdk::tier3 have been tested and all tests passed without new failures.

Hao Sun has updated the pull request incrementally with one additional commit since the last revision:

  Code style: add spaces between operands
  
  add spaces between operands

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1586/files
  - new: https://git.openjdk.java.net/jdk/pull/1586/files/ba69f500..b624a6b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1586&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1586&range=02-03

  Stats: 75 lines in 2 files changed: 2 ins; 0 del; 73 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1586.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1586/head:pull/1586

PR: https://git.openjdk.java.net/jdk/pull/1586

From dongbo at openjdk.java.net  Thu Feb 25 01:47:40 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 25 Feb 2021 01:47:40 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v10]
In-Reply-To: <G61s0RHBJaH52Nt11W3l870l4BW_86OETpSmZAX3uWg=.66e1ba1b-0de6-462d-9c7d-4acd9e3b34b4@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
 <z_gVJyVbmos-6bUwGeSGWhqFz4Iku6ghuBC4CqE1ql4=.5cf04e1f-03b5-4b59-9b01-9db2e0082dde@github.com>
 <BlOlxuz8EYot1Utx13ETlVqmsVG-L5BNzAROHFTq8hA=.330113a8-fd0f-495b-925b-f14bf750aa43@github.com>
 <G61s0RHBJaH52Nt11W3l870l4BW_86OETpSmZAX3uWg=.66e1ba1b-0de6-462d-9c7d-4acd9e3b34b4@github.com>
Message-ID: <9rtmEMrsPaA73FDA-KB7H0S0CRdBePGwnI5FcDY-OLI=.425249e2-b590-4a16-b9b8-8d7b5ecd2800@github.com>

On Wed, 24 Feb 2021 07:31:14 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>>> Hi, @theRealAph
>>> 
>>> I've rebased the tests so that sshr/ushr/sshl/ssra/usra are accessed in one jtreg `test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java`.
>>> Local tests by manually injected error shows all instructions are covered by the jtreg case. Suggestions?
>> 
>> I'm not seeing ```sra``` used anywhere.
>> 
>> The problem I see with the tests is that the methods are large. This causes C2 to do a lot of spilling. Also, because the resuling code is intertwined and complex, it's very hard to debug.
>> 
>> It would be far better to do something like this:
>>     void long_shift_add(long arrLongs[][], LongVector vba, LongVector vbb, int i) {
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 37)).intoArray(arrLongs[op], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 64)).intoArray(arrLongs[op  + 1], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 99)).intoArray(arrLongs[op  + 2], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 128)).intoArray(arrLongs[op + 3], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 157)).intoArray(arrLongs[op + 4], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 192)).intoArray(arrLongs[op + 5], 2 * i);
>>     }
>
>> > Local tests by manually injected error shows all instructions are covered by the jtreg case. Suggestions?
>> 
>> I'm not seeing `sra` used anywhere.
>> 
>> The problem I see with the tests is that the methods are large. This causes C2 to do a lot of spilling. Also, because the resuling code is intertwined and complex, it's very hard to debug.
>> 
>> It would be far better to do something like this:
>> 
>> ```
>>     void long_shift_add(long arrLongs[][], LongVector vba, LongVector vbb, int i) {
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 37)).intoArray(arrLongs[op], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 64)).intoArray(arrLongs[op  + 1], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 99)).intoArray(arrLongs[op  + 2], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 128)).intoArray(arrLongs[op + 3], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 157)).intoArray(arrLongs[op + 4], 2 * i);
>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 192)).intoArray(arrLongs[op + 5], 2 * i);
>>     }
>> ```
> 
> 
> Weird, I took a look at the the assembly, `ssra` did accessed by the tests on our server:
> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 64 &> assembly_vlen64.txt
> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 128 &> assembly_vlen128.txt
> $ cat assembly_vlen*.txt | grep "ssra"
> 02c0    ssra    V18, V17, #37   # vector (2D)
> 02c8    ssra    V19, V17, #0    # vector (2D)
> 02d0    ssra    V20, V17, #35   # vector (2D)
> 0308    ssra    V18, V17, #29   # vector (2D)
> 0644    ssra    V18, V17, #37   # vector (2D)
> 064c    ssra    V19, V17, #0    # vector (2D)
> 0654    ssra    V20, V17, #35   # vector (2D)
> 0674    ssra    V18, V17, #29   # vector (2D)
> 0798    ssra    V18, V17, #37   # vector (2D)
> 07a0    ssra    V19, V17, #0    # vector (2D)
> 07a8    ssra    V20, V17, #35   # vector (2D)
> 07e0    ssra    V18, V17, #29   # vector (2D)
>   0x0000ffff83f7e500:   ssra    v18.2d, v17.2d, #37         ;*aload_0 {reexecute=0 rethrow=0 return_oop=0}
>   0x0000ffff83f7e510:   ssra    v20.2d, v17.2d, #35         ;*iand {reexecute=0 rethrow=0 return_oop=0}
>   0x0000ffff83f7e548:   ssra    v18.2d, v17.2d, #29         ;*if_icmpne {reexecute=0 rethrow=0 return_oop=0}
>   0x0000ffff83f7e884:   ssra    v18.2d, v17.2d, #37
>   0x0000ffff83f7e894:   ssra    v20.2d, v17.2d, #35
>   0x0000ffff83f7e8b4:   ssra    v18.2d, v17.2d, #29
>   0x0000ffff83f7e9d8:   ssra    v18.2d, v17.2d, #37         ;*invokestatic broadcastInt {reexecute=0 rethrow=0 return_oop=0}
>   0x0000ffff83f7e9e8:   ssra    v20.2d, v17.2d, #35         ;*invokestatic broadcastInt {reexecute=0 rethrow=0 return_oop=0}
>   0x0000ffff83f7ea20:   ssra    v18.2d, v17.2d, #29         ;*checkcast {reexecute=0 rethrow=0 return_oop=0}
> 284     ssra    V18, V17, #9    # vector (4S)
> 28c     ssra    V19, V17, #0    # vector (4S)
> 294     ssra    V20, V17, #15   # vector (4S)
>   0x0000ffff83f822c4:   ssra    v18.4s, v17.4s, #9          ;*invokedynamic {reexecute=0 rethrow=0 return_oop=0}
>   0x0000ffff83f822d4:   ssra    v20.4s, v17.4s, #15
> 284     ssra    V18, V17, #1    # vector (8H)
> 28c     ssra    V19, V17, #8    # vector (8H)
> ...
> 
> Also injected error to `sshr+add` by:
> --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
> +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
> @@ -545,7 +545,7 @@ public:
>  #define WRAP(INSN)                                                                \
>    void INSN(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn, int shift) {  \
>      if (shift == 0) {                                                             \
> -      Assembler::addv(Vd, T, Vd, Vn);                                             \
> +      Assembler::subv(Vd, T, Vd, Vn);                                             \
>      } else {                                                                      \
>        Assembler::INSN(Vd, T, Vn, shift);                                          \
>      }                                                                             \
> The `shift+add` tests failed as expected:
> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:-TieredCompilation test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 64
> WARNING: Using incubator modules: jdk.incubator.vector
> warning: using incubating module(s): jdk.incubator.vector
> 1 warning
> Exception in thread "main" java.lang.RuntimeException: Test Failed, failed tests:
> type SHORT index 19, operation ASHR_AND_ACCUMULATE, vector length 64.
> type SHORT index 21, operation ASHR_AND_ACCUMULATE, vector length 64.
> type SHORT index 23, operation ASHR_AND_ACCUMULATE, vector length 64.
> type SHORT index 25, operation LSHR_AND_ACCUMULATE, vector length 64.
> type SHORT index 27, operation LSHR_AND_ACCUMULATE, vector length 64.
> type SHORT index 29, operation LSHR_AND_ACCUMULATE, vector length 64.
> type INTEGER index 19, operation ASHR_AND_ACCUMULATE, vector length 64.
> type INTEGER index 21, operation ASHR_AND_ACCUMULATE, vector length 64.
> type INTEGER index 23, operation ASHR_AND_ACCUMULATE, vector length 64.
> type INTEGER index 25, operation LSHR_AND_ACCUMULATE, vector length 64.
> type INTEGER index 27, operation LSHR_AND_ACCUMULATE, vector length 64.
> type INTEGER index 29, operation LSHR_AND_ACCUMULATE, vector length 64.
> ...
> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:-TieredCompilation test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 128
> WARNING: Using incubator modules: jdk.incubator.vector
> warning: using incubating module(s): jdk.incubator.vector
> 1 warning
> Exception in thread "main" java.lang.RuntimeException: Test Failed, failed tests:
> type LONG index 49, operation ASHR_AND_ACCUMULATE, vector length 128.
> type LONG index 51, operation ASHR_AND_ACCUMULATE, vector length 128.
> type LONG index 53, operation ASHR_AND_ACCUMULATE, vector length 128.
> type LONG index 55, operation LSHR_AND_ACCUMULATE, vector length 128.
> type LONG index 57, operation LSHR_AND_ACCUMULATE, vector length 128.
> type LONG index 59, operation LSHR_AND_ACCUMULATE, vector length 128.
> type SHORT index 49, operation ASHR_AND_ACCUMULATE, vector length 128.
> type SHORT index 51, operation ASHR_AND_ACCUMULATE, vector length 128.
> type SHORT index 53, operation ASHR_AND_ACCUMULATE, vector length 128.
> ...
> 
> Anyway, I extracted operations you suggested into `shift_op_*` methods.
> Performed the error-injected experiments with the new tests on Kunpeng916 and re-checked the assembly output, results looks good.
> 
> The test command I used to run the newest tests are:
> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:-TieredCompilation -XX:CompileThreshold=1000 -Dvlen=64 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java &> assembly_vlen64.txt
> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:-TieredCompilation -XX:CompileThreshold=1000 -Dvlen=128 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java &> assembly_vlen128.txt
> $ cat assembly_vlen64.txt | grep ssra; cat assembly_vlen128.txt | grep ssra

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-compiler-dev](mailto:hotspot-compiler-dev at openjdk.java.net):_
> 
> On 24/02/2021 07:33, Dong Bo wrote:
> 
> > Weird, I took a look at the the assembly, `ssra` did accessed by the tests on our server:
> 
> I don't doubt it, but the test code is so very complex that it can
> fall foul of heuristics given slightly changed circumstances. That's
> why good test cases are as simple as possible, and allow no room for
> variations because they do only one thing. Precise targeting should
> be the goal of HotSpot back-end test cases.
>
 
Understood, thanks. :-)
Does the newest version address the considerations?
I extracted the `shift`/`shift+add` operations into separate methods, mostly as suggested in previous comments, something like:
    static int shift_op_long_ASHR_and_ADD(LongVector vba, LongVector vbb, long arrLongs[][], int end, int ind) {
        vba.add(vbb.lanewise(VectorOperators.ASHR, 37)).intoArray(arrLongs[end++], ind);
        vba.add(vbb.lanewise(VectorOperators.ASHR, 64)).intoArray(arrLongs[end++], ind);
        vba.add(vbb.lanewise(VectorOperators.ASHR, 99)).intoArray(arrLongs[end++], ind);
        vba.add(vbb.lanewise(VectorOperators.ASHR, 128)).intoArray(arrLongs[end++], ind);
        vba.add(vbb.lanewise(VectorOperators.ASHR, 157)).intoArray(arrLongs[end++], ind);
        vba.add(vbb.lanewise(VectorOperators.ASHR, 192)).intoArray(arrLongs[end++], ind);
        return end;
    }

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From jiefu at openjdk.java.net  Thu Feb 25 03:59:38 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 25 Feb 2021 03:59:38 GMT
Subject: RFR: 8262096: Vector API fails to work without C2
In-Reply-To: <avwP-L51q0RsaWVHLOem_B45vRxPOAtdxmr0eanzdy4=.ec2edabc-db79-4e75-8a47-9f6cd8487f79@github.com>
References: <avwP-L51q0RsaWVHLOem_B45vRxPOAtdxmr0eanzdy4=.ec2edabc-db79-4e75-8a47-9f6cd8487f79@github.com>
Message-ID: <3OcNdppJRXH5uv4sL0o6QTdb2-tKoY28mUQ-JHiYWsc=.105484b2-628e-40ce-850f-e7b0696ab2a3@github.com>

On Sun, 21 Feb 2021 23:19:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Vector API won't work without C2.
> The reason is that VectorSupport_GetMaxLaneCount [1] always returns -1 if C2 is not present.
> But it should work even there is no JIT compiler since it's Java-level's api.
> So let's fix it.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

After more thinking about this issue, I've found more bugs which need to be fixed.
So close this PR and re-do it.
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2667

From jiefu at openjdk.java.net  Thu Feb 25 03:59:39 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 25 Feb 2021 03:59:39 GMT
Subject: Withdrawn: 8262096: Vector API fails to work without C2
In-Reply-To: <avwP-L51q0RsaWVHLOem_B45vRxPOAtdxmr0eanzdy4=.ec2edabc-db79-4e75-8a47-9f6cd8487f79@github.com>
References: <avwP-L51q0RsaWVHLOem_B45vRxPOAtdxmr0eanzdy4=.ec2edabc-db79-4e75-8a47-9f6cd8487f79@github.com>
Message-ID: <0LsLDuQkWpLdda9B6V7Pl-tM0g8qpfMtSl5DVB282pE=.b0eed0bd-f4c2-41e0-9587-035af80044d7@github.com>

On Sun, 21 Feb 2021 23:19:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Vector API won't work without C2.
> The reason is that VectorSupport_GetMaxLaneCount [1] always returns -1 if C2 is not present.
> But it should work even there is no JIT compiler since it's Java-level's api.
> So let's fix it.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/2667

From shade at openjdk.java.net  Thu Feb 25 07:09:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 25 Feb 2021 07:09:39 GMT
Subject: RFR: 8261914: IfNode::fold_compares_helper faces
 non-canonicalized bool when running JRuby JSON workload
In-Reply-To: <kN1wCpfeU-SQPUKtOEQL3t-e12ufqO_i2_W5znZcBFE=.027796bc-ba6d-450d-8bbd-4a93c556cb5e@github.com>
References: <kN1wCpfeU-SQPUKtOEQL3t-e12ufqO_i2_W5znZcBFE=.027796bc-ba6d-450d-8bbd-4a93c556cb5e@github.com>
Message-ID: <5qtq9Zb2tHryna_1rSVbuqWe2pjcQ1Eex50oFH2ug4E=.de32d1a5-44dd-42bc-88c9-e09044899c65@github.com>

On Wed, 24 Feb 2021 15:22:26 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The assert fires because the current IfNode's condition was not
> canonicalized when it's being folded with a dominating
> IfNode. idealize_test() should have taken care of that because it
> executed before fold_compares() but it didn't because:
> 
>   Node* new_b = phase->transform( new BoolNode(b->in(1), bt.negate()) );
>   if( !new_b->is_Bool() ) return NULL;
> 
> caused it to bail out. new_b is a constant. This happens because of
> the order in which nodes are processed by IGVN. The If's current Bool
> would also constant fold but it's in the IGVN worklist and hasn't been
> processed yet.
> 
> The fix I propose is to keep Aleksey's defensive fix but to check that
> the Bool input is indeed about to be transformed by IGVN and that that
> would cause the IfNode to be reprocessed.
> 
> I tried to write a test case but didn't succeed. The 2 If nodes come
> from a tableswitch that's transformed into a series of If based on
> profile data. I couldn't reproduce the profile data with a simple test
> case.

Marked as reviewed by shade (Reviewer).

src/hotspot/share/opto/ifnode.cpp line 984:

> 982:       return false;
> 983:     }
> 984:     assert(this_bool->_test.is_less() && !fail->_con, "incorrect test");

This should lead with "this test was canonicalized" comment? Missed during the move, I think.

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

PR: https://git.openjdk.java.net/jdk/pull/2707

From shade at openjdk.java.net  Thu Feb 25 07:09:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 25 Feb 2021 07:09:40 GMT
Subject: RFR: 8261914: IfNode::fold_compares_helper faces
 non-canonicalized bool when running JRuby JSON workload
In-Reply-To: <5qtq9Zb2tHryna_1rSVbuqWe2pjcQ1Eex50oFH2ug4E=.de32d1a5-44dd-42bc-88c9-e09044899c65@github.com>
References: <kN1wCpfeU-SQPUKtOEQL3t-e12ufqO_i2_W5znZcBFE=.027796bc-ba6d-450d-8bbd-4a93c556cb5e@github.com>
 <5qtq9Zb2tHryna_1rSVbuqWe2pjcQ1Eex50oFH2ug4E=.de32d1a5-44dd-42bc-88c9-e09044899c65@github.com>
Message-ID: <Y62x53tU0ZQFve_Aq9GR4dRi5KmZ3wgwPYJwIL5Apwg=.47637bdb-b031-4fb6-8bb4-e818d7cafe1e@github.com>

On Thu, 25 Feb 2021 07:02:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The assert fires because the current IfNode's condition was not
>> canonicalized when it's being folded with a dominating
>> IfNode. idealize_test() should have taken care of that because it
>> executed before fold_compares() but it didn't because:
>> 
>>   Node* new_b = phase->transform( new BoolNode(b->in(1), bt.negate()) );
>>   if( !new_b->is_Bool() ) return NULL;
>> 
>> caused it to bail out. new_b is a constant. This happens because of
>> the order in which nodes are processed by IGVN. The If's current Bool
>> would also constant fold but it's in the IGVN worklist and hasn't been
>> processed yet.
>> 
>> The fix I propose is to keep Aleksey's defensive fix but to check that
>> the Bool input is indeed about to be transformed by IGVN and that that
>> would cause the IfNode to be reprocessed.
>> 
>> I tried to write a test case but didn't succeed. The 2 If nodes come
>> from a tableswitch that's transformed into a series of If based on
>> profile data. I couldn't reproduce the profile data with a simple test
>> case.
>
> src/hotspot/share/opto/ifnode.cpp line 984:
> 
>> 982:       return false;
>> 983:     }
>> 984:     assert(this_bool->_test.is_less() && !fail->_con, "incorrect test");
> 
> This should lead with "this test was canonicalized" comment? Missed during the move, I think.

I also find it a bit weird to even have the assert on this path, as we tested all cases in the if-chain before, and the only path to this assert is through `lt` and `le` -- which is `is_less`? Maybe I am missing something, though.

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

PR: https://git.openjdk.java.net/jdk/pull/2707

From xliu at openjdk.java.net  Thu Feb 25 08:43:41 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 25 Feb 2021 08:43:41 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v8]
In-Reply-To: <9QwSVEA-wKGBPSwUX0MSDAXGLLjCaSmLjtEyKshvdGI=.e9c410e8-5495-4ceb-affc-4590ebcd84d4@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <OqWDff-G81UpwvWSjhd8RKX5KP97tMGqlC8cIfR2L0g=.894571ca-7f64-4678-9156-591322bde4be@github.com>
 <9QwSVEA-wKGBPSwUX0MSDAXGLLjCaSmLjtEyKshvdGI=.e9c410e8-5495-4ceb-affc-4590ebcd84d4@github.com>
Message-ID: <-2ATme5P-5tNlwomRglS6fjxrvD5tK-bKqMx9N11eZg=.e5e0d183-6872-4972-bb0d-7542b3c0b057@github.com>

On Wed, 24 Feb 2021 11:10:46 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>>   
>>   add comments and hoist ResourceMark
>
> test/hotspot/gtest/utilities/test_ostream.cpp line 66:
> 
>> 64: 
>> 65: static size_t count_char(const stringStream* ss, char ch) {
>> 66:   return count_char(ss->as_string(), ss->size(), ch);
> 
> Am I correct `std:count` is not allowed?
> No need to use `as_string`: `return count_char(ss->base(), ss->size(), ch);`
> Or as `stringStream` is always zero-terminated: `return count_char(ss->base(), ch);`

I don't think STL is allowed. 

Make sense. ss->as_string() is not necessary. 

I don't like the idea we assume ss is always zero-terminated like C-string. There is a member variable _written in class stringStream.  Technically speaking, the implementation can avoid from writing '\0' in the end.  that's why I would like to use len argument.  For me, `count_char(ss->base(), ss->size(), ch)` is more reliable because it depends on interfaces instead of implementation.  an interface is supposed to be more stable than implementation.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Thu Feb 25 08:48:40 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 25 Feb 2021 08:48:40 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v8]
In-Reply-To: <9QwSVEA-wKGBPSwUX0MSDAXGLLjCaSmLjtEyKshvdGI=.e9c410e8-5495-4ceb-affc-4590ebcd84d4@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <OqWDff-G81UpwvWSjhd8RKX5KP97tMGqlC8cIfR2L0g=.894571ca-7f64-4678-9156-591322bde4be@github.com>
 <9QwSVEA-wKGBPSwUX0MSDAXGLLjCaSmLjtEyKshvdGI=.e9c410e8-5495-4ceb-affc-4590ebcd84d4@github.com>
Message-ID: <MJOXj7U8WT4POFdvC5IBqWzYs-skTg0Vc5XRcuMj2h0=.6c8eb072-c36e-420f-be2f-a475817192ed@github.com>

On Wed, 24 Feb 2021 12:09:23 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>>   
>>   add comments and hoist ResourceMark
>
> test/hotspot/gtest/utilities/test_ostream.cpp line 69:
> 
>> 67: }
>> 68: 
>> 69: static void test_stringStream_tr_delete(stringStream* ss) {
> 
> I think this is a unit test for `StringUtils::replace_no_expand`. It checks that the function can be used to remove substrings. There is no dependency on `stringStream`. Any string can be used.
> Could you please move the test to `test_stringUtils.cpp`?

yes, let me move it to test_stringUtils.cpp.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Thu Feb 25 08:51:39 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 25 Feb 2021 08:51:39 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v8]
In-Reply-To: <MJOXj7U8WT4POFdvC5IBqWzYs-skTg0Vc5XRcuMj2h0=.6c8eb072-c36e-420f-be2f-a475817192ed@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <OqWDff-G81UpwvWSjhd8RKX5KP97tMGqlC8cIfR2L0g=.894571ca-7f64-4678-9156-591322bde4be@github.com>
 <9QwSVEA-wKGBPSwUX0MSDAXGLLjCaSmLjtEyKshvdGI=.e9c410e8-5495-4ceb-affc-4590ebcd84d4@github.com>
 <MJOXj7U8WT4POFdvC5IBqWzYs-skTg0Vc5XRcuMj2h0=.6c8eb072-c36e-420f-be2f-a475817192ed@github.com>
Message-ID: <ypAq0nv-qgLAVV497ZRzCUgPRy7el84kcSROI_FwLQg=.06c697fe-2896-47f0-a784-8ebdc31e037d@github.com>

On Thu, 25 Feb 2021 08:46:08 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> test/hotspot/gtest/utilities/test_ostream.cpp line 69:
>> 
>>> 67: }
>>> 68: 
>>> 69: static void test_stringStream_tr_delete(stringStream* ss) {
>> 
>> I think this is a unit test for `StringUtils::replace_no_expand`. It checks that the function can be used to remove substrings. There is no dependency on `stringStream`. Any string can be used.
>> Could you please move the test to `test_stringUtils.cpp`?
>
> yes, let me move it to test_stringUtils.cpp.

I would like to keep stringStream because I think it's good idea to test the similar scenario. 
it's also handy to do memory management.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Thu Feb 25 08:56:14 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 25 Feb 2021 08:56:14 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v9]
In-Reply-To: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
Message-ID: <s1cVE9vyCLiv_M3eS3U17dfjA0DgrpbzBaEqDPWqkxo=.659774fa-7900-434d-b9b9-5b3acb98261d@github.com>

> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
> 
> Before:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
> - string: "a"
> :Constant:exact *
> 
> After:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
  
  update comments based on the review feedbacks.
  move the unittest to test_stringUtil.cpp.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2178/files
  - new: https://git.openjdk.java.net/jdk/pull/2178/files/aeff9ecc..2f7ccdb0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2178&range=07-08

  Stats: 76 lines in 3 files changed: 41 ins; 30 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2178.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2178/head:pull/2178

PR: https://git.openjdk.java.net/jdk/pull/2178

From thartmann at openjdk.java.net  Thu Feb 25 08:56:46 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 25 Feb 2021 08:56:46 GMT
Subject: Integrated: 8262299: C2 compilation fails with "modified node was not
 processed by IGVN.transform_old()"
In-Reply-To: <sz17iaCL32d3qPjgs5q33b-OZufMoQez5HUZR850H3w=.d0d143ee-d0c5-4983-9a90-0a578b7c0d5d@github.com>
References: <sz17iaCL32d3qPjgs5q33b-OZufMoQez5HUZR850H3w=.d0d143ee-d0c5-4983-9a90-0a578b7c0d5d@github.com>
Message-ID: <BRZeAjHFGO22bL1MMGxkAjpgiGBI81SWFRZ8UZ_ynJs=.fbab16e2-8c3b-4b61-96a5-f9a6df76d842@github.com>

On Wed, 24 Feb 2021 12:44:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We hit an assert because a dead `MergeMemNode` was not removed. Make sure it's added to the IGVN worklist to give it a chance to be removed.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: a83e802b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a83e802b
Stats:     10 lines in 1 file changed: 6 ins; 4 del; 0 mod

8262299: C2 compilation fails with "modified node was not processed by IGVN.transform_old()"

Reviewed-by: roland, chagedorn

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

PR: https://git.openjdk.java.net/jdk/pull/2705

From jiefu at openjdk.java.net  Thu Feb 25 09:36:02 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 25 Feb 2021 09:36:02 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception
Message-ID: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>

Hi all,

Vector API fails to work when:
 - case 1: MaxVectorSize is set to <=8, or
 - case 2: C2 is disabled

The reason is that {max/preferred} VectorShape initialization fails in both cases.
And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).

Vector API should not depend on C2 to run.
It should work even there is no JIT compiler since it's a Java-level api.
So let's fix it.

Testing:
  - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

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

Commit messages:
 - 8262096: Vector API fails to work due to VectorShape initialization exception

Changes: https://git.openjdk.java.net/jdk/pull/2722/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262096
  Stats: 66 lines in 3 files changed: 57 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722

PR: https://git.openjdk.java.net/jdk/pull/2722

From roland at openjdk.java.net  Thu Feb 25 09:52:40 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 25 Feb 2021 09:52:40 GMT
Subject: RFR: 8261308: C2: assert(inner->is_valid_counted_loop(T_INT) &&
 inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
In-Reply-To: <axZ4LSZiOvS12SeEfK7bmjb2wtW5H5EtxSulqyPAXFY=.ebf5a7a6-f0cb-4976-8b37-dc67f3687a15@github.com>
References: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
 <axZ4LSZiOvS12SeEfK7bmjb2wtW5H5EtxSulqyPAXFY=.ebf5a7a6-f0cb-4976-8b37-dc67f3687a15@github.com>
Message-ID: <N_81iChi8g68udH7e7FLQUSfXEtU-PAJefZhCeiCyqc=.c5eb8394-1a81-4d53-8467-302bbfe093c2@github.com>

On Wed, 24 Feb 2021 19:43:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Add comment here explaining this case (one trip when init >= limit).

Ok. Do you still think we need extra tests?

> BTW, this optimization seems only works for INT iv loops and not LONG. Do you plan to implement for LONG?

I thought about it but it's not straightforward because the current code uses long to avoid overflow. I would also like to rework the parallel iv code so it works with LONG loops. I don't have time right now, thought.

Note also, that because of the iv phi Value(), I would expect some of the single iteration loops to be optimized even without a working IdealLoopTree::compute_trip_count(). That would be true for in and long loops.

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

PR: https://git.openjdk.java.net/jdk/pull/2529

From roland at openjdk.java.net  Thu Feb 25 09:53:39 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 25 Feb 2021 09:53:39 GMT
Subject: RFR: 8261914: IfNode::fold_compares_helper faces
 non-canonicalized bool when running JRuby JSON workload
In-Reply-To: <Y62x53tU0ZQFve_Aq9GR4dRi5KmZ3wgwPYJwIL5Apwg=.47637bdb-b031-4fb6-8bb4-e818d7cafe1e@github.com>
References: <kN1wCpfeU-SQPUKtOEQL3t-e12ufqO_i2_W5znZcBFE=.027796bc-ba6d-450d-8bbd-4a93c556cb5e@github.com>
 <5qtq9Zb2tHryna_1rSVbuqWe2pjcQ1Eex50oFH2ug4E=.de32d1a5-44dd-42bc-88c9-e09044899c65@github.com>
 <Y62x53tU0ZQFve_Aq9GR4dRi5KmZ3wgwPYJwIL5Apwg=.47637bdb-b031-4fb6-8bb4-e818d7cafe1e@github.com>
Message-ID: <HEe2XcIOZblL1uO180ayme7KiX9sYPEjArugMlOZ0Cc=.f4c08fa5-6fa9-420c-a3dc-9d11bc3e38d0@github.com>

On Thu, 25 Feb 2021 07:06:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I also find it a bit weird to even have the assert on this path, as we tested all cases in the if-chain before, and the only path to this assert is through `lt` and `le` -- which is `is_less`? Maybe I am missing something, though.

I kept it because of the !fail->_con part of the assert. I kept the whole assert and move it around because I'm lazy, I guess.

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

PR: https://git.openjdk.java.net/jdk/pull/2707

From adinn at openjdk.java.net  Thu Feb 25 11:04:07 2021
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 25 Feb 2021 11:04:07 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v4]
In-Reply-To: <NxLAxfTal2oKzbLe--PSJlA_3vGKR1TK5pS8dH5JMLc=.482881ea-0f16-4c33-b475-1d626e0e4939@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
 <5M1DPgw-V-j9acOvHLewPoTaxF-a6-9HMIpIzHjqavU=.55831da6-f888-4dc0-beee-19869c5eb638@github.com>
 <NxLAxfTal2oKzbLe--PSJlA_3vGKR1TK5pS8dH5JMLc=.482881ea-0f16-4c33-b475-1d626e0e4939@github.com>
Message-ID: <N7hhVL_EFkcEeL_roxCLbrJA-gMH41AkNdxDT5JURZw=.5e4cf95f-c305-4c44-a13c-9518d241e916@github.com>

On Wed, 24 Feb 2021 20:57:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "test & debug"
>>   
>>   This reverts commit cb9dd24c9fcccc6997e9fca874e2860f966b9576.
>
> Thanks for addressing the comments! Looks good.

@JornVernee I'm not clear that your response addresses my point. I'm concerned that a thread stack dump reported by serviceability code may contain an extra frame for the stub call. This could occur while the Java thread is still in native and it could also include the case wher the native call re-enters into Java i.e. the extra frame could appear at the top of the stack dump or interleaved between Java method frames.

I don't see how that problem is mitigated by your suggestion that this only relates to Panama API use. Code which consumes any such stack dump (incluing 3rd party code) that might be affected by the presence of this extra frame will not care (or even be aware) that the native callout is a Panama call.

Anyway, since no one from the serviceability team has noted this as a potential problem I'm ok to see the patch proceed.

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

PR: https://git.openjdk.java.net/jdk/pull/2528

From github.com+42899633+eastig at openjdk.java.net  Thu Feb 25 11:04:07 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Thu, 25 Feb 2021 11:04:07 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v9]
In-Reply-To: <s1cVE9vyCLiv_M3eS3U17dfjA0DgrpbzBaEqDPWqkxo=.659774fa-7900-434d-b9b9-5b3acb98261d@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <s1cVE9vyCLiv_M3eS3U17dfjA0DgrpbzBaEqDPWqkxo=.659774fa-7900-434d-b9b9-5b3acb98261d@github.com>
Message-ID: <ZNcq8Y_cSkBa2EEomaWvFEUN607qIyBNgCd7j4IjG3I=.98e7dd18-ab0e-4ef5-ac32-f81a04b845e3@github.com>

On Thu, 25 Feb 2021 08:56:14 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
>> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
>> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
>> 
>> Before:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
>> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
>> - string: "a"
>> :Constant:exact *
>> 
>> After:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>   
>   update comments based on the review feedbacks.
>   move the unittest to test_stringUtil.cpp.

Marked as reviewed by eastig at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From github.com+10835776+stsypanov at openjdk.java.net  Thu Feb 25 11:07:47 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 25 Feb 2021 11:07:47 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <MBMi2I0sim_z4rs9I1ISl4XaYOe45pDb7u-TxJbQIQc=.0472c0a4-8776-4714-9628-3623ca3fdda2@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
 <MBMi2I0sim_z4rs9I1ISl4XaYOe45pDb7u-TxJbQIQc=.0472c0a4-8776-4714-9628-3623ca3fdda2@github.com>
Message-ID: <XkiSvaFi48AB2_MTKcVv6NVUy4wPhkGkTO7GLREdIM8=.9b0da781-b629-4efb-ad96-2ceb3f5ac451@github.com>

On Wed, 24 Feb 2021 08:50:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261880: Remove static from declarations of Holder nested classes
>
> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 67:
> 
>> 65:     private final SinkChannel sink;
>> 66: 
>> 67:     private static class Initializer
> 
> This one is okay to do.

Thanks for review! Could you review the rest of the code and approve this PR, if it's fine?

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

PR: https://git.openjdk.java.net/jdk/pull/2589

From rwestrel at redhat.com  Thu Feb 25 11:55:04 2021
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 25 Feb 2021 12:55:04 +0100
Subject: RFC: 8262295: C2: Out-of-Bounds Array Load from Clone Source
In-Reply-To: <AM0PR02MB4273AD4F499F52FA0416F7DA9B9F9@AM0PR02MB4273.eurprd02.prod.outlook.com>
References: <AM0PR02MB4273AD4F499F52FA0416F7DA9B9F9@AM0PR02MB4273.eurprd02.prod.outlook.com>
Message-ID: <87o8g8weef.fsf@redhat.com>


Hi Richard,

> I've been working on a fix for
>
> JDK-8262295: C2: Out-of-Bounds Array Load from Clone Source
> https://bugs.openjdk.java.net/browse/JDK-8262295

The bug is not visible.

> Now I'm not sure if the fix I found (compile time range check) is a good one.
>
> I have created a draft PR with the fix not yet ready for proper review:
>
> https://github.com/openjdk/jdk/pull/2708
>
> Please let me know what you think and if this is the right approach.
>
> My first attempt was to keep the original control for the cloned node in
> LoadNode::can_see_arraycopy_value() but this seemd to confuse loop
> optimizations. At least the test compiler/escapeAnalysis/TestMissingAntiDependency.java
> failed with that change.

Keeping the original control would seem like the best fix. What error do
you get with it? Maybe keeping the cloned load's memory unchanged helps?

Roland.


From shade at openjdk.java.net  Thu Feb 25 14:52:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 25 Feb 2021 14:52:39 GMT
Subject: RFR: 8261914: IfNode::fold_compares_helper faces
 non-canonicalized bool when running JRuby JSON workload
In-Reply-To: <HEe2XcIOZblL1uO180ayme7KiX9sYPEjArugMlOZ0Cc=.f4c08fa5-6fa9-420c-a3dc-9d11bc3e38d0@github.com>
References: <kN1wCpfeU-SQPUKtOEQL3t-e12ufqO_i2_W5znZcBFE=.027796bc-ba6d-450d-8bbd-4a93c556cb5e@github.com>
 <5qtq9Zb2tHryna_1rSVbuqWe2pjcQ1Eex50oFH2ug4E=.de32d1a5-44dd-42bc-88c9-e09044899c65@github.com>
 <Y62x53tU0ZQFve_Aq9GR4dRi5KmZ3wgwPYJwIL5Apwg=.47637bdb-b031-4fb6-8bb4-e818d7cafe1e@github.com>
 <HEe2XcIOZblL1uO180ayme7KiX9sYPEjArugMlOZ0Cc=.f4c08fa5-6fa9-420c-a3dc-9d11bc3e38d0@github.com>
Message-ID: <R2NsFzuWBFehsrr1kDZG_xZYYCDNHE02l_9M3uG1JvQ=.d2662f79-7c49-49c0-b4dd-4e7f6be578ae@github.com>

On Thu, 25 Feb 2021 09:50:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I also find it a bit weird to even have the assert on this path, as we tested all cases in the if-chain before, and the only path to this assert is through `lt` and `le` -- which is `is_less`? Maybe I am missing something, though.
>
>> I also find it a bit weird to even have the assert on this path, as we tested all cases in the if-chain before, and the only path to this assert is through `lt` and `le` -- which is `is_less`? Maybe I am missing something, though.
> 
> I kept it because of the !fail->_con part of the assert. I kept the whole assert and move it around because I'm lazy, I guess.

That's fine. Keep the comment, though?

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

PR: https://git.openjdk.java.net/jdk/pull/2707

From psandoz at openjdk.java.net  Thu Feb 25 17:25:40 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 25 Feb 2021 17:25:40 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception
In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
Message-ID: <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com>

On Thu, 25 Feb 2021 09:31:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

src/hotspot/share/prims/vectorSupport.cpp line 368:

> 366:   if (java_lang_Class::is_primitive(mirror)) {
> 367:     BasicType bt = java_lang_Class::primitive_type(mirror);
> 368:     int min_lane_count = 64 / type2aelembytes(bt);

I am uncertain of the units here. Is the numerator in bits and the denominator in bytes?

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From xliu at openjdk.java.net  Thu Feb 25 17:50:54 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 25 Feb 2021 17:50:54 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v9]
In-Reply-To: <ZNcq8Y_cSkBa2EEomaWvFEUN607qIyBNgCd7j4IjG3I=.98e7dd18-ab0e-4ef5-ac32-f81a04b845e3@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <s1cVE9vyCLiv_M3eS3U17dfjA0DgrpbzBaEqDPWqkxo=.659774fa-7900-434d-b9b9-5b3acb98261d@github.com>
 <ZNcq8Y_cSkBa2EEomaWvFEUN607qIyBNgCd7j4IjG3I=.98e7dd18-ab0e-4ef5-ac32-f81a04b845e3@github.com>
Message-ID: <qxLt0fs4r_T6UKQ8Q_LT1GfKIiWXTDdesNZ1VWNnJus=.1fae7da0-600b-490c-94ea-7616af14533c@github.com>

On Thu, 25 Feb 2021 10:40:07 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>>   
>>   update comments based on the review feedbacks.
>>   move the unittest to test_stringUtil.cpp.
>
> Marked as reviewed by eastig at github.com (no known OpenJDK username).

@eastig  Thank you for reviewing it. 
@TobiHartmann  Could you take a look at it again? I made a little change after you approve it.  If everything looks fine, could  you  sponsor it?  Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From kvn at openjdk.java.net  Thu Feb 25 18:11:53 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 25 Feb 2021 18:11:53 GMT
Subject: RFR: 8261308: C2: assert(inner->is_valid_counted_loop(T_INT) &&
 inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
In-Reply-To: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
References: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
Message-ID: <EYDXtVzIZb2PT9FyHKWTsyvvmkM3eQvPb0wQ6gnc5lg=.4fd8baa4-695a-4710-b9d6-8fcdd0b2b008@github.com>

On Thu, 11 Feb 2021 16:11:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The inner counted loop of the test case starts at 1 and stops at 1 so
> runs for one iteration. A counted loop is created for it. The iv Phi
> is found to be the constant 1 and its type is set by:
> 
> l->phi()->as_Phi()->set_type(l->phi()->Value(&_igvn));
> 
> in PhaseIdealLoop::is_counted_loop() but it's not replaced by the
> constant 1 yet so the counted loop's shape is preserved.
> 
> IdealLoopTree::do_one_iteration_loop() runs but doesn't optimize the
> loop because the trip count is not set to 1. The loop contains a range
> check and range check elimination is applied. That causes the loop
> exit test to be adjusted with a MinI(..) expression. When IGVN runs
> next, the phi is replaced with 1 but because the exit test was
> changed, IGVN can't prove it always fails. So the loop is not removed
> which causes the assert failure as loop opts progress.
> 
> The fix I propose is for IdealLoopTree::do_one_iteration_loop() to
> remove the 1 iteration loop. The reason it doesn't happen is that
> IdealLoopTree::compute_trip_count() doesn't set the trip count because
> it finds a zero trip count: limit - init = 1 - 1 = 0. All loops, once
> entered execute at least once. So I think, it's safe to set the trip
> count to 1 in those cases.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2529

From kvn at openjdk.java.net  Thu Feb 25 18:11:53 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 25 Feb 2021 18:11:53 GMT
Subject: RFR: 8261308: C2: assert(inner->is_valid_counted_loop(T_INT) &&
 inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
In-Reply-To: <N_81iChi8g68udH7e7FLQUSfXEtU-PAJefZhCeiCyqc=.c5eb8394-1a81-4d53-8467-302bbfe093c2@github.com>
References: <B7x8x3Z14KVoAj7tsapLXxNVmQF8gEkL-YDa6sFlihs=.0d95ff95-fadd-4407-a002-96574e9f432d@github.com>
 <axZ4LSZiOvS12SeEfK7bmjb2wtW5H5EtxSulqyPAXFY=.ebf5a7a6-f0cb-4976-8b37-dc67f3687a15@github.com>
 <N_81iChi8g68udH7e7FLQUSfXEtU-PAJefZhCeiCyqc=.c5eb8394-1a81-4d53-8467-302bbfe093c2@github.com>
Message-ID: <kYEiO0hitwyN8N-zRkzd_4uriXTzrNA6FtDdk7pGF6c=.564a24d4-78e8-4cf5-8342-3c46818ab930@github.com>

On Thu, 25 Feb 2021 09:49:31 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> > Add comment here explaining this case (one trip when init >= limit).
> 
> Ok. Do you still think we need extra tests?

Yes, would be nice to have tests for 0,1,2 iterations and all 3 types of loops: `for() {}`, `while() {}`, `do {} while()` to verify that they are converted to straight code. It could be done as separate RFE.

> 
> > BTW, this optimization seems only works for INT iv loops and not LONG. Do you plan to implement for LONG?
> 
> I thought about it but it's not straightforward because the current code uses long to avoid overflow. I would also like to rework the parallel iv code so it works with LONG loops. I don't have time right now, thought.
> 
> Note also, that because of the iv phi Value(), I would expect some of the single iteration loops to be optimized even without a working IdealLoopTree::compute_trip_count(). That would be true for in and long loops.

Got it. Thank you.

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

PR: https://git.openjdk.java.net/jdk/pull/2529

From xliu at openjdk.java.net  Thu Feb 25 20:19:41 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 25 Feb 2021 20:19:41 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v8]
In-Reply-To: <9QwSVEA-wKGBPSwUX0MSDAXGLLjCaSmLjtEyKshvdGI=.e9c410e8-5495-4ceb-affc-4590ebcd84d4@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <OqWDff-G81UpwvWSjhd8RKX5KP97tMGqlC8cIfR2L0g=.894571ca-7f64-4678-9156-591322bde4be@github.com>
 <9QwSVEA-wKGBPSwUX0MSDAXGLLjCaSmLjtEyKshvdGI=.e9c410e8-5495-4ceb-affc-4590ebcd84d4@github.com>
Message-ID: <7u7ZuQQ8gEBsAFXs8ZR6JNQWvHmyzzkGPfN0gez9ZmI=.79e2b654-c552-4fbf-9f2a-e35ae70a2e6b@github.com>

On Wed, 24 Feb 2021 11:08:58 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>>   
>>   add comments and hoist ResourceMark
>
> src/hotspot/share/opto/type.cpp line 4053:
> 
>> 4051:       const_oop()->print_oop(&ss);
>> 4052:       // suppress new-lines('\n') in ss emitted by const_oop->print_oop()
>> 4053:       // so each node is one-liner for -XX:+Verbose && -XX:+PrintIdeal
> 
> What about rewriting the comment in clearer way:
> // 'const_oop->print_oop()' emits new-lines('\n') into ss.
> // For -XX:+Verbose && -XX:+PrintIdeal, new-lines('\n') must be removed from
> // the ss created string to have a node per line.

update it.

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From jiefu at openjdk.java.net  Thu Feb 25 23:52:06 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 25 Feb 2021 23:52:06 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v2]
In-Reply-To: <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com>
Message-ID: <OJoAREdVMjEQw9Zx4mUxVw8rh5Bskxn1zj-Zg5Y0r-c=.2b398a05-0eae-43a4-9d9a-405bda232f49@github.com>

On Thu, 25 Feb 2021 17:23:11 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The numerator should be 8 (byte)
>
> src/hotspot/share/prims/vectorSupport.cpp line 368:
> 
>> 366:   if (java_lang_Class::is_primitive(mirror)) {
>> 367:     BasicType bt = java_lang_Class::primitive_type(mirror);
>> 368:     int min_lane_count = 64 / type2aelembytes(bt);
> 
> I am uncertain of the units here. Is the numerator in bits and the denominator in bytes?

Thanks Paul for your review.

Oops, the numerator should be 8 (bytes).

Updated.
Testing of jdk/incubator/vector (MaxVector=default/8/4 or without C2) is still fine.
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Thu Feb 25 23:52:04 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 25 Feb 2021 23:52:04 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v2]
In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
Message-ID: <d17OBR47Ak_s3KNFnKfZkw88K1EF0zkRKZMKahoGj2Y=.9f4c84d0-50b7-43a8-b02f-014dccb7765d@github.com>

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  The numerator should be 8 (byte)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2722/files
  - new: https://git.openjdk.java.net/jdk/pull/2722/files/09b49f25..724b36d4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722

PR: https://git.openjdk.java.net/jdk/pull/2722

From psandoz at openjdk.java.net  Fri Feb 26 00:33:41 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 26 Feb 2021 00:33:41 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v2]
In-Reply-To: <OJoAREdVMjEQw9Zx4mUxVw8rh5Bskxn1zj-Zg5Y0r-c=.2b398a05-0eae-43a4-9d9a-405bda232f49@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com>
 <OJoAREdVMjEQw9Zx4mUxVw8rh5Bskxn1zj-Zg5Y0r-c=.2b398a05-0eae-43a4-9d9a-405bda232f49@github.com>
Message-ID: <c_nkcjdGTGqfvsB-hrYn0srBm9q8t4VSsJPfNn3ABFI=.0a8fe942-fe03-40a7-b145-73f973d6405e@github.com>

On Thu, 25 Feb 2021 23:48:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> src/hotspot/share/prims/vectorSupport.cpp line 368:
>> 
>>> 366:   if (java_lang_Class::is_primitive(mirror)) {
>>> 367:     BasicType bt = java_lang_Class::primitive_type(mirror);
>>> 368:     int min_lane_count = 64 / type2aelembytes(bt);
>> 
>> I am uncertain of the units here. Is the numerator in bits and the denominator in bytes?
>
> Thanks Paul for your review.
> 
> Oops, the numerator should be 8 (bytes).
> 
> Updated.
> Testing of jdk/incubator/vector (MaxVector=default/8/4 or without C2) is still fine.
> Thanks.

Thanks, was the test `VectorShapeInitTest` passing prior to the fix of the numerator?
Perhaps we should be testing more directly on `VectorShape.S_Max_BIT.vectorBitSize()` and `VectorShape.preferredShape` ? 
Also, perhaps we can run with C2 disabled, with `-XX:TieredStopAtLevel=3` ?

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Fri Feb 26 02:19:01 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 26 Feb 2021 02:19:01 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v3]
In-Reply-To: <c_nkcjdGTGqfvsB-hrYn0srBm9q8t4VSsJPfNn3ABFI=.0a8fe942-fe03-40a7-b145-73f973d6405e@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com>
 <OJoAREdVMjEQw9Zx4mUxVw8rh5Bskxn1zj-Zg5Y0r-c=.2b398a05-0eae-43a4-9d9a-405bda232f49@github.com>
 <c_nkcjdGTGqfvsB-hrYn0srBm9q8t4VSsJPfNn3ABFI=.0a8fe942-fe03-40a7-b145-73f973d6405e@github.com>
Message-ID: <yZT61T0hNADqmnkXBK9MsFterHPAZ_WijKctlOLvFo4=.d3690ae0-bdd1-4d41-be69-ff6186a8a58c@github.com>

On Fri, 26 Feb 2021 00:30:45 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Thanks, was the test `VectorShapeInitTest` passing prior to the fix of the numerator?
Yes. It also passed with min_lane_count = 64 / type2aelembytes(bt).

> Perhaps we should be testing more directly on `VectorShape.S_Max_BIT.vectorBitSize()` and `VectorShape.preferredShape` ?
Ok.
But it that case, I'd like to just re-use jdk/incubator/vector/PreferredSpeciesTest.java.

> Also, perhaps we can run with C2 disabled, with `-XX:TieredStopAtLevel=3` ?
Fine.
Although this bug wouldn't be triggered with -XX:TieredStopAtLevel=x, it can help test  with C1.

Patch had been updated.
Any comments?
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Fri Feb 26 02:19:01 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 26 Feb 2021 02:19:01 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v3]
In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
Message-ID: <mvnEJOFSt3WK73u4drd3rdh7kRtAZVtkwRGkWlZ_Uxw=.1650ded2-92c5-486f-a172-c124f8b1a1de@github.com>

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Update the jtreg test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2722/files
  - new: https://git.openjdk.java.net/jdk/pull/2722/files/724b36d4..aa475b0a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=01-02

  Stats: 59 lines in 2 files changed: 10 ins; 48 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722

PR: https://git.openjdk.java.net/jdk/pull/2722

From psandoz at openjdk.java.net  Fri Feb 26 02:31:39 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 26 Feb 2021 02:31:39 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v3]
In-Reply-To: <yZT61T0hNADqmnkXBK9MsFterHPAZ_WijKctlOLvFo4=.d3690ae0-bdd1-4d41-be69-ff6186a8a58c@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com>
 <OJoAREdVMjEQw9Zx4mUxVw8rh5Bskxn1zj-Zg5Y0r-c=.2b398a05-0eae-43a4-9d9a-405bda232f49@github.com>
 <c_nkcjdGTGqfvsB-hrYn0srBm9q8t4VSsJPfNn3ABFI=.0a8fe942-fe03-40a7-b145-73f973d6405e@github.com>
 <yZT61T0hNADqmnkXBK9MsFterHPAZ_WijKctlOLvFo4=.d3690ae0-bdd1-4d41-be69-ff6186a8a58c@github.com>
Message-ID: <SJJfsFl9v_LQAb25Nrq8EKpfIMeWqkpAMIi1qO_OWK0=.fda325be-57c0-440a-b8f9-0618a9e6a391@github.com>

On Fri, 26 Feb 2021 02:16:02 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Thanks, was the test `VectorShapeInitTest` passing prior to the fix of the numerator?
>> Perhaps we should be testing more directly on `VectorShape.S_Max_BIT.vectorBitSize()` and `VectorShape.preferredShape` ? 
>> Also, perhaps we can run with C2 disabled, with `-XX:TieredStopAtLevel=3` ?
>
>> Thanks, was the test `VectorShapeInitTest` passing prior to the fix of the numerator?
> Yes. It also passed with min_lane_count = 64 / type2aelembytes(bt).
> 
>> Perhaps we should be testing more directly on `VectorShape.S_Max_BIT.vectorBitSize()` and `VectorShape.preferredShape` ?
> Ok.
> But it that case, I'd like to just re-use jdk/incubator/vector/PreferredSpeciesTest.java.
> 
>> Also, perhaps we can run with C2 disabled, with `-XX:TieredStopAtLevel=3` ?
> Fine.
> Although this bug wouldn't be triggered with -XX:TieredStopAtLevel=x, it can help test  with C1.
> 
> Patch had been updated.
> Any comments?
> Thanks.

Reusing PreferredSpeciesTest is a good idea.

I now realize that C2 needs to be compiled out to trigger some other cases. In that case I think we can remove the execution with `-XX:TieredStopAtLevel=x`. The test will get executed with various HotSpot configurations by the test infrastructure, eventually...

Looks good.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Fri Feb 26 02:38:00 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 26 Feb 2021 02:38:00 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v4]
In-Reply-To: <SJJfsFl9v_LQAb25Nrq8EKpfIMeWqkpAMIi1qO_OWK0=.fda325be-57c0-440a-b8f9-0618a9e6a391@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com>
 <OJoAREdVMjEQw9Zx4mUxVw8rh5Bskxn1zj-Zg5Y0r-c=.2b398a05-0eae-43a4-9d9a-405bda232f49@github.com>
 <c_nkcjdGTGqfvsB-hrYn0srBm9q8t4VSsJPfNn3ABFI=.0a8fe942-fe03-40a7-b145-73f973d6405e@github.com>
 <yZT61T0hNADqmnkXBK9MsFterHPAZ_WijKctlOLvFo4=.d3690ae0-bdd1-4d41-be69-ff6186a8a58c@github.com>
 <SJJfsFl9v_LQAb25Nrq8EKpfIMeWqkpAMIi1qO_OWK0=.fda325be-57c0-440a-b8f9-0618a9e6a391@github.com>
Message-ID: <6aOBlWYEmWHRYJ2YehyBI_AoE5_bA3Hejgdl2yIRt84=.fbffb4ec-3949-4993-8468-c39f5cde3f09@github.com>

On Fri, 26 Feb 2021 02:28:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> In that case I think we can remove the execution with `-XX:TieredStopAtLevel=x`.

Fixed. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Fri Feb 26 02:38:00 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 26 Feb 2021 02:38:00 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v4]
In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
Message-ID: <Ogd9bO2tWac2Kds7hEeMqQEmHIyxOkM0yxwQwPeidc0=.0410848c-a82c-4f94-9962-00e358032130@github.com>

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Remove -XX:TieredStopAtLevel=3

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2722/files
  - new: https://git.openjdk.java.net/jdk/pull/2722/files/aa475b0a..bbe6150c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722

PR: https://git.openjdk.java.net/jdk/pull/2722

From psandoz at openjdk.java.net  Fri Feb 26 03:19:41 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 26 Feb 2021 03:19:41 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v4]
In-Reply-To: <Ogd9bO2tWac2Kds7hEeMqQEmHIyxOkM0yxwQwPeidc0=.0410848c-a82c-4f94-9962-00e358032130@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <Ogd9bO2tWac2Kds7hEeMqQEmHIyxOkM0yxwQwPeidc0=.0410848c-a82c-4f94-9962-00e358032130@github.com>
Message-ID: <Ul-uJ6iKy1WDNo_RBGaUuo8E1fDW-DK_aRwRWVqcQ3U=.6cc7b19e-2506-47eb-b8f4-cde8a967a4a7@github.com>

On Fri, 26 Feb 2021 02:38:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Vector API fails to work when:
>>  - case 1: MaxVectorSize is set to <=8, or
>>  - case 2: C2 is disabled
>> 
>> The reason is that {max/preferred} VectorShape initialization fails in both cases.
>> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
>> 
>> Vector API should not depend on C2 to run.
>> It should work even there is no JIT compiler since it's a Java-level api.
>> So let's fix it.
>> 
>> Testing:
>>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove -XX:TieredStopAtLevel=3

Marked as reviewed by psandoz (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From dongbo at openjdk.java.net  Fri Feb 26 06:10:01 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 26 Feb 2021 06:10:01 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v11]
In-Reply-To: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
Message-ID: <YAM3nSoEcTeWm2erhD1y2Ia3HEUumW0ckWTmlm07dXo=.12eeebce-331f-435c-846c-9eb99ea75a97@github.com>

> In vectorAPI, when right-shifting a vector with a shift equals to the element width, the shift is transformed to zero,
> see `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java`:
>     /** Produce {@code a>>>(n&(ESIZE*8-1))}. Integral only. */
>     public static final /*bitwise*/ Binary LSHR = binary("LSHR", ">>>", VectorSupport.VECTOR_OP_URSHIFT, VO_SHIFT);
> 
> The aarch64 assembler generates wrong or illegal instructions in this case, e.g. for the JAVA code below on aarch64,
> assembler call `__ ushr(dst, __ T8B, src, 0)`, the instruction generated is not `ushr dst.8B, src.8B, 0`, but `ushr dst.4H, src.4H, 16` instead.
> According to local tests, JVM gives wrong results for byte/short and crashes with SIGILL for integer/long.
> ByteVector vba = ByteVector.fromArray(byte64SPECIES, bytesA, 8 * i);
> vbb.lanewise(VectorOperators.ASHR, 8).intoArray(arrBytes, 8 * i);
> 
> The legal right shift amount should be in the range 1 to the element width in bits on aarch64:
> https://developer.arm.com/documentation/dui0801/f/A64-SIMD-Vector-Instructions/USHR--vector-?lang=en
> 
> This fix handles zero shift separately. If the shift is zero, it generates `orr` for right shift, `addv` for right shift and accumulate.
> Verified with linux-aarch64-server-fastdebug, tier1. Also created a jtreg to reproduce the issue and for regression tests.

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  refactor tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2472/files
  - new: https://git.openjdk.java.net/jdk/pull/2472/files/9290f27e..24d6e9f8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2472&range=09-10

  Stats: 422 lines in 1 file changed: 16 ins; 222 del; 184 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2472/head:pull/2472

PR: https://git.openjdk.java.net/jdk/pull/2472

From dongbo at openjdk.java.net  Fri Feb 26 06:13:39 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 26 Feb 2021 06:13:39 GMT
Subject: RFR: 8261142: AArch64: Incorrect instruction encoding when
 right-shifting vectors with shift amount equals to the element width [v11]
In-Reply-To: <9rtmEMrsPaA73FDA-KB7H0S0CRdBePGwnI5FcDY-OLI=.425249e2-b590-4a16-b9b8-8d7b5ecd2800@github.com>
References: <fHxu3JO_RrkXCGtobzjj_zxu1xgsizvN-UWtMgiYD6M=.8f5755c1-d80f-47bf-b67e-178aefe93787@github.com>
 <8kMxMFAYtb0B-yUVEt-HLfhji3Gj-gog8OHvWW_tKfw=.f7c9422b-3574-4c31-9489-7286ee98332f@github.com>
 <z_gVJyVbmos-6bUwGeSGWhqFz4Iku6ghuBC4CqE1ql4=.5cf04e1f-03b5-4b59-9b01-9db2e0082dde@github.com>
 <BlOlxuz8EYot1Utx13ETlVqmsVG-L5BNzAROHFTq8hA=.330113a8-fd0f-495b-925b-f14bf750aa43@github.com>
 <G61s0RHBJaH52Nt11W3l870l4BW_86OETpSmZAX3uWg=.66e1ba1b-0de6-462d-9c7d-4acd9e3b34b4@github.com>
 <9rtmEMrsPaA73FDA-KB7H0S0CRdBePGwnI5FcDY-OLI=.425249e2-b590-4a16-b9b8-8d7b5ecd2800@github.com>
Message-ID: <BK2cv_crw5FGsLtdvAB13S1ISpc5UFeBMQlJo5nJxVY=.093a5f14-d305-4591-9ce7-9856d97e6100@github.com>

On Thu, 25 Feb 2021 01:44:27 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>>> > Local tests by manually injected error shows all instructions are covered by the jtreg case. Suggestions?
>>> 
>>> I'm not seeing `sra` used anywhere.
>>> 
>>> The problem I see with the tests is that the methods are large. This causes C2 to do a lot of spilling. Also, because the resuling code is intertwined and complex, it's very hard to debug.
>>> 
>>> It would be far better to do something like this:
>>> 
>>> ```
>>>     void long_shift_add(long arrLongs[][], LongVector vba, LongVector vbb, int i) {
>>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 37)).intoArray(arrLongs[op], 2 * i);
>>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 64)).intoArray(arrLongs[op  + 1], 2 * i);
>>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 99)).intoArray(arrLongs[op  + 2], 2 * i);
>>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 128)).intoArray(arrLongs[op + 3], 2 * i);
>>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 157)).intoArray(arrLongs[op + 4], 2 * i);
>>>         vba.add(vbb.lanewise(VectorOperators.LSHR, 192)).intoArray(arrLongs[op + 5], 2 * i);
>>>     }
>>> ```
>> 
>> 
>> Weird, I took a look at the the assembly, `ssra` did accessed by the tests on our server:
>> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 64 &> assembly_vlen64.txt
>> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 128 &> assembly_vlen128.txt
>> $ cat assembly_vlen*.txt | grep "ssra"
>> 02c0    ssra    V18, V17, #37   # vector (2D)
>> 02c8    ssra    V19, V17, #0    # vector (2D)
>> 02d0    ssra    V20, V17, #35   # vector (2D)
>> 0308    ssra    V18, V17, #29   # vector (2D)
>> 0644    ssra    V18, V17, #37   # vector (2D)
>> 064c    ssra    V19, V17, #0    # vector (2D)
>> 0654    ssra    V20, V17, #35   # vector (2D)
>> 0674    ssra    V18, V17, #29   # vector (2D)
>> 0798    ssra    V18, V17, #37   # vector (2D)
>> 07a0    ssra    V19, V17, #0    # vector (2D)
>> 07a8    ssra    V20, V17, #35   # vector (2D)
>> 07e0    ssra    V18, V17, #29   # vector (2D)
>>   0x0000ffff83f7e500:   ssra    v18.2d, v17.2d, #37         ;*aload_0 {reexecute=0 rethrow=0 return_oop=0}
>>   0x0000ffff83f7e510:   ssra    v20.2d, v17.2d, #35         ;*iand {reexecute=0 rethrow=0 return_oop=0}
>>   0x0000ffff83f7e548:   ssra    v18.2d, v17.2d, #29         ;*if_icmpne {reexecute=0 rethrow=0 return_oop=0}
>>   0x0000ffff83f7e884:   ssra    v18.2d, v17.2d, #37
>>   0x0000ffff83f7e894:   ssra    v20.2d, v17.2d, #35
>>   0x0000ffff83f7e8b4:   ssra    v18.2d, v17.2d, #29
>>   0x0000ffff83f7e9d8:   ssra    v18.2d, v17.2d, #37         ;*invokestatic broadcastInt {reexecute=0 rethrow=0 return_oop=0}
>>   0x0000ffff83f7e9e8:   ssra    v20.2d, v17.2d, #35         ;*invokestatic broadcastInt {reexecute=0 rethrow=0 return_oop=0}
>>   0x0000ffff83f7ea20:   ssra    v18.2d, v17.2d, #29         ;*checkcast {reexecute=0 rethrow=0 return_oop=0}
>> 284     ssra    V18, V17, #9    # vector (4S)
>> 28c     ssra    V19, V17, #0    # vector (4S)
>> 294     ssra    V20, V17, #15   # vector (4S)
>>   0x0000ffff83f822c4:   ssra    v18.4s, v17.4s, #9          ;*invokedynamic {reexecute=0 rethrow=0 return_oop=0}
>>   0x0000ffff83f822d4:   ssra    v20.4s, v17.4s, #15
>> 284     ssra    V18, V17, #1    # vector (8H)
>> 28c     ssra    V19, V17, #8    # vector (8H)
>> ...
>> 
>> Also injected error to `sshr+add` by:
>> --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
>> +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
>> @@ -545,7 +545,7 @@ public:
>>  #define WRAP(INSN)                                                                \
>>    void INSN(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn, int shift) {  \
>>      if (shift == 0) {                                                             \
>> -      Assembler::addv(Vd, T, Vd, Vn);                                             \
>> +      Assembler::subv(Vd, T, Vd, Vn);                                             \
>>      } else {                                                                      \
>>        Assembler::INSN(Vd, T, Vn, shift);                                          \
>>      }                                                                             \
>> The `shift+add` tests failed as expected:
>> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:-TieredCompilation test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 64
>> WARNING: Using incubator modules: jdk.incubator.vector
>> warning: using incubating module(s): jdk.incubator.vector
>> 1 warning
>> Exception in thread "main" java.lang.RuntimeException: Test Failed, failed tests:
>> type SHORT index 19, operation ASHR_AND_ACCUMULATE, vector length 64.
>> type SHORT index 21, operation ASHR_AND_ACCUMULATE, vector length 64.
>> type SHORT index 23, operation ASHR_AND_ACCUMULATE, vector length 64.
>> type SHORT index 25, operation LSHR_AND_ACCUMULATE, vector length 64.
>> type SHORT index 27, operation LSHR_AND_ACCUMULATE, vector length 64.
>> type SHORT index 29, operation LSHR_AND_ACCUMULATE, vector length 64.
>> type INTEGER index 19, operation ASHR_AND_ACCUMULATE, vector length 64.
>> type INTEGER index 21, operation ASHR_AND_ACCUMULATE, vector length 64.
>> type INTEGER index 23, operation ASHR_AND_ACCUMULATE, vector length 64.
>> type INTEGER index 25, operation LSHR_AND_ACCUMULATE, vector length 64.
>> type INTEGER index 27, operation LSHR_AND_ACCUMULATE, vector length 64.
>> type INTEGER index 29, operation LSHR_AND_ACCUMULATE, vector length 64.
>> ...
>> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:CompileThreshold=1000 -XX:-TieredCompilation test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java 128
>> WARNING: Using incubator modules: jdk.incubator.vector
>> warning: using incubating module(s): jdk.incubator.vector
>> 1 warning
>> Exception in thread "main" java.lang.RuntimeException: Test Failed, failed tests:
>> type LONG index 49, operation ASHR_AND_ACCUMULATE, vector length 128.
>> type LONG index 51, operation ASHR_AND_ACCUMULATE, vector length 128.
>> type LONG index 53, operation ASHR_AND_ACCUMULATE, vector length 128.
>> type LONG index 55, operation LSHR_AND_ACCUMULATE, vector length 128.
>> type LONG index 57, operation LSHR_AND_ACCUMULATE, vector length 128.
>> type LONG index 59, operation LSHR_AND_ACCUMULATE, vector length 128.
>> type SHORT index 49, operation ASHR_AND_ACCUMULATE, vector length 128.
>> type SHORT index 51, operation ASHR_AND_ACCUMULATE, vector length 128.
>> type SHORT index 53, operation ASHR_AND_ACCUMULATE, vector length 128.
>> ...
>> 
>> Anyway, I extracted operations you suggested into `shift_op_*` methods.
>> Performed the error-injected experiments with the new tests on Kunpeng916 and re-checked the assembly output, results looks good.
>> 
>> The test command I used to run the newest tests are:
>> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:-TieredCompilation -XX:CompileThreshold=1000 -Dvlen=64 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java &> assembly_vlen64.txt
>> $ ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java --add-modules jdk.incubator.vector -XX:-TieredCompilation -XX:CompileThreshold=1000 -Dvlen=128 -XX:CompileCommand=print,compiler/vectorapi/TestVectorShiftImm.shift_* test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java &> assembly_vlen128.txt
>> $ cat assembly_vlen64.txt | grep ssra; cat assembly_vlen128.txt | grep ssra
>
>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-compiler-dev](mailto:hotspot-compiler-dev at openjdk.java.net):_
>> 
>> On 24/02/2021 07:33, Dong Bo wrote:
>> 
>> > Weird, I took a look at the the assembly, `ssra` did accessed by the tests on our server:
>> 
>> I don't doubt it, but the test code is so very complex that it can
>> fall foul of heuristics given slightly changed circumstances. That's
>> why good test cases are as simple as possible, and allow no room for
>> variations because they do only one thing. Precise targeting should
>> be the goal of HotSpot back-end test cases.
>>
>  
> Understood, thanks. :-)
> Does the newest version address the concern?
> I extracted the `shift`/`shift+add` operations into separate methods, mostly as suggested in previous comments, something like:
>     static int shift_op_long_ASHR_and_ADD(LongVector vba, LongVector vbb, long arrLongs[][], int end, int ind) {
>         vba.add(vbb.lanewise(VectorOperators.ASHR, 37)).intoArray(arrLongs[end++], ind);
>         vba.add(vbb.lanewise(VectorOperators.ASHR, 64)).intoArray(arrLongs[end++], ind);
>         vba.add(vbb.lanewise(VectorOperators.ASHR, 99)).intoArray(arrLongs[end++], ind);
>         vba.add(vbb.lanewise(VectorOperators.ASHR, 128)).intoArray(arrLongs[end++], ind);
>         vba.add(vbb.lanewise(VectorOperators.ASHR, 157)).intoArray(arrLongs[end++], ind);
>         vba.add(vbb.lanewise(VectorOperators.ASHR, 192)).intoArray(arrLongs[end++], ind);
>         return end;
>     }

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-compiler-dev](mailto:hotspot-compiler-dev at openjdk.java.net):_
> 
> 
> I don't doubt it, but the test code is so very complex that it can
> fall foul of heuristics given slightly changed circumstances. That's
> why good test cases are as simple as possible, and allow no room for
> variations because they do only one thing. Precise targeting should
> be the goal of HotSpot back-end test cases.
> 

Test updated, all the operations to test are put in overloaded functions, `shift_with_op` and `shift_with_op_and_add`, repeatly called and tested by `shift` and `shift_and_accumulate` repectively with a loop.
Commands below are used to verify that `ssra` is accessed:
$ cp hsdis-aarch64.so ./build/linux-aarch64-server-fastdebug/images/jdk/lib/
$ jtreg -verbose:all -J-Djavatest.maxOutputSize=50000000 test/hotspot/jtreg/compiler/vectorapi/TestVectorShiftImm.java | grep ssra

The tests do use `ssra` on our two different platforms, Kunpeng916 and Kunpeng920:
2b4 +   ssra    V16, V20, #17   # vector (2S)
2bc +   ssra    V17, V20, #0    # vector (2S)
2c4 +   ssra    V18, V20, #21   # vector (2S)
310 +   ssra    V16, V20, #12   # vector (2S)
  0x0000ffff9894e0f4:   ssra    v16.2s, v20.2s, #17         ;*invokespecial fromArray0Template {reexecute=0 rethrow=0 return_oop=0}
  0x0000ffff9894e104:   ssra    v18.2s, v20.2s, #21         ;*invokestatic arrayAddress {reexecute=0 rethrow=0 return_oop=0}
  0x0000ffff9894e150:   ssra    v16.2s, v20.2s, #12         ;*checkcast {reexecute=0 rethrow=0 return_oop=0}
2b0 +   ssra    V16, V20, #9    # vector (4H)
2b8 +   ssra    V17, V20, #0    # vector (4H)
2c0 +   ssra    V18, V20, #11   # vector (4H)
  0x0000ffff9894ae70:   ssra    v16.4h, v20.4h, #9          ;*invokevirtual vspecies {reexecute=0 rethrow=0 return_oop=0}
  0x0000ffff9894ae80:   ssra    v18.4h, v20.4h, #11         ;*invokestatic arrayAddress {reexecute=0 rethrow=0 return_oop=0}
: #     out( N1802 ) <- 298in( R29,  + R25B70, ssra    V16 ) #7
 + a4c     ssra         V17 + , spill V20, #0   # vector (8B)
        mov ssra    a4cV18R1 + , spill V20R11 -> [sp, #12],     # spill size = 32,
ssra    V16, V20, d08#3         # vector (8B)B150
...

Any comments?
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2472

From vlivanov at openjdk.java.net  Fri Feb 26 08:22:53 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 26 Feb 2021 08:22:53 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class [v2]
In-Reply-To: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
Message-ID: <43tPmPoboooVq-05u97kPDJqwV7uesF8l5AmHy8kJwE=.b46992f1-eb9d-46a3-8048-04659d529da3@github.com>

> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
> 
> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
> 
> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
> 
> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
> 
> Testing:
> - [x] hs-tier1 - hs-tier8
> - [x] additional verification that CHA decisions aren't affected

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Move ClassHierarchyIterator::next() into CPP file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2630/files
  - new: https://git.openjdk.java.net/jdk/pull/2630/files/ae78e51e..7237e9c5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2630&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2630&range=00-01

  Stats: 39 lines in 2 files changed: 21 ins; 17 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2630/head:pull/2630

PR: https://git.openjdk.java.net/jdk/pull/2630

From vlivanov at openjdk.java.net  Fri Feb 26 08:22:54 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 26 Feb 2021 08:22:54 GMT
Subject: RFR: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class [v2]
In-Reply-To: <Ns-Tfx2SKmW2ZgaUsm_Z3y_oUhWaTOsCDkecMYdSxHw=.a09fedc1-78ce-4c22-801e-a0d32b17a14d@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
 <Ns-Tfx2SKmW2ZgaUsm_Z3y_oUhWaTOsCDkecMYdSxHw=.a09fedc1-78ce-4c22-801e-a0d32b17a14d@github.com>
Message-ID: <cKsyhAzPth2BJOx0jN2hYrpJfgDI683Pt7_mhgMhlpY=.831f72da-2659-4edd-9bc6-c2f59770404a@github.com>

On Fri, 19 Feb 2021 15:52:32 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move ClassHierarchyIterator::next() into CPP file
>
> Looks good! (move next() to cpp file if you want to)

Thanks for the review, Erik. 

(Moved ClassHierarchyIterator::next() into CPP file as you suggested.)

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From vlivanov at openjdk.java.net  Fri Feb 26 08:22:54 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 26 Feb 2021 08:22:54 GMT
Subject: Integrated: 8261954: Dependencies: Improve iteration over class
 hierarchy under context class
In-Reply-To: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
References: <Lyef5AFB1XyzJ1sb-Dzx0DQs49QI6Q_UTl9guTNSCcw=.e443b2c2-d33f-4ad3-ba10-c60c244f2336@github.com>
Message-ID: <0IXN29kR2y1UNU4HM_mpf6E9GTRuRNWRWHM2WeywQ9A=.f67b9582-79f3-4ffb-9621-5f87a68b00bd@github.com>

On Thu, 18 Feb 2021 17:05:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
> 
> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
> 
> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
> 
> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
> 
> Testing:
> - [x] hs-tier1 - hs-tier8
> - [x] additional verification that CHA decisions aren't affected

This pull request has now been integrated.

Changeset: 0a4e710f
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a4e710f
Stats:     173 lines in 3 files changed: 68 ins; 69 del; 36 mod

8261954: Dependencies: Improve iteration over class hierarchy under context class

Reviewed-by: kvn, coleenp, eosterlund

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

PR: https://git.openjdk.java.net/jdk/pull/2630

From thartmann at openjdk.java.net  Fri Feb 26 10:49:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 26 Feb 2021 10:49:42 GMT
Subject: RFR: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set [v9]
In-Reply-To: <s1cVE9vyCLiv_M3eS3U17dfjA0DgrpbzBaEqDPWqkxo=.659774fa-7900-434d-b9b9-5b3acb98261d@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
 <s1cVE9vyCLiv_M3eS3U17dfjA0DgrpbzBaEqDPWqkxo=.659774fa-7900-434d-b9b9-5b3acb98261d@github.com>
Message-ID: <CNwqWrznTjV0jyHg-dZWLkmwvo-z7QjBSz6FHlS2jEU=.4d10a24e-76d4-49a4-a220-90b2e04db58d@github.com>

On Thu, 25 Feb 2021 08:56:14 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
>> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
>> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
>> 
>> Before:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
>> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
>> - string: "a"
>> :Constant:exact *
>> 
>> After:
>> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set
>   
>   update comments based on the review feedbacks.
>   move the unittest to test_stringUtil.cpp.

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2178

From xliu at openjdk.java.net  Fri Feb 26 10:49:42 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 26 Feb 2021 10:49:42 GMT
Subject: Integrated: 8260198: TypeInstPtr::dump2() emits multiple lines if
 Verbose is set
In-Reply-To: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
References: <A52jqHCs7Youp_G1AMNZ5-OqTXmFMOAiRLvzAJUp0dc=.dc31e3bb-eccc-4180-96da-1a464bae895e@github.com>
Message-ID: <xSx9a20pP9QfEiaIWE1Ni717BmlMwtCHXM94y6jrMmM=.d2ec3bc6-efa9-4f40-995c-9018ca2d012b@github.com>

On Thu, 21 Jan 2021 08:47:13 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Add a flag _suppress_cr to outputStream. outstream objects won't emit any CR if it's set.
> Correct TypeInstPtr::dump2 to make sure it only emits klass name once.
> Remove the comment because Klass::oop_print_on() has emitted the address of oop.
> 
> Before:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java/lang/Stringjava.lang.String
> {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String'
> - string: "a"
> :Constant:exact *
> 
> After:
> 689  ConP  ===  0  [[ 821 ]]   Oop:java.lang.String {0x000000010159d7c8} - klass: public final synchronized 'java/lang/String' - string: "a":Constant:exact *

This pull request has now been integrated.

Changeset: 76032781
Author:    Xin Liu <xliu at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/76032781
Stats:     55 lines in 2 files changed: 51 ins; 1 del; 3 mod

8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/2178

From vlivanov at openjdk.java.net  Fri Feb 26 13:57:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 26 Feb 2021 13:57:40 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v4]
In-Reply-To: <Ogd9bO2tWac2Kds7hEeMqQEmHIyxOkM0yxwQwPeidc0=.0410848c-a82c-4f94-9962-00e358032130@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <Ogd9bO2tWac2Kds7hEeMqQEmHIyxOkM0yxwQwPeidc0=.0410848c-a82c-4f94-9962-00e358032130@github.com>
Message-ID: <azW9yo1dtnIS35nO7WNSSj2Ug_nHNpz7FkYnqc-Usb4=.89117e57-ab63-4af4-9b9e-c8073c8e82eb@github.com>

On Fri, 26 Feb 2021 02:38:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Vector API fails to work when:
>>  - case 1: MaxVectorSize is set to <=8, or
>>  - case 2: C2 is disabled
>> 
>> The reason is that {max/preferred} VectorShape initialization fails in both cases.
>> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
>> 
>> Vector API should not depend on C2 to run.
>> It should work even there is no JIT compiler since it's a Java-level api.
>> So let's fix it.
>> 
>> Testing:
>>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove -XX:TieredStopAtLevel=3

IMO the fix should be in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java`.

JVM does the right job when it signals vector support is absent (by returning `-1`).

`jdk.incubator.vector` implementation should take that into account and choose a preferred shape for pure Java execution mode.

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

Changes requested by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Fri Feb 26 15:39:42 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 26 Feb 2021 15:39:42 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v4]
In-Reply-To: <azW9yo1dtnIS35nO7WNSSj2Ug_nHNpz7FkYnqc-Usb4=.89117e57-ab63-4af4-9b9e-c8073c8e82eb@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <Ogd9bO2tWac2Kds7hEeMqQEmHIyxOkM0yxwQwPeidc0=.0410848c-a82c-4f94-9962-00e358032130@github.com>
 <azW9yo1dtnIS35nO7WNSSj2Ug_nHNpz7FkYnqc-Usb4=.89117e57-ab63-4af4-9b9e-c8073c8e82eb@github.com>
Message-ID: <4nqS6MYId9oNEztpqjrqKivgX7j0D_9hfqSdOXcbKrA=.4ecc4948-8924-4308-b2a3-c98491de3f8e@github.com>

On Fri, 26 Feb 2021 13:55:15 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> IMO the fix should be in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java`.
> 
> JVM does the right job when it signals vector support is absent (by returning `-1`).
> 
> `jdk.incubator.vector` implementation should take that into account and choose a preferred shape for pure Java execution mode.

Hi @iwanowww ,

Thanks for your review.

>From the view of C2 compiler, you are right.

But the Java programmer may be confused if we got something like DoubleVector.SPECIES_PREFERRED.length() > VectorSupport.getMaxLaneCount(double.class).
I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= VectorSupport.getMaxLaneCount(double.class) for Java programmers since the VectorSupport_GetMaxLaneCount is used to implement a Java API.

What do you think?
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From vlivanov at openjdk.java.net  Fri Feb 26 15:50:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 26 Feb 2021 15:50:41 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v4]
In-Reply-To: <4nqS6MYId9oNEztpqjrqKivgX7j0D_9hfqSdOXcbKrA=.4ecc4948-8924-4308-b2a3-c98491de3f8e@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <Ogd9bO2tWac2Kds7hEeMqQEmHIyxOkM0yxwQwPeidc0=.0410848c-a82c-4f94-9962-00e358032130@github.com>
 <azW9yo1dtnIS35nO7WNSSj2Ug_nHNpz7FkYnqc-Usb4=.89117e57-ab63-4af4-9b9e-c8073c8e82eb@github.com>
 <4nqS6MYId9oNEztpqjrqKivgX7j0D_9hfqSdOXcbKrA=.4ecc4948-8924-4308-b2a3-c98491de3f8e@github.com>
Message-ID: <XTGGdEvpSQXI_MCMcN5KEb7bmgt6fIAJzYthGzxg7mM=.f6adc7cc-87b1-4ecf-a862-8aa076573cec@github.com>

On Fri, 26 Feb 2021 15:37:08 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= VectorSupport.getMaxLaneCount(double.class) for Java programmers since the VectorSupport_GetMaxLaneCount is used to implement a Java API.

It doesn't make much sense to me. `VectorSupport` is an internal API for `jdk.incubator.vector` to consume.
It's `jdk.incubator.vector` job to interpret the result and adapt accordingly.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From vlivanov at openjdk.java.net  Fri Feb 26 16:10:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 26 Feb 2021 16:10:41 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v4]
In-Reply-To: <N7hhVL_EFkcEeL_roxCLbrJA-gMH41AkNdxDT5JURZw=.5e4cf95f-c305-4c44-a13c-9518d241e916@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
 <5M1DPgw-V-j9acOvHLewPoTaxF-a6-9HMIpIzHjqavU=.55831da6-f888-4dc0-beee-19869c5eb638@github.com>
 <NxLAxfTal2oKzbLe--PSJlA_3vGKR1TK5pS8dH5JMLc=.482881ea-0f16-4c33-b475-1d626e0e4939@github.com>
 <N7hhVL_EFkcEeL_roxCLbrJA-gMH41AkNdxDT5JURZw=.5e4cf95f-c305-4c44-a13c-9518d241e916@github.com>
Message-ID: <PrEBgCpxQkEZ-Eo__0z6pOdqAzUv7sP67DQ31o09-ck=.f36c4ee4-10b2-4af3-a5fd-3098397c1194@github.com>

On Thu, 25 Feb 2021 10:06:47 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Thanks for addressing the comments! Looks good.
>
> @JornVernee I'm not clear that your response addresses my point. I'm concerned that a thread stack dump reported by serviceability code may contain an extra frame for the stub call. This could occur while the Java thread is still in native and it could also include the case wher the native call re-enters into Java i.e. the extra frame could appear at the top of the stack dump or interleaved between Java method frames.
> 
> I don't see how that problem is mitigated by your suggestion that this only relates to Panama API use. Code which consumes any such stack dump (incluing 3rd party code) that might be affected by the presence of this extra frame will not care (or even be aware) that the native callout is a Panama call.
> 
> Anyway, since no one from the serviceability team has noted this as a potential problem I'm ok to see the patch proceed.

Overall, the fix looks good. 

At some point, there was no frame for native invoker set up and native state transitions were put inline in generated code, but that was rewritten.

Regarding the refactorings: I find newly introduced `spill_register()`/`fill_register()` methods very confusing. 
I'd prefer to see `spill_output_registers()`/`fill_output_registers()` instead and an assert in `NativeInvokerGenerator` constructor (akin to the one in `NativeInvokerGenerator::generate()` on x86_64): 
  assert(_output_registers.length() <= 1
    || (_output_registers.length() == 2 && !_output_registers.at(1)->is_valid()), "no multi-reg returns");

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

PR: https://git.openjdk.java.net/jdk/pull/2528

From vlivanov at openjdk.java.net  Fri Feb 26 16:10:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 26 Feb 2021 16:10:40 GMT
Subject: RFR: 8259937: guarantee(loc != NULL) failed: missing saved
 register with native invoker [v4]
In-Reply-To: <5M1DPgw-V-j9acOvHLewPoTaxF-a6-9HMIpIzHjqavU=.55831da6-f888-4dc0-beee-19869c5eb638@github.com>
References: <krl6Q3x3h3MKCRkqCwUfZ6gfeuvG-TtQaCw9Tjm98vk=.f90f6e6a-5d3c-4a4c-81d3-548db38c4f0a@github.com>
 <5M1DPgw-V-j9acOvHLewPoTaxF-a6-9HMIpIzHjqavU=.55831da6-f888-4dc0-beee-19869c5eb638@github.com>
Message-ID: <pJY0rpRVhuyY7bCOWQDFm6zxbcAnN-WxXODydNcMPsY=.cc46384c-f37f-443a-91d4-bf53e986c288@github.com>

On Wed, 24 Feb 2021 16:12:59 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> We spotted this issue with Shenandoah and I managed to write a simple
>> test case that reproduces it reliably with Shenandoah but the issue is
>> independent of the GC.
>> 
>> The loop in the test case calls a native invoker with an oop live in
>> rbp. rbp is saved in the native invoker stub's frame. A safepoint is
>> triggered from the safepoint check in the native invoker. The stack
>> walking code sees that rbp contains an oop but can't find where that
>> oop is stored. That's because stack walking updates the caller's frame
>> with the location of rbp in the callee on calls to
>> frame::sender(). But the current code sets the last java frame to be
>> the compiled frame where rbp is live. So there's no call to
>> frame::sender() to update the location rbp. The fix I propose is that
>> the frame of the native invoker be visible by stack walking. On a
>> safepoint, stack walking starts from the native invoker thread, then
>> calls frame::sender() to move to the compiled frame. That causes rbp
>> to be properly recorded with its location in the native invoker frame.
>> 
>> Same problem affects both x86 and aarch64. I've tested this patch with:
>> 
>> make run-test TEST="java/foreign" TEST_VM_OPTS="-Xcomp" JTREG="TIMEOUT_FACTOR=10"
>> 
>> on both platforms.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "test & debug"
>   
>   This reverts commit cb9dd24c9fcccc6997e9fca874e2860f966b9576.

Marked as reviewed by vlivanov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2528

From jiefu at openjdk.java.net  Sat Feb 27 03:23:12 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 27 Feb 2021 03:23:12 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v5]
In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
Message-ID: <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com>

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Fix in jdk/incubator/vector/VectorShape.java
 - Merge branch 'master' into JDK-8262096
 - Revert changes
 - Remove -XX:TieredStopAtLevel=3
 - Update the jtreg test
 - The numerator should be 8 (byte)
 - 8262096: Vector API fails to work due to VectorShape initialization exception

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2722/files
  - new: https://git.openjdk.java.net/jdk/pull/2722/files/bbe6150c..b67b232d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=03-04

  Stats: 7047 lines in 380 files changed: 3707 ins; 1675 del; 1665 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Sat Feb 27 03:26:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 27 Feb 2021 03:26:41 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v4]
In-Reply-To: <XTGGdEvpSQXI_MCMcN5KEb7bmgt6fIAJzYthGzxg7mM=.f6adc7cc-87b1-4ecf-a862-8aa076573cec@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <Ogd9bO2tWac2Kds7hEeMqQEmHIyxOkM0yxwQwPeidc0=.0410848c-a82c-4f94-9962-00e358032130@github.com>
 <azW9yo1dtnIS35nO7WNSSj2Ug_nHNpz7FkYnqc-Usb4=.89117e57-ab63-4af4-9b9e-c8073c8e82eb@github.com>
 <4nqS6MYId9oNEztpqjrqKivgX7j0D_9hfqSdOXcbKrA=.4ecc4948-8924-4308-b2a3-c98491de3f8e@github.com>
 <XTGGdEvpSQXI_MCMcN5KEb7bmgt6fIAJzYthGzxg7mM=.f6adc7cc-87b1-4ecf-a862-8aa076573cec@github.com>
Message-ID: <rQP1PKIzwU6sq39dY_huBvUZayLZjjBTdXK1YUP0TUQ=.040a9103-9e34-48fa-ad2f-f987f8ca1532@github.com>

On Fri, 26 Feb 2021 15:48:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= VectorSupport.getMaxLaneCount(double.class) for Java programmers since the VectorSupport_GetMaxLaneCount is used to implement a Java API.
> 
> It doesn't make much sense to me. `VectorSupport` is an internal API for `jdk.incubator.vector` to consume.
> It's `jdk.incubator.vector` job to interpret the result and adapt accordingly.

Okay, I'm fine to fix it in jdk/incubator/vector/VectorShape.java if we don't keep something like that.

For the updated fix, the {max/preferred} shape will be initialized as shape-64-bit if hotspot doesn't support vectorization.

Testing:
  - jdk/incubator/vector with MaxVectorSize=default/8/4 on Linux/x64 
  - jdk/incubator/vector without C2 on Linux/x64

Any comments?
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From whuang at openjdk.java.net  Sat Feb 27 07:00:45 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 27 Feb 2021 07:00:45 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
Message-ID: <aaPca2POYql-mSs_w8GVRBHmdaOSelvL-LzOhVeYiXU=.352c8b4d-d941-4edb-8a59-791c05bbfb7c@github.com>

On Fri, 5 Feb 2021 07:29:00 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
>> @Benchmark
>> public void testMethod(Blackhole bh) {
>>   int sum = 0;
>>   for (int i = 0; i < data.length; i++) {
>>       Integer ii = Integer.valueOf(data[i]);
>>       if (i < data.length) {
>>           sum += ii.intValue();
>>       }
>>   }
>>   bh.consume(sum);
>> }
>> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
>> The uncommon_trap is generated by the optimized "if", because its condition is always true.
>> 
>> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
>> and deleting the use of box:
>> 
>> There is no additional fail/error(s) of jtreg after this patch.
>> 
>> I adjust my codes and add a new benchmark
>> 
>> public class MyBenchmark {
>> 
>>     static int[] data = new int[10000];
>> 
>>     static {
>>         for(int i = 0; i < data.length; ++i) {
>>             data[i] = i * 1337 % 7331;
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void testMethod(Blackhole bh) {
>>       int sum = 0;
>>       for (int i = 0; i < data.length; i++) {
>>           Integer ii = Integer.valueOf(data[i]);
>>           black();
>>           if (i < 100000) {
>>               sum += ii.intValue();
>>           }
>>       }
>>       bh.consume(sum);
>>     }
>> 
>>     public void black(){}
>> }
>> 
>> 
>> aarch64:  
>> base line?
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  88.513        1.111  us/op
>> 
>> opt?
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  52.776        0.096  us/op
>> 
>> x86:  
>> base line?
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  81.066        3.156  us/op
>> 
>> opt:
>> Benchmark                     Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testMethod    avgt       30  55.596        0.775  us/op
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor codes

> Please, add test case which verifies that Box is scalarized by forking process and checking output of run with `-XX:+PrintEliminateAllocations` flag.
> You also need a test which triggers deoptimization and execute code for Box object reallocation/initialization or load from cache.
> A test should also verifies that box object identity matches after deoptimization in case when object is loaded from cache.

OK. I will add these test cases.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From whuang at openjdk.java.net  Sat Feb 27 07:00:46 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 27 Feb 2021 07:00:46 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <doyhn0k7V_F4yEj4GE_vhuGwLTeWA7qZHkyLfAHB9BE=.27014166-5ca9-44d1-a0a2-38cb805f46e8@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
 <doyhn0k7V_F4yEj4GE_vhuGwLTeWA7qZHkyLfAHB9BE=.27014166-5ca9-44d1-a0a2-38cb805f46e8@github.com>
Message-ID: <vK6Salm1-t234gLXAnXzT5DqEvlqxJCTz_KISigwGk8=.ab311f3b-a51d-4ddb-8e7d-3703e89d5730@github.com>

On Tue, 9 Feb 2021 00:56:42 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor codes
>
> src/hotspot/share/opto/callGenerator.cpp line 586:
> 
>> 584:         ciInstanceKlass* klass = call->as_CallStaticJava()->method()->holder();
>> 585:         int n_fields = klass->nof_nonstatic_fields();
>> 586:         assert(n_fields == 1, "sanity");
> 
> I think you  also need to check the only non-static field of klass must be a scalar.
> "sanity" is too concise. I think we should leave a message to say it's an auto-boxing class.

Yes. I will revise that. Thank you.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From whuang at openjdk.java.net  Sat Feb 27 07:00:46 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 27 Feb 2021 07:00:46 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v2]
In-Reply-To: <A4DIcIM6EGwSqzCytISMY0EvWc-D09fobC15PJS3HWw=.7829876e-26ab-4e7b-b2a3-d8a9d6d4a81f@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <UKlynUyzlPdDeLqflwD98itANbyUMrLxbMzRwQVl3iQ=.ea6b7976-5b32-4947-a442-19f12aa951d8@github.com>
 <A4DIcIM6EGwSqzCytISMY0EvWc-D09fobC15PJS3HWw=.7829876e-26ab-4e7b-b2a3-d8a9d6d4a81f@github.com>
Message-ID: <fGI_HPc7DBCwfbPY2shS9e6QgMrgAdAsvvDxUpH_T8w=.8822ad39-96ee-4784-8712-72e2b40db0ed@github.com>

On Mon, 8 Feb 2021 18:27:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor codes
>
> src/hotspot/share/opto/callGenerator.cpp line 591:
> 
>> 589:         Node* sobj = new SafePointScalarObjectNode(gvn.type(res)->isa_oopptr(),
>> 590: #ifdef ASSERT
>> 591:                                                   NULL,
> 
> I would suggest to record `call` node here treating it as allocation.

The prototype of the constuctor is  `SafePointScalarObjectNode(const TypeOopPtr* , AllocateNode* , uint, uint)`. However , `call` here is  a `CallStaticJavaNode *` instead of `AllocateNode *`. Do you mean that we just pass the `call` as a record here?

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From whuang at openjdk.java.net  Sat Feb 27 07:00:49 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 27 Feb 2021 07:00:49 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v5]
In-Reply-To: <bDAHGAltLV3xaHlg-YprlnsVgYAZxk_nCSnjMBr5uWY=.04d47d7f-cdb7-46a5-a375-a8d4aa5616e4@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <39-V5pqzlgXaCnL3KTIBXvHwrt35rn4WuuknDv8dcuU=.178fe7a3-4b2b-415c-aaa5-ad63598daeb3@github.com>
 <bDAHGAltLV3xaHlg-YprlnsVgYAZxk_nCSnjMBr5uWY=.04d47d7f-cdb7-46a5-a375-a8d4aa5616e4@github.com>
Message-ID: <pt7DMorFpJrxi0KliXVSeBnKVcPUoNuiJFqCrFBGCeA=.83fa1410-6ebb-4979-b5bd-6f37725710de@github.com>

On Wed, 24 Feb 2021 07:06:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add debuginfo optimization
>
> src/hotspot/share/opto/callGenerator.cpp line 561:
> 
>> 559:   if (resproj != nullptr && call->is_CallStaticJava() &&
>> 560:       call->as_CallStaticJava()->is_boxing_method()) {
>> 561:     Unique_Node_List debuginfo_node_list;
> 
> Maybe rename this to `safepoints`.

Sure.

> src/hotspot/share/opto/callGenerator.cpp line 569:
> 
>> 567:         for (uint i = 0; i < dbg_start; i++) {
>> 568:           if (sfpt->in(i) == resproj) {
>> 569:             return;
> 
> I think this code can be replaced by:
>   if (!sfpt->is_Call() || !sfpt->as_Call()->has_non_debug_use(n)) {
>     safepoints.push(sfpt);
>   } else {
>     ...
>   }

Yes, I will do that.

> src/hotspot/share/opto/callGenerator.cpp line 656:
> 
>> 654:   }
>> 655: 
>> 656:   replace_box_to_scalar(call, callprojs.resproj);
> 
> Should this be guarded by `C->eliminate_boxing()`?

Exactly. I will change that.

> src/hotspot/share/opto/callnode.hpp line 503:
> 
>> 501:                      // It is relative to the last (youngest) jvms->_scloff.
>> 502:   uint _n_fields;    // Number of non-static fields of the scalarized object.
>> 503:   bool _is_auto_box; // is the scalarized object is auto box.
> 
> Typo in comment. Should be something like `// True if the scalarized object is an auto box`

Thank you for your review. I'll add this in my next patch.

> src/hotspot/share/opto/callGenerator.cpp line 583:
> 
>> 581:     while (debuginfo_node_list.size() > 0) {
>> 582:       ProjNode* res = resproj->as_Proj();
>> 583:       Node* debuginfo_node = debuginfo_node_list.pop();
> 
> `debuginfo_node` -> `safepoint`

OK.

> src/hotspot/share/opto/callGenerator.cpp line 596:
> 
>> 594:                                                   first_ind, n_fields, true);
>> 595:       sobj->init_req(0, kit.root());
>> 596:       debuginfo_node->add_req(call->in(res->_con));
> 
> I don't understand why you are selecting the input based on the result projection field `res->_con`?

Thank you for your review. I use `sfpt->add_req(call->in(TypeFunc::Parms));` instead of this.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From whuang at openjdk.java.net  Sat Feb 27 07:10:42 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 27 Feb 2021 07:10:42 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v5]
In-Reply-To: <bDAHGAltLV3xaHlg-YprlnsVgYAZxk_nCSnjMBr5uWY=.04d47d7f-cdb7-46a5-a375-a8d4aa5616e4@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <39-V5pqzlgXaCnL3KTIBXvHwrt35rn4WuuknDv8dcuU=.178fe7a3-4b2b-415c-aaa5-ad63598daeb3@github.com>
 <bDAHGAltLV3xaHlg-YprlnsVgYAZxk_nCSnjMBr5uWY=.04d47d7f-cdb7-46a5-a375-a8d4aa5616e4@github.com>
Message-ID: <2_sE6jBIKfHc2b-kJI0yyXMNJRyDSMLq8uVsvDCKgfw=.53813b84-000e-4601-8465-b4e894c03670@github.com>

On Wed, 24 Feb 2021 07:14:08 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add debuginfo optimization
>
> src/hotspot/share/opto/callGenerator.cpp line 587:
> 
>> 585:       ciInstanceKlass* klass = call->as_CallStaticJava()->method()->holder();
>> 586:       int n_fields = klass->nof_nonstatic_fields();
>> 587:       assert(n_fields == 1, "the klass must be an auto-boxing klass");
> 
> This code can be put in `ifdef ASSERT` and `n_fields` below can be replaced by 1.

These codes are similar to https://github.com/openjdk/jdk/pull/853#discussion_r522967411 , so I put `assert` here.

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

PR: https://git.openjdk.java.net/jdk/pull/2401

From whuang at openjdk.java.net  Sat Feb 27 07:17:22 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 27 Feb 2021 07:17:22 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v6]
In-Reply-To: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
Message-ID: <kUj9sM0AI7FuMGHvsO6cS8ooPLHf_PV8FaqNF0-k2l8=.6b932e50-350a-4bda-a739-2169a6e01418@github.com>

> JDK-8075052 has  removed useless autobox. However, in some cases, the box is still saved. For instance:
> @Benchmark
> public void testMethod(Blackhole bh) {
>   int sum = 0;
>   for (int i = 0; i < data.length; i++) {
>       Integer ii = Integer.valueOf(data[i]);
>       if (i < data.length) {
>           sum += ii.intValue();
>       }
>   }
>   bh.consume(sum);
> }
> Although the variable ii is only used at ii.intValue(), it cannot be eliminated as a result of being used by a hidden uncommon_trap.
> The uncommon_trap is generated by the optimized "if", because its condition is always true.
> 
> We can postpone box in uncommon_trap in this situation. We treat box as a scalarized object by adding a SafePointScalarObjectNode in the uncommon_trap node,
> and deleting the use of box:
> 
> There is no additional fail/error(s) of jtreg after this patch.
> 
> I adjust my codes and add a new benchmark
> 
> public class MyBenchmark {
> 
>     static int[] data = new int[10000];
> 
>     static {
>         for(int i = 0; i < data.length; ++i) {
>             data[i] = i * 1337 % 7331;
>         }
>     }
> 
>     @Benchmark
>     public void testMethod(Blackhole bh) {
>       int sum = 0;
>       for (int i = 0; i < data.length; i++) {
>           Integer ii = Integer.valueOf(data[i]);
>           black();
>           if (i < 100000) {
>               sum += ii.intValue();
>           }
>       }
>       bh.consume(sum);
>     }
> 
>     public void black(){}
> }
> 
> 
> aarch64:  
> base line?
> Benchmark                     Mode  Samples   Score  Score error  Units
> o.s.MyBenchmark.testMethod    avgt       30  88.513        1.111  us/op
> 
> opt?
> Benchmark                     Mode  Samples   Score  Score error  Units
> o.s.MyBenchmark.testMethod    avgt       30  52.776        0.096  us/op
> 
> x86:  
> base line?
> Benchmark                     Mode  Samples   Score  Score error  Units
> o.s.MyBenchmark.testMethod    avgt       30  81.066        3.156  us/op
> 
> opt:
> Benchmark                     Mode  Samples   Score  Score error  Units
> o.s.MyBenchmark.testMethod    avgt       30  55.596        0.775  us/op

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  fix bugs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2401/files
  - new: https://git.openjdk.java.net/jdk/pull/2401/files/84290aeb..20324932

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2401&range=04-05

  Stats: 229 lines in 4 files changed: 210 ins; 6 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2401.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2401/head:pull/2401

PR: https://git.openjdk.java.net/jdk/pull/2401

From vlivanov at openjdk.java.net  Sat Feb 27 11:02:54 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Sat, 27 Feb 2021 11:02:54 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v5]
In-Reply-To: <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com>
Message-ID: <e3XY5rvnS7p0Y5ECjLhEOBaH8xivacWUYf3GygDm0g8=.2188907b-f848-4f64-8407-f7cafba966e2@github.com>

On Sat, 27 Feb 2021 03:23:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Vector API fails to work when:
>>  - case 1: MaxVectorSize is set to <=8, or
>>  - case 2: C2 is disabled
>> 
>> The reason is that {max/preferred} VectorShape initialization fails in both cases.
>> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
>> 
>> Vector API should not depend on C2 to run.
>> It should work even there is no JIT compiler since it's a Java-level api.
>> So let's fix it.
>> 
>> Testing:
>>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
>
> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Fix in jdk/incubator/vector/VectorShape.java
>  - Merge branch 'master' into JDK-8262096
>  - Revert changes
>  - Remove -XX:TieredStopAtLevel=3
>  - Update the jtreg test
>  - The numerator should be 8 (byte)
>  - 8262096: Vector API fails to work due to VectorShape initialization exception

> For the updated fix, the {max/preferred} shape will be initialized as shape-64-bit if hotspot doesn't support vectorization.

Sounds reasonable.

test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java line 42:

> 40:  * @modules jdk.incubator.vector java.base/jdk.internal.vm.vector
> 41:  * @run testng/othervm -XX:MaxVectorSize=8 PreferredSpeciesTest
> 42:  * @run testng/othervm -XX:MaxVectorSize=4 PreferredSpeciesTest

`-XX:MaxVectorSize` is C2-specific. It's better to specify either `-XX:-IgnoreUnrecognizedVMOptions` or `@requires vm.compiler2.enabled`.

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

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Sat Feb 27 11:18:03 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 27 Feb 2021 11:18:03 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v5]
In-Reply-To: <e3XY5rvnS7p0Y5ECjLhEOBaH8xivacWUYf3GygDm0g8=.2188907b-f848-4f64-8407-f7cafba966e2@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com>
 <e3XY5rvnS7p0Y5ECjLhEOBaH8xivacWUYf3GygDm0g8=.2188907b-f848-4f64-8407-f7cafba966e2@github.com>
Message-ID: <gL27OMIhX3PbFmqVri2tUrFGuj0RuIucdkkfTJh1jgo=.17a79b44-b65d-4344-bd5e-fe788f222c78@github.com>

On Sat, 27 Feb 2021 10:58:16 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Fix in jdk/incubator/vector/VectorShape.java
>>  - Merge branch 'master' into JDK-8262096
>>  - Revert changes
>>  - Remove -XX:TieredStopAtLevel=3
>>  - Update the jtreg test
>>  - The numerator should be 8 (byte)
>>  - 8262096: Vector API fails to work due to VectorShape initialization exception
>
> test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java line 42:
> 
>> 40:  * @modules jdk.incubator.vector java.base/jdk.internal.vm.vector
>> 41:  * @run testng/othervm -XX:MaxVectorSize=8 PreferredSpeciesTest
>> 42:  * @run testng/othervm -XX:MaxVectorSize=4 PreferredSpeciesTest
> 
> `-XX:MaxVectorSize` is C2-specific. It's better to specify either `-XX:-IgnoreUnrecognizedVMOptions` or `@requires vm.compiler2.enabled`.

`@requires vm.compiler2.enabled` had been added.
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Sat Feb 27 11:18:00 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 27 Feb 2021 11:18:00 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v6]
In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
Message-ID: <BywMiJG_-XNgjMfpgG6R5D7q1JjdKoKrUAXiSJe13lY=.92e04256-31b9-458e-a1ba-33024a127b29@github.com>

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Add requires vm.compiler2.enabled

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2722/files
  - new: https://git.openjdk.java.net/jdk/pull/2722/files/b67b232d..79402411

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=04-05

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Sun Feb 28 13:34:47 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 28 Feb 2021 13:34:47 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v5]
In-Reply-To: <gL27OMIhX3PbFmqVri2tUrFGuj0RuIucdkkfTJh1jgo=.17a79b44-b65d-4344-bd5e-fe788f222c78@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com>
 <e3XY5rvnS7p0Y5ECjLhEOBaH8xivacWUYf3GygDm0g8=.2188907b-f848-4f64-8407-f7cafba966e2@github.com>
 <gL27OMIhX3PbFmqVri2tUrFGuj0RuIucdkkfTJh1jgo=.17a79b44-b65d-4344-bd5e-fe788f222c78@github.com>
Message-ID: <HvKNMr9928e7BprhljVpIsOli17oUJ0yAj8qXdPBFKk=.7f856b60-4c04-4c8e-b825-9be2a78eb73c@github.com>

On Sat, 27 Feb 2021 11:15:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java line 42:
>> 
>>> 40:  * @modules jdk.incubator.vector java.base/jdk.internal.vm.vector
>>> 41:  * @run testng/othervm -XX:MaxVectorSize=8 PreferredSpeciesTest
>>> 42:  * @run testng/othervm -XX:MaxVectorSize=4 PreferredSpeciesTest
>> 
>> `-XX:MaxVectorSize` is C2-specific. It's better to specify either `-XX:-IgnoreUnrecognizedVMOptions` or `@requires vm.compiler2.enabled`.
>
> `@requires vm.compiler2.enabled` had been added.
> Thanks.

@PaulSandoz , are you also OK with the latest version?
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From jbhateja at openjdk.java.net  Sun Feb 28 18:40:07 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 28 Feb 2021 18:40:07 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
Message-ID: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>

AVX-512 added 8 new 64 bit opmask registers[1] . These registers allow conditional execution and efficient merging of destination operands. At present cross instruction mask propagation is being done either using a GPR (e.g. vmask_gen patterns in x86.ad) or a vector register (for propagating results of a vector comparison or vector load mask operations).

This base patch extends the register allocator to support allocation of opmask registers. This will facilitate mask propagation across instructions and thus enable emitting efficient instruction sequence over X86 targets supporting AVX-512 feature.

We intend to build a robust optimization framework[2] based on this patch to emit optimized instruction sequence for masked/predicated vector operation for X86 targets supporting AVX-512. 

Please review and share your feedback.

Summary of changes:

1) AD side changes: New register definitions, register classes, allocation classes, operand definitions and spill code handling for opmask registers.

2) Runtime: Save/restoration for opmask registers in 32 and 64 bit JVM.
   a) For 64 bit JVM we were anyways reserving the space in the frame layout but earlier were not saving and restoring at designated offset(1088), hence no extra space overhead apart from save/restore cost.
   b) For 32 bit JVM: Additional 64 byte are allocated apart from FXSTORE area on the lines of storage for ZMM(16-31) and YMM-Hi bank. There are few regressions due to extra space allocation which we are investigating.

3) Replacing all the hard-coded opmask references from macro-assembly routines: Pulling out the opmask occurrences all the way up to instruction pattern and adding an unbounded opmask operand for them. This exposes these operands to RA and scheduler; this will automatically facilitate spilling of live opmask registers across call sites.

4) Register class initializations related to Op_RegVMask during matcher startup.

5) Handling for mask generating node:  Currently VectorMaskGen node uses a GPR to propagate mask across mask generating DEF instruction to its USER instructions. There are other mask generating nodes like VectorCmpMask, VectorLoadMask which are not handled as the part of this patch. Conditional overriding of two routines, ideal_reg and bottom_type for mask generating IDEAL nodes and modifying the instruction patterns to have new opmask operands enables instruction selector to associate opmask register class with USE/DEF operands  for such MachNodes. This will constrain  the allocation set for these operands to opmask registers(K1-K7).

6) Special handling for setting a flag in PhiNode during construction in case any of its incoming node is a mask generating node, this flag is then checked to return appropriate ideal_reg and bottom_type corresponding to an opmask registers.

[1] : Section 15.1.3 :  https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-software-developers-manual-volume-1-basic-architecture.html
[2] : http://cr.openjdk.java.net/~jbhateja/avx512_masked_operation_optimization/AVX-512_RA_Opmask_Support_VectorMask_Optimizations.pdf

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

Commit messages:
 - 8262355: Support for AVX-512 opmask register allocation.

Changes: https://git.openjdk.java.net/jdk/pull/2768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2768&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262355
  Stats: 1040 lines in 33 files changed: 767 ins; 13 del; 260 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2768/head:pull/2768

PR: https://git.openjdk.java.net/jdk/pull/2768

From jbhateja at openjdk.java.net  Sun Feb 28 19:09:00 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 28 Feb 2021 19:09:00 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation. [v2]
In-Reply-To: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>
References: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>
Message-ID: <T7Rfb6xFQ7rjwwvVeLgnUBsja_5lUBDRQPog3JjQUOY=.d91e0213-63a0-4dad-9b94-d5ff1dfadd1e@github.com>

> AVX-512 added 8 new 64 bit opmask registers[1] . These registers allow conditional execution and efficient merging of destination operands. At present cross instruction mask propagation is being done either using a GPR (e.g. vmask_gen patterns in x86.ad) or a vector register (for propagating results of a vector comparison or vector load mask operations).
> 
> This base patch extends the register allocator to support allocation of opmask registers. This will facilitate mask propagation across instructions and thus enable emitting efficient instruction sequence over X86 targets supporting AVX-512 feature.
> 
> We intend to build a robust optimization framework[2] based on this patch to emit optimized instruction sequence for masked/predicated vector operation for X86 targets supporting AVX-512. 
> 
> Please review and share your feedback.
> 
> Summary of changes:
> 
> 1) AD side changes: New register definitions, register classes, allocation classes, operand definitions and spill code handling for opmask registers.
> 
> 2) Runtime: Save/restoration for opmask registers in 32 and 64 bit JVM.
>    a) For 64 bit JVM we were anyways reserving the space in the frame layout but earlier were not saving and restoring at designated offset(1088), hence no extra space overhead apart from save/restore cost.
>    b) For 32 bit JVM: Additional 64 byte are allocated apart from FXSTORE area on the lines of storage for ZMM(16-31) and YMM-Hi bank. There are few regressions due to extra space allocation which we are investigating.
> 
> 3) Replacing all the hard-coded opmask references from macro-assembly routines: Pulling out the opmask occurrences all the way up to instruction pattern and adding an unbounded opmask operand for them. This exposes these operands to RA and scheduler; this will automatically facilitate spilling of live opmask registers across call sites.
> 
> 4) Register class initializations related to Op_RegVMask during matcher startup.
> 
> 5) Handling for mask generating node:  Currently VectorMaskGen node uses a GPR to propagate mask across mask generating DEF instruction to its USER instructions. There are other mask generating nodes like VectorCmpMask, VectorLoadMask which are not handled as the part of this patch. Conditional overriding of two routines, ideal_reg and bottom_type for mask generating IDEAL nodes and modifying the instruction patterns to have new opmask operands enables instruction selector to associate opmask register class with USE/DEF operands  for such MachNodes. This will constrain  the allocation set for these operands to opmask registers(K1-K7).
> 
> 6) Special handling for setting a flag in PhiNode during construction in case any of its incoming node is a mask generating node, this flag is then checked to return appropriate ideal_reg and bottom_type corresponding to an opmask registers.
> 
> [1] : Section 15.1.3 :  https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-software-developers-manual-volume-1-basic-architecture.html
> [2] : http://cr.openjdk.java.net/~jbhateja/avx512_masked_operation_optimization/AVX-512_RA_Opmask_Support_VectorMask_Optimizations.pdf

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8262355: Fix for AARCH64 build failure.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2768/files
  - new: https://git.openjdk.java.net/jdk/pull/2768/files/9e1c3e0d..69003aa6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2768&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2768&range=00-01

  Stats: 11 lines in 5 files changed: 1 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2768/head:pull/2768

PR: https://git.openjdk.java.net/jdk/pull/2768