From sviswanathan at openjdk.java.net  Thu Apr  1 00:37:24 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 1 Apr 2021 00:37:24 GMT
Subject: Integrated: 8264054: Bad XMM performance on
 java.lang.MathBench.sqrtDouble
In-Reply-To: <oQ4JHiamp6IJT6WxlUC1jehWthRcSJXGgU1A7tgLJuM=.6a4e84b0-7f8e-4e15-a417-b5491d7666b1@github.com>
References: <oQ4JHiamp6IJT6WxlUC1jehWthRcSJXGgU1A7tgLJuM=.6a4e84b0-7f8e-4e15-a417-b5491d7666b1@github.com>
Message-ID: <zsbaJZqkNftUwB6RKdROF03UCZnARHN9IZ6rMoifFUQ=.16a35bc8-0990-4cf3-81b8-d639766944e0@github.com>

On Tue, 30 Mar 2021 00:38:22 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> For the j.l.Math JMH at https://github.com/openjdk/jmh-jdk-microbenchmarks/blob/master/micros-jdk11/src/main/java/org/openjdk/bench/java/lang/MathBench.java, the performance for sqrt benchmark could be improved.  Thanks a lot to Eric Caspole for finding this issue.
> 
> Benchmark:
>     @Benchmark
>     public double  sqrtDouble() {
>         return  Math.sqrt(double4Dot1);
>     }
> 
> Current code generated (linux format) by c2 JIT is:
>      vsqrtsd 0x50(%r10),%xmm0,%xmm0
> 
> The vsqrtsd instruction operation is specified as below: 
>      VSQRTSD (VEX.128 encoded version)
>      DEST[63:0] := SQRT(SRC2[63:0])
>      DEST[127:64] := SRC1[127:64]
>      DEST[MAXVL-1:128] := 0
> 
> The upper 127:64 bits are set from previous contents of xmm0. As the destination xmm0 register was not initialized prior to use by c2 JIT, this causes stall and lower performance.
> 
> By adding xmm0 initialization prior to use, the performance of the above benchmark improves significantly.
> 
> Code generated after patch:
>      vxorpd %xmm0,%xmm0,%xmm0
>      vsqrtsd 0x50(%r10),%xmm0,%xmm0
> 
> Performance before patch:
> Benchmark                    Mode  Cnt       Score      Error   Units
> MathBench.sqrtDouble        thrpt    8  193612.396 ?  95.807  ops/ms
> 
> Performance after patch:
> MathBench.sqrtDouble        thrpt    8  276388.024 ? 846.372  ops/ms
> 
> Best Regards,
> Sandhya

This pull request has now been integrated.

Changeset: 52d8a229
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/52d8a229
Stats:     947 lines in 3 files changed: 879 ins; 51 del; 17 mod

8264054: Bad XMM performance on java.lang.MathBench.sqrtDouble

Co-authored-by: Eric Caspole <ecaspole at openjdk.org>
Co-authored-by: Charlie Hunt <huntch at openjdk.org>
Reviewed-by: neliasso, kvn, vlivanov

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

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

From hshi at openjdk.java.net  Thu Apr  1 01:04:36 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Thu, 1 Apr 2021 01:04:36 GMT
Subject: RFR: 8264223: CodeHeap::verify fails extra_hops assertion in
 fastdebug test [v3]
In-Reply-To: <HH5lrPGL3vBZUi_BeoulGuLPJEbyD8b_zl3-L50ROCY=.e5cd37ca-7649-4f14-adbd-2ea64a6c3462@github.com>
References: <_U973M53ajT2sW5WNh-HMNqjGTmdb6fvusj9NGHS63Y=.70c7f6ca-b68b-4c3d-9b30-5cd673a2386e@github.com>
 <VCfFx4iQZa6-q9VAFDGFxaFznQV16TeP9nsIlEBhcBQ=.5e12bc1e-9878-429f-b273-072b37ddb34e@github.com>
 <HH5lrPGL3vBZUi_BeoulGuLPJEbyD8b_zl3-L50ROCY=.e5cd37ca-7649-4f14-adbd-2ea64a6c3462@github.com>
Message-ID: <xM1pG4q4VfQQXVlk1fpch0A1LquWlSrZ4h3xki0TV48=.ada4c1c2-0822-47ff-a97c-2dc8432c252b@github.com>

On Wed, 31 Mar 2021 12:50:37 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> The change looks good to me.
> Thank you for digging into the tricky code to understand what's happening. The previous limit (16+2*count) was purely heuristic. Obviously, you have a more pathological test case.

Thanks! The entire CodeHeap optimization is great!

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

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

From jiefu at openjdk.java.net  Thu Apr  1 02:00:44 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 1 Apr 2021 02:00:44 GMT
Subject: RFR: 8264557: Incorrect copyright year for
 test/micro/org/openjdk/bench/java/lang/MathBench.java after JDK-8264054
Message-ID: <I_i6_RgSE7g2sVUEpjGHYmvxtaLl2ljnKx0TJ-MEG2U=.8a56d6cd-0c40-483e-8a1a-817d06c1ad6b@github.com>

Hi all,

The copyright year for test/micro/org/openjdk/bench/java/lang/MathBench.java [1] is incorrect since it isn't newly added in 2021.
Let's fix it.

Thanks.
Best regards,
Jie


[1] https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/MathBench.java#L2

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

Commit messages:
 - 8264557: Incorrect copyright year for test/micro/org/openjdk/bench/java/lang/MathBench.java after JDK-8264054

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

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

From xgong at openjdk.java.net  Thu Apr  1 03:39:43 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 1 Apr 2021 03:39:43 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
Message-ID: <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>

> Currently "VectorMask.andNot()" is not vectorized:
>     public VectorMask<E> andNot(VectorMask<E> m) {
>         // FIXME: Generate good code here.
>         return bOp(m, (i, a, b) -> a && !b);
>     }
> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
> can be vectorized as well by calling them.
> 
> The performance gain is >100% for such a simple JMH:
>   @Benchmark
>   public Object andNot(Blackhole bh) {
>     boolean[] mask = fm.apply(SPECIES.length());
>     boolean[] r = fmt.apply(SPECIES.length());
>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
> 
>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>           rm = rm.andNot(vmask);
>         }
>     }
>     return rm;
>   }

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Move the changing to AbstractMask.andNot and revert changes in VectorMask
  
  Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
  CustomizedGitHooks: yes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3211/files
  - new: https://git.openjdk.java.net/jdk/pull/3211/files/ccb73d92..33ac041e

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

  Stats: 9 lines in 2 files changed: 5 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3211.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3211/head:pull/3211

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

From xgong at openjdk.java.net  Thu Apr  1 03:50:18 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 1 Apr 2021 03:50:18 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <4nYUWzXPdlo6tL9f4j7pTj8ArbRtFSZEHRae7P17UBE=.0d1f8bd8-ff98-49a5-b6d7-d5a4856bcaf0@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <4nYUWzXPdlo6tL9f4j7pTj8ArbRtFSZEHRae7P17UBE=.0d1f8bd8-ff98-49a5-b6d7-d5a4856bcaf0@github.com>
Message-ID: <7-bXxH3_wFxlJaN7-G6HnbWnrAgT8dqurUIYg9nCR-k=.f99cd05a-9ed2-4d74-965d-c81511db354f@github.com>

On Wed, 31 Mar 2021 16:42:09 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Would you mind updating the existing `AbstractMask.andNot` implementation? rather than changing `VectorMask.andNot`. That fits in with the current implementation pattern.

Hi @PaulSandoz , thanks for looking at this PR. I'v updated the patch according to your comments. Would you mind having look at it again? Thanks so much!

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

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

From lucy at openjdk.java.net  Thu Apr  1 07:02:24 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 1 Apr 2021 07:02:24 GMT
Subject: RFR: 8264223: CodeHeap::verify fails extra_hops assertion in
 fastdebug test [v3]
In-Reply-To: <xM1pG4q4VfQQXVlk1fpch0A1LquWlSrZ4h3xki0TV48=.ada4c1c2-0822-47ff-a97c-2dc8432c252b@github.com>
References: <_U973M53ajT2sW5WNh-HMNqjGTmdb6fvusj9NGHS63Y=.70c7f6ca-b68b-4c3d-9b30-5cd673a2386e@github.com>
 <VCfFx4iQZa6-q9VAFDGFxaFznQV16TeP9nsIlEBhcBQ=.5e12bc1e-9878-429f-b273-072b37ddb34e@github.com>
 <HH5lrPGL3vBZUi_BeoulGuLPJEbyD8b_zl3-L50ROCY=.e5cd37ca-7649-4f14-adbd-2ea64a6c3462@github.com>
 <xM1pG4q4VfQQXVlk1fpch0A1LquWlSrZ4h3xki0TV48=.ada4c1c2-0822-47ff-a97c-2dc8432c252b@github.com>
Message-ID: <NP0bTXvC_guV_9aVp8E2F7-fUtpkGVwTWWi26izJuI8=.8fcba38e-17ba-45f4-af6c-db6c0705ace1@github.com>

On Thu, 1 Apr 2021 01:01:19 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> The change looks good to me.
>> Thank you for digging into the tricky code to understand what's happening. The previous limit (16+2*count) was purely heuristic. Obviously, you have a more pathological test case.
>
>> The change looks good to me.
>> Thank you for digging into the tricky code to understand what's happening. The previous limit (16+2*count) was purely heuristic. Obviously, you have a more pathological test case.
> 
> Thanks! The entire CodeHeap optimization is great!

You will need a second review before the fix can be integrated.

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

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

From roland at openjdk.java.net  Thu Apr  1 07:15:23 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 1 Apr 2021 07:15:23 GMT
Subject: RFR: 8263448: CTW: fatal error: meet not symmetric
In-Reply-To: <neO1rxILjU5gSUhlwYk8p-UFeSJzq-OtFq-zSbnIy-Q=.f56c5f30-9555-4b5e-a7a5-828533f39885@github.com>
References: <neO1rxILjU5gSUhlwYk8p-UFeSJzq-OtFq-zSbnIy-Q=.f56c5f30-9555-4b5e-a7a5-828533f39885@github.com>
Message-ID: <OqP9g_Nbjn7Yj_4-AQ55YWkY0iPN6a9Iy8_4JNqG5t0=.14efcc21-8add-487e-9b5a-f9f39764b67a@github.com>

On Wed, 31 Mar 2021 23:31:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> In bug's case instance_id should be changed to InstanceBot only if it is real id and not InstanceTop or InstanceBot (similar to Constant in type lattice). Otherwise we incorrectly change InstanceTop to InstanceBot.  In short, we should follow PTR transformation in this code:
>       if (ptr == Constant) {
>          ptr = NotNull;
>       }
> -     instance_id = InstanceBot;
> +     if (instance_id > 0) {
> +       instance_id = InstanceBot;
> +     }
> I noticed that `TypeInstPtr::xmeet_helper()` has the same code as `TypeAryPtr::xmeet_helper()` for case when `InstPtr` meets `AryPtr`. So instead of fixing two places I decided to call TypeAryPtr::xmeet_helper() from `TypeInstPtr::xmeet_helper()` for this case. We do similar thing in `TypeOopPtr::xmeet()`:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/type.cpp#L3283
> 
> Fixed code style in touched code.
> 
> Tested failing test from bug report, hs-tier1-4, hs-comp.

Looks good to me.

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

Marked as reviewed by roland (Reviewer).

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

From shade at openjdk.java.net  Thu Apr  1 08:04:19 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 1 Apr 2021 08:04:19 GMT
Subject: RFR: 8264223: CodeHeap::verify fails extra_hops assertion in
 fastdebug test [v3]
In-Reply-To: <VCfFx4iQZa6-q9VAFDGFxaFznQV16TeP9nsIlEBhcBQ=.5e12bc1e-9878-429f-b273-072b37ddb34e@github.com>
References: <_U973M53ajT2sW5WNh-HMNqjGTmdb6fvusj9NGHS63Y=.70c7f6ca-b68b-4c3d-9b30-5cd673a2386e@github.com>
 <VCfFx4iQZa6-q9VAFDGFxaFznQV16TeP9nsIlEBhcBQ=.5e12bc1e-9878-429f-b273-072b37ddb34e@github.com>
Message-ID: <VHzU4jaxQZvMKpxGfJVYetH5Sl8cxnZ8hmdrgSMQoM0=.5d1b72f2-0f67-423b-9fa2-7cb51e5499a2@github.com>

On Fri, 26 Mar 2021 08:28:40 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> When test with -XX:+VerifyCodeCache, many tests fail due to extra_hops assertion in CodeHeap::verify. See full dump in JBS.
>> 
>> # Internal Error (src/hotspot/share/memory/heap.cpp:838), pid=1525697, tid=1525715
>> # assert((count == 0) || (extra_hops < (16 + 2*count))) failed: CodeHeap: many extra hops due to optimization. blocks: 234, extra hops: 484.
>> Discussion in https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-October/035508.html doesn't tell where assertion (extra_hops < (16 + 2*count) comes from.
>> 
>> In CodeHeap::mark_segmap_as_used wehn is_FreeBlock_join is true,  it creates extra hops in _segmap. _fragmentation_count in inced and trigger defrag_segmap when reach threshold. In my understanding, extra hop can not guarantee under (16 + 2*count). 
>> 
>> In following extreme case, before HeapBlock free, segmap is all 0 (each blob use 1 smallest segment), suppose free action is applied from right to left. This increase 9 unnecessary hop for 1 continous HeapBlock.  assertion (extra_hops < (16 + 2*count)  is not safe.
>> |0|0|0|0|0|0|0|0|0|0|
>> after free, it will be
>> |0|1|1|1|1|1|1|1|1|1|
>> 
>> Proposed fix is assert extra hops not exceed _fragmentation_count. And if it exceeds (16 + 2 * count), give warning on two many extra hops.
>> 
>> fastdebug tier1, tier2 with VerifyCodeCache passed on X86_64 linux, no extra assertion found.
>
> Hui Shi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

It looks fine. But I have a question: are we reasonably sure that `extra_hops <= _fragmentation_count` always. More specifically, when `_fragmentation_count` drops to `0`, are `extra_hops` guaranteed to be `0` as well?

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

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

From njian at openjdk.java.net  Thu Apr  1 08:05:44 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 1 Apr 2021 08:05:44 GMT
Subject: RFR: 8264409: AArch64: generate better code for Vector API allTrue
Message-ID: <JJi4MlR512iDgojKRMFTydXKkYJQgxtYokJ4TzDYNRY=.d8e7db85-38be-4265-a0c7-d81b053fa589@github.com>

In Vector API NEON implementation, we use a vector register to represent vector mask, where an element value of -1 is a true mask and an element value of 0 is a false mask. The allTrue() api is used to check whether all the elements of current mask are set.

Currently, the AArch64 NEON allTrue implementation looks like:

  andr  $tmp, T16B $src1, $src2\t# src2 is maskAllTrue
  notr  $tmp, T16B, $tmp
  addv  $tmp, T16B, $tmp
  umov  $dst, $tmp, B, 0
  cmp   $dst, 0
  cset  $dst

where $src2 is a preset all true (-1) constant. We can optimize it to the code sequence like below, to check whether all bits are set:

  uminv $tmp, T16B, $src1
  umov  $dst, $tmp, B, 0
  cmp   $dst, 0xff
  cset  $dst

With this codegen improvement, we can see about 8%~70% performance uplift on different machines for Alibaba's Vector API bigdata benchmarks [1][2].

Tested with tier1 and vector api jtreg tests.

[1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/BooleanArrayCheck.java#L61
[2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/ValueRangeCheckAndCastL2I.java#L93

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

Commit messages:
 - 8264409: AArch64: generate better code for Vector API allTrue

Changes: https://git.openjdk.java.net/jdk/pull/3302/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3302&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264409
  Stats: 409 lines in 5 files changed: 13 ins; 12 del; 384 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3302/head:pull/3302

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

From adinn at openjdk.java.net  Thu Apr  1 09:05:26 2021
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 1 Apr 2021 09:05:26 GMT
Subject: RFR: 8264409: AArch64: generate better code for Vector API allTrue
In-Reply-To: <JJi4MlR512iDgojKRMFTydXKkYJQgxtYokJ4TzDYNRY=.d8e7db85-38be-4265-a0c7-d81b053fa589@github.com>
References: <JJi4MlR512iDgojKRMFTydXKkYJQgxtYokJ4TzDYNRY=.d8e7db85-38be-4265-a0c7-d81b053fa589@github.com>
Message-ID: <F_-V8J2yIXLPEKfuaTARMEcXuvTj1509fQ2sm2eidfg=.fa4d17af-f396-41fa-a0fb-accf9e9a7ede@github.com>

On Thu, 1 Apr 2021 07:58:07 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> In Vector API NEON implementation, we use a vector register to represent vector mask, where an element value of -1 is a true mask and an element value of 0 is a false mask. The allTrue() api is used to check whether all the elements of current mask are set.
> 
> Currently, the AArch64 NEON allTrue implementation looks like:
> 
>   andr  $tmp, T16B $src1, $src2\t# src2 is maskAllTrue
>   notr  $tmp, T16B, $tmp
>   addv  $tmp, T16B, $tmp
>   umov  $dst, $tmp, B, 0
>   cmp   $dst, 0
>   cset  $dst
> 
> where $src2 is a preset all true (-1) constant. We can optimize it to the code sequence like below, to check whether all bits are set:
> 
>   uminv $tmp, T16B, $src1
>   umov  $dst, $tmp, B, 0
>   cmp   $dst, 0xff
>   cset  $dst
> 
> With this codegen improvement, we can see about 8%~70% performance uplift on different machines for Alibaba's Vector API bigdata benchmarks [1][2].
> 
> Tested with tier1 and vector api jtreg tests.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/BooleanArrayCheck.java#L61
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/ValueRangeCheckAndCastL2I.java#L93

It's a clever trick to use uminv for this specific case.
The patch looks good to me.

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

Marked as reviewed by adinn (Reviewer).

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

From vlivanov at openjdk.java.net  Thu Apr  1 09:11:35 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 1 Apr 2021 09:11:35 GMT
Subject: RFR: 8264548: Dependencies: ClassHierarchyWalker::is_witness()
 cleanups
In-Reply-To: <7gwnAv5IEEhj8je8965QoyZXFOhdZ1EgpHBop6nlmzE=.7410cbc8-52da-4d51-8663-aaea9b630a11@github.com>
References: <m69KB5H2485nxJ04DF8fZ8XHt6qXJLwYQaRq5jt0GvM=.94786055-9d85-4ee9-a1d5-af19677e134e@github.com>
 <7gwnAv5IEEhj8je8965QoyZXFOhdZ1EgpHBop6nlmzE=.7410cbc8-52da-4d51-8663-aaea9b630a11@github.com>
Message-ID: <ns7qMjBFTscClh9EPLpbjIoVHjSeSqjEEQqQi4t9CIw=.97a9a090-af11-426f-9373-75339c5fb7de@github.com>

On Wed, 31 Mar 2021 22:05:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Simplify `ClassHierarchyWalker::is_witness()`.
>> 
>> Testing: hs-tier1 - hs-tier4.
>
> Looks like it has changes from: https://git.openjdk.java.net/jdk/pull/3293

I created it as a dependent PR. 

I think that's the way it works (https://github.com/openjdk/skara/pull/1087 which was used as an example in [1] looks similar). 

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005232.html

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

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

From lucy at openjdk.java.net  Thu Apr  1 09:58:34 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 1 Apr 2021 09:58:34 GMT
Subject: RFR: 8264223: CodeHeap::verify fails extra_hops assertion in
 fastdebug test [v3]
In-Reply-To: <VHzU4jaxQZvMKpxGfJVYetH5Sl8cxnZ8hmdrgSMQoM0=.5d1b72f2-0f67-423b-9fa2-7cb51e5499a2@github.com>
References: <_U973M53ajT2sW5WNh-HMNqjGTmdb6fvusj9NGHS63Y=.70c7f6ca-b68b-4c3d-9b30-5cd673a2386e@github.com>
 <VCfFx4iQZa6-q9VAFDGFxaFznQV16TeP9nsIlEBhcBQ=.5e12bc1e-9878-429f-b273-072b37ddb34e@github.com>
 <VHzU4jaxQZvMKpxGfJVYetH5Sl8cxnZ8hmdrgSMQoM0=.5d1b72f2-0f67-423b-9fa2-7cb51e5499a2@github.com>
Message-ID: <UKKewr7CR5CQoPqY-RwgS1PQ_SJlC6z3cA1QMvHpIAA=.79559788-535a-4459-a660-b991370108ea@github.com>

On Thu, 1 Apr 2021 08:01:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hui Shi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright year
>
> It looks fine. But I have a question: are we reasonably sure that `extra_hops <= _fragmentation_count` always. More specifically, when `_fragmentation_count` drops to `0`, are `extra_hops` guaranteed to be `0` as well?

@shipilev Short answer: yes.
Long answer:
_fragmentation_count is incremented every time the segment map becomes _potentially_ more fragmented by introducing an additional chunk, see mark_segmap_as_used(). Therefore, _fragmentation_count overestimates the actual segmap fragmentation.
 
Once _fragmentation_count hits the limit, defragmentation is triggered (defrag_segmap(true)) and the counter is set to zero. After defragmentation, segmap should not contain any extra hops - that's the purpose of defragmentation. If is does, I would classify that as a bug.

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

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

From shade at openjdk.java.net  Thu Apr  1 10:03:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 1 Apr 2021 10:03:34 GMT
Subject: RFR: 8264223: CodeHeap::verify fails extra_hops assertion in
 fastdebug test [v3]
In-Reply-To: <VCfFx4iQZa6-q9VAFDGFxaFznQV16TeP9nsIlEBhcBQ=.5e12bc1e-9878-429f-b273-072b37ddb34e@github.com>
References: <_U973M53ajT2sW5WNh-HMNqjGTmdb6fvusj9NGHS63Y=.70c7f6ca-b68b-4c3d-9b30-5cd673a2386e@github.com>
 <VCfFx4iQZa6-q9VAFDGFxaFznQV16TeP9nsIlEBhcBQ=.5e12bc1e-9878-429f-b273-072b37ddb34e@github.com>
Message-ID: <yP9a8SXtqxrPvSfiCssbKm3WLqu-CsZaYzbo94VySTQ=.82056277-acc1-4ff0-ad50-fb73788f47a7@github.com>

On Fri, 26 Mar 2021 08:28:40 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> When test with -XX:+VerifyCodeCache, many tests fail due to extra_hops assertion in CodeHeap::verify. See full dump in JBS.
>> 
>> # Internal Error (src/hotspot/share/memory/heap.cpp:838), pid=1525697, tid=1525715
>> # assert((count == 0) || (extra_hops < (16 + 2*count))) failed: CodeHeap: many extra hops due to optimization. blocks: 234, extra hops: 484.
>> Discussion in https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-October/035508.html doesn't tell where assertion (extra_hops < (16 + 2*count) comes from.
>> 
>> In CodeHeap::mark_segmap_as_used wehn is_FreeBlock_join is true,  it creates extra hops in _segmap. _fragmentation_count in inced and trigger defrag_segmap when reach threshold. In my understanding, extra hop can not guarantee under (16 + 2*count). 
>> 
>> In following extreme case, before HeapBlock free, segmap is all 0 (each blob use 1 smallest segment), suppose free action is applied from right to left. This increase 9 unnecessary hop for 1 continous HeapBlock.  assertion (extra_hops < (16 + 2*count)  is not safe.
>> |0|0|0|0|0|0|0|0|0|0|
>> after free, it will be
>> |0|1|1|1|1|1|1|1|1|1|
>> 
>> Proposed fix is assert extra hops not exceed _fragmentation_count. And if it exceeds (16 + 2 * count), give warning on two many extra hops.
>> 
>> fastdebug tier1, tier2 with VerifyCodeCache passed on X86_64 linux, no extra assertion found.
>
> Hui Shi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Okay then, thanks.

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

Marked as reviewed by shade (Reviewer).

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

From hshi at openjdk.java.net  Thu Apr  1 10:48:22 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Thu, 1 Apr 2021 10:48:22 GMT
Subject: Integrated: 8264223: CodeHeap::verify fails extra_hops assertion in
 fastdebug test
In-Reply-To: <_U973M53ajT2sW5WNh-HMNqjGTmdb6fvusj9NGHS63Y=.70c7f6ca-b68b-4c3d-9b30-5cd673a2386e@github.com>
References: <_U973M53ajT2sW5WNh-HMNqjGTmdb6fvusj9NGHS63Y=.70c7f6ca-b68b-4c3d-9b30-5cd673a2386e@github.com>
Message-ID: <Ukecn50FyujKvUatIT3Xp7fNL_qLa4ol9oJBzBTjVck=.64c24ff6-b32f-4d0f-9202-475c2c3f580a@github.com>

On Fri, 26 Mar 2021 02:50:59 GMT, Hui Shi <hshi at openjdk.org> wrote:

> When test with -XX:+VerifyCodeCache, many tests fail due to extra_hops assertion in CodeHeap::verify. See full dump in JBS.
> 
> # Internal Error (src/hotspot/share/memory/heap.cpp:838), pid=1525697, tid=1525715
> # assert((count == 0) || (extra_hops < (16 + 2*count))) failed: CodeHeap: many extra hops due to optimization. blocks: 234, extra hops: 484.
> Discussion in https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-October/035508.html doesn't tell where assertion (extra_hops < (16 + 2*count) comes from.
> 
> In CodeHeap::mark_segmap_as_used wehn is_FreeBlock_join is true,  it creates extra hops in _segmap. _fragmentation_count in inced and trigger defrag_segmap when reach threshold. In my understanding, extra hop can not guarantee under (16 + 2*count). 
> 
> In following extreme case, before HeapBlock free, segmap is all 0 (each blob use 1 smallest segment), suppose free action is applied from right to left. This increase 9 unnecessary hop for 1 continous HeapBlock.  assertion (extra_hops < (16 + 2*count)  is not safe.
> |0|0|0|0|0|0|0|0|0|0|
> after free, it will be
> |0|1|1|1|1|1|1|1|1|1|
> 
> Proposed fix is assert extra hops not exceed _fragmentation_count. And if it exceeds (16 + 2 * count), give warning on two many extra hops.
> 
> fastdebug tier1, tier2 with VerifyCodeCache passed on X86_64 linux, no extra assertion found.

This pull request has now been integrated.

Changeset: 011f6d13
Author:    Hui Shi <hshi at openjdk.org>
Committer: Lutz Schmidt <lucy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/011f6d13
Stats:     13 lines in 2 files changed: 11 ins; 0 del; 2 mod

8264223: CodeHeap::verify fails extra_hops assertion in fastdebug test

Reviewed-by: lucy, shade

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

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

From vlivanov at openjdk.java.net  Thu Apr  1 13:00:27 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 1 Apr 2021 13:00:27 GMT
Subject: RFR: 8264546: Dependencies: Context class is always an
 InstanceKlass
In-Reply-To: <ns8h8GZc0dbqLPd1iqOiCjDtYHt47UwWVArO75KcMxY=.1c69b04f-6b9f-496d-85e4-0e03ac7a7f98@github.com>
References: <lz3eaGT3vA-YihrxbbCkugkQDsxn2JcJPPcu-fhBrFo=.7facb01e-a535-4e87-aaa4-dbb14386b196@github.com>
 <ns8h8GZc0dbqLPd1iqOiCjDtYHt47UwWVArO75KcMxY=.1c69b04f-6b9f-496d-85e4-0e03ac7a7f98@github.com>
Message-ID: <Hl39b1Fdni9zuYKqv4oYSeySHozTkWToeypKbWDQdbI=.979afbdf-ef4f-4f56-9020-352c6fcab6d0@github.com>

On Wed, 31 Mar 2021 22:02:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> A trivial refactoring/cleanup: dependency context is always an InstanceKlass, but `Dependencies` uses `Klass*`. 
>> Migrate` Dependencies` from `Klass*` to `InstanceKlass*`.
>> 
>> Testing: hs-tier1 - hs-tier2
>
> Good.

Thanks, Vladimir.

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

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

From vlivanov at openjdk.java.net  Thu Apr  1 13:00:28 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 1 Apr 2021 13:00:28 GMT
Subject: Integrated: 8264546: Dependencies: Context class is always an
 InstanceKlass
In-Reply-To: <lz3eaGT3vA-YihrxbbCkugkQDsxn2JcJPPcu-fhBrFo=.7facb01e-a535-4e87-aaa4-dbb14386b196@github.com>
References: <lz3eaGT3vA-YihrxbbCkugkQDsxn2JcJPPcu-fhBrFo=.7facb01e-a535-4e87-aaa4-dbb14386b196@github.com>
Message-ID: <G6_b-Fx4htpeWKixfF-Ndzwc-xH9GTO0rAu4IIiXqTs=.8b32bfa0-4c4a-4268-ba21-fe361d03469c@github.com>

On Wed, 31 Mar 2021 21:27:14 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> A trivial refactoring/cleanup: dependency context is always an InstanceKlass, but `Dependencies` uses `Klass*`. 
> Migrate` Dependencies` from `Klass*` to `InstanceKlass*`.
> 
> Testing: hs-tier1 - hs-tier2

This pull request has now been integrated.

Changeset: 80681b54
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/80681b54
Stats:     33 lines in 4 files changed: 1 ins; 6 del; 26 mod

8264546: Dependencies: Context class is always an InstanceKlass

Reviewed-by: kvn

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

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

From vlivanov at openjdk.java.net  Thu Apr  1 14:03:48 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 1 Apr 2021 14:03:48 GMT
Subject: RFR: 8264548: Dependencies: ClassHierarchyWalker::is_witness()
 cleanups [v2]
In-Reply-To: <m69KB5H2485nxJ04DF8fZ8XHt6qXJLwYQaRq5jt0GvM=.94786055-9d85-4ee9-a1d5-af19677e134e@github.com>
References: <m69KB5H2485nxJ04DF8fZ8XHt6qXJLwYQaRq5jt0GvM=.94786055-9d85-4ee9-a1d5-af19677e134e@github.com>
Message-ID: <HAOZRVvO_wPY-6jzH5n05Hj8h7gTjy4xF8jnXkBW-9I=.8367a1f0-02c3-4c71-90b7-ae1d5cff6bed@github.com>

> Simplify `ClassHierarchyWalker::is_witness()`.
> 
> Testing: hs-tier1 - hs-tier4.

Vladimir Ivanov 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 one additional commit since the last revision:

  Refactor ClassHierarchyWalker::is_witness()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3297/files
  - new: https://git.openjdk.java.net/jdk/pull/3297/files/fc92da2e..b7f31326

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

  Stats: 3498 lines in 125 files changed: 2719 ins; 306 del; 473 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3297.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3297/head:pull/3297

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

From vlivanov at openjdk.java.net  Thu Apr  1 14:03:49 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 1 Apr 2021 14:03:49 GMT
Subject: RFR: 8264548: Dependencies: ClassHierarchyWalker::is_witness()
 cleanups [v2]
In-Reply-To: <ns7qMjBFTscClh9EPLpbjIoVHjSeSqjEEQqQi4t9CIw=.97a9a090-af11-426f-9373-75339c5fb7de@github.com>
References: <m69KB5H2485nxJ04DF8fZ8XHt6qXJLwYQaRq5jt0GvM=.94786055-9d85-4ee9-a1d5-af19677e134e@github.com>
 <7gwnAv5IEEhj8je8965QoyZXFOhdZ1EgpHBop6nlmzE=.7410cbc8-52da-4d51-8663-aaea9b630a11@github.com>
 <ns7qMjBFTscClh9EPLpbjIoVHjSeSqjEEQqQi4t9CIw=.97a9a090-af11-426f-9373-75339c5fb7de@github.com>
Message-ID: <e-b1j2rXRZ5-iTamCGMJTl0kzBj9wu5DykuQ8WSmJ-A=.4333d0bb-9d95-461a-a637-19fd8688d492@github.com>

On Thu, 1 Apr 2021 09:08:01 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Looks like it has changes from: https://git.openjdk.java.net/jdk/pull/3293
>
> I created it as a dependent PR. 
> 
> I think that's the way it works (https://github.com/openjdk/skara/pull/1087 which was used as an example in [1] looks similar). 
> 
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005232.html

Anyway, I rebased and force-pushed the patch since #3293 is integrated now.

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

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

From neliasso at openjdk.java.net  Thu Apr  1 15:04:19 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 1 Apr 2021 15:04:19 GMT
Subject: RFR: 8264557: Incorrect copyright year for
 test/micro/org/openjdk/bench/java/lang/MathBench.java after JDK-8264054
In-Reply-To: <I_i6_RgSE7g2sVUEpjGHYmvxtaLl2ljnKx0TJ-MEG2U=.8a56d6cd-0c40-483e-8a1a-817d06c1ad6b@github.com>
References: <I_i6_RgSE7g2sVUEpjGHYmvxtaLl2ljnKx0TJ-MEG2U=.8a56d6cd-0c40-483e-8a1a-817d06c1ad6b@github.com>
Message-ID: <6IBF3cgrWKR65rtbyYA9g8m76E1oW_vWtd7NNMq6fR0=.f865574e-82ad-46d0-8967-cf1779efdcb1@github.com>

On Thu, 1 Apr 2021 01:54:31 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The copyright year for test/micro/org/openjdk/bench/java/lang/MathBench.java [1] is incorrect since it isn't newly added in 2021.
> Let's fix it.
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/MathBench.java#L2

Looks good.

Change is trivial and needs no further approval.

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

Marked as reviewed by neliasso (Reviewer).

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

From psandoz at openjdk.java.net  Thu Apr  1 15:16:26 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 1 Apr 2021 15:16:26 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
Message-ID: <bH97iO9EOXZRcKTS2zyOBwfqJLoRUiP-wFzccuKb-fg=.bd983da8-9b58-4bb3-b8a3-395ef669aafc@github.com>

On Thu, 1 Apr 2021 03:39:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently "VectorMask.andNot()" is not vectorized:
>>     public VectorMask<E> andNot(VectorMask<E> m) {
>>         // FIXME: Generate good code here.
>>         return bOp(m, (i, a, b) -> a && !b);
>>     }
>> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
>> can be vectorized as well by calling them.
>> 
>> The performance gain is >100% for such a simple JMH:
>>   @Benchmark
>>   public Object andNot(Blackhole bh) {
>>     boolean[] mask = fm.apply(SPECIES.length());
>>     boolean[] r = fmt.apply(SPECIES.length());
>>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
>> 
>>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>>           rm = rm.andNot(vmask);
>>         }
>>     }
>>     return rm;
>>   }
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the changing to AbstractMask.andNot and revert changes in VectorMask
>   
>   Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
>   CustomizedGitHooks: yes

Looks good.

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

Marked as reviewed by psandoz (Reviewer).

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

From jiefu at openjdk.java.net  Thu Apr  1 15:16:30 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 1 Apr 2021 15:16:30 GMT
Subject: RFR: 8264557: Incorrect copyright year for
 test/micro/org/openjdk/bench/java/lang/MathBench.java after JDK-8264054
In-Reply-To: <6IBF3cgrWKR65rtbyYA9g8m76E1oW_vWtd7NNMq6fR0=.f865574e-82ad-46d0-8967-cf1779efdcb1@github.com>
References: <I_i6_RgSE7g2sVUEpjGHYmvxtaLl2ljnKx0TJ-MEG2U=.8a56d6cd-0c40-483e-8a1a-817d06c1ad6b@github.com>
 <6IBF3cgrWKR65rtbyYA9g8m76E1oW_vWtd7NNMq6fR0=.f865574e-82ad-46d0-8967-cf1779efdcb1@github.com>
Message-ID: <zsayK-rrRNnnO8CstQv6cjSqviJZTEVujOwBpC2bc04=.e12bcb14-3fa7-409b-813c-657cd129f736@github.com>

On Thu, 1 Apr 2021 15:01:37 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Looks good.
> 
> Change is trivial and needs no further approval.

Thanks @neliasso .

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

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

From jiefu at openjdk.java.net  Thu Apr  1 15:16:31 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 1 Apr 2021 15:16:31 GMT
Subject: Integrated: 8264557: Incorrect copyright year for
 test/micro/org/openjdk/bench/java/lang/MathBench.java after JDK-8264054
In-Reply-To: <I_i6_RgSE7g2sVUEpjGHYmvxtaLl2ljnKx0TJ-MEG2U=.8a56d6cd-0c40-483e-8a1a-817d06c1ad6b@github.com>
References: <I_i6_RgSE7g2sVUEpjGHYmvxtaLl2ljnKx0TJ-MEG2U=.8a56d6cd-0c40-483e-8a1a-817d06c1ad6b@github.com>
Message-ID: <QeX3P3v3DVKeZYfUlbXWq6jY_REvmxaG1aQ0gg5gp1M=.4f355895-bc60-4c72-b05b-a6df7debc1ac@github.com>

On Thu, 1 Apr 2021 01:54:31 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The copyright year for test/micro/org/openjdk/bench/java/lang/MathBench.java [1] is incorrect since it isn't newly added in 2021.
> Let's fix it.
> 
> Thanks.
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/MathBench.java#L2

This pull request has now been integrated.

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

8264557: Incorrect copyright year for test/micro/org/openjdk/bench/java/lang/MathBench.java after JDK-8264054

Reviewed-by: neliasso

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

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

From kvn at openjdk.java.net  Thu Apr  1 16:20:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 1 Apr 2021 16:20:17 GMT
Subject: RFR: 8263448: CTW: fatal error: meet not symmetric
In-Reply-To: <OqP9g_Nbjn7Yj_4-AQ55YWkY0iPN6a9Iy8_4JNqG5t0=.14efcc21-8add-487e-9b5a-f9f39764b67a@github.com>
References: <neO1rxILjU5gSUhlwYk8p-UFeSJzq-OtFq-zSbnIy-Q=.f56c5f30-9555-4b5e-a7a5-828533f39885@github.com>
 <OqP9g_Nbjn7Yj_4-AQ55YWkY0iPN6a9Iy8_4JNqG5t0=.14efcc21-8add-487e-9b5a-f9f39764b67a@github.com>
Message-ID: <v26oPbtcq7jOoq5dLSzyLqhusm_9_rtkmNVS_SFHel8=.04a2488e-b056-4b22-a6a2-5e6e4b20fecd@github.com>

On Thu, 1 Apr 2021 07:12:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> In bug's case instance_id should be changed to InstanceBot only if it is real id and not InstanceTop or InstanceBot (similar to Constant in type lattice). Otherwise we incorrectly change InstanceTop to InstanceBot.  In short, we should follow PTR transformation in this code:
>>       if (ptr == Constant) {
>>          ptr = NotNull;
>>       }
>> -     instance_id = InstanceBot;
>> +     if (instance_id > 0) {
>> +       instance_id = InstanceBot;
>> +     }
>> I noticed that `TypeInstPtr::xmeet_helper()` has the same code as `TypeAryPtr::xmeet_helper()` for case when `InstPtr` meets `AryPtr`. So instead of fixing two places I decided to call TypeAryPtr::xmeet_helper() from `TypeInstPtr::xmeet_helper()` for this case. We do similar thing in `TypeOopPtr::xmeet()`:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/type.cpp#L3283
>> 
>> Fixed code style in touched code.
>> 
>> Tested failing test from bug report, hs-tier1-4, hs-comp.
>
> Looks good to me.

Thank you, Roland.

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

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

From kvn at openjdk.java.net  Thu Apr  1 16:35:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 1 Apr 2021 16:35:17 GMT
Subject: RFR: 8264548: Dependencies: ClassHierarchyWalker::is_witness()
 cleanups [v2]
In-Reply-To: <HAOZRVvO_wPY-6jzH5n05Hj8h7gTjy4xF8jnXkBW-9I=.8367a1f0-02c3-4c71-90b7-ae1d5cff6bed@github.com>
References: <m69KB5H2485nxJ04DF8fZ8XHt6qXJLwYQaRq5jt0GvM=.94786055-9d85-4ee9-a1d5-af19677e134e@github.com>
 <HAOZRVvO_wPY-6jzH5n05Hj8h7gTjy4xF8jnXkBW-9I=.8367a1f0-02c3-4c71-90b7-ae1d5cff6bed@github.com>
Message-ID: <TwTiB1FgdxMgPFphyYdPg8QoRu7-oGZ6wTd8XoTXCAc=.48c72f53-6167-4d9e-9375-5e4a9ac34cc7@github.com>

On Thu, 1 Apr 2021 14:03:48 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Simplify `ClassHierarchyWalker::is_witness()`.
>> 
>> Testing: hs-tier1 - hs-tier4.
>
> Vladimir Ivanov 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 one additional commit since the last revision:
> 
>   Refactor ClassHierarchyWalker::is_witness()

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Thu Apr  1 17:06:14 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 1 Apr 2021 17:06:14 GMT
Subject: Integrated: 8263448: CTW: fatal error: meet not symmetric
In-Reply-To: <neO1rxILjU5gSUhlwYk8p-UFeSJzq-OtFq-zSbnIy-Q=.f56c5f30-9555-4b5e-a7a5-828533f39885@github.com>
References: <neO1rxILjU5gSUhlwYk8p-UFeSJzq-OtFq-zSbnIy-Q=.f56c5f30-9555-4b5e-a7a5-828533f39885@github.com>
Message-ID: <bbtUPGmOaCc_We1bG7UiGSZ_sFx-GpkKGDQXd9piZ14=.2a24e7d9-d9e4-4d3e-a7a4-fc26c98c4cda@github.com>

On Wed, 31 Mar 2021 23:31:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> In bug's case instance_id should be changed to InstanceBot only if it is real id and not InstanceTop or InstanceBot (similar to Constant in type lattice). Otherwise we incorrectly change InstanceTop to InstanceBot.  In short, we should follow PTR transformation in this code:
>       if (ptr == Constant) {
>          ptr = NotNull;
>       }
> -     instance_id = InstanceBot;
> +     if (instance_id > 0) {
> +       instance_id = InstanceBot;
> +     }
> I noticed that `TypeInstPtr::xmeet_helper()` has the same code as `TypeAryPtr::xmeet_helper()` for case when `InstPtr` meets `AryPtr`. So instead of fixing two places I decided to call TypeAryPtr::xmeet_helper() from `TypeInstPtr::xmeet_helper()` for this case. We do similar thing in `TypeOopPtr::xmeet()`:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/type.cpp#L3283
> 
> Fixed code style in touched code.
> 
> Tested failing test from bug report, hs-tier1-4, hs-comp.

This pull request has now been integrated.

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

8263448: CTW: fatal error: meet not symmetric

Reviewed-by: roland

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

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

From kvn at openjdk.java.net  Thu Apr  1 17:27:22 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 1 Apr 2021 17:27:22 GMT
Subject: RFR: 8264548: Dependencies: ClassHierarchyWalker::is_witness()
 cleanups [v2]
In-Reply-To: <TwTiB1FgdxMgPFphyYdPg8QoRu7-oGZ6wTd8XoTXCAc=.48c72f53-6167-4d9e-9375-5e4a9ac34cc7@github.com>
References: <m69KB5H2485nxJ04DF8fZ8XHt6qXJLwYQaRq5jt0GvM=.94786055-9d85-4ee9-a1d5-af19677e134e@github.com>
 <HAOZRVvO_wPY-6jzH5n05Hj8h7gTjy4xF8jnXkBW-9I=.8367a1f0-02c3-4c71-90b7-ae1d5cff6bed@github.com>
 <TwTiB1FgdxMgPFphyYdPg8QoRu7-oGZ6wTd8XoTXCAc=.48c72f53-6167-4d9e-9375-5e4a9ac34cc7@github.com>
Message-ID: <jDdrrxXR-mPImUiQCzgdAu8UD516rWGw_F5fJh8SAU8=.1ac178fd-ece0-45d3-aa0c-a0a9068d9cb7@github.com>

On Thu, 1 Apr 2021 16:32:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Vladimir Ivanov 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 one additional commit since the last revision:
>> 
>>   Refactor ClassHierarchyWalker::is_witness()
>
> Good.

> I created it as a dependent PR.
> 
> I think that's the way it works ([openjdk/skara#1087](https://github.com/openjdk/skara/pull/1087) which was used as an example in [1] looks similar).
> 
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005232.html

As I understand when you are creating PR which based on an other PR you have to change `base:` from `master` to corresponding `pr/3293`  so that only difference of current PR are seen.

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

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

From kvn at openjdk.java.net  Thu Apr  1 17:47:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 1 Apr 2021 17:47:17 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v13]
In-Reply-To: <YUH9o_Z5_avs_-KiNy5jm1O9Hw9fO_uHUbZuy2ovc68=.b735d3c4-ce29-48d9-9425-67aa3f9ae240@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YUH9o_Z5_avs_-KiNy5jm1O9Hw9fO_uHUbZuy2ovc68=.b735d3c4-ce29-48d9-9425-67aa3f9ae240@github.com>
Message-ID: <SqHYD0FCMHi1qLVnGc2sDd4WOMziEJh8OM0x9AohAlY=.65f37a59-23d4-443a-bbf0-9664e11fb49d@github.com>

On Tue, 30 Mar 2021 01:53:12 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:
> 
>   trivial fix

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Thu Apr  1 17:47:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 1 Apr 2021 17:47:17 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v11]
In-Reply-To: <buknmFkv7N2TajbzvMhIuESWTBb5KfH_4V4NzwhPWLE=.1fd2964d-3450-4e7a-88ae-9dcd053efd62@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <NPQkY9pXIIqtErXRUplF7RYiXIo6BQSxMA8-vZZEPIA=.82c47221-8e3d-4619-a016-c09b22eef169@github.com>
 <ZRVRWlUG64YA48qeU5DcmLEPmFI_iugKf06bOAnxxNU=.31cb88c4-4317-4389-9158-8cf2543ca862@github.com>
 <ZiTcc98n91b4Mc4BaMqD2im3JWIkCxm1afg0wlwJ0gc=.8f8a4c97-ed02-40eb-afc2-4f010f50a4fe@github.com>
 <buknmFkv7N2TajbzvMhIuESWTBb5KfH_4V4NzwhPWLE=.1fd2964d-3450-4e7a-88ae-9dcd053efd62@github.com>
Message-ID: <IOcuQ2EskLH7huYJIJVu9WtLkMZ7hRRCb9RpFwfEUBo=.d91bdea1-0515-4cd8-9d39-966f2f7a97fd@github.com>

On Wed, 31 Mar 2021 02:29:33 GMT, Wang Huang <whuang at openjdk.org> wrote:

>>> It was my suggestion to pass call node as allocation so that we could trace back for what node SafePointScalarObject was created because you may have several Box objects for which we create SafePointScalarObject nodes.
>> 
>> The problem with that is `alloc` quickly becomes stale since allocations/calls are removed shortly after scalarization takes place. The only usage of `alloc()` is in `PhaseMacroExpand::scalar_replacement`:
>> assert(scobj->alloc() == alloc, "sanity");
>> 
>> Regarding the assert, frankly speaking, it looks repetitive and verbose. I'd prefer to just see it folded into:
>> assert(alloc == NULL || alloc->is_Allocate() || alloc->as_CallStaticJava()->is_boxing_method(), "unexpected call node");
>> 
>> Or introduce a helper method to dump relevant info about the problematic node: 
>> assert(alloc == NULL || alloc->is_Allocate() || alloc->as_CallStaticJava()->is_boxing_method(), "unexpected call node: %s", dump_node(alloc));
>> 
>> Also, `alloc == NULL` case can be eliminated by avoiding passing `NULL` in `PhaseVector::scalarize_vbox_node()`.
>
>> Okay. Lets do as @iwanowww suggesting.
> 
> Should we implement `dump_node` or should we just use `assert(alloc == NULL || alloc->is_Allocate() || alloc->as_CallStaticJava()->is_boxing_method(), "unexpected call node");`  without dumping?

Creating node's dump string in separate method is complicated.
We can just use `false` in assert:
#ifdef ASSERT
  if (alloc != nullptr && !alloc->is_Allocate() && !alloc->as_CallStaticJava()->is_boxing_method()) {
    alloc->dump();
    assert(false, "unexpected call node for scalar replacement");
  }
#endif

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

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

From kvn at openjdk.java.net  Thu Apr  1 17:47:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 1 Apr 2021 17:47:17 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v11]
In-Reply-To: <IOcuQ2EskLH7huYJIJVu9WtLkMZ7hRRCb9RpFwfEUBo=.d91bdea1-0515-4cd8-9d39-966f2f7a97fd@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <NPQkY9pXIIqtErXRUplF7RYiXIo6BQSxMA8-vZZEPIA=.82c47221-8e3d-4619-a016-c09b22eef169@github.com>
 <ZRVRWlUG64YA48qeU5DcmLEPmFI_iugKf06bOAnxxNU=.31cb88c4-4317-4389-9158-8cf2543ca862@github.com>
 <ZiTcc98n91b4Mc4BaMqD2im3JWIkCxm1afg0wlwJ0gc=.8f8a4c97-ed02-40eb-afc2-4f010f50a4fe@github.com>
 <buknmFkv7N2TajbzvMhIuESWTBb5KfH_4V4NzwhPWLE=.1fd2964d-3450-4e7a-88ae-9dcd053efd62@github.com>
 <IOcuQ2EskLH7huYJIJVu9WtLkMZ7hRRCb9RpFwfEUBo=.d91bdea1-0515-4cd8-9d39-966f2f7a97fd@github.com>
Message-ID: <xfclvzGQNDo_tL2xG9hwaJT18wSh7nLG-0KDQ57ys48=.074bf11a-edac-4f77-8d30-a66bdd2c24b1@github.com>

On Thu, 1 Apr 2021 17:41:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> Okay. Lets do as @iwanowww suggesting.
>> 
>> Should we implement `dump_node` or should we just use `assert(alloc == NULL || alloc->is_Allocate() || alloc->as_CallStaticJava()->is_boxing_method(), "unexpected call node");`  without dumping?
>
> Creating node's dump string in separate method is complicated.
> We can just use `false` in assert:
> #ifdef ASSERT
>   if (alloc != nullptr && !alloc->is_Allocate() && !alloc->as_CallStaticJava()->is_boxing_method()) {
>     alloc->dump();
>     assert(false, "unexpected call node for scalar replacement");
>   }
> #endif

I did not see your latest changes before answering your question. You did exactly as I suggested. Good.

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

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

From neliasso at openjdk.java.net  Thu Apr  1 20:48:44 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 1 Apr 2021 20:48:44 GMT
Subject: RFR: 8264626: C1 should be able to inline excluded methods
Message-ID: <Ge6jM_AcaZCPCCeZWV3PUtVEWQS6pCpRivLPJYfYCLY=.edeadf27-1a5d-4d25-ade0-d50e1699d8b1@github.com>

I noticed a behavioral between c1 and c2. In c2 excluded methods can still be inlined, which is the desired behaviour. Inlining is controlled separately. I propose a small change to c1 inlining that make it work in the same way.

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

Commit messages:
 - c1: allow inlining of excluded methods

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

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

From neliasso at openjdk.java.net  Thu Apr  1 21:13:37 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 1 Apr 2021 21:13:37 GMT
Subject: RFR: 8264359: Compiler directives should enable DebugNonSafepoints
 when PrintAssembly is requested
Message-ID: <ksp0_Yds7sd-ry4MDFMd_fMHZqn8KWUn6ixsUaG0iMo=.51ef2950-9ce4-4baa-a569-3f99fd88901f@github.com>

DebugNonSafepoints should be set when PrintAssembly is requested. This only happened for compile commands but not for compiler directives. This PR moves the check to compiler directives - that code path is used for both directives and commands. I am leaving the check and update in arguments.cpp - there might be some need for using flag PrintAssembly for stubs or wrappers, in a code path that doesn't use commands or directives.

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

Commit messages:
 - Remove update from compilerOracle
 - enable DebugNonSafepoints when directives sets printasm

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

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

From kvn at openjdk.java.net  Thu Apr  1 22:02:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 1 Apr 2021 22:02:26 GMT
Subject: RFR: 8264359: Compiler directives should enable
 DebugNonSafepoints when PrintAssembly is requested
In-Reply-To: <ksp0_Yds7sd-ry4MDFMd_fMHZqn8KWUn6ixsUaG0iMo=.51ef2950-9ce4-4baa-a569-3f99fd88901f@github.com>
References: <ksp0_Yds7sd-ry4MDFMd_fMHZqn8KWUn6ixsUaG0iMo=.51ef2950-9ce4-4baa-a569-3f99fd88901f@github.com>
Message-ID: <pQERfkQOvVohgQNaBYzCO_dGj6rTOrhCJYt3g8hqMk4=.a62a15c3-50bf-4dee-8c6e-1aeeea8d11f2@github.com>

On Thu, 1 Apr 2021 20:57:04 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> DebugNonSafepoints should be set when PrintAssembly is requested. This only happened for compile commands but not for compiler directives. This PR moves the check to compiler directives - that code path is used for both directives and commands. I am leaving the check and update in arguments.cpp - there might be some need for using flag PrintAssembly for stubs or wrappers, in a code path that doesn't use commands or directives.

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From whuang at openjdk.java.net  Fri Apr  2 01:36:34 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 2 Apr 2021 01:36:34 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v13]
In-Reply-To: <SqHYD0FCMHi1qLVnGc2sDd4WOMziEJh8OM0x9AohAlY=.65f37a59-23d4-443a-bbf0-9664e11fb49d@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YUH9o_Z5_avs_-KiNy5jm1O9Hw9fO_uHUbZuy2ovc68=.b735d3c4-ce29-48d9-9425-67aa3f9ae240@github.com>
 <SqHYD0FCMHi1qLVnGc2sDd4WOMziEJh8OM0x9AohAlY=.65f37a59-23d4-443a-bbf0-9664e11fb49d@github.com>
Message-ID: <p1QgvUACdfvIHiVI77PXXHZ5uIDX62SVGsyTGMfD-jw=.9f73d289-6dca-4096-889d-05f3924c6100@github.com>

On Thu, 1 Apr 2021 17:44:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Good.

Thank you for your approval. ;-)

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

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

From whuang at openjdk.java.net  Fri Apr  2 01:36:34 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 2 Apr 2021 01:36:34 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v11]
In-Reply-To: <xfclvzGQNDo_tL2xG9hwaJT18wSh7nLG-0KDQ57ys48=.074bf11a-edac-4f77-8d30-a66bdd2c24b1@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <NPQkY9pXIIqtErXRUplF7RYiXIo6BQSxMA8-vZZEPIA=.82c47221-8e3d-4619-a016-c09b22eef169@github.com>
 <ZRVRWlUG64YA48qeU5DcmLEPmFI_iugKf06bOAnxxNU=.31cb88c4-4317-4389-9158-8cf2543ca862@github.com>
 <ZiTcc98n91b4Mc4BaMqD2im3JWIkCxm1afg0wlwJ0gc=.8f8a4c97-ed02-40eb-afc2-4f010f50a4fe@github.com>
 <buknmFkv7N2TajbzvMhIuESWTBb5KfH_4V4NzwhPWLE=.1fd2964d-3450-4e7a-88ae-9dcd053efd62@github.com>
 <IOcuQ2EskLH7huYJIJVu9WtLkMZ7hRRCb9RpFwfEUBo=.d91bdea1-0515-4cd8-9d39-966f2f7a97fd@github.com>
 <xfclvzGQNDo_tL2xG9hwaJT18wSh7nLG-0KDQ57ys48=.074bf11a-edac-4f77-8d30-a66bdd2c24b1@github.com>
Message-ID: <sJFRoUUbvMIv22LROUeFidoQq3PY2OrMXt-ygWfA3FA=.37ca9d5a-180e-4b00-b499-078ae712212b@github.com>

On Thu, 1 Apr 2021 17:43:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Creating node's dump string in separate method is complicated.
>> We can just use `false` in assert:
>> #ifdef ASSERT
>>   if (alloc != nullptr && !alloc->is_Allocate() && !alloc->as_CallStaticJava()->is_boxing_method()) {
>>     alloc->dump();
>>     assert(false, "unexpected call node for scalar replacement");
>>   }
>> #endif
>
> I did not see your latest changes before answering your question. You did exactly as I suggested. Good.

Thank you for your review.

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

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

From pli at openjdk.java.net  Fri Apr  2 02:30:24 2021
From: pli at openjdk.java.net (Pengfei Li)
Date: Fri, 2 Apr 2021 02:30:24 GMT
Subject: RFR: 8264409: AArch64: generate better code for Vector API allTrue
In-Reply-To: <JJi4MlR512iDgojKRMFTydXKkYJQgxtYokJ4TzDYNRY=.d8e7db85-38be-4265-a0c7-d81b053fa589@github.com>
References: <JJi4MlR512iDgojKRMFTydXKkYJQgxtYokJ4TzDYNRY=.d8e7db85-38be-4265-a0c7-d81b053fa589@github.com>
Message-ID: <2OZrusN7mizjpB0a0qOs2WiL4Bi5rxGmMGertHeYxwY=.118d860c-6e46-48af-8767-3df113014e78@github.com>

On Thu, 1 Apr 2021 07:58:07 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> In Vector API NEON implementation, we use a vector register to represent vector mask, where an element value of -1 is a true mask and an element value of 0 is a false mask. The allTrue() api is used to check whether all the elements of current mask are set.
> 
> Currently, the AArch64 NEON allTrue implementation looks like:
> 
>   andr  $tmp, T16B $src1, $src2\t# src2 is maskAllTrue
>   notr  $tmp, T16B, $tmp
>   addv  $tmp, T16B, $tmp
>   umov  $dst, $tmp, B, 0
>   cmp   $dst, 0
>   cset  $dst
> 
> where $src2 is a preset all true (-1) constant. We can optimize it to the code sequence like below, to check whether all bits are set:
> 
>   uminv $tmp, T16B, $src1
>   umov  $dst, $tmp, B, 0
>   cmp   $dst, 0xff
>   cset  $dst
> 
> With this codegen improvement, we can see about 8%~70% performance uplift on different machines for Alibaba's Vector API bigdata benchmarks [1][2].
> 
> Tested with tier1 and vector api jtreg tests.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/BooleanArrayCheck.java#L61
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/ValueRangeCheckAndCastL2I.java#L93

Overall looks good to me. (not a reviewer)

src/hotspot/cpu/aarch64/aarch64_neon.ad line 3571:

> 3569:   format %{ "uminv $tmp, T8B, $src1\n\t"
> 3570:             "umov  $dst, $tmp, B, 0\n\t"
> 3571:             "cmp   $dst, 0xff\n\t"

I think we should write "#0xff" here. But it looks that all other immediates in format field of aarch64_neon.ad lose the number sign as well.

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

Marked as reviewed by pli (Committer).

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

From njian at openjdk.java.net  Fri Apr  2 03:00:22 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Fri, 2 Apr 2021 03:00:22 GMT
Subject: RFR: 8264409: AArch64: generate better code for Vector API allTrue
In-Reply-To: <F_-V8J2yIXLPEKfuaTARMEcXuvTj1509fQ2sm2eidfg=.fa4d17af-f396-41fa-a0fb-accf9e9a7ede@github.com>
References: <JJi4MlR512iDgojKRMFTydXKkYJQgxtYokJ4TzDYNRY=.d8e7db85-38be-4265-a0c7-d81b053fa589@github.com>
 <F_-V8J2yIXLPEKfuaTARMEcXuvTj1509fQ2sm2eidfg=.fa4d17af-f396-41fa-a0fb-accf9e9a7ede@github.com>
Message-ID: <JaRQbZttQLDtapqVS_qXYXM80NaDxjErVYYjeslJUss=.2be7b69b-126d-4ced-9b57-9deeda6b4a71@github.com>

On Thu, 1 Apr 2021 09:02:39 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> It's a clever trick to use uminv for this specific case.
> The patch looks good to me.

Thank you for the review! @adinn

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

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

From njian at openjdk.java.net  Fri Apr  2 03:00:23 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Fri, 2 Apr 2021 03:00:23 GMT
Subject: RFR: 8264409: AArch64: generate better code for Vector API allTrue
In-Reply-To: <2OZrusN7mizjpB0a0qOs2WiL4Bi5rxGmMGertHeYxwY=.118d860c-6e46-48af-8767-3df113014e78@github.com>
References: <JJi4MlR512iDgojKRMFTydXKkYJQgxtYokJ4TzDYNRY=.d8e7db85-38be-4265-a0c7-d81b053fa589@github.com>
 <2OZrusN7mizjpB0a0qOs2WiL4Bi5rxGmMGertHeYxwY=.118d860c-6e46-48af-8767-3df113014e78@github.com>
Message-ID: <tnIClS3d8wpDf2SZ-d-u6qCp273VlwgTYIV-RW1U7Qs=.c4434563-bbfe-48a5-8660-f712c0043901@github.com>

On Fri, 2 Apr 2021 02:26:52 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> In Vector API NEON implementation, we use a vector register to represent vector mask, where an element value of -1 is a true mask and an element value of 0 is a false mask. The allTrue() api is used to check whether all the elements of current mask are set.
>> 
>> Currently, the AArch64 NEON allTrue implementation looks like:
>> 
>>   andr  $tmp, T16B $src1, $src2\t# src2 is maskAllTrue
>>   notr  $tmp, T16B, $tmp
>>   addv  $tmp, T16B, $tmp
>>   umov  $dst, $tmp, B, 0
>>   cmp   $dst, 0
>>   cset  $dst
>> 
>> where $src2 is a preset all true (-1) constant. We can optimize it to the code sequence like below, to check whether all bits are set:
>> 
>>   uminv $tmp, T16B, $src1
>>   umov  $dst, $tmp, B, 0
>>   cmp   $dst, 0xff
>>   cset  $dst
>> 
>> With this codegen improvement, we can see about 8%~70% performance uplift on different machines for Alibaba's Vector API bigdata benchmarks [1][2].
>> 
>> Tested with tier1 and vector api jtreg tests.
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/BooleanArrayCheck.java#L61
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/ValueRangeCheckAndCastL2I.java#L93
>
> src/hotspot/cpu/aarch64/aarch64_neon.ad line 3571:
> 
>> 3569:   format %{ "uminv $tmp, T8B, $src1\n\t"
>> 3570:             "umov  $dst, $tmp, B, 0\n\t"
>> 3571:             "cmp   $dst, 0xff\n\t"
> 
> I think we should write "#0xff" here. But it looks that all other immediates in format field of aarch64_neon.ad lose the number sign as well.

Thanks for the review, but I think both are ok.

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

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

From dongbo at openjdk.java.net  Fri Apr  2 03:10:57 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 2 Apr 2021 03:10:57 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

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:

 - Merge branch 'master' into aarch64.base64.decode
 - copyright
 - trivial fixes
 - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
 - Merge branch 'master' into aarch64.base64.decode
 - 8256245: AArch64: Implement Base64 decoding intrinsic

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3228/files
  - new: https://git.openjdk.java.net/jdk/pull/3228/files/e658ebf4..16ebc471

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

  Stats: 7270 lines in 287 files changed: 5225 ins; 950 del; 1095 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3228.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228

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

From jbhateja at openjdk.java.net  Fri Apr  2 03:19:45 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 2 Apr 2021 03:19:45 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v18]
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: <YtwXpgNf2OmJ_YNCd9xCBOeDG-2BdygGeZzybM8NHkw=.7deff0a3-1c3d-4860-80ab-af0d3f265204@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) Creation of a new concrete type TypeVectMask for mask generation nodes and a convivence routine Type::makemask which creates a regular vector types (TypeVect[SDXYZ]) for non-AVX-512 targets and TypeVectMask for a AVX-512 targets. 
> 
> 
> [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 with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - 8262355: Review comments resolutions.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8262355
 - 8262355: Updating copywriter for edited files.
 - 8262355: Adding missed safety check.
 - 8262355: Review comments resolution.
 - 8262355: Extending Type::isa_vect and Type::is_vect routines to TypeVectMask since its a valid vector type.
 - 8262355: Review comments resolution
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8262355
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8262355
 - 8262355: Review comments resolutions.
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/8cf1c62c...5aa07306

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

Changes: https://git.openjdk.java.net/jdk/pull/2768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2768&range=17
  Stats: 1560 lines in 41 files changed: 1284 ins; 20 del; 256 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  Fri Apr  2 03:23:36 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 2 Apr 2021 03:23:36 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v17]
In-Reply-To: <krBdWsc6gvti10xKwVQlsYRID1sHFa9d0DKEDluB4HQ=.2d0a026a-8445-44b3-bf1f-f79927ef5072@github.com>
References: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>
 <gGUNhQYlD2cTbk4_eMHWw8cu1a-UJxwrRZ1Ot4OFvzk=.674c517b-abcf-4eeb-b24c-e948eb2d49b4@github.com>
 <krBdWsc6gvti10xKwVQlsYRID1sHFa9d0DKEDluB4HQ=.2d0a026a-8445-44b3-bf1f-f79927ef5072@github.com>
Message-ID: <kGMarfYBiCvxBvhi2w0l1FLxrfaYXm_78YT0cDXkfK4=.6ca649dd-b268-490a-af5c-ac21b9ecc2eb@github.com>

On Mon, 29 Mar 2021 23:02:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8262355: Updating copywriter for edited files.
>
> Few notes.
> 1. In `sharedRuntime_*.cpp` you have name `opmask_state_*` and `.ad` files also `opmask` and  `opmask_reg_k*'. But in C2 code you call them `vectmask` which is confusing. I prefer to use the same name everywhere - `vectmask`:
> const RegMask* Matcher::predicate_reg_mask(void) {
>    return &_OPMASK_REG_mask;
>  }
> 
>  const TypeVect* Matcher::predicate_reg_type(const Type* elemTy, int length) {
>    return new TypeVectMask(TypeInt::BOOL, length);
>  }
> 2. I assume that they are used only for vectors in compiled code and in other cases the don't need to be saved/restored at safepoints.
> 3. In C2 shared code names are mess too: `VectorM, VMASK, RegVMask, TypeVectMask, VectorMaskCmp`.  I suggest to use `VectorMask, VECTMASK, RegVectMask`.

Hi @vnkozlov , @iwanowww , your comments have been resolved, kindly share the results of tier4/tier5 testing.

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

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

From xgong at openjdk.java.net  Fri Apr  2 03:26:16 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 2 Apr 2021 03:26:16 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <bH97iO9EOXZRcKTS2zyOBwfqJLoRUiP-wFzccuKb-fg=.bd983da8-9b58-4bb3-b8a3-395ef669aafc@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
 <bH97iO9EOXZRcKTS2zyOBwfqJLoRUiP-wFzccuKb-fg=.bd983da8-9b58-4bb3-b8a3-395ef669aafc@github.com>
Message-ID: <Fo4Qw_h0xKs4kBtdlv5mXy6mhh4e9hxWTs7YtC8a678=.9f90b57a-9146-4473-8036-7aee3a36b217@github.com>

On Thu, 1 Apr 2021 15:13:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the changing to AbstractMask.andNot and revert changes in VectorMask
>>   
>>   Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
>>   CustomizedGitHooks: yes
>
> Looks good.

Thanks for your review @PaulSandoz !

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

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

From jbhateja at openjdk.java.net  Fri Apr  2 03:29:30 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 2 Apr 2021 03:29:30 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v17]
In-Reply-To: <kGMarfYBiCvxBvhi2w0l1FLxrfaYXm_78YT0cDXkfK4=.6ca649dd-b268-490a-af5c-ac21b9ecc2eb@github.com>
References: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>
 <gGUNhQYlD2cTbk4_eMHWw8cu1a-UJxwrRZ1Ot4OFvzk=.674c517b-abcf-4eeb-b24c-e948eb2d49b4@github.com>
 <krBdWsc6gvti10xKwVQlsYRID1sHFa9d0DKEDluB4HQ=.2d0a026a-8445-44b3-bf1f-f79927ef5072@github.com>
 <kGMarfYBiCvxBvhi2w0l1FLxrfaYXm_78YT0cDXkfK4=.6ca649dd-b268-490a-af5c-ac21b9ecc2eb@github.com>
Message-ID: <gRhr0KD28SRXJFFnAlxLywZWTpgT4BTQF7T6M7WxX1w=.9daaaace-f744-437c-a376-08b023740280@github.com>

On Fri, 2 Apr 2021 03:20:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Few notes.
>> 1. In `sharedRuntime_*.cpp` you have name `opmask_state_*` and `.ad` files also `opmask` and  `opmask_reg_k*'. But in C2 code you call them `vectmask` which is confusing. I prefer to use the same name everywhere - `vectmask`:
>> const RegMask* Matcher::predicate_reg_mask(void) {
>>    return &_OPMASK_REG_mask;
>>  }
>> 
>>  const TypeVect* Matcher::predicate_reg_type(const Type* elemTy, int length) {
>>    return new TypeVectMask(TypeInt::BOOL, length);
>>  }
>> 2. I assume that they are used only for vectors in compiled code and in other cases the don't need to be saved/restored at safepoints.
>> 3. In C2 shared code names are mess too: `VectorM, VMASK, RegVMask, TypeVectMask, VectorMaskCmp`.  I suggest to use `VectorMask, VECTMASK, RegVectMask`.
>
> Hi @vnkozlov , @iwanowww , your comments have been resolved, kindly share the results of tier4/tier5 testing.

> Few notes.
> 
> 1. In `sharedRuntime_*.cpp` you have name `opmask_state_*` and `.ad` files also `opmask` and  `opmask_reg_k*'. But in C2 code you call them `vectmask`which is confusing. I prefer to use the same name everywhere -`vectmask`:
> 
> ```
> const RegMask* Matcher::predicate_reg_mask(void) {
>    return &_OPMASK_REG_mask;
>  }
> 
>  const TypeVect* Matcher::predicate_reg_type(const Type* elemTy, int length) {
>    return new TypeVectMask(TypeInt::BOOL, length);
>  }
> ```
> 
> 1. I assume that they are used only for vectors in compiled code and in other cases the don't need to be saved/restored at safepoints.
There are mask manipulation APIs exposed by jdk.incubator.vector.VectorMask class. This base patch is using new mask operands (used to propagate mask values thorough opmask register) for VectorMaskGen node used during small copy partial in-lining  optimization.

> 2. In C2 shared code names are mess too: `VectorM, VMASK, RegVMask, TypeVectMask, VectorMaskCmp`.  I suggest to use `VectorMask, VECTMASK, RegVectMask`.

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

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

From xgong at openjdk.java.net  Fri Apr  2 03:47:21 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 2 Apr 2021 03:47:21 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v17]
In-Reply-To: <gRhr0KD28SRXJFFnAlxLywZWTpgT4BTQF7T6M7WxX1w=.9daaaace-f744-437c-a376-08b023740280@github.com>
References: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>
 <gGUNhQYlD2cTbk4_eMHWw8cu1a-UJxwrRZ1Ot4OFvzk=.674c517b-abcf-4eeb-b24c-e948eb2d49b4@github.com>
 <krBdWsc6gvti10xKwVQlsYRID1sHFa9d0DKEDluB4HQ=.2d0a026a-8445-44b3-bf1f-f79927ef5072@github.com>
 <kGMarfYBiCvxBvhi2w0l1FLxrfaYXm_78YT0cDXkfK4=.6ca649dd-b268-490a-af5c-ac21b9ecc2eb@github.com>
 <gRhr0KD28SRXJFFnAlxLywZWTpgT4BTQF7T6M7WxX1w=.9daaaace-f744-437c-a376-08b023740280@github.com>
Message-ID: <m2xeMG1SKRHvADG2g9kxFbO8HSWWOQEu7GUH0RhnNQk=.9e345480-81c9-4fe7-8170-18601d6b8007@github.com>

On Fri, 2 Apr 2021 03:25:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @vnkozlov , @iwanowww , your comments have been resolved, kindly share the results of tier4/tier5 testing.
>
>> Few notes.
>> 
>> 1. In `sharedRuntime_*.cpp` you have name `opmask_state_*` and `.ad` files also `opmask` and  `opmask_reg_k*'. But in C2 code you call them `vectmask`which is confusing. I prefer to use the same name everywhere -`vectmask`:
>> 
>> ```
>> const RegMask* Matcher::predicate_reg_mask(void) {
>>    return &_OPMASK_REG_mask;
>>  }
>> 
>>  const TypeVect* Matcher::predicate_reg_type(const Type* elemTy, int length) {
>>    return new TypeVectMask(TypeInt::BOOL, length);
>>  }
>> ```
>> 
>> 1. I assume that they are used only for vectors in compiled code and in other cases the don't need to be saved/restored at safepoints.
> There are mask manipulation APIs exposed by jdk.incubator.vector.VectorMask class. This base patch is using new mask operands (used to propagate mask values thorough opmask register) for VectorMaskGen node used during small copy partial in-lining  optimization.
> 
>> 2. In C2 shared code names are mess too: `VectorM, VMASK, RegVMask, TypeVectMask, VectorMaskCmp`.  I suggest to use `VectorMask, VECTMASK, RegVectMask`.

Hi @jatin-bhateja , could you please also rename the `RegVMask` to `RegVectMask` in `src/hotspot/cpu/aarch64/aarch64.ad` ? This could make the following issue when building jdk image on aarch64:
Ideal node missing: RegVMask
assert fails /home/xiagon01/code/jdk/src/hotspot/share/adlc/archDesc.cpp 484: Failed lookup of ideal node

Thanks,
Xiaohong Gong

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

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

From dongbo at openjdk.java.net  Fri Apr  2 07:08:33 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 2 Apr 2021 07:08:33 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <Nn9jqfMe-xnqho_oiJKjJwTMc7rRUy3cjrB0E0RpsqY=.34512df4-3587-4b8c-96e2-af4d82851c8f@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
 <vxrUJagEcM97odeOocaFBJjZC_lNQwiuGmJwD0s-7wc=.d75d3029-2513-405c-afa3-f1ed8e7af5a1@github.com>
 <Nn9jqfMe-xnqho_oiJKjJwTMc7rRUy3cjrB0E0RpsqY=.34512df4-3587-4b8c-96e2-af4d82851c8f@github.com>
Message-ID: <zhrOSmz2aytq_cXzp88IC5wXiTw3fyjfPD6XPxx7dkY=.4f3a7845-f33e-49ef-8488-eaf81c2c1020@github.com>

On Tue, 30 Mar 2021 03:24:16 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>>> I think I can rewrite this part as loops.
>>> With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?
>> 
>> Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified.
>
>> > With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?
>> 
>> Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified.
> 
> Hi, @theRealAph @nick-arm 
> 
> The code is updated. The error handling in SIMD case was rewriten as loops.
> 
> Also combined the two non-SIMD code blocks into one.
> Due to we have only one non-SIMD loop now, it is moved into `generate_base64_decodeBlock`.
> The size of the stub is 692 bytes, the non-SIMD loop takes about 92 bytes if my calculation is right.
> 
> Verified with tests `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java`.
> Compared with previous implementation, the performance changes are negligible.
> 
> Other comments are addressed too. Thanks.

PING... Any suggestions on the updated commit?

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

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

From aph at openjdk.java.net  Fri Apr  2 08:41:34 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 08:41:34 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
Message-ID: <UP7i84Aa4xFdcVL0LyL4jGGXKEPeJo91xQsTOGU-Xeg=.1877b9d8-3468-40cc-8c02-9f5ae13703ed@github.com>

On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> 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:
> 
>  - Merge branch 'master' into aarch64.base64.decode
>  - copyright
>  - trivial fixes
>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>  - Merge branch 'master' into aarch64.base64.decode
>  - 8256245: AArch64: Implement Base64 decoding intrinsic

test/micro/org/openjdk/bench/java/util/Base64Decode.java line 85:

> 83:         }
> 84:     }
> 85: 

Are there any existing test cases for failing inputs?

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

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

From aph at openjdk.java.net  Fri Apr  2 08:49:29 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 08:49:29 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
Message-ID: <8yiJSbnHVrZTDGmKi7oQygWvCR8Gyvv4iSLdEAAez7I=.fa47a77d-54f1-4b60-94af-ad1aefb40470@github.com>

On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> 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:
> 
>  - Merge branch 'master' into aarch64.base64.decode
>  - copyright
>  - trivial fixes
>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>  - Merge branch 'master' into aarch64.base64.decode
>  - 8256245: AArch64: Implement Base64 decoding intrinsic

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5811:

> 5809:     __ ldrb(r12, __ post(src, 1));
> 5810:     __ ldrb(r13, __ post(src, 1));
> 5811:     // get the de-code

For loads and four post increments rather than one load and a few BFMs? Why?

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

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

From aph at openjdk.java.net  Fri Apr  2 08:49:24 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 08:49:24 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
Message-ID: <iu1E9W1adVNrVe6PynoXaGNrO3TL4eI1BvNuepqmlqw=.703f223a-50aa-401e-8a62-3dcba33cda63@github.com>

On Mon, 29 Mar 2021 03:28:54 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> > Please consider losing the non-SIMD case. It doesn't result in any significant gain.
> 
> The non-SIMD case is useful for MIME decoding performance.

Your test results suggest that it isn't useful for that, surely?

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

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

From jbhateja at openjdk.java.net  Fri Apr  2 09:12:54 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 2 Apr 2021 09:12:54 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v19]
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: <3Y2wKFJbWyH2VosIFD2UGusR-pCls2S0Y19w4lG2zRk=.79873d5b-0821-4eeb-a231-622c4c1a6367@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) Creation of a new concrete type TypeVectMask for mask generation nodes and a convivence routine Type::makemask which creates a regular vector types (TypeVect[SDXYZ]) for non-AVX-512 targets and TypeVectMask for a AVX-512 targets. 
> 
> 
> [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 AARCH64 build issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2768/files
  - new: https://git.openjdk.java.net/jdk/pull/2768/files/5aa07306..366641ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2768&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2768&range=17-18

  Stats: 32 lines in 3 files changed: 11 ins; 2 del; 19 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 njian at openjdk.java.net  Fri Apr  2 09:35:29 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Fri, 2 Apr 2021 09:35:29 GMT
Subject: Integrated: 8264409: AArch64: generate better code for Vector API
 allTrue
In-Reply-To: <JJi4MlR512iDgojKRMFTydXKkYJQgxtYokJ4TzDYNRY=.d8e7db85-38be-4265-a0c7-d81b053fa589@github.com>
References: <JJi4MlR512iDgojKRMFTydXKkYJQgxtYokJ4TzDYNRY=.d8e7db85-38be-4265-a0c7-d81b053fa589@github.com>
Message-ID: <oF3klPaRoCRqARgwZ_cN4KXRJ7pLxkoQIPNgvhU5veo=.04022777-03e8-4f96-acdb-9b38d4694bb1@github.com>

On Thu, 1 Apr 2021 07:58:07 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> In Vector API NEON implementation, we use a vector register to represent vector mask, where an element value of -1 is a true mask and an element value of 0 is a false mask. The allTrue() api is used to check whether all the elements of current mask are set.
> 
> Currently, the AArch64 NEON allTrue implementation looks like:
> 
>   andr  $tmp, T16B $src1, $src2\t# src2 is maskAllTrue
>   notr  $tmp, T16B, $tmp
>   addv  $tmp, T16B, $tmp
>   umov  $dst, $tmp, B, 0
>   cmp   $dst, 0
>   cset  $dst
> 
> where $src2 is a preset all true (-1) constant. We can optimize it to the code sequence like below, to check whether all bits are set:
> 
>   uminv $tmp, T16B, $src1
>   umov  $dst, $tmp, B, 0
>   cmp   $dst, 0xff
>   cset  $dst
> 
> With this codegen improvement, we can see about 8%~70% performance uplift on different machines for Alibaba's Vector API bigdata benchmarks [1][2].
> 
> Tested with tier1 and vector api jtreg tests.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/BooleanArrayCheck.java#L61
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/bigdata/ValueRangeCheckAndCastL2I.java#L93

This pull request has now been integrated.

Changeset: 0935eaa4
Author:    Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0935eaa4
Stats:     409 lines in 5 files changed: 13 ins; 12 del; 384 mod

8264409: AArch64: generate better code for Vector API allTrue

Reviewed-by: adinn, pli

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

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

From njian at openjdk.java.net  Fri Apr  2 10:04:17 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Fri, 2 Apr 2021 10:04:17 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
Message-ID: <SP6eBURfOt9R8efu6XZ16lXlPhvkvzBXO1vUV7Iyamw=.81b8b978-83b3-4d57-80af-f3a39042d611@github.com>

On Thu, 1 Apr 2021 03:39:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently "VectorMask.andNot()" is not vectorized:
>>     public VectorMask<E> andNot(VectorMask<E> m) {
>>         // FIXME: Generate good code here.
>>         return bOp(m, (i, a, b) -> a && !b);
>>     }
>> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
>> can be vectorized as well by calling them.
>> 
>> The performance gain is >100% for such a simple JMH:
>>   @Benchmark
>>   public Object andNot(Blackhole bh) {
>>     boolean[] mask = fm.apply(SPECIES.length());
>>     boolean[] r = fmt.apply(SPECIES.length());
>>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
>> 
>>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>>           rm = rm.andNot(vmask);
>>         }
>>     }
>>     return rm;
>>   }
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the changing to AbstractMask.andNot and revert changes in VectorMask
>   
>   Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
>   CustomizedGitHooks: yes

LGTM

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

Marked as reviewed by njian (Committer).

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

From xgong at openjdk.java.net  Fri Apr  2 10:04:17 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 2 Apr 2021 10:04:17 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot() [v2]
In-Reply-To: <SP6eBURfOt9R8efu6XZ16lXlPhvkvzBXO1vUV7Iyamw=.81b8b978-83b3-4d57-80af-f3a39042d611@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
 <Oz7tzQchYMMW7mVmc_2pYDgCdpqyDMreU-Sgb9m4QYs=.ab6cc3ce-dd35-4498-8a33-ee9815322aa0@github.com>
 <SP6eBURfOt9R8efu6XZ16lXlPhvkvzBXO1vUV7Iyamw=.81b8b978-83b3-4d57-80af-f3a39042d611@github.com>
Message-ID: <7bsAUC0QJ7brBAXu7bTwWuHV4mV4KKCnuPNH8ymY94k=.e545103d-b5f8-46af-92bf-4a236c75d6b6@github.com>

On Fri, 2 Apr 2021 09:59:31 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the changing to AbstractMask.andNot and revert changes in VectorMask
>>   
>>   Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
>>   CustomizedGitHooks: yes
>
> LGTM

Thanks for the review @nsjian !

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

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

From xgong at openjdk.java.net  Fri Apr  2 10:04:18 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 2 Apr 2021 10:04:18 GMT
Subject: Integrated: 8264109: Add vectorized implementation for
 VectorMask.andNot()
In-Reply-To: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
Message-ID: <L-ekfJb77kLc9SVKmwFAvp5krGfe7p21os3H3M8k_jw=.4c19752a-113f-44d7-81f9-e1c10c33df13@github.com>

On Fri, 26 Mar 2021 01:50:33 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently "VectorMask.andNot()" is not vectorized:
>     public VectorMask<E> andNot(VectorMask<E> m) {
>         // FIXME: Generate good code here.
>         return bOp(m, (i, a, b) -> a && !b);
>     }
> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
> can be vectorized as well by calling them.
> 
> The performance gain is >100% for such a simple JMH:
>   @Benchmark
>   public Object andNot(Blackhole bh) {
>     boolean[] mask = fm.apply(SPECIES.length());
>     boolean[] r = fmt.apply(SPECIES.length());
>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
> 
>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>           rm = rm.andNot(vmask);
>         }
>     }
>     return rm;
>   }

This pull request has now been integrated.

Changeset: 7d0a0bad
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7d0a0bad
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8264109: Add vectorized implementation for VectorMask.andNot()

Reviewed-by: psandoz, njian

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

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

From aph at openjdk.java.net  Fri Apr  2 10:20:25 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 10:20:25 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
Message-ID: <T7PlCTv8zluDpuWuogYW0PZknpj7HZjzeG8RrblWCes=.edf34990-3533-4f2f-b9aa-7ce571d96c59@github.com>

On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> 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:
> 
>  - Merge branch 'master' into aarch64.base64.decode
>  - copyright
>  - trivial fixes
>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>  - Merge branch 'master' into aarch64.base64.decode
>  - 8256245: AArch64: Implement Base64 decoding intrinsic

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5802:

> 5800:     // The 1st character of the input can be illegal if the data is MIME encoded.
> 5801:     // We cannot benefits from SIMD for this case. The max line size of MIME
> 5802:     // encoding is 76, with the PreProcess80B blob, we actually use no-simd

"cannot benefit"

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

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

From aph at openjdk.java.net  Fri Apr  2 10:20:20 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Apr 2021 10:20:20 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <zhrOSmz2aytq_cXzp88IC5wXiTw3fyjfPD6XPxx7dkY=.4f3a7845-f33e-49ef-8488-eaf81c2c1020@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
 <vxrUJagEcM97odeOocaFBJjZC_lNQwiuGmJwD0s-7wc=.d75d3029-2513-405c-afa3-f1ed8e7af5a1@github.com>
 <Nn9jqfMe-xnqho_oiJKjJwTMc7rRUy3cjrB0E0RpsqY=.34512df4-3587-4b8c-96e2-af4d82851c8f@github.com>
 <zhrOSmz2aytq_cXzp88IC5wXiTw3fyjfPD6XPxx7dkY=.4f3a7845-f33e-49ef-8488-eaf81c2c1020@github.com>
Message-ID: <Mk6kt6w3URs4k9Ouu4RNKWqByTFsDbW96SM7UlEii0Y=.e6c8d5dc-33f3-4933-942f-be5671ca777b@github.com>

On Fri, 2 Apr 2021 07:05:26 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> PING... Any suggestions on the updated commit?

Once you reply to the comments, sure.

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

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

From jbhateja at openjdk.java.net  Fri Apr  2 13:16:53 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 2 Apr 2021 13:16:53 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v20]
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: <rdHgBuZOmVeKML_Ujj8e1lsE_CNdLICx-nt4J_QJJg4=.25463408-3ad3-4b26-b635-a9ac23a790a5@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) Creation of a new concrete type TypeVectMask for mask generation nodes and a convivence routine Type::makemask which creates a regular vector types (TypeVect[SDXYZ]) for non-AVX-512 targets and TypeVectMask for a AVX-512 targets. 
> 
> 
> [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 with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - 8262355: Rebasing patch, 32bit clean-up.
 - Merge http://github.com/openjdk/jdk into JDK-8262355
 - 8262355: Fix AARCH64 build issue
 - 8262355: Review comments resolutions.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8262355
 - 8262355: Updating copywriter for edited files.
 - 8262355: Adding missed safety check.
 - 8262355: Review comments resolution.
 - 8262355: Extending Type::isa_vect and Type::is_vect routines to TypeVectMask since its a valid vector type.
 - 8262355: Review comments resolution
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/7d0a0bad...b9810d20

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

Changes: https://git.openjdk.java.net/jdk/pull/2768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2768&range=19
  Stats: 1588 lines in 41 files changed: 1294 ins; 19 del; 275 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 vlivanov at openjdk.java.net  Fri Apr  2 16:12:30 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 2 Apr 2021 16:12:30 GMT
Subject: RFR: 8264548: Dependencies: ClassHierarchyWalker::is_witness()
 cleanups [v2]
In-Reply-To: <jDdrrxXR-mPImUiQCzgdAu8UD516rWGw_F5fJh8SAU8=.1ac178fd-ece0-45d3-aa0c-a0a9068d9cb7@github.com>
References: <m69KB5H2485nxJ04DF8fZ8XHt6qXJLwYQaRq5jt0GvM=.94786055-9d85-4ee9-a1d5-af19677e134e@github.com>
 <HAOZRVvO_wPY-6jzH5n05Hj8h7gTjy4xF8jnXkBW-9I=.8367a1f0-02c3-4c71-90b7-ae1d5cff6bed@github.com>
 <TwTiB1FgdxMgPFphyYdPg8QoRu7-oGZ6wTd8XoTXCAc=.48c72f53-6167-4d9e-9375-5e4a9ac34cc7@github.com>
 <jDdrrxXR-mPImUiQCzgdAu8UD516rWGw_F5fJh8SAU8=.1ac178fd-ece0-45d3-aa0c-a0a9068d9cb7@github.com>
Message-ID: <hOHSJsNDgCNcy6x1Cn6ESiPPgexxEgwPQwrtQR9ot_g=.ca560905-17df-4c6b-91ab-b739ad0eb8af@github.com>

On Thu, 1 Apr 2021 17:23:57 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Good.
>
>> I created it as a dependent PR.
>> 
>> I think that's the way it works ([openjdk/skara#1087](https://github.com/openjdk/skara/pull/1087) which was used as an example in [1] looks similar).
>> 
>> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005232.html
> 
> As I understand when you are creating PR which based on an other PR you have to change `base:` from `master` to corresponding `pr/3293`  so that only difference of current PR are seen.

Thanks, Vladimir.

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

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

From vlivanov at openjdk.java.net  Fri Apr  2 16:12:31 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 2 Apr 2021 16:12:31 GMT
Subject: Integrated: 8264548: Dependencies: ClassHierarchyWalker::is_witness()
 cleanups
In-Reply-To: <m69KB5H2485nxJ04DF8fZ8XHt6qXJLwYQaRq5jt0GvM=.94786055-9d85-4ee9-a1d5-af19677e134e@github.com>
References: <m69KB5H2485nxJ04DF8fZ8XHt6qXJLwYQaRq5jt0GvM=.94786055-9d85-4ee9-a1d5-af19677e134e@github.com>
Message-ID: <a7IEuf2IDE2lyU-6jvpHfn9tZEeoUvznrFeGmRfMwkA=.47466421-ff84-42b5-b109-c5030f260c75@github.com>

On Wed, 31 Mar 2021 21:47:53 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Simplify `ClassHierarchyWalker::is_witness()`.
> 
> Testing: hs-tier1 - hs-tier4.

This pull request has now been integrated.

Changeset: f60e81bf
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f60e81bf
Stats:     35 lines in 1 file changed: 16 ins; 6 del; 13 mod

8264548: Dependencies: ClassHierarchyWalker::is_witness() cleanups

Reviewed-by: kvn

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

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

From dcubed at openjdk.java.net  Fri Apr  2 20:48:33 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 2 Apr 2021 20:48:33 GMT
Subject: RFR: 8264662: ProblemList
 vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java
 on win-x64 with ZGC
Message-ID: <SDmrv1pUYm4AY-RKVQQ_bnQoBWx83mPsIy2IjOjkUwE=.4d70c466-b257-4a57-b834-ef86e204f39a@github.com>

A trivial fix to ProblemList vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java
on win-x64 with ZGC

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

Commit messages:
 - 8264662: ProblemList vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java on win-x64 with ZGC

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

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

From hseigel at openjdk.java.net  Fri Apr  2 20:52:17 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 2 Apr 2021 20:52:17 GMT
Subject: RFR: 8264662: ProblemList
 vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java
 on win-x64 with ZGC
In-Reply-To: <SDmrv1pUYm4AY-RKVQQ_bnQoBWx83mPsIy2IjOjkUwE=.4d70c466-b257-4a57-b834-ef86e204f39a@github.com>
References: <SDmrv1pUYm4AY-RKVQQ_bnQoBWx83mPsIy2IjOjkUwE=.4d70c466-b257-4a57-b834-ef86e204f39a@github.com>
Message-ID: <F4OpUG5B6llCqjHGPiJijVW1rhoPMhKswCgSJR0zX7Q=.f887c306-06b8-4a5c-aeef-b749211bc6f4@github.com>

On Fri, 2 Apr 2021 20:41:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java
> on win-x64 with ZGC

Looks good and trivial.
Thanks, Harold

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

Marked as reviewed by hseigel (Reviewer).

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

From dcubed at openjdk.java.net  Fri Apr  2 21:35:20 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 2 Apr 2021 21:35:20 GMT
Subject: RFR: 8264662: ProblemList
 vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java
 on win-x64 with ZGC
In-Reply-To: <F4OpUG5B6llCqjHGPiJijVW1rhoPMhKswCgSJR0zX7Q=.f887c306-06b8-4a5c-aeef-b749211bc6f4@github.com>
References: <SDmrv1pUYm4AY-RKVQQ_bnQoBWx83mPsIy2IjOjkUwE=.4d70c466-b257-4a57-b834-ef86e204f39a@github.com>
 <F4OpUG5B6llCqjHGPiJijVW1rhoPMhKswCgSJR0zX7Q=.f887c306-06b8-4a5c-aeef-b749211bc6f4@github.com>
Message-ID: <GEjHW-sWdkkzVW6vXQR9J48ol65GKxdk2NnPwj3Yzvs=.e2178b7b-43b2-459a-a84b-a043e50c338d@github.com>

On Fri, 2 Apr 2021 20:49:35 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> A trivial fix to ProblemList vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java
>> on win-x64 with ZGC
>
> Looks good and trivial.
> Thanks, Harold

@hseigel - Thanks for the review!

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

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

From dcubed at openjdk.java.net  Fri Apr  2 21:35:21 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 2 Apr 2021 21:35:21 GMT
Subject: Integrated: 8264662: ProblemList
 vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java
 on win-x64 with ZGC
In-Reply-To: <SDmrv1pUYm4AY-RKVQQ_bnQoBWx83mPsIy2IjOjkUwE=.4d70c466-b257-4a57-b834-ef86e204f39a@github.com>
References: <SDmrv1pUYm4AY-RKVQQ_bnQoBWx83mPsIy2IjOjkUwE=.4d70c466-b257-4a57-b834-ef86e204f39a@github.com>
Message-ID: <oZBjrIPgrvWInQEFqq_gOTvQYLbEhDNam_qcz2VOT6Y=.c5d5618b-8d40-4a40-a57b-067169d5d9c1@github.com>

On Fri, 2 Apr 2021 20:41:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java
> on win-x64 with ZGC

This pull request has now been integrated.

Changeset: 9c283da1
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9c283da1
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8264662: ProblemList vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java on win-x64 with ZGC

Reviewed-by: hseigel

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

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

From iveresov at openjdk.java.net  Sat Apr  3 22:48:21 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Sat, 3 Apr 2021 22:48:21 GMT
Subject: RFR: 8264626: C1 should be able to inline excluded methods
In-Reply-To: <Ge6jM_AcaZCPCCeZWV3PUtVEWQS6pCpRivLPJYfYCLY=.edeadf27-1a5d-4d25-ade0-d50e1699d8b1@github.com>
References: <Ge6jM_AcaZCPCCeZWV3PUtVEWQS6pCpRivLPJYfYCLY=.edeadf27-1a5d-4d25-ade0-d50e1699d8b1@github.com>
Message-ID: <oEPa9dS6a-14jS04-XYTSguAmXml03vTql-L03l6TC4=.245b3d3d-f0ad-41cd-bdd1-b74eb53c799a@github.com>

On Thu, 1 Apr 2021 20:32:53 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> I noticed a behavioral between c1 and c2. In c2 excluded methods can still be inlined, which is the desired behaviour. Inlining is controlled separately. I propose a small change to c1 inlining that make it work in the same way.

Looks good.

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

Marked as reviewed by iveresov (Reviewer).

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

From kvn at openjdk.java.net  Sun Apr  4 03:33:54 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sun, 4 Apr 2021 03:33:54 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v20]
In-Reply-To: <rdHgBuZOmVeKML_Ujj8e1lsE_CNdLICx-nt4J_QJJg4=.25463408-3ad3-4b26-b635-a9ac23a790a5@github.com>
References: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>
 <rdHgBuZOmVeKML_Ujj8e1lsE_CNdLICx-nt4J_QJJg4=.25463408-3ad3-4b26-b635-a9ac23a790a5@github.com>
Message-ID: <QHpuYddtm7ffDzaXR1KkyAZgZXDSZoToDjLfe2eHHkk=.1329a4ef-c952-42ca-a961-45208fafe63a@github.com>

On Fri, 2 Apr 2021 13:16:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> 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) Creation of a new concrete type TypeVectMask for mask generation nodes and a convivence routine Type::makemask which creates a regular vector types (TypeVect[SDXYZ]) for non-AVX-512 targets and TypeVectMask for a AVX-512 targets. 
>> 
>> 
>> [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 with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - 8262355: Rebasing patch, 32bit clean-up.
>  - Merge http://github.com/openjdk/jdk into JDK-8262355
>  - 8262355: Fix AARCH64 build issue
>  - 8262355: Review comments resolutions.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8262355
>  - 8262355: Updating copywriter for edited files.
>  - 8262355: Adding missed safety check.
>  - 8262355: Review comments resolution.
>  - 8262355: Extending Type::isa_vect and Type::is_vect routines to TypeVectMask since its a valid vector type.
>  - 8262355: Review comments resolution
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/7d0a0bad...b9810d20

In general looks better.
But it seems you added new instructions into .ad files for ClearArray and String compare which was not in original changes and should not be.

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

Changes requested by kvn (Reviewer).

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

From jbhateja at openjdk.java.net  Sun Apr  4 10:50:39 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 4 Apr 2021 10:50:39 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v20]
In-Reply-To: <QHpuYddtm7ffDzaXR1KkyAZgZXDSZoToDjLfe2eHHkk=.1329a4ef-c952-42ca-a961-45208fafe63a@github.com>
References: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>
 <rdHgBuZOmVeKML_Ujj8e1lsE_CNdLICx-nt4J_QJJg4=.25463408-3ad3-4b26-b635-a9ac23a790a5@github.com>
 <QHpuYddtm7ffDzaXR1KkyAZgZXDSZoToDjLfe2eHHkk=.1329a4ef-c952-42ca-a961-45208fafe63a@github.com>
Message-ID: <ZReoS_Fu_ybb8eGo3xtw7d-0OxQHCw2JIbesZ_2ugq4=.1cb1e5bf-2231-4aaa-a35c-3e89c57d521c@github.com>

On Sun, 4 Apr 2021 03:30:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> In general looks better.
> But it seems you added new instructions into .ad files for ClearArray and String compare which was not in original changes and should not be.

Hi @vnkozlov ,

Thanks for reviewing the patch,  new instruction pattern hold a temporary opmask operand needed only for AVX512 flovour of instruction. 
Earleir same pattern was being used for non-AVX512 instruction which could have posed issues while accessing the encoding for these temporaries in emit routines  using as_KRegister()(as pointed by @iwanowww) which internally asserts is_KRegister() having UseAVX > 2 check.
We can look at opportunities to reducing redundancies around these new instruction pattern (if any) in subsiquent patches.

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

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

From kvn at openjdk.java.net  Sun Apr  4 17:26:04 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sun, 4 Apr 2021 17:26:04 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v20]
In-Reply-To: <rdHgBuZOmVeKML_Ujj8e1lsE_CNdLICx-nt4J_QJJg4=.25463408-3ad3-4b26-b635-a9ac23a790a5@github.com>
References: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>
 <rdHgBuZOmVeKML_Ujj8e1lsE_CNdLICx-nt4J_QJJg4=.25463408-3ad3-4b26-b635-a9ac23a790a5@github.com>
Message-ID: <ZwYoJyLqImSx4Mtk5uzqb6RP1JjFmfvf0PS9gqhPfPY=.c4b2c1f5-cc09-4ddb-b556-fc5cc401dd86@github.com>

On Fri, 2 Apr 2021 13:16:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> 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) Creation of a new concrete type TypeVectMask for mask generation nodes and a convivence routine Type::makemask which creates a regular vector types (TypeVect[SDXYZ]) for non-AVX-512 targets and TypeVectMask for a AVX-512 targets. 
>> 
>> 
>> [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 with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - 8262355: Rebasing patch, 32bit clean-up.
>  - Merge http://github.com/openjdk/jdk into JDK-8262355
>  - 8262355: Fix AARCH64 build issue
>  - 8262355: Review comments resolutions.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8262355
>  - 8262355: Updating copywriter for edited files.
>  - 8262355: Adding missed safety check.
>  - 8262355: Review comments resolution.
>  - 8262355: Extending Type::isa_vect and Type::is_vect routines to TypeVectMask since its a valid vector type.
>  - 8262355: Review comments resolution
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/7d0a0bad...b9810d20

Marked as reviewed by kvn (Reviewer).

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

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

From kvn at openjdk.java.net  Sun Apr  4 17:26:05 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sun, 4 Apr 2021 17:26:05 GMT
Subject: RFR: 8262355: Support for AVX-512 opmask register allocation.
 [v20]
In-Reply-To: <ZReoS_Fu_ybb8eGo3xtw7d-0OxQHCw2JIbesZ_2ugq4=.1cb1e5bf-2231-4aaa-a35c-3e89c57d521c@github.com>
References: <3NqvqAfKOiHvDo7gvwLvi5_U_9Rz8DFBijVVf1wpXWk=.90d51fb9-c6d0-45be-89b7-60851c7a6681@github.com>
 <rdHgBuZOmVeKML_Ujj8e1lsE_CNdLICx-nt4J_QJJg4=.25463408-3ad3-4b26-b635-a9ac23a790a5@github.com>
 <QHpuYddtm7ffDzaXR1KkyAZgZXDSZoToDjLfe2eHHkk=.1329a4ef-c952-42ca-a961-45208fafe63a@github.com>
 <ZReoS_Fu_ybb8eGo3xtw7d-0OxQHCw2JIbesZ_2ugq4=.1cb1e5bf-2231-4aaa-a35c-3e89c57d521c@github.com>
Message-ID: <C59ixDae6WCj820xdLpoH8Kd8Oe5N7F2t2FDFkdlCvc=.29f0dc36-6649-4690-8517-66e0039b81ed@github.com>

On Sun, 4 Apr 2021 10:47:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> In general looks better.
>> But it seems you added new instructions into .ad files for ClearArray and String compare which was not in original changes and should not be.
>
>> In general looks better.
>> But it seems you added new instructions into .ad files for ClearArray and String compare which was not in original changes and should not be.
> 
> Hi @vnkozlov ,
> 
> Thanks for reviewing the patch,  new instruction pattern hold a temporary opmask operand needed only for AVX512 flovour of instruction. 
> Earleir same pattern was being used for non-AVX512 instruction which could have posed issues while accessing the encoding for these temporaries in emit routines  using as_KRegister()(as pointed by @iwanowww) which internally asserts is_KRegister() having UseAVX > 2 check.
> We can look at opportunities to reducing redundancies around these new instruction pattern (if any) in subsiquent patches.

Got it.

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

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

From jbhateja at openjdk.java.net  Sun Apr  4 17:52:17 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 4 Apr 2021 17:52:17 GMT
Subject: Integrated: 8262355: Support for AVX-512 opmask register allocation.
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: <JG4SXoV8pmgL8wJPDHqJ4iJ77TQWc8F66p_uYovGs2E=.73a10556-3265-4973-9e85-fa87c7c6c4d7@github.com>

On Sun, 28 Feb 2021 18:35:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> 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) Creation of a new concrete type TypeVectMask for mask generation nodes and a convivence routine Type::makemask which creates a regular vector types (TypeVect[SDXYZ]) for non-AVX-512 targets and TypeVectMask for a AVX-512 targets. 
> 
> 
> [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

This pull request has now been integrated.

Changeset: f084bd2f
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f084bd2f
Stats:     1588 lines in 41 files changed: 1294 ins; 19 del; 275 mod

8262355: Support for AVX-512 opmask register allocation.

Reviewed-by: vlivanov, njian, kvn

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

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

From ogatak at openjdk.java.net  Mon Apr  5 03:14:05 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Mon, 5 Apr 2021 03:14:05 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v8]
In-Reply-To: <YWKRqgDjXqDMIGR8za0Q7-kktL7W4iqUHnvXpHkreQ4=.305f14d8-2f84-4c1b-8baf-0175e9b65301@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <wGgsoSqiZVa79oudP5RIo2yr2VTm8uk-UWdzjTBipms=.ecd37138-e77f-4837-a13c-3541ac5bef5d@github.com>
 <YWKRqgDjXqDMIGR8za0Q7-kktL7W4iqUHnvXpHkreQ4=.305f14d8-2f84-4c1b-8baf-0175e9b65301@github.com>
Message-ID: <D1AFts3YHuey1WHvaOJ8Ikx6oS_1y70l8ZTOxgCmZME=.06f18021-1331-4f33-b7ca-13675200b82c@github.com>

On Thu, 25 Mar 2021 10:50:45 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up compute_padding() and fix grammatical errors
>
> Looks good to me, now. Is the latest version substantially tested? We need to rely on IBMs testing because nobody else has Power10.

@TheRealMDoerr  @CoreyAshford  Thank you for your review.  I think this is now ready to be integrated.

@TheRealMDoerr  Could you sponsor this pull request?

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

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

From thartmann at openjdk.java.net  Tue Apr  6 05:58:18 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 6 Apr 2021 05:58:18 GMT
Subject: RFR: 8264359: Compiler directives should enable
 DebugNonSafepoints when PrintAssembly is requested
In-Reply-To: <ksp0_Yds7sd-ry4MDFMd_fMHZqn8KWUn6ixsUaG0iMo=.51ef2950-9ce4-4baa-a569-3f99fd88901f@github.com>
References: <ksp0_Yds7sd-ry4MDFMd_fMHZqn8KWUn6ixsUaG0iMo=.51ef2950-9ce4-4baa-a569-3f99fd88901f@github.com>
Message-ID: <ImPXUDwyJ_5GNx65en2m6AK1XPwjEYCyYehr_aqqOkQ=.7750f8c5-36cb-4c76-b106-5d6fc1a26c13@github.com>

On Thu, 1 Apr 2021 20:57:04 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> DebugNonSafepoints should be set when PrintAssembly is requested. This only happened for compile commands but not for compiler directives. This PR moves the check to compiler directives - that code path is used for both directives and commands. I am leaving the check and update in arguments.cpp - there might be some need for using flag PrintAssembly for stubs or wrappers, in a code path that doesn't use commands or directives.

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

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

From thartmann at openjdk.java.net  Tue Apr  6 05:59:23 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 6 Apr 2021 05:59:23 GMT
Subject: RFR: 8264626: C1 should be able to inline excluded methods
In-Reply-To: <Ge6jM_AcaZCPCCeZWV3PUtVEWQS6pCpRivLPJYfYCLY=.edeadf27-1a5d-4d25-ade0-d50e1699d8b1@github.com>
References: <Ge6jM_AcaZCPCCeZWV3PUtVEWQS6pCpRivLPJYfYCLY=.edeadf27-1a5d-4d25-ade0-d50e1699d8b1@github.com>
Message-ID: <v3ZhdQBeMsMKoDdoBLsKYQL0lW8V3T30ns_6tqubz3Q=.f22ca733-5878-4a36-8aeb-41a2c7e4edd5@github.com>

On Thu, 1 Apr 2021 20:32:53 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> I noticed a behavioral between c1 and c2. In c2 excluded methods can still be inlined, which is the desired behaviour. Inlining is controlled separately. I propose a small change to c1 inlining that make it work in the same way.

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From xgong at openjdk.java.net  Tue Apr  6 06:00:18 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 6 Apr 2021 06:00:18 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask
In-Reply-To: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
Message-ID: <4LM1zt2vONG29YFtBYQ9nzi6UJqfQP_22vNULK3JbV0=.92a9e621-ca59-4ad0-8a84-3bb6719dfa0b@github.com>

On Mon, 29 Mar 2021 06:00:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
> 
> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
>   VectorLoadMask (VectorStoreMask vmask)
> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
> vectors with the same element size and vector length, it's safe to do the optimization:
>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.

Hi, could anyone please help to look at this PR? Thanks so much!

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

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

From neliasso at openjdk.java.net  Tue Apr  6 06:49:33 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 6 Apr 2021 06:49:33 GMT
Subject: RFR: 8264626: C1 should be able to inline excluded methods
In-Reply-To: <v3ZhdQBeMsMKoDdoBLsKYQL0lW8V3T30ns_6tqubz3Q=.f22ca733-5878-4a36-8aeb-41a2c7e4edd5@github.com>
References: <Ge6jM_AcaZCPCCeZWV3PUtVEWQS6pCpRivLPJYfYCLY=.edeadf27-1a5d-4d25-ade0-d50e1699d8b1@github.com>
 <v3ZhdQBeMsMKoDdoBLsKYQL0lW8V3T30ns_6tqubz3Q=.f22ca733-5878-4a36-8aeb-41a2c7e4edd5@github.com>
Message-ID: <w2czjPiGfMm0JQvoMJv-oVPBtXw3QYAEwAQTCZ9bFOM=.c00af4e8-dd79-4303-af70-087a5c48d462@github.com>

On Tue, 6 Apr 2021 05:56:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> I noticed a behavioral between c1 and c2. In c2 excluded methods can still be inlined, which is the desired behaviour. Inlining is controlled separately. I propose a small change to c1 inlining that make it work in the same way.
>
> Looks good to me.

Thanks for the reviews Igor and Tobias!

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

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

From neliasso at openjdk.java.net  Tue Apr  6 06:49:34 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 6 Apr 2021 06:49:34 GMT
Subject: Integrated: 8264626: C1 should be able to inline excluded methods
In-Reply-To: <Ge6jM_AcaZCPCCeZWV3PUtVEWQS6pCpRivLPJYfYCLY=.edeadf27-1a5d-4d25-ade0-d50e1699d8b1@github.com>
References: <Ge6jM_AcaZCPCCeZWV3PUtVEWQS6pCpRivLPJYfYCLY=.edeadf27-1a5d-4d25-ade0-d50e1699d8b1@github.com>
Message-ID: <Rusz101apzK_b--Lx8QQ44JnIwfI3dDufNdJmcN_5V4=.a5c21335-d5a6-45e0-810b-d49039e030a2@github.com>

On Thu, 1 Apr 2021 20:32:53 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> I noticed a behavioral between c1 and c2. In c2 excluded methods can still be inlined, which is the desired behaviour. Inlining is controlled separately. I propose a small change to c1 inlining that make it work in the same way.

This pull request has now been integrated.

Changeset: ec7b0028
Author:    Nils Eliasson <neliasso at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec7b0028
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8264626: C1 should be able to inline excluded methods

Reviewed-by: iveresov, thartmann

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

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

From neliasso at openjdk.java.net  Tue Apr  6 06:50:33 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 6 Apr 2021 06:50:33 GMT
Subject: RFR: 8264359: Compiler directives should enable
 DebugNonSafepoints when PrintAssembly is requested
In-Reply-To: <ImPXUDwyJ_5GNx65en2m6AK1XPwjEYCyYehr_aqqOkQ=.7750f8c5-36cb-4c76-b106-5d6fc1a26c13@github.com>
References: <ksp0_Yds7sd-ry4MDFMd_fMHZqn8KWUn6ixsUaG0iMo=.51ef2950-9ce4-4baa-a569-3f99fd88901f@github.com>
 <ImPXUDwyJ_5GNx65en2m6AK1XPwjEYCyYehr_aqqOkQ=.7750f8c5-36cb-4c76-b106-5d6fc1a26c13@github.com>
Message-ID: <25Ge_E5uerbg2dfWiYKbYOoIgkNkjWNH9L6IxqxouIc=.9847bcfd-12d4-456e-9499-d6c66ae11e9b@github.com>

On Tue, 6 Apr 2021 05:55:08 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> DebugNonSafepoints should be set when PrintAssembly is requested. This only happened for compile commands but not for compiler directives. This PR moves the check to compiler directives - that code path is used for both directives and commands. I am leaving the check and update in arguments.cpp - there might be some need for using flag PrintAssembly for stubs or wrappers, in a code path that doesn't use commands or directives.
>
> Looks good.

Thanks for the reviews Vladimir and Tobias!

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

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

From neliasso at openjdk.java.net  Tue Apr  6 06:50:34 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 6 Apr 2021 06:50:34 GMT
Subject: Integrated: 8264359: Compiler directives should enable
 DebugNonSafepoints when PrintAssembly is requested
In-Reply-To: <ksp0_Yds7sd-ry4MDFMd_fMHZqn8KWUn6ixsUaG0iMo=.51ef2950-9ce4-4baa-a569-3f99fd88901f@github.com>
References: <ksp0_Yds7sd-ry4MDFMd_fMHZqn8KWUn6ixsUaG0iMo=.51ef2950-9ce4-4baa-a569-3f99fd88901f@github.com>
Message-ID: <RcN3CLG8CTNL_p07ZoXvZfCU7Ro88HS18kNxpTb-TMQ=.6d921d9c-f964-4b5c-a028-9a7d6d69f977@github.com>

On Thu, 1 Apr 2021 20:57:04 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> DebugNonSafepoints should be set when PrintAssembly is requested. This only happened for compile commands but not for compiler directives. This PR moves the check to compiler directives - that code path is used for both directives and commands. I am leaving the check and update in arguments.cpp - there might be some need for using flag PrintAssembly for stubs or wrappers, in a code path that doesn't use commands or directives.

This pull request has now been integrated.

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

8264359: Compiler directives should enable DebugNonSafepoints when PrintAssembly is requested

Reviewed-by: kvn, thartmann

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

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

From dongbo at openjdk.java.net  Tue Apr  6 06:58:03 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 6 Apr 2021 06:58:03 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v4]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <eEt8wWNkzqD7QZ5Cjk6l6_72WbwqZy8a6d_pRTjh4oQ=.3d028758-b688-4998-9325-6ab5822a22dd@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

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

  load data with one ldrw, add JMH tests for error inputs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3228/files
  - new: https://git.openjdk.java.net/jdk/pull/3228/files/16ebc471..54a75f05

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

  Stats: 37 lines in 2 files changed: 30 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3228.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228

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

From dongbo at openjdk.java.net  Tue Apr  6 07:25:57 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 6 Apr 2021 07:25:57 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v5]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - conflicts resolved
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into aarch64.base64.decode
 - resovling conflicts
 - load data with one ldrw, add JMH tests for error inputs
 - Merge branch 'master' into aarch64.base64.decode
 - copyright
 - trivial fixes
 - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
 - Merge branch 'master' into aarch64.base64.decode
 - 8256245: AArch64: Implement Base64 decoding intrinsic

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

Changes: https://git.openjdk.java.net/jdk/pull/3228/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=04
  Stats: 438 lines in 3 files changed: 438 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3228.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228

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

From rcastanedalo at openjdk.java.net  Tue Apr  6 07:57:42 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 6 Apr 2021 07:57:42 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
Message-ID: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>

This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).

The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).

Tested on:
- original bug reproducer
- hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
- hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)

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

Commit messages:
 - Update comments in test case
 - Exclude MachMerge nodes from dominance assertion
 - Remove cloned multi-nodes in call-catch cleanup
 - Document assumptions in live-range splitting
 - Add basic definition dominance assertion
 - Add test case

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

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

From dongbo at openjdk.java.net  Tue Apr  6 08:04:12 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 6 Apr 2021 08:04:12 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <Mk6kt6w3URs4k9Ouu4RNKWqByTFsDbW96SM7UlEii0Y=.e6c8d5dc-33f3-4933-942f-be5671ca777b@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
 <vxrUJagEcM97odeOocaFBJjZC_lNQwiuGmJwD0s-7wc=.d75d3029-2513-405c-afa3-f1ed8e7af5a1@github.com>
 <Nn9jqfMe-xnqho_oiJKjJwTMc7rRUy3cjrB0E0RpsqY=.34512df4-3587-4b8c-96e2-af4d82851c8f@github.com>
 <zhrOSmz2aytq_cXzp88IC5wXiTw3fyjfPD6XPxx7dkY=.4f3a7845-f33e-49ef-8488-eaf81c2c1020@github.com>
 <Mk6kt6w3URs4k9Ouu4RNKWqByTFsDbW96SM7UlEii0Y=.e6c8d5dc-33f3-4933-942f-be5671ca777b@github.com>
Message-ID: <PJmMVOec8NRmY2RRgiirbiCe9xvJm_vXdW53mlVjWMo=.03639f65-71d9-4cfa-92c7-f85ff81d505e@github.com>

On Fri, 2 Apr 2021 10:17:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> PING... Any suggestions on the updated commit?
>
>> PING... Any suggestions on the updated commit?
> 
> Once you reply to the comments, sure.

>
> Are there any existing test cases for failing inputs?
>
I added one, the error character is injected at the paramized index of the encoded data.
There are no big differences for small error injected index, seems too much time is took by exception handing.
Witnessed ~2x performance improvements as expected. The JMH tests:
### Kunpeng 916, intrinsic?tested with `-jar benchmarks.jar testBase64WithErrorInputsDecode -p errorIndex=3,64,144,208,272,1000,20000 -p maxNumBytes=1`
Base64Decode.testBase64WithErrorInputsDecode             3           4              1  avgt   10   3696.151 ? 202.783  ns/op
Base64Decode.testBase64WithErrorInputsDecode            64           4              1  avgt   10   3899.269 ? 178.289  ns/op
Base64Decode.testBase64WithErrorInputsDecode           144           4              1  avgt   10   3902.022 ? 163.611  ns/op
Base64Decode.testBase64WithErrorInputsDecode           208           4              1  avgt   10   3982.423 ? 256.638  ns/op
Base64Decode.testBase64WithErrorInputsDecode           272           4              1  avgt   10   3984.545 ? 144.282  ns/op
Base64Decode.testBase64WithErrorInputsDecode          1000           4              1  avgt   10   4532.959 ? 310.068  ns/op
Base64Decode.testBase64WithErrorInputsDecode         20000           4              1  avgt   10  17578.148 ? 631.600  ns/op
### Kunpeng 916, default?tested with `-XX:-UseBASE64Intrinsics -jar benchmarks.jar testBase64WithErrorInputsDecode -p errorIndex=3,64,144,208,272,1000,20000 -p maxNumBytes=1`
Base64Decode.testBase64WithErrorInputsDecode             3           4              1  avgt   10   3760.330 ? 261.672  ns/op
Base64Decode.testBase64WithErrorInputsDecode            64           4              1  avgt   10   3900.326 ? 121.632  ns/op
Base64Decode.testBase64WithErrorInputsDecode           144           4              1  avgt   10   4041.428 ? 174.435  ns/op
Base64Decode.testBase64WithErrorInputsDecode           208           4              1  avgt   10   4177.670 ? 214.433  ns/op
Base64Decode.testBase64WithErrorInputsDecode           272           4              1  avgt   10   4324.020 ? 106.826  ns/op
Base64Decode.testBase64WithErrorInputsDecode          1000           4              1  avgt   10   5476.469 ? 171.647  ns/op
Base64Decode.testBase64WithErrorInputsDecode         20000           4              1  avgt   10  34163.743 ? 162.263  ns/op

>
> Your test results suggest that it isn't useful for that, surely?
>
The results suggest non-SIMD code provides ~11.9% improvements for MIME decoding.
Furthermore, according to local tests, we may have about ~30% performance regression for MIME decoding without non-SIMD code.

In worst case, a MIME line has only 4 base64 encoded characters and a newline string consisted of error inputs, e.g. `\r\n`.
When the instrinsic encounter an illegal character (`\r`), it has to exit.
Then the Java code will pass the next illegal source byte (`\n`) to the intrinsic.
With only SIMD code, it will execute too much wasty instructions before it can detect the error.
Whie with non-SIMD code, the instrinsic will execute only one non-SIMD round for this error input.

>
> For loads and four post increments rather than one load and a few BFMs? Why?
>
Nice suggestion. Done, thanks.

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

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

From whuang at openjdk.java.net  Tue Apr  6 09:01:32 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Tue, 6 Apr 2021 09:01:32 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v13]
In-Reply-To: <SqHYD0FCMHi1qLVnGc2sDd4WOMziEJh8OM0x9AohAlY=.65f37a59-23d4-443a-bbf0-9664e11fb49d@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YUH9o_Z5_avs_-KiNy5jm1O9Hw9fO_uHUbZuy2ovc68=.b735d3c4-ce29-48d9-9425-67aa3f9ae240@github.com>
 <SqHYD0FCMHi1qLVnGc2sDd4WOMziEJh8OM0x9AohAlY=.65f37a59-23d4-443a-bbf0-9664e11fb49d@github.com>
Message-ID: <0NVZ-QNbbnPhWLtP8QyXeHAa7NIV50nStefQ6hNCc9w=.0cb67ad5-7076-461e-8261-fd9f0d69d647@github.com>

On Thu, 1 Apr 2021 17:44:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   trivial fix
>
> Good.

@vnkozlov Can you do me a favor to `/sponsor` this patch?

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

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

From shade at openjdk.java.net  Tue Apr  6 09:36:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Apr 2021 09:36:45 GMT
Subject: RFR: 8264759: x86_32 Minimal VM build failure after JDK-8262355
Message-ID: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>

* For target hotspot_variant-minimal_libjvm_objs_sharedRuntime_x86_32.o:

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

Commit messages:
 - 8264759: x86_32 Minimal VM build failure after JDK-8262355

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

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

From neliasso at openjdk.java.net  Tue Apr  6 09:45:40 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 6 Apr 2021 09:45:40 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
Message-ID: <5JuMKHvQeAR147_GiEJFmWNFxpU00DKY3b9Wo1YelQM=.d45c40cd-dd32-498f-a1fe-99aab5163cec@github.com>

On Thu, 1 Apr 2021 10:02:39 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
> 
> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
> 
> Tested on:
> - original bug reproducer
> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)

Looks good!

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

Marked as reviewed by neliasso (Reviewer).

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

From aph at openjdk.java.net  Tue Apr  6 09:47:31 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 6 Apr 2021 09:47:31 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <2JT6v2dKf3XicURmOEsdociN7j0SgmVwYdQMr8PaU-c=.9963e17e-44de-4576-9726-c1b15bd7f4e7@github.com>

On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.

What is the reasoning here? Sure, there can be illegal characters at the start, but what if there are not? The generic logic uses decodeBlock() even in the MIME case, because we don't know that there certainly will be illegal characters.

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

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

From neliasso at openjdk.java.net  Tue Apr  6 09:54:21 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 6 Apr 2021 09:54:21 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <5JuMKHvQeAR147_GiEJFmWNFxpU00DKY3b9Wo1YelQM=.d45c40cd-dd32-498f-a1fe-99aab5163cec@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <5JuMKHvQeAR147_GiEJFmWNFxpU00DKY3b9Wo1YelQM=.d45c40cd-dd32-498f-a1fe-99aab5163cec@github.com>
Message-ID: <O8IAHd3aukudIiZ374jIciQM_-MaNUsAS387S0iWXHM=.432bb680-ee9a-4860-8029-18400516d8bd@github.com>

On Tue, 6 Apr 2021 09:42:01 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
>> 
>> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
>> 
>> Tested on:
>> - original bug reproducer
>> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
>> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)
>
> Looks good!

And thanks for the PDF with the excellent walk through!

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

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

From rcastanedalo at openjdk.java.net  Tue Apr  6 09:54:21 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 6 Apr 2021 09:54:21 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <5JuMKHvQeAR147_GiEJFmWNFxpU00DKY3b9Wo1YelQM=.d45c40cd-dd32-498f-a1fe-99aab5163cec@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <5JuMKHvQeAR147_GiEJFmWNFxpU00DKY3b9Wo1YelQM=.d45c40cd-dd32-498f-a1fe-99aab5163cec@github.com>
Message-ID: <l6ko2puM-0xEgK1UEz1eFs1gbhal99IHrLzvSZ3z2Qc=.b0d8e5bb-cd34-4014-b305-5db485126b02@github.com>

On Tue, 6 Apr 2021 09:42:01 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Looks good!

Thanks for reviewing, Nils!

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

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

From thartmann at openjdk.java.net  Tue Apr  6 10:15:24 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 6 Apr 2021 10:15:24 GMT
Subject: RFR: 8264759: x86_32 Minimal VM build failure after JDK-8262355
In-Reply-To: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
References: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
Message-ID: <85S5rOUs-6I2mblRBp-NnPlYVqM3q-zW8b37C7LAsO0=.8e027e0a-a2ed-4cd0-ad75-332544cf5432@github.com>

On Tue, 6 Apr 2021 09:29:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> * For target hotspot_variant-minimal_libjvm_objs_sharedRuntime_x86_32.o:

Looks good and trivial to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From dongbo at openjdk.java.net  Tue Apr  6 11:19:36 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 6 Apr 2021 11:19:36 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <2JT6v2dKf3XicURmOEsdociN7j0SgmVwYdQMr8PaU-c=.9963e17e-44de-4576-9726-c1b15bd7f4e7@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <2JT6v2dKf3XicURmOEsdociN7j0SgmVwYdQMr8PaU-c=.9963e17e-44de-4576-9726-c1b15bd7f4e7@github.com>
Message-ID: <ThSwvJE2dDAfcx9XR0aeQ_0-YTnyEuFQ_HAF0qZs-pc=.c8601884-fa0d-4a88-8b68-ba5ac8b26c8f@github.com>

On Tue, 6 Apr 2021 09:44:28 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> What is the reasoning here? Sure, there can be illegal characters at the start, but what if there are not? The generic logic uses decodeBlock() even in the MIME case, because we don't know that there certainly will be illegal characters.

This code block only process 80B of the inputs.
If no illegal characters were found, the stub will use the SIMD instructions to process the rest of the inputs if the data length is large enough, i.e. >= 64B, to form up at least one SIMD round.

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

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

From thartmann at openjdk.java.net  Tue Apr  6 12:34:26 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 6 Apr 2021 12:34:26 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v13]
In-Reply-To: <YUH9o_Z5_avs_-KiNy5jm1O9Hw9fO_uHUbZuy2ovc68=.b735d3c4-ce29-48d9-9425-67aa3f9ae240@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YUH9o_Z5_avs_-KiNy5jm1O9Hw9fO_uHUbZuy2ovc68=.b735d3c4-ce29-48d9-9425-67aa3f9ae240@github.com>
Message-ID: <SSc32E1gqVYpB5n8IRNXQwhk8VeZqQipekpeXHKD9oQ=.dc060539-635b-4f8b-a186-529c0393c2a2@github.com>

On Tue, 30 Mar 2021 01:53:12 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:
> 
>   trivial fix

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

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

From aph at openjdk.java.net  Tue Apr  6 14:07:26 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 6 Apr 2021 14:07:26 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v5]
In-Reply-To: <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com>
Message-ID: <rqcpOO-iWcmNJ_MQnX-3ZB0q89o5Avx1Iu8WDLOs_lE=.bfed903b-572e-4aff-8430-f5b01302c2b7@github.com>

On Tue, 6 Apr 2021 07:25:57 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - conflicts resolved
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into aarch64.base64.decode
>  - resovling conflicts
>  - load data with one ldrw, add JMH tests for error inputs
>  - Merge branch 'master' into aarch64.base64.decode
>  - copyright
>  - trivial fixes
>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>  - Merge branch 'master' into aarch64.base64.decode
>  - 8256245: AArch64: Implement Base64 decoding intrinsic

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5800:

> 5798:     __ br(Assembler::LT, Process4B);
> 5799: 
> 5800:     // The 1st character of the input can be illegal if the data is MIME encoded.

Why is this sentence here? It is very misleading.

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

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

From aph at openjdk.java.net  Tue Apr  6 14:07:28 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 6 Apr 2021 14:07:28 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3]
In-Reply-To: <T7PlCTv8zluDpuWuogYW0PZknpj7HZjzeG8RrblWCes=.edf34990-3533-4f2f-b9aa-7ce571d96c59@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com>
 <T7PlCTv8zluDpuWuogYW0PZknpj7HZjzeG8RrblWCes=.edf34990-3533-4f2f-b9aa-7ce571d96c59@github.com>
Message-ID: <W232T35L00czxXOLnQkQTlR5dRUh2lJGEMfT9RRoEuM=.500f1793-cc57-4d03-ac4a-0f5c53fac309@github.com>

On Fri, 2 Apr 2021 10:01:27 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 pull request now contains six commits:
>> 
>>  - Merge branch 'master' into aarch64.base64.decode
>>  - copyright
>>  - trivial fixes
>>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>>  - Merge branch 'master' into aarch64.base64.decode
>>  - 8256245: AArch64: Implement Base64 decoding intrinsic
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5802:
> 
>> 5800:     // The 1st character of the input can be illegal if the data is MIME encoded.
>> 5801:     // We cannot benefits from SIMD for this case. The max line size of MIME
>> 5802:     // encoding is 76, with the PreProcess80B blob, we actually use no-simd
> 
> "cannot benefit"

OK, so I now understand what is actually going on here, and it has nothing to do with illegal first characters.
The problem is that the maximum block length the decode will be supplied with is 76 bytes, and there isn't enough time for the SIMD to be worthwhile. So the comment should be "In the MIME case, the line length cannot be more than 76 bytes (see RFC 2045.) This is too short a block for SIMD to be worthwhile, so we use non-SIMD here."

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

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

From kvn at openjdk.java.net  Tue Apr  6 15:57:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 6 Apr 2021 15:57:20 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v2]
In-Reply-To: <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
Message-ID: <RV2r7e15ksBiQa__sDVH8r-WVAEiO32FdB7fVt0Sak8=.98741436-1a90-41ca-9ea7-6682a6f7dd60@github.com>

On Mon, 29 Mar 2021 06:28:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
>> 
>> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
>> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
>>   VectorLoadMask (VectorStoreMask vmask)
>> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
>> vectors with the same element size and vector length, it's safe to do the optimization:
>>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
>> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.
>
> Xiaohong Gong 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:
> 
>   8264104: Eliminate unnecessary vector mask conversion during VectorUnbox for floating point VectorMask

@iwanowww should confirm correctness of such optimization.
Regarding changes - they seem fine to me. I notice that VectorNode and its subclasses do not check for TOP inputs. Since Vector API introduce vectors in graph before SuperWord transformation their input could become dead. How such cases handled? And why we did not hit them yet? is_vect() should hit assert.

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

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

From kvn at openjdk.java.net  Tue Apr  6 16:11:32 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 6 Apr 2021 16:11:32 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v13]
In-Reply-To: <SSc32E1gqVYpB5n8IRNXQwhk8VeZqQipekpeXHKD9oQ=.dc060539-635b-4f8b-a186-529c0393c2a2@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YUH9o_Z5_avs_-KiNy5jm1O9Hw9fO_uHUbZuy2ovc68=.b735d3c4-ce29-48d9-9425-67aa3f9ae240@github.com>
 <SSc32E1gqVYpB5n8IRNXQwhk8VeZqQipekpeXHKD9oQ=.dc060539-635b-4f8b-a186-529c0393c2a2@github.com>
Message-ID: <JINdSiZVhYlIGmhKY0ujRP9YCk0MI5oQJ9giWUoH3Rk=.60fef4d5-2a10-4e44-9663-a6fda9c785f4@github.com>

On Tue, 6 Apr 2021 12:31:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   trivial fix
>
> Looks good to me too.

I will wait results of testing Vladimir I. is running.

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

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

From kvn at openjdk.java.net  Tue Apr  6 17:58:34 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 6 Apr 2021 17:58:34 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
Message-ID: <M9OcTa-WZ8WQYHiGJZ1hziMDFeGOYs593CweXthMAgc=.3de10d71-924a-4ce9-8215-72f13bd5e638@github.com>

On Thu, 1 Apr 2021 10:02:39 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
> 
> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
> 
> Tested on:
> - original bug reproducer
> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)

src/hotspot/share/opto/lcm.cpp line 1415:

> 1413:       if (dead) {
> 1414:         // Remove projections if n is a dead multi-node.
> 1415:         for (uint k = j + n->outcnt(); sb->get_node(k)->is_Proj(); k--) {

I don't get this logic. The loop is not executed if sb->get_node(j + n->outcnt()) is not Proj node.

src/hotspot/share/opto/lcm.cpp line 1419:

> 1417:                  "dead projection should correspond to current node");
> 1418:           sb->get_node(k)->disconnect_inputs(C);
> 1419:           sb->remove_node(k);

If you remove node here then `j` could be incorrect in `sb->remove_node(j)` at line #1424

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

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

From kvn at openjdk.java.net  Tue Apr  6 18:01:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 6 Apr 2021 18:01:26 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
Message-ID: <C9s8H9XxXGh98TOaXv7uVitMA1M9ZS2aMihwpJx0og4=.81f079d3-1d2c-4ce8-a039-bd2dbfb9b1aa@github.com>

On Thu, 1 Apr 2021 10:02:39 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
> 
> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
> 
> Tested on:
> - original bug reproducer
> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)

Also where is guarantee that all Proj users are in the same block.

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

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

From kvn at openjdk.java.net  Tue Apr  6 18:02:29 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 6 Apr 2021 18:02:29 GMT
Subject: RFR: 8264759: x86_32 Minimal VM build failure after JDK-8262355
In-Reply-To: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
References: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
Message-ID: <b9zbC1_szM8mNihEhPtCOTjCW8Y1Qw0Hyux5ickzg7s=.1d7cb609-daad-470b-930d-2043f81d810c@github.com>

On Tue, 6 Apr 2021 09:29:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> * For target hotspot_variant-minimal_libjvm_objs_sharedRuntime_x86_32.o:

Trivial.

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

Marked as reviewed by kvn (Reviewer).

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

From shade at openjdk.java.net  Tue Apr  6 18:09:58 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Apr 2021 18:09:58 GMT
Subject: RFR: 8264759: x86_32 Minimal VM build failure after JDK-8262355
 [v2]
In-Reply-To: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
References: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
Message-ID: <PUFFwDDNmXYO8GTDIe7-BhTCJEAmmR1G441iIfidZqA=.5eaa4c6a-0748-45e4-acfd-af610d82ea6c@github.com>

> * For target hotspot_variant-minimal_libjvm_objs_sharedRuntime_x86_32.o:

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Avoid sweeping vzeroupper into save_vectors block

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3353/files
  - new: https://git.openjdk.java.net/jdk/pull/3353/files/86a5d8fd..4cf15f25

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

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

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

From shade at openjdk.java.net  Tue Apr  6 18:10:00 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Apr 2021 18:10:00 GMT
Subject: RFR: 8264759: x86_32 Minimal VM build failure after JDK-8262355
 [v2]
In-Reply-To: <b9zbC1_szM8mNihEhPtCOTjCW8Y1Qw0Hyux5ickzg7s=.1d7cb609-daad-470b-930d-2043f81d810c@github.com>
References: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
 <b9zbC1_szM8mNihEhPtCOTjCW8Y1Qw0Hyux5ickzg7s=.1d7cb609-daad-470b-930d-2043f81d810c@github.com>
Message-ID: <IdV0OAsdxQrlZVoqmrxiyl17O5bZosbmKMCrnvK1PMg=.5c4e91db-af6e-43a5-adfa-7223cc084cf3@github.com>

On Tue, 6 Apr 2021 17:59:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid sweeping vzeroupper into save_vectors block
>
> Trivial.

Thanks! I realized that moving `vzeroupper` into `COMPILER2` block was not quite right, as we "handle" only the `save_vectors` branch with that `#ifdef`. Reverted that part in new commit.

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

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

From kvn at openjdk.java.net  Tue Apr  6 18:17:45 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 6 Apr 2021 18:17:45 GMT
Subject: RFR: 8264759: x86_32 Minimal VM build failure after JDK-8262355
 [v2]
In-Reply-To: <PUFFwDDNmXYO8GTDIe7-BhTCJEAmmR1G441iIfidZqA=.5eaa4c6a-0748-45e4-acfd-af610d82ea6c@github.com>
References: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
 <PUFFwDDNmXYO8GTDIe7-BhTCJEAmmR1G441iIfidZqA=.5eaa4c6a-0748-45e4-acfd-af610d82ea6c@github.com>
Message-ID: <Jh4MhMVZIvievC0J6_RoN9rRmbzltHX1hxnP2UB0V_4=.df415ef1-aca7-41bd-ac14-bd9a5f842aaa@github.com>

On Tue, 6 Apr 2021 18:09:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> * For target hotspot_variant-minimal_libjvm_objs_sharedRuntime_x86_32.o:
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid sweeping vzeroupper into save_vectors block

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From shade at openjdk.java.net  Tue Apr  6 18:17:46 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Apr 2021 18:17:46 GMT
Subject: Integrated: 8264759: x86_32 Minimal VM build failure after JDK-8262355
In-Reply-To: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
References: <GNZ5P2pPJHOSOuWFuL1uYeEMilwDcbVN1iJy4TAJZkk=.09f14ec9-2ba8-46bc-b16b-26b21e23e702@github.com>
Message-ID: <-d-WgBnrBJaCk90mldezidDgHr6mtv2CmAwpb2UNdWE=.48bb9cef-a21c-44d6-9043-e81d2e3405e9@github.com>

On Tue, 6 Apr 2021 09:29:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> * For target hotspot_variant-minimal_libjvm_objs_sharedRuntime_x86_32.o:

This pull request has now been integrated.

Changeset: a756d8d7
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a756d8d7
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8264759: x86_32 Minimal VM build failure after JDK-8262355

Reviewed-by: thartmann, kvn

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

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

From rcastanedalo at openjdk.java.net  Tue Apr  6 19:17:35 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 6 Apr 2021 19:17:35 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform
Message-ID: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>

This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).

The change also fixes broken unit tests in the Data module and runs them by default when building.

#### Testing

Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):

- build
- open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
- import graphs via network (localhost)
- expand groups in outline
- open a graph
- open a clone
- zoom in and out
- search a node
- apply filters
- extract a node
- show all nodes
- select nodes corresponding to a bytecode
- view control flow
- select nodes corresponding to a basic block
- cluster nodes
- show satellite view
- compute the difference of two graphs
- change node text
- remove a group
- save groups into a file
- open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
- open a large graph ("After Escape Analysis" in large.xml)

Thanks to Vladimir Ivanov for helping with testing on macOS.

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

Commit messages:
 - Update TemplatesAction name in layer file
 - Remove template integration test
 - Turn off schema validation, since the main input files are not specifying it anyway
 - Fix test errors
 - Configure Maven to run Data unit tests
 - Update copyright years of touched files
 - Indent all XML files consistently
 - Convert all files to UNIX format
 - Add copyright headers to Maven files
 - Remove unnecessary comments
 - ... and 35 more: https://git.openjdk.java.net/jdk/compare/011f6d13...11fb43fa

Changes: https://git.openjdk.java.net/jdk/pull/3361/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3361&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264795
  Stats: 5950 lines in 499 files changed: 2737 ins; 3110 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3361.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3361/head:pull/3361

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

From kvn at openjdk.java.net  Tue Apr  6 20:05:33 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 6 Apr 2021 20:05:33 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform
In-Reply-To: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
Message-ID: <zf4p5evgzYstLM9_ACO-ej5XFtgy7aOjxAGxUtTwgQk=.3b332b31-b6f8-463c-a49a-d045eb0b5487@github.com>

On Tue, 6 Apr 2021 18:34:54 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).
> 
> The change also fixes broken unit tests in the Data module and runs them by default when building.
> 
> #### Testing
> 
> Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):
> 
> - build
> - open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - import graphs via network (localhost)
> - expand groups in outline
> - open a graph
> - open a clone
> - zoom in and out
> - search a node
> - apply filters
> - extract a node
> - show all nodes
> - select nodes corresponding to a bytecode
> - view control flow
> - select nodes corresponding to a basic block
> - cluster nodes
> - show satellite view
> - compute the difference of two graphs
> - change node text
> - remove a group
> - save groups into a file
> - open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - open a large graph ("After Escape Analysis" in large.xml)
> 
> Thanks to Vladimir Ivanov for helping with testing on macOS.

Great work!
After this is pushed consider to update wiki page too: https://wiki.openjdk.java.net/display/HotSpot/IdealGraphVisualizer

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Wed Apr  7 02:36:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 7 Apr 2021 02:36:42 GMT
Subject: RFR: 8264063: Outer Safepoint poll load should not reference the head
 of inner strip mined loop.
Message-ID: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>

When loop is "strip mined" polling address load ([parse1.cpp#L2280](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse1.cpp#L2280)) should be cloned together with safepoint node and pinned outside inner loop. Otherwise we have issues like [8263352](https://bugs.openjdk.java.net/browse/JDK-8263352)

I also remove leftover (unused needs_polling_address_input() method) from  [8220051](https://bugs.openjdk.java.net/browse/JDK-8220051) changes.

Tested hs-tier1-4

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

Commit messages:
 - 8264063: Outer Safepoint poll load should not reference the head of inner strip mined loop.

Changes: https://git.openjdk.java.net/jdk/pull/3365/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3365&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264063
  Stats: 47 lines in 6 files changed: 10 ins; 36 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3365.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3365/head:pull/3365

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

From pli at openjdk.java.net  Wed Apr  7 03:51:26 2021
From: pli at openjdk.java.net (Pengfei Li)
Date: Wed, 7 Apr 2021 03:51:26 GMT
Subject: RFR: 8264063: Outer Safepoint poll load should not reference the
 head of inner strip mined loop.
In-Reply-To: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
References: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
Message-ID: <ovoeWg2V2bJz_LPmjxoG6k33-C9ImH1vCJB7ZOu8iZM=.e78b3595-eb0b-41be-be98-b7b27000e992@github.com>

On Wed, 7 Apr 2021 02:29:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> When loop is "strip mined" polling address load ([parse1.cpp#L2280](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse1.cpp#L2280)) should be cloned together with safepoint node and pinned outside inner loop. Otherwise we have issues like [8263352](https://bugs.openjdk.java.net/browse/JDK-8263352)
> 
> I also remove leftover (unused needs_polling_address_input() method) from  [8220051](https://bugs.openjdk.java.net/browse/JDK-8220051) changes.
> 
> Tested hs-tier1-4

Should we also remove below part of code in `loopTransform.cpp` in this patch?

3704         if (n->is_CountedLoop() && n->as_CountedLoop()->is_strip_mined()) {
3705           // In strip-mined counted loops, the CountedLoopNode may be
3706           // used by the address polling node of the outer safepoint.
3707           // Skip this use because it's safe.
3708           Node* sfpt = n->as_CountedLoop()->outer_safepoint();
3709           Node* polladr = sfpt->in(TypeFunc::Parms+0);
3710           if (use == polladr) {
3711             continue;
3712           }
3713         }

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

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

From kvn at openjdk.java.net  Wed Apr  7 04:56:29 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 7 Apr 2021 04:56:29 GMT
Subject: RFR: 8264063: Outer Safepoint poll load should not reference the
 head of inner strip mined loop.
In-Reply-To: <ovoeWg2V2bJz_LPmjxoG6k33-C9ImH1vCJB7ZOu8iZM=.e78b3595-eb0b-41be-be98-b7b27000e992@github.com>
References: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
 <ovoeWg2V2bJz_LPmjxoG6k33-C9ImH1vCJB7ZOu8iZM=.e78b3595-eb0b-41be-be98-b7b27000e992@github.com>
Message-ID: <7YL-VL_1xzDmZH5jqlr5ZKnJK2tZBFtD_lyM5QUSfTo=.b65bfa0c-37b7-4885-bce7-7517ee6fa0fc@github.com>

On Wed, 7 Apr 2021 03:48:15 GMT, Pengfei Li <pli at openjdk.org> wrote:

> Should we also remove below part of code in `loopTransform.cpp` in this patch?
> 
> ```
> 3704         if (n->is_CountedLoop() && n->as_CountedLoop()->is_strip_mined()) {
> 3705           // In strip-mined counted loops, the CountedLoopNode may be
> 3706           // used by the address polling node of the outer safepoint.
> 3707           // Skip this use because it's safe.
> 3708           Node* sfpt = n->as_CountedLoop()->outer_safepoint();
> 3709           Node* polladr = sfpt->in(TypeFunc::Parms+0);
> 3710           if (use == polladr) {
> 3711             continue;
> 3712           }
> 3713         }
> ```

I thought that it does not harm to have this code but on other hand it will be not executed anymore.
I will removed it and I will run ArrayFill.java to make sure optimization works with strip mined loops.

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

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

From dongbo at openjdk.java.net  Wed Apr  7 05:51:02 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 7 Apr 2021 05:51:02 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

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

  fix misleading annotations

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3228/files
  - new: https://git.openjdk.java.net/jdk/pull/3228/files/faa830cf..a342ad1e

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

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

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

From dongbo at openjdk.java.net  Wed Apr  7 06:00:45 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 7 Apr 2021 06:00:45 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v5]
In-Reply-To: <rqcpOO-iWcmNJ_MQnX-3ZB0q89o5Avx1Iu8WDLOs_lE=.bfed903b-572e-4aff-8430-f5b01302c2b7@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com>
 <rqcpOO-iWcmNJ_MQnX-3ZB0q89o5Avx1Iu8WDLOs_lE=.bfed903b-572e-4aff-8430-f5b01302c2b7@github.com>
Message-ID: <hghsPRtRB2h-VfnV9nSqXwqW7dQF6RlptS1ctf6I1LA=.4be89867-150b-421a-8fbf-4ec0896a6264@github.com>

On Tue, 6 Apr 2021 14:04: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 pull request now contains 10 commits:
>> 
>>  - conflicts resolved
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into aarch64.base64.decode
>>  - resovling conflicts
>>  - load data with one ldrw, add JMH tests for error inputs
>>  - Merge branch 'master' into aarch64.base64.decode
>>  - copyright
>>  - trivial fixes
>>  - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
>>  - Merge branch 'master' into aarch64.base64.decode
>>  - 8256245: AArch64: Implement Base64 decoding intrinsic
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5800:
> 
>> 5798:     __ br(Assembler::LT, Process4B);
>> 5799: 
>> 5800:     // The 1st character of the input can be illegal if the data is MIME encoded.
> 
> Why is this sentence here? It is very misleading.

This sentence was used to describe the worst case observed frequently so that readers can understand more easily why the pre-processing non-SIMD code is necessary.
I apologize for being unclear and misleading. The annotations have been modified as suggested.

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

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

From xgong at openjdk.java.net  Wed Apr  7 06:01:02 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 7 Apr 2021 06:01:02 GMT
Subject: RFR: 8264352: AArch64: Optimize vector "not/andNot" for NEON and SVE
Message-ID: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>

Since the vector bitwise `"andNot"` is implemented with `"v1.and(v2.xor(-1))"`, the generated codes with SVE look like:
  mov z16.b, #-1
  eor z17.d, z20.d, z16.d
  and z18.d, z18.d, z17.d
This could be improved with a single instruction:
  bic z16.d, z16.d, z18.d
Similarly, the following optimization for NEON is also needed:
  not v21.16b, v21.16b
  and v21.16b, v21.16b, v18.16b  ==>  bic v21.16b, v18.16b, v21.16b
This patch also adds the following optimization to vector` "not"` for SVE which has already been added for NEON:
  mov z16.b, #-1
  eor z17.d, z20.d, z16.d     ==>   not z17.d, p7/m, z20.d
The performance can improve about `16% ~ 36%` with NEON for the `"AND_NOT"` benchmark [1].

[1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/ByteMaxVector.java#L343

Tested tier1 and jdk:tier3.

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

Commit messages:
 - 8264352: AArch64: Optimize vector "not/andNot" for NEON and SVE

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

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

From eliu at openjdk.java.net  Wed Apr  7 07:37:51 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Wed, 7 Apr 2021 07:37:51 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
Message-ID: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>

The vector shift count was defined by two separate nodes(LShiftCntV and
RShiftCntV), which would prevent them from being shared when the shift
counts are the same.

public static void test_shiftv(int sh) {
    for (int i = 0; i < N; i+=1) {
        a0[i] = a1[i] << sh;
        b0[i] = b1[i] >> sh;
    }
}

Given the example above, by merging the same shift counts into one
node, they could be shared by shift nodes(RShiftV or LShiftV) like
below:

Before:
1184  LShiftCntV  === _  1189  [[ 1185  ... ]]
1190  RShiftCntV  === _  1189  [[ 1191  ... ]]
1185  LShiftVI  === _  1181  1184  [[ 1186 ]]
1191  RShiftVI  === _  1187  1190  [[ 1192 ]]

After:
1190  ShiftCntV  === _  1189  [[ 1191 1204  ... ]]
1204  LShiftVI  === _  1211  1190  [[ 1203 ]]
1191  RShiftVI  === _  1187  1190  [[ 1192 ]]

The final code could remove one redundant ?dup?(scalar->vector),
with one register saved.

Before:
        dup     v16.16b, w12
        dup     v17.16b, w12
        ...
        ldr     q18, [x13, #16]
        sshl    v18.4s, v18.4s, v16.4s
        add     x18, x16, x12           ; iaload

        add     x4, x15, x12
        str     q18, [x4, #16]          ; iastore

        ldr     q18, [x18, #16]
        add     x12, x14, x12
        neg     v19.16b, v17.16b
        sshl    v18.4s, v18.4s, v19.4s
        str     q18, [x12, #16]         ; iastore

After:
        dup	v16.16b, w11
        ...
        ldr	q17, [x13, #16]
        sshl	v17.4s, v17.4s, v16.4s
        add	x2, x22, x11            ; iaload

        add	x4, x16, x11
        str	q17, [x4, #16]          ; iastore

        ldr	q17, [x2, #16]
        add	x11, x21, x11
        neg	v18.16b, v16.16b
        sshl	v17.4s, v17.4s, v18.4s
        str	q17, [x11, #16]         ; iastore

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

Commit messages:
 - 8262916: Merge LShiftCntV and RShiftCntV into a single node

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

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

From rcastanedalo at openjdk.java.net  Wed Apr  7 07:39:26 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 7 Apr 2021 07:39:26 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform
In-Reply-To: <zf4p5evgzYstLM9_ACO-ej5XFtgy7aOjxAGxUtTwgQk=.3b332b31-b6f8-463c-a49a-d045eb0b5487@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <zf4p5evgzYstLM9_ACO-ej5XFtgy7aOjxAGxUtTwgQk=.3b332b31-b6f8-463c-a49a-d045eb0b5487@github.com>
Message-ID: <mjw6EYpBCyO7uF2ky9MH3BYDZQQGHmBlahnA0ZEriQw=.822aa70e-e302-4ba3-88e6-188bce4992c2@github.com>

On Tue, 6 Apr 2021 20:02:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Great work!
> After this is pushed consider to update wiki page too: https://wiki.openjdk.java.net/display/HotSpot/IdealGraphVisualizer

Thanks for reviewing, Vladimir! Yes, I plan to do that.

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

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

From chagedorn at openjdk.java.net  Wed Apr  7 08:00:32 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 7 Apr 2021 08:00:32 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform
In-Reply-To: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
Message-ID: <OrNt7fwgca9K2RbP1W_9XclFeGPzx2feLm4lwlZk6Yo=.0b4a27fc-1db6-4cf8-b94b-d4317c270afd@github.com>

On Tue, 6 Apr 2021 18:34:54 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).
> 
> The change also fixes broken unit tests in the Data module and runs them by default when building.
> 
> #### Testing
> 
> Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):
> 
> - build
> - open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - import graphs via network (localhost)
> - expand groups in outline
> - open a graph
> - open a clone
> - zoom in and out
> - search a node
> - apply filters
> - extract a node
> - show all nodes
> - select nodes corresponding to a bytecode
> - view control flow
> - select nodes corresponding to a basic block
> - cluster nodes
> - show satellite view
> - compute the difference of two graphs
> - change node text
> - remove a group
> - save groups into a file
> - open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - open a large graph ("After Escape Analysis" in large.xml)
> 
> Thanks to Vladimir Ivanov for helping with testing on macOS.

Very nice work!

src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/Parser.java line 154:

> 152:                             parent.addElement(group);
> 153:                         }
> 154:                     };

You could directly use `Runnable addToParent = () -> parent.addElement(group);` and also for the other ones below.

src/utils/IdealGraphVisualizer/README.md line 10:

> 8: elements.
> 9: 
> 10: The tool is built on top of the NetBeans Platform, and requires Java 8 or later.

Maybe also mention here that the current NetBeans version supports up to JDK 15.

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

Marked as reviewed by chagedorn (Reviewer).

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

From aph at openjdk.java.net  Wed Apr  7 08:34:26 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Apr 2021 08:34:26 GMT
Subject: RFR: 8264352: AArch64: Optimize vector "not/andNot" for NEON and
 SVE
In-Reply-To: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
References: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
Message-ID: <k0vH2naytn5SJk5rBc_dl6m73CEbnLHtHkcE87hPpaQ=.c46e4c3f-c33b-4bc3-bdd6-294b7b5bb446@github.com>

On Wed, 7 Apr 2021 05:53:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Since the vector bitwise `"andNot"` is implemented with `"v1.and(v2.xor(-1))"`, the generated codes with SVE look like:
>   mov z16.b, #-1
>   eor z17.d, z20.d, z16.d
>   and z18.d, z18.d, z17.d
> This could be improved with a single instruction:
>   bic z16.d, z16.d, z18.d
> Similarly, the following optimization for NEON is also needed:
>   not v21.16b, v21.16b
>   and v21.16b, v21.16b, v18.16b  ==>  bic v21.16b, v18.16b, v21.16b
> This patch also adds the following optimization to vector` "not"` for SVE which has already been added for NEON:
>   mov z16.b, #-1
>   eor z17.d, z20.d, z16.d     ==>   not z17.d, p7/m, z20.d
> The performance can improve about `16% ~ 36%` with NEON for the `"AND_NOT"` benchmark [1].
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/ByteMaxVector.java#L343
> 
> Tested tier1 and jdk:tier3.

Looks OK. Is there any test code for this is mainline?

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

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

From neliasso at openjdk.java.net  Wed Apr  7 08:43:29 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 7 Apr 2021 08:43:29 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform
In-Reply-To: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
Message-ID: <pWvVojIQsyDt-_7f8JQjZas1ey-wOKA2wfheW8NnRKA=.0e1c5ac0-822e-40f7-94a5-cb8116c699f8@github.com>

On Tue, 6 Apr 2021 18:34:54 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).
> 
> The change also fixes broken unit tests in the Data module and runs them by default when building.
> 
> #### Testing
> 
> Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):
> 
> - build
> - open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - import graphs via network (localhost)
> - expand groups in outline
> - open a graph
> - open a clone
> - zoom in and out
> - search a node
> - apply filters
> - extract a node
> - show all nodes
> - select nodes corresponding to a bytecode
> - view control flow
> - select nodes corresponding to a basic block
> - cluster nodes
> - show satellite view
> - compute the difference of two graphs
> - change node text
> - remove a group
> - save groups into a file
> - open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - open a large graph ("After Escape Analysis" in large.xml)
> 
> Thanks to Vladimir Ivanov for helping with testing on macOS.

I have tested IGV on a High-DPI screen (4K). The screens are attached to the bug-report.

Compared to baseline the new version improved DPI scaling on both JDK8 and JDK15. Some elements still doesn't scale.

Remaining issues identified:
1) The default zoom level is to small
2) The filter view has broken scaling - the font scales but not the line height.
3) The buttons above the graph view and file list doesn't scale - they are still tiny.
4) The splash screen doesn't scale

Still this is a big improvement and the remaining issues can be solved in separate PRs.

Looks good - Reviewed!

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

Marked as reviewed by neliasso (Reviewer).

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

From xgong at openjdk.java.net  Wed Apr  7 08:48:32 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 7 Apr 2021 08:48:32 GMT
Subject: RFR: 8264352: AArch64: Optimize vector "not/andNot" for NEON and
 SVE
In-Reply-To: <k0vH2naytn5SJk5rBc_dl6m73CEbnLHtHkcE87hPpaQ=.c46e4c3f-c33b-4bc3-bdd6-294b7b5bb446@github.com>
References: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
 <k0vH2naytn5SJk5rBc_dl6m73CEbnLHtHkcE87hPpaQ=.c46e4c3f-c33b-4bc3-bdd6-294b7b5bb446@github.com>
Message-ID: <zrK4Kvxxx4BMCNBGopzn7YrSyMLegUgWnsLcZedBM0U=.1f1b48ed-5d72-43c2-ae48-a9a0f5d50b33@github.com>

On Wed, 7 Apr 2021 08:31:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Looks OK. Is there any test code for this is mainline?

Hi @theRealAph , thanks for looking at this PR.  Yes, there is the Vector API jtreg tests that have covered the opcode `NOT/AND_NOT`.
Please see the tests for byte vector: https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java#L1708
and https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java#L4602

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

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

From aph at openjdk.java.net  Wed Apr  7 09:07:22 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Apr 2021 09:07:22 GMT
Subject: RFR: 8264352: AArch64: Optimize vector "not/andNot" for NEON and
 SVE
In-Reply-To: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
References: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
Message-ID: <vdYCwJcFhx9QjW6d6hrVmSeX6gKhoZNz8A0PapMZokA=.8c991e25-62df-4db8-ba2f-79c18ee6b857@github.com>

On Wed, 7 Apr 2021 05:53:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Since the vector bitwise `"andNot"` is implemented with `"v1.and(v2.xor(-1))"`, the generated codes with SVE look like:
>   mov z16.b, #-1
>   eor z17.d, z20.d, z16.d
>   and z18.d, z18.d, z17.d
> This could be improved with a single instruction:
>   bic z16.d, z16.d, z18.d
> Similarly, the following optimization for NEON is also needed:
>   not v21.16b, v21.16b
>   and v21.16b, v21.16b, v18.16b  ==>  bic v21.16b, v18.16b, v21.16b
> This patch also adds the following optimization to vector` "not"` for SVE which has already been added for NEON:
>   mov z16.b, #-1
>   eor z17.d, z20.d, z16.d     ==>   not z17.d, p7/m, z20.d
> The performance can improve about `16% ~ 36%` with NEON for the `"AND_NOT"` benchmark [1].
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/ByteMaxVector.java#L343
> 
> Tested tier1 and jdk:tier3.

Marked as reviewed by aph (Reviewer).

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

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

From aph at openjdk.java.net  Wed Apr  7 09:56:20 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Apr 2021 09:56:20 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6]
In-Reply-To: <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>
Message-ID: <sGQjaUtyiB5cDch3o5YGyLnf9lG6YoMrwABun7jgbK4=.a0b249ef-2e79-4b56-8eae-e0e2181bd8ec@github.com>

On Wed, 7 Apr 2021 05:51:02 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix misleading annotations

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5829:

> 5827:     __ strb(r14, __ post(dst, 1));
> 5828:     __ strb(r15, __ post(dst, 1));
> 5829:     __ strb(r13, __ post(dst, 1));

I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think.

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

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

From aph at openjdk.java.net  Wed Apr  7 09:56:21 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Apr 2021 09:56:21 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6]
In-Reply-To: <sGQjaUtyiB5cDch3o5YGyLnf9lG6YoMrwABun7jgbK4=.a0b249ef-2e79-4b56-8eae-e0e2181bd8ec@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>
 <sGQjaUtyiB5cDch3o5YGyLnf9lG6YoMrwABun7jgbK4=.a0b249ef-2e79-4b56-8eae-e0e2181bd8ec@github.com>
Message-ID: <uYrE1TBlkMS4Jlz36xe0CX_v9iucRqkHCM_Sc5F2gnA=.4a85979d-9e73-4a83-981c-ee47faf051ce@github.com>

On Wed, 7 Apr 2021 09:50:45 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix misleading annotations
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5829:
> 
>> 5827:     __ strb(r14, __ post(dst, 1));
>> 5828:     __ strb(r15, __ post(dst, 1));
>> 5829:     __ strb(r13, __ post(dst, 1));
> 
> I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think.

Sorry, that's not quite right, but you get the idea: let's not generate unnecessary memory traffic.

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

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

From vlivanov at openjdk.java.net  Wed Apr  7 10:51:47 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 7 Apr 2021 10:51:47 GMT
Subject: RFR: 8261137: Optimization of Box nodes in uncommon_trap [v13]
In-Reply-To: <JINdSiZVhYlIGmhKY0ujRP9YCk0MI5oQJ9giWUoH3Rk=.60fef4d5-2a10-4e44-9663-a6fda9c785f4@github.com>
References: <8Riu9VCQLM7_vDp5DOMtLZK3yMLQzAkwlIKo4ab0F7Q=.662dbffe-c320-47ea-bc67-508e2c382b12@github.com>
 <YUH9o_Z5_avs_-KiNy5jm1O9Hw9fO_uHUbZuy2ovc68=.b735d3c4-ce29-48d9-9425-67aa3f9ae240@github.com>
 <SSc32E1gqVYpB5n8IRNXQwhk8VeZqQipekpeXHKD9oQ=.dc060539-635b-4f8b-a186-529c0393c2a2@github.com>
 <JINdSiZVhYlIGmhKY0ujRP9YCk0MI5oQJ9giWUoH3Rk=.60fef4d5-2a10-4e44-9663-a6fda9c785f4@github.com>
Message-ID: <Yoe3gAafuTPQ39D1cAFyEJok1MJkKBJ4tbzmNnW4_kc=.174fbf5b-29f2-4118-aa59-9d31abe75563@github.com>

On Tue, 6 Apr 2021 16:08:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Looks good to me too.
>
> I will wait results of testing Vladimir I. is running.

Test results (hs-tier1 - hs-tier4) are clean.

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

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

From whuang at openjdk.java.net  Wed Apr  7 10:51:52 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Wed, 7 Apr 2021 10:51:52 GMT
Subject: Integrated: 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: <ZEeoWeGi4j_jh5jf3ttZHqfm5HghuISxhaEwUKEvqAQ=.e2459757-db35-4100-9687-f057d668eabc@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 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

This pull request has now been integrated.

Changeset: eab84554
Author:    Wang Huang <whuang at openjdk.org>
Committer: Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eab84554
Stats:     308 lines in 10 files changed: 284 ins; 2 del; 22 mod

8261137: Optimization of Box nodes in uncommon_trap

Co-authored-by: Wu Yan <wuyan34 at huawei.com>
Co-authored-by: Ai Jiaming <aijiaming1 at huawei.com>
Reviewed-by: kvn, vlivanov, thartmann

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

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

From thartmann at openjdk.java.net  Wed Apr  7 11:33:37 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 7 Apr 2021 11:33:37 GMT
Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java
 crash in fastdebug C2 with -XX:-UseTLAB
In-Reply-To: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
References: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
Message-ID: <6BN6FtOuI_DuZS8Zpuy2k5xTSu10uXZjrfxMEt6e978=.b5e1ee6b-7dba-413c-9c04-bbf66098b588@github.com>

On Sat, 3 Apr 2021 00:53:54 GMT, Hui Shi <hshi at openjdk.org> wrote:

> Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649
> 
> Tier1/2 release /fastdebug passed

Changes requested by thartmann (Reviewer).

src/hotspot/share/opto/phaseX.cpp line 1481:

> 1479:   // Smash all inputs to 'old', isolating him completely
> 1480:   Node *temp = new Node(1);
> 1481:   temp->init_req(0,nn);     // Add a use to nn to prevent him from dying

Just wondering, why do we even need this? Without that code, `remove_dead_node(old)` would kill `nn` as well if it becomes dead.

test/hotspot/jtreg/runtime/InternalApi/ThreadCpuTimesDeadlock.java line 36:

> 34:  * @test
> 35:  * @bug 8264649
> 36:  * @summary OSR compiled metthod crash when UseTLAB is off

Typo `metthod`.

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

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

From rcastanedalo at openjdk.java.net  Wed Apr  7 11:59:28 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 7 Apr 2021 11:59:28 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
Message-ID: <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>

> This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).
> 
> The change also fixes broken unit tests in the Data module and runs them by default when building.
> 
> #### Testing
> 
> Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):
> 
> - build
> - open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - import graphs via network (localhost)
> - expand groups in outline
> - open a graph
> - open a clone
> - zoom in and out
> - search a node
> - apply filters
> - extract a node
> - show all nodes
> - select nodes corresponding to a bytecode
> - view control flow
> - select nodes corresponding to a basic block
> - cluster nodes
> - show satellite view
> - compute the difference of two graphs
> - change node text
> - remove a group
> - save groups into a file
> - open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - open a large graph ("After Escape Analysis" in large.xml)
> 
> Thanks to Vladimir Ivanov for helping with testing on macOS.

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

 - Document how to build and run on a specific JDK
 - Use lambdas to define runnables
 - Document latest JDK version supported

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3361/files
  - new: https://git.openjdk.java.net/jdk/pull/3361/files/11fb43fa..e84d171e

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

  Stats: 24 lines in 2 files changed: 5 ins; 15 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3361.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3361/head:pull/3361

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

From rcastanedalo at openjdk.java.net  Wed Apr  7 11:59:30 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 7 Apr 2021 11:59:30 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <OrNt7fwgca9K2RbP1W_9XclFeGPzx2feLm4lwlZk6Yo=.0b4a27fc-1db6-4cf8-b94b-d4317c270afd@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <OrNt7fwgca9K2RbP1W_9XclFeGPzx2feLm4lwlZk6Yo=.0b4a27fc-1db6-4cf8-b94b-d4317c270afd@github.com>
Message-ID: <j73oy0RZTrzsWgpJQGHQogS9T2iipsbHj4_8aFK5DDs=.945e0f05-729e-4c84-879d-6f3cf618f2b6@github.com>

On Wed, 7 Apr 2021 07:55:58 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Document how to build and run on a specific JDK
>>  - Use lambdas to define runnables
>>  - Document latest JDK version supported
>
> src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/Parser.java line 154:
> 
>> 152:                             parent.addElement(group);
>> 153:                         }
>> 154:                     };
> 
> You could directly use `Runnable addToParent = () -> parent.addElement(group);` and also for the other ones below.

Good suggestion, thanks, done!

> src/utils/IdealGraphVisualizer/README.md line 10:
> 
>> 8: elements.
>> 9: 
>> 10: The tool is built on top of the NetBeans Platform, and requires Java 8 or later.
> 
> Maybe also mention here that the current NetBeans version supports up to JDK 15.

Thanks, done!

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

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

From rcastanedalo at openjdk.java.net  Wed Apr  7 12:00:31 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 7 Apr 2021 12:00:31 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <OrNt7fwgca9K2RbP1W_9XclFeGPzx2feLm4lwlZk6Yo=.0b4a27fc-1db6-4cf8-b94b-d4317c270afd@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <OrNt7fwgca9K2RbP1W_9XclFeGPzx2feLm4lwlZk6Yo=.0b4a27fc-1db6-4cf8-b94b-d4317c270afd@github.com>
Message-ID: <uAqSl_xEnYJM0RvFxyQpL7hE0xGiLLmH5FmOBNgryUo=.96a2acea-8487-40cc-9058-1a4b42adf364@github.com>

On Wed, 7 Apr 2021 07:57:19 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Very nice work!

Thanks for reviewing, Christian!

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

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

From rcastanedalo at openjdk.java.net  Wed Apr  7 12:00:31 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 7 Apr 2021 12:00:31 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <pWvVojIQsyDt-_7f8JQjZas1ey-wOKA2wfheW8NnRKA=.0e1c5ac0-822e-40f7-94a5-cb8116c699f8@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <pWvVojIQsyDt-_7f8JQjZas1ey-wOKA2wfheW8NnRKA=.0e1c5ac0-822e-40f7-94a5-cb8116c699f8@github.com>
Message-ID: <_767rfKcRydco8vGfpcM6NNnzfpmFGrV8bQNzXgiR-E=.376c2613-17f3-4b0c-ace3-2d8572f392ee@github.com>

On Wed, 7 Apr 2021 08:40:02 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> I have tested IGV on a High-DPI screen (4K). The screens are attached to the bug-report.
> 
> Compared to baseline the new version improved DPI scaling on both JDK8 and JDK15. Some elements still doesn't scale.
> 
> Remaining issues identified:
> 
>     1. The default zoom level is to small
> 
>     2. The filter view has broken scaling - the font scales but not the line height.
> 
>     3. The buttons above the graph view and file list doesn't scale - they are still tiny.
> 
>     4. The splash screen doesn't scale
> 
> 
> Still this is a big improvement and the remaining issues can be solved in separate PRs.
> 
> Looks good - Reviewed!

Thanks for reviewing, Nils! I will create a separate RFE for DPI scaling issues.

I also added a clarification to the README file (https://github.com/openjdk/jdk/pull/3361/commits/e84d171e12a238cf0a1905a4bc8107ac6141a540) based on our offline discussion.

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

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

From hshi at openjdk.java.net  Wed Apr  7 12:09:09 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Wed, 7 Apr 2021 12:09:09 GMT
Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java
 crash in fastdebug C2 with -XX:-UseTLAB [v2]
In-Reply-To: <6BN6FtOuI_DuZS8Zpuy2k5xTSu10uXZjrfxMEt6e978=.b5e1ee6b-7dba-413c-9c04-bbf66098b588@github.com>
References: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
 <6BN6FtOuI_DuZS8Zpuy2k5xTSu10uXZjrfxMEt6e978=.b5e1ee6b-7dba-413c-9c04-bbf66098b588@github.com>
Message-ID: <03pdWufgmVqBPCnhdEvHJnRHkblBlxSiAUsG4Zjpg30=.a17a5efa-8f65-4933-994a-f176f9c45cfb@github.com>

On Wed, 7 Apr 2021 11:29:06 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Hui Shi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo in test description
>
> src/hotspot/share/opto/phaseX.cpp line 1481:
> 
>> 1479:   // Smash all inputs to 'old', isolating him completely
>> 1480:   Node *temp = new Node(1);
>> 1481:   temp->init_req(0,nn);     // Add a use to nn to prevent him from dying
> 
> Just wondering, why do we even need this? Without that code, `remove_dead_node(old)` would kill `nn` as well if it becomes dead.

Thanks for your review!

Checking code history,  this code is quite old. From comments around, it doesn't want nn removed directly in PhaseIterGVN::subsume_node and leaves optimization to next GVN iteration.

In my understanding, it might save callers to insert codes checking if "nn" is removed/dead at every subsume_node/replace_node callsite, simplifies implementation.

8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke                  2007-12-01 00:00:00 +0000 1479)   // Smash all inputs to 'old', isolating him completely
2a0815a5 hotspot/src/share/vm/opto/phaseX.cpp (Tobias Hartmann          2014-06-02 08:07:29 +0200 1480)   Node *temp = new Node(1);
8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke                  2007-12-01 00:00:00 +0000 1481)   temp->init_req(0,nn);     // Add a use to nn to prevent him from dying
8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke                  2007-12-01 00:00:00 +0000 1482)   remove_dead_node( old );
8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke                  2007-12-01 00:00:00 +0000 1483)   temp->del_req(0);         // Yank bogus edge

> test/hotspot/jtreg/runtime/InternalApi/ThreadCpuTimesDeadlock.java line 36:
> 
>> 34:  * @test
>> 35:  * @bug 8264649
>> 36:  * @summary OSR compiled metthod crash when UseTLAB is off
> 
> Typo `metthod`.

Fixed.

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

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

From hshi at openjdk.java.net  Wed Apr  7 12:09:05 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Wed, 7 Apr 2021 12:09:05 GMT
Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java
 crash in fastdebug C2 with -XX:-UseTLAB [v2]
In-Reply-To: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
References: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
Message-ID: <fOeAmqUkvL4Uh8VJ3sqHNQwch2_btvm_eKC5U8ncZP4=.65d7c4d2-91fd-4ee6-b481-67643ddedbae@github.com>

> Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649
> 
> Tier1/2 release /fastdebug passed

Hui Shi has updated the pull request incrementally with one additional commit since the last revision:

  fix typo in test description

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3336/files
  - new: https://git.openjdk.java.net/jdk/pull/3336/files/08292fe1..2f6b68df

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

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

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

From chagedorn at openjdk.java.net  Wed Apr  7 12:10:59 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 7 Apr 2021 12:10:59 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
Message-ID: <KDeMlavE_iVz7EP2FBdFQvvrIdPSg7rd01tBde-lONw=.324179f4-4418-4e49-8063-6352c75954ae@github.com>

On Wed, 7 Apr 2021 11:59:28 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).
>> 
>> The change also fixes broken unit tests in the Data module and runs them by default when building.
>> 
>> #### Testing
>> 
>> Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):
>> 
>> - build
>> - open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
>> - import graphs via network (localhost)
>> - expand groups in outline
>> - open a graph
>> - open a clone
>> - zoom in and out
>> - search a node
>> - apply filters
>> - extract a node
>> - show all nodes
>> - select nodes corresponding to a bytecode
>> - view control flow
>> - select nodes corresponding to a basic block
>> - cluster nodes
>> - show satellite view
>> - compute the difference of two graphs
>> - change node text
>> - remove a group
>> - save groups into a file
>> - open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
>> - open a large graph ("After Escape Analysis" in large.xml)
>> 
>> Thanks to Vladimir Ivanov for helping with testing on macOS.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Document how to build and run on a specific JDK
>  - Use lambdas to define runnables
>  - Document latest JDK version supported

Marked as reviewed by chagedorn (Reviewer).

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

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

From kvn at openjdk.java.net  Wed Apr  7 16:05:01 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 7 Apr 2021 16:05:01 GMT
Subject: RFR: 8264063: Outer Safepoint poll load should not reference the
 head of inner strip mined loop. [v2]
In-Reply-To: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
References: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
Message-ID: <DN9M2PExByDIxe0fgJgvWxIp6pXBzXgpjBT1dS1MBvM=.742d63e1-22db-4f2d-9167-ccfc4d208313@github.com>

> When loop is "strip mined" polling address load ([parse1.cpp#L2280](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse1.cpp#L2280)) should be cloned together with safepoint node and pinned outside inner loop. Otherwise we have issues like [8263352](https://bugs.openjdk.java.net/browse/JDK-8263352)
> 
> I also remove leftover (unused needs_polling_address_input() method) from  [8220051](https://bugs.openjdk.java.net/browse/JDK-8220051) changes.
> 
> Tested hs-tier1-4

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Removed unneeded anymore code in match_fill_loop()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3365/files
  - new: https://git.openjdk.java.net/jdk/pull/3365/files/1f645337..58a4ce1d

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

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

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

From kvn at openjdk.java.net  Wed Apr  7 16:05:02 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 7 Apr 2021 16:05:02 GMT
Subject: RFR: 8264063: Outer Safepoint poll load should not reference the
 head of inner strip mined loop.
In-Reply-To: <7YL-VL_1xzDmZH5jqlr5ZKnJK2tZBFtD_lyM5QUSfTo=.b65bfa0c-37b7-4885-bce7-7517ee6fa0fc@github.com>
References: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
 <ovoeWg2V2bJz_LPmjxoG6k33-C9ImH1vCJB7ZOu8iZM=.e78b3595-eb0b-41be-be98-b7b27000e992@github.com>
 <7YL-VL_1xzDmZH5jqlr5ZKnJK2tZBFtD_lyM5QUSfTo=.b65bfa0c-37b7-4885-bce7-7517ee6fa0fc@github.com>
Message-ID: <4sfEfc52fns5swIw2OozuKaqB8Cy82fS4vQ-5890904=.0a2222ff-707a-4741-95f8-819d4db33f86@github.com>

On Wed, 7 Apr 2021 04:53:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Should we also remove below part of code in `loopTransform.cpp` in this patch?
>> 
>> 3704         if (n->is_CountedLoop() && n->as_CountedLoop()->is_strip_mined()) {
>> 3705           // In strip-mined counted loops, the CountedLoopNode may be
>> 3706           // used by the address polling node of the outer safepoint.
>> 3707           // Skip this use because it's safe.
>> 3708           Node* sfpt = n->as_CountedLoop()->outer_safepoint();
>> 3709           Node* polladr = sfpt->in(TypeFunc::Parms+0);
>> 3710           if (use == polladr) {
>> 3711             continue;
>> 3712           }
>> 3713         }
>
>> Should we also remove below part of code in `loopTransform.cpp` in this patch?
>> 
>> ```
>> 3704         if (n->is_CountedLoop() && n->as_CountedLoop()->is_strip_mined()) {
>> 3705           // In strip-mined counted loops, the CountedLoopNode may be
>> 3706           // used by the address polling node of the outer safepoint.
>> 3707           // Skip this use because it's safe.
>> 3708           Node* sfpt = n->as_CountedLoop()->outer_safepoint();
>> 3709           Node* polladr = sfpt->in(TypeFunc::Parms+0);
>> 3710           if (use == polladr) {
>> 3711             continue;
>> 3712           }
>> 3713         }
>> ```
> 
> I thought that it does not harm to have this code but on other hand it will be not executed anymore.
> I will removed it and I will run ArrayFill.java to make sure optimization works with strip mined loops.

I removed pointed code and verified that arrayfill optimization still works with strip mined loops.

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

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

From vlivanov at openjdk.java.net  Wed Apr  7 16:09:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 7 Apr 2021 16:09:41 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v2]
In-Reply-To: <RV2r7e15ksBiQa__sDVH8r-WVAEiO32FdB7fVt0Sak8=.98741436-1a90-41ca-9ea7-6682a6f7dd60@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
 <RV2r7e15ksBiQa__sDVH8r-WVAEiO32FdB7fVt0Sak8=.98741436-1a90-41ca-9ea7-6682a6f7dd60@github.com>
Message-ID: <XsBTy3IFrhUJsdkHQKKd-95_F3pNGY0994st5krllcw=.dea9a899-c9f6-4a03-b925-c366e9c17285@github.com>

On Tue, 6 Apr 2021 15:54:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Xiaohong Gong 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:
>> 
>>   8264104: Eliminate unnecessary vector mask conversion during VectorUnbox for floating point VectorMask
>
> @iwanowww should confirm correctness of such optimization.
> Regarding changes - they seem fine to me. I notice that VectorNode and its subclasses do not check for TOP inputs. Since Vector API introduce vectors in graph before SuperWord transformation their input could become dead. How such cases handled? And why we did not hit them yet? is_vect() should hit assert.

I'm not fond of the proposed approach. 

It hard-codes some implicit assumptions about vector mask representation.  
Also, vector type mismatch can trigger asserts since some vector-related code expects that types of vector inputs match precisely).

I suggest to introduce artificial cast nodes (`VectorLoadMask (VectorStoreMask vmask) ==> VectorMaskCast (vmask)`) which are then lowered into no-ops on backend side.

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

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

From goetz at openjdk.java.net  Wed Apr  7 16:20:56 2021
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Wed, 7 Apr 2021 16:20:56 GMT
Subject: RFR: 8264173: [s390] Improve Hardware Feature Detection And
 Reporting [v2]
In-Reply-To: <5OhEhVbnzUEotih1ykgz3Omnt3jQVEYG4B2uMFbCROY=.cbe91475-a6a5-41c3-a11c-4e23d9df9937@github.com>
References: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com>
 <AMeRnjPOxt3ymf5-TbIfjNVnaUk04OZFxX6OTsODe8Y=.4684a8f6-4c23-4b25-baae-f91e211081e3@github.com>
 <gZONMr9_VqxsSMyXLuOhpoaRwCxnI0q6MmrYNgu666c=.2fe7e8ea-837d-40f2-9b7b-4f7c9abf3e8b@github.com>
 <5OhEhVbnzUEotih1ykgz3Omnt3jQVEYG4B2uMFbCROY=.cbe91475-a6a5-41c3-a11c-4e23d9df9937@github.com>
Message-ID: <hRtc_xwhTM_gC5jgqaJQHwGY6VDiumdqA2H3s8lQuGI=.917eb11c-5c9b-4db6-8a44-cd24b089257e@github.com>

On Mon, 29 Mar 2021 10:32:40 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> I didn't expect the change to become that large. But it looks good to me. The lengthy output only gets generated with -XX:+Verbose. That's fine.
>
> Thank you for the review, Martin!

LGTM

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

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

From goetz at openjdk.java.net  Wed Apr  7 16:20:54 2021
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Wed, 7 Apr 2021 16:20:54 GMT
Subject: RFR: 8264173: [s390] Improve Hardware Feature Detection And
 Reporting [v3]
In-Reply-To: <-dA2uhXwH7eME201-lzohAOpXigVwsUjtGACZZWMRXc=.0a4e611f-a3c0-470f-a310-5d17715492e1@github.com>
References: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com>
 <-dA2uhXwH7eME201-lzohAOpXigVwsUjtGACZZWMRXc=.0a4e611f-a3c0-470f-a310-5d17715492e1@github.com>
Message-ID: <7Urlz3zuxm7aJgwjId9mUtSG_2qeeGrX4mNGqDtJ5aI=.d881dc3b-b102-4427-b43c-9d7b73abeb60@github.com>

On Mon, 29 Mar 2021 10:36:47 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This enhancement is intended to improve the hardware feature detection and reporting, in particular for more recently introduced hardware. The enhancement is a prerequisite for possible future feature exploitation. 
>> 
>> Reviews are highly welcome and appreciated.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaned up some spaces

Marked as reviewed by goetz (Reviewer).

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

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

From lucy at openjdk.java.net  Wed Apr  7 16:20:57 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 7 Apr 2021 16:20:57 GMT
Subject: RFR: 8264173: [s390] Improve Hardware Feature Detection And
 Reporting [v3]
In-Reply-To: <7Urlz3zuxm7aJgwjId9mUtSG_2qeeGrX4mNGqDtJ5aI=.d881dc3b-b102-4427-b43c-9d7b73abeb60@github.com>
References: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com>
 <-dA2uhXwH7eME201-lzohAOpXigVwsUjtGACZZWMRXc=.0a4e611f-a3c0-470f-a310-5d17715492e1@github.com>
 <7Urlz3zuxm7aJgwjId9mUtSG_2qeeGrX4mNGqDtJ5aI=.d881dc3b-b102-4427-b43c-9d7b73abeb60@github.com>
Message-ID: <DEyQ1dHaZuAffX41Na1eCnzCYH5JsZsVmG6Feqg_DQQ=.d24718d4-1b8c-417b-b13c-b75fc44ebaa5@github.com>

On Wed, 7 Apr 2021 16:17:07 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleaned up some spaces
>
> Marked as reviewed by goetz (Reviewer).

Thank you Goetz! 
I will now proceed and integrate the PR.

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

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

From lucy at openjdk.java.net  Wed Apr  7 16:23:44 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 7 Apr 2021 16:23:44 GMT
Subject: Integrated: 8264173: [s390] Improve Hardware Feature Detection And
 Reporting
In-Reply-To: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com>
References: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com>
Message-ID: <UUOUrx4QWMYsuAe6FdDRTaA0ysQ2uNTNLxdGLQ9RSgY=.83d30201-da08-4e9e-825a-b29f11e5f1de@github.com>

On Thu, 25 Mar 2021 15:28:21 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> This enhancement is intended to improve the hardware feature detection and reporting, in particular for more recently introduced hardware. The enhancement is a prerequisite for possible future feature exploitation. 
> 
> Reviews are highly welcome and appreciated.

This pull request has now been integrated.

Changeset: d3fdd739
Author:    Lutz Schmidt <lucy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d3fdd739
Stats:     557 lines in 4 files changed: 340 ins; 74 del; 143 mod

8264173: [s390] Improve Hardware Feature Detection And Reporting

Reviewed-by: mdoerr, goetz

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

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

From mark.reinhold at oracle.com  Wed Apr  7 21:47:19 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed,  7 Apr 2021 14:47:19 -0700 (PDT)
Subject: New candidate JEP: 410: Remove the Experimental AOT and JIT Compiler
Message-ID: <20210407214719.2E6553DF0DA@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/410

  Summary: Remove the experimental Java-based ahead-of-time (AOT) and
  just-in-time (JIT) compiler.  This compiler has seen little use since
  its introduction and the effort required to maintain it is significant.
  Retain the experimental Java-level JVM compiler interface (JVMCI) so
  that developers can continue to use externally-built versions of the
  compiler for JIT compilation.

- Mark

From vlivanov at openjdk.java.net  Wed Apr  7 22:07:21 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 7 Apr 2021 22:07:21 GMT
Subject: RFR: 8264871: Dependencies: Miscellaneous cleanups in dependencies.cpp
Message-ID: <JNlxCwvoJ0E_LJ07OD9a9-R_7ZziN2ib682QMQ3-CkQ=.c88a0e49-934b-401f-8616-32912384a38d@github.com>

Miscellaneous cleanups in dependencies.cpp.

Testing:
* [x] hs-tier1 - hs-tier4

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

Commit messages:
 - KlassDepChange::involves_context
 - KlassDepChange::_new_type
 - Dependencies::is_concrete_method
 - Dependencies::verify_method_context
 - int -> uint

Changes: https://git.openjdk.java.net/jdk/pull/3385/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3385&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264871
  Stats: 156 lines in 2 files changed: 70 ins; 58 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3385.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3385/head:pull/3385

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

From vlivanov at openjdk.java.net  Wed Apr  7 22:17:12 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 7 Apr 2021 22:17:12 GMT
Subject: RFR: 8264872: Dependencies: Migrate to PerfData counters
Message-ID: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>

Migrate performance counters on `Dependencies` (`deps_find_witness_*`) to `PerfData`.

Testing:
- [x] hs-tier1 - hs-tier2

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

Depends on: https://git.openjdk.java.net/jdk/pull/3385

Commit messages:
 - CountingClassHierarchyIterator
 - Migrate to PerfData
 - Depenencies perf counters

Changes: https://git.openjdk.java.net/jdk/pull/3386/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3386&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264872
  Stats: 121 lines in 4 files changed: 61 ins; 37 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3386.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3386/head:pull/3386

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

From kvn at openjdk.java.net  Wed Apr  7 22:25:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 7 Apr 2021 22:25:20 GMT
Subject: RFR: 8264872: Dependencies: Migrate to PerfData counters
In-Reply-To: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
References: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
Message-ID: <4yiaYDeeRWpCxqMVjbOAWmukMD1yq1jx3BJjrRAVtDE=.d8299195-b67e-47dc-998d-5fdc41836d2b@github.com>

On Wed, 7 Apr 2021 22:07:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Migrate performance counters on `Dependencies` (`deps_find_witness_*`) to `PerfData`.
> 
> Testing:
> - [x] hs-tier1 - hs-tier2

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From vlivanov at openjdk.java.net  Wed Apr  7 22:27:07 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 7 Apr 2021 22:27:07 GMT
Subject: RFR: 8264873: Dependencies: Split ClassHierarchyWalker
Message-ID: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>

Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder.

Testing:
- [x] hs-tier1 - hs-tier4

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

Depends on: https://git.openjdk.java.net/jdk/pull/3386

Commit messages:
 - Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder

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

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

From vlivanov at openjdk.java.net  Wed Apr  7 22:38:58 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 7 Apr 2021 22:38:58 GMT
Subject: RFR: 8264873: Dependencies: Split ClassHierarchyWalker [v2]
In-Reply-To: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
References: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
Message-ID: <nGnwTUnX0tzu_vJVkY4WWHzEu7RglsM03VBKWA3HGhg=.4ef9557c-6678-4905-b42f-82945c8128f6@github.com>

> Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Fix formatting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3387/files
  - new: https://git.openjdk.java.net/jdk/pull/3387/files/6b905d78..071de4cd

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

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

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

From njian at openjdk.java.net  Thu Apr  8 01:48:42 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 8 Apr 2021 01:48:42 GMT
Subject: RFR: 8264352: AArch64: Optimize vector "not/andNot" for NEON and
 SVE
In-Reply-To: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
References: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
Message-ID: <aQkJTbjY4TmI8__kw7lsgdbirKuQaB9PRRieYpyamcU=.6933586f-ce35-4c1e-b4c6-646212e77266@github.com>

On Wed, 7 Apr 2021 05:53:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Since the vector bitwise `"andNot"` is implemented with `"v1.and(v2.xor(-1))"`, the generated codes with SVE look like:
>   mov z16.b, #-1
>   eor z17.d, z20.d, z16.d
>   and z18.d, z18.d, z17.d
> This could be improved with a single instruction:
>   bic z16.d, z16.d, z18.d
> Similarly, the following optimization for NEON is also needed:
>   not v21.16b, v21.16b
>   and v21.16b, v21.16b, v18.16b  ==>  bic v21.16b, v18.16b, v21.16b
> This patch also adds the following optimization to vector` "not"` for SVE which has already been added for NEON:
>   mov z16.b, #-1
>   eor z17.d, z20.d, z16.d     ==>   not z17.d, p7/m, z20.d
> The performance can improve about `16% ~ 36%` with NEON for the `"AND_NOT"` benchmark [1].
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/ByteMaxVector.java#L343
> 
> Tested tier1 and jdk:tier3.

Looks good.

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

Marked as reviewed by njian (Committer).

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

From xgong at openjdk.java.net  Thu Apr  8 01:52:08 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 8 Apr 2021 01:52:08 GMT
Subject: RFR: 8264352: AArch64: Optimize vector "not/andNot" for NEON and
 SVE
In-Reply-To: <vdYCwJcFhx9QjW6d6hrVmSeX6gKhoZNz8A0PapMZokA=.8c991e25-62df-4db8-ba2f-79c18ee6b857@github.com>
References: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
 <vdYCwJcFhx9QjW6d6hrVmSeX6gKhoZNz8A0PapMZokA=.8c991e25-62df-4db8-ba2f-79c18ee6b857@github.com>
Message-ID: <3x-7Bl7IUNLh_RV3l6f8DT0lmLrbPtWznqZgV9UFVDE=.5bc933c5-255a-4725-9ea8-f96c00d09002@github.com>

On Wed, 7 Apr 2021 09:03:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Since the vector bitwise `"andNot"` is implemented with `"v1.and(v2.xor(-1))"`, the generated codes with SVE look like:
>>   mov z16.b, #-1
>>   eor z17.d, z20.d, z16.d
>>   and z18.d, z18.d, z17.d
>> This could be improved with a single instruction:
>>   bic z16.d, z16.d, z18.d
>> Similarly, the following optimization for NEON is also needed:
>>   not v21.16b, v21.16b
>>   and v21.16b, v21.16b, v18.16b  ==>  bic v21.16b, v18.16b, v21.16b
>> This patch also adds the following optimization to vector` "not"` for SVE which has already been added for NEON:
>>   mov z16.b, #-1
>>   eor z17.d, z20.d, z16.d     ==>   not z17.d, p7/m, z20.d
>> The performance can improve about `16% ~ 36%` with NEON for the `"AND_NOT"` benchmark [1].
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/ByteMaxVector.java#L343
>> 
>> Tested tier1 and jdk:tier3.
>
> Marked as reviewed by aph (Reviewer).

Thanks for the review @theRealAph @nsjian !

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

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

From kvn at openjdk.java.net  Thu Apr  8 03:19:32 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 03:19:32 GMT
Subject: RFR: 8264873: Dependencies: Split ClassHierarchyWalker [v2]
In-Reply-To: <nGnwTUnX0tzu_vJVkY4WWHzEu7RglsM03VBKWA3HGhg=.4ef9557c-6678-4905-b42f-82945c8128f6@github.com>
References: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
 <nGnwTUnX0tzu_vJVkY4WWHzEu7RglsM03VBKWA3HGhg=.4ef9557c-6678-4905-b42f-82945c8128f6@github.com>
Message-ID: <wh92WI6FSW_fidBQmx1AiBHU8IAHgLPmKxc0Wqo_tPI=.9a17a9f6-ef30-4848-9454-dda7f59aa0bc@github.com>

On Wed, 7 Apr 2021 22:38:58 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier4
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting

Marked as reviewed by kvn (Reviewer).

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

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

From xgong at openjdk.java.net  Thu Apr  8 03:45:42 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 8 Apr 2021 03:45:42 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v2]
In-Reply-To: <XsBTy3IFrhUJsdkHQKKd-95_F3pNGY0994st5krllcw=.dea9a899-c9f6-4a03-b925-c366e9c17285@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
 <RV2r7e15ksBiQa__sDVH8r-WVAEiO32FdB7fVt0Sak8=.98741436-1a90-41ca-9ea7-6682a6f7dd60@github.com>
 <XsBTy3IFrhUJsdkHQKKd-95_F3pNGY0994st5krllcw=.dea9a899-c9f6-4a03-b925-c366e9c17285@github.com>
Message-ID: <5dkX8tZwS9ZWQ7t3d130spNBF54dICgn-XLKW-OuLCs=.7d319f40-1c32-4ebd-8a6b-f11780292d2a@github.com>

On Wed, 7 Apr 2021 16:06:44 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> @iwanowww should confirm correctness of such optimization.
>> Regarding changes - they seem fine to me. I notice that VectorNode and its subclasses do not check for TOP inputs. Since Vector API introduce vectors in graph before SuperWord transformation their input could become dead. How such cases handled? And why we did not hit them yet? is_vect() should hit assert.
>
> I'm not fond of the proposed approach. 
> 
> It hard-codes some implicit assumptions about vector mask representation.  
> Also, vector type mismatch can trigger asserts since some vector-related code expects that types of vector inputs match precisely).
> 
> I suggest to introduce artificial cast nodes (`VectorLoadMask (VectorStoreMask vmask) ==> VectorMaskCast (vmask)`) which are then lowered into no-ops on backend side.

Hi @iwanowww , thanks for looking at this PR.

> It hard-codes some implicit assumptions about vector mask representation.
> Also, vector type mismatch can trigger asserts since some vector-related code expects that types of vector inputs match precisely).

Agree. I'm also anxious about the potential assertion although I didn't met the issue currently.

> I suggest to introduce artificial cast nodes (`VectorLoadMask (VectorStoreMask vmask) ==> VectorMaskCast (vmask)`) which are then lowered into no-ops on backend side.

It's a good idea to add a cast node for mask. I tried with it, and it can work well for the casting with same element size and vector   length. However, for the different element size (i.g. short->int) casting, I think the original `VectorLoadMask (VectorStoreMask vmask)` is better since there are some optimizations existed. Also using `VectorMaskCast` for all cases needs more match rules in the backend which I think is duplicated with `VectorLoadMask+VectorStoreMask`. So does it look good for you if the `VectorMaskCast` is limited to the masking cast with the same element size? The changes might look like:
diff --git a/src/hotspot/share/opto/vectornode.cpp b/src/hotspot/share/opto/vectornode.cpp
index 326b9c4a5a0..d7b53c247fb 100644
--- a/src/hotspot/share/opto/vectornode.cpp
+++ b/src/hotspot/share/opto/vectornode.cpp
@@ -1232,6 +1232,10 @@ Node* VectorUnboxNode::Ideal(PhaseGVN* phase, bool can_reshape) {
         bool is_vector_mask    = vbox_klass->is_subclass_of(ciEnv::current()->vector_VectorMask_klass());
         bool is_vector_shuffle = vbox_klass->is_subclass_of(ciEnv::current()->vector_VectorShuffle_klass());
         if (is_vector_mask) {
+          if (in_vt->length_in_bytes() == out_vt->length_in_bytes() &&
+              Matcher::match_rule_supported(Op_VectorMaskCast)) {
+            return new VectorMaskCastNode(value, out_vt);
+          }
           // VectorUnbox (VectorBox vmask) ==> VectorLoadMask (VectorStoreMask vmask)
           value = phase->transform(VectorStoreMaskNode::make(*phase, value, in_vt->element_basic_type(), in_vt->length()));
           return new VectorLoadMaskNode(value, out_vt);

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

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

From xgong at openjdk.java.net  Thu Apr  8 03:51:28 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 8 Apr 2021 03:51:28 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v2]
In-Reply-To: <XsBTy3IFrhUJsdkHQKKd-95_F3pNGY0994st5krllcw=.dea9a899-c9f6-4a03-b925-c366e9c17285@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
 <RV2r7e15ksBiQa__sDVH8r-WVAEiO32FdB7fVt0Sak8=.98741436-1a90-41ca-9ea7-6682a6f7dd60@github.com>
 <XsBTy3IFrhUJsdkHQKKd-95_F3pNGY0994st5krllcw=.dea9a899-c9f6-4a03-b925-c366e9c17285@github.com>
Message-ID: <hv5FOW1N_YN_ow02GjYEmOQSxD6sAWFNa8cmB960s4c=.816fa680-6418-4ebd-a56f-5298005db102@github.com>

On Wed, 7 Apr 2021 16:06:44 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> @iwanowww should confirm correctness of such optimization.
>> Regarding changes - they seem fine to me. I notice that VectorNode and its subclasses do not check for TOP inputs. Since Vector API introduce vectors in graph before SuperWord transformation their input could become dead. How such cases handled? And why we did not hit them yet? is_vect() should hit assert.
>
> I'm not fond of the proposed approach. 
> 
> It hard-codes some implicit assumptions about vector mask representation.  
> Also, vector type mismatch can trigger asserts since some vector-related code expects that types of vector inputs match precisely).
> 
> I suggest to introduce artificial cast nodes (`VectorLoadMask (VectorStoreMask vmask) ==> VectorMaskCast (vmask)`) which are then lowered into no-ops on backend side.

> @iwanowww should confirm correctness of such optimization.
> Regarding changes - they seem fine to me. I notice that VectorNode and its subclasses do not check for TOP inputs. Since Vector API introduce vectors in graph before SuperWord transformation their input could become dead. How such cases handled? And why we did not hit them yet? is_vect() should hit assert.

Thanks for looking at this PR @vnkozlov . To be honest, I'v no idea about the TOP checking issue to the inputs of the VectorNode. Hope @iwanowww  could explain more. Thanks!

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

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

From dlong at openjdk.java.net  Thu Apr  8 05:21:37 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 8 Apr 2021 05:21:37 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
Message-ID: <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>

On Wed, 7 Apr 2021 07:28:08 GMT, Eric Liu <eliu at openjdk.org> wrote:

> The vector shift count was defined by two separate nodes(LShiftCntV and
> RShiftCntV), which would prevent them from being shared when the shift
> counts are the same.
> 
> public static void test_shiftv(int sh) {
>     for (int i = 0; i < N; i+=1) {
>         a0[i] = a1[i] << sh;
>         b0[i] = b1[i] >> sh;
>     }
> }
> 
> Given the example above, by merging the same shift counts into one
> node, they could be shared by shift nodes(RShiftV or LShiftV) like
> below:
> 
> Before:
> 1184  LShiftCntV  === _  1189  [[ 1185  ... ]]
> 1190  RShiftCntV  === _  1189  [[ 1191  ... ]]
> 1185  LShiftVI  === _  1181  1184  [[ 1186 ]]
> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
> 
> After:
> 1190  ShiftCntV  === _  1189  [[ 1191 1204  ... ]]
> 1204  LShiftVI  === _  1211  1190  [[ 1203 ]]
> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
> 
> The final code could remove one redundant ?dup?(scalar->vector),
> with one register saved.
> 
> Before:
>         dup     v16.16b, w12
>         dup     v17.16b, w12
>         ...
>         ldr     q18, [x13, #16]
>         sshl    v18.4s, v18.4s, v16.4s
>         add     x18, x16, x12           ; iaload
> 
>         add     x4, x15, x12
>         str     q18, [x4, #16]          ; iastore
> 
>         ldr     q18, [x18, #16]
>         add     x12, x14, x12
>         neg     v19.16b, v17.16b
>         sshl    v18.4s, v18.4s, v19.4s
>         str     q18, [x12, #16]         ; iastore
> 
> After:
>         dup	v16.16b, w11
>         ...
>         ldr	q17, [x13, #16]
>         sshl	v17.4s, v17.4s, v16.4s
>         add	x2, x22, x11            ; iaload
> 
>         add	x4, x16, x11
>         str	q17, [x4, #16]          ; iastore
> 
>         ldr	q17, [x2, #16]
>         add	x11, x21, x11
>         neg	v18.16b, v16.16b
>         sshl	v17.4s, v17.4s, v18.4s
>         str	q17, [x11, #16]         ; iastore

You should be able to do this without introducing a new node type.  You could change the shift rules to match a vector register like x86.ad and aarch64_sve.ad already do.

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

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

From xgong at openjdk.java.net  Thu Apr  8 06:27:17 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 8 Apr 2021 06:27:17 GMT
Subject: Integrated: 8264352: AArch64: Optimize vector "not/andNot" for NEON
 and SVE
In-Reply-To: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
References: <2RRMDFhq5Eo8gVfh1Mrn343KFLKPJh08oHx4TMGgbcw=.d8ea6de7-8efa-424b-abb2-8b7135e4675d@github.com>
Message-ID: <ao_4nHiu7kLWCHBzJSavjAe7Q-RjqlcRA9RBHeaxgpU=.448ea397-3741-45bf-b9ce-faa9f237c56b@github.com>

On Wed, 7 Apr 2021 05:53:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Since the vector bitwise `"andNot"` is implemented with `"v1.and(v2.xor(-1))"`, the generated codes with SVE look like:
>   mov z16.b, #-1
>   eor z17.d, z20.d, z16.d
>   and z18.d, z18.d, z17.d
> This could be improved with a single instruction:
>   bic z16.d, z16.d, z18.d
> Similarly, the following optimization for NEON is also needed:
>   not v21.16b, v21.16b
>   and v21.16b, v21.16b, v18.16b  ==>  bic v21.16b, v18.16b, v21.16b
> This patch also adds the following optimization to vector` "not"` for SVE which has already been added for NEON:
>   mov z16.b, #-1
>   eor z17.d, z20.d, z16.d     ==>   not z17.d, p7/m, z20.d
> The performance can improve about `16% ~ 36%` with NEON for the `"AND_NOT"` benchmark [1].
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/ByteMaxVector.java#L343
> 
> Tested tier1 and jdk:tier3.

This pull request has now been integrated.

Changeset: e89542fb
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e89542fb
Stats:     219 lines in 7 files changed: 185 ins; 0 del; 34 mod

8264352: AArch64: Optimize vector "not/andNot" for NEON and SVE

Reviewed-by: aph, njian

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

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

From dongbo at openjdk.java.net  Thu Apr  8 06:33:43 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 8 Apr 2021 06:33:43 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

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

  reduce unnecessary memory write traffic in non-SIMD code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3228/files
  - new: https://git.openjdk.java.net/jdk/pull/3228/files/a342ad1e..ab0e405b

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

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

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

From dongbo at openjdk.java.net  Thu Apr  8 06:39:11 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 8 Apr 2021 06:39:11 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6]
In-Reply-To: <uYrE1TBlkMS4Jlz36xe0CX_v9iucRqkHCM_Sc5F2gnA=.4a85979d-9e73-4a83-981c-ee47faf051ce@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <p7UhN-ChMgoVPh1Jmc0clB0LUNmApV__m56rfbMFHJ8=.9fd0730e-e373-4b85-a9ba-9a69f16653b7@github.com>
 <sGQjaUtyiB5cDch3o5YGyLnf9lG6YoMrwABun7jgbK4=.a0b249ef-2e79-4b56-8eae-e0e2181bd8ec@github.com>
 <uYrE1TBlkMS4Jlz36xe0CX_v9iucRqkHCM_Sc5F2gnA=.4a85979d-9e73-4a83-981c-ee47faf051ce@github.com>
Message-ID: <M87LnnCUtlf_s6jY3eRaU8IrV_YM-zzEh6jjdPOjGhs=.83ed3f80-8c28-4acd-bee0-13534b1dd656@github.com>

On Wed, 7 Apr 2021 09:53:36 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5829:
>> 
>>> 5827:     __ strb(r14, __ post(dst, 1));
>>> 5828:     __ strb(r15, __ post(dst, 1));
>>> 5829:     __ strb(r13, __ post(dst, 1));
>> 
>> I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think.
>
> Sorry, that's not quite right, but you get the idea: let's not generate unnecessary memory traffic.

Okay, implemented as:
__ lslw(r14, r10, 10);
__ bfiw(r14, r11, 4, 6);
__ bfmw(r14, r12, 2, 5);
__ rev16w(r14, r14);
__ bfiw(r13, r12, 6, 2);
__ strh(r14, __ post(dst, 2));
__ strb(r13, __ post(dst, 1));

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

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

From aph at openjdk.java.net  Thu Apr  8 08:32:18 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 8 Apr 2021 08:32:18 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
Message-ID: <jMsubVt8m3Xn_R8ABDVLCzZK3kyvO2EFhnjrc6XX5l0=.198df9f0-4f9a-4660-aa70-9a36612e11d2@github.com>

On Thu, 8 Apr 2021 06:33:43 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce unnecessary memory write traffic in non-SIMD code

Marked as reviewed by aph (Reviewer).

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

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

From whuang at openjdk.java.net  Thu Apr  8 08:35:41 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 8 Apr 2021 08:35:41 GMT
Subject: RFR: 8264885: Fix the code style of macro in aarch64_neon_ad.m4
Message-ID: <xjU_nkh8X6ObmJAkMYYzBYJ5M3-tNFuOpRCLHof4lwI=.bf86b041-4d22-4223-a606-bc061422e1aa@github.com>

* trivial fix
* align the comment of macros

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

Commit messages:
 - 8264885: Fix the code style of macro in aarch64_neon_ad.m4

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

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

From aph at openjdk.java.net  Thu Apr  8 08:49:10 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 8 Apr 2021 08:49:10 GMT
Subject: RFR: 8264885: Fix the code style of macro in aarch64_neon_ad.m4
In-Reply-To: <xjU_nkh8X6ObmJAkMYYzBYJ5M3-tNFuOpRCLHof4lwI=.bf86b041-4d22-4223-a606-bc061422e1aa@github.com>
References: <xjU_nkh8X6ObmJAkMYYzBYJ5M3-tNFuOpRCLHof4lwI=.bf86b041-4d22-4223-a606-bc061422e1aa@github.com>
Message-ID: <j78fIUWPOx0kMp184CvocedXMG4-7z0PXy7WdHMMcDQ=.d7dbc478-92f3-42de-8f02-48bd4e41764d@github.com>

On Thu, 8 Apr 2021 08:28:52 GMT, Wang Huang <whuang at openjdk.org> wrote:

> * trivial fix
> * align the comment of macros

Marked as reviewed by aph (Reviewer).

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

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

From dongbo at openjdk.java.net  Thu Apr  8 09:08:17 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Thu, 8 Apr 2021 09:08:17 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <jMsubVt8m3Xn_R8ABDVLCzZK3kyvO2EFhnjrc6XX5l0=.198df9f0-4f9a-4660-aa70-9a36612e11d2@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
 <jMsubVt8m3Xn_R8ABDVLCzZK3kyvO2EFhnjrc6XX5l0=.198df9f0-4f9a-4660-aa70-9a36612e11d2@github.com>
Message-ID: <ihe1BY1gSa4LAWNjnF0GGh-3R56YYhLAOWtM7-sGHGQ=.fc0a4abe-908a-4582-86a6-8d56193015b0@github.com>

On Thu, 8 Apr 2021 08:28:53 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce unnecessary memory write traffic in non-SIMD code
>
> Marked as reviewed by aph (Reviewer).

@theRealAph Thanks for the review.

Hi @nick-arm, are you also ok with the newest commit?

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

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

From ngasson at openjdk.java.net  Thu Apr  8 09:13:09 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 8 Apr 2021 09:13:09 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
Message-ID: <FiqGN4RkG8w_gL11WWWjFf6YpLUlIeU_QU0Ko3neuy4=.97207cfe-cfeb-4dc7-ad36-c13f55796064@github.com>

On Thu, 8 Apr 2021 06:33:43 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce unnecessary memory write traffic in non-SIMD code

Marked as reviewed by ngasson (Committer).

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

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

From ngasson at openjdk.java.net  Thu Apr  8 09:13:09 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 8 Apr 2021 09:13:09 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7]
In-Reply-To: <ihe1BY1gSa4LAWNjnF0GGh-3R56YYhLAOWtM7-sGHGQ=.fc0a4abe-908a-4582-86a6-8d56193015b0@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <tqfBnrKpOUYXGoMxEvArzsXjdIHg7N2Xvtt6_UQ5uEk=.5ed97048-b05f-4ab0-a8c1-7ed7345c7985@github.com>
 <jMsubVt8m3Xn_R8ABDVLCzZK3kyvO2EFhnjrc6XX5l0=.198df9f0-4f9a-4660-aa70-9a36612e11d2@github.com>
 <ihe1BY1gSa4LAWNjnF0GGh-3R56YYhLAOWtM7-sGHGQ=.fc0a4abe-908a-4582-86a6-8d56193015b0@github.com>
Message-ID: <nYOZzRGbJTFTZqnIswMZNfi3e25V1CxlGJaB022RWug=.92d1ecab-9bf8-40a9-a830-86afbcc8f083@github.com>

On Thu, 8 Apr 2021 09:05:43 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> Hi @nick-arm, are you also ok with the newest commit?

It looks ok to me but I'm not a Reviewer.

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

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

From dholmes at openjdk.java.net  Thu Apr  8 09:25:48 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 8 Apr 2021 09:25:48 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v2]
In-Reply-To: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
Message-ID: <uDil0eWh2xOe2h7napvVnjoddYii22KkL35xdWQnkaI=.42760eec-aad3-4b52-a0aa-9bae04186126@github.com>

> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
> 
> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
> 
> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
> 
> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
> 
> Some missing CHECK_ uses were added.
> 
> Testing:
>   - tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fixed CHECK on return statement.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3394/files
  - new: https://git.openjdk.java.net/jdk/pull/3394/files/78298e5f..1adf0fd0

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

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

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

From vlivanov at openjdk.java.net  Thu Apr  8 10:10:28 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 8 Apr 2021 10:10:28 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v2]
In-Reply-To: <5dkX8tZwS9ZWQ7t3d130spNBF54dICgn-XLKW-OuLCs=.7d319f40-1c32-4ebd-8a6b-f11780292d2a@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
 <RV2r7e15ksBiQa__sDVH8r-WVAEiO32FdB7fVt0Sak8=.98741436-1a90-41ca-9ea7-6682a6f7dd60@github.com>
 <XsBTy3IFrhUJsdkHQKKd-95_F3pNGY0994st5krllcw=.dea9a899-c9f6-4a03-b925-c366e9c17285@github.com>
 <5dkX8tZwS9ZWQ7t3d130spNBF54dICgn-XLKW-OuLCs=.7d319f40-1c32-4ebd-8a6b-f11780292d2a@github.com>
Message-ID: <ROmWizPsmCrzXbAK1xXrYEWimlVGBOaeV_Z3YryJgrE=.b38b09fe-25c9-485c-a6b7-c3247d31d34c@github.com>

On Thu, 8 Apr 2021 03:41:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> So does it look good for you if the VectorMaskCast is limited to the masking cast with the same element size?

Yes, I'm fine with focusing on no-op case for now. 
Moreover, both vector length and element size should match to reuse the very same bit representation of the mask.

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

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

From vlivanov at openjdk.java.net  Thu Apr  8 10:17:28 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 8 Apr 2021 10:17:28 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v2]
In-Reply-To: <hv5FOW1N_YN_ow02GjYEmOQSxD6sAWFNa8cmB960s4c=.816fa680-6418-4ebd-a56f-5298005db102@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
 <RV2r7e15ksBiQa__sDVH8r-WVAEiO32FdB7fVt0Sak8=.98741436-1a90-41ca-9ea7-6682a6f7dd60@github.com>
 <XsBTy3IFrhUJsdkHQKKd-95_F3pNGY0994st5krllcw=.dea9a899-c9f6-4a03-b925-c366e9c17285@github.com>
 <hv5FOW1N_YN_ow02GjYEmOQSxD6sAWFNa8cmB960s4c=.816fa680-6418-4ebd-a56f-5298005db102@github.com>
Message-ID: <srkN3wp5Zywh9UdwW1ZfoFzGJQ4jk0G7Fgu7wiTXct8=.5a4fa626-22ed-4891-9b48-4eab60911a2e@github.com>

On Thu, 8 Apr 2021 03:44:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>  I notice that VectorNode and its subclasses do not check for TOP inputs. 
> Since Vector API introduce vectors in graph before SuperWord transformation their input could become dead. 
> How such cases handled? And why we did not hit them yet? is_vect() should hit assert.

`VectorLoadMaskNode::Identity()` can't observe TOP types because it uses the type cached at construction (`type()` and `VectorNode` extends `TypeNode`). Still, a TOP input is possible and should be filtered out by opcode check (`in(1)->Opcode() == Op_VectorStoreMask`).

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

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

From eliu at openjdk.java.net  Thu Apr  8 10:39:07 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Thu, 8 Apr 2021 10:39:07 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
Message-ID: <N-oGkAM31WpJZQNPby0l1OkTcv1A2nqF0U4C5fwUmkk=.50ada121-bff5-482a-8f65-5bffd07f098b@github.com>

On Thu, 8 Apr 2021 05:14:52 GMT, Dean Long <dlong at openjdk.org> wrote:

> You should be able to do this without introducing a new node type. 

Do you mean just matching them with ReplicateBNode? Indeed they do generate the same instruction. I was wondering about the same but I'm not sure if ReplicateBNode has the same semantic with ShiftCntV in middle-end.

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

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

From rcastanedalo at openjdk.java.net  Thu Apr  8 10:49:22 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 8 Apr 2021 10:49:22 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <M9OcTa-WZ8WQYHiGJZ1hziMDFeGOYs593CweXthMAgc=.3de10d71-924a-4ce9-8215-72f13bd5e638@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <M9OcTa-WZ8WQYHiGJZ1hziMDFeGOYs593CweXthMAgc=.3de10d71-924a-4ce9-8215-72f13bd5e638@github.com>
Message-ID: <YwFxUxSk7TMhWe7yK6Aty-C1kE5s1SXwqul3UJZd29o=.9cde72b2-1364-45e6-9314-0225028b1e93@github.com>

On Tue, 6 Apr 2021 17:54:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
>> 
>> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
>> 
>> Tested on:
>> - original bug reproducer
>> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
>> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)
>
> src/hotspot/share/opto/lcm.cpp line 1415:
> 
>> 1413:       if (dead) {
>> 1414:         // Remove projections if n is a dead multi-node.
>> 1415:         for (uint k = j + n->outcnt(); sb->get_node(k)->is_Proj(); k--) {
> 
> I don't get this logic. The loop is not executed if sb->get_node(j + n->outcnt()) is not Proj node.

Thanks for reviewing, Vladimir! The intention of this loop is to remove all projections of a multi-node `n` before removing `n` itself (if it has been found to be dead). I indeed have to rethink this code as e.g. the loop can be executed if `n` is not a multi-node but `k` ends up pointing to a projection of another node. I will investigate and come back with a new revision.

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

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

From rcastanedalo at openjdk.java.net  Thu Apr  8 10:57:07 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 8 Apr 2021 10:57:07 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <M9OcTa-WZ8WQYHiGJZ1hziMDFeGOYs593CweXthMAgc=.3de10d71-924a-4ce9-8215-72f13bd5e638@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <M9OcTa-WZ8WQYHiGJZ1hziMDFeGOYs593CweXthMAgc=.3de10d71-924a-4ce9-8215-72f13bd5e638@github.com>
Message-ID: <lWT-o2dYgMtvRO9NI_Skm9_P_ZxoN0LmKVWfuEdBu48=.d73e95cd-7d21-4353-8b76-3559e3c77316@github.com>

On Tue, 6 Apr 2021 17:55:35 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
>> 
>> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
>> 
>> Tested on:
>> - original bug reproducer
>> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
>> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)
>
> src/hotspot/share/opto/lcm.cpp line 1419:
> 
>> 1417:                  "dead projection should correspond to current node");
>> 1418:           sb->get_node(k)->disconnect_inputs(C);
>> 1419:           sb->remove_node(k);
> 
> If you remove node here then `j` could be incorrect in `sb->remove_node(j)` at line #1424

`k` should always be greater than `j`, as `sb->get_node(k)` is a projection of `sb->get_node(j)`. Shouldn't this make the removal safe?

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

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

From rcastanedalo at openjdk.java.net  Thu Apr  8 11:07:07 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 8 Apr 2021 11:07:07 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <C9s8H9XxXGh98TOaXv7uVitMA1M9ZS2aMihwpJx0og4=.81f079d3-1d2c-4ce8-a039-bd2dbfb9b1aa@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <C9s8H9XxXGh98TOaXv7uVitMA1M9ZS2aMihwpJx0og4=.81f079d3-1d2c-4ce8-a039-bd2dbfb9b1aa@github.com>
Message-ID: <-vl-o8PemGJNrb-7AtTQoNB6YGnhxoA3CVWot_iihlU=.90713355-bd98-4c1c-b253-08d660c1590e@github.com>

On Tue, 6 Apr 2021 17:58:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Also where is guarantee that all Proj users are in the same block.

Isn't this guaranteed by `PhaseCFG::schedule_node_into_block()`?

https://github.com/openjdk/jdk/blob/ec599da68cac6349e7f28b508d8038c18a4e7347/src/hotspot/share/opto/gcm.cpp#L48-L72

I will run some tests with extra assertions in `PhaseCFG::verify()` to double-check.

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

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

From vlivanov at openjdk.java.net  Thu Apr  8 11:08:25 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 8 Apr 2021 11:08:25 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
Message-ID: <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>

On Thu, 8 Apr 2021 05:14:52 GMT, Dean Long <dlong at openjdk.org> wrote:

> You should be able to do this without introducing a new node type. You could change the shift rules to match a vector register like x86.ad and aarch64_sve.ad already do.

Not sure what you refer to in x86.ad: vector shifts with variable scalar count require the scalar to be placed in XMM register. `ShiftCntV` handles register-to-register move between different register classes (`RegI` and `Vec*`). 

Do you suggest reusing some existing vector node (like `Replicate`) to covert the scalar index to vector first? It would have slightly different behavior on x86.

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

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

From vlivanov at openjdk.java.net  Thu Apr  8 11:22:28 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 8 Apr 2021 11:22:28 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
 <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
Message-ID: <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>

On Thu, 8 Apr 2021 11:04:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> You should be able to do this without introducing a new node type.  You could change the shift rules to match a vector register like x86.ad and aarch64_sve.ad already do.
>
>> You should be able to do this without introducing a new node type. You could change the shift rules to match a vector register like x86.ad and aarch64_sve.ad already do.
> 
> Not sure what you refer to in x86.ad: vector shifts with variable scalar count require the scalar to be placed in XMM register. `ShiftCntV` handles register-to-register move between different register classes (`RegI` and `Vec*`). 
> 
> Do you suggest reusing some existing vector node (like `Replicate`) to covert the scalar index to vector first? It would have slightly different behavior on x86.

Regarding the proposed change itself (`LShiftCntV/RShiftCntV => ShiftCntV`).

Not sure how important it is, but it has an unfortunate change in generated code for right vector shifts on AArch32: instead of sharing the result of index negation at all use sites, negation is performed at every use site now. 

As a consequence, in an auto-vectorized loop it will lead to:
- 1 instruction per loop iteration (multiplied by unrolling factor);
- no way to hoist the negation of loop invariant index.

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

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

From eliu at openjdk.java.net  Thu Apr  8 11:56:18 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Thu, 8 Apr 2021 11:56:18 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
 <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
 <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>
Message-ID: <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>

On Thu, 8 Apr 2021 11:19:27 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Regarding the proposed change itself (`LShiftCntV/RShiftCntV => ShiftCntV`).
> 
> Not sure how important it is, but it has an unfortunate change in generated code for right vector shifts on AArch32: instead of sharing the result of index negation at all use sites, negation is performed at every use site now.
> 
> As a consequence, in an auto-vectorized loop it will lead to:
> 
> * 1 instruction per loop iteration (multiplied by unrolling factor);
> * no way to hoist the negation of loop invariant index.

Thanks for your feedback!

I have checked the generated code on AArch32 and it's a shame that 'vneg' is at every use point.

Before:
0xf46c8338:   add fp, r7, fp
0xf46c833c:   vshl.u16  d9, d9, d8
0xf46c8340:   vstr  d9, [fp, #12]
0xf46c8344:   vshl.u16  d9, d10, d8
0xf46c8348:   vstr  d9, [fp, #20]
0xf46c834c:   vshl.u16  d9, d11, d8
0xf46c8350:   vstr  d9, [fp, #28]

After:
0xf4aa1328:   add fp, r7, fp
0xf4aa132c:   vneg.s8 d13, d8
0xf4aa1330:   vshl.u16  d9, d9, d13
0xf4aa1334:   vstr  d9, [fp, #12]
0xf4aa1338:   vneg.s8 d9, d8
0xf4aa133c:   vshl.u16  d9, d10, d9
0xf4aa1340:   vstr  d9, [fp, #20]
0xf4aa1344:   vneg.s8 d9, d8
0xf4aa1348:   vshl.u16  d9, d11, d9
0xf4aa134c:   vstr  d9, [fp, #28]  

I suppose it's more like a trade off that either remaining those two R/LShiftCntV nodes and change AArch64 and X86  to what AArch32 dose, or merging them and accept this defect on AArch32.

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

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

From roland at openjdk.java.net  Thu Apr  8 12:03:18 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 8 Apr 2021 12:03:18 GMT
Subject: RFR: 8264063: Outer Safepoint poll load should not reference the
 head of inner strip mined loop. [v2]
In-Reply-To: <DN9M2PExByDIxe0fgJgvWxIp6pXBzXgpjBT1dS1MBvM=.742d63e1-22db-4f2d-9167-ccfc4d208313@github.com>
References: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
 <DN9M2PExByDIxe0fgJgvWxIp6pXBzXgpjBT1dS1MBvM=.742d63e1-22db-4f2d-9167-ccfc4d208313@github.com>
Message-ID: <gvOiGEA8e2xFc7dZL0KKSziW7thwncl-FawuNLcVM5Y=.81eb94c5-1f21-4785-89da-8fe493bf8b73@github.com>

On Wed, 7 Apr 2021 16:05:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> When loop is "strip mined" polling address load ([parse1.cpp#L2280](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse1.cpp#L2280)) should be cloned together with safepoint node and pinned outside inner loop. Otherwise we have issues like [8263352](https://bugs.openjdk.java.net/browse/JDK-8263352)
>> 
>> I also remove leftover (unused needs_polling_address_input() method) from  [8220051](https://bugs.openjdk.java.net/browse/JDK-8220051) changes.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unneeded anymore code in match_fill_loop()

Looks good to me.

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

Marked as reviewed by roland (Reviewer).

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

From vlivanov at openjdk.java.net  Thu Apr  8 12:41:17 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 8 Apr 2021 12:41:17 GMT
Subject: RFR: 8264063: Outer Safepoint poll load should not reference the
 head of inner strip mined loop. [v2]
In-Reply-To: <DN9M2PExByDIxe0fgJgvWxIp6pXBzXgpjBT1dS1MBvM=.742d63e1-22db-4f2d-9167-ccfc4d208313@github.com>
References: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
 <DN9M2PExByDIxe0fgJgvWxIp6pXBzXgpjBT1dS1MBvM=.742d63e1-22db-4f2d-9167-ccfc4d208313@github.com>
Message-ID: <Nc3Sxu7CxRqAIiwEVc-IwSZRik-t-Nv3XcNsc4H05yk=.56b8f222-3052-4247-b900-b0cf8196b2db@github.com>

On Wed, 7 Apr 2021 16:05:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> When loop is "strip mined" polling address load ([parse1.cpp#L2280](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse1.cpp#L2280)) should be cloned together with safepoint node and pinned outside inner loop. Otherwise we have issues like [8263352](https://bugs.openjdk.java.net/browse/JDK-8263352)
>> 
>> I also remove leftover (unused needs_polling_address_input() method) from  [8220051](https://bugs.openjdk.java.net/browse/JDK-8220051) changes.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unneeded anymore code in match_fill_loop()

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From vlivanov at openjdk.java.net  Thu Apr  8 13:02:36 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 8 Apr 2021 13:02:36 GMT
Subject: RFR: 8264918: [JVMCI] getVtableIndexForInterfaceMethod doesn't check
 that type and method are related
Message-ID: <Ry8UFrNx9pAEJMsHvEgmbFALNcvfsaDQeDvkv3koNJ4=.12a43c9f-f133-4f14-9d7a-00aeb1ee63d1@github.com>

getVtableIndexForInterfaceMethod should reject the case when a resolved class doesn't implement the holder interface.

Testing:
- [x] hs-tier1 - hs-tier4

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

Commit messages:
 - getVtableIndexForInterfaceMethod

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

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

From coleenp at openjdk.java.net  Thu Apr  8 13:03:20 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 8 Apr 2021 13:03:20 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v2]
In-Reply-To: <uDil0eWh2xOe2h7napvVnjoddYii22KkL35xdWQnkaI=.42760eec-aad3-4b52-a0aa-9bae04186126@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <uDil0eWh2xOe2h7napvVnjoddYii22KkL35xdWQnkaI=.42760eec-aad3-4b52-a0aa-9bae04186126@github.com>
Message-ID: <HK7GdPI2uU37ss48YqxCbuQciSaYNxNAGC-y9cswY7I=.afab90a2-16c2-4d69-95cc-37db04f5968e@github.com>

On Thu, 8 Apr 2021 09:25:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
>> 
>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
>> 
>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
>> 
>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
>> 
>> Some missing CHECK_ uses were added.
>> 
>> Testing:
>>   - tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed CHECK on return statement.

I think substituting "JavaThread* thread" for "JavaThread* current" is a good change and convention that makes the code more clear, so worth the dull code review and diffs.

src/hotspot/share/c1/c1_Runtime1.cpp line 180:

> 178: static void deopt_caller() {
> 179:   if ( !caller_is_deopted()) {
> 180:     JavaThread* current = JavaThread::current();

It looks like both of these functions could be passed JavaThread from the callers.  You could leave this as a cleanup though.  It would eliminate two explicit JavaThread::current calls.

src/hotspot/share/c1/c1_Runtime1.cpp line 414:

> 412:   assert(klass->is_klass(), "not a class");
> 413:   assert(rank >= 1, "rank must be nonzero");
> 414:   Handle holder(current, klass->klass_holder()); // keep the klass alive

I think this is ok now, since current is obviously the current thread.  There doesn't seem to be a need to use THREAD here.  I don't know about changing all the uses of THREAD to current for Handles/methodHandles/ResourceMark/HandleMark but this seems ok in this context since JavaThread* current is present.

src/hotspot/share/c1/c1_Runtime1.cpp line 695:

> 693:   NOT_PRODUCT(_throw_class_cast_exception_count++;)
> 694:   ResourceMark rm(current);
> 695: char* message = SharedRuntime::generate_class_cast_message(current, object->klass());

Is this indentation off?

src/hotspot/share/interpreter/interpreterRuntime.cpp line 1157:

> 1155: JRT_END
> 1156: 
> 1157: JRT_ENTRY(void, InterpreterRuntime::post_field_access(JavaThread *current, oopDesc* obj,

nit: JavaThread* current

src/hotspot/share/interpreter/interpreterRuntime.cpp line 1237:

> 1235: JRT_END
> 1236: 
> 1237: JRT_ENTRY(void, InterpreterRuntime::post_method_entry(JavaThread *current))

Also move the star here and one below.

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

Marked as reviewed by coleenp (Reviewer).

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

From hseigel at openjdk.java.net  Thu Apr  8 13:16:26 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 8 Apr 2021 13:16:26 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v2]
In-Reply-To: <uDil0eWh2xOe2h7napvVnjoddYii22KkL35xdWQnkaI=.42760eec-aad3-4b52-a0aa-9bae04186126@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <uDil0eWh2xOe2h7napvVnjoddYii22KkL35xdWQnkaI=.42760eec-aad3-4b52-a0aa-9bae04186126@github.com>
Message-ID: <4IppJ2wYSTxcAKq1z7iSB8fxmmtDSlFimFFSJs9no5g=.29e6b187-a81b-4f9f-afd1-0ce0e9b956f7@github.com>

On Thu, 8 Apr 2021 09:25:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
>> 
>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
>> 
>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
>> 
>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
>> 
>> Some missing CHECK_ uses were added.
>> 
>> Testing:
>>   - tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed CHECK on return statement.

src/hotspot/share/interpreter/interpreterRuntime.cpp line 303:

> 301:   // We'd expect to assert that we're only here to quicken bytecodes, but in a multithreaded
> 302:   // program we might have seen an unquick'd bytecode in the interpreter but have another
> 303:   // current quicken the bytecode before we get here.

This should still say 'thread', not 'current'

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

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

From dholmes at openjdk.java.net  Thu Apr  8 13:16:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 8 Apr 2021 13:16:25 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v2]
In-Reply-To: <HK7GdPI2uU37ss48YqxCbuQciSaYNxNAGC-y9cswY7I=.afab90a2-16c2-4d69-95cc-37db04f5968e@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <uDil0eWh2xOe2h7napvVnjoddYii22KkL35xdWQnkaI=.42760eec-aad3-4b52-a0aa-9bae04186126@github.com>
 <HK7GdPI2uU37ss48YqxCbuQciSaYNxNAGC-y9cswY7I=.afab90a2-16c2-4d69-95cc-37db04f5968e@github.com>
Message-ID: <2fThFbhrFCVWjj4KuHJyYtHl47kKuyrBTwkiZFqDQ9c=.2abb180f-479d-4776-aada-6235359d23b9@github.com>

On Thu, 8 Apr 2021 13:00:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed CHECK on return statement.
>
> I think substituting "JavaThread* thread" for "JavaThread* current" is a good change and convention that makes the code more clear, so worth the dull code review and diffs.

Looks like I missed some definitions that aren't included in our test builds but have been found via GHA builds. I will rectify those and update.

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

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

From vlivanov at openjdk.java.net  Thu Apr  8 13:41:20 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 8 Apr 2021 13:41:20 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
 <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
 <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>
 <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
Message-ID: <Pa8IXPBC6slvkKcF-ZcKGojgNsaSKJS7oFoCjXJZp08=.d792e10e-582b-4b9b-a67f-6f62d986c0fe@github.com>

On Thu, 8 Apr 2021 11:52:02 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> Regarding the proposed change itself (`LShiftCntV/RShiftCntV => ShiftCntV`).
>> 
>> Not sure how important it is, but it has an unfortunate change in generated code for right vector shifts on AArch32: instead of sharing the result of index negation at all use sites, negation is performed at every use site now. 
>> 
>> As a consequence, in an auto-vectorized loop it will lead to:
>> - 1 instruction per loop iteration (multiplied by unrolling factor);
>> - no way to hoist the negation of loop invariant index.
>
>> Regarding the proposed change itself (`LShiftCntV/RShiftCntV => ShiftCntV`).
>> 
>> Not sure how important it is, but it has an unfortunate change in generated code for right vector shifts on AArch32: instead of sharing the result of index negation at all use sites, negation is performed at every use site now.
>> 
>> As a consequence, in an auto-vectorized loop it will lead to:
>> 
>> * 1 instruction per loop iteration (multiplied by unrolling factor);
>> * no way to hoist the negation of loop invariant index.
> 
> Thanks for your feedback!
> 
> I have checked the generated code on AArch32 and it's a shame that 'vneg' is at every use point.
> 
> Before:
> 0xf46c8338:   add fp, r7, fp
> 0xf46c833c:   vshl.u16  d9, d9, d8
> 0xf46c8340:   vstr  d9, [fp, #12]
> 0xf46c8344:   vshl.u16  d9, d10, d8
> 0xf46c8348:   vstr  d9, [fp, #20]
> 0xf46c834c:   vshl.u16  d9, d11, d8
> 0xf46c8350:   vstr  d9, [fp, #28]
> 
> After:
> 0xf4aa1328:   add fp, r7, fp
> 0xf4aa132c:   vneg.s8 d13, d8
> 0xf4aa1330:   vshl.u16  d9, d9, d13
> 0xf4aa1334:   vstr  d9, [fp, #12]
> 0xf4aa1338:   vneg.s8 d9, d8
> 0xf4aa133c:   vshl.u16  d9, d10, d9
> 0xf4aa1340:   vstr  d9, [fp, #20]
> 0xf4aa1344:   vneg.s8 d9, d8
> 0xf4aa1348:   vshl.u16  d9, d11, d9
> 0xf4aa134c:   vstr  d9, [fp, #28]  
> 
> I suppose it's more like a trade off that either remaining those two R/LShiftCntV nodes and change AArch64 and X86  to what AArch32 dose, or merging them and accept this defect on AArch32.

`LShiftCntV`/`RShiftCntV` were added specifically for AArch32 and other platforms don't need/benefit from such separation.

Ultimately, I'd like to hear what AArch32 port maintainers think about it, but if there are concerns about performance impact expressed, as an alternative a platform-specific logic can be introduced that adjusts Ideal IR shape for `URShiftV`/`RShiftV` nodes accordingly.

(Not sure whether it is a good trade-off w.r.t. code complexity though.)

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

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

From rcastanedalo at openjdk.java.net  Thu Apr  8 13:53:15 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 8 Apr 2021 13:53:15 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <YwFxUxSk7TMhWe7yK6Aty-C1kE5s1SXwqul3UJZd29o=.9cde72b2-1364-45e6-9314-0225028b1e93@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <M9OcTa-WZ8WQYHiGJZ1hziMDFeGOYs593CweXthMAgc=.3de10d71-924a-4ce9-8215-72f13bd5e638@github.com>
 <YwFxUxSk7TMhWe7yK6Aty-C1kE5s1SXwqul3UJZd29o=.9cde72b2-1364-45e6-9314-0225028b1e93@github.com>
Message-ID: <-OXlf8TYEEY3rOr6V8ae6zR2QtDnjfnso4R_CKA9alU=.5c7de539-587e-47dd-b25d-ef0443e024d6@github.com>

On Thu, 8 Apr 2021 10:46:10 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> src/hotspot/share/opto/lcm.cpp line 1415:
>> 
>>> 1413:       if (dead) {
>>> 1414:         // Remove projections if n is a dead multi-node.
>>> 1415:         for (uint k = j + n->outcnt(); sb->get_node(k)->is_Proj(); k--) {
>> 
>> I don't get this logic. The loop is not executed if sb->get_node(j + n->outcnt()) is not Proj node.
>
> Thanks for reviewing, Vladimir! The intention of this loop is to remove all projections of a multi-node `n` before removing `n` itself (if it has been found to be dead). I indeed have to rethink this code as e.g. the loop can be executed if `n` is not a multi-node but `k` ends up pointing to a projection of another node. I will investigate and come back with a new revision.

On second thought, at the loop entry, the only users of `n` are (unused) projections or else `n` wouldn't be dead. Assuming these projections are scheduled right after `n`, the code should be OK. In any case, I will submit a (hopefully) clearer revision.

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

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

From kvn at openjdk.java.net  Thu Apr  8 15:03:22 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 15:03:22 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v2]
In-Reply-To: <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
Message-ID: <z58RsnFF_iHfLJMOy3Lrk8xSf9HQT_-WFIPBfU85EBo=.0fcd28e8-4a60-4d8c-add6-f98139df9cdc@github.com>

On Mon, 29 Mar 2021 06:28:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
>> 
>> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
>> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
>>   VectorLoadMask (VectorStoreMask vmask)
>> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
>> vectors with the same element size and vector length, it's safe to do the optimization:
>>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
>> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.
>
> Xiaohong Gong 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:
> 
>   8264104: Eliminate unnecessary vector mask conversion during VectorUnbox for floating point VectorMask

Okay.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Thu Apr  8 15:09:14 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 15:09:14 GMT
Subject: RFR: 8264063: Outer Safepoint poll load should not reference the
 head of inner strip mined loop. [v2]
In-Reply-To: <Nc3Sxu7CxRqAIiwEVc-IwSZRik-t-Nv3XcNsc4H05yk=.56b8f222-3052-4247-b900-b0cf8196b2db@github.com>
References: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
 <DN9M2PExByDIxe0fgJgvWxIp6pXBzXgpjBT1dS1MBvM=.742d63e1-22db-4f2d-9167-ccfc4d208313@github.com>
 <Nc3Sxu7CxRqAIiwEVc-IwSZRik-t-Nv3XcNsc4H05yk=.56b8f222-3052-4247-b900-b0cf8196b2db@github.com>
Message-ID: <SzcYlc41IQzShxN5eA8I3bk38DNPRw4IldxhbfZOLbY=.2fdb7692-d401-4a89-88da-6a85df2e90dd@github.com>

On Thu, 8 Apr 2021 12:38:36 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unneeded anymore code in match_fill_loop()
>
> Looks good.

Thank you Vladimir and Roland.

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

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

From kvn at openjdk.java.net  Thu Apr  8 15:09:15 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 15:09:15 GMT
Subject: Integrated: 8264063: Outer Safepoint poll load should not reference
 the head of inner strip mined loop.
In-Reply-To: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
References: <yOQkaOAhg1liOsfy0UjcdhPslt0GZSAcPrHiyplux7M=.f82dee0f-508c-4e9e-a8fe-9abfd913db45@github.com>
Message-ID: <IS8pJ1EZMLWhuFQ2MXoQzdn-p7dEmx_5q5pjttikaN4=.689c3a83-aa5e-4d00-8ece-67cb0bd66b04@github.com>

On Wed, 7 Apr 2021 02:29:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> When loop is "strip mined" polling address load ([parse1.cpp#L2280](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse1.cpp#L2280)) should be cloned together with safepoint node and pinned outside inner loop. Otherwise we have issues like [8263352](https://bugs.openjdk.java.net/browse/JDK-8263352)
> 
> I also remove leftover (unused needs_polling_address_input() method) from  [8220051](https://bugs.openjdk.java.net/browse/JDK-8220051) changes.
> 
> Tested hs-tier1-4

This pull request has now been integrated.

Changeset: 81d35e43
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81d35e43
Stats:     57 lines in 7 files changed: 10 ins; 46 del; 1 mod

8264063: Outer Safepoint poll load should not reference the head of inner strip mined loop.

Reviewed-by: roland, vlivanov

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

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

From kvn at openjdk.java.net  Thu Apr  8 15:20:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 15:20:26 GMT
Subject: RFR: 8264918: [JVMCI] getVtableIndexForInterfaceMethod doesn't
 check that type and method are related
In-Reply-To: <Ry8UFrNx9pAEJMsHvEgmbFALNcvfsaDQeDvkv3koNJ4=.12a43c9f-f133-4f14-9d7a-00aeb1ee63d1@github.com>
References: <Ry8UFrNx9pAEJMsHvEgmbFALNcvfsaDQeDvkv3koNJ4=.12a43c9f-f133-4f14-9d7a-00aeb1ee63d1@github.com>
Message-ID: <BugdR0Zm5BSN2-MhmYXqTlJizEwJxMrkONWEiyztano=.a1c98e94-d12f-4c54-b4e4-aac7982be80d@github.com>

On Thu, 8 Apr 2021 12:49:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> getVtableIndexForInterfaceMethod should reject the case when a resolved class doesn't implement the holder interface.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

Good.
It needs review from Graal team.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Thu Apr  8 17:56:06 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 17:56:06 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <-vl-o8PemGJNrb-7AtTQoNB6YGnhxoA3CVWot_iihlU=.90713355-bd98-4c1c-b253-08d660c1590e@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <C9s8H9XxXGh98TOaXv7uVitMA1M9ZS2aMihwpJx0og4=.81f079d3-1d2c-4ce8-a039-bd2dbfb9b1aa@github.com>
 <-vl-o8PemGJNrb-7AtTQoNB6YGnhxoA3CVWot_iihlU=.90713355-bd98-4c1c-b253-08d660c1590e@github.com>
Message-ID: <gIPBubLRWm99DJY2swvO1oIDJ1VBC9KK-sAvaEnJ_w4=.67444468-ae7f-4dfa-8163-651cb939f23e@github.com>

On Thu, 8 Apr 2021 11:04:00 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Also where is guarantee that all Proj users are in the same block.
>
>> Also where is guarantee that all Proj users are in the same block.
> 
> Isn't this guaranteed by `PhaseCFG::schedule_node_into_block()`?
> 
> https://github.com/openjdk/jdk/blob/ec599da68cac6349e7f28b508d8038c18a4e7347/src/hotspot/share/opto/gcm.cpp#L48-L72
> 
> I will run some tests with extra assertions in `PhaseCFG::verify()` to double-check.

> > Also where is guarantee that all Proj users are in the same block.
> 
> Isn't this guaranteed by `PhaseCFG::schedule_node_into_block()`?
> 
> 
> I will run some tests with extra assertions in `PhaseCFG::verify()` to double-check.

Okay.

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

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

From mdoerr at openjdk.java.net  Thu Apr  8 17:58:14 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 8 Apr 2021 17:58:14 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v8]
In-Reply-To: <D1AFts3YHuey1WHvaOJ8Ikx6oS_1y70l8ZTOxgCmZME=.06f18021-1331-4f33-b7ca-13675200b82c@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <wGgsoSqiZVa79oudP5RIo2yr2VTm8uk-UWdzjTBipms=.ecd37138-e77f-4837-a13c-3541ac5bef5d@github.com>
 <YWKRqgDjXqDMIGR8za0Q7-kktL7W4iqUHnvXpHkreQ4=.305f14d8-2f84-4c1b-8baf-0175e9b65301@github.com>
 <D1AFts3YHuey1WHvaOJ8Ikx6oS_1y70l8ZTOxgCmZME=.06f18021-1331-4f33-b7ca-13675200b82c@github.com>
Message-ID: <3JbTLT-r8ksY7GL4YSdsLKAW7In2c1qCQ9iZvpwemDI=.f6652e1d-6c15-4022-8bbd-25b9e665da48@github.com>

On Mon, 5 Apr 2021 03:10:30 GMT, Kazunori Ogata <ogatak at openjdk.org> wrote:

>> Looks good to me, now. Is the latest version substantially tested? We need to rely on IBMs testing because nobody else has Power10.
>
> @TheRealMDoerr  @CoreyAshford  Thank you for your review.  I think this is now ready to be integrated.
> 
> @TheRealMDoerr  Could you sponsor this pull request?

Yes, I can sponsor it. Thanks for testing.
@CoreyAshford Are all your requests resolved? Do you need more time for additional tests? Please approve once you're fine with it.

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

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

From kvn at openjdk.java.net  Thu Apr  8 18:24:09 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 18:24:09 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <-OXlf8TYEEY3rOr6V8ae6zR2QtDnjfnso4R_CKA9alU=.5c7de539-587e-47dd-b25d-ef0443e024d6@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <M9OcTa-WZ8WQYHiGJZ1hziMDFeGOYs593CweXthMAgc=.3de10d71-924a-4ce9-8215-72f13bd5e638@github.com>
 <YwFxUxSk7TMhWe7yK6Aty-C1kE5s1SXwqul3UJZd29o=.9cde72b2-1364-45e6-9314-0225028b1e93@github.com>
 <-OXlf8TYEEY3rOr6V8ae6zR2QtDnjfnso4R_CKA9alU=.5c7de539-587e-47dd-b25d-ef0443e024d6@github.com>
Message-ID: <UIrzlot2zh1e-5Ox2nq_stIK1ycpF5_OgfN7DnPqHFs=.e4cad8c0-5655-4766-9109-823471b85c8b@github.com>

On Thu, 8 Apr 2021 13:49:56 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thanks for reviewing, Vladimir! The intention of this loop is to remove all projections of a multi-node `n` before removing `n` itself (if it has been found to be dead). I indeed have to rethink this code as e.g. the loop can be executed if `n` is not a multi-node but `k` ends up pointing to a projection of another node. I will investigate and come back with a new revision.
>
> On second thought, at the loop entry, the only users of `n` are (unused) projections or else `n` wouldn't be dead. Assuming these projections are scheduled right after `n`, the code should be OK. In any case, I will submit a (hopefully) clearer revision.

You are right that users will follow `n` but I am not sure that no other nodes were inserted in between users.
I would prefer to see loop code like this:
  for (uint k = new_cnt; k > j; k-- ) {
    Node* user = sb->get_node(k);
    if (user->is_Proj() && user->in(0) == n) {
Or may be record user's indexes into a local array for users in previous loop at lines #1406-1412 and iterate of that loop.
I also noticed wrong code stile in `for()` statements near your change. Please, fix them too.

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

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

From kvn at openjdk.java.net  Thu Apr  8 18:24:10 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 18:24:10 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <lWT-o2dYgMtvRO9NI_Skm9_P_ZxoN0LmKVWfuEdBu48=.d73e95cd-7d21-4353-8b76-3559e3c77316@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <M9OcTa-WZ8WQYHiGJZ1hziMDFeGOYs593CweXthMAgc=.3de10d71-924a-4ce9-8215-72f13bd5e638@github.com>
 <lWT-o2dYgMtvRO9NI_Skm9_P_ZxoN0LmKVWfuEdBu48=.d73e95cd-7d21-4353-8b76-3559e3c77316@github.com>
Message-ID: <IGVt9UQ6BWOcdsOeFPvdZR34u7liOgzFakFD0LAF5C4=.e43896c3-43e1-4ce0-b5cb-5e55be892626@github.com>

On Thu, 8 Apr 2021 10:54:31 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> src/hotspot/share/opto/lcm.cpp line 1419:
>> 
>>> 1417:                  "dead projection should correspond to current node");
>>> 1418:           sb->get_node(k)->disconnect_inputs(C);
>>> 1419:           sb->remove_node(k);
>> 
>> If you remove node here then `j` could be incorrect in `sb->remove_node(j)` at line #1424
>
> `k` should always be greater than `j`, as `sb->get_node(k)` is a projection of `sb->get_node(j)`. Shouldn't this make the removal safe?

Yes, you are right - users should follow.

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

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

From dnsimon at openjdk.java.net  Thu Apr  8 19:00:08 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 8 Apr 2021 19:00:08 GMT
Subject: RFR: 8264918: [JVMCI] getVtableIndexForInterfaceMethod doesn't
 check that type and method are related
In-Reply-To: <BugdR0Zm5BSN2-MhmYXqTlJizEwJxMrkONWEiyztano=.a1c98e94-d12f-4c54-b4e4-aac7982be80d@github.com>
References: <Ry8UFrNx9pAEJMsHvEgmbFALNcvfsaDQeDvkv3koNJ4=.12a43c9f-f133-4f14-9d7a-00aeb1ee63d1@github.com>
 <BugdR0Zm5BSN2-MhmYXqTlJizEwJxMrkONWEiyztano=.a1c98e94-d12f-4c54-b4e4-aac7982be80d@github.com>
Message-ID: <F8QG9sVLUVbJCnzB9tf6nvx9CRjzwusjijZqnY5Ymow=.8d7441be-68f5-484f-9b1e-65d2586c97f6@github.com>

On Thu, 8 Apr 2021 15:17:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> getVtableIndexForInterfaceMethod should reject the case when a resolved class doesn't implement the holder interface.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier4
>
> Good.
> It needs review from Graal team.

The changes look good to me.
How did you discover this problem? If the detail is in https://bugs.openjdk.java.net/browse/JDK-8264918, I can wait until the JBS server comes back up.

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

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

From vlivanov at openjdk.java.net  Thu Apr  8 20:05:09 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 8 Apr 2021 20:05:09 GMT
Subject: RFR: 8264918: [JVMCI] getVtableIndexForInterfaceMethod doesn't
 check that type and method are related
In-Reply-To: <F8QG9sVLUVbJCnzB9tf6nvx9CRjzwusjijZqnY5Ymow=.8d7441be-68f5-484f-9b1e-65d2586c97f6@github.com>
References: <Ry8UFrNx9pAEJMsHvEgmbFALNcvfsaDQeDvkv3koNJ4=.12a43c9f-f133-4f14-9d7a-00aeb1ee63d1@github.com>
 <BugdR0Zm5BSN2-MhmYXqTlJizEwJxMrkONWEiyztano=.a1c98e94-d12f-4c54-b4e4-aac7982be80d@github.com>
 <F8QG9sVLUVbJCnzB9tf6nvx9CRjzwusjijZqnY5Ymow=.8d7441be-68f5-484f-9b1e-65d2586c97f6@github.com>
Message-ID: <DFEA0j0WIFJ9CaVsGYNXFfzEXkJnwOgXsMvoaafntxY=.9964b5f3-1d61-410c-980a-e92752cfb5dd@github.com>

On Thu, 8 Apr 2021 18:57:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Good.
>> It needs review from Graal team.
>
> The changes look good to me.
> How did you discover this problem? If the detail is in https://bugs.openjdk.java.net/browse/JDK-8264918, I can wait until the JBS server comes back up.

Thanks for the reviews, Vladimir and Doug.

It was discovered by a new assert introduced in #3346.

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

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

From cashford at openjdk.java.net  Thu Apr  8 20:40:10 2021
From: cashford at openjdk.java.net (Corey Ashford)
Date: Thu, 8 Apr 2021 20:40:10 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v8]
In-Reply-To: <wGgsoSqiZVa79oudP5RIo2yr2VTm8uk-UWdzjTBipms=.ecd37138-e77f-4837-a13c-3541ac5bef5d@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <wGgsoSqiZVa79oudP5RIo2yr2VTm8uk-UWdzjTBipms=.ecd37138-e77f-4837-a13c-3541ac5bef5d@github.com>
Message-ID: <-yjWFxV8D5j_g3Ke6Eb5cCtNnshSGiqPSHXuhXrJTRg=.9339fd6d-0ec6-473b-aa2c-45c08450144e@github.com>

On Thu, 25 Mar 2021 06:16:53 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:
> 
>   Clean up compute_padding() and fix grammatical errors

Marked as reviewed by cashford (Author).

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

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

From cashford at openjdk.java.net  Thu Apr  8 20:40:11 2021
From: cashford at openjdk.java.net (Corey Ashford)
Date: Thu, 8 Apr 2021 20:40:11 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v8]
In-Reply-To: <3JbTLT-r8ksY7GL4YSdsLKAW7In2c1qCQ9iZvpwemDI=.f6652e1d-6c15-4022-8bbd-25b9e665da48@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <wGgsoSqiZVa79oudP5RIo2yr2VTm8uk-UWdzjTBipms=.ecd37138-e77f-4837-a13c-3541ac5bef5d@github.com>
 <YWKRqgDjXqDMIGR8za0Q7-kktL7W4iqUHnvXpHkreQ4=.305f14d8-2f84-4c1b-8baf-0175e9b65301@github.com>
 <D1AFts3YHuey1WHvaOJ8Ikx6oS_1y70l8ZTOxgCmZME=.06f18021-1331-4f33-b7ca-13675200b82c@github.com>
 <3JbTLT-r8ksY7GL4YSdsLKAW7In2c1qCQ9iZvpwemDI=.f6652e1d-6c15-4022-8bbd-25b9e665da48@github.com>
Message-ID: <Lt9tlwUrR25q8itqMGDvlTjimZfC2bQCqo__SNm06ao=.1d8fa652-f5c6-4f04-9c2d-e37c47186fac@github.com>

On Thu, 8 Apr 2021 17:55:15 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> @TheRealMDoerr  @CoreyAshford  Thank you for your review.  I think this is now ready to be integrated.
>> 
>> @TheRealMDoerr  Could you sponsor this pull request?
>
> Yes, I can sponsor it. Thanks for testing.
> @CoreyAshford Are all your requests resolved? Do you need more time for additional tests? Please approve once you're fine with it.

The only other thing I see is that there are a number of static functions that are defined for accessing fields (e.g. `inv_st_x1`), but aren't actually used yet.  However, I think these are probably ok, since they are not very complex.  So I will approve.

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

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

From dholmes at openjdk.java.net  Thu Apr  8 23:40:18 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 8 Apr 2021 23:40:18 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v2]
In-Reply-To: <HK7GdPI2uU37ss48YqxCbuQciSaYNxNAGC-y9cswY7I=.afab90a2-16c2-4d69-95cc-37db04f5968e@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <uDil0eWh2xOe2h7napvVnjoddYii22KkL35xdWQnkaI=.42760eec-aad3-4b52-a0aa-9bae04186126@github.com>
 <HK7GdPI2uU37ss48YqxCbuQciSaYNxNAGC-y9cswY7I=.afab90a2-16c2-4d69-95cc-37db04f5968e@github.com>
Message-ID: <XOOo-2qnyilM-EkAc52q9WIzD5X-bOBgRfDWeqM0x4A=.2d611022-12c1-4e5a-ba2f-6c4e616e955b@github.com>

On Thu, 8 Apr 2021 12:18:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed CHECK on return statement.
>
> src/hotspot/share/c1/c1_Runtime1.cpp line 180:
> 
>> 178: static void deopt_caller() {
>> 179:   if ( !caller_is_deopted()) {
>> 180:     JavaThread* current = JavaThread::current();
> 
> It looks like both of these functions could be passed JavaThread from the callers.  You could leave this as a cleanup though.  It would eliminate two explicit JavaThread::current calls.

That's a good additional cleanup - thanks. Fixed.

> src/hotspot/share/c1/c1_Runtime1.cpp line 695:
> 
>> 693:   NOT_PRODUCT(_throw_class_cast_exception_count++;)
>> 694:   ResourceMark rm(current);
>> 695: char* message = SharedRuntime::generate_class_cast_message(current, object->klass());
> 
> Is this indentation off?

Fixed. (My emacs can't figure out how to indent when these macros are used. :( )

> src/hotspot/share/interpreter/interpreterRuntime.cpp line 1157:
> 
>> 1155: JRT_END
>> 1156: 
>> 1157: JRT_ENTRY(void, InterpreterRuntime::post_field_access(JavaThread *current, oopDesc* obj,
> 
> nit: JavaThread* current

Fixed

> src/hotspot/share/interpreter/interpreterRuntime.cpp line 1237:
> 
>> 1235: JRT_END
>> 1236: 
>> 1237: JRT_ENTRY(void, InterpreterRuntime::post_method_entry(JavaThread *current))
> 
> Also move the star here and one below.

Fixed all.

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

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

From dholmes at openjdk.java.net  Thu Apr  8 23:40:19 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 8 Apr 2021 23:40:19 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v2]
In-Reply-To: <4IppJ2wYSTxcAKq1z7iSB8fxmmtDSlFimFFSJs9no5g=.29e6b187-a81b-4f9f-afd1-0ce0e9b956f7@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <uDil0eWh2xOe2h7napvVnjoddYii22KkL35xdWQnkaI=.42760eec-aad3-4b52-a0aa-9bae04186126@github.com>
 <4IppJ2wYSTxcAKq1z7iSB8fxmmtDSlFimFFSJs9no5g=.29e6b187-a81b-4f9f-afd1-0ce0e9b956f7@github.com>
Message-ID: <rvlEWGCiMj9E2XP_msnKrrC8bGkO0AXaiEcu4HLt0D8=.b010370d-34df-4369-8634-17fb8e59e85f@github.com>

On Thu, 8 Apr 2021 13:11:36 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed CHECK on return statement.
>
> src/hotspot/share/interpreter/interpreterRuntime.cpp line 303:
> 
>> 301:   // We'd expect to assert that we're only here to quicken bytecodes, but in a multithreaded
>> 302:   // program we might have seen an unquick'd bytecode in the interpreter but have another
>> 303:   // current quicken the bytecode before we get here.
> 
> This should still say 'thread', not 'current'

Well spotted! Fixed.

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

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

From dholmes at openjdk.java.net  Thu Apr  8 23:45:40 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 8 Apr 2021 23:45:40 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v3]
In-Reply-To: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
Message-ID: <BQfspaDVeVovBfIMSecqlEew_HCn_wzo3tiZfT4vtmo=.0f494325-f3e4-469f-b9bb-3b4a3bb04982@github.com>

> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
> 
> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
> 
> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
> 
> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
> 
> Some missing CHECK_ uses were added.
> 
> Testing:
>   - tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with three additional commits since the last revision:

 - Fix minor nits reported by @coleenp and @hseigel
 - @coleenp review comment - Avoid manifesting JavaThread::current() when it can be passed in
 - Added in missed JRT_BLOCK_ENTRY methods in AOT-related jvmci/compilerRuntime.cpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3394/files
  - new: https://git.openjdk.java.net/jdk/pull/3394/files/1adf0fd0..041d7ef5

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

  Stats: 71 lines in 5 files changed: 1 ins; 2 del; 68 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3394.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3394/head:pull/3394

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

From dongbo at openjdk.java.net  Fri Apr  9 01:31:21 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Fri, 9 Apr 2021 01:31:21 GMT
Subject: Integrated: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <uKMipGivuWdeMN-7Zc-CYY3OehrZMV2X0b18N2wOKcM=.2509357d-110b-4e2c-b833-531343251db8@github.com>

On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

This pull request has now been integrated.

Changeset: 77b16739
Author:    Dong Bo <dongbo at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77b16739
Stats:     436 lines in 3 files changed: 436 ins; 0 del; 0 mod

8256245: AArch64: Implement Base64 decoding intrinsic

Reviewed-by: aph, ngasson

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

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

From jiefu at openjdk.java.net  Fri Apr  9 02:26:46 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 9 Apr 2021 02:26:46 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
Message-ID: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>

Hi all,

I'd like to optimize the code-gen for Math.pow(x, 0.5).
And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.

While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.

The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).

Before:
Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms

Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms

After:
Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso

Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms

Testing:
  - tier1~3 on Linux/x64

Thanks,
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680

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

Commit messages:
 - 8264945: Optimize the code-gen for Math.pow(x, 0.5)

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

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

From hshi at openjdk.java.net  Fri Apr  9 03:41:34 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Fri, 9 Apr 2021 03:41:34 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
In-Reply-To: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
Message-ID: <PolMPp_jOihuI7M-E1IatzZms0VNEF7NwsWXTyYSPO8=.a37b2305-c9f4-4af4-ac73-f98ccefea52c@github.com>

On Fri, 9 Apr 2021 02:19:10 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to optimize the code-gen for Math.pow(x, 0.5).
> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
> 
> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
> 
> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
> 
> Before:
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> After:
> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
> 
> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
> 
> Testing:
>   - tier1~3 on Linux/x64
> 
> Thanks,
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680

Does float vector needs same optimization? convert pow to sqrt?

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

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

From jiefu at openjdk.java.net  Fri Apr  9 03:59:15 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 9 Apr 2021 03:59:15 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
In-Reply-To: <PolMPp_jOihuI7M-E1IatzZms0VNEF7NwsWXTyYSPO8=.a37b2305-c9f4-4af4-ac73-f98ccefea52c@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <PolMPp_jOihuI7M-E1IatzZms0VNEF7NwsWXTyYSPO8=.a37b2305-c9f4-4af4-ac73-f98ccefea52c@github.com>
Message-ID: <0LkbLa3f1wADOWAqkzIyDR3w-jlo1-AsUE5fQn_vsXM=.a1c544d6-b849-4a4a-b34b-2640e8f0fe27@github.com>

On Fri, 9 Apr 2021 03:37:52 GMT, Hui Shi <hshi at openjdk.org> wrote:

> Does float vector needs same optimization? convert pow to sqrt?

Thanks @huishi-hs for your review.

The same optimization for the vector api is in progress.
Let's see what the reviewers think of this opt.

Thanks.

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

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

From dlong at openjdk.java.net  Fri Apr  9 05:05:15 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 9 Apr 2021 05:05:15 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
 <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
 <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>
 <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
Message-ID: <NtpUKjhUSFZMfEGXZJWktEhTRZ8wMWUEujhVL-HxWFk=.7743f8c3-4a48-4d08-bf79-963aefb0e255@github.com>

On Thu, 8 Apr 2021 11:52:02 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> Regarding the proposed change itself (`LShiftCntV/RShiftCntV => ShiftCntV`).
>> 
>> Not sure how important it is, but it has an unfortunate change in generated code for right vector shifts on AArch32: instead of sharing the result of index negation at all use sites, negation is performed at every use site now. 
>> 
>> As a consequence, in an auto-vectorized loop it will lead to:
>> - 1 instruction per loop iteration (multiplied by unrolling factor);
>> - no way to hoist the negation of loop invariant index.
>
>> Regarding the proposed change itself (`LShiftCntV/RShiftCntV => ShiftCntV`).
>> 
>> Not sure how important it is, but it has an unfortunate change in generated code for right vector shifts on AArch32: instead of sharing the result of index negation at all use sites, negation is performed at every use site now.
>> 
>> As a consequence, in an auto-vectorized loop it will lead to:
>> 
>> * 1 instruction per loop iteration (multiplied by unrolling factor);
>> * no way to hoist the negation of loop invariant index.
> 
> Thanks for your feedback!
> 
> I have checked the generated code on AArch32 and it's a shame that 'vneg' is at every use point.
> 
> Before:
> 0xf46c8338:   add fp, r7, fp
> 0xf46c833c:   vshl.u16  d9, d9, d8
> 0xf46c8340:   vstr  d9, [fp, #12]
> 0xf46c8344:   vshl.u16  d9, d10, d8
> 0xf46c8348:   vstr  d9, [fp, #20]
> 0xf46c834c:   vshl.u16  d9, d11, d8
> 0xf46c8350:   vstr  d9, [fp, #28]
> 
> After:
> 0xf4aa1328:   add fp, r7, fp
> 0xf4aa132c:   vneg.s8 d13, d8
> 0xf4aa1330:   vshl.u16  d9, d9, d13
> 0xf4aa1334:   vstr  d9, [fp, #12]
> 0xf4aa1338:   vneg.s8 d9, d8
> 0xf4aa133c:   vshl.u16  d9, d10, d9
> 0xf4aa1340:   vstr  d9, [fp, #20]
> 0xf4aa1344:   vneg.s8 d9, d8
> 0xf4aa1348:   vshl.u16  d9, d11, d9
> 0xf4aa134c:   vstr  d9, [fp, #28]  
> 
> I suppose it's more like a trade off that either remaining those two R/LShiftCntV nodes and change AArch64 and X86  to what AArch32 dose, or merging them and accept this defect on AArch32.

@theRealELiu @iwanowww Yes, but I was thinking of the `vshiftcnt` rules and didn't realize the `replicate` rules are virtually identical.  Now that I look again, it appears that aarch64 is already doing the same as x86 (converting the scalar shift count to a vector register, and matching the vector register in the rule).  So why is it that x86 can share the shift register, but aarch64 cannot?  Is it because x86 has combined left- and right-shift into the same rule?

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

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

From dholmes at openjdk.java.net  Fri Apr  9 05:08:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 9 Apr 2021 05:08:37 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v4]
In-Reply-To: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
Message-ID: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>

> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
> 
> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
> 
> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
> 
> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
> 
> Some missing CHECK_ uses were added.
> 
> Testing:
>   - tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix search&replace mistake

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3394/files
  - new: https://git.openjdk.java.net/jdk/pull/3394/files/041d7ef5..9cfc43c2

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

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

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

From shade at openjdk.java.net  Fri Apr  9 06:32:19 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Apr 2021 06:32:19 GMT
Subject: RFR: 8264885: Fix the code style of macro in aarch64_neon_ad.m4
In-Reply-To: <xjU_nkh8X6ObmJAkMYYzBYJ5M3-tNFuOpRCLHof4lwI=.bf86b041-4d22-4223-a606-bc061422e1aa@github.com>
References: <xjU_nkh8X6ObmJAkMYYzBYJ5M3-tNFuOpRCLHof4lwI=.bf86b041-4d22-4223-a606-bc061422e1aa@github.com>
Message-ID: <ab_hSXdZ73_KGr-5Ntt-KV27YJVPKTa51z6oNb_GudQ=.d2096044-ab1f-4ebc-a714-e70f4fa23845@github.com>

On Thu, 8 Apr 2021 08:28:52 GMT, Wang Huang <whuang at openjdk.org> wrote:

> * trivial fix
> * align the comment of macros

Marked as reviewed by shade (Reviewer).

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

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

From whuang at openjdk.java.net  Fri Apr  9 06:32:20 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 9 Apr 2021 06:32:20 GMT
Subject: Integrated: 8264885: Fix the code style of macro in aarch64_neon_ad.m4
In-Reply-To: <xjU_nkh8X6ObmJAkMYYzBYJ5M3-tNFuOpRCLHof4lwI=.bf86b041-4d22-4223-a606-bc061422e1aa@github.com>
References: <xjU_nkh8X6ObmJAkMYYzBYJ5M3-tNFuOpRCLHof4lwI=.bf86b041-4d22-4223-a606-bc061422e1aa@github.com>
Message-ID: <2BpB-3gRVHHOD-FrAM_jnXDzC5jv0MqpSN8UjyKIzxc=.62071fc2-2ec0-4945-ae04-1f0f9815ac5e@github.com>

On Thu, 8 Apr 2021 08:28:52 GMT, Wang Huang <whuang at openjdk.org> wrote:

> * trivial fix
> * align the comment of macros

This pull request has now been integrated.

Changeset: 3e57924a
Author:    Wang Huang <whuang at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3e57924a
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8264885: Fix the code style of macro in aarch64_neon_ad.m4

Reviewed-by: aph, shade

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

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

From thartmann at openjdk.java.net  Fri Apr  9 07:04:24 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 9 Apr 2021 07:04:24 GMT
Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java
 crash in fastdebug C2 with -XX:-UseTLAB [v2]
In-Reply-To: <fOeAmqUkvL4Uh8VJ3sqHNQwch2_btvm_eKC5U8ncZP4=.65d7c4d2-91fd-4ee6-b481-67643ddedbae@github.com>
References: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
 <fOeAmqUkvL4Uh8VJ3sqHNQwch2_btvm_eKC5U8ncZP4=.65d7c4d2-91fd-4ee6-b481-67643ddedbae@github.com>
Message-ID: <-63abPXoiWhcD8FhNKDptvxLVKYCLjKW5WtAGKUVg4U=.9b9367a3-202f-418c-b049-dad477aa6f2f@github.com>

On Wed, 7 Apr 2021 12:09:05 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649
>> 
>> Tier1/2 release /fastdebug passed
>
> Hui Shi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo in test description

Thanks for the details. Your fix looks reasonable to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From stefank at openjdk.java.net  Fri Apr  9 07:09:08 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 9 Apr 2021 07:09:08 GMT
Subject: RFR: 8264358: Don't create invalid oop in method handle tracing
In-Reply-To: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
References: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
Message-ID: <_Nynq1SJulaT-SE9YZZ06M5q9Neg137TssgQL3p1-ag=.3a8d545a-b45e-4282-848b-7340b8145317@github.com>

On Mon, 29 Mar 2021 11:49:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The `mh` field in:
> 
> struct MethodHandleStubArguments {
>   const char* adaptername;
>   oopDesc* mh;
>   intptr_t* saved_regs;
>   intptr_t* entry_sp;
> };
> 
> doesn't always point to a valid object. The `oopDesc*` is then implicitly converted to an `oop` here:
> 
> void trace_method_handle_stub_wrapper(MethodHandleStubArguments* args) {
>   trace_method_handle_stub(args->adaptername,
>                            args->mh,
>                            args->saved_regs,
>                            args->entry_sp);
> }
> 
> This gets caught by my ad-hoc verification code that verifies oops when they are created/used.
> 
> I propose that we don't create an oop until it `mh` is actually used, and it has been checked that the argument should contain a valid oop.  I started with a more elaborate fix that changed the type of `mh` to be `void*`, but then reverted to a more targetted fix to remove the early oopDesc* > oop conversion.
> 
> One thing that I am curious about is this code inside trace_method_handle_stub:
> if (has_mh && oopDesc::is_oop(mh)) {
>   mh->print_on(&ls);
> 
> Delaying the oopDesc* > oop conversion to after the `has_mh` check solves my verification failure, but I wonder if the `oopDesc::is_oop(mh)` call is really needed when we have the `has_mh` check?

Could I get a review for this? It is a super small change.

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

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

From jbhateja at openjdk.java.net  Fri Apr  9 07:30:28 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 9 Apr 2021 07:30:28 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization
Message-ID: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>

Following flow describes object reconstruction for de-optimization:-
1)	PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
2)	During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
3)	De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
4)	During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings. 

By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.

tier1-tier3 regressions are clean with UseAVX=2/3.

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

Commit messages:
 - 8264954: unified handling for VectorMask object re-materialization during de-optimization

Changes: https://git.openjdk.java.net/jdk/pull/3408/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3408&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264954
  Stats: 51 lines in 2 files changed: 29 ins; 15 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3408.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3408/head:pull/3408

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

From eliu at openjdk.java.net  Fri Apr  9 07:35:15 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Fri, 9 Apr 2021 07:35:15 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
 <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
 <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>
 <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
Message-ID: <qT4slWNdIinK-S4ZwPxSdU5sofOnMd-ily3yJV5P8kk=.0e40c338-085b-49ef-a59e-02488a84636b@github.com>

On Thu, 8 Apr 2021 11:52:02 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> Regarding the proposed change itself (`LShiftCntV/RShiftCntV => ShiftCntV`).
>> 
>> Not sure how important it is, but it has an unfortunate change in generated code for right vector shifts on AArch32: instead of sharing the result of index negation at all use sites, negation is performed at every use site now. 
>> 
>> As a consequence, in an auto-vectorized loop it will lead to:
>> - 1 instruction per loop iteration (multiplied by unrolling factor);
>> - no way to hoist the negation of loop invariant index.
>
>> Regarding the proposed change itself (`LShiftCntV/RShiftCntV => ShiftCntV`).
>> 
>> Not sure how important it is, but it has an unfortunate change in generated code for right vector shifts on AArch32: instead of sharing the result of index negation at all use sites, negation is performed at every use site now.
>> 
>> As a consequence, in an auto-vectorized loop it will lead to:
>> 
>> * 1 instruction per loop iteration (multiplied by unrolling factor);
>> * no way to hoist the negation of loop invariant index.
> 
> Thanks for your feedback!
> 
> I have checked the generated code on AArch32 and it's a shame that 'vneg' is at every use point.
> 
> Before:
> 0xf46c8338:   add fp, r7, fp
> 0xf46c833c:   vshl.u16  d9, d9, d8
> 0xf46c8340:   vstr  d9, [fp, #12]
> 0xf46c8344:   vshl.u16  d9, d10, d8
> 0xf46c8348:   vstr  d9, [fp, #20]
> 0xf46c834c:   vshl.u16  d9, d11, d8
> 0xf46c8350:   vstr  d9, [fp, #28]
> 
> After:
> 0xf4aa1328:   add fp, r7, fp
> 0xf4aa132c:   vneg.s8 d13, d8
> 0xf4aa1330:   vshl.u16  d9, d9, d13
> 0xf4aa1334:   vstr  d9, [fp, #12]
> 0xf4aa1338:   vneg.s8 d9, d8
> 0xf4aa133c:   vshl.u16  d9, d10, d9
> 0xf4aa1340:   vstr  d9, [fp, #20]
> 0xf4aa1344:   vneg.s8 d9, d8
> 0xf4aa1348:   vshl.u16  d9, d11, d9
> 0xf4aa134c:   vstr  d9, [fp, #28]  
> 
> I suppose it's more like a trade off that either remaining those two R/LShiftCntV nodes and change AArch64 and X86  to what AArch32 dose, or merging them and accept this defect on AArch32.

> @theRealELiu @iwanowww Yes, but I was thinking of the `vshiftcnt` rules and didn't realize the `replicate` rules are virtually identical. Now that I look again, it appears that aarch64 is already doing the same as x86 (converting the scalar shift count to a vector register, and matching the vector register in the rule). So why is it that x86 can share the shift register, but aarch64 cannot? Is it because x86 has combined left- and right-shift into the same rule?

I suppose x86 has the different kinds of vector shift instructions[1], but AArch64 and AArch32 only have the left one. For this reason, arm should use a "neg-leftshift" pair to implement right shift.

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp#L1234

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

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

From xgong at openjdk.java.net  Fri Apr  9 07:43:50 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 9 Apr 2021 07:43:50 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v3]
In-Reply-To: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
Message-ID: <JS7xbPOO9_TvNFy5zehs4KwZCYuKU8VYbmQ3UdXd708=.35d0b172-a69e-4b96-b356-18ba34d3b77e@github.com>

> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
> 
> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
>   VectorLoadMask (VectorStoreMask vmask)
> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
> vectors with the same element size and vector length, it's safe to do the optimization:
>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to VectorLoadMask and add a VectorMaskCast for the same element size mask casting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3238/files
  - new: https://git.openjdk.java.net/jdk/pull/3238/files/bf5b2028..ce3577ae

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

  Stats: 121 lines in 10 files changed: 92 ins; 27 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3238.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3238/head:pull/3238

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

From xgong at openjdk.java.net  Fri Apr  9 07:46:18 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 9 Apr 2021 07:46:18 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v2]
In-Reply-To: <z58RsnFF_iHfLJMOy3Lrk8xSf9HQT_-WFIPBfU85EBo=.0fcd28e8-4a60-4d8c-add6-f98139df9cdc@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
 <z58RsnFF_iHfLJMOy3Lrk8xSf9HQT_-WFIPBfU85EBo=.0fcd28e8-4a60-4d8c-add6-f98139df9cdc@github.com>
Message-ID: <1rTu7ezhH3o26yoU1RZa9HrJBqshdC6QSPdZwpSlLR4=.4486d157-6ebf-476c-9ffc-64ccd7d8e5b7@github.com>

On Thu, 8 Apr 2021 15:00:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Xiaohong Gong 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:
>> 
>>   8264104: Eliminate unnecessary vector mask conversion during VectorUnbox for floating point VectorMask
>
> Okay.

Hi @iwanowww , I'v updated the codes to use `VectorMaskCast` for vector mask casting with the same element size and vector length. Would you mind having a look again? Thanks!

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

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

From eliu at openjdk.java.net  Fri Apr  9 08:54:22 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Fri, 9 Apr 2021 08:54:22 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <Pa8IXPBC6slvkKcF-ZcKGojgNsaSKJS7oFoCjXJZp08=.d792e10e-582b-4b9b-a67f-6f62d986c0fe@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
 <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
 <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>
 <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
 <Pa8IXPBC6slvkKcF-ZcKGojgNsaSKJS7oFoCjXJZp08=.d792e10e-582b-4b9b-a67f-6f62d986c0fe@github.com>
Message-ID: <BNRC8qkMCzI4Y9vwTNuJD3VdNqoIalOfDtbj172g8h8=.be8bfbd5-4c46-4274-b444-7329bd35d3e0@github.com>

On Thu, 8 Apr 2021 13:37:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> `LShiftCntV`/`RShiftCntV` were added specifically for AArch32 and other platforms don't need/benefit from such separation.

I think AArch64 shared the same problem with AArch32 since it only has left shift instruction as well. I checked the generated code on AArch64 with latest master. Test case is TestCharVect2::test_srav[1].

  0x0000ffffa9106c68:   ldr     q17, [x15, #16]
  0x0000ffffa9106c6c:   add     x14, x10, x14
  0x0000ffffa9106c70:   neg     v18.16b, v16.16b
  0x0000ffffa9106c74:   ushl    v17.8h, v17.8h, v18.8h
  0x0000ffffa9106c78:   str     q17, [x14, #16]
  0x0000ffffa9106c7c:   ldr     q17, [x15, #32]
  0x0000ffffa9106c80:   neg     v18.16b, v16.16b
  0x0000ffffa9106c84:   ushl    v17.8h, v17.8h, v18.8h
  0x0000ffffa9106c88:   str     q17, [x14, #32]
  0x0000ffffa9106c8c:   ldr     q17, [x15, #48]
  0x0000ffffa9106c90:   neg     v18.16b, v16.16b
  0x0000ffffa9106c94:   ushl    v17.8h, v17.8h, v18.8h
  0x0000ffffa9106c98:   str     q17, [x14, #48]
  0x0000ffffa9106c9c:   ldr     q17, [x15, #64]
  0x0000ffffa9106ca0:   neg     v18.16b, v16.16b
  0x0000ffffa9106ca4:   ushl    v17.8h, v17.8h, v18.8h
  0x0000ffffa9106ca8:   str     q17, [x14, #64]
  0x0000ffffa9106cac:   ldr     q17, [x15, #80]
  0x0000ffffa9106cb0:   neg     v18.16b, v16.16b
  0x0000ffffa9106cb4:   ushl    v17.8h, v17.8h, v18.8h

It seems that keeping those two RShiftCntV and LShiftCntV is friendly to AArch32/64 in this case, but AArch64 should changed to what AArch32 dose. @theRealAph 

[1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/codegen/TestCharVect2.java#L1215

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

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

From ogatak at openjdk.java.net  Fri Apr  9 09:10:32 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Fri, 9 Apr 2021 09:10:32 GMT
Subject: Integrated: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10
In-Reply-To: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
Message-ID: <kk-p-FBT0SuUFUYrO4IT-80dy54cRgkkGIaB4BqiULk=.9181c2ea-edf8-4415-8e54-d85c6b585012@github.com>

On Fri, 15 Jan 2021 08:09:56 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

This pull request has now been integrated.

Changeset: f7a6c63a
Author:    Kazunori Ogata <ogatak at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f7a6c63a
Stats:     244 lines in 3 files changed: 240 ins; 0 del; 4 mod

8259822: [PPC64] Support the prefixed instruction format added in POWER10

Reviewed-by: cashford, mdoerr

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

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

From aph at openjdk.java.net  Fri Apr  9 09:29:20 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 9 Apr 2021 09:29:20 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <BNRC8qkMCzI4Y9vwTNuJD3VdNqoIalOfDtbj172g8h8=.be8bfbd5-4c46-4274-b444-7329bd35d3e0@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
 <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
 <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>
 <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
 <Pa8IXPBC6slvkKcF-ZcKGojgNsaSKJS7oFoCjXJZp08=.d792e10e-582b-4b9b-a67f-6f62d986c0fe@github.com>
 <BNRC8qkMCzI4Y9vwTNuJD3VdNqoIalOfDtbj172g8h8=.be8bfbd5-4c46-4274-b444-7329bd35d3e0@github.com>
Message-ID: <xPFPFOV3utkvM9MNkb47RtwRlZ_F-kJOjSjXUHX9U4o=.f67f29ec-6758-4885-b688-ecd838b52e4c@github.com>

On Fri, 9 Apr 2021 08:50:49 GMT, Eric Liu <eliu at openjdk.org> wrote:

> 
> It seems that keeping those two RShiftCntV and LShiftCntV is friendly to AArch32/64 in this case, but AArch64 should changed to what AArch32 dose. @theRealAph

Thanks, but it's been a while since I looked at the vector code. Can you point me to the AArch32 patterns in question, to show me the AArch64 changes needed? Thanks.

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

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

From xgong at openjdk.java.net  Fri Apr  9 10:11:41 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 9 Apr 2021 10:11:41 GMT
Subject: RFR: 8264957: Type::dual_type array is not aligned with enum TYPES
Message-ID: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>

This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.

I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
 Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
 # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.

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

Tested with tier1 and jdk:tier3

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

Commit messages:
 - 8264957: Type::dual_type array is not aligned with enum TYPES

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

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

From vlivanov at openjdk.java.net  Fri Apr  9 10:49:21 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 10:49:21 GMT
Subject: Integrated: 8264918: [JVMCI] getVtableIndexForInterfaceMethod doesn't
 check that type and method are related
In-Reply-To: <Ry8UFrNx9pAEJMsHvEgmbFALNcvfsaDQeDvkv3koNJ4=.12a43c9f-f133-4f14-9d7a-00aeb1ee63d1@github.com>
References: <Ry8UFrNx9pAEJMsHvEgmbFALNcvfsaDQeDvkv3koNJ4=.12a43c9f-f133-4f14-9d7a-00aeb1ee63d1@github.com>
Message-ID: <wl8XKUF6cR3h5CNqoAkgyhZ7kcfUzPxtMXP1yJlv1yg=.257e5bc7-8bee-4ac2-98f4-145de1205cfd@github.com>

On Thu, 8 Apr 2021 12:49:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> getVtableIndexForInterfaceMethod should reject the case when a resolved class doesn't implement the holder interface.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: b3782ead
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b3782ead
Stats:     11 lines in 2 files changed: 6 ins; 0 del; 5 mod

8264918: [JVMCI] getVtableIndexForInterfaceMethod doesn't check that type and method are related

Reviewed-by: kvn

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

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

From eliu at openjdk.java.net  Fri Apr  9 10:51:20 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Fri, 9 Apr 2021 10:51:20 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <xPFPFOV3utkvM9MNkb47RtwRlZ_F-kJOjSjXUHX9U4o=.f67f29ec-6758-4885-b688-ecd838b52e4c@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
 <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
 <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>
 <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
 <Pa8IXPBC6slvkKcF-ZcKGojgNsaSKJS7oFoCjXJZp08=.d792e10e-582b-4b9b-a67f-6f62d986c0fe@github.com>
 <BNRC8qkMCzI4Y9vwTNuJD3VdNqoIalOfDtbj172g8h8=.be8bfbd5-4c46-4274-b444-7329bd35d3e0@github.com>
 <xPFPFOV3utkvM9MNkb47RtwRlZ_F-kJOjSjXUHX9U4o=.f67f29ec-6758-4885-b688-ecd838b52e4c@github.com>
Message-ID: <eMcZEXC5Xs1INJA00CQEOVOw3xxNRZCRXhGB2cNpgxA=.5db63a5b-851d-4059-9637-54f15b1a537c@github.com>

On Fri, 9 Apr 2021 09:26:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > It seems that keeping those two RShiftCntV and LShiftCntV is friendly to AArch32/64 in this case, but AArch64 should changed to what AArch32 dose. @theRealAph
> 
> Thanks, but it's been a while since I looked at the vector code. Can you point me to the AArch32 patterns in question, to show me the AArch64 changes needed? Thanks.

AArch32 combinates 'neg' with 'dup' in RShiftCntV[1], which AArch64  has a single 'dup' only[2] and generates 'neg' before every use sites, e.g. RShiftVB[3]. 

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/arm.ad#L10451
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/aarch64_neon.ad#L5117
[3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/aarch64_neon.ad#L5188

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

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

From jiefu at openjdk.java.net  Fri Apr  9 11:05:25 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 9 Apr 2021 11:05:25 GMT
Subject: RFR: 8264957: Type::dual_type array is not aligned with enum TYPES
In-Reply-To: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
Message-ID: <jVzalT5mDb_J5KMrQduJMHNfhT1vKAdndNuN3jW3d9I=.e8056bc5-56e8-460c-ae89-6160510876bc@github.com>

On Fri, 9 Apr 2021 10:04:10 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.
> 
> I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
>  Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
>  # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
> Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8262355
> 
> Tested with tier1 and jdk:tier3

This sounds reasonable to me.
Thanks.

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

Marked as reviewed by jiefu (Committer).

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

From neliasso at openjdk.java.net  Fri Apr  9 11:08:19 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 9 Apr 2021 11:08:19 GMT
Subject: RFR: 8264358: Don't create invalid oop in method handle tracing
In-Reply-To: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
References: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
Message-ID: <caLSbDz45NJlTDhTgEcTeHz88pMUo3J6F1ptBHdQzbw=.cbce62ef-e28c-424b-b76e-abc8053d3443@github.com>

On Mon, 29 Mar 2021 11:49:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The `mh` field in:
> 
> struct MethodHandleStubArguments {
>   const char* adaptername;
>   oopDesc* mh;
>   intptr_t* saved_regs;
>   intptr_t* entry_sp;
> };
> 
> doesn't always point to a valid object. The `oopDesc*` is then implicitly converted to an `oop` here:
> 
> void trace_method_handle_stub_wrapper(MethodHandleStubArguments* args) {
>   trace_method_handle_stub(args->adaptername,
>                            args->mh,
>                            args->saved_regs,
>                            args->entry_sp);
> }
> 
> This gets caught by my ad-hoc verification code that verifies oops when they are created/used.
> 
> I propose that we don't create an oop until it `mh` is actually used, and it has been checked that the argument should contain a valid oop.  I started with a more elaborate fix that changed the type of `mh` to be `void*`, but then reverted to a more targetted fix to remove the early oopDesc* > oop conversion.
> 
> One thing that I am curious about is this code inside trace_method_handle_stub:
> if (has_mh && oopDesc::is_oop(mh)) {
>   mh->print_on(&ls);
> 
> Delaying the oopDesc* > oop conversion to after the `has_mh` check solves my verification failure, but I wonder if the `oopDesc::is_oop(mh)` call is really needed when we have the `has_mh` check?

Looks good.

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

Marked as reviewed by neliasso (Reviewer).

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

From neliasso at openjdk.java.net  Fri Apr  9 11:13:14 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 9 Apr 2021 11:13:14 GMT
Subject: RFR: 8264871: Dependencies: Miscellaneous cleanups in
 dependencies.cpp
In-Reply-To: <JNlxCwvoJ0E_LJ07OD9a9-R_7ZziN2ib682QMQ3-CkQ=.c88a0e49-934b-401f-8616-32912384a38d@github.com>
References: <JNlxCwvoJ0E_LJ07OD9a9-R_7ZziN2ib682QMQ3-CkQ=.c88a0e49-934b-401f-8616-32912384a38d@github.com>
Message-ID: <wtXFJHBK6v0EflZIlTGN0ZHLtwOc8rCO1pH8uOhZ96k=.77d486db-34a8-4534-98ed-98ad625e6d92@github.com>

On Wed, 7 Apr 2021 21:51:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Miscellaneous cleanups in dependencies.cpp.
> 
> Testing:
> * [x] hs-tier1 - hs-tier4

Looks good.

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

Marked as reviewed by neliasso (Reviewer).

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

From vlivanov at openjdk.java.net  Fri Apr  9 11:18:10 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 11:18:10 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization
In-Reply-To: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
Message-ID: <LpacWY2_bInGhQ23o4LZykJ3FYTveW-agBJ8u3pnS_Y=.6c3a537a-153c-4a44-9d88-123c85b3ab67@github.com>

On Fri, 9 Apr 2021 07:25:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Following flow describes object reconstruction for de-optimization:-
> 1)	PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
> 2)	During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
> 3)	De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
> 4)	During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings. 
> 
> By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.
> 
> tier1-tier3 regressions are clean with UseAVX=2/3.

Very nice! I like your idea to unify mask representation. It simplifies implementation a lot.
But it also means there'll be 2 representations kept alive for masks with debug usages and burns 2 registers (speaking of x86, either 1 predicate + 1 vector registers on AVX512 or 2 vector regsiters on pre-AVX512). Do you see any problems with that? (It can be improved later if it turns out to be a problem in practice.)

src/hotspot/share/opto/vector.cpp line 277:

> 275:         const TypeVect* vt = vec_value->bottom_type()->is_vect();
> 276:         BasicType bt = vt->element_basic_type();
> 277:         vec_value = gvn.transform(VectorStoreMaskNode::make(gvn, vec_value, bt, vt->length()));

`VectorStoreMaskNode::Identity()` already handles `VectorStoreMask (VectorLoadMask bv) elem_size ==> bv` transformation, doesn't it? So, you can just unconditionally instantiate `VectorStoreMaskNode` and let IGVN handle it.

Also, an observation on naming: `VectorLoadMask` and `VectorStoreMask` names are misleading. On the surface, they look like memory nodes, but in fact, are cast nodes (`Vector <-> Mask`). Please, file an RFE to address that eventually.

src/hotspot/share/prims/vectorSupport.cpp line 91:

> 89: void VectorSupport::init_payload_element(typeArrayOop arr, bool is_mask, BasicType elem_bt, int index, address addr) {
> 90:   if (is_mask) {
> 91:     // Masks require special handling: when boxed they are packed and stored in boolean

The comment is still valid. Please, keep it and update with latest details about mask support.

src/hotspot/share/prims/vectorSupport.cpp line 97:

> 95:       case T_LONG:
> 96:       case T_FLOAT:
> 97:       case T_DOUBLE: arr->bool_at_put(index,  (*(jbyte*)addr) != 0); break;

No switch needed anymore. Just leave the  `arr->bool_at_put(index,  (*(jbyte*)addr) != 0)`.
As an option, consider adding an assert (`assert(is_java_type(bt) && bt != T_BOOLEAN)`.

src/hotspot/share/prims/vectorSupport.cpp line 124:

> 122:   // byte array for masks present in both predicated register
> 123:   // or vector registers.
> 124:   int elem_size = is_mask ? 1 : type2aelembytes(elem_bt);

If `elem_bt == T_BOOLEAN` for masks, you can get rid of `is_mask` usages in `VectorSupport::allocate_vector_payload_helper()` and just introduce a special case in `VectorSupport::klass2bt` (as already done for `VectorShuffle`s).

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

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

From vlivanov at openjdk.java.net  Fri Apr  9 11:18:11 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 11:18:11 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization
In-Reply-To: <LpacWY2_bInGhQ23o4LZykJ3FYTveW-agBJ8u3pnS_Y=.6c3a537a-153c-4a44-9d88-123c85b3ab67@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
 <LpacWY2_bInGhQ23o4LZykJ3FYTveW-agBJ8u3pnS_Y=.6c3a537a-153c-4a44-9d88-123c85b3ab67@github.com>
Message-ID: <GCwGkCHJB2NexvBtncsStl7uYtI4NisQmYO_IxSCZL0=.cc7a800b-736c-447a-b132-13f358a43e5d@github.com>

On Fri, 9 Apr 2021 11:04:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Following flow describes object reconstruction for de-optimization:-
>> 1)	PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
>> 2)	During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
>> 3)	De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
>> 4)	During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings. 
>> 
>> By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.
>> 
>> tier1-tier3 regressions are clean with UseAVX=2/3.
>
> src/hotspot/share/prims/vectorSupport.cpp line 97:
> 
>> 95:       case T_LONG:
>> 96:       case T_FLOAT:
>> 97:       case T_DOUBLE: arr->bool_at_put(index,  (*(jbyte*)addr) != 0); break;
> 
> No switch needed anymore. Just leave the  `arr->bool_at_put(index,  (*(jbyte*)addr) != 0)`.
> As an option, consider adding an assert (`assert(is_java_type(bt) && bt != T_BOOLEAN)`.

Actually, I think you can get rid of `is_mask` and just use `elem_bt = T_BOOLEAN` / `bool_at_put(index, (*(jboolean*)addr))`.

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

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

From neliasso at openjdk.java.net  Fri Apr  9 11:45:20 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 9 Apr 2021 11:45:20 GMT
Subject: RFR: 8264872: Dependencies: Migrate to PerfData counters
In-Reply-To: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
References: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
Message-ID: <bdIBsRQhWq3RZ-XSj8zwYjWjLghPhnfUMqPD3JL3RUE=.622503db-5920-44d4-904f-cfc9a51b7bde@github.com>

On Wed, 7 Apr 2021 22:07:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Migrate performance counters on `Dependencies` (`deps_find_witness_*`) to `PerfData`.
> 
> Testing:
> - [x] hs-tier1 - hs-tier2

Looks good.

src/hotspot/share/code/dependencies.cpp line 1212:

> 1210: };
> 1211: 
> 1212: PerfCounter* ClassHierarchyWalker::_perf_find_witness_anywhere_calls_count   = NULL;

Align '=' on all three or skip extra space

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

Marked as reviewed by neliasso (Reviewer).

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

From neliasso at openjdk.java.net  Fri Apr  9 11:49:18 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 9 Apr 2021 11:49:18 GMT
Subject: RFR: 8264957: Type::dual_type array is not aligned with enum TYPES
In-Reply-To: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
Message-ID: <MrhQqQzh4cYExsxzCady4g_pHayXPR0RxElYSDu_nI0=.84823c89-033f-49ac-9fd3-78553c1c16aa@github.com>

On Fri, 9 Apr 2021 10:04:10 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.
> 
> I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
>  Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
>  # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
> Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8262355
> 
> Tested with tier1 and jdk:tier3

Could you please add an assert so that we don't make this mistake again.

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

Changes requested by neliasso (Reviewer).

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

From neliasso at openjdk.java.net  Fri Apr  9 12:00:14 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 9 Apr 2021 12:00:14 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
In-Reply-To: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
Message-ID: <gXBXRTk8yPp-CC8Pe4YbAhB35NvAx1FXj2XD-Ru3iTk=.07c15ed0-b159-4ffe-8b67-c9b06850f4c2@github.com>

On Fri, 9 Apr 2021 02:19:10 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to optimize the code-gen for Math.pow(x, 0.5).
> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
> 
> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
> 
> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
> 
> Before:
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> After:
> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
> 
> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
> 
> Testing:
>   - tier1~3 on Linux/x64
> 
> Thanks,
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680

Looks good.

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

Marked as reviewed by neliasso (Reviewer).

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

From neliasso at openjdk.java.net  Fri Apr  9 12:03:17 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 9 Apr 2021 12:03:17 GMT
Subject: RFR: 8264872: Dependencies: Migrate to PerfData counters
In-Reply-To: <bdIBsRQhWq3RZ-XSj8zwYjWjLghPhnfUMqPD3JL3RUE=.622503db-5920-44d4-904f-cfc9a51b7bde@github.com>
References: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
 <bdIBsRQhWq3RZ-XSj8zwYjWjLghPhnfUMqPD3JL3RUE=.622503db-5920-44d4-904f-cfc9a51b7bde@github.com>
Message-ID: <kfaMxJcghYJaaDCtLDUkqKyhjVeL7I_4f16yaJ8VUSk=.7464c827-2ceb-4553-8d71-0c96c34609d4@github.com>

On Fri, 9 Apr 2021 11:15:54 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Migrate performance counters on `Dependencies` (`deps_find_witness_*`) to `PerfData`.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier2
>
> src/hotspot/share/code/dependencies.cpp line 1212:
> 
>> 1210: };
>> 1211: 
>> 1212: PerfCounter* ClassHierarchyWalker::_perf_find_witness_anywhere_calls_count   = NULL;
> 
> Align '=' on all three or skip extra space

I'm refering to the whitespace before '= NULL'

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

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

From jiefu at openjdk.java.net  Fri Apr  9 12:41:21 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 9 Apr 2021 12:41:21 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
In-Reply-To: <gXBXRTk8yPp-CC8Pe4YbAhB35NvAx1FXj2XD-Ru3iTk=.07c15ed0-b159-4ffe-8b67-c9b06850f4c2@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <gXBXRTk8yPp-CC8Pe4YbAhB35NvAx1FXj2XD-Ru3iTk=.07c15ed0-b159-4ffe-8b67-c9b06850f4c2@github.com>
Message-ID: <8zL5le-W7Hdb86TOlgFEhr_7vb08pEdvQElS0wP1DoE=.b39b7f49-722e-4dfe-a39e-6480f20bc0cf@github.com>

On Fri, 9 Apr 2021 11:57:06 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Looks good.

Thanks @neliasso .

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

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

From hseigel at openjdk.java.net  Fri Apr  9 13:43:18 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 9 Apr 2021 13:43:18 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v4]
In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
Message-ID: <cbc9Uc22IAeP780OcxJHB1U9U1-TBiJhyXIg4ND9TDk=.b149a46f-d8f0-4d56-8033-58f826d68fe2@github.com>

On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
>> 
>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
>> 
>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
>> 
>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
>> 
>> Some missing CHECK_ uses were added.
>> 
>> Testing:
>>   - tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix search&replace mistake

Nice big cleanup!  LGTM
Harold

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

Marked as reviewed by hseigel (Reviewer).

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

From kvn at openjdk.java.net  Fri Apr  9 17:13:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:13:17 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
Message-ID: <FkHY159OY-BZJOj3EpameQ-wQhLgiMyMrrjxu2JZQ8k=.f879e3aa-cdb7-40af-8826-3484a299e914@github.com>

On Fri, 9 Apr 2021 04:32:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Vladimir,
> 
> This looks good to me - I went through all the files.
> 
> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??
> 
> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.
> 
> Thanks,
> David

Thank you, David.
We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`.
I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000

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

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

From kvn at openjdk.java.net  Fri Apr  9 17:42:27 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:42:27 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <FkHY159OY-BZJOj3EpameQ-wQhLgiMyMrrjxu2JZQ8k=.f879e3aa-cdb7-40af-8826-3484a299e914@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
 <FkHY159OY-BZJOj3EpameQ-wQhLgiMyMrrjxu2JZQ8k=.f879e3aa-cdb7-40af-8826-3484a299e914@github.com>
Message-ID: <lC8kkzacpStLbNr77SkZMBiGX6j3frs3zFkSq2OdAXA=.92744f14-5afc-4458-814d-6d61e8644af7@github.com>

On Fri, 9 Apr 2021 17:09:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi Vladimir,
>> 
>> This looks good to me - I went through all the files.
>> 
>> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??
>> 
>> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.
>> 
>> Thanks,
>> David
>
>> Hi Vladimir,
>> 
>> This looks good to me - I went through all the files.
>> 
>> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??
>> 
>> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.
>> 
>> Thanks,
>> David
> 
> Thank you, David.
> We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`.
> I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000

Thank you, Igor Ignatyev, Igor Veresov, Ioi, Aleksey and Andrew for reviews.
I will update changes based on your comments.

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

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

From kvn at openjdk.java.net  Fri Apr  9 17:45:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:45:20 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
Message-ID: <VtF7FHuoaEtc_asbPszw_UIshxBWd7F2CQp0DdzKcZ4=.5f06acbb-7de3-4a23-8602-92a8c31dd8ac@github.com>

On Fri, 9 Apr 2021 02:44:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/compiledIC_x86.cpp line 134:
> 
>> 132: #ifdef ASSERT
>> 133:   CodeBlob *cb = CodeCache::find_blob_unsafe((address) _call);
>> 134:   assert(cb, "sanity");
> 
> Nit: implied boolean - use "cb != NULL"

done

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

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

From kvn at openjdk.java.net  Fri Apr  9 18:23:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:23:26 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
Message-ID: <obMOiA-1TtLCLVF4QQ8u16sMgzCJuhb1h_HpwerXte0=.5f118e88-ab6a-4105-86ab-70d87d2fa439@github.com>

On Fri, 9 Apr 2021 03:03:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/memory/heap.hpp line 174:
> 
>> 172:   bool contains(const void* p) const             { return low() <= p && p < high(); }
>> 173:   bool contains_blob(const CodeBlob* blob) const {
>> 174:     const void* start = (void*)blob;
> 
> start seems redundant now

Done:
   bool contains_blob(const CodeBlob* blob) const {
-    const void* start = (void*)blob;
-    return contains(start);
+    return contains((void*)blob);
   }

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

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

From kvn at openjdk.java.net  Fri Apr  9 18:23:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:23:25 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
Message-ID: <ofskald98fzMljX0LHBVGFyKrGey-skK1S_4gpd07r8=.33f3109a-b923-44a5-bdf1-d99dfbf341fd@github.com>

On Fri, 9 Apr 2021 08:29:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/globalDefinitions_x86.hpp line 73:
> 
>> 71: 
>> 72: #if INCLUDE_JVMCI
>> 73: #define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS (EnableJVMCI)
> 
> Minor nit: can probably drop parentheses here.

done

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

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

From kvn at openjdk.java.net  Fri Apr  9 18:32:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:32:26 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
Message-ID: <Cv3I8B_-bwT0M-Ft2JqNPkxYk-PP46aqJKN23mKYblY=.c94b7bfc-cc2a-4a76-87bd-58a7a24d4fba@github.com>

On Fri, 9 Apr 2021 08:32:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/code/compiledIC.cpp line 715:
> 
>> 713:     tty->print("interpreted");
>> 714:   } else {
>> 715:     tty->print("unknown");
> 
> We can probably split this cleanup into the minor issue, your call. The benefit of separate issue: backportability.

Reverted and filed https://bugs.openjdk.java.net/browse/JDK-8265013

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

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

From kvn at openjdk.java.net  Fri Apr  9 18:36:24 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:36:24 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
Message-ID: <8rFTTlGuCqN9XzBEbaAAf9R-YhTTqe45jv9Gh7F506w=.67e92697-68c4-4657-abb4-803231a9d1a9@github.com>

On Fri, 9 Apr 2021 16:30:41 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/instanceKlass.hpp line 257:
> 
>> 255:     _misc_declares_nonstatic_concrete_methods = 1 << 6,  // directly declares non-static, concrete methods
>> 256:     _misc_has_been_redefined                  = 1 << 7,  // class has been redefined
>> 257:     _unused                                   = 1 << 8,  //
> 
> Any particular reason we don't want to remove this gap?

Less changes. We don't get any benefits from removing it. It is opposite - if we need a new value we will use it without changing following values again.

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

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

From jbhateja at openjdk.java.net  Fri Apr  9 18:56:43 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 9 Apr 2021 18:56:43 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization [v2]
In-Reply-To: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
Message-ID: <wWxk0BA7nACrZwQL872NjdRW3N2xDa4I9ir1u6wlJv8=.fa8842fd-d2ea-4441-9964-ef80f889e8fd@github.com>

> Following flow describes object reconstruction for de-optimization:-
> 1)	PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
> 2)	During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
> 3)	De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
> 4)	During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings. 
> 
> By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.
> 
> tier1-tier3 regressions are clean with UseAVX=2/3.

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8264954: Review comments resolution.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3408/files
  - new: https://git.openjdk.java.net/jdk/pull/3408/files/39312ade..239923fd

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

  Stats: 41 lines in 3 files changed: 2 ins; 13 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3408.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3408/head:pull/3408

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

From jbhateja at openjdk.java.net  Fri Apr  9 18:56:44 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 9 Apr 2021 18:56:44 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization [v2]
In-Reply-To: <LpacWY2_bInGhQ23o4LZykJ3FYTveW-agBJ8u3pnS_Y=.6c3a537a-153c-4a44-9d88-123c85b3ab67@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
 <LpacWY2_bInGhQ23o4LZykJ3FYTveW-agBJ8u3pnS_Y=.6c3a537a-153c-4a44-9d88-123c85b3ab67@github.com>
Message-ID: <beut_DE__dtRMFWMxd8KqjRWQWkqQj5CoBpk3CfbogM=.333f0a3c-84e1-4dd9-a881-2bf32ae5d6c2@github.com>

On Fri, 9 Apr 2021 11:15:14 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8264954: Review comments resolution.
>
> Very nice! I like your idea to unify mask representation. It simplifies implementation a lot.
> But it also means there'll be 2 representations kept alive for masks with debug usages and burns 2 registers (speaking of x86, either 1 predicate + 1 vector registers on AVX512 or 2 vector regsiters on pre-AVX512). Do you see any problems with that? (It can be improved later if it turns out to be a problem in practice.)

Thanks @iwanowww , your comments are resolved.

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

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

From kvn at openjdk.java.net  Fri Apr  9 19:09:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 19:09:25 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
Message-ID: <qc4oegjT9GB5i8kHO9od5ygICGV2g5kv2RP0wUEoW0w=.69e16fc3-aa93-4cd6-9419-91b83914dfd1@github.com>

On Fri, 9 Apr 2021 16:34:58 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1184:
> 
>> 1182:       }
>> 1183:     } else if (jvmci_env()->isa_HotSpotMetaspaceConstantImpl(constant)) {
>> 1184:       if (!_immutable_pic_compilation) {
> 
> All _immutable_pic_compilation mentions can be removed as well. It is true only for AOT compiles produced by Graal. It's never going to be used without AOT.

Done. I removed _immutable_pic_compilation in JVMCI in Hotspot.

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

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

From vlivanov at openjdk.java.net  Fri Apr  9 19:20:28 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 19:20:28 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization [v2]
In-Reply-To: <wWxk0BA7nACrZwQL872NjdRW3N2xDa4I9ir1u6wlJv8=.fa8842fd-d2ea-4441-9964-ef80f889e8fd@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
 <wWxk0BA7nACrZwQL872NjdRW3N2xDa4I9ir1u6wlJv8=.fa8842fd-d2ea-4441-9964-ef80f889e8fd@github.com>
Message-ID: <4jMKSSVNKx5Fh7hek0pT5MMIYAnTjB7y7faOh_L60Pw=.2ce391ed-b29c-4a05-a412-bb3935126b2f@github.com>

On Fri, 9 Apr 2021 18:56:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Following flow describes object reconstruction for de-optimization:-
>> 1)	PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
>> 2)	During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
>> 3)	De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
>> 4)	During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings. 
>> 
>> By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.
>> 
>> tier1-tier3 regressions are clean with UseAVX=2/3.
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264954: Review comments resolution.

Looks good. 

Minor comments follow.

src/hotspot/share/opto/vector.cpp line 270:

> 268:     bool is_mask = is_vector_mask(iklass);
> 269:     if (is_mask) {
> 270:       if (vec_value->Opcode() != Op_VectorStoreMask) {

It's better to do the check against the type of `vec_value`: `VectorStoreMask` produces a vector of booleans  and you can guard `gvn.transform(VectorStoreMaskNode::make(...))` call with `bt != T_BOOLEAN` check instead.

src/hotspot/share/prims/vectorSupport.cpp line 98:

> 96: // and safepoint node always ensures the existence of masks in a boolean array.
> 97: //
> 98: // TODO: revisit when predicate registers are fully supported.

TODO line can be removed now.

src/hotspot/share/prims/vectorSupport.cpp line 102:

> 100: void VectorSupport::init_payload_element(typeArrayOop arr, BasicType elem_bt, int index, address addr) {
> 101:   switch (elem_bt) {
> 102:     case T_BOOLEAN:

Please, use `bool_at_put()` accessor here (just for clarity):
case T_BOOLEAN: arr->bool_at_put(index, *(jboolean*)addr); break;

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

Marked as reviewed by vlivanov (Reviewer).

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

From kvn at openjdk.java.net  Fri Apr  9 19:26:22 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 19:26:22 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
Message-ID: <9RiwxlBLMiREzNvRHU14RQBW33nieUT8-Pmkod_GvtA=.ad51b2f9-f244-4346-8844-9fee39c9aa5b@github.com>

On Fri, 9 Apr 2021 16:54:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/methodCounters.cpp line 77:
> 
>> 75: }
>> 76: 
>> 77: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) {
> 
> MethodCounters::metaspace_pointers_do can be removed altogether (also need to remove the declaration in methodCounter.hpp).

Done.

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

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

From kvn at openjdk.java.net  Fri Apr  9 20:07:16 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 20:07:16 GMT
Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java
 crash in fastdebug C2 with -XX:-UseTLAB [v2]
In-Reply-To: <03pdWufgmVqBPCnhdEvHJnRHkblBlxSiAUsG4Zjpg30=.a17a5efa-8f65-4933-994a-f176f9c45cfb@github.com>
References: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
 <6BN6FtOuI_DuZS8Zpuy2k5xTSu10uXZjrfxMEt6e978=.b5e1ee6b-7dba-413c-9c04-bbf66098b588@github.com>
 <03pdWufgmVqBPCnhdEvHJnRHkblBlxSiAUsG4Zjpg30=.a17a5efa-8f65-4933-994a-f176f9c45cfb@github.com>
Message-ID: <HPz2ncOvLUWL6GObqxjF4off8o3N27qQLy26G04b2vo=.7e7cbd25-3eee-4031-8b54-a4f20e985450@github.com>

On Wed, 7 Apr 2021 12:00:10 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> src/hotspot/share/opto/phaseX.cpp line 1481:
>> 
>>> 1479:   // Smash all inputs to 'old', isolating him completely
>>> 1480:   Node *temp = new Node(1);
>>> 1481:   temp->init_req(0,nn);     // Add a use to nn to prevent him from dying
>> 
>> Just wondering, why do we even need this? Without that code, `remove_dead_node(old)` would kill `nn` as well if it becomes dead.
>
> Thanks for your review!
> 
> Checking code history,  this code is quite old. From comments around, it doesn't want nn removed directly in PhaseIterGVN::subsume_node and leaves optimization to next GVN iteration.
> 
> In my understanding, it might save callers to insert codes checking if "nn" is removed/dead at every subsume_node/replace_node callsite, simplifies implementation.
> 
> 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke                  2007-12-01 00:00:00 +0000 1479)   // Smash all inputs to 'old', isolating him completely
> 2a0815a5 hotspot/src/share/vm/opto/phaseX.cpp (Tobias Hartmann          2014-06-02 08:07:29 +0200 1480)   Node *temp = new Node(1);
> 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke                  2007-12-01 00:00:00 +0000 1481)   temp->init_req(0,nn);     // Add a use to nn to prevent him from dying
> 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke                  2007-12-01 00:00:00 +0000 1482)   remove_dead_node( old );
> 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke                  2007-12-01 00:00:00 +0000 1483)   temp->del_req(0);         // Yank bogus edge

Note `nn` could be new node created during parsing which does not have users yet. that is why we need to keep it

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

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

From kvn at openjdk.java.net  Fri Apr  9 20:32:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 20:32:20 GMT
Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java
 crash in fastdebug C2 with -XX:-UseTLAB [v2]
In-Reply-To: <fOeAmqUkvL4Uh8VJ3sqHNQwch2_btvm_eKC5U8ncZP4=.65d7c4d2-91fd-4ee6-b481-67643ddedbae@github.com>
References: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
 <fOeAmqUkvL4Uh8VJ3sqHNQwch2_btvm_eKC5U8ncZP4=.65d7c4d2-91fd-4ee6-b481-67643ddedbae@github.com>
Message-ID: <arXGotwJZh8pLLEBea2EkBmqqMguVKyOxVQnCYcGDm8=.283c6caf-aa38-486a-af4e-144a3ecd39d2@github.com>

On Wed, 7 Apr 2021 12:09:05 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649
>> 
>> Tier1/2 release /fastdebug passed
>
> Hui Shi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo in test description

I agree with change.

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

Marked as reviewed by kvn (Reviewer).

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

From mchung at openjdk.java.net  Fri Apr  9 20:53:33 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 9 Apr 2021 20:53:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <FhGLyUe8AL5wDoKma5NIDtKP8Rmq2c5a9e4uFF5rRWM=.0aca481d-4791-4021-b9ae-b868ea42f11e@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

I reviewed the module-loader-map and non-hotspot non-AOT tests.

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

Marked as reviewed by mchung (Reviewer).

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

From kvn at openjdk.java.net  Fri Apr  9 21:59:04 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 21:59:04 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <wJ_aASXqtzMg6Fb3Ag8Ia6bjvAzdMIHH_GF5U8OuNEE=.574c044a-9fa1-46a9-8a0d-d1a89ce3fcc3@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

Vladimir Kozlov 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/3398/files
  - new: https://git.openjdk.java.net/jdk/pull/3398/files/6cce0f6c..71a166c1

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

  Stats: 36 lines in 9 files changed: 0 ins; 27 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

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

From iveresov at openjdk.java.net  Fri Apr  9 22:02:33 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 9 Apr 2021 22:02:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5]
In-Reply-To: <wJ_aASXqtzMg6Fb3Ag8Ia6bjvAzdMIHH_GF5U8OuNEE=.574c044a-9fa1-46a9-8a0d-d1a89ce3fcc3@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <wJ_aASXqtzMg6Fb3Ag8Ia6bjvAzdMIHH_GF5U8OuNEE=.574c044a-9fa1-46a9-8a0d-d1a89ce3fcc3@github.com>
Message-ID: <qEoLNtb0E3sj735OChUsZUqhMxWzOslXVpFmPslveQ4=.913b5cdb-e9ca-48c8-8246-371e5d881879@github.com>

On Fri, 9 Apr 2021 21:59:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by iveresov (Reviewer).

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

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

From vlivanov at openjdk.java.net  Fri Apr  9 22:07:21 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 22:07:21 GMT
Subject: RFR: 8264871: Dependencies: Miscellaneous cleanups in
 dependencies.cpp
In-Reply-To: <wtXFJHBK6v0EflZIlTGN0ZHLtwOc8rCO1pH8uOhZ96k=.77d486db-34a8-4534-98ed-98ad625e6d92@github.com>
References: <JNlxCwvoJ0E_LJ07OD9a9-R_7ZziN2ib682QMQ3-CkQ=.c88a0e49-934b-401f-8616-32912384a38d@github.com>
 <wtXFJHBK6v0EflZIlTGN0ZHLtwOc8rCO1pH8uOhZ96k=.77d486db-34a8-4534-98ed-98ad625e6d92@github.com>
Message-ID: <5oO0lwHfxXsX5SQJmylkqnTpPDsYILhwyBP4-BhXWe4=.d87704eb-2551-4a67-867a-22acbfc725fb@github.com>

On Fri, 9 Apr 2021 11:10:33 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Miscellaneous cleanups in dependencies.cpp.
>> 
>> Testing:
>> * [x] hs-tier1 - hs-tier4
>
> Looks good.

Thanks for the review, Nils.

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

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

From vlivanov at openjdk.java.net  Fri Apr  9 22:07:22 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 22:07:22 GMT
Subject: Integrated: 8264871: Dependencies: Miscellaneous cleanups in
 dependencies.cpp
In-Reply-To: <JNlxCwvoJ0E_LJ07OD9a9-R_7ZziN2ib682QMQ3-CkQ=.c88a0e49-934b-401f-8616-32912384a38d@github.com>
References: <JNlxCwvoJ0E_LJ07OD9a9-R_7ZziN2ib682QMQ3-CkQ=.c88a0e49-934b-401f-8616-32912384a38d@github.com>
Message-ID: <jhZ-dPjfGbIcs-NDwZIvjSbr_zX-EiEQgIutPu_MOao=.5fb4ce4f-8a1b-432c-83f4-de7806367017@github.com>

On Wed, 7 Apr 2021 21:51:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Miscellaneous cleanups in dependencies.cpp.
> 
> Testing:
> * [x] hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: 07c8ff47
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/07c8ff47
Stats:     156 lines in 2 files changed: 70 ins; 58 del; 28 mod

8264871: Dependencies: Miscellaneous cleanups in dependencies.cpp

Reviewed-by: neliasso

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

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

From vlivanov at openjdk.java.net  Fri Apr  9 22:14:05 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 22:14:05 GMT
Subject: RFR: 8264872: Dependencies: Migrate to PerfData counters [v2]
In-Reply-To: <bdIBsRQhWq3RZ-XSj8zwYjWjLghPhnfUMqPD3JL3RUE=.622503db-5920-44d4-904f-cfc9a51b7bde@github.com>
References: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
 <bdIBsRQhWq3RZ-XSj8zwYjWjLghPhnfUMqPD3JL3RUE=.622503db-5920-44d4-904f-cfc9a51b7bde@github.com>
Message-ID: <Mnt27kMu2kSEDA1zLQz1rntiKY9crkNpB6vRcELoW_k=.d57b32e9-82ae-494c-a219-699c7aee7635@github.com>

On Fri, 9 Apr 2021 11:42:19 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Vladimir Ivanov 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:
>> 
>>  - Merge branch 'master' into 8264872.perf_counters
>>  - Formatting
>>  - CountingClassHierarchyIterator
>>  - Migrate to PerfData
>>  - Depenencies perf counters
>>  - KlassDepChange::involves_context
>>  - KlassDepChange::_new_type
>>  - Dependencies::is_concrete_method
>>  - Dependencies::verify_method_context
>>  - int -> uint
>
> Looks good.

Thanks for the reviews, Vladimir and Nils.

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

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

From vlivanov at openjdk.java.net  Fri Apr  9 22:14:00 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 22:14:00 GMT
Subject: RFR: 8264872: Dependencies: Migrate to PerfData counters [v2]
In-Reply-To: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
References: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
Message-ID: <qbGFF3qf1Y7nlO-9IOXTDOyvZYIRRPI6a_KZtSqNMz8=.a8bd2da8-5045-48c0-863e-9959745bf6a8@github.com>

> Migrate performance counters on `Dependencies` (`deps_find_witness_*`) to `PerfData`.
> 
> Testing:
> - [x] hs-tier1 - hs-tier2

Vladimir Ivanov 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:

 - Merge branch 'master' into 8264872.perf_counters
 - Formatting
 - CountingClassHierarchyIterator
 - Migrate to PerfData
 - Depenencies perf counters
 - KlassDepChange::involves_context
 - KlassDepChange::_new_type
 - Dependencies::is_concrete_method
 - Dependencies::verify_method_context
 - int -> uint

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3386/files
  - new: https://git.openjdk.java.net/jdk/pull/3386/files/3567e0f0..a810a10e

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

  Stats: 5774 lines in 162 files changed: 4269 ins; 1012 del; 493 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3386.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3386/head:pull/3386

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

From vlivanov at openjdk.java.net  Fri Apr  9 22:19:26 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 22:19:26 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v3]
In-Reply-To: <JS7xbPOO9_TvNFy5zehs4KwZCYuKU8VYbmQ3UdXd708=.35d0b172-a69e-4b96-b356-18ba34d3b77e@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <JS7xbPOO9_TvNFy5zehs4KwZCYuKU8VYbmQ3UdXd708=.35d0b172-a69e-4b96-b356-18ba34d3b77e@github.com>
Message-ID: <Iyitokh4QpeTPElt7Ad2Q_np96M9PGj449rEakcGkc4=.5ac1d23d-4445-43d9-8eca-49463102e7ee@github.com>

On Fri, 9 Apr 2021 07:43:50 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
>> 
>> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
>> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
>>   VectorLoadMask (VectorStoreMask vmask)
>> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
>> vectors with the same element size and vector length, it's safe to do the optimization:
>>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
>> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to VectorLoadMask and add a VectorMaskCast for the same element size mask casting

Overall, looks good.

src/hotspot/share/opto/vectornode.cpp line 1236:

> 1234:         if (is_vector_mask) {
> 1235:           if (in_vt->length_in_bytes() == out_vt->length_in_bytes() &&
> 1236:               Matcher::match_rule_supported(Op_VectorMaskCast)) {

There's `Matcher::match_rule_supported_vector()` specifically for vector nodes.

src/hotspot/share/opto/vectornode.cpp line 1237:

> 1235:           if (in_vt->length_in_bytes() == out_vt->length_in_bytes() &&
> 1236:               Matcher::match_rule_supported(Op_VectorMaskCast)) {
> 1237:             // VectorUnbox (VectorBox vmask) ==> VectorMaskCast (vmask)

It's better to implement it as a 2-step transformation and place it in `VectorLoadMaskNode::Ideal()`:
VectorUnbox (VectorBox vmask) ==> VectorLoadMask (VectorStoreMask vmask) => VectorMaskCast (vmask)

src/hotspot/share/opto/vectornode.hpp line 1247:

> 1245:     assert(type2aelembytes(in_vt->element_basic_type()) == type2aelembytes(vt->element_basic_type()), "element size must match");
> 1246:   }
> 1247: 

FTR there's a way to avoid platform-specific changes (in AD files) if we don't envision any non-trivial conversions to be supported: just disable matching of the node by overriding `Node::ideal_reg()`:
virtual uint ideal_reg() const { return 0; } // not matched in the AD file

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

Marked as reviewed by vlivanov (Reviewer).

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

From vlivanov at openjdk.java.net  Fri Apr  9 22:22:30 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 22:22:30 GMT
Subject: Integrated: 8264872: Dependencies: Migrate to PerfData counters
In-Reply-To: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
References: <6G6POLSvOArZJ0iXvZW2PDx1ps6xJLTnNe20nwcOyVA=.a254144b-8fc9-494d-9655-ba68638469da@github.com>
Message-ID: <HByaTXzaBuHrL6KYj3XfCBW0QlPTNpcSTTvJkz4xd8Y=.9836f993-cb68-4a42-bff9-e707ec27d509@github.com>

On Wed, 7 Apr 2021 22:07:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Migrate performance counters on `Dependencies` (`deps_find_witness_*`) to `PerfData`.
> 
> Testing:
> - [x] hs-tier1 - hs-tier2

This pull request has now been integrated.

Changeset: 76bd313d
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/76bd313d
Stats:     121 lines in 4 files changed: 61 ins; 37 del; 23 mod

8264872: Dependencies: Migrate to PerfData counters

Reviewed-by: kvn, neliasso

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

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

From vlivanov at openjdk.java.net  Fri Apr  9 22:41:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 9 Apr 2021 22:41:42 GMT
Subject: RFR: 8264873: Dependencies: Split ClassHierarchyWalker [v3]
In-Reply-To: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
References: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
Message-ID: <bVpFyU8J3ZXoS5sPj8mX_cRLV4e8y037MqhDGfPKWYM=.00dccd8f-2636-4ab5-b3be-74b53dba2cda@github.com>

> Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into 8264873.cha.split
 - Fix formatting
 - Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder
 - CountingClassHierarchyIterator
 - Migrate to PerfData
 - Depenencies perf counters
 - KlassDepChange::involves_context
 - KlassDepChange::_new_type
 - Dependencies::is_concrete_method
 - Dependencies::verify_method_context
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/76bd313d...e38b995c

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

Changes: https://git.openjdk.java.net/jdk/pull/3387/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3387&range=02
  Stats: 437 lines in 1 file changed: 134 ins; 144 del; 159 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3387.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3387/head:pull/3387

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

From kvn at openjdk.java.net  Fri Apr  9 22:42:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 22:42:20 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
In-Reply-To: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
Message-ID: <l3o653-2gcl0bTV4qfKCwjc7PmEFUyXTVnfPhevU3Yw=.cab7930d-44ea-4a2d-89e4-dcd112a539dc@github.com>

On Fri, 9 Apr 2021 02:19:10 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to optimize the code-gen for Math.pow(x, 0.5).
> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
> 
> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
> 
> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
> 
> Before:
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> After:
> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
> 
> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
> 
> Testing:
>   - tier1~3 on Linux/x64
> 
> Thanks,
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680

Please, verify that result is the same when run with -Xint (Interpreter only) and (-XX:TieredStopAtLevel=1) C1 only. May be they need the same optimization.

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

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

From xliu at openjdk.java.net  Fri Apr  9 23:10:26 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 9 Apr 2021 23:10:26 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
Message-ID: <OCiLTSE4SK7CNHNbIkfQkw_EQIL7xocjzOPhXjp1lew=.19a2e087-60dc-4d74-9c14-dd27fed49f79@github.com>

On Wed, 7 Apr 2021 11:59:28 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).
>> 
>> The change also fixes broken unit tests in the Data module and runs them by default when building.
>> 
>> #### Testing
>> 
>> Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):
>> 
>> - build
>> - open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
>> - import graphs via network (localhost)
>> - expand groups in outline
>> - open a graph
>> - open a clone
>> - zoom in and out
>> - search a node
>> - apply filters
>> - extract a node
>> - show all nodes
>> - select nodes corresponding to a bytecode
>> - view control flow
>> - select nodes corresponding to a basic block
>> - cluster nodes
>> - show satellite view
>> - compute the difference of two graphs
>> - change node text
>> - remove a group
>> - save groups into a file
>> - open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
>> - open a large graph ("After Escape Analysis" in large.xml)
>> 
>> Thanks to Vladimir Ivanov for helping with testing on macOS.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Document how to build and run on a specific JDK
>  - Use lambdas to define runnables
>  - Document latest JDK version supported

Thank you for modernizing IGV. I manage to import this project to IntelliJ. The process is hassle-free!

I also ran using jdk8/jdk11 on macOS. I haven't identified any problem so far.

src/utils/IdealGraphVisualizer/Filter/pom.xml line 93:

> 91:         <profile>
> 92:             <activation>
> 93:                 <jdk>[15,)</jdk>

Does this mean that module `Filter` will depend on external nashorn after jdk15? 

I know that jdk doesn't remove nashorn util jdk15, but does it make sense that IGV always picks up external nashorn. My concern is "javascript" in jdk8/11 may be not well-maintained and leave vulnerability behind.

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

Marked as reviewed by xliu (no project role).

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

From hshi at openjdk.java.net  Fri Apr  9 23:59:29 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Fri, 9 Apr 2021 23:59:29 GMT
Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java
 crash in fastdebug C2 with -XX:-UseTLAB [v2]
In-Reply-To: <-63abPXoiWhcD8FhNKDptvxLVKYCLjKW5WtAGKUVg4U=.9b9367a3-202f-418c-b049-dad477aa6f2f@github.com>
References: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
 <fOeAmqUkvL4Uh8VJ3sqHNQwch2_btvm_eKC5U8ncZP4=.65d7c4d2-91fd-4ee6-b481-67643ddedbae@github.com>
 <-63abPXoiWhcD8FhNKDptvxLVKYCLjKW5WtAGKUVg4U=.9b9367a3-202f-418c-b049-dad477aa6f2f@github.com>
Message-ID: <Nj3BcHYRzMGbgzfjSIbC-lmqR06RYgAtkUXAg46GZjc=.67f74436-134a-485b-94b0-9bc92e93a4ce@github.com>

On Fri, 9 Apr 2021 07:01:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Hui Shi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo in test description
>
> Thanks for the details. Your fix looks reasonable to me.

Thanks! @TobiHartmann @vnkozlov

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

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

From hshi at openjdk.java.net  Sat Apr 10 00:07:34 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Sat, 10 Apr 2021 00:07:34 GMT
Subject: Integrated: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java
 crash in fastdebug C2 with -XX:-UseTLAB
In-Reply-To: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
References: <zFjAUR7NfQGjOjZY4-_lD3OUE4moJJmco4wPDPkKadk=.0bbe3f9d-3ea1-4b9a-939c-af8bad2bbfa5@github.com>
Message-ID: <kw9J_zh1xM_NtFHe5_y2CI1wxlA2LBe1BaIgqjWeiAI=.7fc0f8c4-152d-40eb-a7e5-bdd79cf8886e@github.com>

On Sat, 3 Apr 2021 00:53:54 GMT, Hui Shi <hshi at openjdk.org> wrote:

> Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649
> 
> Tier1/2 release /fastdebug passed

This pull request has now been integrated.

Changeset: 42f4d706
Author:    Hui Shi <hshi at openjdk.org>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42f4d706
Stats:     13 lines in 2 files changed: 12 ins; 0 del; 1 mod

8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB

Reviewed-by: thartmann, kvn

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

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

From dlong at openjdk.java.net  Sat Apr 10 04:05:27 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 10 Apr 2021 04:05:27 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
Message-ID: <R3JbyZHH6VUO_p8svNqSG992mHxBRJhObXokst2aIjM=.f4c8ec54-c2e8-443f-8ace-f58080234fd4@github.com>

On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> LGTM. Just a small nit.

@iklam
I thought the fingerprint code was also used by CDS.

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

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

From iklam at openjdk.java.net  Sat Apr 10 06:08:33 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 10 Apr 2021 06:08:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
Message-ID: <GNwoVCz0KZNh5hN9Fiz9iLgzj1zjMfEXzxqKQP0MOpo=.95df12c1-172e-4465-bc9f-c580a6129147@github.com>

On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> LGTM. Just a small nit.

> @iklam
> I thought the fingerprint code was also used by CDS.

CDS actually uses a different mechanism (CRC of the classfile bytes) to validate that a class has not changed between archive dumping time and runtime. See

https://github.com/openjdk/jdk/blob/5784f6b7f74d0b8081ac107fea172539d57d6020/src/hotspot/share/classfile/systemDictionaryShared.cpp#L1126-L1130

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

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

From ogatak at openjdk.java.net  Sat Apr 10 12:30:33 2021
From: ogatak at openjdk.java.net (Kazunori Ogata)
Date: Sat, 10 Apr 2021 12:30:33 GMT
Subject: RFR: 8259822: [PPC64] Support the prefixed instruction format
 added in POWER10 [v8]
In-Reply-To: <YWKRqgDjXqDMIGR8za0Q7-kktL7W4iqUHnvXpHkreQ4=.305f14d8-2f84-4c1b-8baf-0175e9b65301@github.com>
References: <LzkGwGxKTXWE7yEhDgVEPKyY1sa5kHuQ1AD7182SWqc=.6d4eb523-8af7-41da-8be2-bea235b607dd@github.com>
 <wGgsoSqiZVa79oudP5RIo2yr2VTm8uk-UWdzjTBipms=.ecd37138-e77f-4837-a13c-3541ac5bef5d@github.com>
 <YWKRqgDjXqDMIGR8za0Q7-kktL7W4iqUHnvXpHkreQ4=.305f14d8-2f84-4c1b-8baf-0175e9b65301@github.com>
Message-ID: <Itdzh3VSGDL41c5W9_rL_rcw62yv1NroWjPnYwlwZA8=.9814807c-ae31-4506-8f64-aed8033efc41@github.com>

On Thu, 25 Mar 2021 10:50:45 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Kazunori Ogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up compute_padding() and fix grammatical errors
>
> Looks good to me, now. Is the latest version substantially tested? We need to rely on IBMs testing because nobody else has Power10.

@TheRealMDoerr  Thank you for sponsoring this patch.

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

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

From iignatyev at openjdk.java.net  Sat Apr 10 15:28:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 10 Apr 2021 15:28:35 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler
In-Reply-To: <esTJIrmWXvkRNa7I79JjO0sB4EGlXlVPDhkihL8n-tw=.c996f1e8-8012-41c6-918b-de2b5abc8867@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <esTJIrmWXvkRNa7I79JjO0sB4EGlXlVPDhkihL8n-tw=.c996f1e8-8012-41c6-918b-de2b5abc8867@github.com>
Message-ID: <xgOd5n66UzgCkCKWjyJm36Iny0IgrHhasvw414josho=.59b61cf1-deaa-4e8e-abac-416b72f96b44@github.com>

On Fri, 9 Apr 2021 22:30:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Thankyou, @erikj79, for review. I restored code as you asked.
> For some reasons incremental webrev shows update only in Cdiffs.

none of the full webrevs seem to render even the list of changed files? is it just me?

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

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

From iignatyev at openjdk.java.net  Sat Apr 10 15:41:44 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 10 Apr 2021 15:41:44 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
Message-ID: <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>

On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov 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 three additional commits since the last revision:
> 
>  - Restore Graal Builder image makefile
>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>  - 8264806: Remove the experimental JIT compiler

should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
what about `vm.graal.enabled` `@requires` property?

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

Changes requested by iignatyev (Reviewer).

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

From kvn at openjdk.java.net  Sat Apr 10 16:35:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 10 Apr 2021 16:35:40 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
Message-ID: <NzvHUjqTGTOLJ62arAOL48geIgrsPKOz8JIPgxRU7p8=.148828ec-a76e-448d-ab4c-7b8c68e6e54b@github.com>

On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
> what about `vm.graal.enabled` `@requires` property?

Thank you, @iignatev for looking on changes.

I forgot to mention that `Compiler::isGraalEnabled()` returns always false now. Because 94 tests uses `@requires !vm.graal.enabled` I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests.

Unfortunately changes in `Compiler.java` are listed the last on `Files changed` tab and GitHub has trouble to load these big changes - it takes time to see them. Here `Compiler.java` chnges for review:
diff --git a/test/lib/sun/hotspot/code/Compiler.java b/test/lib/sun/hotspot/code/Compiler.java
index 99122bd93b8..71288ae4482 100644
--- a/test/lib/sun/hotspot/code/Compiler.java
+++ b/test/lib/sun/hotspot/code/Compiler.java
@@ -60,33 +60,10 @@ public class Compiler {
     /**
      * Check if Graal is used as JIT compiler.
      *
-     * Graal is enabled if following conditions are true:
-     * - we are not in Interpreter mode
-     * - UseJVMCICompiler flag is true
-     * - jvmci.Compiler variable is equal to 'graal'
-     * - TieredCompilation is not used or TieredStopAtLevel is greater than 3
-     * No need to check client mode because it set UseJVMCICompiler to false.
-     *
-     * @return true if Graal is used as JIT compiler.
+     * @return false because Graal is removed from JDK.
      */
     public static boolean isGraalEnabled() {
-        Boolean useCompiler = WB.getBooleanVMFlag("UseCompiler");
-        if (useCompiler == null || !useCompiler) {
-            return false;
-        }
-        Boolean useJvmciComp = WB.getBooleanVMFlag("UseJVMCICompiler");
-        if (useJvmciComp == null || !useJvmciComp) {
-            return false;
-        }
-
-        Boolean tieredCompilation = WB.getBooleanVMFlag("TieredCompilation");
-        Long compLevel = WB.getIntxVMFlag("TieredStopAtLevel");
-        // if TieredCompilation is enabled and compilation level is <= 3 then no Graal is used
-        if (tieredCompilation != null && tieredCompilation &&
-            compLevel != null && compLevel <= 3) {
-            return false;
-        }
-        return true;
+        return false;
     }
 ```

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

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

From kvn at openjdk.java.net  Sat Apr 10 16:40:48 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 10 Apr 2021 16:40:48 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
Message-ID: <CJmqOz4xt_BJW73qbUCZU_XnBafv4DRs6M2Yq1MQunQ=.72f19d3a-e2a5-4abe-a2fc-05ec4cd0f774@github.com>

On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Vladimir Kozlov 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 three additional commits since the last revision:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
> what about `vm.graal.enabled` `@requires` property?

@iignatev  If you think that I should clean tests anyway I will file follow up RFE to do that.

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

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

From iignatyev at openjdk.java.net  Sat Apr 10 16:50:46 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 10 Apr 2021 16:50:46 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <CJmqOz4xt_BJW73qbUCZU_XnBafv4DRs6M2Yq1MQunQ=.72f19d3a-e2a5-4abe-a2fc-05ec4cd0f774@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <rONHpijiJ4P-xIEMzIaFdYpnCNdbz7UFP7l4_Ir9JAs=.03bfeb3a-3018-43ad-a12e-7105393823d8@github.com>
 <CJmqOz4xt_BJW73qbUCZU_XnBafv4DRs6M2Yq1MQunQ=.72f19d3a-e2a5-4abe-a2fc-05ec4cd0f774@github.com>
Message-ID: <mLnVgoSLUnIg2T8JXKoBMIysR3WFMUrwfqb99Qlrjt4=.9b96d02a-9f49-42f6-b8aa-83f71c5010f0@github.com>

On Sat, 10 Apr 2021 16:36:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
>> what about `vm.graal.enabled` `@requires` property?
>
> @iignatev  If you think that I should clean tests anyway I will file follow up RFE to do that.

> > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly?
> > what about `vm.graal.enabled` `@requires` property?
> 
> Thank you, @iignatev for looking on changes.
> 
> I forgot to mention that `Compiler::isGraalEnabled()` returns always false now. Because 94 tests uses `@requires !vm.graal.enabled` I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests.

> If you think that I should clean tests anyway I will file follow up RFE to do that.

changing  `Compiler::isGraalEnabled()` to always return false effectively makes these tests unrunnable for GraalVM group (unless they are keep the modified `sun/hotspot/code/Compiler` and/or `requires/VMProps` in their forks). on top of that, I foresee that there will be more tests incompatible w/ Graal yet given it won't be run/tested in OpenJDK, these tests won't be marked and hence will fail when run w/ Graal. so Graal people will have to either do marking themselves (I guess in both upstream and their fork) or maintain a list of inapplicable tests in a format that works best for their setup.

that's to say, I think we should clean up the tests, yet I totally agree there is no need to do it as part of this PR. we can discuss how to do it better for both OpenJDK and GraalVM folks in the follow-up RFE.

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

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

From iignatyev at openjdk.java.net  Sat Apr 10 16:50:46 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 10 Apr 2021 16:50:46 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
Message-ID: <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>

On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov 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 three additional commits since the last revision:
> 
>  - Restore Graal Builder image makefile
>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>  - 8264806: Remove the experimental JIT compiler

Marked as reviewed by iignatyev (Reviewer).

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

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

From kvn at openjdk.java.net  Sat Apr 10 17:44:34 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 10 Apr 2021 17:44:34 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
Message-ID: <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>

On Sat, 10 Apr 2021 16:47:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Vladimir Kozlov 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 three additional commits since the last revision:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> Marked as reviewed by iignatyev (Reviewer).

Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032

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

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

From yyang at openjdk.java.net  Sun Apr 11 05:17:08 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sun, 11 Apr 2021 05:17:08 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <OCiLTSE4SK7CNHNbIkfQkw_EQIL7xocjzOPhXjp1lew=.19a2e087-60dc-4d74-9c14-dd27fed49f79@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
 <OCiLTSE4SK7CNHNbIkfQkw_EQIL7xocjzOPhXjp1lew=.19a2e087-60dc-4d74-9c14-dd27fed49f79@github.com>
Message-ID: <aDhe7612uMWMTNZVMlpFkDxKRsZ1VPu4yiceUBs_mWY=.1d86a3f3-938e-46de-9988-0d75f3081bdc@github.com>

On Fri, 9 Apr 2021 23:07:39 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Document how to build and run on a specific JDK
>>  - Use lambdas to define runnables
>>  - Document latest JDK version supported
>
> Thank you for modernizing IGV. I manage to import this project to IntelliJ. The process is hassle-free!
> 
> I also ran using jdk8/jdk11 on macOS. I haven't identified any problem so far.

Nice work. It works on Windows home pc. ??

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

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

From yyang at openjdk.java.net  Sun Apr 11 05:29:42 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sun, 11 Apr 2021 05:29:42 GMT
Subject: RFR: 8263790: C2: new igv_print_immediately() for debugging
 purpose
In-Reply-To: <48S8jMzp6NlZui6ThjZRTI2Z4NigPrIiNLGkPxCLAds=.6f39378f-f127-4320-8799-f382aa25cc42@github.com>
References: <hBPJff7i-WJJNJjbhv739WqCdPj1rLJ8ant1VOI-Y24=.d3a7db1f-c138-4c4c-b7b9-f0e235932585@github.com>
 <-tNb12ZzWakvHEo3QYkjv43on_YR7ZlgFOIXzkr71ao=.4cd993d6-cc1b-4a8b-8e4b-6479386942c9@github.com>
 <8qcB9THxEItMnobccojmNuJHb9c-9Q6aF0WWkWW1iGo=.b9b233e2-24dc-446a-88ee-8c8e797d2964@github.com>
 <mUekjcBCwS31U8rUGGpfB8HE5EKoATwwNdRvkrRrwUU=.75755d26-f0b2-4621-8dd9-7be195d98e81@github.com>
 <Lqrb_FHDL95IKSsLHHD3KZht7MNoOo7NF4PReeQD9ZQ=.4e145549-e94d-4ae4-91b5-54fe4d6a895f@github.com>
 <48S8jMzp6NlZui6ThjZRTI2Z4NigPrIiNLGkPxCLAds=.6f39378f-f127-4320-8799-f382aa25cc42@github.com>
Message-ID: <iUvAl2dFOW2my3_-TQDRSqnqzUT8nPI-7awdpRb4L1s=.c69ac1a8-5e2c-4acb-aafb-becafe79e60a@github.com>

On Fri, 19 Mar 2021 08:50:25 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Sure, I have uploaded `custom_debug.xml` in JBS issue. I don't find an option like '-version' for idealgraphvisualizer. But from GUI->Preference->About, it shows `Version 1.0 (1.0)`.
>
> Hi @kelthuzadx, I cannot reproduce the problem running the latest IGV on JDK 8 and linux-x64 either.
> 
> Note that IGV is designed to tolerate XML files without closing `</graphDocument>` and `</group>` tags. The parser does not use an error handler, which leads to ignoring all parsing errors [1], and on top of that certain parsing exceptions are ignored:
> 
> https://github.com/openjdk/jdk/blob/d24e4cfef36026b781906a9e0c5cf519eb72696e/src/utils/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/Parser.java#L531-L539
> 
> [1] https://docs.oracle.com/javase/8/docs/api/org/xml/sax/XMLReader.html#setErrorHandler-org.xml.sax.ErrorHandler-
> 
> Perhaps the problem you report should be addressed by making sure IGV also accepts missing closing `</graphDocument>` and `</group>` tags in your case? As you mention, this is a common debugging scenario.

The latest IGV can not open incomplete XML as well.  When I changed the system locale to en-US, it works for incomplete XML as expected. I guess this is yet another an i18n problem. As @robcasloz pointed out, the parser does not use an error handler, which leads to ignoring all parsing errors, and on top of that certain parsing exceptions are ignored
 try { 
     XMLReader reader = createReader(); 
     reader.setContentHandler(new XMLParser(xmlDocument, monitor)); 
     reader.parse(new InputSource(Channels.newInputStream(channel))); 
 } catch (SAXException ex) { 
     if (!(ex instanceof SAXParseException) || !"XML document structures must start and end within the same entity.".equals(ex.getMessage())) { 
         throw new IOException(ex); 
     } 
 } 
In the catch clause, ex.getMessage() compares with ASCII characters, but ex.getMessage()gets characters that corresponding to their system locale settings. To support non-English system locale settings(if needed), we could code something like this:
     if (!(ex instanceof SAXParseException) || !"XML document structures must start and end within the same entity.".equals(disable_i18n(ex.getMessage())))
-------
![fig1](https://user-images.githubusercontent.com/5010047/114293326-c0474e00-9ac7-11eb-983b-22e60bceea6e.png)
![FIG2](https://user-images.githubusercontent.com/5010047/114293327-c2111180-9ac7-11eb-94c6-4e9aac373f74.png)

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

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

From dnsimon at openjdk.java.net  Sun Apr 11 10:28:36 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Sun, 11 Apr 2021 10:28:36 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
Message-ID: <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>

On Sat, 10 Apr 2021 17:41:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Marked as reviewed by iignatyev (Reviewer).
>
> Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032

We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important.

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

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

From yyang at openjdk.java.net  Mon Apr 12 03:34:05 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 12 Apr 2021 03:34:05 GMT
Subject: RFR: 8264972: Unused TypeFunc declared in OptoRuntime
Message-ID: <hMnyMvn4a315EKYg4RHpWQ7NQtuJQzq8i5lTiPjcGs8=.cd3b60f3-38d6-48d4-95e5-96e1f40242b0@github.com>

When investigating some C2 related stuff, I noticed that some TypeFunc are declared in OptoRuntime since JDK6:

  // leaf on stack replacement interpreter accessor types
  static const TypeFunc* fetch_int_Type();
  static const TypeFunc* fetch_long_Type();
  static const TypeFunc* fetch_float_Type();
  static const TypeFunc* fetch_double_Type();
  static const TypeFunc* fetch_oop_Type();
  static const TypeFunc* fetch_monitor_Type();

They are not used nor implemented. It looks like we can remove them(I'm curious about their stories/history.)

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

Commit messages:
 - remove unused TypeFunc

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

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

From thartmann at openjdk.java.net  Mon Apr 12 06:40:04 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 12 Apr 2021 06:40:04 GMT
Subject: RFR: 8264358: Don't create invalid oop in method handle tracing
In-Reply-To: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
References: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
Message-ID: <2s-ZjC47FeWGiEGlBlI5TwcVtL1tLXsmJGps3vTYYLE=.a06c1d2e-adc1-4bd4-888f-81657074f723@github.com>

On Mon, 29 Mar 2021 11:49:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The `mh` field in:
> 
> struct MethodHandleStubArguments {
>   const char* adaptername;
>   oopDesc* mh;
>   intptr_t* saved_regs;
>   intptr_t* entry_sp;
> };
> 
> doesn't always point to a valid object. The `oopDesc*` is then implicitly converted to an `oop` here:
> 
> void trace_method_handle_stub_wrapper(MethodHandleStubArguments* args) {
>   trace_method_handle_stub(args->adaptername,
>                            args->mh,
>                            args->saved_regs,
>                            args->entry_sp);
> }
> 
> This gets caught by my ad-hoc verification code that verifies oops when they are created/used.
> 
> I propose that we don't create an oop until it `mh` is actually used, and it has been checked that the argument should contain a valid oop.  I started with a more elaborate fix that changed the type of `mh` to be `void*`, but then reverted to a more targetted fix to remove the early oopDesc* > oop conversion.
> 
> One thing that I am curious about is this code inside trace_method_handle_stub:
> if (has_mh && oopDesc::is_oop(mh)) {
>   mh->print_on(&ls);
> 
> Delaying the oopDesc* > oop conversion to after the `has_mh` check solves my verification failure, but I wonder if the `oopDesc::is_oop(mh)` call is really needed when we have the `has_mh` check?

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

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

From stefank at openjdk.java.net  Mon Apr 12 06:40:05 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 12 Apr 2021 06:40:05 GMT
Subject: RFR: 8264358: Don't create invalid oop in method handle tracing
In-Reply-To: <caLSbDz45NJlTDhTgEcTeHz88pMUo3J6F1ptBHdQzbw=.cbce62ef-e28c-424b-b76e-abc8053d3443@github.com>
References: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
 <caLSbDz45NJlTDhTgEcTeHz88pMUo3J6F1ptBHdQzbw=.cbce62ef-e28c-424b-b76e-abc8053d3443@github.com>
Message-ID: <rrU1PSh2qYssA9w9srGJ7NT24Mg0M6KWA-CMDmzs4jw=.3eb154ce-6600-41f0-8cfd-3f5ab2629447@github.com>

On Fri, 9 Apr 2021 11:05:34 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> The `mh` field in:
>> 
>> struct MethodHandleStubArguments {
>>   const char* adaptername;
>>   oopDesc* mh;
>>   intptr_t* saved_regs;
>>   intptr_t* entry_sp;
>> };
>> 
>> doesn't always point to a valid object. The `oopDesc*` is then implicitly converted to an `oop` here:
>> 
>> void trace_method_handle_stub_wrapper(MethodHandleStubArguments* args) {
>>   trace_method_handle_stub(args->adaptername,
>>                            args->mh,
>>                            args->saved_regs,
>>                            args->entry_sp);
>> }
>> 
>> This gets caught by my ad-hoc verification code that verifies oops when they are created/used.
>> 
>> I propose that we don't create an oop until it `mh` is actually used, and it has been checked that the argument should contain a valid oop.  I started with a more elaborate fix that changed the type of `mh` to be `void*`, but then reverted to a more targetted fix to remove the early oopDesc* > oop conversion.
>> 
>> One thing that I am curious about is this code inside trace_method_handle_stub:
>> if (has_mh && oopDesc::is_oop(mh)) {
>>   mh->print_on(&ls);
>> 
>> Delaying the oopDesc* > oop conversion to after the `has_mh` check solves my verification failure, but I wonder if the `oopDesc::is_oop(mh)` call is really needed when we have the `has_mh` check?
>
> Looks good.

Thanks, @neliasso.

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

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

From stefank at openjdk.java.net  Mon Apr 12 06:43:31 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 12 Apr 2021 06:43:31 GMT
Subject: Integrated: 8264358: Don't create invalid oop in method handle tracing
In-Reply-To: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
References: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
Message-ID: <zVvWCLzUwrui6TgaccltLIOZo7N7gPaKlFsRJihFrGY=.04570a0d-a9d0-4ac3-b027-4b9f74194ce1@github.com>

On Mon, 29 Mar 2021 11:49:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The `mh` field in:
> 
> struct MethodHandleStubArguments {
>   const char* adaptername;
>   oopDesc* mh;
>   intptr_t* saved_regs;
>   intptr_t* entry_sp;
> };
> 
> doesn't always point to a valid object. The `oopDesc*` is then implicitly converted to an `oop` here:
> 
> void trace_method_handle_stub_wrapper(MethodHandleStubArguments* args) {
>   trace_method_handle_stub(args->adaptername,
>                            args->mh,
>                            args->saved_regs,
>                            args->entry_sp);
> }
> 
> This gets caught by my ad-hoc verification code that verifies oops when they are created/used.
> 
> I propose that we don't create an oop until it `mh` is actually used, and it has been checked that the argument should contain a valid oop.  I started with a more elaborate fix that changed the type of `mh` to be `void*`, but then reverted to a more targetted fix to remove the early oopDesc* > oop conversion.
> 
> One thing that I am curious about is this code inside trace_method_handle_stub:
> if (has_mh && oopDesc::is_oop(mh)) {
>   mh->print_on(&ls);
> 
> Delaying the oopDesc* > oop conversion to after the `has_mh` check solves my verification failure, but I wonder if the `oopDesc::is_oop(mh)` call is really needed when we have the `has_mh` check?

This pull request has now been integrated.

Changeset: b1ebf822
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b1ebf822
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8264358: Don't create invalid oop in method handle tracing

Reviewed-by: neliasso, thartmann

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

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

From jiefu at tencent.com  Mon Apr 12 06:51:27 2021
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Mon, 12 Apr 2021 06:51:27 +0000
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}
Message-ID: <F8E82625-69A8-44BD-8BA8-CE77377895C2@tencent.com>

Hi all,

I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
```
Math.pow(-0.0, 0.5) = 0.0
Math.sqrt(-0.0) = -0.0

Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
```

The reason is that both of pow and sqrt have special rules for these computations.
For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.

I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).

So why Java creates conflict special rules for them?
Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?

I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L644
[2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L385
[3] https://github.com/openjdk/jdk/pull/3404/

From thartmann at openjdk.java.net  Mon Apr 12 06:52:17 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 12 Apr 2021 06:52:17 GMT
Subject: RFR: 8264873: Dependencies: Split ClassHierarchyWalker [v3]
In-Reply-To: <bVpFyU8J3ZXoS5sPj8mX_cRLV4e8y037MqhDGfPKWYM=.00dccd8f-2636-4ab5-b3be-74b53dba2cda@github.com>
References: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
 <bVpFyU8J3ZXoS5sPj8mX_cRLV4e8y037MqhDGfPKWYM=.00dccd8f-2636-4ab5-b3be-74b53dba2cda@github.com>
Message-ID: <ozkpwsOhV3D42fdFZHrtOuw-1qCTCD0_ND-Wrt7opZk=.07cbaad2-69ff-4467-ad21-f5cb822d3ff3@github.com>

On Fri, 9 Apr 2021 22:41:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier4
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into 8264873.cha.split
>  - Fix formatting
>  - Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder
>  - CountingClassHierarchyIterator
>  - Migrate to PerfData
>  - Depenencies perf counters
>  - KlassDepChange::involves_context
>  - KlassDepChange::_new_type
>  - Dependencies::is_concrete_method
>  - Dependencies::verify_method_context
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/76bd313d...e38b995c

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From thartmann at openjdk.java.net  Mon Apr 12 07:03:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 12 Apr 2021 07:03:39 GMT
Subject: RFR: 8264972: Unused TypeFunc declared in OptoRuntime
In-Reply-To: <hMnyMvn4a315EKYg4RHpWQ7NQtuJQzq8i5lTiPjcGs8=.cd3b60f3-38d6-48d4-95e5-96e1f40242b0@github.com>
References: <hMnyMvn4a315EKYg4RHpWQ7NQtuJQzq8i5lTiPjcGs8=.cd3b60f3-38d6-48d4-95e5-96e1f40242b0@github.com>
Message-ID: <Qaj_Ylj5t4mZCT5xfV9yiU1UogkGQvR64szgJaqzrEQ=.25135e9b-6fcb-4ad9-b3e4-36ed37bc1567@github.com>

On Mon, 12 Apr 2021 03:18:33 GMT, Yi Yang <yyang at openjdk.org> wrote:

> When investigating some C2 related stuff, I noticed that some TypeFunc are declared in OptoRuntime since JDK6:
> 
>   // leaf on stack replacement interpreter accessor types
>   static const TypeFunc* fetch_int_Type();
>   static const TypeFunc* fetch_long_Type();
>   static const TypeFunc* fetch_float_Type();
>   static const TypeFunc* fetch_double_Type();
>   static const TypeFunc* fetch_oop_Type();
>   static const TypeFunc* fetch_monitor_Type();
> 
> They are neither used nor implemented. It looks like we can remove them(I'm curious about their stories/history.)

Good catch. Looks good and trivial to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From jiefu at openjdk.java.net  Mon Apr 12 07:06:38 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 12 Apr 2021 07:06:38 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
In-Reply-To: <l3o653-2gcl0bTV4qfKCwjc7PmEFUyXTVnfPhevU3Yw=.cab7930d-44ea-4a2d-89e4-dcd112a539dc@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <l3o653-2gcl0bTV4qfKCwjc7PmEFUyXTVnfPhevU3Yw=.cab7930d-44ea-4a2d-89e4-dcd112a539dc@github.com>
Message-ID: <pIjDROLMueFI9Jtq0WG_Sq0oyvKFFHYpZCPnfzvGvUE=.911f0103-ad5b-48ba-8108-75ff17f94832@github.com>

On Fri, 9 Apr 2021 22:39:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> I'd like to optimize the code-gen for Math.pow(x, 0.5).
>> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
>> 
>> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
>> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
>> 
>> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
>> 
>> Before:
>> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
>> 
>> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
>> 
>> After:
>> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
>> 
>> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
>> 
>> Testing:
>>   - tier1~3 on Linux/x64
>> 
>> Thanks,
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680
>
> Please, verify that result is the same when run with -Xint (Interpreter only) and (-XX:TieredStopAtLevel=1) C1 only. May be they need the same optimization.

Hi @vnkozlov @neliasso and @huishi-hs , 

Thanks for your review and comments.
While I was implementing the opt for C1 and interpreter, I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values for x={-0.0, Double.NEGATIVE_INFINITY} [1].
Let's hold on this issue until we have a conclusion about that question.
Thanks.

[1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076195.html

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

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

From xgong at openjdk.java.net  Mon Apr 12 07:06:34 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 12 Apr 2021 07:06:34 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v3]
In-Reply-To: <Iyitokh4QpeTPElt7Ad2Q_np96M9PGj449rEakcGkc4=.5ac1d23d-4445-43d9-8eca-49463102e7ee@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <JS7xbPOO9_TvNFy5zehs4KwZCYuKU8VYbmQ3UdXd708=.35d0b172-a69e-4b96-b356-18ba34d3b77e@github.com>
 <Iyitokh4QpeTPElt7Ad2Q_np96M9PGj449rEakcGkc4=.5ac1d23d-4445-43d9-8eca-49463102e7ee@github.com>
Message-ID: <aksQ5VA2DukLD2B4SNkxMxmEJBQS7VG-JnZnCWaF9m8=.6a54ce2f-7c88-4d55-b125-fcefa27533c5@github.com>

On Fri, 9 Apr 2021 21:52:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to VectorLoadMask and add a VectorMaskCast for the same element size mask casting
>
> src/hotspot/share/opto/vectornode.cpp line 1236:
> 
>> 1234:         if (is_vector_mask) {
>> 1235:           if (in_vt->length_in_bytes() == out_vt->length_in_bytes() &&
>> 1236:               Matcher::match_rule_supported(Op_VectorMaskCast)) {
> 
> There's `Matcher::match_rule_supported_vector()` specifically for vector nodes.

OK, I will use this instead. Thanks!

> src/hotspot/share/opto/vectornode.cpp line 1237:
> 
>> 1235:           if (in_vt->length_in_bytes() == out_vt->length_in_bytes() &&
>> 1236:               Matcher::match_rule_supported(Op_VectorMaskCast)) {
>> 1237:             // VectorUnbox (VectorBox vmask) ==> VectorMaskCast (vmask)
> 
> It's better to implement it as a 2-step transformation and place it in `VectorLoadMaskNode::Ideal()`:
> VectorUnbox (VectorBox vmask) ==> VectorLoadMask (VectorStoreMask vmask) => VectorMaskCast (vmask)

Thanks for your comments. Yes, theoretically it's better to place it in `VectorLoadMaskNode::Ideal()`. Unfortunately, we met an issue that is related to optimization for `VectorStoreMask`. Considering the following case:
   LoadVector                                              LoadVector
           |                                                    |
   VectorLoadMask  (double)                          VectorLoadMask (double)
               |                                               |
           VectorUnbox   (long)          ==>           VectorStoreMask  (double)
                                                               |
                                                      VectorLoadMask  (long)
This case loads the masking values for a double type, and does a bitwise `and` operation. Since the type is mismatched, the compiler will try to do `VectorUnbox (VectorBox vmask) ==> VectorLoadMask (VectorStoreMask vmask)`. However, since there is the transformation `VectorStoreMask (VectorLoadMask value)  ==> value`, the above `VectorStoreMaskNode` will be optimized out. The final graph looks like:

   LoadVector                                                  LoadVector
          |                                                      /      \
        VectorLoadMask  (double)                               /         \
              |                      ==>     VectorLoadMask (double)      \
         VectorStoreMask (double)                                   VectorLoadMask (long)
                   |
            VectorLoadMask (long)
Since the two `VectorLoadMaskNode` have different element type, the GVN cannot optimize out one. So finally there will be two similar  `VectorLoadMaskNode`s. That's also why I override the `cmp/hash` for `VectorLoadMaskNode` in the first version.

So I prefer to add `VectorUnbox (VectorBox vmask) ==> VectorMaskCast (vmask)` directly.

> src/hotspot/share/opto/vectornode.hpp line 1247:
> 
>> 1245:     assert(type2aelembytes(in_vt->element_basic_type()) == type2aelembytes(vt->element_basic_type()), "element size must match");
>> 1246:   }
>> 1247: 
> 
> FTR there's a way to avoid platform-specific changes (in AD files) if we don't envision any non-trivial conversions to be supported: just disable matching of the node by overriding `Node::ideal_reg()`:
> virtual uint ideal_reg() const { return 0; } // not matched in the AD file

Good idea, I will try this way. Thanks!

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

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

From yyang at openjdk.java.net  Mon Apr 12 07:09:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 12 Apr 2021 07:09:01 GMT
Subject: RFR: 8264972: Unused TypeFunc declared in OptoRuntime
In-Reply-To: <Qaj_Ylj5t4mZCT5xfV9yiU1UogkGQvR64szgJaqzrEQ=.25135e9b-6fcb-4ad9-b3e4-36ed37bc1567@github.com>
References: <hMnyMvn4a315EKYg4RHpWQ7NQtuJQzq8i5lTiPjcGs8=.cd3b60f3-38d6-48d4-95e5-96e1f40242b0@github.com>
 <Qaj_Ylj5t4mZCT5xfV9yiU1UogkGQvR64szgJaqzrEQ=.25135e9b-6fcb-4ad9-b3e4-36ed37bc1567@github.com>
Message-ID: <WGc3uKJXG_74EEFeFi8B7tQlDtmDe3jPxtopnrAflkc=.6f2c44ef-1790-478e-9d0c-90e5b36443f9@github.com>

On Mon, 12 Apr 2021 06:58:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> When investigating some C2 related stuff, I noticed that some TypeFunc are declared in OptoRuntime since JDK6:
>> 
>>   // leaf on stack replacement interpreter accessor types
>>   static const TypeFunc* fetch_int_Type();
>>   static const TypeFunc* fetch_long_Type();
>>   static const TypeFunc* fetch_float_Type();
>>   static const TypeFunc* fetch_double_Type();
>>   static const TypeFunc* fetch_oop_Type();
>>   static const TypeFunc* fetch_monitor_Type();
>> 
>> They are neither used nor implemented. It looks like we can remove them(I'm curious about their stories/history.)
>
> Good catch. Looks good and trivial to me.

Thank you Tobias. It's trivial indeed.

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

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

From stefank at openjdk.java.net  Mon Apr 12 07:49:10 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 12 Apr 2021 07:49:10 GMT
Subject: RFR: 8264358: Don't create invalid oop in method handle tracing
In-Reply-To: <2s-ZjC47FeWGiEGlBlI5TwcVtL1tLXsmJGps3vTYYLE=.a06c1d2e-adc1-4bd4-888f-81657074f723@github.com>
References: <rIn0RBBp0JZCrIcK6BE9GBS9ZW39aZbhtl1Y-BGa8sY=.4532ede3-2ee2-4482-96cc-68060cf69fac@github.com>
 <2s-ZjC47FeWGiEGlBlI5TwcVtL1tLXsmJGps3vTYYLE=.a06c1d2e-adc1-4bd4-888f-81657074f723@github.com>
Message-ID: <eX0q4uU29Sg4Tcxb3rCqAVUw35wsgc8VEb7y2pOxM_o=.4864d850-0353-44a5-8f21-51535fda96a2@github.com>

On Mon, 12 Apr 2021 06:37:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The `mh` field in:
>> 
>> struct MethodHandleStubArguments {
>>   const char* adaptername;
>>   oopDesc* mh;
>>   intptr_t* saved_regs;
>>   intptr_t* entry_sp;
>> };
>> 
>> doesn't always point to a valid object. The `oopDesc*` is then implicitly converted to an `oop` here:
>> 
>> void trace_method_handle_stub_wrapper(MethodHandleStubArguments* args) {
>>   trace_method_handle_stub(args->adaptername,
>>                            args->mh,
>>                            args->saved_regs,
>>                            args->entry_sp);
>> }
>> 
>> This gets caught by my ad-hoc verification code that verifies oops when they are created/used.
>> 
>> I propose that we don't create an oop until it `mh` is actually used, and it has been checked that the argument should contain a valid oop.  I started with a more elaborate fix that changed the type of `mh` to be `void*`, but then reverted to a more targetted fix to remove the early oopDesc* > oop conversion.
>> 
>> One thing that I am curious about is this code inside trace_method_handle_stub:
>> if (has_mh && oopDesc::is_oop(mh)) {
>>   mh->print_on(&ls);
>> 
>> Delaying the oopDesc* > oop conversion to after the `has_mh` check solves my verification failure, but I wonder if the `oopDesc::is_oop(mh)` call is really needed when we have the `has_mh` check?
>
> Looks good to me too.

Thanks, @TobiHartmann

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

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

From xgong at openjdk.java.net  Mon Apr 12 07:58:07 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 12 Apr 2021 07:58:07 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v3]
In-Reply-To: <aksQ5VA2DukLD2B4SNkxMxmEJBQS7VG-JnZnCWaF9m8=.6a54ce2f-7c88-4d55-b125-fcefa27533c5@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <JS7xbPOO9_TvNFy5zehs4KwZCYuKU8VYbmQ3UdXd708=.35d0b172-a69e-4b96-b356-18ba34d3b77e@github.com>
 <Iyitokh4QpeTPElt7Ad2Q_np96M9PGj449rEakcGkc4=.5ac1d23d-4445-43d9-8eca-49463102e7ee@github.com>
 <aksQ5VA2DukLD2B4SNkxMxmEJBQS7VG-JnZnCWaF9m8=.6a54ce2f-7c88-4d55-b125-fcefa27533c5@github.com>
Message-ID: <JA2Eqaq2YGX9rG0gTqH9nhbRYEB7OUkq7svmbUctoWw=.a8add179-569d-4167-a6d0-18c063d026a3@github.com>

On Mon, 12 Apr 2021 07:02:38 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.hpp line 1247:
>> 
>>> 1245:     assert(type2aelembytes(in_vt->element_basic_type()) == type2aelembytes(vt->element_basic_type()), "element size must match");
>>> 1246:   }
>>> 1247: 
>> 
>> FTR there's a way to avoid platform-specific changes (in AD files) if we don't envision any non-trivial conversions to be supported: just disable matching of the node by overriding `Node::ideal_reg()`:
>> virtual uint ideal_reg() const { return 0; } // not matched in the AD file
>
> Good idea, I will try this way. Thanks!

I met the bad AD file issue when I remove the changes in AD files and overriding `Node::ideal_reg()`. I guess if a node is not used as an input of other node, this can work well? For the `VectorMaskCastNode`, it must be an input for some other nodes. If just disable the matching of this node, how does its usage find the right input code?

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

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

From jbhateja at openjdk.java.net  Mon Apr 12 08:21:42 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 12 Apr 2021 08:21:42 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization [v2]
In-Reply-To: <4jMKSSVNKx5Fh7hek0pT5MMIYAnTjB7y7faOh_L60Pw=.2ce391ed-b29c-4a05-a412-bb3935126b2f@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
 <wWxk0BA7nACrZwQL872NjdRW3N2xDa4I9ir1u6wlJv8=.fa8842fd-d2ea-4441-9964-ef80f889e8fd@github.com>
 <4jMKSSVNKx5Fh7hek0pT5MMIYAnTjB7y7faOh_L60Pw=.2ce391ed-b29c-4a05-a412-bb3935126b2f@github.com>
Message-ID: <EpEbhmWmMahhyFpWZwLeVfPlCnSy_4sHdtd0azMoP2o=.cdb7d76a-6eea-4573-8d2a-4c25fc259cf0@github.com>

On Fri, 9 Apr 2021 19:12:27 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8264954: Review comments resolution.
>
> src/hotspot/share/opto/vector.cpp line 270:
> 
>> 268:     bool is_mask = is_vector_mask(iklass);
>> 269:     if (is_mask) {
>> 270:       if (vec_value->Opcode() != Op_VectorStoreMask) {
> 
> It's better to do the check against the type of `vec_value`: `VectorStoreMask` produces a vector of booleans  and you can guard `gvn.transform(VectorStoreMaskNode::make(...))` call with `bt != T_BOOLEAN` check instead.

In addition to bt != T_BOOLEAN check, we also need to check if type is a vectormask (explicit type added for mask generating nodes on targets supporting predicate registers).

A similar check needs to be added at following location
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vector.cpp#L329

Keeping this as it is i.e. an Opcode based check.

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

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

From rcastanedalo at openjdk.java.net  Mon Apr 12 08:37:18 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 12 Apr 2021 08:37:18 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block [v2]
In-Reply-To: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
Message-ID: <ASaeKyQC6TCF_iejF4ky2BvK0OMcn5SALosyYAb1SUw=.bc82c0f0-09c5-4595-b5ce-363b318cd5a0@github.com>

> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
> 
> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
> 
> Tested on:
> - original bug reproducer
> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)

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

 - Complete projection assertions with basic checks
 - Enforce code style in surrounding 'for' statements
 - Simplify loop that removes dead projections, rename and comment for clarity
 - Assert that projections are stuck to their parents

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3303/files
  - new: https://git.openjdk.java.net/jdk/pull/3303/files/a4973ba0..808451de

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

  Stats: 26 lines in 2 files changed: 13 ins; 1 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3303/head:pull/3303

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

From rcastanedalo at openjdk.java.net  Mon Apr 12 08:37:23 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 12 Apr 2021 08:37:23 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block [v2]
In-Reply-To: <UIrzlot2zh1e-5Ox2nq_stIK1ycpF5_OgfN7DnPqHFs=.e4cad8c0-5655-4766-9109-823471b85c8b@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <M9OcTa-WZ8WQYHiGJZ1hziMDFeGOYs593CweXthMAgc=.3de10d71-924a-4ce9-8215-72f13bd5e638@github.com>
 <YwFxUxSk7TMhWe7yK6Aty-C1kE5s1SXwqul3UJZd29o=.9cde72b2-1364-45e6-9314-0225028b1e93@github.com>
 <-OXlf8TYEEY3rOr6V8ae6zR2QtDnjfnso4R_CKA9alU=.5c7de539-587e-47dd-b25d-ef0443e024d6@github.com>
 <UIrzlot2zh1e-5Ox2nq_stIK1ycpF5_OgfN7DnPqHFs=.e4cad8c0-5655-4766-9109-823471b85c8b@github.com>
Message-ID: <vM2nNlWfm3pgFfX5oksURbKABmZkLGtS61xypNyNn4Q=.69ef0b7e-0c18-432d-9906-5c8733271a8a@github.com>

On Thu, 8 Apr 2021 18:20:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I am not sure that no other nodes were inserted in between users.

Isn't this enforced by local scheduling? From `PhaseCFG::select()`:

https://github.com/openjdk/jdk/blob/b1ebf82269fa85bed859ffafacd59ed000f22bd0/src/hotspot/share/opto/lcm.cpp#L477-L478

https://github.com/openjdk/jdk/blob/b1ebf82269fa85bed859ffafacd59ed000f22bd0/src/hotspot/share/opto/lcm.cpp#L516-L523

`PhaseCFG::call_catch_cleanup()` runs right after local scheduling, and it doesn't reorder the cloned instructions before reaching the dead code elimination loop, so I don't see any place where other nodes might be inserted in between projections of the same node. I checked this with an assertion in `PhaseCFG::verify()` (commits 8d96589 and 808451d), and the following tests run without assertion failures:

- hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
- hs-tier6-9 (linux-x64) with `+VerifyRegisterAllocator`
- hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`, `+StressGCM`, and `+StressLCM` (5 repetitions)

Based on above analysis, code comments in `lcm.cpp`, and test results, I suggest to treat the fact that projections are scheduled next to their parent nodes as an invariant, and exploit the invariant as in this (updated) change -- but I am fine with the more defensive alternative you propose if you still prefer that.

> I also noticed wrong code stile in for() statements near your change. Please, fix them too.

Done.

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

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

From aph at redhat.com  Mon Apr 12 08:38:29 2021
From: aph at redhat.com (Andrew Haley)
Date: Mon, 12 Apr 2021 09:38:29 +0100
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}
In-Reply-To: <F8E82625-69A8-44BD-8BA8-CE77377895C2@tencent.com>
References: <F8E82625-69A8-44BD-8BA8-CE77377895C2@tencent.com>
Message-ID: <0a111afe-0ac5-0d2e-a4b6-a2c3aedeebee@redhat.com>

On 4/12/21 7:51 AM, jiefu(??) wrote:
> So why Java creates conflict special rules for them?
> Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?

These rules are in the C standard too, which is inherited by other
programming languages. Also, please see
https://bugs.openjdk.java.net/browse/JDK-8240632

-- 
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 rcastanedalo at openjdk.java.net  Mon Apr 12 08:40:52 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 12 Apr 2021 08:40:52 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <gIPBubLRWm99DJY2swvO1oIDJ1VBC9KK-sAvaEnJ_w4=.67444468-ae7f-4dfa-8163-651cb939f23e@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <C9s8H9XxXGh98TOaXv7uVitMA1M9ZS2aMihwpJx0og4=.81f079d3-1d2c-4ce8-a039-bd2dbfb9b1aa@github.com>
 <-vl-o8PemGJNrb-7AtTQoNB6YGnhxoA3CVWot_iihlU=.90713355-bd98-4c1c-b253-08d660c1590e@github.com>
 <gIPBubLRWm99DJY2swvO1oIDJ1VBC9KK-sAvaEnJ_w4=.67444468-ae7f-4dfa-8163-651cb939f23e@github.com>
Message-ID: <a0lIyeAjMcTbrWHROfWKS4HO8Yg1bsbDkCkRvdEaxfE=.9421105c-6b91-4694-a2c1-2078f05dfd45@github.com>

On Thu, 8 Apr 2021 17:53:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > > Also where is guarantee that all Proj users are in the same block.
> > 
> > 
> > Isn't this guaranteed by `PhaseCFG::schedule_node_into_block()`?
> > I will run some tests with extra assertions in `PhaseCFG::verify()` to double-check.
> 
> Okay.

Done, see results in the related discussion (https://github.com/openjdk/jdk/pull/3303#discussion_r611430316).

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

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

From shade at openjdk.java.net  Mon Apr 12 08:40:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Apr 2021 08:40:54 GMT
Subject: RFR: 8264972: Unused TypeFunc declared in OptoRuntime
In-Reply-To: <hMnyMvn4a315EKYg4RHpWQ7NQtuJQzq8i5lTiPjcGs8=.cd3b60f3-38d6-48d4-95e5-96e1f40242b0@github.com>
References: <hMnyMvn4a315EKYg4RHpWQ7NQtuJQzq8i5lTiPjcGs8=.cd3b60f3-38d6-48d4-95e5-96e1f40242b0@github.com>
Message-ID: <4usgDpGn_k432DLdk3RrPRFwFpUd4Epl6Hl8c2m44X4=.4c1e0ed4-7df8-4d27-baa4-ce120d4b543e@github.com>

On Mon, 12 Apr 2021 03:18:33 GMT, Yi Yang <yyang at openjdk.org> wrote:

> When investigating some C2 related stuff, I noticed that some TypeFunc are declared in OptoRuntime since JDK6:
> 
>   // leaf on stack replacement interpreter accessor types
>   static const TypeFunc* fetch_int_Type();
>   static const TypeFunc* fetch_long_Type();
>   static const TypeFunc* fetch_float_Type();
>   static const TypeFunc* fetch_double_Type();
>   static const TypeFunc* fetch_oop_Type();
>   static const TypeFunc* fetch_monitor_Type();
> 
> They are neither used nor implemented. It looks like we can remove them(I'm curious about their stories/history.)

This apparently predates OpenJDK history. Looks fine.

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

Marked as reviewed by shade (Reviewer).

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

From yyang at openjdk.java.net  Mon Apr 12 08:45:16 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 12 Apr 2021 08:45:16 GMT
Subject: Integrated: 8264972: Unused TypeFunc declared in OptoRuntime
In-Reply-To: <hMnyMvn4a315EKYg4RHpWQ7NQtuJQzq8i5lTiPjcGs8=.cd3b60f3-38d6-48d4-95e5-96e1f40242b0@github.com>
References: <hMnyMvn4a315EKYg4RHpWQ7NQtuJQzq8i5lTiPjcGs8=.cd3b60f3-38d6-48d4-95e5-96e1f40242b0@github.com>
Message-ID: <zM8sTH25JbPWY_Um4CdJQA1_PMWhxdd8jlNus69WJx4=.92fda156-f3d3-4955-9c02-024759055950@github.com>

On Mon, 12 Apr 2021 03:18:33 GMT, Yi Yang <yyang at openjdk.org> wrote:

> When investigating some C2 related stuff, I noticed that some TypeFunc are declared in OptoRuntime since JDK6:
> 
>   // leaf on stack replacement interpreter accessor types
>   static const TypeFunc* fetch_int_Type();
>   static const TypeFunc* fetch_long_Type();
>   static const TypeFunc* fetch_float_Type();
>   static const TypeFunc* fetch_double_Type();
>   static const TypeFunc* fetch_oop_Type();
>   static const TypeFunc* fetch_monitor_Type();
> 
> They are neither used nor implemented. It looks like we can remove them(I'm curious about their stories/history.)

This pull request has now been integrated.

Changeset: ecef1fc8
Author:    Yi Yang <yyang at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ecef1fc8
Stats:     8 lines in 1 file changed: 0 ins; 8 del; 0 mod

8264972: Unused TypeFunc declared in OptoRuntime

Reviewed-by: thartmann, shade

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

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

From yyang at openjdk.java.net  Mon Apr 12 08:49:32 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 12 Apr 2021 08:49:32 GMT
Subject: RFR: 8264972: Unused TypeFunc declared in OptoRuntime
In-Reply-To: <4usgDpGn_k432DLdk3RrPRFwFpUd4Epl6Hl8c2m44X4=.4c1e0ed4-7df8-4d27-baa4-ce120d4b543e@github.com>
References: <hMnyMvn4a315EKYg4RHpWQ7NQtuJQzq8i5lTiPjcGs8=.cd3b60f3-38d6-48d4-95e5-96e1f40242b0@github.com>
 <4usgDpGn_k432DLdk3RrPRFwFpUd4Epl6Hl8c2m44X4=.4c1e0ed4-7df8-4d27-baa4-ce120d4b543e@github.com>
Message-ID: <qZ2WMQWmLlmy8uV5fc7cBstMQyA56GrweShsMBLLAAE=.790e874f-babe-491e-a93d-1c225e33cdc1@github.com>

On Mon, 12 Apr 2021 08:36:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This apparently predates OpenJDK history. Looks fine.

Yes, it seems an ancient code. I googled it but got nothing except source codes in OpenJDK.

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

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

From rcastanedalo at openjdk.java.net  Mon Apr 12 09:02:51 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 12 Apr 2021 09:02:51 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <OCiLTSE4SK7CNHNbIkfQkw_EQIL7xocjzOPhXjp1lew=.19a2e087-60dc-4d74-9c14-dd27fed49f79@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
 <OCiLTSE4SK7CNHNbIkfQkw_EQIL7xocjzOPhXjp1lew=.19a2e087-60dc-4d74-9c14-dd27fed49f79@github.com>
Message-ID: <_Cu2871SERzpfwf5GrLz6SfQqhfOew58zQXGXYa4MBU=.bb49faf1-7b04-4d08-924c-49e3e132eb61@github.com>

On Fri, 9 Apr 2021 23:07:39 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Thank you for modernizing IGV. I manage to import this project to IntelliJ. The process is hassle-free!
> 
> I also ran using jdk8/jdk11 on macOS. I haven't identified any problem so far.

Thanks for checking, Xin!

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

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

From rcastanedalo at openjdk.java.net  Mon Apr 12 09:09:47 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 12 Apr 2021 09:09:47 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
Message-ID: <HO8ya6cGFMlLMaMrNgSNt8VnqMJ4j4jLePYj5gN_t60=.6d4069d3-198e-41f9-997e-082be3fe5628@github.com>

On Wed, 7 Apr 2021 11:59:28 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).
>> 
>> The change also fixes broken unit tests in the Data module and runs them by default when building.
>> 
>> #### Testing
>> 
>> Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):
>> 
>> - build
>> - open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
>> - import graphs via network (localhost)
>> - expand groups in outline
>> - open a graph
>> - open a clone
>> - zoom in and out
>> - search a node
>> - apply filters
>> - extract a node
>> - show all nodes
>> - select nodes corresponding to a bytecode
>> - view control flow
>> - select nodes corresponding to a basic block
>> - cluster nodes
>> - show satellite view
>> - compute the difference of two graphs
>> - change node text
>> - remove a group
>> - save groups into a file
>> - open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
>> - open a large graph ("After Escape Analysis" in large.xml)
>> 
>> Thanks to Vladimir Ivanov for helping with testing on macOS.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Document how to build and run on a specific JDK
>  - Use lambdas to define runnables
>  - Document latest JDK version supported

> Nice work. It works on Windows home pc. rocket

Thanks for checking, Yang!

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

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

From rcastanedalo at openjdk.java.net  Mon Apr 12 09:09:47 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 12 Apr 2021 09:09:47 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <OCiLTSE4SK7CNHNbIkfQkw_EQIL7xocjzOPhXjp1lew=.19a2e087-60dc-4d74-9c14-dd27fed49f79@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
 <OCiLTSE4SK7CNHNbIkfQkw_EQIL7xocjzOPhXjp1lew=.19a2e087-60dc-4d74-9c14-dd27fed49f79@github.com>
Message-ID: <TpZAfQ-c6ltqxuIXaY5aFy7OPoscmce-8L3x--lBCSs=.0e1967ea-1955-4cf0-904d-a05b736d5411@github.com>

On Fri, 9 Apr 2021 22:39:09 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Does this mean that module Filter will depend on external nashorn after jdk15?

Yes (including JDK 15).

> I know that jdk doesn't remove nashorn util jdk15, but does it make sense that IGV always picks up external nashorn. My concern is "javascript" in jdk8/11 may be not well-maintained and leave vulnerability behind.

I assume potential issues in "built-in" Nashorn are addressed in JDK 8-14 as for any other OpenJDK component. Besides, [standalone (external) Nashorn only works on JDK >= 11](https://github.com/szegedi/nashorn/wiki/Using-Nashorn-with-different-Java-versions), and I think it makes sense that IGV stills support JDK 8 for minimal disruption (this was the only JDK version supported before this upgrade).

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

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

From adinn at redhat.com  Mon Apr 12 09:23:24 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 12 Apr 2021 10:23:24 +0100
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}
In-Reply-To: <F8E82625-69A8-44BD-8BA8-CE77377895C2@tencent.com>
References: <F8E82625-69A8-44BD-8BA8-CE77377895C2@tencent.com>
Message-ID: <e1cf592d-b883-a4e5-63c2-bcaceb00f675@redhat.com>

On 12/04/2021 07:51, jiefu(??) wrote:

> I think most people will be confused by these rules because from the
> view of mathematics, Math.pow(x, 0.5) should be equal to
> Math.sqrt(x).

This is already a confused situation from the point of view of 
mathematics. Consider these two expressions:

Math.sqrt(-0.0) * Math.sqrt(-0.0)

Math.pow(-0.0, 0.5) * Math.pow(-0.0, 0.5)

It doesn't matter whether the functions sqrt and pow compute -0.0 or 0.0 
as the value here. Either result will fail to satisfy the equality

   f(x) * f(x) == x

The problem is that computation has already diverged from mathematical 
expectation by introducing the value -0.0. So, Java (and other 
languages) have to make up a rule here.

> So why Java creates conflict special rules for them? Is it possible
> to let Math.pow(-0.0, 0.5) = -0.0 and
> Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?

It might well match expectations better if both functions were to 
generate the same value here. However, expectations have already been 
set by libc:

$ cat > sqrt.c << END
#include <stdio.h>
#include <math.h>
int main(int argc, char **argv) {
     printf("sqrt(-0.F) = %f\n", sqrt(-0.F));
     printf("pow(-0.F, 0.5) = %f\n", pow(-0.F, 0.5));
}
END
$ make sqrt
cc     sqrt.c   -o sqrt
$ ./sqrt
sqrt(-0.F) = -0.000000
pow(-0.F, 0.5) = 0.000000

I have no idea why these specific results were made up for C but Java 
really ought to follow them.

regards,


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


From xgong at openjdk.java.net  Mon Apr 12 09:29:38 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 12 Apr 2021 09:29:38 GMT
Subject: RFR: 8264957: Type::dual_type array is not aligned with enum TYPES
In-Reply-To: <jVzalT5mDb_J5KMrQduJMHNfhT1vKAdndNuN3jW3d9I=.e8056bc5-56e8-460c-ae89-6160510876bc@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
 <jVzalT5mDb_J5KMrQduJMHNfhT1vKAdndNuN3jW3d9I=.e8056bc5-56e8-460c-ae89-6160510876bc@github.com>
Message-ID: <SEDsAMfaxSVs3JZjcUHuJo9nJ0j9e0v-KsdNOYaIO3E=.de4d7ddb-7355-4cbf-8a55-1963e1046876@github.com>

On Fri, 9 Apr 2021 11:02:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.
>> 
>> I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
>> 
>>  Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
>>  # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
>> 
>> Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8262355
>> 
>> Tested with tier1 and jdk:tier3
>
> This sounds reasonable to me.
> Thanks.

Thanks for your review @DamonFool @neliasso ! It seems the array `Type::dual_type` is not used anywhere currently. The same definition for `dual_type` is defined in https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/type.hpp#L140 and used in type.cpp, which uses `Type::dual_type` before. So I think the whole definition can be totally removed. The issue I met might not be related to it. I will have a test and remove it if everything works well. Thanks!

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

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

From jbhateja at openjdk.java.net  Mon Apr 12 09:33:14 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 12 Apr 2021 09:33:14 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization [v3]
In-Reply-To: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
Message-ID: <WNL_27olNI8kucH51BEgNekrTyIe0IvItWM_HYF2fjE=.8c5f8eed-a215-4f2d-a7c3-a39bd54c2dda@github.com>

> Following flow describes object reconstruction for de-optimization:-
> 1)	PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
> 2)	During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
> 3)	De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
> 4)	During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings. 
> 
> By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.
> 
> tier1-tier3 regressions are clean with UseAVX=2/3.

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8264954: Incorporating closing comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3408/files
  - new: https://git.openjdk.java.net/jdk/pull/3408/files/239923fd..98b4778d

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

  Stats: 13 lines in 2 files changed: 1 ins; 4 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3408.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3408/head:pull/3408

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

From rcastanedalo at openjdk.java.net  Mon Apr 12 10:26:49 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 12 Apr 2021 10:26:49 GMT
Subject: RFR: 8263790: C2: new igv_print_immediately() for debugging
 purpose
In-Reply-To: <hBPJff7i-WJJNJjbhv739WqCdPj1rLJ8ant1VOI-Y24=.d3a7db1f-c138-4c4c-b7b9-f0e235932585@github.com>
References: <hBPJff7i-WJJNJjbhv739WqCdPj1rLJ8ant1VOI-Y24=.d3a7db1f-c138-4c4c-b7b9-f0e235932585@github.com>
Message-ID: <T2fIQbwJvB994kmA7OLisVQeUvzKIle2fNNpVavoRmQ=.607bc26a-aefb-4038-bf11-7b0855c0e925@github.com>

On Thu, 18 Mar 2021 10:05:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Add a new igv_print_immediately, it prints the current method immediately. This differs from other igv_print* methods, it creates a well-formed and complete ideal graph xml immediately, while others accomplish their ideal graph xml when VM exists (i.e. destructor of `IdealGraphPrinter::_xx_printer`). If VM crashes before VM exit, the ideal graph xml will be ill-formed, this is fairly a common case when debugging another crash.
> 
> Test manually!
> 
> Cheers,
> Yang

> In the catch clause, ex.getMessage() compares with ASCII characters, but ex.getMessage()gets characters that corresponding to their system locale settings. To support non-English system locale settings(if needed), we could code something like this:
> 
> ```java
>      if (!(ex instanceof SAXParseException) || !"XML document structures must start and end within the same entity.".equals(disable_i18n(ex.getMessage())))
> ```

That makes sense, can you please try if this fix works for you? https://github.com/robcasloz/jdk/commit/702e763

If it does, please feel free to re-purpose this issue with the proposed fix (once https://github.com/openjdk/jdk/pull/3361 is integrated), and with a test case that parses an incomplete XML document in `src/utils/IdealGraphVisualizer/Data/src/test/java/com/sun/hotspot/igv/data/serialization/ParserTest.java`. Please make sure to test in on different JDK versions (I suggest JDK 8, 11, and 15).

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

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

From jbhateja at openjdk.java.net  Mon Apr 12 12:17:48 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 12 Apr 2021 12:17:48 GMT
Subject: Integrated: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization
In-Reply-To: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
Message-ID: <cbwMr3xf2DwTfRkOiz_27k9VBVxez4CbfKyhe1tHaoQ=.8ba181ba-4566-45cd-b657-fbac58938318@github.com>

On Fri, 9 Apr 2021 07:25:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Following flow describes object reconstruction for de-optimization:-
> 1)	PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
> 2)	During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
> 3)	De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
> 4)	During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings. 
> 
> By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.
> 
> tier1-tier3 regressions are clean with UseAVX=2/3.

This pull request has now been integrated.

Changeset: f71be8b5
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f71be8b5
Stats:     66 lines in 3 files changed: 22 ins; 22 del; 22 mod

8264954: unified handling for VectorMask object re-materialization during de-optimization

Reviewed-by: vlivanov

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

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

From jiefu at tencent.com  Mon Apr 12 13:39:16 2021
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Mon, 12 Apr 2021 13:39:16 +0000
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}(Internet mail)
In-Reply-To: <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
 <72184DF4-C63B-488F-8490-074247292022@tencent.com>
 <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>
Message-ID: <F7BB9A3B-454F-48A4-A8EB-83200E0C50CF@tencent.com>

Hi Raffaello,

Thanks for your execllent analysis.
I agree with you now.
And I'll close the optimization PR [1] tomorrow if there is no objections.

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/pull/3404/


?On 2021/4/12, 9:06 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:

    Hi Jie,
    
    I don't think that changing the spec of Math.pow() to be misaligned with 
    IEEE 754 would be a wise option. IEEE is much more pervasive than Java. 
    There are many aspects in IEEE that might be seen as questionable, but 
    at least it is a widely adopted standard.
    
    AFAIU, the only reason you would like to "optimize" the special case of 
    y = 0.5 in pow(x, y) to return sqrt(x) is for performance, more accuracy 
    and some kind of consistency.
    
    But then, why not a special case for y = 0.25 as sqrt(sqrt(x))?
    And what about y = 0.75? Should this be translated to sqrt(sqrt(pow(x, 3)))?
    What about y = 1.0 / 3.0? Should this become cbrt(x)?
    And why not consider y = 2.0 / 3.0 in a special rule: cbrt(x * x)?
    
    You see, the special cases can quickly become unmanageable. Also, 
    special rules would produce results which are "discontinuous" with 
    nearby exponents, like y = 0.5000000000000001.
    
    That's probably why IEEE doesn't propose translation rules for finite 
    numerical exponents that are not integers, except when x is a special value.
    
    
    Greetings
    Raffaello
    
    
    
    On 2021-04-12 13:44, jiefu(??) wrote:
    > Hi Andrew H, Andrew D, and Raffaello,
    > 
    > Thank you all for your kind reply and helpful comments.
    > 
    > Now I got where the rules come from.
    > But I don't think the IEEE standars are reasonable to specify conflits rules.
    > Maybe, these computations should be open to be implementation dependent.
    > 
    > (If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java.
    > We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right?
    > And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.
    > 
    > Thanks.
    > Best regards,
    > Jie
    > 
    > 
    > On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
    > 
    >      Hi Jie,
    >      
    >      the behavior you report is the one specified by the standard IEEE 754.
    >      Java follows this standard as closely as it can.
    >      
    >      The standard says that
    >      * squareRoot(-0) = -0
    >      * squareRoot(-?) = NaN
    >      
    >      Also, the standard has a long lists of special cases for pow(x, y),
    >      among them:
    >      * pow(?0, y) is +0 for finite y > 0 and not an odd integer
    >      * pow(-?, y) is +? for finite y > 0 and not an odd integer
    >      
    >      Thus, the conflicts you observe originate in following the standard, not
    >      by special Java rules.
    >      
    >      Unfortunately, the IEEE standard does not explain the reasons for the
    >      special rules. Some are obvious, some are not.
    >      
    >      
    >      HTH
    >      Raffaello
    >      
    >      
    >      > Hi all,
    >      >
    >      > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
    >      > ```
    >      > Math.pow(-0.0, 0.5) = 0.0
    >      > Math.sqrt(-0.0) = -0.0
    >      >
    >      > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
    >      > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
    >      > ```
    >      >
    >      > The reason is that both of pow and sqrt have special rules for these computations.
    >      > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
    >      > And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
    >      > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
    >      >
    >      > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
    >      >
    >      > So why Java creates conflict special rules for them?
    >      > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
    >      >
    >      > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
    >      > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
    >      >
    >      > Thanks.
    >      > Best regards,
    >      > Jie
    >      
    >      
    > 
    
    


From vlivanov at openjdk.java.net  Mon Apr 12 15:04:39 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 12 Apr 2021 15:04:39 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization [v2]
In-Reply-To: <EpEbhmWmMahhyFpWZwLeVfPlCnSy_4sHdtd0azMoP2o=.cdb7d76a-6eea-4573-8d2a-4c25fc259cf0@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
 <wWxk0BA7nACrZwQL872NjdRW3N2xDa4I9ir1u6wlJv8=.fa8842fd-d2ea-4441-9964-ef80f889e8fd@github.com>
 <4jMKSSVNKx5Fh7hek0pT5MMIYAnTjB7y7faOh_L60Pw=.2ce391ed-b29c-4a05-a412-bb3935126b2f@github.com>
 <EpEbhmWmMahhyFpWZwLeVfPlCnSy_4sHdtd0azMoP2o=.cdb7d76a-6eea-4573-8d2a-4c25fc259cf0@github.com>
Message-ID: <itY_OcHpq_x-nX-n4McZ7ul5ddr51matU6QngVO3N_A=.8bb9c1ef-b62d-4d71-8611-b1c1151721b4@github.com>

On Mon, 12 Apr 2021 08:16:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> In addition to bt != T_BOOLEAN check, we also need to check if type is a vectormask (explicit type added for mask generating nodes on targets supporting predicate registers).

You check here that the mask is in canonical representation (which is a vector of booleans) before applying the canonicalizing conversion. Alternatively, you could check that the mask is in "native"/platform-dependent representation (`vec_value` has `TypeVectMask` type).

So, my reading of your response is that `bt != T_BOOLEAN` check is not enough to reliably distinguish between the representations: a mask for vector of booleans (in native representation) will have the same type as the vector of booleans produced by the canonicalizing cast of a mask value. I agree with that.

But until `TypeVectMask` is used uniformly and independently of predicate register support, `TypeVect` vs `TypeVectMask` doesn't cut the problem as well. And adding `bt != T_BOOLEAN` doesn't help.

So, I'm fine with leaving the Opcode check for now. 

In the longer term, we need to come up with a uniform representation in type system for masks in native format to be able to reliably distinguish between masks and vectors in cross-platform manner.

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

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

From vlivanov at openjdk.java.net  Mon Apr 12 15:12:30 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 12 Apr 2021 15:12:30 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v3]
In-Reply-To: <JA2Eqaq2YGX9rG0gTqH9nhbRYEB7OUkq7svmbUctoWw=.a8add179-569d-4167-a6d0-18c063d026a3@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <JS7xbPOO9_TvNFy5zehs4KwZCYuKU8VYbmQ3UdXd708=.35d0b172-a69e-4b96-b356-18ba34d3b77e@github.com>
 <Iyitokh4QpeTPElt7Ad2Q_np96M9PGj449rEakcGkc4=.5ac1d23d-4445-43d9-8eca-49463102e7ee@github.com>
 <aksQ5VA2DukLD2B4SNkxMxmEJBQS7VG-JnZnCWaF9m8=.6a54ce2f-7c88-4d55-b125-fcefa27533c5@github.com>
 <JA2Eqaq2YGX9rG0gTqH9nhbRYEB7OUkq7svmbUctoWw=.a8add179-569d-4167-a6d0-18c063d026a3@github.com>
Message-ID: <P_A2ViU-DOS9mY2L1OMjQdkU-W81AJtnl_sQLm3Jan8=.a350d148-d85a-4bc2-a129-aec2c1350892@github.com>

On Mon, 12 Apr 2021 07:53:36 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Good idea, I will try this way. Thanks!
>
> I met the bad AD file issue when I remove the changes in AD files and overriding `Node::ideal_reg()`. I guess if a node is not used as an input of other node, this can work well? For the `VectorMaskCastNode`, it must be an input for some other nodes. If just disable the matching of this node, how does its usage find the right input code?

Yeah, `ideal_reg() { return 0; }` won't work here. Sorry for the misleading suggestion.

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

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

From erikj at openjdk.java.net  Mon Apr 12 16:21:50 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 12 Apr 2021 16:21:50 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
Message-ID: <kVdFvMb_xK3q3FCB94V8aJbUpoEVsH3mjZFPP6JFy_0=.6bdcc9ec-33d4-4492-83bf-b728a0fce482@github.com>

On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> 
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov 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 three additional commits since the last revision:
> 
>  - Restore Graal Builder image makefile
>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>  - 8264806: Remove the experimental JIT compiler

make/common/Modules.gmk line 68:

> 66: 
> 67: # Filter out Graal specific modules
> 68: MODULES_FILTER += jdk.internal.vm.compiler

If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all?

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

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

From iklam at openjdk.java.net  Mon Apr 12 16:52:33 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 12 Apr 2021 16:52:33 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v4]
In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
Message-ID: <5dhg50Ktvcm23PgJR3WejtOxkozTDxNLjAn07pMzPAY=.7d29d3d1-8a14-403f-9cbe-acd1bfe05e11@github.com>

On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
>> 
>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
>> 
>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
>> 
>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
>> 
>> Some missing CHECK_ uses were added.
>> 
>> Testing:
>>   - tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix search&replace mistake

LGTM

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

Marked as reviewed by iklam (Reviewer).

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

From vlivanov at openjdk.java.net  Mon Apr 12 16:52:47 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 12 Apr 2021 16:52:47 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v3]
In-Reply-To: <aksQ5VA2DukLD2B4SNkxMxmEJBQS7VG-JnZnCWaF9m8=.6a54ce2f-7c88-4d55-b125-fcefa27533c5@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <JS7xbPOO9_TvNFy5zehs4KwZCYuKU8VYbmQ3UdXd708=.35d0b172-a69e-4b96-b356-18ba34d3b77e@github.com>
 <Iyitokh4QpeTPElt7Ad2Q_np96M9PGj449rEakcGkc4=.5ac1d23d-4445-43d9-8eca-49463102e7ee@github.com>
 <aksQ5VA2DukLD2B4SNkxMxmEJBQS7VG-JnZnCWaF9m8=.6a54ce2f-7c88-4d55-b125-fcefa27533c5@github.com>
Message-ID: <OxDlkWga5vddXNeLjqtj5OwbB25mNf9_kino0snKVnI=.3f4b9590-2b4d-48a5-b414-3e2ad5b44634@github.com>

On Mon, 12 Apr 2021 07:00:58 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 1237:
>> 
>>> 1235:           if (in_vt->length_in_bytes() == out_vt->length_in_bytes() &&
>>> 1236:               Matcher::match_rule_supported(Op_VectorMaskCast)) {
>>> 1237:             // VectorUnbox (VectorBox vmask) ==> VectorMaskCast (vmask)
>> 
>> It's better to implement it as a 2-step transformation and place it in `VectorLoadMaskNode::Ideal()`:
>> 
>> VectorUnbox (VectorBox vmask) ==> VectorLoadMask (VectorStoreMask vmask) => VectorMaskCast (vmask)
>
> Thanks for your comments. Yes, theoretically it's better to place it in `VectorLoadMaskNode::Ideal()`. Unfortunately, we met an issue that is related to optimization for `VectorStoreMask`. Considering the following case:
> 
>    LoadVector                                              LoadVector
>            |                                                    |
>    VectorLoadMask  (double)                          VectorLoadMask (double)
>                |                                               |
>            VectorUnbox   (long)          ==>           VectorStoreMask  (double)
>                                                                |
>                                                       VectorLoadMask  (long)
> 
> This case loads the masking values for a double type, and does a bitwise `and` operation. Since the type is mismatched, the compiler will try to do `VectorUnbox (VectorBox vmask) ==> VectorLoadMask (VectorStoreMask vmask)`. However, since there is the transformation `VectorStoreMask (VectorLoadMask value)  ==> value`, the above `VectorStoreMaskNode` will be optimized out. The final graph looks like:
> 
> 
>    LoadVector                                                  LoadVector
>           |                                                      /      \
>         VectorLoadMask  (double)                               /         \
>               |                      ==>     VectorLoadMask (double)      \
>          VectorStoreMask (double)                                   VectorLoadMask (long)
>                    |
>             VectorLoadMask (long)
> 
> Since the two `VectorLoadMaskNode` have different element type, the GVN cannot optimize out one. So finally there will be two similar  `VectorLoadMaskNode`s. That's also why I override the `cmp/hash` for `VectorLoadMaskNode` in the first version.
> 
> So I prefer to add `VectorUnbox (VectorBox vmask) ==> VectorMaskCast (vmask)` directly.

Ok, so you face a transformation ordering problem here. 

By working on `VectorUnbox (VectorBox vmask)` you effectively delay `VectorStoreMask (VectorLoadMask vmask) => vmask` transformation.

As an alternative you could:

(1) check for `VectorLoadMask` users before applying `VectorStoreMask (VectorLoadMask vmask) => vmask`;

(2) nest adjacent casts: 

VectorLoadMask #double (1 LoadVector)
VectorLoadMask #long   (1 LoadVector)
==>
VectorMaskCast #long (VectorLoadMask #double (1 LoadVector)


The latter looks more powerful (and hence preferrable), but I'm fine with what you have right now. (It can be enhanced later.)
Please, leave a comment describing the motivation for doing the transformation directly on `VectorUnbox (VectorBox ...)`.

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

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

From kvn at openjdk.java.net  Mon Apr 12 17:22:00 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 12 Apr 2021 17:22:00 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <kVdFvMb_xK3q3FCB94V8aJbUpoEVsH3mjZFPP6JFy_0=.6bdcc9ec-33d4-4492-83bf-b728a0fce482@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <kVdFvMb_xK3q3FCB94V8aJbUpoEVsH3mjZFPP6JFy_0=.6bdcc9ec-33d4-4492-83bf-b728a0fce482@github.com>
Message-ID: <z8uXpkbdA-wiwrLpejc7CDO-er7i6IH3bxJ_xD-Ayl0=.f7d147c2-f0e1-4228-aed0-83023551afd9@github.com>

On Mon, 12 Apr 2021 16:18:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Vladimir Kozlov 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 three additional commits since the last revision:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> make/common/Modules.gmk line 68:
> 
>> 66: 
>> 67: # Filter out Graal specific modules
>> 68: MODULES_FILTER += jdk.internal.vm.compiler
> 
> If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all?

We filter out because we can't build Graal anymore. But we need these module-info.java files because JVMCI's module-info.java references them:
https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java#L26

Otherwise we can't build JVMCI which we continue to support.

I filed followup RFE to implement Alan's suggestion to use Module  API which will allow to remove these files later:
https://bugs.openjdk.java.net/browse/JDK-8265091

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

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

From joe.darcy at oracle.com  Mon Apr 12 18:20:28 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 12 Apr 2021 11:20:28 -0700
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}(Internet mail)
In-Reply-To: <F7BB9A3B-454F-48A4-A8EB-83200E0C50CF@tencent.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
 <72184DF4-C63B-488F-8490-074247292022@tencent.com>
 <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>
 <F7BB9A3B-454F-48A4-A8EB-83200E0C50CF@tencent.com>
Message-ID: <e093136a-78ff-06f4-46ce-3b46c764ee03@oracle.com>

Hello,

Adding some additional context, more recent versions of the IEEE 754 
standard have given explicit recommendations for math library function 
definitions, including pow. The Java definitions of those methods long 
predate the IEEE 754 coverage and there are a small number of 
differences, including in the pow special cases. These differences are 
now described more explicitly in the JDK 17 specs as of

JDK-8240632: Note differences between IEEE 754-2019 math lib special 
cases and java.lang.Math

The difference in question for pow is:

> ???? * @apiNote
> ???? * The special cases definitions of this method differ from the
> ???? * special case definitions of the IEEE 754 recommended {@code
> ???? * pow} operation for &plusmn;{@code 1.0} raised to an infinite
> ???? * power. This method treats such cases as indeterminate and
> ???? * specifies a NaN is returned. The IEEE 754 specification treats
> ???? * the infinite power as a large integer (large-magnitude
> ???? * floating-point numbers are numerically integers, specifically
> ???? * even integers) and therefore specifies {@code 1.0} be returned.

There are no plans to align the Java definition of pow with the IEEE 754 
definition in these few cases.

Note that the Java library implementation of pow does delegate to sqrt 
while respecting the relevant special cases:

> ??????????? } else if (y == 0.5) {
> ??????????????? if (x >= -Double.MAX_VALUE) // Handle x == -infinity later
> ??????????????????? return Math.sqrt(x + 0.0); // Add 0.0 to properly 
> handle x == -0.0
https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L366

Mathematically, the sqrt function is about as pleasant a function as you 
can be asked to approximate in floating-point arithmetic. The function 
is smooth, doesn't overflow or underflow, and has a simple 
Newton-iteration that can be expressed in basic arithmetic operations. 
The pow function doesn't enjoy these properties and has a larger design 
space for what a reasonable floating-point approximation could be.

HTH,

-Joe

On 4/12/2021 6:39 AM, jiefu(??) wrote:
> Hi Raffaello,
>
> Thanks for your execllent analysis.
> I agree with you now.
> And I'll close the optimization PR [1] tomorrow if there is no objections.
>
> Thanks.
> Best regards,
> Jie
>
> [1] https://github.com/openjdk/jdk/pull/3404/
>
>
> ?On 2021/4/12, 9:06 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
>
>      Hi Jie,
>      
>      I don't think that changing the spec of Math.pow() to be misaligned with
>      IEEE 754 would be a wise option. IEEE is much more pervasive than Java.
>      There are many aspects in IEEE that might be seen as questionable, but
>      at least it is a widely adopted standard.
>      
>      AFAIU, the only reason you would like to "optimize" the special case of
>      y = 0.5 in pow(x, y) to return sqrt(x) is for performance, more accuracy
>      and some kind of consistency.
>      
>      But then, why not a special case for y = 0.25 as sqrt(sqrt(x))?
>      And what about y = 0.75? Should this be translated to sqrt(sqrt(pow(x, 3)))?
>      What about y = 1.0 / 3.0? Should this become cbrt(x)?
>      And why not consider y = 2.0 / 3.0 in a special rule: cbrt(x * x)?
>      
>      You see, the special cases can quickly become unmanageable. Also,
>      special rules would produce results which are "discontinuous" with
>      nearby exponents, like y = 0.5000000000000001.
>      
>      That's probably why IEEE doesn't propose translation rules for finite
>      numerical exponents that are not integers, except when x is a special value.
>      
>      
>      Greetings
>      Raffaello
>      
>      
>      
>      On 2021-04-12 13:44, jiefu(??) wrote:
>      > Hi Andrew H, Andrew D, and Raffaello,
>      >
>      > Thank you all for your kind reply and helpful comments.
>      >
>      > Now I got where the rules come from.
>      > But I don't think the IEEE standars are reasonable to specify conflits rules.
>      > Maybe, these computations should be open to be implementation dependent.
>      >
>      > (If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java.
>      > We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right?
>      > And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.
>      >
>      > Thanks.
>      > Best regards,
>      > Jie
>      >
>      >
>      > On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
>      >
>      >      Hi Jie,
>      >
>      >      the behavior you report is the one specified by the standard IEEE 754.
>      >      Java follows this standard as closely as it can.
>      >
>      >      The standard says that
>      >      * squareRoot(-0) = -0
>      >      * squareRoot(-?) = NaN
>      >
>      >      Also, the standard has a long lists of special cases for pow(x, y),
>      >      among them:
>      >      * pow(?0, y) is +0 for finite y > 0 and not an odd integer
>      >      * pow(-?, y) is +? for finite y > 0 and not an odd integer
>      >
>      >      Thus, the conflicts you observe originate in following the standard, not
>      >      by special Java rules.
>      >
>      >      Unfortunately, the IEEE standard does not explain the reasons for the
>      >      special rules. Some are obvious, some are not.
>      >
>      >
>      >      HTH
>      >      Raffaello
>      >
>      >
>      >      > Hi all,
>      >      >
>      >      > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
>      >      > ```
>      >      > Math.pow(-0.0, 0.5) = 0.0
>      >      > Math.sqrt(-0.0) = -0.0
>      >      >
>      >      > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
>      >      > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
>      >      > ```
>      >      >
>      >      > The reason is that both of pow and sqrt have special rules for these computations.
>      >      > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
>      >      > And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
>      >      > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
>      >      >
>      >      > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
>      >      >
>      >      > So why Java creates conflict special rules for them?
>      >      > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
>      >      >
>      >      > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
>      >      > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
>      >      >
>      >      > Thanks.
>      >      > Best regards,
>      >      > Jie
>      >
>      >
>      >
>      
>      
>

From dcubed at openjdk.java.net  Mon Apr 12 20:57:50 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 12 Apr 2021 20:57:50 GMT
Subject: RFR: 8264954: unified handling for VectorMask object
 re-materialization during de-optimization [v3]
In-Reply-To: <WNL_27olNI8kucH51BEgNekrTyIe0IvItWM_HYF2fjE=.8c5f8eed-a215-4f2d-a7c3-a39bd54c2dda@github.com>
References: <zyBgGfFj8zslEyOZ_WKS90QRnWP7uUcRe5FB0AV_gBM=.3f4bffe7-58f9-4434-987c-98aa01be4202@github.com>
 <WNL_27olNI8kucH51BEgNekrTyIe0IvItWM_HYF2fjE=.8c5f8eed-a215-4f2d-a7c3-a39bd54c2dda@github.com>
Message-ID: <Cbj1LlTe4Jdg7W-AjlTtfiAtlsuu05xLB81H6CNKZrg=.65802d2f-b3d2-492f-84e1-63bc633c496b@github.com>

On Mon, 12 Apr 2021 09:33:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Following flow describes object reconstruction for de-optimization:-
>> 1)	PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
>> 2)	During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
>> 3)	De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
>> 4)	During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings. 
>> 
>> By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.
>> 
>> tier1-tier3 regressions are clean with UseAVX=2/3.
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264954: Incorporating closing comments.

<Remove comment posted in error>

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

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

From erikj at openjdk.java.net  Mon Apr 12 20:58:35 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 12 Apr 2021 20:58:35 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <z8uXpkbdA-wiwrLpejc7CDO-er7i6IH3bxJ_xD-Ayl0=.f7d147c2-f0e1-4228-aed0-83023551afd9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <kVdFvMb_xK3q3FCB94V8aJbUpoEVsH3mjZFPP6JFy_0=.6bdcc9ec-33d4-4492-83bf-b728a0fce482@github.com>
 <z8uXpkbdA-wiwrLpejc7CDO-er7i6IH3bxJ_xD-Ayl0=.f7d147c2-f0e1-4228-aed0-83023551afd9@github.com>
Message-ID: <7HS0ES8bIxSFNXrIiGQRIgm5w30UQqGIHP7TmfWNDAg=.3a2af723-79ee-4ce8-9e1c-3873b09ed9c0@github.com>

On Mon, 12 Apr 2021 17:18:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> make/common/Modules.gmk line 68:
>> 
>>> 66: 
>>> 67: # Filter out Graal specific modules
>>> 68: MODULES_FILTER += jdk.internal.vm.compiler
>> 
>> If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all?
>
> We filter out because we can't build Graal anymore. But we need these module-info.java files because JVMCI's module-info.java references them:
> https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java#L26
> 
> Otherwise we can't build JVMCI which we continue to support.
> 
> I filed followup RFE to implement Alan's suggestion to use Module  API which will allow to remove these files later:
> https://bugs.openjdk.java.net/browse/JDK-8265091

Right, I thought I saw something about modules that Alan commented on, but couldn't find it. All good then.

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

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

From erikj at openjdk.java.net  Mon Apr 12 20:58:32 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 12 Apr 2021 20:58:32 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
Message-ID: <eA8Jvy2UDmoHFmXXl7iKHf1Rpye4jcGbcC_itITSyYI=.959320fc-e89a-4b74-b0ad-131fc2d962e6@github.com>

On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> 
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov 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 three additional commits since the last revision:
> 
>  - Restore Graal Builder image makefile
>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>  - 8264806: Remove the experimental JIT compiler

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From kvn at openjdk.java.net  Mon Apr 12 21:09:09 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 12 Apr 2021 21:09:09 GMT
Subject: Integrated: 8265084: [BACKOUT] 8264954: unified handling for
 VectorMask object re-materialization during de-optimization
Message-ID: <p1c2b3FtWXHZmDm1NF2cvfRU_bzBR0a8OaJPl0V_tU4=.ab9a44e8-ae38-4fe7-8701-f6726af54581@github.com>

JDK-8264954 changes caused failures on Aarch64 in Tier3 testing and needs to be backed out.

Tested tier1 and ran jdk/incubator/vector/ tests on linux-x64 and linux-aarch64 machines.

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

Commit messages:
 - 8265084: [BACKOUT] 8264954: unified handling for VectorMask object re-materialization during de-optimization

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

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

From dcubed at openjdk.java.net  Mon Apr 12 21:09:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 12 Apr 2021 21:09:10 GMT
Subject: Integrated: 8265084: [BACKOUT] 8264954: unified handling for
 VectorMask object re-materialization during de-optimization
In-Reply-To: <p1c2b3FtWXHZmDm1NF2cvfRU_bzBR0a8OaJPl0V_tU4=.ab9a44e8-ae38-4fe7-8701-f6726af54581@github.com>
References: <p1c2b3FtWXHZmDm1NF2cvfRU_bzBR0a8OaJPl0V_tU4=.ab9a44e8-ae38-4fe7-8701-f6726af54581@github.com>
Message-ID: <4IBHq8yAHwOPlx3eckA29DFOpxTREHTG8yNRh0VteOc=.5b09d422-8fb8-4348-ae9c-17af1be83c8d@github.com>

On Mon, 12 Apr 2021 18:46:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> JDK-8264954 changes caused failures on Aarch64 in Tier3 testing and needs to be backed out.
> 
> Tested tier1 and ran jdk/incubator/vector/ tests on linux-x64 and linux-aarch64 machines.

This appears to be an accurate [BACKOUT] of the original patch.

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

Marked as reviewed by dcubed (Reviewer).

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

From kvn at openjdk.java.net  Mon Apr 12 21:09:11 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 12 Apr 2021 21:09:11 GMT
Subject: Integrated: 8265084: [BACKOUT] 8264954: unified handling for
 VectorMask object re-materialization during de-optimization
In-Reply-To: <p1c2b3FtWXHZmDm1NF2cvfRU_bzBR0a8OaJPl0V_tU4=.ab9a44e8-ae38-4fe7-8701-f6726af54581@github.com>
References: <p1c2b3FtWXHZmDm1NF2cvfRU_bzBR0a8OaJPl0V_tU4=.ab9a44e8-ae38-4fe7-8701-f6726af54581@github.com>
Message-ID: <t-C3TkEO45yZ-zHxQ3YmKPOXK7fJArcrWvDc29E-dcE=.671c2751-da0c-4f3a-9d36-42906dc3c080@github.com>

On Mon, 12 Apr 2021 18:46:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> JDK-8264954 changes caused failures on Aarch64 in Tier3 testing and needs to be backed out.
> 
> Tested tier1 and ran jdk/incubator/vector/ tests on linux-x64 and linux-aarch64 machines.

This pull request has now been integrated.

Changeset: 18bec9cf
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18bec9cf
Stats:     66 lines in 3 files changed: 22 ins; 22 del; 22 mod

8265084: [BACKOUT] 8264954: unified handling for VectorMask object re-materialization during de-optimization

Reviewed-by: dcubed

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

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

From dholmes at openjdk.java.net  Mon Apr 12 21:55:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 12 Apr 2021 21:55:58 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v2]
In-Reply-To: <HK7GdPI2uU37ss48YqxCbuQciSaYNxNAGC-y9cswY7I=.afab90a2-16c2-4d69-95cc-37db04f5968e@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <uDil0eWh2xOe2h7napvVnjoddYii22KkL35xdWQnkaI=.42760eec-aad3-4b52-a0aa-9bae04186126@github.com>
 <HK7GdPI2uU37ss48YqxCbuQciSaYNxNAGC-y9cswY7I=.afab90a2-16c2-4d69-95cc-37db04f5968e@github.com>
Message-ID: <GHJwRgaDx-9vUMGsoeUS-pxip0tzDvHl6Tr0avIrAuY=.512e183e-180c-4b80-981d-f2839edf28aa@github.com>

On Thu, 8 Apr 2021 13:00:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed CHECK on return statement.
>
> I think substituting "JavaThread* thread" for "JavaThread* current" is a good change and convention that makes the code more clear, so worth the dull code review and diffs.

Thanks for the reviews @coleenp , @hseigel  and @iklam .

Can someone from compiler team please take a look and give the okay? (I know things are a bit busy at the moment.)

Thanks,
David

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

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

From kvn at openjdk.java.net  Mon Apr 12 22:10:06 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 12 Apr 2021 22:10:06 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v3]
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <tXz08rqVPR_leQJMDGrYd4-Z-CrN8vIX105a8Z-GFho=.4b53feba-294e-4a9d-8b6a-d5cdcfaa1367@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> 
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Restore Compiler::isGraalEnabled()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3421/files
  - new: https://git.openjdk.java.net/jdk/pull/3421/files/a246aaa6..9d6bd42c

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

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

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

From kvn at openjdk.java.net  Mon Apr 12 22:26:09 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 12 Apr 2021 22:26:09 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
Message-ID: <PgueLCQ0HYg5vnvL4zYYrWZbPJbH78CtDkWEr41dBDM=.34bbd71a-990d-47eb-9b1c-10868501c12d@github.com>

On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Vladimir Kozlov 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 three additional commits since the last revision:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important.

@dougxc  I restored Compiler::isGraalEnabled().

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

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

From jiefu at tencent.com  Tue Apr 13 01:26:02 2021
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Tue, 13 Apr 2021 01:26:02 +0000
Subject: Conflict API definitions of Math.pow(x, 0.5) and Math.sqrt(x) for
 x={-0.0, Double.NEGATIVE_INFINITY}(Internet mail)
In-Reply-To: <e093136a-78ff-06f4-46ce-3b46c764ee03@oracle.com>
References: <f5583eec-347d-1e36-2b0e-2266eac8e02d@gmail.com>
 <72184DF4-C63B-488F-8490-074247292022@tencent.com>
 <05560ff3-7ea3-6e4d-ff0f-b25358b7f7b7@gmail.com>
 <F7BB9A3B-454F-48A4-A8EB-83200E0C50CF@tencent.com>
 <e093136a-78ff-06f4-46ce-3b46c764ee03@oracle.com>
Message-ID: <0545E3C5-7216-4F39-AF95-D8854CA6B84E@tencent.com>

Hi Joe,

Thanks for your nice sharing.

Very glad to know that the Java library implementation of pow does delegate to sqrt while respecting the relevant special cases.
This implementation [1] has set a good example for us which means it's safe to replace pow(x, 0.5) with sqrt(x) for all x > 0.0.

Thanks
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L366


?On 2021/4/13, 2:21 AM, "Joe Darcy" <joe.darcy at oracle.com> wrote:

    Hello,
    
    Adding some additional context, more recent versions of the IEEE 754 
    standard have given explicit recommendations for math library function 
    definitions, including pow. The Java definitions of those methods long 
    predate the IEEE 754 coverage and there are a small number of 
    differences, including in the pow special cases. These differences are 
    now described more explicitly in the JDK 17 specs as of
    
    JDK-8240632: Note differences between IEEE 754-2019 math lib special 
    cases and java.lang.Math
    
    The difference in question for pow is:
    
    >      * @apiNote
    >      * The special cases definitions of this method differ from the
    >      * special case definitions of the IEEE 754 recommended {@code
    >      * pow} operation for &plusmn;{@code 1.0} raised to an infinite
    >      * power. This method treats such cases as indeterminate and
    >      * specifies a NaN is returned. The IEEE 754 specification treats
    >      * the infinite power as a large integer (large-magnitude
    >      * floating-point numbers are numerically integers, specifically
    >      * even integers) and therefore specifies {@code 1.0} be returned.
    
    There are no plans to align the Java definition of pow with the IEEE 754 
    definition in these few cases.
    
    Note that the Java library implementation of pow does delegate to sqrt 
    while respecting the relevant special cases:
    
    >             } else if (y == 0.5) {
    >                 if (x >= -Double.MAX_VALUE) // Handle x == -infinity later
    >                     return Math.sqrt(x + 0.0); // Add 0.0 to properly 
    > handle x == -0.0
    https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L366
    
    Mathematically, the sqrt function is about as pleasant a function as you 
    can be asked to approximate in floating-point arithmetic. The function 
    is smooth, doesn't overflow or underflow, and has a simple 
    Newton-iteration that can be expressed in basic arithmetic operations. 
    The pow function doesn't enjoy these properties and has a larger design 
    space for what a reasonable floating-point approximation could be.
    
    HTH,
    
    -Joe
    
    On 4/12/2021 6:39 AM, jiefu(??) wrote:
    > Hi Raffaello,
    >
    > Thanks for your execllent analysis.
    > I agree with you now.
    > And I'll close the optimization PR [1] tomorrow if there is no objections.
    >
    > Thanks.
    > Best regards,
    > Jie
    >
    > [1] https://github.com/openjdk/jdk/pull/3404/
    >
    >
    > On 2021/4/12, 9:06 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
    >
    >      Hi Jie,
    >      
    >      I don't think that changing the spec of Math.pow() to be misaligned with
    >      IEEE 754 would be a wise option. IEEE is much more pervasive than Java.
    >      There are many aspects in IEEE that might be seen as questionable, but
    >      at least it is a widely adopted standard.
    >      
    >      AFAIU, the only reason you would like to "optimize" the special case of
    >      y = 0.5 in pow(x, y) to return sqrt(x) is for performance, more accuracy
    >      and some kind of consistency.
    >      
    >      But then, why not a special case for y = 0.25 as sqrt(sqrt(x))?
    >      And what about y = 0.75? Should this be translated to sqrt(sqrt(pow(x, 3)))?
    >      What about y = 1.0 / 3.0? Should this become cbrt(x)?
    >      And why not consider y = 2.0 / 3.0 in a special rule: cbrt(x * x)?
    >      
    >      You see, the special cases can quickly become unmanageable. Also,
    >      special rules would produce results which are "discontinuous" with
    >      nearby exponents, like y = 0.5000000000000001.
    >      
    >      That's probably why IEEE doesn't propose translation rules for finite
    >      numerical exponents that are not integers, except when x is a special value.
    >      
    >      
    >      Greetings
    >      Raffaello
    >      
    >      
    >      
    >      On 2021-04-12 13:44, jiefu(??) wrote:
    >      > Hi Andrew H, Andrew D, and Raffaello,
    >      >
    >      > Thank you all for your kind reply and helpful comments.
    >      >
    >      > Now I got where the rules come from.
    >      > But I don't think the IEEE standars are reasonable to specify conflits rules.
    >      > Maybe, these computations should be open to be implementation dependent.
    >      >
    >      > (If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java.
    >      > We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right?
    >      > And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.
    >      >
    >      > Thanks.
    >      > Best regards,
    >      > Jie
    >      >
    >      >
    >      > On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <raffaello.giulietti at gmail.com> wrote:
    >      >
    >      >      Hi Jie,
    >      >
    >      >      the behavior you report is the one specified by the standard IEEE 754.
    >      >      Java follows this standard as closely as it can.
    >      >
    >      >      The standard says that
    >      >      * squareRoot(-0) = -0
    >      >      * squareRoot(-?) = NaN
    >      >
    >      >      Also, the standard has a long lists of special cases for pow(x, y),
    >      >      among them:
    >      >      * pow(?0, y) is +0 for finite y > 0 and not an odd integer
    >      >      * pow(-?, y) is +? for finite y > 0 and not an odd integer
    >      >
    >      >      Thus, the conflicts you observe originate in following the standard, not
    >      >      by special Java rules.
    >      >
    >      >      Unfortunately, the IEEE standard does not explain the reasons for the
    >      >      special rules. Some are obvious, some are not.
    >      >
    >      >
    >      >      HTH
    >      >      Raffaello
    >      >
    >      >
    >      >      > Hi all,
    >      >      >
    >      >      > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following:
    >      >      > ```
    >      >      > Math.pow(-0.0, 0.5) = 0.0
    >      >      > Math.sqrt(-0.0) = -0.0
    >      >      >
    >      >      > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
    >      >      > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
    >      >      > ```
    >      >      >
    >      >      > The reason is that both of pow and sqrt have special rules for these computations.
    >      >      > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0.
    >      >      > And this one [2] specifies Math.sqrt(-0.0) must be -0.0.
    >      >      > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too.
    >      >      >
    >      >      > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x).
    >      >      >
    >      >      > So why Java creates conflict special rules for them?
    >      >      > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed?
    >      >      >
    >      >      > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x).
    >      >      > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3].
    >      >      >
    >      >      > Thanks.
    >      >      > Best regards,
    >      >      > Jie
    >      >
    >      >
    >      >
    >      
    >      
    >
    
    
    


From yyang at openjdk.java.net  Tue Apr 13 03:16:58 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 13 Apr 2021 03:16:58 GMT
Subject: RFR: 8263790: C2: new igv_print_immediately() for debugging
 purpose
In-Reply-To: <hBPJff7i-WJJNJjbhv739WqCdPj1rLJ8ant1VOI-Y24=.d3a7db1f-c138-4c4c-b7b9-f0e235932585@github.com>
References: <hBPJff7i-WJJNJjbhv739WqCdPj1rLJ8ant1VOI-Y24=.d3a7db1f-c138-4c4c-b7b9-f0e235932585@github.com>
Message-ID: <XuV6rs8FIlKw9hk-O1hiNxNPQ00AOPhDJxtE5nseXXk=.46320c05-7b0e-4f01-826f-3a4f1952ae01@github.com>

On Thu, 18 Mar 2021 10:05:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Add a new igv_print_immediately, it prints the current method immediately. This differs from other igv_print* methods, it creates a well-formed and complete ideal graph xml immediately, while others accomplish their ideal graph xml when VM exists (i.e. destructor of `IdealGraphPrinter::_xx_printer`). If VM crashes before VM exit, the ideal graph xml will be ill-formed, this is fairly a common case when debugging another crash.
> 
> Test manually!
> 
> Cheers,
> Yang

> > In the catch clause, ex.getMessage() compares with ASCII characters, but ex.getMessage()gets characters that corresponding to their system locale settings. To support non-English system locale settings(if needed), we could code something like this:
> > ```java
> >      if (!(ex instanceof SAXParseException) || !"XML document structures must start and end within the same entity.".equals(disable_i18n(ex.getMessage())))
> > ```
> 
> That makes sense, can you please try if this fix works for you? [robcasloz at 702e763](https://github.com/robcasloz/jdk/commit/702e763)
> 
> If it does, please feel free to re-purpose this issue with the proposed fix (once #3361 is integrated), and with a test case that parses an incomplete XML document in `src/utils/IdealGraphVisualizer/Data/src/test/java/com/sun/hotspot/igv/data/serialization/ParserTest.java`. Please make sure to test in on different JDK versions (I suggest JDK 8, 11, and 15).

Thank you @robcasloz, I can verify it on the weekend. In order to not disturb others, I'd like to close this PR and I have filed this as https://bugs.openjdk.java.net/browse/JDK-8265106.

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

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

From yyang at openjdk.java.net  Tue Apr 13 03:16:59 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 13 Apr 2021 03:16:59 GMT
Subject: Withdrawn: 8263790: C2: new igv_print_immediately() for debugging
 purpose
In-Reply-To: <hBPJff7i-WJJNJjbhv739WqCdPj1rLJ8ant1VOI-Y24=.d3a7db1f-c138-4c4c-b7b9-f0e235932585@github.com>
References: <hBPJff7i-WJJNJjbhv739WqCdPj1rLJ8ant1VOI-Y24=.d3a7db1f-c138-4c4c-b7b9-f0e235932585@github.com>
Message-ID: <8Xr30HdfeM42JQOKfeX6Kh0WPEEI3APNGE58mVnrC38=.8d31d6fb-7740-4392-bd28-68ed1d8ce042@github.com>

On Thu, 18 Mar 2021 10:05:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Add a new igv_print_immediately, it prints the current method immediately. This differs from other igv_print* methods, it creates a well-formed and complete ideal graph xml immediately, while others accomplish their ideal graph xml when VM exists (i.e. destructor of `IdealGraphPrinter::_xx_printer`). If VM crashes before VM exit, the ideal graph xml will be ill-formed, this is fairly a common case when debugging another crash.
> 
> Test manually!
> 
> Cheers,
> Yang

This pull request has been closed without being integrated.

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

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

From xgong at openjdk.java.net  Tue Apr 13 03:21:21 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 03:21:21 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
Message-ID: <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>

> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
> 
> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
> 
>   VectorLoadMask (VectorStoreMask vmask)
> 
> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
> vectors with the same element size and vector length, it's safe to do the optimization:
> 
>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
> 
> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Use "Matcher::match_rule_supported_vector" for vector nodes checking

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3238/files
  - new: https://git.openjdk.java.net/jdk/pull/3238/files/ce3577ae..977787e4

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

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

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

From xgong at openjdk.java.net  Tue Apr 13 04:16:58 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 04:16:58 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v2]
In-Reply-To: <srkN3wp5Zywh9UdwW1ZfoFzGJQ4jk0G7Fgu7wiTXct8=.5a4fa626-22ed-4891-9b48-4eab60911a2e@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <oUtNbu91aeyJNcbafgB5-R4qD1I5Lkk4shXvHWkxyK4=.41b41aa7-fa4c-4969-8118-37c310983bc8@github.com>
 <RV2r7e15ksBiQa__sDVH8r-WVAEiO32FdB7fVt0Sak8=.98741436-1a90-41ca-9ea7-6682a6f7dd60@github.com>
 <XsBTy3IFrhUJsdkHQKKd-95_F3pNGY0994st5krllcw=.dea9a899-c9f6-4a03-b925-c366e9c17285@github.com>
 <hv5FOW1N_YN_ow02GjYEmOQSxD6sAWFNa8cmB960s4c=.816fa680-6418-4ebd-a56f-5298005db102@github.com>
 <srkN3wp5Zywh9UdwW1ZfoFzGJQ4jk0G7Fgu7wiTXct8=.5a4fa626-22ed-4891-9b48-4eab60911a2e@github.com>
Message-ID: <2lJG4-6hFiftQkaVD0mthu9hLUPDSO1hwsJzlx4uPLk=.64989e5d-be84-418c-b284-d1ede3544663@github.com>

On Thu, 8 Apr 2021 10:14:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> @iwanowww should confirm correctness of such optimization.
>>> Regarding changes - they seem fine to me. I notice that VectorNode and its subclasses do not check for TOP inputs. Since Vector API introduce vectors in graph before SuperWord transformation their input could become dead. How such cases handled? And why we did not hit them yet? is_vect() should hit assert.
>> 
>> Thanks for looking at this PR @vnkozlov . To be honest, I'v no idea about the TOP checking issue to the inputs of the VectorNode. Hope @iwanowww  could explain more. Thanks!
>
>>  I notice that VectorNode and its subclasses do not check for TOP inputs. 
>> Since Vector API introduce vectors in graph before SuperWord transformation their input could become dead. 
>> How such cases handled? And why we did not hit them yet? is_vect() should hit assert.
> 
> `VectorLoadMaskNode::Identity()` can't observe TOP types because it uses the type cached at construction (`type()` and `VectorNode` extends `TypeNode`). Still, a TOP input is possible and should be filtered out by opcode check (`in(1)->Opcode() == Op_VectorStoreMask`).

Hi @iwanowww , all your review comments have been addressed. Would you mind having a look at it again? Thanks!

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

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

From xgong at openjdk.java.net  Tue Apr 13 04:16:58 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 04:16:58 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v3]
In-Reply-To: <OxDlkWga5vddXNeLjqtj5OwbB25mNf9_kino0snKVnI=.3f4b9590-2b4d-48a5-b414-3e2ad5b44634@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <JS7xbPOO9_TvNFy5zehs4KwZCYuKU8VYbmQ3UdXd708=.35d0b172-a69e-4b96-b356-18ba34d3b77e@github.com>
 <Iyitokh4QpeTPElt7Ad2Q_np96M9PGj449rEakcGkc4=.5ac1d23d-4445-43d9-8eca-49463102e7ee@github.com>
 <aksQ5VA2DukLD2B4SNkxMxmEJBQS7VG-JnZnCWaF9m8=.6a54ce2f-7c88-4d55-b125-fcefa27533c5@github.com>
 <OxDlkWga5vddXNeLjqtj5OwbB25mNf9_kino0snKVnI=.3f4b9590-2b4d-48a5-b414-3e2ad5b44634@github.com>
Message-ID: <s7qbpe5drt0kL4nBYB9oIX3VeFAOUNrDG0yewZMpNkk=.cb20ea55-ed5d-4ca1-ad4b-69801557bf58@github.com>

On Mon, 12 Apr 2021 16:50:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Thanks for your comments. Yes, theoretically it's better to place it in `VectorLoadMaskNode::Ideal()`. Unfortunately, we met an issue that is related to optimization for `VectorStoreMask`. Considering the following case:
>> 
>>    LoadVector                                              LoadVector
>>            |                                                    |
>>    VectorLoadMask  (double)                          VectorLoadMask (double)
>>                |                                               |
>>            VectorUnbox   (long)          ==>           VectorStoreMask  (double)
>>                                                                |
>>                                                       VectorLoadMask  (long)
>> 
>> This case loads the masking values for a double type, and does a bitwise `and` operation. Since the type is mismatched, the compiler will try to do `VectorUnbox (VectorBox vmask) ==> VectorLoadMask (VectorStoreMask vmask)`. However, since there is the transformation `VectorStoreMask (VectorLoadMask value)  ==> value`, the above `VectorStoreMaskNode` will be optimized out. The final graph looks like:
>> 
>> 
>>    LoadVector                                                  LoadVector
>>           |                                                      /      \
>>         VectorLoadMask  (double)                               /         \
>>               |                      ==>     VectorLoadMask (double)      \
>>          VectorStoreMask (double)                                   VectorLoadMask (long)
>>                    |
>>             VectorLoadMask (long)
>> 
>> Since the two `VectorLoadMaskNode` have different element type, the GVN cannot optimize out one. So finally there will be two similar  `VectorLoadMaskNode`s. That's also why I override the `cmp/hash` for `VectorLoadMaskNode` in the first version.
>> 
>> So I prefer to add `VectorUnbox (VectorBox vmask) ==> VectorMaskCast (vmask)` directly.
>
> Ok, so you face a transformation ordering problem here. 
> 
> By working on `VectorUnbox (VectorBox vmask)` you effectively delay `VectorStoreMask (VectorLoadMask vmask) => vmask` transformation.
> 
> As an alternative you could:
> 
> (1) check for `VectorLoadMask` users before applying `VectorStoreMask (VectorLoadMask vmask) => vmask`;
> 
> (2) nest adjacent casts: 
> 
> VectorLoadMask #double (1 LoadVector)
> VectorLoadMask #long   (1 LoadVector)
> ==>
> VectorMaskCast #long (VectorLoadMask #double (1 LoadVector)
> 
> 
> The latter looks more powerful (and hence preferrable), but I'm fine with what you have right now. (It can be enhanced later.)
> Please, leave a comment describing the motivation for doing the transformation directly on `VectorUnbox (VectorBox ...)`.

Thanks for your alternative advice! I prefer to keep the code as it is right now. Also the comments have been added. Thanks!

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

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

From xgong at openjdk.java.net  Tue Apr 13 04:16:59 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 04:16:59 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v3]
In-Reply-To: <P_A2ViU-DOS9mY2L1OMjQdkU-W81AJtnl_sQLm3Jan8=.a350d148-d85a-4bc2-a129-aec2c1350892@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <JS7xbPOO9_TvNFy5zehs4KwZCYuKU8VYbmQ3UdXd708=.35d0b172-a69e-4b96-b356-18ba34d3b77e@github.com>
 <Iyitokh4QpeTPElt7Ad2Q_np96M9PGj449rEakcGkc4=.5ac1d23d-4445-43d9-8eca-49463102e7ee@github.com>
 <aksQ5VA2DukLD2B4SNkxMxmEJBQS7VG-JnZnCWaF9m8=.6a54ce2f-7c88-4d55-b125-fcefa27533c5@github.com>
 <JA2Eqaq2YGX9rG0gTqH9nhbRYEB7OUkq7svmbUctoWw=.a8add179-569d-4167-a6d0-18c063d026a3@github.com>
 <P_A2ViU-DOS9mY2L1OMjQdkU-W81AJtnl_sQLm3Jan8=.a350d148-d85a-4bc2-a129-aec2c1350892@github.com>
Message-ID: <2hVkatGHq3Sdxeba9QrM3VVSEth1uaoYFDdUrojGyKQ=.004ae672-bdbc-45b3-bbfc-b16a55ad6390@github.com>

On Mon, 12 Apr 2021 15:09:56 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I met the bad AD file issue when I remove the changes in AD files and overriding `Node::ideal_reg()`. I guess if a node is not used as an input of other node, this can work well? For the `VectorMaskCastNode`, it must be an input for some other nodes. If just disable the matching of this node, how does its usage find the right input code?
>
> Yeah, `ideal_reg() { return 0; }` won't work here. Sorry for the misleading suggestion.

That's ok. Thanks!

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

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

From xgong at openjdk.java.net  Tue Apr 13 06:39:18 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 06:39:18 GMT
Subject: RFR: 8264957: Type::dual_type array is not aligned with enum
 TYPES [v2]
In-Reply-To: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
Message-ID: <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>

> This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.
> 
> I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
> 
>  Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
>  # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
> 
> Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8262355
> 
> Tested with tier1 and jdk:tier3

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Remove array Type::dual_type

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3410/files
  - new: https://git.openjdk.java.net/jdk/pull/3410/files/b1c68018..28df8046

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

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

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

From xgong at openjdk.java.net  Tue Apr 13 06:39:19 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 06:39:19 GMT
Subject: RFR: 8264957: Type::dual_type array is not aligned with enum
 TYPES [v2]
In-Reply-To: <jVzalT5mDb_J5KMrQduJMHNfhT1vKAdndNuN3jW3d9I=.e8056bc5-56e8-460c-ae89-6160510876bc@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
 <jVzalT5mDb_J5KMrQduJMHNfhT1vKAdndNuN3jW3d9I=.e8056bc5-56e8-460c-ae89-6160510876bc@github.com>
Message-ID: <yJh09iDN0c-qkVDvIfQA3C1PQtV6sxvy-vwCH4g8Cmg=.b9546877-8f06-4b46-9435-97bc8cfcc9f7@github.com>

On Fri, 9 Apr 2021 11:02:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove array Type::dual_type
>
> This sounds reasonable to me.
> Thanks.

Hi, the array `Type:;dual_type` is totally removed. Tested `hotspot:hotspot_all_no_apps, langtools:tier1, jdk:jdk_core and jdk:tier3` internally. Would you mind having a look at it again @DamonFool @neliasso ? Thanks so much!

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

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

From jiefu at openjdk.java.net  Tue Apr 13 07:03:04 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 13 Apr 2021 07:03:04 GMT
Subject: RFR: 8264957: Type::dual_type array is not aligned with enum
 TYPES [v2]
In-Reply-To: <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
 <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
Message-ID: <qDRiMbWaWz5EMC3q2Fqg5YizEZiL_Bcp4TuQRbE2SzA=.70d65bde-5eb8-4267-9348-05780ac66e9e@github.com>

On Tue, 13 Apr 2021 06:39:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.
>> 
>> I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
>> 
>>  Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
>>  # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
>> 
>> Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8262355
>> 
>> Tested with tier1 and jdk:tier3
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove array Type::dual_type

I didn't find the usage of that array either.
So the change looks fine to me.

I'm afraid the JBS needs to be updated as a cleanup issue.
Thanks.

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

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

From xgong at openjdk.java.net  Tue Apr 13 07:05:57 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 07:05:57 GMT
Subject: RFR: 8264957: Type::dual_type array is not aligned with enum
 TYPES [v2]
In-Reply-To: <qDRiMbWaWz5EMC3q2Fqg5YizEZiL_Bcp4TuQRbE2SzA=.70d65bde-5eb8-4267-9348-05780ac66e9e@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
 <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
 <qDRiMbWaWz5EMC3q2Fqg5YizEZiL_Bcp4TuQRbE2SzA=.70d65bde-5eb8-4267-9348-05780ac66e9e@github.com>
Message-ID: <ZndBowpaA0PavrN9Pnv8leI1iwhd7PPVDaJE3zOA4g4=.6b154492-a0da-41fd-a432-a68c9c62c39e@github.com>

On Tue, 13 Apr 2021 06:59:46 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> I didn't find the usage of that array either.
> So the change looks fine to me.
> 
> I'm afraid the JBS needs to be updated as a cleanup issue.
> Thanks.

Seems reasonable. I will update the JBS and the PR title. Thanks!

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

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

From jiefu at openjdk.java.net  Tue Apr 13 07:31:59 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 13 Apr 2021 07:31:59 GMT
Subject: RFR: 8264957: Cleanup unused array Type::dual_type [v2]
In-Reply-To: <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
 <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
Message-ID: <T-VMwaSCTRLbG8du8A4XR6-n5fmVBmLoUAzjJPPGNkg=.a7b489d8-4ceb-4dee-b8ce-c50bb613507d@github.com>

On Tue, 13 Apr 2021 06:39:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.
>> 
>> I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
>> 
>>  Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
>>  # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
>> 
>> Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8262355
>> 
>> Tested with tier1 and jdk:tier3
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove array Type::dual_type

Thanks for your update.

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

Marked as reviewed by jiefu (Committer).

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

From thartmann at openjdk.java.net  Tue Apr 13 07:39:59 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 13 Apr 2021 07:39:59 GMT
Subject: RFR: 8264957: Cleanup unused array Type::dual_type [v2]
In-Reply-To: <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
 <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
Message-ID: <cCwIB4SGlCzXBntnl3STkMsJy8If8FYK7LTuNPldWV0=.bc5c61fd-d187-4677-a7f7-282045d099f8@github.com>

On Tue, 13 Apr 2021 06:39:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.
>> 
>> I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
>> 
>>  Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
>>  # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
>> 
>> Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8262355
>> 
>> Tested with tier1 and jdk:tier3
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove array Type::dual_type

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From xgong at openjdk.java.net  Tue Apr 13 07:40:00 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 07:40:00 GMT
Subject: RFR: 8264957: Cleanup unused array Type::dual_type [v2]
In-Reply-To: <qDRiMbWaWz5EMC3q2Fqg5YizEZiL_Bcp4TuQRbE2SzA=.70d65bde-5eb8-4267-9348-05780ac66e9e@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
 <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
 <qDRiMbWaWz5EMC3q2Fqg5YizEZiL_Bcp4TuQRbE2SzA=.70d65bde-5eb8-4267-9348-05780ac66e9e@github.com>
Message-ID: <iafq4VweXg9wp-RHb8eP4l7b2k-2e3v3Rpj3etsdztk=.7118f216-2630-49d1-9a19-79fc17b0c044@github.com>

On Tue, 13 Apr 2021 06:59:46 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove array Type::dual_type
>
> I didn't find the usage of that array either.
> So the change looks fine to me.
> 
> I'm afraid the JBS needs to be updated as a cleanup issue.
> Thanks.

Thanks for the review @DamonFool @TobiHartmann !

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

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

From neliasso at openjdk.java.net  Tue Apr 13 07:46:05 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 13 Apr 2021 07:46:05 GMT
Subject: RFR: 8264957: Cleanup unused array Type::dual_type [v2]
In-Reply-To: <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
 <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
Message-ID: <wbbPuAuuw4BQ89-x44F_xK5akcLhj-iPhWHq-32jd9U=.ba6ab6b6-cb97-4970-bbbe-d86441d79234@github.com>

On Tue, 13 Apr 2021 06:39:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.
>> 
>> I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
>> 
>>  Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
>>  # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
>> 
>> Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8262355
>> 
>> Tested with tier1 and jdk:tier3
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove array Type::dual_type

Marked as reviewed by neliasso (Reviewer).

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

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

From xgong at openjdk.java.net  Tue Apr 13 07:46:07 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 07:46:07 GMT
Subject: RFR: 8264957: Cleanup unused array Type::dual_type [v2]
In-Reply-To: <wbbPuAuuw4BQ89-x44F_xK5akcLhj-iPhWHq-32jd9U=.ba6ab6b6-cb97-4970-bbbe-d86441d79234@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
 <uYmiR-gIaHUOPPi3GoVTqlc07d8LsaI_nr7HkF2tLrU=.5b90bffb-1bd3-4afc-bd92-def1f422489e@github.com>
 <wbbPuAuuw4BQ89-x44F_xK5akcLhj-iPhWHq-32jd9U=.ba6ab6b6-cb97-4970-bbbe-d86441d79234@github.com>
Message-ID: <khgH9MLVgdo0jqBn1RmVGTEQmB9VQ3IF5L3yQYILCqs=.209ae8ca-0e68-4bba-9fe9-ccd7897e9e1c@github.com>

On Tue, 13 Apr 2021 07:41:38 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove array Type::dual_type
>
> Marked as reviewed by neliasso (Reviewer).

Thanks for the review @neliasso !

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

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

From rcastanedalo at openjdk.java.net  Tue Apr 13 09:27:58 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 13 Apr 2021 09:27:58 GMT
Subject: RFR: 8264795: IGV: Upgrade NetBeans platform [v2]
In-Reply-To: <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
 <SPMOAbmEZ2eslrkE0dd5pdAEJzyJ3dTSQ9zJVvo3SFo=.0d4cd6f5-0e96-44a6-8bd1-7fff0775fc0f@github.com>
Message-ID: <Z1iLAvq8ubx_B3EQbauLVeA3fCpFTOv0BqEYbZHqGi8=.d98efcbb-d71c-4ce4-a0d1-e6b24c913a83@github.com>

On Wed, 7 Apr 2021 11:59:28 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).
>> 
>> The change also fixes broken unit tests in the Data module and runs them by default when building.
>> 
>> #### Testing
>> 
>> Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):
>> 
>> - build
>> - open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
>> - import graphs via network (localhost)
>> - expand groups in outline
>> - open a graph
>> - open a clone
>> - zoom in and out
>> - search a node
>> - apply filters
>> - extract a node
>> - show all nodes
>> - select nodes corresponding to a bytecode
>> - view control flow
>> - select nodes corresponding to a basic block
>> - cluster nodes
>> - show satellite view
>> - compute the difference of two graphs
>> - change node text
>> - remove a group
>> - save groups into a file
>> - open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
>> - open a large graph ("After Escape Analysis" in large.xml)
>> 
>> Thanks to Vladimir Ivanov for helping with testing on macOS.
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Document how to build and run on a specific JDK
>  - Use lambdas to define runnables
>  - Document latest JDK version supported

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

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

From rcastanedalo at openjdk.java.net  Tue Apr 13 09:30:58 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 13 Apr 2021 09:30:58 GMT
Subject: Integrated: 8264795: IGV: Upgrade NetBeans platform
In-Reply-To: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
References: <vujF0LbPiU6IuRpGQWFsuElsK8YaCmkEzVKX6PludKU=.62043bec-fb05-4b99-aba0-e7d572f280e9@github.com>
Message-ID: <oYyQQcb3dXEjtV0lILjhuSkpxLogxHm-yjlP-tdzkCM=.abc21f6c-cac8-48da-9c9e-1ad962bee65c@github.com>

On Tue, 6 Apr 2021 18:34:54 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change upgrades the NetBeans platform on which IGV is based to its latest version ([12.3](https://netbeans.apache.org/download/nb123/index.html)) and switches IGV's build system from Ant to Maven. The upgrade introduces support for a wide range of JDK versions (from 8 to 15, the latest version supported by NetBeans 12.3), and the switch from Ant to Maven makes the IGV build simpler, faster (first-time build is approximately 5x faster), and more stable (all dependencies are fetched directly from the Maven central repository).
> 
> The change also fixes broken unit tests in the Data module and runs them by default when building.
> 
> #### Testing
> 
> Regression-tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 8, JDK 11, JDK 15):
> 
> - build
> - open graph file (small.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - import graphs via network (localhost)
> - expand groups in outline
> - open a graph
> - open a clone
> - zoom in and out
> - search a node
> - apply filters
> - extract a node
> - show all nodes
> - select nodes corresponding to a bytecode
> - view control flow
> - select nodes corresponding to a basic block
> - cluster nodes
> - show satellite view
> - compute the difference of two graphs
> - change node text
> - remove a group
> - save groups into a file
> - open a large graph file (large.xml in [test-input.zip](https://bugs.openjdk.java.net/secure/attachment/93988/test-input.zip))
> - open a large graph ("After Escape Analysis" in large.xml)
> 
> Thanks to Vladimir Ivanov for helping with testing on macOS.

This pull request has now been integrated.

Changeset: 954b9a1c
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/954b9a1c
Stats:     5940 lines in 499 files changed: 2727 ins; 3110 del; 103 mod

8264795: IGV: Upgrade NetBeans platform

Upgrade IGV's underlying NetBeans platform to version 12.3, switch build system
from Ant to Maven, and fix broken unit tests in Data module.

Reviewed-by: kvn, chagedorn, neliasso, xliu

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

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

From dnsimon at openjdk.java.net  Tue Apr 13 09:33:11 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 13 Apr 2021 09:33:11 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
Message-ID: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>

On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Vladimir Kozlov 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 three additional commits since the last revision:
>> 
>>  - Restore Graal Builder image makefile
>>  - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
>>  - 8264806: Remove the experimental JIT compiler
>
> We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important.

> @dougxc I restored Compiler::isGraalEnabled().

Thanks. I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later).

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

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

From xgong at openjdk.java.net  Tue Apr 13 10:01:59 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 13 Apr 2021 10:01:59 GMT
Subject: Integrated: 8264957: Cleanup unused array Type::dual_type
In-Reply-To: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
References: <Thqxw33PO3tBZhZ6rXhg1M0rb5Lk1gifPo_AAlX85P4=.ff1e8142-9344-4dce-a118-27d9a3fe703a@github.com>
Message-ID: <KVRFKshr4zObAtNX7mOv38WwI3D2j51tTGEnRIUkjMs=.744c41db-2c8b-4f9c-b5a1-a5b161a402b7@github.com>

On Fri, 9 Apr 2021 10:04:10 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> This is a bug fix for [1] which adds a new vector mask type. The new added TYPE `"VectorMask"` is inserted into `enum TYPES`, while the array `"Type::dual_type"` is not updated. This makes the array elements are not aligned with TYPES.
> 
> I met the following crash due to this issue when I was working on the masking feature support on panama-vector:
> 
>  Internal Error (/home/xiagon01/code/panama-vector/src/hotspot/share/opto/type.hpp:1727), pid=104432, tid=104449
>  # assert(_base >= AnyPtr && _base <= KlassPtr) failed: Not a pointer
> 
> Adding a value like other vector types for the `"VectorMask"` in the array `"dual_type"` can fix it.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8262355
> 
> Tested with tier1 and jdk:tier3

This pull request has now been integrated.

Changeset: 19356556
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/19356556
Stats:     43 lines in 2 files changed: 0 ins; 43 del; 0 mod

8264957: Cleanup unused array Type::dual_type

Reviewed-by: jiefu, neliasso, thartmann

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

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

From jbhateja at openjdk.java.net  Tue Apr 13 10:54:02 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 13 Apr 2021 10:54:02 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
Message-ID: <m9aemYnzRi3RvjPSUJFeF54e-Hg9MfBQ1ggNjZ8-Mlo=.5fbaac0c-7ca8-4ac3-93fc-55ee19fc246e@github.com>

On Tue, 13 Apr 2021 03:21:21 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
>> 
>> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
>> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
>> 
>>   VectorLoadMask (VectorStoreMask vmask)
>> 
>> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
>> vectors with the same element size and vector length, it's safe to do the optimization:
>> 
>>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
>> 
>> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "Matcher::match_rule_supported_vector" for vector nodes checking

src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 861:

> 859: instruct vmaskcast(vReg dst) %{
> 860:   predicate(UseSVE > 0);
> 861:   match(Set dst (VectorMaskCast dst));

A strict check based on in-type and out-type in predicate could strengthen the pattern.

src/hotspot/share/opto/vectornode.hpp line 1240:

> 1238: };
> 1239: 
> 1240: class VectorMaskCastNode : public VectorNode {

VectorMaskReinterpret seems better choice, since its a re-interpretation and not a casting (up/down).

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

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

From vlivanov at openjdk.java.net  Tue Apr 13 11:21:05 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 13 Apr 2021 11:21:05 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <m9aemYnzRi3RvjPSUJFeF54e-Hg9MfBQ1ggNjZ8-Mlo=.5fbaac0c-7ca8-4ac3-93fc-55ee19fc246e@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
 <m9aemYnzRi3RvjPSUJFeF54e-Hg9MfBQ1ggNjZ8-Mlo=.5fbaac0c-7ca8-4ac3-93fc-55ee19fc246e@github.com>
Message-ID: <1mjRZSrgWpn61bMsZ_hioYpmWFjGtySndhAmC0zkGu0=.9684321b-a412-4907-8367-c6071405655d@github.com>

On Tue, 13 Apr 2021 10:49:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use "Matcher::match_rule_supported_vector" for vector nodes checking
>
> src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 861:
> 
>> 859: instruct vmaskcast(vReg dst) %{
>> 860:   predicate(UseSVE > 0);
>> 861:   match(Set dst (VectorMaskCast dst));
> 
> A strict check based on in-type and out-type in predicate could strengthen the pattern.

I agree.

> src/hotspot/share/opto/vectornode.hpp line 1240:
> 
>> 1238: };
>> 1239: 
>> 1240: class VectorMaskCastNode : public VectorNode {
> 
> VectorMaskReinterpret seems better choice, since its a re-interpretation and not a casting (up/down).

Considering masks have platform-specific representation, full-blown casts between different element types look more appropriate here.

In this particular case, the focus is on the cheapest possible case when representations share the same bit pattern and the cast degenerates into a no-op. But in the longer term, it makes perfect sense to support the full matrix of conversions and don't rely on `VectorLoadMask <=> VectorStoreMask` and intermediate canonical vector representation.

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

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

From rcastanedalo at openjdk.java.net  Tue Apr 13 11:35:03 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 13 Apr 2021 11:35:03 GMT
Subject: RFR: 8265125: IGV: cannot edit forms with NetBeans GUI builder
Message-ID: <y_z_ISYLh-FsXBI-XuIB-RMmlaaFctn9p-Gv7TAV1Fc=.327c4219-02fc-442c-9130-af4cf644ee71@github.com>

This change moves all NetBeans-generated .form files to the same directory as their corresponding Java source files. This allows NetBeans to recognize the corresponding Java source files as Swing forms, and open them in "Design" mode:

![design](https://user-images.githubusercontent.com/8792647/114543087-07187d80-9c59-11eb-8d30-6d53db35db17.png)

The .form files are only processed by NetBeans, so this change does not affect how IGV is built and run.

Tested manually by reproducing the steps in the [JBS bug report](https://bugs.openjdk.java.net/browse/JDK-8265125) and by checking that IGV can be built and run following the steps in IGV's [README.md](https://github.com/openjdk/jdk/tree/master/src/utils/IdealGraphVisualizer#building-and-running) file.

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

Commit messages:
 - Move NetBeans .form files to Java directories

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

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

From jbhateja at openjdk.java.net  Tue Apr 13 15:53:06 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 13 Apr 2021 15:53:06 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <1mjRZSrgWpn61bMsZ_hioYpmWFjGtySndhAmC0zkGu0=.9684321b-a412-4907-8367-c6071405655d@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
 <m9aemYnzRi3RvjPSUJFeF54e-Hg9MfBQ1ggNjZ8-Mlo=.5fbaac0c-7ca8-4ac3-93fc-55ee19fc246e@github.com>
 <1mjRZSrgWpn61bMsZ_hioYpmWFjGtySndhAmC0zkGu0=.9684321b-a412-4907-8367-c6071405655d@github.com>
Message-ID: <j89LF5SayfAJ9VMkSBHj6D8cKE5fm3gSZId00kzGdTE=.a1fd968e-bcf9-4799-a579-4564f51c7eda@github.com>

On Tue, 13 Apr 2021 11:16:33 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.hpp line 1240:
>> 
>>> 1238: };
>>> 1239: 
>>> 1240: class VectorMaskCastNode : public VectorNode {
>> 
>> VectorMaskReinterpret seems better choice, since its a re-interpretation and not a casting (up/down).
>
> Considering masks have platform-specific representation, full-blown casts between different element types look more appropriate here.
> 
> In this particular case, the focus is on the cheapest possible case when representations share the same bit pattern and the cast degenerates into a no-op. But in the longer term, it makes perfect sense to support the full matrix of conversions and don't rely on `VectorLoadMask <=> VectorStoreMask` and intermediate canonical vector representation.

Got it.

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

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

From kvn at openjdk.java.net  Tue Apr 13 17:02:02 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 13 Apr 2021 17:02:02 GMT
Subject: RFR: 8265125: IGV: cannot edit forms with NetBeans GUI builder
In-Reply-To: <y_z_ISYLh-FsXBI-XuIB-RMmlaaFctn9p-Gv7TAV1Fc=.327c4219-02fc-442c-9130-af4cf644ee71@github.com>
References: <y_z_ISYLh-FsXBI-XuIB-RMmlaaFctn9p-Gv7TAV1Fc=.327c4219-02fc-442c-9130-af4cf644ee71@github.com>
Message-ID: <a2a1kUFzhVf8r_QsIiSS0JtuOV9hhzAuVlyOlgE4x0Q=.2d52a1e3-8132-44dc-a71e-d15e7d329dc3@github.com>

On Tue, 13 Apr 2021 11:12:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change moves all NetBeans-generated .form files to the same directory as their corresponding Java source files. This allows NetBeans to recognize the corresponding Java source files as Swing forms, and open them in "Design" mode:
> 
> ![design](https://user-images.githubusercontent.com/8792647/114543087-07187d80-9c59-11eb-8d30-6d53db35db17.png)
> 
> The .form files are only processed by NetBeans, so this change does not affect how IGV is built and run.
> 
> Tested manually by reproducing the steps in the [JBS bug report](https://bugs.openjdk.java.net/browse/JDK-8265125) and by checking that IGV can be built and run following the steps in IGV's [README.md](https://github.com/openjdk/jdk/tree/master/src/utils/IdealGraphVisualizer#building-and-running) file.

Trivial

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

Marked as reviewed by kvn (Reviewer).

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

From rcastanedalo at openjdk.java.net  Tue Apr 13 17:11:04 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 13 Apr 2021 17:11:04 GMT
Subject: RFR: 8265125: IGV: cannot edit forms with NetBeans GUI builder
In-Reply-To: <a2a1kUFzhVf8r_QsIiSS0JtuOV9hhzAuVlyOlgE4x0Q=.2d52a1e3-8132-44dc-a71e-d15e7d329dc3@github.com>
References: <y_z_ISYLh-FsXBI-XuIB-RMmlaaFctn9p-Gv7TAV1Fc=.327c4219-02fc-442c-9130-af4cf644ee71@github.com>
 <a2a1kUFzhVf8r_QsIiSS0JtuOV9hhzAuVlyOlgE4x0Q=.2d52a1e3-8132-44dc-a71e-d15e7d329dc3@github.com>
Message-ID: <LtMuBua1JGEIWQKuhugrRzNVhp96prUXR3K3AhO52s4=.ca68ad25-ea20-4830-95a7-89d1a5871ea2@github.com>

On Tue, 13 Apr 2021 16:59:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Trivial

Thanks for reviewing, Vladimir!

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

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

From rcastanedalo at openjdk.java.net  Tue Apr 13 17:11:05 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 13 Apr 2021 17:11:05 GMT
Subject: Integrated: 8265125: IGV: cannot edit forms with NetBeans GUI builder
In-Reply-To: <y_z_ISYLh-FsXBI-XuIB-RMmlaaFctn9p-Gv7TAV1Fc=.327c4219-02fc-442c-9130-af4cf644ee71@github.com>
References: <y_z_ISYLh-FsXBI-XuIB-RMmlaaFctn9p-Gv7TAV1Fc=.327c4219-02fc-442c-9130-af4cf644ee71@github.com>
Message-ID: <rrPVbnHRajHqJRPjU71wlccBpdRNMzgK15DrBO8etco=.11d5d226-a075-4781-8879-00e944ca50b4@github.com>

On Tue, 13 Apr 2021 11:12:19 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change moves all NetBeans-generated .form files to the same directory as their corresponding Java source files. This allows NetBeans to recognize the corresponding Java source files as Swing forms, and open them in "Design" mode:
> 
> ![design](https://user-images.githubusercontent.com/8792647/114543087-07187d80-9c59-11eb-8d30-6d53db35db17.png)
> 
> The .form files are only processed by NetBeans, so this change does not affect how IGV is built and run.
> 
> Tested manually by reproducing the steps in the [JBS bug report](https://bugs.openjdk.java.net/browse/JDK-8265125) and by checking that IGV can be built and run following the steps in IGV's [README.md](https://github.com/openjdk/jdk/tree/master/src/utils/IdealGraphVisualizer#building-and-running) file.

This pull request has now been integrated.

Changeset: 8df8512b
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8df8512b
Stats:     0 lines in 7 files changed: 0 ins; 0 del; 0 mod

8265125: IGV: cannot edit forms with NetBeans GUI builder

Reviewed-by: kvn

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

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

From henri.tremblay at gmail.com  Tue Apr 13 11:26:21 2021
From: henri.tremblay at gmail.com (Henri Tremblay)
Date: Tue, 13 Apr 2021 07:26:21 -0400
Subject: New candidate JEP: 410: Remove the Experimental AOT and JIT
 Compiler
In-Reply-To: <20210407214719.2E6553DF0DA@eggemoggin.niobe.net>
References: <20210407214719.2E6553DF0DA@eggemoggin.niobe.net>
Message-ID: <CADZL2=sT8N422KMNMt8GotpC2izyMo96_+xLGN+dcr9EVHjZ9g@mail.gmail.com>

Hi,

Does it mean that the chances to see GraalVM becoming the default JIT are
now becoming thiner and thiner?

Thanks,
Henri

On Wed, 7 Apr 2021 at 17:47, <mark.reinhold at oracle.com> wrote:

> https://openjdk.java.net/jeps/410
>
>   Summary: Remove the experimental Java-based ahead-of-time (AOT) and
>   just-in-time (JIT) compiler.  This compiler has seen little use since
>   its introduction and the effort required to maintain it is significant.
>   Retain the experimental Java-level JVM compiler interface (JVMCI) so
>   that developers can continue to use externally-built versions of the
>   compiler for JIT compilation.
>
> - Mark
>

From kvn at openjdk.java.net  Tue Apr 13 17:55:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 13 Apr 2021 17:55:20 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
 <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
Message-ID: <TuPyGyrUBp_XcAKrstUIJjz1TGwnoFQ3V-HnXfP7laI=.bd845394-edfb-4ef3-9ed3-ac6dbdcbae3b@github.com>

On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important.
>
>> @dougxc I restored Compiler::isGraalEnabled().
> 
> Thanks. I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later).

@dougxc
Renaming should be done separately. May be use RFE I filed: https://bugs.openjdk.java.net/browse/JDK-8265032

Do you approve these Graal removal changes?

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

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

From lutz.schmidt at sap.com  Tue Apr 13 19:43:28 2021
From: lutz.schmidt at sap.com (Schmidt, Lutz)
Date: Tue, 13 Apr 2021 19:43:28 +0000
Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use
 Compile_lock in favour of fancy checks
Message-ID: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com>

Dear Community,?

I would appreciate receiving reviews for this downport change. It is a small change in one file only. Unfortunately, it did not apply clean. 

Original bug:    https://bugs.openjdk.java.net/browse/JDK-8250635 
Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/ 

Tests:
SAP's internal build and test farm. Results pending. 

Thank you!
Lutz
 


From lutz.schmidt at sap.com  Tue Apr 13 20:02:27 2021
From: lutz.schmidt at sap.com (Schmidt, Lutz)
Date: Tue, 13 Apr 2021 20:02:27 +0000
Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use
 Compile_lock in favour of fancy checks
In-Reply-To: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com>
References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com>
Message-ID: <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com>

Sorry for spamming, forgot jdk-updates-dev. 
Lutz

?On 13.04.21, 21:43, "Schmidt, Lutz" <lutz.schmidt at sap.com> wrote:

    Dear Community, 

    I would appreciate receiving reviews for this downport change. It is a small change in one file only. Unfortunately, it did not apply clean. 

    Original bug:    https://bugs.openjdk.java.net/browse/JDK-8250635 
    Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/ 

    Tests:
    SAP's internal build and test farm. Results pending. 

    Thank you!
    Lutz




From dnsimon at openjdk.java.net  Tue Apr 13 21:22:14 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 13 Apr 2021 21:22:14 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v3]
In-Reply-To: <tXz08rqVPR_leQJMDGrYd4-Z-CrN8vIX105a8Z-GFho=.4b53feba-294e-4a9d-8b6a-d5cdcfaa1367@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <tXz08rqVPR_leQJMDGrYd4-Z-CrN8vIX105a8Z-GFho=.4b53feba-294e-4a9d-8b6a-d5cdcfaa1367@github.com>
Message-ID: <ey1KPPydMltPmdsD1a3t_p7D77EYszQrCWoaY7tKidw=.121360c8-e175-4246-b169-78339888927d@github.com>

On Mon, 12 Apr 2021 22:10:06 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
>> 
>> - `jdk.internal.vm.compiler` ? the Graal compiler 
>> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
>> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
>> 
>> Remove Graal related code in makefiles.
>> 
>> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
>> 
>> src/jdk.internal.vm.compiler/share/classes/module-info.java
>> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>> 
>> 
>> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore Compiler::isGraalEnabled()

Approved.

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

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

From hohensee at amazon.com  Tue Apr 13 23:05:56 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 13 Apr 2021 23:05:56 +0000
Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use
 Compile_lock in favour of fancy checks
Message-ID: <5C8796FB-7411-42B6-BE8B-96A9DC9E8107@amazon.com>

Lgtm, assuming tests pass.

Thanks,
Paul

?-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of "Schmidt, Lutz" <lutz.schmidt at sap.com>
Date: Tuesday, April 13, 2021 at 1:03 PM
To: "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-dev at openjdk.java.net>, "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Subject: RE: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use Compile_lock in favour of fancy checks

Sorry for spamming, forgot jdk-updates-dev.
Lutz

On 13.04.21, 21:43, "Schmidt, Lutz" <lutz.schmidt at sap.com> wrote:

    Dear Community,

    I would appreciate receiving reviews for this downport change. It is a small change in one file only. Unfortunately, it did not apply clean.

    Original bug:    https://bugs.openjdk.java.net/browse/JDK-8250635
    Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/

    Tests:
    SAP's internal build and test farm. Results pending.

    Thank you!
    Lutz





From xgong at openjdk.java.net  Wed Apr 14 01:55:57 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 14 Apr 2021 01:55:57 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <1mjRZSrgWpn61bMsZ_hioYpmWFjGtySndhAmC0zkGu0=.9684321b-a412-4907-8367-c6071405655d@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
 <m9aemYnzRi3RvjPSUJFeF54e-Hg9MfBQ1ggNjZ8-Mlo=.5fbaac0c-7ca8-4ac3-93fc-55ee19fc246e@github.com>
 <1mjRZSrgWpn61bMsZ_hioYpmWFjGtySndhAmC0zkGu0=.9684321b-a412-4907-8367-c6071405655d@github.com>
Message-ID: <f0QsxwoE-k4hlySdk0keZ5v17H1effTaUToXZ-QzP84=.50da8280-9931-480e-a2fb-259b68628a2a@github.com>

On Tue, 13 Apr 2021 11:18:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 861:
>> 
>>> 859: instruct vmaskcast(vReg dst) %{
>>> 860:   predicate(UseSVE > 0);
>>> 861:   match(Set dst (VectorMaskCast dst));
>> 
>> A strict check based on in-type and out-type in predicate could strengthen the pattern.
>
> I agree.

I'v added the type assertion in the constructor of the `"VectorMaskCastNode"`. See :

assert(in_vt->length() == vt->length(), "vector length must match");
assert(type2aelembytes(in_vt->element_basic_type()) == type2aelembytes(vt->element_basic_type()), "element size must match");

That's why I didn't add the check in predicate. So do you think it's enough?

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

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

From dholmes at openjdk.java.net  Wed Apr 14 02:31:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 14 Apr 2021 02:31:58 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v4]
In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
Message-ID: <KGeJODnI7DH4FfiBjlyiW4X-qoIs0AAGdHpxsZbbPLo=.df3f4be2-6269-4e43-ba27-ffa5c3d4d431@github.com>

On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
>> 
>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
>> 
>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
>> 
>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
>> 
>> Some missing CHECK_ uses were added.
>> 
>> Testing:
>>   - tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix search&replace mistake

Repeating this as the bots failed to send out an email.

Thanks for the reviews @coleenp , @hseigel and @iklam .

Can someone from compiler team please take a look and give the okay? (I know things are a bit busy at the moment.)

Thanks,
David

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

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

From sviswanathan at openjdk.java.net  Wed Apr 14 05:06:05 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 14 Apr 2021 05:06:05 GMT
Subject: RFR: 8265154: vinserti128 operand mix up for KNL platforms
Message-ID: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>

There is a bug in macro assembler in vinserti128 special handling for platforms like KNL that do not support AVX512VL.
 
The following:
   void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
     if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
       Assembler::vinserti32x4(dst, dst, src, imm8);
     }
     ...
  }
 
Should have been:
   void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
     if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
       Assembler::vinserti32x4(dst, nds, src, imm8);
     }
    ...
  }

Best Regards,
Sandhya

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

Commit messages:
 - 8265154: vinserti128 operand mix up for KNL platforms

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

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

From zhaixiang at loongson.cn  Wed Apr 14 05:09:21 2021
From: zhaixiang at loongson.cn (Leslie Zhai)
Date: Wed, 14 Apr 2021 13:09:21 +0800
Subject: 8230015: [instruction selector] generic vector operands support.
In-Reply-To: <A66BBE673E08E1428E3A918AE4D5B32C0A042065@BGSMSX106.gar.corp.intel.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A042065@BGSMSX106.gar.corp.intel.com>
Message-ID: <c8e81440-73d9-d8cf-3f67-5768edbb2398@loongson.cn>

Hi Jatin,

Thanks for your great work!

libjvm.so reduced +1MB will help SPECjvm2008 some benchmark +44% speed up.

Then I tried to port 8234391: C2: Generic vector operands for `YOURARCH` 
about LoadVector and StoreVector at first.

Only `Matcher::regmask_for_ideal_register` was able to call 
`Matcher::is_generic_vector`, but compared with X86, 
`Matcher::do_postselect_cleanup` was also able to call 
`Matcher::is_generic_vector` too.

I debug the `Matcher::do_postselect_cleanup`:

diff --git a/src/hotspot/share/opto/matcher.cpp 
b/src/hotspot/share/opto/matcher.cpp
index 0846cad3c3f..8fd644d2d93 100644
--- a/src/hotspot/share/opto/matcher.cpp
+++ b/src/hotspot/share/opto/matcher.cpp
@@ -309,6 +309,9 @@ void Matcher::match( ) {
      C->record_method_not_compilable("must be able to represent all 
call arguments in reg mask");
    }

+#ifdef YOURARCH64
+  do_postselect_cleanup();
+#endif
    if (C->failing())  return;  // bailed out on incoming arg failure

    // ---------------
@@ -2630,8 +2633,10 @@ void Matcher::specialize_generic_vector_operands() {
          int opnd_idx = m->operand_index(1);
          Node* def = m->in(opnd_idx);
          m->subsume_by(def, C);
+#if !defined(YOURARCH64)
        } else if (m->is_MachTemp()) {
          // process MachTemp nodes at use site (see 
Matcher::specialize_vector_operand)
+#endif
        } else {
          specialize_mach_node(m);
        }

But `Matcher::do_postselect_cleanup` was still not able to be called.

 > Current patch enables this support only for x86 target, to get a 
feedback from community.

Then how to port Generic vector operands for other targets?

Thanks,

Leslie Zhai


? 2019?08?22? 14:49, Bhateja, Jatin ??:
> Hi All,
>
> Please find below a patch for generic vector operands[1] support during instruction selection.
>
> Motivation behind the patch is to reduce the number of vector selection patterns whose operands meagerly differ in vector lengths.
> This will not only result in lesser code being generated by ADLC which effectively translates to size reduction in libjvm.so but also
> help in better maintenance of AD files.
>
> Using generic operands we were able to collapse multiple vector patterns over mainline
>               Initial number of vector instruction patterns (vec[XYZSD] + legVec[ZXYSD]   :  510
>               Reduced vector instruction patterns  (vecG + legVecG)                                  :  222
>
> With this we could see around 1MB size reduction in libjvm.so.
>
> In order to have minimal impact over downstream compiler passes, a post-selection pass has been introduced (currently enabled only for X86 target)
> which replaces these generic operands with their corresponding concreter vector length variants.
>
> JBS      : https://bugs.openjdk.java.net/browse/JDK-8230015
> Patch  : http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.00/
>
> Kindly review and share your feedback.
>
> Best Regards,
> Jatin Bhateja
>
> [1] http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf
>


From thartmann at openjdk.java.net  Wed Apr 14 06:40:03 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 14 Apr 2021 06:40:03 GMT
Subject: RFR: 8265154: vinserti128 operand mix up for KNL platforms
In-Reply-To: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
References: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
Message-ID: <H_5wxWz4vjP2tvkRbGyp6DCMG3XYKqK7XTAEf7Tby2M=.be0ff23f-4395-4ba5-b3eb-b5a3a52f0bb0@github.com>

On Wed, 14 Apr 2021 00:25:40 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> There is a bug in macro assembler in vinserti128 special handling for platforms like KNL that do not support AVX512VL.
>  
> The following:
>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>        Assembler::vinserti32x4(dst, dst, src, imm8);
>      }
>      ...
>   }
>  
> Should have been:
>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>        Assembler::vinserti32x4(dst, nds, src, imm8);
>      }
>     ...
>   }
> 
> Best Regards,
> Sandhya

Looks good to me. Just wondering, why did this never show up? Are we missing tests exercising this code path?

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

Marked as reviewed by thartmann (Reviewer).

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

From rbackman at openjdk.java.net  Wed Apr 14 08:34:19 2021
From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=)
Date: Wed, 14 Apr 2021 08:34:19 GMT
Subject: RFR: 8260255: C1: LoopInvariantCodeMotion constructor can leave some
 fields uninitialized
Message-ID: <Bn_19BvOhBXMAdbbmtWx7WIlBK26ukK5_BmDCTDx4zk=.5265423b-e229-4988-b84d-38e79326e71f@github.com>

Initialize instance variables to default values to avoid uninitialized values for early return.

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

Commit messages:
 - 8260255: C1: LoopInvariantCodeMotion constructor can leave some fields uninitialized

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

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

From martin.doerr at sap.com  Wed Apr 14 09:06:52 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 14 Apr 2021 09:06:52 +0000
Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use
 Compile_lock in favour of fancy checks
In-Reply-To: <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com>
References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com>
 <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com>
Message-ID: <AM4PR02MB3057F1D793F2F3DC22D15B579A4E9@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi Lutz,

your backport looks good.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Schmidt, Lutz
> Sent: Dienstag, 13. April 2021 22:02
> To: hotspot-compiler-dev at openjdk.java.net; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram should
> use Compile_lock in favour of fancy checks
> 
> Sorry for spamming, forgot jdk-updates-dev.
> Lutz
> 
> ?On 13.04.21, 21:43, "Schmidt, Lutz" <lutz.schmidt at sap.com> wrote:
> 
>     Dear Community,
> 
>     I would appreciate receiving reviews for this downport change. It is a small
> change in one file only. Unfortunately, it did not apply clean.
> 
>     Original bug:    https://bugs.openjdk.java.net/browse/JDK-8250635
>     Downport webrev:
> https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/
> 
>     Tests:
>     SAP's internal build and test farm. Results pending.
> 
>     Thank you!
>     Lutz
> 
> 


From lutz.schmidt at sap.com  Wed Apr 14 09:18:18 2021
From: lutz.schmidt at sap.com (Schmidt, Lutz)
Date: Wed, 14 Apr 2021 09:18:18 +0000
Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use
 Compile_lock in favour of fancy checks
In-Reply-To: <AM4PR02MB3057F1D793F2F3DC22D15B579A4E9@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com>
 <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com>
 <AM4PR02MB3057F1D793F2F3DC22D15B579A4E9@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <40507412-5F59-4623-BA39-728CA14F9C64@sap.com>

Thank you, Martin and Paul, for your reviews. 

Submit will have to wait another day. I was too late for testing last night. 

I will need a sponsor anyway. Is it ok to contact you, Martin, once the tests are done successfully? 

Thanks, 
Lutz

?On 14.04.21, 11:06, "Doerr, Martin" <martin.doerr at sap.com> wrote:

    Hi Lutz,

    your backport looks good.

    Best regards,
    Martin


    > -----Original Message-----
    > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
    > Behalf Of Schmidt, Lutz
    > Sent: Dienstag, 13. April 2021 22:02
    > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates-
    > dev at openjdk.java.net
    > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram should
    > use Compile_lock in favour of fancy checks
    > 
    > Sorry for spamming, forgot jdk-updates-dev.
    > Lutz
    > 
    > On 13.04.21, 21:43, "Schmidt, Lutz" <lutz.schmidt at sap.com> wrote:
    > 
    >     Dear Community,
    > 
    >     I would appreciate receiving reviews for this downport change. It is a small
    > change in one file only. Unfortunately, it did not apply clean.
    > 
    >     Original bug:    https://bugs.openjdk.java.net/browse/JDK-8250635
    >     Downport webrev:
    > https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/
    > 
    >     Tests:
    >     SAP's internal build and test farm. Results pending.
    > 
    >     Thank you!
    >     Lutz
    > 
    > 



From martin.doerr at sap.com  Wed Apr 14 09:21:31 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 14 Apr 2021 09:21:31 +0000
Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use
 Compile_lock in favour of fancy checks
In-Reply-To: <40507412-5F59-4623-BA39-728CA14F9C64@sap.com>
References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com>
 <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com>
 <AM4PR02MB3057F1D793F2F3DC22D15B579A4E9@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <40507412-5F59-4623-BA39-728CA14F9C64@sap.com>
Message-ID: <AM4PR02MB30579B492399EA30D05C74649A4E9@AM4PR02MB3057.eurprd02.prod.outlook.com>

Yes. Just let me know when it's ready.

Best regards,
Martin


> -----Original Message-----
> From: Schmidt, Lutz <lutz.schmidt at sap.com>
> Sent: Mittwoch, 14. April 2021 11:18
> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-
> dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Hohensee,
> Paul <hohensee at amazon.com>
> Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram should
> use Compile_lock in favour of fancy checks
> 
> Thank you, Martin and Paul, for your reviews.
> 
> Submit will have to wait another day. I was too late for testing last night.
> 
> I will need a sponsor anyway. Is it ok to contact you, Martin, once the tests
> are done successfully?
> 
> Thanks,
> Lutz
> 
> ?On 14.04.21, 11:06, "Doerr, Martin" <martin.doerr at sap.com> wrote:
> 
>     Hi Lutz,
> 
>     your backport looks good.
> 
>     Best regards,
>     Martin
> 
> 
>     > -----Original Message-----
>     > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
>     > Behalf Of Schmidt, Lutz
>     > Sent: Dienstag, 13. April 2021 22:02
>     > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates-
>     > dev at openjdk.java.net
>     > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram
> should
>     > use Compile_lock in favour of fancy checks
>     >
>     > Sorry for spamming, forgot jdk-updates-dev.
>     > Lutz
>     >
>     > On 13.04.21, 21:43, "Schmidt, Lutz" <lutz.schmidt at sap.com> wrote:
>     >
>     >     Dear Community,
>     >
>     >     I would appreciate receiving reviews for this downport change. It is a
> small
>     > change in one file only. Unfortunately, it did not apply clean.
>     >
>     >     Original bug:    https://bugs.openjdk.java.net/browse/JDK-8250635
>     >     Downport webrev:
>     > https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/
>     >
>     >     Tests:
>     >     SAP's internal build and test farm. Results pending.
>     >
>     >     Thank you!
>     >     Lutz
>     >
>     >
> 


From neliasso at openjdk.java.net  Wed Apr 14 09:32:57 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 14 Apr 2021 09:32:57 GMT
Subject: RFR: 8260255: C1: LoopInvariantCodeMotion constructor can leave
 some fields uninitialized
In-Reply-To: <Bn_19BvOhBXMAdbbmtWx7WIlBK26ukK5_BmDCTDx4zk=.5265423b-e229-4988-b84d-38e79326e71f@github.com>
References: <Bn_19BvOhBXMAdbbmtWx7WIlBK26ukK5_BmDCTDx4zk=.5265423b-e229-4988-b84d-38e79326e71f@github.com>
Message-ID: <b-IMB4niLultUZrEqudiENz_iEsOvTR01SCEEbRN4nI=.d47f0b42-9f55-415e-bb99-b68571fce4f5@github.com>

On Wed, 14 Apr 2021 08:27:16 GMT, Rickard B?ckman <rbackman at openjdk.org> wrote:

> Initialize instance variables to default values to avoid uninitialized values for early return.

Looks good.

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

Marked as reviewed by neliasso (Reviewer).

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

From thartmann at openjdk.java.net  Wed Apr 14 09:39:59 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 14 Apr 2021 09:39:59 GMT
Subject: RFR: 8260255: C1: LoopInvariantCodeMotion constructor can leave
 some fields uninitialized
In-Reply-To: <Bn_19BvOhBXMAdbbmtWx7WIlBK26ukK5_BmDCTDx4zk=.5265423b-e229-4988-b84d-38e79326e71f@github.com>
References: <Bn_19BvOhBXMAdbbmtWx7WIlBK26ukK5_BmDCTDx4zk=.5265423b-e229-4988-b84d-38e79326e71f@github.com>
Message-ID: <PaGib69ocXMBuYb2vOZVgScd-TE7Tgz1zKfHbkCcYKw=.fc22e478-6ffb-433e-9ac8-a4bd14a11a4c@github.com>

On Wed, 14 Apr 2021 08:27:16 GMT, Rickard B?ckman <rbackman at openjdk.org> wrote:

> Initialize instance variables to default values to avoid uninitialized values for early return.

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

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

From eliu at openjdk.java.net  Wed Apr 14 10:05:56 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Wed, 14 Apr 2021 10:05:56 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <xPFPFOV3utkvM9MNkb47RtwRlZ_F-kJOjSjXUHX9U4o=.f67f29ec-6758-4885-b688-ecd838b52e4c@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <BTm22Oi34Dmf74iVWFzBlpWpXGXlZyXmFFpJeiX1fks=.a510e477-65d4-4de9-9d74-877699c81153@github.com>
 <9T0fatLfUStsY_1SA94rlhKokfqT7TeySYeFzIuO7Nk=.7394e20e-a4a3-4786-a2db-f5d8acc2b74a@github.com>
 <eW-ovE81LsZRl4EL_DMDUvO3SAQyVmEHIfNwxtjGWes=.fee1ca04-f365-4824-8698-289b51701fd9@github.com>
 <Nj4ujEK3cYFxTSGa0Homij1W1UyHnHjGtjWtLYMfWRo=.7ac138b1-0654-4210-93ef-3e1b90b10a52@github.com>
 <Pa8IXPBC6slvkKcF-ZcKGojgNsaSKJS7oFoCjXJZp08=.d792e10e-582b-4b9b-a67f-6f62d986c0fe@github.com>
 <BNRC8qkMCzI4Y9vwTNuJD3VdNqoIalOfDtbj172g8h8=.be8bfbd5-4c46-4274-b444-7329bd35d3e0@github.com>
 <xPFPFOV3utkvM9MNkb47RtwRlZ_F-kJOjSjXUHX9U4o=.f67f29ec-6758-4885-b688-ecd838b52e4c@github.com>
Message-ID: <KGrblv-VhlmELGSR5sed-FJ0raLUzDapd6G7YHMPNUQ=.edb985c8-3fe1-468d-a591-5529b33ae9fe@github.com>

On Fri, 9 Apr 2021 09:26:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The vector shift count was defined by two separate nodes(LShiftCntV and
>> RShiftCntV), which would prevent them from being shared when the shift
>> counts are the same.
>> 
>> 
>> public static void test_shiftv(int sh) {
>>     for (int i = 0; i < N; i+=1) {
>>         a0[i] = a1[i] << sh;
>>         b0[i] = b1[i] >> sh;
>>     }
>> }
>> 
>> 
>> Given the example above, by merging the same shift counts into one
>> node, they could be shared by shift nodes(RShiftV or LShiftV) like
>> below:
>> 
>> 
>> Before:
>> 1184  LShiftCntV  === _  1189  [[ 1185  ... ]]
>> 1190  RShiftCntV  === _  1189  [[ 1191  ... ]]
>> 1185  LShiftVI  === _  1181  1184  [[ 1186 ]]
>> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
>> 
>> After:
>> 1190  ShiftCntV  === _  1189  [[ 1191 1204  ... ]]
>> 1204  LShiftVI  === _  1211  1190  [[ 1203 ]]
>> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
>> 
>> 
>> The final code could remove one redundant ?dup?(scalar->vector),
>> with one register saved.
>> 
>> 
>> Before:
>>         dup     v16.16b, w12
>>         dup     v17.16b, w12
>>         ...
>>         ldr     q18, [x13, #16]
>>         sshl    v18.4s, v18.4s, v16.4s
>>         add     x18, x16, x12           ; iaload
>> 
>>         add     x4, x15, x12
>>         str     q18, [x4, #16]          ; iastore
>> 
>>         ldr     q18, [x18, #16]
>>         add     x12, x14, x12
>>         neg     v19.16b, v17.16b
>>         sshl    v18.4s, v18.4s, v19.4s
>>         str     q18, [x12, #16]         ; iastore
>> 
>> After:
>>         dup	v16.16b, w11
>>         ...
>>         ldr	q17, [x13, #16]
>>         sshl	v17.4s, v17.4s, v16.4s
>>         add	x2, x22, x11            ; iaload
>> 
>>         add	x4, x16, x11
>>         str	q17, [x4, #16]          ; iastore
>> 
>>         ldr	q17, [x2, #16]
>>         add	x11, x21, x11
>>         neg	v18.16b, v16.16b
>>         sshl	v17.4s, v17.4s, v18.4s
>>         str	q17, [x11, #16]         ; iastore
>
>> 
>> It seems that keeping those two RShiftCntV and LShiftCntV is friendly to AArch32/64 in this case, but AArch64 should changed to what AArch32 dose. @theRealAph
> 
> Thanks, but it's been a while since I looked at the vector code. Can you point me to the AArch32 patterns in question, to show me the AArch64 changes needed? Thanks.

@theRealAph Could you please take a look at this?

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

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

From github.com+40024232+sunny868 at openjdk.java.net  Wed Apr 14 14:52:51 2021
From: github.com+40024232+sunny868 at openjdk.java.net (SUN Guoyun)
Date: Wed, 14 Apr 2021 14:52:51 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
Message-ID: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>

On MIPS64 platform has not impliment C1,only has C2.
 so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
 perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

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

Commit messages:
 - 8265105: gc/arguments/TestSelectDefaultGC.java fails when compiler1 is disabled

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

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

From github.com+40024232+sunny868 at openjdk.java.net  Wed Apr 14 14:52:51 2021
From: github.com+40024232+sunny868 at openjdk.java.net (SUN Guoyun)
Date: Wed, 14 Apr 2021 14:52:51 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <2ndqbMB_O7VQOeF6IrOcbZwoBt2HA05D3S4zMHtWDzw=.bc0b0e6e-d358-4687-a7a0-de15ea1bb342@github.com>

On Tue, 13 Apr 2021 05:46:15 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

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

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

From thartmann at openjdk.java.net  Wed Apr 14 14:52:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 14 Apr 2021 14:52:51 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <u4wWVvq_cgx8iL33YlNIH8toMYVtlu1hb7OzZfpdGok=.25a7e91b-2bc6-416c-bad2-dc655e5fc837@github.com>

On Tue, 13 Apr 2021 05:46:15 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

Please add a description of your fix to the PR.

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

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

From kvn at openjdk.java.net  Wed Apr 14 15:26:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 14 Apr 2021 15:26:38 GMT
Subject: RFR: 8265154: vinserti128 operand mix up for KNL platforms
In-Reply-To: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
References: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
Message-ID: <JiqwfyYtwIRHM1A42fQF_f1P8BgqnwYiDFpChuFya8U=.72e7c8d0-9462-4e9a-a0e8-caf107e1fdda@github.com>

On Wed, 14 Apr 2021 00:25:40 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> There is a bug in macro assembler in vinserti128 special handling for platforms like KNL that do not support AVX512VL.
>  
> The following:
>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>        Assembler::vinserti32x4(dst, dst, src, imm8);
>      }
>      ...
>   }
>  
> Should have been:
>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>        Assembler::vinserti32x4(dst, nds, src, imm8);
>      }
>     ...
>   }
> 
> Best Regards,
> Sandhya

What problems this is causing? Would be nice to have a test to show the issue (if possible).

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

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

From vladimir.x.ivanov at oracle.com  Wed Apr 14 17:11:10 2021
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 14 Apr 2021 20:11:10 +0300
Subject: 8230015: [instruction selector] generic vector operands support.
In-Reply-To: <c8e81440-73d9-d8cf-3f67-5768edbb2398@loongson.cn>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A042065@BGSMSX106.gar.corp.intel.com>
 <c8e81440-73d9-d8cf-3f67-5768edbb2398@loongson.cn>
Message-ID: <17d6fd4c-196d-ea5b-f2a9-a2175e6ee652@oracle.com>

Hi Leslie,

I'm not sure what you are trying to achieve with the port.

Currently, there are 3 platform-specific methods which 
Matcher::do_postselect_cleanup() relies on:

   Matcher::pd_specialize_generic_vector_operand()
   Matcher::is_generic_reg2reg_move()
   Matcher::is_generic_vector()

It should be enough to provide implementations for those methods on 
YOURARCH to make Matcher::do_postselect_cleanup() working.

Can you elaborate on what exactly you are trying to accomplish?

Best regards,
Vladimir Ivanov

On 14.04.2021 08:09, Leslie Zhai wrote:
> Hi Jatin,
> 
> Thanks for your great work!
> 
> libjvm.so reduced +1MB will help SPECjvm2008 some benchmark +44% speed up.
> 
> Then I tried to port 8234391: C2: Generic vector operands for `YOURARCH` 
> about LoadVector and StoreVector at first.
> 
> Only `Matcher::regmask_for_ideal_register` was able to call 
> `Matcher::is_generic_vector`, but compared with X86, 
> `Matcher::do_postselect_cleanup` was also able to call 
> `Matcher::is_generic_vector` too.
> 
> I debug the `Matcher::do_postselect_cleanup`:
> 
> diff --git a/src/hotspot/share/opto/matcher.cpp 
> b/src/hotspot/share/opto/matcher.cpp
> index 0846cad3c3f..8fd644d2d93 100644
> --- a/src/hotspot/share/opto/matcher.cpp
> +++ b/src/hotspot/share/opto/matcher.cpp
> @@ -309,6 +309,9 @@ void Matcher::match( ) {
>  ??? C->record_method_not_compilable("must be able to represent all call 
> arguments in reg mask");
>  ? }
> 
> +#ifdef YOURARCH64
> +? do_postselect_cleanup();
> +#endif
>  ? if (C->failing())? return;? // bailed out on incoming arg failure
> 
>  ? // ---------------
> @@ -2630,8 +2633,10 @@ void Matcher::specialize_generic_vector_operands() {
>  ??????? int opnd_idx = m->operand_index(1);
>  ??????? Node* def = m->in(opnd_idx);
>  ??????? m->subsume_by(def, C);
> +#if !defined(YOURARCH64)
>  ????? } else if (m->is_MachTemp()) {
>  ??????? // process MachTemp nodes at use site (see 
> Matcher::specialize_vector_operand)
> +#endif
>  ????? } else {
>  ??????? specialize_mach_node(m);
>  ????? }
> 
> But `Matcher::do_postselect_cleanup` was still not able to be called.
> 
>> Current patch enables this support only for x86 target, to get a 
> feedback from community.
> 
> Then how to port Generic vector operands for other targets?
> 
> Thanks,
> 
> Leslie Zhai
> 
> 
> ? 2019?08?22? 14:49, Bhateja, Jatin ??:
>> Hi All,
>>
>> Please find below a patch for generic vector operands[1] support 
>> during instruction selection.
>>
>> Motivation behind the patch is to reduce the number of vector 
>> selection patterns whose operands meagerly differ in vector lengths.
>> This will not only result in lesser code being generated by ADLC which 
>> effectively translates to size reduction in libjvm.so but also
>> help in better maintenance of AD files.
>>
>> Using generic operands we were able to collapse multiple vector 
>> patterns over mainline
>> ????????????? Initial number of vector instruction patterns 
>> (vec[XYZSD] + legVec[ZXYSD]?? :? 510
>> ????????????? Reduced vector instruction patterns? (vecG + 
>> legVecG)????????????????????????????????? :? 222
>>
>> With this we could see around 1MB size reduction in libjvm.so.
>>
>> In order to have minimal impact over downstream compiler passes, a 
>> post-selection pass has been introduced (currently enabled only for 
>> X86 target)
>> which replaces these generic operands with their corresponding 
>> concreter vector length variants.
>>
>> JBS????? : https://bugs.openjdk.java.net/browse/JDK-8230015
>> Patch? : 
>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.00/
>>
>> Kindly review and share your feedback.
>>
>> Best Regards,
>> Jatin Bhateja
>>
>> [1] 
>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf 
>>
>>
> 

From vlivanov at openjdk.java.net  Wed Apr 14 17:17:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 14 Apr 2021 17:17:40 GMT
Subject: RFR: 8264188: Improve handling of assembly files in the JDK [v2]
In-Reply-To: <AjONWW_lVy2VoejYbDl9ya4EZNnXiuMu7sJI4ESxcLc=.f306273b-bf02-4cf7-8311-00e31aca1eae@github.com>
References: <N3XzVlA2e9lFDk47zQ-HE7L6PUoJczjZ9lppLW4ArTY=.f5b748fc-c30c-4532-8265-cacf62114622@github.com>
 <AjONWW_lVy2VoejYbDl9ya4EZNnXiuMu7sJI4ESxcLc=.f306273b-bf02-4cf7-8311-00e31aca1eae@github.com>
Message-ID: <Jo9ZmA7ILnwSTrSWViEsxl9TEoCz66W9prwm3I8hdfo=.35e686fd-1443-4036-9d54-77f36224ca93@github.com>

On Mon, 29 Mar 2021 10:48:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. 
>> 
>> In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. 
>> 
>> It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. 
>> 
>> For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. 
>> 
>> All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form
>> 
>> # if (a) {
>> 
>> as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`).
>> 
>> We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-().
>> 
>> This patch has been partly written by Sandhya Viswanathan <sviswanathan at openjdk.org> for the panama-vector repo.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use OPENJDK_BUILD_CPU_BITS instead

Looks good!

Thanks a lot for taking care of it.

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

Marked as reviewed by vlivanov (Reviewer).

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

From vlivanov at openjdk.java.net  Wed Apr 14 17:25:37 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 14 Apr 2021 17:25:37 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <f0QsxwoE-k4hlySdk0keZ5v17H1effTaUToXZ-QzP84=.50da8280-9931-480e-a2fb-259b68628a2a@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
 <m9aemYnzRi3RvjPSUJFeF54e-Hg9MfBQ1ggNjZ8-Mlo=.5fbaac0c-7ca8-4ac3-93fc-55ee19fc246e@github.com>
 <1mjRZSrgWpn61bMsZ_hioYpmWFjGtySndhAmC0zkGu0=.9684321b-a412-4907-8367-c6071405655d@github.com>
 <f0QsxwoE-k4hlySdk0keZ5v17H1effTaUToXZ-QzP84=.50da8280-9931-480e-a2fb-259b68628a2a@github.com>
Message-ID: <GXE2UaTv9a-BYYkJER2s3H_9xwpvMKwxu6WgcKELYoY=.5f454535-cbc1-4061-8ee2-5da8cbed6765@github.com>

On Wed, 14 Apr 2021 01:53:15 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> I agree.
>
> I'v added the type assertion in the constructor of the `"VectorMaskCastNode"`. See :
> 
> assert(in_vt->length() == vt->length(), "vector length must match");
> assert(type2aelembytes(in_vt->element_basic_type()) == type2aelembytes(vt->element_basic_type()), "element size must match");
> 
> That's why I didn't add the check in predicate. So do you think it's enough?

IMO AD instructions should also be accompanied either by predicates or asserts which stress the conditions for the no-op implementation.

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

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

From iignatyev at openjdk.java.net  Wed Apr 14 17:26:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 14 Apr 2021 17:26:38 GMT
Subject: RFR: 8262060: compiler/whitebox/BlockingCompilation.java timed
 out [v2]
In-Reply-To: <kVeQu-aD0YECasqwjFq2dNhCsBWjJEkx8riXLn1CDag=.e78bc51e-4cbf-4d65-b622-330bf1ba5975@github.com>
References: <OiOA1GtUHhEIG2bLIsEskiqzWwS0Fr6HjhKEUbsixFg=.d1edd99a-a57c-47b1-b48a-e2f399c3c487@github.com>
 <kVeQu-aD0YECasqwjFq2dNhCsBWjJEkx8riXLn1CDag=.e78bc51e-4cbf-4d65-b622-330bf1ba5975@github.com>
Message-ID: <OgP50HSNV2zsby9d2upx7of7bvQ-DCCgux2h2cN-0l4=.59f04b8c-f086-41a9-882d-d03ceb311284@github.com>

On Tue, 30 Mar 2021 08:24:09 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> Please review this small fix for a test.
>> 
>> Test fails sometimes when run with UsageTracker enabled. For some reason, a loading of ThreadLocalRandom can happen during the test run, and this invalidates Random.nextInt method (because it's not the only implementation now).
>> 
>> Fixed by pre-loading ThreadLocalRandom. Tested by multiple runs with UsageTracker enabled - approx. 1 out of 20-30 test runs fails without the fix and no failures spotted with the fix.
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of dependency on the Random class

LGTM

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

Marked as reviewed by iignatyev (Reviewer).

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

From kvn at openjdk.java.net  Wed Apr 14 23:52:34 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 14 Apr 2021 23:52:34 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v4]
In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
Message-ID: <7Z7WVmrAwRFOZLRr7WpgBhbfpuCXOwMHZQ7xPM50Vt0=.b5cee83a-1bd6-4838-92d5-e9e1057479a5@github.com>

On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
>> 
>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
>> 
>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
>> 
>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
>> 
>> Some missing CHECK_ uses were added.
>> 
>> Testing:
>>   - tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix search&replace mistake

Why you kept `JavaThread  *thread` parameter in some methods and renamed in others in deoptimization.* files.

src/hotspot/share/c1/c1_Runtime1.cpp line 178:

> 176: // Stress deoptimization
> 177: static void deopt_caller(JavaThread* current) {
> 178:   if ( !caller_is_deopted(current)) {

Can you remove space after `( `?

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

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

From kvn at openjdk.java.net  Thu Apr 15 00:06:35 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 15 Apr 2021 00:06:35 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v4]
In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
Message-ID: <VmYtiTQ5PvvjpMZCcHekWTG2qaOXdi6scKDGMBhoGlE=.a7340dbb-585c-418d-81fd-d135083a46b1@github.com>

On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
>> 
>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
>> 
>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
>> 
>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
>> 
>> Some missing CHECK_ uses were added.
>> 
>> Testing:
>>   - tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix search&replace mistake

I also don't see changes in `src/hotspot/share/ci/`. Is code there okay?

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

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

From david.holmes at oracle.com  Thu Apr 15 00:16:26 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Apr 2021 10:16:26 +1000
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v4]
In-Reply-To: <7Z7WVmrAwRFOZLRr7WpgBhbfpuCXOwMHZQ7xPM50Vt0=.b5cee83a-1bd6-4838-92d5-e9e1057479a5@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
 <7Z7WVmrAwRFOZLRr7WpgBhbfpuCXOwMHZQ7xPM50Vt0=.b5cee83a-1bd6-4838-92d5-e9e1057479a5@github.com>
Message-ID: <3352b004-d6ba-6bdf-3ee6-663a12414f1c@oracle.com>

Hi Vladimir,

Thanks for looking at this.

On 15/04/2021 9:52 am, Vladimir Kozlov wrote:
> On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
>>>
>>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
>>>
>>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
>>>
>>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
>>>
>>> Some missing CHECK_ uses were added.
>>>
>>> Testing:
>>>    - tiers 1-3
>>>
>>> Thanks,
>>> David
>>
>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Fix search&replace mistake
> 
> Why you kept `JavaThread  *thread` parameter in some methods and renamed in others in deoptimization.* files.

I only changed those parameters involved with JRT_* routines, as those 
can obviously be seen to be the current thread. For other code in that 
file it probably deals with the current thread, but that isn't 
necessarily obvious and would need more rigorous checking. That is 
beyond the scope of the current set of changes and would need a future RFE.

Similarly for the lack of changes in the ci files - if they weren't 
affected by the JRT changes they weren't changed.

> src/hotspot/share/c1/c1_Runtime1.cpp line 178:
> 
>> 176: // Stress deoptimization
>> 177: static void deopt_caller(JavaThread* current) {
>> 178:   if ( !caller_is_deopted(current)) {
> 
> Can you remove space after `( `?

Sure. :)

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3394
> 

From kvn at openjdk.java.net  Thu Apr 15 01:08:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 15 Apr 2021 01:08:36 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v4]
In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
Message-ID: <Jgx5UxxJfZFS4KrHn770tvoDMmKsaDRcnaLp1-D-9-M=.cb99c36b-5f51-41a8-a94f-d4c54aca9a83@github.com>

On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
>> 
>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
>> 
>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
>> 
>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
>> 
>> Some missing CHECK_ uses were added.
>> 
>> Testing:
>>   - tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix search&replace mistake

Okay.

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

Marked as reviewed by kvn (Reviewer).

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

From dholmes at openjdk.java.net  Thu Apr 15 02:20:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 15 Apr 2021 02:20:09 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v5]
In-Reply-To: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
Message-ID: <RstvNxLEAq4NTb7EDIjx5wFiHHvZsdpByDoix4Cw2kw=.9f5a6cdf-cab3-4b2d-88ed-1e3804048208@github.com>

> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
> 
> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
> 
> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
> 
> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
> 
> Some missing CHECK_ uses were added.
> 
> Testing:
>   - tiers 1-3
> 
> Thanks,
> David

David Holmes 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 ten additional commits since the last revision:

 - Merge branch 'master' into jrt_entry_v2
 - Fix style nit for kvn
 - Merge branch 'master' into jrt_entry_v2
 - Fix search&replace mistake
 - Fix minor nits reported by @coleenp and @hseigel
 - @coleenp review comment - Avoid manifesting JavaThread::current() when it can be passed in
 - Added in missed JRT_BLOCK_ENTRY methods in AOT-related jvmci/compilerRuntime.cpp
 - Fixed CHECK on return statement.
 - 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3394/files
  - new: https://git.openjdk.java.net/jdk/pull/3394/files/9cfc43c2..166c7fe5

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

  Stats: 17123 lines in 917 files changed: 10458 ins; 5286 del; 1379 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3394.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3394/head:pull/3394

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

From dholmes at openjdk.java.net  Thu Apr 15 02:25:35 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 15 Apr 2021 02:25:35 GMT
Subject: Integrated: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines
In-Reply-To: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
Message-ID: <K885Vr7t8dkuFWsJ4CH6mrUKuhygWm4gTM-hbzKreOM=.49883ed0-4550-4cca-bc65-576c1913cbb1@github.com>

On Thu, 8 Apr 2021 06:52:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread".
> 
> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom.
> 
> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing.
> 
> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread().
> 
> Some missing CHECK_ uses were added.
> 
> Testing:
>   - tiers 1-3
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 79bff21b
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/79bff21b
Stats:     936 lines in 23 files changed: 16 ins; 29 del; 891 mod

8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines

Reviewed-by: coleenp, hseigel, iklam, kvn

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

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

From dholmes at openjdk.java.net  Thu Apr 15 02:25:34 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 15 Apr 2021 02:25:34 GMT
Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY
 routines [v4]
In-Reply-To: <VmYtiTQ5PvvjpMZCcHekWTG2qaOXdi6scKDGMBhoGlE=.a7340dbb-585c-418d-81fd-d135083a46b1@github.com>
References: <Ya-hjJUaPbRlhX3A0M9BN3q-Hyr7SGhn_2aTVvSdG2I=.f7ad1bc7-9b47-4d85-8081-a7d401d0b2bf@github.com>
 <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com>
 <VmYtiTQ5PvvjpMZCcHekWTG2qaOXdi6scKDGMBhoGlE=.a7340dbb-585c-418d-81fd-d135083a46b1@github.com>
Message-ID: <ADqGLQa7l419CS436xHkqRFAoKfPQRapX8ARqJCBzys=.5556cb3d-c973-4178-bc25-f80436f9f205@github.com>

On Thu, 15 Apr 2021 00:03:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix search&replace mistake
>
> I also don't see changes in `src/hotspot/share/ci/`. Is code there okay?

Thanks for the review @vnkozlov !

David

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

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

From whuang at openjdk.java.net  Thu Apr 15 03:04:44 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 15 Apr 2021 03:04:44 GMT
Subject: RFR: 8265244: assert(false) failed: bad AD file
Message-ID: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>

* aarch64 can only accept `VectorReinterpret` with 64/128 bits.
* I will fix this bug by adding a rule for `VectorReinterpret` in `match_rule_supported_vector`
* after changing note with @nsjian and @XiaohongGong , I think that two checks in `inline_vector_conver` is useless now. However, these checks impact other cpus, so I need more reviewers.

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

Commit messages:
 - 8265244: assert(false) failed: bad AD file

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

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

From zhaixiang at loongson.cn  Thu Apr 15 03:57:05 2021
From: zhaixiang at loongson.cn (Leslie Zhai)
Date: Thu, 15 Apr 2021 11:57:05 +0800
Subject: 8230015: [instruction selector] generic vector operands support.
In-Reply-To: <17d6fd4c-196d-ea5b-f2a9-a2175e6ee652@oracle.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A042065@BGSMSX106.gar.corp.intel.com>
 <c8e81440-73d9-d8cf-3f67-5768edbb2398@loongson.cn>
 <17d6fd4c-196d-ea5b-f2a9-a2175e6ee652@oracle.com>
Message-ID: <15686c57-66ff-05a4-6f99-bd495ceb0a31@loongson.cn>

Hi Vladimir,

Thanks for your kind response!


? 2021?04?15? 01:11, Vladimir Ivanov ??:
> Hi Leslie,
>
> I'm not sure what you are trying to achieve with the port.

SPECjvm2008 some benchmarks performed better after ported Vector API for 
YOURARCH,  but libjvm.so became fatter.  So I tried to port Generic 
Vector Operands for losing weight.

>
>
> Currently, there are 3 platform-specific methods which 
> Matcher::do_postselect_cleanup() relies on:
>
>   Matcher::pd_specialize_generic_vector_operand()
>   Matcher::is_generic_reg2reg_move()
>   Matcher::is_generic_vector()

There is no `vec` move to `legVec` or `legVec` to `vec`:

diff --git a/src/hotspot/cpu/yourarch/yourarch_64.ad 
b/src/hotspot/cpu/yourarch/yourarch_64.ad
index f3cdc560372..a2beb6bc776 100644
--- a/src/hotspot/cpu/yourarch/yourarch_64.ad
+++ b/src/hotspot/cpu/yourarch/yourarch_64.ad
@@ -1104,22 +1104,32 @@ const bool Matcher::require_postalloc_expand = 
false;
  // the cpu only look at the lower 5/6 bits anyway?
  const bool Matcher::need_masked_shift_count = false;

-// No support for generic vector operands.
-const bool Matcher::supports_generic_vector_operands = false;
+const bool Matcher::supports_generic_vector_operands = true;

  MachOper* Matcher::pd_specialize_generic_vector_operand(MachOper* 
generic_opnd, uint ideal_reg, bool is_temp) {
-  ShouldNotReachHere(); // generic vector operands not supported
+  assert(Matcher::is_generic_vector(generic_opnd), "not generic");
+  switch (ideal_reg) {
+    case Op_VecS: return new vecSOper();
+    case Op_VecD: return new vecDOper();
+    case Op_VecX: return new vecXOper();
+    case Op_VecY: return new vecYOper();
+  }
+  ShouldNotReachHere();
    return NULL;
  }

+// No vec move to legVec or legVec to vec
  bool Matcher::is_generic_reg2reg_move(MachNode* m) {
-  ShouldNotReachHere();  // generic vector operands not supported
    return false;
  }

  bool Matcher::is_generic_vector(MachOper* opnd)  {
-  ShouldNotReachHere();  // generic vector operands not supported
-  return false;
+  switch (opnd->opcode()) {
+    case VEC:
+      return true;
+    default:
+      return false;
+  }
  }

  bool Matcher::supports_vector_variable_shifts(void) {
@@ -2745,6 +2755,19 @@ ins_attrib ins_alignment(4);    // Required 
alignment attribute (must be a power

  // Vectors

+// Dummy generic vector class. Should be used for all vector operands.
+// Replaced with vec[SDXY] during post-selection pass.
+operand vec() %{
+  constraint(ALLOC_IN_RC(dynamic));
+  match(VecX);
+  match(VecY);
+  match(VecS);
+  match(VecD);
+
+  format %{ %}
+  interface(REG_INTER);
+%}
+
  operand vecS() %{
    constraint(ALLOC_IN_RC(vectors_reg));
    match(VecS);

Then merged loadV4/8/16/32 into loadV and storeV4/8/16/32 to storeV with 
the helper functions `vector_length_in_bytes` for LoadVector and 
StoreVector at first.

>
>
> It should be enough to provide implementations for those methods on 
> YOURARCH to make Matcher::do_postselect_cleanup() working.

It is my fault: other VectorNodes, for example, `MulVD` and `ReplicateD` 
also need to change `vecX/Y` to `vec` in the very beginning, not only 
just LoadVector/StoreVector.  Sorry that I am too hurry to see the 
optimization effect.

>
>
> Can you elaborate on what exactly you are trying to accomplish?

Better SPECjvm2008 benchmark performance and meanwhile libjvm.so keep 
slim :)

Thanks,
Leslie Zhai

>
>
> Best regards,
> Vladimir Ivanov
>
> On 14.04.2021 08:09, Leslie Zhai wrote:
>> Hi Jatin,
>>
>> Thanks for your great work!
>>
>> libjvm.so reduced +1MB will help SPECjvm2008 some benchmark +44% 
>> speed up.
>>
>> Then I tried to port 8234391: C2: Generic vector operands for 
>> `YOURARCH` about LoadVector and StoreVector at first.
>>
>> Only `Matcher::regmask_for_ideal_register` was able to call 
>> `Matcher::is_generic_vector`, but compared with X86, 
>> `Matcher::do_postselect_cleanup` was also able to call 
>> `Matcher::is_generic_vector` too.
>>
>> I debug the `Matcher::do_postselect_cleanup`:
>>
>> diff --git a/src/hotspot/share/opto/matcher.cpp 
>> b/src/hotspot/share/opto/matcher.cpp
>> index 0846cad3c3f..8fd644d2d93 100644
>> --- a/src/hotspot/share/opto/matcher.cpp
>> +++ b/src/hotspot/share/opto/matcher.cpp
>> @@ -309,6 +309,9 @@ void Matcher::match( ) {
>>      C->record_method_not_compilable("must be able to represent all 
>> call arguments in reg mask");
>>    }
>>
>> +#ifdef YOURARCH64
>> +  do_postselect_cleanup();
>> +#endif
>>    if (C->failing())  return;  // bailed out on incoming arg failure
>>
>>    // ---------------
>> @@ -2630,8 +2633,10 @@ void 
>> Matcher::specialize_generic_vector_operands() {
>>          int opnd_idx = m->operand_index(1);
>>          Node* def = m->in(opnd_idx);
>>          m->subsume_by(def, C);
>> +#if !defined(YOURARCH64)
>>        } else if (m->is_MachTemp()) {
>>          // process MachTemp nodes at use site (see 
>> Matcher::specialize_vector_operand)
>> +#endif
>>        } else {
>>          specialize_mach_node(m);
>>        }
>>
>> But `Matcher::do_postselect_cleanup` was still not able to be called.
>>
>>> Current patch enables this support only for x86 target, to get a 
>> feedback from community.
>>
>> Then how to port Generic vector operands for other targets?
>>
>> Thanks,
>>
>> Leslie Zhai
>>
>>
>> ? 2019?08?22? 14:49, Bhateja, Jatin ??:
>>> Hi All,
>>>
>>> Please find below a patch for generic vector operands[1] support 
>>> during instruction selection.
>>>
>>> Motivation behind the patch is to reduce the number of vector 
>>> selection patterns whose operands meagerly differ in vector lengths.
>>> This will not only result in lesser code being generated by ADLC 
>>> which effectively translates to size reduction in libjvm.so but also
>>> help in better maintenance of AD files.
>>>
>>> Using generic operands we were able to collapse multiple vector 
>>> patterns over mainline
>>>               Initial number of vector instruction patterns 
>>> (vec[XYZSD] + legVec[ZXYSD]   :  510
>>>               Reduced vector instruction patterns  (vecG + 
>>> legVecG)                                  :  222
>>>
>>> With this we could see around 1MB size reduction in libjvm.so.
>>>
>>> In order to have minimal impact over downstream compiler passes, a 
>>> post-selection pass has been introduced (currently enabled only for 
>>> X86 target)
>>> which replaces these generic operands with their corresponding 
>>> concreter vector length variants.
>>>
>>> JBS      : https://bugs.openjdk.java.net/browse/JDK-8230015
>>> Patch  : 
>>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.00/
>>>
>>> Kindly review and share your feedback.
>>>
>>> Best Regards,
>>> Jatin Bhateja
>>>
>>> [1] 
>>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf 
>>>
>>>
>>


From xgong at openjdk.java.net  Thu Apr 15 04:02:03 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 15 Apr 2021 04:02:03 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v5]
In-Reply-To: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
Message-ID: <id9W05xFL-NEbEvEeAfVcBZQN2jArYk1IDVWeWjvyhw=.45460a3e-badc-4665-a17e-2c7fe2cfd2e6@github.com>

> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
> 
> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
> 
>   VectorLoadMask (VectorStoreMask vmask)
> 
> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
> vectors with the same element size and vector length, it's safe to do the optimization:
> 
>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
> 
> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Add type restrict in the match rule predicate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3238/files
  - new: https://git.openjdk.java.net/jdk/pull/3238/files/977787e4..8232bd96

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

  Stats: 13 lines in 4 files changed: 8 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3238.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3238/head:pull/3238

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

From xgong at openjdk.java.net  Thu Apr 15 04:02:04 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 15 Apr 2021 04:02:04 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
Message-ID: <x8_XL0KjlpU2OtgJFYLqJi_nFGo_LbV55eVtJPJaBe8=.74b49e7c-b6ad-4c32-a67c-e0eec30df40f@github.com>

On Tue, 13 Apr 2021 03:21:21 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
>> 
>> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
>> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
>> 
>>   VectorLoadMask (VectorStoreMask vmask)
>> 
>> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
>> vectors with the same element size and vector length, it's safe to do the optimization:
>> 
>>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
>> 
>> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "Matcher::match_rule_supported_vector" for vector nodes checking

Hi @jatin-bhateja @iwanowww , all your comments have been addressed. Could you please take a look at it again? Thanks!

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

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

From xgong at openjdk.java.net  Thu Apr 15 04:02:04 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 15 Apr 2021 04:02:04 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <GXE2UaTv9a-BYYkJER2s3H_9xwpvMKwxu6WgcKELYoY=.5f454535-cbc1-4061-8ee2-5da8cbed6765@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
 <m9aemYnzRi3RvjPSUJFeF54e-Hg9MfBQ1ggNjZ8-Mlo=.5fbaac0c-7ca8-4ac3-93fc-55ee19fc246e@github.com>
 <1mjRZSrgWpn61bMsZ_hioYpmWFjGtySndhAmC0zkGu0=.9684321b-a412-4907-8367-c6071405655d@github.com>
 <f0QsxwoE-k4hlySdk0keZ5v17H1effTaUToXZ-QzP84=.50da8280-9931-480e-a2fb-259b68628a2a@github.com>
 <GXE2UaTv9a-BYYkJER2s3H_9xwpvMKwxu6WgcKELYoY=.5f454535-cbc1-4061-8ee2-5da8cbed6765@github.com>
Message-ID: <GHrZk3NDVfQjOBQV_Tql0PM0vYbA_Z1lHUPpDhcKHOw=.9481fd7f-90a6-4aa0-b8d4-dd850dfee5de@github.com>

On Wed, 14 Apr 2021 17:22:41 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I'v added the type assertion in the constructor of the `"VectorMaskCastNode"`. See :
>> 
>> assert(in_vt->length() == vt->length(), "vector length must match");
>> assert(type2aelembytes(in_vt->element_basic_type()) == type2aelembytes(vt->element_basic_type()), "element size must match");
>> 
>> That's why I didn't add the check in predicate. So do you think it's enough?
>
> IMO AD instructions should also be accompanied either by predicates or asserts which stress the conditions for the no-op implementation.

OK, thanks! I will add the type restrict in the predicate.

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

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

From jatin.bhateja at intel.com  Thu Apr 15 06:48:38 2021
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Thu, 15 Apr 2021 06:48:38 +0000
Subject: 8230015: [instruction selector] generic vector operands support.
In-Reply-To: <17d6fd4c-196d-ea5b-f2a9-a2175e6ee652@oracle.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A042065@BGSMSX106.gar.corp.intel.com>
 <c8e81440-73d9-d8cf-3f67-5768edbb2398@loongson.cn>
 <17d6fd4c-196d-ea5b-f2a9-a2175e6ee652@oracle.com>
Message-ID: <CY4PR11MB2054210D973CCCE775F95DD4E84D9@CY4PR11MB2054.namprd11.prod.outlook.com>

Hi Vladimir,
Thanks for responding on my behalf.

Best Regards,
Jatin

> -----Original Message-----
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: Wednesday, April 14, 2021 10:41 PM
> To: Leslie Zhai <zhaixiang at loongson.cn>
> Cc: Bhateja, Jatin <jatin.bhateja at intel.com>; hotspot-compiler-
> dev at openjdk.java.net
> Subject: Re: 8230015: [instruction selector] generic vector operands
> support.
> 
> Hi Leslie,
> 
> I'm not sure what you are trying to achieve with the port.
> 
> Currently, there are 3 platform-specific methods which
> Matcher::do_postselect_cleanup() relies on:
> 
>    Matcher::pd_specialize_generic_vector_operand()
>    Matcher::is_generic_reg2reg_move()
>    Matcher::is_generic_vector()
> 
> It should be enough to provide implementations for those methods on
> YOURARCH to make Matcher::do_postselect_cleanup() working.
> 
> Can you elaborate on what exactly you are trying to accomplish?
> 
> Best regards,
> Vladimir Ivanov
> 
> On 14.04.2021 08:09, Leslie Zhai wrote:
> > Hi Jatin,
> >
> > Thanks for your great work!
> >
> > libjvm.so reduced +1MB will help SPECjvm2008 some benchmark +44% speed
> up.
> >
> > Then I tried to port 8234391: C2: Generic vector operands for
> > `YOURARCH` about LoadVector and StoreVector at first.
> >
> > Only `Matcher::regmask_for_ideal_register` was able to call
> > `Matcher::is_generic_vector`, but compared with X86,
> > `Matcher::do_postselect_cleanup` was also able to call
> > `Matcher::is_generic_vector` too.
> >
> > I debug the `Matcher::do_postselect_cleanup`:
> >
> > diff --git a/src/hotspot/share/opto/matcher.cpp
> > b/src/hotspot/share/opto/matcher.cpp
> > index 0846cad3c3f..8fd644d2d93 100644
> > --- a/src/hotspot/share/opto/matcher.cpp
> > +++ b/src/hotspot/share/opto/matcher.cpp
> > @@ -309,6 +309,9 @@ void Matcher::match( ) {
> >  ??? C->record_method_not_compilable("must be able to represent all
> > call arguments in reg mask");
> >  ? }
> >
> > +#ifdef YOURARCH64
> > +? do_postselect_cleanup();
> > +#endif
> >  ? if (C->failing())? return;? // bailed out on incoming arg failure
> >
> >  ? // ---------------
> > @@ -2630,8 +2633,10 @@ void
> > Matcher::specialize_generic_vector_operands() {
> >  ??????? int opnd_idx = m->operand_index(1);
> >  ??????? Node* def = m->in(opnd_idx);
> >  ??????? m->subsume_by(def, C);
> > +#if !defined(YOURARCH64)
> >  ????? } else if (m->is_MachTemp()) {
> >  ??????? // process MachTemp nodes at use site (see
> > Matcher::specialize_vector_operand)
> > +#endif
> >  ????? } else {
> >  ??????? specialize_mach_node(m);
> >  ????? }
> >
> > But `Matcher::do_postselect_cleanup` was still not able to be called.
> >
> >> Current patch enables this support only for x86 target, to get a
> > feedback from community.
> >
> > Then how to port Generic vector operands for other targets?
> >
> > Thanks,
> >
> > Leslie Zhai
> >
> >
> > ? 2019?08?22? 14:49, Bhateja, Jatin ??:
> >> Hi All,
> >>
> >> Please find below a patch for generic vector operands[1] support
> >> during instruction selection.
> >>
> >> Motivation behind the patch is to reduce the number of vector
> >> selection patterns whose operands meagerly differ in vector lengths.
> >> This will not only result in lesser code being generated by ADLC
> >> which effectively translates to size reduction in libjvm.so but also
> >> help in better maintenance of AD files.
> >>
> >> Using generic operands we were able to collapse multiple vector
> >> patterns over mainline
> >> ????????????? Initial number of vector instruction patterns
> >> (vec[XYZSD] + legVec[ZXYSD]?? :? 510
> >> ????????????? Reduced vector instruction patterns? (vecG +
> >> legVecG)????????????????????????????????? :? 222
> >>
> >> With this we could see around 1MB size reduction in libjvm.so.
> >>
> >> In order to have minimal impact over downstream compiler passes, a
> >> post-selection pass has been introduced (currently enabled only for
> >> X86 target)
> >> which replaces these generic operands with their corresponding
> >> concreter vector length variants.
> >>
> >> JBS????? : https://bugs.openjdk.java.net/browse/JDK-8230015
> >> Patch? :
> >> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.00/
> >>
> >> Kindly review and share your feedback.
> >>
> >> Best Regards,
> >> Jatin Bhateja
> >>
> >> [1]
> >> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_op
> >> erands_support_v1.0.pdf
> >>
> >>
> >

From lutz.schmidt at sap.com  Thu Apr 15 07:46:08 2021
From: lutz.schmidt at sap.com (Schmidt, Lutz)
Date: Thu, 15 Apr 2021 07:46:08 +0000
Subject: [11u] RFR(S): 8250635 backport: MethodArityHistogram should use
 Compile_lock in favour of fancy checks
In-Reply-To: <AM4PR02MB30579B492399EA30D05C74649A4E9@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <18C76401-DE61-4B8F-821B-9136B3B00E20@sap.com>
 <0D8921EA-F9CA-493F-AA7F-A0BFBF992B21@sap.com>
 <AM4PR02MB3057F1D793F2F3DC22D15B579A4E9@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <40507412-5F59-4623-BA39-728CA14F9C64@sap.com>
 <AM4PR02MB30579B492399EA30D05C74649A4E9@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <9967BB60-EF86-4EC7-9F56-B8E3E7A5D02D@sap.com>

Tests did not reveal any issues. From this end, downport is ready to be pushed. Bug was updated accordingly.
Thanks,
Lutz


?On 14.04.21, 11:21, "Doerr, Martin" <martin.doerr at sap.com> wrote:

    Yes. Just let me know when it's ready.

    Best regards,
    Martin


    > -----Original Message-----
    > From: Schmidt, Lutz <lutz.schmidt at sap.com>
    > Sent: Mittwoch, 14. April 2021 11:18
    > To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-
    > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Hohensee,
    > Paul <hohensee at amazon.com>
    > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram should
    > use Compile_lock in favour of fancy checks
    > 
    > Thank you, Martin and Paul, for your reviews.
    > 
    > Submit will have to wait another day. I was too late for testing last night.
    > 
    > I will need a sponsor anyway. Is it ok to contact you, Martin, once the tests
    > are done successfully?
    > 
    > Thanks,
    > Lutz
    > 
    > On 14.04.21, 11:06, "Doerr, Martin" <martin.doerr at sap.com> wrote:
    > 
    >     Hi Lutz,
    > 
    >     your backport looks good.
    > 
    >     Best regards,
    >     Martin
    > 
    > 
    >     > -----Original Message-----
    >     > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
    >     > Behalf Of Schmidt, Lutz
    >     > Sent: Dienstag, 13. April 2021 22:02
    >     > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates-
    >     > dev at openjdk.java.net
    >     > Subject: Re: [11u] RFR(S): 8250635 backport: MethodArityHistogram
    > should
    >     > use Compile_lock in favour of fancy checks
    >     >
    >     > Sorry for spamming, forgot jdk-updates-dev.
    >     > Lutz
    >     >
    >     > On 13.04.21, 21:43, "Schmidt, Lutz" <lutz.schmidt at sap.com> wrote:
    >     >
    >     >     Dear Community,
    >     >
    >     >     I would appreciate receiving reviews for this downport change. It is a
    > small
    >     > change in one file only. Unfortunately, it did not apply clean.
    >     >
    >     >     Original bug:    https://bugs.openjdk.java.net/browse/JDK-8250635
    >     >     Downport webrev:
    >     > https://cr.openjdk.java.net/~lucy/webrevs/8250635.11u.01/
    >     >
    >     >     Tests:
    >     >     SAP's internal build and test farm. Results pending.
    >     >
    >     >     Thank you!
    >     >     Lutz
    >     >
    >     >
    > 



From rbackman at openjdk.java.net  Thu Apr 15 07:51:35 2021
From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=)
Date: Thu, 15 Apr 2021 07:51:35 GMT
Subject: Integrated: 8260255: C1: LoopInvariantCodeMotion constructor can
 leave some fields uninitialized
In-Reply-To: <Bn_19BvOhBXMAdbbmtWx7WIlBK26ukK5_BmDCTDx4zk=.5265423b-e229-4988-b84d-38e79326e71f@github.com>
References: <Bn_19BvOhBXMAdbbmtWx7WIlBK26ukK5_BmDCTDx4zk=.5265423b-e229-4988-b84d-38e79326e71f@github.com>
Message-ID: <RYSdmMuN8zzO9eA9voYyzk4hGbzOMvk1O2DzW5VK4CQ=.366be8e9-0806-4a84-b6c0-9be734b15a3c@github.com>

On Wed, 14 Apr 2021 08:27:16 GMT, Rickard B?ckman <rbackman at openjdk.org> wrote:

> Initialize instance variables to default values to avoid uninitialized values for early return.

This pull request has now been integrated.

Changeset: 0793fcbb
Author:    Rickard B?ckman <rbackman at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0793fcbb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8260255: C1: LoopInvariantCodeMotion constructor can leave some fields uninitialized

Reviewed-by: neliasso, thartmann

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

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

From jbhateja at openjdk.java.net  Thu Apr 15 09:56:35 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 15 Apr 2021 09:56:35 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <x8_XL0KjlpU2OtgJFYLqJi_nFGo_LbV55eVtJPJaBe8=.74b49e7c-b6ad-4c32-a67c-e0eec30df40f@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
 <x8_XL0KjlpU2OtgJFYLqJi_nFGo_LbV55eVtJPJaBe8=.74b49e7c-b6ad-4c32-a67c-e0eec30df40f@github.com>
Message-ID: <YkaTSqeHwZ92BdTyIL754hRivc8UXUPjFN2lr6UIJs8=.aef9c173-4196-4e82-b819-e9979090064a@github.com>

On Thu, 15 Apr 2021 03:58:26 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Hi @jatin-bhateja @iwanowww , all your comments have been addressed. Could you please take a look at it again? Thanks!

Thanks for addressing it. as Vladimir suggested in long term we can just emit this node instead of VectorStoreMask + VectorLoadMask  combination when mask types are non-conformal to emit efficient instruction sequence using input mask packing/unpacking.

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

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

From chagedorn at openjdk.java.net  Thu Apr 15 10:15:51 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 15 Apr 2021 10:15:51 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching on
 the IR in JTreg compiler tests
Message-ID: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>

This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.

The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.

A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.

To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.

Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.

Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):

-  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
   - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
      - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
      - which leaves 4382 lines of code inserted 

Big thanks to:
- @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
- @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
- @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
- and others who provided valuable feedback.

Thanks,
Christian

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

Commit messages:
 - Fix comment
 - Remove accidentally added print statement
 - Fix whitespaces + minor fix
 - Fix whitespaces
 - Add Javadoc files
 - 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests

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

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

From vlivanov at openjdk.java.net  Thu Apr 15 11:06:36 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 15 Apr 2021 11:06:36 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v5]
In-Reply-To: <id9W05xFL-NEbEvEeAfVcBZQN2jArYk1IDVWeWjvyhw=.45460a3e-badc-4665-a17e-2c7fe2cfd2e6@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <id9W05xFL-NEbEvEeAfVcBZQN2jArYk1IDVWeWjvyhw=.45460a3e-badc-4665-a17e-2c7fe2cfd2e6@github.com>
Message-ID: <65k0L3mzv75D0GxrUlzwB0e3_wts1XA3nzGxpPVbKRI=.2152c65f-6ece-4856-a1ef-d040c4d84d66@github.com>

On Thu, 15 Apr 2021 04:02:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
>> 
>> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
>> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
>> 
>>   VectorLoadMask (VectorStoreMask vmask)
>> 
>> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
>> vectors with the same element size and vector length, it's safe to do the optimization:
>> 
>>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
>> 
>> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add type restrict in the match rule predicate

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From zhaixiang at loongson.cn  Thu Apr 15 11:06:42 2021
From: zhaixiang at loongson.cn (Leslie Zhai)
Date: Thu, 15 Apr 2021 19:06:42 +0800
Subject: 8230015: [instruction selector] generic vector operands support.
In-Reply-To: <CY4PR11MB2054210D973CCCE775F95DD4E84D9@CY4PR11MB2054.namprd11.prod.outlook.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A042065@BGSMSX106.gar.corp.intel.com>
 <c8e81440-73d9-d8cf-3f67-5768edbb2398@loongson.cn>
 <17d6fd4c-196d-ea5b-f2a9-a2175e6ee652@oracle.com>
 <CY4PR11MB2054210D973CCCE775F95DD4E84D9@CY4PR11MB2054.namprd11.prod.outlook.com>
Message-ID: <2ae8b6a9-beef-c0ee-8733-31c2cbd06606@loongson.cn>

Hi Jatin,

Thanks again for your great work!

Before vs After ported

16137992 vs 15803384

Cheers,

Leslie Zhai


? 2021?04?15? 14:48, Bhateja, Jatin ??:
> Hi Vladimir,
> Thanks for responding on my behalf.
>
> Best Regards,
> Jatin
>
>> -----Original Message-----
>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>> Sent: Wednesday, April 14, 2021 10:41 PM
>> To: Leslie Zhai <zhaixiang at loongson.cn>
>> Cc: Bhateja, Jatin <jatin.bhateja at intel.com>; hotspot-compiler-
>> dev at openjdk.java.net
>> Subject: Re: 8230015: [instruction selector] generic vector operands
>> support.
>>
>> Hi Leslie,
>>
>> I'm not sure what you are trying to achieve with the port.
>>
>> Currently, there are 3 platform-specific methods which
>> Matcher::do_postselect_cleanup() relies on:
>>
>>     Matcher::pd_specialize_generic_vector_operand()
>>     Matcher::is_generic_reg2reg_move()
>>     Matcher::is_generic_vector()
>>
>> It should be enough to provide implementations for those methods on
>> YOURARCH to make Matcher::do_postselect_cleanup() working.
>>
>> Can you elaborate on what exactly you are trying to accomplish?
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 14.04.2021 08:09, Leslie Zhai wrote:
>>> Hi Jatin,
>>>
>>> Thanks for your great work!
>>>
>>> libjvm.so reduced +1MB will help SPECjvm2008 some benchmark +44% speed
>> up.
>>> Then I tried to port 8234391: C2: Generic vector operands for
>>> `YOURARCH` about LoadVector and StoreVector at first.
>>>
>>> Only `Matcher::regmask_for_ideal_register` was able to call
>>> `Matcher::is_generic_vector`, but compared with X86,
>>> `Matcher::do_postselect_cleanup` was also able to call
>>> `Matcher::is_generic_vector` too.
>>>
>>> I debug the `Matcher::do_postselect_cleanup`:
>>>
>>> diff --git a/src/hotspot/share/opto/matcher.cpp
>>> b/src/hotspot/share/opto/matcher.cpp
>>> index 0846cad3c3f..8fd644d2d93 100644
>>> --- a/src/hotspot/share/opto/matcher.cpp
>>> +++ b/src/hotspot/share/opto/matcher.cpp
>>> @@ -309,6 +309,9 @@ void Matcher::match( ) {
>>>       C->record_method_not_compilable("must be able to represent all
>>> call arguments in reg mask");
>>>     }
>>>
>>> +#ifdef YOURARCH64
>>> +  do_postselect_cleanup();
>>> +#endif
>>>     if (C->failing())  return;  // bailed out on incoming arg failure
>>>
>>>     // ---------------
>>> @@ -2630,8 +2633,10 @@ void
>>> Matcher::specialize_generic_vector_operands() {
>>>           int opnd_idx = m->operand_index(1);
>>>           Node* def = m->in(opnd_idx);
>>>           m->subsume_by(def, C);
>>> +#if !defined(YOURARCH64)
>>>         } else if (m->is_MachTemp()) {
>>>           // process MachTemp nodes at use site (see
>>> Matcher::specialize_vector_operand)
>>> +#endif
>>>         } else {
>>>           specialize_mach_node(m);
>>>         }
>>>
>>> But `Matcher::do_postselect_cleanup` was still not able to be called.
>>>
>>>> Current patch enables this support only for x86 target, to get a
>>> feedback from community.
>>>
>>> Then how to port Generic vector operands for other targets?
>>>
>>> Thanks,
>>>
>>> Leslie Zhai
>>>
>>>
>>> ? 2019?08?22? 14:49, Bhateja, Jatin ??:
>>>> Hi All,
>>>>
>>>> Please find below a patch for generic vector operands[1] support
>>>> during instruction selection.
>>>>
>>>> Motivation behind the patch is to reduce the number of vector
>>>> selection patterns whose operands meagerly differ in vector lengths.
>>>> This will not only result in lesser code being generated by ADLC
>>>> which effectively translates to size reduction in libjvm.so but also
>>>> help in better maintenance of AD files.
>>>>
>>>> Using generic operands we were able to collapse multiple vector
>>>> patterns over mainline
>>>>                Initial number of vector instruction patterns
>>>> (vec[XYZSD] + legVec[ZXYSD]   :  510
>>>>                Reduced vector instruction patterns  (vecG +
>>>> legVecG)                                  :  222
>>>>
>>>> With this we could see around 1MB size reduction in libjvm.so.
>>>>
>>>> In order to have minimal impact over downstream compiler passes, a
>>>> post-selection pass has been introduced (currently enabled only for
>>>> X86 target)
>>>> which replaces these generic operands with their corresponding
>>>> concreter vector length variants.
>>>>
>>>> JBS      : https://bugs.openjdk.java.net/browse/JDK-8230015
>>>> Patch  :
>>>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.00/
>>>>
>>>> Kindly review and share your feedback.
>>>>
>>>> Best Regards,
>>>> Jatin Bhateja
>>>>
>>>> [1]
>>>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_op
>>>> erands_support_v1.0.pdf
>>>>
>>>>


From vladimir.x.ivanov at oracle.com  Thu Apr 15 11:09:30 2021
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 15 Apr 2021 14:09:30 +0300
Subject: [External] : Re: 8230015: [instruction selector] generic vector
 operands support.
In-Reply-To: <15686c57-66ff-05a4-6f99-bd495ceb0a31@loongson.cn>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A042065@BGSMSX106.gar.corp.intel.com>
 <c8e81440-73d9-d8cf-3f67-5768edbb2398@loongson.cn>
 <17d6fd4c-196d-ea5b-f2a9-a2175e6ee652@oracle.com>
 <15686c57-66ff-05a4-6f99-bd495ceb0a31@loongson.cn>
Message-ID: <a4cb0178-22b3-6841-f98e-81f0a535528e@oracle.com>


>> It should be enough to provide implementations for those methods on 
>> YOURARCH to make Matcher::do_postselect_cleanup() working.
> 
> It is my fault: other VectorNodes, for example, `MulVD` and `ReplicateD` 
> also need to change `vecX/Y` to `vec` in the very beginning, not only 
> just LoadVector/StoreVector.? Sorry that I am too hurry to see the 
> optimization effect.

Yes, the downside is that there's no implicit operand conversion 
supported between concrete and generic vector operands. You have to 
migrate everything at once.

Best regards,
Vladimir Ivanov

>>
>> Can you elaborate on what exactly you are trying to accomplish?
> 
> Better SPECjvm2008 benchmark performance and meanwhile libjvm.so keep 
> slim :)
> 
> Thanks,
> Leslie Zhai
> 
>>
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 14.04.2021 08:09, Leslie Zhai wrote:
>>> Hi Jatin,
>>>
>>> Thanks for your great work!
>>>
>>> libjvm.so reduced +1MB will help SPECjvm2008 some benchmark +44% 
>>> speed up.
>>>
>>> Then I tried to port 8234391: C2: Generic vector operands for 
>>> `YOURARCH` about LoadVector and StoreVector at first.
>>>
>>> Only `Matcher::regmask_for_ideal_register` was able to call 
>>> `Matcher::is_generic_vector`, but compared with X86, 
>>> `Matcher::do_postselect_cleanup` was also able to call 
>>> `Matcher::is_generic_vector` too.
>>>
>>> I debug the `Matcher::do_postselect_cleanup`:
>>>
>>> diff --git a/src/hotspot/share/opto/matcher.cpp 
>>> b/src/hotspot/share/opto/matcher.cpp
>>> index 0846cad3c3f..8fd644d2d93 100644
>>> --- a/src/hotspot/share/opto/matcher.cpp
>>> +++ b/src/hotspot/share/opto/matcher.cpp
>>> @@ -309,6 +309,9 @@ void Matcher::match( ) {
>>> ???? C->record_method_not_compilable("must be able to represent all 
>>> call arguments in reg mask");
>>> ?? }
>>>
>>> +#ifdef YOURARCH64
>>> +? do_postselect_cleanup();
>>> +#endif
>>> ?? if (C->failing())? return;? // bailed out on incoming arg failure
>>>
>>> ?? // ---------------
>>> @@ -2630,8 +2633,10 @@ void 
>>> Matcher::specialize_generic_vector_operands() {
>>> ???????? int opnd_idx = m->operand_index(1);
>>> ???????? Node* def = m->in(opnd_idx);
>>> ???????? m->subsume_by(def, C);
>>> +#if !defined(YOURARCH64)
>>> ?????? } else if (m->is_MachTemp()) {
>>> ???????? // process MachTemp nodes at use site (see 
>>> Matcher::specialize_vector_operand)
>>> +#endif
>>> ?????? } else {
>>> ???????? specialize_mach_node(m);
>>> ?????? }
>>>
>>> But `Matcher::do_postselect_cleanup` was still not able to be called.
>>>
>>>> Current patch enables this support only for x86 target, to get a 
>>> feedback from community.
>>>
>>> Then how to port Generic vector operands for other targets?
>>>
>>> Thanks,
>>>
>>> Leslie Zhai
>>>
>>>
>>> ? 2019?08?22? 14:49, Bhateja, Jatin ??:
>>>> Hi All,
>>>>
>>>> Please find below a patch for generic vector operands[1] support 
>>>> during instruction selection.
>>>>
>>>> Motivation behind the patch is to reduce the number of vector 
>>>> selection patterns whose operands meagerly differ in vector lengths.
>>>> This will not only result in lesser code being generated by ADLC 
>>>> which effectively translates to size reduction in libjvm.so but also
>>>> help in better maintenance of AD files.
>>>>
>>>> Using generic operands we were able to collapse multiple vector 
>>>> patterns over mainline
>>>> ????????????? Initial number of vector instruction patterns 
>>>> (vec[XYZSD] + legVec[ZXYSD]?? :? 510
>>>> ????????????? Reduced vector instruction patterns? (vecG + 
>>>> legVecG)????????????????????????????????? :? 222
>>>>
>>>> With this we could see around 1MB size reduction in libjvm.so.
>>>>
>>>> In order to have minimal impact over downstream compiler passes, a 
>>>> post-selection pass has been introduced (currently enabled only for 
>>>> X86 target)
>>>> which replaces these generic operands with their corresponding 
>>>> concreter vector length variants.
>>>>
>>>> JBS????? : https://bugs.openjdk.java.net/browse/JDK-8230015
>>>> Patch? : 
>>>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.00/
>>>>
>>>> Kindly review and share your feedback.
>>>>
>>>> Best Regards,
>>>> Jatin Bhateja
>>>>
>>>> [1] 
>>>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf 
>>>>
>>>>
>>>
> 

From whuang at openjdk.java.net  Thu Apr 15 11:46:43 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 15 Apr 2021 11:46:43 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node
Message-ID: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>

* I optimize `max` and `min` by using these identities 
    - op (max(a,b) , min(a,b))=== op(a,b)
    - if op is commutable
    - example : 
      - max(a,b) + min(a,b))=== a + b // op = add
      - max(a,b) * min(a,b))=== a * b  // op = mul
      -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
      - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
* Test case 
  ```java
  /*
   * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
   * under the terms of the GNU General Public License version 2 only, as
   * published by the Free Software Foundation.
   *
   * This code is distributed in the hope that it will be useful, but WITHOUT
   * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
   * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
   * version 2 for more details (a copy is included in the LICENSE file that
   * accompanied this code).
   *
   * You should have received a copy of the GNU General Public License version
   * 2 along with this work; if not, write to the Free Software Foundation,
   * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
   *
   * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
   * or visit www.oracle.com if you need additional information or have any
   * questions.
   */
  package org.sample;
  
  import org.openjdk.jmh.annotations.Benchmark;
  import org.openjdk.jmh.annotations.*;
  
  import java.util.Random;
  import java.util.concurrent.TimeUnit;
  import org.openjdk.jmh.infra.Blackhole;
  
  @BenchmarkMode({Mode.AverageTime})
  @OutputTimeUnit(TimeUnit.MICROSECONDS)
  public class MyBenchmark {
  
      static int length = 100000;
      static double[] data1 = new double[length];
      static double[] data2 = new double[length];
      static Random random = new Random();
  
      static {
          for(int i = 0; i < length; ++i) {
            data1[i] = random.nextDouble();
            data2[i] = random.nextDouble();
          }
      }
  
      @Benchmark
      public void testAdd(Blackhole bh) {
        double sum = 0;
        for (int i = 0; i < length; i++) {
            sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
        }
        bh.consume(sum);
      }
  
      @Benchmark
      public void testMax(Blackhole bh) {
          double sum = 0;
          for (int i = 0; i < length; i++) {
              sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
          }
          bh.consume(sum);
      }
  
      @Benchmark
      public void testMin(Blackhole bh) {
          double sum = 0;
          for (int i = 0; i < length; i++) {
              sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
          }
          bh.consume(sum);
      }
  
      @Benchmark
      public void testMul(Blackhole bh) {
          double sum = 0;
          for (int i = 0; i < length; i++) {
              sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
          }
          bh.consume(sum);
      }
  }
  ```

*  The result is listed here:
    before:
    Benchmark                  Mode  Samples    Score  Score error  Units
    o.s.MyBenchmark.testAdd    avgt       10  556.048       32.368  us/op
    o.s.MyBenchmark.testMax    avgt       10  543.065       54.221  us/op
    o.s.MyBenchmark.testMin    avgt       10  570.731       37.630  us/op
    o.s.MyBenchmark.testMul    avgt       10  531.906       20.518  us/op
    after:
    Benchmark                  Mode  Samples    Score  Score error  Units
    o.s.MyBenchmark.testAdd    avgt       10  319.350        9.248  us/op
    o.s.MyBenchmark.testMax    avgt       10  356.138       10.736  us/op
    o.s.MyBenchmark.testMin    avgt       10  323.731       16.621  us/op
    o.s.MyBenchmark.testMul    avgt       10  338.458       23.755  us/op

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

Commit messages:
 - 8263006: Add optimization for Max(*)Node and Min(*)Node

Changes: https://git.openjdk.java.net/jdk/pull/3513/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3513&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263006
  Stats: 117 lines in 4 files changed: 107 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3513.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3513/head:pull/3513

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

From rehn at openjdk.java.net  Thu Apr 15 13:02:52 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 15 Apr 2021 13:02:52 GMT
Subject: RFR: 8264480: Unreachable code in nmethod.cpp inside #ifdef DEBUG
Message-ID: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>

Fixed ifdef to use correct define.

Stress tested locally, running t1-5.

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

Commit messages:
 - Fixed ifdef

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

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

From chagedorn at openjdk.java.net  Thu Apr 15 13:15:34 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 15 Apr 2021 13:15:34 GMT
Subject: RFR: 8264480: Unreachable code in nmethod.cpp inside #ifdef DEBUG
In-Reply-To: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
References: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
Message-ID: <qf3kX3AXMJ6deFkWbs70u_bx8NVKCxyYPVKyDRqEgGw=.db954146-6bdb-48ae-83e2-6460dedb3249@github.com>

On Thu, 15 Apr 2021 12:50:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Fixed ifdef to use correct define.
> 
> Stress tested locally, running t1-5.

Looks good.

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

Marked as reviewed by chagedorn (Reviewer).

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

From chagedorn at openjdk.java.net  Thu Apr 15 13:19:56 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 15 Apr 2021 13:19:56 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
Message-ID: <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>

> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 
> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
> 
> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
> 
> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
> 
> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
> 
> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
> 
> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>       - which leaves 4382 lines of code inserted 
> 
> Big thanks to:
> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
> - and others who provided valuable feedback.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:

  Adjust whitelist

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3508/files
  - new: https://git.openjdk.java.net/jdk/pull/3508/files/e2843410..7ed789dc

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

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

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

From kvn at openjdk.java.net  Thu Apr 15 16:52:34 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 15 Apr 2021 16:52:34 GMT
Subject: RFR: 8264480: Unreachable code in nmethod.cpp inside #ifdef DEBUG
In-Reply-To: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
References: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
Message-ID: <-Hx4zlH3PdtjGg-iyXFXscPQw-Aa1gPTeN7QrnZeU98=.6e52ab74-90aa-4833-ac07-09eccd1b836e@github.com>

On Thu, 15 Apr 2021 12:50:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Fixed ifdef to use correct define.
> 
> Stress tested locally, running t1-5.

Marked as reviewed by kvn (Reviewer).

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

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

From mikael at openjdk.java.net  Thu Apr 15 17:33:58 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 15 Apr 2021 17:33:58 GMT
Subject: Integrated: 8265302: ProblemList
 runtime/logging/RedefineClasses.java on linux-x64 -Xcomp
In-Reply-To: <TJooGb6GOM65gdmBxT2gOEdw09xZsg2vD8UYI21zCkM=.6fa1b39e-defd-4dc6-b970-8aa96cbfa6bd@github.com>
References: <TJooGb6GOM65gdmBxT2gOEdw09xZsg2vD8UYI21zCkM=.6fa1b39e-defd-4dc6-b970-8aa96cbfa6bd@github.com>
Message-ID: <2qJ24ep5dCgvGDB2hp3IDLGDlEUD2dmQGFO-R33W6Og=.f0195c38-0635-43eb-8444-2ed4b1f340fe@github.com>

On Thu, 15 Apr 2021 17:23:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp.

Marked as reviewed by mikael (Reviewer).

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

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

From dcubed at openjdk.java.net  Thu Apr 15 17:33:58 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 15 Apr 2021 17:33:58 GMT
Subject: Integrated: 8265302: ProblemList runtime/logging/RedefineClasses.java
 on linux-x64 -Xcomp
Message-ID: <TJooGb6GOM65gdmBxT2gOEdw09xZsg2vD8UYI21zCkM=.6fa1b39e-defd-4dc6-b970-8aa96cbfa6bd@github.com>

A trivial fix to ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp.

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

Commit messages:
 - 8265302: ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp

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

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

From dcubed at openjdk.java.net  Thu Apr 15 17:33:58 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 15 Apr 2021 17:33:58 GMT
Subject: Integrated: 8265302: ProblemList
 runtime/logging/RedefineClasses.java on linux-x64 -Xcomp
In-Reply-To: <2qJ24ep5dCgvGDB2hp3IDLGDlEUD2dmQGFO-R33W6Og=.f0195c38-0635-43eb-8444-2ed4b1f340fe@github.com>
References: <TJooGb6GOM65gdmBxT2gOEdw09xZsg2vD8UYI21zCkM=.6fa1b39e-defd-4dc6-b970-8aa96cbfa6bd@github.com>
 <2qJ24ep5dCgvGDB2hp3IDLGDlEUD2dmQGFO-R33W6Og=.f0195c38-0635-43eb-8444-2ed4b1f340fe@github.com>
Message-ID: <x_XZUyupPPxUdKMotcwtcPtoszczq49DATE-tFhbL3U=.81b7c12f-72d6-4787-99e0-16c72427c734@github.com>

On Thu, 15 Apr 2021 17:27:40 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivial fix to ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the lightning fast review!

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

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

From dcubed at openjdk.java.net  Thu Apr 15 17:33:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 15 Apr 2021 17:33:59 GMT
Subject: Integrated: 8265302: ProblemList runtime/logging/RedefineClasses.java
 on linux-x64 -Xcomp
In-Reply-To: <TJooGb6GOM65gdmBxT2gOEdw09xZsg2vD8UYI21zCkM=.6fa1b39e-defd-4dc6-b970-8aa96cbfa6bd@github.com>
References: <TJooGb6GOM65gdmBxT2gOEdw09xZsg2vD8UYI21zCkM=.6fa1b39e-defd-4dc6-b970-8aa96cbfa6bd@github.com>
Message-ID: <FdRIz1th6AztJR-GsSL9UTmWk0TF_l0iqcEO3cymFfY=.2cb34582-d3db-4222-9383-99c12affdd92@github.com>

On Thu, 15 Apr 2021 17:23:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp.

This pull request has now been integrated.

Changeset: c7da64a4
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c7da64a4
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8265302: ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp

Reviewed-by: mikael

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

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

From iignatyev at openjdk.java.net  Thu Apr 15 17:52:34 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 15 Apr 2021 17:52:34 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
Message-ID: <xxbm1as_hR1VGJ7xG7FRMFDBpPJWYstFiiC8VoCOvSo=.8b7237ef-4bb6-4471-b9c7-404b8f10a6ec@github.com>

On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust whitelist

Hi Christian,

kudos to you, Tobias, Katya, and all involved, I have really high hopes that this framework will improve the quality of both JVM and our testing.  

I'll look at the code later, a few general comments: 
 - although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files
 - the same goes for `README.html` generated from `README.md`
 - this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`.
 - I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot`


Thanks,
-- Igor

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

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

From kvn at openjdk.java.net  Thu Apr 15 18:08:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 15 Apr 2021 18:08:38 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
Message-ID: <uPzckD9PeCL-nvTQxAijetsqYo4cx66VvNEFSYAlMMY=.148a5e41-1c45-46c5-aaf1-eaa73686f4e8@github.com>

On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust whitelist

I understand the desire to use this framework for more then IR verification but it is main goal.
Why you did not place it into `test/lib/sun/hotspot/code/`?

I also don't think you should include javadoc generated files into these changes.

test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 62:

> 60:      *  </ul>
> 61:      */
> 62:     ANY(-2),

This will change (`-2` -> `-1`) after AOT is removed (8264805).

test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 63:

> 61:      */
> 62:     ANY(-2),
> 63:     /**

For completeness may be add value `NONE(0)` for Interpreter only case.

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 478:

> 476:  * Helper class to store information about a method that needs to be IR matched.
> 477:  */
> 478: class IRMethod {

Can you move this class `IRMethod` into a separate file? This file is already big.

test/lib/jdk/test/lib/hotspot/ir_framework/examples/TEST.ROOT line 1:

> 1: # Minimal TEST.ROOT file to run the examples tests as if the examples would have been placed inside

Missing Copyright header.

test/lib/jdk/test/lib/hotspot/ir_framework/tests/README.md line 7:

> 5: 
> 6: Additional testing should be performed with the converted Valhalla tests (see [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) to make sure a changeset is correct (these are part of the Valhalla CI).
> 7: 

I don't think you should reference particular RFE which will be resolved eventually. The statement itself is fine.

test/lib/jdk/test/lib/hotspot/ir_framework/tests/TEST.ROOT line 1:

> 1: # Minimal TEST.ROOT file to run the internal framework tests as if they would have been placed inside

Missing Copyright header.

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

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

From github.com+2249648+johntortugo at openjdk.java.net  Thu Apr 15 18:28:02 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 15 Apr 2021 18:28:02 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler [v7]
In-Reply-To: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
Message-ID: <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@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:

  Use cdql/cdqq implemented in MacroAssembler.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2420/files
  - new: https://git.openjdk.java.net/jdk/pull/2420/files/6fecb5dc..ef7a993c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=05-06

  Stats: 69 lines in 1 file changed: 0 ins; 63 del; 6 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 Apr 15 18:30:37 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 15 Apr 2021 18:30:37 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler [v7]
In-Reply-To: <bA7R9JV0PNktx9RDgBlkcoa3nf5CWaR5QzqXiEnrnHA=.d0a8820f-742c-4a58-bcbc-f9081149ce6d@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <00CZum78AaG7wa9LLxbJNiIsYVqT_Ice0Gl3ucxglW4=.b94a74d7-0c88-4ca8-9986-5b5c67929297@github.com>
 <bA7R9JV0PNktx9RDgBlkcoa3nf5CWaR5QzqXiEnrnHA=.d0a8820f-742c-4a58-bcbc-f9081149ce6d@github.com>
Message-ID: <fqRqf4-tnkKrhsinq_FCtkgjHhKpB25kWWb2GmobBsU=.61ced325-1826-41de-b96a-d959dd72963d@github.com>

On Mon, 29 Mar 2021 10:44:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use cdql/cdqq implemented in MacroAssembler.
>
> src/hotspot/cpu/x86/x86_64.ad line 8329:
> 
>> 8327:     "done:"        %}
>> 8328:   opcode(0xF7, 0x7);  /* Opcode F7 /7 */
>> 8329:   ins_encode(cdql_enc(div), REX_reg(div), OpcP, reg_opc(div));
> 
> `cdql_enc`/`cdqq_enc` contain extensive comments about the logic. What about migrating them to dedicated methods in `MacroAssembler`/`C2_MacroAssembler` (`idivrem`/`ldivrem`) and calling those from `divI_rReg` / `divL_rReg`/`divModL_rReg_divmod`/...?

Hi Vladimir, thanks for the comment. Actually, there is already an implementation of cdql/cdqq in MacroAssembler, the names are slightly different though: corrected_idivl and corrected_idivq. I followed your suggestion and replaced the encoding of div*_rReg / divMod*_rReg_divmod and mod*_rReg with calls to these two functions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From dnsimon at openjdk.java.net  Thu Apr 15 19:05:33 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 15 Apr 2021 19:05:33 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
Message-ID: <nY--JO_prShpuSOsg52khe6DLSSC_7VZjtcp5unbUgQ=.d8615a76-17d6-4210-9afd-211b4be456d6@github.com>

On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust whitelist

test/lib/jdk/test/lib/hotspot/ir_framework/README.html line 1:

> 1: <h1>IR Test Framework</h1>

Just curious: why HTML instead of markdown?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Fri Apr 16 00:44:36 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 16 Apr 2021 00:44:36 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <uPzckD9PeCL-nvTQxAijetsqYo4cx66VvNEFSYAlMMY=.148a5e41-1c45-46c5-aaf1-eaa73686f4e8@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <uPzckD9PeCL-nvTQxAijetsqYo4cx66VvNEFSYAlMMY=.148a5e41-1c45-46c5-aaf1-eaa73686f4e8@github.com>
Message-ID: <JitZ0mzE5m9xgC_cNyp2hs9EgGy0MuQR7TirTYB0U_k=.6ebccb53-f334-418b-a54a-b88286a23775@github.com>

On Thu, 15 Apr 2021 18:05:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Why you did not place it into `test/lib/sun/hotspot/code/`?
there is an RFE to rename `sun.hotspot` testlibrary classes, so I wouldn't put new stuff there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Fri Apr 16 01:33:37 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 16 Apr 2021 01:33:37 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
Message-ID: <F0eo7Zs3FqdH33meE7Br0fgSbTfhkCQaBqp4-FXcF6M=.ba0201be-dfbb-49a6-836c-bf0037fd8fdc@github.com>

On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust whitelist

Hi Christian,

here is the 1st portion of my comments. I'll return to reviewing it 1st thing tomorrow...

Cheers,
-- Igor

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 107:

> 105:      */
> 106:     public static final Set<String> JTREG_WHITELIST_FLAGS = new HashSet<>(
> 107:             Arrays.asList(

it doesn't seem to be a comprehensive list of flags that don't affect IR verification work, e.g. different GCs. I think it might be easy to go with the blacklist instead, and possibly warning people if there are any flags in `test.*.opts`.

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 146:

> 144:     private List<Class<?>> helperClasses = null;
> 145:     private List<Scenario> scenarios = null;
> 146:     private final List<String> flags = new ArrayList<>();

why did you decide to eagerly create list for `flags`, but not for `scenarios` / `helpersClasses`?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 166:

> 164:         if (VERBOSE) {
> 165:             System.out.println("Test class: " + testClass);
> 166:         }

this c-tor can be replaced by:
Suggestion:

        this(StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).getCallerClass());


and actually, I don't see it being used (outside of the tests for this testlibrary) and I don't think it will ever be used by actual tests that would use this framework, so I think we can safely remove it.

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 211:

> 209:     }
> 210: 
> 211:     /**

I'm not sure how much of the benefits all these different `run.*` bring. I fully understand the desire to simplify the most common use-case (i.e. no-arg `run`), but for the rest I'd assume the users will be capable of writing, for example, `new TestFramework(testClass).addScenarios(scenarios).start();` instead of `TestFramework .runWithScenarios(testClass, scenarios);`

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 269:

> 267:      * <ul>
> 268:      *     <li><p>If a helper class is not in the same file as the test class, make sure that JTreg compiles it by using
> 269:      *     {@literal @}compile in the JTreg header comment block.</li>

you don't need `@compile` to compile a helper class, 1st of all, you shouldn't use `@compile` when you want to compile a class in your test, you should use `@build`, 2nd, in this particular case, the class will be automatically built as part of your test b/c jtreg (or rather javac) will be able to statically detect it as a dependency of the code that calls `runWithHelperClasses(Class, Class...)`

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 366:

> 364:         }
> 365: 
> 366:         for (Class<?> helperClass : helperClasses) {

nit: I'd use `var` here

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 367:

> 365: 
> 366:         for (Class<?> helperClass : helperClasses) {
> 367:             TestRun.check(!this.helperClasses.contains(helperClass), "Cannot add the same class twice: " + helperClass);

won't it be easy to use `Set` to store `helperClasses`?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 407:

> 405:                 start(null);
> 406:             } catch (TestVMException e) {
> 407:                 System.err.println("\n" + e.getExceptionInfo());

you shouldn't use "\n", as it might not be the right line-separator. you can either do:
Suggestion:

                System.err.println();
                System.err.println(e.getExceptionInfo());

or
Suggestion:

                System.err.printf("%n%s%n", e.getExceptionInfo());

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 604:

> 602:      * Disable IR verification completely in certain cases.
> 603:      */
> 604:     private void maybeDisableIRVerificationCompletely() {

nit: 
Suggestion:

    private void disableIRVerificationIfNotFeasible() {

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 617:

> 615:                                    "and PrintOptoAssembly), running with -Xint, or -Xcomp (use warm-up of 0 instead)");
> 616:                 return;
> 617:             }

I'd reorder them as "platform" checks are faster than `hasIRAnnotations` check and, I'd guess, will be a more common culprit to disable IR verification.

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 669:

> 667:             }
> 668:             if (e instanceof IRViolationException) {
> 669:                 IRViolationException irException = (IRViolationException) e;

nit:
Suggestion:

            if (e instanceof IRViolationException irException) {

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 674:

> 672:                                    + "Compilation(s) of failed matche(s):");
> 673:                 System.out.println(irException.getCompilations());
> 674:                 builder.append(errorMsg).append("\n").append(irException.getExceptionInfo()).append(e.getMessage());

as `builder.toString` will be printed out to cout/cerr, you should use platform-specific line-separator instead of `\n`

-------------

Changes requested by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Fri Apr 16 01:33:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 16 Apr 2021 01:33:38 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <F0eo7Zs3FqdH33meE7Br0fgSbTfhkCQaBqp4-FXcF6M=.ba0201be-dfbb-49a6-836c-bf0037fd8fdc@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <F0eo7Zs3FqdH33meE7Br0fgSbTfhkCQaBqp4-FXcF6M=.ba0201be-dfbb-49a6-836c-bf0037fd8fdc@github.com>
Message-ID: <So18R3zB8dbCvYW50l3Lox7gY3bxsPO6ncST8SurJUc=.c9121fa9-8b70-4b7c-96a7-99090d58f290@github.com>

On Fri, 16 Apr 2021 01:08:28 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust whitelist
>
> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 367:
> 
>> 365: 
>> 366:         for (Class<?> helperClass : helperClasses) {
>> 367:             TestRun.check(!this.helperClasses.contains(helperClass), "Cannot add the same class twice: " + helperClass);
> 
> won't it be easy to use `Set` to store `helperClasses`?

you might also want to update javadoc for this method to state that there can be duplicates.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From whuang at openjdk.java.net  Fri Apr 16 01:40:01 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 16 Apr 2021 01:40:01 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
Message-ID: <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>

> * I optimize `max` and `min` by using these identities 
>     - op (max(a,b) , min(a,b))=== op(a,b)
>     - if op is commutable
>     - example : 
>       - max(a,b) + min(a,b))=== a + b // op = add
>       - max(a,b) * min(a,b))=== a * b  // op = mul
>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
> * Test case 
>   ```java
>   /*
>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
>    * under the terms of the GNU General Public License version 2 only, as
>    * published by the Free Software Foundation.
>    *
>    * This code is distributed in the hope that it will be useful, but WITHOUT
>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>    * version 2 for more details (a copy is included in the LICENSE file that
>    * accompanied this code).
>    *
>    * You should have received a copy of the GNU General Public License version
>    * 2 along with this work; if not, write to the Free Software Foundation,
>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>    *
>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>    * or visit www.oracle.com if you need additional information or have any
>    * questions.
>    */
>   package org.sample;
>   
>   import org.openjdk.jmh.annotations.Benchmark;
>   import org.openjdk.jmh.annotations.*;
>   
>   import java.util.Random;
>   import java.util.concurrent.TimeUnit;
>   import org.openjdk.jmh.infra.Blackhole;
>   
>   @BenchmarkMode({Mode.AverageTime})
>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>   public class MyBenchmark {
>   
>       static int length = 100000;
>       static double[] data1 = new double[length];
>       static double[] data2 = new double[length];
>       static Random random = new Random();
>   
>       static {
>           for(int i = 0; i < length; ++i) {
>             data1[i] = random.nextDouble();
>             data2[i] = random.nextDouble();
>           }
>       }
>   
>       @Benchmark
>       public void testAdd(Blackhole bh) {
>         double sum = 0;
>         for (int i = 0; i < length; i++) {
>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>         }
>         bh.consume(sum);
>       }
>   
>       @Benchmark
>       public void testMax(Blackhole bh) {
>           double sum = 0;
>           for (int i = 0; i < length; i++) {
>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>           }
>           bh.consume(sum);
>       }
>   
>       @Benchmark
>       public void testMin(Blackhole bh) {
>           double sum = 0;
>           for (int i = 0; i < length; i++) {
>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>           }
>           bh.consume(sum);
>       }
>   
>       @Benchmark
>       public void testMul(Blackhole bh) {
>           double sum = 0;
>           for (int i = 0; i < length; i++) {
>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>           }
>           bh.consume(sum);
>       }
>   }
>   ```
> 
> *  The result is listed here (aarch64):
> 
>   before:
> 
>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>   |---|                           ---|  ---|    ---|  --- | ---|
>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>  
>   after:
> 
>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>   |---|                           ---|  ---|    ---|  --- | ---|
>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  adjust code style

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3513/files
  - new: https://git.openjdk.java.net/jdk/pull/3513/files/f132222e..7579586f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3513&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3513&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3513.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3513/head:pull/3513

PR: https://git.openjdk.java.net/jdk/pull/3513

From xgong at openjdk.java.net  Fri Apr 16 01:46:32 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 16 Apr 2021 01:46:32 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v4]
In-Reply-To: <YkaTSqeHwZ92BdTyIL754hRivc8UXUPjFN2lr6UIJs8=.aef9c173-4196-4e82-b819-e9979090064a@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
 <vW73f_ipX6VPIgyQbHD1Q1i7DOPFhvo3U3JbUBNHD5Y=.7e547d28-e6e2-4523-8573-35f4f4bfed64@github.com>
 <x8_XL0KjlpU2OtgJFYLqJi_nFGo_LbV55eVtJPJaBe8=.74b49e7c-b6ad-4c32-a67c-e0eec30df40f@github.com>
 <YkaTSqeHwZ92BdTyIL754hRivc8UXUPjFN2lr6UIJs8=.aef9c173-4196-4e82-b819-e9979090064a@github.com>
Message-ID: <E-zj_eK90Ulj7YxCysBJV7WNijBsZDCTeryWaCmgwww=.d3b56d11-c0ff-4e72-bd19-7662085647b9@github.com>

On Thu, 15 Apr 2021 09:53:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Thanks for addressing it. as Vladimir suggested in long term we can just emit this node instead of VectorStoreMask + VectorLoadMask combination when mask types are non-conformal to emit efficient instruction sequence using input mask packing/unpacking.

Yeah, previously I thought about this. However, considering there are some optimizations like GVN for `VectorStoreMask`, currently I prefer to keep the code as it is. Maybe we can reconsider this in future. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3238

From whuang at openjdk.java.net  Fri Apr 16 02:10:10 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 16 Apr 2021 02:10:10 GMT
Subject: RFR: 8265244: assert(false) failed: bad AD file [v2]
In-Reply-To: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
Message-ID: <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>

> * aarch64 can only accept `VectorReinterpret` with 64/128 bits.
> * I will fix this bug by adding a rule for `VectorReinterpret` in `match_rule_supported_vector`
> * after changing note with @nsjian and @XiaohongGong , I think that two checks in `inline_vector_conver` is useless now. However, these checks impact other cpus, so I need more reviewers.

Wang Huang 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 JDK-8265244
 - 8265244: assert(false) failed: bad AD file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3507/files
  - new: https://git.openjdk.java.net/jdk/pull/3507/files/f65c8671..522b256f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3507&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3507&range=00-01

  Stats: 1045 lines in 44 files changed: 798 ins; 153 del; 94 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3507/head:pull/3507

PR: https://git.openjdk.java.net/jdk/pull/3507

From yyang at openjdk.java.net  Fri Apr 16 03:16:04 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 16 Apr 2021 03:16:04 GMT
Subject: RFR: 8265322: C2: Simplify control inputs for
 BarrierSetC2::obj_allocate
Message-ID: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>

This PR simplifies control inputs for BarrierSetC2::obj_allocate. In most cases, it doesn't change anything since `toobig_false` is equivalent to `ctrl`. In rare case, `toobig_false` is created for Unsafe.allocateInstance while instance size is not statically known, `ctrl` would become control input of IfNode whose projects are `toobig_false` and `toobig_true`, old eden_end and old_eden_top can simply accept `toobig_false` as their control input rather than `ctrl`.

-------------

Commit messages:
 - simplify

Changes: https://git.openjdk.java.net/jdk/pull/3529/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3529&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265322
  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3529.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3529/head:pull/3529

PR: https://git.openjdk.java.net/jdk/pull/3529

From yyang at openjdk.java.net  Fri Apr 16 03:16:58 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 16 Apr 2021 03:16:58 GMT
Subject: RFR: 8265245: depChecker_<cpu> don't have any functionalities
Message-ID: <1JKPxPdQ9XoTDXdIP8P_eBy6EqYZhEoD8SACCs0MfSs=.d5cd2e5f-6c11-4be8-8651-3931368d1471@github.com>

Yet another OpenJDK6 old guy.

src/hotspot/cpu/<cpu>/depChecker_<cpu>.hpp/cpp are included by src/hotspot/share/compiler/disassembler.cpp, they don't provide any functionality.

In the absence of strong demand either in existing ARCHs or future ARCHs, I think we can remove it.

-------------

Commit messages:
 - remove depcheck_<cpu>

Changes: https://git.openjdk.java.net/jdk/pull/3531/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3531&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265245
  Stats: 305 lines in 13 files changed: 0 ins; 305 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3531/head:pull/3531

PR: https://git.openjdk.java.net/jdk/pull/3531

From yyang at openjdk.java.net  Fri Apr 16 03:23:06 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 16 Apr 2021 03:23:06 GMT
Subject: RFR: 8265323: Leftover local variables in PcDesc
Message-ID: <G9FMO7Ufi1r0TDmkBZT4Pp55_BEGsEY2E-GFieB8JwQ=.fcdd124e-9e4b-41b7-bce1-2821651f948e@github.com>

Leftover local variables in PcDesc. Remove it to save electric power.

-------------

Commit messages:
 - remove unused local vars

Changes: https://git.openjdk.java.net/jdk/pull/3532/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3532&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265323
  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3532.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3532/head:pull/3532

PR: https://git.openjdk.java.net/jdk/pull/3532

From xgong at openjdk.java.net  Fri Apr 16 03:36:02 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 16 Apr 2021 03:36:02 GMT
Subject: RFR: 8264104: Eliminate unnecessary vector mask conversion during
 VectorUnbox for floating point VectorMask [v6]
In-Reply-To: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
Message-ID: <0Oh1jRqGYglCqibmgxl3D5_H99UFu2if2VYuhwSb-Lk=.29a8f263-4375-46f9-811c-6a68d8f8a189@github.com>

> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
> 
> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
> 
>   VectorLoadMask (VectorStoreMask vmask)
> 
> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
> vectors with the same element size and vector length, it's safe to do the optimization:
> 
>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
> 
> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.

Xiaohong Gong 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 five additional commits since the last revision:

 - Merge jdk 'master' into JDK-8264104
 - Add type restrict in the match rule predicate
 - Use "Matcher::match_rule_supported_vector" for vector nodes checking
 - Revert changes to VectorLoadMask and add a VectorMaskCast for the same element size mask casting
 - 8264104: Eliminate unnecessary vector mask conversion during VectorUnbox for floating point VectorMask

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3238/files
  - new: https://git.openjdk.java.net/jdk/pull/3238/files/8232bd96..e4352b39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3238&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3238&range=04-05

  Stats: 96154 lines in 2370 files changed: 53099 ins; 34862 del; 8193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3238.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3238/head:pull/3238

PR: https://git.openjdk.java.net/jdk/pull/3238

From jiefu at openjdk.java.net  Fri Apr 16 06:58:00 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 16 Apr 2021 06:58:00 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x, 0.5)
Message-ID: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>

Hi all,

I'd like to optimize the StubRoutines::dpow() for Math.pow(x, 0.5).

In the pow and sqrt discussion [1], Joe taught me that the Java library implementation of pow has been optimized for pow(x, 2.0) [2] and pow(x, 0.5) [3].
However, the hotspot StubRoutines::dpow() only implements the same opt for pow(x, 2.0), but still not for pow(x, 0.5).
This patch optimizes StubRoutines::dpow() for pow(x, 0.5).

Although not all Math.pow(x, 0.5) can be replaced with sqrt(x), we can still do it safely for the following cases:
  1) x >= 0.0    (fully implemented)
  2) x is +Inf   (fully implemented)
  3) x is NaN    (can be further divided into +NaN and -NaN and only +NaN is implemented)

The effect of this opt has been tested on serveral platforms showing 3.0x ~ 6.3x performance improvement.
And no performance drop was observed.

Testing:
  - tier1 ~ tier3 on Linux/x64

Thanks.
Best regards,
Jie

[1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076220.html
[2] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L362
[3] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L364

Detailed performance numbers:
* Linux/Intel

--------- Before -----------
Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
MathBench.powDouble                 0  thrpt    8  218783.605 ?   838.379  ops/ms
MathBench.powDouble0Dot5            0  thrpt    8   45498.351 ?     7.558  ops/ms
MathBench.powDouble0Dot5Const       0  thrpt    8   45243.530 ?  1097.100  ops/ms
MathBench.powDouble0Dot5Loop        0  thrpt    8       0.031 ?     0.001  ops/ms
MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
StrictMathBench.powDouble         N/A  thrpt    8  176106.602 ? 13127.650  ops/ms
----------------------------

--------- After -----------
Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
MathBench.powDouble                 0  thrpt    8  219930.462 ?   181.922  ops/ms
MathBench.powDouble0Dot5            0  thrpt    8  204966.834 ?   329.032  ops/ms   <-- 4.5x up
MathBench.powDouble0Dot5Const       0  thrpt    8  203004.302 ?   684.072  ops/ms
MathBench.powDouble0Dot5Loop        0  thrpt    8       0.121 ?     0.001  ops/ms   <-- 3.9x up
MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
StrictMathBench.powDouble         N/A  thrpt    8  178818.861 ? 16235.465  ops/ms
----------------------------


* Linux/AMD

--------- Before -----------
Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
MathBench.powDouble                 0  thrpt    8  100741.348 ? 207.766  ops/ms
MathBench.powDouble0Dot5            0  thrpt    8   33896.623 ? 103.352  ops/ms
MathBench.powDouble0Dot5Const       0  thrpt    8   34195.944 ? 230.703  ops/ms
MathBench.powDouble0Dot5Loop        0  thrpt    8       0.039 ?   0.001  ops/ms
MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
StrictMathBench.powDouble         N/A  thrpt    8   72000.166 ? 135.002  ops/ms
----------------------------

--------- After -----------
Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
MathBench.powDouble                 0  thrpt    8  100738.866 ? 222.820  ops/ms
MathBench.powDouble0Dot5            0  thrpt    8  100799.098 ?  95.537  ops/ms   <-- 3.0x up
MathBench.powDouble0Dot5Const       0  thrpt    8  100765.571 ? 178.436  ops/ms
MathBench.powDouble0Dot5Loop        0  thrpt    8       0.244 ?   0.002  ops/ms   <-- 6.3x up
MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
StrictMathBench.powDouble         N/A  thrpt    8   71758.725 ? 339.660  ops/ms
----------------------------


* MacOS/Intel

--------- Before -----------
Benchmark                      (seed)   Mode  Cnt       Score      Error   Units
MathBench.powDouble                 0  thrpt    8  238064.722 ? 5181.318  ops/ms
MathBench.powDouble0Dot5            0  thrpt    8   59235.979 ? 2046.519  ops/ms
MathBench.powDouble0Dot5Const       0  thrpt    8   59695.014 ? 1079.692  ops/ms
MathBench.powDouble0Dot5Loop        0  thrpt    8       0.040 ?    0.001  ops/ms
MathBench.powDoubleLoop             0  thrpt    8       0.041 ?    0.001  ops/ms
StrictMathBench.powDouble         N/A  thrpt    8  238391.026 ? 2743.385  ops/ms
----------------------------

--------- After -----------
Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
MathBench.powDouble                 0  thrpt    8  238582.414 ?  3661.261  ops/ms
MathBench.powDouble0Dot5            0  thrpt    8  224102.701 ?  2846.892  ops/ms   <-- 3.8x up
MathBench.powDouble0Dot5Const       0  thrpt    8  224542.331 ? 19027.596  ops/ms
MathBench.powDouble0Dot5Loop        0  thrpt    8       0.158 ?     0.002  ops/ms   <-- 4.0x up
MathBench.powDoubleLoop             0  thrpt    8       0.041 ?     0.001  ops/ms
StrictMathBench.powDouble         N/A  thrpt    8  233689.504 ? 10141.034  ops/ms
----------------------------

-------------

Commit messages:
 - 8265325: Optimize StubRoutines::dpow() for Math.pow(x, 0.5)

Changes: https://git.openjdk.java.net/jdk/pull/3536/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3536&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265325
  Stats: 144 lines in 3 files changed: 142 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3536.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3536/head:pull/3536

PR: https://git.openjdk.java.net/jdk/pull/3536

From jiefu at openjdk.java.net  Fri Apr 16 07:08:35 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 16 Apr 2021 07:08:35 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
In-Reply-To: <l3o653-2gcl0bTV4qfKCwjc7PmEFUyXTVnfPhevU3Yw=.cab7930d-44ea-4a2d-89e4-dcd112a539dc@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <l3o653-2gcl0bTV4qfKCwjc7PmEFUyXTVnfPhevU3Yw=.cab7930d-44ea-4a2d-89e4-dcd112a539dc@github.com>
Message-ID: <obtg1U8CztI4U_RRHfuSjtGp6hBIHLbXIfMMH-_sUHg=.d145f001-bbc1-47ee-bfd6-1ef49df288ed@github.com>

On Fri, 9 Apr 2021 22:39:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> I'd like to optimize the code-gen for Math.pow(x, 0.5).
>> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
>> 
>> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
>> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
>> 
>> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
>> 
>> Before:
>> 
>> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
>> 
>> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
>> 
>> 
>> After:
>> 
>> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
>> 
>> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
>> 
>> 
>> Testing:
>>   - tier1~3 on Linux/x64
>> 
>> Thanks,
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680
>
> Please, verify that result is the same when run with -Xint (Interpreter only) and (-XX:TieredStopAtLevel=1) C1 only. May be they need the same optimization.

> Hi @vnkozlov @neliasso and @huishi-hs ,
> 
> Thanks for your review and comments.
> While I was implementing the opt for C1 and interpreter, I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values for x={-0.0, Double.NEGATIVE_INFINITY} [1].
> Let's hold on this issue until we have a conclusion about that question.
> Thanks.
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076195.html

Hi all,

According to the discussion [1], we can still perform pow(x, 0.5) => sqrt(x) for x >= 0.0 or x is +Inf/NaN.

To better help the code review, the whole optimization has been split into JDK-8265325 and JDK-8264945.
 - 1) JDK-8265325: Optimize StubRoutines::dpow() for Math.pow(x, 0.5)
 - 2) JDK-8264945: Optimize the code-gen for Math.pow(x, 0.5)

I'll update this pr once JDK-8265325 is finished since it depends on JDK-8265325.

Thanks.
Best regards,
Jie

[1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076220.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From xgong at openjdk.java.net  Fri Apr 16 07:16:36 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 16 Apr 2021 07:16:36 GMT
Subject: Integrated: 8264104: Eliminate unnecessary vector mask conversion
 during VectorUnbox for floating point VectorMask
In-Reply-To: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
References: <BT57hrfiCn3oS5mm2JL_bjBISh7gz71Sq9098ouUXA0=.0b67dca8-8281-49f4-a40f-c94745e05d12@github.com>
Message-ID: <EkRNV91SJgu-Ir39Sp_CRofdOmEw5s7nL9ndPSz_zDs=.ac87a905-41b3-4e8f-9c95-154907b38db9@github.com>

On Mon, 29 Mar 2021 06:00:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
> 
> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
> 
>   VectorLoadMask (VectorStoreMask vmask)
> 
> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
> vectors with the same element size and vector length, it's safe to do the optimization:
> 
>   VectorLoadMask (VectorStoreMask vmask) ==> vmask
> 
> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.

This pull request has now been integrated.

Changeset: e0151a6f
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0151a6f
Stats:     103 lines in 9 files changed: 102 ins; 0 del; 1 mod

8264104: Eliminate unnecessary vector mask conversion during VectorUnbox for floating point VectorMask

Reviewed-by: kvn, vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3238

From rehn at openjdk.java.net  Fri Apr 16 07:18:36 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 16 Apr 2021 07:18:36 GMT
Subject: RFR: 8264480: Unreachable code in nmethod.cpp inside #ifdef DEBUG
In-Reply-To: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
References: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
Message-ID: <NAbZlnMxiaqCO59XpijRH4dsyGymQEwbhn0JrC0ps4w=.f42a7647-17a7-4ae0-b14a-63a94a626d3c@github.com>

On Thu, 15 Apr 2021 12:50:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Fixed ifdef to use correct define.
> 
> Stress tested locally, running t1-5.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3517

From rehn at openjdk.java.net  Fri Apr 16 07:22:34 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 16 Apr 2021 07:22:34 GMT
Subject: RFR: 8264480: Unreachable code in nmethod.cpp inside #ifdef DEBUG
In-Reply-To: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
References: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
Message-ID: <xVqSmOiuNER4ZB2wooViriIa8h3nXIw5mTUB4Am8qTg=.e45ca701-6dfe-4235-9d56-6e2685f55025@github.com>

On Thu, 15 Apr 2021 12:50:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Fixed ifdef to use correct define.
> 
> Stress tested locally, running t1-5.

Passed t1-5.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3517

From rehn at openjdk.java.net  Fri Apr 16 07:22:34 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 16 Apr 2021 07:22:34 GMT
Subject: Integrated: 8264480: Unreachable code in nmethod.cpp inside #ifdef
 DEBUG
In-Reply-To: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
References: <rERkZvEwzV1n_yNHO3I2D7MUKEVtVzlrjeZsB23TMFE=.f5f671d0-49ee-4e96-8df9-461e335cd456@github.com>
Message-ID: <zwbVYYRqqEfsRgCPK-zRDhE-DwxWUrm5fQ_K5iAjFLw=.498a7807-cbdf-4e8b-b15f-928c0d7ae0c5@github.com>

On Thu, 15 Apr 2021 12:50:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Fixed ifdef to use correct define.
> 
> Stress tested locally, running t1-5.

This pull request has now been integrated.

Changeset: 50f3da8d
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/50f3da8d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8264480: Unreachable code in nmethod.cpp inside #ifdef DEBUG

Reviewed-by: chagedorn, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3517

From jiefu at openjdk.java.net  Fri Apr 16 07:30:11 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 16 Apr 2021 07:30:11 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v2]
In-Reply-To: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
Message-ID: <iS-bmLoqbTFTSO4gEXlQuH3mIeybrxQ1aniwBbm-z4c=.6316efaa-3f77-4f9d-9e63-31325a112e14@github.com>

> Hi all,
> 
> I'd like to optimize the StubRoutines::dpow() for Math.pow(x, 0.5).
> 
> In the pow and sqrt discussion [1], Joe taught me that the Java library implementation of pow has been optimized for pow(x, 2.0) [2] and pow(x, 0.5) [3].
> However, the hotspot StubRoutines::dpow() only implements the same opt for pow(x, 2.0), but still not for pow(x, 0.5).
> This patch optimizes StubRoutines::dpow() for pow(x, 0.5).
> 
> Although not all Math.pow(x, 0.5) can be replaced with sqrt(x), we can still do it safely for the following cases:
>   1) x >= 0.0    (fully implemented)
>   2) x is +Inf   (fully implemented)
>   3) x is NaN    (can be further divided into +NaN and -NaN and only +NaN is implemented)
> 
> The effect of this opt has been tested on serveral platforms showing 3.0x ~ 6.3x performance improvement.
> And no performance drop was observed.
> 
> Testing:
>   - tier1 ~ tier3 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076220.html
> [2] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L362
> [3] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L364
> 
> Detailed performance numbers:
> * Linux/Intel
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  218783.605 ?   838.379  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   45498.351 ?     7.558  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   45243.530 ?  1097.100  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.031 ?     0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  176106.602 ? 13127.650  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  219930.462 ?   181.922  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  204966.834 ?   329.032  ops/ms   <-- 4.5x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  203004.302 ?   684.072  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.121 ?     0.001  ops/ms   <-- 3.9x up
> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  178818.861 ? 16235.465  ops/ms
> ----------------------------
> 
> 
> * Linux/AMD
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble                 0  thrpt    8  100741.348 ? 207.766  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   33896.623 ? 103.352  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   34195.944 ? 230.703  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.039 ?   0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8   72000.166 ? 135.002  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble                 0  thrpt    8  100738.866 ? 222.820  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  100799.098 ?  95.537  ops/ms   <-- 3.0x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  100765.571 ? 178.436  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.244 ?   0.002  ops/ms   <-- 6.3x up
> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8   71758.725 ? 339.660  ops/ms
> ----------------------------
> 
> 
> * MacOS/Intel
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score      Error   Units
> MathBench.powDouble                 0  thrpt    8  238064.722 ? 5181.318  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   59235.979 ? 2046.519  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   59695.014 ? 1079.692  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.040 ?    0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?    0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  238391.026 ? 2743.385  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  238582.414 ?  3661.261  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  224102.701 ?  2846.892  ops/ms   <-- 3.8x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  224542.331 ? 19027.596  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.158 ?     0.002  ops/ms   <-- 4.0x up
> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  233689.504 ? 10141.034  ops/ms
> ----------------------------

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Add test for x=0.0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3536/files
  - new: https://git.openjdk.java.net/jdk/pull/3536/files/392a5b92..a97cb957

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3536&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3536&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3536.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3536/head:pull/3536

PR: https://git.openjdk.java.net/jdk/pull/3536

From thartmann at openjdk.java.net  Fri Apr 16 08:11:40 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 16 Apr 2021 08:11:40 GMT
Subject: RFR: 8265323: Leftover local variables in PcDesc
In-Reply-To: <G9FMO7Ufi1r0TDmkBZT4Pp55_BEGsEY2E-GFieB8JwQ=.fcdd124e-9e4b-41b7-bce1-2821651f948e@github.com>
References: <G9FMO7Ufi1r0TDmkBZT4Pp55_BEGsEY2E-GFieB8JwQ=.fcdd124e-9e4b-41b7-bce1-2821651f948e@github.com>
Message-ID: <lGsmWjazJJuz60LmuUGopsHQBE3dEGJy4Kgs7_fEACk=.cd02f7ef-a37f-4476-958c-23d0744babb6@github.com>

On Fri, 16 Apr 2021 03:16:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Leftover local variables in PcDesc. Remove it to save electric power.

Marked as reviewed by thartmann (Reviewer).

src/hotspot/share/code/pcDesc.cpp line 46:

> 44: #ifndef PRODUCT
> 45:   ResourceMark rm;
> 46:   st->print_cr("PcDesc(pc=" PTR_FORMAT " offset=%x bits=%x):", p2i(real_pc(code)), pc_offset(), _flags);

This changes the output from

PcDesc(pc=0x00007fe00d12475f offset=ffffffff bits=0):
PcDesc(pc=0x00007fe00d12478c offset=2c bits=0):   Test::test3 at -1 (line 33)
``` 
to

PcDesc(pc=0x00007f4fc9035a5f offset=ffffffff bits=0):
PcDesc(pc=0x00007f4fc9035a8c offset=2c bits=0):
   Test::test3 at -1 (line 33)
``` 
But since that is more inline with the output of `ScopeDesc::print_on`, that's fine with me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3532

From thartmann at openjdk.java.net  Fri Apr 16 08:13:34 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 16 Apr 2021 08:13:34 GMT
Subject: RFR: 8265245: depChecker_<cpu> don't have any functionalities
In-Reply-To: <1JKPxPdQ9XoTDXdIP8P_eBy6EqYZhEoD8SACCs0MfSs=.d5cd2e5f-6c11-4be8-8651-3931368d1471@github.com>
References: <1JKPxPdQ9XoTDXdIP8P_eBy6EqYZhEoD8SACCs0MfSs=.d5cd2e5f-6c11-4be8-8651-3931368d1471@github.com>
Message-ID: <7KW8AJT9EL9Mt0Tebhtooow-7zbDcwEbeoG21HURdG8=.12c7367e-11fc-4a45-b9c1-23f97321799d@github.com>

On Fri, 16 Apr 2021 03:10:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Yet another OpenJDK6 old guy.
> 
> src/hotspot/cpu/<cpu>/depChecker_<cpu>.hpp/cpp are included by src/hotspot/share/compiler/disassembler.cpp, they don't provide any functionality.
> 
> In the absence of strong demand either in existing ARCHs or future ARCHs, I think we can remove it.

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3531

From roland at openjdk.java.net  Fri Apr 16 08:45:06 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 16 Apr 2021 08:45:06 GMT
Subject: RFR: 8264958: C2 compilation fails with assert "n is later than its
 clone"
Message-ID: <3LVvNT_SSyzcC2M7fT-WGZ0nf_0a1QOSgdG3uUjmVaI=.2d00656f-ecd7-4635-a81d-a0a3f8e913b9@github.com>

JDK-8229483 added logic to hoist a load that would wrongly end up in
an outer strip mined loop. That logic checks that it's legal to do so
with:

is_dominator(n_ctrl, x_head)

but that test passes for n_ctrl == x_head when it's not legal to hoist
the load i.e. the test we want is for strict domination. The fix I
propose is to add an explicit check for that case.

-------------

Commit messages:
 - test
 - fix

Changes: https://git.openjdk.java.net/jdk/pull/3539/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3539&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264958
  Stats: 58 lines in 2 files changed: 57 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3539.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3539/head:pull/3539

PR: https://git.openjdk.java.net/jdk/pull/3539

From neliasso at openjdk.java.net  Fri Apr 16 09:18:40 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 16 Apr 2021 09:18:40 GMT
Subject: RFR: 8264958: C2 compilation fails with assert "n is later than
 its clone"
In-Reply-To: <3LVvNT_SSyzcC2M7fT-WGZ0nf_0a1QOSgdG3uUjmVaI=.2d00656f-ecd7-4635-a81d-a0a3f8e913b9@github.com>
References: <3LVvNT_SSyzcC2M7fT-WGZ0nf_0a1QOSgdG3uUjmVaI=.2d00656f-ecd7-4635-a81d-a0a3f8e913b9@github.com>
Message-ID: <10meL3nI3zWykDGjFlH6L7N1hU716jl9SJ3VOSRfASY=.ab2873db-c091-498f-bd05-7103efde5da0@github.com>

On Fri, 16 Apr 2021 08:36:31 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> JDK-8229483 added logic to hoist a load that would wrongly end up in
> an outer strip mined loop. That logic checks that it's legal to do so
> with:
> 
> is_dominator(n_ctrl, x_head)
> 
> but that test passes for n_ctrl == x_head when it's not legal to hoist
> the load i.e. the test we want is for strict domination. The fix I
> propose is to add an explicit check for that case.

Looks good!

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3539

From neliasso at openjdk.java.net  Fri Apr 16 09:21:36 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 16 Apr 2021 09:21:36 GMT
Subject: RFR: 8265245: depChecker_<cpu> don't have any functionalities
In-Reply-To: <1JKPxPdQ9XoTDXdIP8P_eBy6EqYZhEoD8SACCs0MfSs=.d5cd2e5f-6c11-4be8-8651-3931368d1471@github.com>
References: <1JKPxPdQ9XoTDXdIP8P_eBy6EqYZhEoD8SACCs0MfSs=.d5cd2e5f-6c11-4be8-8651-3931368d1471@github.com>
Message-ID: <i3z0xJQe6GzgMvzoGGWH-lXqfIUpA77FRCavszP6564=.16a41ae5-89d1-4963-b734-658f69ce8d9c@github.com>

On Fri, 16 Apr 2021 03:10:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Yet another OpenJDK6 old guy.
> 
> src/hotspot/cpu/<cpu>/depChecker_<cpu>.hpp/cpp are included by src/hotspot/share/compiler/disassembler.cpp, they don't provide any functionality.
> 
> In the absence of strong demand either in existing ARCHs or future ARCHs, I think we can remove it.

Nice cleanup. 

Approved.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3531

From neliasso at openjdk.java.net  Fri Apr 16 09:30:33 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 16 Apr 2021 09:30:33 GMT
Subject: RFR: 8265323: Leftover local variables in PcDesc
In-Reply-To: <G9FMO7Ufi1r0TDmkBZT4Pp55_BEGsEY2E-GFieB8JwQ=.fcdd124e-9e4b-41b7-bce1-2821651f948e@github.com>
References: <G9FMO7Ufi1r0TDmkBZT4Pp55_BEGsEY2E-GFieB8JwQ=.fcdd124e-9e4b-41b7-bce1-2821651f948e@github.com>
Message-ID: <ocoD51YbIlLPncU1Fxp_-ALmC7_J2i8qOEoOvPuYs_g=.ec6e1198-1872-4395-a69a-5bd0efb6791c@github.com>

On Fri, 16 Apr 2021 03:16:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Leftover local variables in PcDesc. Remove it to save electric power.

Approved.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3532

From rcastanedalo at openjdk.java.net  Fri Apr 16 10:03:06 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 16 Apr 2021 10:03:06 GMT
Subject: RFR: 8262462: IGV: cannot remove specific groups imported via network
Message-ID: <4rcLWv7_UPyzmG6NRSLwBQs78yKuQyyveKYg4LzvMWY=.0bb709f7-d313-4bbf-ade3-278fbeb3fc3b@github.com>

This change connects groups to their `GraphDocument` parents when the groups are imported via network, making it possible to remove the imported groups later. Before the change, this connection was made only when groups are imported from a file:

https://github.com/openjdk/jdk/blob/1d66a155c711906fbb5e8e976fd6585ef491ea68/src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/ImportAction.java#L147

Tested manually on JDK 8, 11, and 15 (latest version currently supported by IGV) by following the steps in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262462).

-------------

Commit messages:
 - Set group's parent when a group is added to the graph document

Changes: https://git.openjdk.java.net/jdk/pull/3515/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3515&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262462
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3515.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3515/head:pull/3515

PR: https://git.openjdk.java.net/jdk/pull/3515

From neliasso at openjdk.java.net  Fri Apr 16 10:12:34 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 16 Apr 2021 10:12:34 GMT
Subject: RFR: 8262462: IGV: cannot remove specific groups imported via
 network
In-Reply-To: <4rcLWv7_UPyzmG6NRSLwBQs78yKuQyyveKYg4LzvMWY=.0bb709f7-d313-4bbf-ade3-278fbeb3fc3b@github.com>
References: <4rcLWv7_UPyzmG6NRSLwBQs78yKuQyyveKYg4LzvMWY=.0bb709f7-d313-4bbf-ade3-278fbeb3fc3b@github.com>
Message-ID: <pg_BKiPrM-PtYpM0CKwyPsh7W6bqmr_NiSq3c-lWQZc=.6d193d84-f819-48e3-87d3-ec93ea190248@github.com>

On Thu, 15 Apr 2021 12:39:09 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change connects groups to their `GraphDocument` parents when the groups are imported via network, making it possible to remove the imported groups later. Before the change, this connection was made only when groups are imported from a file:
> 
> https://github.com/openjdk/jdk/blob/1d66a155c711906fbb5e8e976fd6585ef491ea68/src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/ImportAction.java#L147
> 
> Tested manually on JDK 8, 11, and 15 (latest version currently supported by IGV) by following the steps in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262462).

Looks good! 

You can consider this a 'trivial' change.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3515

From rcastanedalo at openjdk.java.net  Fri Apr 16 10:18:44 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 16 Apr 2021 10:18:44 GMT
Subject: RFR: 8262462: IGV: cannot remove specific groups imported via
 network
In-Reply-To: <pg_BKiPrM-PtYpM0CKwyPsh7W6bqmr_NiSq3c-lWQZc=.6d193d84-f819-48e3-87d3-ec93ea190248@github.com>
References: <4rcLWv7_UPyzmG6NRSLwBQs78yKuQyyveKYg4LzvMWY=.0bb709f7-d313-4bbf-ade3-278fbeb3fc3b@github.com>
 <pg_BKiPrM-PtYpM0CKwyPsh7W6bqmr_NiSq3c-lWQZc=.6d193d84-f819-48e3-87d3-ec93ea190248@github.com>
Message-ID: <SVpZqh3tmWFucZS12li38lgp4iADXtqxo4jNCYiCj9Q=.8afed65e-ab13-4a13-96f1-88a9d30f74a7@github.com>

On Fri, 16 Apr 2021 10:09:39 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Looks good!
> 
> You can consider this a 'trivial' change.

Thanks for reviewing, Nils!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3515

From thartmann at openjdk.java.net  Fri Apr 16 10:45:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 16 Apr 2021 10:45:39 GMT
Subject: RFR: 8264958: C2 compilation fails with assert "n is later than
 its clone"
In-Reply-To: <3LVvNT_SSyzcC2M7fT-WGZ0nf_0a1QOSgdG3uUjmVaI=.2d00656f-ecd7-4635-a81d-a0a3f8e913b9@github.com>
References: <3LVvNT_SSyzcC2M7fT-WGZ0nf_0a1QOSgdG3uUjmVaI=.2d00656f-ecd7-4635-a81d-a0a3f8e913b9@github.com>
Message-ID: <l--FFglG3Z8ks0yHeHPtwwHuxFZ0dwkYjZQtEvbxwPE=.b6d7e5e6-eafd-4b4e-845d-b30aa3c73a4d@github.com>

On Fri, 16 Apr 2021 08:36:31 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> JDK-8229483 added logic to hoist a load that would wrongly end up in
> an outer strip mined loop. That logic checks that it's legal to do so
> with:
> 
> is_dominator(n_ctrl, x_head)
> 
> but that test passes for n_ctrl == x_head when it's not legal to hoist
> the load i.e. the test we want is for strict domination. The fix I
> propose is to add an explicit check for that case.

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3539

From thartmann at openjdk.java.net  Fri Apr 16 10:47:36 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 16 Apr 2021 10:47:36 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <b4tiFq5Eq6_3Ll0UfGpYwkjvxhTOTE0go1lZRfA6HzU=.dd378ebb-7740-4f32-8ec8-b5cffd3f3508@github.com>

On Tue, 13 Apr 2021 05:46:15 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

@veresov should have a look at this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3449

From roland at openjdk.java.net  Fri Apr 16 11:37:38 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 16 Apr 2021 11:37:38 GMT
Subject: RFR: 8264958: C2 compilation fails with assert "n is later than
 its clone"
In-Reply-To: <10meL3nI3zWykDGjFlH6L7N1hU716jl9SJ3VOSRfASY=.ab2873db-c091-498f-bd05-7103efde5da0@github.com>
References: <3LVvNT_SSyzcC2M7fT-WGZ0nf_0a1QOSgdG3uUjmVaI=.2d00656f-ecd7-4635-a81d-a0a3f8e913b9@github.com>
 <10meL3nI3zWykDGjFlH6L7N1hU716jl9SJ3VOSRfASY=.ab2873db-c091-498f-bd05-7103efde5da0@github.com>
Message-ID: <iJCyXjPMdp65YpJWVq3qNvvwsL1zWUyoR_aYvfhx-UQ=.882bf0b2-0f73-4451-879d-81db50832040@github.com>

On Fri, 16 Apr 2021 09:15:39 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> JDK-8229483 added logic to hoist a load that would wrongly end up in
>> an outer strip mined loop. That logic checks that it's legal to do so
>> with:
>> 
>> is_dominator(n_ctrl, x_head)
>> 
>> but that test passes for n_ctrl == x_head when it's not legal to hoist
>> the load i.e. the test we want is for strict domination. The fix I
>> propose is to add an explicit check for that case.
>
> Looks good!

@neliasso @TobiHartmann thanks for the reviews

-------------

PR: https://git.openjdk.java.net/jdk/pull/3539

From roland at openjdk.java.net  Fri Apr 16 11:37:41 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 16 Apr 2021 11:37:41 GMT
Subject: Integrated: 8264958: C2 compilation fails with assert "n is later
 than its clone"
In-Reply-To: <3LVvNT_SSyzcC2M7fT-WGZ0nf_0a1QOSgdG3uUjmVaI=.2d00656f-ecd7-4635-a81d-a0a3f8e913b9@github.com>
References: <3LVvNT_SSyzcC2M7fT-WGZ0nf_0a1QOSgdG3uUjmVaI=.2d00656f-ecd7-4635-a81d-a0a3f8e913b9@github.com>
Message-ID: <HRBLdhzhLN40OxGQr-vnLD6M4AP7BSWdbcTSDcjOX60=.0384bb3e-b64d-46aa-a03f-83178ccc9c19@github.com>

On Fri, 16 Apr 2021 08:36:31 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> JDK-8229483 added logic to hoist a load that would wrongly end up in
> an outer strip mined loop. That logic checks that it's legal to do so
> with:
> 
> is_dominator(n_ctrl, x_head)
> 
> but that test passes for n_ctrl == x_head when it's not legal to hoist
> the load i.e. the test we want is for strict domination. The fix I
> propose is to add an explicit check for that case.

This pull request has now been integrated.

Changeset: 71373280
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/71373280
Stats:     58 lines in 2 files changed: 57 ins; 0 del; 1 mod

8264958: C2 compilation fails with assert "n is later than its clone"

Reviewed-by: neliasso, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3539

From rcastanedalo at openjdk.java.net  Fri Apr 16 11:52:36 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 16 Apr 2021 11:52:36 GMT
Subject: Integrated: 8262462: IGV: cannot remove specific groups imported via
 network
In-Reply-To: <4rcLWv7_UPyzmG6NRSLwBQs78yKuQyyveKYg4LzvMWY=.0bb709f7-d313-4bbf-ade3-278fbeb3fc3b@github.com>
References: <4rcLWv7_UPyzmG6NRSLwBQs78yKuQyyveKYg4LzvMWY=.0bb709f7-d313-4bbf-ade3-278fbeb3fc3b@github.com>
Message-ID: <NY7RRdiIrS56xfbKkYMfM9fvaY89JEY8PpElNHfFE-s=.57b7fe0b-8167-4e88-a9f1-d82bffb5d28b@github.com>

On Thu, 15 Apr 2021 12:39:09 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change connects groups to their `GraphDocument` parents when the groups are imported via network, making it possible to remove the imported groups later. Before the change, this connection was made only when groups are imported from a file:
> 
> https://github.com/openjdk/jdk/blob/1d66a155c711906fbb5e8e976fd6585ef491ea68/src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/ImportAction.java#L147
> 
> Tested manually on JDK 8, 11, and 15 (latest version currently supported by IGV) by following the steps in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262462).

This pull request has now been integrated.

Changeset: 10ec38f8
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/10ec38f8
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8262462: IGV: cannot remove specific groups imported via network

Reviewed-by: neliasso

-------------

PR: https://git.openjdk.java.net/jdk/pull/3515

From rcastanedalo at openjdk.java.net  Fri Apr 16 12:04:43 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 16 Apr 2021 12:04:43 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group
Message-ID: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>

This change makes IGV close graph views when their groups are either a) removed or b) emptied (all graphs are removed but the group remains), and avoids faulty graph view computation in case b).

Tested the following scenarios manually (on groups loaded both via network and from a file, and on JDK 8, 11, and 15):
1. open a graph, then remove all graphs in the group (as described in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262725));
2. open a graph, then remove its group; and
3. open a graph, then remove all graphs and groups (File -> Remove all graphs and groups).

-------------

Commit messages:
 - Close graph views when their groups are removed or emptied

Changes: https://git.openjdk.java.net/jdk/pull/3540/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3540&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262725
  Stats: 33 lines in 2 files changed: 31 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3540.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3540/head:pull/3540

PR: https://git.openjdk.java.net/jdk/pull/3540

From iveresov at openjdk.java.net  Fri Apr 16 14:22:37 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 16 Apr 2021 14:22:37 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <jGAHgpWDN88aTryHfE5ARGQKXJHdkMDeeKOQdftYVxg=.c784f635-a036-4c44-a781-c70adf9d5cb0@github.com>

On Tue, 13 Apr 2021 05:46:15 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

So, you want the VM to ignore the ```NeverActAsServerClassMachine``` if it has C2 and not C1?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3449

From enikitin at openjdk.java.net  Fri Apr 16 14:36:38 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 16 Apr 2021 14:36:38 GMT
Subject: Integrated: 8262060: compiler/whitebox/BlockingCompilation.java timed
 out
In-Reply-To: <OiOA1GtUHhEIG2bLIsEskiqzWwS0Fr6HjhKEUbsixFg=.d1edd99a-a57c-47b1-b48a-e2f399c3c487@github.com>
References: <OiOA1GtUHhEIG2bLIsEskiqzWwS0Fr6HjhKEUbsixFg=.d1edd99a-a57c-47b1-b48a-e2f399c3c487@github.com>
Message-ID: <N7XNDdHTsvEKo27V8kiuql75QHJZD8z3evlpED8e0tg=.28d7a95e-178c-4f0c-ac98-96994668b8fa@github.com>

On Fri, 26 Mar 2021 20:22:14 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> Please review this small fix for a test.
> 
> Test fails sometimes when run with UsageTracker enabled. For some reason, a loading of ThreadLocalRandom can happen during the test run, and this invalidates Random.nextInt method (because it's not the only implementation now).
> 
> Fixed by pre-loading ThreadLocalRandom. Tested by multiple runs with UsageTracker enabled - approx. 1 out of 20-30 test runs fails without the fix and no failures spotted with the fix.

This pull request has now been integrated.

Changeset: 694e1cdc
Author:    Evgeny Nikitin <enikitin at openjdk.org>
Committer: Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/694e1cdc
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8262060: compiler/whitebox/BlockingCompilation.java timed out

Reviewed-by: iignatyev

-------------

PR: https://git.openjdk.java.net/jdk/pull/3224

From kvn at openjdk.java.net  Fri Apr 16 17:28:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 16 Apr 2021 17:28:38 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v2]
In-Reply-To: <iS-bmLoqbTFTSO4gEXlQuH3mIeybrxQ1aniwBbm-z4c=.6316efaa-3f77-4f9d-9e63-31325a112e14@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
 <iS-bmLoqbTFTSO4gEXlQuH3mIeybrxQ1aniwBbm-z4c=.6316efaa-3f77-4f9d-9e63-31325a112e14@github.com>
Message-ID: <fEgSBkutD-qI3vL1cS-jDEy70e1iNPeBM-YoHs0WBt8=.a502dadd-bae7-425e-9735-ecb80e46a739@github.com>

On Fri, 16 Apr 2021 07:30:11 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> I'd like to optimize the StubRoutines::dpow() for Math.pow(x, 0.5).
>> 
>> In the pow and sqrt discussion [1], Joe taught me that the Java library implementation of pow has been optimized for pow(x, 2.0) [2] and pow(x, 0.5) [3].
>> However, the hotspot StubRoutines::dpow() only implements the same opt for pow(x, 2.0), but still not for pow(x, 0.5).
>> This patch optimizes StubRoutines::dpow() for pow(x, 0.5).
>> 
>> Although not all Math.pow(x, 0.5) can be replaced with sqrt(x), we can still do it safely for the following cases:
>>   1) x >= 0.0    (fully implemented)
>>   2) x is +Inf   (fully implemented)
>>   3) x is NaN    (can be further divided into +NaN and -NaN and only +NaN is implemented)
>> 
>> The effect of this opt has been tested on serveral platforms showing 3.0x ~ 6.3x performance improvement.
>> And no performance drop was observed.
>> 
>> Testing:
>>   - tier1 ~ tier3 on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076220.html
>> [2] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L362
>> [3] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L364
>> 
>> Detailed performance numbers:
>> * Linux/Intel
>> 
>> --------- Before -----------
>> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
>> MathBench.powDouble                 0  thrpt    8  218783.605 ?   838.379  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8   45498.351 ?     7.558  ops/ms
>> MathBench.powDouble0Dot5Const       0  thrpt    8   45243.530 ?  1097.100  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.031 ?     0.001  ops/ms
>> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  176106.602 ? 13127.650  ops/ms
>> ----------------------------
>> 
>> --------- After -----------
>> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
>> MathBench.powDouble                 0  thrpt    8  219930.462 ?   181.922  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8  204966.834 ?   329.032  ops/ms   <-- 4.5x up
>> MathBench.powDouble0Dot5Const       0  thrpt    8  203004.302 ?   684.072  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.121 ?     0.001  ops/ms   <-- 3.9x up
>> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  178818.861 ? 16235.465  ops/ms
>> ----------------------------
>> 
>> 
>> * Linux/AMD
>> 
>> --------- Before -----------
>> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble                 0  thrpt    8  100741.348 ? 207.766  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8   33896.623 ? 103.352  ops/ms
>> MathBench.powDouble0Dot5Const       0  thrpt    8   34195.944 ? 230.703  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.039 ?   0.001  ops/ms
>> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8   72000.166 ? 135.002  ops/ms
>> ----------------------------
>> 
>> --------- After -----------
>> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble                 0  thrpt    8  100738.866 ? 222.820  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8  100799.098 ?  95.537  ops/ms   <-- 3.0x up
>> MathBench.powDouble0Dot5Const       0  thrpt    8  100765.571 ? 178.436  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.244 ?   0.002  ops/ms   <-- 6.3x up
>> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8   71758.725 ? 339.660  ops/ms
>> ----------------------------
>> 
>> 
>> * MacOS/Intel
>> 
>> --------- Before -----------
>> Benchmark                      (seed)   Mode  Cnt       Score      Error   Units
>> MathBench.powDouble                 0  thrpt    8  238064.722 ? 5181.318  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8   59235.979 ? 2046.519  ops/ms
>> MathBench.powDouble0Dot5Const       0  thrpt    8   59695.014 ? 1079.692  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.040 ?    0.001  ops/ms
>> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?    0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  238391.026 ? 2743.385  ops/ms
>> ----------------------------
>> 
>> --------- After -----------
>> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
>> MathBench.powDouble                 0  thrpt    8  238582.414 ?  3661.261  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8  224102.701 ?  2846.892  ops/ms   <-- 3.8x up
>> MathBench.powDouble0Dot5Const       0  thrpt    8  224542.331 ? 19027.596  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.158 ?     0.002  ops/ms   <-- 4.0x up
>> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?     0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  233689.504 ? 10141.034  ops/ms
>> ----------------------------
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test for x=0.0

Thank you for testing all modes.

Note, when StubRoutines::dpow() is not used (-XX:-UseLibmIntrinsic or -XX:DisableIntrinsic=_pow) we use C code which also have this (and others) optimization already:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L483

src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp line 2:

> 1: /*
> 2: * Copyright (c) 2016, 2021, Intel Corporation.

Please, don't modify copyright line of other company. Add new line for your company.

test/hotspot/jtreg/compiler/intrinsics/math/TestPow0Dot5Opt.java line 41:

> 39:     if (a < 0.0) return;
> 40: 
> 41:     double r1 = Math.sqrt(a);

`r1` should be static value to avoid compiling `sqrt()` method as intrinsic.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3536

From kvn at openjdk.java.net  Fri Apr 16 17:31:37 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 16 Apr 2021 17:31:37 GMT
Subject: RFR: 8265322: C2: Simplify control inputs for
 BarrierSetC2::obj_allocate
In-Reply-To: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
References: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
Message-ID: <bpyb_GcMFrm9Y3bt5_tmQnC0Pjrgr09mDF6pLHR967E=.d8cfa991-5794-487c-aebf-787ab95ae6d1@github.com>

On Fri, 16 Apr 2021 03:06:19 GMT, Yi Yang <yyang at openjdk.org> wrote:

> This PR simplifies control inputs for BarrierSetC2::obj_allocate. In most cases, it doesn't change anything since `toobig_false` is equivalent to `ctrl`. In rare case, `toobig_false` is created for Unsafe.allocateInstance while instance size is not statically known, `ctrl` would become control input of IfNode whose projects are `toobig_false` and `toobig_true`, old eden_end and old_eden_top can simply accept `toobig_false` as their control input rather than `ctrl`.

This should be reviewed by GC group who owns this code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3529

From kvn at openjdk.java.net  Fri Apr 16 17:39:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 16 Apr 2021 17:39:40 GMT
Subject: RFR: 8265322: C2: Simplify control inputs for
 BarrierSetC2::obj_allocate
In-Reply-To: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
References: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
Message-ID: <SPtW3V9OzA3ecZhHI8aFwOB2z0c7leuWZDuK6HpHIgI=.3db80bff-cf4b-4183-844b-2db4a2b93e80@github.com>

On Fri, 16 Apr 2021 03:06:19 GMT, Yi Yang <yyang at openjdk.org> wrote:

> This PR simplifies control inputs for BarrierSetC2::obj_allocate. In most cases, it doesn't change anything since `toobig_false` is equivalent to `ctrl`. In rare case, `toobig_false` is created for Unsafe.allocateInstance while instance size is not statically known, `ctrl` would become control input of IfNode whose projects are `toobig_false` and `toobig_true`, old eden_end and old_eden_top can simply accept `toobig_false` as their control input rather than `ctrl`.

>From compiler code POV the fix is reasonable and correct.

Note, the path when `initial_slow_test != NULL` is not rare. It is frequent for arrays allocation when `length` is not constant.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3529

From iignatyev at openjdk.java.net  Fri Apr 16 18:27:39 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 16 Apr 2021 18:27:39 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
Message-ID: <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>

On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust whitelist

next portion of my comments, stay tuned for more to come :)

-- Igor

PS I must say that by some reason github's 'file changed' tab is unbelievably slow for me in this particular PR, so it's somewhat painful to even just find the place I want to associate my comment with (not to speak about actually using it to browse/read the code)

test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 41:

> 39:  */
> 40: abstract public class AbstractInfo {
> 41:     private static final Random random = new Random();

you shouldn't use Random w/o predefined seed as it might make it harder to reproduce, please consider using `jdk.test.lib.Utils.getRandomInstance` or `jdk.test.lib.RandomFactory.getRandom` here

test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 57:

> 55:      * @return an inverted boolean of the result of the last invocation of this method.
> 56:      */
> 57:     public boolean toggleBoolean() {

I don't think `toggleBoolean` really belongs to `AbstractInfo`, I'd rather move it into a (separate) aux class.

test/lib/jdk/test/lib/hotspot/ir_framework/ArgumentValue.java line 35:

> 33:  */
> 34: class ArgumentValue {
> 35:     private static final Random random = new Random();

the same comment as in `AbstractInfo`, please use the reproducible rng here.

test/lib/jdk/test/lib/hotspot/ir_framework/IREncodingPrinter.java line 213:

> 211: 
> 212:     private boolean checkBooleanFlag(String flag, String value, Boolean actualFlagValue) {
> 213:         boolean actualBooleanFlagValue = actualFlagValue;

as `actualFlagValue` can't be null, you don't need to use box here: 
Suggestion:

    private boolean checkBooleanFlag(String flag, String value, boolean actualBooleanFlagValue) {


the same for `checkLongFlag`, `checkDoubleFlag`

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 47:

> 45: 
> 46:     public IRMatcher(String hotspotPidFileName, String irEncoding, Class<?> testClass) {
> 47:         this.compilations =  new LinkedHashMap<>();

why do we use LinkedHashMap here (as opposed to HashMap)? I haven't found the place where you need to traverse it in the insertion order.

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 88:

> 86:         Map<String, Integer[]> irRulesMap = new HashMap<>();
> 87:         String patternString = "(?<=" + IREncodingPrinter.START + "\\R)[\\s\\S]*(?=" + IREncodingPrinter.END + ")";
> 88:         Pattern pattern = Pattern.compile(patternString);

`patternString` is effectively a constant here, but you will compile it into `j.u.Pattern` on each invocation of `parseIREncoding`, it might be a better idea to introduce a static field that holds a precompiled patter.

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 98:

> 96:             String[] splitComma = line.split(",");
> 97:             if (splitComma.length < 2) {
> 98:                 throw new TestFrameworkException("Invalid IR match rule encoding");

will it make sense to include the line-offender into the exception message here?

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 101:

> 99:             }
> 100:             String testName = splitComma[0];
> 101:             Integer[] irRulesIdx = new Integer[splitComma.length - 1];

you can actually use an array of int here, so there will be less wasted memory and no unboxing later on

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 116:

> 114:     private void parseHotspotPidFile() {
> 115:         Map<Integer, String> compileIdMap = new HashMap<>();
> 116:         try (BufferedReader br = new BufferedReader(new FileReader(new File(System.getProperty("user.dir") + File.separator + hotspotPidFileName)))) {

more idiomatic/modern version would be
Suggestion:

try (BufferedReader br = Files.newBufferedReader(Paths.get(System.getProperty("user.dir"), hotspotPidFileName))) {


I actually not sure if you really need `$user.dir`, won't hotspot_pid file get generated in the current dir?

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 207:

> 205:     private void addTestMethodCompileId(Map<Integer, String> compileIdMap, String line) {
> 206:         Pattern pattern = Pattern.compile("compile_id='(\\d+)'.*" + Pattern.quote(testClass.getCanonicalName()) + " (\\S+)");
> 207:         Matcher matcher = pattern.matcher(line);

similarly to `parseIREncoding`, `pattern` here can be precomputed in `IRMatcher::IRMatcher` and stored into a final instance field.

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 243:

> 241:     private String getMethodName(Map<Integer, String> compileIdMap, String line) {
> 242:         Pattern pattern = Pattern.compile("compile_id='(\\d+)'");
> 243:         Matcher matcher = pattern.matcher(line);

again, precompiled pattern can be saved into a (in this case) static field and reused.

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 639:

> 637:             TestFormat.check(!scenarioIndices.contains(scenarioIndex),
> 638:                              "Cannot define two scenarios with the same index " + scenarioIndex);
> 639:             scenarioIndices.add(scenarioIndex);

you can use `Set::add` to verify that the element isn't in a set:
Suggestion:

            TestFormat.check(scenarioIndices.add(scenarioIndex),
                             "Cannot define two scenarios with the same index " + scenarioIndex);

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 795:

> 793:     private void checkFlagVMExitCode(OutputAnalyzer oa) {
> 794:         String flagVMOutput = oa.getOutput();
> 795:         final int exitCode = oa.getExitValue();

nit: there is no need for this `final`

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 804:

> 802:             System.err.println("--- OUTPUT TestFramework flag VM ---");
> 803:             System.err.println(flagVMOutput);
> 804:             throw new RuntimeException("\nTestFramework flag VM exited with " + exitCode);

what's the reason for `\n` in the begging of this exception message?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 958:

> 956:         throw new TestFrameworkException("Internal Test Framework exception - please file a bug:\n" + failureMessage, e);
> 957:     }
> 958: }

I am not convinced that we really these guys when we already have `TestFormat::check` and `TestRun::check` (I'm actually not 100% convinced that we need check/fail in both TestFormat and TestRun)

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1027:

> 1025:     }
> 1026: 
> 1027:     public static String getRerunHint() {

why is this a method and not just a public final static String?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1043:

> 1041:  * Dedicated socket to send data from the flag and test VM back to the driver VM.
> 1042:  */
> 1043: class TestFrameworkSocket {

could you please move it to a separate .java file?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1043:

> 1041:  * Dedicated socket to send data from the flag and test VM back to the driver VM.
> 1042:  */
> 1043: class TestFrameworkSocket {

I guess it should implement AutoClosable, and then you try-catch-finally in `TestFramework::start` could be replaced by `try-w-resource`. 

btw, I don't the fact that `socket` is a field of `TestFramework` with the lifetime bounded to `start` method.

-------------

Changes requested by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Fri Apr 16 18:27:40 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 16 Apr 2021 18:27:40 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
Message-ID: <CMxIfIfctmyWvlLfmaESDmPj2b0EZpK5_0YZ8eb1_LM=.d9814615-f2be-43ba-8e30-9c86a5b893c6@github.com>

On Fri, 16 Apr 2021 01:48:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust whitelist
>
> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 639:
> 
>> 637:             TestFormat.check(!scenarioIndices.contains(scenarioIndex),
>> 638:                              "Cannot define two scenarios with the same index " + scenarioIndex);
>> 639:             scenarioIndices.add(scenarioIndex);
> 
> you can use `Set::add` to verify that the element isn't in a set:
> Suggestion:
> 
>             TestFormat.check(scenarioIndices.add(scenarioIndex),
>                              "Cannot define two scenarios with the same index " + scenarioIndex);

also, shouldn't this check be done as part of `addScenarios`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From sviswanathan at openjdk.java.net  Fri Apr 16 18:52:39 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 16 Apr 2021 18:52:39 GMT
Subject: RFR: 8265154: vinserti128 operand mix up for KNL platforms
In-Reply-To: <JiqwfyYtwIRHM1A42fQF_f1P8BgqnwYiDFpChuFya8U=.72e7c8d0-9462-4e9a-a0e8-caf107e1fdda@github.com>
References: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
 <JiqwfyYtwIRHM1A42fQF_f1P8BgqnwYiDFpChuFya8U=.72e7c8d0-9462-4e9a-a0e8-caf107e1fdda@github.com>
Message-ID: <V8oLmWVmRll3LGLbP47D4b1FyfhEJqYWJ8tW6HikP2A=.2a9264e0-920a-4fb7-9dd1-62a983d519ac@github.com>

On Wed, 14 Apr 2021 15:23:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> There is a bug in macro assembler in vinserti128 special handling for platforms like KNL that do not support AVX512VL.
>>  
>> The following:
>>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>>        Assembler::vinserti32x4(dst, dst, src, imm8);
>>      }
>>      ...
>>   }
>>  
>> Should have been:
>>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>>        Assembler::vinserti32x4(dst, nds, src, imm8);
>>      }
>>     ...
>>   }
>> 
>> Best Regards,
>> Sandhya
>
> What problems this is causing? Would be nice to have a test to show the issue (if possible).

@vnkozlov  @TobiHartmann Thanks a lot for the review.
I noticed this bug while running the vector api tests on KNL platform.
The specific tests that are failing without this fix are:
 jdk/incubator/vector/Float256VectorTests.java (withFloat256VectorTests)
 jdk/incubator/vector/Double256VectorTests.java (withDouble256VectorTests)

Majority of the places where vinserti128 is used in code gen, the dst and nds are passed as same register. Only in the implementation of VectorInsert node for vector api, the dst and nds are different.

The vector api tests are run as part of tier 3.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3480

From dcubed at openjdk.java.net  Fri Apr 16 19:35:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 19:35:04 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64
Message-ID: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>

A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:

- JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
- JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
- JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
- JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64
- JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
- JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

-------------

Commit messages:
 - 8265370: ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64
 - 8265368: ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
 - 8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64
 - 8265363: ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
 - 8265361: ProblemList a few compiler/whitebox tests on macos-aarch64
 - 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64

Changes: https://git.openjdk.java.net/jdk/pull/3549/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265358
  Stats: 16 lines in 3 files changed: 16 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3549/head:pull/3549

PR: https://git.openjdk.java.net/jdk/pull/3549

From bpb at openjdk.java.net  Fri Apr 16 19:44:33 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 16 Apr 2021 19:44:33 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64
In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
Message-ID: <SsQBbhEMuHyCLH2COOP33e6p8WCRtUZ2aaj5wfbrtEQ=.b88a2bcb-a102-4f64-b062-cc1656c810a4@github.com>

On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
> 
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
> - JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64
> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From mikael at openjdk.java.net  Fri Apr 16 19:49:33 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Fri, 16 Apr 2021 19:49:33 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64
In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
Message-ID: <H7bO5BjUb9UQeO0EejrcQaMLKyGy5-xzHfdhDaj3Q1A=.053183fd-8147-4659-beb3-78f816ddd0d5@github.com>

On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
> 
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
> - JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64
> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From mikael at openjdk.java.net  Fri Apr 16 20:16:06 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Fri, 16 Apr 2021 20:16:06 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64 [v2]
In-Reply-To: <qJvuAkCdpiNuj-O3-sgVhYSf74WRUOkBL18kDKoKuGI=.3a7f93f7-f4bf-47ef-9a69-51bf29ddc25b@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
 <qJvuAkCdpiNuj-O3-sgVhYSf74WRUOkBL18kDKoKuGI=.3a7f93f7-f4bf-47ef-9a69-51bf29ddc25b@github.com>
Message-ID: <SI2K-ILzSbVIEWY6g0doYk6Yd9PMD4zhkuj1Ej_BS3Y=.acd3e049-0a6b-4622-93f0-5d17614137ec@github.com>

On Fri, 16 Apr 2021 20:12:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
>> 
>> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
>> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
>> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
>> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
>> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes for JDK-8265366 at @fguallini's request.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From dcubed at openjdk.java.net  Fri Apr 16 20:16:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 20:16:06 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64 [v2]
In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
Message-ID: <qJvuAkCdpiNuj-O3-sgVhYSf74WRUOkBL18kDKoKuGI=.3a7f93f7-f4bf-47ef-9a69-51bf29ddc25b@github.com>

> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
> 
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Remove changes for JDK-8265366 at @fguallini's request.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3549/files
  - new: https://git.openjdk.java.net/jdk/pull/3549/files/5fb3de6a..7f245f4e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3549/head:pull/3549

PR: https://git.openjdk.java.net/jdk/pull/3549

From dcubed at openjdk.java.net  Fri Apr 16 20:16:07 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 20:16:07 GMT
Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64 [v2]
In-Reply-To: <SsQBbhEMuHyCLH2COOP33e6p8WCRtUZ2aaj5wfbrtEQ=.b88a2bcb-a102-4f64-b062-cc1656c810a4@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
 <SsQBbhEMuHyCLH2COOP33e6p8WCRtUZ2aaj5wfbrtEQ=.b88a2bcb-a102-4f64-b062-cc1656c810a4@github.com>
Message-ID: <Jr2m61yqaIunXX84ywc8hAfRZBCRoJP4sNMl6mbQGvM=.079ecccf-ab4f-4339-93c1-66acbd5da0eb@github.com>

On Fri, 16 Apr 2021 19:42:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove changes for JDK-8265366 at @fguallini's request.
>
> Marked as reviewed by bpb (Reviewer).

@bplb and @vidmik - Thanks for the reviews.

I'm removing the changes for JDK-8265366 at @fguallini's request.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From dcubed at openjdk.java.net  Fri Apr 16 20:24:37 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 20:24:37 GMT
Subject: Integrated: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on
 macOS-aarch64
In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com>
Message-ID: <g6aTlQn0_t1Dy3W7dBUZssOqtFiZNu1Z0TRbrjilKZ8=.1b28a8d3-d8c6-4ff9-bf15-85c260141ffd@github.com>

On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
> 
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

This pull request has now been integrated.

Changeset: 888d80b5
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/888d80b5
Stats:     13 lines in 3 files changed: 13 ins; 0 del; 0 mod

8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
8265361: ProblemList a few compiler/whitebox tests on macos-aarch64
8265363: ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
8265368: ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64
8265370: ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64

Reviewed-by: bpb, mikael

-------------

PR: https://git.openjdk.java.net/jdk/pull/3549

From bpb at openjdk.java.net  Fri Apr 16 21:09:57 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 16 Apr 2021 21:09:57 GMT
Subject: RFR: 8265381: ProblemList runtime/logging/RedefineClasses.java on
 macos-x64 -Xcomp
In-Reply-To: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com>
References: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com>
Message-ID: <vDMc6rsfVXZ4OBgu1cJ5iCfZTthjB725fELqQbTi4yY=.a8d25b08-9070-4cb1-8f93-f9167d04e7f1@github.com>

On Fri, 16 Apr 2021 21:01:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial change to ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3552

From dcubed at openjdk.java.net  Fri Apr 16 21:09:57 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 21:09:57 GMT
Subject: RFR: 8265381: ProblemList runtime/logging/RedefineClasses.java on
 macos-x64 -Xcomp
Message-ID: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com>

A trivial change to ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp.

-------------

Commit messages:
 - 8265381: ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp

Changes: https://git.openjdk.java.net/jdk/pull/3552/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3552&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265381
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3552.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3552/head:pull/3552

PR: https://git.openjdk.java.net/jdk/pull/3552

From kvn at openjdk.java.net  Fri Apr 16 21:16:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 16 Apr 2021 21:16:38 GMT
Subject: RFR: 8265154: vinserti128 operand mix up for KNL platforms
In-Reply-To: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
References: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
Message-ID: <XHYWT8YoTmcaXjlmub2As8L3agAYCWqoLHjjCgO4gjc=.ec2a53d3-2d67-4b6e-a6cd-83cbdd655585@github.com>

On Wed, 14 Apr 2021 00:25:40 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> There is a bug in macro assembler in vinserti128 special handling for platforms like KNL that do not support AVX512VL.
>  
> The following:
>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>        Assembler::vinserti32x4(dst, dst, src, imm8);
>      }
>      ...
>   }
>  
> Should have been:
>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>        Assembler::vinserti32x4(dst, nds, src, imm8);
>      }
>     ...
>   }
> 
> Best Regards,
> Sandhya

Good.

So it was caught by existing tests.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3480

From dcubed at openjdk.java.net  Fri Apr 16 21:24:36 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 21:24:36 GMT
Subject: RFR: 8265381: ProblemList runtime/logging/RedefineClasses.java on
 macos-x64 -Xcomp
In-Reply-To: <vDMc6rsfVXZ4OBgu1cJ5iCfZTthjB725fELqQbTi4yY=.a8d25b08-9070-4cb1-8f93-f9167d04e7f1@github.com>
References: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com>
 <vDMc6rsfVXZ4OBgu1cJ5iCfZTthjB725fELqQbTi4yY=.a8d25b08-9070-4cb1-8f93-f9167d04e7f1@github.com>
Message-ID: <ONzaSYy26l1KXiqamHooOZLLQKAhhQWDf3L6POmTFrM=.fde76697-e0dd-4309-b3ce-174d116a69d3@github.com>

On Fri, 16 Apr 2021 21:05:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial change to ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3552

From dcubed at openjdk.java.net  Fri Apr 16 21:24:37 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 16 Apr 2021 21:24:37 GMT
Subject: Integrated: 8265381: ProblemList runtime/logging/RedefineClasses.java
 on macos-x64 -Xcomp
In-Reply-To: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com>
References: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com>
Message-ID: <HwAbNonbSqaDm-89alJC-KT8DxdmukVLb-7gEOhok9w=.7dbe9025-3e40-479b-843a-70c6dbb56cba@github.com>

On Fri, 16 Apr 2021 21:01:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial change to ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp.

This pull request has now been integrated.

Changeset: 2c4075cb
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c4075cb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8265381: ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3552

From sviswanathan at openjdk.java.net  Fri Apr 16 21:32:33 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 16 Apr 2021 21:32:33 GMT
Subject: Integrated: 8265154: vinserti128 operand mix up for KNL platforms
In-Reply-To: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
References: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
Message-ID: <1-V080sqMJz9jo3Vnm23HdPTSXQ9tjoh3JfDsoWKFHQ=.fab57e93-0a6d-4cf8-bbba-e83b5ad1abfe@github.com>

On Wed, 14 Apr 2021 00:25:40 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> There is a bug in macro assembler in vinserti128 special handling for platforms like KNL that do not support AVX512VL.
>  
> The following:
>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>        Assembler::vinserti32x4(dst, dst, src, imm8);
>      }
>      ...
>   }
>  
> Should have been:
>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>        Assembler::vinserti32x4(dst, nds, src, imm8);
>      }
>     ...
>   }
> 
> Best Regards,
> Sandhya

This pull request has now been integrated.

Changeset: c108e7ab
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c108e7ab
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8265154: vinserti128 operand mix up for KNL platforms

Reviewed-by: thartmann, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3480

From sviswanathan at openjdk.java.net  Fri Apr 16 21:32:32 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 16 Apr 2021 21:32:32 GMT
Subject: RFR: 8265154: vinserti128 operand mix up for KNL platforms
In-Reply-To: <XHYWT8YoTmcaXjlmub2As8L3agAYCWqoLHjjCgO4gjc=.ec2a53d3-2d67-4b6e-a6cd-83cbdd655585@github.com>
References: <rDWJYv9SB16X3G0KR6bxLAFNddrlurz4v9gk539KYoE=.20a1d92d-5697-4898-ae3a-cf256d1bddd5@github.com>
 <XHYWT8YoTmcaXjlmub2As8L3agAYCWqoLHjjCgO4gjc=.ec2a53d3-2d67-4b6e-a6cd-83cbdd655585@github.com>
Message-ID: <qgOJqmLUW3y2Nw_3HRabU_2qcVVmcmMRl2yltv2Jpyk=.d2ce2f00-6fb5-467b-b4ab-7e379967b0c6@github.com>

On Fri, 16 Apr 2021 21:13:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> There is a bug in macro assembler in vinserti128 special handling for platforms like KNL that do not support AVX512VL.
>>  
>> The following:
>>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>>        Assembler::vinserti32x4(dst, dst, src, imm8);
>>      }
>>      ...
>>   }
>>  
>> Should have been:
>>    void vinserti128(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>>      if (UseAVX > 2 && VM_Version::supports_avx512novl()) {
>>        Assembler::vinserti32x4(dst, nds, src, imm8);
>>      }
>>     ...
>>   }
>> 
>> Best Regards,
>> Sandhya
>
> Good.
> 
> So it was caught by existing tests.

Thanks @vnkozlov. Yes, it was caught by existing tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3480

From jiefu at openjdk.java.net  Fri Apr 16 23:04:56 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 16 Apr 2021 23:04:56 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v3]
In-Reply-To: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
Message-ID: <hlojtppIuHcjNgNCnWUHxlwsaXx3n_1cjJXhPb2WV4w=.e22af6f2-2de7-4090-87eb-4d5a91abd325@github.com>

> Hi all,
> 
> I'd like to optimize the StubRoutines::dpow() for Math.pow(x, 0.5).
> 
> In the pow and sqrt discussion [1], Joe taught me that the Java library implementation of pow has been optimized for pow(x, 2.0) [2] and pow(x, 0.5) [3].
> However, the hotspot StubRoutines::dpow() only implements the same opt for pow(x, 2.0), but still not for pow(x, 0.5).
> This patch optimizes StubRoutines::dpow() for pow(x, 0.5).
> 
> Although not all Math.pow(x, 0.5) can be replaced with sqrt(x), we can still do it safely for the following cases:
>   1) x >= 0.0    (fully implemented)
>   2) x is +Inf   (fully implemented)
>   3) x is NaN    (can be further divided into +NaN and -NaN and only +NaN is implemented)
> 
> The effect of this opt has been tested on serveral platforms showing 3.0x ~ 6.3x performance improvement.
> And no performance drop was observed.
> 
> Testing:
>   - tier1 ~ tier3 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076220.html
> [2] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L362
> [3] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L364
> 
> Detailed performance numbers:
> * Linux/Intel
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  218783.605 ?   838.379  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   45498.351 ?     7.558  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   45243.530 ?  1097.100  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.031 ?     0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  176106.602 ? 13127.650  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  219930.462 ?   181.922  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  204966.834 ?   329.032  ops/ms   <-- 4.5x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  203004.302 ?   684.072  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.121 ?     0.001  ops/ms   <-- 3.9x up
> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  178818.861 ? 16235.465  ops/ms
> ----------------------------
> 
> 
> * Linux/AMD
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble                 0  thrpt    8  100741.348 ? 207.766  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   33896.623 ? 103.352  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   34195.944 ? 230.703  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.039 ?   0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8   72000.166 ? 135.002  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble                 0  thrpt    8  100738.866 ? 222.820  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  100799.098 ?  95.537  ops/ms   <-- 3.0x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  100765.571 ? 178.436  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.244 ?   0.002  ops/ms   <-- 6.3x up
> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8   71758.725 ? 339.660  ops/ms
> ----------------------------
> 
> 
> * MacOS/Intel
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score      Error   Units
> MathBench.powDouble                 0  thrpt    8  238064.722 ? 5181.318  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   59235.979 ? 2046.519  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   59695.014 ? 1079.692  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.040 ?    0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?    0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  238391.026 ? 2743.385  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  238582.414 ?  3661.261  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  224102.701 ?  2846.892  ops/ms   <-- 3.8x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  224542.331 ? 19027.596  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.158 ?     0.002  ops/ms   <-- 4.0x up
> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  233689.504 ? 10141.034  ops/ms
> ----------------------------

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Fix tests

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3536/files
  - new: https://git.openjdk.java.net/jdk/pull/3536/files/a97cb957..dc194975

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3536&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3536&range=01-02

  Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3536.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3536/head:pull/3536

PR: https://git.openjdk.java.net/jdk/pull/3536

From jiefu at openjdk.java.net  Fri Apr 16 23:10:36 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 16 Apr 2021 23:10:36 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v2]
In-Reply-To: <fEgSBkutD-qI3vL1cS-jDEy70e1iNPeBM-YoHs0WBt8=.a502dadd-bae7-425e-9735-ecb80e46a739@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
 <iS-bmLoqbTFTSO4gEXlQuH3mIeybrxQ1aniwBbm-z4c=.6316efaa-3f77-4f9d-9e63-31325a112e14@github.com>
 <fEgSBkutD-qI3vL1cS-jDEy70e1iNPeBM-YoHs0WBt8=.a502dadd-bae7-425e-9735-ecb80e46a739@github.com>
Message-ID: <BEZt6LYKGe_wE-hO2X-QnArm6n4V7I5l_ngE2CrEVpE=.d578909b-d5e6-4faa-9598-0af3334a7ecb@github.com>

On Fri, 16 Apr 2021 17:22:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `r1` should be static value to avoid compiling `sqrt()` method as intrinsic.

Hi @vnkozlov ,

Thanks for your review.

Patch has been updated based on your comments.

To be honest, I didn't get why r1 should be static value.
I think both static and non-static should be OK for the test.

So what would happen is sqrt() is intrinsified?
Could you please make it more clearer?

Thanks.
Best regards,
Jie

-------------

PR: https://git.openjdk.java.net/jdk/pull/3536

From kvn at openjdk.java.net  Fri Apr 16 23:41:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 16 Apr 2021 23:41:36 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v2]
In-Reply-To: <BEZt6LYKGe_wE-hO2X-QnArm6n4V7I5l_ngE2CrEVpE=.d578909b-d5e6-4faa-9598-0af3334a7ecb@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
 <iS-bmLoqbTFTSO4gEXlQuH3mIeybrxQ1aniwBbm-z4c=.6316efaa-3f77-4f9d-9e63-31325a112e14@github.com>
 <fEgSBkutD-qI3vL1cS-jDEy70e1iNPeBM-YoHs0WBt8=.a502dadd-bae7-425e-9735-ecb80e46a739@github.com>
 <BEZt6LYKGe_wE-hO2X-QnArm6n4V7I5l_ngE2CrEVpE=.d578909b-d5e6-4faa-9598-0af3334a7ecb@github.com>
Message-ID: <ID4D5fUTg50yOC02Si5HjRhBbJY33UFei0FEOH6Wadc=.dc5a395c-bd41-43b8-93e1-d18c42ca8a45@github.com>

On Fri, 16 Apr 2021 23:07:20 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/intrinsics/math/TestPow0Dot5Opt.java line 41:
>> 
>>> 39:     if (a < 0.0) return;
>>> 40: 
>>> 41:     double r1 = Math.sqrt(a);
>> 
>> `r1` should be static value to avoid compiling `sqrt()` method as intrinsic.
>
>> `r1` should be static value to avoid compiling `sqrt()` method as intrinsic.
> 
> Hi @vnkozlov ,
> 
> Thanks for your review.
> 
> Patch has been updated based on your comments.
> 
> To be honest, I didn't get why r1 should be static value.
> I think both static and non-static should be OK for the test.
> 
> So what would happen is sqrt() is intrinsified?
> Could you please make it more clearer?
> 
> Thanks.
> Best regards,
> Jie

Sorry, my bad. I thought to calculate `sqrt(a)` outside `test` method so that only `pow()` code is tested.
Like calculating `gold` value not in compiled code. 
But the test have to use sqrt() for each value `a` and `sqrt` is 1 HW instruction so my suggestion was stupid.
Please, revert this change. Original test code was fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3536

From jiefu at openjdk.java.net  Fri Apr 16 23:51:06 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 16 Apr 2021 23:51:06 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v4]
In-Reply-To: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
Message-ID: <6Nww_kOuxx9sjowFZjd0t1rYAOIkSaDDrGb1vkMc2iY=.0c81042a-a3b8-49b4-b718-112d1e7348f4@github.com>

> Hi all,
> 
> I'd like to optimize the StubRoutines::dpow() for Math.pow(x, 0.5).
> 
> In the pow and sqrt discussion [1], Joe taught me that the Java library implementation of pow has been optimized for pow(x, 2.0) [2] and pow(x, 0.5) [3].
> However, the hotspot StubRoutines::dpow() only implements the same opt for pow(x, 2.0), but still not for pow(x, 0.5).
> This patch optimizes StubRoutines::dpow() for pow(x, 0.5).
> 
> Although not all Math.pow(x, 0.5) can be replaced with sqrt(x), we can still do it safely for the following cases:
>   1) x >= 0.0    (fully implemented)
>   2) x is +Inf   (fully implemented)
>   3) x is NaN    (can be further divided into +NaN and -NaN and only +NaN is implemented)
> 
> The effect of this opt has been tested on serveral platforms showing 3.0x ~ 6.3x performance improvement.
> And no performance drop was observed.
> 
> Testing:
>   - tier1 ~ tier3 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076220.html
> [2] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L362
> [3] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L364
> 
> Detailed performance numbers:
> * Linux/Intel
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  218783.605 ?   838.379  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   45498.351 ?     7.558  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   45243.530 ?  1097.100  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.031 ?     0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  176106.602 ? 13127.650  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  219930.462 ?   181.922  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  204966.834 ?   329.032  ops/ms   <-- 4.5x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  203004.302 ?   684.072  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.121 ?     0.001  ops/ms   <-- 3.9x up
> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  178818.861 ? 16235.465  ops/ms
> ----------------------------
> 
> 
> * Linux/AMD
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble                 0  thrpt    8  100741.348 ? 207.766  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   33896.623 ? 103.352  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   34195.944 ? 230.703  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.039 ?   0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8   72000.166 ? 135.002  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble                 0  thrpt    8  100738.866 ? 222.820  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  100799.098 ?  95.537  ops/ms   <-- 3.0x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  100765.571 ? 178.436  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.244 ?   0.002  ops/ms   <-- 6.3x up
> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8   71758.725 ? 339.660  ops/ms
> ----------------------------
> 
> 
> * MacOS/Intel
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score      Error   Units
> MathBench.powDouble                 0  thrpt    8  238064.722 ? 5181.318  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   59235.979 ? 2046.519  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   59695.014 ? 1079.692  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.040 ?    0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?    0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  238391.026 ? 2743.385  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  238582.414 ?  3661.261  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  224102.701 ?  2846.892  ops/ms   <-- 3.8x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  224542.331 ? 19027.596  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.158 ?     0.002  ops/ms   <-- 4.0x up
> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  233689.504 ? 10141.034  ops/ms
> ----------------------------

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Revert TestPow0Dot5Opt.java change

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3536/files
  - new: https://git.openjdk.java.net/jdk/pull/3536/files/dc194975..e745e4ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3536&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3536&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3536.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3536/head:pull/3536

PR: https://git.openjdk.java.net/jdk/pull/3536

From jiefu at openjdk.java.net  Fri Apr 16 23:51:06 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 16 Apr 2021 23:51:06 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v2]
In-Reply-To: <ID4D5fUTg50yOC02Si5HjRhBbJY33UFei0FEOH6Wadc=.dc5a395c-bd41-43b8-93e1-d18c42ca8a45@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
 <iS-bmLoqbTFTSO4gEXlQuH3mIeybrxQ1aniwBbm-z4c=.6316efaa-3f77-4f9d-9e63-31325a112e14@github.com>
 <fEgSBkutD-qI3vL1cS-jDEy70e1iNPeBM-YoHs0WBt8=.a502dadd-bae7-425e-9735-ecb80e46a739@github.com>
 <BEZt6LYKGe_wE-hO2X-QnArm6n4V7I5l_ngE2CrEVpE=.d578909b-d5e6-4faa-9598-0af3334a7ecb@github.com>
 <ID4D5fUTg50yOC02Si5HjRhBbJY33UFei0FEOH6Wadc=.dc5a395c-bd41-43b8-93e1-d18c42ca8a45@github.com>
Message-ID: <HjzF6PnYY0Qi3qirELsUF2AbcCy6Sx9v9s6Cssy6sPo=.5feb5236-8d11-47ef-9829-3232bd91343b@github.com>

On Fri, 16 Apr 2021 23:38:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Sorry, my bad. I thought to calculate `sqrt(a)` outside `test` method so that only `pow()` code is tested.
> Like calculating `gold` value not in compiled code.
> But the test have to use sqrt() for each value `a` and `sqrt` is 1 HW instruction so my suggestion was stupid.
> Please, revert this change. Original test code was fine.

Thanks for your clarification.
I got your point.

Updated.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3536

From whuang at openjdk.java.net  Sat Apr 17 01:51:36 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 17 Apr 2021 01:51:36 GMT
Subject: RFR: 8265244: assert(false) failed: bad AD file [v2]
In-Reply-To: <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
Message-ID: <Aa7W92CYXXWLjttBGTcHvu3htnAgu3m-CAoUCBhbCNs=.0ba92a85-45ec-452d-94cc-bbd9ba6c11b8@github.com>

On Fri, 16 Apr 2021 02:10:10 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * aarch64 can only accept `VectorReinterpret` with 64/128 bits.
>> * I will fix this bug by adding a rule for `VectorReinterpret` in `match_rule_supported_vector`
>> * after changing note with @nsjian and @XiaohongGong , I think that two checks in `inline_vector_conver` is useless now. However, these checks impact other cpus, so I need more reviewers.
>
> Wang Huang 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 JDK-8265244
>  - 8265244: assert(false) failed: bad AD file

@iwanowww Can you do me a favor to review this patch? Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3507

From kvn at openjdk.java.net  Sat Apr 17 01:52:35 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 17 Apr 2021 01:52:35 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v4]
In-Reply-To: <6Nww_kOuxx9sjowFZjd0t1rYAOIkSaDDrGb1vkMc2iY=.0c81042a-a3b8-49b4-b718-112d1e7348f4@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
 <6Nww_kOuxx9sjowFZjd0t1rYAOIkSaDDrGb1vkMc2iY=.0c81042a-a3b8-49b4-b718-112d1e7348f4@github.com>
Message-ID: <xoDP3SDEVlns0qus1CjPwULmFVmbnnmSqU4mD6aSj3o=.ba156071-21ac-48ab-946e-05e948d33090@github.com>

On Fri, 16 Apr 2021 23:51:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> I'd like to optimize the StubRoutines::dpow() for Math.pow(x, 0.5).
>> 
>> In the pow and sqrt discussion [1], Joe taught me that the Java library implementation of pow has been optimized for pow(x, 2.0) [2] and pow(x, 0.5) [3].
>> However, the hotspot StubRoutines::dpow() only implements the same opt for pow(x, 2.0), but still not for pow(x, 0.5).
>> This patch optimizes StubRoutines::dpow() for pow(x, 0.5).
>> 
>> Although not all Math.pow(x, 0.5) can be replaced with sqrt(x), we can still do it safely for the following cases:
>>   1) x >= 0.0    (fully implemented)
>>   2) x is +Inf   (fully implemented)
>>   3) x is NaN    (can be further divided into +NaN and -NaN and only +NaN is implemented)
>> 
>> The effect of this opt has been tested on serveral platforms showing 3.0x ~ 6.3x performance improvement.
>> And no performance drop was observed.
>> 
>> Testing:
>>   - tier1 ~ tier3 on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076220.html
>> [2] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L362
>> [3] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L364
>> 
>> Detailed performance numbers:
>> * Linux/Intel
>> 
>> --------- Before -----------
>> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
>> MathBench.powDouble                 0  thrpt    8  218783.605 ?   838.379  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8   45498.351 ?     7.558  ops/ms
>> MathBench.powDouble0Dot5Const       0  thrpt    8   45243.530 ?  1097.100  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.031 ?     0.001  ops/ms
>> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  176106.602 ? 13127.650  ops/ms
>> ----------------------------
>> 
>> --------- After -----------
>> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
>> MathBench.powDouble                 0  thrpt    8  219930.462 ?   181.922  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8  204966.834 ?   329.032  ops/ms   <-- 4.5x up
>> MathBench.powDouble0Dot5Const       0  thrpt    8  203004.302 ?   684.072  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.121 ?     0.001  ops/ms   <-- 3.9x up
>> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  178818.861 ? 16235.465  ops/ms
>> ----------------------------
>> 
>> 
>> * Linux/AMD
>> 
>> --------- Before -----------
>> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble                 0  thrpt    8  100741.348 ? 207.766  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8   33896.623 ? 103.352  ops/ms
>> MathBench.powDouble0Dot5Const       0  thrpt    8   34195.944 ? 230.703  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.039 ?   0.001  ops/ms
>> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8   72000.166 ? 135.002  ops/ms
>> ----------------------------
>> 
>> --------- After -----------
>> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble                 0  thrpt    8  100738.866 ? 222.820  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8  100799.098 ?  95.537  ops/ms   <-- 3.0x up
>> MathBench.powDouble0Dot5Const       0  thrpt    8  100765.571 ? 178.436  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.244 ?   0.002  ops/ms   <-- 6.3x up
>> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8   71758.725 ? 339.660  ops/ms
>> ----------------------------
>> 
>> 
>> * MacOS/Intel
>> 
>> --------- Before -----------
>> Benchmark                      (seed)   Mode  Cnt       Score      Error   Units
>> MathBench.powDouble                 0  thrpt    8  238064.722 ? 5181.318  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8   59235.979 ? 2046.519  ops/ms
>> MathBench.powDouble0Dot5Const       0  thrpt    8   59695.014 ? 1079.692  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.040 ?    0.001  ops/ms
>> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?    0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  238391.026 ? 2743.385  ops/ms
>> ----------------------------
>> 
>> --------- After -----------
>> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
>> MathBench.powDouble                 0  thrpt    8  238582.414 ?  3661.261  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8  224102.701 ?  2846.892  ops/ms   <-- 3.8x up
>> MathBench.powDouble0Dot5Const       0  thrpt    8  224542.331 ? 19027.596  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.158 ?     0.002  ops/ms   <-- 4.0x up
>> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?     0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  233689.504 ? 10141.034  ops/ms
>> ----------------------------
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert TestPow0Dot5Opt.java change

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3536

From whuang at openjdk.java.net  Sat Apr 17 03:39:36 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 17 Apr 2021 03:39:36 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
Message-ID: <bKxe5v8u2l2wU8nwv6XUzFPE79kGHN_T1C33u9r7DeQ=.3271d02f-95ed-47a5-ba88-0c40cf55b139@github.com>

On Fri, 16 Apr 2021 01:40:01 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * I optimize `max` and `min` by using these identities 
>>     - op (max(a,b) , min(a,b))=== op(a,b)
>>     - if op is commutable
>>     - example : 
>>       - max(a,b) + min(a,b))=== a + b // op = add
>>       - max(a,b) * min(a,b))=== a * b  // op = mul
>>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
>> * Test case 
>>   ```java
>>   /*
>>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>    *
>>    * This code is free software; you can redistribute it and/or modify it
>>    * under the terms of the GNU General Public License version 2 only, as
>>    * published by the Free Software Foundation.
>>    *
>>    * This code is distributed in the hope that it will be useful, but WITHOUT
>>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>    * version 2 for more details (a copy is included in the LICENSE file that
>>    * accompanied this code).
>>    *
>>    * You should have received a copy of the GNU General Public License version
>>    * 2 along with this work; if not, write to the Free Software Foundation,
>>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>    *
>>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>    * or visit www.oracle.com if you need additional information or have any
>>    * questions.
>>    */
>>   package org.sample;
>>   
>>   import org.openjdk.jmh.annotations.Benchmark;
>>   import org.openjdk.jmh.annotations.*;
>>   
>>   import java.util.Random;
>>   import java.util.concurrent.TimeUnit;
>>   import org.openjdk.jmh.infra.Blackhole;
>>   
>>   @BenchmarkMode({Mode.AverageTime})
>>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>>   public class MyBenchmark {
>>   
>>       static int length = 100000;
>>       static double[] data1 = new double[length];
>>       static double[] data2 = new double[length];
>>       static Random random = new Random();
>>   
>>       static {
>>           for(int i = 0; i < length; ++i) {
>>             data1[i] = random.nextDouble();
>>             data2[i] = random.nextDouble();
>>           }
>>       }
>>   
>>       @Benchmark
>>       public void testAdd(Blackhole bh) {
>>         double sum = 0;
>>         for (int i = 0; i < length; i++) {
>>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>>         }
>>         bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMax(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMin(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMul(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   }
>>   ```
>> 
>> *  The result is listed here (aarch64):
>> 
>>   before:
>> 
>>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>>  
>>   after:
>> 
>>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |
>> 
>> *  I have tested `NaN`  ` INFINITY` and `-INFINITY` and got same result (before/after)
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust code style

@vnkozlov Can you do me a favor to review this optimization? Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From github.com+40024232+sunny868 at openjdk.java.net  Sat Apr 17 05:49:36 2021
From: github.com+40024232+sunny868 at openjdk.java.net (SUN Guoyun)
Date: Sat, 17 Apr 2021 05:49:36 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <-Av02XcjAMlPB7vBxjMrVi9RQnUJtMj5As1wY7bkeEI=.038fd344-04b8-4140-b216-b020979cee74@github.com>

On Tue, 13 Apr 2021 05:46:15 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

Maybe yes. And I am not clear between TieredCompilation NeverActAsServerClassMachine and AlwaysActAsServerClassMachine much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3449

From kvn at openjdk.java.net  Sat Apr 17 05:58:35 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 17 Apr 2021 05:58:35 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
Message-ID: <cQyYCHTzEttQDnXolHHBRpozgAuRDoyvWeA49eK6MaY=.a38921b5-4fef-4e16-9182-8764895b65d4@github.com>

On Fri, 16 Apr 2021 01:40:01 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * I optimize `max` and `min` by using these identities 
>>     - op (max(a,b) , min(a,b))=== op(a,b)
>>     - if op is commutable
>>     - example : 
>>       - max(a,b) + min(a,b))=== a + b // op = add
>>       - max(a,b) * min(a,b))=== a * b  // op = mul
>>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
>> * Test case 
>>   ```java
>>   /*
>>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>    *
>>    * This code is free software; you can redistribute it and/or modify it
>>    * under the terms of the GNU General Public License version 2 only, as
>>    * published by the Free Software Foundation.
>>    *
>>    * This code is distributed in the hope that it will be useful, but WITHOUT
>>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>    * version 2 for more details (a copy is included in the LICENSE file that
>>    * accompanied this code).
>>    *
>>    * You should have received a copy of the GNU General Public License version
>>    * 2 along with this work; if not, write to the Free Software Foundation,
>>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>    *
>>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>    * or visit www.oracle.com if you need additional information or have any
>>    * questions.
>>    */
>>   package org.sample;
>>   
>>   import org.openjdk.jmh.annotations.Benchmark;
>>   import org.openjdk.jmh.annotations.*;
>>   
>>   import java.util.Random;
>>   import java.util.concurrent.TimeUnit;
>>   import org.openjdk.jmh.infra.Blackhole;
>>   
>>   @BenchmarkMode({Mode.AverageTime})
>>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>>   public class MyBenchmark {
>>   
>>       static int length = 100000;
>>       static double[] data1 = new double[length];
>>       static double[] data2 = new double[length];
>>       static Random random = new Random();
>>   
>>       static {
>>           for(int i = 0; i < length; ++i) {
>>             data1[i] = random.nextDouble();
>>             data2[i] = random.nextDouble();
>>           }
>>       }
>>   
>>       @Benchmark
>>       public void testAdd(Blackhole bh) {
>>         double sum = 0;
>>         for (int i = 0; i < length; i++) {
>>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>>         }
>>         bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMax(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMin(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMul(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   }
>>   ```
>> 
>> *  The result is listed here (aarch64):
>> 
>>   before:
>> 
>>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>>  
>>   after:
>> 
>>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |
>> 
>> *  I have tested `NaN`  ` INFINITY` and `-INFINITY` and got same result (before/after)
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust code style

Do you have a real example in Java applications which benefit from this optimization?
We should not add and **support** code which would never be used in real world.

Optimization will not work for Integer because of `_min` and `_max` intrinsic which generates `cmove`:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1806

I am not sure if this optimization will always work for float/double because of NaN values.

You need to verify results for all edge cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From whuang at openjdk.java.net  Sat Apr 17 06:42:40 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 17 Apr 2021 06:42:40 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
Message-ID: <rCyid6IqxwaXQt46bTXcJpw-5urwDqE1EALAYUiwJtk=.a800b3ba-9b44-4fcc-8069-2339ebea104d@github.com>

On Fri, 16 Apr 2021 01:40:01 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * I optimize `max` and `min` by using these identities 
>>     - op (max(a,b) , min(a,b))=== op(a,b)
>>     - if op is commutable
>>     - example : 
>>       - max(a,b) + min(a,b))=== a + b // op = add
>>       - max(a,b) * min(a,b))=== a * b  // op = mul
>>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
>> * Test case 
>>   ```java
>>   /*
>>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>    *
>>    * This code is free software; you can redistribute it and/or modify it
>>    * under the terms of the GNU General Public License version 2 only, as
>>    * published by the Free Software Foundation.
>>    *
>>    * This code is distributed in the hope that it will be useful, but WITHOUT
>>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>    * version 2 for more details (a copy is included in the LICENSE file that
>>    * accompanied this code).
>>    *
>>    * You should have received a copy of the GNU General Public License version
>>    * 2 along with this work; if not, write to the Free Software Foundation,
>>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>    *
>>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>    * or visit www.oracle.com if you need additional information or have any
>>    * questions.
>>    */
>>   package org.sample;
>>   
>>   import org.openjdk.jmh.annotations.Benchmark;
>>   import org.openjdk.jmh.annotations.*;
>>   
>>   import java.util.Random;
>>   import java.util.concurrent.TimeUnit;
>>   import org.openjdk.jmh.infra.Blackhole;
>>   
>>   @BenchmarkMode({Mode.AverageTime})
>>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>>   public class MyBenchmark {
>>   
>>       static int length = 100000;
>>       static double[] data1 = new double[length];
>>       static double[] data2 = new double[length];
>>       static Random random = new Random();
>>   
>>       static {
>>           for(int i = 0; i < length; ++i) {
>>             data1[i] = random.nextDouble();
>>             data2[i] = random.nextDouble();
>>           }
>>       }
>>   
>>       @Benchmark
>>       public void testAdd(Blackhole bh) {
>>         double sum = 0;
>>         for (int i = 0; i < length; i++) {
>>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>>         }
>>         bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMax(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMin(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMul(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   }
>>   ```
>> 
>> *  The result is listed here (aarch64):
>> 
>>   before:
>> 
>>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>>  
>>   after:
>> 
>>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |
>> 
>> *  I have tested `NaN`  ` INFINITY` and `-INFINITY` and got same result (before/after)
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust code style

Thank you for your review.
> Do you have a real example in Java applications which benefit from this optimization?
> We should not add and **support** code which would never be used in real world.
> 
Yes. We refined this optimization from our internal software experience. For instance, the model `min( max(a,b) , min(a,b)))` exists in many source codes in  some AI projects.
> Optimization will not work for Integer because of `_min` and `_max` intrinsic which generates `cmove`:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1806
> 
Yes. Adding `MaxINode`'s `max_opcode`  is just for `max_opcode` method is abstract. Our test cases is for float types only. 
> I am not sure if this optimization will always work for float/double because of NaN values.
> 
> You need to verify results for all edge cases.

I have tested that and showed in my comments. The test cases for NaN values and other special values are listed here 

import java.lang.Math;

public class Test {

    public static void main(String[] args) throws Exception {
      Test m = new Test();
      m.test();
    }

    public void test() throws Exception {
      double[] num = new double[9];
      num[0] = 1; num[1] = 0; num[2] = -0;
      num[3] = Double.POSITIVE_INFINITY; 
      num[4] = Double.NEGATIVE_INFINITY;
      num[5] = Double.NaN;
      num[6] = Double.MAX_VALUE;
      num[7] = Double.MIN_VALUE;
      num[8] = Double.MIN_NORMAL;

      for(int i = 0; i < 9; i++) {
        for(int j = 0; j < 9; j++) {
          check(add_opt(num[i], num[j]), (num[i] + num[j]));
          check(mul_opt(num[i], num[j]), (num[i] * num[j]));
          check(max_opt(num[i], num[j]), Math.max(num[i], num[j]));
          check(min_opt(num[i], num[j]), Math.min(num[i], num[j]));
        } 
      }
    }

    public void check(double a, double b) {
      if (a != b) {
        System.out.println("false");
        System.out.println(a);
        System.out.println(b);
        System.out.println();
      }
    }

    public double add_opt(double a, double b) throws Exception {
      return Math.max(a, b) + Math.min(a, b);
    }

    public double mul_opt(double a, double b) throws Exception {
      return Math.max(a, b) * Math.min(a, b);
    }

    public double max_opt(double a, double b) throws Exception {
      return Math.max(Math.max(a, b), Math.min(a, b));
    }

    public double min_opt(double a, double b) throws Exception {
      return Math.min(Math.max(a, b), Math.min(a, b));
    }
}

The `NaN` is a special case. Because `NaN == NaN` is false in Java, so I run the case and check the result. 

Should I add the other test cases for `NaN` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From iveresov at openjdk.java.net  Sat Apr 17 19:12:38 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Sat, 17 Apr 2021 19:12:38 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <feA-fqkDnR9U0BcFMI5TAlyuscfFq477kaznvWW-E7E=.eca90fbb-f8ca-44bf-b5b5-f745f001374c@github.com>

On Tue, 13 Apr 2021 05:46:15 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

Ok, I'll try to reproduce it and take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3449

From iveresov at openjdk.java.net  Sat Apr 17 20:11:34 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Sat, 17 Apr 2021 20:11:34 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <FoRmnL15iMkojM7ngWfojLfBfwORQSjgzDtCL8A3TDk=.179d8bc2-d1b9-404a-aeda-9f371798588c@github.com>

On Tue, 13 Apr 2021 05:46:15 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

So, I would propose doing it the following way. Basically, I think we should put ```if (has_c1())``` around the whole thing because ```NeverActAsServerClassMachine``` doesn't make any sense without C1.


diff --git a/src/hotspot/share/compiler/compilerDefinitions.cpp b/src/hotspot/share/compiler/compilerDefinitions.cpp
index f8eff0a6917..7db439373a1 100644
--- a/src/hotspot/share/compiler/compilerDefinitions.cpp
+++ b/src/hotspot/share/compiler/compilerDefinitions.cpp
@@ -159,7 +159,8 @@ intx CompilerConfig::scaled_freq_log(intx freq_log, double scale) {
   }
 }
 
-void set_client_emulation_mode_flags() {
+void CompilerConfig::set_client_emulation_mode_flags() {
+  assert(has_c1(), "Must have C1 compiler present");
   CompilationModeFlag::set_quick_only();
 
   FLAG_SET_ERGO(ProfileInterpreter, false);
@@ -560,17 +561,19 @@ void CompilerConfig::ergo_initialize() {
   return;
 #endif
 
-  if (!is_compilation_mode_selected()) {
+  if (has_c1()) {
+    if (!is_compilation_mode_selected()) {
 #if defined(_WINDOWS) && !defined(_LP64)
-    if (FLAG_IS_DEFAULT(NeverActAsServerClassMachine)) {
-      FLAG_SET_ERGO(NeverActAsServerClassMachine, true);
-    }
+      if (FLAG_IS_DEFAULT(NeverActAsServerClassMachine)) {
+        FLAG_SET_ERGO(NeverActAsServerClassMachine, true);
+      }
 #endif
-    if (NeverActAsServerClassMachine) {
+      if (NeverActAsServerClassMachine) {
+        set_client_emulation_mode_flags();
+      }
+    } else if (!has_c2() && !is_jvmci_compiler()) {
       set_client_emulation_mode_flags();
     }
-  } else if (!has_c2() && !is_jvmci_compiler()) {
-    set_client_emulation_mode_flags();
   }
 
   set_legacy_emulation_flags();
diff --git a/src/hotspot/share/compiler/compilerDefinitions.hpp b/src/hotspot/share/compiler/compilerDefinitions.hpp
index d87c892f091..2f8794ad43a 100644
--- a/src/hotspot/share/compiler/compilerDefinitions.hpp
+++ b/src/hotspot/share/compiler/compilerDefinitions.hpp
@@ -246,6 +246,7 @@ private:
   static void set_compilation_policy_flags();
   static void set_jvmci_specific_flags();
   static void set_legacy_emulation_flags();
+  static void set_client_emulation_mode_flags();
 };
 
 #endif // SHARE_COMPILER_COMPILERDEFINITIONS_HPP

-------------

PR: https://git.openjdk.java.net/jdk/pull/3449

From dnsimon at openjdk.java.net  Sat Apr 17 20:48:07 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Sat, 17 Apr 2021 20:48:07 GMT
Subject: RFR: 8252600: [JVMCI] update JVMCI code style and mx configuration
Message-ID: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>

This PR updates the configuration files used to develop the JVMCI Java and C++ sources with mx and Eclipse.

-------------

Commit messages:
 - 8252600: [JVMCI] update JVMCI code style and mx configuration

Changes: https://git.openjdk.java.net/jdk/pull/3559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3559&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252600
  Stats: 2096 lines in 14 files changed: 752 ins; 1344 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3559/head:pull/3559

PR: https://git.openjdk.java.net/jdk/pull/3559

From alanb at openjdk.java.net  Sun Apr 18 07:34:55 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 18 Apr 2021 07:34:55 GMT
Subject: RFR: 8252600: [JVMCI] update JVMCI code style and mx configuration
In-Reply-To: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
Message-ID: <zETCprW0FmODJclHlZ0s1GessBhPtQ7O_FIwHW1C6wE=.c7c73a99-d7b1-4572-af9c-0e1164ebd522@github.com>

On Sat, 17 Apr 2021 20:37:08 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR updates the configuration files used to develop the JVMCI Java and C++ sources with mx and Eclipse.

Are you sure it make sense to have this dev config in the openjdk/jdk repo? I would think this is something for the downstream Graal repos.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3559

From dnsimon at openjdk.java.net  Sun Apr 18 09:53:41 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Sun, 18 Apr 2021 09:53:41 GMT
Subject: RFR: 8252600: [JVMCI] update JVMCI code style and mx configuration
In-Reply-To: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
Message-ID: <ZjZnefK-fECJsDZ2c5xtbdGCT2mN-E2uQXBBcVoyQos=.114eef79-92c9-493e-acf4-d3906c62a238@github.com>

On Sat, 17 Apr 2021 20:37:08 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR updates the configuration files used to develop the JVMCI Java and C++ sources with mx and Eclipse.

Until we have downstream repos for JDK 17, it's very handy to have this config in the JDK. I've tried to keep it only in JVMCI related directories so as to not perturb non-JVMCI sources. However, if the consensus is that this config does not belong in the JDK at all, I will repurpose this PR to remove all such config as it's current broken as is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3559

From lists at steffen-moser.de  Sun Apr 18 11:53:11 2021
From: lists at steffen-moser.de (Steffen Moser)
Date: Sun, 18 Apr 2021 13:53:11 +0200
Subject: Backport of JDK-8249672 ("Include microcode revision in
 features_string") to JDK-11.0.10 breaks compiling it on Oracle Solaris 11.4
Message-ID: <473d105d-9cd3-475f-726a-97fe93c2bb4c@steffen-moser.de>

Hi all,

I am new into JDK contribution/bug reporting, so I really hope I've 
chosen the right way to report a bug - at least I could neither find a 
possibility to register for openjdk.java.net nor did my Oracle SSO 
account work on this site.

Bug report: In JDK-8249672, the microcode version of an x86 CPU was 
added to the "features_string" printed in an hs_err_pidXXXXX log file. 
As far as I know, it was introduced to JDK-16 and back-ported to both, 
JDK-15 and JDK-11 last year. While Solaris support was (unfortunately) 
abandoned in JDK-15, JDK-11 still supports and should further support 
Solaris on both SPARC and x86 if my information is correct.

I desperately need JDK-11 (and probably newer versions of Java) in order 
to run several modern open-source tools. When trying to compile JDK-11 
on Solaris 11.4 SRU 31 on x86 according to [1] and [2], I run into the 
following compile error problem:

    "./src/hotspot/cpu/x86/vm_version_x86.cpp", line 753: Error: 
cpu_microcode_revision is not a member of os.
    1 Error(s) detected.

The reason is quite obvious. The method

    os::cpu_microcode_revision()

is not defined for the Solaris platform as JDK-8249672 does not alter

    src/hotspot/os_cpu/solaris_x86/os_solaris_x86.hpp
    src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp

The question is: How should we fix it? Is it allowed to call Solaris'

    /usr/sbin/ucodeadm -v

and parse this binary's results or do we have to get the contents from 
"/dev/ucode" (which seems to be the symlink to the pseudo-device 
"/devices/pseudo/ucode at 0:ucode" and is accessed by ucodeadm) manually?

Any help to make JDK 11 compiling on Solaris 11.4/x86 again would be 
highly appreciated. Thank you very much in advance!

Kind regards,
Steffen

[1] https://blogs.oracle.com/solaris/building-openjdk-12-using-jdk-8
[2] 
http://notallmicrosoft.blogspot.com/2020/04/building-openjdk-13-and-openjdk-14-on.html

From github.com+40024232+sunny868 at openjdk.java.net  Sun Apr 18 13:03:51 2021
From: github.com+40024232+sunny868 at openjdk.java.net (SUN Guoyun)
Date: Sun, 18 Apr 2021 13:03:51 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <K72ed_WI0oPgvpHjc0SrSw0UQy4d6uFBkHHOk1RiFLA=.6f585dd7-c365-4b45-9a0b-6c87f65d2284@github.com>

On Tue, 13 Apr 2021 05:46:15 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

OK, thank you. I'll update this patch later

-------------

PR: https://git.openjdk.java.net/jdk/pull/3449

From dnsimon at openjdk.java.net  Sun Apr 18 20:17:14 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Sun, 18 Apr 2021 20:17:14 GMT
Subject: RFR: 8252600: remove mx configuration [v2]
In-Reply-To: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
Message-ID: <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com>

> This PR updates the configuration files used to develop the JVMCI Java and C++ sources with mx and Eclipse.

Doug Simon 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:

  8252600: [JVMCI] remove mx configuration

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3559/files
  - new: https://git.openjdk.java.net/jdk/pull/3559/files/7026605f..7c18d2d9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3559&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3559&range=00-01

  Stats: 754 lines in 8 files changed: 0 ins; 754 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3559/head:pull/3559

PR: https://git.openjdk.java.net/jdk/pull/3559

From dnsimon at openjdk.java.net  Sun Apr 18 20:20:43 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Sun, 18 Apr 2021 20:20:43 GMT
Subject: RFR: 8252600: remove mx configuration [v2]
In-Reply-To: <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com>
References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
 <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com>
Message-ID: <9BHFJ8Vurf3bVA12x8Fo0iaZGzQmUrXCbImXjY56Wtw=.daf237c0-2368-48dd-9fc0-5936431ddd56@github.com>

On Sun, 18 Apr 2021 20:17:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk.
>
> Doug Simon 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:
> 
>   8252600: [JVMCI] remove mx configuration

On second thoughts, I concur with you Alan and am thus using this PR to remove the mx configuration files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3559

From github.com+40024232+sunny868 at openjdk.java.net  Mon Apr 19 01:23:06 2021
From: github.com+40024232+sunny868 at openjdk.java.net (SUN Guoyun)
Date: Mon, 19 Apr 2021 01:23:06 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled [v2]
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <nTmx66kTGCytWWTwqLBsM29XHW3YgvCF0YlHoYWGM2g=.1204b6ad-883d-43a6-8848-bd32002a8943@github.com>

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

SUN Guoyun 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:

  8265105: gc/arguments/TestSelectDefaultGC.java fails when compiler1 is disabled

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3449/files
  - new: https://git.openjdk.java.net/jdk/pull/3449/files/51dcbbf8..c21468f2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3449&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3449&range=00-01

  Stats: 14 lines in 2 files changed: 6 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3449/head:pull/3449

PR: https://git.openjdk.java.net/jdk/pull/3449

From yyang at openjdk.java.net  Mon Apr 19 02:12:35 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 19 Apr 2021 02:12:35 GMT
Subject: RFR: 8265245: depChecker_<cpu> don't have any functionalities
In-Reply-To: <7KW8AJT9EL9Mt0Tebhtooow-7zbDcwEbeoG21HURdG8=.12c7367e-11fc-4a45-b9c1-23f97321799d@github.com>
References: <1JKPxPdQ9XoTDXdIP8P_eBy6EqYZhEoD8SACCs0MfSs=.d5cd2e5f-6c11-4be8-8651-3931368d1471@github.com>
 <7KW8AJT9EL9Mt0Tebhtooow-7zbDcwEbeoG21HURdG8=.12c7367e-11fc-4a45-b9c1-23f97321799d@github.com>
Message-ID: <yhKF_FVXjxLKeQxc1JkTpCymIQINLnQPMzON6Rg2DIQ=.299919b0-3c55-4694-84c5-622b401992c3@github.com>

On Fri, 16 Apr 2021 08:10:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Yet another OpenJDK6 old guy.
>> 
>> src/hotspot/cpu/<cpu>/depChecker_<cpu>.hpp/cpp are included by src/hotspot/share/compiler/disassembler.cpp, they don't provide any functionality.
>> 
>> In the absence of strong demand either in existing ARCHs or future ARCHs, I think we can remove it.
>
> Looks good to me.

Thanks @TobiHartmann and @neliasso for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3531

From yyang at openjdk.java.net  Mon Apr 19 02:12:34 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 19 Apr 2021 02:12:34 GMT
Subject: RFR: 8265323: Leftover local variables in PcDesc
In-Reply-To: <lGsmWjazJJuz60LmuUGopsHQBE3dEGJy4Kgs7_fEACk=.cd02f7ef-a37f-4476-958c-23d0744babb6@github.com>
References: <G9FMO7Ufi1r0TDmkBZT4Pp55_BEGsEY2E-GFieB8JwQ=.fcdd124e-9e4b-41b7-bce1-2821651f948e@github.com>
 <lGsmWjazJJuz60LmuUGopsHQBE3dEGJy4Kgs7_fEACk=.cd02f7ef-a37f-4476-958c-23d0744babb6@github.com>
Message-ID: <IaR0MpSiS5vyB-mAsghNIjqGq9pPsVSHi0_rWNd8g5c=.5a2718a0-c941-4177-b7e1-d1585198bccc@github.com>

On Fri, 16 Apr 2021 08:08:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Leftover local variables in PcDesc. Remove it to save electric power.
>
> Marked as reviewed by thartmann (Reviewer).

Thanks @TobiHartmann and @neliasso for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3532

From yyang at openjdk.java.net  Mon Apr 19 02:22:34 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 19 Apr 2021 02:22:34 GMT
Subject: RFR: 8265322: C2: Simplify control inputs for
 BarrierSetC2::obj_allocate
In-Reply-To: <SPtW3V9OzA3ecZhHI8aFwOB2z0c7leuWZDuK6HpHIgI=.3db80bff-cf4b-4183-844b-2db4a2b93e80@github.com>
References: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
 <SPtW3V9OzA3ecZhHI8aFwOB2z0c7leuWZDuK6HpHIgI=.3db80bff-cf4b-4183-844b-2db4a2b93e80@github.com>
Message-ID: <jZYYkujO47rgKqpW8MEhfTFX4Cjez5LIhYF6yqZNMOA=.9e69a777-dd91-466c-8070-9a2dd8062541@github.com>

On Fri, 16 Apr 2021 17:37:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> From compiler code POV the fix is reasonable and correct.

Thank you @vnkozlov!

Do you think it's reasonable to move PhaseMacroExpand::set_eden_pointers to BarrierSetC2? It seems that that's GC knowledge area about how to set eden_top/eden_end w or w/o turning UseTLAB.

> Note, the path when `initial_slow_test != NULL` is not rare. It is frequent for arrays allocation when `length` is not constant.

Yes, I missed the AllocateArrayNode when skimming the code. Thanks for pointing out this.

Let's wait for other hotspot gc/compiler folks for more reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3529

From yyang at openjdk.java.net  Mon Apr 19 04:59:03 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 19 Apr 2021 04:59:03 GMT
Subject: RFR: 8265106: IGV: Enforce en-US locale while parsing ideal graph
Message-ID: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>

IGV is designed to support parsing incomplete XML. However, it does not work for non-English users. See XXPR for the detailed reasons. This patch would address it.

(P.S. Locale.ENGLISH also does not work, see  Philip Helger' [comment](https://stackoverflow.com/questions/18531633/locale-specific-messages-in-xerces-2-11-0-java) on the first answer.)

-------------

Commit messages:
 - parse incomplete xml

Changes: https://git.openjdk.java.net/jdk/pull/3563/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3563&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265106
  Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3563.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3563/head:pull/3563

PR: https://git.openjdk.java.net/jdk/pull/3563

From yyang at openjdk.java.net  Mon Apr 19 04:59:03 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 19 Apr 2021 04:59:03 GMT
Subject: RFR: 8265106: IGV: Enforce en-US locale while parsing ideal graph
In-Reply-To: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
References: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
Message-ID: <s2CQFuixGh2glJNCOlgBIpaZo-L15Ebu45AEBCZxctE=.8b85f3e9-85e8-400a-b00d-32eacca2a855@github.com>

On Mon, 19 Apr 2021 04:48:07 GMT, Yi Yang <yyang at openjdk.org> wrote:

> IGV is designed to support parsing incomplete XML. However, it does not work for non-English users. See XXPR for the detailed reasons. This patch would address it.
> 
> (P.S. Locale.ENGLISH also does not work, see  Philip Helger' [comment](https://stackoverflow.com/questions/18531633/locale-specific-messages-in-xerces-2-11-0-java) on the first answer.)

Thanks @robcasloz  for giving this purposed fix!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3563

From yyang at openjdk.java.net  Mon Apr 19 06:29:35 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 19 Apr 2021 06:29:35 GMT
Subject: Integrated: 8265323: Leftover local variables in PcDesc
In-Reply-To: <G9FMO7Ufi1r0TDmkBZT4Pp55_BEGsEY2E-GFieB8JwQ=.fcdd124e-9e4b-41b7-bce1-2821651f948e@github.com>
References: <G9FMO7Ufi1r0TDmkBZT4Pp55_BEGsEY2E-GFieB8JwQ=.fcdd124e-9e4b-41b7-bce1-2821651f948e@github.com>
Message-ID: <KCUQRr8MF8R0IX1NQnNVOlwAZkAZeiVOmrO86bZxWvk=.af382e0a-b20f-4709-92d6-d09801c047a5@github.com>

On Fri, 16 Apr 2021 03:16:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Leftover local variables in PcDesc. Remove it to save electric power.

This pull request has now been integrated.

Changeset: a2b0e0f4
Author:    Yi Yang <yyang at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a2b0e0f4
Stats:     6 lines in 1 file changed: 0 ins; 5 del; 1 mod

8265323: Leftover local variables in PcDesc

Reviewed-by: thartmann, neliasso

-------------

PR: https://git.openjdk.java.net/jdk/pull/3532

From yyang at openjdk.java.net  Mon Apr 19 06:30:41 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 19 Apr 2021 06:30:41 GMT
Subject: Integrated: 8265245: depChecker_<cpu> don't have any functionalities
In-Reply-To: <1JKPxPdQ9XoTDXdIP8P_eBy6EqYZhEoD8SACCs0MfSs=.d5cd2e5f-6c11-4be8-8651-3931368d1471@github.com>
References: <1JKPxPdQ9XoTDXdIP8P_eBy6EqYZhEoD8SACCs0MfSs=.d5cd2e5f-6c11-4be8-8651-3931368d1471@github.com>
Message-ID: <5HVUqQeZKsgXRGEmzpXbVxw-0vmHU0Ofg8ZrRh48rL8=.0b2794fd-33c6-4438-b910-ff848312e15f@github.com>

On Fri, 16 Apr 2021 03:10:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Yet another OpenJDK6 old guy.
> 
> src/hotspot/cpu/<cpu>/depChecker_<cpu>.hpp/cpp are included by src/hotspot/share/compiler/disassembler.cpp, they don't provide any functionality.
> 
> In the absence of strong demand either in existing ARCHs or future ARCHs, I think we can remove it.

This pull request has now been integrated.

Changeset: fa58aae8
Author:    Yi Yang <yyang at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fa58aae8
Stats:     305 lines in 13 files changed: 0 ins; 305 del; 0 mod

8265245: depChecker_<cpu> don't have any functionalities

Reviewed-by: thartmann, neliasso

-------------

PR: https://git.openjdk.java.net/jdk/pull/3531

From rcastanedalo at openjdk.java.net  Mon Apr 19 08:07:33 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 19 Apr 2021 08:07:33 GMT
Subject: RFR: 8265106: IGV: Enforce en-US locale while parsing ideal graph
In-Reply-To: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
References: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
Message-ID: <JDonwZwMWxe5Gn9XmZsWO0K70QMD7kpMvOtJ_qP9PuU=.94788c11-3a18-4caa-afd8-5d59c0cfd237@github.com>

On Mon, 19 Apr 2021 04:48:07 GMT, Yi Yang <yyang at openjdk.org> wrote:

> IGV is designed to support parsing incomplete XML. However, it does not work for non-English users. See #3071 for detailed reasons. This patch would address it.
> 
> (P.S. Locale.ENGLISH also does not work, see  Philip Helger' [comment](https://stackoverflow.com/questions/18531633/locale-specific-messages-in-xerces-2-11-0-java) on the first answer.)

Hi Yang, I tested this on Linux by opening a file missing closing `group` and `graphDocument` tags ([incomplete.xml](https://bugs.openjdk.java.net/secure/attachment/94215/incomplete.zip)), and it works for the following configurations:
- JDK versions 8, 11, and 15
- `export LC_ALL=es_ES.UTF-8`, `export LC_ALL=en_US.UTF-8`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3563

From eliu at openjdk.java.net  Mon Apr 19 08:54:49 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Mon, 19 Apr 2021 08:54:49 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
 [v2]
In-Reply-To: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
Message-ID: <tXhN0LYkB6C4g82DSiZ2NIG3v90gi0jtWOQHKQ3B6uc=.86a47a4f-678a-4395-9761-77ddb136111e@github.com>

> The vector shift count was defined by two separate nodes(LShiftCntV and
> RShiftCntV), which would prevent them from being shared when the shift
> counts are the same.
> 
> 
> public static void test_shiftv(int sh) {
>     for (int i = 0; i < N; i+=1) {
>         a0[i] = a1[i] << sh;
>         b0[i] = b1[i] >> sh;
>     }
> }
> 
> 
> Given the example above, by merging the same shift counts into one
> node, they could be shared by shift nodes(RShiftV or LShiftV) like
> below:
> 
> 
> Before:
> 1184  LShiftCntV  === _  1189  [[ 1185  ... ]]
> 1190  RShiftCntV  === _  1189  [[ 1191  ... ]]
> 1185  LShiftVI  === _  1181  1184  [[ 1186 ]]
> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
> 
> After:
> 1190  ShiftCntV  === _  1189  [[ 1191 1204  ... ]]
> 1204  LShiftVI  === _  1211  1190  [[ 1203 ]]
> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
> 
> 
> The final code could remove one redundant ?dup?(scalar->vector),
> with one register saved.
> 
> 
> Before:
>         dup     v16.16b, w12
>         dup     v17.16b, w12
>         ...
>         ldr     q18, [x13, #16]
>         sshl    v18.4s, v18.4s, v16.4s
>         add     x18, x16, x12           ; iaload
> 
>         add     x4, x15, x12
>         str     q18, [x4, #16]          ; iastore
> 
>         ldr     q18, [x18, #16]
>         add     x12, x14, x12
>         neg     v19.16b, v17.16b
>         sshl    v18.4s, v18.4s, v19.4s
>         str     q18, [x12, #16]         ; iastore
> 
> After:
>         dup	v16.16b, w11
>         ...
>         ldr	q17, [x13, #16]
>         sshl	v17.4s, v17.4s, v16.4s
>         add	x2, x22, x11            ; iaload
> 
>         add	x4, x16, x11
>         str	q17, [x4, #16]          ; iastore
> 
>         ldr	q17, [x2, #16]
>         add	x11, x21, x11
>         neg	v18.16b, v16.16b
>         sshl	v17.4s, v17.4s, v18.4s
>         str	q17, [x11, #16]         ; iastore

Eric Liu has updated the pull request incrementally with one additional commit since the last revision:

  code backup
  
  Change-Id: Ie9046b1d7e8f5e2669767756b6b074b564523039

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3371/files
  - new: https://git.openjdk.java.net/jdk/pull/3371/files/eece376d..c860c725

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3371&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3371&range=00-01

  Stats: 826 lines in 10 files changed: 324 ins; 205 del; 297 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3371.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3371/head:pull/3371

PR: https://git.openjdk.java.net/jdk/pull/3371

From yyang at openjdk.java.net  Mon Apr 19 09:02:34 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 19 Apr 2021 09:02:34 GMT
Subject: RFR: 8265106: IGV: Enforce en-US locale while parsing ideal graph
In-Reply-To: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
References: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
Message-ID: <OA8RHXbUlfFs-AdSiSTjdRefwfbvEIRAJkqJuklMdFU=.345ed48d-b7a0-4207-8227-bf28cf729012@github.com>

On Mon, 19 Apr 2021 04:48:07 GMT, Yi Yang <yyang at openjdk.org> wrote:

> IGV is designed to support parsing incomplete XML. However, it does not work for non-English users. See #3071 for detailed reasons. This patch would address it.
> 
> (P.S. Locale.ENGLISH also does not work, see  Philip Helger' [comment](https://stackoverflow.com/questions/18531633/locale-specific-messages-in-xerces-2-11-0-java) on the first answer.)

Thank you Roberto for additional testing :)

It also works for my following configuration:
+ JDK 15
+ Both en-US and zh-CN (Systme Locale, not LC_ALL environment variable)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3563

From eliu at openjdk.java.net  Mon Apr 19 09:02:40 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Mon, 19 Apr 2021 09:02:40 GMT
Subject: Withdrawn: 8262916: Merge LShiftCntV and RShiftCntV into a single node
In-Reply-To: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
Message-ID: <tyMjIr-kXvHfhFmaKI6RkS-jBZ2kD2LSEHHrk8GmnN4=.c2e7e5e6-9290-4f6b-a236-8e74b91b859c@github.com>

On Wed, 7 Apr 2021 07:28:08 GMT, Eric Liu <eliu at openjdk.org> wrote:

> The vector shift count was defined by two separate nodes(LShiftCntV and
> RShiftCntV), which would prevent them from being shared when the shift
> counts are the same.
> 
> 
> public static void test_shiftv(int sh) {
>     for (int i = 0; i < N; i+=1) {
>         a0[i] = a1[i] << sh;
>         b0[i] = b1[i] >> sh;
>     }
> }
> 
> 
> Given the example above, by merging the same shift counts into one
> node, they could be shared by shift nodes(RShiftV or LShiftV) like
> below:
> 
> 
> Before:
> 1184  LShiftCntV  === _  1189  [[ 1185  ... ]]
> 1190  RShiftCntV  === _  1189  [[ 1191  ... ]]
> 1185  LShiftVI  === _  1181  1184  [[ 1186 ]]
> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
> 
> After:
> 1190  ShiftCntV  === _  1189  [[ 1191 1204  ... ]]
> 1204  LShiftVI  === _  1211  1190  [[ 1203 ]]
> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
> 
> 
> The final code could remove one redundant ?dup?(scalar->vector),
> with one register saved.
> 
> 
> Before:
>         dup     v16.16b, w12
>         dup     v17.16b, w12
>         ...
>         ldr     q18, [x13, #16]
>         sshl    v18.4s, v18.4s, v16.4s
>         add     x18, x16, x12           ; iaload
> 
>         add     x4, x15, x12
>         str     q18, [x4, #16]          ; iastore
> 
>         ldr     q18, [x18, #16]
>         add     x12, x14, x12
>         neg     v19.16b, v17.16b
>         sshl    v18.4s, v18.4s, v19.4s
>         str     q18, [x12, #16]         ; iastore
> 
> After:
>         dup	v16.16b, w11
>         ...
>         ldr	q17, [x13, #16]
>         sshl	v17.4s, v17.4s, v16.4s
>         add	x2, x22, x11            ; iaload
> 
>         add	x4, x16, x11
>         str	q17, [x4, #16]          ; iastore
> 
>         ldr	q17, [x2, #16]
>         add	x11, x21, x11
>         neg	v18.16b, v16.16b
>         sshl	v17.4s, v17.4s, v18.4s
>         str	q17, [x11, #16]         ; iastore

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3371

From eliu at openjdk.java.net  Mon Apr 19 09:02:39 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Mon, 19 Apr 2021 09:02:39 GMT
Subject: RFR: 8262916: Merge LShiftCntV and RShiftCntV into a single node
 [v2]
In-Reply-To: <tXhN0LYkB6C4g82DSiZ2NIG3v90gi0jtWOQHKQ3B6uc=.86a47a4f-678a-4395-9761-77ddb136111e@github.com>
References: <g6nnA-9kuXBvqi7cDOgVPZjXkO1hNWbNaR0kFLSAfAc=.1b1f2f44-ebfb-4d98-b49e-1c355d068508@github.com>
 <tXhN0LYkB6C4g82DSiZ2NIG3v90gi0jtWOQHKQ3B6uc=.86a47a4f-678a-4395-9761-77ddb136111e@github.com>
Message-ID: <yvff8_bhkGOpVfGJSDiwVyNyp-C7U3jGNdTTzggpUnM=.3577192f-88ae-4925-8b06-80293bddaaee@github.com>

On Mon, 19 Apr 2021 08:54:49 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> The vector shift count was defined by two separate nodes(LShiftCntV and
>> RShiftCntV), which would prevent them from being shared when the shift
>> counts are the same.
>> 
>> 
>> public static void test_shiftv(int sh) {
>>     for (int i = 0; i < N; i+=1) {
>>         a0[i] = a1[i] << sh;
>>         b0[i] = b1[i] >> sh;
>>     }
>> }
>> 
>> 
>> Given the example above, by merging the same shift counts into one
>> node, they could be shared by shift nodes(RShiftV or LShiftV) like
>> below:
>> 
>> 
>> Before:
>> 1184  LShiftCntV  === _  1189  [[ 1185  ... ]]
>> 1190  RShiftCntV  === _  1189  [[ 1191  ... ]]
>> 1185  LShiftVI  === _  1181  1184  [[ 1186 ]]
>> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
>> 
>> After:
>> 1190  ShiftCntV  === _  1189  [[ 1191 1204  ... ]]
>> 1204  LShiftVI  === _  1211  1190  [[ 1203 ]]
>> 1191  RShiftVI  === _  1187  1190  [[ 1192 ]]
>> 
>> 
>> The final code could remove one redundant ?dup?(scalar->vector),
>> with one register saved.
>> 
>> 
>> Before:
>>         dup     v16.16b, w12
>>         dup     v17.16b, w12
>>         ...
>>         ldr     q18, [x13, #16]
>>         sshl    v18.4s, v18.4s, v16.4s
>>         add     x18, x16, x12           ; iaload
>> 
>>         add     x4, x15, x12
>>         str     q18, [x4, #16]          ; iastore
>> 
>>         ldr     q18, [x18, #16]
>>         add     x12, x14, x12
>>         neg     v19.16b, v17.16b
>>         sshl    v18.4s, v18.4s, v19.4s
>>         str     q18, [x12, #16]         ; iastore
>> 
>> After:
>>         dup	v16.16b, w11
>>         ...
>>         ldr	q17, [x13, #16]
>>         sshl	v17.4s, v17.4s, v16.4s
>>         add	x2, x22, x11            ; iaload
>> 
>>         add	x4, x16, x11
>>         str	q17, [x4, #16]          ; iastore
>> 
>>         ldr	q17, [x2, #16]
>>         add	x11, x21, x11
>>         neg	v18.16b, v16.16b
>>         sshl	v17.4s, v17.4s, v18.4s
>>         str	q17, [x11, #16]         ; iastore
>
> Eric Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code backup
>   
>   Change-Id: Ie9046b1d7e8f5e2669767756b6b074b564523039

VectorAPI would *not* profit from this two nodes' separation as the input of RShiftVNode may *not* be a RShiftCntVNode[1]. Inserting a special 'VNEG' only for AArch64 in mid-end maybe work but seems too ugly and merging those two nodes would harm AArch32. It's quite hard to compromise the benefits between AArch64 and other architectures.

[1] https://github.com/openjdk/jdk/blob/jdk-17%2B18/src/hotspot/cpu/aarch64/aarch64_neon.ad#L5179

-------------

PR: https://git.openjdk.java.net/jdk/pull/3371

From jiefu at openjdk.java.net  Mon Apr 19 09:26:35 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 19 Apr 2021 09:26:35 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v4]
In-Reply-To: <xoDP3SDEVlns0qus1CjPwULmFVmbnnmSqU4mD6aSj3o=.ba156071-21ac-48ab-946e-05e948d33090@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
 <6Nww_kOuxx9sjowFZjd0t1rYAOIkSaDDrGb1vkMc2iY=.0c81042a-a3b8-49b4-b718-112d1e7348f4@github.com>
 <xoDP3SDEVlns0qus1CjPwULmFVmbnnmSqU4mD6aSj3o=.ba156071-21ac-48ab-946e-05e948d33090@github.com>
Message-ID: <0DjbuczzhoibwdBZIvL30204me9UYPh-deHGmLFCpRE=.f7e6f122-01dc-4f47-a11e-c4f3da8e9807@github.com>

On Sat, 17 Apr 2021 01:50:00 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Good.

Thanks @vnkozlov .

May I get a second review for this change?
Or it's already OK to be pushed?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3536

From neliasso at openjdk.java.net  Mon Apr 19 09:41:57 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Mon, 19 Apr 2021 09:41:57 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v4]
In-Reply-To: <6Nww_kOuxx9sjowFZjd0t1rYAOIkSaDDrGb1vkMc2iY=.0c81042a-a3b8-49b4-b718-112d1e7348f4@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
 <6Nww_kOuxx9sjowFZjd0t1rYAOIkSaDDrGb1vkMc2iY=.0c81042a-a3b8-49b4-b718-112d1e7348f4@github.com>
Message-ID: <NUHoTHV32yclpAieIZfdjt1tcdxef9OQ2COudiMz3NM=.b9efe5fb-d7cd-43e6-bb4a-9e91dd4f08ec@github.com>

On Fri, 16 Apr 2021 23:51:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> I'd like to optimize the StubRoutines::dpow() for Math.pow(x, 0.5).
>> 
>> In the pow and sqrt discussion [1], Joe taught me that the Java library implementation of pow has been optimized for pow(x, 2.0) [2] and pow(x, 0.5) [3].
>> However, the hotspot StubRoutines::dpow() only implements the same opt for pow(x, 2.0), but still not for pow(x, 0.5).
>> This patch optimizes StubRoutines::dpow() for pow(x, 0.5).
>> 
>> Although not all Math.pow(x, 0.5) can be replaced with sqrt(x), we can still do it safely for the following cases:
>>   1) x >= 0.0    (fully implemented)
>>   2) x is +Inf   (fully implemented)
>>   3) x is NaN    (can be further divided into +NaN and -NaN and only +NaN is implemented)
>> 
>> The effect of this opt has been tested on serveral platforms showing 3.0x ~ 6.3x performance improvement.
>> And no performance drop was observed.
>> 
>> Testing:
>>   - tier1 ~ tier3 on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076220.html
>> [2] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L362
>> [3] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L364
>> 
>> Detailed performance numbers:
>> * Linux/Intel
>> 
>> --------- Before -----------
>> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
>> MathBench.powDouble                 0  thrpt    8  218783.605 ?   838.379  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8   45498.351 ?     7.558  ops/ms
>> MathBench.powDouble0Dot5Const       0  thrpt    8   45243.530 ?  1097.100  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.031 ?     0.001  ops/ms
>> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  176106.602 ? 13127.650  ops/ms
>> ----------------------------
>> 
>> --------- After -----------
>> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
>> MathBench.powDouble                 0  thrpt    8  219930.462 ?   181.922  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8  204966.834 ?   329.032  ops/ms   <-- 4.5x up
>> MathBench.powDouble0Dot5Const       0  thrpt    8  203004.302 ?   684.072  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.121 ?     0.001  ops/ms   <-- 3.9x up
>> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  178818.861 ? 16235.465  ops/ms
>> ----------------------------
>> 
>> 
>> * Linux/AMD
>> 
>> --------- Before -----------
>> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble                 0  thrpt    8  100741.348 ? 207.766  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8   33896.623 ? 103.352  ops/ms
>> MathBench.powDouble0Dot5Const       0  thrpt    8   34195.944 ? 230.703  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.039 ?   0.001  ops/ms
>> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8   72000.166 ? 135.002  ops/ms
>> ----------------------------
>> 
>> --------- After -----------
>> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble                 0  thrpt    8  100738.866 ? 222.820  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8  100799.098 ?  95.537  ops/ms   <-- 3.0x up
>> MathBench.powDouble0Dot5Const       0  thrpt    8  100765.571 ? 178.436  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.244 ?   0.002  ops/ms   <-- 6.3x up
>> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8   71758.725 ? 339.660  ops/ms
>> ----------------------------
>> 
>> 
>> * MacOS/Intel
>> 
>> --------- Before -----------
>> Benchmark                      (seed)   Mode  Cnt       Score      Error   Units
>> MathBench.powDouble                 0  thrpt    8  238064.722 ? 5181.318  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8   59235.979 ? 2046.519  ops/ms
>> MathBench.powDouble0Dot5Const       0  thrpt    8   59695.014 ? 1079.692  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.040 ?    0.001  ops/ms
>> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?    0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  238391.026 ? 2743.385  ops/ms
>> ----------------------------
>> 
>> --------- After -----------
>> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
>> MathBench.powDouble                 0  thrpt    8  238582.414 ?  3661.261  ops/ms
>> MathBench.powDouble0Dot5            0  thrpt    8  224102.701 ?  2846.892  ops/ms   <-- 3.8x up
>> MathBench.powDouble0Dot5Const       0  thrpt    8  224542.331 ? 19027.596  ops/ms
>> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.158 ?     0.002  ops/ms   <-- 4.0x up
>> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?     0.001  ops/ms
>> StrictMathBench.powDouble         N/A  thrpt    8  233689.504 ? 10141.034  ops/ms
>> ----------------------------
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert TestPow0Dot5Opt.java change

Approved.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3536

From neliasso at openjdk.java.net  Mon Apr 19 09:41:57 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Mon, 19 Apr 2021 09:41:57 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v4]
In-Reply-To: <0DjbuczzhoibwdBZIvL30204me9UYPh-deHGmLFCpRE=.f7e6f122-01dc-4f47-a11e-c4f3da8e9807@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
 <6Nww_kOuxx9sjowFZjd0t1rYAOIkSaDDrGb1vkMc2iY=.0c81042a-a3b8-49b4-b718-112d1e7348f4@github.com>
 <xoDP3SDEVlns0qus1CjPwULmFVmbnnmSqU4mD6aSj3o=.ba156071-21ac-48ab-946e-05e948d33090@github.com>
 <0DjbuczzhoibwdBZIvL30204me9UYPh-deHGmLFCpRE=.f7e6f122-01dc-4f47-a11e-c4f3da8e9807@github.com>
Message-ID: <96kPMdJewmI_yyl8pYgemG-xDvEw_-cq71YL8khL9pI=.21ff78cb-9432-4d31-bfe5-d374330e151d@github.com>

On Mon, 19 Apr 2021 09:23:35 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> May I get a second review for this change?
> Or it's already OK to be pushed?

You need a second review for changes to Hotspot. I will provide it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3536

From jiefu at openjdk.java.net  Mon Apr 19 09:41:57 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 19 Apr 2021 09:41:57 GMT
Subject: RFR: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5) [v4]
In-Reply-To: <NUHoTHV32yclpAieIZfdjt1tcdxef9OQ2COudiMz3NM=.b9efe5fb-d7cd-43e6-bb4a-9e91dd4f08ec@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
 <6Nww_kOuxx9sjowFZjd0t1rYAOIkSaDDrGb1vkMc2iY=.0c81042a-a3b8-49b4-b718-112d1e7348f4@github.com>
 <NUHoTHV32yclpAieIZfdjt1tcdxef9OQ2COudiMz3NM=.b9efe5fb-d7cd-43e6-bb4a-9e91dd4f08ec@github.com>
Message-ID: <Ih0qt7C-XmXzDkmtjmmFAPiZ3vg6o7duR8lsE1q22HQ=.2edd2bef-81f6-4430-9d91-1d50f1f2f75b@github.com>

On Mon, 19 Apr 2021 09:37:20 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Approved.

Thanks @neliasso .

-------------

PR: https://git.openjdk.java.net/jdk/pull/3536

From jiefu at openjdk.java.net  Mon Apr 19 10:49:38 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 19 Apr 2021 10:49:38 GMT
Subject: Integrated: 8265325: Optimize StubRoutines::dpow() for Math.pow(x,
 0.5)
In-Reply-To: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
References: <qMwOwZ2grwM137pfAXRZCcR6zqlKtDOMONHz3fLCep4=.8d7f487c-2d60-46a0-bfeb-c1637c7e8b16@github.com>
Message-ID: <wjTWGMK0ikBTEj5UOppmRLjXXoQruyxmcoN0mXuOHe4=.d4473c8b-1106-451d-bc7a-e988d285479e@github.com>

On Fri, 16 Apr 2021 06:51:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to optimize the StubRoutines::dpow() for Math.pow(x, 0.5).
> 
> In the pow and sqrt discussion [1], Joe taught me that the Java library implementation of pow has been optimized for pow(x, 2.0) [2] and pow(x, 0.5) [3].
> However, the hotspot StubRoutines::dpow() only implements the same opt for pow(x, 2.0), but still not for pow(x, 0.5).
> This patch optimizes StubRoutines::dpow() for pow(x, 0.5).
> 
> Although not all Math.pow(x, 0.5) can be replaced with sqrt(x), we can still do it safely for the following cases:
>   1) x >= 0.0    (fully implemented)
>   2) x is +Inf   (fully implemented)
>   3) x is NaN    (can be further divided into +NaN and -NaN and only +NaN is implemented)
> 
> The effect of this opt has been tested on serveral platforms showing 3.0x ~ 6.3x performance improvement.
> And no performance drop was observed.
> 
> Testing:
>   - tier1 ~ tier3 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076220.html
> [2] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L362
> [3] https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L364
> 
> Detailed performance numbers:
> * Linux/Intel
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  218783.605 ?   838.379  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   45498.351 ?     7.558  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   45243.530 ?  1097.100  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.031 ?     0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  176106.602 ? 13127.650  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  219930.462 ?   181.922  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  204966.834 ?   329.032  ops/ms   <-- 4.5x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  203004.302 ?   684.072  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.121 ?     0.001  ops/ms   <-- 3.9x up
> MathBench.powDoubleLoop             0  thrpt    8       0.031 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  178818.861 ? 16235.465  ops/ms
> ----------------------------
> 
> 
> * Linux/AMD
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble                 0  thrpt    8  100741.348 ? 207.766  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   33896.623 ? 103.352  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   34195.944 ? 230.703  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.039 ?   0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8   72000.166 ? 135.002  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble                 0  thrpt    8  100738.866 ? 222.820  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  100799.098 ?  95.537  ops/ms   <-- 3.0x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  100765.571 ? 178.436  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.244 ?   0.002  ops/ms   <-- 6.3x up
> MathBench.powDoubleLoop             0  thrpt    8       0.038 ?   0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8   71758.725 ? 339.660  ops/ms
> ----------------------------
> 
> 
> * MacOS/Intel
> 
> --------- Before -----------
> Benchmark                      (seed)   Mode  Cnt       Score      Error   Units
> MathBench.powDouble                 0  thrpt    8  238064.722 ? 5181.318  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8   59235.979 ? 2046.519  ops/ms
> MathBench.powDouble0Dot5Const       0  thrpt    8   59695.014 ? 1079.692  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.040 ?    0.001  ops/ms
> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?    0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  238391.026 ? 2743.385  ops/ms
> ----------------------------
> 
> --------- After -----------
> Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
> MathBench.powDouble                 0  thrpt    8  238582.414 ?  3661.261  ops/ms
> MathBench.powDouble0Dot5            0  thrpt    8  224102.701 ?  2846.892  ops/ms   <-- 3.8x up
> MathBench.powDouble0Dot5Const       0  thrpt    8  224542.331 ? 19027.596  ops/ms
> MathBench.powDouble0Dot5Loop        0  thrpt    8       0.158 ?     0.002  ops/ms   <-- 4.0x up
> MathBench.powDoubleLoop             0  thrpt    8       0.041 ?     0.001  ops/ms
> StrictMathBench.powDouble         N/A  thrpt    8  233689.504 ? 10141.034  ops/ms
> ----------------------------

This pull request has now been integrated.

Changeset: b64a3fb9
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b64a3fb9
Stats:     146 lines in 3 files changed: 145 ins; 0 del; 1 mod

8265325: Optimize StubRoutines::dpow() for Math.pow(x, 0.5)

Reviewed-by: kvn, neliasso

-------------

PR: https://git.openjdk.java.net/jdk/pull/3536

From chagedorn at openjdk.java.net  Mon Apr 19 12:49:46 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 19 Apr 2021 12:49:46 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
Message-ID: <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>

On Fri, 16 Apr 2021 17:41:08 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust whitelist
>
> test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 57:
> 
>> 55:      * @return an inverted boolean of the result of the last invocation of this method.
>> 56:      */
>> 57:     public boolean toggleBoolean() {
> 
> I don't think `toggleBoolean` really belongs to `AbstractInfo`, I'd rather move it into a (separate) aux class.

The problem with having a separate class for it is that we would need to create a new instance somehow in a test and store it in a field to access it in subsequent iterations of a test. On the other hand, one could argue that we do not really need to guarantee that the first invocation of `toggleBoolean()` always returns `false` as the common use-case of this method is just to execute some if-else paths (roughly) equally often (regardless with which one we start) . Then we could also just move the method to `TestFramework::toggleBoolean()` with a static boolean field. We are always only executing a single test at a time, so `toggleBoolean()` reliably returns a different boolean each time it is called in a single test. What do you think?

> test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 47:
> 
>> 45: 
>> 46:     public IRMatcher(String hotspotPidFileName, String irEncoding, Class<?> testClass) {
>> 47:         this.compilations =  new LinkedHashMap<>();
> 
> why do we use LinkedHashMap here (as opposed to HashMap)? I haven't found the place where you need to traverse it in the insertion order.

I think you're right. I first had the linked hash map to keep some sort of ordering for the reported IR rule failures. But in the current version, the compilations would only be sorted by type of test which probably does not add much benefit. I changed it back to `HashMap`.

> test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 116:
> 
>> 114:     private void parseHotspotPidFile() {
>> 115:         Map<Integer, String> compileIdMap = new HashMap<>();
>> 116:         try (BufferedReader br = new BufferedReader(new FileReader(new File(System.getProperty("user.dir") + File.separator + hotspotPidFileName)))) {
> 
> more idiomatic/modern version would be
> Suggestion:
> 
> try (BufferedReader br = Files.newBufferedReader(Paths.get(System.getProperty("user.dir"), hotspotPidFileName))) {
> 
> 
> I actually not sure if you really need `$user.dir`, won't hotspot_pid file get generated in the current dir?

Yes it should. Would this be equivalent to `Paths.get("")`? It seems to work like that.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 107:
> 
>> 105:      */
>> 106:     public static final Set<String> JTREG_WHITELIST_FLAGS = new HashSet<>(
>> 107:             Arrays.asList(
> 
> it doesn't seem to be a comprehensive list of flags that don't affect IR verification work, e.g. different GCs. I think it might be easy to go with the blacklist instead, and possibly warning people if there are any flags in `test.*.opts`.

Maybe first some general background about having a whitelist/blacklist in the first place. When a user writes an `@IR` rule, we do not want him to think about any possible VM flag combination (which he is not specifically using in his test, for example with `addFlags`) that could break his `@IR` rule and then requiring him to restrict the `@IR` rule with `IR::applyIfXX()` for these flags.

I agree that the whitelist is probably not complete and could be improved (but I think we should not whitelist different GCs as these affect the barrier code of the IR). About whitelist vs. blacklist, I had discussions about it with @TobiHartmann. We eventually decided to use a whitelist which seemed easier to maintain and is probably a lot shorter than a blacklist. In addition, if a new flag is introduced or removed, we most likely do not need to worry about updating the whitelist as the (currently) whitelisted flags will most likely remain unchanged. This first whitelist version is also just a best guess solution. We might miss on some other flags that will not affect the IR but we have the confidence that we do not run into surprising failures due to forgetting to blacklist a particular flag. But this is open for discussion of course. It would be interesting to hear how people think about it.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 146:
> 
>> 144:     private List<Class<?>> helperClasses = null;
>> 145:     private List<Scenario> scenarios = null;
>> 146:     private final List<String> flags = new ArrayList<>();
> 
> why did you decide to eagerly create list for `flags`, but not for `scenarios` / `helpersClasses`?

Good catch. I adapted it to also create it lazily.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 166:
> 
>> 164:         if (VERBOSE) {
>> 165:             System.out.println("Test class: " + testClass);
>> 166:         }
> 
> this c-tor can be replaced by:
> Suggestion:
> 
>         this(StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).getCallerClass());
> 
> 
> and actually, I don't see it being used (outside of the tests for this testlibrary) and I don't think it will ever be used by actual tests that would use this framework, so I think we can safely remove it.

I think we should keep it for the cases when a user wants a more specific setup for his tests in the calling test class. For example, if he wants to define a new default warm-up for all of his tests (using `setDefaultWarmup`) or if he needs to combine different options for which there is no `runXX` method (helper classes, scenarios, and/or flags). In this case, he needs to create a `TestFramework()` builder and then call the different builder methods. We could argue that a single constructor is enough in which the test class needs to be specified. But I think most of the time, the user wants to test the calling class for which this additional constructor is quite useful.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 211:
> 
>> 209:     }
>> 210: 
>> 211:     /**
> 
> I'm not sure how much of the benefits all these different `run.*` bring. I fully understand the desire to simplify the most common use-case (i.e. no-arg `run`), but for the rest I'd assume the users will be capable of writing, for example, `new TestFramework(testClass).addScenarios(scenarios).start();` instead of `TestFramework .runWithScenarios(testClass, scenarios);`

I think you are probably right. I added this builder approach later during the development of the framework. It might be better to keep the `TestFramework` interface simple(r). However, I will wait for others to comment on that before changing/removing all of these. 

If we're gonna simplify it, I suggest to keep `run()` and maybe also `runWithFlags()` as (probably?) most common use-case.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 269:
> 
>> 267:      * <ul>
>> 268:      *     <li><p>If a helper class is not in the same file as the test class, make sure that JTreg compiles it by using
>> 269:      *     {@literal @}compile in the JTreg header comment block.</li>
> 
> you don't need `@compile` to compile a helper class, 1st of all, you shouldn't use `@compile` when you want to compile a class in your test, you should use `@build`, 2nd, in this particular case, the class will be automatically built as part of your test b/c jtreg (or rather javac) will be able to statically detect it as a dependency of the code that calls `runWithHelperClasses(Class, Class...)`

Okay, thanks for clearing that up! I removed that comment and related ones.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 407:
> 
>> 405:                 start(null);
>> 406:             } catch (TestVMException e) {
>> 407:                 System.err.println("\n" + e.getExceptionInfo());
> 
> you shouldn't use "\n", as it might not be the right line-separator. you can either do:
> Suggestion:
> 
>                 System.err.println();
>                 System.err.println(e.getExceptionInfo());
> 
> or
> Suggestion:
> 
>                 System.err.printf("%n%s%n", e.getExceptionInfo());

I will address all `\n` in a separate commit as there are a lot of them. Could I also just use `System.lineSeparator()` anywhere where I'm currently using `\n` like  `System.err.println(System.lineSeparator() + e.getExceptionInfo()`)? Might be easier when I'm using `\n` with a `StringBuilder`, for example.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 674:
> 
>> 672:                                    + "Compilation(s) of failed matche(s):");
>> 673:                 System.out.println(irException.getCompilations());
>> 674:                 builder.append(errorMsg).append("\n").append(irException.getExceptionInfo()).append(e.getMessage());
> 
> as `builder.toString` will be printed out to cout/cerr, you should use platform-specific line-separator instead of `\n`

See earlier comment.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 804:
> 
>> 802:             System.err.println("--- OUTPUT TestFramework flag VM ---");
>> 803:             System.err.println(flagVMOutput);
>> 804:             throw new RuntimeException("\nTestFramework flag VM exited with " + exitCode);
> 
> what's the reason for `\n` in the begging of this exception message?

I guess it's not necessary. Removed it.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 958:
> 
>> 956:         throw new TestFrameworkException("Internal Test Framework exception - please file a bug:\n" + failureMessage, e);
>> 957:     }
>> 958: }
> 
> I am not convinced that we really these guys when we already have `TestFormat::check` and `TestRun::check` (I'm actually not 100% convinced that we need check/fail in both TestFormat and TestRun)

I wanted to distinguish the following cases (but I'm open to use a different approach):

- `TestFormat::check` (using `TestFormatException`): The format of any test/helper class does not conform with the format the framework is expecting. The user needs to fix this (for example, using a wrong annotation). I report these kind of failures before actually running any of the tests [here](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L265).
- `TestRun::check` (using `TestRunException`): Thrown while the framework is [executing a test](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L799), there is nothing wrong with the format of a test.
- `TestFramework::check` (using `TestFrameworkException`): If such a check fails there is a bug in the framework itself (like internal framework assertions). The user cannot really do anything about it without fixing the framework itself.

I have to double check again if I'm using the right kind of exception everywhere.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1027:
> 
>> 1025:     }
>> 1026: 
>> 1027:     public static String getRerunHint() {
> 
> why is this a method and not just a public final static String?

Fixed.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1043:
> 
>> 1041:  * Dedicated socket to send data from the flag and test VM back to the driver VM.
>> 1042:  */
>> 1043: class TestFrameworkSocket {
> 
> I guess it should implement AutoClosable, and then you try-catch-finally in `TestFramework::start` could be replaced by `try-w-resource`. 
> 
> btw, I don't the fact that `socket` is a field of `TestFramework` with the lifetime bounded to `start` method.

+1 for `AutoClosable`. I wanted to avoid passing the socket object to all the different methods and thus tried to use the `socket` field like that. I agree that this not nice. Is delegating the socket object from `TestFramework::start` to the different methods the only solution or are there any other recommended ways?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Mon Apr 19 12:49:39 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 19 Apr 2021 12:49:39 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v3]
In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
Message-ID: <lik1BDARDj9-MFobMiQdldzFHX1gh4G6VpsH8tCRaws=.44e14bc9-15dc-4578-a094-7b29220de98d@github.com>

> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 
> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
> 
> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
> 
> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
> 
> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
> 
> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
> 
> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>       - which leaves 4382 lines of code inserted 
> 
> Big thanks to:
> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
> - and others who provided valuable feedback.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:

  Apply review comments in code from Igor I. and Vladimir K.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3508/files
  - new: https://git.openjdk.java.net/jdk/pull/3508/files/7ed789dc..b3f58111

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=01-02

  Stats: 807 lines in 10 files changed: 433 ins; 321 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3508.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Mon Apr 19 12:49:40 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 19 Apr 2021 12:49:40 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
Message-ID: <rz1rhvT_o6WZCGnopgqSKJ-mQrdhjdT86qWPH_Mdqzs=.cd8737fa-0677-4753-a908-ab1dc2a873c3@github.com>

On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust whitelist

Thanks a lot to @iignatev for your careful review and also to @vnkozlov! I will update this PR incrementally regarding the different review comments. I'll start with handling the comments directly in the code. I waited with some of the changes if there is still something open for discussion/follow-up.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Mon Apr 19 12:49:48 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 19 Apr 2021 12:49:48 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <nY--JO_prShpuSOsg52khe6DLSSC_7VZjtcp5unbUgQ=.d8615a76-17d6-4210-9afd-211b4be456d6@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <nY--JO_prShpuSOsg52khe6DLSSC_7VZjtcp5unbUgQ=.d8615a76-17d6-4210-9afd-211b4be456d6@github.com>
Message-ID: <VH2LOvIGjQ_7uewtTaXe7r7UNnAvEVrZF-zcLaYJaDs=.6a8de9d7-8c42-4112-a9e9-4d44ffb08b4d@github.com>

On Thu, 15 Apr 2021 19:02:44 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust whitelist
>
> test/lib/jdk/test/lib/hotspot/ir_framework/README.html line 1:
> 
>> 1: <h1>IR Test Framework</h1>
> 
> Just curious: why HTML instead of markdown?

There is also a `README.md` file in the same folder from which I generated this HTML file from. But as others have suggested, I will remove this html file again and only leave the markdown file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Mon Apr 19 12:49:47 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 19 Apr 2021 12:49:47 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <uPzckD9PeCL-nvTQxAijetsqYo4cx66VvNEFSYAlMMY=.148a5e41-1c45-46c5-aaf1-eaa73686f4e8@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <uPzckD9PeCL-nvTQxAijetsqYo4cx66VvNEFSYAlMMY=.148a5e41-1c45-46c5-aaf1-eaa73686f4e8@github.com>
Message-ID: <eaIxoIKm5q1njHQ1X8CiesciG14_Qyfa688551ASzFc=.0a9d6b28-f7d9-482b-84c0-31f98241da48@github.com>

On Thu, 15 Apr 2021 17:08:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust whitelist
>
> test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 62:
> 
>> 60:      *  </ul>
>> 61:      */
>> 62:     ANY(-2),
> 
> This will change (`-2` -> `-1`) after AOT is removed (8264805).

I'll change that as soon as it is integrated.

> test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 63:
> 
>> 61:      */
>> 62:     ANY(-2),
>> 63:     /**
> 
> For completeness may be add value `NONE(0)` for Interpreter only case.

I agree that it makes sense for completeness. But I'm not sure if this is useful to have as `NONE` would not be supported by the framework for the time being and would just require additional handling, informing the user that this has no effect.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Mon Apr 19 12:49:48 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 19 Apr 2021 12:49:48 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <So18R3zB8dbCvYW50l3Lox7gY3bxsPO6ncST8SurJUc=.c9121fa9-8b70-4b7c-96a7-99090d58f290@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <F0eo7Zs3FqdH33meE7Br0fgSbTfhkCQaBqp4-FXcF6M=.ba0201be-dfbb-49a6-836c-bf0037fd8fdc@github.com>
 <So18R3zB8dbCvYW50l3Lox7gY3bxsPO6ncST8SurJUc=.c9121fa9-8b70-4b7c-96a7-99090d58f290@github.com>
Message-ID: <ZdPVH4X773b1eN9CshE6jeiPP9g0Ai30iHqOVS2Z8x4=.0d63d47b-3e5d-4c24-8612-fe3b61a6ef1c@github.com>

On Fri, 16 Apr 2021 01:10:07 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 367:
>> 
>>> 365: 
>>> 366:         for (Class<?> helperClass : helperClasses) {
>>> 367:             TestRun.check(!this.helperClasses.contains(helperClass), "Cannot add the same class twice: " + helperClass);
>> 
>> won't it be easy to use `Set` to store `helperClasses`?
>
> you might also want to update javadoc for this method to state that there can be duplicates.

Have I understood this correctly that you suggest to just remove this check completely and just specifying in the Javadocs that duplicates are ignore (due to using a `Set`)?

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 639:
>> 
>>> 637:             TestFormat.check(!scenarioIndices.contains(scenarioIndex),
>>> 638:                              "Cannot define two scenarios with the same index " + scenarioIndex);
>>> 639:             scenarioIndices.add(scenarioIndex);
>> 
>> you can use `Set::add` to verify that the element isn't in a set:
>> Suggestion:
>> 
>>             TestFormat.check(scenarioIndices.add(scenarioIndex),
>>                              "Cannot define two scenarios with the same index " + scenarioIndex);
>
> also, shouldn't this check be done as part of `addScenarios`?

Right, I moved it to `addScenarios`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Mon Apr 19 12:52:38 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 19 Apr 2021 12:52:38 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <xxbm1as_hR1VGJ7xG7FRMFDBpPJWYstFiiC8VoCOvSo=.8b7237ef-4bb6-4471-b9c7-404b8f10a6ec@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <xxbm1as_hR1VGJ7xG7FRMFDBpPJWYstFiiC8VoCOvSo=.8b7237ef-4bb6-4471-b9c7-404b8f10a6ec@github.com>
Message-ID: <gxsA__SaOXZ2CYH2QMYVPIRiodtR-_HJv4n3s7VsAOA=.75227295-f0f8-4055-a29a-5d5fd3a28a68@github.com>

On Thu, 15 Apr 2021 17:49:34 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files
> * the same goes for `README.html` generated from `README.md`

Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? 

> * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`.
> * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot`

That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)?

I will do this things in a separate commit and adjust the README.md file accordingly (has links to the Javadoc files).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From erikj at openjdk.java.net  Mon Apr 19 12:55:46 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 19 Apr 2021 12:55:46 GMT
Subject: RFR: 8252600: remove mx configuration [v2]
In-Reply-To: <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com>
References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
 <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com>
Message-ID: <ZppmREZH4ZqEtHwnm9jo7i4Pfo1qwyVYpHMhvSObGEw=.ff5515a8-0ffd-4ed0-a524-cf34f518bd5f@github.com>

On Sun, 18 Apr 2021 20:17:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk.
>
> Doug Simon 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:
> 
>   8252600: [JVMCI] remove mx configuration

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3559

From chagedorn at openjdk.java.net  Mon Apr 19 13:08:35 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 19 Apr 2021 13:08:35 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group
In-Reply-To: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
Message-ID: <C8LwGeCZV-KZJc_gjLPWKgrtWHzZekC5WPVxxoA4qIc=.5cb8ed93-2eb8-43f5-9db1-da1dee5cb52d@github.com>

On Fri, 16 Apr 2021 09:11:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change makes IGV close graph views when their groups are either a) removed or b) emptied (all graphs are removed but the group remains), and avoids faulty graph view computation in case b).
> 
> Tested the following scenarios manually (on groups loaded both via network and from a file, and on JDK 8, 11, and 15):
> 1. open a graph, then remove all graphs in the group (as described in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262725));
> 2. open a graph, then remove its group; and
> 3. open a graph, then remove all graphs and groups (File -> Remove all graphs and groups).

Looks good!

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/EditorTopComponent.java line 236:

> 234:                     closeOnRemovedOrEmptyGroup();
> 235:                 }
> 236:             });

Can be replace with `.addListener(g -> closeOnRemovedOrEmptyGroup())`. Same for below.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3540

From rrich at openjdk.java.net  Mon Apr 19 13:08:35 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 19 Apr 2021 13:08:35 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group
In-Reply-To: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
Message-ID: <P0_2z-1mOCeTNdGV6n2V1o6FA_lux3lqKtkSztOjT7M=.85b3a919-236f-4541-9e51-e6b731ff4921@github.com>

On Fri, 16 Apr 2021 09:11:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change makes IGV close graph views when their groups are either a) removed or b) emptied (all graphs are removed but the group remains), and avoids faulty graph view computation in case b).
> 
> Tested the following scenarios manually (on groups loaded both via network and from a file, and on JDK 8, 11, and 15):
> 1. open a graph, then remove all graphs in the group (as described in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262725));
> 2. open a graph, then remove its group; and
> 3. open a graph, then remove all graphs and groups (File -> Remove all graphs and groups).

Hi Roberto,

thanks for providing the fix. I've built and tested it successfully as described in the bug report [JDK-8262725](https://bugs.openjdk.java.net/browse/JDK-8262725). Your fix seems to solve this issue.

I'm still not able to remove the empty group `virtual void java.lang.Object.<init>()` as additional last step though.
Does this work for you?

Cheers, Richard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3540

From rcastanedalo at openjdk.java.net  Mon Apr 19 13:28:20 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 19 Apr 2021 13:28:20 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group [v2]
In-Reply-To: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
Message-ID: <S1MRhBGCMi1Y4CeUXL6zkDWUsZT4YgYtOz3Cqt2Xmz0=.0bbbfed2-e52d-4741-8fc7-815f2783fb06@github.com>

> This change makes IGV close graph views when their groups are either a) removed or b) emptied (all graphs are removed but the group remains), and avoids faulty graph view computation in case b).
> 
> Tested the following scenarios manually (on groups loaded both via network and from a file, and on JDK 8, 11, and 15):
> 1. open a graph, then remove all graphs in the group (as described in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262725));
> 2. open a graph, then remove its group; and
> 3. open a graph, then remove all graphs and groups (File -> Remove all graphs and groups).

Roberto Casta?eda Lozano 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 three additional commits since the last revision:

 - Simplify listener registration
 - Merge branch 'master' into JDK-8262725
 - Close graph views when their groups are removed or emptied

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3540/files
  - new: https://git.openjdk.java.net/jdk/pull/3540/files/955a01c5..691b51cc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3540&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3540&range=00-01

  Stats: 29523 lines in 962 files changed: 2466 ins; 23481 del; 3576 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3540.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3540/head:pull/3540

PR: https://git.openjdk.java.net/jdk/pull/3540

From rcastanedalo at openjdk.java.net  Mon Apr 19 13:28:21 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 19 Apr 2021 13:28:21 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group [v2]
In-Reply-To: <C8LwGeCZV-KZJc_gjLPWKgrtWHzZekC5WPVxxoA4qIc=.5cb8ed93-2eb8-43f5-9db1-da1dee5cb52d@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
 <C8LwGeCZV-KZJc_gjLPWKgrtWHzZekC5WPVxxoA4qIc=.5cb8ed93-2eb8-43f5-9db1-da1dee5cb52d@github.com>
Message-ID: <KGjfKfCKr-RCJ8zKH0HnKwtdfjogJq8Yhz9RbqKTo6o=.34c0976f-339d-4906-93fc-c8ca3912c5a4@github.com>

On Mon, 19 Apr 2021 13:04:57 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Looks good!

Thanks for reviewing, Christian!

> src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/EditorTopComponent.java line 236:
> 
>> 234:                     closeOnRemovedOrEmptyGroup();
>> 235:                 }
>> 236:             });
> 
> Can be replace with `.addListener(g -> closeOnRemovedOrEmptyGroup())`. Same for below.

Great suggestion, done, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3540

From rcastanedalo at openjdk.java.net  Mon Apr 19 13:34:33 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 19 Apr 2021 13:34:33 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group
In-Reply-To: <P0_2z-1mOCeTNdGV6n2V1o6FA_lux3lqKtkSztOjT7M=.85b3a919-236f-4541-9e51-e6b731ff4921@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
 <P0_2z-1mOCeTNdGV6n2V1o6FA_lux3lqKtkSztOjT7M=.85b3a919-236f-4541-9e51-e6b731ff4921@github.com>
Message-ID: <ONjygfD9W1IuJZcf8yfihHhR-gDPCGyjjak1HnAcVyA=.d2e845c4-ff0d-4b3c-9255-437bb6567c2a@github.com>

On Mon, 19 Apr 2021 13:03:58 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> thanks for providing the fix. I've built and tested it successfully as described in the bug report [JDK-8262725](https://bugs.openjdk.java.net/browse/JDK-8262725). Your fix seems to solve this issue.

Thanks for testing, Richard!

> I'm still not able to remove the empty group `virtual void java.lang.Object.<init>()` as additional last step though.
> Does this work for you?

The preceding fix [8262462](https://github.com/openjdk/jdk/pull/3515) should make this possible, however I see now that it wasn't merged into this PR. I merged it now (04c0b3c), could you please try again?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3540

From rrich at openjdk.java.net  Mon Apr 19 13:56:39 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 19 Apr 2021 13:56:39 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group [v2]
In-Reply-To: <S1MRhBGCMi1Y4CeUXL6zkDWUsZT4YgYtOz3Cqt2Xmz0=.0bbbfed2-e52d-4741-8fc7-815f2783fb06@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
 <S1MRhBGCMi1Y4CeUXL6zkDWUsZT4YgYtOz3Cqt2Xmz0=.0bbbfed2-e52d-4741-8fc7-815f2783fb06@github.com>
Message-ID: <n93N4d35wd5i1lSoa4anqjo5_PdJFLBLDsoqnNknv6w=.598e168b-0b8f-41d0-8419-1d13477d2832@github.com>

On Mon, 19 Apr 2021 13:28:20 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change makes IGV close graph views when their groups are either a) removed or b) emptied (all graphs are removed but the group remains), and avoids faulty graph view computation in case b).
>> 
>> Tested the following scenarios manually (on groups loaded both via network and from a file, and on JDK 8, 11, and 15):
>> 1. open a graph, then remove all graphs in the group (as described in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262725));
>> 2. open a graph, then remove its group; and
>> 3. open a graph, then remove all graphs and groups (File -> Remove all graphs and groups).
>
> Roberto Casta?eda Lozano 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 three additional commits since the last revision:
> 
>  - Simplify listener registration
>  - Merge branch 'master' into JDK-8262725
>  - Close graph views when their groups are removed or emptied

> The preceding fix [8262462](https://github.com/openjdk/jdk/pull/3515) should make this possible, however I see now that it wasn't merged into this PR. I merged it now ([04c0b3c](https://github.com/openjdk/jdk/commit/04c0b3c8ec9896a8e26d72af3461069c5cc5ae91)), could you please try again?

Working nicely now! ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/3540

From rrich at openjdk.java.net  Mon Apr 19 14:00:45 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 19 Apr 2021 14:00:45 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group [v2]
In-Reply-To: <S1MRhBGCMi1Y4CeUXL6zkDWUsZT4YgYtOz3Cqt2Xmz0=.0bbbfed2-e52d-4741-8fc7-815f2783fb06@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
 <S1MRhBGCMi1Y4CeUXL6zkDWUsZT4YgYtOz3Cqt2Xmz0=.0bbbfed2-e52d-4741-8fc7-815f2783fb06@github.com>
Message-ID: <6jO7cUy1aWM5I1qMwdH79aJz4nKKjxTxxfZfZquJybc=.743df27d-1e33-4adb-8e69-fd0a75fb7bb8@github.com>

On Mon, 19 Apr 2021 13:28:20 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change makes IGV close graph views when their groups are either a) removed or b) emptied (all graphs are removed but the group remains), and avoids faulty graph view computation in case b).
>> 
>> Tested the following scenarios manually (on groups loaded both via network and from a file, and on JDK 8, 11, and 15):
>> 1. open a graph, then remove all graphs in the group (as described in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262725));
>> 2. open a graph, then remove its group; and
>> 3. open a graph, then remove all graphs and groups (File -> Remove all graphs and groups).
>
> Roberto Casta?eda Lozano 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 three additional commits since the last revision:
> 
>  - Simplify listener registration
>  - Merge branch 'master' into JDK-8262725
>  - Close graph views when their groups are removed or emptied

I've tested the fix and found it solves the issues.
(Cannot really comment on the change itself as I'm not familiar with igv implementation / netbeans).

Thanks, Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3540

From rcastanedalo at openjdk.java.net  Mon Apr 19 14:07:34 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 19 Apr 2021 14:07:34 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group [v2]
In-Reply-To: <6jO7cUy1aWM5I1qMwdH79aJz4nKKjxTxxfZfZquJybc=.743df27d-1e33-4adb-8e69-fd0a75fb7bb8@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
 <S1MRhBGCMi1Y4CeUXL6zkDWUsZT4YgYtOz3Cqt2Xmz0=.0bbbfed2-e52d-4741-8fc7-815f2783fb06@github.com>
 <6jO7cUy1aWM5I1qMwdH79aJz4nKKjxTxxfZfZquJybc=.743df27d-1e33-4adb-8e69-fd0a75fb7bb8@github.com>
Message-ID: <LmoC3TfM6sxpA_8Tlc_Bwy93HWDV8qWWWaq4YqWFYhA=.718616b5-3da3-44e9-871e-a2ada8775cdf@github.com>

On Mon, 19 Apr 2021 13:58:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I've tested the fix and found it solves the issues.
> (Cannot really comment on the change itself as I'm not familiar with igv implementation / netbeans).
> 
> Thanks, Richard.

Thanks for reviewing, Richard!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3540

From martin.doerr at sap.com  Mon Apr 19 14:32:16 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 19 Apr 2021 14:32:16 +0000
Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error)
 failed: bad dominance
Message-ID: <AM4PR02MB305773DD4F4DC15323E6CDC99A499@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi,

JDK-8261812 is backported to 11.0.12-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8261812

Original change:
https://git.openjdk.java.net/jdk/commit/2c0507ec

Resolution steps:
compile.hpp:
-  push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry,
-                BasicType bt);
+  static bool push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry,
+                            BasicType bt);
This cleanup is not applicable. Skipped.

macro.cpp:
+        if (is_subword_type(ft)) {
+          n = Compile::narrow_value(ft, n, phi_type, &_igvn, true);
+        }
The surrounding code is different in 11u because of GC related changes. I had to adapt it.

11u backport:
http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/

Please review.

Best regards,
Martin


From jiefu at openjdk.java.net  Mon Apr 19 15:10:55 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 19 Apr 2021 15:10:55 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
Message-ID: <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>

> Hi all,
> 
> I'd like to optimize the code-gen for Math.pow(x, 0.5).
> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
> 
> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
> 
> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
> 
> Before:
> 
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> 
> After:
> 
> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
> 
> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
> 
> 
> Testing:
>   - tier1~3 on Linux/x64
> 
> Thanks,
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680

Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Optimize C2
 - Merge branch 'master' into JDK-8264945
 - Revert old changes
 - 8264945: Optimize the code-gen for Math.pow(x, 0.5)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3404/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3404&range=01
  Stats: 75 lines in 2 files changed: 61 ins; 13 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3404/head:pull/3404

PR: https://git.openjdk.java.net/jdk/pull/3404

From jiefu at openjdk.java.net  Mon Apr 19 15:10:55 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 19 Apr 2021 15:10:55 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
In-Reply-To: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
Message-ID: <zLBXiBmT_r3v9_p30SuIlvd-JmnBxs3_z1XyCjSXMgc=.2012b054-ba7e-451f-baec-d5d383eb6147@github.com>

On Fri, 9 Apr 2021 02:19:10 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to optimize the code-gen for Math.pow(x, 0.5).
> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
> 
> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
> 
> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
> 
> Before:
> 
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> 
> After:
> 
> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
> 
> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
> 
> 
> Testing:
>   - tier1~3 on Linux/x64
> 
> Thanks,
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680

Hi all,

This is the follow-up of JDK-8265325, which optimizes the code-gen of C2 for pow(x, 0.5).
Instead of calling into the StubRoutines::dpow(), the compiler can directly generate sqrt for all x >= 0.0.
1.5x ~ 4.2x performance improvement is observed after the opt.

Before

Benchmark                      (seed)   Mode  Cnt       Score       Error   Units
MathBench.powDouble0Dot5Const       0  thrpt    8  203004.302 ?   684.072  ops/ms
MathBench.powDouble0Dot5Loop        0  thrpt    8       0.121 ?     0.001  ops/ms


After

Benchmark                      (seed)   Mode  Cnt       Score      Error   Units
MathBench.powDouble0Dot5Const       0  thrpt    8  308771.237 ? 1604.567  ops/ms   <-- 1.5x
MathBench.powDouble0Dot5Loop        0  thrpt    8       0.508 ?    0.001  ops/ms   <-- 4.2x


Testing:
  tier1 ~ tier3 on Linux/x64

Thanks.
Best regards,
Jie

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From iveresov at openjdk.java.net  Mon Apr 19 15:15:36 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Mon, 19 Apr 2021 15:15:36 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled [v2]
In-Reply-To: <nTmx66kTGCytWWTwqLBsM29XHW3YgvCF0YlHoYWGM2g=.1204b6ad-883d-43a6-8848-bd32002a8943@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
 <nTmx66kTGCytWWTwqLBsM29XHW3YgvCF0YlHoYWGM2g=.1204b6ad-883d-43a6-8848-bd32002a8943@github.com>
Message-ID: <xFizGtSU3F1F6eYpjQ5pQ_5m6EIBXpxZ5ZXdUAdRvmg=.f1766939-3f04-4104-8911-a240c005d00f@github.com>

On Mon, 19 Apr 2021 01:23:06 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

>> On MIPS64 platform has not impliment C1,only has C2.
>>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462
>
> SUN Guoyun 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:
> 
>   8265105: gc/arguments/TestSelectDefaultGC.java fails when compiler1 is disabled

Looks good.

-------------

Marked as reviewed by iveresov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3449

From iignatyev at openjdk.java.net  Mon Apr 19 15:30:40 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 19 Apr 2021 15:30:40 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
Message-ID: <IV0q3C7kZ6BcKeKiocgmxC8a5pH7MSrcW-koSoTdw2g=.65c4f461-ddc6-487f-abf5-1c2e4a1dcfae@github.com>

On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust whitelist

@chhagedorn , I haven't finished reviewing the patch, but I figure it would be better to re-review the patch after you address the prev comments, so I will post the few pending comments I had and will return to review the whole patch after we finish discussing prev. comments.

Cheers,
-- Igor

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 182:

> 180:     private static void appendLine(StringBuilder builder, String line) {
> 181:         if (line.contains("&")) {
> 182:             line = line.replace("&amp;", "&");

although I doubt it will ever be a problem in our use case, yet to be safe this replacement should be the last one, otherwise `&amp;lt;` will become `<` while it should be `&lt;`

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 349:

> 347:             if (matchCount > 0) {
> 348:                 matcher.reset();
> 349:                 failMsg.append("    Regex ").append(nodeId).append(") ").append(nodeRegex).append("\n");

it seems you missed an opening parenthesis after `Regex ` .

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 516:

> 514:      */
> 515:     public void appendIdealOutput(String idealOutput) {
> 516:         outputBuilder.setLength(0);

I doubt that a method named `append.*` should remove the previous values.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Mon Apr 19 15:37:36 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 19 Apr 2021 15:37:36 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <gxsA__SaOXZ2CYH2QMYVPIRiodtR-_HJv4n3s7VsAOA=.75227295-f0f8-4055-a29a-5d5fd3a28a68@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <xxbm1as_hR1VGJ7xG7FRMFDBpPJWYstFiiC8VoCOvSo=.8b7237ef-4bb6-4471-b9c7-404b8f10a6ec@github.com>
 <gxsA__SaOXZ2CYH2QMYVPIRiodtR-_HJv4n3s7VsAOA=.75227295-f0f8-4055-a29a-5d5fd3a28a68@github.com>
Message-ID: <zbToJ5_pj6ysv-TUUD0oYpWacEvz0oUn2_CYDhHcJj4=.58f0dac0-8224-465c-9da0-da7970e91248@github.com>

On Mon, 19 Apr 2021 12:48:26 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files
> > * the same goes for `README.html` generated from `README.md`
> 
> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk?
> 
> > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`.
> > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot`
> 
> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)?

`test/hotspot/jtreg/testlibrary_tests` are seldomly run as part of `:hotspot_misc` test group, yet I don't think it's an issue. the benefit of running testlibrary tests is to gain confidence that the tests which use these libraries are reliable. I'd also disagree that `ir_framework/tests` should be run *only* when the framework is actually, they should also be run when its dependencies are changed, and the framework highly depends on hotspot, so to be sure that the framework didn't get broken after changes in c2, whitebox, etc, you do need run these tests more often.

Thanks,
-- Igor

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Mon Apr 19 17:03:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 19 Apr 2021 17:03:38 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
 <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>
Message-ID: <AwVg7jUJudbQ39WG-b-FyU2CBlp60pHP4O8P0YnSHUs=.07cdb899-a3fd-462e-b2e2-3348cbf73c45@github.com>

On Mon, 19 Apr 2021 11:11:40 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 57:
>> 
>>> 55:      * @return an inverted boolean of the result of the last invocation of this method.
>>> 56:      */
>>> 57:     public boolean toggleBoolean() {
>> 
>> I don't think `toggleBoolean` really belongs to `AbstractInfo`, I'd rather move it into a (separate) aux class.
>
> The problem with having a separate class for it is that we would need to create a new instance somehow in a test and store it in a field to access it in subsequent iterations of a test. On the other hand, one could argue that we do not really need to guarantee that the first invocation of `toggleBoolean()` always returns `false` as the common use-case of this method is just to execute some if-else paths (roughly) equally often (regardless with which one we start) . Then we could also just move the method to `TestFramework::toggleBoolean()` with a static boolean field. We are always only executing a single test at a time, so `toggleBoolean()` reliably returns a different boolean each time it is called in a single test. What do you think?

`TestFramework::toggleBoolean()` sounds like a good alternative.

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 107:
>> 
>>> 105:      */
>>> 106:     public static final Set<String> JTREG_WHITELIST_FLAGS = new HashSet<>(
>>> 107:             Arrays.asList(
>> 
>> it doesn't seem to be a comprehensive list of flags that don't affect IR verification work, e.g. different GCs. I think it might be easy to go with the blacklist instead, and possibly warning people if there are any flags in `test.*.opts`.
>
> Maybe first some general background about having a whitelist/blacklist in the first place. When a user writes an `@IR` rule, we do not want him to think about any possible VM flag combination (which he is not specifically using in his test, for example with `addFlags`) that could break his `@IR` rule and then requiring him to restrict the `@IR` rule with `IR::applyIfXX()` for these flags.
> 
> I agree that the whitelist is probably not complete and could be improved (but I think we should not whitelist different GCs as these affect the barrier code of the IR). About whitelist vs. blacklist, I had discussions about it with @TobiHartmann. We eventually decided to use a whitelist which seemed easier to maintain and is probably a lot shorter than a blacklist. In addition, if a new flag is introduced or removed, we most likely do not need to worry about updating the whitelist as the (currently) whitelisted flags will most likely remain unchanged. This first whitelist version is also just a best guess solution. We might miss on some other flags that will not affect the IR but we have the confidence that we do not run into surprising failures due to forgetting to blacklist a particular flag. But this is open for discussion of course. It would be interesting to hear how people think about it.

I'll need to think about it a bit more, but my first impression after reading your comment is that we don't actually want to allow any flags, so we might better off just using `@requies vm.flagless` or reusing the underlying code to check that we don't have any flags that can "significantly" change behavior.

> But I think most of the time, the user wants to test the calling class for which this additional constructor is quite useful.

I concur that in most cases the users would want to use the caller as a `testClass`, yet we already have `run` and friends to cover that (most common) use-case, users who would need to construct fancier `TestFramework`, most probably, won't be doing it in their `testClass`, and if they would, the overhead of writing `new TestFramework(getClass())` is just 10 keystrokes and is neglatible (given the assumption of a more complicated use case)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Mon Apr 19 17:03:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 19 Apr 2021 17:03:38 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
Message-ID: <XHYhuY1c7iwd5DJULvVBSCpyMRI_AZgJzYD1x0-NML8=.2d892ddb-d593-421d-a7ed-f25e52d884a1@github.com>

On Fri, 16 Apr 2021 02:14:35 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust whitelist
>
> test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 41:
> 
>> 39:  */
>> 40: abstract public class AbstractInfo {
>> 41:     private static final Random random = new Random();
> 
> you shouldn't use Random w/o predefined seed as it might make it harder to reproduce, please consider using `jdk.test.lib.Utils.getRandomInstance` or `jdk.test.lib.RandomFactory.getRandom` here

I've also noticed that you use `Collections::shuffle` in `TestFrameworkExecution` w/o passing a reproducible rng.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From kvn at openjdk.java.net  Mon Apr 19 17:10:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Apr 2021 17:10:39 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block [v2]
In-Reply-To: <ASaeKyQC6TCF_iejF4ky2BvK0OMcn5SALosyYAb1SUw=.bc82c0f0-09c5-4595-b5ce-363b318cd5a0@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <ASaeKyQC6TCF_iejF4ky2BvK0OMcn5SALosyYAb1SUw=.bc82c0f0-09c5-4595-b5ce-363b318cd5a0@github.com>
Message-ID: <FA1PzSEdgXK5esJfbw6eGt_q5K6UQuURTyThMWB366U=.4be4db0f-b7a8-4df8-95de-0464045cff80@github.com>

On Mon, 12 Apr 2021 08:37:18 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
>> 
>> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
>> 
>> Tested on:
>> - original bug reproducer
>> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
>> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Complete projection assertions with basic checks
>  - Enforce code style in surrounding 'for' statements
>  - Simplify loop that removes dead projections, rename and comment for clarity
>  - Assert that projections are stuck to their parents

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3303

From kvn at openjdk.java.net  Mon Apr 19 17:24:35 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Apr 2021 17:24:35 GMT
Subject: RFR: 8252600: remove mx configuration [v2]
In-Reply-To: <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com>
References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
 <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com>
Message-ID: <2840qz4etikwMFvVnTMvthHrn-2dfmqWCFwI5Sb3nnY=.6ab2e3b6-da00-4614-9be3-b5d76c7ff9d4@github.com>

On Sun, 18 Apr 2021 20:17:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk.
>
> Doug Simon 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:
> 
>   8252600: [JVMCI] remove mx configuration

The PR is missing `[JVMCI] ` in title to match RFE title. Otherwise it is good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3559

From kvn at openjdk.java.net  Mon Apr 19 17:29:37 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Apr 2021 17:29:37 GMT
Subject: RFR: 8265322: C2: Simplify control inputs for
 BarrierSetC2::obj_allocate
In-Reply-To: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
References: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
Message-ID: <cj-4QRaigsBPew_jBiuDMO4E9TdXXL1TUH9KZg5Oi-g=.1cb90d4f-6a1b-48aa-b731-4cab4a2681df@github.com>

On Fri, 16 Apr 2021 03:06:19 GMT, Yi Yang <yyang at openjdk.org> wrote:

> While just using BarrierSetC2::obj_allocate in https://github.com/openjdk/valhalla/pull/385, I noticed the control input `ctrl` for obj_allocate is not so much necessary. This PR simplifies control inputs for BarrierSetC2::obj_allocate. In most cases, it doesn't change anything since `toobig_false` is equivalent to `ctrl`. In other cases, `toobig_false` is created for Unsafe.allocateInstance while instance size is not statically known, `ctrl` would become control input of IfNode whose projects are `toobig_false` and `toobig_true`, old eden_end and old_eden_top can simply accept `toobig_false` as their control input rather than `ctrl`.

> > From compiler code POV the fix is reasonable and correct.
> Do you think it's reasonable to move PhaseMacroExpand::set_eden_pointers to BarrierSetC2? It seems that that's GC knowledge area about how to set eden_top/eden_end w or w/o turning UseTLAB.

It is up to GC group but it is common code for all GCs. As I understand BarrierSetC2 is used for GC variations code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3529

From dnsimon at openjdk.java.net  Mon Apr 19 17:47:48 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 19 Apr 2021 17:47:48 GMT
Subject: Integrated: 8252600: [JVMCI] remove mx configuration
In-Reply-To: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
Message-ID: <pqLN16Udif8x9a0BFENND8Wwg0op2t3wAu6CTKQRuVU=.59c3f328-9404-4033-84c3-ea6f007a0358@github.com>

On Sat, 17 Apr 2021 20:37:08 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk.

This pull request has now been integrated.

Changeset: 54cb388d
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/54cb388d
Stats:     1346 lines in 7 files changed: 0 ins; 1346 del; 0 mod

8252600: [JVMCI] remove mx configuration

Reviewed-by: erikj, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3559

From dnsimon at openjdk.java.net  Mon Apr 19 17:47:48 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 19 Apr 2021 17:47:48 GMT
Subject: RFR: 8252600: [JVMCI] remove mx configuration
In-Reply-To: <zETCprW0FmODJclHlZ0s1GessBhPtQ7O_FIwHW1C6wE=.c7c73a99-d7b1-4572-af9c-0e1164ebd522@github.com>
References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com>
 <zETCprW0FmODJclHlZ0s1GessBhPtQ7O_FIwHW1C6wE=.c7c73a99-d7b1-4572-af9c-0e1164ebd522@github.com>
Message-ID: <T9cCt6Bq-UWaKU0ZDWFoWeBNb0yp4_gAhDn7MJcPcCg=.0e80c0ef-3701-49b4-8e7c-f390d162e0b5@github.com>

On Sun, 18 Apr 2021 07:32:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk.
>
> Are you sure it make sense to have this dev config in the openjdk/jdk repo? I would think this is something for the downstream Graal repos.

Thanks @AlanBateman , @erikj79 and @vnkozlov for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3559

From dcubed at openjdk.java.net  Mon Apr 19 18:06:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 19 Apr 2021 18:06:31 GMT
Subject: RFR: 8265463: ProblemList
 vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on
 Win-X64 -Xcomp
Message-ID: <mUZ9FpUEX3DMDI7FVgZWXmF4IB3C6x96NN9NFJneLIg=.007e1f5f-238e-4ba4-868f-34e0782354a9@github.com>

A couple of trivial fixes to ProblemList a couple of tests in -Xcomp configs:

- JDK-8265463 ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp
- JDK-8265464 ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs

-------------

Commit messages:
 - 8265464: ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs
 - 8265463: ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp

Changes: https://git.openjdk.java.net/jdk/pull/3575/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3575&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265463
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3575/head:pull/3575

PR: https://git.openjdk.java.net/jdk/pull/3575

From mikael at openjdk.java.net  Mon Apr 19 18:41:07 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Mon, 19 Apr 2021 18:41:07 GMT
Subject: RFR: 8265463: ProblemList
 vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on
 Win-X64 -Xcomp
In-Reply-To: <mUZ9FpUEX3DMDI7FVgZWXmF4IB3C6x96NN9NFJneLIg=.007e1f5f-238e-4ba4-868f-34e0782354a9@github.com>
References: <mUZ9FpUEX3DMDI7FVgZWXmF4IB3C6x96NN9NFJneLIg=.007e1f5f-238e-4ba4-868f-34e0782354a9@github.com>
Message-ID: <5twxFUikmLcAtUEypKZbYMUmg89n6cmLz5i7KSoiB9s=.adbdff2b-df25-4ae6-be6a-6d0419a7be57@github.com>

On Mon, 19 Apr 2021 17:52:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A couple of trivial fixes to ProblemList a couple of tests in -Xcomp configs:
> 
> - JDK-8265463 ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp
> - JDK-8265464 ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3575

From dcubed at openjdk.java.net  Mon Apr 19 18:54:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 19 Apr 2021 18:54:04 GMT
Subject: RFR: 8265463: ProblemList
 vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on
 Win-X64 -Xcomp
In-Reply-To: <5twxFUikmLcAtUEypKZbYMUmg89n6cmLz5i7KSoiB9s=.adbdff2b-df25-4ae6-be6a-6d0419a7be57@github.com>
References: <mUZ9FpUEX3DMDI7FVgZWXmF4IB3C6x96NN9NFJneLIg=.007e1f5f-238e-4ba4-868f-34e0782354a9@github.com>
 <5twxFUikmLcAtUEypKZbYMUmg89n6cmLz5i7KSoiB9s=.adbdff2b-df25-4ae6-be6a-6d0419a7be57@github.com>
Message-ID: <DJ7fO7EeI12yzq5SQnkzPCrSG3d9h0oLzF7RZc7M2G0=.355d5b33-29c2-4788-9dfb-752e20ebba8b@github.com>

On Mon, 19 Apr 2021 18:38:40 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A couple of trivial fixes to ProblemList a couple of tests in -Xcomp configs:
>> 
>> - JDK-8265463 ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp
>> - JDK-8265464 ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3575

From dcubed at openjdk.java.net  Mon Apr 19 18:54:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 19 Apr 2021 18:54:05 GMT
Subject: Integrated: 8265463: ProblemList
 vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on
 Win-X64 -Xcomp
In-Reply-To: <mUZ9FpUEX3DMDI7FVgZWXmF4IB3C6x96NN9NFJneLIg=.007e1f5f-238e-4ba4-868f-34e0782354a9@github.com>
References: <mUZ9FpUEX3DMDI7FVgZWXmF4IB3C6x96NN9NFJneLIg=.007e1f5f-238e-4ba4-868f-34e0782354a9@github.com>
Message-ID: <rASnh_yPidk2NeN0YU9q4zdkynOMnEkBMTBPCddmmgI=.5bd5d561-3f29-4dea-bb28-692143b740c1@github.com>

On Mon, 19 Apr 2021 17:52:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A couple of trivial fixes to ProblemList a couple of tests in -Xcomp configs:
> 
> - JDK-8265463 ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp
> - JDK-8265464 ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs

This pull request has now been integrated.

Changeset: 39907136
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/39907136
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8265463: ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp
8265464: ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs

Reviewed-by: mikael

-------------

PR: https://git.openjdk.java.net/jdk/pull/3575

From kvn at openjdk.java.net  Mon Apr 19 19:15:06 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Apr 2021 19:15:06 GMT
Subject: RFR: 8265403: consolidate definition of CPU features [v3]
In-Reply-To: <T6VZEMXGmqJ3XlqqiIohHu8-nT2PPMFvlm6YN_JP_XU=.196aa39a-8d70-4666-a086-aeed22b7325a@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
 <T6VZEMXGmqJ3XlqqiIohHu8-nT2PPMFvlm6YN_JP_XU=.196aa39a-8d70-4666-a086-aeed22b7325a@github.com>
Message-ID: <EwDafgW1t0kBzLZH42vcm_YwGO2ar7yRcv0cAsb3DO0=.9c49ce7c-f21c-43d1-9327-0e39110006e0@github.com>

On Mon, 19 Apr 2021 09:46:17 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries.
>> 
>> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition.
>
> Doug Simon 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:
> 
>   avoid use of a lambda in JVMCI initialization

Please, update copyright years in files you touched.

src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 118:

> 116:     decl(STXR_PREFETCH, "stxr_prefetch", 29)  \
> 117:     decl(A53MAC,        "a53mac",        30)
> 118: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (1 << bit),

Add empty line before to separate `CPU_FEATURE_FLAGS` macro.

src/hotspot/cpu/x86/vmStructs_x86.hpp line 45:

> 43: 
> 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id)
> 45: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT)

Do we need to keep `VM_LONG_CONSTANTS_CPU` after you removed its body here and in vmStructs_jvmci.cpp?

What about `VM_INT_CONSTANTS_CPU` here? vmStructs_jvmci.cpp duplicates it.

src/hotspot/cpu/x86/vm_version_x86.hpp line 363:

> 361:     decl(AVX512_VBMI,       "avx512_vbmi",       45) /* Vector BMI instructions */ \
> 362:     decl(HV,                "hv",                46) /* Hypervisor instructions */
> 363: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (1ULL << bit),

Add empty line before it to separate `CPU_FEATURE_FLAGS` macro more clear.

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 753:

> 751: 
> 752: #define DECLARE_INT_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_INT_CONSTANT_ENTRY(VM_Version::CPU_##id)
> 753: #define VM_INT_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_INT_CPU_FEATURE_CONSTANT)

Missing `#undef DECLARE_INT_CPU_FEATURE_CONSTANT`.

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 769:

> 767: 
> 768: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id)
> 769: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT)

Missing `#undef DECLARE_LONG_CPU_FEATURE_CONSTANT`.

src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 66:

> 64:             long bitMask = e.getValue();
> 65:             String key = e.getKey();
> 66:             if (key.startsWith("VM_Version::CPU_")) {

As I understand this code, it goes over `constants` values passed from VM and Trying to map them to `enumType`. It catches cases when a value is missing in `enumType`. What about case when `enumType` has `extra` value which is not defined in `constants`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3558

From dnsimon at openjdk.java.net  Mon Apr 19 19:38:08 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 19 Apr 2021 19:38:08 GMT
Subject: RFR: 8265403: consolidate definition of CPU features [v3]
In-Reply-To: <EwDafgW1t0kBzLZH42vcm_YwGO2ar7yRcv0cAsb3DO0=.9c49ce7c-f21c-43d1-9327-0e39110006e0@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
 <T6VZEMXGmqJ3XlqqiIohHu8-nT2PPMFvlm6YN_JP_XU=.196aa39a-8d70-4666-a086-aeed22b7325a@github.com>
 <EwDafgW1t0kBzLZH42vcm_YwGO2ar7yRcv0cAsb3DO0=.9c49ce7c-f21c-43d1-9327-0e39110006e0@github.com>
Message-ID: <SF2pVAhPzsugvNVSFkHHCr4ziWj0EQJwof-p6DNlAiE=.ed87d866-dd3d-471f-8226-369e849128a7@github.com>

On Mon, 19 Apr 2021 18:57:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Doug Simon 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:
>> 
>>   avoid use of a lambda in JVMCI initialization
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 118:
> 
>> 116:     decl(STXR_PREFETCH, "stxr_prefetch", 29)  \
>> 117:     decl(A53MAC,        "a53mac",        30)
>> 118: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (1 << bit),
> 
> Add empty line before to separate `CPU_FEATURE_FLAGS` macro.

Ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3558

From dnsimon at openjdk.java.net  Mon Apr 19 19:42:05 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 19 Apr 2021 19:42:05 GMT
Subject: RFR: 8265403: consolidate definition of CPU features [v3]
In-Reply-To: <EwDafgW1t0kBzLZH42vcm_YwGO2ar7yRcv0cAsb3DO0=.9c49ce7c-f21c-43d1-9327-0e39110006e0@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
 <T6VZEMXGmqJ3XlqqiIohHu8-nT2PPMFvlm6YN_JP_XU=.196aa39a-8d70-4666-a086-aeed22b7325a@github.com>
 <EwDafgW1t0kBzLZH42vcm_YwGO2ar7yRcv0cAsb3DO0=.9c49ce7c-f21c-43d1-9327-0e39110006e0@github.com>
Message-ID: <EksASFe-ENVewPLMYgl-j-wwDmBciQBvqyoKNcyp57I=.cf1ef55f-91b5-41a7-bc50-ee129085af1d@github.com>

On Mon, 19 Apr 2021 18:58:46 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Doug Simon 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:
>> 
>>   avoid use of a lambda in JVMCI initialization
>
> src/hotspot/cpu/x86/vmStructs_x86.hpp line 45:
> 
>> 43: 
>> 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id)
>> 45: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT)
> 
> Do we need to keep `VM_LONG_CONSTANTS_CPU` after you removed its body here and in vmStructs_jvmci.cpp?
> 
> What about `VM_INT_CONSTANTS_CPU` here? vmStructs_jvmci.cpp duplicates it.

`vmStructs.cpp` and `vmStructs_jvmci.cpp` are disjoint. This file (i.e. `vmStructs_x86.hpp`) is only used by `vmStructs.cpp`.
`vmStructs.cpp` expects all macros such as `VM_LONG_CONSTANTS_CPU` to be defined.
`vmStructs_jvmci.cpp` will provide a dummy definition for missing macros.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3558

From kvn at openjdk.java.net  Mon Apr 19 19:44:11 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Apr 2021 19:44:11 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
Message-ID: <NxPI1oa4YKWRc1DT9woPeBtMYKWbXQFi5iS7fqpzM14=.d7877d50-e915-4eb8-ac93-1107d534b286@github.com>

On Mon, 19 Apr 2021 15:10:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> I'd like to optimize the code-gen for Math.pow(x, 0.5).
>> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
>> 
>> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
>> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
>> 
>> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
>> 
>> Before:
>> 
>> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
>> 
>> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
>> 
>> 
>> After:
>> 
>> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
>> 
>> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
>> 
>> 
>> Testing:
>>   - tier1~3 on Linux/x64
>> 
>> Thanks,
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680
>
> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Optimize C2
>  - Merge branch 'master' into JDK-8264945
>  - Revert old changes
>  - 8264945: Optimize the code-gen for Math.pow(x, 0.5)

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3404

From dnsimon at openjdk.java.net  Mon Apr 19 19:49:07 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 19 Apr 2021 19:49:07 GMT
Subject: RFR: 8265403: consolidate definition of CPU features [v3]
In-Reply-To: <EwDafgW1t0kBzLZH42vcm_YwGO2ar7yRcv0cAsb3DO0=.9c49ce7c-f21c-43d1-9327-0e39110006e0@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
 <T6VZEMXGmqJ3XlqqiIohHu8-nT2PPMFvlm6YN_JP_XU=.196aa39a-8d70-4666-a086-aeed22b7325a@github.com>
 <EwDafgW1t0kBzLZH42vcm_YwGO2ar7yRcv0cAsb3DO0=.9c49ce7c-f21c-43d1-9327-0e39110006e0@github.com>
Message-ID: <czinHkykzw84zSry6R6NV76PTUQqxpRW5I_GvNqESwk=.8262581e-9fe3-4073-aaf1-9b1b67f166e5@github.com>

On Mon, 19 Apr 2021 19:00:09 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Doug Simon 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:
>> 
>>   avoid use of a lambda in JVMCI initialization
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 753:
> 
>> 751: 
>> 752: #define DECLARE_INT_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_INT_CONSTANT_ENTRY(VM_Version::CPU_##id)
>> 753: #define VM_INT_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_INT_CPU_FEATURE_CONSTANT)
> 
> Missing `#undef DECLARE_INT_CPU_FEATURE_CONSTANT`.

No, it must stay defined up to the point `VM_INT_CPU_FEATURE_CONSTANTS` is used. Since this is a `.cpp` file, it's ok to leave it defined.

> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 769:
> 
>> 767: 
>> 768: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id)
>> 769: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT)
> 
> Missing `#undef DECLARE_LONG_CPU_FEATURE_CONSTANT`.

So comment as for `DECLARE_INT_CPU_FEATURE_CONSTANT`.

> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 66:
> 
>> 64:             long bitMask = e.getValue();
>> 65:             String key = e.getKey();
>> 66:             if (key.startsWith("VM_Version::CPU_")) {
> 
> As I understand this code, it goes over `constants` values passed from VM and Trying to map them to `enumType`. It catches cases when a value is missing in `enumType`. What about case when `enumType` has `extra` value which is not defined in `constants`?

We could warn about that but cannot remove it without breaking backwards capability for JVMCI wrt Graal. Such a deleted capability will simply be seen as "not supported" by Graal.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3558

From dnsimon at openjdk.java.net  Mon Apr 19 19:56:45 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 19 Apr 2021 19:56:45 GMT
Subject: RFR: 8265403: consolidate definition of CPU features [v4]
In-Reply-To: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
Message-ID: <m6VDuNFc5zRwM0hhuY_c85jxk_wVgXaZm9DwoxGU1po=.90d96d09-7560-4edc-bcf2-f562fc33f389@github.com>

> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries.
> 
> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition.

Doug Simon has updated the pull request incrementally with two additional commits since the last revision:

 - updated date in copyright
 - added blank lines after macros

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3558/files
  - new: https://git.openjdk.java.net/jdk/pull/3558/files/124019d7..c6be1437

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=02-03

  Stats: 11 lines in 10 files changed: 2 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3558.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3558/head:pull/3558

PR: https://git.openjdk.java.net/jdk/pull/3558

From kvn at openjdk.java.net  Mon Apr 19 19:58:07 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Apr 2021 19:58:07 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
Message-ID: <K74RAdzf2HPkqiw2Puv2fWJPs4k6wCxOLZAd78OmK6o=.7c000915-9e9c-4f72-a230-dcf0e3c808d1@github.com>

On Fri, 16 Apr 2021 01:40:01 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * I optimize `max` and `min` by using these identities 
>>     - op (max(a,b) , min(a,b))=== op(a,b)
>>     - if op is commutable
>>     - example : 
>>       - max(a,b) + min(a,b))=== a + b // op = add
>>       - max(a,b) * min(a,b))=== a * b  // op = mul
>>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
>> * Test case 
>>   ```java
>>   /*
>>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>    *
>>    * This code is free software; you can redistribute it and/or modify it
>>    * under the terms of the GNU General Public License version 2 only, as
>>    * published by the Free Software Foundation.
>>    *
>>    * This code is distributed in the hope that it will be useful, but WITHOUT
>>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>    * version 2 for more details (a copy is included in the LICENSE file that
>>    * accompanied this code).
>>    *
>>    * You should have received a copy of the GNU General Public License version
>>    * 2 along with this work; if not, write to the Free Software Foundation,
>>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>    *
>>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>    * or visit www.oracle.com if you need additional information or have any
>>    * questions.
>>    */
>>   package org.sample;
>>   
>>   import org.openjdk.jmh.annotations.Benchmark;
>>   import org.openjdk.jmh.annotations.*;
>>   
>>   import java.util.Random;
>>   import java.util.concurrent.TimeUnit;
>>   import org.openjdk.jmh.infra.Blackhole;
>>   
>>   @BenchmarkMode({Mode.AverageTime})
>>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>>   public class MyBenchmark {
>>   
>>       static int length = 100000;
>>       static double[] data1 = new double[length];
>>       static double[] data2 = new double[length];
>>       static Random random = new Random();
>>   
>>       static {
>>           for(int i = 0; i < length; ++i) {
>>             data1[i] = random.nextDouble();
>>             data2[i] = random.nextDouble();
>>           }
>>       }
>>   
>>       @Benchmark
>>       public void testAdd(Blackhole bh) {
>>         double sum = 0;
>>         for (int i = 0; i < length; i++) {
>>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>>         }
>>         bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMax(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMin(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMul(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   }
>>   ```
>> 
>> *  The result is listed here (aarch64):
>> 
>>   before:
>> 
>>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>>  
>>   after:
>> 
>>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |
>> 
>> *  I have tested `NaN`  ` INFINITY` and `-INFINITY` and got same result (before/after)
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust code style

Thank you for answers.
The test should be part of changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From kvn at openjdk.java.net  Mon Apr 19 20:05:06 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Apr 2021 20:05:06 GMT
Subject: RFR: 8265403: consolidate definition of CPU features [v3]
In-Reply-To: <EksASFe-ENVewPLMYgl-j-wwDmBciQBvqyoKNcyp57I=.cf1ef55f-91b5-41a7-bc50-ee129085af1d@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
 <T6VZEMXGmqJ3XlqqiIohHu8-nT2PPMFvlm6YN_JP_XU=.196aa39a-8d70-4666-a086-aeed22b7325a@github.com>
 <EwDafgW1t0kBzLZH42vcm_YwGO2ar7yRcv0cAsb3DO0=.9c49ce7c-f21c-43d1-9327-0e39110006e0@github.com>
 <EksASFe-ENVewPLMYgl-j-wwDmBciQBvqyoKNcyp57I=.cf1ef55f-91b5-41a7-bc50-ee129085af1d@github.com>
Message-ID: <jP5J8AGulCWkSwmJdjp6x5dPkzowT9qKIQthJoPftvs=.947f01bc-6945-4233-afb8-e191ff727097@github.com>

On Mon, 19 Apr 2021 19:38:52 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vmStructs_x86.hpp line 45:
>> 
>>> 43: 
>>> 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id)
>>> 45: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT)
>> 
>> Do we need to keep `VM_LONG_CONSTANTS_CPU` after you removed its body here and in vmStructs_jvmci.cpp?
>> 
>> What about `VM_INT_CONSTANTS_CPU` here? vmStructs_jvmci.cpp duplicates it.
>
> `vmStructs.cpp` and `vmStructs_jvmci.cpp` are disjoint. This file (i.e. `vmStructs_x86.hpp`) is only used by `vmStructs.cpp`.
> `vmStructs.cpp` expects all macros such as `VM_LONG_CONSTANTS_CPU` to be defined.
> `vmStructs_jvmci.cpp` will provide a dummy definition for missing macros.

Got it. Even so they are empty everywhere :(

>> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 753:
>> 
>>> 751: 
>>> 752: #define DECLARE_INT_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_INT_CONSTANT_ENTRY(VM_Version::CPU_##id)
>>> 753: #define VM_INT_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_INT_CPU_FEATURE_CONSTANT)
>> 
>> Missing `#undef DECLARE_INT_CPU_FEATURE_CONSTANT`.
>
> No, it must stay defined up to the point `VM_INT_CPU_FEATURE_CONSTANTS` is used. Since this is a `.cpp` file, it's ok to leave it defined.

I see.

>> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 66:
>> 
>>> 64:             long bitMask = e.getValue();
>>> 65:             String key = e.getKey();
>>> 66:             if (key.startsWith("VM_Version::CPU_")) {
>> 
>> As I understand this code, it goes over `constants` values passed from VM and Trying to map them to `enumType`. It catches cases when a value is missing in `enumType`. What about case when `enumType` has `extra` value which is not defined in `constants`?
>
> We could warn about that but cannot remove it without breaking backwards capability for JVMCI wrt Graal. Such a deleted capability will simply be seen as "not supported" by Graal.

Okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3558

From kvn at openjdk.java.net  Mon Apr 19 20:05:05 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Apr 2021 20:05:05 GMT
Subject: RFR: 8265403: consolidate definition of CPU features [v4]
In-Reply-To: <m6VDuNFc5zRwM0hhuY_c85jxk_wVgXaZm9DwoxGU1po=.90d96d09-7560-4edc-bcf2-f562fc33f389@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
 <m6VDuNFc5zRwM0hhuY_c85jxk_wVgXaZm9DwoxGU1po=.90d96d09-7560-4edc-bcf2-f562fc33f389@github.com>
Message-ID: <X-_pAMWn-uIzh0Kg9wTWTrfUsSXifrx01UfnSER_HJk=.4615f8f5-c004-480e-b0eb-5999961c523c@github.com>

On Mon, 19 Apr 2021 19:56:45 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries.
>> 
>> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated date in copyright
>  - added blank lines after macros

You need review from Runtime group too.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3558

From dholmes at openjdk.java.net  Mon Apr 19 21:47:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 19 Apr 2021 21:47:25 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and
 callers
Message-ID: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>

If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.

In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.

This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 

Testing: tiers 1-3

Thanks,
David

-------------

Commit messages:
 - 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers

Changes: https://git.openjdk.java.net/jdk/pull/3580/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265484
  Stats: 44 lines in 4 files changed: 16 ins; 11 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3580.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3580/head:pull/3580

PR: https://git.openjdk.java.net/jdk/pull/3580

From github.com+2249648+johntortugo at openjdk.java.net  Mon Apr 19 21:57:10 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Mon, 19 Apr 2021 21:57:10 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v3]
In-Reply-To: <lik1BDARDj9-MFobMiQdldzFHX1gh4G6VpsH8tCRaws=.44e14bc9-15dc-4578-a094-7b29220de98d@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <lik1BDARDj9-MFobMiQdldzFHX1gh4G6VpsH8tCRaws=.44e14bc9-15dc-4578-a094-7b29220de98d@github.com>
Message-ID: <srlwPPnPzJTwIzio8e0EWsW1uqwUltW3WxZTFdPHKMo=.de1456b6-7b9a-41a7-945f-3fa4a52563b7@github.com>

On Mon, 19 Apr 2021 12:49:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review comments in code from Igor I. and Vladimir K.

test/lib/jdk/test/lib/hotspot/ir_framework/IRMethod.java line 32:

> 30:  */
> 31: class IRMethod {
> 32:     final private Method method;

The order of these keywords seems to be inverted.

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 43:

> 41: The simplest form of testing provides a single `@Test` annotated method which the framework will invoke as part of the testing. The test method has no or well-defined arguments that the framework can automatically provide. 
> 42: 
> 43: More information on base tasts with a precise definition can be found in the [Javadocs](./doc/jdk/test/lib/hotspot/ir_framework/Test.html). Concrete examples on how to specify a base test can be found in [BaseTestsExample](./examples/BaseTestExample.java).

"tasts"

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 48:

> 46: The base tests do not provide any way of verification by user code. A checked test enabled that by allowing the user to define an additional `@Check` annotated method which is invoked directly after the `@Test` annotated method. This allows the user to perform various checks about the test method including return value verification.
> 47: 
> 48: More information on checked tasts with a precise definition can be found in the [Javadocs](./doc/jdk/test/lib/hotspot/ir_framework/Check.html). Concrete examples on how to specify a checked test can be found in [CheckedTestsExample](./examples/CheckedTestExample.java).

Typo "tasts"

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 53:

> 51: Neither the base nor the checked tests provide any control over how a `@Test` annotated method is invoked in terms of customized argument values and/or conditions for the invocation itself. A custom run test gives full control over the invocation of the `@Test` annotated method to the user. The framework calls a dedicated `@Run` annotated method from which the user can invoke the `@Test` method according to his/her needs.
> 52: 
> 53: More information on checked tasts with a precise definition can be found in the [Javadocs](./doc/jdk/test/lib/hotspot/ir_framework/Run.html). Concrete examples on how to specify a custom run test can be found in [CustomRunTestsExample](./examples/CustomRunTestExample.java).

Typo: "tasts" -> "tests".

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 74:

> 72: 
> 73: ### 2.3 Test VM Flags and Scenarios
> 74: The recommended way to use the framework is by using defining single `@run driver` statement in the JTreg header which, however, does not allow the specification of additional test VM flags. Instead, the user has the possibility to provide VM flags by calling `TestFramework.runWithFlags()` or by creating a `TestFramework` builder object on which `addFlags()` can be called.

Typo: missing article or duplicated words? "is by using defining single"

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 110:

> 108: 
> 109: The framework will spawn a new "test VM" to execute the user defined tests. The test VM collects all tests of the test class specified by the user code in `main()` and ensures that there is no violation of the required format by the framework. In a next step, the framework does the following for each test in general:
> 110: 1. Warm the test up for a predefined number of times (default 2000). This can also be adapted for all tests by using `testFrameworkobject.setDefaultWarmup(100)` or for individual tests with an additional [@Warmup](./doc/jdk/test/lib/hotspot/ir_framework/Warmup.html) annotation. 

The previous section seems to indicate that the default number of warm-up iterations is 200. "-Dwarmup=200".

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 112:

> 110: 1. Warm the test up for a predefined number of times (default 2000). This can also be adapted for all tests by using `testFrameworkobject.setDefaultWarmup(100)` or for individual tests with an additional [@Warmup](./doc/jdk/test/lib/hotspot/ir_framework/Warmup.html) annotation. 
> 111: 2. After the warm-up is finished, the framework compiles the associated `@Test` annotated method at the specified compilation level (default: C2).
> 112: 3. After the compilation, the test is invokes one more time.

Typoe: "invokes" -> "invoked".

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 116:

> 114: Once the test VM terminates, IR verification (if possible) is performed on the output of the test VM. If any test throws an exception during its execution or if IR matching fails, the failures are collected and reported in a pretty format. Check the standard error and output for more information and how to reproduce these failures.
> 115: 
> 116: Some of the steps above can be different due to the kind of the test or due to using non-default annotation properties. These details and differences are discribed in the Javadocs for the three tests (see section 2.1 Different Tests).

Typo: "discribed" -> "described".

test/lib/jdk/test/lib/hotspot/ir_framework/examples/BaseTestExample.java line 65:

> 63: 
> 64:     public static void main(String[] args) {
> 65:         TestFramework.run(); // equivalent to TestFramework.run(TestSimpleTest.class)

Did you mean same as `TestFramework.run(BaseTestExample.class)` ?

test/lib/jdk/test/lib/hotspot/ir_framework/examples/CheckedTestExample.java line 72:

> 70: 
> 71:     public static void main(String[] args) {
> 72:         TestFramework.run(); // equivalent to TestFramework.run(TestSimpleTest.class)

Did you mean same as `TestFramework.run(CheckedTestExample.class)` ?

test/lib/jdk/test/lib/hotspot/ir_framework/examples/CustomRunTestExample.java line 80:

> 78: 
> 79:     public static void main(String[] args) {
> 80:         TestFramework.run(); // equivalent to TestFramework.run(TestSimpleTest.class)

Did you mean same as `TestFramework.run(CustomRunTestExample.class)` ?

test/lib/jdk/test/lib/hotspot/ir_framework/examples/IRExample.java line 145:

> 143:     @IR(failOn = {IRNode.STORE, IRNode.LOOP}) // LOOP regex not found but STORE regex, letting the rule fail
> 144:     @IR(failOn = {IRNode.LOOP, IRNode.STORE}) // Order does not matter
> 145:     @IR(failOn = {IRNode.STORE, IRNode.LOAD}) // LOOP and STORE regex, letting the rule fail

LOOP regex?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Mon Apr 19 23:27:09 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 19 Apr 2021 23:27:09 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
 <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>
Message-ID: <GEZVvInDaECSTt-cU4xWTLNX2zE8aRJ7yTxj9f71Ne8=.c40c58ee-d22c-4ede-a405-0747ff527bff@github.com>

On Mon, 19 Apr 2021 09:23:10 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> I suggest to keep run() and maybe also runWithFlags() as (probably?) most common use-case.

I guess you are right, `run()` and `runWithFlags(String[])` will be most-commonly used ones.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Mon Apr 19 23:36:15 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 19 Apr 2021 23:36:15 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
 <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>
Message-ID: <c_Gy-xZEmiAnSxqbPNoVvU-mN4iNVJfnWKcV4M2XPtc=.02947e83-47bd-46c3-ab16-8d6fe4f36fe1@github.com>

On Mon, 19 Apr 2021 09:42:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 407:
>> 
>>> 405:                 start(null);
>>> 406:             } catch (TestVMException e) {
>>> 407:                 System.err.println("\n" + e.getExceptionInfo());
>> 
>> you shouldn't use "\n", as it might not be the right line-separator. you can either do:
>> Suggestion:
>> 
>>                 System.err.println();
>>                 System.err.println(e.getExceptionInfo());
>> 
>> or
>> Suggestion:
>> 
>>                 System.err.printf("%n%s%n", e.getExceptionInfo());
>
> I will address all `\n` in a separate commit as there are a lot of them. Could I also just use `System.lineSeparator()` anywhere where I'm currently using `\n` like  `System.err.println(System.lineSeparator() + e.getExceptionInfo()`)? Might be easier when I'm using `\n` with a `StringBuilder`, for example.

sure you case use `System.lineSeparator()`, it's just a matter of personal choice/style

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 804:
>> 
>>> 802:             System.err.println("--- OUTPUT TestFramework flag VM ---");
>>> 803:             System.err.println(flagVMOutput);
>>> 804:             throw new RuntimeException("\nTestFramework flag VM exited with " + exitCode);
>> 
>> what's the reason for `\n` in the begging of this exception message?
>
> I guess it's not necessary. Removed it.

?? . I noticed that you have leading `\n` in other exceptions, do you plan to remove it from there as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Mon Apr 19 23:36:14 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 19 Apr 2021 23:36:14 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <ZdPVH4X773b1eN9CshE6jeiPP9g0Ai30iHqOVS2Z8x4=.0d63d47b-3e5d-4c24-8612-fe3b61a6ef1c@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <F0eo7Zs3FqdH33meE7Br0fgSbTfhkCQaBqp4-FXcF6M=.ba0201be-dfbb-49a6-836c-bf0037fd8fdc@github.com>
 <So18R3zB8dbCvYW50l3Lox7gY3bxsPO6ncST8SurJUc=.c9121fa9-8b70-4b7c-96a7-99090d58f290@github.com>
 <ZdPVH4X773b1eN9CshE6jeiPP9g0Ai30iHqOVS2Z8x4=.0d63d47b-3e5d-4c24-8612-fe3b61a6ef1c@github.com>
Message-ID: <picZrwjIcUD9ctxKqfiECMumRCe2oBvQyrPJLJAEwCk=.80f9291f-f5c6-466d-a2c2-f627ae77cff0@github.com>

On Mon, 19 Apr 2021 09:37:40 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> you might also want to update javadoc for this method to state that there can be duplicates.
>
> Have I understood this correctly that you suggest to just remove this check completely and just specifying in the Javadocs that duplicates are ignore (due to using a `Set`)?

you don't have to ignore duplicates, you can still throw an exception if you encounter one. I, personally, don't think we should force users to avoid dups (as I don't yet? see any issues w/ duplicated helpers), but if you think we need to enforce that *and* make it users' responsibilities then you should continue to throw an exception. in both cases, javadoc should be updated to reflect that duplicates are ignored or that an exception is raised in case a duplicate was encountered.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Mon Apr 19 23:41:09 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 19 Apr 2021 23:41:09 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
 <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>
Message-ID: <_4R3VaH4SDOdZ9K4mgapY3eIKYD2Y_ALsMjDFz7KSAc=.73e9490f-2b1f-49f8-b41a-2dbd5c4e77a0@github.com>

On Mon, 19 Apr 2021 08:10:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 116:
>> 
>>> 114:     private void parseHotspotPidFile() {
>>> 115:         Map<Integer, String> compileIdMap = new HashMap<>();
>>> 116:         try (BufferedReader br = new BufferedReader(new FileReader(new File(System.getProperty("user.dir") + File.separator + hotspotPidFileName)))) {
>> 
>> more idiomatic/modern version would be
>> Suggestion:
>> 
>> try (BufferedReader br = Files.newBufferedReader(Paths.get(System.getProperty("user.dir"), hotspotPidFileName))) {
>> 
>> 
>> I actually not sure if you really need `$user.dir`, won't hotspot_pid file get generated in the current dir?
>
> Yes it should. Would this be equivalent to `Paths.get("")`? It seems to work like that.

`Paths.get(hotspotPidFileName)` returns you a `Path` to `hotspotPidFileName` in cwd.

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 958:
>> 
>>> 956:         throw new TestFrameworkException("Internal Test Framework exception - please file a bug:\n" + failureMessage, e);
>>> 957:     }
>>> 958: }
>> 
>> I am not convinced that we really these guys when we already have `TestFormat::check` and `TestRun::check` (I'm actually not 100% convinced that we need check/fail in both TestFormat and TestRun)
>
> I wanted to distinguish the following cases (but I'm open to use a different approach):
> 
> - `TestFormat::check` (using `TestFormatException`): The format of any test/helper class does not conform with the format the framework is expecting. The user needs to fix this (for example, using a wrong annotation). I report these kind of failures before actually running any of the tests [here](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L265).
> - `TestRun::check` (using `TestRunException`): Thrown while the framework is [executing a test](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L799), there is nothing wrong with the format of a test.
> - `TestFramework::check` (using `TestFrameworkException`): If such a check fails there is a bug in the framework itself (like internal framework assertions). The user cannot really do anything about it without fixing the framework itself.
> 
> I have to double check again if I'm using the right kind of exception everywhere.

I understand that you want to use different exception types to distinguish different kinds of failures, I just don't see lots of benefits in have `::check` and `::fail` methods, they are just `if (p) throw new X(m)` or `throw new X(m)`.

if, for example, you want `TestFrameworkException` to always have `Internal Test Framework exception - please file a bug`, you can prepend it in `TestFrameworkException::<init>`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From roberto.castaneda.lozano at oracle.com  Tue Apr 20 07:22:08 2021
From: roberto.castaneda.lozano at oracle.com (=?UTF-8?Q?Roberto_Casta=c3=b1eda_Lozano?=)
Date: Tue, 20 Apr 2021 09:22:08 +0200
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block [v2]
In-Reply-To: <FA1PzSEdgXK5esJfbw6eGt_q5K6UQuURTyThMWB366U=.4be4db0f-b7a8-4df8-95de-0464045cff80@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <ASaeKyQC6TCF_iejF4ky2BvK0OMcn5SALosyYAb1SUw=.bc82c0f0-09c5-4595-b5ce-363b318cd5a0@github.com>
 <FA1PzSEdgXK5esJfbw6eGt_q5K6UQuURTyThMWB366U=.4be4db0f-b7a8-4df8-95de-0464045cff80@github.com>
Message-ID: <6178a0ea-6445-92b6-d2a1-aa082349ec94@oracle.com>

On 2021-04-19 19:10, Vladimir Kozlov wrote:
> Marked as reviewed by kvn (Reviewer).

Thanks for reviewing, Vladimir!

From rcastanedalo at openjdk.java.net  Tue Apr 20 07:58:12 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 20 Apr 2021 07:58:12 GMT
Subject: RFR: 8262725: IGV: crash when removing all graphs in a group [v2]
In-Reply-To: <S1MRhBGCMi1Y4CeUXL6zkDWUsZT4YgYtOz3Cqt2Xmz0=.0bbbfed2-e52d-4741-8fc7-815f2783fb06@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
 <S1MRhBGCMi1Y4CeUXL6zkDWUsZT4YgYtOz3Cqt2Xmz0=.0bbbfed2-e52d-4741-8fc7-815f2783fb06@github.com>
Message-ID: <MrVbUQe-XKD3b_ep8X4qUOtA314pU-gTrq2uXZfE3qk=.706f0596-3482-4f36-8d16-e9191ba46e1c@github.com>

On Mon, 19 Apr 2021 13:28:20 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change makes IGV close graph views when their groups are either a) removed or b) emptied (all graphs are removed but the group remains), and avoids faulty graph view computation in case b).
>> 
>> Tested the following scenarios manually (on groups loaded both via network and from a file, and on JDK 8, 11, and 15):
>> 1. open a graph, then remove all graphs in the group (as described in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262725));
>> 2. open a graph, then remove its group; and
>> 3. open a graph, then remove all graphs and groups (File -> Remove all graphs and groups).
>
> Roberto Casta?eda Lozano 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 three additional commits since the last revision:
> 
>  - Simplify listener registration
>  - Merge branch 'master' into JDK-8262725
>  - Close graph views when their groups are removed or emptied

-------------

PR: https://git.openjdk.java.net/jdk/pull/3540

From rcastanedalo at openjdk.java.net  Tue Apr 20 08:01:09 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 20 Apr 2021 08:01:09 GMT
Subject: Integrated: 8262725: IGV: crash when removing all graphs in a group
In-Reply-To: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
References: <QEEFkIRMKY-pywmhWTwpnvqSNYkC20jp6nJ6pFSMo-0=.5a46bfc2-cb16-4b8c-b3df-bdb23113b4b1@github.com>
Message-ID: <yK6gdZ76UWQHIRncy3JHS35iLKyYREUwIu2-YifEgCc=.b5dcab83-96fe-4b6f-9dab-15b37ac34d93@github.com>

On Fri, 16 Apr 2021 09:11:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change makes IGV close graph views when their groups are either a) removed or b) emptied (all graphs are removed but the group remains), and avoids faulty graph view computation in case b).
> 
> Tested the following scenarios manually (on groups loaded both via network and from a file, and on JDK 8, 11, and 15):
> 1. open a graph, then remove all graphs in the group (as described in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8262725));
> 2. open a graph, then remove its group; and
> 3. open a graph, then remove all graphs and groups (File -> Remove all graphs and groups).

This pull request has now been integrated.

Changeset: 51366439
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51366439
Stats:     23 lines in 2 files changed: 21 ins; 0 del; 2 mod

8262725: IGV: crash when removing all graphs in a group

Make IGV close graph views when their groups are either removed or emptied, and
avoid faulty graph view computation for empty groups.

Reviewed-by: chagedorn, rrich

-------------

PR: https://git.openjdk.java.net/jdk/pull/3540

From jbhateja at openjdk.java.net  Tue Apr 20 08:41:07 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 20 Apr 2021 08:41:07 GMT
Subject: RFR: 8265491: Math Signum optimization for x86
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <R6I61hf1_yOOru812U3yV0G2b5O2ccs43Te4grxtzgg=.1a96a013-80bb-4d83-bdf5-05d91dc0c19e@github.com>

On Mon, 19 Apr 2021 23:00:47 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>  
> Optimized:
> signum intrinsic patch
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op
> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

@mgkwill,  your newly added benchmark has 4 micro worklets, please publish the results for all of them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From neliasso at openjdk.java.net  Tue Apr 20 09:00:08 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 20 Apr 2021 09:00:08 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block [v2]
In-Reply-To: <ASaeKyQC6TCF_iejF4ky2BvK0OMcn5SALosyYAb1SUw=.bc82c0f0-09c5-4595-b5ce-363b318cd5a0@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <ASaeKyQC6TCF_iejF4ky2BvK0OMcn5SALosyYAb1SUw=.bc82c0f0-09c5-4595-b5ce-363b318cd5a0@github.com>
Message-ID: <800nwO9jTsyHxLVbCsiWA1o6VqWHhB9n3wEI76rTH0U=.12083990-9631-4950-911d-f19ab73020e8@github.com>

On Mon, 12 Apr 2021 08:37:18 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
>> 
>> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
>> 
>> Tested on:
>> - original bug reproducer
>> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
>> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Complete projection assertions with basic checks
>  - Enforce code style in surrounding 'for' statements
>  - Simplify loop that removes dead projections, rename and comment for clarity
>  - Assert that projections are stuck to their parents

Looks good!

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3303

From rcastanedalo at openjdk.java.net  Tue Apr 20 09:05:09 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 20 Apr 2021 09:05:09 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block [v2]
In-Reply-To: <l6ko2puM-0xEgK1UEz1eFs1gbhal99IHrLzvSZ3z2Qc=.b0d8e5bb-cd34-4014-b305-5db485126b02@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <5JuMKHvQeAR147_GiEJFmWNFxpU00DKY3b9Wo1YelQM=.d45c40cd-dd32-498f-a1fe-99aab5163cec@github.com>
 <l6ko2puM-0xEgK1UEz1eFs1gbhal99IHrLzvSZ3z2Qc=.b0d8e5bb-cd34-4014-b305-5db485126b02@github.com>
Message-ID: <UBRYu-3WoaW-fKkbtlvyHmW9dHRBeGG6TQO-Ld16QJ4=.1e43641f-837e-483d-bff7-b8ba7ade13cd@github.com>

On Tue, 6 Apr 2021 09:51:41 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Looks good!

Thanks again, Nils.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3303

From jiefu at openjdk.java.net  Tue Apr 20 09:33:04 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 20 Apr 2021 09:33:04 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <NxPI1oa4YKWRc1DT9woPeBtMYKWbXQFi5iS7fqpzM14=.d7877d50-e915-4eb8-ac93-1107d534b286@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
 <NxPI1oa4YKWRc1DT9woPeBtMYKWbXQFi5iS7fqpzM14=.d7877d50-e915-4eb8-ac93-1107d534b286@github.com>
Message-ID: <io1eB_wZnr4jT3ePFHWIBXD_SQdu0Afn6iQjmoDr8mE=.0275a7fc-e394-46f4-99ec-ac02b76e5e9c@github.com>

On Mon, 19 Apr 2021 19:40:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Good.

Thanks @vnkozlov .

Hi @neliasso , are you OK with the latest change?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From neliasso at openjdk.java.net  Tue Apr 20 09:41:11 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 20 Apr 2021 09:41:11 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <gXBXRTk8yPp-CC8Pe4YbAhB35NvAx1FXj2XD-Ru3iTk=.07c15ed0-b159-4ffe-8b67-c9b06850f4c2@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <gXBXRTk8yPp-CC8Pe4YbAhB35NvAx1FXj2XD-Ru3iTk=.07c15ed0-b159-4ffe-8b67-c9b06850f4c2@github.com>
Message-ID: <CIPCZZWDfy6YD2NT6dEUIwDEpEGn0BCy9K5pqyczGTM=.54fd5b6b-7ab4-40b5-9639-6cefe80999d8@github.com>

On Fri, 9 Apr 2021 11:57:06 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Optimize C2
>>  - Merge branch 'master' into JDK-8264945
>>  - Revert old changes
>>  - 8264945: Optimize the code-gen for Math.pow(x, 0.5)
>
> Looks good.

> Hi @neliasso , are you OK with the latest change?

Yes. Looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From jiefu at openjdk.java.net  Tue Apr 20 09:45:07 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 20 Apr 2021 09:45:07 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <CIPCZZWDfy6YD2NT6dEUIwDEpEGn0BCy9K5pqyczGTM=.54fd5b6b-7ab4-40b5-9639-6cefe80999d8@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <gXBXRTk8yPp-CC8Pe4YbAhB35NvAx1FXj2XD-Ru3iTk=.07c15ed0-b159-4ffe-8b67-c9b06850f4c2@github.com>
 <CIPCZZWDfy6YD2NT6dEUIwDEpEGn0BCy9K5pqyczGTM=.54fd5b6b-7ab4-40b5-9639-6cefe80999d8@github.com>
Message-ID: <phAp6Rq5PzWG5PdHv-VkameBbG2fH9vsFIKTt9dQCoQ=.9968b186-712a-410a-b859-e64597ca5887@github.com>

On Tue, 20 Apr 2021 09:38:22 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> > Hi @neliasso , are you OK with the latest change?
> 
> Yes. Looks good.

Thanks @neliasso .

Will push it tomorrow if there is no objection.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From rcastanedalo at openjdk.java.net  Tue Apr 20 10:05:05 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 20 Apr 2021 10:05:05 GMT
Subject: RFR: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block [v2]
In-Reply-To: <ASaeKyQC6TCF_iejF4ky2BvK0OMcn5SALosyYAb1SUw=.bc82c0f0-09c5-4595-b5ce-363b318cd5a0@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
 <ASaeKyQC6TCF_iejF4ky2BvK0OMcn5SALosyYAb1SUw=.bc82c0f0-09c5-4595-b5ce-363b318cd5a0@github.com>
Message-ID: <IEWO9nhKoCLVABfxJovL3gMKt6gxTthKzLyCM0p0QkI=.1adeb7b8-d74f-48f9-8395-7ff7e562270a@github.com>

On Mon, 12 Apr 2021 08:37:18 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
>> 
>> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
>> 
>> Tested on:
>> - original bug reproducer
>> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
>> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Complete projection assertions with basic checks
>  - Enforce code style in surrounding 'for' statements
>  - Simplify loop that removes dead projections, rename and comment for clarity
>  - Assert that projections are stuck to their parents

-------------

PR: https://git.openjdk.java.net/jdk/pull/3303

From rcastanedalo at openjdk.java.net  Tue Apr 20 10:10:10 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 20 Apr 2021 10:10:10 GMT
Subject: Integrated: 8263227: C2: inconsistent spilling due to dead nodes in
 exception block
In-Reply-To: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
References: <9y8Bw6bniQX2kF659D_tyTfbZQc1W3ptA7xSr7fmsc8=.77b3fb6e-6e49-4861-9f1d-3ffbf0b075fd@github.com>
Message-ID: <k4NfIcfOGtW1Qj8hRHKQpss7SBxSRfUYj-7RKaX3o_U=.cbfa74cc-5444-4b38-9ac4-6c28a4304852@github.com>

On Thu, 1 Apr 2021 10:02:39 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change eliminates dead multi-nodes created by call-catch cleanup after GCM. Eliminating all dead code created by call-catch cleanup avoids potential issues when splitting the live range of call result values, see the analysis in the [bug report](https://bugs.openjdk.java.net/browse/JDK-8263227) for details. This solution is the least invasive of the three alternatives proposed in the bug report (the other two are constraining global code motion and extending live-range splitting).
> 
> The change also extends the control-flow graph verification pass to catch similar live-range splitting issues earlier (with `+VerifyRegisterAllocator`).
> 
> Tested on:
> - original bug reproducer
> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator`
> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64) with `+VerifyRegisterAllocator` and `+StressGCM` (5 repetitions)

This pull request has now been integrated.

Changeset: d81b0461
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d81b0461
Stats:     115 lines in 4 files changed: 107 ins; 0 del; 8 mod

8263227: C2: inconsistent spilling due to dead nodes in exception block

Eliminate dead nodes created by call-catch cleanup even if they have multiple
projections. Assert that definitions dominate uses and projections are scheduled
next to their parent nodes.

Reviewed-by: neliasso, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3303

From thartmann at openjdk.java.net  Tue Apr 20 13:34:06 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 20 Apr 2021 13:34:06 GMT
Subject: RFR: 8265106: IGV: Enforce en-US locale while parsing ideal graph
In-Reply-To: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
References: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
Message-ID: <AiZ9Wp-MH-8fWBNrIfvRkk61-4psVtM1C78vnLNhQqk=.9dea78ca-3d0d-49bd-a4b6-bfabb5b7bf31@github.com>

On Mon, 19 Apr 2021 04:48:07 GMT, Yi Yang <yyang at openjdk.org> wrote:

> IGV is designed to support parsing incomplete XML. However, it does not work for non-English users. See #3071 for detailed reasons. This patch would address it.
> 
> (P.S. Locale.ENGLISH also does not work, see  Philip Helger' [comment](https://stackoverflow.com/questions/18531633/locale-specific-messages-in-xerces-2-11-0-java) on the first answer.)

Looks reasonable to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3563

From chagedorn at openjdk.java.net  Tue Apr 20 13:41:03 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 13:41:03 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v3]
In-Reply-To: <lik1BDARDj9-MFobMiQdldzFHX1gh4G6VpsH8tCRaws=.44e14bc9-15dc-4578-a094-7b29220de98d@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <lik1BDARDj9-MFobMiQdldzFHX1gh4G6VpsH8tCRaws=.44e14bc9-15dc-4578-a094-7b29220de98d@github.com>
Message-ID: <uzqfjnTKAy_Ua9ZfGVShqEakPK-KHNIfzEVZo4d7_Lk=.23e456cf-2d40-453f-ade6-fea3c52ec10e@github.com>

On Mon, 19 Apr 2021 12:49:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review comments in code from Igor I. and Vladimir K.

Updated with review comments from @JohnTortugo and @iignatev related to code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 20 13:40:59 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 13:40:59 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v4]
In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
Message-ID: <rxwJsMSAvWUVJjkmjED6vz9yd5wGmEoJu93-Q1xa9zE=.5021d88d-cd78-4c17-8cbf-310f82950381@github.com>

> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 
> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
> 
> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
> 
> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
> 
> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
> 
> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
> 
> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>       - which leaves 4382 lines of code inserted 
> 
> Big thanks to:
> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
> - and others who provided valuable feedback.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with three additional commits since the last revision:

 - Improve error format output by changing some new lines
 - Replace "\n" by System.lineSeparator()
 - Fix typos and grammar, code format (JohnTortugo), fix exception throwing, toggleBoolean, shuffle and others (Igor I.)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3508/files
  - new: https://git.openjdk.java.net/jdk/pull/3508/files/b3f58111..433006c5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=02-03

  Stats: 209 lines in 19 files changed: 44 ins; 41 del; 124 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3508.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 20 13:41:08 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 13:41:08 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <IV0q3C7kZ6BcKeKiocgmxC8a5pH7MSrcW-koSoTdw2g=.65c4f461-ddc6-487f-abf5-1c2e4a1dcfae@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <IV0q3C7kZ6BcKeKiocgmxC8a5pH7MSrcW-koSoTdw2g=.65c4f461-ddc6-487f-abf5-1c2e4a1dcfae@github.com>
Message-ID: <Xo-3wO7K-cBtUFDBFJJPuXWowRCIR2XuNieOKrr6fFA=.f361b9e4-8ab8-4e0d-a0d6-8ccbc909c5ce@github.com>

On Sat, 17 Apr 2021 01:16:33 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust whitelist
>
> test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 182:
> 
>> 180:     private static void appendLine(StringBuilder builder, String line) {
>> 181:         if (line.contains("&")) {
>> 182:             line = line.replace("&amp;", "&");
> 
> although I doubt it will ever be a problem in our use case, yet to be safe this replacement should be the last one, otherwise `&amp;lt;` will become `<` while it should be `&lt;`

Good catch!

> test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 349:
> 
>> 347:             if (matchCount > 0) {
>> 348:                 matcher.reset();
>> 349:                 failMsg.append("    Regex ").append(nodeId).append(") ").append(nodeRegex).append("\n");
> 
> it seems you missed an opening parenthesis after `Regex ` .

I used the parenthesis like an enumeration `Regex 1), Regex 2)` etc. But might be better to just use `Regex 1:`.

> test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 516:
> 
>> 514:      */
>> 515:     public void appendIdealOutput(String idealOutput) {
>> 516:         outputBuilder.setLength(0);
> 
> I doubt that a method named `append.*` should remove the previous values.

Renamed the methods into `set.*`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 20 13:41:04 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 13:41:04 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <XHYhuY1c7iwd5DJULvVBSCpyMRI_AZgJzYD1x0-NML8=.2d892ddb-d593-421d-a7ed-f25e52d884a1@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
 <XHYhuY1c7iwd5DJULvVBSCpyMRI_AZgJzYD1x0-NML8=.2d892ddb-d593-421d-a7ed-f25e52d884a1@github.com>
Message-ID: <tt16jQ3UHaI-IVsARiw0e9kuNCjr_Fg4wz1z0IALkEI=.b320882d-2f91-48fb-ac7f-412404ddc22f@github.com>

On Mon, 19 Apr 2021 15:37:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 41:
>> 
>>> 39:  */
>>> 40: abstract public class AbstractInfo {
>>> 41:     private static final Random random = new Random();
>> 
>> you shouldn't use Random w/o predefined seed as it might make it harder to reproduce, please consider using `jdk.test.lib.Utils.getRandomInstance` or `jdk.test.lib.RandomFactory.getRandom` here
>
> I've also noticed that you use `Collections::shuffle` in `TestFrameworkExecution` w/o passing a reproducible rng.

Fixed that, too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 20 13:41:09 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 13:41:09 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <AwVg7jUJudbQ39WG-b-FyU2CBlp60pHP4O8P0YnSHUs=.07cdb899-a3fd-462e-b2e2-3348cbf73c45@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <j0TOiTvlb9RzpyTDwUp7GMuxNZCcNceiGC0OhcDQUEk=.ca4471b6-29ee-4bf6-9948-ccd49af89e94@github.com>
 <kHAYSDMLiKuQKGnyQzQIYFy5iz7UAkcHvZotGSUGmd8=.68e8b525-8112-4b97-acd1-c857710cfd47@github.com>
 <AwVg7jUJudbQ39WG-b-FyU2CBlp60pHP4O8P0YnSHUs=.07cdb899-a3fd-462e-b2e2-3348cbf73c45@github.com>
Message-ID: <QcKoVf8m_VuzNSrvViktZld7vDDr_p371ELf5b92XW8=.734c75c5-b17d-4dcf-98c9-9b3958608197@github.com>

On Mon, 19 Apr 2021 16:59:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Maybe first some general background about having a whitelist/blacklist in the first place. When a user writes an `@IR` rule, we do not want him to think about any possible VM flag combination (which he is not specifically using in his test, for example with `addFlags`) that could break his `@IR` rule and then requiring him to restrict the `@IR` rule with `IR::applyIfXX()` for these flags.
>> 
>> I agree that the whitelist is probably not complete and could be improved (but I think we should not whitelist different GCs as these affect the barrier code of the IR). About whitelist vs. blacklist, I had discussions about it with @TobiHartmann. We eventually decided to use a whitelist which seemed easier to maintain and is probably a lot shorter than a blacklist. In addition, if a new flag is introduced or removed, we most likely do not need to worry about updating the whitelist as the (currently) whitelisted flags will most likely remain unchanged. This first whitelist version is also just a best guess solution. We might miss on some other flags that will not affect the IR but we have the confidence that we do not run into surprising failures due to forgetting to blacklist a particular flag. But this is open for discussion of course. It would be interesting to hear how people think about it.
>
> I'll need to think about it a bit more, but my first impression after reading your comment is that we don't actually want to allow any flags, so we might better off just using `@requies vm.flagless` or reusing the underlying code to check that we don't have any flags that can "significantly" change behavior.

Our idea was to only restrict the IR verification done after the test VM terminates with the whitelist (or blacklist). But the framework should still run each test with any flag combination. This showed to be quite useful in Valhalla to find bugs.

>> I think we should keep it for the cases when a user wants a more specific setup for his tests in the calling test class. For example, if he wants to define a new default warm-up for all of his tests (using `setDefaultWarmup`) or if he needs to combine different options for which there is no `runXX` method (helper classes, scenarios, and/or flags). In this case, he needs to create a `TestFramework()` builder and then call the different builder methods. We could argue that a single constructor is enough in which the test class needs to be specified. But I think most of the time, the user wants to test the calling class for which this additional constructor is quite useful.
>
>> But I think most of the time, the user wants to test the calling class for which this additional constructor is quite useful.
> 
> I concur that in most cases the users would want to use the caller as a `testClass`, yet we already have `run` and friends to cover that (most common) use-case, users who would need to construct fancier `TestFramework`, most probably, won't be doing it in their `testClass`, and if they would, the overhead of writing `new TestFramework(getClass())` is just 10 keystrokes and is neglatible (given the assumption of a more complicated use case)

That is true. The entire test will probably look more complex in this case so it's probably reasonable to only provide the constructor with a class argument. However, if we are going to remove most of the (current) `runXX()` methods as discussed in a comment below, then keeping this parameterless constructor might be justified again? Anyhow, I'm fine with both. (Nit: when used from `main()` we would need to use `MyTestClass.class` instead of `getClass()`)

>> I think you are probably right. I added this builder approach later during the development of the framework. It might be better to keep the `TestFramework` interface simple(r). However, I will wait for others to comment on that before changing/removing all of these. 
>> 
>> If we're gonna simplify it, I suggest to keep `run()` and maybe also `runWithFlags()` as (probably?) most common use-case.
>
>> I suggest to keep run() and maybe also runWithFlags() as (probably?) most common use-case.
> 
> I guess you are right, `run()` and `runWithFlags(String[])` will be most-commonly used ones.

Sounds good. Will do these changes if others agree.

>> I will address all `\n` in a separate commit as there are a lot of them. Could I also just use `System.lineSeparator()` anywhere where I'm currently using `\n` like  `System.err.println(System.lineSeparator() + e.getExceptionInfo()`)? Might be easier when I'm using `\n` with a `StringBuilder`, for example.
>
> sure you case use `System.lineSeparator()`, it's just a matter of personal choice/style

?? I fixed them.

>> I guess it's not necessary. Removed it.
>
> ?? . I noticed that you have leading `\n` in other exceptions, do you plan to remove it from there as well?

Sometimes, I found the resulting format of the error message nicer with the additional new lines. For example the exception at [L940](https://github.com/openjdk/jdk/blob/a563fb33ead7d2c8c9a5266d7187c956327281b2/test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java#L940):


JavaTest Message: Test threw exception: jdk.test.lib.hotspot.ir_framework.TestFormatException: 

Violations (1)
--------------
 - Cannot use explicit compile command annotations ...

vs. no new lines:

JavaTest Message: Test threw exception: jdk.test.lib.hotspot.ir_framework.TestFormatException: Violations (1)
--------------
 - Cannot use explicit compile command annotations ...

I will check the other exceptions again if they really need the new lines or not.

>> I wanted to distinguish the following cases (but I'm open to use a different approach):
>> 
>> - `TestFormat::check` (using `TestFormatException`): The format of any test/helper class does not conform with the format the framework is expecting. The user needs to fix this (for example, using a wrong annotation). I report these kind of failures before actually running any of the tests [here](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L265).
>> - `TestRun::check` (using `TestRunException`): Thrown while the framework is [executing a test](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L799), there is nothing wrong with the format of a test.
>> - `TestFramework::check` (using `TestFrameworkException`): If such a check fails there is a bug in the framework itself (like internal framework assertions). The user cannot really do anything about it without fixing the framework itself.
>> 
>> I have to double check again if I'm using the right kind of exception everywhere.
>
> I understand that you want to use different exception types to distinguish different kinds of failures, I just don't see lots of benefits in have `::check` and `::fail` methods, they are just `if (p) throw new X(m)` or `throw new X(m)`.
> 
> if, for example, you want `TestFrameworkException` to always have `Internal Test Framework exception - please file a bug`, you can prepend it in `TestFrameworkException::<init>`

I see your point. Having `fail` indeed does not add much benefit compared to just having `throw new XX` for `TestFramework` and `TestRun`. I replaced these `fail` methods with direct `throw new XX` statements and only kept the `check` methods. For `TestFormat`, I think it makes makes more sense to keep the `check` and `fail` methods as I'm also logging the failures and sometimes not even throwing an exception directly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 20 13:41:09 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 13:41:09 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <picZrwjIcUD9ctxKqfiECMumRCe2oBvQyrPJLJAEwCk=.80f9291f-f5c6-466d-a2c2-f627ae77cff0@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <F0eo7Zs3FqdH33meE7Br0fgSbTfhkCQaBqp4-FXcF6M=.ba0201be-dfbb-49a6-836c-bf0037fd8fdc@github.com>
 <So18R3zB8dbCvYW50l3Lox7gY3bxsPO6ncST8SurJUc=.c9121fa9-8b70-4b7c-96a7-99090d58f290@github.com>
 <ZdPVH4X773b1eN9CshE6jeiPP9g0Ai30iHqOVS2Z8x4=.0d63d47b-3e5d-4c24-8612-fe3b61a6ef1c@github.com>
 <picZrwjIcUD9ctxKqfiECMumRCe2oBvQyrPJLJAEwCk=.80f9291f-f5c6-466d-a2c2-f627ae77cff0@github.com>
Message-ID: <-IVxOwoxe3y80ESAqhDj9Ps1eslFee_G_qnt8igLQjs=.c2057599-cd95-4b71-8bbc-9b379581f0eb@github.com>

On Mon, 19 Apr 2021 23:30:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Have I understood this correctly that you suggest to just remove this check completely and just specifying in the Javadocs that duplicates are ignore (due to using a `Set`)?
>
> you don't have to ignore duplicates, you can still throw an exception if you encounter one. I, personally, don't think we should force users to avoid dups (as I don't yet? see any issues w/ duplicated helpers), but if you think we need to enforce that *and* make it users' responsibilities then you should continue to throw an exception. in both cases, javadoc should be updated to reflect that duplicates are ignored or that an exception is raised in case a duplicate was encountered.

>From a correctness point of view, it should not make a difference if a helper class is added twice. We will just apply all the annotations twice (enqueue a method for compilation, set a method to be not inlined etc.). But I think it's unnecessary work for the framework to walk through all methods and process them twice. So, I tend towards just ignoring dups without an exception and mention that in the Javadocs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 20 13:41:09 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 13:41:09 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v3]
In-Reply-To: <srlwPPnPzJTwIzio8e0EWsW1uqwUltW3WxZTFdPHKMo=.de1456b6-7b9a-41a7-945f-3fa4a52563b7@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <lik1BDARDj9-MFobMiQdldzFHX1gh4G6VpsH8tCRaws=.44e14bc9-15dc-4578-a094-7b29220de98d@github.com>
 <srlwPPnPzJTwIzio8e0EWsW1uqwUltW3WxZTFdPHKMo=.de1456b6-7b9a-41a7-945f-3fa4a52563b7@github.com>
Message-ID: <_h0p3wWDlBKQqd1Pjev89NtWoMBRWcllgcolvzYas3Q=.b32b6657-1caa-4a11-9388-7c4754f538de@github.com>

On Mon, 19 Apr 2021 20:52:31 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review comments in code from Igor I. and Vladimir K.
>
> test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 110:
> 
>> 108: 
>> 109: The framework will spawn a new "test VM" to execute the user defined tests. The test VM collects all tests of the test class specified by the user code in `main()` and ensures that there is no violation of the required format by the framework. In a next step, the framework does the following for each test in general:
>> 110: 1. Warm the test up for a predefined number of times (default 2000). This can also be adapted for all tests by using `testFrameworkobject.setDefaultWarmup(100)` or for individual tests with an additional [@Warmup](./doc/jdk/test/lib/hotspot/ir_framework/Warmup.html) annotation. 
> 
> The previous section seems to indicate that the default number of warm-up iterations is 200. "-Dwarmup=200".

I added a comment in section 2.5 mentioning the framework default of 2000 to avoid confusions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 20 13:42:17 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 13:42:17 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v3]
In-Reply-To: <lik1BDARDj9-MFobMiQdldzFHX1gh4G6VpsH8tCRaws=.44e14bc9-15dc-4578-a094-7b29220de98d@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <lik1BDARDj9-MFobMiQdldzFHX1gh4G6VpsH8tCRaws=.44e14bc9-15dc-4578-a094-7b29220de98d@github.com>
Message-ID: <CuOJUzvt686fcJ8mZEogloyazUAu-xoDy0rWSI3cOXc=.0f3bede6-21ee-461b-9a90-084c5ccd21a2@github.com>

On Mon, 19 Apr 2021 12:49:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review comments in code from Igor I. and Vladimir K.

> > > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files
> > > * the same goes for `README.html` generated from `README.md`
> > 
> > 
> > Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk?
> > > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`.
> > > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot`
> > 
> > 
> > That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)?
> 
> `test/hotspot/jtreg/testlibrary_tests` are seldomly run as part of `:hotspot_misc` test group, yet I don't think it's an issue. the benefit of running testlibrary tests is to gain confidence that the tests which use these libraries are reliable. I'd also disagree that `ir_framework/tests` should be run _only_ when the framework is actually, they should also be run when its dependencies are changed, and the framework highly depends on hotspot, so to be sure that the framework didn't get broken after changes in c2, whitebox, etc, you do need run these tests more often.

I see your point. I have not considered the dependencies which can frequently change even though the framework does not. I therefore agree with you that we should run them at least from time to time. I will move everything to  `test/hotspot/jtreg/testlibrary` in a next step.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 20 13:52:13 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 13:52:13 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v5]
In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
Message-ID: <VIClyiA702WOBS5M5azRIWp2D2zSp9B58HxlCdyMx7I=.29bf18f8-0fe0-4209-91c5-1c8e67144f3e@github.com>

> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 
> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
> 
> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
> 
> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
> 
> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
> 
> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
> 
> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>       - which leaves 4382 lines of code inserted 
> 
> Big thanks to:
> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
> - and others who provided valuable feedback.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:

  Remove Javadocs and README.html, update README.md to reference java files instead of html files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3508/files
  - new: https://git.openjdk.java.net/jdk/pull/3508/files/433006c5..72eece63

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=03-04

  Stats: 11647 lines in 86 files changed: 0 ins; 11635 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3508.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 20 14:04:08 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 14:04:08 GMT
Subject: RFR: 8265106: IGV: Enforce en-US locale while parsing ideal graph
In-Reply-To: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
References: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
Message-ID: <OHUXEH-fx3TL7d_n42rLMaoppajiAHZNJgJU_iLhuzI=.b8edf3ec-e40e-4deb-ac3b-b59d0d4a6d54@github.com>

On Mon, 19 Apr 2021 04:48:07 GMT, Yi Yang <yyang at openjdk.org> wrote:

> IGV is designed to support parsing incomplete XML. However, it does not work for non-English users. See #3071 for detailed reasons. This patch would address it.
> 
> (P.S. Locale.ENGLISH also does not work, see  Philip Helger' [comment](https://stackoverflow.com/questions/18531633/locale-specific-messages-in-xerces-2-11-0-java) on the first answer.)

Looks good.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3563

From github.com+168222+mgkwill at openjdk.java.net  Tue Apr 20 14:46:04 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 20 Apr 2021 14:46:04 GMT
Subject: RFR: 8265491: Math Signum optimization for x86
In-Reply-To: <R6I61hf1_yOOru812U3yV0G2b5O2ccs43Te4grxtzgg=.1a96a013-80bb-4d83-bdf5-05d91dc0c19e@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <R6I61hf1_yOOru812U3yV0G2b5O2ccs43Te4grxtzgg=.1a96a013-80bb-4d83-bdf5-05d91dc0c19e@github.com>
Message-ID: <6mLapx2FtNNrgyWDg8lmrumY1JIZpPEDZ6UHbGu-btM=.784d8a12-15c5-495d-80cc-33d379ddd4be@github.com>

On Tue, 20 Apr 2021 08:38:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> @mgkwill, your newly added benchmark has 4 micro worklets, please publish the results for all of them.

@jatin-bhateja Certainly. Omission was an oversight. I've updated the description of the pull request with overhead results.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From jiefu at openjdk.java.net  Tue Apr 20 15:00:08 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 20 Apr 2021 15:00:08 GMT
Subject: RFR: 8265491: Math Signum optimization for x86
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <Hpu4HvZLuK88SnNBj210KUpqmOdkEb2Eb2DNu7D1n0s=.0629d430-8b20-4ad8-903b-d6a9fda8286b@github.com>

On Mon, 19 Apr 2021 23:00:47 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>  
> Optimized:
> signum intrinsic patch
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op
> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op
> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op
> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 ns/op
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 28:

> 26:  * @test
> 27:  * @summary Test compiler intrinsics for signum
> 28:  * @requires os.arch=="aarch64" | os.arch=="x86" | os.arch=="amd64" | os.arch=="x86_64"

What about os.arch=="i386" ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Tue Apr 20 15:28:43 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 20 Apr 2021 15:28:43 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>  
> Optimized:
> signum intrinsic patch
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op
> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op
> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op
> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 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:

  Add os.arch=="i386" to signum jtreg
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/e461edc7..99a2971d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Tue Apr 20 15:28:48 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 20 Apr 2021 15:28:48 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <Hpu4HvZLuK88SnNBj210KUpqmOdkEb2Eb2DNu7D1n0s=.0629d430-8b20-4ad8-903b-d6a9fda8286b@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <Hpu4HvZLuK88SnNBj210KUpqmOdkEb2Eb2DNu7D1n0s=.0629d430-8b20-4ad8-903b-d6a9fda8286b@github.com>
Message-ID: <lV7xROXZsiQGV7ODr2sN2s6f7pcVLNUo6Xd4-Ej5tgI=.3719359b-c166-4e3a-b85c-6fc09ce8a7ca@github.com>

On Tue, 20 Apr 2021 14:57:09 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add os.arch=="i386" to signum jtreg
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 28:
> 
>> 26:  * @test
>> 27:  * @summary Test compiler intrinsics for signum
>> 28:  * @requires os.arch=="aarch64" | os.arch=="x86" | os.arch=="amd64" | os.arch=="x86_64"
> 
> What about os.arch=="i386" ?

@DamonFool, I wasn't sure about `os.arch=="i386"`. I'm still getting my head around os.arch and how it is used in these tests. 

I'll add it to the jtreg.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From aph at openjdk.java.net  Tue Apr 20 16:55:07 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 20 Apr 2021 16:55:07 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
Message-ID: <Fw-cC-ivS5FWD2YN5UDVI1EPorXf1nk_1KwM5l4XGiA=.12e66f4c-c654-48ce-be37-86349c72fa48@github.com>

On Mon, 19 Apr 2021 15:10:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> I'd like to optimize the code-gen for Math.pow(x, 0.5).
>> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
>> 
>> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
>> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
>> 
>> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
>> 
>> Before:
>> 
>> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
>> 
>> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
>> 
>> 
>> After:
>> 
>> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
>> 
>> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
>> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
>> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
>> 
>> 
>> Testing:
>>   - tier1~3 on Linux/x64
>> 
>> Thanks,
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680
>
> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Optimize C2
>  - Merge branch 'master' into JDK-8264945
>  - Revert old changes
>  - 8264945: Optimize the code-gen for Math.pow(x, 0.5)

This may be unsafe. AFAIK there is no guarantee about the monotonicity of `Math.pow(x, y)` as y moves from `Math.pow(x, nextAfter?(0.5, -1)` to `Math.pow(x, 0.5)` to `Math.pow(x, nextAfter?(0.5, 1)` for all x. Did anyone look?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From chagedorn at openjdk.java.net  Tue Apr 20 17:30:17 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 20 Apr 2021 17:30:17 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <zbToJ5_pj6ysv-TUUD0oYpWacEvz0oUn2_CYDhHcJj4=.58f0dac0-8224-465c-9da0-da7970e91248@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <xxbm1as_hR1VGJ7xG7FRMFDBpPJWYstFiiC8VoCOvSo=.8b7237ef-4bb6-4471-b9c7-404b8f10a6ec@github.com>
 <gxsA__SaOXZ2CYH2QMYVPIRiodtR-_HJv4n3s7VsAOA=.75227295-f0f8-4055-a29a-5d5fd3a28a68@github.com>
 <zbToJ5_pj6ysv-TUUD0oYpWacEvz0oUn2_CYDhHcJj4=.58f0dac0-8224-465c-9da0-da7970e91248@github.com>
Message-ID: <w5OlfBgg4Bd3CCssZUGrz5ekjC32NAmBe5O2vsp0Nh8=.7fe502eb-e9f5-4ce4-8633-1668980e75da@github.com>

On Mon, 19 Apr 2021 15:34:27 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>>> * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files
>>> * the same goes for `README.html` generated from `README.md`
>> 
>> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? 
>> 
>>> * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`.
>>> * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot`
>> 
>> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)?
>> 
>> I will do this things in a separate commit and adjust the README.md file accordingly (has links to the Javadoc files).
>
>> > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files
>> > * the same goes for `README.html` generated from `README.md`
>> 
>> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk?
>> 
>> > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`.
>> > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot`
>> 
>> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)?
> 
> `test/hotspot/jtreg/testlibrary_tests` are seldomly run as part of `:hotspot_misc` test group, yet I don't think it's an issue. the benefit of running testlibrary tests is to gain confidence that the tests which use these libraries are reliable. I'd also disagree that `ir_framework/tests` should be run *only* when the framework is actually, they should also be run when its dependencies are changed, and the framework highly depends on hotspot, so to be sure that the framework didn't get broken after changes in c2, whitebox, etc, you do need run these tests more often.
> 
> Thanks,
> -- Igor

There is no decision, yet, (and open for discussion) about the location and package name for the framework and the framework internal tests. After discussing it offline with @iignatev, we think there are basically two good options:
1. Leave the framework in `/test/lib` and put the framework internal tests into `/test/lib-test`:
   - Pros: Only need to specify `@library /test/lib` in a JTreg test; the framework internal tests are run in tier1 before any other tests are run which depend on the framework ensuring correctness.
   - Cons: Clarity: The framework is intended to be used for HotSpot tests only (thus not exactly the right location in `/test/lib`); the framework internal tests might be run too often as part of tier1 (trade-off ensuring correctness vs. execution time).
2. Move the framework to `/test/hotspot/jtreg/testlibrary`, put the framework internal tests into `/test/hotspot/jtreg/testlibrary_tests`, and use package name `hotspot.test.lib.ir_framework`:
   - Pros: Clarity: The framework is only used for HotSpot tests (mainly compiler tests but could also be used for other tests).
   - Cons: A JTreg test needs to additionally specify `/testlibrary/ir_framework` like `@library /testlibrary/ir_framework /test/lib`; the framework internal tests are run more seldomly as part of `:hotspot_misc` (trade-off, see cons of first option).
 
What do others think about that?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From enikitin at openjdk.java.net  Tue Apr 20 18:11:35 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Tue, 20 Apr 2021 18:11:35 GMT
Subject: RFR: 8264632: compiler/codecache/jmx/PoolsIndependenceTest.java fails
 to Notification not being received
Message-ID: <Tve8mb_uD2jmhBW2O8AMYO6H40wR-fPogYxh-WpEpbE=.297df043-078b-4eb2-aae2-80a628f458be@github.com>

Hi all,

May I ask for reviews for this change? 

**The case**
https://bugs.openjdk.java.net/browse/JDK-8264632

**The problem**
The test calls for MemoryPoolMXBean.setUsageThreshold() and expects a Notification get fired when the threshold is breached. The Notification is never received.

The failure most probably is caused by the combination of following events:
1. Some threshold has already breached (caused by some other tests); 
2. In this case MemoryPoolMXBean never fires subsequent Notifications until the usage is less than a set threshold;
3. The usage manages to grow up between these two lines[1]:

final long usageThresholdLimit = bean.getUsage().getUsed() + 1;
bean.setUsageThreshold(usageThresholdLimit);

4. The usage has never fallen below any set threshold and therefore Notification is never sent. Setting usageThresholdLimit to 0 doesn't clear up the situation "Notification has already been sent" either.

[1] Very common, happens almost every time during my testing - the code cache usage grows up quickly at VM start.

**Proposed solution:**
1. Before the actual test, I set the usageThresholdLimit to max. possible value;
2. This causes the current usage to appear below the threshold and therefore the "Notification has already been sent" state is cleared;
3. The monitoring is then switched off (by setting usageThresholdLimit to 0), as at the VM start.

**Testing**
1. Preemptive breaching of some threshold causes the problem for non-modified test.
2. The modified test has been tested with debug versions of macosx, windows, linux x64 builds and a linux-aarch64-debug build.

Thanks,
Evgeny.

-------------

Commit messages:
 - 8264632: compiler/codecache/jmx/PoolsIndependenceTest.java fails to Notification not being received

Changes: https://git.openjdk.java.net/jdk/pull/3592/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3592&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264632
  Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3592.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3592/head:pull/3592

PR: https://git.openjdk.java.net/jdk/pull/3592

From jbhateja at openjdk.java.net  Tue Apr 20 18:40:09 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 20 Apr 2021 18:40:09 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
Message-ID: <RQ-UY2pbK_tM0uClYIX7QkQfklM-mYNFcRhOuU5dYGI=.1e581242-968d-4b8e-b4b2-d208def74cf2@github.com>

On Tue, 20 Apr 2021 15:28:43 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> Benchmark Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>>  
>> Optimized:
>> signum intrinsic patch
>> Benchmark Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op
>> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op
>> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op
>> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 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:
> 
>   Add os.arch=="i386" to signum jtreg
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/cpu/x86/x86.ad line 5786:

> 5784:   ins_encode %{
> 5785:     Label exit;
> 5786: 

Can you kindly move this into a macro assembly routine.

src/hotspot/cpu/x86/x86.ad line 5806:

> 5804:     Label exit;
> 5805: 
> 5806:     __ ucomisd($dst$$XMMRegister, $zero$$XMMRegister);

Same as above, please create a macro assembly routine to capture it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+2249648+johntortugo at openjdk.java.net  Tue Apr 20 18:40:08 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Tue, 20 Apr 2021 18:40:08 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler [v6]
In-Reply-To: <N0VonW97-8SFv_RRjWeGnxlXXRNPvOE7iHxdi7vugkg=.d0c093c5-b28d-43fc-81ad-ba0ab60631c2@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <00CZum78AaG7wa9LLxbJNiIsYVqT_Ice0Gl3ucxglW4=.b94a74d7-0c88-4ca8-9986-5b5c67929297@github.com>
 <wpbKPUctNgH8Lx1NVy8G5af8ZFuJ64T4xRKna9BAzo4=.992fd1ec-2b1a-4714-afdd-429ac3a2951f@github.com>
 <Ra9F8l39Dua-J-gXcE4cCqBGNZs4h3BRG93_JfMOu3k=.cea13573-37ea-4888-99c0-63b75313ba93@github.com>
 <xSAdg4LCVjx255RwARmMxRjyUYkBh-1d8A54-D9ze9c=.41f3e850-4c81-4901-8d9d-18500bba4bc8@github.com>
 <Dp2azITJyuWXb-C_oRPKWJhvtB15bFtaPSK0AXbLARE=.e26d4fdf-7eb0-41aa-b75f-21da2bd573e9@github.com>
 <N0VonW97-8SFv_RRjWeGnxlXXRNPvOE7iHxdi7vugkg=.d0c093c5-b28d-43fc-81ad-ba0ab60631c2@github.com>
Message-ID: <WdlBCvNHmhHRqne_jOI7ggy_ZnZrXj0lvihM8KkTQPw=.14cb008e-fc39-4705-a2f7-8754b62d2071@github.com>

On Fri, 26 Mar 2021 12:20:41 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Thank you all for reviewing!
>> 
>>> Can you elaborate, please, what you mean here? I don't see "enc_classes and related code" in the latest patch.
>> 
>> @dean-long got my wording right. I'll do the cleaning as a separate RFE.
>> 
>>> This changes could be tested by running in all our tiers testing.
>> 
>> Right, this is how I tested: hotspot_all, tier1, tier2, tier3, different GCs, different OS's.
>
>>  I'll do the cleaning as a separate RFE.
> 
> Sounds good.

@iwanowww @vnkozlov - can you please take a look again? I think I've addressed all your comments. Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From dholmes at openjdk.java.net  Tue Apr 20 22:04:35 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 20 Apr 2021 22:04:35 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v2]
In-Reply-To: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
Message-ID: <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>

> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
> 
> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
> 
> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Additional comments on failure modes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3580/files
  - new: https://git.openjdk.java.net/jdk/pull/3580/files/5681dfe4..264fbea5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=00-01

  Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3580.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3580/head:pull/3580

PR: https://git.openjdk.java.net/jdk/pull/3580

From github.com+168222+mgkwill at openjdk.java.net  Tue Apr 20 22:22:07 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 20 Apr 2021 22:22:07 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <RQ-UY2pbK_tM0uClYIX7QkQfklM-mYNFcRhOuU5dYGI=.1e581242-968d-4b8e-b4b2-d208def74cf2@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
 <RQ-UY2pbK_tM0uClYIX7QkQfklM-mYNFcRhOuU5dYGI=.1e581242-968d-4b8e-b4b2-d208def74cf2@github.com>
Message-ID: <PMeH4jlv-li4aLxa28pPqlYHdv6P03Fm5fM0MTmGcQE=.56c784c5-da79-48b1-822a-d420ecf4c2bb@github.com>

On Tue, 20 Apr 2021 08:30:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add os.arch=="i386" to signum jtreg
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> src/hotspot/cpu/x86/x86.ad line 5786:
> 
>> 5784:   ins_encode %{
>> 5785:     Label exit;
>> 5786: 
> 
> Can you kindly move this into a macro assembly routine.

Do you mean `instruct signumF_reg`? Please explain your reasoning for the proposed move.

> src/hotspot/cpu/x86/x86.ad line 5806:
> 
>> 5804:     Label exit;
>> 5805: 
>> 5806:     __ ucomisd($dst$$XMMRegister, $zero$$XMMRegister);
> 
> Same as above, please create a macro assembly routine to capture it.

Do you mean `instruct signumD_reg`? Please explain your reasoning for the proposed move.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From jiefu at openjdk.java.net  Tue Apr 20 22:43:04 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 20 Apr 2021 22:43:04 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <Fw-cC-ivS5FWD2YN5UDVI1EPorXf1nk_1KwM5l4XGiA=.12e66f4c-c654-48ce-be37-86349c72fa48@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
 <Fw-cC-ivS5FWD2YN5UDVI1EPorXf1nk_1KwM5l4XGiA=.12e66f4c-c654-48ce-be37-86349c72fa48@github.com>
Message-ID: <8f5G7Ec-5E4TnpHeQpYKz-tAqA6y_8PI3gAphHIvbCU=.08f3b508-c5e8-41e1-8c9b-374b31784ee6@github.com>

On Tue, 20 Apr 2021 16:49:58 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This may be unsafe. AFAIK there is no guarantee about the monotonicity of `Math.pow(x, y)` as y moves from `Math.pow(x, nextAfter?(0.5, -1)` to `Math.pow(x, 0.5)` to `Math.pow(x, nextAfter?(0.5, 1)` for all x. Did anyone look?

Thanks @theRealAph for your review.

What did you mean by `Math.pow(x, nextAfter?(0.5, -1)`  and `Math.pow(x, nextAfter?(0.5, 1)` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From yyang at openjdk.java.net  Wed Apr 21 01:45:13 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 21 Apr 2021 01:45:13 GMT
Subject: RFR: 8265106: IGV: Enforce en-US locale while parsing ideal graph
In-Reply-To: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
References: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
Message-ID: <-0WS0z5txDPueXlHIpOH4cRtfF0vyP4A7ofhcxm_488=.9a6cac98-25ee-433d-89f0-bcb2e98e8fe2@github.com>

On Mon, 19 Apr 2021 04:48:07 GMT, Yi Yang <yyang at openjdk.org> wrote:

> IGV is designed to support parsing incomplete XML. However, it does not work for non-English users. See #3071 for detailed reasons. This patch would address it.
> 
> (P.S. Locale.ENGLISH also does not work, see  Philip Helger' [comment](https://stackoverflow.com/questions/18531633/locale-specific-messages-in-xerces-2-11-0-java) on the first answer.)

Thank Tobias and Christian for reviews, and thanks Roberto for your suggested fix~

Now let me

-------------

PR: https://git.openjdk.java.net/jdk/pull/3563

From iklam at openjdk.java.net  Wed Apr 21 01:54:07 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 21 Apr 2021 01:54:07 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v2]
In-Reply-To: <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
Message-ID: <rul6dF0s84i60a1pL0opaYJtaORM5HjKmbBnxs3b9wg=.ff99269c-71b0-41aa-8473-63aa8c6a3866@github.com>

On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>> 
>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>> 
>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional comments on failure modes

LGTM.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3580

From dlong at openjdk.java.net  Wed Apr 21 03:23:04 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 21 Apr 2021 03:23:04 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v2]
In-Reply-To: <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
Message-ID: <RXPU-zt69UO90Y86a6pB3PCDqmOKsdMn0qevY552WFs=.15a99173-4e0a-4551-aef4-7429de22ac38@github.com>

On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>> 
>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>> 
>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional comments on failure modes

If this gets backported to an older jdk where CATCH called ShouldNotReachHere() instead of assert(), then it will be a change in behavior, right?

What's the reason for moving the exception throwing into the caller?  Is it necessary or just an optimization?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3580

From jiefu at openjdk.java.net  Wed Apr 21 04:00:11 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 21 Apr 2021 04:00:11 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
Message-ID: <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com>

On Tue, 20 Apr 2021 15:28:43 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> Benchmark Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>>  
>> Optimized:
>> signum intrinsic patch
>> Benchmark Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op
>> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op
>> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op
>> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 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:
> 
>   Add os.arch=="i386" to signum jtreg
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/cpu/x86/x86.ad line 5780:

> 5778: // --------------------------------- Signum ---------------------------
> 5779: 
> 5780: instruct signumF_reg(regF dst, regF zero, regF one, rFlagsReg cr) %{

Do we need `predicate(UseSSE>=2);` here?

src/hotspot/cpu/x86/x86.ad line 5788:

> 5786: 
> 5787:     __ ucomiss($dst$$XMMRegister, $zero$$XMMRegister);
> 5788:     __ jcc(Assembler::parity, exit);

How about checking equal first and then parity?

I think the unordered case is rare in real programs.

src/hotspot/cpu/x86/x86.ad line 5792:

> 5790:     __ movflt($dst$$XMMRegister, $one$$XMMRegister);
> 5791:     __ jcc(Assembler::above, exit);
> 5792:     __ movflt($dst$$XMMRegister, $zero$$XMMRegister);

Is it possible to use just one instruction to assign -1 to $dst?

Maybe, you can try to follow negF_reg/negF_reg_reg.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From jbhateja at openjdk.java.net  Wed Apr 21 05:31:07 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 21 Apr 2021 05:31:07 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <PMeH4jlv-li4aLxa28pPqlYHdv6P03Fm5fM0MTmGcQE=.56c784c5-da79-48b1-822a-d420ecf4c2bb@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
 <RQ-UY2pbK_tM0uClYIX7QkQfklM-mYNFcRhOuU5dYGI=.1e581242-968d-4b8e-b4b2-d208def74cf2@github.com>
 <PMeH4jlv-li4aLxa28pPqlYHdv6P03Fm5fM0MTmGcQE=.56c784c5-da79-48b1-822a-d420ecf4c2bb@github.com>
Message-ID: <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com>

On Tue, 20 Apr 2021 22:19:00 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 5786:
>> 
>>> 5784:   ins_encode %{
>>> 5785:     Label exit;
>>> 5786: 
>> 
>> Can you kindly move this into a macro assembly routine.
>
> Do you mean `instruct signumF_reg`? Please explain your reasoning for the proposed move.

I am referring to moving the instruction sequence into a macro assembly routine for better code sharing, one should be enough for both float and double type, please refer to following snippet for more detail.
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L5672

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From david.holmes at oracle.com  Wed Apr 21 06:19:20 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Apr 2021 16:19:20 +1000
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v2]
In-Reply-To: <RXPU-zt69UO90Y86a6pB3PCDqmOKsdMn0qevY552WFs=.15a99173-4e0a-4551-aef4-7429de22ac38@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
 <RXPU-zt69UO90Y86a6pB3PCDqmOKsdMn0qevY552WFs=.15a99173-4e0a-4551-aef4-7429de22ac38@github.com>
Message-ID: <7ef4daa8-f884-11ad-fe53-c5688f7ed162@oracle.com>

Hi Dean,

Thanks for looking at this.

On 21/04/2021 1:23 pm, Dean Long wrote:
> On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>>>
>>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>>>
>>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself.
>>>
>>> Testing: tiers 1-3
>>>
>>> Thanks,
>>> David
>>
>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Additional comments on failure modes
> 
> If this gets backported to an older jdk where CATCH called ShouldNotReachHere() instead of assert(), then it will be a change in behavior, right?

Right - though there is really no direct reason to backport such 
cleanups. Also Ioi and I were discussing that perhaps we should revert 
the current version of CATCH so it once again aborts in the product VM, 
and then fix up call-sites like these. But these call-sites would 
ideally properly deal with exceptions in regular JavaThreads - somehow.

> What's the reason for moving the exception throwing into the caller?  Is it necessary or just an optimization?

Necessary to get TRAPS out of the method signatures because I'm changing 
TRAPS to be JavaThread (in another issue) and compute_map is not always 
called on a JavaThread.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3580
> 

From david.holmes at oracle.com  Wed Apr 21 06:19:44 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Apr 2021 16:19:44 +1000
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v2]
In-Reply-To: <rul6dF0s84i60a1pL0opaYJtaORM5HjKmbBnxs3b9wg=.ff99269c-71b0-41aa-8473-63aa8c6a3866@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
 <rul6dF0s84i60a1pL0opaYJtaORM5HjKmbBnxs3b9wg=.ff99269c-71b0-41aa-8473-63aa8c6a3866@github.com>
Message-ID: <fc89d5ed-4fd1-0285-8cd3-477df569e226@oracle.com>

On 21/04/2021 11:54 am, Ioi Lam wrote:
> On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>>>
>>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>>>
>>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself.
>>>
>>> Testing: tiers 1-3
>>>
>>> Thanks,
>>> David
>>
>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Additional comments on failure modes
> 
> LGTM.

Thanks Ioi!

David

> -------------
> 
> Marked as reviewed by iklam (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/3580
> 

From yyang at openjdk.java.net  Wed Apr 21 06:40:07 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 21 Apr 2021 06:40:07 GMT
Subject: Integrated: 8265106: IGV: Enforce en-US locale while parsing ideal
 graph
In-Reply-To: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
References: <TSoq_dFnyZdUUCg7WquT5wfOMtX9OkOkvEoo6KE9fQQ=.a66137b5-115d-4098-970a-00f15d8c591c@github.com>
Message-ID: <_17KpTx9Yh2lT7RYtQdI9gstlSgWI8Prxt89KkNqQwI=.6a4faf1d-b128-4a4a-9c36-8f2fd90d2862@github.com>

On Mon, 19 Apr 2021 04:48:07 GMT, Yi Yang <yyang at openjdk.org> wrote:

> IGV is designed to support parsing incomplete XML. However, it does not work for non-English users. See #3071 for detailed reasons. This patch would address it.
> 
> (P.S. Locale.ENGLISH also does not work, see  Philip Helger' [comment](https://stackoverflow.com/questions/18531633/locale-specific-messages-in-xerces-2-11-0-java) on the first answer.)

This pull request has now been integrated.

Changeset: b5c92ca3
Author:    Yi Yang <yyang at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b5c92ca3
Stats:     9 lines in 2 files changed: 9 ins; 0 del; 0 mod

8265106: IGV: Enforce en-US locale while parsing ideal graph

Co-authored-by: Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Reviewed-by: thartmann, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3563

From dholmes at openjdk.java.net  Wed Apr 21 06:42:10 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 21 Apr 2021 06:42:10 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
Message-ID: <hmM5lQ2enhIjBFa3p5w-93830DsDYKAiKMTCAQasP4c=.ad2fe32b-3223-4b60-a033-9935e8c49cc3@github.com>

On Tue, 20 Apr 2021 15:28:43 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> Benchmark Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>>  
>> Optimized:
>> signum intrinsic patch
>> Benchmark Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op
>> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op
>> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op
>> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 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:
> 
>   Add os.arch=="i386" to signum jtreg
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 28:

> 26:  * @test
> 27:  * @summary Test compiler intrinsics for signum
> 28:  * @requires os.arch=="aarch64" | os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64"

Shouldn't this test run successfully on all platforms, even if they don't do anything in response to UseSignumIntrinsic? I can run it today on x86_64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From rcastanedalo at openjdk.java.net  Wed Apr 21 07:30:45 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 21 Apr 2021 07:30:45 GMT
Subject: RFR: 8264842: IGV: different nodes sharing idx are treated as equal
Message-ID: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>

This change replaces `Node::_idx` with a dedicated `Node::_igv_idx` as the internal node identifier for IGV. `_igv_idx` is unique across all phases in a compilation, which prevents IGV from wrongly treating unrelated nodes as if they were the same.`_igv_idx` is proposed instead of `Node::_debug_idx`, which is also unique across phases, for stability (the `_debug_idx` identifiers of a compilation are affected by the entire compilation history) and flexibility (future enhancements such as [JDK-8265587](https://bugs.openjdk.java.net/browse/JDK-8265587) require altering the node identifier in IGV-specific ways).

The following figure illustrates the effect of using `_igv_idx` instead of `_idx` as an internal node identifier. Using  `_idx` (left), node 54 is wrongly treated as created in two different phases (two green circles in the graph snapshot view), whereas using `_igv_idx` (right), node 54 is shown as created once, as expected:

![before-after-fix](https://user-images.githubusercontent.com/8792647/115462349-d624e380-a22a-11eb-8d29-810a5ccbd09c.png)

At the IGV user interface level, this change encapsulates the internal node identifier by showing a "short node text" (configurable from `Tools -> Options`, defaulting to `[idx] [name]`) in all places where the internal identifier was exposed before: edge tooltips, slot tooltips, and the node search results. The code in [ViewPanel.form](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-9b4fd66fc1b7a93a40abcec79b8825db44bdef62f13fede745238c3b87a2ab90) and [ViewPanel.java](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-c8cfda144359ba8b317fd0d02988dc0798418dcd211eb5eb91c3ed94567684d3) is generated by NetBeans 12.3 by editing ViewPanel.java in "Design" mode.

#### Testing

- Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
- Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
- Tested manually, for a few graphs, that nodes are treated as created exactly once by IGV (by selecting single nodes and checking that a single green circle appears in the graph snapshot view, as in the right screenshot above).
- Tested manually that the new `Short Node Text` field in `Tools -> Options` is displayed and stored correctly, and that it is honored by edge tooltips, slot tooltips, and node search results (on Linux and Windows, for JDK 8, 11, and 15).

-------------

Commit messages:
 - Update header
 - Fix spacing in tooltip text
 - Use custom IGV node identifier instead of Node::_idx
 - Encapsulate node identifiers

Changes: https://git.openjdk.java.net/jdk/pull/3593/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3593&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264842
  Stats: 239 lines in 19 files changed: 132 ins; 57 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3593.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3593/head:pull/3593

PR: https://git.openjdk.java.net/jdk/pull/3593

From jiefu at openjdk.java.net  Wed Apr 21 08:41:13 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 21 Apr 2021 08:41:13 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <8f5G7Ec-5E4TnpHeQpYKz-tAqA6y_8PI3gAphHIvbCU=.08f3b508-c5e8-41e1-8c9b-374b31784ee6@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
 <Fw-cC-ivS5FWD2YN5UDVI1EPorXf1nk_1KwM5l4XGiA=.12e66f4c-c654-48ce-be37-86349c72fa48@github.com>
 <8f5G7Ec-5E4TnpHeQpYKz-tAqA6y_8PI3gAphHIvbCU=.08f3b508-c5e8-41e1-8c9b-374b31784ee6@github.com>
Message-ID: <MzoKGBp54I8BOZFokthrKK7R7Czr0ZIEVvoFA_Z4xI8=.1a77718a-e774-4945-aa73-f60406cdc4fe@github.com>

On Tue, 20 Apr 2021 22:39:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> This may be unsafe. AFAIK there is no guarantee about the monotonicity of `Math.pow(x, y)` as y moves from `Math.pow(x, nextAfter?(0.5, -1)` to `Math.pow(x, 0.5)` to `Math.pow(x, nextAfter?(0.5, 1)` for all x. Did anyone look?

Hi @theRealAph ,

I didn't get your point.

Could you please make it more clearer and give us an example?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From aph at openjdk.java.net  Wed Apr 21 08:56:40 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 21 Apr 2021 08:56:40 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <8f5G7Ec-5E4TnpHeQpYKz-tAqA6y_8PI3gAphHIvbCU=.08f3b508-c5e8-41e1-8c9b-374b31784ee6@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
 <Fw-cC-ivS5FWD2YN5UDVI1EPorXf1nk_1KwM5l4XGiA=.12e66f4c-c654-48ce-be37-86349c72fa48@github.com>
 <8f5G7Ec-5E4TnpHeQpYKz-tAqA6y_8PI3gAphHIvbCU=.08f3b508-c5e8-41e1-8c9b-374b31784ee6@github.com>
Message-ID: <mrvWroRJtZxIZLkgv52n6OR5_JM4hCnop04GYgB9TDc=.c64a095b-1dd2-400c-83cf-73868ef720cf@github.com>

On Tue, 20 Apr 2021 22:39:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > This may be unsafe. AFAIK there is no guarantee about the monotonicity of `Math.pow(x, y)` as y moves from `Math.pow(x, nextAfter?(0.5, -1)` to `Math.pow(x, 0.5)` to `Math.pow(x, nextAfter?(0.5, 1)` for all x. Did anyone look?
> 
> Thanks @theRealAph for your review.
> 
> What did you mean by `Math.pow(x, nextAfter?(0.5, -1)` and `Math.pow(x, nextAfter?(0.5, 1)` ?

>From the spec, "errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation."

nextAfter "Returns the floating-point number adjacent to the first argument in the direction of the second argument."

Using sqrt() rather than pow() for pow(x,0.5) will return different results for some arguments. For this optimization you're proposing to be safe, you need to prove that in such cases the "Results must be semi-monotonic" requirement is still satisfied. 

There may exist values of pow(x,0.5) where, if we substitute sqrt() this requirement is not met. I don't immediately know how to prove this does not happen. I think that to do so would require careful analysis.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From goetz.lindenmaier at sap.com  Wed Apr 21 09:17:17 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 21 Apr 2021 09:17:17 +0000
Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error)
 failed: bad dominance
In-Reply-To: <AM4PR02MB305773DD4F4DC15323E6CDC99A499@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB305773DD4F4DC15323E6CDC99A499@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB344306B008EA5DD12BDDDA4EEC479@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi Martin,

I had a look at the change. Looks good.
Especially the code in macro.cpp is correctly adapted.

Best regards
  Goetz

From: Doerr, Martin <martin.doerr at sap.com>
Sent: Monday, April 19, 2021 4:32 PM
To: jdk-updates-dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph <christoph.langer at sap.com>
Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance

Hi,

JDK-8261812 is backported to 11.0.12-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8261812

Original change:
https://git.openjdk.java.net/jdk/commit/2c0507ec

Resolution steps:
compile.hpp:
-  push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry,
-                BasicType bt);
+  static bool push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry,
+                            BasicType bt);
This cleanup is not applicable. Skipped.

macro.cpp:
+        if (is_subword_type(ft)) {
+          n = Compile::narrow_value(ft, n, phi_type, &_igvn, true);
+        }
The surrounding code is different in 11u because of GC related changes. I had to adapt it.

11u backport:
http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/

Please review.

Best regards,
Martin


From jiefu at openjdk.java.net  Wed Apr 21 09:17:28 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 21 Apr 2021 09:17:28 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <mrvWroRJtZxIZLkgv52n6OR5_JM4hCnop04GYgB9TDc=.c64a095b-1dd2-400c-83cf-73868ef720cf@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
 <Fw-cC-ivS5FWD2YN5UDVI1EPorXf1nk_1KwM5l4XGiA=.12e66f4c-c654-48ce-be37-86349c72fa48@github.com>
 <8f5G7Ec-5E4TnpHeQpYKz-tAqA6y_8PI3gAphHIvbCU=.08f3b508-c5e8-41e1-8c9b-374b31784ee6@github.com>
 <mrvWroRJtZxIZLkgv52n6OR5_JM4hCnop04GYgB9TDc=.c64a095b-1dd2-400c-83cf-73868ef720cf@github.com>
Message-ID: <Gyn4CihgtePBXQdyOeOU4ZmcH68X7Bo5rvJnABGKOuc=.745d11bb-4f12-4ab4-b416-9e0a0a5d3750@github.com>

On Wed, 21 Apr 2021 08:44:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > This may be unsafe. AFAIK there is no guarantee about the monotonicity of `Math.pow(x, y)` as y moves from `Math.pow(x, nextAfter?(0.5, -1)` to `Math.pow(x, 0.5)` to `Math.pow(x, nextAfter?(0.5, 1)` for all x. Did anyone look?
> > 
> > 
> > Thanks @theRealAph for your review.
> > What did you mean by `Math.pow(x, nextAfter?(0.5, -1)` and `Math.pow(x, nextAfter?(0.5, 1)` ?
> 
> From the spec, "errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation."
> 
> nextAfter "Returns the floating-point number adjacent to the first argument in the direction of the second argument."
> 
> Using sqrt() rather than pow() for pow(x,0.5) will return different results for some arguments. For this optimization you're proposing to be safe, you need to prove that in such cases the "Results must be semi-monotonic" requirement is still satisfied.
> 
> There may exist values of pow(x,0.5) where, if we substitute sqrt() this requirement is not met. I don't immediately know how to prove this does not happen. I think that to do so would require careful analysis.

Hi @theRealAph ,

Thanks for your clarification.

Actually, this optimization has been long used for Java.
And we don't see any problems of it, right?
So I don't think it will cause problems in the future.

What do you think of the same optimization in the HotSpot which has been applied more than 10 years ago?
  https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L499

And also the same optimization in the Java lib?
 https://github.com/openjdk/jdk/blob/d84a7e55be40eae57b6c322694d55661a5053a55/src/java.base/share/classes/java/lang/FdLibm.java#L366

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From vlivanov at openjdk.java.net  Wed Apr 21 09:28:08 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 21 Apr 2021 09:28:08 GMT
Subject: RFR: 8241502: Migrate x86_64.ad to MacroAssembler [v7]
In-Reply-To: <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
Message-ID: <ZuLh6nw0M8OsyAub7F8h-SL8T7Tx5tf2qANP_NNldkI=.06c62aef-950b-4166-b90d-106de81d8424@github.com>

On Thu, 15 Apr 2021 18:28:02 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use cdql/cdqq implemented in MacroAssembler.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2420

From martin.doerr at sap.com  Wed Apr 21 09:40:25 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 21 Apr 2021 09:40:25 +0000
Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error)
 failed: bad dominance
In-Reply-To: <AM0PR0202MB344306B008EA5DD12BDDDA4EEC479@AM0PR0202MB3443.eurprd02.prod.outlook.com>
References: <AM4PR02MB305773DD4F4DC15323E6CDC99A499@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM0PR0202MB344306B008EA5DD12BDDDA4EEC479@AM0PR0202MB3443.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3057C8E5B511828EF78586039A479@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi G?tz,

thanks for the review!

Best regards,
Martin


From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Sent: Mittwoch, 21. April 2021 11:17
To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RE: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance

Hi Martin,

I had a look at the change. Looks good.
Especially the code in macro.cpp is correctly adapted.

Best regards
  Goetz

From: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Sent: Monday, April 19, 2021 4:32 PM
To: jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>>
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>; Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance

Hi,

JDK-8261812 is backported to 11.0.12-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8261812

Original change:
https://git.openjdk.java.net/jdk/commit/2c0507ec

Resolution steps:
compile.hpp:
-  push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry,
-                BasicType bt);
+  static bool push_thru_add(PhaseGVN* phase, Node* z, const TypeInteger* tz, const TypeInteger*& rx, const TypeInteger*& ry,
+                            BasicType bt);
This cleanup is not applicable. Skipped.

macro.cpp:
+        if (is_subword_type(ft)) {
+          n = Compile::narrow_value(ft, n, phi_type, &_igvn, true);
+        }
The surrounding code is different in 11u because of GC related changes. I had to adapt it.

11u backport:
http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/

Please review.

Best regards,
Martin


From dlong at openjdk.java.net  Wed Apr 21 09:40:49 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 21 Apr 2021 09:40:49 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v2]
In-Reply-To: <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
Message-ID: <1vM-RogqXpz7izNhHR-toQyyNmqGq-VEYSrhVcjU5Fw=.f1597299-3ad8-4e84-b6f9-f2590f59dd1a@github.com>

On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>> 
>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>> 
>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional comments on failure modes

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3580

From aph at openjdk.java.net  Wed Apr 21 09:49:26 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 21 Apr 2021 09:49:26 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <Gyn4CihgtePBXQdyOeOU4ZmcH68X7Bo5rvJnABGKOuc=.745d11bb-4f12-4ab4-b416-9e0a0a5d3750@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
 <Fw-cC-ivS5FWD2YN5UDVI1EPorXf1nk_1KwM5l4XGiA=.12e66f4c-c654-48ce-be37-86349c72fa48@github.com>
 <8f5G7Ec-5E4TnpHeQpYKz-tAqA6y_8PI3gAphHIvbCU=.08f3b508-c5e8-41e1-8c9b-374b31784ee6@github.com>
 <mrvWroRJtZxIZLkgv52n6OR5_JM4hCnop04GYgB9TDc=.c64a095b-1dd2-400c-83cf-73868ef720cf@github.com>
 <Gyn4CihgtePBXQdyOeOU4ZmcH68X7Bo5rvJnABGKOuc=.745d11bb-4f12-4ab4-b416-9e0a0a5d3750@github.com>
Message-ID: <MERbV6xTmzKvV7p-IkUbt9QtDxdkCL6PkZykeR8LTg0=.057e661b-a44c-4a2c-b482-555cfce832f7@github.com>

On Wed, 21 Apr 2021 09:10:08 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> 
> Actually, this optimization has been long used for Java.
> And we don't see any problems of it, right?
> So I don't think it will cause problems in the future.
> 
> What do you think of the same optimization in the HotSpot which has been applied more than 10 years ago?
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L499
> 
> And also the same optimization in the Java lib?

OK, fair enough. I still don't know if this optimization is safe, but I guess (?) the analysis was done at the time. In any case, given that this optimization is already done elsewhere, your patch won't make anything any worse.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From yyang at openjdk.java.net  Wed Apr 21 10:07:38 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 21 Apr 2021 10:07:38 GMT
Subject: RFR: 8265322: C2: Simplify control inputs for
 BarrierSetC2::obj_allocate
In-Reply-To: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
References: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
Message-ID: <GJ-4IC_uCZA0YqI6EdCQPe4tGdLpZezWBq6GkiWvSOQ=.a78ff8a9-f77a-4acd-a1cb-31622d3771d7@github.com>

On Fri, 16 Apr 2021 03:06:19 GMT, Yi Yang <yyang at openjdk.org> wrote:

> While just using BarrierSetC2::obj_allocate in https://github.com/openjdk/valhalla/pull/385, I noticed the control input `ctrl` for obj_allocate is not so much necessary. This PR simplifies control inputs for BarrierSetC2::obj_allocate. In most cases, it doesn't change anything since `toobig_false` is equivalent to `ctrl`. In other cases, `toobig_false` is created for Unsafe.allocateInstance while instance size is not statically known, `ctrl` would become control input of IfNode whose projects are `toobig_false` and `toobig_true`, old eden_end and old_eden_top can simply accept `toobig_false` as their control input rather than `ctrl`.

Can hotspot-gc folks help review this PR?
 
Thanks!??
Yang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3529

From jiefu at openjdk.java.net  Wed Apr 21 10:14:42 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 21 Apr 2021 10:14:42 GMT
Subject: RFR: 8264945: Optimize the code-gen for Math.pow(x, 0.5) [v2]
In-Reply-To: <MERbV6xTmzKvV7p-IkUbt9QtDxdkCL6PkZykeR8LTg0=.057e661b-a44c-4a2c-b482-555cfce832f7@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
 <0K8-_7K7GG6xahHqFOcQTbq7WkYcifang8lYtBkpcB4=.3175b556-c49e-44df-9af4-934d5a9bc067@github.com>
 <Fw-cC-ivS5FWD2YN5UDVI1EPorXf1nk_1KwM5l4XGiA=.12e66f4c-c654-48ce-be37-86349c72fa48@github.com>
 <8f5G7Ec-5E4TnpHeQpYKz-tAqA6y_8PI3gAphHIvbCU=.08f3b508-c5e8-41e1-8c9b-374b31784ee6@github.com>
 <mrvWroRJtZxIZLkgv52n6OR5_JM4hCnop04GYgB9TDc=.c64a095b-1dd2-400c-83cf-73868ef720cf@github.com>
 <Gyn4CihgtePBXQdyOeOU4ZmcH68X7Bo5rvJnABGKOuc=.745d11bb-4f12-4ab4-b416-9e0a0a5d3750@github.com>
 <MERbV6xTmzKvV7p-IkUbt9QtDxdkCL6PkZykeR8LTg0=.057e661b-a44c-4a2c-b482-555cfce832f7@github.com>
Message-ID: <QdS2n7w95AIGW2EsT_WAqXOnFU65Qp2-o64sz-flJhI=.ce5e9e32-1006-4f74-821c-2d2956556aec@github.com>

On Wed, 21 Apr 2021 09:46:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Actually, this optimization has been long used for Java.
> > And we don't see any problems of it, right?
> > So I don't think it will cause problems in the future.
> > What do you think of the same optimization in the HotSpot which has been applied more than 10 years ago?
> > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L499
> > And also the same optimization in the Java lib?
> 
> OK, fair enough. I still don't know if this optimization is safe, but I guess (?) the analysis was done at the time. In any case, given that this optimization is already done elsewhere, your patch won't make anything any worse.

Thanks @theRealAph .

And thank you all again.
Much has been learned while discussing with you.

Best regards,
Jie

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From jiefu at openjdk.java.net  Wed Apr 21 10:14:43 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 21 Apr 2021 10:14:43 GMT
Subject: Integrated: 8264945: Optimize the code-gen for Math.pow(x, 0.5)
In-Reply-To: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
References: <QrYCiqMi_knVlfj3TIiu813kIhz3NwWJrtTKqnH2PWc=.e01652af-a809-414a-82dd-494053b9f368@github.com>
Message-ID: <6O320Cil6_PbJZ8-JlFh9rGsOCLcEjPFiL5bTDUsw7g=.20e02cb8-5d61-4c2b-907e-04b25beb9484@github.com>

On Fri, 9 Apr 2021 02:19:10 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to optimize the code-gen for Math.pow(x, 0.5).
> And 7x ~ 14x performance improvement is observed by the jmh micro-benchmarks.
> 
> While I was optimizing a machine learning program, I found both Math.pow(x, 2) and Math.pow(x, 0.5) are used.
> To my surprise, C2 just optimizes the case for Math.pow(x, 2) [1], but still not for Math.pow(x, 0.5) yet.
> 
> The patch just replace Math.pow(x, 0.5) with Math.sqrt(x).
> 
> Before:
> 
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45525.117 ? 11.686  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> Benchmark                     (seed)   Mode  Cnt      Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  45509.317 ?  6.581  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8      0.031 ?  0.001  ops/ms
> 
> 
> After:
> 
> Benchmark                     (seed)   Mode  Cnt       Score     Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343354.892 ? 362.900  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?   0.001  ops/mso
> 
> Benchmark                     (seed)   Mode  Cnt       Score    Error   Units
> MathBench.powDouble0Dot5           0  thrpt    8  343421.559 ? 49.326  ops/ms
> MathBench.powDouble0Dot5Loop       0  thrpt    8       0.457 ?  0.001  ops/ms
> 
> 
> Testing:
>   - tier1~3 on Linux/x64
> 
> Thanks,
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1680

This pull request has now been integrated.

Changeset: ed477da9
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed477da9
Stats:     75 lines in 2 files changed: 61 ins; 13 del; 1 mod

8264945: Optimize the code-gen for Math.pow(x, 0.5)

Reviewed-by: neliasso, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3404

From dnsimon at openjdk.java.net  Wed Apr 21 10:18:07 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 21 Apr 2021 10:18:07 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic Class-File
 Constants
Message-ID: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>

This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).

When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.

When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.

-------------

Commit messages:
 - add basic JVMCI support for JEP 309: Dynamic Class-File Constants

Changes: https://git.openjdk.java.net/jdk/pull/3578/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3578&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265480
  Stats: 377 lines in 10 files changed: 353 ins; 10 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3578.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3578/head:pull/3578

PR: https://git.openjdk.java.net/jdk/pull/3578

From rcastanedalo at openjdk.java.net  Wed Apr 21 11:42:37 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 21 Apr 2021 11:42:37 GMT
Subject: RFR: 8264842: IGV: different nodes sharing idx are treated as
 equal
In-Reply-To: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
References: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
Message-ID: <zEq_p6E5fSvtRxd3cM39Ca5VWF-k115ErJCYgnS9yfQ=.74ac1a1f-bec7-4b20-a71a-900927e82a12@github.com>

On Tue, 20 Apr 2021 20:33:25 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change replaces `Node::_idx` with a dedicated `Node::_igv_idx` as the internal node identifier for IGV. `_igv_idx` is unique across all phases in a compilation, which prevents IGV from wrongly treating unrelated nodes as if they were the same.`_igv_idx` is proposed instead of `Node::_debug_idx`, which is also unique across phases, for stability (the `_debug_idx` identifiers of a compilation are affected by the entire compilation history) and flexibility (future enhancements such as [JDK-8265587](https://bugs.openjdk.java.net/browse/JDK-8265587) require altering the node identifier in IGV-specific ways).
> 
> The following figure illustrates the effect of using `_igv_idx` instead of `_idx` as an internal node identifier. Using  `_idx` (left), node 54 is wrongly treated as created in two different phases (two green circles in the graph snapshot view), whereas using `_igv_idx` (right), node 54 is shown as created once, as expected:
> 
> ![before-after-fix](https://user-images.githubusercontent.com/8792647/115462349-d624e380-a22a-11eb-8d29-810a5ccbd09c.png)
> 
> At the IGV user interface level, this change encapsulates the internal node identifier by showing a "short node text" (configurable from `Tools -> Options`, defaulting to `[idx] [name]`) in all places where the internal identifier was exposed before: edge tooltips, slot tooltips, and the node search results. The code in [ViewPanel.form](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-9b4fd66fc1b7a93a40abcec79b8825db44bdef62f13fede745238c3b87a2ab90) and [ViewPanel.java](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-c8cfda144359ba8b317fd0d02988dc0798418dcd211eb5eb91c3ed94567684d3) is generated by NetBeans 12.3 by editing ViewPanel.java in "Design" mode.
> 
> #### Testing
> 
> - Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
> - Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
> - Tested manually, for a few graphs, that nodes are treated as created exactly once by IGV (by selecting single nodes and checking that a single green circle appears in the graph snapshot view, as in the right screenshot above).
> - Tested manually that the new `Short Node Text` field in `Tools -> Options` is displayed and stored correctly, and that it is honored by edge tooltips, slot tooltips, and node search results (on Linux and Windows, for JDK 8, 11, and 15).

This change has a side benefit: nodes that are renumbered by C2 (by calling `Node::set_idx()`) keep the same internal `Node::_igv_idx` value, and get treated as if they were the same node by IGV. This is illustrated in the following screenshot, where the selection of a graph subset is kept between "Incremental Boxing Inline" and "Before beautify loops" despite all nodes in the selection being renumbered (by `PhaseRenumberLive::PhaseRenumberLive()`):

![before-after-renumbering](https://user-images.githubusercontent.com/8792647/115546708-a36c0100-a2a5-11eb-88bc-1f26c5029df3.png)

Preserving node equivalence in more complex transformations (matching) is proposed in a separate RFE ([JDK-8265587](https://bugs.openjdk.java.net/browse/JDK-8265587)).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3593

From duke at openjdk.java.net  Wed Apr 21 13:21:39 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 21 Apr 2021 13:21:39 GMT
Subject: Withdrawn: 8259383: AsyncGetCallTrace() crashes sporadically
In-Reply-To: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com>
References: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com>
Message-ID: <6hOp3Z-00yD5XS_sJ0LKViyBLSg8-F0AsxZuNep9TkY=.820f279d-3fe0-4df9-a236-67fb5ed17e9e@github.com>

On Mon, 11 Jan 2021 18:39:41 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Hi,
> may I please ask the community to review this small fix? It closes another hole in AsyncGetCallTrace(). 
> Thanks a lot!
> Lutz

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2032

From coleenp at openjdk.java.net  Wed Apr 21 14:19:44 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 21 Apr 2021 14:19:44 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v2]
In-Reply-To: <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <ACc3QfE2ice7WNwLAG49ZgTXYlJnmF1s7Xq3SlQwOec=.4fe46881-c1be-416c-98a5-fb170b6b11b7@github.com>
Message-ID: <6b5Ra0eTA240RpMbkGThOFJ7pRef4v0icuMIX7guLTM=.8f5a5bf9-cd24-472c-a259-29664b0eb903@github.com>

On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>> 
>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>> 
>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional comments on failure modes

This looks good to me other than changing asserts to fatals.

src/hotspot/share/ci/ciMethod.cpp line 307:

> 305:       // Failure is only possible for a resource-area OOM, or malformed bytecode
> 306:       // with verification disabled.
> 307:       assert(false, "Unexpected exception from compute_map");

Since CATCH was only recently changed from fatal to assert, making these fatal() wouldn't be a change in behavior and that's what this should do.

src/hotspot/share/interpreter/oopMapCache.cpp line 115:

> 113:       // Failure is only possible for a resource-area OOM, or malformed bytecode
> 114:       // with verification disabled.
> 115:       assert(false, "Unexpected exception from compute_map");

same here, and below, should be fatal.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3580

From ddong at openjdk.java.net  Wed Apr 21 15:24:42 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 21 Apr 2021 15:24:42 GMT
Subject: RFR: 8265129: Add intrinsic support for JVM.getClassId
In-Reply-To: <WRTO3ij4-ef6lLk8NMQWGkmd68vFfqLICYU9nIakgOU=.d10e0f2f-087c-43f9-b08a-86c51919ac44@github.com>
References: <WRTO3ij4-ef6lLk8NMQWGkmd68vFfqLICYU9nIakgOU=.d10e0f2f-087c-43f9-b08a-86c51919ac44@github.com>
Message-ID: <urEngraJD1CMaUzC4E-i0Yl2LVqmDkrWBfCZL3ikv40=.b7fc941b-d306-427c-858e-234166eff0b3@github.com>

On Tue, 13 Apr 2021 16:52:44 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> 8265129: Add intrinsic support for JVM.getClassId

Hi,

Could I have a review of this change that adding intrinsic support for JVM.getClassId.

In the current patch, I didn't completely implement c1 intrinsic support on arm/ppc/s390 platform, but I believe it can be easily achieved,
but before that, I hope someone can do a preliminary review of this patch because I am not familiar with the implementation of jit.

JMH benchmark:

@State(Scope.Benchmark)
public class MyBenchmark {

    @Setup
    public void setup() {
        JVM.getJVM().createNativeJFR();
    }

    @Benchmark
    @Fork(value=1, jvmArgs = {"--add-exports", "jdk.jfr/jdk.jfr.internal=ALL-UNNAMED"})
    @Warmup(iterations = 5, time = 1)
    public void testIntrinsic(Blackhole bh) {
        bh.consume(JVM.getClassId(boolean.class));
        bh.consume(JVM.getClassId(void.class));
        bh.consume(JVM.getClassId(MyBenchmark.class));
    }

    @Benchmark
    @Fork(value=1, jvmArgs = {"--add-exports", "jdk.jfr/jdk.jfr.internal=ALL-UNNAMED"})
    @Warmup(iterations = 5, time = 1)
    public void testNoIntrinsic(Blackhole bh) {
        bh.consume(JVM.getClassIdNonIntrinsic(boolean.class));
        bh.consume(JVM.getClassIdNonIntrinsic(void.class));
        bh.consume(JVM.getClassIdNonIntrinsic(MyBenchmark.class));
    }

    @TearDown
    public void tearDown() {
      if (JVM.getClassIdNonIntrinsic(boolean.class) != JVM.getClassId(boolean.class)
          || JVM.getClassIdNonIntrinsic(void.class) != JVM.getClassId(void.class)
          || JVM.getClassIdNonIntrinsic(MyBenchmark.class) != JVM.getClassId(MyBenchmark.class)) {
          throw new RuntimeException();
      }
    }
}


result on x86_64:

Benchmark                           Mode  Samples          Score  Score error  Units
o.s.MyBenchmark.testIntrinsic      thrpt       20  195662934.056   566744.281  ops/s
o.s.MyBenchmark.testNoIntrinsic    thrpt       20    7997200.373     6424.038  ops/s

-------------

PR: https://git.openjdk.java.net/jdk/pull/3470

From ddong at openjdk.java.net  Wed Apr 21 15:24:42 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 21 Apr 2021 15:24:42 GMT
Subject: RFR: 8265129: Add intrinsic support for JVM.getClassId
Message-ID: <WRTO3ij4-ef6lLk8NMQWGkmd68vFfqLICYU9nIakgOU=.d10e0f2f-087c-43f9-b08a-86c51919ac44@github.com>

8265129: Add intrinsic support for JVM.getClassId

-------------

Commit messages:
 - disable c1 intrinsic support on arm, ppc, s390 and enable the related test case
 - fix build error
 - rename JfrKlassEnqueueStub
 - rename jfr_enqueue_klass to trace_id_load_barrier and remove unused parameter
 - 8265129: Add intrinsic support for JVM.getClassId

Changes: https://git.openjdk.java.net/jdk/pull/3470/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3470&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265129
  Stats: 337 lines in 20 files changed: 279 ins; 28 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3470.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3470/head:pull/3470

PR: https://git.openjdk.java.net/jdk/pull/3470

From iignatyev at openjdk.java.net  Wed Apr 21 15:40:32 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 21 Apr 2021 15:40:32 GMT
Subject: RFR: 8264632: compiler/codecache/jmx/PoolsIndependenceTest.java
 fails to Notification not being received
In-Reply-To: <Tve8mb_uD2jmhBW2O8AMYO6H40wR-fPogYxh-WpEpbE=.297df043-078b-4eb2-aae2-80a628f458be@github.com>
References: <Tve8mb_uD2jmhBW2O8AMYO6H40wR-fPogYxh-WpEpbE=.297df043-078b-4eb2-aae2-80a628f458be@github.com>
Message-ID: <xg1fVbT5Q1Tx7TXIlxhav7ka3v81aYOy9umlW6XK8NQ=.c8deb11a-8179-4025-ba49-f24b402bd88d@github.com>

On Tue, 20 Apr 2021 18:04:07 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> Hi all,
> 
> May I ask for reviews for this change? 
> 
> **The case**
> https://bugs.openjdk.java.net/browse/JDK-8264632
> 
> **The problem**
> The test calls for MemoryPoolMXBean.setUsageThreshold() and expects a Notification get fired when the threshold is breached. The Notification is never received.
> 
> The failure most probably is caused by the combination of following events:
> 1. Some threshold has already breached (caused by some other tests); 
> 2. In this case MemoryPoolMXBean never fires subsequent Notifications until the usage is less than a set threshold;
> 3. The usage manages to grow up between these two lines[1]:
> 
> final long usageThresholdLimit = bean.getUsage().getUsed() + 1;
> bean.setUsageThreshold(usageThresholdLimit);
> 
> 4. The usage has never fallen below any set threshold and therefore Notification is never sent. Setting usageThresholdLimit to 0 doesn't clear up the situation "Notification has already been sent" either.
> 
> [1] Very common, happens almost every time during my testing - the code cache usage grows up quickly at VM start.
> 
> **Proposed solution:**
> 1. Before the actual test, I set the usageThresholdLimit to max. possible value;
> 2. This causes the current usage to appear below the threshold and therefore the "Notification has already been sent" state is cleared;
> 3. The monitoring is then switched off (by setting usageThresholdLimit to 0), as at the VM start.
> 
> **Testing**
> 1. Preemptive breaching of some threshold causes the problem for non-modified test.
> 2. The modified test has been tested with debug versions of macosx, windows, linux x64 builds and a linux-aarch64-debug build.
> 
> Thanks,
> Evgeny.

Hi Evgeny,

I'm sorry but I don't understand your root-cause analysis (and hence can't review the patch), could you please elaborate on what you mean by some other tests? as far as I can see all test actions in `PoolsIndependenceTest` are run as `@run main/othervm`, so they are executed in a fresh JVM, in other words, there were no tests which got exected before `compiler.codecache.jmx.PoolsIndependenceTest ` and no other tests are run concurrently to it.

Cheers,
-- Igor

-------------

PR: https://git.openjdk.java.net/jdk/pull/3592

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 16:23:38 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 16:23:38 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <hmM5lQ2enhIjBFa3p5w-93830DsDYKAiKMTCAQasP4c=.ad2fe32b-3223-4b60-a033-9935e8c49cc3@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
 <hmM5lQ2enhIjBFa3p5w-93830DsDYKAiKMTCAQasP4c=.ad2fe32b-3223-4b60-a033-9935e8c49cc3@github.com>
Message-ID: <k0U_LFCJ6Qaux1kKSxDDaFb9rlNfv92GrY3NarZdiac=.e8f936b7-a87f-4e4f-91f4-d59031654798@github.com>

On Wed, 21 Apr 2021 06:38:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add os.arch=="i386" to signum jtreg
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 28:
> 
>> 26:  * @test
>> 27:  * @summary Test compiler intrinsics for signum
>> 28:  * @requires os.arch=="aarch64" | os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64"
> 
> Shouldn't this test run successfully on all platforms, even if they don't do anything in response to UseSignumIntrinsic? I can run it today on x86_64.

Hi @dholmes-ora. I have not done negative testing on any platform using TestSignumIntrinsic.java. I'm not the original author, but what you say makes sense after some thought. I'll try an easy test, remove this line and see if presubmit tests pass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 16:50:35 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 16:50:35 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
 <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com>
Message-ID: <0GErbVcHiUYxfrFLooYD5wFx5pKa6Lavi7zKszA1AXc=.9ba89489-5411-431e-a3a5-3b59c5bbf49b@github.com>

On Wed, 21 Apr 2021 03:48:57 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add os.arch=="i386" to signum jtreg
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> src/hotspot/cpu/x86/x86.ad line 5780:
> 
>> 5778: // --------------------------------- Signum ---------------------------
>> 5779: 
>> 5780: instruct signumF_reg(regF dst, regF zero, regF one, rFlagsReg cr) %{
> 
> Do we need `predicate(UseSSE>=2);` here?

It seems ucomiss is SSE, but ucomisd is SSE2. I will add a SSE predicate to `instruct signumF_reg` and an SSE2 predicate to `instruct signumD_reg`. Thanks for the suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 16:59:39 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 16:59:39 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <0GErbVcHiUYxfrFLooYD5wFx5pKa6Lavi7zKszA1AXc=.9ba89489-5411-431e-a3a5-3b59c5bbf49b@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
 <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com>
 <0GErbVcHiUYxfrFLooYD5wFx5pKa6Lavi7zKszA1AXc=.9ba89489-5411-431e-a3a5-3b59c5bbf49b@github.com>
Message-ID: <o1OL2FjInpZr44_JMCDL35rwdwnsyI-qo2gHdh2RzYc=.aca967be-d884-430b-a999-9b07bf9d77af@github.com>

On Wed, 21 Apr 2021 16:47:20 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 5780:
>> 
>>> 5778: // --------------------------------- Signum ---------------------------
>>> 5779: 
>>> 5780: instruct signumF_reg(regF dst, regF zero, regF one, rFlagsReg cr) %{
>> 
>> Do we need `predicate(UseSSE>=2);` here?
>
> It seems ucomiss is SSE, but ucomisd is SSE2. I will add a SSE predicate to `instruct signumF_reg` and an SSE2 predicate to `instruct signumD_reg`. Thanks for the suggestion.

It looks like subss, subsd are also SSE, SSE2 respectively.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From kvn at openjdk.java.net  Wed Apr 21 17:08:35 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Apr 2021 17:08:35 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v7]
In-Reply-To: <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
Message-ID: <4dzEqTrzWhq4HseP_sXQIWhKEUWDO8iiE1x9y29mFvI=.2b6d6ba9-2e7b-4bce-b22f-bfa3b89810d2@github.com>

On Thu, 15 Apr 2021 18:28:02 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use cdql/cdqq implemented in MacroAssembler.

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 17:29:31 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 17:29:31 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
 <RQ-UY2pbK_tM0uClYIX7QkQfklM-mYNFcRhOuU5dYGI=.1e581242-968d-4b8e-b4b2-d208def74cf2@github.com>
 <PMeH4jlv-li4aLxa28pPqlYHdv6P03Fm5fM0MTmGcQE=.56c784c5-da79-48b1-822a-d420ecf4c2bb@github.com>
 <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com>
Message-ID: <PiSIVj94iTW3hzwa3xfRmnled8s2VYt_DwYwKfVqkkA=.e13b7684-1058-4ae7-83e9-0574c2401f9e@github.com>

On Wed, 21 Apr 2021 05:28:38 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Do you mean `instruct signumF_reg`? Please explain your reasoning for the proposed move.
>
> I am referring to moving the instruction sequence into a macro assembly routine for better code sharing, one should be enough for both float and double type, please refer to following snippet for more detail.
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L5672

Hi @jatin-bhateja your original request was quite unclear. The highlighting of the code was incorrect and the use of 'this' made it unclear what you were suggesting and you did not explain a reason for the suggestion. 

> Can you kindly move **this** into a macro assembly routine.

Seeing "better code sharing" as the reason it's unclear to me if the proposed refactor results in any meaningful benefit for the work involved. It's also unclear if there are any hard code structure or style issues that would necessitate the move.

The refactor you suggest calls for the instruction sequences here to be moved into a src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp function that is then called here. Inside that function there is a selection between float and double but otherwise stays the same except one is formatted .AD and one is .CPP/.HPP. 

If I am doing this refactor for `instruct signumF_reg` and `instruct signumD_reg` to cut down on code duplication, I see that as close to a wash for saving of code lines and effort involved. I also think this would make the code more complex to read.

However if there are strong opinions as to why this is necessary I'd be happy to hear them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 17:38:03 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 17:38:03 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v3]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <8HCZEiL6_Gfv36clgI91Okyzf0zOp1VulIgLRe-3Lic=.a03d4ce7-71b3-44ea-bca8-cef03f6c70fe@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>  
> Optimized:
> signum intrinsic patch
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op
> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op
> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op
> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 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 two additional commits since the last revision:

 - Remove requires os.arch from TestSignumIntrinsic
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Add predicate to signum intrinsics
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/99a2971d..a6d670be

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=01-02

  Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From iveresov at openjdk.java.net  Wed Apr 21 16:38:32 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 21 Apr 2021 16:38:32 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled [v2]
In-Reply-To: <nTmx66kTGCytWWTwqLBsM29XHW3YgvCF0YlHoYWGM2g=.1204b6ad-883d-43a6-8848-bd32002a8943@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
 <nTmx66kTGCytWWTwqLBsM29XHW3YgvCF0YlHoYWGM2g=.1204b6ad-883d-43a6-8848-bd32002a8943@github.com>
Message-ID: <5sWw4sUzLm7XOpa2hF42gwE4BG9KqrgRB-w1GKkAXIM=.b19e4639-9b05-4dac-a2d3-747f921ace80@github.com>

On Mon, 19 Apr 2021 01:23:06 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

>> On MIPS64 platform has not impliment C1,only has C2.
>>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462
>
> SUN Guoyun 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.

Let me do some testing just in case, I'll push it if it's clean.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3449

From kvn at openjdk.java.net  Wed Apr 21 18:20:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Apr 2021 18:20:38 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v7]
In-Reply-To: <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
Message-ID: <YtrWAu16lkyYg25-vZ2M851TuSy0-J2xa8ldq9CszoQ=.9a2f5f83-0ae8-4e59-a2c1-2f646090a3c4@github.com>

On Thu, 15 Apr 2021 18:28:02 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use cdql/cdqq implemented in MacroAssembler.

I will sponsor it after my testing is passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 18:44:19 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 18:44:19 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v2]
In-Reply-To: <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
 <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com>
Message-ID: <rm1yC7NQowSyeqAfbFj9jR3B97pMp9OXac1ERflzT7Q=.0c4c5e0e-96be-4400-8d1a-c91e90bd65b3@github.com>

On Wed, 21 Apr 2021 03:56:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add os.arch=="i386" to signum jtreg
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> src/hotspot/cpu/x86/x86.ad line 5788:
> 
>> 5786: 
>> 5787:     __ ucomiss($dst$$XMMRegister, $zero$$XMMRegister);
>> 5788:     __ jcc(Assembler::parity, exit);
> 
> How about checking equal first and then parity?
> 
> I think the unordered case is rare in real programs.

+1

> src/hotspot/cpu/x86/x86.ad line 5792:
> 
>> 5790:     __ movflt($dst$$XMMRegister, $one$$XMMRegister);
>> 5791:     __ jcc(Assembler::above, exit);
>> 5792:     __ movflt($dst$$XMMRegister, $zero$$XMMRegister);
> 
> Is it possible to use just one instruction to assign -1 to $dst?
> 
> Maybe, you can try to follow negF_reg/negF_reg_reg.

Good idea. Changed to use `xorps($dst$$XMMRegister, ExternalAddress(float_signflip()));` and `xorpd($dst$$XMMRegister, ExternalAddress(double_signflip()));`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 18:46:46 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 18:46:46 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v4]
In-Reply-To: <MqGcOSqy_ASo2Kn4_Mab1HVdHk2U9Xji2p9xUKBgpDE=.4f971d84-bc26-4082-9101-9faa57f87571@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <MqGcOSqy_ASo2Kn4_Mab1HVdHk2U9Xji2p9xUKBgpDE=.4f971d84-bc26-4082-9101-9faa57f87571@github.com>
Message-ID: <0VJzL5kKixle3AEe3M6VefPBVAehsEepNrFSyumpoxM=.560b904f-7ca9-42cc-ad3f-684b8b86313b@github.com>

On Wed, 21 Apr 2021 17:47:12 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:
> 
>   Fix predicate
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Updated benchmarks from patch updated from comments of @DamonFool:

Benchmark                       Mode  Cnt  Score   Error  Units
Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  ns/op


Updated Summary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 17:47:12 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 17:47:12 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v4]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <MqGcOSqy_ASo2Kn4_Mab1HVdHk2U9Xji2p9xUKBgpDE=.4f971d84-bc26-4082-9101-9faa57f87571@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>  
> Optimized:
> signum intrinsic patch
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op
> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op
> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op
> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 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:

  Fix predicate
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/a6d670be..0349468b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 18:44:14 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 18:44:14 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v5]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <4KS_ollgdqiNeQgI-XB2AKVJwpgtTo8lRRCwUvqTryk=.8597bbde-a56b-4d2a-a59c-8e80c83b3ec2@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>  
> Optimized:
> signum intrinsic patch
> Benchmark Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op
> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op
> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op
> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 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 two additional commits since the last revision:

 - Reorder jcc equal,parity
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Use xorp to negate 1
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/0349468b..895eab4d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=03-04

  Stats: 8 lines in 1 file changed: 2 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From kvn at openjdk.java.net  Wed Apr 21 19:15:35 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Apr 2021 19:15:35 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v7]
In-Reply-To: <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
Message-ID: <jA4z4TTkOschrEzjugkWKP2tRh3MQsSp8bEBN0LATBQ=.586ae71e-a60c-4a85-b44e-28e09bfb951a@github.com>

On Thu, 15 Apr 2021 18:28:02 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use cdql/cdqq implemented in MacroAssembler.

Please, fix build failure and run testing on Windows.

Build failed on Windows:

t:\workspace\open\src\hotspot\cpu\x86\assembler_x86.cpp(10877): error C2220: the following warning is treated as an error
t:\workspace\open\src\hotspot\cpu\x86\assembler_x86.cpp(10877): warning C4309: 'argument': truncation of constant value

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2420

From kvn at openjdk.java.net  Wed Apr 21 18:43:35 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Apr 2021 18:43:35 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants
In-Reply-To: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
Message-ID: <5Eikbjz2SDs7HNnz8eBJe_1C-bVf6OtjX1_Gsu4uNec=.30fbcd94-a99e-4bff-acc0-52ff615ed977@github.com>

On Mon, 19 Apr 2021 21:31:04 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
> 
> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
> 
> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.

Good. Please, update copyright year in files you touched.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3578

From dnsimon at openjdk.java.net  Wed Apr 21 19:57:05 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 21 Apr 2021 19:57:05 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v2]
In-Reply-To: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
Message-ID: <Xw6y8VDi_uOka1FLF_9cSHyfhSqhE55TwANZb04y1Mo=.f861c95a-78da-41cb-a335-b49248fbf12d@github.com>

> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
> 
> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
> 
> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  fixed date in copyright headers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3578/files
  - new: https://git.openjdk.java.net/jdk/pull/3578/files/0a9e1d32..6d8d4b49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3578&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3578&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3578.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3578/head:pull/3578

PR: https://git.openjdk.java.net/jdk/pull/3578

From github.com+2249648+johntortugo at openjdk.java.net  Wed Apr 21 20:22:30 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Wed, 21 Apr 2021 20:22:30 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v7]
In-Reply-To: <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <A2xgEaXl7AgZMaOVWoPGg0w3jYi76Yc4L2j07dhDFRY=.f30e47ff-caa1-4de4-a437-77de5dd187d7@github.com>
Message-ID: <NJWwXulEsfOfcNQTr52dC7F11EJODj5Se1y0T9iqFVg=.8b9e2456-b08a-49fd-9968-b01647c2f8cf@github.com>

On Thu, 15 Apr 2021 18:28:02 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use cdql/cdqq implemented in MacroAssembler.

Thank you, Vladimir. I'll take a look on that!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From psandoz at openjdk.java.net  Wed Apr 21 20:26:10 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 21 Apr 2021 20:26:10 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v2]
In-Reply-To: <Xw6y8VDi_uOka1FLF_9cSHyfhSqhE55TwANZb04y1Mo=.f861c95a-78da-41cb-a335-b49248fbf12d@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <Xw6y8VDi_uOka1FLF_9cSHyfhSqhE55TwANZb04y1Mo=.f861c95a-78da-41cb-a335-b49248fbf12d@github.com>
Message-ID: <-THXdiPqcmGQNArUZysUr-MSf8rkBNMFT0RFFmtHLts=.377a6ca4-8227-4a0f-9153-d571573769b4@github.com>

On Wed, 21 Apr 2021 19:57:05 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
>> 
>> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
>> 
>> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed date in copyright headers

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 659:

> 657:       }
> 658: 
> 659:       JVMCIObject result = JVMCIENV->call_PrimitiveConstant_forTypeChar(type2char(bt2), raw_value, JVMCI_CHECK_NULL);

Given the above switch is total this part is unreachable? Did you mean for it to occur after the `if (!is_reference_type(bt)) ` block?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From dnsimon at openjdk.java.net  Wed Apr 21 20:49:56 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 21 Apr 2021 20:49:56 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v3]
In-Reply-To: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
Message-ID: <L7fq2jTRFmdZBPcLmfGUVQJqAKgxFRVkvqmHJ4559K8=.5e894e43-da24-49b3-a515-8df6f3904666@github.com>

> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
> 
> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
> 
> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  removed unreachable code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3578/files
  - new: https://git.openjdk.java.net/jdk/pull/3578/files/6d8d4b49..b70c7b1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3578&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3578&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3578.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3578/head:pull/3578

PR: https://git.openjdk.java.net/jdk/pull/3578

From psandoz at openjdk.java.net  Wed Apr 21 21:47:23 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 21 Apr 2021 21:47:23 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v2]
In-Reply-To: <Nv3u1NhpZCx8qezllPBbjd94UPfTdxpcAmv1x4t4S-o=.035fab48-4844-41fd-9966-d791185c55ce@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <Xw6y8VDi_uOka1FLF_9cSHyfhSqhE55TwANZb04y1Mo=.f861c95a-78da-41cb-a335-b49248fbf12d@github.com>
 <-THXdiPqcmGQNArUZysUr-MSf8rkBNMFT0RFFmtHLts=.377a6ca4-8227-4a0f-9153-d571573769b4@github.com>
 <Nv3u1NhpZCx8qezllPBbjd94UPfTdxpcAmv1x4t4S-o=.035fab48-4844-41fd-9966-d791185c55ce@github.com>
Message-ID: <wOgkapkS66gAygWkUpWs7tXC5nQi-HTU74__dQ9tNic=.f406dcd3-cf2d-4f77-8f97-4fbb18b67319@github.com>

On Wed, 21 Apr 2021 20:45:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 659:
>> 
>>> 657:       }
>>> 658: 
>>> 659:       JVMCIObject result = JVMCIENV->call_PrimitiveConstant_forTypeChar(type2char(bt2), raw_value, JVMCI_CHECK_NULL);
>> 
>> Given the above switch is total this part is unreachable? Did you mean for it to occur after the `if (!is_reference_type(bt)) ` block?
>
> No - it should not be there at all: https://github.com/openjdk/jdk/pull/3578/commits/b70c7b1a64d51fce23edde860f04749e8e49d34f
> Thanks for spotting.

Oops, i think i need glasses, the switch has break statements that results in processing of the `raw_value`:
```c++
      switch (bt2) {
        case T_BOOLEAN: raw_value = value.z; break;
...

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From dnsimon at openjdk.java.net  Wed Apr 21 20:50:00 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 21 Apr 2021 20:50:00 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v2]
In-Reply-To: <-THXdiPqcmGQNArUZysUr-MSf8rkBNMFT0RFFmtHLts=.377a6ca4-8227-4a0f-9153-d571573769b4@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <Xw6y8VDi_uOka1FLF_9cSHyfhSqhE55TwANZb04y1Mo=.f861c95a-78da-41cb-a335-b49248fbf12d@github.com>
 <-THXdiPqcmGQNArUZysUr-MSf8rkBNMFT0RFFmtHLts=.377a6ca4-8227-4a0f-9153-d571573769b4@github.com>
Message-ID: <Nv3u1NhpZCx8qezllPBbjd94UPfTdxpcAmv1x4t4S-o=.035fab48-4844-41fd-9966-d791185c55ce@github.com>

On Wed, 21 Apr 2021 20:16:58 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed date in copyright headers
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 659:
> 
>> 657:       }
>> 658: 
>> 659:       JVMCIObject result = JVMCIENV->call_PrimitiveConstant_forTypeChar(type2char(bt2), raw_value, JVMCI_CHECK_NULL);
> 
> Given the above switch is total this part is unreachable? Did you mean for it to occur after the `if (!is_reference_type(bt)) ` block?

No - it should not be there at all: https://github.com/openjdk/jdk/pull/3578/commits/b70c7b1a64d51fce23edde860f04749e8e49d34f
Thanks for spotting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From psandoz at openjdk.java.net  Wed Apr 21 22:22:20 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 21 Apr 2021 22:22:20 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v3]
In-Reply-To: <L7fq2jTRFmdZBPcLmfGUVQJqAKgxFRVkvqmHJ4559K8=.5e894e43-da24-49b3-a515-8df6f3904666@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <L7fq2jTRFmdZBPcLmfGUVQJqAKgxFRVkvqmHJ4559K8=.5e894e43-da24-49b3-a515-8df6f3904666@github.com>
Message-ID: <RgQzEpbkZIsVTsc1zAtn6dkMXFabbmecdshOaNyqSwU=.84676cd9-f6e3-4b26-bb3d-d9c45fb57bef@github.com>

On Wed, 21 Apr 2021 20:49:56 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
>> 
>> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
>> 
>> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unreachable code

I am not an expert in HS/JVMCI code, but i can mostly follow it. Test looks good. I did wonder if there should be a test for a BSM with a ref type of say `List` rather than `String` given the latter can be represented directly in the constant pool (i don't know if that would exercise different code paths).

Why does a dynamic constant producing a primitive value need to be explicitly processed by `resolvePossiblyCachedConstantInPool`? Is that so specific certain primitive values can be identified and/or values normalized in some manner.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From jiefu at openjdk.java.net  Wed Apr 21 23:56:22 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 21 Apr 2021 23:56:22 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v5]
In-Reply-To: <4KS_ollgdqiNeQgI-XB2AKVJwpgtTo8lRRCwUvqTryk=.8597bbde-a56b-4d2a-a59c-8e80c83b3ec2@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <4KS_ollgdqiNeQgI-XB2AKVJwpgtTo8lRRCwUvqTryk=.8597bbde-a56b-4d2a-a59c-8e80c83b3ec2@github.com>
Message-ID: <q_dNkBu9HklVgHWnFhyzLYJrMougX4H9pUS4JGULAjA=.f942c503-2e5b-4ba5-875a-5235492ee3c0@github.com>

On Wed, 21 Apr 2021 18:44:14 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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 two additional commits since the last revision:
> 
>  - Reorder jcc equal,parity
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Use xorp to negate 1
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/cpu/x86/vm_version_x86.cpp line 1703:

> 1701:   }
> 1702: #endif // !PRODUCT
> 1703:   if (FLAG_IS_DEFAULT(UseSignumIntrinsic) && (UseSSE >= 2)) {

`UseSSE >=2` looks a bit uncomfortable to me since signumF_reg only requires UseSSE>=1. 

How about something like this:

diff --git a/src/hotspot/cpu/x86/x86.ad b/src/hotspot/cpu/x86/x86.ad
index bbf5256c112..0a738704c4d 100644
--- a/src/hotspot/cpu/x86/x86.ad
+++ b/src/hotspot/cpu/x86/x86.ad
@@ -1598,6 +1598,16 @@ const bool Matcher::match_rule_supported(int opcode) {
         return false;
       }
       break;
+    case Op_SignumF:
+      if (UseSSE < 1) {
+        return false;
+      }
+      break;
+    case Op_SignumD:
+      if (UseSSE < 2) {
+        return false;
+      }
+      break;
 #endif // !LP64
   }
   return true;  // Match rules are supported by default.
diff --git a/src/hotspot/share/opto/library_call.cpp b/src/hotspot/share/opto/library_call.cpp
index 7cb7955c612..217ee39d709 100644
--- a/src/hotspot/share/opto/library_call.cpp
+++ b/src/hotspot/share/opto/library_call.cpp
@@ -1737,8 +1737,8 @@ bool LibraryCallKit::inline_math_native(vmIntrinsics::ID id) {
   case vmIntrinsics::_dpow:      return inline_math_pow();
   case vmIntrinsics::_dcopySign: return inline_double_math(id);
   case vmIntrinsics::_fcopySign: return inline_math(id);
-  case vmIntrinsics::_dsignum: return inline_double_math(id);
-  case vmIntrinsics::_fsignum: return inline_math(id);
+  case vmIntrinsics::_dsignum: return Matcher::match_rule_supported(Op_SignumD) ? inline_double_math(id) : false;
+  case vmIntrinsics::_fsignum: return Matcher::match_rule_supported(Op_SignumF) ? inline_math(id) : false;
 
    // These intrinsics are not yet correctly implemented
   case vmIntrinsics::_datan2:


In this way, we can enable UseSignumIntrinsic by default on x86.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 21 23:03:32 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 21 Apr 2021 23:03:32 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
Message-ID: <Mht6-ZqKUaATPWoPHA5cEdmoPsJShlAXQRK7mNS_BNs=.bc7f54dd-10db-4e25-b31b-574f9a12a0fe@github.com>

On Fri, 16 Apr 2021 01:40:01 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * I optimize `max` and `min` by using these identities 
>>     - op (max(a,b) , min(a,b))=== op(a,b)
>>     - if op is commutable
>>     - example : 
>>       - max(a,b) + min(a,b))=== a + b // op = add
>>       - max(a,b) * min(a,b))=== a * b  // op = mul
>>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
>> * Test case 
>>   ```java
>>   /*
>>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>    *
>>    * This code is free software; you can redistribute it and/or modify it
>>    * under the terms of the GNU General Public License version 2 only, as
>>    * published by the Free Software Foundation.
>>    *
>>    * This code is distributed in the hope that it will be useful, but WITHOUT
>>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>    * version 2 for more details (a copy is included in the LICENSE file that
>>    * accompanied this code).
>>    *
>>    * You should have received a copy of the GNU General Public License version
>>    * 2 along with this work; if not, write to the Free Software Foundation,
>>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>    *
>>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>    * or visit www.oracle.com if you need additional information or have any
>>    * questions.
>>    */
>>   package org.sample;
>>   
>>   import org.openjdk.jmh.annotations.Benchmark;
>>   import org.openjdk.jmh.annotations.*;
>>   
>>   import java.util.Random;
>>   import java.util.concurrent.TimeUnit;
>>   import org.openjdk.jmh.infra.Blackhole;
>>   
>>   @BenchmarkMode({Mode.AverageTime})
>>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>>   public class MyBenchmark {
>>   
>>       static int length = 100000;
>>       static double[] data1 = new double[length];
>>       static double[] data2 = new double[length];
>>       static Random random = new Random();
>>   
>>       static {
>>           for(int i = 0; i < length; ++i) {
>>             data1[i] = random.nextDouble();
>>             data2[i] = random.nextDouble();
>>           }
>>       }
>>   
>>       @Benchmark
>>       public void testAdd(Blackhole bh) {
>>         double sum = 0;
>>         for (int i = 0; i < length; i++) {
>>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>>         }
>>         bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMax(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMin(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMul(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   }
>>   ```
>> 
>> *  The result is listed here (aarch64):
>> 
>>   before:
>> 
>>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>>  
>>   after:
>> 
>>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |
>> 
>> *  I have tested `NaN`  ` INFINITY` and `-INFINITY` and got same result (before/after)
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust code style

Running MyBenchmark test listed in the summary on x86_64 Haswell XEON with this patch results in:


# Benchmark: org.sample.MyBenchmark.testMax

# Run progress: 25.00% complete, ETA 00:03:57
# Fork: 1 of 1                                                                                                                                                              # Warmup Iteration   1: 112.714 us/op
# Warmup Iteration   2: # To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152                                                                                                           #
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450238, tid=3450253
#  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
#
# JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk) 


AND


# Benchmark: org.sample.MyBenchmark.testMin

# Run progress: 25.00% complete, ETA 00:03:57
# Fork: 1 of 1
# Warmup Iteration   1: 112.445 us/op
# Warmup Iteration   2: # To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450444, tid=3450481
#  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
#
# JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk)


Otherwise the results are below.

Baseline
Benchmark            Mode  Cnt    Score     Error  Units
MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
Finished running test 'micro:MyBenchmark'



Benchmark            Mode  Cnt    Score   Error  Units
MyBenchmark.testAdd  avgt    5  107.874 ? 0.148  us/op
MyBenchmark.testMul  avgt    5  107.881 ? 0.015  us/op
Finished running test 'micro:MyBenchmark'

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From whuang at openjdk.java.net  Thu Apr 22 01:52:20 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 22 Apr 2021 01:52:20 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
Message-ID: <Tc0XCuCtXO7vixyHY951U3RwRH-hbwUNw29PfU_nLQQ=.4a16ced5-9b5b-44f5-823e-a3136eb39ee3@github.com>

On Fri, 16 Apr 2021 01:40:01 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * I optimize `max` and `min` by using these identities 
>>     - op (max(a,b) , min(a,b))=== op(a,b)
>>     - if op is commutable
>>     - example : 
>>       - max(a,b) + min(a,b))=== a + b // op = add
>>       - max(a,b) * min(a,b))=== a * b  // op = mul
>>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
>> * Test case 
>>   ```java
>>   /*
>>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>    *
>>    * This code is free software; you can redistribute it and/or modify it
>>    * under the terms of the GNU General Public License version 2 only, as
>>    * published by the Free Software Foundation.
>>    *
>>    * This code is distributed in the hope that it will be useful, but WITHOUT
>>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>    * version 2 for more details (a copy is included in the LICENSE file that
>>    * accompanied this code).
>>    *
>>    * You should have received a copy of the GNU General Public License version
>>    * 2 along with this work; if not, write to the Free Software Foundation,
>>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>    *
>>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>    * or visit www.oracle.com if you need additional information or have any
>>    * questions.
>>    */
>>   package org.sample;
>>   
>>   import org.openjdk.jmh.annotations.Benchmark;
>>   import org.openjdk.jmh.annotations.*;
>>   
>>   import java.util.Random;
>>   import java.util.concurrent.TimeUnit;
>>   import org.openjdk.jmh.infra.Blackhole;
>>   
>>   @BenchmarkMode({Mode.AverageTime})
>>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>>   public class MyBenchmark {
>>   
>>       static int length = 100000;
>>       static double[] data1 = new double[length];
>>       static double[] data2 = new double[length];
>>       static Random random = new Random();
>>   
>>       static {
>>           for(int i = 0; i < length; ++i) {
>>             data1[i] = random.nextDouble();
>>             data2[i] = random.nextDouble();
>>           }
>>       }
>>   
>>       @Benchmark
>>       public void testAdd(Blackhole bh) {
>>         double sum = 0;
>>         for (int i = 0; i < length; i++) {
>>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>>         }
>>         bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMax(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMin(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMul(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   }
>>   ```
>> 
>> *  The result is listed here (aarch64):
>> 
>>   before:
>> 
>>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>>  
>>   after:
>> 
>>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |
>> 
>> *  I have tested `NaN`  ` INFINITY` and `-INFINITY` and got same result (before/after)
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust code style

> Running MyBenchmark test listed in the summary on x86_64 Haswell XEON with this patch results in:
> 
> ```
> # Benchmark: org.sample.MyBenchmark.testMax
> 
> # Run progress: 25.00% complete, ETA 00:03:57
> # Fork: 1 of 1                                                                                                                                                              # Warmup Iteration   1: 112.714 us/op
> # Warmup Iteration   2: # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152                                                                                                           #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450238, tid=3450253
> #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> #
> # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk) 
> ```
> 
> AND
> 
> ```
> # Benchmark: org.sample.MyBenchmark.testMin
> 
> # Run progress: 25.00% complete, ETA 00:03:57
> # Fork: 1 of 1
> # Warmup Iteration   1: 112.445 us/op
> # Warmup Iteration   2: # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450444, tid=3450481
> #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> #
> # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk)
> ```
> 
> Otherwise the results are below.
> 
> ```
> Baseline
> Benchmark            Mode  Cnt    Score     Error  Units
> MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
> MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
> MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
> MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
> Finished running test 'micro:MyBenchmark'
> ```
> 
> ```
> Benchmark            Mode  Cnt    Score   Error  Units
> MyBenchmark.testAdd  avgt    5  107.874 ? 0.148  us/op
> MyBenchmark.testMul  avgt    5  107.881 ? 0.015  us/op
> Finished running test 'micro:MyBenchmark'
> ```



> MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
> MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
> MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
> MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op

I run this test case by `java -jar target/benchmarks.jar -i 10 -wi 10 -f 1 ``on `  Intel(R) Xeon(R) CPU E7-8890 v4 @ 2.20GHz` without crash. Can you give me your jvm options and this crash log? Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From github.com+168222+mgkwill at openjdk.java.net  Thu Apr 22 02:18:24 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Thu, 22 Apr 2021 02:18:24 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <Tc0XCuCtXO7vixyHY951U3RwRH-hbwUNw29PfU_nLQQ=.4a16ced5-9b5b-44f5-823e-a3136eb39ee3@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
 <Tc0XCuCtXO7vixyHY951U3RwRH-hbwUNw29PfU_nLQQ=.4a16ced5-9b5b-44f5-823e-a3136eb39ee3@github.com>
Message-ID: <Kk19BJtpiMR9di5G_hGoKcFpY9SHIPTd99H-3_YgMdM=.6747cc6c-f952-41aa-a5a6-07321a0b24d1@github.com>

On Thu, 22 Apr 2021 01:49:07 GMT, Wang Huang <whuang at openjdk.org> wrote:

> > Running MyBenchmark test listed in the summary on x86_64 Haswell XEON with this patch results in:
> > ```
> > # Benchmark: org.sample.MyBenchmark.testMax
> > 
> > # Run progress: 25.00% complete, ETA 00:03:57
> > # Fork: 1 of 1                                                                                                                                                              # Warmup Iteration   1: 112.714 us/op
> > # Warmup Iteration   2: # To suppress the following error report, specify this argument
> > # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152                                                                                                           #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450238, tid=3450253
> > #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> > #
> > # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk) 
> > ```
> > 
> > 
> > AND
> > ```
> > # Benchmark: org.sample.MyBenchmark.testMin
> > 
> > # Run progress: 25.00% complete, ETA 00:03:57
> > # Fork: 1 of 1
> > # Warmup Iteration   1: 112.445 us/op
> > # Warmup Iteration   2: # To suppress the following error report, specify this argument
> > # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450444, tid=3450481
> > #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> > #
> > # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk)
> > ```
> > 
> > 
> > Otherwise the results are below.
> > ```
> > Baseline
> > Benchmark            Mode  Cnt    Score     Error  Units
> > MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
> > MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
> > MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
> > MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
> > Finished running test 'micro:MyBenchmark'
> > ```
> > 
> > 
> > ```
> > Benchmark            Mode  Cnt    Score   Error  Units
> > MyBenchmark.testAdd  avgt    5  107.874 ? 0.148  us/op
> > MyBenchmark.testMul  avgt    5  107.881 ? 0.015  us/op
> > Finished running test 'micro:MyBenchmark'
> > ```
> 
> > MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
> > MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
> > MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
> > MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
> 
> I run this test case by `java -jar target/benchmarks.jar -i 10 -wi 10 -f 1 `on ` Intel(R) Xeon(R) CPU E7-8890 v4 @ 2.20GHz` without crash. Can you give me your jvm options and this crash log? Thank you very much.

Certainly. Tomorrow morning (my time) I will re-run with your command and test on a few other Xeons. I need to re-run to get crash logs (I'm jumping around between patches and cleaned already) but I will post those when I can recreate.

To run I copied MyBenchmark.java from summary to test/micro/org/openjdk/bench/vm/compiler/MyBenchmark.java
Command on running was:
`make test TEST="micro:MyBenchmark" MICRO="FORK=1;WARMUP_ITER=2;" CONF=linux-x86_64-server-slowdebug`

This worked on master, but on checkout of pr/3513 caused the errors above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From whuang at openjdk.java.net  Thu Apr 22 02:38:21 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 22 Apr 2021 02:38:21 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <Kk19BJtpiMR9di5G_hGoKcFpY9SHIPTd99H-3_YgMdM=.6747cc6c-f952-41aa-a5a6-07321a0b24d1@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
 <Tc0XCuCtXO7vixyHY951U3RwRH-hbwUNw29PfU_nLQQ=.4a16ced5-9b5b-44f5-823e-a3136eb39ee3@github.com>
 <Kk19BJtpiMR9di5G_hGoKcFpY9SHIPTd99H-3_YgMdM=.6747cc6c-f952-41aa-a5a6-07321a0b24d1@github.com>
Message-ID: <u3i4urpIMZovq5SzU7tfwg6gRF4mF0_S0pt3jFS0GgA=.a648d13f-6ee8-4d68-ad96-aeae58da7a54@github.com>

On Thu, 22 Apr 2021 02:15:40 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

> > > Running MyBenchmark test listed in the summary on x86_64 Haswell XEON with this patch results in:
> > > ```
> > > # Benchmark: org.sample.MyBenchmark.testMax
> > > 
> > > # Run progress: 25.00% complete, ETA 00:03:57
> > > # Fork: 1 of 1                                                                                                                                                              # Warmup Iteration   1: 112.714 us/op
> > > # Warmup Iteration   2: # To suppress the following error report, specify this argument
> > > # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152                                                                                                           #
> > > # A fatal error has been detected by the Java Runtime Environment:
> > > #
> > > #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450238, tid=3450253
> > > #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> > > #
> > > # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk) 
> > > ```
> > > 
> > > 
> > > AND
> > > ```
> > > # Benchmark: org.sample.MyBenchmark.testMin
> > > 
> > > # Run progress: 25.00% complete, ETA 00:03:57
> > > # Fork: 1 of 1
> > > # Warmup Iteration   1: 112.445 us/op
> > > # Warmup Iteration   2: # To suppress the following error report, specify this argument
> > > # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152
> > > #
> > > # A fatal error has been detected by the Java Runtime Environment:
> > > #
> > > #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450444, tid=3450481
> > > #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> > > #
> > > # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk)
> > > ```
> > > 
> > > 
> > > Otherwise the results are below.
> > > ```
> > > Baseline
> > > Benchmark            Mode  Cnt    Score     Error  Units
> > > MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
> > > MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
> > > MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
> > > MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
> > > Finished running test 'micro:MyBenchmark'
> > > ```
> > > 
> > > 
> > > ```
> > > Benchmark            Mode  Cnt    Score   Error  Units
> > > MyBenchmark.testAdd  avgt    5  107.874 ? 0.148  us/op
> > > MyBenchmark.testMul  avgt    5  107.881 ? 0.015  us/op
> > > Finished running test 'micro:MyBenchmark'
> > > ```
> > 
> > 
> > > MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
> > > MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
> > > MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
> > > MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
> > 
> > 
> > I run this test case by `java -jar target/benchmarks.jar -i 10 -wi 10 -f 1 `on ` Intel(R) Xeon(R) CPU E7-8890 v4 @ 2.20GHz` without crash. Can you give me your jvm options and this crash log? Thank you very much.
> 
> Certainly. Tomorrow morning (my time) I will re-run with your command and test on a few other Xeons. I need to re-run to get crash logs (I'm jumping around between patches and cleaned already) but I will post those when I can recreate.
> 
> To run I copied MyBenchmark.java from summary to test/micro/org/openjdk/bench/vm/compiler/MyBenchmark.java
> Command on running was:
> `make test TEST="micro:MyBenchmark" MICRO="FORK=1;WARMUP_ITER=2;" CONF=linux-x86_64-server-slowdebug`
> 
> This worked on master, but on checkout of pr/3513 caused the errors above.

Thank you very much. I will check this issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From yyang at openjdk.java.net  Thu Apr 22 07:08:32 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 22 Apr 2021 07:08:32 GMT
Subject: RFR: 8265711: C1: Canonicalize Class.getModifier intrinsic method
Message-ID: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>

It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.

-------------

Commit messages:
 - canonicalize well-chosen intrinsic methods

Changes: https://git.openjdk.java.net/jdk/pull/3616/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3616&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265711
  Stats: 111 lines in 2 files changed: 111 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3616/head:pull/3616

PR: https://git.openjdk.java.net/jdk/pull/3616

From dholmes at openjdk.java.net  Thu Apr 22 07:31:38 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 22 Apr 2021 07:31:38 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v3]
In-Reply-To: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
Message-ID: <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>

> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
> 
> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
> 
> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Replace assert(false) with fatal()
  
  After a number of people examined this code it was decided that the best approach was to re-instate
  the call to fatal() in product builds, that would have been present in the CATCH macro, until recent
  changes converted that to an assert(). The code here is not prepared to continue if compute_map fails
  so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed
  bytecode where verification has been disabled).

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3580/files
  - new: https://git.openjdk.java.net/jdk/pull/3580/files/264fbea5..926e951c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=01-02

  Stats: 9 lines in 2 files changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3580.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3580/head:pull/3580

PR: https://git.openjdk.java.net/jdk/pull/3580

From dnsimon at openjdk.java.net  Thu Apr 22 10:32:24 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 22 Apr 2021 10:32:24 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v2]
In-Reply-To: <wOgkapkS66gAygWkUpWs7tXC5nQi-HTU74__dQ9tNic=.f406dcd3-cf2d-4f77-8f97-4fbb18b67319@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <Xw6y8VDi_uOka1FLF_9cSHyfhSqhE55TwANZb04y1Mo=.f861c95a-78da-41cb-a335-b49248fbf12d@github.com>
 <-THXdiPqcmGQNArUZysUr-MSf8rkBNMFT0RFFmtHLts=.377a6ca4-8227-4a0f-9153-d571573769b4@github.com>
 <Nv3u1NhpZCx8qezllPBbjd94UPfTdxpcAmv1x4t4S-o=.035fab48-4844-41fd-9966-d791185c55ce@github.com>
 <wOgkapkS66gAygWkUpWs7tXC5nQi-HTU74__dQ9tNic=.f406dcd3-cf2d-4f77-8f97-4fbb18b67319@github.com>
Message-ID: <ftO4lU4OAXa5UkuLE7TelvpnXs9SWScEeZUgoC2fCWM=.6ec9b9cf-5974-437c-9b87-1e3b40243061@github.com>

On Wed, 21 Apr 2021 21:44:51 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> No - it should not be there at all: https://github.com/openjdk/jdk/pull/3578/commits/b70c7b1a64d51fce23edde860f04749e8e49d34f
>> Thanks for spotting.
>
> Oops, i think i need glasses, the switch has break statements that results in processing of the `raw_value`:
> ```c++
>       switch (bt2) {
>         case T_BOOLEAN: raw_value = value.z; break;
> ...

I need more than glasses since I wrote this code! Thankfully the test I added also showed the problem with removing this "unreachable" code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From dnsimon at openjdk.java.net  Thu Apr 22 10:37:20 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 22 Apr 2021 10:37:20 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v3]
In-Reply-To: <RgQzEpbkZIsVTsc1zAtn6dkMXFabbmecdshOaNyqSwU=.84676cd9-f6e3-4b26-bb3d-d9c45fb57bef@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <L7fq2jTRFmdZBPcLmfGUVQJqAKgxFRVkvqmHJ4559K8=.5e894e43-da24-49b3-a515-8df6f3904666@github.com>
 <RgQzEpbkZIsVTsc1zAtn6dkMXFabbmecdshOaNyqSwU=.84676cd9-f6e3-4b26-bb3d-d9c45fb57bef@github.com>
Message-ID: <GaVdpypF2Ia--SVZ5DBQQT-FpWxk-IAfcAA39vot0eY=.f34d9b2f-03c5-4f0a-8c8f-a27925f98002@github.com>

On Wed, 21 Apr 2021 22:19:21 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I am not an expert in HS/JVMCI code, but i can mostly follow it. Test looks good. I did wonder if there should be a test for a BSM with a ref type of say `List` rather than `String` given the latter can be represented directly in the constant pool (i don't know if that would exercise different code paths).

I don't think it exercises different code paths but I added it anyway.

> Why does a dynamic constant producing a primitive value need to be explicitly processed by `resolvePossiblyCachedConstantInPool`? Is that so specific certain primitive values can be identified and/or values normalized in some manner.

It's there to convert standard boxes (e.g. `java.lang.Integer`) to JVMCI boxes (e.g. `jdk.vm.ci.meta.PrimitiveConstant`)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From dnsimon at openjdk.java.net  Thu Apr 22 11:26:46 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 22 Apr 2021 11:26:46 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v4]
In-Reply-To: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
Message-ID: <lilnKTMzqjIWpptmH9RmHRAjPIdjP_ztV-EksuliNBQ=.70979c6b-2b68-4077-9490-bc93bec63be3@github.com>

> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
> 
> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
> 
> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.

Doug Simon 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 two new commits since the last revision:

 - added comment explaining box conversion of primitives
 - added test for loading a List from a condy

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3578/files
  - new: https://git.openjdk.java.net/jdk/pull/3578/files/b70c7b1a..06953124

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3578&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3578&range=02-03

  Stats: 26 lines in 2 files changed: 20 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3578.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3578/head:pull/3578

PR: https://git.openjdk.java.net/jdk/pull/3578

From coleenp at openjdk.java.net  Thu Apr 22 12:20:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 22 Apr 2021 12:20:30 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v3]
In-Reply-To: <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>
Message-ID: <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com>

On Thu, 22 Apr 2021 07:31:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>> 
>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>> 
>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace assert(false) with fatal()
>   
>   After a number of people examined this code it was decided that the best approach was to re-instate
>   the call to fatal() in product builds, that would have been present in the CATCH macro, until recent
>   changes converted that to an assert(). The code here is not prepared to continue if compute_map fails
>   so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed
>   bytecode where verification has been disabled).

Good cleanup!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3580

From dnsimon at openjdk.java.net  Thu Apr 22 13:29:22 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 22 Apr 2021 13:29:22 GMT
Subject: RFR: 8264918: [JVMCI] getVtableIndexForInterfaceMethod doesn't
 check that type and method are related
In-Reply-To: <Ry8UFrNx9pAEJMsHvEgmbFALNcvfsaDQeDvkv3koNJ4=.12a43c9f-f133-4f14-9d7a-00aeb1ee63d1@github.com>
References: <Ry8UFrNx9pAEJMsHvEgmbFALNcvfsaDQeDvkv3koNJ4=.12a43c9f-f133-4f14-9d7a-00aeb1ee63d1@github.com>
Message-ID: <OjJP8GPjn0E3Yh0dYsPv9YnsFdVVih1wbtOjuJZy04k=.04651a61-8eaf-4aae-a052-f2420c48e3b9@github.com>

On Thu, 8 Apr 2021 12:49:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> getVtableIndexForInterfaceMethod should reject the case when a resolved class doesn't implement the holder interface.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

Looking into https://bugs.openjdk.java.net/browse/JDK-8265689, I see that it's due to this PR missing these changes:

diff --git a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
index faf3cec709..945ec7ba1a 100644
--- a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
+++ b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
@@ -590,8 +590,9 @@ final class CompilerToVM {
      * {@link HotSpotVMConfig#invalidVtableIndex} if {@code method} is not in {@code type}'s
      * v-table.
      *
-     * @throws InternalError if {@code type} is an interface or {@code method} is not held by an
-     *             interface or class represented by {@code type} is not initialized
+     * @throws InternalError if {@code type} is an interface, {@code method} is not defined by an
+     *             interface, {@code type} does not implement the interface defining {@code method}
+     *             or class represented by {@code type} is not initialized
      */
     native int getVtableIndexForInterfaceMethod(HotSpotResolvedObjectTypeImpl type, HotSpotResolvedJavaMethodImpl method);
 
diff --git a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
index d494679aff..41dab25d0e 100644
--- a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
+++ b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
@@ -677,7 +677,7 @@ final class HotSpotResolvedJavaMethodImpl extends HotSpotMethod implements HotSp
             return config().invalidVtableIndex;
         }
         if (holder.isInterface()) {
-            if (resolved.isInterface() || !resolved.isLinked()) {
+            if (resolved.isInterface() || !resolved.isLinked() || !getDeclaringClass().isAssignableFrom(resolved)) {
                 return config().invalidVtableIndex;
             }
             return getVtableIndexForInterfaceMethod(resolved);


@iwanowww would you mind taking JDK-8265689 and using it to apply these missing changes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3396

From thartmann at openjdk.java.net  Thu Apr 22 13:33:33 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 22 Apr 2021 13:33:33 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v5]
In-Reply-To: <VIClyiA702WOBS5M5azRIWp2D2zSp9B58HxlCdyMx7I=.29bf18f8-0fe0-4209-91c5-1c8e67144f3e@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <VIClyiA702WOBS5M5azRIWp2D2zSp9B58HxlCdyMx7I=.29bf18f8-0fe0-4209-91c5-1c8e67144f3e@github.com>
Message-ID: <GKyKAe6WSrHK0zQNcpmBtyN16aHuVIEFhOKAnMangwQ=.9f9f2742-78ac-4bdc-b9d6-953b65c55bb3@github.com>

On Tue, 20 Apr 2021 13:52:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Javadocs and README.html, update README.md to reference java files instead of html files

Great work, Christian! I'm glad we finally have the capability to write regression tests with IR verification.

Hard to review this in detail but I've added some comments. In any case, conversion of Valhalla tests to the new framework has proven that this is good to go. We can still fix problems and add new features once this is in.

test/lib/jdk/test/lib/hotspot/ir_framework/Check.java line 94:

> 92: @Retention(RetentionPolicy.RUNTIME)
> 93: public @interface Check {
> 94: 

Some classes/interfaces have a newline at the beginning and others don't. I think they can be removed.

test/lib/jdk/test/lib/hotspot/ir_framework/IREncodingPrinter.java line 36:

> 34: 
> 35: /**
> 36:  * Prints an encoding of all @Test methods whether an @IR rules should be applied to the dedicated test framework socket.

The comment is a bit confusing, maybe "rules" -> "rule"?

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 4:

> 2: This folder contains a test framework whose main purpose is to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags _-XX:+PrintIdeal_ and _-XX:+PrintOptoAssembly_. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 3: 
> 4: The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypesTest.java) and aims to replace it at some point.

I think this line can be removed because we will happily remove the Valhalla version as soon as this one gets integrated :)

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 46:

> 44: 
> 45: #### Checked Tests
> 46: The base tests do not provide any way of verification by user code. A checked test enabled that by allowing the user to define an additional `@Check` annotated method which is invoked directly after the `@Test` annotated method. This allows the user to perform various checks about the test method including return value verification.

"enabled" -> "enables"

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 65:

> 63: A regex can either be a custom string or any of the default regexes provided by the framework in [IRNode](IRNode.java) for some commonly used IR nodes (also provides the possibility of composite regexes).
> 64: 
> 65: An IR verification cannot (and does not want to) always be performed. For example, a JTreg test could be run with _-Xint_ or not a debug build (_-XX:+PrintIdeal_ and _-XX:+PrintOptoAssembly_ are debug build flags). But also CI tier testing could add additional JTreg VM and Javaoptions flags which could make an IR rule unstable. 

Maybe rephrase "does not want to"

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 93:

> 91: - `-DTest=test1,test2`: Provide a list of `@Test` method names which should be executed.
> 92: - `-DExclude=test3`: Provide a list of `@Test` method names which should be excluded from execution.
> 93: - `-DScenarios=1,2`: Provide a list of scenario indexes to specify which scenarios that should be executed.

"that" should be removed

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 101:

> 99: - `-DExcluceRandom=true`: The framework randomly excludes some methods from compilation. IR verification is disabled completely with this flag.
> 100: - `-DFlipC1C2=true`: The framework compiles all `@Test` annotated method with C1 if a C2 compilation would have been applied and vice versa. IR verification is disabled completely with this flag.
> 101: - `-DShuffleTests=false`: Disables the shuffling of tests (a shuffling is always done by default).

Maybe explain that "shuffling" means execution in random order.

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 128:

> 126: This framework is based on the idea of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypesTest.java). This IR framework was used with great success in Valhalla and thus served as a foundation for this new IR framework.
> 127:  
> 128:  The new framework supports all the features that are present in the Valhalla IR framework with the idea to replace it at some point. The initial design and feature set was kept simple and straight forward and serves well for small to medium sized tests. There are a lot of possibilities to further enhance the framework and make it more powerful. This can be tackled in additional RFEs. A few ideas include:

Again, I would remove the reference to the Valhalla framework. Looking through the changes, I see 13 references to "Valhalla", I think these should all be removed.

test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 135:

> 133: - More interface methods for verification in checked and custom run tests.
> 134: - More stress/debug framework flags.
> 135: - Additional check possibilities in `@IR` annotations. 

I would remove the "Future Work" section and migrate it completely to RFEs. Otherwise it will quickly be outdated anyway.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3508

From dnsimon at openjdk.java.net  Thu Apr 22 14:35:31 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 22 Apr 2021 14:35:31 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v4]
In-Reply-To: <lilnKTMzqjIWpptmH9RmHRAjPIdjP_ztV-EksuliNBQ=.70979c6b-2b68-4077-9490-bc93bec63be3@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <lilnKTMzqjIWpptmH9RmHRAjPIdjP_ztV-EksuliNBQ=.70979c6b-2b68-4077-9490-bc93bec63be3@github.com>
Message-ID: <WT5-uESReO0zQKA3E0iQMWpvgwFX5spW2F3kEN6P9Aw=.60f5f4d1-cb99-40bd-8f22-ebd4c8e7d7a6@github.com>

On Thu, 22 Apr 2021 11:26:46 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
>> 
>> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
>> 
>> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.
>
> Doug Simon 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 two new commits since the last revision:
> 
>  - added comment explaining box conversion of primitives
>  - added test for loading a List from a condy

test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/TestDynamicConstant.java line 28:

> 26:  * @requires vm.jvmci
> 27:  * @summary Test CONSTANT_Dynamic resolution by HotSpotConstantPool.
> 28:  * @modules java.base/jdk.internal.org.objectweb.asm

Instead of ASM, I would have preferred to use `test.java.lang.invoke.lib.InstructionHelper` like `CondyBSMInvocation` [does](https://github.com/openjdk/jdk/blob/05a764f4ffb8030d6b768f2d362c388e5aabd92d/test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java#L56). However, I could not figure out how to use a test library from the `test/jdk` suite in the `test/hotspot/jtreg` suite. Do you know if that's possible @PaulSandoz ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From psandoz at openjdk.java.net  Thu Apr 22 15:34:22 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 22 Apr 2021 15:34:22 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v4]
In-Reply-To: <lilnKTMzqjIWpptmH9RmHRAjPIdjP_ztV-EksuliNBQ=.70979c6b-2b68-4077-9490-bc93bec63be3@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <lilnKTMzqjIWpptmH9RmHRAjPIdjP_ztV-EksuliNBQ=.70979c6b-2b68-4077-9490-bc93bec63be3@github.com>
Message-ID: <eU8Xv2AUYNmbVyQ3QLo_fgmGHJ91W5wDlqYQAqpj3Lg=.b770d7c5-d057-43fb-9f2f-23e018819502@github.com>

On Thu, 22 Apr 2021 11:26:46 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
>> 
>> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
>> 
>> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.
>
> Doug Simon 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 two new commits since the last revision:
> 
>  - added comment explaining box conversion of primitives
>  - added test for loading a List from a condy

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From psandoz at openjdk.java.net  Thu Apr 22 15:34:23 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 22 Apr 2021 15:34:23 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v4]
In-Reply-To: <WT5-uESReO0zQKA3E0iQMWpvgwFX5spW2F3kEN6P9Aw=.60f5f4d1-cb99-40bd-8f22-ebd4c8e7d7a6@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <lilnKTMzqjIWpptmH9RmHRAjPIdjP_ztV-EksuliNBQ=.70979c6b-2b68-4077-9490-bc93bec63be3@github.com>
 <WT5-uESReO0zQKA3E0iQMWpvgwFX5spW2F3kEN6P9Aw=.60f5f4d1-cb99-40bd-8f22-ebd4c8e7d7a6@github.com>
Message-ID: <M24mmMz1zZgt55CfomcdR-0GnPXEZLrru3EuZIcG3GU=.0de04184-ecfc-4f4f-a24e-8023cffdf2d3@github.com>

On Thu, 22 Apr 2021 14:31:45 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Doug Simon 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 two new commits since the last revision:
>> 
>>  - added comment explaining box conversion of primitives
>>  - added test for loading a List from a condy
>
> test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/TestDynamicConstant.java line 28:
> 
>> 26:  * @requires vm.jvmci
>> 27:  * @summary Test CONSTANT_Dynamic resolution by HotSpotConstantPool.
>> 28:  * @modules java.base/jdk.internal.org.objectweb.asm
> 
> Instead of ASM, I would have preferred to use `test.java.lang.invoke.lib.InstructionHelper` like `CondyBSMInvocation` [does](https://github.com/openjdk/jdk/blob/05a764f4ffb8030d6b768f2d362c388e5aabd92d/test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java#L56). However, I could not figure out how to use a test library from the `test/jdk` suite in the `test/hotspot/jtreg` suite. Do you know if that's possible @PaulSandoz ?

It might be (depending of source locations). I would need to look in more detail. I can do that as a follow on investigation/fix if need be, rather than block this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From psandoz at openjdk.java.net  Thu Apr 22 15:34:22 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 22 Apr 2021 15:34:22 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v3]
In-Reply-To: <GaVdpypF2Ia--SVZ5DBQQT-FpWxk-IAfcAA39vot0eY=.f34d9b2f-03c5-4f0a-8c8f-a27925f98002@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <L7fq2jTRFmdZBPcLmfGUVQJqAKgxFRVkvqmHJ4559K8=.5e894e43-da24-49b3-a515-8df6f3904666@github.com>
 <RgQzEpbkZIsVTsc1zAtn6dkMXFabbmecdshOaNyqSwU=.84676cd9-f6e3-4b26-bb3d-d9c45fb57bef@github.com>
 <GaVdpypF2Ia--SVZ5DBQQT-FpWxk-IAfcAA39vot0eY=.f34d9b2f-03c5-4f0a-8c8f-a27925f98002@github.com>
Message-ID: <YNsZVd8WtgEWdJzd4yoAoDRbuxYgqvu1JtOBw4dFex8=.e0ad0067-f4eb-4467-9d22-90b5198c5ca9@github.com>

On Thu, 22 Apr 2021 10:34:15 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > Why does a dynamic constant producing a primitive value need to be explicitly processed by `resolvePossiblyCachedConstantInPool`? Is that so specific certain primitive values can be identified and/or values normalized in some manner.
> 
> It's there to convert standard boxes (e.g. `java.lang.Integer`) to JVMCI boxes (e.g. `jdk.vm.ci.meta.PrimitiveConstant`)

Thanks, and now see it checks that in the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From dnsimon at openjdk.java.net  Thu Apr 22 15:41:23 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 22 Apr 2021 15:41:23 GMT
Subject: RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants [v4]
In-Reply-To: <M24mmMz1zZgt55CfomcdR-0GnPXEZLrru3EuZIcG3GU=.0de04184-ecfc-4f4f-a24e-8023cffdf2d3@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
 <lilnKTMzqjIWpptmH9RmHRAjPIdjP_ztV-EksuliNBQ=.70979c6b-2b68-4077-9490-bc93bec63be3@github.com>
 <WT5-uESReO0zQKA3E0iQMWpvgwFX5spW2F3kEN6P9Aw=.60f5f4d1-cb99-40bd-8f22-ebd4c8e7d7a6@github.com>
 <M24mmMz1zZgt55CfomcdR-0GnPXEZLrru3EuZIcG3GU=.0de04184-ecfc-4f4f-a24e-8023cffdf2d3@github.com>
Message-ID: <Tto1Vzf3fV52H4HtqtgQgf9Pkbw6bV6U8aWyX-cPBV4=.7bdf85a1-6279-407c-8add-3b24cd7d628b@github.com>

On Thu, 22 Apr 2021 15:31:48 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/TestDynamicConstant.java line 28:
>> 
>>> 26:  * @requires vm.jvmci
>>> 27:  * @summary Test CONSTANT_Dynamic resolution by HotSpotConstantPool.
>>> 28:  * @modules java.base/jdk.internal.org.objectweb.asm
>> 
>> Instead of ASM, I would have preferred to use `test.java.lang.invoke.lib.InstructionHelper` like `CondyBSMInvocation` [does](https://github.com/openjdk/jdk/blob/05a764f4ffb8030d6b768f2d362c388e5aabd92d/test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java#L56). However, I could not figure out how to use a test library from the `test/jdk` suite in the `test/hotspot/jtreg` suite. Do you know if that's possible @PaulSandoz ?
>
> It might be (depending of source locations). I would need to look in more detail. I can do that as a follow on investigation/fix if need be, rather than block this PR?

No need to spend time on this - just thought you may know off the top of your head. I'll investigate further myself.
Thanks for the detailed review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From iklam at openjdk.java.net  Thu Apr 22 15:46:22 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 22 Apr 2021 15:46:22 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v3]
In-Reply-To: <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>
Message-ID: <tiqOKr3JU2O6yJ7NDZiiYHbXQS86IDtNfuVW4hlKDy4=.f4719034-59e6-4ce5-8761-8f4810ddd776@github.com>

On Thu, 22 Apr 2021 07:31:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>> 
>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>> 
>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace assert(false) with fatal()
>   
>   After a number of people examined this code it was decided that the best approach was to re-instate
>   the call to fatal() in product builds, that would have been present in the CATCH macro, until recent
>   changes converted that to an assert(). The code here is not prepared to continue if compute_map fails
>   so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed
>   bytecode where verification has been disabled).

Latest version LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3580

From dnsimon at openjdk.java.net  Thu Apr 22 16:02:28 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 22 Apr 2021 16:02:28 GMT
Subject: Integrated: 8265480: add basic JVMCI support for JEP 309: Dynamic
 Class-File Constants
In-Reply-To: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
References: <P4ZivOW_cE1GAwrMSR6S3NLEctgeZ4DnW7xgqKnZSwY=.87f10385-61dd-49bc-b86b-d720d63ab2b6@github.com>
Message-ID: <PzCDOAYeklky7TrW7QmlJ-O-QwZ4pr1tkJIGj7_5mcY=.50d273ca-443e-4f39-9860-649c7db811e7@github.com>

On Mon, 19 Apr 2021 21:31:04 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
> 
> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
> 
> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.

This pull request has now been integrated.

Changeset: 7df0c10a
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7df0c10a
Stats:     401 lines in 10 files changed: 370 ins; 10 del; 21 mod

8265480: add basic JVMCI support for JEP 309: Dynamic Class-File Constants

Reviewed-by: kvn, psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/3578

From iveresov at openjdk.java.net  Thu Apr 22 18:04:25 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Thu, 22 Apr 2021 18:04:25 GMT
Subject: RFR: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled [v2]
In-Reply-To: <nTmx66kTGCytWWTwqLBsM29XHW3YgvCF0YlHoYWGM2g=.1204b6ad-883d-43a6-8848-bd32002a8943@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
 <nTmx66kTGCytWWTwqLBsM29XHW3YgvCF0YlHoYWGM2g=.1204b6ad-883d-43a6-8848-bd32002a8943@github.com>
Message-ID: <Og0xDbPw3L12esdgH4pquseBjkeiHJjzaHpaKy3o8bQ=.05b059d3-9a56-4b12-9eab-54c9d5f36688@github.com>

On Mon, 19 Apr 2021 01:23:06 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

>> On MIPS64 platform has not impliment C1,only has C2.
>>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462
>
> SUN Guoyun 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.

Ok, the internal testing looks good. I think we're ready to go.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3449

From iveresov at openjdk.java.net  Thu Apr 22 18:14:38 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Thu, 22 Apr 2021 18:14:38 GMT
Subject: RFR: 8264842: IGV: different nodes sharing idx are treated as
 equal
In-Reply-To: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
References: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
Message-ID: <9wt0Agz3Q-oh5l_-wc8ixf3wwCWjaLot7m592G-_8W4=.8b6c444a-419a-423c-ba82-74a10e9a4e42@github.com>

On Tue, 20 Apr 2021 20:33:25 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change replaces `Node::_idx` with a dedicated `Node::_igv_idx` as the internal node identifier for IGV. `_igv_idx` is unique across all phases in a compilation, which prevents IGV from wrongly treating unrelated nodes as if they were the same.`_igv_idx` is proposed instead of `Node::_debug_idx`, which is also unique across phases, for stability (the `_debug_idx` identifiers of a compilation are affected by the entire compilation history) and flexibility (future enhancements such as [JDK-8265587](https://bugs.openjdk.java.net/browse/JDK-8265587) require altering the node identifier in IGV-specific ways).
> 
> The following figure illustrates the effect of using `_igv_idx` instead of `_idx` as an internal node identifier. Using  `_idx` (left), node 54 is wrongly treated as created in two different phases (two green circles in the graph snapshot view), whereas using `_igv_idx` (right), node 54 is shown as created once, as expected:
> 
> ![before-after-fix](https://user-images.githubusercontent.com/8792647/115462349-d624e380-a22a-11eb-8d29-810a5ccbd09c.png)
> 
> At the IGV user interface level, this change encapsulates the internal node identifier by showing a "short node text" (configurable from `Tools -> Options`, defaulting to `[idx] [name]`) in all places where the internal identifier was exposed before: edge tooltips, slot tooltips, and the node search results. The code in [ViewPanel.form](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-9b4fd66fc1b7a93a40abcec79b8825db44bdef62f13fede745238c3b87a2ab90) and [ViewPanel.java](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-c8cfda144359ba8b317fd0d02988dc0798418dcd211eb5eb91c3ed94567684d3) is generated by NetBeans 12.3 by editing ViewPanel.java in "Design" mode.
> 
> #### Testing
> 
> - Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
> - Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
> - Tested manually, for a few graphs, that nodes are treated as created exactly once by IGV (by selecting single nodes and checking that a single green circle appears in the graph snapshot view, as in the right screenshot above).
> - Tested manually that the new `Short Node Text` field in `Tools -> Options` is displayed and stored correctly, and that it is honored by edge tooltips, slot tooltips, and node search results (on Linux and Windows, for JDK 8, 11, and 15).

LGTM

-------------

Marked as reviewed by iveresov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3593

From kvn at openjdk.java.net  Thu Apr 22 18:24:27 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 22 Apr 2021 18:24:27 GMT
Subject: RFR: 8264842: IGV: different nodes sharing idx are treated as
 equal
In-Reply-To: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
References: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
Message-ID: <79KVSGgBiJBraQH7VFiIQZuYqjafQByH1NAL-6x4BNs=.4274d0ba-1047-448b-beb6-94ab44530ac6@github.com>

On Tue, 20 Apr 2021 20:33:25 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change replaces `Node::_idx` with a dedicated `Node::_igv_idx` as the internal node identifier for IGV. `_igv_idx` is unique across all phases in a compilation, which prevents IGV from wrongly treating unrelated nodes as if they were the same.`_igv_idx` is proposed instead of `Node::_debug_idx`, which is also unique across phases, for stability (the `_debug_idx` identifiers of a compilation are affected by the entire compilation history) and flexibility (future enhancements such as [JDK-8265587](https://bugs.openjdk.java.net/browse/JDK-8265587) require altering the node identifier in IGV-specific ways).
> 
> The following figure illustrates the effect of using `_igv_idx` instead of `_idx` as an internal node identifier. Using  `_idx` (left), node 54 is wrongly treated as created in two different phases (two green circles in the graph snapshot view), whereas using `_igv_idx` (right), node 54 is shown as created once, as expected:
> 
> ![before-after-fix](https://user-images.githubusercontent.com/8792647/115462349-d624e380-a22a-11eb-8d29-810a5ccbd09c.png)
> 
> At the IGV user interface level, this change encapsulates the internal node identifier by showing a "short node text" (configurable from `Tools -> Options`, defaulting to `[idx] [name]`) in all places where the internal identifier was exposed before: edge tooltips, slot tooltips, and the node search results. The code in [ViewPanel.form](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-9b4fd66fc1b7a93a40abcec79b8825db44bdef62f13fede745238c3b87a2ab90) and [ViewPanel.java](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-c8cfda144359ba8b317fd0d02988dc0798418dcd211eb5eb91c3ed94567684d3) is generated by NetBeans 12.3 by editing ViewPanel.java in "Design" mode.
> 
> #### Testing
> 
> - Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
> - Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
> - Tested manually, for a few graphs, that nodes are treated as created exactly once by IGV (by selecting single nodes and checking that a single green circle appears in the graph snapshot view, as in the right screenshot above).
> - Tested manually that the new `Short Node Text` field in `Tools -> Options` is displayed and stored correctly, and that it is honored by edge tooltips, slot tooltips, and node search results (on Linux and Windows, for JDK 8, 11, and 15).

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3593

From github.com+40024232+sunny868 at openjdk.java.net  Thu Apr 22 18:26:28 2021
From: github.com+40024232+sunny868 at openjdk.java.net (SUN Guoyun)
Date: Thu, 22 Apr 2021 18:26:28 GMT
Subject: Integrated: 8265105: gc/arguments/TestSelectDefaultGC.java fails when
 compiler1 is disabled
In-Reply-To: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
References: <w14_LLFv3qBdkh5iULZRTjWUHfkJTyjRVtce8aWjlDw=.43412533-451e-4177-acfc-9732d69a2820@github.com>
Message-ID: <8O3Th4SXG3dTjTpQv2Kv8yOQ06kQi2I0lWJuJp1ORUI=.fe3b9579-2823-4475-b510-c4fdf68d157d@github.com>

On Tue, 13 Apr 2021 05:46:15 GMT, SUN Guoyun <github.com+40024232+sunny868 at openjdk.org> wrote:

> On MIPS64 platform has not impliment C1,only has C2.
>  so when tiered compilation is off, it is unnecessary to set client emulation mode flags.
>  perhaps this bug be included by https://bugs.openjdk.java.net/browse/JDK-8251462

This pull request has now been integrated.

Changeset: 31d8a19e
Author:    sunguoyun <sunguoyun at loongson.cn>
Committer: Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/31d8a19e
Stats:     14 lines in 2 files changed: 6 ins; 2 del; 6 mod

8265105: gc/arguments/TestSelectDefaultGC.java fails when compiler1 is disabled

Reviewed-by: iveresov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3449

From github.com+168222+mgkwill at openjdk.java.net  Thu Apr 22 18:44:58 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Thu, 22 Apr 2021 18:44:58 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v6]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> 
> Benchmark                       Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
> 
>  
> Optimized:
> signum intrinsic patch
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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 two additional commits since the last revision:

 - Implement Default UseSignumIntrinsic suggestion
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Use three operand xorps/d
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/895eab4d..afefdc28

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=04-05

  Stats: 21 lines in 3 files changed: 10 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Thu Apr 22 18:58:32 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Thu, 22 Apr 2021 18:58:32 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v6]
In-Reply-To: <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com>
Message-ID: <nzYP0z38O3cm4I4PIda_IV6AocPrfy9LEFHyKwBjJlM=.5ba2002e-24ef-4c29-9bf6-d26ac763d2d7@github.com>

On Thu, 22 Apr 2021 18:44:58 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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 two additional commits since the last revision:
> 
>  - Implement Default UseSignumIntrinsic suggestion
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Use three operand xorps/d
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

- Switched to 3 operand xorps/d on colleague suggestion to insure I don't introduce a hard to find register bug. 

- Implemented @DamonFool suggestion for Default Enable of UseSignumIntrinsic on x86. Slightly worried about `!has_match_rule(opcode)` for aarch64. But as long as it doesn't hit this I think it will work.

 src/hotspot/cpu/aarch64/aarch64.ad:

const bool Matcher::match_rule_supported(int opcode) {
  if (!has_match_rule(opcode))
    return false;


Also moved matcher checks in src/hotspot/cpu/x86/x86.ad outside of 

#ifndef _LP64
#endif // !LP64


Thanks for the review @DamonFool @dholmes-ora @jatin-bhateja.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Thu Apr 22 19:02:24 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Thu, 22 Apr 2021 19:02:24 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v5]
In-Reply-To: <q_dNkBu9HklVgHWnFhyzLYJrMougX4H9pUS4JGULAjA=.f942c503-2e5b-4ba5-875a-5235492ee3c0@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <4KS_ollgdqiNeQgI-XB2AKVJwpgtTo8lRRCwUvqTryk=.8597bbde-a56b-4d2a-a59c-8e80c83b3ec2@github.com>
 <q_dNkBu9HklVgHWnFhyzLYJrMougX4H9pUS4JGULAjA=.f942c503-2e5b-4ba5-875a-5235492ee3c0@github.com>
Message-ID: <vHWUTafrtyldld7K7o9g80j75o6PpXp1jbnkKxMLtZ8=.f32e8e43-7ce2-4d1d-97da-a470b6bcf5bc@github.com>

On Wed, 21 Apr 2021 23:53:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Reorder jcc equal,parity
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Use xorp to negate 1
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1703:
> 
>> 1701:   }
>> 1702: #endif // !PRODUCT
>> 1703:   if (FLAG_IS_DEFAULT(UseSignumIntrinsic) && (UseSSE >= 2)) {
> 
> `UseSSE >=2` looks a bit uncomfortable to me since signumF_reg only requires UseSSE>=1. 
> 
> How about something like this:
> 
> diff --git a/src/hotspot/cpu/x86/x86.ad b/src/hotspot/cpu/x86/x86.ad
> index bbf5256c112..0a738704c4d 100644
> --- a/src/hotspot/cpu/x86/x86.ad
> +++ b/src/hotspot/cpu/x86/x86.ad
> @@ -1598,6 +1598,16 @@ const bool Matcher::match_rule_supported(int opcode) {
>          return false;
>        }
>        break;
> +    case Op_SignumF:
> +      if (UseSSE < 1) {
> +        return false;
> +      }
> +      break;
> +    case Op_SignumD:
> +      if (UseSSE < 2) {
> +        return false;
> +      }
> +      break;
>  #endif // !LP64
>    }
>    return true;  // Match rules are supported by default.
> diff --git a/src/hotspot/share/opto/library_call.cpp b/src/hotspot/share/opto/library_call.cpp
> index 7cb7955c612..217ee39d709 100644
> --- a/src/hotspot/share/opto/library_call.cpp
> +++ b/src/hotspot/share/opto/library_call.cpp
> @@ -1737,8 +1737,8 @@ bool LibraryCallKit::inline_math_native(vmIntrinsics::ID id) {
>    case vmIntrinsics::_dpow:      return inline_math_pow();
>    case vmIntrinsics::_dcopySign: return inline_double_math(id);
>    case vmIntrinsics::_fcopySign: return inline_math(id);
> -  case vmIntrinsics::_dsignum: return inline_double_math(id);
> -  case vmIntrinsics::_fsignum: return inline_math(id);
> +  case vmIntrinsics::_dsignum: return Matcher::match_rule_supported(Op_SignumD) ? inline_double_math(id) : false;
> +  case vmIntrinsics::_fsignum: return Matcher::match_rule_supported(Op_SignumF) ? inline_math(id) : false;
>  
>     // These intrinsics are not yet correctly implemented
>    case vmIntrinsics::_datan2:
> 
> 
> In this way, we can enable UseSignumIntrinsic by default on x86.
> Thanks.

Thanks for the suggestion. This looks good as long as it doesn't affect aarch64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From vlivanov at openjdk.java.net  Thu Apr 22 20:04:35 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 22 Apr 2021 20:04:35 GMT
Subject: RFR: 8264320: ShouldNotReachHere in Compile::print_inlining_move_to()
Message-ID: <fkN1bdoq543dtjlrWrYDMri1WyBtWgiOENx07f0H_oY=.c11df31f-ddd7-47d7-bd77-7e16ffd52274@github.com>

Cloned `CallNode` gets a fresh `CallGenerator` which has to be put on `_print_inlining_list` when -XX:+PrintInlining is used.

Otherwise, if the  `CallGenerator` ends up on `_late_inlines` list (which is processed by `Compile::process_late_inline_calls_no_inline()`, `Compile::print_inlining_move_to()` can't locate it in `_print_inlining_list` and triggers the crash. 

The fix is to put cloned `CallGenerator` next to original one in `_print_inlining_list`.

Testing:
- [x] failing test
- [x] hs-tier1 - hs-tier4

-------------

Commit messages:
 - 8264320: ShouldNotReachHere in Compile::print_inlining_move_to()

Changes: https://git.openjdk.java.net/jdk/pull/3635/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3635&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264320
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3635.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3635/head:pull/3635

PR: https://git.openjdk.java.net/jdk/pull/3635

From kvn at openjdk.java.net  Thu Apr 22 20:39:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 22 Apr 2021 20:39:26 GMT
Subject: RFR: 8264320: ShouldNotReachHere in
 Compile::print_inlining_move_to()
In-Reply-To: <fkN1bdoq543dtjlrWrYDMri1WyBtWgiOENx07f0H_oY=.c11df31f-ddd7-47d7-bd77-7e16ffd52274@github.com>
References: <fkN1bdoq543dtjlrWrYDMri1WyBtWgiOENx07f0H_oY=.c11df31f-ddd7-47d7-bd77-7e16ffd52274@github.com>
Message-ID: <ljn--SmbpoWaiAvGe0PXlYYIjAVDzNyeAkKH15oR2lo=.a7e0373d-1b06-4d09-9f0e-c147122083cb@github.com>

On Thu, 22 Apr 2021 16:56:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Cloned `CallNode` gets a fresh `CallGenerator` which has to be put on `_print_inlining_list` when -XX:+PrintInlining is used.
> 
> Otherwise, if the  `CallGenerator` ends up on `_late_inlines` list (which is processed by `Compile::process_late_inline_calls_no_inline()`, `Compile::print_inlining_move_to()` can't locate it in `_print_inlining_list` and triggers the crash. 
> 
> The fix is to put cloned `CallGenerator` next to original one in `_print_inlining_list`.
> 
> Testing:
> - [x] failing test
> - [x] hs-tier1 - hs-tier4

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3635

From github.com+2249648+johntortugo at openjdk.java.net  Thu Apr 22 22:05:44 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 22 Apr 2021 22:05:44 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v8]
In-Reply-To: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
Message-ID: <f5ZnAIf7-onkXq2Vw4oEmwbdaAaXUxLZTqrBV4G7nMI=.287d5c62-2eee-4b5e-bfa6-16809ae3f4cf@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:

  Fix cast of constant

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2420/files
  - new: https://git.openjdk.java.net/jdk/pull/2420/files/ef7a993c..4b0912ce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 dholmes at openjdk.java.net  Thu Apr 22 22:13:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 22 Apr 2021 22:13:25 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v3]
In-Reply-To: <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>
 <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com>
Message-ID: <ha2xVhIjWYPiLtgQq0eITOJ7jnfxIKaQc5EHq2GSgbc=.cedb1c73-5168-458f-a5c5-c27154d2d22f@github.com>

On Thu, 22 Apr 2021 12:17:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace assert(false) with fatal()
>>   
>>   After a number of people examined this code it was decided that the best approach was to re-instate
>>   the call to fatal() in product builds, that would have been present in the CATCH macro, until recent
>>   changes converted that to an assert(). The code here is not prepared to continue if compute_map fails
>>   so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed
>>   bytecode where verification has been disabled).
>
> Good cleanup!

Thanks @coleenp  and @iklam  for the re-reviews. @dean-long are you also okay with the latest version? It addresses your earlier concern.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/3580

From kvn at openjdk.java.net  Thu Apr 22 22:20:34 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 22 Apr 2021 22:20:34 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v8]
In-Reply-To: <f5ZnAIf7-onkXq2Vw4oEmwbdaAaXUxLZTqrBV4G7nMI=.287d5c62-2eee-4b5e-bfa6-16809ae3f4cf@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <f5ZnAIf7-onkXq2Vw4oEmwbdaAaXUxLZTqrBV4G7nMI=.287d5c62-2eee-4b5e-bfa6-16809ae3f4cf@github.com>
Message-ID: <SqgYPxXIrwLKtI0LBAjdcEnovPA7gtul5LJ68qrUwh0=.52bdf648-5d70-4c08-87ac-a8685d0c4b1c@github.com>

On Thu, 22 Apr 2021 22:05:44 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cast of constant

src/hotspot/cpu/x86/assembler_x86.cpp line 9413:

> 9411: 
> 9412: void Assembler::set_byte_if_not_zero(Register dst) {
> 9413:   emit_int24(0x0F, (unsigned char)0x95, (0xC0 | dst->encoding()));

Can you explain this change?
I see it is used only in c1_LIRAssembler_x86.cpp

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From sviswanathan at openjdk.java.net  Thu Apr 22 22:27:50 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 22 Apr 2021 22:27:50 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly
 intrinsics
Message-ID: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>

Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.

The following changes are made:
   The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
   The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
   The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
   Changes are made to build system to support dependency tracking for assembly files with includes.
   The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
   The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.

Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).

This work is part of second round of incubation of the Vector API.
JEP: https://bugs.openjdk.java.net/browse/JDK-8261663

Please review.

Performance:
Micro benchmark Base Optimized Unit Gain(Optimized/Base)
Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
Double128Vector.COS 49.94 245.89 ops/ms 4.92
Double128Vector.COSH 26.91 126.00 ops/ms 4.68
Double128Vector.EXP 71.64 379.65 ops/ms 5.30
Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
Double128Vector.LOG 61.95 279.84 ops/ms 4.52
Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
Double128Vector.SIN 49.36 240.79 ops/ms 4.88
Double128Vector.SINH 26.59 103.75 ops/ms 3.90
Double128Vector.TAN 41.05 152.39 ops/ms 3.71
Double128Vector.TANH 45.29 169.53 ops/ms 3.74
Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
Double256Vector.COS 58.26 389.77 ops/ms 6.69
Double256Vector.COSH 29.44 151.11 ops/ms 5.13
Double256Vector.EXP 86.67 564.68 ops/ms 6.52
Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
Double256Vector.LOG 71.52 394.90 ops/ms 5.52
Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
Double256Vector.SIN 57.06 380.98 ops/ms 6.68
Double256Vector.SINH 29.40 117.37 ops/ms 3.99
Double256Vector.TAN 44.90 279.90 ops/ms 6.23
Double256Vector.TANH 54.08 274.71 ops/ms 5.08
Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
Double512Vector.COS 59.88 837.04 ops/ms 13.98
Double512Vector.COSH 30.34 172.76 ops/ms 5.70
Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
Double512Vector.LOG 74.84 996.00 ops/ms 13.31
Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
Double512Vector.POW 37.42 384.13 ops/ms 10.26
Double512Vector.SIN 59.74 728.45 ops/ms 12.19
Double512Vector.SINH 29.47 143.38 ops/ms 4.87
Double512Vector.TAN 46.20 587.21 ops/ms 12.71
Double512Vector.TANH 57.36 495.42 ops/ms 8.64
Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
Double64Vector.COS 23.42 152.01 ops/ms 6.49
Double64Vector.COSH 17.34 113.34 ops/ms 6.54
Double64Vector.EXP 27.08 203.53 ops/ms 7.52
Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
Double64Vector.LOG 26.75 142.63 ops/ms 5.33
Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
Double64Vector.SIN 23.28 146.91 ops/ms 6.31
Double64Vector.SINH 17.62 88.59 ops/ms 5.03
Double64Vector.TAN 21.00 86.43 ops/ms 4.12
Double64Vector.TANH 23.75 111.35 ops/ms 4.69
Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
Float128Vector.COS 42.82 803.02 ops/ms 18.75
Float128Vector.COSH 31.44 118.34 ops/ms 3.76
Float128Vector.EXP 72.43 855.33 ops/ms 11.81
Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
Float128Vector.LOG 52.95 877.94 ops/ms 16.58
Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
Float128Vector.SIN 43.38 745.31 ops/ms 17.18
Float128Vector.SINH 31.11 112.91 ops/ms 3.63
Float128Vector.TAN 37.25 332.13 ops/ms 8.92
Float128Vector.TANH 57.63 453.77 ops/ms 7.87
Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
Float256Vector.COS 43.75 926.69 ops/ms 21.18
Float256Vector.COSH 33.52 130.46 ops/ms 3.89
Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
Float256Vector.SIN 44.07 911.04 ops/ms 20.67
Float256Vector.SINH 33.16 122.50 ops/ms 3.69
Float256Vector.TAN 37.85 497.75 ops/ms 13.15
Float256Vector.TANH 64.27 537.20 ops/ms 8.36
Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
Float512Vector.COS 40.92 1567.93 ops/ms 38.32
Float512Vector.COSH 33.42 138.36 ops/ms 4.14
Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
Float512Vector.POW 32.73 1015.85 ops/ms 31.04
Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
Float512Vector.SINH 33.05 129.39 ops/ms 3.91
Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
Float64Vector.COS 44.28 394.33 ops/ms 8.91
Float64Vector.COSH 28.35 95.27 ops/ms 3.36
Float64Vector.EXP 65.80 486.37 ops/ms 7.39
Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
Float64Vector.LOG 51.93 163.25 ops/ms 3.14
Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
Float64Vector.SIN 44.41 382.09 ops/ms 8.60
Float64Vector.SINH 28.20 90.68 ops/ms 3.22
Float64Vector.TAN 36.29 160.89 ops/ms 4.43
Float64Vector.TANH 47.65 214.04 ops/ms 4.49

-------------

Commit messages:
 - remove whitespace
 - Merge master
 - Small fix
 - cleanup
 - x86 short vector math optimization for Vector API

Changes: https://git.openjdk.java.net/jdk/pull/3638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265783
  Stats: 417153 lines in 124 files changed: 416959 ins; 126 del; 68 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From github.com+2249648+johntortugo at openjdk.java.net  Thu Apr 22 22:34:25 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 22 Apr 2021 22:34:25 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v8]
In-Reply-To: <SqgYPxXIrwLKtI0LBAjdcEnovPA7gtul5LJ68qrUwh0=.52bdf648-5d70-4c08-87ac-a8685d0c4b1c@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <f5ZnAIf7-onkXq2Vw4oEmwbdaAaXUxLZTqrBV4G7nMI=.287d5c62-2eee-4b5e-bfa6-16809ae3f4cf@github.com>
 <SqgYPxXIrwLKtI0LBAjdcEnovPA7gtul5LJ68qrUwh0=.52bdf648-5d70-4c08-87ac-a8685d0c4b1c@github.com>
Message-ID: <oJeuQIlVhV8wCik2NPLLG1KlaOEuCr3DcfeetWYQ-co=.0ae4ba29-8adf-44ab-9b03-215c8a3f6503@github.com>

On Thu, 22 Apr 2021 22:17:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix cast of constant
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 9413:
> 
>> 9411: 
>> 9412: void Assembler::set_byte_if_not_zero(Register dst) {
>> 9413:   emit_int24(0x0F, (unsigned char)0x95, (0xC0 | dst->encoding()));
> 
> Can you explain this change?
> I see it is used only in c1_LIRAssembler_x86.cpp

The operand encoding of SETNE r/m8 is just 0b11.000.000 AFAIU, and not 0b11.100.000 as in the previous code. I found this difference while comparing the bytes emitted by instructions encoded using "opcode(...)" with instructions emitted by MacroAssembler.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From github.com+2249648+johntortugo at openjdk.java.net  Thu Apr 22 22:34:26 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 22 Apr 2021 22:34:26 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v8]
In-Reply-To: <oJeuQIlVhV8wCik2NPLLG1KlaOEuCr3DcfeetWYQ-co=.0ae4ba29-8adf-44ab-9b03-215c8a3f6503@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <f5ZnAIf7-onkXq2Vw4oEmwbdaAaXUxLZTqrBV4G7nMI=.287d5c62-2eee-4b5e-bfa6-16809ae3f4cf@github.com>
 <SqgYPxXIrwLKtI0LBAjdcEnovPA7gtul5LJ68qrUwh0=.52bdf648-5d70-4c08-87ac-a8685d0c4b1c@github.com>
 <oJeuQIlVhV8wCik2NPLLG1KlaOEuCr3DcfeetWYQ-co=.0ae4ba29-8adf-44ab-9b03-215c8a3f6503@github.com>
Message-ID: <Midgy-tNCfHF9eqWe6MtGPnIvCVtnKiNr43_XuDNqgo=.4ea3d1fd-9578-4f1a-82bd-36010454c0b0@github.com>

On Thu, 22 Apr 2021 22:29:49 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

>> src/hotspot/cpu/x86/assembler_x86.cpp line 9413:
>> 
>>> 9411: 
>>> 9412: void Assembler::set_byte_if_not_zero(Register dst) {
>>> 9413:   emit_int24(0x0F, (unsigned char)0x95, (0xC0 | dst->encoding()));
>> 
>> Can you explain this change?
>> I see it is used only in c1_LIRAssembler_x86.cpp
>
> The operand encoding of SETNE r/m8 is just 0b11.000.000 AFAIU, and not 0b11.100.000 as in the previous code. I found this difference while comparing the bytes emitted by instructions encoded using "opcode(...)" with instructions emitted by MacroAssembler.

I.e., I basically patched the MacroAssembler routine to emit an instruction that matched this: https://github.com/openjdk/jdk/blob/b84f6901275aedfeb59438898846b6e69ced316d/src/hotspot/cpu/x86/x86_64.ad#L2750

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From kvn at openjdk.java.net  Thu Apr 22 22:39:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 22 Apr 2021 22:39:26 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v8]
In-Reply-To: <Midgy-tNCfHF9eqWe6MtGPnIvCVtnKiNr43_XuDNqgo=.4ea3d1fd-9578-4f1a-82bd-36010454c0b0@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <f5ZnAIf7-onkXq2Vw4oEmwbdaAaXUxLZTqrBV4G7nMI=.287d5c62-2eee-4b5e-bfa6-16809ae3f4cf@github.com>
 <SqgYPxXIrwLKtI0LBAjdcEnovPA7gtul5LJ68qrUwh0=.52bdf648-5d70-4c08-87ac-a8685d0c4b1c@github.com>
 <oJeuQIlVhV8wCik2NPLLG1KlaOEuCr3DcfeetWYQ-co=.0ae4ba29-8adf-44ab-9b03-215c8a3f6503@github.com>
 <Midgy-tNCfHF9eqWe6MtGPnIvCVtnKiNr43_XuDNqgo=.4ea3d1fd-9578-4f1a-82bd-36010454c0b0@github.com>
Message-ID: <pJF9fomhASjXjwzxCJ6vxeUU3Vj16hBJBcoK_0O_Fek=.d7201e14-db03-4c8f-a355-bb0172781e84@github.com>

On Thu, 22 Apr 2021 22:31:24 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

>> The operand encoding of SETNE r/m8 is just 0b11.000.000 AFAIU, and not 0b11.100.000 as in the previous code. I found this difference while comparing the bytes emitted by instructions encoded using "opcode(...)" with instructions emitted by MacroAssembler.
>
> I.e., I basically patched the MacroAssembler routine to emit an instruction that matched this: https://github.com/openjdk/jdk/blob/b84f6901275aedfeb59438898846b6e69ced316d/src/hotspot/cpu/x86/x86_64.ad#L2750

Got it. I submitted new testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From kvn at openjdk.java.net  Thu Apr 22 23:53:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 22 Apr 2021 23:53:26 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v8]
In-Reply-To: <f5ZnAIf7-onkXq2Vw4oEmwbdaAaXUxLZTqrBV4G7nMI=.287d5c62-2eee-4b5e-bfa6-16809ae3f4cf@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <f5ZnAIf7-onkXq2Vw4oEmwbdaAaXUxLZTqrBV4G7nMI=.287d5c62-2eee-4b5e-bfa6-16809ae3f4cf@github.com>
Message-ID: <AFQ7u2FdiJg1cE0k1VHPlLJVOSgDf3KiSFKdhPXHqVI=.b4ad8621-a12d-4775-9fac-59981bfd327b@github.com>

On Thu, 22 Apr 2021 22:05:44 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cast of constant

I got a lot of failures on Windows only. Almost all test/hotspot/jtreg/serviceability/sa/ tests failed and others.
Examples:

serviceability/sa/TestSysProps.java

#  Internal Error (t:\\workspace\\open\\src\\hotspot\\share\\runtime\\stackValue.cpp:139), pid=7572, tid=26052
#  assert(oopDesc::is_oop_or_null(val, false)) failed: bad oop found

compiler/c2/Test6800154.java
java.lang.InternalError: 9223372036854775807 / -9223372036854775808 failed: 65547 != 0
	at compiler.c2.Test6800154.run(Test6800154.java:111)
	at compiler.c2.Test6800154.main(Test6800154.java:97)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From jiefu at openjdk.java.net  Thu Apr 22 23:56:35 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 22 Apr 2021 23:56:35 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v6]
In-Reply-To: <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com>
Message-ID: <lcsOuPxcMAJy4xX0MN4yxomQyz0kk2FOkx50FfkhPxo=.a9d3a9bb-ab25-42b2-acbe-8f353e30a7c7@github.com>

On Thu, 22 Apr 2021 18:44:58 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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 two additional commits since the last revision:
> 
>  - Implement Default UseSignumIntrinsic suggestion
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Use three operand xorps/d
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Looks good to me.
Thanks for your update.

Please make sure the copyright year has been updated (TestSignumIntrinsic.java?) and all the imports are actually needed (import org.openjdk.jmh.annotations.Setup; ?).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From dlong at openjdk.java.net  Fri Apr 23 00:48:27 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 23 Apr 2021 00:48:27 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v3]
In-Reply-To: <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>
Message-ID: <TB26FG6gTrwPO-FVOsV_hmc8kxmQwL__jzcSUQOBA78=.58c8138f-603f-4a8b-96ef-82bf39ea376a@github.com>

On Thu, 22 Apr 2021 07:31:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>> 
>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>> 
>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace assert(false) with fatal()
>   
>   After a number of people examined this code it was decided that the best approach was to re-instate
>   the call to fatal() in product builds, that would have been present in the CATCH macro, until recent
>   changes converted that to an assert(). The code here is not prepared to continue if compute_map fails
>   so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed
>   bytecode where verification has been disabled).

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3580

From dlong at openjdk.java.net  Fri Apr 23 00:48:28 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 23 Apr 2021 00:48:28 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v3]
In-Reply-To: <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>
 <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com>
Message-ID: <gUd0jnwzsYQr9TCq9AKcBeouaBjpOEXbX7akAsbIbrc=.cc4a40e5-1f86-42c2-8c1b-40a5620ef765@github.com>

On Thu, 22 Apr 2021 12:17:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace assert(false) with fatal()
>>   
>>   After a number of people examined this code it was decided that the best approach was to re-instate
>>   the call to fatal() in product builds, that would have been present in the CATCH macro, until recent
>>   changes converted that to an assert(). The code here is not prepared to continue if compute_map fails
>>   so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed
>>   bytecode where verification has been disabled).
>
> Good cleanup!

> Thanks @coleenp and @iklam for the re-reviews. @dean-long are you also okay with the latest version? It addresses your earlier concern.
> 
> Thanks,
> David

Yes, looks good!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3580

From dholmes at openjdk.java.net  Fri Apr 23 01:17:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 23 Apr 2021 01:17:26 GMT
Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map
 and callers [v3]
In-Reply-To: <gUd0jnwzsYQr9TCq9AKcBeouaBjpOEXbX7akAsbIbrc=.cc4a40e5-1f86-42c2-8c1b-40a5620ef765@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
 <doxZZBsEPLLNqcUHts-pkxHXAyaiex1ozqU5avDUAaE=.b855a38d-6f0c-4e89-a8cd-fb747fbd163d@github.com>
 <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com>
 <gUd0jnwzsYQr9TCq9AKcBeouaBjpOEXbX7akAsbIbrc=.cc4a40e5-1f86-42c2-8c1b-40a5620ef765@github.com>
Message-ID: <JGannSi4F8l3oOUO1LN65EINxE7b-gCZYpc2-CMT84Q=.2c36bc23-7ffd-4f84-ba51-58bbfbe2f51a@github.com>

On Fri, 23 Apr 2021 00:45:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Good cleanup!
>
>> Thanks @coleenp and @iklam for the re-reviews. @dean-long are you also okay with the latest version? It addresses your earlier concern.
>> 
>> Thanks,
>> David
> 
> Yes, looks good!

Thanks @dean-long !

-------------

PR: https://git.openjdk.java.net/jdk/pull/3580

From dholmes at openjdk.java.net  Fri Apr 23 01:17:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 23 Apr 2021 01:17:26 GMT
Subject: Integrated: 8265484: Fix up TRAPS usage in
 GenerateOopMap::compute_map and callers
In-Reply-To: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
References: <o3EeKAGgnPuuPdvG-MpyX_TtGXx_Fud8_J32S5O33kw=.a298c212-96d1-489b-ac71-04e067b0ae2d@github.com>
Message-ID: <_e0sanqzoSSP1_3CfSVt6oQFmA4F3z41pODZUuJN3dg=.7cb33124-bb3b-4bb8-8097-ea24d44ba5d3@github.com>

On Mon, 19 Apr 2021 21:38:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
> 
> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
> 
> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 13d32633
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/13d32633
Stats:     44 lines in 4 files changed: 16 ins; 11 del; 17 mod

8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers

Reviewed-by: iklam, dlong, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/3580

From sviswanathan at openjdk.java.net  Fri Apr 23 01:23:50 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 23 Apr 2021 01:23:50 GMT
Subject: RFR: 8265816: Handle new VectorMaskCast node for x86
Message-ID: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>

To eliminate unnecessary vector mask conversion during unboxing a
VectorMaskCast node was added as part of JDK-8264104 for aarch64. This patch handles the x86 side of it.

Please review.

Best Regards,
Sandhya

-------------

Commit messages:
 - 8265816: Handle new VectorMaskCast node for x86

Changes: https://git.openjdk.java.net/jdk/pull/3645/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3645&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265816
  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3645.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3645/head:pull/3645

PR: https://git.openjdk.java.net/jdk/pull/3645

From jiefu at openjdk.java.net  Fri Apr 23 01:47:26 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 23 Apr 2021 01:47:26 GMT
Subject: RFR: 8265816: Handle new VectorMaskCast node for x86
In-Reply-To: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
References: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
Message-ID: <WGCGOscWrVdeXLVajsIhYb6-y-Ldytx0U0D67PT-mKU=.6b0cea2c-6a91-4060-a701-1fc514409061@github.com>

On Fri, 23 Apr 2021 01:15:37 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> To eliminate unnecessary vector mask conversion during unboxing a
> VectorMaskCast node was added as part of JDK-8264104 for aarch64. This patch handles the x86 side of it.
> 
> Please review.
> 
> Best Regards,
> Sandhya

Is there a small program which can be used to verify the effect of this opt?
I just want to learn how this kind of opt works, not to require a jtreg test.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3645

From whuang at openjdk.java.net  Fri Apr 23 03:04:26 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 23 Apr 2021 03:04:26 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <u3i4urpIMZovq5SzU7tfwg6gRF4mF0_S0pt3jFS0GgA=.a648d13f-6ee8-4d68-ad96-aeae58da7a54@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
 <Tc0XCuCtXO7vixyHY951U3RwRH-hbwUNw29PfU_nLQQ=.4a16ced5-9b5b-44f5-823e-a3136eb39ee3@github.com>
 <Kk19BJtpiMR9di5G_hGoKcFpY9SHIPTd99H-3_YgMdM=.6747cc6c-f952-41aa-a5a6-07321a0b24d1@github.com>
 <u3i4urpIMZovq5SzU7tfwg6gRF4mF0_S0pt3jFS0GgA=.a648d13f-6ee8-4d68-ad96-aeae58da7a54@github.com>
Message-ID: <POJXAIWo8KbWV219C9e44zQOJ3BwvPvrXfFdgE_SH8A=.4309e635-9082-4242-bd97-f1a5e04d71b9@github.com>

On Thu, 22 Apr 2021 02:35:48 GMT, Wang Huang <whuang at openjdk.org> wrote:

> > > Running MyBenchmark test listed in the summary on x86_64 Haswell XEON with this patch results in:
> > > ```
> > > # Benchmark: org.sample.MyBenchmark.testMax
> > > 
> > > # Run progress: 25.00% complete, ETA 00:03:57
> > > # Fork: 1 of 1                                                                                                                                                              # Warmup Iteration   1: 112.714 us/op
> > > # Warmup Iteration   2: # To suppress the following error report, specify this argument
> > > # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152                                                                                                           #
> > > # A fatal error has been detected by the Java Runtime Environment:
> > > #
> > > #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450238, tid=3450253
> > > #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> > > #
> > > # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk) 
> > > ```
> > > 
> > > 
> > > AND
> > > ```
> > > # Benchmark: org.sample.MyBenchmark.testMin
> > > 
> > > # Run progress: 25.00% complete, ETA 00:03:57
> > > # Fork: 1 of 1
> > > # Warmup Iteration   1: 112.445 us/op
> > > # Warmup Iteration   2: # To suppress the following error report, specify this argument
> > > # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152
> > > #
> > > # A fatal error has been detected by the Java Runtime Environment:
> > > #
> > > #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450444, tid=3450481
> > > #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> > > #
> > > # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk)
> > > ```
> > > 
> > > 
> > > Otherwise the results are below.
> > > ```
> > > Baseline
> > > Benchmark            Mode  Cnt    Score     Error  Units
> > > MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
> > > MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
> > > MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
> > > MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
> > > Finished running test 'micro:MyBenchmark'
> > > ```
> > > 
> > > 
> > > ```
> > > Benchmark            Mode  Cnt    Score   Error  Units
> > > MyBenchmark.testAdd  avgt    5  107.874 ? 0.148  us/op
> > > MyBenchmark.testMul  avgt    5  107.881 ? 0.015  us/op
> > > Finished running test 'micro:MyBenchmark'
> > > ```
> > 
> > 
> > > MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
> > > MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
> > > MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
> > > MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
> > 
> > 
> > I run this test case by `java -jar target/benchmarks.jar -i 10 -wi 10 -f 1 `on ` Intel(R) Xeon(R) CPU E7-8890 v4 @ 2.20GHz` without crash. Can you give me your jvm options and this crash log? Thank you very much.
> 
> Certainly. Tomorrow morning (my time) I will re-run with your command and test on a few other Xeons. I need to re-run to get crash logs (I'm jumping around between patches and cleaned already) but I will post those when I can recreate.
> 
> To run I copied MyBenchmark.java from summary to test/micro/org/openjdk/bench/vm/compiler/MyBenchmark.java
> Command on running was:
> `make test TEST="micro:MyBenchmark" MICRO="FORK=1;WARMUP_ITER=2;" CONF=linux-x86_64-server-slowdebug`
> 
> This worked on master, but on checkout of pr/3513 caused the errors above.

I have tested on my ` Intel(R) Xeon(R) CPU E7-8890 v4 @ 2.20GHz`  on `make test TEST="micro:MyBenchmark" MICRO="FORK=1;WARMUP_ITER=2;" CONF=linux-x86_64-server-slowdebug`. It seems that all things are right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From yyang at openjdk.java.net  Fri Apr 23 03:50:54 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 23 Apr 2021 03:50:54 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  remove java_nio_Buffer in javaClasses.hpp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/a6affc54..7f30dc48

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=00-01

  Stats: 27 lines in 2 files changed: 0 ins; 27 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From thartmann at openjdk.java.net  Fri Apr 23 06:29:26 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 23 Apr 2021 06:29:26 GMT
Subject: RFR: 8264320: ShouldNotReachHere in
 Compile::print_inlining_move_to()
In-Reply-To: <fkN1bdoq543dtjlrWrYDMri1WyBtWgiOENx07f0H_oY=.c11df31f-ddd7-47d7-bd77-7e16ffd52274@github.com>
References: <fkN1bdoq543dtjlrWrYDMri1WyBtWgiOENx07f0H_oY=.c11df31f-ddd7-47d7-bd77-7e16ffd52274@github.com>
Message-ID: <dNb4StJYZJ3gBQDC5xlwVxESDkirXpPug5B6m6N9xeA=.21bc2cbf-1f0f-49a6-b53f-1c7405d84104@github.com>

On Thu, 22 Apr 2021 16:56:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Cloned `CallNode` gets a fresh `CallGenerator` which has to be put on `_print_inlining_list` when -XX:+PrintInlining is used.
> 
> Otherwise, if the  `CallGenerator` ends up on `_late_inlines` list (which is processed by `Compile::process_late_inline_calls_no_inline()`, `Compile::print_inlining_move_to()` can't locate it in `_print_inlining_list` and triggers the crash. 
> 
> The fix is to put cloned `CallGenerator` next to original one in `_print_inlining_list`.
> 
> Testing:
> - [x] failing test
> - [x] hs-tier1 - hs-tier4

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3635

From rcastanedalo at openjdk.java.net  Fri Apr 23 07:24:24 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 23 Apr 2021 07:24:24 GMT
Subject: RFR: 8264842: IGV: different nodes sharing idx are treated as
 equal
In-Reply-To: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
References: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
Message-ID: <WRb5yrvZcIli5SWi2ZgI3k0YaLNPJkdc8naN7SDrnGo=.71f5f0e1-b4fb-49aa-9aa2-16ed219c04f7@github.com>

On Tue, 20 Apr 2021 20:33:25 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change replaces `Node::_idx` with a dedicated `Node::_igv_idx` as the internal node identifier for IGV. `_igv_idx` is unique across all phases in a compilation, which prevents IGV from wrongly treating unrelated nodes as if they were the same.`_igv_idx` is proposed instead of `Node::_debug_idx`, which is also unique across phases, for stability (the `_debug_idx` identifiers of a compilation are affected by the entire compilation history) and flexibility (future enhancements such as [JDK-8265587](https://bugs.openjdk.java.net/browse/JDK-8265587) require altering the node identifier in IGV-specific ways).
> 
> The following figure illustrates the effect of using `_igv_idx` instead of `_idx` as an internal node identifier. Using  `_idx` (left), node 54 is wrongly treated as created in two different phases (two green circles in the graph snapshot view), whereas using `_igv_idx` (right), node 54 is shown as created once, as expected:
> 
> ![before-after-fix](https://user-images.githubusercontent.com/8792647/115462349-d624e380-a22a-11eb-8d29-810a5ccbd09c.png)
> 
> At the IGV user interface level, this change encapsulates the internal node identifier by showing a "short node text" (configurable from `Tools -> Options`, defaulting to `[idx] [name]`) in all places where the internal identifier was exposed before: edge tooltips, slot tooltips, and the node search results. The code in [ViewPanel.form](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-9b4fd66fc1b7a93a40abcec79b8825db44bdef62f13fede745238c3b87a2ab90) and [ViewPanel.java](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-c8cfda144359ba8b317fd0d02988dc0798418dcd211eb5eb91c3ed94567684d3) is generated by NetBeans 12.3 by editing ViewPanel.java in "Design" mode.
> 
> #### Testing
> 
> - Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
> - Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
> - Tested manually, for a few graphs, that nodes are treated as created exactly once by IGV (by selecting single nodes and checking that a single green circle appears in the graph snapshot view, as in the right screenshot above).
> - Tested manually that the new `Short Node Text` field in `Tools -> Options` is displayed and stored correctly, and that it is honored by edge tooltips, slot tooltips, and node search results (on Linux and Windows, for JDK 8, 11, and 15).

Thanks for reviewing, Igor and Vladimir!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3593

From rcastanedalo at openjdk.java.net  Fri Apr 23 07:33:24 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 23 Apr 2021 07:33:24 GMT
Subject: Integrated: 8264842: IGV: different nodes sharing idx are treated as
 equal
In-Reply-To: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
References: <vzz2leyLRiY3GuYz7l96xe1roXzGwHMZ7J3NIYs4iVc=.aa582a4f-9a62-4a76-8bfa-d79a5742245e@github.com>
Message-ID: <2ahVEF11R4vAnPeWGLnSkvzSNTpXzPgIORXvMZnpknk=.04556803-1b8f-4415-9c98-1e0858e93a1f@github.com>

On Tue, 20 Apr 2021 20:33:25 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change replaces `Node::_idx` with a dedicated `Node::_igv_idx` as the internal node identifier for IGV. `_igv_idx` is unique across all phases in a compilation, which prevents IGV from wrongly treating unrelated nodes as if they were the same.`_igv_idx` is proposed instead of `Node::_debug_idx`, which is also unique across phases, for stability (the `_debug_idx` identifiers of a compilation are affected by the entire compilation history) and flexibility (future enhancements such as [JDK-8265587](https://bugs.openjdk.java.net/browse/JDK-8265587) require altering the node identifier in IGV-specific ways).
> 
> The following figure illustrates the effect of using `_igv_idx` instead of `_idx` as an internal node identifier. Using  `_idx` (left), node 54 is wrongly treated as created in two different phases (two green circles in the graph snapshot view), whereas using `_igv_idx` (right), node 54 is shown as created once, as expected:
> 
> ![before-after-fix](https://user-images.githubusercontent.com/8792647/115462349-d624e380-a22a-11eb-8d29-810a5ccbd09c.png)
> 
> At the IGV user interface level, this change encapsulates the internal node identifier by showing a "short node text" (configurable from `Tools -> Options`, defaulting to `[idx] [name]`) in all places where the internal identifier was exposed before: edge tooltips, slot tooltips, and the node search results. The code in [ViewPanel.form](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-9b4fd66fc1b7a93a40abcec79b8825db44bdef62f13fede745238c3b87a2ab90) and [ViewPanel.java](https://github.com/openjdk/jdk/compare/master...robcasloz:JDK-8264842?expand=1#diff-c8cfda144359ba8b317fd0d02988dc0798418dcd211eb5eb91c3ed94567684d3) is generated by NetBeans 12.3 by editing ViewPanel.java in "Design" mode.
> 
> #### Testing
> 
> - Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
> - Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
> - Tested manually, for a few graphs, that nodes are treated as created exactly once by IGV (by selecting single nodes and checking that a single green circle appears in the graph snapshot view, as in the right screenshot above).
> - Tested manually that the new `Short Node Text` field in `Tools -> Options` is displayed and stored correctly, and that it is honored by edge tooltips, slot tooltips, and node search results (on Linux and Windows, for JDK 8, 11, and 15).

This pull request has now been integrated.

Changeset: b3a319c8
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b3a319c8
Stats:     239 lines in 19 files changed: 132 ins; 57 del; 50 mod

8264842: IGV: different nodes sharing idx are treated as equal

Introduce IGV-specific node identifier and encapsulate it in IGV by showing a
configurable 'short node text' string instead.

Reviewed-by: iveresov, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3593

From aph at openjdk.java.net  Fri Apr 23 09:00:37 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 23 Apr 2021 09:00:37 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v6]
In-Reply-To: <PiSIVj94iTW3hzwa3xfRmnled8s2VYt_DwYwKfVqkkA=.e13b7684-1058-4ae7-83e9-0574c2401f9e@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
 <RQ-UY2pbK_tM0uClYIX7QkQfklM-mYNFcRhOuU5dYGI=.1e581242-968d-4b8e-b4b2-d208def74cf2@github.com>
 <PMeH4jlv-li4aLxa28pPqlYHdv6P03Fm5fM0MTmGcQE=.56c784c5-da79-48b1-822a-d420ecf4c2bb@github.com>
 <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com>
 <PiSIVj94iTW3hzwa3xfRmnled8s2VYt_DwYwKfVqkkA=.e13b7684-1058-4ae7-83e9-0574c2401f9e@github.com>
Message-ID: <0Avbb0TUKgZg5On5mRpirby1UyAqSKc8vQYIly1J2Bo=.dd8d60ef-e328-4624-a89b-fe3e4789deda@github.com>

On Wed, 21 Apr 2021 17:26:30 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> I am referring to moving the instruction sequence into a macro assembly routine for better code sharing, one should be enough for both float and double type, please refer to following snippet for more detail.
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L5672
>
> Hi @jatin-bhateja your original request was quite unclear. The highlighting of the code was incorrect and the use of 'this' made it unclear what you were suggesting and you did not explain a reason for the suggestion. 
> 
>> Can you kindly move **this** into a macro assembly routine.
> 
> Seeing "better code sharing" as the reason it's unclear to me if the proposed refactor results in any meaningful benefit for the work involved. It's also unclear if there are any hard code structure or style issues that would necessitate the move.
> 
> The refactor you suggest calls for the instruction sequences here to be moved into a src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp function that is then called here. Inside that function there is a selection between float and double but otherwise stays the same except one is formatted .AD and one is .CPP/.HPP. 
> 
> If I am doing this refactor for `instruct signumF_reg` and `instruct signumD_reg` to cut down on code duplication, I see that as close to a wash for saving of code lines and effort involved. I also think this would make the code more complex to read.
> 
> However if there are strong opinions as to why this is necessary I'd be happy to hear them.

I think it'd be easier to understand with a signum macro in MacroAssembler. Less code duplication is good, obviously. And it's potentially useful elsewhere. Win-win-win.
We've already factored out C2 instruction sequences for things like vabsnegd  into c2_MacroAssembler_x86.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From whuang at openjdk.java.net  Fri Apr 23 09:07:48 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 23 Apr 2021 09:07:48 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v3]
In-Reply-To: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
Message-ID: <Dyot6mD3ixa6I06Z_sZqMC5n_SmM71Du9ehPYrxjp_w=.7ee20464-de2f-4a4f-9b52-82bae02a65fc@github.com>

> * I optimize `max` and `min` by using these identities 
>     - op (max(a,b) , min(a,b))=== op(a,b)
>     - if op is commutable
>     - example : 
>       - max(a,b) + min(a,b))=== a + b // op = add
>       - max(a,b) * min(a,b))=== a * b  // op = mul
>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
> * Test case 
>   ```java
>   /*
>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
>    * under the terms of the GNU General Public License version 2 only, as
>    * published by the Free Software Foundation.
>    *
>    * This code is distributed in the hope that it will be useful, but WITHOUT
>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>    * version 2 for more details (a copy is included in the LICENSE file that
>    * accompanied this code).
>    *
>    * You should have received a copy of the GNU General Public License version
>    * 2 along with this work; if not, write to the Free Software Foundation,
>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>    *
>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>    * or visit www.oracle.com if you need additional information or have any
>    * questions.
>    */
>   package org.sample;
>   
>   import org.openjdk.jmh.annotations.Benchmark;
>   import org.openjdk.jmh.annotations.*;
>   
>   import java.util.Random;
>   import java.util.concurrent.TimeUnit;
>   import org.openjdk.jmh.infra.Blackhole;
>   
>   @BenchmarkMode({Mode.AverageTime})
>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>   public class MyBenchmark {
>   
>       static int length = 100000;
>       static double[] data1 = new double[length];
>       static double[] data2 = new double[length];
>       static Random random = new Random();
>   
>       static {
>           for(int i = 0; i < length; ++i) {
>             data1[i] = random.nextDouble();
>             data2[i] = random.nextDouble();
>           }
>       }
>   
>       @Benchmark
>       public void testAdd(Blackhole bh) {
>         double sum = 0;
>         for (int i = 0; i < length; i++) {
>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>         }
>         bh.consume(sum);
>       }
>   
>       @Benchmark
>       public void testMax(Blackhole bh) {
>           double sum = 0;
>           for (int i = 0; i < length; i++) {
>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>           }
>           bh.consume(sum);
>       }
>   
>       @Benchmark
>       public void testMin(Blackhole bh) {
>           double sum = 0;
>           for (int i = 0; i < length; i++) {
>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>           }
>           bh.consume(sum);
>       }
>   
>       @Benchmark
>       public void testMul(Blackhole bh) {
>           double sum = 0;
>           for (int i = 0; i < length; i++) {
>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>           }
>           bh.consume(sum);
>       }
>   }
>   ```
> 
> *  The result is listed here (aarch64):
> 
>   before:
> 
>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>   |---|                           ---|  ---|    ---|  --- | ---|
>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>  
>   after:
> 
>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>   |---|                           ---|  ---|    ---|  --- | ---|
>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |
> 
> *  I have tested `NaN`  ` INFINITY` and `-INFINITY` and got same result (before/after)

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  fix bugs & add test case

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3513/files
  - new: https://git.openjdk.java.net/jdk/pull/3513/files/7579586f..8aef3596

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3513&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3513&range=01-02

  Stats: 211 lines in 3 files changed: 209 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3513.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3513/head:pull/3513

PR: https://git.openjdk.java.net/jdk/pull/3513

From whuang at openjdk.java.net  Fri Apr 23 09:07:49 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 23 Apr 2021 09:07:49 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <POJXAIWo8KbWV219C9e44zQOJ3BwvPvrXfFdgE_SH8A=.4309e635-9082-4242-bd97-f1a5e04d71b9@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
 <Tc0XCuCtXO7vixyHY951U3RwRH-hbwUNw29PfU_nLQQ=.4a16ced5-9b5b-44f5-823e-a3136eb39ee3@github.com>
 <Kk19BJtpiMR9di5G_hGoKcFpY9SHIPTd99H-3_YgMdM=.6747cc6c-f952-41aa-a5a6-07321a0b24d1@github.com>
 <u3i4urpIMZovq5SzU7tfwg6gRF4mF0_S0pt3jFS0GgA=.a648d13f-6ee8-4d68-ad96-aeae58da7a54@github.com>
 <POJXAIWo8KbWV219C9e44zQOJ3BwvPvrXfFdgE_SH8A=.4309e635-9082-4242-bd97-f1a5e04d71b9@github.com>
Message-ID: <9oHnEGs2dzrNBUeQGxgDVTwknSa8XdxCIuq75KMKAFU=.67efd418-22f5-4ab4-b933-51dccf15961e@github.com>

On Fri, 23 Apr 2021 03:01:17 GMT, Wang Huang <whuang at openjdk.org> wrote:

> Running MyBenchmark test listed in the summary on x86_64 Haswell XEON with this patch results in:
> 
> ```
> # Benchmark: org.sample.MyBenchmark.testMax
> 
> # Run progress: 25.00% complete, ETA 00:03:57
> # Fork: 1 of 1                                                                                                                                                              # Warmup Iteration   1: 112.714 us/op
> # Warmup Iteration   2: # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152                                                                                                           #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450238, tid=3450253
> #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> #
> # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk) 
> ```
> 
> AND
> 
> ```
> # Benchmark: org.sample.MyBenchmark.testMin
> 
> # Run progress: 25.00% complete, ETA 00:03:57
> # Fork: 1 of 1
> # Warmup Iteration   1: 112.445 us/op
> # Warmup Iteration   2: # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/register.hpp:152
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/mgkwill/src/git/jdk/src/hotspot/share/asm/register.hpp:152), pid=3450444, tid=3450481
> #  assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x0000000000000001, b=0x0000000000000001, c=0x0000000000000003, d=0x0000000000000004, e=0x0000000000000005
> #
> # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.mgkwill.jdk)
> ```
> 
> Otherwise the results are below.
> 
> ```
> Baseline
> Benchmark            Mode  Cnt    Score     Error  Units
> MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
> MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
> MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
> MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
> Finished running test 'micro:MyBenchmark'
> ```
> 
> ```
> Benchmark            Mode  Cnt    Score   Error  Units
> MyBenchmark.testAdd  avgt    5  107.874 ? 0.148  us/op
> MyBenchmark.testMul  avgt    5  107.881 ? 0.015  us/op
> Finished running test 'micro:MyBenchmark'
> ```

I fix a bug in my code. I am not sure if it is the reason of your crash. However, you can pull the latest code and test again. Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From vlivanov at openjdk.java.net  Fri Apr 23 10:12:23 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 23 Apr 2021 10:12:23 GMT
Subject: RFR: 8265816: Handle new VectorMaskCast node for x86
In-Reply-To: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
References: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
Message-ID: <VqnU0iC8X6zDVxccN8wwJdk8Xh1hRazLkg9wnXJZgoo=.54aa8417-6ca1-4638-8331-80bc950cce10@github.com>

On Fri, 23 Apr 2021 01:15:37 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> To eliminate unnecessary vector mask conversion during unboxing a
> VectorMaskCast node was added as part of JDK-8264104 for aarch64. This patch handles the x86 side of it.
> 
> Please review.
> 
> Best Regards,
> Sandhya

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3645

From ddong at openjdk.java.net  Fri Apr 23 12:37:42 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 23 Apr 2021 12:37:42 GMT
Subject: RFR: 8265129: Add intrinsic support for JVM.getClassId [v2]
In-Reply-To: <WRTO3ij4-ef6lLk8NMQWGkmd68vFfqLICYU9nIakgOU=.d10e0f2f-087c-43f9-b08a-86c51919ac44@github.com>
References: <WRTO3ij4-ef6lLk8NMQWGkmd68vFfqLICYU9nIakgOU=.d10e0f2f-087c-43f9-b08a-86c51919ac44@github.com>
Message-ID: <uWwjeNfhY2jYzpsGcE8k41BzIgax6UN8NzlUwB_p-ig=.ccf8e6fd-0a67-4541-98ad-b449bc60065c@github.com>

> 8265129: Add intrinsic support for JVM.getClassId

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  add doc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3470/files
  - new: https://git.openjdk.java.net/jdk/pull/3470/files/1a429be3..8315bffd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3470&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3470&range=00-01

  Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3470.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3470/head:pull/3470

PR: https://git.openjdk.java.net/jdk/pull/3470

From chagedorn at openjdk.java.net  Fri Apr 23 12:39:32 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 23 Apr 2021 12:39:32 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v6]
In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
Message-ID: <bx37BlKEGAGguvVKHvGFpNX05eFU27sng_RHmV_6ASg=.6b1a194f-f6e7-4bb0-a6ca-21dd79b16a52@github.com>

> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 
> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
> 
> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
> 
> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
> 
> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
> 
> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
> 
> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>       - which leaves 4382 lines of code inserted 
> 
> Big thanks to:
> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
> - and others who provided valuable feedback.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:

  Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3508/files
  - new: https://git.openjdk.java.net/jdk/pull/3508/files/72eece63..0720a330

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=04-05

  Stats: 59 lines in 21 files changed: 6 ins; 34 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3508.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Fri Apr 23 12:39:33 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 23 Apr 2021 12:39:33 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v5]
In-Reply-To: <GKyKAe6WSrHK0zQNcpmBtyN16aHuVIEFhOKAnMangwQ=.9f9f2742-78ac-4bdc-b9d6-953b65c55bb3@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <VIClyiA702WOBS5M5azRIWp2D2zSp9B58HxlCdyMx7I=.29bf18f8-0fe0-4209-91c5-1c8e67144f3e@github.com>
 <GKyKAe6WSrHK0zQNcpmBtyN16aHuVIEFhOKAnMangwQ=.9f9f2742-78ac-4bdc-b9d6-953b65c55bb3@github.com>
Message-ID: <JB4rx5HAHYH77Q5vfXs0mZHzqkBYTBdgXuN-kDSfgnU=.a27da741-577a-4c26-ab2c-0fc8ecbfe3b7@github.com>

On Thu, 22 Apr 2021 13:30:17 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Great work, Christian! I'm glad we finally have the capability to write regression tests with IR verification.
> 
> Hard to review this in detail but I've added some comments. In any case, conversion of Valhalla tests to the new framework has proven that this is good to go. We can still fix problems and add new features once this is in.

Thank you Tobias for your review! I pushed an update with your review comments. I agree that we can still follow up with fixes and new features once this went it.

> test/lib/jdk/test/lib/hotspot/ir_framework/Check.java line 94:
> 
>> 92: @Retention(RetentionPolicy.RUNTIME)
>> 93: public @interface Check {
>> 94: 
> 
> Some classes/interfaces have a newline at the beginning and others don't. I think they can be removed.

Cleaned that up together with some other formatting.

> test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 128:
> 
>> 126: This framework is based on the idea of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypesTest.java). This IR framework was used with great success in Valhalla and thus served as a foundation for this new IR framework.
>> 127:  
>> 128:  The new framework supports all the features that are present in the Valhalla IR framework with the idea to replace it at some point. The initial design and feature set was kept simple and straight forward and serves well for small to medium sized tests. There are a lot of possibilities to further enhance the framework and make it more powerful. This can be tackled in additional RFEs. A few ideas include:
> 
> Again, I would remove the reference to the Valhalla framework. Looking through the changes, I see 13 references to "Valhalla", I think these should all be removed.

I removed all references except the ones in the testing section about the converted tests. I think these references are important to keep for now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From rcastanedalo at openjdk.java.net  Fri Apr 23 12:45:51 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 23 Apr 2021 12:45:51 GMT
Subject: RFR: 8265587: IGV: track nodes across matching
Message-ID: <n4rVpa5niUA7uxFGvO49o6MT9TH5pMvwF8Mnpax1Bg0=.3ff29745-d792-4793-98fa-e3ee5c4975ea@github.com>

This change preserves, as much as possible, the IGV node identifier of Ideal nodes in their corresponding machine nodes created by `Matcher::match()`. This makes it possible to track nodes when stepping from "Before matching" to "After matching" in IGV, as illustrated for an extracted compare-and-branch subgraph in the following screenshot: 

![before-after-matching](https://user-images.githubusercontent.com/8792647/115867587-94b75280-a43b-11eb-8a79-9c13a0a68d42.png)

#### Limitations
This solution preserves most of the node relations across matching, however if an Ideal node is expanded into multiple machine nodes, only one of them is assigned the IGV identifier of the Ideal node (since IGV identifiers need to be unique within a compilation phase). This limitation can be seen in the following example, where the `CmpU` Ideal node is implemented with three `compU_rReg` machine nodes (one for each `jmpConU` machine node), but only one of the `compU_rReg` machine nodes (50) preserves the IGV identifier:

![before-after-matching-limitation](https://user-images.githubusercontent.com/8792647/115869469-3770d080-a43e-11eb-9ede-d8845862c7bd.png)

Overcoming this limitation would require explicitly serializing the entire before-after relation among nodes and adapting IGV's node selection and graph difference logic, which seems too complex for a relatively infrequent case.

#### Testing
- Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
- Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
- Tested manually, for a few graphs, that nodes of different types can be tracked across matching.

-------------

Commit messages:
 - Refine description of Node::_igv_idx
 - Reuse Ideal-level IGV identifiers in machine nodes

Changes: https://git.openjdk.java.net/jdk/pull/3654/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3654&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265587
  Stats: 50 lines in 4 files changed: 20 ins; 13 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3654.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3654/head:pull/3654

PR: https://git.openjdk.java.net/jdk/pull/3654

From vlivanov at openjdk.java.net  Fri Apr 23 12:57:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 23 Apr 2021 12:57:41 GMT
Subject: RFR: 8265689: JVMCI: InternalError: Class java.lang.Object does not
 implement interface jdk.vm.ci.meta.JavaType
Message-ID: <Q0HVfj6Pj8veCMEheKVkTvbw12X_SNmQh-feK41aeOE=.4253b109-b7b3-45a4-846b-da6d6f3773ec@github.com>

The fix for JDK-8264918 (#3396) strengthened the checks on JVM side, but overlooked that `CompilerToVM.getVtableIndexForInterfaceMethod` callers should be adjusted as well to avoid calling into the JVM with ?onflicting arguments.

Testing:
- [x] hs-tier1 - hs-tier4

-------------

Commit messages:
 - 8265689: JVMCI: InternalError: Class java.lang.Object does not implement interface jdk.vm.ci.meta.JavaType

Changes: https://git.openjdk.java.net/jdk/pull/3625/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3625&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265689
  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3625.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3625/head:pull/3625

PR: https://git.openjdk.java.net/jdk/pull/3625

From vlivanov at openjdk.java.net  Fri Apr 23 12:57:27 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 23 Apr 2021 12:57:27 GMT
Subject: Integrated: 8264320: ShouldNotReachHere in
 Compile::print_inlining_move_to()
In-Reply-To: <fkN1bdoq543dtjlrWrYDMri1WyBtWgiOENx07f0H_oY=.c11df31f-ddd7-47d7-bd77-7e16ffd52274@github.com>
References: <fkN1bdoq543dtjlrWrYDMri1WyBtWgiOENx07f0H_oY=.c11df31f-ddd7-47d7-bd77-7e16ffd52274@github.com>
Message-ID: <hEvmBIHvNtU2sNMZaedjXglvQtVuXMNmMyCP9rOsJvc=.c31bfa8c-9156-4ef3-a71f-7f152461a144@github.com>

On Thu, 22 Apr 2021 16:56:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Cloned `CallNode` gets a fresh `CallGenerator` which has to be put on `_print_inlining_list` when -XX:+PrintInlining is used.
> 
> Otherwise, if the  `CallGenerator` ends up on `_late_inlines` list (which is processed by `Compile::process_late_inline_calls_no_inline()`, `Compile::print_inlining_move_to()` can't locate it in `_print_inlining_list` and triggers the crash. 
> 
> The fix is to put cloned `CallGenerator` next to original one in `_print_inlining_list`.
> 
> Testing:
> - [x] failing test
> - [x] hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: bfc1cd8e
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bfc1cd8e
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8264320: ShouldNotReachHere in Compile::print_inlining_move_to()

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3635

From vlivanov at openjdk.java.net  Fri Apr 23 12:57:26 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 23 Apr 2021 12:57:26 GMT
Subject: RFR: 8264320: ShouldNotReachHere in
 Compile::print_inlining_move_to()
In-Reply-To: <fkN1bdoq543dtjlrWrYDMri1WyBtWgiOENx07f0H_oY=.c11df31f-ddd7-47d7-bd77-7e16ffd52274@github.com>
References: <fkN1bdoq543dtjlrWrYDMri1WyBtWgiOENx07f0H_oY=.c11df31f-ddd7-47d7-bd77-7e16ffd52274@github.com>
Message-ID: <oPaUDnU4OevF_AVlw6EvPHkjRjulLfPCd8IwpsW3IIs=.78e3364f-d7ac-4ddf-9637-ec2f624a4f70@github.com>

On Thu, 22 Apr 2021 16:56:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Cloned `CallNode` gets a fresh `CallGenerator` which has to be put on `_print_inlining_list` when -XX:+PrintInlining is used.
> 
> Otherwise, if the  `CallGenerator` ends up on `_late_inlines` list (which is processed by `Compile::process_late_inline_calls_no_inline()`, `Compile::print_inlining_move_to()` can't locate it in `_print_inlining_list` and triggers the crash. 
> 
> The fix is to put cloned `CallGenerator` next to original one in `_print_inlining_list`.
> 
> Testing:
> - [x] failing test
> - [x] hs-tier1 - hs-tier4

Thanks for the reviews, Vladimir and Tobias.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3635

From iklam at openjdk.java.net  Fri Apr 23 16:27:40 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 23 Apr 2021 16:27:40 GMT
Subject: RFR: 8265403: consolidate definition of CPU features [v4]
In-Reply-To: <m6VDuNFc5zRwM0hhuY_c85jxk_wVgXaZm9DwoxGU1po=.90d96d09-7560-4edc-bcf2-f562fc33f389@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
 <m6VDuNFc5zRwM0hhuY_c85jxk_wVgXaZm9DwoxGU1po=.90d96d09-7560-4edc-bcf2-f562fc33f389@github.com>
Message-ID: <djV51G8SrnRkj4EaB8l3eypK6pdSTKUOLfYu2MuIVwg=.a4ababeb-157b-43e0-a023-df7d2e89b10a@github.com>

On Mon, 19 Apr 2021 19:56:45 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries.
>> 
>> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated date in copyright
>  - added blank lines after macros

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3558

From kvn at openjdk.java.net  Fri Apr 23 16:28:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 23 Apr 2021 16:28:36 GMT
Subject: RFR: 8265689: JVMCI: InternalError: Class java.lang.Object does
 not implement interface jdk.vm.ci.meta.JavaType
In-Reply-To: <Q0HVfj6Pj8veCMEheKVkTvbw12X_SNmQh-feK41aeOE=.4253b109-b7b3-45a4-846b-da6d6f3773ec@github.com>
References: <Q0HVfj6Pj8veCMEheKVkTvbw12X_SNmQh-feK41aeOE=.4253b109-b7b3-45a4-846b-da6d6f3773ec@github.com>
Message-ID: <4yOi-6cXSWju5xlFJblzeHXW9Wt3-dLZOQ7IWHs-uYg=.eadc9444-eb52-4075-a841-60930e39752f@github.com>

On Thu, 22 Apr 2021 13:43:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> The fix for JDK-8264918 (#3396) strengthened the checks on JVM side, but overlooked that `CompilerToVM.getVtableIndexForInterfaceMethod` callers should be adjusted as well to avoid calling into the JVM with ?onflicting arguments.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3625

From github.com+168222+mgkwill at openjdk.java.net  Fri Apr 23 17:24:54 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 23 Apr 2021 17:24:54 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v7]
In-Reply-To: <0Avbb0TUKgZg5On5mRpirby1UyAqSKc8vQYIly1J2Bo=.dd8d60ef-e328-4624-a89b-fe3e4789deda@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <KMUIk0sLw0ZaFZl1J3HqMSoxPlaUy58Gbe8QiLFwguI=.7250c399-f63a-4143-b73b-3560d1039d1e@github.com>
 <RQ-UY2pbK_tM0uClYIX7QkQfklM-mYNFcRhOuU5dYGI=.1e581242-968d-4b8e-b4b2-d208def74cf2@github.com>
 <PMeH4jlv-li4aLxa28pPqlYHdv6P03Fm5fM0MTmGcQE=.56c784c5-da79-48b1-822a-d420ecf4c2bb@github.com>
 <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com>
 <PiSIVj94iTW3hzwa3xfRmnled8s2VYt_DwYwKfVqkkA=.e13b7684-1058-4ae7-83e9-0574c2401f9e@github.com>
 <0Avbb0TUKgZg5On5mRpirby1UyAqSKc8vQYIly1J2Bo=.dd8d60ef-e328-4624-a89b-fe3e4789deda@github.com>
Message-ID: <i9u3Uo6qiVIXmCbNa-SUCr96xeAxinzjZ9t3J7DDyNs=.0f62de8b-7122-406f-ad4f-eb3627ed6cc6@github.com>

On Fri, 23 Apr 2021 08:57:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hi @jatin-bhateja your original request was quite unclear. The highlighting of the code was incorrect and the use of 'this' made it unclear what you were suggesting and you did not explain a reason for the suggestion. 
>> 
>>> Can you kindly move **this** into a macro assembly routine.
>> 
>> Seeing "better code sharing" as the reason it's unclear to me if the proposed refactor results in any meaningful benefit for the work involved. It's also unclear if there are any hard code structure or style issues that would necessitate the move.
>> 
>> The refactor you suggest calls for the instruction sequences here to be moved into a src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp function that is then called here. Inside that function there is a selection between float and double but otherwise stays the same except one is formatted .AD and one is .CPP/.HPP. 
>> 
>> If I am doing this refactor for `instruct signumF_reg` and `instruct signumD_reg` to cut down on code duplication, I see that as close to a wash for saving of code lines and effort involved. I also think this would make the code more complex to read.
>> 
>> However if there are strong opinions as to why this is necessary I'd be happy to hear them.
>
> I think it'd be easier to understand with a signum macro in MacroAssembler. Less code duplication is good, obviously. And it's potentially useful elsewhere. Win-win-win.
> We've already factored out C2 instruction sequences for things like vabsnegd  into c2_MacroAssembler_x86.

I wave the white flag. 

Thanks for the review and suggestions @theRealAph and @jatin-bhateja.

In an effort to eradicate the 5 lines of duplication and with an eye to potential usefulness in the future I've created a twice called `C2_MacroAssembler::signum_fp` using 36 lines of code and modification of c2_MacroAssembler_x86.cpp c2_MacroAssembler_x86.hpp.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Fri Apr 23 17:24:54 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 23 Apr 2021 17:24:54 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v6]
In-Reply-To: <lcsOuPxcMAJy4xX0MN4yxomQyz0kk2FOkx50FfkhPxo=.a9d3a9bb-ab25-42b2-acbe-8f353e30a7c7@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com>
 <lcsOuPxcMAJy4xX0MN4yxomQyz0kk2FOkx50FfkhPxo=.a9d3a9bb-ab25-42b2-acbe-8f353e30a7c7@github.com>
Message-ID: <N300K_P7Y0QS9FXjOAt5DGkky4UXdV7funRkHWfNEQM=.b994a925-942b-4322-923f-860da3d7e260@github.com>

On Thu, 22 Apr 2021 23:53:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Looks good to me.
> Thanks for your update.
> 
> Please make sure the copyright year has been updated (TestSignumIntrinsic.java?) and all the imports are actually needed (import org.openjdk.jmh.annotations.Setup; ?).

Thanks @DamonFool. Updated with your suggestions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Fri Apr 23 17:24:53 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 23 Apr 2021 17:24:53 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v7]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <-R3W5TtT5d8dyhcrKvkAUSndQshrVZTHN0VxpIJZoow=.6024f8a6-9fbd-4cc9-9381-8ea54a931bf9@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> 
> Benchmark                       Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
> 
>  
> Optimized:
> signum intrinsic patch
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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 two additional commits since the last revision:

 - Update DamonFool
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
 - Refactor on suggestion of jatin-bhateja & theRealAph
   
   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/afefdc28..3e0a4c79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=05-06

  Stats: 60 lines in 5 files changed: 40 ins; 15 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From never at openjdk.java.net  Fri Apr 23 18:46:34 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Fri, 23 Apr 2021 18:46:34 GMT
Subject: RFR: 8258625: [JVMCI] refactor and unify JVMCI readFieldValue path
Message-ID: <Wm4wRAeWj0lWMTW7lPYlTDlKo4DQpqtAd45cTS1AKm0=.0f7d0cde-0c00-4c16-97b4-be6498589c54@github.com>

This was originally just a cleanup but it turned out to be a partial safety fix for folding reads during compilation.  I've rolled in a couple other safety checks that were found along the way, along with jtreg test improvements that exercise the new paths.

-------------

Commit messages:
 - 8258625: [JVMCI] refactor and unify JVMCI readFieldValue path

Changes: https://git.openjdk.java.net/jdk/pull/3659/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3659&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258625
  Stats: 799 lines in 17 files changed: 170 ins; 529 del; 100 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3659.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3659/head:pull/3659

PR: https://git.openjdk.java.net/jdk/pull/3659

From sviswanathan at openjdk.java.net  Fri Apr 23 18:58:27 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 23 Apr 2021 18:58:27 GMT
Subject: RFR: 8265816: Handle new VectorMaskCast node for x86
In-Reply-To: <WGCGOscWrVdeXLVajsIhYb6-y-Ldytx0U0D67PT-mKU=.6b0cea2c-6a91-4060-a701-1fc514409061@github.com>
References: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
 <WGCGOscWrVdeXLVajsIhYb6-y-Ldytx0U0D67PT-mKU=.6b0cea2c-6a91-4060-a701-1fc514409061@github.com>
Message-ID: <fxSM6FQn7FI2GbNsc81YKPSUjQ47SUagDoZBOhEKvxo=.268ae11c-3ba5-465b-9c19-e0c4b5bd7727@github.com>

On Fri, 23 Apr 2021 01:44:27 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> To eliminate unnecessary vector mask conversion during unboxing a
>> VectorMaskCast node was added as part of JDK-8264104 for aarch64. This patch handles the x86 side of it.
>> 
>> Please review.
>> 
>> Best Regards,
>> Sandhya
>
> Is there a small program which can be used to verify the effect of this opt?
> I just want to learn how this kind of opt works, not to require a jtreg test.
> Thanks.

@DamonFool I see this case come up for the existing Vector API jtreg tests e.g. Float256VectorTests.EQFloat256VectorTestsMasked.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3645

From sviswanathan at openjdk.java.net  Fri Apr 23 18:58:27 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 23 Apr 2021 18:58:27 GMT
Subject: RFR: 8265816: Handle new VectorMaskCast node for x86
In-Reply-To: <VqnU0iC8X6zDVxccN8wwJdk8Xh1hRazLkg9wnXJZgoo=.54aa8417-6ca1-4638-8331-80bc950cce10@github.com>
References: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
 <VqnU0iC8X6zDVxccN8wwJdk8Xh1hRazLkg9wnXJZgoo=.54aa8417-6ca1-4638-8331-80bc950cce10@github.com>
Message-ID: <SKuu1HCVIuQ9TBEhpLoPFhq-4V7YpdlCRoEvnES76NI=.493b7b94-cd21-4fb7-8c36-3cba40b580df@github.com>

On Fri, 23 Apr 2021 10:09:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> To eliminate unnecessary vector mask conversion during unboxing a
>> VectorMaskCast node was added as part of JDK-8264104 for aarch64. This patch handles the x86 side of it.
>> 
>> Please review.
>> 
>> Best Regards,
>> Sandhya
>
> Looks good.

@iwanowww Thanks a lot for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3645

From github.com+168222+mgkwill at openjdk.java.net  Fri Apr 23 19:49:31 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 23 Apr 2021 19:49:31 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v3]
In-Reply-To: <Dyot6mD3ixa6I06Z_sZqMC5n_SmM71Du9ehPYrxjp_w=.7ee20464-de2f-4a4f-9b52-82bae02a65fc@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <Dyot6mD3ixa6I06Z_sZqMC5n_SmM71Du9ehPYrxjp_w=.7ee20464-de2f-4a4f-9b52-82bae02a65fc@github.com>
Message-ID: <hosTIGsBg6BorWIwVS4kFeL83SxYozDZoPzq8qqUIbY=.bd49a477-6ac4-4457-8449-336445c03128@github.com>

On Fri, 23 Apr 2021 09:07:48 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * I optimize `max` and `min` by using these identities 
>>     - op (max(a,b) , min(a,b))=== op(a,b)
>>     - if op is commutable
>>     - example : 
>>       - max(a,b) + min(a,b))=== a + b // op = add
>>       - max(a,b) * min(a,b))=== a * b  // op = mul
>>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
>> * Test case 
>>   ```java
>>   /*
>>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>    *
>>    * This code is free software; you can redistribute it and/or modify it
>>    * under the terms of the GNU General Public License version 2 only, as
>>    * published by the Free Software Foundation.
>>    *
>>    * This code is distributed in the hope that it will be useful, but WITHOUT
>>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>    * version 2 for more details (a copy is included in the LICENSE file that
>>    * accompanied this code).
>>    *
>>    * You should have received a copy of the GNU General Public License version
>>    * 2 along with this work; if not, write to the Free Software Foundation,
>>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>    *
>>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>    * or visit www.oracle.com if you need additional information or have any
>>    * questions.
>>    */
>>   package org.sample;
>>   
>>   import org.openjdk.jmh.annotations.Benchmark;
>>   import org.openjdk.jmh.annotations.*;
>>   
>>   import java.util.Random;
>>   import java.util.concurrent.TimeUnit;
>>   import org.openjdk.jmh.infra.Blackhole;
>>   
>>   @BenchmarkMode({Mode.AverageTime})
>>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>>   public class MyBenchmark {
>>   
>>       static int length = 100000;
>>       static double[] data1 = new double[length];
>>       static double[] data2 = new double[length];
>>       static Random random = new Random();
>>   
>>       static {
>>           for(int i = 0; i < length; ++i) {
>>             data1[i] = random.nextDouble();
>>             data2[i] = random.nextDouble();
>>           }
>>       }
>>   
>>       @Benchmark
>>       public void testAdd(Blackhole bh) {
>>         double sum = 0;
>>         for (int i = 0; i < length; i++) {
>>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>>         }
>>         bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMax(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMin(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   
>>       @Benchmark
>>       public void testMul(Blackhole bh) {
>>           double sum = 0;
>>           for (int i = 0; i < length; i++) {
>>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>>           }
>>           bh.consume(sum);
>>       }
>>   }
>>   ```
>> 
>> *  The result is listed here (aarch64):
>> 
>>   before:
>> 
>>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>>  
>>   after:
>> 
>>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>>   |---|                           ---|  ---|    ---|  --- | ---|
>>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |
>> 
>> *  I have tested `NaN`  ` INFINITY` and `-INFINITY` and got same result (before/after)
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix bugs & add test case

> Thank you for answers.
> The test should be part of changes.

I agree with @vnkozlov the jmh benchmark should be included in the changes and should be renamed to express what the benchmark is for.

-------------

Changes requested by mgkwill at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/3513

From github.com+168222+mgkwill at openjdk.java.net  Fri Apr 23 19:49:31 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 23 Apr 2021 19:49:31 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v2]
In-Reply-To: <9oHnEGs2dzrNBUeQGxgDVTwknSa8XdxCIuq75KMKAFU=.67efd418-22f5-4ab4-b933-51dccf15961e@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <NJ9SV8pFPq3sA3P8LjU7T0CmD9ZcvRxAM1-VZwKk30M=.eae88d31-013b-4aaa-923b-b4bda7ddd33d@github.com>
 <Tc0XCuCtXO7vixyHY951U3RwRH-hbwUNw29PfU_nLQQ=.4a16ced5-9b5b-44f5-823e-a3136eb39ee3@github.com>
 <Kk19BJtpiMR9di5G_hGoKcFpY9SHIPTd99H-3_YgMdM=.6747cc6c-f952-41aa-a5a6-07321a0b24d1@github.com>
 <u3i4urpIMZovq5SzU7tfwg6gRF4mF0_S0pt3jFS0GgA=.a648d13f-6ee8-4d68-ad96-aeae58da7a54@github.com>
 <POJXAIWo8KbWV219C9e44zQOJ3BwvPvrXfFdgE_SH8A=.4309e635-9082-4242-bd97-f1a5e04d71b9@github.com>
 <9oHnEGs2dzrNBUeQGxgDVTwknSa8XdxCIuq75KMKAFU=.67efd418-22f5-4ab4-b933-51dccf15961e@github.com>
Message-ID: <TBHXCx6fBL5WkswDCy3USiwbekRSXmAmTgVLbhY6LvQ=.3028c5ec-9e58-4e28-a8ee-230587cb35d1@github.com>

On Fri, 23 Apr 2021 09:04:14 GMT, Wang Huang <whuang at openjdk.org> wrote:

> I fix a bug in my code. I am not sure if it is the reason of your crash. However, you can pull the latest code and test again. Thank you.

Your update fixed the error I was seeing. My apologies for not getting back to you yesterday, it turned out to be busier than I projected.

Perf numbers on Haswell Intel Xeon CPU E5-1603 v3 @ 2.80GHz:

Baseline
Benchmark            Mode  Cnt    Score     Error  Units
MyBenchmark.testAdd  avgt    5  149.581 ?  13.626  us/op
MyBenchmark.testMax  avgt    5  223.362 ? 195.007  us/op
MyBenchmark.testMin  avgt    5  206.096 ?  16.840  us/op
MyBenchmark.testMul  avgt    5  149.366 ?   9.558  us/op
Finished running test 'micro:MyBenchmark'


Patch
Benchmark            Mode  Cnt    Score   Error  Units
MyBenchmark.testAdd  avgt    5  109.432 ? 0.010  us/op
MyBenchmark.testMax  avgt    5  109.893 ? 0.072  us/op
MyBenchmark.testMin  avgt    5  109.500 ? 0.024  us/op
MyBenchmark.testMul  avgt    5  111.225 ? 0.013  us/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From neliasso at openjdk.java.net  Fri Apr 23 20:44:21 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 23 Apr 2021 20:44:21 GMT
Subject: RFR: 8265816: Handle new VectorMaskCast node for x86
In-Reply-To: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
References: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
Message-ID: <OxWd5su2Ard9oLu9S_WokIyY417VXzY992n1RoSMQ2o=.43ea50fd-c742-4c2b-9eba-18a125795e5f@github.com>

On Fri, 23 Apr 2021 01:15:37 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> To eliminate unnecessary vector mask conversion during unboxing a
> VectorMaskCast node was added as part of JDK-8264104 for aarch64. This patch handles the x86 side of it.
> 
> Please review.
> 
> Best Regards,
> Sandhya

Looks good!

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3645

From sviswanathan at openjdk.java.net  Fri Apr 23 20:53:25 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 23 Apr 2021 20:53:25 GMT
Subject: RFR: 8265816: Handle new VectorMaskCast node for x86
In-Reply-To: <OxWd5su2Ard9oLu9S_WokIyY417VXzY992n1RoSMQ2o=.43ea50fd-c742-4c2b-9eba-18a125795e5f@github.com>
References: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
 <OxWd5su2Ard9oLu9S_WokIyY417VXzY992n1RoSMQ2o=.43ea50fd-c742-4c2b-9eba-18a125795e5f@github.com>
Message-ID: <80bB9sRyuRakS1y08ZOeD9NKryFfEIzjrNFwMppIPbk=.cd4b9f0a-754d-4ec1-9d94-613e8339acad@github.com>

On Fri, 23 Apr 2021 20:41:10 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> To eliminate unnecessary vector mask conversion during unboxing a
>> VectorMaskCast node was added as part of JDK-8264104 for aarch64. This patch handles the x86 side of it.
>> 
>> Please review.
>> 
>> Best Regards,
>> Sandhya
>
> Looks good!

@neliasso Thanks a lot for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3645

From sviswanathan at openjdk.java.net  Fri Apr 23 20:53:26 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 23 Apr 2021 20:53:26 GMT
Subject: Integrated: 8265816: Handle new VectorMaskCast node for x86
In-Reply-To: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
References: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
Message-ID: <NMls6YvA3hLkYqJ7wpLsnBYgSjKAOKgiJl_FOF6jneY=.fd633b97-92f8-433b-b26e-54e8cf68f4e6@github.com>

On Fri, 23 Apr 2021 01:15:37 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> To eliminate unnecessary vector mask conversion during unboxing a
> VectorMaskCast node was added as part of JDK-8264104 for aarch64. This patch handles the x86 side of it.
> 
> Please review.
> 
> Best Regards,
> Sandhya

This pull request has now been integrated.

Changeset: e08f506f
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e08f506f
Stats:     12 lines in 1 file changed: 12 ins; 0 del; 0 mod

8265816: Handle new VectorMaskCast node for x86

Reviewed-by: vlivanov, neliasso

-------------

PR: https://git.openjdk.java.net/jdk/pull/3645

From dcubed at openjdk.java.net  Fri Apr 23 22:15:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 23 Apr 2021 22:15:34 GMT
Subject: RFR: 8265884: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64
Message-ID: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>

A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64.

-------------

Commit messages:
 - 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64

Changes: https://git.openjdk.java.net/jdk/pull/3667/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3667&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265884
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3667.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3667/head:pull/3667

PR: https://git.openjdk.java.net/jdk/pull/3667

From mikael at openjdk.java.net  Fri Apr 23 22:25:23 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Fri, 23 Apr 2021 22:25:23 GMT
Subject: RFR: 8265884: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64
In-Reply-To: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
References: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
Message-ID: <g8OvExfTftmvu7BYfAh5hL5nT4nPNhDbiv437R2vE60=.a8622ae0-dd48-4296-93fe-07c1b1826c3a@github.com>

On Fri, 23 Apr 2021 22:09:10 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64.

test/hotspot/jtreg/ProblemList.txt line 71:

> 69: compiler/whitebox/MakeMethodNotCompilableTest.java 8265360 macosx-aarch64
> 70: 
> 71: compiler/codecache/jmx/PoolsIndependenceTest.java 8264632 macos-x64

Missing an 'x' - macos*x*-x64

-------------

PR: https://git.openjdk.java.net/jdk/pull/3667

From dnsimon at openjdk.java.net  Fri Apr 23 23:35:27 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Fri, 23 Apr 2021 23:35:27 GMT
Subject: Integrated: 8265403: consolidate definition of CPU features
In-Reply-To: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
Message-ID: <sDlro16K2H0CodrLw1KUYCtuWNqvlFxgtRDb4Xgt6Cs=.cb8fd494-8de0-44c2-be57-7a1f56591ffa@github.com>

On Sat, 17 Apr 2021 20:18:31 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries.
> 
> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition.

This pull request has now been integrated.

Changeset: 5aed446e
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5aed446e
Stats:     493 lines in 15 files changed: 146 ins; 235 del; 112 mod

8265403: consolidate definition of CPU features

Reviewed-by: kvn, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/3558

From dnsimon at openjdk.java.net  Fri Apr 23 23:35:25 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Fri, 23 Apr 2021 23:35:25 GMT
Subject: RFR: 8265403: consolidate definition of CPU features [v4]
In-Reply-To: <X-_pAMWn-uIzh0Kg9wTWTrfUsSXifrx01UfnSER_HJk=.4615f8f5-c004-480e-b0eb-5999961c523c@github.com>
References: <RWU703pmOhoH-HeLcKLBU89yGEe4LHg3vE4vc1_ee10=.446bb051-4be3-4618-8448-5b19067c4938@github.com>
 <m6VDuNFc5zRwM0hhuY_c85jxk_wVgXaZm9DwoxGU1po=.90d96d09-7560-4edc-bcf2-f562fc33f389@github.com>
 <X-_pAMWn-uIzh0Kg9wTWTrfUsSXifrx01UfnSER_HJk=.4615f8f5-c004-480e-b0eb-5999961c523c@github.com>
Message-ID: <CKfv-8QbNMVbaL2YWBM1b2WSACDHY2Qdyhf8ba-_n5Q=.dec5af37-47b5-4ed7-91b1-3fe74482acab@github.com>

On Mon, 19 Apr 2021 20:01:46 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updated date in copyright
>>  - added blank lines after macros
>
> You need review from Runtime group too.

Thanks for the reviews @vnkozlov and @iklam.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3558

From dcubed at openjdk.java.net  Fri Apr 23 23:35:48 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 23 Apr 2021 23:35:48 GMT
Subject: RFR: 8265884: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64
In-Reply-To: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
References: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
Message-ID: <9v7CinWLuUJ4cCIy2OPpbIlDuthO318ivU6BKd-Ew0o=.06b95eed-d782-463c-bbf3-38f14e733987@github.com>

On Fri, 23 Apr 2021 22:09:10 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64.

@vidmik - Thanks for catching the typo. Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3667

From dcubed at openjdk.java.net  Fri Apr 23 23:35:47 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 23 Apr 2021 23:35:47 GMT
Subject: RFR: 8265884: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 [v2]
In-Reply-To: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
References: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
Message-ID: <SSayddWVOL5YnVyATnJuKtnCNo5_MNI3VBoBe-_QLWI=.7ab541dd-2479-4825-b507-75e63ea5e3d9@github.com>

> A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  mikael CR - fix 'macosx' typo.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3667/files
  - new: https://git.openjdk.java.net/jdk/pull/3667/files/378751d9..5c0c7998

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3667&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3667&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3667.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3667/head:pull/3667

PR: https://git.openjdk.java.net/jdk/pull/3667

From jiefu at openjdk.java.net  Sat Apr 24 00:04:23 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 24 Apr 2021 00:04:23 GMT
Subject: RFR: 8265816: Handle new VectorMaskCast node for x86
In-Reply-To: <WGCGOscWrVdeXLVajsIhYb6-y-Ldytx0U0D67PT-mKU=.6b0cea2c-6a91-4060-a701-1fc514409061@github.com>
References: <5QNqP6jZ79ljknfDHrhdDMyTtQr-1PE4CLgr3H2F5pc=.90201d37-2b59-427e-b27f-1e0c195debc8@github.com>
 <WGCGOscWrVdeXLVajsIhYb6-y-Ldytx0U0D67PT-mKU=.6b0cea2c-6a91-4060-a701-1fc514409061@github.com>
Message-ID: <az4aYRNqlLv4rzZyhLAjPaKWXCXuluTU63jT6ZvzIL0=.da421fba-9f9e-4413-b4af-efc349a9d610@github.com>

On Fri, 23 Apr 2021 01:44:27 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> To eliminate unnecessary vector mask conversion during unboxing a
>> VectorMaskCast node was added as part of JDK-8264104 for aarch64. This patch handles the x86 side of it.
>> 
>> Please review.
>> 
>> Best Regards,
>> Sandhya
>
> Is there a small program which can be used to verify the effect of this opt?
> I just want to learn how this kind of opt works, not to require a jtreg test.
> Thanks.

> @DamonFool I see this case come up for the existing Vector API jtreg tests e.g. Float256VectorTests.EQFloat256VectorTestsMasked.

Thanks for your kind reply.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3645

From jiefu at openjdk.java.net  Sat Apr 24 00:11:28 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 24 Apr 2021 00:11:28 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v7]
In-Reply-To: <-R3W5TtT5d8dyhcrKvkAUSndQshrVZTHN0VxpIJZoow=.6024f8a6-9fbd-4cc9-9381-8ea54a931bf9@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <-R3W5TtT5d8dyhcrKvkAUSndQshrVZTHN0VxpIJZoow=.6024f8a6-9fbd-4cc9-9381-8ea54a931bf9@github.com>
Message-ID: <suvmNr22kb-aNZ33jUbPYhchjL40vApIXvkBWFp4DWI=.7845cf2a-a8d0-4da1-8b07-e8c6b0c13a63@github.com>

On Fri, 23 Apr 2021 17:24:53 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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 two additional commits since the last revision:
> 
>  - Update DamonFool
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>  - Refactor on suggestion of jatin-bhateja & theRealAph
>    
>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

This is incorrect since it's not a new file.

I suggest this kind of change

diff --git a/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java b/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
index 86434d556bb..37aa511dcff 100644
--- a/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
+++ b/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
  * Copyright (c) 2020, BELLSOFT. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Sat Apr 24 00:21:50 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Sat, 24 Apr 2021 00:21:50 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v7]
In-Reply-To: <suvmNr22kb-aNZ33jUbPYhchjL40vApIXvkBWFp4DWI=.7845cf2a-a8d0-4da1-8b07-e8c6b0c13a63@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <-R3W5TtT5d8dyhcrKvkAUSndQshrVZTHN0VxpIJZoow=.6024f8a6-9fbd-4cc9-9381-8ea54a931bf9@github.com>
 <suvmNr22kb-aNZ33jUbPYhchjL40vApIXvkBWFp4DWI=.7845cf2a-a8d0-4da1-8b07-e8c6b0c13a63@github.com>
Message-ID: <IfZmc9dBvTFhk7VI0PDAXSThrCscoqLx8gLOomQfDAM=.398cbaf6-8e1f-4766-ad4f-8412f025ce07@github.com>

On Sat, 24 Apr 2021 00:08:19 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update DamonFool
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>>  - Refactor on suggestion of jatin-bhateja & theRealAph
>>    
>>    Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> This is incorrect since it's not a new file.
> 
> I suggest this kind of change
> 
> diff --git a/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java b/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
> index 86434d556bb..37aa511dcff 100644
> --- a/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
> +++ b/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
>   * Copyright (c) 2020, BELLSOFT. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *

Thanks again @DamonFool. Fixed as you suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Sat Apr 24 00:21:49 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Sat, 24 Apr 2021 00:21:49 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v8]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <utIX2iDZFYUTZXh6ix90EIxqk9z2RfzcD8xM21q6XAM=.94212c52-9382-4214-a54a-a758bf1e2990@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> 
> Benchmark                       Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
> 
>  
> Optimized:
> signum intrinsic patch
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:

  Fix copyright
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/3e0a4c79..7d54845f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From jiefu at openjdk.java.net  Sat Apr 24 00:27:25 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 24 Apr 2021 00:27:25 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v8]
In-Reply-To: <utIX2iDZFYUTZXh6ix90EIxqk9z2RfzcD8xM21q6XAM=.94212c52-9382-4214-a54a-a758bf1e2990@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <utIX2iDZFYUTZXh6ix90EIxqk9z2RfzcD8xM21q6XAM=.94212c52-9382-4214-a54a-a758bf1e2990@github.com>
Message-ID: <dqTvP0t6XVJI5xuqb6PNPsWNQAmdqjQ8L7nkr8njDqU=.7a43f3c3-0f01-40bd-bcbd-e541796bb2a9@github.com>

On Sat, 24 Apr 2021 00:21:49 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:
> 
>   Fix copyright
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Looks good to me.
Thanks.

-------------

Marked as reviewed by jiefu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/3581

From mikael at openjdk.java.net  Sat Apr 24 00:53:23 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Sat, 24 Apr 2021 00:53:23 GMT
Subject: RFR: 8265884: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 [v2]
In-Reply-To: <SSayddWVOL5YnVyATnJuKtnCNo5_MNI3VBoBe-_QLWI=.7ab541dd-2479-4825-b507-75e63ea5e3d9@github.com>
References: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
 <SSayddWVOL5YnVyATnJuKtnCNo5_MNI3VBoBe-_QLWI=.7ab541dd-2479-4825-b507-75e63ea5e3d9@github.com>
Message-ID: <vJQBusdDeXvVY05S6z_PlE15fE3oKiLdqfSWz0gHz4s=.f6b1f306-6247-42fb-857d-a59c55e40ee0@github.com>

On Fri, 23 Apr 2021 23:35:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mikael CR - fix 'macosx' typo.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3667

From dcubed at openjdk.java.net  Sat Apr 24 00:59:23 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 24 Apr 2021 00:59:23 GMT
Subject: RFR: 8265884: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 [v2]
In-Reply-To: <vJQBusdDeXvVY05S6z_PlE15fE3oKiLdqfSWz0gHz4s=.f6b1f306-6247-42fb-857d-a59c55e40ee0@github.com>
References: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
 <SSayddWVOL5YnVyATnJuKtnCNo5_MNI3VBoBe-_QLWI=.7ab541dd-2479-4825-b507-75e63ea5e3d9@github.com>
 <vJQBusdDeXvVY05S6z_PlE15fE3oKiLdqfSWz0gHz4s=.f6b1f306-6247-42fb-857d-a59c55e40ee0@github.com>
Message-ID: <5gNMpQ5un5JH14BglA8_Vbc2fzU-iq12_4ZjvAKISgo=.965d7434-9552-44c5-928e-d18452eb999a@github.com>

On Sat, 24 Apr 2021 00:50:20 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mikael CR - fix 'macosx' typo.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the re-review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3667

From dcubed at openjdk.java.net  Sat Apr 24 00:59:24 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 24 Apr 2021 00:59:24 GMT
Subject: Integrated: 8265884: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64
In-Reply-To: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
References: <Njx1gQt_5CKVNOcuqnrhplDIu8QctN-Pak2PpOBScxM=.a03f677e-fd29-4ca7-9648-a023c5be8218@github.com>
Message-ID: <Ll5jHPDDt5K_0dLyZWMEOmzdZeK3ABqW-HIHXOMp04o=.52e90e49-f90a-4a23-a705-88344190ce72@github.com>

On Fri, 23 Apr 2021 22:09:10 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64.

This pull request has now been integrated.

Changeset: 52f9d229
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/52f9d229
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64

Reviewed-by: mikael

-------------

PR: https://git.openjdk.java.net/jdk/pull/3667

From whuang at openjdk.java.net  Sun Apr 25 07:50:00 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sun, 25 Apr 2021 07:50:00 GMT
Subject: RFR: 8265907: JVM crashes when matching VectorMaskCmp Node for Neon
 backend
Message-ID: <u-7MdHM6IGvkXcRUDh8miqL3nMx7SKaHxTD1WMqX674=.b791dd7f-1d65-42ba-9c6e-9ff1eee73ce3@github.com>

* fix the issue JDK-8265907

-------------

Commit messages:
 - 8265907: JVM crashes when matching VectorMaskCmp Node for Neon backend

Changes: https://git.openjdk.java.net/jdk/pull/3670/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3670&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265907
  Stats: 63 lines in 2 files changed: 63 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3670.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3670/head:pull/3670

PR: https://git.openjdk.java.net/jdk/pull/3670

From github.com+16741972+whjpji at openjdk.java.net  Sun Apr 25 09:03:54 2021
From: github.com+16741972+whjpji at openjdk.java.net (Frank King)
Date: Sun, 25 Apr 2021 09:03:54 GMT
Subject: RFR: 8265911: assert(comp != __null) failed: Compiler instance missing
Message-ID: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>

As I debugged into the code, the `_c1_count` was set to `1` [1] with flags `-XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:JVMCIHostThreads=1`. However, [2] would never be executed, and thus `_compilers[0]` was `NULL`. 

When C1 is disabled, `_c1_count` should always be `0`, so I added this `#ifdef` guard to avoid changing value of `_c1_count` under this circumstance.

[1] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L656
[2] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L664

-------------

Commit messages:
 - 8265911: assert(comp != __null) failed: Compiler instance missing

Changes: https://git.openjdk.java.net/jdk/pull/3672/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3672&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265911
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3672.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3672/head:pull/3672

PR: https://git.openjdk.java.net/jdk/pull/3672

From jiefu at openjdk.java.net  Sun Apr 25 11:46:06 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 25 Apr 2021 11:46:06 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1 for
 Math.pow(x, 2.0) on x86_32
Message-ID: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>

Hi all,

C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.

E.g., for Math.pow(1.0 / 2047, 2.0):

interpreter: 2.38651580386563E-7 
         C2: 2.3865158038656307E-7


The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
However, there is no such optimization for interpreter/C1 on x86_32.

The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
And we don't have a plan to implement such opt on x86_32.

Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8265917: Different values computed by C2 and interpreter/C1 for Math.pow(x, 2.0) on x86_32

Changes: https://git.openjdk.java.net/jdk/pull/3677/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3677&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265917
  Stats: 60 lines in 2 files changed: 60 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3677.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3677/head:pull/3677

PR: https://git.openjdk.java.net/jdk/pull/3677

From kvn at openjdk.java.net  Sun Apr 25 17:41:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sun, 25 Apr 2021 17:41:46 GMT
Subject: RFR: 8265911: assert(comp != __null) failed: Compiler instance
 missing
In-Reply-To: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>
References: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>
Message-ID: <J9JiJYikAytIfokRqa0KDfFRGFNMDC6QkoOH23xa1Tw=.8b7c282b-2142-4cf4-b419-5cf09a0bc70e@github.com>

On Sun, 25 Apr 2021 08:56:39 GMT, Frank King <github.com+16741972+whjpji at openjdk.org> wrote:

> As I debugged into the code, the `_c1_count` was set to `1` [1] with flags `-XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:JVMCIHostThreads=1`. However, [2] would never be executed, and thus `_compilers[0]` was `NULL`. 
> 
> When C1 is disabled, `_c1_count` should always be `0`, so I added this `#ifdef` guard to avoid changing value of `_c1_count` under this circumstance.
> 
> [1] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L656
> [2] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L664

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3672

From kvn at openjdk.java.net  Sun Apr 25 18:11:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sun, 25 Apr 2021 18:11:51 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32
In-Reply-To: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
Message-ID: <qUbhA3-YoQCS1aOvDzyJsLEFBkP-XhtfwW9J9gpJRrY=.bc461aad-358c-4da8-8db5-91eb5f11b24b@github.com>

On Sun, 25 Apr 2021 11:39:43 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
> 
> E.g., for Math.pow(1.0 / 2047, 2.0):
> 
> interpreter: 2.38651580386563E-7 
>          C2: 2.3865158038656307E-7
> 
> 
> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
> However, there is no such optimization for interpreter/C1 on x86_32.
> 
> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
> And we don't have a plan to implement such opt on x86_32.
> 
> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
> 
> Thanks.
> Best regards,
> Jie

I think you should fix 32-bit version of `dpow` stub because 64-bit stub has this optimization:
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L828

Also add `pow(x, 0.5)` as well.

C `dpow` code in VM has this optimization which works in 32- and in 64-bit when stub is not used (for example, on other platforms):
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L496

Java lib code also has this optimization:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/FdLibm.java#L362

Only 32-bit x86 stub is missing it:
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L2544

The stub is generated only on x86:

$ grep -r StubRoutines::_dpow src/hotspot/cpu/
src/hotspot/cpu//x86/stubGenerator_x86_64.cpp:        StubRoutines::_dpow = generate_libmPow();
src/hotspot/cpu//x86/stubGenerator_x86_32.cpp:        StubRoutines::_dpow = generate_libmPow();

I suggest to fix it to be consistent with the rest of VM and Java lib code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From njian at openjdk.java.net  Mon Apr 26 05:36:33 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 26 Apr 2021 05:36:33 GMT
Subject: RFR: 8265907: JVM crashes when matching VectorMaskCmp Node for
 Neon backend
In-Reply-To: <u-7MdHM6IGvkXcRUDh8miqL3nMx7SKaHxTD1WMqX674=.b791dd7f-1d65-42ba-9c6e-9ff1eee73ce3@github.com>
References: <u-7MdHM6IGvkXcRUDh8miqL3nMx7SKaHxTD1WMqX674=.b791dd7f-1d65-42ba-9c6e-9ff1eee73ce3@github.com>
Message-ID: <IOgC8aALBOHnIaqTPDmXYx_Uo6_bC6uHfTvUhUA0QrY=.e6d1df32-514f-49ca-af7f-975b223906de@github.com>

On Sun, 25 Apr 2021 07:38:30 GMT, Wang Huang <whuang at openjdk.org> wrote:

> * fix the issue JDK-8265907

src/hotspot/cpu/aarch64/aarch64.ad line 2421:

> 2419:         return false;
> 2420:       }
> 2421:       break;

Hmm, currently min_vector_size for byte type is lower to 4 bytes to support vector api shuffle, but we don't have a per Opcode size check correctly. E.g. no length check for reduce_add8B, do you also see any issue for that? I think we'd better only allow 4 bytes for vector api shuffle related opcodes (and 2 for mask related opcodes) in match_rule_supported_vector, while for other opcodes, we still only support for >=64 bits.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3670

From dongbo at openjdk.java.net  Mon Apr 26 05:58:52 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 26 Apr 2021 05:58:52 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of two
 integers with NEON pairwise instructions
Message-ID: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>

On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:


## reduce_add2I, before
mov    w10, v19.s[0]
mov    w2, v19.s[1]
add    w10, w0, w10
add    w10, w10, w2
## reduce_add2I, optimized
addp   v23.2s, v24.2s, v24.2s
mov    w10, v23.s[0]
add    w10, w10, w2

## reduce_max2I, before
dup    v16.2d, v23.d[0]
sminv  s16, v16.4s
mov    w10, v16.s[0]
cmp    w10, w0
csel   w10, w10, w0, lt
## reduce_max2I, optimized
sminp  v16.2s, v23.2s, v23.2s
mov    w10, v16.s[0]
cmp    w10, w0
csel   w10, w10, w0, lt


I don't expect this to change anything of SuperWord, vectorizing of length 2 reductions is disabled by [1].
This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.


Benchmark                   (size)   Mode  Cnt     Score    Error   Units
# optimized
Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
# default
Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms


Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.

[1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
[2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java

-------------

Commit messages:
 - 8264973: AArch64: Optimize vector max/min/add reduction of two integers with NEON pairwise instructions

Changes: https://git.openjdk.java.net/jdk/pull/3683/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3683&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264973
  Stats: 40 lines in 3 files changed: 2 ins; 12 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3683/head:pull/3683

PR: https://git.openjdk.java.net/jdk/pull/3683

From jiefu at openjdk.java.net  Mon Apr 26 06:06:07 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 26 Apr 2021 06:06:07 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v2]
In-Reply-To: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
Message-ID: <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>

> Hi all,
> 
> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
> 
> E.g., for Math.pow(1.0 / 2047, 2.0):
> 
> interpreter: 2.38651580386563E-7 
>          C2: 2.3865158038656307E-7
> 
> 
> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
> However, there is no such optimization for interpreter/C1 on x86_32.
> 
> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
> And we don't have a plan to implement such opt on x86_32.
> 
> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Optimize pow(x, 2.0) for x86_32

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3677/files
  - new: https://git.openjdk.java.net/jdk/pull/3677/files/a7d32c25..dde59758

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3677&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3677&range=00-01

  Stats: 37 lines in 3 files changed: 17 ins; 13 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3677.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3677/head:pull/3677

PR: https://git.openjdk.java.net/jdk/pull/3677

From jiefu at openjdk.java.net  Mon Apr 26 06:20:33 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 26 Apr 2021 06:20:33 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32
In-Reply-To: <qUbhA3-YoQCS1aOvDzyJsLEFBkP-XhtfwW9J9gpJRrY=.bc461aad-358c-4da8-8db5-91eb5f11b24b@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <qUbhA3-YoQCS1aOvDzyJsLEFBkP-XhtfwW9J9gpJRrY=.bc461aad-358c-4da8-8db5-91eb5f11b24b@github.com>
Message-ID: <pY6cHUuBrimBhnjj6Dqezdco62jB4rRNsF29TrFFsKI=.a5258a1f-65c4-401c-9238-ed727f1193c5@github.com>

On Sun, 25 Apr 2021 18:09:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I think you should fix 32-bit version of `dpow` stub because 64-bit stub has this optimization:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L828
> 
> Also add `pow(x, 0.5)` as well.
> 
> C `dpow` code in VM has this optimization which works in 32- and in 64-bit when stub is not used (for example, on other platforms):
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L496
> 
> Java lib code also has this optimization:
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/FdLibm.java#L362
> 
> Only 32-bit x86 stub is missing it:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L2544
> 
> The stub is generated only on x86:
> 
> ```
> $ grep -r StubRoutines::_dpow src/hotspot/cpu/
> src/hotspot/cpu//x86/stubGenerator_x86_64.cpp:        StubRoutines::_dpow = generate_libmPow();
> src/hotspot/cpu//x86/stubGenerator_x86_32.cpp:        StubRoutines::_dpow = generate_libmPow();
> ```
> 
> I suggest to fix it to be consistent with the rest of VM and Java lib code.

Hi @vnkozlov ,

Math.pow(x, 2.0) has been optimized for x86_32.
As for the Math.pow(x, 0.5), it will be handled in JDK-8265940 after this issue.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From jiefu at openjdk.java.net  Mon Apr 26 06:24:45 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 26 Apr 2021 06:24:45 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v2]
In-Reply-To: <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>
Message-ID: <MZj-ZTOon4cpSf-4mSqy8iw5pmBCTaguJvUNCorM4H8=.3ec73cf6-b7ee-4add-80f8-3c2e1858c970@github.com>

On Mon, 26 Apr 2021 06:06:07 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
>> 
>> E.g., for Math.pow(1.0 / 2047, 2.0):
>> 
>> interpreter: 2.38651580386563E-7 
>>          C2: 2.3865158038656307E-7
>> 
>> 
>> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
>> However, there is no such optimization for interpreter/C1 on x86_32.
>> 
>> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
>> And we don't have a plan to implement such opt on x86_32.
>> 
>> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize pow(x, 2.0) for x86_32

Testing:
  -tier1 ~ tier3 on Linux/x86_32, no regression

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From yyang at openjdk.java.net  Mon Apr 26 06:33:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Apr 2021 06:33:30 GMT
Subject: RFR: 8265711: C1: Canonicalize Class.getModifier intrinsic method
In-Reply-To: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
Message-ID: <5rhJv7eoChJNptPurGAES5GlDnewluWwWbmgW8338xM=.43154e31-4923-4632-86bb-2a79a88688ff@github.com>

On Thu, 22 Apr 2021 07:02:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

> It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.

Can I have a review of this PR? Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From yyang at openjdk.java.net  Mon Apr 26 06:33:31 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Apr 2021 06:33:31 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
Message-ID: <rD3RCyB8LBa04-MgpqOqPi3HmVH2nDbDhoGJHVzdbug=.d86c723c-6fa2-4b2d-adf8-5bfe45a5e67c@github.com>

On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove java_nio_Buffer in javaClasses.hpp

Can I have a review of this PR? Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From thartmann at openjdk.java.net  Mon Apr 26 06:53:48 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Apr 2021 06:53:48 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle top
 Phi
Message-ID: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>

C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".

I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.

This issue was reported by John Jiang (johnsjiang at tencent.com).

Thanks,
Tobias

-------------

Commit messages:
 - 8265938: C2's conditional move optimization does not handle top Phi

Changes: https://git.openjdk.java.net/jdk/pull/3684/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3684&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265938
  Stats: 71 lines in 2 files changed: 70 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3684.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3684/head:pull/3684

PR: https://git.openjdk.java.net/jdk/pull/3684

From whuang at openjdk.java.net  Mon Apr 26 07:39:53 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Mon, 26 Apr 2021 07:39:53 GMT
Subject: RFR: 8265907: JVM crashes when matching VectorMaskCmp Node [v2]
In-Reply-To: <u-7MdHM6IGvkXcRUDh8miqL3nMx7SKaHxTD1WMqX674=.b791dd7f-1d65-42ba-9c6e-9ff1eee73ce3@github.com>
References: <u-7MdHM6IGvkXcRUDh8miqL3nMx7SKaHxTD1WMqX674=.b791dd7f-1d65-42ba-9c6e-9ff1eee73ce3@github.com>
Message-ID: <hKbvUONEPcyaB4zsZ1trMAjNCDqqCd9PdKsobouZ68I=.4be861c9-c76b-45d8-9d0b-d186981ced1f@github.com>

> * fix the issue JDK-8265907

Wang Huang 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:

  8265907: JVM crashes when matching VectorMaskCmp Node

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3670/files
  - new: https://git.openjdk.java.net/jdk/pull/3670/files/a193ff03..44b255c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3670&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3670&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3670.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3670/head:pull/3670

PR: https://git.openjdk.java.net/jdk/pull/3670

From roberto.castaneda.lozano at oracle.com  Mon Apr 26 07:45:08 2021
From: roberto.castaneda.lozano at oracle.com (=?UTF-8?Q?Roberto_Casta=c3=b1eda_Lozano?=)
Date: Mon, 26 Apr 2021 09:45:08 +0200
Subject: Invitation to contribute to IGV
Message-ID: <4d3220f0-9ae3-8e00-91b8-c53a844f1efb@oracle.com>

Hi all,

The Ideal Graph visualizer (IGV) [1] is a tool to explore visually and 
interactively the IR of a C2 compilation through its different phases. 
IGV is useful for both newcomers (to learn about C2) and more 
experienced C2 engineers (to debug complex issues). As you may have 
noticed, there is an ongoing effort to stabilize and modernize IGV [2, 3].

 From the experience and feedback gathered during this work, we have 
collected a list of bugs and enhancements that would make IGV even more 
useful in the future. If you are looking to make a contribution in this 
area, please have a look at the unassigned IGV issues on JBS [4]. If you 
are getting started on C2, we have marked a subset of these with the 
"starter" label [5]. We believe these tasks are particularly suitable 
for newcomers: improving IGV is a fun and perhaps friendlier path 
towards learning the C2 IR than hacking C2 itself.

Thanks and happy hacking!

Roberto

[1] https://wiki.openjdk.java.net/display/HotSpot/IdealGraphVisualizer

[2] https://bugs.openjdk.java.net/browse/JDK-8254145

[3] 
https://robcasloz.github.io/blog/2021/04/22/improving-the-ideal-graph-visualizer.html

[4] 
https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20c2-igv%20AND%20%28status%20%3D%20open%20OR%20status%20%3D%20new%29%20AND%20assignee%20%3D%20null

[5] 
https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20c2-igv%20AND%20labels%20%3D%20starter%20AND%20%28status%20%3D%20open%20OR%20status%20%3D%20new%29%20AND%20assignee%20%3D%20null

From chagedorn at openjdk.java.net  Mon Apr 26 07:45:33 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 26 Apr 2021 07:45:33 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
Message-ID: <Q5keGaiH7FptJRWNRSD6iNSodhd_hiWdVZZCGbEXiyc=.af91e933-9775-473b-8bf2-084b02cdfd6d@github.com>

On Mon, 26 Apr 2021 06:46:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
> 
> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
> 
> This issue was reported by John Jiang (johnsjiang at tencent.com).
> 
> Thanks,
> Tobias

Looks reasonable to me!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3684

From rwestrel at redhat.com  Mon Apr 26 07:44:47 2021
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 26 Apr 2021 09:44:47 +0200
Subject: [11u] RFR: 8261812: C2 compilation fails with
 assert(!had_error) failed: bad dominance
In-Reply-To: <AM4PR02MB305773DD4F4DC15323E6CDC99A499@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB305773DD4F4DC15323E6CDC99A499@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <875z09o5g0.fsf@redhat.com>


> 11u backport:
> http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/

Looks good to me too.

Roland.


From whuang at openjdk.java.net  Mon Apr 26 07:47:05 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Mon, 26 Apr 2021 07:47:05 GMT
Subject: RFR: 8265907: JVM crashes when matching VectorMaskCmp Node [v3]
In-Reply-To: <u-7MdHM6IGvkXcRUDh8miqL3nMx7SKaHxTD1WMqX674=.b791dd7f-1d65-42ba-9c6e-9ff1eee73ce3@github.com>
References: <u-7MdHM6IGvkXcRUDh8miqL3nMx7SKaHxTD1WMqX674=.b791dd7f-1d65-42ba-9c6e-9ff1eee73ce3@github.com>
Message-ID: <_otBn8mWHgqdIjnZ6yiBu_T6F5076C_aKL7yMHe-sHo=.d94a0510-0e91-4286-814c-5b568d7ce923@github.com>

> * fix the issue JDK-8265907
> * all archs might be effected by this bug. I fixed x86 and aarch64.

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  fix x86's bug

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3670/files
  - new: https://git.openjdk.java.net/jdk/pull/3670/files/44b255c1..817c8beb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3670&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3670&range=01-02

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3670.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3670/head:pull/3670

PR: https://git.openjdk.java.net/jdk/pull/3670

From thartmann at openjdk.java.net  Mon Apr 26 08:02:27 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Apr 2021 08:02:27 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
Message-ID: <kOwuZfzON3GqKRfr-r1UPdR4Q6WDVkhZetMg9kaE8xs=.0dece4f4-0b7e-4135-9ff8-18e312defe6a@github.com>

On Mon, 26 Apr 2021 06:46:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
> 
> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
> 
> This issue was reported by John Jiang (johnsjiang at tencent.com).
> 
> Thanks,
> Tobias

Thanks for the review, Christian!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From hshi at openjdk.java.net  Mon Apr 26 08:24:24 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Mon, 26 Apr 2021 08:24:24 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <kOwuZfzON3GqKRfr-r1UPdR4Q6WDVkhZetMg9kaE8xs=.0dece4f4-0b7e-4135-9ff8-18e312defe6a@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
 <kOwuZfzON3GqKRfr-r1UPdR4Q6WDVkhZetMg9kaE8xs=.0dece4f4-0b7e-4135-9ff8-18e312defe6a@github.com>
Message-ID: <Q-uWjbk-5YcBtxhpTH0NEeqsodrypos96zv2Jl7SMSM=.a5052d5c-251e-4bd0-a69f-7a9728dfee36@github.com>

On Mon, 26 Apr 2021 07:59:02 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
>> 
>> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
>> 
>> This issue was reported by John Jiang (johnsjiang at tencent.com).
>> 
>> Thanks,
>> Tobias
>
> Thanks for the review, Christian!

@TobiHartmann Thanks for fixing tencent reported bug! Your fix is good.

Could an early check added after ccp GVN? Check if it is compiling a method currently in inifinite loop and abort compilation earlier?


--- a/src/hotspot/share/opto/compile.cpp
+++ b/src/hotspot/share/opto/compile.cpp
@@ -2287,6 +2287,9 @@ void Compile::Optimize() {
     TracePhase tp("iterGVN2", &timers[_t_iterGVN2]);
     igvn = ccp;
     igvn.optimize();
+    if (root()->req() == 1) {
+      record_method_not_compilable("trivial infinite loop after phase ccp");
+    }
   }
   print_method(PHASE_ITER_GVN2, 2);

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From thartmann at openjdk.java.net  Mon Apr 26 08:40:30 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Apr 2021 08:40:30 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <Q-uWjbk-5YcBtxhpTH0NEeqsodrypos96zv2Jl7SMSM=.a5052d5c-251e-4bd0-a69f-7a9728dfee36@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
 <kOwuZfzON3GqKRfr-r1UPdR4Q6WDVkhZetMg9kaE8xs=.0dece4f4-0b7e-4135-9ff8-18e312defe6a@github.com>
 <Q-uWjbk-5YcBtxhpTH0NEeqsodrypos96zv2Jl7SMSM=.a5052d5c-251e-4bd0-a69f-7a9728dfee36@github.com>
Message-ID: <vS0E6f1kg8o4KdnB-Or9g3dPzx4xJlUO5vx-AFBSuJA=.df0e08a3-17a5-4c26-bb59-9e34442a71f6@github.com>

On Mon, 26 Apr 2021 08:21:38 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> Thanks for the review, Christian!
>
> @TobiHartmann Thanks for fixing tencent reported bug! Your fix is good.
> 
> Could an early check added after ccp GVN? Check if it is compiling a method currently in inifinite loop and abort compilation earlier?
> 
> 
> --- a/src/hotspot/share/opto/compile.cpp
> +++ b/src/hotspot/share/opto/compile.cpp
> @@ -2287,6 +2287,9 @@ void Compile::Optimize() {
>      TracePhase tp("iterGVN2", &timers[_t_iterGVN2]);
>      igvn = ccp;
>      igvn.optimize();
> +    if (root()->req() == 1) {
> +      record_method_not_compilable("trivial infinite loop after phase ccp");
> +    }
>    }
>    print_method(PHASE_ITER_GVN2, 2);

@huishi-hs thanks for the review. This version of the fix was also proposed by the reporter but is not sufficient because it assumes that the infinite loop is reachable from all exit paths. This is not the case in my version of the regression test, were the infinite loop is only in the `b == true` branch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From hshi at openjdk.java.net  Mon Apr 26 08:44:32 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Mon, 26 Apr 2021 08:44:32 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <Q-uWjbk-5YcBtxhpTH0NEeqsodrypos96zv2Jl7SMSM=.a5052d5c-251e-4bd0-a69f-7a9728dfee36@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
 <kOwuZfzON3GqKRfr-r1UPdR4Q6WDVkhZetMg9kaE8xs=.0dece4f4-0b7e-4135-9ff8-18e312defe6a@github.com>
 <Q-uWjbk-5YcBtxhpTH0NEeqsodrypos96zv2Jl7SMSM=.a5052d5c-251e-4bd0-a69f-7a9728dfee36@github.com>
Message-ID: <3yIt7qI4jWzxy_KRikgLNNiuZvoG11zHoc8QTNdcja4=.699931a3-a961-4a3a-8d96-127b7fa62e90@github.com>

On Mon, 26 Apr 2021 08:21:38 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> Thanks for the review, Christian!
>
> @TobiHartmann Thanks for fixing tencent reported bug! Your fix is good.
> 
> Could an early check added after ccp GVN? Check if it is compiling a method currently in inifinite loop and abort compilation earlier?
> 
> 
> --- a/src/hotspot/share/opto/compile.cpp
> +++ b/src/hotspot/share/opto/compile.cpp
> @@ -2287,6 +2287,9 @@ void Compile::Optimize() {
>      TracePhase tp("iterGVN2", &timers[_t_iterGVN2]);
>      igvn = ccp;
>      igvn.optimize();
> +    if (root()->req() == 1) {
> +      record_method_not_compilable("trivial infinite loop after phase ccp");
> +    }
>    }
>    print_method(PHASE_ITER_GVN2, 2);

> @huishi-hs thanks for the review. This version of the fix was also proposed by the reporter but is not sufficient because it assumes that the infinite loop is reachable from all exit paths. This is not the case in my version of the regression test, were the infinite loop is only in the `b == true` branch.

You're right. Test is modified. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From martin.doerr at sap.com  Mon Apr 26 09:09:59 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 26 Apr 2021 09:09:59 +0000
Subject: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error)
 failed: bad dominance
In-Reply-To: <875z09o5g0.fsf@redhat.com>
References: <AM4PR02MB305773DD4F4DC15323E6CDC99A499@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <875z09o5g0.fsf@redhat.com>
Message-ID: <AM4PR02MB3057788C160C2D39ACC6B5F29A429@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi Roland,

thanks for the review! Pushed.

Best regards,
Martin


> -----Original Message-----
> From: Roland Westrelin <rwestrel at redhat.com>
> Sent: Montag, 26. April 2021 09:45
> To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-
> dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-
> compiler-dev at openjdk.java.net>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Subject: Re: [11u] RFR: 8261812: C2 compilation fails with assert(!had_error)
> failed: bad dominance
> 
> 
> > 11u backport:
> > http://cr.openjdk.java.net/~mdoerr/8261812_C2_assert_11u/webrev.00/
> 
> Looks good to me too.
> 
> Roland.


From whuang at openjdk.java.net  Mon Apr 26 09:39:07 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Mon, 26 Apr 2021 09:39:07 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v3]
In-Reply-To: <hosTIGsBg6BorWIwVS4kFeL83SxYozDZoPzq8qqUIbY=.bd49a477-6ac4-4457-8449-336445c03128@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
 <Dyot6mD3ixa6I06Z_sZqMC5n_SmM71Du9ehPYrxjp_w=.7ee20464-de2f-4a4f-9b52-82bae02a65fc@github.com>
 <hosTIGsBg6BorWIwVS4kFeL83SxYozDZoPzq8qqUIbY=.bd49a477-6ac4-4457-8449-336445c03128@github.com>
Message-ID: <nigKBnLKx8XREGC52n1oCxwvsCVEo7gkirkFWLnVIac=.82d028bb-0f5a-4004-aa45-2fa9098b51d4@github.com>

On Fri, 23 Apr 2021 19:46:22 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

> > Thank you for answers.
> > The test should be part of changes.
> 
> I agree with @vnkozlov the jmh benchmark should be included in the changes and should be renamed to express what the benchmark is for.

Thank you for your review. I have added the benchmark. @vnkozlov @mgkwill

-------------

PR: https://git.openjdk.java.net/jdk/pull/3513

From whuang at openjdk.java.net  Mon Apr 26 09:39:00 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Mon, 26 Apr 2021 09:39:00 GMT
Subject: RFR: 8263006: Add optimization for Max(*)Node and Min(*)Node [v4]
In-Reply-To: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
References: <zK14kt6TpOaMA-sfpYd1IkGCwcgrQQe2tqOFMlZA7sk=.8c2977d4-d8c8-4bdf-9e53-cbd6170813f4@github.com>
Message-ID: <iIorfc6PCXthHuR0c97JBGBGCevmJkEnSd3Wkg3FoCY=.6cdc9849-e7e8-4ffd-9141-7455c0609ab4@github.com>

> * I optimize `max` and `min` by using these identities 
>     - op (max(a,b) , min(a,b))=== op(a,b)
>     - if op is commutable
>     - example : 
>       - max(a,b) + min(a,b))=== a + b // op = add
>       - max(a,b) * min(a,b))=== a * b  // op = mul
>       -  max( max(a,b) , min(a,b)))=== max(a,b) // op = max()
>       - min( max(a,b) , min(a,b)))=== max(a,b) // op = min()
> * Test case 
>   ```java
>   /*
>    * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
>    * under the terms of the GNU General Public License version 2 only, as
>    * published by the Free Software Foundation.
>    *
>    * This code is distributed in the hope that it will be useful, but WITHOUT
>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>    * version 2 for more details (a copy is included in the LICENSE file that
>    * accompanied this code).
>    *
>    * You should have received a copy of the GNU General Public License version
>    * 2 along with this work; if not, write to the Free Software Foundation,
>    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>    *
>    * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>    * or visit www.oracle.com if you need additional information or have any
>    * questions.
>    */
>   package org.sample;
>   
>   import org.openjdk.jmh.annotations.Benchmark;
>   import org.openjdk.jmh.annotations.*;
>   
>   import java.util.Random;
>   import java.util.concurrent.TimeUnit;
>   import org.openjdk.jmh.infra.Blackhole;
>   
>   @BenchmarkMode({Mode.AverageTime})
>   @OutputTimeUnit(TimeUnit.MICROSECONDS)
>   public class MyBenchmark {
>   
>       static int length = 100000;
>       static double[] data1 = new double[length];
>       static double[] data2 = new double[length];
>       static Random random = new Random();
>   
>       static {
>           for(int i = 0; i < length; ++i) {
>             data1[i] = random.nextDouble();
>             data2[i] = random.nextDouble();
>           }
>       }
>   
>       @Benchmark
>       public void testAdd(Blackhole bh) {
>         double sum = 0;
>         for (int i = 0; i < length; i++) {
>             sum += Math.max(data1[i], data2[i]) + Math.min(data1[i], data2[i]);
>         }
>         bh.consume(sum);
>       }
>   
>       @Benchmark
>       public void testMax(Blackhole bh) {
>           double sum = 0;
>           for (int i = 0; i < length; i++) {
>               sum += Math.max(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>           }
>           bh.consume(sum);
>       }
>   
>       @Benchmark
>       public void testMin(Blackhole bh) {
>           double sum = 0;
>           for (int i = 0; i < length; i++) {
>               sum += Math.min(Math.max(data1[i], data2[i]), Math.min(data1[i], data2[i]));
>           }
>           bh.consume(sum);
>       }
>   
>       @Benchmark
>       public void testMul(Blackhole bh) {
>           double sum = 0;
>           for (int i = 0; i < length; i++) {
>               sum += (Math.max(data1[i], data2[i]) * Math.min(data1[i], data2[i]));
>           }
>           bh.consume(sum);
>       }
>   }
>   ```
> 
> *  The result is listed here (aarch64):
> 
>   before:
> 
>   |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>   |---|                           ---|  ---|    ---|  --- | ---|
>    |o.s.MyBenchmark.testAdd     |avgt     |   10  | 556.048     |   32.368       |  us/op |
>  |  o.s.MyBenchmark.testMax  |   avgt     |   10   |543.065    |    54.221    |     us/op |
>  |  o.s.MyBenchmark.testMin    | avgt        |10   |570.731 |       37.630   |      us/op |
>   | o.s.MyBenchmark.testMul   |  avgt    |    10 |  531.906     |   20.518    |     us/op |
>  
>   after:
> 
>    |Benchmark|                           Mode|  Samples|    Score|  Score error| Units|
>   |---|                           ---|  ---|    ---|  --- | ---|
>    |  o.s.MyBenchmark.testAdd |      avgt     |     10   |  319.350  |         9.248     |      us/op |  
>  |    o.s.MyBenchmark.testMax     |  avgt    |      10 |    356.138      |    10.736 |          us/op |  
>  |    o.s.MyBenchmark.testMin  |     avgt      |    10 |    323.731  |        16.621     |      us/op |  
>  |    o.s.MyBenchmark.testMul    |   avgt     |     10  |   338.458      |    23.755  |        us/op |
> 
> *  I have tested `NaN`  ` INFINITY` and `-INFINITY` and got same result (before/after)

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  add jmh test case

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3513/files
  - new: https://git.openjdk.java.net/jdk/pull/3513/files/8aef3596..cd51304f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3513&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3513&range=02-03

  Stats: 151 lines in 1 file changed: 151 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3513.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3513/head:pull/3513

PR: https://git.openjdk.java.net/jdk/pull/3513

From thartmann at openjdk.java.net  Mon Apr 26 09:48:27 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Apr 2021 09:48:27 GMT
Subject: RFR: 8265689: JVMCI: InternalError: Class java.lang.Object does
 not implement interface jdk.vm.ci.meta.JavaType
In-Reply-To: <Q0HVfj6Pj8veCMEheKVkTvbw12X_SNmQh-feK41aeOE=.4253b109-b7b3-45a4-846b-da6d6f3773ec@github.com>
References: <Q0HVfj6Pj8veCMEheKVkTvbw12X_SNmQh-feK41aeOE=.4253b109-b7b3-45a4-846b-da6d6f3773ec@github.com>
Message-ID: <xu7bhxX6ab0U0nVr2wA1psBDLuaet5mvajEgGqNt1tI=.ac58556e-9fed-4b1a-8127-04072e842db0@github.com>

On Thu, 22 Apr 2021 13:43:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> The fix for JDK-8264918 (#3396) strengthened the checks on JVM side, but overlooked that `CompilerToVM.getVtableIndexForInterfaceMethod` callers should be adjusted as well to avoid calling into the JVM with ?onflicting arguments.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3625

From thartmann at openjdk.java.net  Mon Apr 26 09:51:30 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Apr 2021 09:51:30 GMT
Subject: RFR: 8265911: assert(comp != __null) failed: Compiler instance
 missing
In-Reply-To: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>
References: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>
Message-ID: <IpJ9pnTKNmWxwWkgkGa24sEyr-C0PARt2rOilMzaVf8=.745b022c-5c2f-41dc-8560-01e71d6eff10@github.com>

On Sun, 25 Apr 2021 08:56:39 GMT, Frank King <github.com+16741972+whjpji at openjdk.org> wrote:

> As I debugged into the code, the `_c1_count` was set to `1` [1] with flags `-XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:JVMCIHostThreads=1`. However, [2] would never be executed, and thus `_compilers[0]` was `NULL`. 
> 
> When C1 is disabled, `_c1_count` should always be `0`, so I added this `#ifdef` guard to avoid changing value of `_c1_count` under this circumstance.
> 
> [1] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L656
> [2] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L664

Looks good. Is it worth adding a regression test?

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3672

From roland at openjdk.java.net  Mon Apr 26 09:53:50 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 26 Apr 2021 09:53:50 GMT
Subject: RFR: 8252372: Check if cloning is required to move loads out of loops
 in PhaseIdealLoop::split_if_with_blocks_post()
Message-ID: <qz3kFumQXyMW3Xt3cjmvCKvMH8QumRapQa8BjETXvRY=.1a778d56-257f-437d-89d5-6e50a160a7d5@github.com>

Sinking data nodes out of a loop when all uses are out of a loop has
several issues that this attempts to fix.

1- Only non control uses are considered which makes little sense (why
  not sink if the data node is an argument to a call or a returned
  value?)

2- Sinking of Loads is broken because of the handling of
  anti-dependence: the get_late_ctrl(n, n_ctrl) call returns a control
  in the loop because it takes all uses into account.

3- For data nodes for which a control edge can't be set, commoning of
  clones back in the loop is prevented with:
  _igvn._worklist.yank(x);
  which gives no guarantee

This patch tries to address all issues:

1- it looks at all uses, not only non control uses

2- anti-dependences are computed for each use independently

3- Cast nodes are used to pin clones out of loop


2- requires refactoring of the PhaseIdealLoop::get_late_ctrl()
logic. While working on this, I noticed a bug in anti-dependence
analysis: when the use is a cfg node, the code sometimes looks at uses
of the memory state of the cfg. The logic uses the use of the cfg
which is a projection of adr_type identical to the cfg. It should
instead look at the use of the memory projection.

The existing logic for sinking loads calls clear_dom_lca_tags() for
every load which seems like quite a waste. I added a
_dom_lca_tags_round variable that's or'ed with the tag_node's _idx. By
incrementing _dom_lca_tags_round, new tags that don't conflict with
existing ones are produced and there's no need for
clear_dom_lca_tags().

For anti-dependence analysis to return a correct result, early control
of the load is needed. The only way to get it at this stage, AFAICT,
is to compute it by following the load's input until a pinned node is
reached.

The existing logic pins cloned nodes next to their use. The logic I
propose pins them right out of the loop. This could possibly avoid
some redundant clones. It also makes some special handling for corner
cases with loop strip mining useless.

For 3-, I added extra Cast nodes for float types. If a chain of data
nodes are sunk, the new logic tries to keep a single Cast for the
entire chain rather than one Cast per node.

-------------

Commit messages:
 - extra comments
 - fix

Changes: https://git.openjdk.java.net/jdk/pull/3689/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3689&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252372
  Stats: 494 lines in 12 files changed: 286 ins; 76 del; 132 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3689.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3689/head:pull/3689

PR: https://git.openjdk.java.net/jdk/pull/3689

From thartmann at openjdk.java.net  Mon Apr 26 10:00:52 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Apr 2021 10:00:52 GMT
Subject: RFR: 8265711: C1: Canonicalize Class.getModifier intrinsic method
In-Reply-To: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
Message-ID: <8n1l4xCz8Kn1h6U2K6IwH_0vx-NYzWaUdEBwZ5GFaNc=.16d7e985-30bf-4e26-b240-66405f6c25ee@github.com>

On Thu, 22 Apr 2021 07:02:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

> It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.

Changes requested by thartmann (Reviewer).

src/hotspot/share/c1/c1_Canonicalizer.cpp line 551:

> 549:     break;
> 550:   }
> 551:   case vmIntrinsics::_getModifiers           : {

Although old code below has this weird style, please change this to `_getModifiers: {`

src/hotspot/share/c1/c1_Canonicalizer.cpp line 558:

> 556:     if (c != NULL && !c->value()->is_null_object()) {
> 557:       ciType* t = c->value()->java_mirror_type();
> 558:       if (t->is_klass()) {

Shouldn't `t->is_primitive_type()` be handled as well?

test/hotspot/jtreg/compiler/c1/CanonicalizeGetModifiers.java line 94:

> 92: 
> 93:     public static void main(String... args) {
> 94:         for (int i = 0; i < 1_0000; i++) {

The thousand separator is at the wrong place, should be `10_000`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From njian at openjdk.java.net  Mon Apr 26 10:29:29 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 26 Apr 2021 10:29:29 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions
In-Reply-To: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
Message-ID: <KAkAIzJNMh9h1n8UXG6RMIfMrSi0kTSrAbP9usEsPdo=.0a773d94-f145-450d-ab39-dd6afeac1e95@github.com>

On Mon, 26 Apr 2021 05:50:20 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
> 
> 
> ## reduce_add2I, before
> mov    w10, v19.s[0]
> mov    w2, v19.s[1]
> add    w10, w0, w10
> add    w10, w10, w2
> ## reduce_add2I, optimized
> addp   v23.2s, v24.2s, v24.2s
> mov    w10, v23.s[0]
> add    w10, w10, w2
> 
> ## reduce_max2I, before
> dup    v16.2d, v23.d[0]
> sminv  s16, v16.4s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> ## reduce_max2I, optimized
> sminp  v16.2s, v23.2s, v23.2s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> 
> 
> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
> 
> 
> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
> # optimized
> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
> # default
> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
> 
> 
> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
> 
> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java

Yes, this looks good to me. Thanks!

-------------

Marked as reviewed by njian (Committer).

PR: https://git.openjdk.java.net/jdk/pull/3683

From njian at openjdk.java.net  Mon Apr 26 10:32:37 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 26 Apr 2021 10:32:37 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions
In-Reply-To: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
Message-ID: <SFCcGk5txynfL38mQX33us40hyzlPYyYlyc_4EZgl5o=.860a3f52-b647-4c7c-8b09-a7178cb5df9f@github.com>

On Mon, 26 Apr 2021 05:50:20 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
> 
> 
> ## reduce_add2I, before
> mov    w10, v19.s[0]
> mov    w2, v19.s[1]
> add    w10, w0, w10
> add    w10, w10, w2
> ## reduce_add2I, optimized
> addp   v23.2s, v24.2s, v24.2s
> mov    w10, v23.s[0]
> add    w10, w10, w2
> 
> ## reduce_max2I, before
> dup    v16.2d, v23.d[0]
> sminv  s16, v16.4s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> ## reduce_max2I, optimized
> sminp  v16.2s, v23.2s, v23.2s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> 
> 
> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
> 
> 
> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
> # optimized
> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
> # default
> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
> 
> 
> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
> 
> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2408:

> 2406:   INSN(minv,   0, 0b011011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S
> 2407:   INSN(smaxp,  0, 0b101001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S
> 2408:   INSN(sminp,  0, 0b101011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S

Just one nit: do we need an assembler test case for them?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3683

From github.com+16741972+whjpji at openjdk.java.net  Mon Apr 26 10:53:24 2021
From: github.com+16741972+whjpji at openjdk.java.net (Frank King)
Date: Mon, 26 Apr 2021 10:53:24 GMT
Subject: RFR: 8265911: assert(comp != __null) failed: Compiler instance
 missing
In-Reply-To: <IpJ9pnTKNmWxwWkgkGa24sEyr-C0PARt2rOilMzaVf8=.745b022c-5c2f-41dc-8560-01e71d6eff10@github.com>
References: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>
 <IpJ9pnTKNmWxwWkgkGa24sEyr-C0PARt2rOilMzaVf8=.745b022c-5c2f-41dc-8560-01e71d6eff10@github.com>
Message-ID: <PT7g3l6m5Z8-0WdUI1h3vVVcd7OKiOa2xYlQbWbTK1k=.e65745dc-ea5d-4024-9011-b1d912240678@github.com>

On Mon, 26 Apr 2021 09:48:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good. Is it worth adding a regression test?

Thanks @TobiHartmann.

Actually, this bug is produced by [`runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java` (4 of 10)](https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3672

From vlivanov at openjdk.java.net  Mon Apr 26 10:56:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 26 Apr 2021 10:56:40 GMT
Subject: RFR: 8265689: JVMCI: InternalError: Class java.lang.Object does
 not implement interface jdk.vm.ci.meta.JavaType
In-Reply-To: <Q0HVfj6Pj8veCMEheKVkTvbw12X_SNmQh-feK41aeOE=.4253b109-b7b3-45a4-846b-da6d6f3773ec@github.com>
References: <Q0HVfj6Pj8veCMEheKVkTvbw12X_SNmQh-feK41aeOE=.4253b109-b7b3-45a4-846b-da6d6f3773ec@github.com>
Message-ID: <QULTDVPhvhewR9Q68KpOcNCaUK_I7AMgs8cQ3SmuEzw=.08447fb3-90a3-48b1-baf5-610cf65d1acf@github.com>

On Thu, 22 Apr 2021 13:43:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> The fix for JDK-8264918 (#3396) strengthened the checks on JVM side, but overlooked that `CompilerToVM.getVtableIndexForInterfaceMethod` callers should be adjusted as well to avoid calling into the JVM with ?onflicting arguments.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

Thanks for the reviews, Vladimir and Tobias.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3625

From vlivanov at openjdk.java.net  Mon Apr 26 10:56:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 26 Apr 2021 10:56:41 GMT
Subject: Integrated: 8265689: JVMCI: InternalError: Class java.lang.Object
 does not implement interface jdk.vm.ci.meta.JavaType
In-Reply-To: <Q0HVfj6Pj8veCMEheKVkTvbw12X_SNmQh-feK41aeOE=.4253b109-b7b3-45a4-846b-da6d6f3773ec@github.com>
References: <Q0HVfj6Pj8veCMEheKVkTvbw12X_SNmQh-feK41aeOE=.4253b109-b7b3-45a4-846b-da6d6f3773ec@github.com>
Message-ID: <VYX7Sd6ppa_TwL8CUD9hQq5a6t-DjIJwFT18_B99-m4=.5ce88fc0-4cd2-4bdd-b7e9-df9705bf4318@github.com>

On Thu, 22 Apr 2021 13:43:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> The fix for JDK-8264918 (#3396) strengthened the checks on JVM side, but overlooked that `CompilerToVM.getVtableIndexForInterfaceMethod` callers should be adjusted as well to avoid calling into the JVM with ?onflicting arguments.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: 9647fb0d
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9647fb0d
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8265689: JVMCI: InternalError: Class java.lang.Object does not implement interface jdk.vm.ci.meta.JavaType

Co-authored-by: Doug Simon <dnsimon at openjdk.org>
Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3625

From thartmann at openjdk.java.net  Mon Apr 26 11:10:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Apr 2021 11:10:39 GMT
Subject: RFR: 8265911: assert(comp != __null) failed: Compiler instance
 missing
In-Reply-To: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>
References: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>
Message-ID: <Of-OgtBQEAMvTkUKc_VL14B5UzkrhA3gnXlbo-pl6e4=.67dd779e-a605-4fbd-a873-c065da3c6d8c@github.com>

On Sun, 25 Apr 2021 08:56:39 GMT, Frank King <github.com+16741972+whjpji at openjdk.org> wrote:

> As I debugged into the code, the `_c1_count` was set to `1` [1] with flags `-XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:JVMCIHostThreads=1`. However, [2] would never be executed, and thus `_compilers[0]` was `NULL`. 
> 
> When C1 is disabled, `_c1_count` should always be `0`, so I added this `#ifdef` guard to avoid changing value of `_c1_count` under this circumstance.
> 
> [1] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L656
> [2] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L664

Okay, thanks for the clarification.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3672

From github.com+16741972+whjpji at openjdk.java.net  Mon Apr 26 11:10:40 2021
From: github.com+16741972+whjpji at openjdk.java.net (Frank King)
Date: Mon, 26 Apr 2021 11:10:40 GMT
Subject: Integrated: 8265911: assert(comp != __null) failed: Compiler instance
 missing
In-Reply-To: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>
References: <e25jeCzCn7k9FfwBH0WjcvbGGRCs35zVivUsvBQL3l0=.4f35c77b-a330-4f83-91dd-5044f1a2bb34@github.com>
Message-ID: <H0WC028jYWVeHSN0Ch3DyaCwdQsbDoeZp3phIOruO64=.c87f590a-82c0-4203-b495-b9ce98f8c3af@github.com>

On Sun, 25 Apr 2021 08:56:39 GMT, Frank King <github.com+16741972+whjpji at openjdk.org> wrote:

> As I debugged into the code, the `_c1_count` was set to `1` [1] with flags `-XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:JVMCIHostThreads=1`. However, [2] would never be executed, and thus `_compilers[0]` was `NULL`. 
> 
> When C1 is disabled, `_c1_count` should always be `0`, so I added this `#ifdef` guard to avoid changing value of `_c1_count` under this circumstance.
> 
> [1] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L656
> [2] https://github.com/openjdk/jdk/blob/f1f2afda5a0ab8f213e8a1b5324a251928c8d81a/src/hotspot/share/compiler/compileBroker.cpp#L664

This pull request has now been integrated.

Changeset: 1580a473
Author:    Junji Wang <junjiwang at tencent.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1580a473
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8265911: assert(comp != __null) failed: Compiler instance missing

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3672

From dongbo at openjdk.java.net  Mon Apr 26 11:16:00 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 26 Apr 2021 11:16:00 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
Message-ID: <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com>

> On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions:
> 
> 
> ## reduce_add2I, before
> mov    w10, v19.s[0]
> mov    w2, v19.s[1]
> add    w10, w0, w10
> add    w10, w10, w2
> ## reduce_add2I, optimized
> addp   v23.2s, v24.2s, v24.2s
> mov    w10, v23.s[0]
> add    w10, w10, w2
> 
> ## reduce_max2I, before
> dup    v16.2d, v23.d[0]
> sminv  s16, v16.4s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> ## reduce_max2I, optimized
> sminp  v16.2s, v23.2s, v23.2s
> mov    w10, v16.s[0]
> cmp    w10, w0
> csel   w10, w10, w0, lt
> 
> 
> I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1].
> This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively.
> 
> 
> Benchmark                   (size)   Mode  Cnt     Score    Error   Units
> # optimized
> Int64Vector.ADDLanes          1024  thrpt   10  2492.123 ? 23.561  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1825.882 ?  5.261  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1921.028 ?  3.253  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1588.575 ?  3.903  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1923.913 ?  2.117  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1596.875 ?  2.163  ops/ms
> # default
> Int64Vector.ADDLanes          1024  thrpt   10  1644.223 ?  1.885  ops/ms
> Int64Vector.ADDMaskedLanes    1024  thrpt   10  1491.502 ? 26.436  ops/ms
> Int64Vector.MAXLanes          1024  thrpt   10  1784.066 ?  3.816  ops/ms
> Int64Vector.MAXMaskedLanes    1024  thrpt   10  1494.750 ?  3.451  ops/ms
> Int64Vector.MINLanes          1024  thrpt   10  1785.266 ?  8.893  ops/ms
> Int64Vector.MINMaskedLanes    1024  thrpt   10  1499.233 ?  3.498  ops/ms
> 
> 
> Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3.
> 
> [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  add assembler tests for smaxp/sminp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3683/files
  - new: https://git.openjdk.java.net/jdk/pull/3683/files/0de0bef4..838ccc9c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3683&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3683&range=00-01

  Stats: 254 lines in 2 files changed: 21 ins; 0 del; 233 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3683/head:pull/3683

PR: https://git.openjdk.java.net/jdk/pull/3683

From dongbo at openjdk.java.net  Mon Apr 26 11:20:35 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 26 Apr 2021 11:20:35 GMT
Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of
 two integers with NEON pairwise instructions [v2]
In-Reply-To: <SFCcGk5txynfL38mQX33us40hyzlPYyYlyc_4EZgl5o=.860a3f52-b647-4c7c-8b09-a7178cb5df9f@github.com>
References: <V6LwQe2aEEr4xa8bLDjsT3vfIadq63uHtVnDuVPGUm8=.1c0c057e-0083-4fdf-80f3-7c82068c5b1e@github.com>
 <SFCcGk5txynfL38mQX33us40hyzlPYyYlyc_4EZgl5o=.860a3f52-b647-4c7c-8b09-a7178cb5df9f@github.com>
Message-ID: <6c5_c5_wzHfSy1jgOk5SzPDAk1h_qIG0UkwWXxFpH6s=.bc853035-5a9d-4b6b-975e-dd3b7d1f6a64@github.com>

On Mon, 26 Apr 2021 10:29:24 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add assembler tests for smaxp/sminp
>
> src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2408:
> 
>> 2406:   INSN(minv,   0, 0b011011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S
>> 2407:   INSN(smaxp,  0, 0b101001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S
>> 2408:   INSN(sminp,  0, 0b101011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S
> 
> Just one nit: do we need an assembler test case for them?

Sure, added in the updated commit. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3683

From thartmann at openjdk.java.net  Mon Apr 26 11:50:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Apr 2021 11:50:39 GMT
Subject: RFR: 8265967: Unused NullCheckNode forward declaration in node.hpp
Message-ID: <qoOIFPJwXRnQTcm5pqdoG_ePHAKsHwLD_dVMSScYpsk=.6bdc5969-6b9d-4429-839c-a2d56e58fdae@github.com>

Please review this trivial change that removes the forward declaration of a nonexistent `NullCheckNode`.

Thanks,
Tobias

-------------

Commit messages:
 - 8265967: Unused NullCheckNode forward declaration in node.hpp

Changes: https://git.openjdk.java.net/jdk/pull/3691/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3691&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265967
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3691.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3691/head:pull/3691

PR: https://git.openjdk.java.net/jdk/pull/3691

From ihse at openjdk.java.net  Mon Apr 26 12:56:50 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 26 Apr 2021 12:56:50 GMT
Subject: RFR: 8264188: Improve handling of assembly files in the JDK [v3]
In-Reply-To: <N3XzVlA2e9lFDk47zQ-HE7L6PUoJczjZ9lppLW4ArTY=.f5b748fc-c30c-4532-8265-cacf62114622@github.com>
References: <N3XzVlA2e9lFDk47zQ-HE7L6PUoJczjZ9lppLW4ArTY=.f5b748fc-c30c-4532-8265-cacf62114622@github.com>
Message-ID: <Itmdu2NQy2TLswdSydNoVRMKZk7M1yqELSOlZTTgTbE=.909e7675-c484-42c8-8e0b-45939a8462ea@github.com>

> We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. 
> 
> In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. 
> 
> It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. 
> 
> For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. 
> 
> All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form
> 
> # if (a) {
> 
> as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`).
> 
> We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-().
> 
> This patch has been partly written by Sandhya Viswanathan <sviswanathan at openjdk.org> for the panama-vector repo.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into improve-asm-handling
 - Use OPENJDK_BUILD_CPU_BITS instead
 - Fix comments that trip up the preprocessor
 - Transplant over more fixes from panama-vector
 - -Ta needs to be prefixed to source file
 - Remove support for non-preprocessed assembly files in gcc/clang
 - Rename all *.s files to *.S
 - Port over initial fixes from panama-vector

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3198/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3198&range=02
  Stats: 78 lines in 12 files changed: 33 ins; 9 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3198.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3198/head:pull/3198

PR: https://git.openjdk.java.net/jdk/pull/3198

From ihse at openjdk.java.net  Mon Apr 26 13:00:33 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 26 Apr 2021 13:00:33 GMT
Subject: Integrated: 8264188: Improve handling of assembly files in the JDK
In-Reply-To: <N3XzVlA2e9lFDk47zQ-HE7L6PUoJczjZ9lppLW4ArTY=.f5b748fc-c30c-4532-8265-cacf62114622@github.com>
References: <N3XzVlA2e9lFDk47zQ-HE7L6PUoJczjZ9lppLW4ArTY=.f5b748fc-c30c-4532-8265-cacf62114622@github.com>
Message-ID: <ZlHOAjobdrAm1oRYl5nACRDe2eKNiR53Euc-UrINBLQ=.b5f1ad6c-5770-4e69-a8c6-9aac41de9a6b@github.com>

On Thu, 25 Mar 2021 16:25:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. 
> 
> In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. 
> 
> It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. 
> 
> For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. 
> 
> All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form
> 
> # if (a) {
> 
> as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`).
> 
> We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-().
> 
> This patch has been partly written by Sandhya Viswanathan <sviswanathan at openjdk.org> for the panama-vector repo.

This pull request has now been integrated.

Changeset: b9f66d93
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b9f66d93
Stats:     78 lines in 12 files changed: 33 ins; 9 del; 36 mod

8264188: Improve handling of assembly files in the JDK

Co-authored-by: Sandhya Viswanathan <sviswanathan at openjdk.org>
Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Reviewed-by: erikj, vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3198

From alanb at openjdk.java.net  Mon Apr 26 13:23:27 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 26 Apr 2021 13:23:27 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
Message-ID: <9-2H-KUkJbuLQ4wO0bSrKG4OgihZzAU30TryjlFi3jc=.bdd81481-05e6-473b-b837-2ae17fd19067@github.com>

On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove java_nio_Buffer in javaClasses.hpp

src/java.base/share/classes/java/nio/Buffer.java line 740:

> 738:      */
> 739:     final int checkIndex(int i) {                       // package-private
> 740:         return Objects.checkIndex(i, limit);

Changing Buffer.checkIndex to use Objects.checkIndex is okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From enikitin at openjdk.java.net  Mon Apr 26 14:17:25 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Mon, 26 Apr 2021 14:17:25 GMT
Subject: RFR: 8264632: compiler/codecache/jmx/PoolsIndependenceTest.java
 fails to Notification not being received
In-Reply-To: <xg1fVbT5Q1Tx7TXIlxhav7ka3v81aYOy9umlW6XK8NQ=.c8deb11a-8179-4025-ba49-f24b402bd88d@github.com>
References: <Tve8mb_uD2jmhBW2O8AMYO6H40wR-fPogYxh-WpEpbE=.297df043-078b-4eb2-aae2-80a628f458be@github.com>
 <xg1fVbT5Q1Tx7TXIlxhav7ka3v81aYOy9umlW6XK8NQ=.c8deb11a-8179-4025-ba49-f24b402bd88d@github.com>
Message-ID: <NZEkBKIk3uBXUsiyiMsJ6BGBabOllMcyYIVYzqkeiWg=.b2c8d0b2-b3e6-4d44-bcbb-2542d6b75302@github.com>

On Wed, 21 Apr 2021 15:37:56 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi Evgeny,
> 
> I'm sorry but I don't understand your root-cause analysis (and hence can't review the patch), could you please elaborate on what you mean by some other tests? as far as I can see all test actions in `PoolsIndependenceTest` are run as `@run main/othervm`, so they are executed in a fresh JVM, in other words, there were no tests which got exected before `compiler.codecache.jmx.PoolsIndependenceTest ` and no other tests are run concurrently to it.
> 
> Cheers,
> -- Igor

Hi Igor,

Yep, you're right. I came to that idea during simulated repetitive runs in attempt to trigger the problem, but the idea of mutual interference is completely wrong. I'm closing the PR.

// Evgeny.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3592

From enikitin at openjdk.java.net  Mon Apr 26 14:17:25 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Mon, 26 Apr 2021 14:17:25 GMT
Subject: Withdrawn: 8264632: compiler/codecache/jmx/PoolsIndependenceTest.java
 fails to Notification not being received
In-Reply-To: <Tve8mb_uD2jmhBW2O8AMYO6H40wR-fPogYxh-WpEpbE=.297df043-078b-4eb2-aae2-80a628f458be@github.com>
References: <Tve8mb_uD2jmhBW2O8AMYO6H40wR-fPogYxh-WpEpbE=.297df043-078b-4eb2-aae2-80a628f458be@github.com>
Message-ID: <fYdMY384xhKulS4x650z5u8b96C0Iok5Or_rlHOBeA0=.228cce97-19ae-4e55-8605-62c4c1628758@github.com>

On Tue, 20 Apr 2021 18:04:07 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> Hi all,
> 
> May I ask for reviews for this change? 
> 
> **The case**
> https://bugs.openjdk.java.net/browse/JDK-8264632
> 
> **The problem**
> The test calls for MemoryPoolMXBean.setUsageThreshold() and expects a Notification get fired when the threshold is breached. The Notification is never received.
> 
> The failure most probably is caused by the combination of following events:
> 1. Some threshold has already breached (caused by some other tests); 
> 2. In this case MemoryPoolMXBean never fires subsequent Notifications until the usage is less than a set threshold;
> 3. The usage manages to grow up between these two lines[1]:
> 
> final long usageThresholdLimit = bean.getUsage().getUsed() + 1;
> bean.setUsageThreshold(usageThresholdLimit);
> 
> 4. The usage has never fallen below any set threshold and therefore Notification is never sent. Setting usageThresholdLimit to 0 doesn't clear up the situation "Notification has already been sent" either.
> 
> [1] Very common, happens almost every time during my testing - the code cache usage grows up quickly at VM start.
> 
> **Proposed solution:**
> 1. Before the actual test, I set the usageThresholdLimit to max. possible value;
> 2. This causes the current usage to appear below the threshold and therefore the "Notification has already been sent" state is cleared;
> 3. The monitoring is then switched off (by setting usageThresholdLimit to 0), as at the VM start.
> 
> **Testing**
> 1. Preemptive breaching of some threshold causes the problem for non-modified test.
> 2. The modified test has been tested with debug versions of macosx, windows, linux x64 builds and a linux-aarch64-debug build.
> 
> Thanks,
> Evgeny.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3592

From kvn at openjdk.java.net  Mon Apr 26 17:24:34 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 17:24:34 GMT
Subject: RFR: 8258625: [JVMCI] refactor and unify JVMCI readFieldValue path
In-Reply-To: <Wm4wRAeWj0lWMTW7lPYlTDlKo4DQpqtAd45cTS1AKm0=.0f7d0cde-0c00-4c16-97b4-be6498589c54@github.com>
References: <Wm4wRAeWj0lWMTW7lPYlTDlKo4DQpqtAd45cTS1AKm0=.0f7d0cde-0c00-4c16-97b4-be6498589c54@github.com>
Message-ID: <cdehjF8K29FR5POX6cnYjWRG3O3DVDVVDHSnsLkmB5E=.524123a8-b2e9-4324-a9fc-0f98d3346d34@github.com>

On Fri, 23 Apr 2021 18:39:11 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This was originally just a cleanup but it turned out to be a partial safety fix for folding reads during compilation.  I've rolled in a couple other safety checks that were found along the way, along with jtreg test improvements that exercise the new paths.

Seems good.
Doug should review it too.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3659

From kvn at openjdk.java.net  Mon Apr 26 17:25:05 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 17:25:05 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v2]
In-Reply-To: <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>
Message-ID: <yRWUfm3ULtsPLjbFpPLruHwFDq9ZdIaeH-UjE1VVabQ=.b3e087bb-f4a8-4c00-8da3-1ce2c07c9ecd@github.com>

On Mon, 26 Apr 2021 06:06:07 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
>> 
>> E.g., for Math.pow(1.0 / 2047, 2.0):
>> 
>> interpreter: 2.38651580386563E-7 
>>          C2: 2.3865158038656307E-7
>> 
>> 
>> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
>> However, there is no such optimization for interpreter/C1 on x86_32.
>> 
>> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
>> And we don't have a plan to implement such opt on x86_32.
>> 
>> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize pow(x, 2.0) for x86_32

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3677

From kvn at openjdk.java.net  Mon Apr 26 17:25:12 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 17:25:12 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32
In-Reply-To: <pY6cHUuBrimBhnjj6Dqezdco62jB4rRNsF29TrFFsKI=.a5258a1f-65c4-401c-9238-ed727f1193c5@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <qUbhA3-YoQCS1aOvDzyJsLEFBkP-XhtfwW9J9gpJRrY=.bc461aad-358c-4da8-8db5-91eb5f11b24b@github.com>
 <pY6cHUuBrimBhnjj6Dqezdco62jB4rRNsF29TrFFsKI=.a5258a1f-65c4-401c-9238-ed727f1193c5@github.com>
Message-ID: <j7aTXxJjJoViJh2DPDUPjxeE3cOTqZTJDnRG1zhWNZ4=.87fa920f-11bd-4c30-ae33-4b8312c2ef04@github.com>

On Mon, 26 Apr 2021 06:17:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> As for the Math.pow(x, 0.5), it will be handled in JDK-8265940 after this issue.
> 

Okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From kvn at openjdk.java.net  Mon Apr 26 18:45:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 18:45:36 GMT
Subject: RFR: 8265967: Unused NullCheckNode forward declaration in node.hpp
In-Reply-To: <qoOIFPJwXRnQTcm5pqdoG_ePHAKsHwLD_dVMSScYpsk=.6bdc5969-6b9d-4429-839c-a2d56e58fdae@github.com>
References: <qoOIFPJwXRnQTcm5pqdoG_ePHAKsHwLD_dVMSScYpsk=.6bdc5969-6b9d-4429-839c-a2d56e58fdae@github.com>
Message-ID: <KJc-cKWgdiKgcr9H4GA9uZPYqQGlYxDDyiH7fJYDyyo=.2935f29e-3527-4113-ab8f-4685b09bc9ae@github.com>

On Mon, 26 Apr 2021 11:44:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Please review this trivial change that removes the forward declaration of a nonexistent `NullCheckNode`.
> 
> Thanks,
> Tobias

Trivial.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3691

From kvn at openjdk.java.net  Mon Apr 26 18:54:34 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 18:54:34 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
Message-ID: <ooLzkpeRvYNoIKWq20AeL_bcGzCZXsB2tzCr7ZxP5hY=.0c7004af-7034-45b0-88d6-a9b1d9ca55ca@github.com>

On Mon, 26 Apr 2021 06:46:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
> 
> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
> 
> This issue was reported by John Jiang (johnsjiang at tencent.com).
> 
> Thanks,
> Tobias

The fix is good.

I think you need System.exit(0) (or something else) at the end of test. Otherwise the test runs forever due to presence of infinite loop in an other thread. I tried.
May be @iignatev can suggest graceful solution for timely exit in such case.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3684

From kvn at openjdk.java.net  Mon Apr 26 18:57:43 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 18:57:43 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
Message-ID: <Lc7bg6OTgo-fgIlGu__9dvggsFiT1JlySJAPyUR-KC8=.3716044a-fcd4-4e94-bee1-5c0f3c59c666@github.com>

On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove java_nio_Buffer in javaClasses.hpp

@veresov please look on C1 changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From iignatyev at openjdk.java.net  Mon Apr 26 19:09:43 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 26 Apr 2021 19:09:43 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <eaIxoIKm5q1njHQ1X8CiesciG14_Qyfa688551ASzFc=.0a9d6b28-f7d9-482b-84c0-31f98241da48@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <uPzckD9PeCL-nvTQxAijetsqYo4cx66VvNEFSYAlMMY=.148a5e41-1c45-46c5-aaf1-eaa73686f4e8@github.com>
 <eaIxoIKm5q1njHQ1X8CiesciG14_Qyfa688551ASzFc=.0a9d6b28-f7d9-482b-84c0-31f98241da48@github.com>
Message-ID: <bsZfIFI9TY4ROPzAWPqKNMMAjJeXEDvWqMsdL3tXniA=.3859dc36-78ba-470e-b1f8-dd777665ada5@github.com>

On Mon, 19 Apr 2021 07:29:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 62:
>> 
>>> 60:      *  </ul>
>>> 61:      */
>>> 62:     ANY(-2),
>> 
>> This will change (`-2` -> `-1`) after AOT is removed (8264805).
>
> I'll change that as soon as it is integrated.

should we also add a comment suggesting to keep in sync w/ `compiler/compilerDefinitions.hpp`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Mon Apr 26 19:09:43 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 26 Apr 2021 19:09:43 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v6]
In-Reply-To: <bx37BlKEGAGguvVKHvGFpNX05eFU27sng_RHmV_6ASg=.6b1a194f-f6e7-4bb0-a6ca-21dd79b16a52@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <bx37BlKEGAGguvVKHvGFpNX05eFU27sng_RHmV_6ASg=.6b1a194f-f6e7-4bb0-a6ca-21dd79b16a52@github.com>
Message-ID: <NfQVyJmkahrCDcv6z8uWeTD-Vjw1KEmcVIgI4X2d3-g=.07970959-6917-4689-bcc6-6d3e48a2010f@github.com>

On Fri, 23 Apr 2021 12:39:32 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup

Changes requested by iignatyev (Reviewer).

test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 87:

> 85:             String parameters = args == null || args.length == 0 ? "" :
> 86:                     " with arguments [" + Arrays.stream(args).map(Class::getName).collect(Collectors.joining(",")) + "]";
> 87:             throw new TestRunException("Could not find method " + name + " in " + c + parameters);

I'd pass `e` (`NSME`) to `TestRunException::<init>` so the info in it won't be lost

test/lib/jdk/test/lib/hotspot/ir_framework/Argument.java line 80:

> 78:      * Float and double values are restricted to the range [-10000,10000].
> 79:      */
> 80:     RANDOM_EACH

nit: I'd put a trailing comma here, so the future additions will have lesser chance for a merge conflict

test/lib/jdk/test/lib/hotspot/ir_framework/CheckAt.java line 42:

> 40:      * and the framework has compiled the associated {@link Test} method.
> 41:      */
> 42:     COMPILED

nit: trailing comma

test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 65:

> 63:      *  Compilation level 1: C1 compilation without any profile information.
> 64:      */
> 65:     C1(1),

this name might be misleading, as one can assume that it means all C1 levels, `C1_SIMPLE`?

test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 77:

> 75:      * Compilation level 4: C2 compilation with full optimizations.
> 76:      */
> 77:     C2(4);

nit:
Suggestion:

    C2(4),
    
    ;

test/lib/jdk/test/lib/hotspot/ir_framework/DeclaredTest.java line 90:

> 88:                         argumentValString += " (" + (int)(Character)argumentVal + ")";
> 89:                     }
> 90:                     builder.append("arg ").append(i).append(": ").append(argumentValString).append(", ");

you can avoid extra string concatination:
Suggestion:

                    builder.append("arg ").append(i).append(": ").append(argumentVal.toString());
                    if (argumentVal instanceof Character) {
                        builder.append(" (").append((int)(Character)argumentVal).append(")");
                    }
                    builder..append(", ");

test/lib/jdk/test/lib/hotspot/ir_framework/DontCompile.java line 39:

> 37:  *     <li><p>The usage of any other compilation level is forbidden and results in a
> 38:  *            {@link TestFormatException TestFormatException}.</li>
> 39:  * </ul>

this actually suggests that we shouldn't use `CompLevel` here and need to introduce another enum to denote compilers.

test/lib/jdk/test/lib/hotspot/ir_framework/ForceCompile.java line 44:

> 42:  *            {@link TestFormatException}.</li>
> 43:  *     <li><p>{@link CompLevel#WAIT_FOR_COMPILATION}: Does not apply to {@code @ForceCompile} and results in a
> 44:  *            {@link TestFormatException}.</li>

the same comment as in `ForceCompileClassInitializer.java`

test/lib/jdk/test/lib/hotspot/ir_framework/ForceCompileClassInitializer.java line 44:

> 42:  *     {@link TestFormatException}.</li>
> 43:  *     <li><p>{@link CompLevel#WAIT_FOR_COMPILATION}: Does not apply to {@code @ForceCompileClassInitializer} and results in a
> 44:  *     {@link TestFormatException}.</li>

I don't think you should list all `CompLevel` here as this increases maintenance cost (if/when we update CompLevel) for little to no gain, I'd just mention that `SKIP` and `WAIT_FOR_COMPILATION` are inapplicable here.

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 39:

> 37: class IRMatcher {
> 38:     private static final boolean PRINT_IR_ENCODING = Boolean.parseBoolean(System.getProperty("PrintIREncoding", "false"));
> 39:     private static final Pattern irEncodingPattern =

we typically use UPPER_CAMEL_CASE for constants such as `irEncodingPattern`

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 54:

> 52: 
> 53:     public IRMatcher(String hotspotPidFileName, String irEncoding, Class<?> testClass) {
> 54:         this.compilations =  new HashMap<>();

nite: double space b/w `=` and `new`

test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 127:

> 125:     private void parseHotspotPidFile() {
> 126:         Map<Integer, String> compileIdMap = new HashMap<>();
> 127:         try (BufferedReader br = Files.newBufferedReader(Paths.get(hotspotPidFileName))) {

nit: I'd use `var` here, and it seems this would reduce classes imported from `java.io` to just `IOException`, so we could change L#26 to an explicit import.

Suggestion:

        try (var br = Files.newBufferedReader(Paths.get(hotspotPidFileName))) {

test/lib/jdk/test/lib/hotspot/ir_framework/IRNode.java line 132:

> 130: 
> 131:     static List<String> mergeNodes(String[] nodes) {
> 132:         final List<String> mergedNodes = new ArrayList<>();

nit: I don't see any reasons for this var to be `final`.

test/lib/jdk/test/lib/hotspot/ir_framework/RunMode.java line 42:

> 40:      * method.
> 41:      */
> 42:     STANDALONE

nit: a trailing comma

test/lib/jdk/test/lib/hotspot/ir_framework/Scenario.java line 55:

> 53:     static {
> 54:         if (!SCENARIOS_PROPERTY.isEmpty()) {
> 55:             System.out.println(Arrays.toString(SCENARIOS_PROPERTY.split("\\s*,\\s*")));

did you mean to print it here or was it just a leftover from a debugging session?

test/lib/jdk/test/lib/hotspot/ir_framework/Scenario.java line 62:

> 60:                                            + "a number: " + SCENARIOS_PROPERTY);
> 61:             }
> 62:         }

a more idiomatic way to do that would be to remove initialization of `ENABLED_SCENARIOS` at L46 and do:
Suggestion:

        if (!SCENARIOS_PROPERTY.isEmpty()) {
           var split = SCENARIOS_PROPERTY.split("\\s*,\\s*");
            System.out.println(Arrays.toString(split));
            try {
                ENABLED_SCENARIOS  = Arrays.stream(split).map(Integer::parseInt).collect(Collectors.toList());
            } catch (NumberFormatException e) {
                throw new TestRunException("Provided a scenario index in the -DScenario comma-separated list which is not "
                                           + "a number: " + SCENARIOS_PROPERTY);
            }
        } else {
            ENABLED_SCENARIOS = Collections.emptyList();
        }

test/lib/jdk/test/lib/hotspot/ir_framework/Scenario.java line 66:

> 64:         if (!ADDITIONAL_SCENARIO_FLAGS_PROPERTY.isEmpty()) {
> 65:             ADDITIONAL_SCENARIO_FLAGS.addAll(Arrays.asList(ADDITIONAL_SCENARIO_FLAGS_PROPERTY.split("\\s*,\\s*")));
> 66:         }

similar comment, this can be replaced by just:
Suggestion:

       ADDITIONAL_SCENARIO_FLAGS = ADDITIONAL_SCENARIO_FLAGS_PROPERTY.isEmpty() ? Collections.emptyList() : Arrays.asList(ADDITIONAL_SCENARIO_FLAGS_PROPERTY.split("\\s*,\\s*"));

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 135:

> 133:                                         - To only run the failed tests use -DTest, -DExclude,
> 134:                                           and/or -DScenarios.
> 135:                                         - To also get the standard output of the test VM run with\s

why do you need `\s` here?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 146:

> 144:     private static final boolean REPORT_STDOUT = Boolean.getBoolean("ReportStdout");
> 145:     private final boolean VERIFY_VM = Boolean.getBoolean("VerifyVM") && Platform.isDebugBuild();
> 146:     private boolean VERIFY_IR = Boolean.parseBoolean(System.getProperty("VerifyIR", "true"));

it seems both these guys were meant to be `static final`

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 156:

> 154:     private List<Scenario> scenarios = null;
> 155:     private Set<Integer> scenarioIndices = null;
> 156:     private List<String> flags = null;

`null` is a default value for reference types, so there is no need to set it explicitly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Mon Apr 26 19:18:44 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 26 Apr 2021 19:18:44 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v2]
In-Reply-To: <zbToJ5_pj6ysv-TUUD0oYpWacEvz0oUn2_CYDhHcJj4=.58f0dac0-8224-465c-9da0-da7970e91248@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <Bs7_nxWjUBUu1w2Noetr6_36EKMlxOJOCM-uXT3zw0w=.d14c22ba-68c5-4d37-9210-07f00d63afb9@github.com>
 <xxbm1as_hR1VGJ7xG7FRMFDBpPJWYstFiiC8VoCOvSo=.8b7237ef-4bb6-4471-b9c7-404b8f10a6ec@github.com>
 <gxsA__SaOXZ2CYH2QMYVPIRiodtR-_HJv4n3s7VsAOA=.75227295-f0f8-4055-a29a-5d5fd3a28a68@github.com>
 <zbToJ5_pj6ysv-TUUD0oYpWacEvz0oUn2_CYDhHcJj4=.58f0dac0-8224-465c-9da0-da7970e91248@github.com>
Message-ID: <8m3dztYNNjO9ZHKSoyH3-YOtwFbKpMyn8WPgnxZRV-Q=.a07c3878-4567-4c43-b732-515fa750a6b2@github.com>

On Mon, 19 Apr 2021 15:34:27 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>>> * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files
>>> * the same goes for `README.html` generated from `README.md`
>> 
>> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? 
>> 
>>> * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`.
>>> * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot`
>> 
>> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)?
>> 
>> I will do this things in a separate commit and adjust the README.md file accordingly (has links to the Javadoc files).
>
>> > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files
>> > * the same goes for `README.html` generated from `README.md`
>> 
>> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk?
>> 
>> > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`.
>> > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot`
>> 
>> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)?
> 
> `test/hotspot/jtreg/testlibrary_tests` are seldomly run as part of `:hotspot_misc` test group, yet I don't think it's an issue. the benefit of running testlibrary tests is to gain confidence that the tests which use these libraries are reliable. I'd also disagree that `ir_framework/tests` should be run *only* when the framework is actually, they should also be run when its dependencies are changed, and the framework highly depends on hotspot, so to be sure that the framework didn't get broken after changes in c2, whitebox, etc, you do need run these tests more often.
> 
> Thanks,
> -- Igor

> There is no decision, yet, (and open for discussion) about the location and package name for the framework and the framework internal tests. After discussing it offline with @iignatev, we think there are basically two good options:
> 
> 1. Leave the framework in `/test/lib` and put the framework internal tests into `/test/lib-test`:
>    
>    * Pros: Only need to specify `@library /test/lib` in a JTreg test; the framework internal tests are run in tier1 before any other tests are run which depend on the framework ensuring correctness.
>    * Cons: Clarity: The framework is intended to be used for HotSpot tests only (thus not exactly the right location in `/test/lib`); the framework internal tests might be run too often as part of tier1 (trade-off ensuring correctness vs. execution time).
> 2. Move the framework to `/test/hotspot/jtreg/testlibrary`, put the framework internal tests into `/test/hotspot/jtreg/testlibrary_tests`, and use package name `hotspot.test.lib.ir_framework`:
>    
>    * Pros: Clarity: The framework is only used for HotSpot tests (mainly compiler tests but could also be used for other tests).
>    * Cons: A JTreg test needs to additionally specify `/testlibrary/ir_framework` like `@library /testlibrary/ir_framework /test/lib`; the framework internal tests are run more seldomly as part of `:hotspot_misc` (trade-off, see cons of first option).
> 

there is also 3rd alternative, move the framework to `/test/hotspot/jtreg/compiler/` and use `compiler.ir_framework` or `compiler.lib.ir_framework` as the package name. that will make it even clearer that this is a compiler-specific library, and its users are going to be in `/test/hotspot/jtreg/compiler/`. I understand that there can be some runtime (or other) tests that might benefit from this library, but in the end, they won't be clear runtime tests, so `t/h/j/compiler` might be a better location for them anyways. the `@library` tag will still have to contain two paths, but these will be usual paths as in many compiler tests : `@library / /test/lib`.
the tests can be placed in `/test/hotspot/jtreg/testlibrary_tests` as in the 2nd option, with the same trade-off.

-- Igor

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From dnsimon at openjdk.java.net  Mon Apr 26 19:25:34 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 26 Apr 2021 19:25:34 GMT
Subject: RFR: 8258625: [JVMCI] refactor and unify JVMCI readFieldValue path
In-Reply-To: <Wm4wRAeWj0lWMTW7lPYlTDlKo4DQpqtAd45cTS1AKm0=.0f7d0cde-0c00-4c16-97b4-be6498589c54@github.com>
References: <Wm4wRAeWj0lWMTW7lPYlTDlKo4DQpqtAd45cTS1AKm0=.0f7d0cde-0c00-4c16-97b4-be6498589c54@github.com>
Message-ID: <7NU6OTvhYhvNoW2bVysoaeabououPbVqwKQTvC5mIso=.ba07b1da-655a-4761-a46a-2c63d2d6b026@github.com>

On Fri, 23 Apr 2021 18:39:11 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This was originally just a cleanup but it turned out to be a partial safety fix for folding reads during compilation.  I've rolled in a couple other safety checks that were found along the way, along with jtreg test improvements that exercise the new paths.

LGTM.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3659

From iignatyev at openjdk.java.net  Mon Apr 26 19:29:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 26 Apr 2021 19:29:38 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
Message-ID: <-2BddQRFAwdLcyLljqm252vjbhM-hQYvVUP9re6TkkU=.6b1724a1-4915-4ebe-9cbe-cf1ff799eb1d@github.com>

On Mon, 26 Apr 2021 06:46:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
> 
> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
> 
> This issue was reported by John Jiang (johnsjiang at tencent.com).
> 
> Thanks,
> Tobias

one way to solve it is to make the thread created at L#57 daemon thread (+L64: `thread.setDaemon(true);`).

I'd also recommend you to use `jdk.test.lib.Utils::adjustTimeout` to factor the sleep time at L66: `Thread.sleep(Utils.adjustTimeout(4000));`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From never at openjdk.java.net  Mon Apr 26 20:03:36 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Mon, 26 Apr 2021 20:03:36 GMT
Subject: Integrated: 8258625: [JVMCI] refactor and unify JVMCI readFieldValue
 path
In-Reply-To: <Wm4wRAeWj0lWMTW7lPYlTDlKo4DQpqtAd45cTS1AKm0=.0f7d0cde-0c00-4c16-97b4-be6498589c54@github.com>
References: <Wm4wRAeWj0lWMTW7lPYlTDlKo4DQpqtAd45cTS1AKm0=.0f7d0cde-0c00-4c16-97b4-be6498589c54@github.com>
Message-ID: <nEfcnc9Duhy1ktuDXvW0URq106SP3n9oFRLOAgh5vQo=.807240a7-a7b6-4ff1-ac3f-42b77fe256d2@github.com>

On Fri, 23 Apr 2021 18:39:11 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This was originally just a cleanup but it turned out to be a partial safety fix for folding reads during compilation.  I've rolled in a couple other safety checks that were found along the way, along with jtreg test improvements that exercise the new paths.

This pull request has now been integrated.

Changeset: 852a41d7
Author:    Tom Rodriguez <never at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/852a41d7
Stats:     799 lines in 17 files changed: 170 ins; 529 del; 100 mod

8258625: [JVMCI] refactor and unify JVMCI readFieldValue path

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3659

From vlivanov at openjdk.java.net  Mon Apr 26 20:24:01 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 26 Apr 2021 20:24:01 GMT
Subject: RFR: 8263972: C2: LoadVector/StoreVector type mismatch in
 MemNode::can_see_stored_value()
Message-ID: <vk57j-MOSDyC9q6BE69rqM9hz_EEwkOODJ2eCbEDnEo=.4639fa30-8287-4905-88f1-3354bbd4cf3a@github.com>

`MemNode::can_see_stored_value()` doesn't take type info for `LoadVector`/`StoreVector` into account.

Eliminating `LoadVector`/`StoreVector` pair in presence of a type mismatch leads to a broken graph (omitting vector cast nodes) and sometimes manifest as a broken generated code. 

The fix adds necessary checks for vector case. 

Testing:
- [x] regression test
- [x] hs-tier1 - hs-tier4

-------------

Commit messages:
 - Whitespaces
 - Regression test
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/3698/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3698&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263972
  Stats: 82 lines in 2 files changed: 81 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3698.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3698/head:pull/3698

PR: https://git.openjdk.java.net/jdk/pull/3698

From kvn at openjdk.java.net  Mon Apr 26 22:27:35 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 22:27:35 GMT
Subject: RFR: 8263972: C2: LoadVector/StoreVector type mismatch in
 MemNode::can_see_stored_value()
In-Reply-To: <vk57j-MOSDyC9q6BE69rqM9hz_EEwkOODJ2eCbEDnEo=.4639fa30-8287-4905-88f1-3354bbd4cf3a@github.com>
References: <vk57j-MOSDyC9q6BE69rqM9hz_EEwkOODJ2eCbEDnEo=.4639fa30-8287-4905-88f1-3354bbd4cf3a@github.com>
Message-ID: <FJGwuM83wplegFvLoMJNlS2L-pHCNQXpz-A3jvQ4xZE=.fbbf062f-70dc-4d76-9126-49cb52362bcb@github.com>

On Mon, 26 Apr 2021 16:07:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> `MemNode::can_see_stored_value()` doesn't take type info for `LoadVector`/`StoreVector` into account.
> 
> Eliminating `LoadVector`/`StoreVector` pair in presence of a type mismatch leads to a broken graph (omitting vector cast nodes) and sometimes manifest as a broken generated code. 
> 
> The fix adds necessary checks for vector case. 
> 
> Testing:
> - [x] regression test
> - [x] hs-tier1 - hs-tier4

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3698

From kvn at openjdk.java.net  Mon Apr 26 22:45:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 22:45:25 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v6]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <nltrVq6SKEmgbuz4LuFlhxOqflGrSyf04EhJefvGxUA=.b01a8293-d4c2-4f8f-8e59-9d2ca2a7db4e@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into JDK-8264805
 - Address review comments
 - Remove exports from Graal module to jdk.aot
 - Merge branch 'master' into JDK-8264805
 - Merge branch 'master' into JDK-8264805
 - 8264805: Remove the experimental Ahead-of-Time Compiler

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=05
  Stats: 26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

PR: https://git.openjdk.java.net/jdk/pull/3398

From jiefu at openjdk.java.net  Mon Apr 26 23:25:39 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 26 Apr 2021 23:25:39 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v2]
In-Reply-To: <yRWUfm3ULtsPLjbFpPLruHwFDq9ZdIaeH-UjE1VVabQ=.b3e087bb-f4a8-4c00-8da3-1ce2c07c9ecd@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>
 <yRWUfm3ULtsPLjbFpPLruHwFDq9ZdIaeH-UjE1VVabQ=.b3e087bb-f4a8-4c00-8da3-1ce2c07c9ecd@github.com>
Message-ID: <Ax_Wa46HAXccldnz7cvYQhBIzi8kjtwYIpTkju3iKUI=.704b6ec4-dd81-4035-a3f3-b1c5fea7e82c@github.com>

On Mon, 26 Apr 2021 16:07:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Good.

Thanks @vnkozlov for your review.

Let's wait for a second review of this change.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From github.com+2249648+johntortugo at openjdk.java.net  Tue Apr 27 01:02:44 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Tue, 27 Apr 2021 01:02:44 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v6]
In-Reply-To: <bx37BlKEGAGguvVKHvGFpNX05eFU27sng_RHmV_6ASg=.6b1a194f-f6e7-4bb0-a6ca-21dd79b16a52@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <bx37BlKEGAGguvVKHvGFpNX05eFU27sng_RHmV_6ASg=.6b1a194f-f6e7-4bb0-a6ca-21dd79b16a52@github.com>
Message-ID: <1MYGXgT-l5ghB-P0sQ7V1YcH3KmqPVra8pnjjWpJIOo=.c7a271c2-01dc-448e-ac95-22d7d30af0af@github.com>

On Fri, 23 Apr 2021 12:39:32 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup

test/lib/jdk/test/lib/hotspot/ir_framework/Run.java line 96:

> 94: public @interface Run {
> 95:     /**
> 96:      * The associated {@link Test @Test} methods (one or more) for for this {@code @Run} annotated run method.

Typo: "for for"

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 149:

> 147:             String testClassName = args[0];
> 148:             System.out.println("Framework main(), about to run tests in class " + testClassName);
> 149:             Class<?> testClass;

Merge this and next line?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 163:

> 161:         Class<?> c;
> 162:         try {
> 163:             c = Class.forName(className);

Maybe just return "Class.forName(className)" here?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 174:

> 172:      */
> 173:     private void addHelperClasses(String[] args) {
> 174:         Class<?>[] helperClasses = getHelperClasses(args);

It's a bit confusing that this local variable has the same name as the class property.

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 308:

> 306: 
> 307:     private void processControlAnnotations(Class<?> clazz) {
> 308:         if (!XCOMP) {

Perhaps transform this condition on an early return, i.e., "if (XCOMP) return ;", instead of nesting the whole method under the if.

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 340:

> 338:     private void applyClassAnnotations(Class<?> c) {
> 339:         ForceCompileClassInitializer anno = getAnnotation(c, ForceCompileClassInitializer.class);
> 340:         if (anno != null) {

Transform to early return?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 373:

> 371:         boolean exclude = random.nextBoolean();
> 372:         CompLevel level = CompLevel.ANY;
> 373:         if (exclude) {

Transform to early return?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 378:

> 376:                 case 1 -> {
> 377:                     level = CompLevel.C1;
> 378:                     WHITE_BOX.makeMethodNotCompilable(ex, CompLevel.C2.getValue(), false);

I'm curious why two calls (with different values for the last parameter) are needed for these?

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 591:

> 589:     }
> 590: 
> 591:     private static CompLevel flipCompLevel(CompLevel compLevel) {

Wouldn't be better to put this on the CompLevel enum itself?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From ddong at openjdk.java.net  Tue Apr 27 01:10:43 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 27 Apr 2021 01:10:43 GMT
Subject: RFR: 8265129: Add intrinsic support for JVM.getClassId [v2]
In-Reply-To: <uWwjeNfhY2jYzpsGcE8k41BzIgax6UN8NzlUwB_p-ig=.ccf8e6fd-0a67-4541-98ad-b449bc60065c@github.com>
References: <WRTO3ij4-ef6lLk8NMQWGkmd68vFfqLICYU9nIakgOU=.d10e0f2f-087c-43f9-b08a-86c51919ac44@github.com>
 <uWwjeNfhY2jYzpsGcE8k41BzIgax6UN8NzlUwB_p-ig=.ccf8e6fd-0a67-4541-98ad-b449bc60065c@github.com>
Message-ID: <elNNRrW6Yz0mk8g_UFFF1VchSTzcPIxHrJ8S9PoaHtE=.de46a6fb-21c8-4a07-b9d8-d4cd3823e11f@github.com>

On Fri, 23 Apr 2021 12:37:42 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> 8265129: Add intrinsic support for JVM.getClassId
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add doc

Hi,
Could I have a review of this PR? 
Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3470

From kvn at openjdk.java.net  Tue Apr 27 01:15:37 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 01:15:37 GMT
Subject: Integrated: 8264805: Remove the experimental Ahead-of-Time Compiler
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <3MIAR4n0RJot9rerXkZf7hB7NlYhJbPI6ri5q9IP3SM=.c6fecb4a-0d84-4c78-bf41-b750ee03d6df@github.com>

On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

This pull request has now been integrated.

Changeset: 694acedf
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/694acedf
Stats:     26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod

8264805: Remove the experimental Ahead-of-Time Compiler

Reviewed-by: coleenp, erikj, stefank, iignatyev, dholmes, aph, shade, iklam, mchung, iveresov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Tue Apr 27 02:18:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 02:18:40 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v4]
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <0mJY3m49euRLBowk0WfgXqx6bGSqNJFykEXZdJ9cO6k=.87753850-16f7-4c15-b526-c29898caf5ac@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> 
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'JDK-8264805' into JDK-8264806
 - Merge branch 'master' into JDK-8264805
 - Restore Compiler::isGraalEnabled()
 - Restore Graal Builder image makefile
 - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
 - Address review comments
 - 8264806: Remove the experimental JIT compiler
 - Remove exports from Graal module to jdk.aot
 - Merge branch 'master' into JDK-8264805
 - Merge branch 'master' into JDK-8264805
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b524a81a...db7c9aaf

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3421/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=03
  Stats: 468493 lines in 3247 files changed: 2 ins; 468290 del; 201 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3421.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421

PR: https://git.openjdk.java.net/jdk/pull/3421

From kvn at openjdk.java.net  Tue Apr 27 04:44:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 04:44:17 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v5]
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <9SR3Bnj0ywpPcSx4uU4G9oH7cXJv6dWPIkvyIb_rnKo=.30180267-aeb7-4ab3-947a-cdf80e62c81c@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> 
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8264806
 - Merge branch 'JDK-8264805' into JDK-8264806
 - Merge branch 'master' into JDK-8264805
 - Restore Compiler::isGraalEnabled()
 - Restore Graal Builder image makefile
 - Merge latest changes from branch 'JDK-8264805' into JDK-8264806
 - Address review comments
 - 8264806: Remove the experimental JIT compiler
 - Remove exports from Graal module to jdk.aot
 - Merge branch 'master' into JDK-8264805
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/694acedf...b1e9ba63

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3421/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=04
  Stats: 441532 lines in 2884 files changed: 0 ins; 441518 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3421.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421

PR: https://git.openjdk.java.net/jdk/pull/3421

From kvn at openjdk.java.net  Tue Apr 27 06:26:53 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 06:26:53 GMT
Subject: Integrated: 8264806: Remove the experimental JIT compiler
In-Reply-To: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
Message-ID: <Ag2soyoHyod50x0jbW9wCqjeeiPoY5exNLGilCeUBOw=.915beb49-19c7-4091-9476-c069bffc8123@github.com>

On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK:
> 
> - `jdk.internal.vm.compiler` ? the Graal compiler 
> - `jdk.internal.vm.compiler.management` ? Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests
> 
> Remove Graal related code in makefiles.
> 
> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build:
> 
> src/jdk.internal.vm.compiler/share/classes/module-info.java
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
> 
> 
> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.
> 
> Tested hs-tier1-4

This pull request has now been integrated.

Changeset: 4785e112
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4785e112
Stats:     441532 lines in 2884 files changed: 0 ins; 441518 del; 14 mod

8264806: Remove the experimental JIT compiler

Reviewed-by: iignatyev, erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/3421

From thartmann at openjdk.java.net  Tue Apr 27 07:54:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 07:54:39 GMT
Subject: RFR: 8265967: Unused NullCheckNode forward declaration in node.hpp
In-Reply-To: <qoOIFPJwXRnQTcm5pqdoG_ePHAKsHwLD_dVMSScYpsk=.6bdc5969-6b9d-4429-839c-a2d56e58fdae@github.com>
References: <qoOIFPJwXRnQTcm5pqdoG_ePHAKsHwLD_dVMSScYpsk=.6bdc5969-6b9d-4429-839c-a2d56e58fdae@github.com>
Message-ID: <csfPCMn6nK9zQ1zSm0lGy9nyEKinoHQMqPshxWKqh_Y=.996540ce-3bca-470d-b157-a6ee3dbe6f93@github.com>

On Mon, 26 Apr 2021 11:44:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Please review this trivial change that removes the forward declaration of a nonexistent `NullCheckNode`.
> 
> Thanks,
> Tobias

Thanks, Vladimir!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3691

From thartmann at openjdk.java.net  Tue Apr 27 07:54:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 07:54:39 GMT
Subject: Integrated: 8265967: Unused NullCheckNode forward declaration in
 node.hpp
In-Reply-To: <qoOIFPJwXRnQTcm5pqdoG_ePHAKsHwLD_dVMSScYpsk=.6bdc5969-6b9d-4429-839c-a2d56e58fdae@github.com>
References: <qoOIFPJwXRnQTcm5pqdoG_ePHAKsHwLD_dVMSScYpsk=.6bdc5969-6b9d-4429-839c-a2d56e58fdae@github.com>
Message-ID: <cqatHWeopDTgDz5obTSGGaBTjQTiLcdfDfPXh_vB06A=.897e95ac-7348-433b-a39e-5942c8dafcbf@github.com>

On Mon, 26 Apr 2021 11:44:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Please review this trivial change that removes the forward declaration of a nonexistent `NullCheckNode`.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 82b37195
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/82b37195
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8265967: Unused NullCheckNode forward declaration in node.hpp

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3691

From jiefu at openjdk.java.net  Tue Apr 27 08:34:43 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 27 Apr 2021 08:34:43 GMT
Subject: RFR: 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)
Message-ID: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>

Hi all,

C2 computes -0.0 for Math.pow(-0.0, 0.5) which should be 0.0 according to the API specs.
This bug was found while I was implementing the same optimization for x86_32 (JDK-8265940).

The reason is that CmpDNode [1] doesn't distinguish -0.0 from 0.0.
Math.pow(-0.0, 0.5) was replaced with Math.sqrt(-0.0) incorrectly since CmpDNode says -0.0 < 0.0 if false.

The fix excludes C2's optimization for x=0.0/-0.0. 
And the jtreg test has been improved to make sure the corner cases are covered by the compilers.

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1656

-------------

Commit messages:
 - 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)

Changes: https://git.openjdk.java.net/jdk/pull/3712/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3712&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266028
  Stats: 21 lines in 2 files changed: 9 ins; 11 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3712.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3712/head:pull/3712

PR: https://git.openjdk.java.net/jdk/pull/3712

From thartmann at openjdk.java.net  Tue Apr 27 08:46:05 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 08:46:05 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi [v2]
In-Reply-To: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
Message-ID: <USY63n1Z_hB1Yq9k_X3ff2GvTK6HInFNFWm9OPhEcKs=.cd2359b4-3033-4e7b-8d18-1f2c65b2409d@github.com>

> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
> 
> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
> 
> This issue was reported by John Jiang (johnsjiang at tencent.com).
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Use daemon thread and adjust timeout

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3684/files
  - new: https://git.openjdk.java.net/jdk/pull/3684/files/d0e0e819..a0a170d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3684&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3684&range=00-01

  Stats: 12 lines in 2 files changed: 8 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3684.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3684/head:pull/3684

PR: https://git.openjdk.java.net/jdk/pull/3684

From thartmann at openjdk.java.net  Tue Apr 27 08:46:05 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 08:46:05 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
Message-ID: <IWtd4bFGH89625esaRb7qqKymlijqIr1sc826nGTBYI=.30a64f57-2b0f-43fe-8c59-0040a81625f5@github.com>

On Mon, 26 Apr 2021 06:46:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
> 
> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
> 
> This issue was reported by John Jiang (johnsjiang at tencent.com).
> 
> Thanks,
> Tobias

Thanks for the reviews and suggestions.

@vnkozlov, how did you run the test? The exact same code is also used in `compiler/loopopts/TestStrangeControl.java` and we never had problems with that test not exiting.

@iignatev Thanks, I've updated the test(s) accordingly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From aph at openjdk.java.net  Tue Apr 27 09:09:38 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 27 Apr 2021 09:09:38 GMT
Subject: RFR: 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)
In-Reply-To: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
References: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
Message-ID: <2-UEycI_jEcqxt0lPfufHvIo4mnsBfrbTlpM2xHc7dw=.a0a7b7a2-98fb-4b1d-b5fa-d39a09254ad4@github.com>

On Tue, 27 Apr 2021 08:29:04 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> C2 computes -0.0 for Math.pow(-0.0, 0.5) which should be 0.0 according to the API specs.
> This bug was found while I was implementing the same optimization for x86_32 (JDK-8265940).
> 
> The reason is that CmpDNode [1] doesn't distinguish -0.0 from 0.0.
> Math.pow(-0.0, 0.5) was replaced with Math.sqrt(-0.0) incorrectly since CmpDNode says -0.0 < 0.0 if false.
> 
> The fix excludes C2's optimization for x=0.0/-0.0. 
> And the jtreg test has been improved to make sure the corner cases are covered by the compilers.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1656

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3712

From jiefu at openjdk.java.net  Tue Apr 27 09:13:35 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 27 Apr 2021 09:13:35 GMT
Subject: RFR: 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)
In-Reply-To: <2-UEycI_jEcqxt0lPfufHvIo4mnsBfrbTlpM2xHc7dw=.a0a7b7a2-98fb-4b1d-b5fa-d39a09254ad4@github.com>
References: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
 <2-UEycI_jEcqxt0lPfufHvIo4mnsBfrbTlpM2xHc7dw=.a0a7b7a2-98fb-4b1d-b5fa-d39a09254ad4@github.com>
Message-ID: <reRbpaVmNlHRlT0-fLkFt7zmF2ZH7YJ2IbamBOROZI4=.828c8575-8bc4-4257-9bb5-e05f960fac78@github.com>

On Tue, 27 Apr 2021 09:06:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hi all,
>> 
>> C2 computes -0.0 for Math.pow(-0.0, 0.5) which should be 0.0 according to the API specs.
>> This bug was found while I was implementing the same optimization for x86_32 (JDK-8265940).
>> 
>> The reason is that CmpDNode [1] doesn't distinguish -0.0 from 0.0.
>> Math.pow(-0.0, 0.5) was replaced with Math.sqrt(-0.0) incorrectly since CmpDNode says -0.0 < 0.0 if false.
>> 
>> The fix excludes C2's optimization for x=0.0/-0.0. 
>> And the jtreg test has been improved to make sure the corner cases are covered by the compilers.
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1656
>
> Marked as reviewed by aph (Reviewer).

Thanks @theRealAph for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3712

From thartmann at openjdk.java.net  Tue Apr 27 09:15:43 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 09:15:43 GMT
Subject: RFR: 8252372: Check if cloning is required to move loads out of
 loops in PhaseIdealLoop::split_if_with_blocks_post()
In-Reply-To: <qz3kFumQXyMW3Xt3cjmvCKvMH8QumRapQa8BjETXvRY=.1a778d56-257f-437d-89d5-6e50a160a7d5@github.com>
References: <qz3kFumQXyMW3Xt3cjmvCKvMH8QumRapQa8BjETXvRY=.1a778d56-257f-437d-89d5-6e50a160a7d5@github.com>
Message-ID: <D5tFq1DpXL5_EIS3bIyAsZ4KV_dk1E_nhQWMSmvXR5Y=.6a0caecd-fe1b-47ff-a1b3-1269ddaaa97e@github.com>

On Mon, 26 Apr 2021 09:46:18 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Sinking data nodes out of a loop when all uses are out of a loop has
> several issues that this attempts to fix.
> 
> 1- Only non control uses are considered which makes little sense (why
>   not sink if the data node is an argument to a call or a returned
>   value?)
> 
> 2- Sinking of Loads is broken because of the handling of
>   anti-dependence: the get_late_ctrl(n, n_ctrl) call returns a control
>   in the loop because it takes all uses into account.
> 
> 3- For data nodes for which a control edge can't be set, commoning of
>   clones back in the loop is prevented with:
>   _igvn._worklist.yank(x);
>   which gives no guarantee
> 
> This patch tries to address all issues:
> 
> 1- it looks at all uses, not only non control uses
> 
> 2- anti-dependences are computed for each use independently
> 
> 3- Cast nodes are used to pin clones out of loop
> 
> 
> 2- requires refactoring of the PhaseIdealLoop::get_late_ctrl()
> logic. While working on this, I noticed a bug in anti-dependence
> analysis: when the use is a cfg node, the code sometimes looks at uses
> of the memory state of the cfg. The logic uses the use of the cfg
> which is a projection of adr_type identical to the cfg. It should
> instead look at the use of the memory projection.
> 
> The existing logic for sinking loads calls clear_dom_lca_tags() for
> every load which seems like quite a waste. I added a
> _dom_lca_tags_round variable that's or'ed with the tag_node's _idx. By
> incrementing _dom_lca_tags_round, new tags that don't conflict with
> existing ones are produced and there's no need for
> clear_dom_lca_tags().
> 
> For anti-dependence analysis to return a correct result, early control
> of the load is needed. The only way to get it at this stage, AFAICT,
> is to compute it by following the load's input until a pinned node is
> reached.
> 
> The existing logic pins cloned nodes next to their use. The logic I
> propose pins them right out of the loop. This could possibly avoid
> some redundant clones. It also makes some special handling for corner
> cases with loop strip mining useless.
> 
> For 3-, I added extra Cast nodes for float types. If a chain of data
> nodes are sunk, the new logic tries to keep a single Cast for the
> entire chain rather than one Cast per node.

Hi Roland,

I didn't look at this in detail yet but gave it a quick run through our testing. I'm seeing many of the following failures with the `jdk/incubator/vector/` tests:


assert(cast != __null) failed: must have added a cast to pin the node

Current CompileTask:
C2:  48324 7090    b        ShortMaxVectorTests::getShortMaxVectorTests (1916 bytes)

Stack: [0x00007f13688f8000,0x00007f13689f9000],  sp=0x00007f13689f3250,  free space=1004k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x13293b4]  PhaseIdealLoop::try_sink_out_of_loop(Node*)+0x8d4
V  [libjvm.so+0x132969c]  PhaseIdealLoop::split_if_with_blocks_post(Node*)+0x5c
V  [libjvm.so+0x132a311]  PhaseIdealLoop::split_if_with_blocks(VectorSet&, Node_Stack&)+0x201
V  [libjvm.so+0x131d2ad]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x121d
V  [libjvm.so+0xa4193a]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x2da
V  [libjvm.so+0xa3d1f6]  Compile::Optimize()+0x586
V  [libjvm.so+0xa40946]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x2276
V  [libjvm.so+0x861cfa]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1ea
V  [libjvm.so+0xa50a59]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xfb9
V  [libjvm.so+0xa517c8]  CompileBroker::compiler_thread_loop()+0x5a8
V  [libjvm.so+0x18bc4d1]  JavaThread::thread_main_inner()+0x271
V  [libjvm.so+0x18c3f10]  Thread::call_run()+0x100
V  [libjvm.so+0x159a26e]  thread_native_entry(Thread*)+0x10e


`jdk/incubator/vector/ShortMaxVectorTests.java` with `-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -Xcomp`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3689

From thartmann at openjdk.java.net  Tue Apr 27 09:18:35 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 09:18:35 GMT
Subject: RFR: 8263972: C2: LoadVector/StoreVector type mismatch in
 MemNode::can_see_stored_value()
In-Reply-To: <vk57j-MOSDyC9q6BE69rqM9hz_EEwkOODJ2eCbEDnEo=.4639fa30-8287-4905-88f1-3354bbd4cf3a@github.com>
References: <vk57j-MOSDyC9q6BE69rqM9hz_EEwkOODJ2eCbEDnEo=.4639fa30-8287-4905-88f1-3354bbd4cf3a@github.com>
Message-ID: <y3TBVB2wmXOU6pO1zXFaCogYRMScjibsHneyA135TFE=.bdaa3d12-cc41-4ae9-80f9-20e79fbe57df@github.com>

On Mon, 26 Apr 2021 16:07:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> `MemNode::can_see_stored_value()` doesn't take type info for `LoadVector`/`StoreVector` into account.
> 
> Eliminating `LoadVector`/`StoreVector` pair in presence of a type mismatch leads to a broken graph (omitting vector cast nodes) and sometimes manifest as a broken generated code. 
> 
> The fix adds necessary checks for vector case. 
> 
> Testing:
> - [x] regression test
> - [x] hs-tier1 - hs-tier4

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3698

From neliasso at openjdk.java.net  Tue Apr 27 09:20:38 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 27 Apr 2021 09:20:38 GMT
Subject: RFR: 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)
In-Reply-To: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
References: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
Message-ID: <WB37f3rOEx_DVZcUYjk4sRN8TDJrGTCooQwi2ZJqhvU=.0bb452af-6a62-4c67-a106-69c69a881c81@github.com>

On Tue, 27 Apr 2021 08:29:04 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> C2 computes -0.0 for Math.pow(-0.0, 0.5) which should be 0.0 according to the API specs.
> This bug was found while I was implementing the same optimization for x86_32 (JDK-8265940).
> 
> The reason is that CmpDNode [1] doesn't distinguish -0.0 from 0.0.
> Math.pow(-0.0, 0.5) was replaced with Math.sqrt(-0.0) incorrectly since CmpDNode says -0.0 < 0.0 if false.
> 
> The fix excludes C2's optimization for x=0.0/-0.0. 
> And the jtreg test has been improved to make sure the corner cases are covered by the compilers.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1656

Looks good.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3712

From jiefu at openjdk.java.net  Tue Apr 27 09:28:35 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 27 Apr 2021 09:28:35 GMT
Subject: RFR: 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)
In-Reply-To: <WB37f3rOEx_DVZcUYjk4sRN8TDJrGTCooQwi2ZJqhvU=.0bb452af-6a62-4c67-a106-69c69a881c81@github.com>
References: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
 <WB37f3rOEx_DVZcUYjk4sRN8TDJrGTCooQwi2ZJqhvU=.0bb452af-6a62-4c67-a106-69c69a881c81@github.com>
Message-ID: <4swYlsoeMTkZmD3T6d5V-Gh7pG6VfY7EacDM3zmklHg=.ce4cd0c4-01c2-4af9-aadd-2d3b45520b4a@github.com>

On Tue, 27 Apr 2021 09:18:01 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Looks good.

Thanks @neliasso .

-------------

PR: https://git.openjdk.java.net/jdk/pull/3712

From thartmann at openjdk.java.net  Tue Apr 27 09:32:41 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 09:32:41 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v2]
In-Reply-To: <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>
Message-ID: <HE-PStiZnd9kjjnY9etCaSiR-hhU20OWpA8mnn_FuFU=.13b0e1c3-394a-4bbf-8861-87cb3ed6c4bf@github.com>

On Mon, 26 Apr 2021 06:06:07 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
>> 
>> E.g., for Math.pow(1.0 / 2047, 2.0):
>> 
>> interpreter: 2.38651580386563E-7 
>>          C2: 2.3865158038656307E-7
>> 
>> 
>> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
>> However, there is no such optimization for interpreter/C1 on x86_32.
>> 
>> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
>> And we don't have a plan to implement such opt on x86_32.
>> 
>> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize pow(x, 2.0) for x86_32

src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp line 2546:

> 2544: 
> 2545:   address static_const_table_pow = (address)_static_const_table_pow;
> 2546:   static double DOUBLE2 = 2.0;

Constants in the 64-bit code and `_static_const_table_pow` above use `ATTRIBUTE_ALIGNED`. Should we add that for `DOUBLE2` as well?

src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp line 2555:

> 2553:   movsd(xmm1, Address(rsp, 136));
> 2554: 
> 2555:   // Special case: pow(x, 2.0) => x * x

64-bit code also handles `Special case: pow(x, 0.5) => sqrt(x)`. Don't we need to add that as well for consistency?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From yyang at openjdk.java.net  Tue Apr 27 09:35:36 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 09:35:36 GMT
Subject: RFR: 8265129: Add intrinsic support for JVM.getClassId [v2]
In-Reply-To: <uWwjeNfhY2jYzpsGcE8k41BzIgax6UN8NzlUwB_p-ig=.ccf8e6fd-0a67-4541-98ad-b449bc60065c@github.com>
References: <WRTO3ij4-ef6lLk8NMQWGkmd68vFfqLICYU9nIakgOU=.d10e0f2f-087c-43f9-b08a-86c51919ac44@github.com>
 <uWwjeNfhY2jYzpsGcE8k41BzIgax6UN8NzlUwB_p-ig=.ccf8e6fd-0a67-4541-98ad-b449bc60065c@github.com>
Message-ID: <MquzI7ZqrRqpg8vryDFwE67Zw_436pRjHBRs5MxYzuk=.9c6c4dbc-ecea-408e-9111-f9f3da8a01f8@github.com>

On Fri, 23 Apr 2021 12:37:42 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> 8265129: Add intrinsic support for JVM.getClassId
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add doc

There are some comments rather than a real review that should be done by reviewers.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 3049:

> 3047: 
> 3048: #ifdef JFR_HAVE_INTRINSICS
> 3049: void LIRGenerator::do_ClassIDIntrinsic(Intrinsic* x) {

Is this method really important and hot enough that we need to intrinsify it both in C1 and C2?

src/hotspot/share/c1/c1_LIRGenerator.cpp line 3095:

> 3093: 
> 3094:   LIR_Opr epoch = new_register(T_INT);
> 3095:   LIR_Opr epoch_address = new_register(T_LONG);

new_pointer_register

-------------

PR: https://git.openjdk.java.net/jdk/pull/3470

From yyang at openjdk.java.net  Tue Apr 27 09:40:11 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 09:40:11 GMT
Subject: RFR: 8265711: C1: Canonicalize Class.getModifier intrinsic method
 [v2]
In-Reply-To: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
Message-ID: <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>

> It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.

Yi Yang 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 three additional commits since the last revision:

 - add missing stuff; change according to review comment
 - Merge branch 'master' into canon_opt
 - canonicalize well-chosen intrinsic methods

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3616/files
  - new: https://git.openjdk.java.net/jdk/pull/3616/files/fad55ab0..76f5bfa9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3616&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3616&range=00-01

  Stats: 45304 lines in 1125 files changed: 9465 ins; 32430 del; 3409 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3616/head:pull/3616

PR: https://git.openjdk.java.net/jdk/pull/3616

From yyang at openjdk.java.net  Tue Apr 27 09:40:17 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 09:40:17 GMT
Subject: RFR: 8265711: C1: Canonicalize Class.getModifier intrinsic method
 [v2]
In-Reply-To: <8n1l4xCz8Kn1h6U2K6IwH_0vx-NYzWaUdEBwZ5GFaNc=.16d7e985-30bf-4e26-b240-66405f6c25ee@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <8n1l4xCz8Kn1h6U2K6IwH_0vx-NYzWaUdEBwZ5GFaNc=.16d7e985-30bf-4e26-b240-66405f6c25ee@github.com>
Message-ID: <VKjtEgbOcgM2pILaEH4uA-eWCKugkzrW9JMqOr4dYgs=.9ebabb06-343a-4015-9b51-0550850c8598@github.com>

On Mon, 26 Apr 2021 09:57:59 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Yi Yang 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 three additional commits since the last revision:
>> 
>>  - add missing stuff; change according to review comment
>>  - Merge branch 'master' into canon_opt
>>  - canonicalize well-chosen intrinsic methods
>
> src/hotspot/share/c1/c1_Canonicalizer.cpp line 558:
> 
>> 556:     if (c != NULL && !c->value()->is_null_object()) {
>> 557:       ciType* t = c->value()->java_mirror_type();
>> 558:       if (t->is_klass()) {
> 
> Shouldn't `t->is_primitive_type()` be handled as well?

Done.

Testing:
- hotspot/jtreg/compiler

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From thartmann at openjdk.java.net  Tue Apr 27 09:40:38 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 09:40:38 GMT
Subject: RFR: 8265587: IGV: track nodes across matching
In-Reply-To: <n4rVpa5niUA7uxFGvO49o6MT9TH5pMvwF8Mnpax1Bg0=.3ff29745-d792-4793-98fa-e3ee5c4975ea@github.com>
References: <n4rVpa5niUA7uxFGvO49o6MT9TH5pMvwF8Mnpax1Bg0=.3ff29745-d792-4793-98fa-e3ee5c4975ea@github.com>
Message-ID: <2NlJDBY6mLj9VYZgScYECjAgNDKKQwDID73khKKff1o=.3c2f3631-378e-4ad4-8e3a-2335f8768e09@github.com>

On Fri, 23 Apr 2021 12:31:20 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change preserves, as much as possible, the IGV node identifier of Ideal nodes in their corresponding machine nodes created by `Matcher::match()`. This makes it possible to track nodes when stepping from "Before matching" to "After matching" in IGV, as illustrated for an extracted compare-and-branch subgraph in the following screenshot: 
> 
> ![before-after-matching](https://user-images.githubusercontent.com/8792647/115867587-94b75280-a43b-11eb-8a79-9c13a0a68d42.png)
> 
> #### Limitations
> This solution preserves most of the node relations across matching, however if an Ideal node is expanded into multiple machine nodes, only one of them is assigned the IGV identifier of the Ideal node (since IGV identifiers need to be unique within a compilation phase). This limitation can be seen in the following example, where the `CmpU` Ideal node is implemented with three `compU_rReg` machine nodes (one for each `jmpConU` machine node), but only one of the `compU_rReg` machine nodes (50) preserves the IGV identifier:
> 
> ![before-after-matching-limitation](https://user-images.githubusercontent.com/8792647/115869469-3770d080-a43e-11eb-9ede-d8845862c7bd.png)
> 
> Overcoming this limitation would require explicitly serializing the entire before-after relation among nodes and adapting IGV's node selection and graph difference logic, which seems too complex for a relatively infrequent case.
> 
> #### Testing
> - Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
> - Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
> - Tested manually, for a few graphs, that nodes of different types can be tracked across matching.

That's a nice enhancement, looks good to me!

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3654

From yyang at openjdk.java.net  Tue Apr 27 09:50:45 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 09:50:45 GMT
Subject: RFR: 8265914: Duplicated NotANode and not_a_node
Message-ID: <dvP9EfHE9BMy_-1HPlxV90ysNSACwQsQWH00XVhM2Zk=.c5e3e011-38f9-40d8-a47f-5052ac751604@github.com>

NotANode(node.hpp) and not_a_node(compile.cpp) are completely repeated guys.

-------------

Commit messages:
 - not_a_node

Changes: https://git.openjdk.java.net/jdk/pull/3715/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3715&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265914
  Stats: 36 lines in 5 files changed: 0 ins; 14 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3715.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3715/head:pull/3715

PR: https://git.openjdk.java.net/jdk/pull/3715

From thartmann at openjdk.java.net  Tue Apr 27 10:01:41 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 10:01:41 GMT
Subject: RFR: 8265711: C1: Canonicalize Class.getModifier intrinsic method
 [v2]
In-Reply-To: <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
Message-ID: <FSaF-XhI8oLTdVwMQ3TBAjydTVdKLqDeOp8K2jLlsIQ=.ef9d0be5-54af-46fe-8e32-b7a74e74fdda@github.com>

On Tue, 27 Apr 2021 09:40:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.
>
> Yi Yang 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 three additional commits since the last revision:
> 
>  - add missing stuff; change according to review comment
>  - Merge branch 'master' into canon_opt
>  - canonicalize well-chosen intrinsic methods

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1333:

> 1331:   // Checking if it's a java mirror of primitive type
> 1332:   __ move(new LIR_Address(receiver.result(), java_lang_Class::klass_offset(), T_ADDRESS), temp, info);
> 1333:   __ cmp(lir_cond_notEqual, temp, LIR_OprFact::metadataConst(0));

The previous version of your patch was missing the check for a primitive type. Why did testing not catch this?

Also, your PR title is misleading. You are not simply canonicalizing `Class.getModifier.` You are intrinsifying it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From rcastanedalo at openjdk.java.net  Tue Apr 27 10:04:34 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 27 Apr 2021 10:04:34 GMT
Subject: RFR: 8265587: IGV: track nodes across matching
In-Reply-To: <2NlJDBY6mLj9VYZgScYECjAgNDKKQwDID73khKKff1o=.3c2f3631-378e-4ad4-8e3a-2335f8768e09@github.com>
References: <n4rVpa5niUA7uxFGvO49o6MT9TH5pMvwF8Mnpax1Bg0=.3ff29745-d792-4793-98fa-e3ee5c4975ea@github.com>
 <2NlJDBY6mLj9VYZgScYECjAgNDKKQwDID73khKKff1o=.3c2f3631-378e-4ad4-8e3a-2335f8768e09@github.com>
Message-ID: <he5dQ3qJCF9kKmIPOc4LAtKLgXTqfT_efcXGNR_YZ3s=.354e5f93-db3a-486b-93f0-f53425e59556@github.com>

On Tue, 27 Apr 2021 09:37:29 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> That's a nice enhancement, looks good to me!

Thanks for reviewing, Tobias!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3654

From roland at openjdk.java.net  Tue Apr 27 10:22:44 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 27 Apr 2021 10:22:44 GMT
Subject: RFR: 8259609: C2: optimize long range checks in long counted
 loops [v4]
In-Reply-To: <SXAvq1BxF-hO_8cR_Xo8wrkwgC6gnETzEmnl-bcYW1U=.dbf6034c-e3a7-47ea-9e38-3446eb40b1a8@github.com>
References: <J0Kj7AiqCi5l8cNV1YRmcPu005hmLgeCbBCurQ2hwHc=.aaec0d99-c0f0-4b6a-b492-d08c07b46806@github.com>
 <SXAvq1BxF-hO_8cR_Xo8wrkwgC6gnETzEmnl-bcYW1U=.dbf6034c-e3a7-47ea-9e38-3446eb40b1a8@github.com>
Message-ID: <E7ht8Rb47XokLpBGHToylzCQdMTKA3zlRowebdxRZKU=.92df5a48-8b16-4bb4-b2d4-17327e2b58c5@github.com>

On Wed, 27 Jan 2021 08:36:11 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> JDK-8255150 makes it possible for java code to explicitly perform a
>> range check on long values. JDK-8223051 provides a transformation of
>> long counted loops into loop nests with an inner int counted
>> loop. With this change I propose transforming long range checks that
>> operate on the iv of a long counted loop into range checks that
>> operate on the iv of the int inner loop once it has been
>> created. Existing range check eliminations can then kick in.
>> 
>> Transformation of range checks is piggy backed on the loop nest
>> creation for 2 reasons:
>> 
>> - pattern matching range checks is easier right before the loop nest
>>   is created
>> 
>> - the number of iterations of the inner loop is adjusted so scale *
>>   inner_iv doesn't overflow
>> 
>> C2 has logic to delay some split if transformations so they don't
>> break the scale * iv + offset pattern. I reused that logic for long
>> range checks and had to relax what's considered a range check because
>> initially a range check from Object.checkIndex() may include a test
>> for range > 0 that needs a round of loop opts to be hoisted. 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 realize the comment in PhaseIdealLoop::transform_long_range_checks()
>> is scary. FWIW, it's not as complicated as it looks. I found drawing
>> the range covered by the entire long loop and the range covered by the
>> inner loop help see how range checks can be transformed. Then the
>> comment helps make sure all cases are covered and verify the generated
>> code actually covers all of them.
>> 
>> One issue is overflow. I think the fact that inner_iv * scale doesn't
>> overflow helps simplify thing. One possible overflow is that of scale
>> * upper + offset which is handled by forcing all range checks in that
>> case to deoptimize. I don't think other case of overflow needs special
>> handling.
>> 
>> This was tested with a Memory Segment micro benchmark (and patched
>> Memory Segment support to take advantage of the new checkIndex
>> intrinsic, both provided by Maurizio). Range checks in the micro
>> benchmark are properly optimized (and performance increases
>> significantly).
>
> 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 ten additional commits since the last revision:
> 
>  - Tobias' comments
>  - Merge branch 'master' into JDK-8259609
>  - min_jint overflow fix
>  - Revert "assert(static_cast<T1>(result) == thing) fix"
>    
>    This reverts commit e234477df097475d503ea6f94ab6a258132d165e.
>  - Merge branch 'master' into JDK-8259609
>  - assert(static_cast<T1>(result) == thing) fix
>  - whitespaces
>  - build fix + test cleanup
>  - range checks

comment to keep the PR open

-------------

PR: https://git.openjdk.java.net/jdk/pull/2045

From yyang at openjdk.java.net  Tue Apr 27 10:43:40 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 10:43:40 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]
In-Reply-To: <INEybUvTQ7rfHo7vuktcKG_BvJN16OOJelpVlvaI9us=.195af3d6-48eb-42b6-abb5-f345d9a587ed@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
 <FSaF-XhI8oLTdVwMQ3TBAjydTVdKLqDeOp8K2jLlsIQ=.ef9d0be5-54af-46fe-8e32-b7a74e74fdda@github.com>
 <INEybUvTQ7rfHo7vuktcKG_BvJN16OOJelpVlvaI9us=.195af3d6-48eb-42b6-abb5-f345d9a587ed@github.com>
Message-ID: <dduAJ9xSTeDNN16Mg_SnbPetJgJZn328s1tfqDphdco=.48f33398-ce8d-446d-8fd5-1c0d2ee05e80@github.com>

On Tue, 27 Apr 2021 10:38:24 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> src/hotspot/share/c1/c1_LIRGenerator.cpp line 1333:
>> 
>>> 1331:   // Checking if it's a java mirror of primitive type
>>> 1332:   __ move(new LIR_Address(receiver.result(), java_lang_Class::klass_offset(), T_ADDRESS), temp, info);
>>> 1333:   __ cmp(lir_cond_notEqual, temp, LIR_OprFact::metadataConst(0));
>> 
>> The previous version of your patch was missing the check for a primitive type. Why did testing not catch this?
>> 
>> Also, your PR title is misleading. You are not simply canonicalizing `Class.getModifier.` You are intrinsifying it.
>
> Because is_intrinsic_support is not aware of the fact that getModifiers is an intrinsic method. So canonicalizer is even not applied.
> 
>> Also, your PR title is misleading. You are not simply canonicalizing Class.getModifier. You are intrinsifying it.
> 
> Yes, exactly. Changed.

With the new IR test framework, these kinds of problem would never happen, we can do verification at IR level.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From yyang at openjdk.java.net  Tue Apr 27 10:43:39 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 10:43:39 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]
In-Reply-To: <FSaF-XhI8oLTdVwMQ3TBAjydTVdKLqDeOp8K2jLlsIQ=.ef9d0be5-54af-46fe-8e32-b7a74e74fdda@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
 <FSaF-XhI8oLTdVwMQ3TBAjydTVdKLqDeOp8K2jLlsIQ=.ef9d0be5-54af-46fe-8e32-b7a74e74fdda@github.com>
Message-ID: <INEybUvTQ7rfHo7vuktcKG_BvJN16OOJelpVlvaI9us=.195af3d6-48eb-42b6-abb5-f345d9a587ed@github.com>

On Tue, 27 Apr 2021 09:58:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Yi Yang 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 three additional commits since the last revision:
>> 
>>  - add missing stuff; change according to review comment
>>  - Merge branch 'master' into canon_opt
>>  - canonicalize well-chosen intrinsic methods
>
> src/hotspot/share/c1/c1_LIRGenerator.cpp line 1333:
> 
>> 1331:   // Checking if it's a java mirror of primitive type
>> 1332:   __ move(new LIR_Address(receiver.result(), java_lang_Class::klass_offset(), T_ADDRESS), temp, info);
>> 1333:   __ cmp(lir_cond_notEqual, temp, LIR_OprFact::metadataConst(0));
> 
> The previous version of your patch was missing the check for a primitive type. Why did testing not catch this?
> 
> Also, your PR title is misleading. You are not simply canonicalizing `Class.getModifier.` You are intrinsifying it.

Because is_intrinsic_support is not aware of the fact that getModifiers is an intrinsic method. So canonicalizer is even not applied.

> Also, your PR title is misleading. You are not simply canonicalizing Class.getModifier. You are intrinsifying it.

Yes, exactly. Changed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From jiefu at openjdk.java.net  Tue Apr 27 11:09:05 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 27 Apr 2021 11:09:05 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v3]
In-Reply-To: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
Message-ID: <aMkSkY_c1V94fMIzmMQtGYcUn3SHC2uzaDH5bs-ihdU=.509aed47-25ba-4c11-a642-06a524fdca21@github.com>

> Hi all,
> 
> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
> 
> E.g., for Math.pow(1.0 / 2047, 2.0):
> 
> interpreter: 2.38651580386563E-7 
>          C2: 2.3865158038656307E-7
> 
> 
> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
> However, there is no such optimization for interpreter/C1 on x86_32.
> 
> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
> And we don't have a plan to implement such opt on x86_32.
> 
> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Add align attribute for 2.0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3677/files
  - new: https://git.openjdk.java.net/jdk/pull/3677/files/dde59758..9c4283ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3677&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3677&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3677.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3677/head:pull/3677

PR: https://git.openjdk.java.net/jdk/pull/3677

From jiefu at openjdk.java.net  Tue Apr 27 11:09:06 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 27 Apr 2021 11:09:06 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v2]
In-Reply-To: <HE-PStiZnd9kjjnY9etCaSiR-hhU20OWpA8mnn_FuFU=.13b0e1c3-394a-4bbf-8861-87cb3ed6c4bf@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>
 <HE-PStiZnd9kjjnY9etCaSiR-hhU20OWpA8mnn_FuFU=.13b0e1c3-394a-4bbf-8861-87cb3ed6c4bf@github.com>
Message-ID: <AsTcCfABfLNM4pfGkm1AHLP6xqaVf5VW4Y2hf_yRAGY=.3f884faf-c20a-48e5-a3f9-85aa6754c514@github.com>

On Tue, 27 Apr 2021 09:28:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimize pow(x, 2.0) for x86_32
>
> src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp line 2546:
> 
>> 2544: 
>> 2545:   address static_const_table_pow = (address)_static_const_table_pow;
>> 2546:   static double DOUBLE2 = 2.0;
> 
> Constants in the 64-bit code and `_static_const_table_pow` above use `ATTRIBUTE_ALIGNED`. Should we add that for `DOUBLE2` as well?

Hi @TobiHartmann ,

Thanks for your review.

Yes, it seem better to be with ATTRIBUTE_ALIGNED.
Updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From jiefu at openjdk.java.net  Tue Apr 27 11:12:39 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 27 Apr 2021 11:12:39 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v2]
In-Reply-To: <HE-PStiZnd9kjjnY9etCaSiR-hhU20OWpA8mnn_FuFU=.13b0e1c3-394a-4bbf-8861-87cb3ed6c4bf@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <7lt6NMcDayVX_jf5yL3k1D5aRr8eeYTIBpJnGmcGxdY=.4c70c46d-6ce9-4885-b0f8-937ad0830784@github.com>
 <HE-PStiZnd9kjjnY9etCaSiR-hhU20OWpA8mnn_FuFU=.13b0e1c3-394a-4bbf-8861-87cb3ed6c4bf@github.com>
Message-ID: <PuBAuX2EmuzMyNVckl_VlqFIIm4ggXwvZOCn2Z2wUIE=.8dd96119-54c8-42fe-9294-e89bd0701c04@github.com>

On Tue, 27 Apr 2021 09:29:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> 64-bit code also handles `Special case: pow(x, 0.5) => sqrt(x)`. Don't we need to add that as well for consistency?

This is the bug fix for C2's optimization of pow(x, 2.0).

pow(x, 0.5) will be handled in JDK-8265940 .
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From thartmann at openjdk.java.net  Tue Apr 27 12:24:37 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 12:24:37 GMT
Subject: RFR: 8265914: Duplicated NotANode and not_a_node
In-Reply-To: <dvP9EfHE9BMy_-1HPlxV90ysNSACwQsQWH00XVhM2Zk=.c5e3e011-38f9-40d8-a47f-5052ac751604@github.com>
References: <dvP9EfHE9BMy_-1HPlxV90ysNSACwQsQWH00XVhM2Zk=.c5e3e011-38f9-40d8-a47f-5052ac751604@github.com>
Message-ID: <d1Y4h8uh9u41rFjipc-2Xjf_54pv2Kia2Egyn_3kfPQ=.035cde82-2994-430e-bbdc-ad5d513e1ad8@github.com>

On Tue, 27 Apr 2021 09:42:39 GMT, Yi Yang <yyang at openjdk.org> wrote:

> NotANode(node.hpp) and not_a_node(compile.cpp) are completely repeated guys.

Looks good and trivial to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3715

From thartmann at openjdk.java.net  Tue Apr 27 12:26:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 12:26:39 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v3]
In-Reply-To: <aMkSkY_c1V94fMIzmMQtGYcUn3SHC2uzaDH5bs-ihdU=.509aed47-25ba-4c11-a642-06a524fdca21@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <aMkSkY_c1V94fMIzmMQtGYcUn3SHC2uzaDH5bs-ihdU=.509aed47-25ba-4c11-a642-06a524fdca21@github.com>
Message-ID: <f1xbNj7re8eD0W2am0p8I7rBjlUhKj8BW9dPSrRR7aI=.e87767a4-4cd8-4917-b4a4-99395b55fbce@github.com>

On Tue, 27 Apr 2021 11:09:05 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
>> 
>> E.g., for Math.pow(1.0 / 2047, 2.0):
>> 
>> interpreter: 2.38651580386563E-7 
>>          C2: 2.3865158038656307E-7
>> 
>> 
>> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
>> However, there is no such optimization for interpreter/C1 on x86_32.
>> 
>> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
>> And we don't have a plan to implement such opt on x86_32.
>> 
>> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add align attribute for 2.0

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3677

From yyang at openjdk.java.net  Tue Apr 27 12:54:34 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 12:54:34 GMT
Subject: RFR: 8265914: Duplicated NotANode and not_a_node
In-Reply-To: <dvP9EfHE9BMy_-1HPlxV90ysNSACwQsQWH00XVhM2Zk=.c5e3e011-38f9-40d8-a47f-5052ac751604@github.com>
References: <dvP9EfHE9BMy_-1HPlxV90ysNSACwQsQWH00XVhM2Zk=.c5e3e011-38f9-40d8-a47f-5052ac751604@github.com>
Message-ID: <lfWlFHMS-vVIxk4DJAbPg1f74PFaLiU5V1tM39tETiE=.8c0b4c13-0f2b-454c-9cb6-6943df35090e@github.com>

On Tue, 27 Apr 2021 09:42:39 GMT, Yi Yang <yyang at openjdk.org> wrote:

> NotANode(node.hpp) and not_a_node(compile.cpp) are completely repeated guys.

Thank you Tobias! Trivial indeed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3715

From thartmann at openjdk.java.net  Tue Apr 27 12:55:49 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 12:55:49 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]
In-Reply-To: <dduAJ9xSTeDNN16Mg_SnbPetJgJZn328s1tfqDphdco=.48f33398-ce8d-446d-8fd5-1c0d2ee05e80@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
 <FSaF-XhI8oLTdVwMQ3TBAjydTVdKLqDeOp8K2jLlsIQ=.ef9d0be5-54af-46fe-8e32-b7a74e74fdda@github.com>
 <INEybUvTQ7rfHo7vuktcKG_BvJN16OOJelpVlvaI9us=.195af3d6-48eb-42b6-abb5-f345d9a587ed@github.com>
 <dduAJ9xSTeDNN16Mg_SnbPetJgJZn328s1tfqDphdco=.48f33398-ce8d-446d-8fd5-1c0d2ee05e80@github.com>
Message-ID: <BrjZRRTywdRkBkSLpGgZhrZ9Z2sK-ovieKjuRTRV2sA=.0f354935-4a58-4b5f-a851-7739666f9f0a@github.com>

On Tue, 27 Apr 2021 10:40:38 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Because is_intrinsic_support is not aware of the fact that getModifiers is an intrinsic method. So canonicalizer is even not applied.
>> 
>>> Also, your PR title is misleading. You are not simply canonicalizing Class.getModifier. You are intrinsifying it.
>> 
>> Yes, exactly. Changed.
>
> With the new IR test framework, these kinds of problem would never happen, we can do verification at IR level.

> Because is_intrinsic_support is not aware of the fact that getModifiers is an intrinsic method. So canonicalizer is even not applied.

But your first version (https://github.com/openjdk/jdk/pull/3616/commits/7f0be4e8a2cb4f6a9ef650b1b31c16f46716a257) already had the change to `is_intrinsic_supported`? Shouldn't that version have triggered test failures because it does not handle primitive types?

> With the new IR test framework, these kinds of problem would never happen, we can do verification at IR level.

Unfortunately not. The IR test framework currently only supports C2.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From yyang at openjdk.java.net  Tue Apr 27 12:59:57 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 12:59:57 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]
In-Reply-To: <BrjZRRTywdRkBkSLpGgZhrZ9Z2sK-ovieKjuRTRV2sA=.0f354935-4a58-4b5f-a851-7739666f9f0a@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
 <FSaF-XhI8oLTdVwMQ3TBAjydTVdKLqDeOp8K2jLlsIQ=.ef9d0be5-54af-46fe-8e32-b7a74e74fdda@github.com>
 <INEybUvTQ7rfHo7vuktcKG_BvJN16OOJelpVlvaI9us=.195af3d6-48eb-42b6-abb5-f345d9a587ed@github.com>
 <dduAJ9xSTeDNN16Mg_SnbPetJgJZn328s1tfqDphdco=.48f33398-ce8d-446d-8fd5-1c0d2ee05e80@github.com>
 <BrjZRRTywdRkBkSLpGgZhrZ9Z2sK-ovieKjuRTRV2sA=.0f354935-4a58-4b5f-a851-7739666f9f0a@github.com>
Message-ID: <o93_B1yB1daO2qIY3SPdlEA7qPVVr0JHNMlILjt7Bnk=.009539b2-b40b-4791-a13a-da05771717b8@github.com>

On Tue, 27 Apr 2021 12:52:56 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> With the new IR test framework, these kinds of problem would never happen, we can do verification at IR level.
>
>> Because is_intrinsic_support is not aware of the fact that getModifiers is an intrinsic method. So canonicalizer is even not applied.
> 
> But your first version (https://github.com/openjdk/jdk/pull/3616/commits/7f0be4e8a2cb4f6a9ef650b1b31c16f46716a257) already had the change to `is_intrinsic_supported`? Shouldn't that version have triggered test failures because it does not handle primitive types?
> 
>> With the new IR test framework, these kinds of problem would never happen, we can do verification at IR level.
> 
> Unfortunately not. The IR test framework currently only supports C2.

> But your first version (7f0be4e) already had the change to is_intrinsic_supported? Shouldn't that version have triggered test failures because it does not handle primitive types?

The first version only changes Canonicalizer::do_Intrinsic :_

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From yyang at openjdk.java.net  Tue Apr 27 13:03:38 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 13:03:38 GMT
Subject: Integrated: 8265914: Duplicated NotANode and not_a_node
In-Reply-To: <dvP9EfHE9BMy_-1HPlxV90ysNSACwQsQWH00XVhM2Zk=.c5e3e011-38f9-40d8-a47f-5052ac751604@github.com>
References: <dvP9EfHE9BMy_-1HPlxV90ysNSACwQsQWH00XVhM2Zk=.c5e3e011-38f9-40d8-a47f-5052ac751604@github.com>
Message-ID: <aEkS7AOyo0smm4pqLIjBqDiXiqaa0sMjd8Ugy-Ebjfo=.4215c8b0-62ac-4d9e-88e6-a93b06da26af@github.com>

On Tue, 27 Apr 2021 09:42:39 GMT, Yi Yang <yyang at openjdk.org> wrote:

> NotANode(node.hpp) and not_a_node(compile.cpp) are completely repeated guys.

This pull request has now been integrated.

Changeset: fbfd4ea3
Author:    Yi Yang <yyang at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fbfd4ea3
Stats:     36 lines in 5 files changed: 0 ins; 14 del; 22 mod

8265914: Duplicated NotANode and not_a_node

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3715

From roland at openjdk.java.net  Tue Apr 27 13:06:35 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 27 Apr 2021 13:06:35 GMT
Subject: RFR: 8252372: Check if cloning is required to move loads out of
 loops in PhaseIdealLoop::split_if_with_blocks_post()
In-Reply-To: <D5tFq1DpXL5_EIS3bIyAsZ4KV_dk1E_nhQWMSmvXR5Y=.6a0caecd-fe1b-47ff-a1b3-1269ddaaa97e@github.com>
References: <qz3kFumQXyMW3Xt3cjmvCKvMH8QumRapQa8BjETXvRY=.1a778d56-257f-437d-89d5-6e50a160a7d5@github.com>
 <D5tFq1DpXL5_EIS3bIyAsZ4KV_dk1E_nhQWMSmvXR5Y=.6a0caecd-fe1b-47ff-a1b3-1269ddaaa97e@github.com>
Message-ID: <7OlbNRI3CRiA0djTy6noB0xuQAS73O0ArQ8c7Lgwczs=.9acf4e3e-d5a6-4def-bc55-8730df916dd8@github.com>

On Tue, 27 Apr 2021 09:13:04 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I didn't look at this in detail yet but gave it a quick run through our testing. I'm seeing many of the following failures with the `jdk/incubator/vector/` tests:

Thanks for running the tests. I will work on the failures.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3689

From thartmann at openjdk.java.net  Tue Apr 27 13:09:37 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 13:09:37 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]
In-Reply-To: <o93_B1yB1daO2qIY3SPdlEA7qPVVr0JHNMlILjt7Bnk=.009539b2-b40b-4791-a13a-da05771717b8@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
 <FSaF-XhI8oLTdVwMQ3TBAjydTVdKLqDeOp8K2jLlsIQ=.ef9d0be5-54af-46fe-8e32-b7a74e74fdda@github.com>
 <INEybUvTQ7rfHo7vuktcKG_BvJN16OOJelpVlvaI9us=.195af3d6-48eb-42b6-abb5-f345d9a587ed@github.com>
 <dduAJ9xSTeDNN16Mg_SnbPetJgJZn328s1tfqDphdco=.48f33398-ce8d-446d-8fd5-1c0d2ee05e80@github.com>
 <BrjZRRTywdRkBkSLpGgZhrZ9Z2sK-ovieKjuRTRV2sA=.0f354935-4a58-4b5f-a851-7739666f9f0a@github.com>
 <o93_B1yB1daO2qIY3SPdlEA7qPVVr0JHNMlILjt7Bnk=.009539b2-b40b-4791-a13a-da05771717b8@github.com>
Message-ID: <YUVH1DiyAEvcUP-spGjVgVNRZ6JRP_rNSJELpX0-qNI=.6a6cedb2-0f5d-4cf3-9f8e-319ab5be7074@github.com>

On Tue, 27 Apr 2021 12:56:25 GMT, Yi Yang <yyang at openjdk.org> wrote:

>>> Because is_intrinsic_support is not aware of the fact that getModifiers is an intrinsic method. So canonicalizer is even not applied.
>> 
>> But your first version (https://github.com/openjdk/jdk/pull/3616/commits/7f0be4e8a2cb4f6a9ef650b1b31c16f46716a257) already had the change to `is_intrinsic_supported`? Shouldn't that version have triggered test failures because it does not handle primitive types?
>> 
>>> With the new IR test framework, these kinds of problem would never happen, we can do verification at IR level.
>> 
>> Unfortunately not. The IR test framework currently only supports C2.
>
>> But your first version (7f0be4e) already had the change to is_intrinsic_supported? Shouldn't that version have triggered test failures because it does not handle primitive types?
> 
> The first version only changes Canonicalizer::do_Intrinsic :_

Okay, maybe the force-push screwed up some of the history here, you should try to avoid that (it also makes it much harder to review changes incrementally).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From thartmann at openjdk.java.net  Tue Apr 27 13:31:40 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 13:31:40 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]
In-Reply-To: <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
Message-ID: <pZNZCfeQNBk2wKOG9wOSDppeOklvlmrxA1on3bvQuJw=.7ef82df7-b79b-428e-9c1b-0f0f8a1be7ea@github.com>

On Tue, 27 Apr 2021 09:40:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.
>
> Yi Yang 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 three additional commits since the last revision:
> 
>  - add missing stuff; change according to review comment
>  - Merge branch 'master' into canon_opt
>  - canonicalize well-chosen intrinsic methods

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1330:

> 1328:   LabelObj* L_done = new LabelObj();
> 1329: 
> 1330:   LIR_Opr temp = new_register(T_METADATA);

`temp` could be renamed to `klass`.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1339:

> 1337: 
> 1338:   __ branch_destination(L_not_prim->label());
> 1339:   __ move(new LIR_Address(receiver.result(), java_lang_Class::klass_offset(), T_ADDRESS), temp, NULL);

Why are you reloading the klass here?

Also, as @rwestrel explained in the RFR for [8211231](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030745.html), we need to be really careful when emitting branches in C1's LIR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From yyang at openjdk.java.net  Tue Apr 27 13:31:41 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 27 Apr 2021 13:31:41 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]
In-Reply-To: <YUVH1DiyAEvcUP-spGjVgVNRZ6JRP_rNSJELpX0-qNI=.6a6cedb2-0f5d-4cf3-9f8e-319ab5be7074@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
 <FSaF-XhI8oLTdVwMQ3TBAjydTVdKLqDeOp8K2jLlsIQ=.ef9d0be5-54af-46fe-8e32-b7a74e74fdda@github.com>
 <INEybUvTQ7rfHo7vuktcKG_BvJN16OOJelpVlvaI9us=.195af3d6-48eb-42b6-abb5-f345d9a587ed@github.com>
 <dduAJ9xSTeDNN16Mg_SnbPetJgJZn328s1tfqDphdco=.48f33398-ce8d-446d-8fd5-1c0d2ee05e80@github.com>
 <BrjZRRTywdRkBkSLpGgZhrZ9Z2sK-ovieKjuRTRV2sA=.0f354935-4a58-4b5f-a851-7739666f9f0a@github.com>
 <o93_B1yB1daO2qIY3SPdlEA7qPVVr0JHNMlILjt7Bnk=.009539b2-b40b-4791-a13a-da05771717b8@github.com>
 <YUVH1DiyAEvcUP-spGjVgVNRZ6JRP_rNSJELpX0-qNI=.6a6cedb2-0f5d-4cf3-9f8e-319ab5be7074@github.com>
Message-ID: <bQhi8NJT2-husRmfCy85ejxwZwdDcUd7qFAtFk6T5CA=.42162cf5-b7fc-4e1a-bd61-52c8bc9b6417@github.com>

On Tue, 27 Apr 2021 13:07:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Okay, maybe the force-push screwed up some of the history here, you should try to avoid that (it also makes it much harder to review changes incrementally).

Got it! (The reason why I forcibly push is that I can not push them normally after merging some commits from master branch.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From thartmann at openjdk.java.net  Tue Apr 27 13:37:34 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 13:37:34 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]
In-Reply-To: <bQhi8NJT2-husRmfCy85ejxwZwdDcUd7qFAtFk6T5CA=.42162cf5-b7fc-4e1a-bd61-52c8bc9b6417@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
 <FSaF-XhI8oLTdVwMQ3TBAjydTVdKLqDeOp8K2jLlsIQ=.ef9d0be5-54af-46fe-8e32-b7a74e74fdda@github.com>
 <INEybUvTQ7rfHo7vuktcKG_BvJN16OOJelpVlvaI9us=.195af3d6-48eb-42b6-abb5-f345d9a587ed@github.com>
 <dduAJ9xSTeDNN16Mg_SnbPetJgJZn328s1tfqDphdco=.48f33398-ce8d-446d-8fd5-1c0d2ee05e80@github.com>
 <BrjZRRTywdRkBkSLpGgZhrZ9Z2sK-ovieKjuRTRV2sA=.0f354935-4a58-4b5f-a851-7739666f9f0a@github.com>
 <o93_B1yB1daO2qIY3SPdlEA7qPVVr0JHNMlILjt7Bnk=.009539b2-b40b-4791-a13a-da05771717b8@github.com>
 <YUVH1DiyAEvcUP-spGjVgVNRZ6JRP_rNSJELpX0-qNI=.6a6cedb2-0f5d-4cf3-9f8e-319ab5be7074@github.com>
 <bQhi8NJT2-husRmfCy85ejxwZwdDcUd7qFAtFk6T5CA=.42162cf5-b7fc-4e1a-bd61-52c8bc9b6417@github.com>
Message-ID: <KRWhRUfd-xV3T0-LtcBCDmTVRCw8jCMNAXLY1FMOD30=.8151c5bc-d176-47cf-98b8-e969a304bf5a@github.com>

On Tue, 27 Apr 2021 13:25:43 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Okay, maybe the force-push screwed up some of the history here, you should try to avoid that (it also makes it much harder to review changes incrementally).
>
>> Okay, maybe the force-push screwed up some of the history here, you should try to avoid that (it also makes it much harder to review changes incrementally).
> 
> Got it! (The reason why I forcibly push is that I can not push them normally after merging some commits from master branch.)

Even when merging changes from master into your branch, a force-push should not be required. Here's a related discussion:
https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/046538.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From chagedorn at openjdk.java.net  Tue Apr 27 15:25:42 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 27 Apr 2021 15:25:42 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v6]
In-Reply-To: <NfQVyJmkahrCDcv6z8uWeTD-Vjw1KEmcVIgI4X2d3-g=.07970959-6917-4689-bcc6-6d3e48a2010f@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <bx37BlKEGAGguvVKHvGFpNX05eFU27sng_RHmV_6ASg=.6b1a194f-f6e7-4bb0-a6ca-21dd79b16a52@github.com>
 <NfQVyJmkahrCDcv6z8uWeTD-Vjw1KEmcVIgI4X2d3-g=.07970959-6917-4689-bcc6-6d3e48a2010f@github.com>
Message-ID: <Gz3d75wHaCAvsAaGJVA0Q3Uk6fv909IB1jnDup2otPU=.30d4ad5e-94f4-489a-9618-70af13d94989@github.com>

On Mon, 26 Apr 2021 18:09:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup
>
> test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 65:
> 
>> 63:      *  Compilation level 1: C1 compilation without any profile information.
>> 64:      */
>> 65:     C1(1),
> 
> this name might be misleading, as one can assume that it means all C1 levels, `C1_SIMPLE`?

I initially had `C1_SIMPLE` but then replaced it with `C1` as `@DontCompile` can only exclude a compilation for a compiler and not a specific level. However, while thinking about it, it might be better to not share `C1/C1_SIMPLE` but use a separate annotation for `@DontCompile`. I added a new `Compiler` annotation class and updated the usages and checks.

> test/lib/jdk/test/lib/hotspot/ir_framework/DontCompile.java line 39:
> 
>> 37:  *     <li><p>The usage of any other compilation level is forbidden and results in a
>> 38:  *            {@link TestFormatException TestFormatException}.</li>
>> 39:  * </ul>
> 
> this actually suggests that we shouldn't use `CompLevel` here and need to introduce another enum to denote compilers.

I was thinking about the same thing while processing an earlier review comment above :) So, it indeed makes sense to use a separate enum for it.

> test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 39:
> 
>> 37: class IRMatcher {
>> 38:     private static final boolean PRINT_IR_ENCODING = Boolean.parseBoolean(System.getProperty("PrintIREncoding", "false"));
>> 39:     private static final Pattern irEncodingPattern =
> 
> we typically use UPPER_CAMEL_CASE for constants such as `irEncodingPattern`

I updated this and other inconsistencies in the naming of `static final` variables.

> test/lib/jdk/test/lib/hotspot/ir_framework/Scenario.java line 55:
> 
>> 53:     static {
>> 54:         if (!SCENARIOS_PROPERTY.isEmpty()) {
>> 55:             System.out.println(Arrays.toString(SCENARIOS_PROPERTY.split("\\s*,\\s*")));
> 
> did you mean to print it here or was it just a leftover from a debugging session?

Good catch. It was a leftover.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 135:
> 
>> 133:                                         - To only run the failed tests use -DTest, -DExclude,
>> 134:                                           and/or -DScenarios.
>> 135:                                         - To also get the standard output of the test VM run with\s
> 
> why do you need `\s` here?

I needed this because `jcheck` complained about trailing whitespaces. Maybe this needs to be addressed at some point in `jcheck`.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 146:
> 
>> 144:     private static final boolean REPORT_STDOUT = Boolean.getBoolean("ReportStdout");
>> 145:     private final boolean VERIFY_VM = Boolean.getBoolean("VerifyVM") && Platform.isDebugBuild();
>> 146:     private boolean VERIFY_IR = Boolean.parseBoolean(System.getProperty("VerifyIR", "true"));
> 
> it seems both these guys were meant to be `static final`

`VERIFY_VM` should be yes. But `VERIFY_IR` is only initialized and later updated in `disableIRVerificationIfNotFeasible()`. However, I suggest to rename this field into something more meaningful like `irVerificationPossible`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 27 15:25:43 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 27 Apr 2021 15:25:43 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v6]
In-Reply-To: <1MYGXgT-l5ghB-P0sQ7V1YcH3KmqPVra8pnjjWpJIOo=.c7a271c2-01dc-448e-ac95-22d7d30af0af@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <bx37BlKEGAGguvVKHvGFpNX05eFU27sng_RHmV_6ASg=.6b1a194f-f6e7-4bb0-a6ca-21dd79b16a52@github.com>
 <1MYGXgT-l5ghB-P0sQ7V1YcH3KmqPVra8pnjjWpJIOo=.c7a271c2-01dc-448e-ac95-22d7d30af0af@github.com>
Message-ID: <onYGny6CbKMvpGVMtTzUIkYixF_P2i6auwi8dMm48Js=.681734b8-047c-4ee1-8ca5-ecc0aabb331f@github.com>

On Mon, 26 Apr 2021 23:54:44 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup
>
> test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 308:
> 
>> 306: 
>> 307:     private void processControlAnnotations(Class<?> clazz) {
>> 308:         if (!XCOMP) {
> 
> Perhaps transform this condition on an early return, i.e., "if (XCOMP) return ;", instead of nesting the whole method under the if.

This handling with `XCOMP` (and other related ones) seem to be wrong and only worked like that in the old Valhalla framework. I don't think it is correct like that anymore. I discussed it with @TobiHartmann and thus added a new debug flag `-DIgnoreCompilerControls` to achieve the same functionality as in the old framework. I will push this update in a separate commit.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 373:
> 
>> 371:         boolean exclude = random.nextBoolean();
>> 372:         CompLevel level = CompLevel.ANY;
>> 373:         if (exclude) {
> 
> Transform to early return?

I refactored the code relating to `ExcludeRandom`.

> test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 378:
> 
>> 376:                 case 1 -> {
>> 377:                     level = CompLevel.C1;
>> 378:                     WHITE_BOX.makeMethodNotCompilable(ex, CompLevel.C2.getValue(), false);
> 
> I'm curious why two calls (with different values for the last parameter) are needed for these?

The parameter is for [osr](https://github.com/openjdk/jdk/blob/dc323a933401e4e540cdc416de5260923f42ba7f/src/hotspot/share/prims/whitebox.cpp#L928-L937): We need to exclude the method for osr and for normal compilations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From chagedorn at openjdk.java.net  Tue Apr 27 15:37:58 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 27 Apr 2021 15:37:58 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
Message-ID: <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>

> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
> 
> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
> 
> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
> 
> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
> 
> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
> 
> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
> 
> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>       - which leaves 4382 lines of code inserted 
> 
> Big thanks to:
> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
> - and others who provided valuable feedback.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:

 - Fix XCOMP cases from old framework and turn it into new debug flag -DIgnoreCompilerControls
 - Apply review comments: Added new Compiler annotation class for @DontCompile, changed C1 into C1_SIMPLE, refactored code for ExcludeRandom and FlipC1C2, added missing flag description in README, and some other smaller refactoring/renamings

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3508/files
  - new: https://git.openjdk.java.net/jdk/pull/3508/files/0720a330..90a0064d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=05-06

  Stats: 484 lines in 23 files changed: 207 ins; 85 del; 192 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3508.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Tue Apr 27 15:44:44 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 15:44:44 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v6]
In-Reply-To: <Gz3d75wHaCAvsAaGJVA0Q3Uk6fv909IB1jnDup2otPU=.30d4ad5e-94f4-489a-9618-70af13d94989@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <bx37BlKEGAGguvVKHvGFpNX05eFU27sng_RHmV_6ASg=.6b1a194f-f6e7-4bb0-a6ca-21dd79b16a52@github.com>
 <NfQVyJmkahrCDcv6z8uWeTD-Vjw1KEmcVIgI4X2d3-g=.07970959-6917-4689-bcc6-6d3e48a2010f@github.com>
 <Gz3d75wHaCAvsAaGJVA0Q3Uk6fv909IB1jnDup2otPU=.30d4ad5e-94f4-489a-9618-70af13d94989@github.com>
Message-ID: <0ieb3GL4kRcuSN4ZftJdRVlarhrqcYC0LFb9ZSpd7UY=.8f6cf2af-6e92-4743-bbf0-2b21f76d2413@github.com>

On Tue, 27 Apr 2021 15:21:44 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 135:
>> 
>>> 133:                                         - To only run the failed tests use -DTest, -DExclude,
>>> 134:                                           and/or -DScenarios.
>>> 135:                                         - To also get the standard output of the test VM run with\s
>> 
>> why do you need `\s` here?
>
> I needed this because `jcheck` complained about trailing whitespaces. Maybe this needs to be addressed at some point in `jcheck`.

well, why do you want to have a trailing space here? the text block you current have produces the following multeline sting, which has a trailing space at 4th line:
```  #############################################################
   - To only run the failed tests use -DTest, -DExclude,
     and/or -DScenarios.
   - To also get the standard output of the test VM run with 
     -DReportStdout=true or for even more fine-grained logging
     use -DVerbose=true.
  #############################################################

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From roland at openjdk.java.net  Tue Apr 27 15:57:07 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 27 Apr 2021 15:57:07 GMT
Subject: RFR: 8252372: Check if cloning is required to move loads out of
 loops in PhaseIdealLoop::split_if_with_blocks_post() [v2]
In-Reply-To: <qz3kFumQXyMW3Xt3cjmvCKvMH8QumRapQa8BjETXvRY=.1a778d56-257f-437d-89d5-6e50a160a7d5@github.com>
References: <qz3kFumQXyMW3Xt3cjmvCKvMH8QumRapQa8BjETXvRY=.1a778d56-257f-437d-89d5-6e50a160a7d5@github.com>
Message-ID: <i8kZA-y-E9JB5JSgyGmj4EnNY9QuwNBKYcfB9Hucj_Y=.832ebccd-f0b8-48b3-ba6a-1b5a7e04dec6@github.com>

> Sinking data nodes out of a loop when all uses are out of a loop has
> several issues that this attempts to fix.
> 
> 1- Only non control uses are considered which makes little sense (why
>   not sink if the data node is an argument to a call or a returned
>   value?)
> 
> 2- Sinking of Loads is broken because of the handling of
>   anti-dependence: the get_late_ctrl(n, n_ctrl) call returns a control
>   in the loop because it takes all uses into account.
> 
> 3- For data nodes for which a control edge can't be set, commoning of
>   clones back in the loop is prevented with:
>   _igvn._worklist.yank(x);
>   which gives no guarantee
> 
> This patch tries to address all issues:
> 
> 1- it looks at all uses, not only non control uses
> 
> 2- anti-dependences are computed for each use independently
> 
> 3- Cast nodes are used to pin clones out of loop
> 
> 
> 2- requires refactoring of the PhaseIdealLoop::get_late_ctrl()
> logic. While working on this, I noticed a bug in anti-dependence
> analysis: when the use is a cfg node, the code sometimes looks at uses
> of the memory state of the cfg. The logic uses the use of the cfg
> which is a projection of adr_type identical to the cfg. It should
> instead look at the use of the memory projection.
> 
> The existing logic for sinking loads calls clear_dom_lca_tags() for
> every load which seems like quite a waste. I added a
> _dom_lca_tags_round variable that's or'ed with the tag_node's _idx. By
> incrementing _dom_lca_tags_round, new tags that don't conflict with
> existing ones are produced and there's no need for
> clear_dom_lca_tags().
> 
> For anti-dependence analysis to return a correct result, early control
> of the load is needed. The only way to get it at this stage, AFAICT,
> is to compute it by following the load's input until a pinned node is
> reached.
> 
> The existing logic pins cloned nodes next to their use. The logic I
> propose pins them right out of the loop. This could possibly avoid
> some redundant clones. It also makes some special handling for corner
> cases with loop strip mining useless.
> 
> For 3-, I added extra Cast nodes for float types. If a chain of data
> nodes are sunk, the new logic tries to keep a single Cast for the
> entire chain rather than one Cast per node.

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 four additional commits since the last revision:

 - CastVV
 - Merge branch 'master' into JDK-8252372
 - extra comments
 - fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3689/files
  - new: https://git.openjdk.java.net/jdk/pull/3689/files/3bb62a6f..1d90bb1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3689&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3689&range=00-01

  Stats: 1179 lines in 114 files changed: 797 ins; 80 del; 302 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3689.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3689/head:pull/3689

PR: https://git.openjdk.java.net/jdk/pull/3689

From roland at openjdk.java.net  Tue Apr 27 15:57:07 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 27 Apr 2021 15:57:07 GMT
Subject: RFR: 8252372: Check if cloning is required to move loads out of
 loops in PhaseIdealLoop::split_if_with_blocks_post()
In-Reply-To: <qz3kFumQXyMW3Xt3cjmvCKvMH8QumRapQa8BjETXvRY=.1a778d56-257f-437d-89d5-6e50a160a7d5@github.com>
References: <qz3kFumQXyMW3Xt3cjmvCKvMH8QumRapQa8BjETXvRY=.1a778d56-257f-437d-89d5-6e50a160a7d5@github.com>
Message-ID: <MDegvOOseTongDqgmaGyyOWz5JTHYxDY2C6hwPyrhzQ=.c4482e72-6983-48c7-83e2-c6f311d58018@github.com>

On Mon, 26 Apr 2021 09:46:18 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Sinking data nodes out of a loop when all uses are out of a loop has
> several issues that this attempts to fix.
> 
> 1- Only non control uses are considered which makes little sense (why
>   not sink if the data node is an argument to a call or a returned
>   value?)
> 
> 2- Sinking of Loads is broken because of the handling of
>   anti-dependence: the get_late_ctrl(n, n_ctrl) call returns a control
>   in the loop because it takes all uses into account.
> 
> 3- For data nodes for which a control edge can't be set, commoning of
>   clones back in the loop is prevented with:
>   _igvn._worklist.yank(x);
>   which gives no guarantee
> 
> This patch tries to address all issues:
> 
> 1- it looks at all uses, not only non control uses
> 
> 2- anti-dependences are computed for each use independently
> 
> 3- Cast nodes are used to pin clones out of loop
> 
> 
> 2- requires refactoring of the PhaseIdealLoop::get_late_ctrl()
> logic. While working on this, I noticed a bug in anti-dependence
> analysis: when the use is a cfg node, the code sometimes looks at uses
> of the memory state of the cfg. The logic uses the use of the cfg
> which is a projection of adr_type identical to the cfg. It should
> instead look at the use of the memory projection.
> 
> The existing logic for sinking loads calls clear_dom_lca_tags() for
> every load which seems like quite a waste. I added a
> _dom_lca_tags_round variable that's or'ed with the tag_node's _idx. By
> incrementing _dom_lca_tags_round, new tags that don't conflict with
> existing ones are produced and there's no need for
> clear_dom_lca_tags().
> 
> For anti-dependence analysis to return a correct result, early control
> of the load is needed. The only way to get it at this stage, AFAICT,
> is to compute it by following the load's input until a pinned node is
> reached.
> 
> The existing logic pins cloned nodes next to their use. The logic I
> propose pins them right out of the loop. This could possibly avoid
> some redundant clones. It also makes some special handling for corner
> cases with loop strip mining useless.
> 
> For 3-, I added extra Cast nodes for float types. If a chain of data
> nodes are sunk, the new logic tries to keep a single Cast for the
> entire chain rather than one Cast per node.

That issue should be fixed. I added a CastVV node for vectors.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3689

From chagedorn at openjdk.java.net  Tue Apr 27 16:01:40 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 27 Apr 2021 16:01:40 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v6]
In-Reply-To: <0ieb3GL4kRcuSN4ZftJdRVlarhrqcYC0LFb9ZSpd7UY=.8f6cf2af-6e92-4743-bbf0-2b21f76d2413@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <bx37BlKEGAGguvVKHvGFpNX05eFU27sng_RHmV_6ASg=.6b1a194f-f6e7-4bb0-a6ca-21dd79b16a52@github.com>
 <NfQVyJmkahrCDcv6z8uWeTD-Vjw1KEmcVIgI4X2d3-g=.07970959-6917-4689-bcc6-6d3e48a2010f@github.com>
 <Gz3d75wHaCAvsAaGJVA0Q3Uk6fv909IB1jnDup2otPU=.30d4ad5e-94f4-489a-9618-70af13d94989@github.com>
 <0ieb3GL4kRcuSN4ZftJdRVlarhrqcYC0LFb9ZSpd7UY=.8f6cf2af-6e92-4743-bbf0-2b21f76d2413@github.com>
Message-ID: <9WzMXz_x4oWYNvye8WlUwI8S1ecO0krG3YhavJFsHn4=.e0687541-e365-4507-b577-d6f8f8d98930@github.com>

On Tue, 27 Apr 2021 15:41:07 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> I needed this because `jcheck` complained about trailing whitespaces. Maybe this needs to be addressed at some point in `jcheck`.
>
> well, why do you want to have a trailing space here? the text block you current have produces the following multeline sting, which has a trailing space at 4th line:
> ```  #############################################################
>    - To only run the failed tests use -DTest, -DExclude,
>      and/or -DScenarios.
>    - To also get the standard output of the test VM run with 
>      -DReportStdout=true or for even more fine-grained logging
>      use -DVerbose=true.
>   #############################################################

Hm, it somehow made sense when I added it back there but looking at it again it no longer does. I'll remove it in the next iteration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From kvn at openjdk.java.net  Tue Apr 27 16:06:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 16:06:36 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <IWtd4bFGH89625esaRb7qqKymlijqIr1sc826nGTBYI=.30a64f57-2b0f-43fe-8c59-0040a81625f5@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
 <IWtd4bFGH89625esaRb7qqKymlijqIr1sc826nGTBYI=.30a64f57-2b0f-43fe-8c59-0040a81625f5@github.com>
Message-ID: <DzCOWhf_6WaSDAC-u1rYzCepbGuAxZBqQFkbS0W57JU=.ce367649-f3fe-4a77-86c6-1f91d5343587@github.com>

On Tue, 27 Apr 2021 08:41:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
>> 
>> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
>> 
>> This issue was reported by John Jiang (johnsjiang at tencent.com).
>> 
>> Thanks,
>> Tobias
>
> Thanks for the reviews and suggestions.
> 
> @vnkozlov, how did you run the test? The exact same code is also used in `compiler/loopopts/TestStrangeControl.java` and we never had problems with that test not exiting.
> 
> @iignatev Thanks, I've updated the test(s) accordingly.

@TobiHartmann I ran test locally (not with jtreg). TestStrangeControl.java has the same issue when run standalone.
I think JTREG may kill process when main thread exits or something like that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From kvn at openjdk.java.net  Tue Apr 27 16:12:35 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 16:12:35 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi [v2]
In-Reply-To: <USY63n1Z_hB1Yq9k_X3ff2GvTK6HInFNFWm9OPhEcKs=.cd2359b4-3033-4e7b-8d18-1f2c65b2409d@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
 <USY63n1Z_hB1Yq9k_X3ff2GvTK6HInFNFWm9OPhEcKs=.cd2359b4-3033-4e7b-8d18-1f2c65b2409d@github.com>
Message-ID: <nXzB_ry5zK3NNE00zZjGavCKrd63r1moALfFze3_lAY=.d384bacc-e6ea-4a58-8c58-8b1f4621c505@github.com>

On Tue, 27 Apr 2021 08:46:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
>> 
>> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
>> 
>> This issue was reported by John Jiang (johnsjiang at tencent.com).
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use daemon thread and adjust timeout

I verified that `thread.setDaemon(true);` solved endless run issue with local testing I observed.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3684

From thartmann at openjdk.java.net  Tue Apr 27 16:16:37 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 16:16:37 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <woToWlA1lU98KSpL9oXWlOAxLn4cZmqfeT-_A5kxFBA=.37fb0a91-c031-4dcf-aba7-75d1688b228b@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
 <IWtd4bFGH89625esaRb7qqKymlijqIr1sc826nGTBYI=.30a64f57-2b0f-43fe-8c59-0040a81625f5@github.com>
 <DzCOWhf_6WaSDAC-u1rYzCepbGuAxZBqQFkbS0W57JU=.ce367649-f3fe-4a77-86c6-1f91d5343587@github.com>
 <woToWlA1lU98KSpL9oXWlOAxLn4cZmqfeT-_A5kxFBA=.37fb0a91-c031-4dcf-aba7-75d1688b228b@github.com>
Message-ID: <uxhgqir7EDDaXXA4y5CVqwYIu9MWo191YqLULBATFSc=.db24c501-bc6e-4311-a6cc-82adae54fc46@github.com>

On Tue, 27 Apr 2021 16:13:30 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> I think JTREG may kill process when main thread exits or something like that.

Ah right, that explains it. Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From iignatyev at openjdk.java.net  Tue Apr 27 16:16:37 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 16:16:37 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi
In-Reply-To: <DzCOWhf_6WaSDAC-u1rYzCepbGuAxZBqQFkbS0W57JU=.ce367649-f3fe-4a77-86c6-1f91d5343587@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
 <IWtd4bFGH89625esaRb7qqKymlijqIr1sc826nGTBYI=.30a64f57-2b0f-43fe-8c59-0040a81625f5@github.com>
 <DzCOWhf_6WaSDAC-u1rYzCepbGuAxZBqQFkbS0W57JU=.ce367649-f3fe-4a77-86c6-1f91d5343587@github.com>
Message-ID: <woToWlA1lU98KSpL9oXWlOAxLn4cZmqfeT-_A5kxFBA=.37fb0a91-c031-4dcf-aba7-75d1688b228b@github.com>

On Tue, 27 Apr 2021 16:03:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I think JTREG may kill process when main thread exits or something like that.

correct, jtreg exits the process almost immediately after the main method exits.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From iignatyev at openjdk.java.net  Tue Apr 27 16:23:36 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 16:23:36 GMT
Subject: RFR: 8265938: C2's conditional move optimization does not handle
 top Phi [v2]
In-Reply-To: <USY63n1Z_hB1Yq9k_X3ff2GvTK6HInFNFWm9OPhEcKs=.cd2359b4-3033-4e7b-8d18-1f2c65b2409d@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
 <USY63n1Z_hB1Yq9k_X3ff2GvTK6HInFNFWm9OPhEcKs=.cd2359b4-3033-4e7b-8d18-1f2c65b2409d@github.com>
Message-ID: <BG1S1Vwl7NNQfd-KIZJlc-LG3x2ttqtKHu7vuNM5L40=.1809f695-42a4-4088-92dc-229fc7c540ed@github.com>

On Tue, 27 Apr 2021 08:46:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
>> 
>> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
>> 
>> This issue was reported by John Jiang (johnsjiang at tencent.com).
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use daemon thread and adjust timeout

Marked as reviewed by iignatyev (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From vlivanov at openjdk.java.net  Tue Apr 27 16:37:37 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 27 Apr 2021 16:37:37 GMT
Subject: RFR: 8263972: C2: LoadVector/StoreVector type mismatch in
 MemNode::can_see_stored_value()
In-Reply-To: <vk57j-MOSDyC9q6BE69rqM9hz_EEwkOODJ2eCbEDnEo=.4639fa30-8287-4905-88f1-3354bbd4cf3a@github.com>
References: <vk57j-MOSDyC9q6BE69rqM9hz_EEwkOODJ2eCbEDnEo=.4639fa30-8287-4905-88f1-3354bbd4cf3a@github.com>
Message-ID: <qun2mkXc6wDG2scJwLrQQV0351bTbRxCw2NDGxO75Mw=.324c1469-cb52-4e64-94ca-9891d65364ec@github.com>

On Mon, 26 Apr 2021 16:07:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> `MemNode::can_see_stored_value()` doesn't take type info for `LoadVector`/`StoreVector` into account.
> 
> Eliminating `LoadVector`/`StoreVector` pair in presence of a type mismatch leads to a broken graph (omitting vector cast nodes) and sometimes manifest as a broken generated code. 
> 
> The fix adds necessary checks for vector case. 
> 
> Testing:
> - [x] regression test
> - [x] hs-tier1 - hs-tier4

Thanks for the reviews, Vladimir and Tobias.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3698

From vlivanov at openjdk.java.net  Tue Apr 27 16:37:39 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 27 Apr 2021 16:37:39 GMT
Subject: Integrated: 8263972: C2: LoadVector/StoreVector type mismatch in
 MemNode::can_see_stored_value()
In-Reply-To: <vk57j-MOSDyC9q6BE69rqM9hz_EEwkOODJ2eCbEDnEo=.4639fa30-8287-4905-88f1-3354bbd4cf3a@github.com>
References: <vk57j-MOSDyC9q6BE69rqM9hz_EEwkOODJ2eCbEDnEo=.4639fa30-8287-4905-88f1-3354bbd4cf3a@github.com>
Message-ID: <Fej6b3PnCy42NnLkE5oVDz37pcJwyCgNhSS-kCPHcl8=.a9405532-c19b-47d8-9f46-9d115ddba2c5@github.com>

On Mon, 26 Apr 2021 16:07:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> `MemNode::can_see_stored_value()` doesn't take type info for `LoadVector`/`StoreVector` into account.
> 
> Eliminating `LoadVector`/`StoreVector` pair in presence of a type mismatch leads to a broken graph (omitting vector cast nodes) and sometimes manifest as a broken generated code. 
> 
> The fix adds necessary checks for vector case. 
> 
> Testing:
> - [x] regression test
> - [x] hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: b2628d15
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b2628d15
Stats:     82 lines in 2 files changed: 81 ins; 0 del; 1 mod

8263972: C2: LoadVector/StoreVector type mismatch in MemNode::can_see_stored_value()

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3698

From psandoz at openjdk.java.net  Tue Apr 27 16:39:44 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 27 Apr 2021 16:39:44 GMT
Subject: RFR: 8255915:  jdk/incubator/vector/AddTest.java timed out
Message-ID: <g8I-V3x2hpEY5LYZw7ANLj3_rY2IQIEKIw3kRJwBU-w=.90cf2796-0d68-4994-8a7a-e3eb6e2a3198@github.com>

Update the test to require C2, since under execution with -Xcomp and C1 only this test can time out.

-------------

Commit messages:
 - Require C2 for test execution

Changes: https://git.openjdk.java.net/jdk/pull/3718/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3718&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255915
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3718.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3718/head:pull/3718

PR: https://git.openjdk.java.net/jdk/pull/3718

From kvn at openjdk.java.net  Tue Apr 27 16:48:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 16:48:38 GMT
Subject: RFR: 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)
In-Reply-To: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
References: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
Message-ID: <W8so2g4r-P7fGo444b_1cAcE6ovRuXOhBGjLTEK-SJo=.a083d3e4-a785-496d-8909-96b5e0db91ca@github.com>

On Tue, 27 Apr 2021 08:29:04 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> C2 computes -0.0 for Math.pow(-0.0, 0.5) which should be 0.0 according to the API specs.
> This bug was found while I was implementing the same optimization for x86_32 (JDK-8265940).
> 
> The reason is that CmpDNode [1] doesn't distinguish -0.0 from 0.0.
> Math.pow(-0.0, 0.5) was replaced with Math.sqrt(-0.0) incorrectly since CmpDNode says -0.0 < 0.0 if false.
> 
> The fix excludes C2's optimization for x=0.0/-0.0. 
> And the jtreg test has been improved to make sure the corner cases are covered by the compilers.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1656

I am fine with your fix - it is rare case so we can skip 0 case. But we need to verify that Interpreter and stubs (and Java) give the same result for -0.0 in 32- and 64-bit VMs.

C code uses `if(hx>=0)` so what result will it give for `-0.0`? :
 https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L497
 
 64-bit stub code use Integer compare which should be fine I think:
 https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L839
 
 Java code adds `+0.0` to get correct result (would be nice to see what code C2 generates when it see such bytecode):
 https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/FdLibm.java#L364

-------------

PR: https://git.openjdk.java.net/jdk/pull/3712

From vlivanov at openjdk.java.net  Tue Apr 27 17:01:35 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 27 Apr 2021 17:01:35 GMT
Subject: RFR: 8255915:  jdk/incubator/vector/AddTest.java timed out
In-Reply-To: <g8I-V3x2hpEY5LYZw7ANLj3_rY2IQIEKIw3kRJwBU-w=.90cf2796-0d68-4994-8a7a-e3eb6e2a3198@github.com>
References: <g8I-V3x2hpEY5LYZw7ANLj3_rY2IQIEKIw3kRJwBU-w=.90cf2796-0d68-4994-8a7a-e3eb6e2a3198@github.com>
Message-ID: <tEHOS3eX-pnatUyRmDK7kqzCb0zYJ44v4miRwCiRfxk=.5532080b-1317-44d4-86d4-e1823a76e2a3@github.com>

On Tue, 27 Apr 2021 16:30:20 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Update the test to require C2, since under execution with -Xcomp and C1 only this test can time out.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3718

From thartmann at openjdk.java.net  Tue Apr 27 17:14:38 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Apr 2021 17:14:38 GMT
Subject: Integrated: 8265938: C2's conditional move optimization does not
 handle top Phi
In-Reply-To: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
References: <BBISgN7hfVgN9uwU1Mignfn_of49u6nraXFL-0tNdUk=.1b6c9685-199c-4251-9744-df9c2fcaafac@github.com>
Message-ID: <8ZLPwjKDbO2bcxvFexSaPb0mvy-J8lupcijy73ttYEw=.70e9aa75-9148-4b01-bb69-5f493dd6a727@github.com>

On Mon, 26 Apr 2021 06:46:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C2's CCP optimization sets the type of a PhiNode to TOP because it became dead after loop unrolling. Now since that node is not reachable from the bottom due to an infinite loop at the end of the method, CCP does not enqueue the PhiNode for IGVN. As a result, the dead subgraph is not removed. During loop opts, the conditional move optimization fails on the PhiNode because its type is top. The expected behavior is to simply bail out with "COMPILE SKIPPED: infinite loop (retry at different tier)".
> 
> I suggest to fix this by simply handling a TOP Phi in the conditional move optimization code.
> 
> This issue was reported by John Jiang (johnsjiang at tencent.com).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: ab2aec2a
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab2aec2a
Stats:     82 lines in 3 files changed: 78 ins; 1 del; 3 mod

8265938: C2's conditional move optimization does not handle top Phi

Reviewed-by: chagedorn, kvn, iignatyev

-------------

PR: https://git.openjdk.java.net/jdk/pull/3684

From rcastanedalo at openjdk.java.net  Tue Apr 27 17:28:38 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 27 Apr 2021 17:28:38 GMT
Subject: RFR: 8265587: IGV: track nodes across matching
In-Reply-To: <lbLYj3nNOs7f3Kmnpy-Krg6fZA0k1iaGIxbW8OZZBTY=.54e702ab-1cc2-40fb-b35a-604be7010578@github.com>
References: <n4rVpa5niUA7uxFGvO49o6MT9TH5pMvwF8Mnpax1Bg0=.3ff29745-d792-4793-98fa-e3ee5c4975ea@github.com>
 <lbLYj3nNOs7f3Kmnpy-Krg6fZA0k1iaGIxbW8OZZBTY=.54e702ab-1cc2-40fb-b35a-604be7010578@github.com>
Message-ID: <9tRVZIZ1ADjmB6pw8Bf3U5HPNN0MF_eXq_cSlwbSJUg=.1a2cfdcd-20ef-40eb-a077-a3b44ff4fb34@github.com>

On Tue, 27 Apr 2021 17:25:59 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Looks good.

Thanks Vladimir!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3654

From vlivanov at openjdk.java.net  Tue Apr 27 17:28:38 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 27 Apr 2021 17:28:38 GMT
Subject: RFR: 8265587: IGV: track nodes across matching
In-Reply-To: <n4rVpa5niUA7uxFGvO49o6MT9TH5pMvwF8Mnpax1Bg0=.3ff29745-d792-4793-98fa-e3ee5c4975ea@github.com>
References: <n4rVpa5niUA7uxFGvO49o6MT9TH5pMvwF8Mnpax1Bg0=.3ff29745-d792-4793-98fa-e3ee5c4975ea@github.com>
Message-ID: <lbLYj3nNOs7f3Kmnpy-Krg6fZA0k1iaGIxbW8OZZBTY=.54e702ab-1cc2-40fb-b35a-604be7010578@github.com>

On Fri, 23 Apr 2021 12:31:20 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change preserves, as much as possible, the IGV node identifier of Ideal nodes in their corresponding machine nodes created by `Matcher::match()`. This makes it possible to track nodes when stepping from "Before matching" to "After matching" in IGV, as illustrated for an extracted compare-and-branch subgraph in the following screenshot: 
> 
> ![before-after-matching](https://user-images.githubusercontent.com/8792647/115867587-94b75280-a43b-11eb-8a79-9c13a0a68d42.png)
> 
> #### Limitations
> This solution preserves most of the node relations across matching, however if an Ideal node is expanded into multiple machine nodes, only one of them is assigned the IGV identifier of the Ideal node (since IGV identifiers need to be unique within a compilation phase). This limitation can be seen in the following example, where the `CmpU` Ideal node is implemented with three `compU_rReg` machine nodes (one for each `jmpConU` machine node), but only one of the `compU_rReg` machine nodes (50) preserves the IGV identifier:
> 
> ![before-after-matching-limitation](https://user-images.githubusercontent.com/8792647/115869469-3770d080-a43e-11eb-9ede-d8845862c7bd.png)
> 
> Overcoming this limitation would require explicitly serializing the entire before-after relation among nodes and adapting IGV's node selection and graph difference logic, which seems too complex for a relatively infrequent case.
> 
> #### Testing
> - Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
> - Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
> - Tested manually, for a few graphs, that nodes of different types can be tracked across matching.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3654

From vlivanov at openjdk.java.net  Tue Apr 27 17:42:57 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 27 Apr 2021 17:42:57 GMT
Subject: RFR: 8264873: Dependencies: Split ClassHierarchyWalker [v4]
In-Reply-To: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
References: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
Message-ID: <BVVACBoeu07xqCH4nni35NtBsi83HnN8PIUiQK8cTl4=.cf0f89b9-16e9-423d-86c5-f797ca915bcc@github.com>

> Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into 8264873.cha.split
 - Merge branch 'master' into 8264873.cha.split
 - Fix build failure
 - Merge branch 'master' into 8264873.cha.split
 - Merge branch 'master' into 8264873.cha.split
 - Fix formatting
 - Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder
 - CountingClassHierarchyIterator
 - Migrate to PerfData
 - Depenencies perf counters
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/dc323a93...e414f9c4

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3387/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3387&range=03
  Stats: 503 lines in 1 file changed: 169 ins; 177 del; 157 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3387.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3387/head:pull/3387

PR: https://git.openjdk.java.net/jdk/pull/3387

From vlivanov at openjdk.java.net  Tue Apr 27 17:42:58 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 27 Apr 2021 17:42:58 GMT
Subject: RFR: 8264873: Dependencies: Split ClassHierarchyWalker [v3]
In-Reply-To: <bVpFyU8J3ZXoS5sPj8mX_cRLV4e8y037MqhDGfPKWYM=.00dccd8f-2636-4ab5-b3be-74b53dba2cda@github.com>
References: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
 <bVpFyU8J3ZXoS5sPj8mX_cRLV4e8y037MqhDGfPKWYM=.00dccd8f-2636-4ab5-b3be-74b53dba2cda@github.com>
Message-ID: <5KJQn6yqBnNCAOoFgmXYgYW6iBiaUql3vjLbvVjlSHQ=.2a9fe7a6-6cc0-4dbc-8d1d-6f0cf5295a2a@github.com>

On Fri, 9 Apr 2021 22:41:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier4
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into 8264873.cha.split
>  - Fix formatting
>  - Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder
>  - CountingClassHierarchyIterator
>  - Migrate to PerfData
>  - Depenencies perf counters
>  - KlassDepChange::involves_context
>  - KlassDepChange::_new_type
>  - Dependencies::is_concrete_method
>  - Dependencies::verify_method_context
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/76bd313d...e38b995c

Thanks for the reviews, Vladimir and Tobias.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3387

From sviswanathan at openjdk.java.net  Tue Apr 27 18:15:40 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 27 Apr 2021 18:15:40 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v8]
In-Reply-To: <utIX2iDZFYUTZXh6ix90EIxqk9z2RfzcD8xM21q6XAM=.94212c52-9382-4214-a54a-a758bf1e2990@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <utIX2iDZFYUTZXh6ix90EIxqk9z2RfzcD8xM21q6XAM=.94212c52-9382-4214-a54a-a758bf1e2990@github.com>
Message-ID: <dh9pXfCuQSEhETpE0sh8hSIaVwRqzjLZyIlk_Xmrr54=.6e1ad2ca-3fd2-457f-bec8-2bcbae402eac@github.com>

On Sat, 24 Apr 2021 00:21:49 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:
> 
>   Fix copyright
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1065:

> 1063: 
> 1064:   jcc(Assembler::equal, DONE_LABEL);
> 1065:   jcc(Assembler::parity, DONE_LABEL);

Please add comments here to explain that equal takes care of special case for +0.0/-0.0 and parity takes care of NaN.
If the argument is positive zero or negative zero, then the result is the same as the argument.
If the argument is NaN, then the result is NaN.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1076:

> 1074: 
> 1075:   if (opcode == Op_SignumF){
> 1076:     xorps(dst, ExternalAddress(StubRoutines::x86::vector_float_sign_flip()), scratch);

The vector_float_sign_flip is 64 bit aligned. Whereas the sse version of xorps and xorpd will need 128 bit aligned memory address.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From jbhateja at openjdk.java.net  Tue Apr 27 18:24:44 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 27 Apr 2021 18:24:44 GMT
Subject: RFR: 8265126: unified handling for VectorMask object
 re-materialization during de-optimization (re-submit)
Message-ID: <2KlypmIXfPwTn6dp0AG9W0LMqvu6griQnWjSEQBwn2o=.6b09a942-e241-4ff6-b581-1810aa6bb124@github.com>

Following flow describes object reconstruction for de-optimization:-

1. PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
2. During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
3. De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
4. During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings.

By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.

tier1-tier3 regressions are clean with UseAVX=2/3.

-------------

Commit messages:
 - 8265126:[REDO] unified handling for VectorMask object re-materialization during de-optimization

Changes: https://git.openjdk.java.net/jdk/pull/3721/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3721&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265126
  Stats: 74 lines in 3 files changed: 26 ins; 26 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3721.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3721/head:pull/3721

PR: https://git.openjdk.java.net/jdk/pull/3721

From psandoz at openjdk.java.net  Tue Apr 27 18:45:34 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 27 Apr 2021 18:45:34 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization
In-Reply-To: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
Message-ID: <t6x-07deVE-31m3nJaiOWKhM_4oPZ-1tmfsMc1fx2AM=.f24f1776-bf4b-43c7-8316-e77cd2db7ca9@github.com>

On Tue, 27 Apr 2021 17:56:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server)
> 
> ``
> Benchmark | (TESTSIZE) | Baseline (ops/min) | Withopt (ops/min) | Gain %
> -- | -- | -- | -- | --
> RotateBenchmark.testRotateLeftI | 64 | 6813.033 | 6936.507 | 1.81
> RotateBenchmark.testRotateLeftI | 64 | 11549.524 | 12109.845 | 4.85
> RotateBenchmark.testRotateLeftI | 64 | 17780.166 | 18180.083 | 2.25
> RotateBenchmark.testRotateLeftI | 128 | 3355.631 | 3426.436 | 2.11
> RotateBenchmark.testRotateLeftI | 128 | 5925.534 | 6096.71 | 2.89
> RotateBenchmark.testRotateLeftI | 128 | 8847.645 | 8964.224 | 1.32
> RotateBenchmark.testRotateLeftI | 256 | 1704.192 | 1779.964 | 4.45
> RotateBenchmark.testRotateLeftI | 256 | 2919.158 | 3000.392 | 2.78
> RotateBenchmark.testRotateLeftI | 256 | 4386.134 | 4514.211 | 2.92
> RotateBenchmark.testRotateLeftL | 64 | 3419.193 | 3500.522 | 2.38
> RotateBenchmark.testRotateLeftL | 64 | 5982.87 | 6056.589 | 1.23
> RotateBenchmark.testRotateLeftL | 64 | 8829.172 | 8949.157 | 1.36
> RotateBenchmark.testRotateLeftL | 128 | 1684.745 | 1784.49 | 5.92
> RotateBenchmark.testRotateLeftL | 128 | 2942.226 | 2947.684 | 0.19
> RotateBenchmark.testRotateLeftL | 128 | 4385.488 | 4554.113 | 3.85
> RotateBenchmark.testRotateLeftL | 256 | 834.195 | 856.939 | 2.73
> RotateBenchmark.testRotateLeftL | 256 | 1463.802 | 1551.051 | 5.96
> RotateBenchmark.testRotateLeftL | 256 | 2187.005 | 2268.596 | 3.73
> RotateBenchmark.testRotateRightI | 64 | 6676.132 | 7077.587 | 6.01
> RotateBenchmark.testRotateRightI | 64 | 11452.825 | 11855.45 | 3.52
> RotateBenchmark.testRotateRightI | 64 | 17507.286 | 18164.757 | 3.76
> RotateBenchmark.testRotateRightI | 128 | 3412.394 | 3519.829 | 3.15
> RotateBenchmark.testRotateRightI | 128 | 5905.677 | 5875.698 | -0.51
> RotateBenchmark.testRotateRightI | 128 | 8745.95 | 8890.757 | 1.66
> RotateBenchmark.testRotateRightI | 256 | 1681.176 | 1708.54 | 1.63
> RotateBenchmark.testRotateRightI | 256 | 3004.008 | 3005.606 | 0.05
> RotateBenchmark.testRotateRightI | 256 | 4466.633 | 4548.232 | 1.83
> RotateBenchmark.testRotateRightL | 64 | 3361.499 | 3461.121 | 2.96
> RotateBenchmark.testRotateRightL | 64 | 5873.37 | 6072.209 | 3.39
> RotateBenchmark.testRotateRightL | 64 | 8820.284 | 9016.172 | 2.22
> RotateBenchmark.testRotateRightL | 128 | 1715.556 | 1720.67 | 0.30
> RotateBenchmark.testRotateRightL | 128 | 2957.337 | 3149.193 | 6.49
> RotateBenchmark.testRotateRightL | 128 | 4440.468 | 4473.221 | 0.74
> RotateBenchmark.testRotateRightL | 256 | 851.391 | 875.371 | 2.82
> RotateBenchmark.testRotateRightL | 256 | 1452.422 | 1522.942 | 4.86
> RotateBenchmark.testRotateRightL | 256 | 2208.454 | 2263.349 | 2.49
> 
>  ``

I noticed the tests are only updated for int and long, is that intentional? The HotSpot changes in some cases seem to imply all integral types are supported via the use of `is_integral_type`, contradicted by the use of `is_subword_type`.

I would recommend trying to leverage Integer/Long.rotateLeft/Right implementations. They are not available for byte/short, so lets add specific methods in those cases, that should make the Java op implementation clearer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From psandoz at openjdk.java.net  Tue Apr 27 19:01:35 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 27 Apr 2021 19:01:35 GMT
Subject: Integrated: 8255915:  jdk/incubator/vector/AddTest.java timed out
In-Reply-To: <g8I-V3x2hpEY5LYZw7ANLj3_rY2IQIEKIw3kRJwBU-w=.90cf2796-0d68-4994-8a7a-e3eb6e2a3198@github.com>
References: <g8I-V3x2hpEY5LYZw7ANLj3_rY2IQIEKIw3kRJwBU-w=.90cf2796-0d68-4994-8a7a-e3eb6e2a3198@github.com>
Message-ID: <eyPl2XUcVUlnRHTVRB8P5wD_Ip8ItXqZpV0E0-r5-mg=.f22cfd60-a7ed-42c7-b05e-ea1632ee00f5@github.com>

On Tue, 27 Apr 2021 16:30:20 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Update the test to require C2, since under execution with -Xcomp and C1 only this test can time out.

This pull request has now been integrated.

Changeset: 0a88f0a1
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a88f0a1
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8255915: jdk/incubator/vector/AddTest.java timed out

Reviewed-by: vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3718

From iignatyev at openjdk.java.net  Tue Apr 27 19:10:50 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 19:10:50 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
 <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
Message-ID: <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com>

On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later).

@dougxc, I don't think that we should (or even can) rename it to `vm.jvmcicompiler.enabled`. although the value of the property is indeed `true` whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change `requires/VMProps.java` to set `vm.graal.enabled` only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here.

-- Igor

-------------

PR: https://git.openjdk.java.net/jdk/pull/3421

From dnsimon at openjdk.java.net  Tue Apr 27 19:52:22 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 27 Apr 2021 19:52:22 GMT
Subject: RFR: 8264806: Remove the experimental JIT compiler [v2]
In-Reply-To: <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com>
References: <iHvGW7C8zvysgGB-Crr2uansA6eC5aZouxVPkGgW2pE=.e3eca778-945d-4f9b-b4ed-394655c62cb9@github.com>
 <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com>
 <Ff29h8_b8pFAPFa-CaSXgcxeGq2bMa-Vw_tBoIjxQ_8=.73ecf438-1029-4e35-add7-c67100bbd39e@github.com>
 <Lftb5hgpx-Oc7yyuDdyz44enOwyXOWCNEuwbOJd8eig=.50fc5c44-6c2f-4146-ab66-3fac3fd4b47d@github.com>
 <C4v1Buz15KGEnz45i7ysZovkZ36rmotwbGpEDWQAymA=.c3edd020-3c80-4afd-83f8-040f9990afb0@github.com>
 <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com>
 <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com>
Message-ID: <o7MoSCHYzz8LY-cQhlF8gksBqUecUrsZv_rnC9Z_oSc=.5d3e308f-3539-442c-a0f9-50c03ebc2e27@github.com>

On Tue, 27 Apr 2021 19:07:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> > I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later).
> 
> @dougxc, I don't think that we should (or even can) rename it to `vm.jvmcicompiler.enabled`. although the value of the property is indeed `true` whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change `requires/VMProps.java` to set `vm.graal.enabled` only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here.
> 
> -- Igor

Yes, we should just it as is until a second JVMCI compiler shows up.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3421

From iignatyev at openjdk.java.net  Tue Apr 27 20:02:20 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 20:02:20 GMT
Subject: RFR: 8266088: compiler/arguments/TestPrintOptoAssemblyLineNumbers
 test should user driver mode
Message-ID: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>

Hi all,

could you please review this tiny patch for `TestPrintOptoAssemblyLineNumbers` test? 
from JBS:
> compiler/arguments/TestPrintOptoAssemblyLineNumbers class is a driver class that spawns a new JVM and validates its output, there is no need for the JVM which executes TestPrintOptoAssemblyLineNumbers to be run w/ all vm flags.

besides addressing this, the patch also removes `/compiler/patches` from `@library` as it's not needed and fixes code style here and there.

testing:
- [x] `compiler/arguments/TestPrintOptoAssemblyLineNumbers` on `{linux,windows,macosx}-x64-debug`

Thanks,
-- Igor

-------------

Commit messages:
 - one more space before { missed
 - use driver mode in TestPrintOptoAssemblyLineNumbers

Changes: https://git.openjdk.java.net/jdk/pull/3726/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3726&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266088
  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3726.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3726/head:pull/3726

PR: https://git.openjdk.java.net/jdk/pull/3726

From vlivanov at openjdk.java.net  Tue Apr 27 20:06:10 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 27 Apr 2021 20:06:10 GMT
Subject: Integrated: 8264873: Dependencies: Split ClassHierarchyWalker
In-Reply-To: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
References: <L6bUqv7ocdieIMnskgiQElusKdpE-Bfj4dwUHRmkAQQ=.e2840c9a-266d-44c7-b67b-1d8ada5a35de@github.com>
Message-ID: <lMlbg0mFvehZ3YiXk6c04qFjoHUmqtXGMS6A_6Bpp6s=.49b6f9a9-d26d-47c8-ac8d-46be201b64e3@github.com>

On Wed, 7 Apr 2021 22:14:33 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Split ClassHierarchyWalker into ConcreteMethodFinder and ConcreteSubtypeFinder.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: f560b892
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f560b8923378042b1cb162de4e1c65ea1c875af0
Stats:     503 lines in 1 file changed: 169 ins; 177 del; 157 mod

8264873: Dependencies: Split ClassHierarchyWalker

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3387

From iignatyev at openjdk.java.net  Tue Apr 27 20:26:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 20:26:38 GMT
Subject: RFR: 8266088: compiler/arguments/TestPrintOptoAssemblyLineNumbers
 test should user driver mode [v2]
In-Reply-To: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
References: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
Message-ID: <zizb72F1_pzYOIzTolprtCwHnHNoww7xJirk96iH1Vg=.85cd4c6e-6d40-4ed9-9885-4c8c1762e1ca@github.com>

> Hi all,
> 
> could you please review this tiny patch for `TestPrintOptoAssemblyLineNumbers` test? 
> from JBS:
>> compiler/arguments/TestPrintOptoAssemblyLineNumbers class is a driver class that spawns a new JVM and validates its output, there is no need for the JVM which executes TestPrintOptoAssemblyLineNumbers to be run w/ all vm flags.
> 
> besides addressing this, the patch also removes `/compiler/patches` from `@library` as it's not needed and fixes code style here and there.
> 
> testing:
> - [x] `compiler/arguments/TestPrintOptoAssemblyLineNumbers` on `{linux,windows,macosx}-x64-debug`
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with four additional commits since the last revision:

 - added oracle copyright line
 - and one more space
 - "mark" test as sensitive to line numbers
 - use OutputAnalyzer to check stdout
   check exit code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3726/files
  - new: https://git.openjdk.java.net/jdk/pull/3726/files/1e37f7b3..d4b342a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3726&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3726&range=00-01

  Stats: 9 lines in 1 file changed: 4 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3726.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3726/head:pull/3726

PR: https://git.openjdk.java.net/jdk/pull/3726

From kvn at openjdk.java.net  Tue Apr 27 20:26:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 20:26:38 GMT
Subject: RFR: 8266088: compiler/arguments/TestPrintOptoAssemblyLineNumbers
 test should user driver mode [v2]
In-Reply-To: <zizb72F1_pzYOIzTolprtCwHnHNoww7xJirk96iH1Vg=.85cd4c6e-6d40-4ed9-9885-4c8c1762e1ca@github.com>
References: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
 <zizb72F1_pzYOIzTolprtCwHnHNoww7xJirk96iH1Vg=.85cd4c6e-6d40-4ed9-9885-4c8c1762e1ca@github.com>
Message-ID: <a7-srb8u6K5MsLRSyENps7t2Gxg3IHHLl_u9u9EzSus=.a0a33d9e-e56a-418e-b275-0a0096ccf945@github.com>

On Tue, 27 Apr 2021 20:22:47 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this tiny patch for `TestPrintOptoAssemblyLineNumbers` test? 
>> from JBS:
>>> compiler/arguments/TestPrintOptoAssemblyLineNumbers class is a driver class that spawns a new JVM and validates its output, there is no need for the JVM which executes TestPrintOptoAssemblyLineNumbers to be run w/ all vm flags.
>> 
>> besides addressing this, the patch also removes `/compiler/patches` from `@library` as it's not needed and fixes code style here and there.
>> 
>> testing:
>> - [x] `compiler/arguments/TestPrintOptoAssemblyLineNumbers` on `{linux,windows,macosx}-x64-debug`
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - added oracle copyright line
>  - and one more space
>  - "mark" test as sensitive to line numbers
>  - use OutputAnalyzer to check stdout
>    check exit code

Add Oracle copyright line.

test/hotspot/jtreg/compiler/arguments/TestPrintOptoAssemblyLineNumbers.java line 67:

> 65:         public static void main(String[] args) {
> 66:             int count = 0;
> 67:             for (int x = 0; x < 200_000; x++){

Missed space between `){`

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3726

From iignatyev at openjdk.java.net  Tue Apr 27 20:26:39 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 20:26:39 GMT
Subject: RFR: 8266088: compiler/arguments/TestPrintOptoAssemblyLineNumbers
 test should user driver mode
In-Reply-To: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
References: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
Message-ID: <ja6ZZG-O3Tuak05tqUr37GLIocpCf0_uk2yTgqjmXEM=.a71404c2-302f-48d5-80be-56046aa99b50@github.com>

On Tue, 27 Apr 2021 19:54:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this tiny patch for `TestPrintOptoAssemblyLineNumbers` test? 
> from JBS:
>> compiler/arguments/TestPrintOptoAssemblyLineNumbers class is a driver class that spawns a new JVM and validates its output, there is no need for the JVM which executes TestPrintOptoAssemblyLineNumbers to be run w/ all vm flags.
> 
> besides addressing this, the patch also removes `/compiler/patches` from `@library` as it's not needed and fixes code style here and there.
> 
> testing:
> - [x] `compiler/arguments/TestPrintOptoAssemblyLineNumbers` on `{linux,windows,macosx}-x64-debug`
> 
> Thanks,
> -- Igor

staring more at this test, I've noticed a few other things which should be improved:
 - the test didn't use `OutputAnaluzer::*should*` method to check that the output contains the desired line. so in case of failure, we won't have all information about the subprocess
 - it didn't check the subprocess' exit code
 - the file is sensitive to line numbers but didn't have the comment which we use to mark and track such files

-------------

PR: https://git.openjdk.java.net/jdk/pull/3726

From iignatyev at openjdk.java.net  Tue Apr 27 20:30:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 20:30:35 GMT
Subject: RFR: 8266088: compiler/arguments/TestPrintOptoAssemblyLineNumbers
 test should user driver mode [v3]
In-Reply-To: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
References: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
Message-ID: <k1-VHal5FHRSPOPb4ejuAa8fb-NE39ma_gOrTp6uLzo=.1ca80873-2e05-4b5b-9bf3-79bbbf5800ed@github.com>

> Hi all,
> 
> could you please review this tiny patch for `TestPrintOptoAssemblyLineNumbers` test? 
> from JBS:
>> compiler/arguments/TestPrintOptoAssemblyLineNumbers class is a driver class that spawns a new JVM and validates its output, there is no need for the JVM which executes TestPrintOptoAssemblyLineNumbers to be run w/ all vm flags.
> 
> besides addressing this, the patch also removes `/compiler/patches` from `@library` as it's not needed and fixes code style here and there.
> 
> testing:
> - [x] `compiler/arguments/TestPrintOptoAssemblyLineNumbers` on `{linux,windows,macosx}-x64-debug`
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:

  fixed line numbers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3726/files
  - new: https://git.openjdk.java.net/jdk/pull/3726/files/d4b342a9..b5a52b94

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3726&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3726&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3726.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3726/head:pull/3726

PR: https://git.openjdk.java.net/jdk/pull/3726

From kvn at openjdk.java.net  Tue Apr 27 20:51:07 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 20:51:07 GMT
Subject: RFR: 8266088: compiler/arguments/TestPrintOptoAssemblyLineNumbers
 test should user driver mode [v3]
In-Reply-To: <k1-VHal5FHRSPOPb4ejuAa8fb-NE39ma_gOrTp6uLzo=.1ca80873-2e05-4b5b-9bf3-79bbbf5800ed@github.com>
References: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
 <k1-VHal5FHRSPOPb4ejuAa8fb-NE39ma_gOrTp6uLzo=.1ca80873-2e05-4b5b-9bf3-79bbbf5800ed@github.com>
Message-ID: <7-1He7LjRSRXmly5i6YyO6lu1NTB4JxltXTFZoacbV8=.1f3b70af-9947-4f49-a05e-ef55bf97395d@github.com>

On Tue, 27 Apr 2021 20:30:35 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this tiny patch for `TestPrintOptoAssemblyLineNumbers` test? 
>> from JBS:
>>> compiler/arguments/TestPrintOptoAssemblyLineNumbers class is a driver class that spawns a new JVM and validates its output, there is no need for the JVM which executes TestPrintOptoAssemblyLineNumbers to be run w/ all vm flags.
>> 
>> besides addressing this, the patch also removes `/compiler/patches` from `@library` as it's not needed and fixes code style here and there.
>> 
>> testing:
>> - [x] `compiler/arguments/TestPrintOptoAssemblyLineNumbers` on `{linux,windows,macosx}-x64-debug`
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed line numbers

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3726

From iignatyev at openjdk.java.net  Tue Apr 27 21:02:12 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 21:02:12 GMT
Subject: RFR: 8266088: compiler/arguments/TestPrintOptoAssemblyLineNumbers
 test should user driver mode [v3]
In-Reply-To: <k1-VHal5FHRSPOPb4ejuAa8fb-NE39ma_gOrTp6uLzo=.1ca80873-2e05-4b5b-9bf3-79bbbf5800ed@github.com>
References: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
 <k1-VHal5FHRSPOPb4ejuAa8fb-NE39ma_gOrTp6uLzo=.1ca80873-2e05-4b5b-9bf3-79bbbf5800ed@github.com>
Message-ID: <IRTrOGH4ykLGc_fqItVrO7QXmKPJWs8e5yXaMItOaDQ=.e4489c5a-bec6-472d-ac94-48238572d2c8@github.com>

On Tue, 27 Apr 2021 20:30:35 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this tiny patch for `TestPrintOptoAssemblyLineNumbers` test? 
>> from JBS:
>>> compiler/arguments/TestPrintOptoAssemblyLineNumbers class is a driver class that spawns a new JVM and validates its output, there is no need for the JVM which executes TestPrintOptoAssemblyLineNumbers to be run w/ all vm flags.
>> 
>> besides addressing this, the patch also removes `/compiler/patches` from `@library` as it's not needed and fixes code style here and there.
>> 
>> testing:
>> - [x] `compiler/arguments/TestPrintOptoAssemblyLineNumbers` on `{linux,windows,macosx}-x64-debug`
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed line numbers

thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3726

From iignatyev at openjdk.java.net  Tue Apr 27 21:02:13 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 21:02:13 GMT
Subject: Integrated: 8266088:
 compiler/arguments/TestPrintOptoAssemblyLineNumbers test should user driver
 mode
In-Reply-To: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
References: <QN6XW6BMjF-qPpbGUek6YiJi7v2DU8pWJCXy_GVNb-s=.1bf71fe7-81a6-44a5-b6e5-e39d13c6e972@github.com>
Message-ID: <D8H4f-t4Ogaw_KyThuYBbI71wjy_RA4lG5ZQSw6H24M=.90fd7f9d-212c-4176-99a1-c676b16818e1@github.com>

On Tue, 27 Apr 2021 19:54:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this tiny patch for `TestPrintOptoAssemblyLineNumbers` test? 
> from JBS:
>> compiler/arguments/TestPrintOptoAssemblyLineNumbers class is a driver class that spawns a new JVM and validates its output, there is no need for the JVM which executes TestPrintOptoAssemblyLineNumbers to be run w/ all vm flags.
> 
> besides addressing this, the patch also removes `/compiler/patches` from `@library` as it's not needed and fixes code style here and there.
> 
> testing:
> - [x] `compiler/arguments/TestPrintOptoAssemblyLineNumbers` on `{linux,windows,macosx}-x64-debug`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 7f4a9f68
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7f4a9f68bfd6fd002f79ac989155550db0bcdd20
Stats:     19 lines in 1 file changed: 4 ins; 1 del; 14 mod

8266088: compiler/arguments/TestPrintOptoAssemblyLineNumbers test should user driver mode

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3726

From iignatyev at openjdk.java.net  Tue Apr 27 21:14:25 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 21:14:25 GMT
Subject: RFR: 8266149: mark hotspot compiler/startup tests which ignore VM
 flags
Message-ID: <k5ZA2wVRv2To3GUrN3hurdtC-NEyINiICXuab0nhVwo=.0c0aa660-2b4d-4179-8228-b03b3ced91ef@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/startup` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright
 - update compiler/startup tests

Changes: https://git.openjdk.java.net/jdk/pull/3729/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3729&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266149
  Stats: 6 lines in 3 files changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3729.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3729/head:pull/3729

PR: https://git.openjdk.java.net/jdk/pull/3729

From iignatyev at openjdk.java.net  Tue Apr 27 21:21:13 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 21:21:13 GMT
Subject: RFR: 8266150: mark hotspot compiler/arguments tests which ignore VM
 flags
Message-ID: <cAilxCYd8ocZQkzwSiMgEXJZccbmfMnnR8JasvMU0jg=.09b8a697-8523-4255-88ea-68c578791106@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/arguments` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright
 - update line number in TestPrintOptoAssemblyLineNumbers
 - update compiler/arguments tests

Changes: https://git.openjdk.java.net/jdk/pull/3730/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3730&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266150
  Stats: 16 lines in 9 files changed: 12 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3730.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3730/head:pull/3730

PR: https://git.openjdk.java.net/jdk/pull/3730

From iignatyev at openjdk.java.net  Tue Apr 27 21:34:21 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 21:34:21 GMT
Subject: RFR: 8266153: mark hotspot compiler/onSpinWait tests which ignore VM
 flags
Message-ID: <khyvkfkYW6Hk7gfSFHUocbgCBJY64VjEJ8raVr1F9LU=.fba30b70-fddf-4eea-ab31-1c124211cea3@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/onSpinWait` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright
 - 8266153

Changes: https://git.openjdk.java.net/jdk/pull/3731/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3731&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266153
  Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3731/head:pull/3731

PR: https://git.openjdk.java.net/jdk/pull/3731

From iignatyev at openjdk.java.net  Tue Apr 27 21:38:17 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 21:38:17 GMT
Subject: RFR: 8266154: mark hotspot compiler/oracle tests which ignore VM flags
Message-ID: <2F21p8WiYXUzOBpkQSGaPBOLeleeMHOVaP1LJHvEjNg=.86c1b538-951d-4a9f-872c-38878446c7e2@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/oracle` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright year
 - 8266154

Changes: https://git.openjdk.java.net/jdk/pull/3733/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3733&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266154
  Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3733.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3733/head:pull/3733

PR: https://git.openjdk.java.net/jdk/pull/3733

From github.com+168222+mgkwill at openjdk.java.net  Tue Apr 27 21:38:40 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 27 Apr 2021 21:38:40 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v9]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <MHIgI1xEu3p_uoLoexDwAIiP-QiXZcb6rde1DSvVyq0=.ad643299-2004-41d1-a216-e8856c92a454@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> 
> Benchmark                       Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
> 
>  
> Optimized:
> signum intrinsic patch
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:

  sviswa7 review
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/7d54845f..07054334

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=07-08

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Tue Apr 27 21:43:11 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 27 Apr 2021 21:43:11 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v9]
In-Reply-To: <MHIgI1xEu3p_uoLoexDwAIiP-QiXZcb6rde1DSvVyq0=.ad643299-2004-41d1-a216-e8856c92a454@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <MHIgI1xEu3p_uoLoexDwAIiP-QiXZcb6rde1DSvVyq0=.ad643299-2004-41d1-a216-e8856c92a454@github.com>
Message-ID: <C0dRIHhnA7OusgUV1mzT2xm0lp5k-lGuXo0vv65mg5E=.acbe66af-3586-4be4-b129-389926d60eb4@github.com>

On Tue, 27 Apr 2021 21:38:40 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:
> 
>   sviswa7 review
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Thanks for the review @sviswa7. 

I've updated to `StubRoutines::x86::float_sign_flip()` & `StubRoutines::x86::double_sign_flip()` as I was using when the code was in the src/hotspot/cpu/x86/x86.ad. If I understood your comment correctly this should use 128 bit aligned.

I've added comments as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Tue Apr 27 22:20:38 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Tue, 27 Apr 2021 22:20:38 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v10]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <etkBudiKaf-Zeezpu2jdOwJghi9qPZ-LqJdbopXzWHY=.49a3501f-47c4-409e-9afd-403cd818e64f@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> 
> Benchmark                       Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
> 
>  
> Optimized:
> signum intrinsic patch
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:

  Handle x86 float/dbl signflip
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/07054334..7044d9a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=08-09

  Stats: 29 lines in 1 file changed: 27 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From kvn at openjdk.java.net  Tue Apr 27 23:10:11 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 23:10:11 GMT
Subject: RFR: 8266149: mark hotspot compiler/startup tests which ignore VM
 flags
In-Reply-To: <k5ZA2wVRv2To3GUrN3hurdtC-NEyINiICXuab0nhVwo=.0c0aa660-2b4d-4179-8228-b03b3ced91ef@github.com>
References: <k5ZA2wVRv2To3GUrN3hurdtC-NEyINiICXuab0nhVwo=.0c0aa660-2b4d-4179-8228-b03b3ced91ef@github.com>
Message-ID: <SLYiBbfQhtKS5AoCgHjETiOtBhyLBSXY3SPP2ti-LzY=.a92fdf5c-0a4f-44ed-bd6f-f08867b22f59@github.com>

On Tue, 27 Apr 2021 21:08:22 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/startup` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3729

From kvn at openjdk.java.net  Tue Apr 27 23:10:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 23:10:46 GMT
Subject: RFR: 8266153: mark hotspot compiler/onSpinWait tests which ignore
 VM flags
In-Reply-To: <khyvkfkYW6Hk7gfSFHUocbgCBJY64VjEJ8raVr1F9LU=.fba30b70-fddf-4eea-ab31-1c124211cea3@github.com>
References: <khyvkfkYW6Hk7gfSFHUocbgCBJY64VjEJ8raVr1F9LU=.fba30b70-fddf-4eea-ab31-1c124211cea3@github.com>
Message-ID: <Zs8ay1ZaL3sK6_Omr7wnDUYupcyKl6_3GTc_i5cI-Ks=.9bcb3627-2738-455e-97e3-755378e881dd@github.com>

On Tue, 27 Apr 2021 21:26:39 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/onSpinWait` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3731

From kvn at openjdk.java.net  Tue Apr 27 23:11:06 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 23:11:06 GMT
Subject: RFR: 8266150: mark hotspot compiler/arguments tests which ignore
 VM flags
In-Reply-To: <cAilxCYd8ocZQkzwSiMgEXJZccbmfMnnR8JasvMU0jg=.09b8a697-8523-4255-88ea-68c578791106@github.com>
References: <cAilxCYd8ocZQkzwSiMgEXJZccbmfMnnR8JasvMU0jg=.09b8a697-8523-4255-88ea-68c578791106@github.com>
Message-ID: <a9yCq8VG-7l8h-OBqyfiKBO17vf5TmK_fWvA4LN6Ons=.9cecaf9f-31ea-4e94-95c2-848ae7d85c6d@github.com>

On Tue, 27 Apr 2021 21:14:38 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/arguments` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3730

From kvn at openjdk.java.net  Tue Apr 27 23:11:00 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 23:11:00 GMT
Subject: RFR: 8266154: mark hotspot compiler/oracle tests which ignore VM
 flags
In-Reply-To: <2F21p8WiYXUzOBpkQSGaPBOLeleeMHOVaP1LJHvEjNg=.86c1b538-951d-4a9f-872c-38878446c7e2@github.com>
References: <2F21p8WiYXUzOBpkQSGaPBOLeleeMHOVaP1LJHvEjNg=.86c1b538-951d-4a9f-872c-38878446c7e2@github.com>
Message-ID: <yRD3rsRGRfHGJPqMGODYCzZ0KhfDE4hVKOcwYmOxjHg=.3be7d2a5-2b5d-489a-a6b2-0aa8bc3c8189@github.com>

On Tue, 27 Apr 2021 21:31:04 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/oracle` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3733

From jiefu at openjdk.java.net  Tue Apr 27 23:37:55 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 27 Apr 2021 23:37:55 GMT
Subject: RFR: 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)
In-Reply-To: <W8so2g4r-P7fGo444b_1cAcE6ovRuXOhBGjLTEK-SJo=.a083d3e4-a785-496d-8909-96b5e0db91ca@github.com>
References: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
 <W8so2g4r-P7fGo444b_1cAcE6ovRuXOhBGjLTEK-SJo=.a083d3e4-a785-496d-8909-96b5e0db91ca@github.com>
Message-ID: <cEv2yV_sVY5RG4G921OrJI5Qq3WaWtCEq0dPuARz-Y8=.e8120cf7-c748-4e20-bcfe-f78001d4e77a@github.com>

On Tue, 27 Apr 2021 16:45:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I am fine with your fix - it is rare case so we can skip 0 case. But we need to verify that Interpreter and stubs (and Java) give the same result for -0.0 in 32- and 64-bit VMs.
> 
> C code uses `if(hx>=0)` so what result will it give for `-0.0`? :
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L497
> 
> 64-bit stub code use Integer compare which should be fine I think:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L839
> 
> Java code adds `+0.0` to get correct result (would be nice to see what code C2 generates when it see such bytecode):
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/FdLibm.java#L364

Hi @vnkozlov ,

Thanks for your review.

The C code actually uses integer compare.
So I think it's fine otherwise non-x86 platforms would report errors.


As for the Java code, C2 will emit a `vaddsd` instruction.

Java method

  public static double test(double d) {
    return d + 0.0;
  }


Generated code by C2

000     B1: #   out( N1 ) <- BLOCK HEAD IS JUNK  Freq: 1
000     # stack bang (96 bytes)
        pushq   rbp     # Save rbp
        subq    rsp, #16        # Create frame

00c     # MachConstantBaseNode (empty encoding)
00c     vaddsd  XMM0, XMM0, [constant table base + #0]  # load from constant table: double=#0.000000
014     addq    rsp, 16 # Destroy frame
        popq    rbp
        cmpq     rsp, poll_offset[r15_thread]
        ja       #safepoint_stub        # Safepoint: poll for GC

026     ret

-------------

PR: https://git.openjdk.java.net/jdk/pull/3712

From sviswanathan at openjdk.java.net  Tue Apr 27 23:37:52 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 27 Apr 2021 23:37:52 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v9]
In-Reply-To: <C0dRIHhnA7OusgUV1mzT2xm0lp5k-lGuXo0vv65mg5E=.acbe66af-3586-4be4-b129-389926d60eb4@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <MHIgI1xEu3p_uoLoexDwAIiP-QiXZcb6rde1DSvVyq0=.ad643299-2004-41d1-a216-e8856c92a454@github.com>
 <C0dRIHhnA7OusgUV1mzT2xm0lp5k-lGuXo0vv65mg5E=.acbe66af-3586-4be4-b129-389926d60eb4@github.com>
Message-ID: <UmhXENZfFgtciem6GXBrjHmjTHD5IzQv3qhLGek44HY=.b6509486-d9d1-4a99-ad77-e9fc2a54bd82@github.com>

On Tue, 27 Apr 2021 21:40:24 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sviswa7 review
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Thanks for the review @sviswa7. 
> 
> I've updated to `StubRoutines::x86::float_sign_flip()` & `StubRoutines::x86::double_sign_flip()` as I was using when the code was in the src/hotspot/cpu/x86/x86.ad. If I understood your comment correctly this should use 128 bit aligned.
> 
> I've added comments as suggested.

@mgkwill I was wrong. It looks like the CodeEntryAlignment is set to 16 bytes i.e. 128 bits as minimum (globals_x86.hpp). So please continue to use the vector_float_sign_flip and vector_double_sign_flip masks. Xorps and xorpd are vector instructions and we should use the vector masks here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From jiefu at openjdk.java.net  Tue Apr 27 23:39:51 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 27 Apr 2021 23:39:51 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v3]
In-Reply-To: <f1xbNj7re8eD0W2am0p8I7rBjlUhKj8BW9dPSrRR7aI=.e87767a4-4cd8-4917-b4a4-99395b55fbce@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <aMkSkY_c1V94fMIzmMQtGYcUn3SHC2uzaDH5bs-ihdU=.509aed47-25ba-4c11-a642-06a524fdca21@github.com>
 <f1xbNj7re8eD0W2am0p8I7rBjlUhKj8BW9dPSrRR7aI=.e87767a4-4cd8-4917-b4a4-99395b55fbce@github.com>
Message-ID: <CDvATXD513S7yhALExWjmBi5MEuxybN0nIWZ4zLVwJc=.f89b57f3-30a3-4a0f-ae18-c9f90cf2f21b@github.com>

On Tue, 27 Apr 2021 12:23:59 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good to me.

Thanks @TobiHartmann .

@vnkozlov , are you OK with the latest change?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From kvn at openjdk.java.net  Tue Apr 27 23:53:56 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 23:53:56 GMT
Subject: RFR: 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)
In-Reply-To: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
References: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
Message-ID: <BOGYapOc8hTNH7hJPSIFvo6I1Pl2TSo9VKsPn9FZSRA=.e35b3873-782a-4dbd-b8d1-391aa25b0dee@github.com>

On Tue, 27 Apr 2021 08:29:04 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> C2 computes -0.0 for Math.pow(-0.0, 0.5) which should be 0.0 according to the API specs.
> This bug was found while I was implementing the same optimization for x86_32 (JDK-8265940).
> 
> The reason is that CmpDNode [1] doesn't distinguish -0.0 from 0.0.
> Math.pow(-0.0, 0.5) was replaced with Math.sqrt(-0.0) incorrectly since CmpDNode says -0.0 < 0.0 if false.
> 
> The fix excludes C2's optimization for x=0.0/-0.0. 
> And the jtreg test has been improved to make sure the corner cases are covered by the compilers.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1656

Good. Thank you for checking other places.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3712

From iignatyev at openjdk.java.net  Tue Apr 27 23:54:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 23:54:55 GMT
Subject: RFR: 8266154: mark hotspot compiler/oracle tests which ignore VM
 flags
In-Reply-To: <2F21p8WiYXUzOBpkQSGaPBOLeleeMHOVaP1LJHvEjNg=.86c1b538-951d-4a9f-872c-38878446c7e2@github.com>
References: <2F21p8WiYXUzOBpkQSGaPBOLeleeMHOVaP1LJHvEjNg=.86c1b538-951d-4a9f-872c-38878446c7e2@github.com>
Message-ID: <LDCWEuXXnLYAYlUhghIrV38opBhssbhnfxC37HeNcDk=.eb82e6af-56f8-4013-ac71-918d5d71a004@github.com>

On Tue, 27 Apr 2021 21:31:04 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/oracle` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3733

From iignatyev at openjdk.java.net  Tue Apr 27 23:54:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 23:54:55 GMT
Subject: Integrated: 8266154: mark hotspot compiler/oracle tests which ignore
 VM flags
In-Reply-To: <2F21p8WiYXUzOBpkQSGaPBOLeleeMHOVaP1LJHvEjNg=.86c1b538-951d-4a9f-872c-38878446c7e2@github.com>
References: <2F21p8WiYXUzOBpkQSGaPBOLeleeMHOVaP1LJHvEjNg=.86c1b538-951d-4a9f-872c-38878446c7e2@github.com>
Message-ID: <iGHdLiDqpqOZ0I0huH-8d62SUtac5Eglh6bhUwrBeSs=.64ec11a7-88e2-4727-9b69-429348d2d49b@github.com>

On Tue, 27 Apr 2021 21:31:04 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/oracle` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: eb72950c
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eb72950cfd54eb39ac6f2d331d3e6ea860210a63
Stats:     5 lines in 3 files changed: 3 ins; 0 del; 2 mod

8266154: mark hotspot compiler/oracle tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3733

From iignatyev at openjdk.java.net  Tue Apr 27 23:57:57 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 23:57:57 GMT
Subject: RFR: 8266150: mark hotspot compiler/arguments tests which ignore
 VM flags
In-Reply-To: <cAilxCYd8ocZQkzwSiMgEXJZccbmfMnnR8JasvMU0jg=.09b8a697-8523-4255-88ea-68c578791106@github.com>
References: <cAilxCYd8ocZQkzwSiMgEXJZccbmfMnnR8JasvMU0jg=.09b8a697-8523-4255-88ea-68c578791106@github.com>
Message-ID: <x8SGgrA0ilxgv6GGsRlfF3VhNbw4ahxSoeyG5JeO41A=.64d171f6-4512-41bf-8098-60252d460a20@github.com>

On Tue, 27 Apr 2021 21:14:38 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/arguments` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3730

From iignatyev at openjdk.java.net  Tue Apr 27 23:57:58 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 23:57:58 GMT
Subject: RFR: 8266149: mark hotspot compiler/startup tests which ignore VM
 flags
In-Reply-To: <k5ZA2wVRv2To3GUrN3hurdtC-NEyINiICXuab0nhVwo=.0c0aa660-2b4d-4179-8228-b03b3ced91ef@github.com>
References: <k5ZA2wVRv2To3GUrN3hurdtC-NEyINiICXuab0nhVwo=.0c0aa660-2b4d-4179-8228-b03b3ced91ef@github.com>
Message-ID: <MXwzkRK8g3zzinirraqJtx4Pa4ZRYpstPtpNcQd-Y4o=.fd947767-f49c-475c-afc8-362d1c31f153@github.com>

On Tue, 27 Apr 2021 21:08:22 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/startup` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3729

From iignatyev at openjdk.java.net  Tue Apr 27 23:57:59 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 23:57:59 GMT
Subject: Integrated: 8266149: mark hotspot compiler/startup tests which ignore
 VM flags
In-Reply-To: <k5ZA2wVRv2To3GUrN3hurdtC-NEyINiICXuab0nhVwo=.0c0aa660-2b4d-4179-8228-b03b3ced91ef@github.com>
References: <k5ZA2wVRv2To3GUrN3hurdtC-NEyINiICXuab0nhVwo=.0c0aa660-2b4d-4179-8228-b03b3ced91ef@github.com>
Message-ID: <zsfupK7M5UMl1C0LN5ZnSvyWKlmgxAqmedFOvXMxp28=.d051c5ca-139d-4b69-94e9-cb808cedb37a@github.com>

On Tue, 27 Apr 2021 21:08:22 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/startup` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: feb18d29
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/feb18d292f9fa22ff55e8db7dd0ed4af5c03a38f
Stats:     6 lines in 3 files changed: 3 ins; 0 del; 3 mod

8266149: mark hotspot compiler/startup tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3729

From iignatyev at openjdk.java.net  Tue Apr 27 23:57:59 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Apr 2021 23:57:59 GMT
Subject: Integrated: 8266150: mark hotspot compiler/arguments tests which
 ignore VM flags
In-Reply-To: <cAilxCYd8ocZQkzwSiMgEXJZccbmfMnnR8JasvMU0jg=.09b8a697-8523-4255-88ea-68c578791106@github.com>
References: <cAilxCYd8ocZQkzwSiMgEXJZccbmfMnnR8JasvMU0jg=.09b8a697-8523-4255-88ea-68c578791106@github.com>
Message-ID: <nkKXrEPn1C9d8Jfua-N3XyDUHImrH8BUMRR_7aSkCOc=.e2860c54-23da-40b6-823e-ac3b54cc5969@github.com>

On Tue, 27 Apr 2021 21:14:38 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/arguments` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: eeddb303
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eeddb3034494a463a929048d2e030938e75f37f8
Stats:     16 lines in 9 files changed: 12 ins; 0 del; 4 mod

8266150: mark hotspot compiler/arguments tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3730

From iignatyev at openjdk.java.net  Wed Apr 28 00:01:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 00:01:52 GMT
Subject: RFR: 8266153: mark hotspot compiler/onSpinWait tests which ignore
 VM flags
In-Reply-To: <khyvkfkYW6Hk7gfSFHUocbgCBJY64VjEJ8raVr1F9LU=.fba30b70-fddf-4eea-ab31-1c124211cea3@github.com>
References: <khyvkfkYW6Hk7gfSFHUocbgCBJY64VjEJ8raVr1F9LU=.fba30b70-fddf-4eea-ab31-1c124211cea3@github.com>
Message-ID: <wK_SblD8v4qpzGLkfwXj2SPV8B3nQRrIIqOmniqUiMc=.258dfaab-0ce8-40a0-8847-7970ba4f0df2@github.com>

On Tue, 27 Apr 2021 21:26:39 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/onSpinWait` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3731

From iignatyev at openjdk.java.net  Wed Apr 28 00:01:53 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 00:01:53 GMT
Subject: Integrated: 8266153: mark hotspot compiler/onSpinWait tests which
 ignore VM flags
In-Reply-To: <khyvkfkYW6Hk7gfSFHUocbgCBJY64VjEJ8raVr1F9LU=.fba30b70-fddf-4eea-ab31-1c124211cea3@github.com>
References: <khyvkfkYW6Hk7gfSFHUocbgCBJY64VjEJ8raVr1F9LU=.fba30b70-fddf-4eea-ab31-1c124211cea3@github.com>
Message-ID: <b9cyd1NDalwz--xhDYYCK5w9HZfqlc8KL1Znm8-RoA4=.12775b78-f81f-45aa-810c-477490f4d1e9@github.com>

On Tue, 27 Apr 2021 21:26:39 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/onSpinWait` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 30b13540
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/30b13540855dfdb9b39695eb8218b13e64b34894
Stats:     8 lines in 2 files changed: 4 ins; 0 del; 4 mod

8266153: mark hotspot compiler/onSpinWait tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3731

From iignatyev at openjdk.java.net  Wed Apr 28 00:24:18 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 00:24:18 GMT
Subject: RFR: 8266161: mark hotspot compiler/rtm tests which ignore VM flags
Message-ID: <Urn6qSCGLJj8mSZ2ImKGRfbldFViHWfsgeL_WlbLzVY=.4dcf6e74-b3dd-4c1e-9fae-e630bcf83729@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/rtm` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright year
 - 8266161: mark hotspot compiler/rtm tests which ignore VM flags

Changes: https://git.openjdk.java.net/jdk/pull/3736/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3736&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266161
  Stats: 34 lines in 17 files changed: 17 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3736.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3736/head:pull/3736

PR: https://git.openjdk.java.net/jdk/pull/3736

From iignatyev at openjdk.java.net  Wed Apr 28 00:31:04 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 00:31:04 GMT
Subject: RFR: 8266164: mark hotspot compiler/loopstripmining tests which
 ignore VM flags
Message-ID: <X2UHhOr-jnd9sJ4XLi5sd_xPat-NMt7egJy5drfvQ4Q=.37a2d550-4424-4553-accb-0f6442411bc3@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/loopstripmining` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - 8266164

Changes: https://git.openjdk.java.net/jdk/pull/3737/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3737&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266164
  Stats: 7 lines in 2 files changed: 3 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3737/head:pull/3737

PR: https://git.openjdk.java.net/jdk/pull/3737

From iignatyev at openjdk.java.net  Wed Apr 28 00:45:09 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 00:45:09 GMT
Subject: RFR: 8266166: mark hotspot compiler/linkage tests which ignore VM
 flags
Message-ID: <GOXl74w8GlnK1RYgYFRsm9Vs6RAR9foR_fYRUhFwFHs=.b42f6218-caac-40ae-81e5-a3ff963a97ed@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/linkage ` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright
 - 8266166

Changes: https://git.openjdk.java.net/jdk/pull/3738/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3738&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266166
  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3738.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3738/head:pull/3738

PR: https://git.openjdk.java.net/jdk/pull/3738

From iignatyev at openjdk.java.net  Wed Apr 28 01:09:07 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 01:09:07 GMT
Subject: RFR: 8266169: mark hotspot compiler/jvmci tests which ignore VM flags
Message-ID: <ydT0UYPAWqdSF3ybQx-JbrKjaqZVP6in5ix40KgjvJ0=.a6d18e5c-24bf-490e-9653-bd75432807a2@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/jvmci ` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright
 - 8266169

Changes: https://git.openjdk.java.net/jdk/pull/3739/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3739&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266169
  Stats: 19 lines in 4 files changed: 5 ins; 4 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3739.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3739/head:pull/3739

PR: https://git.openjdk.java.net/jdk/pull/3739

From iignatyev at openjdk.java.net  Wed Apr 28 01:16:01 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 01:16:01 GMT
Subject: RFR: 8266175: mark hotspot compiler/jsr292 tests which ignore VM flags
Message-ID: <xNwNgu4qdJFX9UUPtH_3Zgs_IFDFIjXmokU7Bm8-OY8=.2e5aef35-8632-49d4-8a76-cef5cc01bc1d@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/jsr292 ` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - copyright year
 - 8266175

Changes: https://git.openjdk.java.net/jdk/pull/3740/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3740&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266175
  Stats: 10 lines in 3 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3740.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3740/head:pull/3740

PR: https://git.openjdk.java.net/jdk/pull/3740

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 28 01:39:23 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 28 Apr 2021 01:39:23 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v11]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <vIEjf8vOWuaUlzkQyh5w1b4XcK9Mk-o9sPyPg6FDXGs=.0aabb462-8b05-4175-aff9-3266b55bc8ee@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> 
> Benchmark                       Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
> 
>  
> Optimized:
> signum intrinsic patch
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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 vector _sign_flip
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/7044d9a6..c3478950

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=09-10

  Stats: 29 lines in 1 file changed: 0 ins; 27 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 28 01:39:24 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 28 Apr 2021 01:39:24 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v9]
In-Reply-To: <C0dRIHhnA7OusgUV1mzT2xm0lp5k-lGuXo0vv65mg5E=.acbe66af-3586-4be4-b129-389926d60eb4@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <MHIgI1xEu3p_uoLoexDwAIiP-QiXZcb6rde1DSvVyq0=.ad643299-2004-41d1-a216-e8856c92a454@github.com>
 <C0dRIHhnA7OusgUV1mzT2xm0lp5k-lGuXo0vv65mg5E=.acbe66af-3586-4be4-b129-389926d60eb4@github.com>
Message-ID: <09seyLuNve6Sw3scAsRb18rKnrkcdPsmIyprf17tBNs=.14998c96-d2ed-44c0-99e1-e17f37d32d70@github.com>

On Tue, 27 Apr 2021 21:40:24 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sviswa7 review
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Thanks for the review @sviswa7. 
> 
> I've updated to `StubRoutines::x86::float_sign_flip()` & `StubRoutines::x86::double_sign_flip()` as I was using when the code was in the src/hotspot/cpu/x86/x86.ad. If I understood your comment correctly this should use 128 bit aligned.
> 
> I've added comments as suggested.

> @mgkwill I was wrong. It looks like the CodeEntryAlignment is set to 16 bytes i.e. 128 bits as minimum (globals_x86.hpp). So please continue to use the vector_float_sign_flip and vector_double_sign_flip masks. Xorps and xorpd are vector instructions and we should use the vector masks here.

Thanks @sviswa7. I've reverted to `StubRoutines::x86::vector_float_sign_flip(`) `StubRoutines::x86::vector_double_sign_flip()`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From sviswanathan at openjdk.java.net  Wed Apr 28 01:39:25 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 28 Apr 2021 01:39:25 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v10]
In-Reply-To: <etkBudiKaf-Zeezpu2jdOwJghi9qPZ-LqJdbopXzWHY=.49a3501f-47c4-409e-9afd-403cd818e64f@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <etkBudiKaf-Zeezpu2jdOwJghi9qPZ-LqJdbopXzWHY=.49a3501f-47c4-409e-9afd-403cd818e64f@github.com>
Message-ID: <5qYmiJljiuGzgble4BcC6uHd1xSHpewfwMqxpWmItJE=.4e7f68ec-9eb8-42db-95e1-4e2b38820cfd@github.com>

On Tue, 27 Apr 2021 22:20:38 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:
> 
>   Handle x86 float/dbl signflip
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Looks good to me. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From iignatyev at openjdk.java.net  Wed Apr 28 01:58:04 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 01:58:04 GMT
Subject: RFR: 8266180: compiler/vectorapi/TestVectorErgonomics should be run
 in driver mode
Message-ID: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>

Hi all,

could you please review this one-liner?

from JBS:
> `compiler/vectorapi/TestVectorErgonomics` class just spawns new JVMs and verifies their output, there is no need for `TestVectorErgonomics` to be run w/ all external flags.

Thanks,
-- Igor

-------------

Commit messages:
 - 8266180

Changes: https://git.openjdk.java.net/jdk/pull/3745/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3745&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266180
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3745.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3745/head:pull/3745

PR: https://git.openjdk.java.net/jdk/pull/3745

From jiefu at openjdk.java.net  Wed Apr 28 02:23:52 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Apr 2021 02:23:52 GMT
Subject: RFR: 8266180: compiler/vectorapi/TestVectorErgonomics should be
 run in driver mode
In-Reply-To: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
References: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
Message-ID: <47HVC78LmZqc7RTRPL615cXRVDLqF_QYCC8TtSwAghg=.429046ea-b169-4cb2-9797-553ded6e2385@github.com>

On Wed, 28 Apr 2021 01:50:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner?
> 
> from JBS:
>> `compiler/vectorapi/TestVectorErgonomics` class just spawns new JVMs and verifies their output, there is no need for `TestVectorErgonomics` to be run w/ all external flags.
> 
> Thanks,
> -- Igor

LGTM and trivial.
Thanks.

-------------

Marked as reviewed by jiefu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/3745

From iignatyev at openjdk.java.net  Wed Apr 28 02:25:07 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 02:25:07 GMT
Subject: RFR: 8266181: compiler/eliminateAutobox/TestEliminateBoxInDebugInfo
 should be in driver mode
Message-ID: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>

Hi all,

could you please review this small patch that switches the execution mode of TestEliminateBoxInDebugInfo to driver mode and makes a few small cleanups?

from JBS:
> TestEliminateBoxInDebugInfo creates a new JVM and verifies its output, hence it doesn't have to be run in the JDK in test configuration and can be run in driver mode.

Thanks,
-- Igor

-------------

Commit messages:
 - 8266181

Changes: https://git.openjdk.java.net/jdk/pull/3746/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3746&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266181
  Stats: 16 lines in 1 file changed: 0 ins; 11 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3746.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3746/head:pull/3746

PR: https://git.openjdk.java.net/jdk/pull/3746

From epavlova at openjdk.java.net  Wed Apr 28 02:26:48 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Wed, 28 Apr 2021 02:26:48 GMT
Subject: RFR: 8266180: compiler/vectorapi/TestVectorErgonomics should be
 run in driver mode
In-Reply-To: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
References: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
Message-ID: <EOf8_LQpS60RLOtZZ2VG7461DfzbjUr5khAgVUCV_6o=.d5b322cd-a53d-42bf-a064-9912aa3ce245@github.com>

On Wed, 28 Apr 2021 01:50:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner?
> 
> from JBS:
>> `compiler/vectorapi/TestVectorErgonomics` class just spawns new JVMs and verifies their output, there is no need for `TestVectorErgonomics` to be run w/ all external flags.
> 
> Thanks,
> -- Igor

Looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3745

From whuang at openjdk.java.net  Wed Apr 28 03:00:09 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Wed, 28 Apr 2021 03:00:09 GMT
Subject: RFR: 8265956: JVM crashes when matching LShiftVB Node
Message-ID: <0lX7U-sIV4c6Wi1Cyw3caRD6ZTVCIYzbiiji3uPXf4M=.c0494113-32c5-40c4-bdd7-93b226ffe236@github.com>

It is fount that the rule `match(Set dst (LShiftVB src shift))` is missing on many cpus, such like `aarch64` and `x86`. It is this reason that JVM will crash under `JDK-8265956`'s test case. In this commit, I :
* show the crash case `TestVectorShuffleIotaShort`
* solve the issue on `aarch64` and `x86` by adding the rule. 
* test after fixing on tire1~3

Thank you for your review. Any suggestion is welcome. 
                         Wang Huang

-------------

Commit messages:
 - 8265956: JVM crashes when matching LShiftVB Node

Changes: https://git.openjdk.java.net/jdk/pull/3747/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3747&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265956
  Stats: 202 lines in 5 files changed: 202 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3747/head:pull/3747

PR: https://git.openjdk.java.net/jdk/pull/3747

From kvn at openjdk.java.net  Wed Apr 28 03:00:53 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 03:00:53 GMT
Subject: RFR: 8266161: mark hotspot compiler/rtm tests which ignore VM
 flags
In-Reply-To: <Urn6qSCGLJj8mSZ2ImKGRfbldFViHWfsgeL_WlbLzVY=.4dcf6e74-b3dd-4c1e-9fae-e630bcf83729@github.com>
References: <Urn6qSCGLJj8mSZ2ImKGRfbldFViHWfsgeL_WlbLzVY=.4dcf6e74-b3dd-4c1e-9fae-e630bcf83729@github.com>
Message-ID: <orz2nrSrj_M9qOJlRSlfsNR_4Sy4Ta1GGyiEEi8ZLCs=.c9a2025a-d7ed-4a5e-a7e6-ba9776d0008b@github.com>

On Wed, 28 Apr 2021 00:16:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/rtm` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3736

From kvn at openjdk.java.net  Wed Apr 28 03:03:00 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 03:03:00 GMT
Subject: RFR: 8266164: mark hotspot compiler/loopstripmining tests which
 ignore VM flags
In-Reply-To: <X2UHhOr-jnd9sJ4XLi5sd_xPat-NMt7egJy5drfvQ4Q=.37a2d550-4424-4553-accb-0f6442411bc3@github.com>
References: <X2UHhOr-jnd9sJ4XLi5sd_xPat-NMt7egJy5drfvQ4Q=.37a2d550-4424-4553-accb-0f6442411bc3@github.com>
Message-ID: <1v1dfsT542faFuOZXAaFlOIZtX24mGlXcgwjpcCccLk=.a230b6e8-dcba-4c03-9286-703d5738196e@github.com>

On Wed, 28 Apr 2021 00:24:34 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/loopstripmining` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3737

From kvn at openjdk.java.net  Wed Apr 28 03:03:53 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 03:03:53 GMT
Subject: RFR: 8266166: mark hotspot compiler/linkage tests which ignore VM
 flags
In-Reply-To: <GOXl74w8GlnK1RYgYFRsm9Vs6RAR9foR_fYRUhFwFHs=.b42f6218-caac-40ae-81e5-a3ff963a97ed@github.com>
References: <GOXl74w8GlnK1RYgYFRsm9Vs6RAR9foR_fYRUhFwFHs=.b42f6218-caac-40ae-81e5-a3ff963a97ed@github.com>
Message-ID: <kj48XKZm56fagRnrVhwwkP-UNJGJbnOKVpO42kd7unQ=.a5d03092-0d1c-4e7b-ac36-52187e27bb19@github.com>

On Wed, 28 Apr 2021 00:37:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/linkage ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3738

From kvn at openjdk.java.net  Wed Apr 28 03:04:50 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 03:04:50 GMT
Subject: RFR: 8266169: mark hotspot compiler/jvmci tests which ignore VM
 flags
In-Reply-To: <ydT0UYPAWqdSF3ybQx-JbrKjaqZVP6in5ix40KgjvJ0=.a6d18e5c-24bf-490e-9653-bd75432807a2@github.com>
References: <ydT0UYPAWqdSF3ybQx-JbrKjaqZVP6in5ix40KgjvJ0=.a6d18e5c-24bf-490e-9653-bd75432807a2@github.com>
Message-ID: <LIRk4vIBavZdtCwUJqrpIpC-VA-r_P4PGYo3p-Qe_Y0=.4ba99293-80c0-4899-bdd2-e6a3fb0f4945@github.com>

On Wed, 28 Apr 2021 01:00:37 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/jvmci ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3739

From kvn at openjdk.java.net  Wed Apr 28 03:05:50 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 03:05:50 GMT
Subject: RFR: 8266175: mark hotspot compiler/jsr292 tests which ignore VM
 flags
In-Reply-To: <xNwNgu4qdJFX9UUPtH_3Zgs_IFDFIjXmokU7Bm8-OY8=.2e5aef35-8632-49d4-8a76-cef5cc01bc1d@github.com>
References: <xNwNgu4qdJFX9UUPtH_3Zgs_IFDFIjXmokU7Bm8-OY8=.2e5aef35-8632-49d4-8a76-cef5cc01bc1d@github.com>
Message-ID: <d1n8OdHzuHI9de-e7ZOM6eGPsw10RvNngFJRNc2chIg=.3d57b51c-5da9-467d-8946-1490b1ecd494@github.com>

On Wed, 28 Apr 2021 01:09:07 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/jsr292 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3740

From kvn at openjdk.java.net  Wed Apr 28 03:07:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 03:07:51 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v3]
In-Reply-To: <aMkSkY_c1V94fMIzmMQtGYcUn3SHC2uzaDH5bs-ihdU=.509aed47-25ba-4c11-a642-06a524fdca21@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <aMkSkY_c1V94fMIzmMQtGYcUn3SHC2uzaDH5bs-ihdU=.509aed47-25ba-4c11-a642-06a524fdca21@github.com>
Message-ID: <sKyVwLUMMeIygBnJ_XbPcXHvsDZOrAvKTE74oD8B2kY=.fd979ed0-f784-457d-a993-b3a3e02c87cd@github.com>

On Tue, 27 Apr 2021 11:09:05 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
>> 
>> E.g., for Math.pow(1.0 / 2047, 2.0):
>> 
>> interpreter: 2.38651580386563E-7 
>>          C2: 2.3865158038656307E-7
>> 
>> 
>> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
>> However, there is no such optimization for interpreter/C1 on x86_32.
>> 
>> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
>> And we don't have a plan to implement such opt on x86_32.
>> 
>> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add align attribute for 2.0

Latest version with alignment is good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3677

From kvn at openjdk.java.net  Wed Apr 28 03:08:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 03:08:51 GMT
Subject: RFR: 8266180: compiler/vectorapi/TestVectorErgonomics should be
 run in driver mode
In-Reply-To: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
References: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
Message-ID: <94B23jqHxZOpmnOPI4WG-E1yv-Q4Dy9yZ-JuXTV0YKo=.6f5c2cd6-aa38-41ae-ba44-047e3ed69587@github.com>

On Wed, 28 Apr 2021 01:50:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner?
> 
> from JBS:
>> `compiler/vectorapi/TestVectorErgonomics` class just spawns new JVMs and verifies their output, there is no need for `TestVectorErgonomics` to be run w/ all external flags.
> 
> Thanks,
> -- Igor

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3745

From jiefu at openjdk.java.net  Wed Apr 28 03:14:53 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Apr 2021 03:14:53 GMT
Subject: RFR: 8265917: Different values computed by C2 and interpreter/C1
 for Math.pow(x, 2.0) on x86_32 [v3]
In-Reply-To: <sKyVwLUMMeIygBnJ_XbPcXHvsDZOrAvKTE74oD8B2kY=.fd979ed0-f784-457d-a993-b3a3e02c87cd@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
 <aMkSkY_c1V94fMIzmMQtGYcUn3SHC2uzaDH5bs-ihdU=.509aed47-25ba-4c11-a642-06a524fdca21@github.com>
 <sKyVwLUMMeIygBnJ_XbPcXHvsDZOrAvKTE74oD8B2kY=.fd979ed0-f784-457d-a993-b3a3e02c87cd@github.com>
Message-ID: <wk6fGVxvyGDvYYVQKX4Po2-faopYTMwEuHWCMPNSXoA=.62b4f6c9-d051-460c-a572-5d66686771b7@github.com>

On Wed, 28 Apr 2021 03:04:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Latest version with alignment is good.

Thanks @vnkozlov .

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From jiefu at openjdk.java.net  Wed Apr 28 03:14:55 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Apr 2021 03:14:55 GMT
Subject: Integrated: 8265917: Different values computed by C2 and
 interpreter/C1 for Math.pow(x, 2.0) on x86_32
In-Reply-To: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
References: <mI2zBEpwuJXpTnWV5KlbcB7BJo-IFHoEENXVbxyfvbk=.01314273-7607-4eec-b91c-a40148a5b78c@github.com>
Message-ID: <E2d8auBzR4ekqJQnShhi9PSTuPq49bjjCRP7O1D8Cbg=.40f9f502-f816-4ccf-95bb-46dbe89081cb@github.com>

On Sun, 25 Apr 2021 11:39:43 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
> 
> E.g., for Math.pow(1.0 / 2047, 2.0):
> 
> interpreter: 2.38651580386563E-7 
>          C2: 2.3865158038656307E-7
> 
> 
> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
> However, there is no such optimization for interpreter/C1 on x86_32.
> 
> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
> And we don't have a plan to implement such opt on x86_32.
> 
> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 889d2466
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/889d246681e937af1fa8d97f683c49043ddf2eda
Stats:     66 lines in 2 files changed: 66 ins; 0 del; 0 mod

8265917: Different values computed by C2 and interpreter/C1 for Math.pow(x, 2.0) on x86_32

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3677

From kvn at openjdk.java.net  Wed Apr 28 03:18:48 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 03:18:48 GMT
Subject: RFR: 8266181:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo should be in driver
 mode
In-Reply-To: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
References: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
Message-ID: <ygi4TXravP-BkxwOpmy_abwmxMf9LKsRlrQZ-uyl5dE=.80368dd5-23ff-4180-8f3d-115478c3198b@github.com>

On Wed, 28 Apr 2021 02:18:20 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that switches the execution mode of TestEliminateBoxInDebugInfo to driver mode and makes a few small cleanups?
> 
> from JBS:
>> TestEliminateBoxInDebugInfo creates a new JVM and verifies its output, hence it doesn't have to be run in the JDK in test configuration and can be run in driver mode.
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3746

From iignatyev at openjdk.java.net  Wed Apr 28 03:38:18 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:38:18 GMT
Subject: RFR: 8266181:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo should be in driver
 mode [v2]
In-Reply-To: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
References: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
Message-ID: <42y92SG5Aoe4z5UXrmhy4CoEvI51VLD80LvTwwxAN6M=.2b5bb79b-6bef-43dc-a310-bf852c8188f9@github.com>

> Hi all,
> 
> could you please review this small patch that switches the execution mode of TestEliminateBoxInDebugInfo to driver mode and makes a few small cleanups?
> 
> from JBS:
>> TestEliminateBoxInDebugInfo creates a new JVM and verifies its output, hence it doesn't have to be run in the JDK in test configuration and can be run in driver mode.
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:

  fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3746/files
  - new: https://git.openjdk.java.net/jdk/pull/3746/files/f81ef29d..30800044

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3746&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3746&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3746.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3746/head:pull/3746

PR: https://git.openjdk.java.net/jdk/pull/3746

From iignatyev at openjdk.java.net  Wed Apr 28 03:38:19 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:38:19 GMT
Subject: RFR: 8266181:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo should be in driver
 mode
In-Reply-To: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
References: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
Message-ID: <XgcAOmVA3T095O4PS2G0fqD3OOaTFx9t2ZGKCt844Zc=.60885957-fdb7-4afc-b053-adac7f12f6a4@github.com>

On Wed, 28 Apr 2021 02:18:20 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that switches the execution mode of TestEliminateBoxInDebugInfo to driver mode and makes a few small cleanups?
> 
> from JBS:
>> TestEliminateBoxInDebugInfo creates a new JVM and verifies its output, hence it doesn't have to be run in the JDK in test configuration and can be run in driver mode.
> 
> Thanks,
> -- Igor

I realized that a) I should have used `OutputAnalyzer::stdoutShouldMatch`; b) there is no need to use a regexp here; c) we don't check the exit code. the latest patch addresses this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3746

From iignatyev at openjdk.java.net  Wed Apr 28 03:40:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:40:52 GMT
Subject: RFR: 8266180: compiler/vectorapi/TestVectorErgonomics should be
 run in driver mode
In-Reply-To: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
References: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
Message-ID: <E7DDaOT0weBZJPKEVgyKpIUWXRZ98pxxNDdHxMAjOh8=.c8083999-ec7e-4a99-833e-a09fcaf819b0@github.com>

On Wed, 28 Apr 2021 01:50:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner?
> 
> from JBS:
>> `compiler/vectorapi/TestVectorErgonomics` class just spawns new JVMs and verifies their output, there is no need for `TestVectorErgonomics` to be run w/ all external flags.
> 
> Thanks,
> -- Igor

Jie, Katya, Vladimir, thank you for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3745

From iignatyev at openjdk.java.net  Wed Apr 28 03:41:53 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:41:53 GMT
Subject: RFR: 8266169: mark hotspot compiler/jvmci tests which ignore VM
 flags
In-Reply-To: <ydT0UYPAWqdSF3ybQx-JbrKjaqZVP6in5ix40KgjvJ0=.a6d18e5c-24bf-490e-9653-bd75432807a2@github.com>
References: <ydT0UYPAWqdSF3ybQx-JbrKjaqZVP6in5ix40KgjvJ0=.a6d18e5c-24bf-490e-9653-bd75432807a2@github.com>
Message-ID: <_3Jzhbn8KqqmOySC9Tt6yTkHuqMIrkcJNpHrAqAA67I=.8a0d23b4-c0fe-43c1-a0fc-97b0baaed039@github.com>

On Wed, 28 Apr 2021 01:00:37 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/jvmci ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

thank you, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3739

From iignatyev at openjdk.java.net  Wed Apr 28 03:42:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:42:55 GMT
Subject: RFR: 8266164: mark hotspot compiler/loopstripmining tests which
 ignore VM flags
In-Reply-To: <X2UHhOr-jnd9sJ4XLi5sd_xPat-NMt7egJy5drfvQ4Q=.37a2d550-4424-4553-accb-0f6442411bc3@github.com>
References: <X2UHhOr-jnd9sJ4XLi5sd_xPat-NMt7egJy5drfvQ4Q=.37a2d550-4424-4553-accb-0f6442411bc3@github.com>
Message-ID: <Msyfy-Q9A9f1aw4QJMn5cijvzfqtCzJTd9l6zrTCeuo=.96ecba93-bd8a-41f7-82e9-49aa7c031e6c@github.com>

On Wed, 28 Apr 2021 00:24:34 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/loopstripmining` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

thank you, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3737

From iignatyev at openjdk.java.net  Wed Apr 28 03:42:56 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:42:56 GMT
Subject: Integrated: 8266164: mark hotspot compiler/loopstripmining tests
 which ignore VM flags
In-Reply-To: <X2UHhOr-jnd9sJ4XLi5sd_xPat-NMt7egJy5drfvQ4Q=.37a2d550-4424-4553-accb-0f6442411bc3@github.com>
References: <X2UHhOr-jnd9sJ4XLi5sd_xPat-NMt7egJy5drfvQ4Q=.37a2d550-4424-4553-accb-0f6442411bc3@github.com>
Message-ID: <KlCsYA5ruFJIM8z8jd0Qc-oKuKvA-XtnXPrnNYvhQnA=.df65efae-cb64-4181-aa94-a4550e9687d5@github.com>

On Wed, 28 Apr 2021 00:24:34 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/loopstripmining` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 5ee58b04
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5ee58b0496c517ac75c28e1841e354bb9a42711d
Stats:     7 lines in 2 files changed: 3 ins; 4 del; 0 mod

8266164: mark hotspot compiler/loopstripmining tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3737

From iignatyev at openjdk.java.net  Wed Apr 28 03:43:02 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:43:02 GMT
Subject: RFR: 8266161: mark hotspot compiler/rtm tests which ignore VM
 flags
In-Reply-To: <Urn6qSCGLJj8mSZ2ImKGRfbldFViHWfsgeL_WlbLzVY=.4dcf6e74-b3dd-4c1e-9fae-e630bcf83729@github.com>
References: <Urn6qSCGLJj8mSZ2ImKGRfbldFViHWfsgeL_WlbLzVY=.4dcf6e74-b3dd-4c1e-9fae-e630bcf83729@github.com>
Message-ID: <XHII9Na03TGKnPPzTKCpA-pidovMn4wG1uPFtDsmg08=.618a54a2-5861-44b2-9bae-32f8099fefb1@github.com>

On Wed, 28 Apr 2021 00:16:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/rtm` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

thank you, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3736

From kvn at openjdk.java.net  Wed Apr 28 03:43:55 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 03:43:55 GMT
Subject: RFR: 8266181:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo should be in driver
 mode [v2]
In-Reply-To: <42y92SG5Aoe4z5UXrmhy4CoEvI51VLD80LvTwwxAN6M=.2b5bb79b-6bef-43dc-a310-bf852c8188f9@github.com>
References: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
 <42y92SG5Aoe4z5UXrmhy4CoEvI51VLD80LvTwwxAN6M=.2b5bb79b-6bef-43dc-a310-bf852c8188f9@github.com>
Message-ID: <mDYpepYP4g8EFSlLNi4rVp7imPGLnHly0_Z0L7iGq38=.d15ea4ca-e7a1-49bd-a293-2cd795a86cb1@github.com>

On Wed, 28 Apr 2021 03:38:18 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small patch that switches the execution mode of TestEliminateBoxInDebugInfo to driver mode and makes a few small cleanups?
>> 
>> from JBS:
>>> TestEliminateBoxInDebugInfo creates a new JVM and verifies its output, hence it doesn't have to be run in the JDK in test configuration and can be run in driver mode.
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Still good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3746

From iignatyev at openjdk.java.net  Wed Apr 28 03:44:00 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:44:00 GMT
Subject: Integrated: 8266166: mark hotspot compiler/linkage tests which ignore
 VM flags
In-Reply-To: <GOXl74w8GlnK1RYgYFRsm9Vs6RAR9foR_fYRUhFwFHs=.b42f6218-caac-40ae-81e5-a3ff963a97ed@github.com>
References: <GOXl74w8GlnK1RYgYFRsm9Vs6RAR9foR_fYRUhFwFHs=.b42f6218-caac-40ae-81e5-a3ff963a97ed@github.com>
Message-ID: <qDyMNU-fxTGxOTtNkBeFyaHuYu9RWbazF2DxmLu8DRk=.ab5fcc31-fc21-4c00-b347-a8f9b5f6d3da@github.com>

On Wed, 28 Apr 2021 00:37:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/linkage ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 1a2a570c
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1a2a570c8daabdd1a563fd6c890df791b8cbe3f7
Stats:     4 lines in 1 file changed: 0 ins; 1 del; 3 mod

8266166: mark hotspot compiler/linkage tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3738

From iignatyev at openjdk.java.net  Wed Apr 28 03:44:00 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:44:00 GMT
Subject: RFR: 8266166: mark hotspot compiler/linkage tests which ignore VM
 flags
In-Reply-To: <GOXl74w8GlnK1RYgYFRsm9Vs6RAR9foR_fYRUhFwFHs=.b42f6218-caac-40ae-81e5-a3ff963a97ed@github.com>
References: <GOXl74w8GlnK1RYgYFRsm9Vs6RAR9foR_fYRUhFwFHs=.b42f6218-caac-40ae-81e5-a3ff963a97ed@github.com>
Message-ID: <ABMy6D0O3QkJtsyVhKAMPibduaEuSHrhurs75DPeQx8=.ab5086f2-04d7-4d33-ad68-b0f4813395bb@github.com>

On Wed, 28 Apr 2021 00:37:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/linkage ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

thank you, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3738

From iignatyev at openjdk.java.net  Wed Apr 28 03:44:56 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:44:56 GMT
Subject: RFR: 8266175: mark hotspot compiler/jsr292 tests which ignore VM
 flags
In-Reply-To: <xNwNgu4qdJFX9UUPtH_3Zgs_IFDFIjXmokU7Bm8-OY8=.2e5aef35-8632-49d4-8a76-cef5cc01bc1d@github.com>
References: <xNwNgu4qdJFX9UUPtH_3Zgs_IFDFIjXmokU7Bm8-OY8=.2e5aef35-8632-49d4-8a76-cef5cc01bc1d@github.com>
Message-ID: <jo5t1iJqwoTrZ3O6LXd9EvL8d6RDDVsBAWiUZ70Umeg=.6665da74-a0ed-4bbb-b12d-f67bffa61122@github.com>

On Wed, 28 Apr 2021 01:09:07 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/jsr292 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

thank you, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3740

From iignatyev at openjdk.java.net  Wed Apr 28 03:44:57 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:44:57 GMT
Subject: Integrated: 8266175: mark hotspot compiler/jsr292 tests which ignore
 VM flags
In-Reply-To: <xNwNgu4qdJFX9UUPtH_3Zgs_IFDFIjXmokU7Bm8-OY8=.2e5aef35-8632-49d4-8a76-cef5cc01bc1d@github.com>
References: <xNwNgu4qdJFX9UUPtH_3Zgs_IFDFIjXmokU7Bm8-OY8=.2e5aef35-8632-49d4-8a76-cef5cc01bc1d@github.com>
Message-ID: <Grf2VOlCqkkM2Ts3qdr3cKqtS2WX03_W_FO4vlSN2mo=.8b221ce8-b8e3-47c4-9cf4-b5931accb5ea@github.com>

On Wed, 28 Apr 2021 01:09:07 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/jsr292 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 0601aba5
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0601aba545432a9df7b2347daf7342953b36046f
Stats:     10 lines in 3 files changed: 5 ins; 0 del; 5 mod

8266175: mark hotspot compiler/jsr292 tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3740

From iignatyev at openjdk.java.net  Wed Apr 28 03:44:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:44:54 GMT
Subject: Integrated: 8266169: mark hotspot compiler/jvmci tests which ignore
 VM flags
In-Reply-To: <ydT0UYPAWqdSF3ybQx-JbrKjaqZVP6in5ix40KgjvJ0=.a6d18e5c-24bf-490e-9653-bd75432807a2@github.com>
References: <ydT0UYPAWqdSF3ybQx-JbrKjaqZVP6in5ix40KgjvJ0=.a6d18e5c-24bf-490e-9653-bd75432807a2@github.com>
Message-ID: <n8wxXAGgzIjsGZSGQWC6cfmQ97zQhVix75_6sHKZQ5Q=.faf52f66-9ad2-477b-a7ab-9879c92828ce@github.com>

On Wed, 28 Apr 2021 01:00:37 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/jvmci ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 69ad8ac5
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/69ad8ac537419caba72b369d1e3fb5f575e55061
Stats:     19 lines in 4 files changed: 5 ins; 4 del; 10 mod

8266169: mark hotspot compiler/jvmci tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3739

From iignatyev at openjdk.java.net  Wed Apr 28 03:46:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:46:54 GMT
Subject: Integrated: 8266161: mark hotspot compiler/rtm tests which ignore VM
 flags
In-Reply-To: <Urn6qSCGLJj8mSZ2ImKGRfbldFViHWfsgeL_WlbLzVY=.4dcf6e74-b3dd-4c1e-9fae-e630bcf83729@github.com>
References: <Urn6qSCGLJj8mSZ2ImKGRfbldFViHWfsgeL_WlbLzVY=.4dcf6e74-b3dd-4c1e-9fae-e630bcf83729@github.com>
Message-ID: <ew0hgQvVx6VQCCbF_xo_wv0zQiK3qyl65FxYWClFDCs=.d352c65c-7af2-45ed-8fba-ac6dfa1b4ca5@github.com>

On Wed, 28 Apr 2021 00:16:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/rtm` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 81b15027
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81b1502701e70c98d3d6a763808a3ae6f2dc8739
Stats:     34 lines in 17 files changed: 17 ins; 0 del; 17 mod

8266161: mark hotspot compiler/rtm tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3736

From iignatyev at openjdk.java.net  Wed Apr 28 03:46:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 03:46:55 GMT
Subject: Integrated: 8266180: compiler/vectorapi/TestVectorErgonomics should
 be run in driver mode
In-Reply-To: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
References: <fpo2FJ94ZJCWfi4nAEGuCrzoff3jMZ-GclUtdqnmwDE=.55350e4a-8738-4fb3-94c3-02e114df036a@github.com>
Message-ID: <ZqyYKIYwsNwOYd02Oxy_JoI4HUDPfr22o-mcYJhKAZ0=.fed25d83-7f86-45a0-b237-04ebeead2c7d@github.com>

On Wed, 28 Apr 2021 01:50:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner?
> 
> from JBS:
>> `compiler/vectorapi/TestVectorErgonomics` class just spawns new JVMs and verifies their output, there is no need for `TestVectorErgonomics` to be run w/ all external flags.
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 4a8324d4
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4a8324d48b0c64964aa75d1198a340ba4f58adac
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8266180: compiler/vectorapi/TestVectorErgonomics should be run in driver mode

Reviewed-by: jiefu, kvn, epavlova

-------------

PR: https://git.openjdk.java.net/jdk/pull/3745

From iignatyev at openjdk.java.net  Wed Apr 28 04:04:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 04:04:52 GMT
Subject: RFR: 8266181:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo should be in driver
 mode [v2]
In-Reply-To: <42y92SG5Aoe4z5UXrmhy4CoEvI51VLD80LvTwwxAN6M=.2b5bb79b-6bef-43dc-a310-bf852c8188f9@github.com>
References: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
 <42y92SG5Aoe4z5UXrmhy4CoEvI51VLD80LvTwwxAN6M=.2b5bb79b-6bef-43dc-a310-bf852c8188f9@github.com>
Message-ID: <cfKi7nGmRjsDVI-uyjKHgkMsFVN_89mhCUnTJrMND9s=.643bf536-1260-491d-ab3c-1cc41f72f128@github.com>

On Wed, 28 Apr 2021 03:38:18 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small patch that switches the execution mode of TestEliminateBoxInDebugInfo to driver mode and makes a few small cleanups?
>> 
>> from JBS:
>>> TestEliminateBoxInDebugInfo creates a new JVM and verifies its output, hence it doesn't have to be run in the JDK in test configuration and can be run in driver mode.
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

thanks, Vladimir!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3746

From iignatyev at openjdk.java.net  Wed Apr 28 04:04:53 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 04:04:53 GMT
Subject: Integrated: 8266181:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo should be in driver
 mode
In-Reply-To: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
References: <yc6hBqzJud7QzYv92EmCTZKnMHnG8mDbxSNLSv7-dkA=.f4191b73-2cc5-48d8-8b34-f36aa42735b3@github.com>
Message-ID: <MCbE1YYx2coN4YJfJyL-JCVFg2O-Y2WgN-cdSs1ssBk=.6339e1bb-d5c0-472a-bbfa-a7501a27655c@github.com>

On Wed, 28 Apr 2021 02:18:20 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that switches the execution mode of TestEliminateBoxInDebugInfo to driver mode and makes a few small cleanups?
> 
> from JBS:
>> TestEliminateBoxInDebugInfo creates a new JVM and verifies its output, hence it doesn't have to be run in the JDK in test configuration and can be run in driver mode.
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 6b5e5d7a
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b5e5d7a2c01d6f2b28d54033a2fd37add469d36
Stats:     17 lines in 1 file changed: 0 ins; 11 del; 6 mod

8266181: compiler/eliminateAutobox/TestEliminateBoxInDebugInfo should be in driver mode

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3746

From iignatyev at openjdk.java.net  Wed Apr 28 05:13:59 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 05:13:59 GMT
Subject: RFR: 8266184: a few compiler/debug tests don't check exit code
Message-ID: <3xwfUjqf_GvNtOErU2T0kWJyJAJ_UlRAgsTINEpr5Xc=.0e2d9be8-167f-4572-b77a-ddb3c4832fd8@github.com>

Hi all,

could you please review this small fix for `compiler/debug` tests?
from JBS:
> `compiler/debug/TestGenerateStressSeed.java`, `TestStressCM.java`, and `TestStressIGVNAndCCP.java` don't check the exit code of spawned JVMs, as a result, they might miss misconfiguration and/or defects. in fact, `TestStressIGVNAndCCP.java` uses a wrong flag name (`TraceIterativeIGVN` instead of `TraceIterativeGVN`) and this was unnoticed b/c we didn't check the exit code.

the patch adds calls to `OutputAnalyzer::shouldHaveExitValue` and fixes `TestStressIGVNAndCCP.java` to use the right flag.

testing:
- [x] `test/hotspot/jtreg/compiler/debug` on `linux-x64-debug`

Thanks,
-- Igor

-------------

Commit messages:
 - copyright year
 - 8266184

Changes: https://git.openjdk.java.net/jdk/pull/3748/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3748&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266184
  Stats: 7 lines in 3 files changed: 3 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3748/head:pull/3748

PR: https://git.openjdk.java.net/jdk/pull/3748

From jbhateja at openjdk.java.net  Wed Apr 28 05:43:53 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 28 Apr 2021 05:43:53 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v11]
In-Reply-To: <vIEjf8vOWuaUlzkQyh5w1b4XcK9Mk-o9sPyPg6FDXGs=.0aabb462-8b05-4175-aff9-3266b55bc8ee@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <vIEjf8vOWuaUlzkQyh5w1b4XcK9Mk-o9sPyPg6FDXGs=.0aabb462-8b05-4175-aff9-3266b55bc8ee@github.com>
Message-ID: <LAGc0fqsy7U5yD5fVd0KRB2YY7tGOlN5WUu4Pbs4ulg=.302f2ec8-6c29-4339-886e-0cf96548fc8f@github.com>

On Wed, 28 Apr 2021 01:39:23 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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 vector _sign_flip
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1067:

> 1065:   jcc(Assembler::parity, DONE_LABEL);   // handle special case NaN, if argument NaN, return NaN
> 1066: 
> 1067:   if (opcode == Op_SignumF){

Too many if/else, can you kindly club the instruction for SignumF and SignumD in one conditional(if/else) block.

src/hotspot/cpu/x86/x86.ad line 5791:

> 5789: 
> 5790: instruct signumF_reg(regF dst, regF zero, regF one, rRegP scratch, rFlagsReg cr) %{
> 5791:   predicate(UseSSE>=1);

Predicate looks redundant since you already added a check in match_rule_supported

src/hotspot/cpu/x86/x86.ad line 5803:

> 5801: 
> 5802: instruct signumD_reg(regD dst, regD zero, regD one, rRegP scratch, rFlagsReg cr) %{
> 5803:   predicate(UseSSE>=2);

Same as above

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From jiefu at openjdk.java.net  Wed Apr 28 06:19:57 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Apr 2021 06:19:57 GMT
Subject: Integrated: 8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)
In-Reply-To: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
References: <1qsOMKklDQoO6BCCln_Xo08IMTsWExeha7EmNl75RFQ=.11176b7d-39e4-4eeb-94ce-d96c70093b28@github.com>
Message-ID: <LIhxxmLEiMHpcZavmOFhsBIAZ9QYc0Wq3PVdoBySJrw=.e9cb7334-759c-4739-8b54-146fa33cdf60@github.com>

On Tue, 27 Apr 2021 08:29:04 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> C2 computes -0.0 for Math.pow(-0.0, 0.5) which should be 0.0 according to the API specs.
> This bug was found while I was implementing the same optimization for x86_32 (JDK-8265940).
> 
> The reason is that CmpDNode [1] doesn't distinguish -0.0 from 0.0.
> Math.pow(-0.0, 0.5) was replaced with Math.sqrt(-0.0) incorrectly since CmpDNode says -0.0 < 0.0 if false.
> 
> The fix excludes C2's optimization for x=0.0/-0.0. 
> And the jtreg test has been improved to make sure the corner cases are covered by the compilers.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1656

This pull request has now been integrated.

Changeset: 75a2354d
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/75a2354dc276e107d64516d20fc72bc7ef3d5f86
Stats:     21 lines in 2 files changed: 9 ins; 11 del; 1 mod

8266028: C2 computes -0.0 for Math.pow(-0.0, 0.5)

Reviewed-by: aph, neliasso, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3712

From yyang at openjdk.java.net  Wed Apr 28 06:37:55 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Apr 2021 06:37:55 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v2]
In-Reply-To: <pZNZCfeQNBk2wKOG9wOSDppeOklvlmrxA1on3bvQuJw=.7ef82df7-b79b-428e-9c1b-0f0f8a1be7ea@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <q-IErhIOywV6IYTcgs-dhIJMFByz39jJ_8oa88uzM_o=.12808795-4dac-46df-b397-53edae405398@github.com>
 <pZNZCfeQNBk2wKOG9wOSDppeOklvlmrxA1on3bvQuJw=.7ef82df7-b79b-428e-9c1b-0f0f8a1be7ea@github.com>
Message-ID: <Iw9Rj7CRsiWGWAvMsiFzB3FEBTO_wHWHJ9_bBhj8PRM=.741d4670-7e33-4cc3-91b8-c2acd7991894@github.com>

On Tue, 27 Apr 2021 13:23:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Why are you reloading the klass here?

Typo. I forget removing it.

> Also, as @rwestrel explained in the RFR for 8211231, we need to be really careful when emitting branches in C1's LIR.

> The problem is that there's control flow here that's invisible to
the register allocator. The register allocator only knows about control
flow that connects basic blocks. The control flow here is within a
block. So as far as the register allocator is concerned the code above
is a linear sequence of instructions all of which are all executed

Ok, I see. But from the compiled code, it behaves well?


B1 [0, 0] sux: B0 
__id_Instruction___________________________________________
   0 label [label:0x00007f0c10025f60]
   2 std_entry 

B0 std [0, 4] preds: B1 
__id_Instruction___________________________________________
   8 label [label:0x00007f0c100253c0]
  10 move [Base:[rsi|L] Disp: 16|] [rax|M]  [bci:1]
  12 cmp [NE] [rax|M] [metadata:0x0000000000000000|M] 
  14 branch [NE] [label:0x00007f0c10028d78] 
  16 move [int:1041|I] [rsi|I] 
  18 branch [AL] [label:0x00007f0c10028e18] 
  20 label [label:0x00007f0c10028d78]
  22 move [Base:[rax|M] Disp: 168|I] [rsi|I] 
  24 label [label:0x00007f0c10028e18]
  26 move [rsi|I] [rax|I] 
  28 return [rax|I]  





__bci__use__tid____instr____________________________________
. 0    0     4     B1 [0, 0] -> B0 sux: B0

   0 label [label:0x00007f0c10025f60]
Memory range [0x00007f0ca06a9120..0x00007f0ca06a9120] not readable   2 std_entry 
--------------------------------------------------------------------------------
 ;;  block B1 [0, 0]
  0x00007f0ca06a9120:   mov    %eax,-0x16000(%rsp)
  0x00007f0ca06a9127:   push   %rbp
  0x00007f0ca06a9128:   sub    $0x30,%rsp
--------------------------------------------------------------------------------
__bci__use__tid____instr____________________________________
. 0    0     0     B0 (SV) [0, 4] dom B1 pred: B1

   8 label [label:0x00007f0c100253c0]
Memory range [0x00007f0ca06a912c..0x00007f0ca06a912c] not readable  10 move [Base:[rsi|L] Disp: 16|] [rax|M]  [bci:1]
--------------------------------------------------------------------------------
 ;;  block B1 [0, 0]
  0x00007f0ca06a912c:   mov    0x10(%rsi),%rax
--------------------------------------------------------------------------------
  12 cmp [NE] [rax|M] [metadata:0x0000000000000000|M] 
--------------------------------------------------------------------------------
 ;;  block B1 [0, 0]
  0x00007f0ca06a9130:   cmp    $0x0,%rax
--------------------------------------------------------------------------------
  14 branch [NE] [label:0x00007f0c10028d78] 
--------------------------------------------------------------------------------
 ;;  block B1 [0, 0]
  0x00007f0ca06a9134:   jne    0x00007f0ca06a913a
--------------------------------------------------------------------------------
  16 move [int:1041|I] [rsi|I] 
--------------------------------------------------------------------------------
 ;;  block B1 [0, 0]
  0x00007f0ca06a913a:   mov    $0x411,%esi
--------------------------------------------------------------------------------
  18 branch [AL] [label:0x00007f0c10028e18] 
--------------------------------------------------------------------------------
 ;;  block B1 [0, 0]
  0x00007f0ca06a913f:   jmpq   0x00007f0ca06a9144
--------------------------------------------------------------------------------
  20 label [label:0x00007f0c10028d78]
Memory range [0x00007f0ca06a9144..0x00007f0ca06a9144] not readable  22 move [Base:[rax|M] Disp: 168|I] [rsi|I] 
--------------------------------------------------------------------------------
 ;;  block B1 [0, 0]
  0x00007f0ca06a9144:   mov    0xa8(%rax),%esi
--------------------------------------------------------------------------------
  24 label [label:0x00007f0c10028e18]
Memory range [0x00007f0ca06a914a..0x00007f0ca06a914a] not readable  26 move [rsi|I] [rax|I] 
--------------------------------------------------------------------------------
 ;;  block B1 [0, 0]
  0x00007f0ca06a914a:   mov    %rsi,%rax
--------------------------------------------------------------------------------
  28 return [rax|I]  
--------------------------------------------------------------------------------
 ;;  block B1 [0, 0]
  0x00007f0ca06a914d:   add    $0x30,%rsp
  0x00007f0ca06a9151:   pop    %rbp
  0x00007f0ca06a9152:   cmp    0x118(%r15),%rsp
 ;;  block B0 [0, 4]
  0x00007f0ca06a9159:   ja     0x00007f0ca06a915f
  0x00007f0ca06a915f:   retq   
--------------------------------------------------------------------------------

Also tests under compiler and jdk are passed with slowdebug mode.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From yyang at openjdk.java.net  Wed Apr 28 06:43:19 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Apr 2021 06:43:19 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v3]
In-Reply-To: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
Message-ID: <rMBogIoB8y6JLdsOI62S7vkgSIQLwFqg4YOjq3KMoDM=.414b238f-4640-4a6a-bae7-009af46ceb92@github.com>

> It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  rename; redundant reloading

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3616/files
  - new: https://git.openjdk.java.net/jdk/pull/3616/files/76f5bfa9..5a0716c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3616&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3616&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3616/head:pull/3616

PR: https://git.openjdk.java.net/jdk/pull/3616

From iignatyev at openjdk.java.net  Wed Apr 28 07:06:58 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 07:06:58 GMT
Subject: RFR: 8266188: mark hotspot compiler/cpuflags tests which ignore VM
 flags
Message-ID: <gHNJK2LdtOz1dIxOIqPbLsBOHAKc9Ud8itoIW9NP_eE=.e93d227d-4fcf-4c3a-8ed1-c2e70ce9e876@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/cpuflags ` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - copyright year
 - 8266190

Changes: https://git.openjdk.java.net/jdk/pull/3752/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3752&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266188
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3752.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3752/head:pull/3752

PR: https://git.openjdk.java.net/jdk/pull/3752

From chagedorn at openjdk.java.net  Wed Apr 28 07:46:00 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 28 Apr 2021 07:46:00 GMT
Subject: RFR: 8266188: mark hotspot compiler/cpuflags tests which ignore
 VM flags
In-Reply-To: <gHNJK2LdtOz1dIxOIqPbLsBOHAKc9Ud8itoIW9NP_eE=.e93d227d-4fcf-4c3a-8ed1-c2e70ce9e876@github.com>
References: <gHNJK2LdtOz1dIxOIqPbLsBOHAKc9Ud8itoIW9NP_eE=.e93d227d-4fcf-4c3a-8ed1-c2e70ce9e876@github.com>
Message-ID: <4960TeJf3lfwYNpD08Up88TOH2bJPxHZvnJPv8ZlCUw=.9e1957d2-eaa7-454f-9b7c-6151d91b58e1@github.com>

On Wed, 28 Apr 2021 06:59:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/cpuflags ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Looks good.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3752

From rcastanedalo at openjdk.java.net  Wed Apr 28 08:48:56 2021
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 28 Apr 2021 08:48:56 GMT
Subject: Integrated: 8265587: IGV: track nodes across matching
In-Reply-To: <n4rVpa5niUA7uxFGvO49o6MT9TH5pMvwF8Mnpax1Bg0=.3ff29745-d792-4793-98fa-e3ee5c4975ea@github.com>
References: <n4rVpa5niUA7uxFGvO49o6MT9TH5pMvwF8Mnpax1Bg0=.3ff29745-d792-4793-98fa-e3ee5c4975ea@github.com>
Message-ID: <oYmvmaDDoviI2ZnmyXKwLFQURnYgZhkKnlwPwxdulls=.a6f2020d-28b1-4281-a357-213525f03e3f@github.com>

On Fri, 23 Apr 2021 12:31:20 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change preserves, as much as possible, the IGV node identifier of Ideal nodes in their corresponding machine nodes created by `Matcher::match()`. This makes it possible to track nodes when stepping from "Before matching" to "After matching" in IGV, as illustrated for an extracted compare-and-branch subgraph in the following screenshot: 
> 
> ![before-after-matching](https://user-images.githubusercontent.com/8792647/115867587-94b75280-a43b-11eb-8a79-9c13a0a68d42.png)
> 
> #### Limitations
> This solution preserves most of the node relations across matching, however if an Ideal node is expanded into multiple machine nodes, only one of them is assigned the IGV identifier of the Ideal node (since IGV identifiers need to be unique within a compilation phase). This limitation can be seen in the following example, where the `CmpU` Ideal node is implemented with three `compU_rReg` machine nodes (one for each `jmpConU` machine node), but only one of the `compU_rReg` machine nodes (50) preserves the IGV identifier:
> 
> ![before-after-matching-limitation](https://user-images.githubusercontent.com/8792647/115869469-3770d080-a43e-11eb-9ede-d8845862c7bd.png)
> 
> Overcoming this limitation would require explicitly serializing the entire before-after relation among nodes and adapting IGV's node selection and graph difference logic, which seems too complex for a relatively infrequent case.
> 
> #### Testing
> - Regression-tested HotSpot changes on hs-tier1-3, windows-x64, linux-x64, linux-aarch64, and macosx-x64 (both release and debug).
> - Tested HotSpot graph generation and IGV graph loading and scheduling on tens of thousands of graphs by running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4 ...` on an instrumented IGV. Loading and scheduling are useful graph well-formedness tests, as they tend to fail for incorrect graphs, e.g. with repeated node identifiers.
> - Tested manually, for a few graphs, that nodes of different types can be tracked across matching.

This pull request has now been integrated.

Changeset: e879f8c6
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e879f8c6c874cc7039d344f19430cce7cfb138ea
Stats:     50 lines in 4 files changed: 20 ins; 13 del; 17 mod

8265587: IGV: track nodes across matching

Preserve the IGV node identifier of Ideal nodes in their corresponding machine
nodes after matching, to allow IGV users to track nodes across this phase.

Reviewed-by: thartmann, vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3654

From jiefu at openjdk.java.net  Wed Apr 28 09:44:05 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Apr 2021 09:44:05 GMT
Subject: RFR: 8265940: Enable C2's optimization for Math.pow(x,
 0.5) on all platforms
Message-ID: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>

Hi all,

I'd like to enable C2's optimization for Math.pow(x, 0.5) on all platforms.

This is fine because:
 1) For x86, it will call the assembly stubs.
    This opt has already been implemented for x86_64 [1]. 
    And the x86_32 version is added in this patch.
 2) For non-x86, it will call the shared runtime c code [2], which does the same opt too.

Testing:
  - tier1~3 on Linux/{x86_32, x86_64}, no regression

Thanks,
Best regards,
Jie


[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L838
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L497

-------------

Commit messages:
 - 8265940: Enable C2's optimization for Math.pow(x, 0.5) on all platforms

Changes: https://git.openjdk.java.net/jdk/pull/3755/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3755&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265940
  Stats: 21 lines in 3 files changed: 14 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3755.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3755/head:pull/3755

PR: https://git.openjdk.java.net/jdk/pull/3755

From whuang at openjdk.java.net  Wed Apr 28 09:52:22 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Wed, 28 Apr 2021 09:52:22 GMT
Subject: RFR: 8265956: JVM crashes when matching LShiftVB Node [v2]
In-Reply-To: <0lX7U-sIV4c6Wi1Cyw3caRD6ZTVCIYzbiiji3uPXf4M=.c0494113-32c5-40c4-bdd7-93b226ffe236@github.com>
References: <0lX7U-sIV4c6Wi1Cyw3caRD6ZTVCIYzbiiji3uPXf4M=.c0494113-32c5-40c4-bdd7-93b226ffe236@github.com>
Message-ID: <xLNhEF-RBuHsL7HMxPn_JhdySfiJeztSQnJXUOVdsVk=.45dbda60-97dc-4173-9772-d8c7325b67ec@github.com>

> It is fount that the rule `match(Set dst (LShiftVB src shift))` is missing on many cpus, such like `aarch64` and `x86`. It is this reason that JVM will crash under `JDK-8265956`'s test case. In this commit, I :
> * show the crash case `TestVectorShuffleIotaShort`
> * solve the issue on `aarch64` and `x86` by adding the rule. 
> * test after fixing on tire1~3
> 
> Thank you for your review. Any suggestion is welcome. 
>                          Wang Huang

Wang Huang has updated the pull request incrementally with one additional commit since the last revision:

  add m4 file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3747/files
  - new: https://git.openjdk.java.net/jdk/pull/3747/files/b416645b..3d11bb1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3747&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3747&range=00-01

  Stats: 6 lines in 2 files changed: 3 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3747/head:pull/3747

PR: https://git.openjdk.java.net/jdk/pull/3747

From thartmann at openjdk.java.net  Wed Apr 28 10:55:56 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Apr 2021 10:55:56 GMT
Subject: RFR: 8266184: a few compiler/debug tests don't check exit code
In-Reply-To: <3xwfUjqf_GvNtOErU2T0kWJyJAJ_UlRAgsTINEpr5Xc=.0e2d9be8-167f-4572-b77a-ddb3c4832fd8@github.com>
References: <3xwfUjqf_GvNtOErU2T0kWJyJAJ_UlRAgsTINEpr5Xc=.0e2d9be8-167f-4572-b77a-ddb3c4832fd8@github.com>
Message-ID: <fzzPVyZqd4GFBbZvt5guK4EFcTM87C32MIKjntuvkbA=.17b7e513-4c91-4b30-a58f-e77105bca337@github.com>

On Wed, 28 Apr 2021 05:06:19 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small fix for `compiler/debug` tests?
> from JBS:
>> `compiler/debug/TestGenerateStressSeed.java`, `TestStressCM.java`, and `TestStressIGVNAndCCP.java` don't check the exit code of spawned JVMs, as a result, they might miss misconfiguration and/or defects. in fact, `TestStressIGVNAndCCP.java` uses a wrong flag name (`TraceIterativeIGVN` instead of `TraceIterativeGVN`) and this was unnoticed b/c we didn't check the exit code.
> 
> the patch adds calls to `OutputAnalyzer::shouldHaveExitValue` and fixes `TestStressIGVNAndCCP.java` to use the right flag.
> 
> testing:
> - [x] `test/hotspot/jtreg/compiler/debug` on `linux-x64-debug`
> 
> Thanks,
> -- Igor

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3748

From thartmann at openjdk.java.net  Wed Apr 28 10:58:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Apr 2021 10:58:51 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v3]
In-Reply-To: <rMBogIoB8y6JLdsOI62S7vkgSIQLwFqg4YOjq3KMoDM=.414b238f-4640-4a6a-bae7-009af46ceb92@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <rMBogIoB8y6JLdsOI62S7vkgSIQLwFqg4YOjq3KMoDM=.414b238f-4640-4a6a-bae7-009af46ceb92@github.com>
Message-ID: <qSCk9BzxZdTtqg1mCgb6soVlrrgQJ2cBv7-mfE8Wap0=.28add9e8-6a21-4bb3-8cf2-7a79c14da4df@github.com>

On Wed, 28 Apr 2021 06:43:19 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename; redundant reloading

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3616

From thartmann at openjdk.java.net  Wed Apr 28 11:15:01 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Apr 2021 11:15:01 GMT
Subject: RFR: 8266188: mark hotspot compiler/cpuflags tests which ignore
 VM flags
In-Reply-To: <gHNJK2LdtOz1dIxOIqPbLsBOHAKc9Ud8itoIW9NP_eE=.e93d227d-4fcf-4c3a-8ed1-c2e70ce9e876@github.com>
References: <gHNJK2LdtOz1dIxOIqPbLsBOHAKc9Ud8itoIW9NP_eE=.e93d227d-4fcf-4c3a-8ed1-c2e70ce9e876@github.com>
Message-ID: <vQbhH4C6hhPMNJN6av4zhUWolDRjkLXLZ-7QIi1kpvg=.ac82cbeb-47a5-45d9-837f-69085dea405b@github.com>

On Wed, 28 Apr 2021 06:59:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/cpuflags ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Marked as reviewed by thartmann (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3752

From neliasso at openjdk.java.net  Wed Apr 28 12:55:55 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 28 Apr 2021 12:55:55 GMT
Subject: RFR: 8265244: assert(false) failed: bad AD file [v2]
In-Reply-To: <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
Message-ID: <RWSogn_WX6pqEdOkKWMxcaBtx6FsojnSZytqZ0oUfpI=.1a6863a2-dd64-41f8-8b5f-17a39cdc5f3b@github.com>

On Fri, 16 Apr 2021 02:10:10 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * aarch64 can only accept `VectorReinterpret` with 64/128 bits.
>> * I will fix this bug by adding a rule for `VectorReinterpret` in `match_rule_supported_vector`
>> * after changing note with @nsjian and @XiaohongGong , I think that two checks in `inline_vector_conver` is useless now. However, these checks impact other cpus, so I need more reviewers.
>
> Wang Huang 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 JDK-8265244
>  - 8265244: assert(false) failed: bad AD file

Please change the bug and PR title to something that describes the problem or solution.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3507

From neliasso at openjdk.java.net  Wed Apr 28 12:58:55 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 28 Apr 2021 12:58:55 GMT
Subject: RFR: 8265322: C2: Simplify control inputs for
 BarrierSetC2::obj_allocate
In-Reply-To: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
References: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
Message-ID: <GDQ2ERbZWMa65_r5cBoXBMzm0i6Tm66Jz1cFIfcjn7A=.278ea6ce-bcfb-47d7-a525-e991007b266d@github.com>

On Fri, 16 Apr 2021 03:06:19 GMT, Yi Yang <yyang at openjdk.org> wrote:

> While just using BarrierSetC2::obj_allocate in https://github.com/openjdk/valhalla/pull/385, I noticed the control input `ctrl` for obj_allocate is not so much necessary. This PR simplifies control inputs for BarrierSetC2::obj_allocate. In most cases, it doesn't change anything since `toobig_false` is equivalent to `ctrl`. In other cases, `toobig_false` is created for Unsafe.allocateInstance while instance size is not statically known, `ctrl` would become control input of IfNode whose projects are `toobig_false` and `toobig_true`, old eden_end and old_eden_top can simply accept `toobig_false` as their control input rather than `ctrl`.

Looks good.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3529

From rraghavan at openjdk.java.net  Wed Apr 28 13:00:25 2021
From: rraghavan at openjdk.java.net (Rahul Raghavan)
Date: Wed, 28 Apr 2021 13:00:25 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with "method
 holder must be initialized" when called for uninitialized class
Message-ID: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>

https://bugs.openjdk.java.net/browse/JDK-8264395

Reported assert failure, during compilation triggered by Whitebox API `enqueueInitializerForCompilation` method,
is fixed by adding support to to bail out if a class not initialized yet.

Confirmed the new `compiler/whitebox/TestEnqueueInitializerForCompilation.java` test passes with the proposed `whitebox.cpp` changes and fails with reported assert without this fix.
No issues with tier tests.

-------------

Commit messages:
 - 8264395: WB_EnqueueInitializerForCompilation fails with "method holder must be initialized" when called for uninitialized class
 - 8264395: WB_EnqueueInitializerForCompilation fails with method holder must be initialized when called for uninitialized class

Changes: https://git.openjdk.java.net/jdk/pull/3757/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3757&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264395
  Stats: 58 lines in 2 files changed: 57 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3757.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3757/head:pull/3757

PR: https://git.openjdk.java.net/jdk/pull/3757

From neliasso at openjdk.java.net  Wed Apr 28 13:01:03 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 28 Apr 2021 13:01:03 GMT
Subject: RFR: 8265940: Enable C2's optimization for Math.pow(x,
 0.5) on all platforms
In-Reply-To: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
References: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
Message-ID: <j4P66x3WVPLruGasHIOlthpXBUT0QnNoUcDWSkaap6M=.f3a26719-26a6-40bb-be9c-ab5c146b0198@github.com>

On Wed, 28 Apr 2021 08:10:36 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to enable C2's optimization for Math.pow(x, 0.5) on all platforms.
> 
> This is fine because:
>  1) For x86, it will call the assembly stubs.
>     This opt has already been implemented for x86_64 [1]. 
>     And the x86_32 version is added in this patch.
>  2) For non-x86, it will call the shared runtime c code [2], which does the same opt too.
> 
> Testing:
>   - tier1~3 on Linux/{x86_32, x86_64}, no regression
> 
> Thanks,
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L838
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L497

Looks good.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3755

From chagedorn at openjdk.java.net  Wed Apr 28 13:02:55 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 28 Apr 2021 13:02:55 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class
In-Reply-To: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
Message-ID: <qnHTAcjvnNlYxSRhiMcoiV4shHgDGXOA0j6UvxZ1UME=.8c837532-84f5-4f87-a118-6e1ac5cfca08@github.com>

On Wed, 28 Apr 2021 09:39:08 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8264395
> 
> Reported assert failure, during compilation triggered by Whitebox API `enqueueInitializerForCompilation` method,
> is fixed by adding support to to bail out if a class not initialized yet.
> 
> Confirmed the new `compiler/whitebox/TestEnqueueInitializerForCompilation.java` test passes with the proposed `whitebox.cpp` changes and fails with reported assert without this fix.
> No issues with tier tests.

Looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3757

From thartmann at openjdk.java.net  Wed Apr 28 13:23:53 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Apr 2021 13:23:53 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class
In-Reply-To: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
Message-ID: <K1Mr0JImlogw5c_cV9wlstr_jxO9mjkCC-5lS_YUtJA=.22ed7613-e8a0-4f64-9ace-90612c17752f@github.com>

On Wed, 28 Apr 2021 09:39:08 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8264395
> 
> Reported assert failure, during compilation triggered by Whitebox API `enqueueInitializerForCompilation` method,
> is fixed by adding support to to bail out if a class not initialized yet.
> 
> Confirmed the new `compiler/whitebox/TestEnqueueInitializerForCompilation.java` test passes with the proposed `whitebox.cpp` changes and fails with reported assert without this fix.
> No issues with tier tests.

Changes requested by thartmann (Reviewer).

test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 27:

> 25:  * @test
> 26:  * @bug 8264395
> 27:  * @summary testing of WB::enqueueInitializerForCompilation()

Maybe change the summary to something explaining that we are testing compilation of the class initializer of a class that is not initialized yet.

test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 28:

> 26:  * @bug 8264395
> 27:  * @summary testing of WB::enqueueInitializerForCompilation()
> 28:  * @library /test/lib /

`/test/lib` is not required, right?

test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 31:

> 29:  * @build sun.hotspot.WhiteBox
> 30:  * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox
> 31:  * @run main/othervm/timeout=300 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions

Why do you need a non-default timeout?

test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 42:

> 40: 
> 41:     public static void main(String[] args) {
> 42:         WhiteBox.getWhiteBox().enqueueInitializerForCompilation(LongWrapper.class, 4);

What if compilation level 4 (= C2) is not available?

test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 53:

> 51:         }
> 52: 
> 53:         static LongWrapper wrap(long val) {

`wrap` is unused. Are fields required?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3757

From enikitin at openjdk.java.net  Wed Apr 28 14:10:08 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Wed, 28 Apr 2021 14:10:08 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion.
Message-ID: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>

The bug: https://bugs.openjdk.java.net/browse/JDK-8265349

A repetition of the JDK-8058176 (mlvm tests cause code cache exhaustion), this time with -Xcomp. My measurements show up max code cache consumption of 400-500 kb per test thread and tree (depends on random tree and other factors, of course, but still). For the whole test which usually doesn't exceed 10 threads, I've got max. value of 6.1M for one sequence/tree build (between checks for remaining free space).

So I suggest to raise the allowances to 10M, just to be safe. Compared to the 103 Mb of required code cache space that test requests via the 'run' parameter, it doesn't look that much.

Thanks in advance,
// Evgeny Nikitin.

-------------

Commit messages:
 - 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java fails with OOME due to CodeCache exhaustion

Changes: https://git.openjdk.java.net/jdk/pull/3762/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3762&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265349
  Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3762.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3762/head:pull/3762

PR: https://git.openjdk.java.net/jdk/pull/3762

From jiefu at openjdk.java.net  Wed Apr 28 14:11:54 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Apr 2021 14:11:54 GMT
Subject: RFR: 8265940: Enable C2's optimization for Math.pow(x,
 0.5) on all platforms
In-Reply-To: <j4P66x3WVPLruGasHIOlthpXBUT0QnNoUcDWSkaap6M=.f3a26719-26a6-40bb-be9c-ab5c146b0198@github.com>
References: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
 <j4P66x3WVPLruGasHIOlthpXBUT0QnNoUcDWSkaap6M=.f3a26719-26a6-40bb-be9c-ab5c146b0198@github.com>
Message-ID: <qIHCcEjoj6QeZDMX3tbtQbnsn7JMTG578D4Dr-xW60c=.586ee6c4-9f11-4977-b21b-b969f1aa8f4b@github.com>

On Wed, 28 Apr 2021 12:58:27 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Looks good.

Thanks @neliasso .

-------------

PR: https://git.openjdk.java.net/jdk/pull/3755

From zhuoren.wz at alibaba-inc.com  Wed Apr 28 12:20:55 2021
From: zhuoren.wz at alibaba-inc.com (=?UTF-8?B?V2FuZyBaaHVvKFpodW9yZW4p?=)
Date: Wed, 28 Apr 2021 20:20:55 +0800
Subject: =?UTF-8?B?Wzh1XVJGUjpiYWNrcG9ydGluZyBKREstODA2OTE5MSB0byA4dQ==?=
In-Reply-To: <ba6fd991-c634-4dc6-8a37-73f6c776d5dd.>
References: <ba6fd991-c634-4dc6-8a37-73f6c776d5dd.>
Message-ID: <32a42b09-f9bb-49e4-b8cb-de46ded05d82.zhuoren.wz@alibaba-inc.com>

Please help review this patch. AArch64 JDK8 may crash without this patch. The newly added tests can reproduce this crash on aarch64 platform.

webrev : http://cr.openjdk.java.net/~wzhuo/8266039/webrev.00/
JDK-bug: https://bugs.openjdk.java.net/browse/JDK-8266039


Regards,
Zhuoren

From iignatyev at openjdk.java.net  Wed Apr 28 15:48:53 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 15:48:53 GMT
Subject: RFR: 8266184: a few compiler/debug tests don't check exit code
In-Reply-To: <3xwfUjqf_GvNtOErU2T0kWJyJAJ_UlRAgsTINEpr5Xc=.0e2d9be8-167f-4572-b77a-ddb3c4832fd8@github.com>
References: <3xwfUjqf_GvNtOErU2T0kWJyJAJ_UlRAgsTINEpr5Xc=.0e2d9be8-167f-4572-b77a-ddb3c4832fd8@github.com>
Message-ID: <iuvXmou3nc6Rwdm2uRpwU7rmQW3eU6gF3jNR4HiQqNs=.67e01156-62fe-4f38-8d52-595736233d86@github.com>

On Wed, 28 Apr 2021 05:06:19 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small fix for `compiler/debug` tests?
> from JBS:
>> `compiler/debug/TestGenerateStressSeed.java`, `TestStressCM.java`, and `TestStressIGVNAndCCP.java` don't check the exit code of spawned JVMs, as a result, they might miss misconfiguration and/or defects. in fact, `TestStressIGVNAndCCP.java` uses a wrong flag name (`TraceIterativeIGVN` instead of `TraceIterativeGVN`) and this was unnoticed b/c we didn't check the exit code.
> 
> the patch adds calls to `OutputAnalyzer::shouldHaveExitValue` and fixes `TestStressIGVNAndCCP.java` to use the right flag.
> 
> testing:
> - [x] `test/hotspot/jtreg/compiler/debug` on `linux-x64-debug`
> 
> Thanks,
> -- Igor

thanks, Tobias.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3748

From iignatyev at openjdk.java.net  Wed Apr 28 15:48:53 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 15:48:53 GMT
Subject: Integrated: 8266184: a few compiler/debug tests don't check exit code
In-Reply-To: <3xwfUjqf_GvNtOErU2T0kWJyJAJ_UlRAgsTINEpr5Xc=.0e2d9be8-167f-4572-b77a-ddb3c4832fd8@github.com>
References: <3xwfUjqf_GvNtOErU2T0kWJyJAJ_UlRAgsTINEpr5Xc=.0e2d9be8-167f-4572-b77a-ddb3c4832fd8@github.com>
Message-ID: <pe6ryGJsWk0qnCQLiY0yRdJjdJJNMZ4PUrStCShiJ2Q=.2eb748c7-4235-4858-830c-aa253860d152@github.com>

On Wed, 28 Apr 2021 05:06:19 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small fix for `compiler/debug` tests?
> from JBS:
>> `compiler/debug/TestGenerateStressSeed.java`, `TestStressCM.java`, and `TestStressIGVNAndCCP.java` don't check the exit code of spawned JVMs, as a result, they might miss misconfiguration and/or defects. in fact, `TestStressIGVNAndCCP.java` uses a wrong flag name (`TraceIterativeIGVN` instead of `TraceIterativeGVN`) and this was unnoticed b/c we didn't check the exit code.
> 
> the patch adds calls to `OutputAnalyzer::shouldHaveExitValue` and fixes `TestStressIGVNAndCCP.java` to use the right flag.
> 
> testing:
> - [x] `test/hotspot/jtreg/compiler/debug` on `linux-x64-debug`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 19d3c451
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/19d3c451b89680cefa41fd18f9e9ba0624f56858
Stats:     7 lines in 3 files changed: 3 ins; 1 del; 3 mod

8266184: a few compiler/debug tests don't check exit code

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3748

From iignatyev at openjdk.java.net  Wed Apr 28 15:49:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 15:49:52 GMT
Subject: RFR: 8266188: mark hotspot compiler/cpuflags tests which ignore
 VM flags
In-Reply-To: <gHNJK2LdtOz1dIxOIqPbLsBOHAKc9Ud8itoIW9NP_eE=.e93d227d-4fcf-4c3a-8ed1-c2e70ce9e876@github.com>
References: <gHNJK2LdtOz1dIxOIqPbLsBOHAKc9Ud8itoIW9NP_eE=.e93d227d-4fcf-4c3a-8ed1-c2e70ce9e876@github.com>
Message-ID: <ZR83CDU_lmk5zC3BeiD4Ec6kHvi5P0zjmQsY_2ol-2w=.79c32133-229c-4f9e-80cf-86f34e3dcd28@github.com>

On Wed, 28 Apr 2021 06:59:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/cpuflags ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Christian, Tobias, thank you for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3752

From iignatyev at openjdk.java.net  Wed Apr 28 15:49:53 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 15:49:53 GMT
Subject: Integrated: 8266188: mark hotspot compiler/cpuflags tests which
 ignore VM flags
In-Reply-To: <gHNJK2LdtOz1dIxOIqPbLsBOHAKc9Ud8itoIW9NP_eE=.e93d227d-4fcf-4c3a-8ed1-c2e70ce9e876@github.com>
References: <gHNJK2LdtOz1dIxOIqPbLsBOHAKc9Ud8itoIW9NP_eE=.e93d227d-4fcf-4c3a-8ed1-c2e70ce9e876@github.com>
Message-ID: <Wh7xRo7_FhLAN62jPkfG-62ZGEqq4amvCauS6jL_4Hg=.8c05cb0c-500c-4da4-ab01-f590e672a2e9@github.com>

On Wed, 28 Apr 2021 06:59:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/cpuflags ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 8954befd
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8954befd771ef71c6b77aa8bea921859692226f1
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8266188: mark hotspot compiler/cpuflags tests which ignore VM flags

Reviewed-by: chagedorn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3752

From iignatyev at openjdk.java.net  Wed Apr 28 16:02:06 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 16:02:06 GMT
Subject: RFR: 8266165: TestNoWarningLoopStripMiningIterSet is runnable only on
 VM w/ G1, Shenandoah, Z and Epsilon
Message-ID: <MaaVK3KRXzOHrvAlbjOl3A9XS-TmQhyvin7dTtQQilQ=.6322333b-07e9-4760-8924-5a1e91f05ff6@github.com>

Hi all,

could you please review the patch which splits `TestNoWarningLoopStripMiningIterSet` test into several "subtests", one for each GCs?

from JBS:
> `TestNoWarningLoopStripMiningIterSet` test uses `@requires vm.gc.G1 & vm.gc.Shenandoah & vm.gc.Z & vm.gc.Epsilon` to make sure all GCs in its loop are available. this exlcudes this test from execution on VMs which don't have at least one of the listed GCs.

Thanks,
-- Igor

-------------

Commit messages:
 - split the test

Changes: https://git.openjdk.java.net/jdk/pull/3767/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3767&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266165
  Stats: 43 lines in 1 file changed: 34 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3767.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3767/head:pull/3767

PR: https://git.openjdk.java.net/jdk/pull/3767

From iignatyev at openjdk.java.net  Wed Apr 28 16:04:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 16:04:52 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion.
In-Reply-To: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
References: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
Message-ID: <0SCSfAUu0QbDs34bUJKl6x-fyHFJ7zFuEyDzSYk5zlQ=.ddf4d426-3ef9-4895-8afd-e85996073dd0@github.com>

On Wed, 28 Apr 2021 14:02:16 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> The bug: https://bugs.openjdk.java.net/browse/JDK-8265349
> 
> A repetition of the JDK-8058176 (mlvm tests cause code cache exhaustion), this time with -Xcomp. My measurements show up max code cache consumption of 400-500 kb per test thread and tree (depends on random tree and other factors, of course, but still). For the whole test which usually doesn't exceed 10 threads, I've got max. value of 6.1M for one sequence/tree build (between checks for remaining free space).
> 
> So I suggest to raise the allowances to 10M, just to be safe. Compared to the 103 Mb of required code cache space that test requests via the 'run' parameter, it doesn't look that much.
> 
> Thanks in advance,
> // Evgeny Nikitin.

Will it make sense to make `NON_SEGMENTED_CACHE_ALLOWANCE` / `SEGMENTED_CACHE_ALLOWANCE` value dependent on `Platform::isComp`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3762

From roland at openjdk.java.net  Wed Apr 28 16:08:50 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 28 Apr 2021 16:08:50 GMT
Subject: RFR: 8266165: TestNoWarningLoopStripMiningIterSet is runnable
 only on VM w/ G1, Shenandoah, Z and Epsilon
In-Reply-To: <MaaVK3KRXzOHrvAlbjOl3A9XS-TmQhyvin7dTtQQilQ=.6322333b-07e9-4760-8924-5a1e91f05ff6@github.com>
References: <MaaVK3KRXzOHrvAlbjOl3A9XS-TmQhyvin7dTtQQilQ=.6322333b-07e9-4760-8924-5a1e91f05ff6@github.com>
Message-ID: <uv4GttsRJ39z7PTSbV-g5NngM_gCg7C73ZNsiac6fJU=.ab8a1f95-f5ad-4441-81ad-4fbab09a8686@github.com>

On Wed, 28 Apr 2021 15:55:05 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which splits `TestNoWarningLoopStripMiningIterSet` test into several "subtests", one for each GCs?
> 
> from JBS:
>> `TestNoWarningLoopStripMiningIterSet` test uses `@requires vm.gc.G1 & vm.gc.Shenandoah & vm.gc.Z & vm.gc.Epsilon` to make sure all GCs in its loop are available. this exlcudes this test from execution on VMs which don't have at least one of the listed GCs.
> 
> Thanks,
> -- Igor

Looks good to me.

-------------

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3767

From kvn at openjdk.java.net  Wed Apr 28 16:25:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 16:25:52 GMT
Subject: RFR: 8265940: Enable C2's optimization for Math.pow(x,
 0.5) on all platforms
In-Reply-To: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
References: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
Message-ID: <ESf7bnG9qx0Z1VtxQ3-T3EHV0ih3gytP6B9DsSFs8mQ=.ddeeeaf2-37bb-4f9a-9333-1a85d3ffe038@github.com>

On Wed, 28 Apr 2021 08:10:36 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to enable C2's optimization for Math.pow(x, 0.5) on all platforms.
> 
> This is fine because:
>  1) For x86, it will call the assembly stubs.
>     This opt has already been implemented for x86_64 [1]. 
>     And the x86_32 version is added in this patch.
>  2) For non-x86, it will call the shared runtime c code [2], which does the same opt too.
> 
> Testing:
>   - tier1~3 on Linux/{x86_32, x86_64}, no regression
> 
> Thanks,
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L838
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L497

The fix looks good.

src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp line 2574:

> 2572:   jccb(Assembler::parity, L_NOT_DOUBLE0DOT5);
> 2573:   ucomisd(xmm0, ExternalAddress(DOUBLE0));
> 2574:   jccb(Assembler::belowEqual, L_NOT_DOUBLE0DOT5); // pow(x, 0.5) => sqrt(x) only for x > 0.0

Add comment about why 0. case is skipped: -0.0 case.

src/hotspot/share/opto/library_call.cpp line 1646:

> 1644:       set_result(_gvn.transform(new MulDNode(base, base)));
> 1645:       return true;
> 1646:     } else if (d->getd() == 0.5 && Matcher::match_rule_supported(Op_SqrtD)) {

Add the same comment at line #1654 explaining why 0. is excluded.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3755

From iignatyev at openjdk.java.net  Wed Apr 28 16:33:56 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 16:33:56 GMT
Subject: RFR: 8266165: TestNoWarningLoopStripMiningIterSet is runnable
 only on VM w/ G1, Shenandoah, Z and Epsilon
In-Reply-To: <MaaVK3KRXzOHrvAlbjOl3A9XS-TmQhyvin7dTtQQilQ=.6322333b-07e9-4760-8924-5a1e91f05ff6@github.com>
References: <MaaVK3KRXzOHrvAlbjOl3A9XS-TmQhyvin7dTtQQilQ=.6322333b-07e9-4760-8924-5a1e91f05ff6@github.com>
Message-ID: <khJLwiV_SaPngrivVzsnJHRAs64kPcmG2ZAXk3gjZxY=.bc3259a7-968f-4ae9-8cfe-ffa57acd3b95@github.com>

On Wed, 28 Apr 2021 15:55:05 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which splits `TestNoWarningLoopStripMiningIterSet` test into several "subtests", one for each GCs?
> 
> from JBS:
>> `TestNoWarningLoopStripMiningIterSet` test uses `@requires vm.gc.G1 & vm.gc.Shenandoah & vm.gc.Z & vm.gc.Epsilon` to make sure all GCs in its loop are available. this exlcudes this test from execution on VMs which don't have at least one of the listed GCs.
> 
> Thanks,
> -- Igor

Thanks, Roland.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3767

From iignatyev at openjdk.java.net  Wed Apr 28 16:33:56 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 16:33:56 GMT
Subject: Integrated: 8266165: TestNoWarningLoopStripMiningIterSet is runnable
 only on VM w/ G1, Shenandoah, Z and Epsilon
In-Reply-To: <MaaVK3KRXzOHrvAlbjOl3A9XS-TmQhyvin7dTtQQilQ=.6322333b-07e9-4760-8924-5a1e91f05ff6@github.com>
References: <MaaVK3KRXzOHrvAlbjOl3A9XS-TmQhyvin7dTtQQilQ=.6322333b-07e9-4760-8924-5a1e91f05ff6@github.com>
Message-ID: <JmIyB_S_goic6BPoVjedY851N0pWN1NGqMKC__bAxtE=.c42b10f1-5a47-4449-a6d4-01b318b1da5c@github.com>

On Wed, 28 Apr 2021 15:55:05 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which splits `TestNoWarningLoopStripMiningIterSet` test into several "subtests", one for each GCs?
> 
> from JBS:
>> `TestNoWarningLoopStripMiningIterSet` test uses `@requires vm.gc.G1 & vm.gc.Shenandoah & vm.gc.Z & vm.gc.Epsilon` to make sure all GCs in its loop are available. this exlcudes this test from execution on VMs which don't have at least one of the listed GCs.
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: c71c2685
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c71c26859f40b8790757102ca097788a5348295d
Stats:     43 lines in 1 file changed: 34 ins; 1 del; 8 mod

8266165: TestNoWarningLoopStripMiningIterSet is runnable only on VM w/ G1, Shenandoah, Z and Epsilon

Reviewed-by: roland

-------------

PR: https://git.openjdk.java.net/jdk/pull/3767

From iignatyev at openjdk.java.net  Wed Apr 28 17:16:08 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 17:16:08 GMT
Subject: RFR: 8246497: mark hotspot compiler tests which ignore external VM
 flags
Message-ID: <SoCMSIyampBzH5M7fKbEzFCsPvlOFT_bCayZE2LnJPQ=.5cbf6aa6-4d69-418d-b891-07a17e127958@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/codecache ` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - copyright year
 - 8246497

Changes: https://git.openjdk.java.net/jdk/pull/3769/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3769&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8246497
  Stats: 10 lines in 3 files changed: 0 ins; 3 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3769.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3769/head:pull/3769

PR: https://git.openjdk.java.net/jdk/pull/3769

From iignatyev at openjdk.java.net  Wed Apr 28 17:23:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 17:23:54 GMT
Subject: RFR: 8266190: mark hotspot compiler/codecache tests which ignore
 VM flags
In-Reply-To: <SoCMSIyampBzH5M7fKbEzFCsPvlOFT_bCayZE2LnJPQ=.5cbf6aa6-4d69-418d-b891-07a17e127958@github.com>
References: <SoCMSIyampBzH5M7fKbEzFCsPvlOFT_bCayZE2LnJPQ=.5cbf6aa6-4d69-418d-b891-07a17e127958@github.com>
Message-ID: <6EGvklEzXI3irDzZm-CsbLt17WuXp_3V8wWO2WcRtzc=.9172d81c-7ef1-4e9c-9f43-b8a89dfc4575@github.com>

On Wed, 28 Apr 2021 17:08:53 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/codecache ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

oopsie, wrong bug id, it is meant to be for [8266190](https://bugs.openjdk.java.net/browse/JDK-8266190) not for [8246497](https://bugs.openjdk.java.net/browse/JDK-8246497)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3769

From iveresov at openjdk.java.net  Wed Apr 28 17:35:55 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 28 Apr 2021 17:35:55 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
Message-ID: <Q0BkGMwL3g4JdhCsLQ11X7xlGAfdsyTzY7SqXLw-uJk=.992c8a34-e6f5-4941-be46-53ba5a557df2@github.com>

On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove java_nio_Buffer in javaClasses.hpp

src/hotspot/share/c1/c1_GraphBuilder.cpp line 2052:

> 2050:         return;
> 2051:       }
> 2052: 

Do we need to keep this flag?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From iignatyev at openjdk.java.net  Wed Apr 28 17:38:08 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 17:38:08 GMT
Subject: RFR: 8266230: mark hotspot compiler/c2 tests which ignore VM flags
Message-ID: <X14N7nNMFEsKJzkQfmKz2u07ArZthD2dodDmB798bJU=.fda0a967-a6cd-416b-ae39-ef39810cc6c8@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/c2 ` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - update copyright year
 - 8266190

Changes: https://git.openjdk.java.net/jdk/pull/3770/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3770&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266230
  Stats: 13 lines in 6 files changed: 7 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3770.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3770/head:pull/3770

PR: https://git.openjdk.java.net/jdk/pull/3770

From iignatyev at openjdk.java.net  Wed Apr 28 17:53:00 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 17:53:00 GMT
Subject: RFR: 8266232: compiler.c1.TestRangeCheckEliminated should be run in
 driver mode
Message-ID: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>

Hi all,

could you please review this small patch that changes `compiler.c1.TestRangeCheckEliminated` to be run in driver mode (as the actual testing is done in the JVMs spawned by it, `TestRangeCheckEliminated` just verifies their output)? the patch also makes a few small code style changes.

Thanks,
-- Igor

-------------

Commit messages:
 - 8266232

Changes: https://git.openjdk.java.net/jdk/pull/3772/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3772&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266232
  Stats: 12 lines in 1 file changed: 2 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3772.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3772/head:pull/3772

PR: https://git.openjdk.java.net/jdk/pull/3772

From kvn at openjdk.java.net  Wed Apr 28 18:08:57 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 18:08:57 GMT
Subject: RFR: 8266190: mark hotspot compiler/codecache tests which ignore
 VM flags
In-Reply-To: <SoCMSIyampBzH5M7fKbEzFCsPvlOFT_bCayZE2LnJPQ=.5cbf6aa6-4d69-418d-b891-07a17e127958@github.com>
References: <SoCMSIyampBzH5M7fKbEzFCsPvlOFT_bCayZE2LnJPQ=.5cbf6aa6-4d69-418d-b891-07a17e127958@github.com>
Message-ID: <NuSLjg3tr4AQzxl56rjgRoYfSPdL8vEosHGbjn73Hrg=.471f39e2-aa76-4110-9a73-ec000deae67c@github.com>

On Wed, 28 Apr 2021 17:08:53 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/codecache ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3769

From kvn at openjdk.java.net  Wed Apr 28 18:09:53 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 18:09:53 GMT
Subject: RFR: 8266230: mark hotspot compiler/c2 tests which ignore VM flags
In-Reply-To: <X14N7nNMFEsKJzkQfmKz2u07ArZthD2dodDmB798bJU=.fda0a967-a6cd-416b-ae39-ef39810cc6c8@github.com>
References: <X14N7nNMFEsKJzkQfmKz2u07ArZthD2dodDmB798bJU=.fda0a967-a6cd-416b-ae39-ef39810cc6c8@github.com>
Message-ID: <kY9tXoLr29p9iGE8jUT6bkJp0LdAaqoxdfJAL3NdqGo=.a81c5651-561e-4956-92c5-353dbdae149c@github.com>

On Wed, 28 Apr 2021 17:28:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/c2 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3770

From kvn at openjdk.java.net  Wed Apr 28 18:15:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 18:15:52 GMT
Subject: RFR: 8266232: compiler.c1.TestRangeCheckEliminated should be run
 in driver mode
In-Reply-To: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>
References: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>
Message-ID: <IuTn99vcH2FqTZtsYMOpDDSCp3a_GE90zo8ovSSMKyI=.27345f0b-9c90-4f80-adc0-014e96b78103@github.com>

On Wed, 28 Apr 2021 17:46:01 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that changes `compiler.c1.TestRangeCheckEliminated` to be run in driver mode (as the actual testing is done in the JVMs spawned by it, `TestRangeCheckEliminated` just verifies their output)? the patch also makes a few small code style changes.
> 
> Thanks,
> -- Igor

Add Oracle copyright line.

What about `@requires vm.flagless` ?

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3772

From iignatyev at openjdk.java.net  Wed Apr 28 18:22:51 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 18:22:51 GMT
Subject: RFR: 8266232: compiler.c1.TestRangeCheckEliminated should be run
 in driver mode
In-Reply-To: <IuTn99vcH2FqTZtsYMOpDDSCp3a_GE90zo8ovSSMKyI=.27345f0b-9c90-4f80-adc0-014e96b78103@github.com>
References: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>
 <IuTn99vcH2FqTZtsYMOpDDSCp3a_GE90zo8ovSSMKyI=.27345f0b-9c90-4f80-adc0-014e96b78103@github.com>
Message-ID: <zavFqMMUNZdp_EnuQQRKr7Sg5Yy9UhGMTj8z6A5R9Jg=.af5f1b41-5e52-482a-b1d3-8c7d8c9bdb64@github.com>

On Wed, 28 Apr 2021 18:12:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Add Oracle copyright line.

sure, I can do that. but I personally don't see this patch as significant enough to add Oracle's copyright.

> What about `@requires vm.flagless` ?

I want to keep adding `vm.flagless` change as self-contained as possible for ease of review and ease of backporting. but yes, I'll add `@requires vm.flagless` to this test as well.

-- Igor

-------------

PR: https://git.openjdk.java.net/jdk/pull/3772

From iignatyev at openjdk.java.net  Wed Apr 28 18:41:13 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 18:41:13 GMT
Subject: RFR: 8266190: mark hotspot compiler/codecache tests which ignore
 VM flags
In-Reply-To: <SoCMSIyampBzH5M7fKbEzFCsPvlOFT_bCayZE2LnJPQ=.5cbf6aa6-4d69-418d-b891-07a17e127958@github.com>
References: <SoCMSIyampBzH5M7fKbEzFCsPvlOFT_bCayZE2LnJPQ=.5cbf6aa6-4d69-418d-b891-07a17e127958@github.com>
Message-ID: <X_j58AS9XAnz1YyYqg9YkQ5hI6ScoQyN6IFjHhC10Xk=.52d4c0fb-95de-492e-847c-de4ac66b1e0a@github.com>

On Wed, 28 Apr 2021 17:08:53 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/codecache ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3769

From iignatyev at openjdk.java.net  Wed Apr 28 18:41:42 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 18:41:42 GMT
Subject: RFR: 8266232: compiler.c1.TestRangeCheckEliminated should be run
 in driver mode [v2]
In-Reply-To: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>
References: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>
Message-ID: <zuBHGBlvVLY4rjE6AaNeofOThW5Pujxog8GeSnK3gtk=.5b117536-59ca-47ef-b9c0-0ca7a034adde@github.com>

> Hi all,
> 
> could you please review this small patch that changes `compiler.c1.TestRangeCheckEliminated` to be run in driver mode (as the actual testing is done in the JVMs spawned by it, `TestRangeCheckEliminated` just verifies their output)? the patch also makes a few small code style changes.
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:

  added oracle copyright line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3772/files
  - new: https://git.openjdk.java.net/jdk/pull/3772/files/661ab0c7..a76d54cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3772&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3772&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3772.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3772/head:pull/3772

PR: https://git.openjdk.java.net/jdk/pull/3772

From iignatyev at openjdk.java.net  Wed Apr 28 18:50:10 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 18:50:10 GMT
Subject: Integrated: 8266190: mark hotspot compiler/codecache tests which
 ignore VM flags
In-Reply-To: <SoCMSIyampBzH5M7fKbEzFCsPvlOFT_bCayZE2LnJPQ=.5cbf6aa6-4d69-418d-b891-07a17e127958@github.com>
References: <SoCMSIyampBzH5M7fKbEzFCsPvlOFT_bCayZE2LnJPQ=.5cbf6aa6-4d69-418d-b891-07a17e127958@github.com>
Message-ID: <xOWBdG8lLpAmkShdncNnIhQlnJBMR39GLDgI935CPys=.8c56fe7c-8589-444d-87e1-9c57100f70bd@github.com>

On Wed, 28 Apr 2021 17:08:53 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/codecache ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 3f9879f1
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3f9879f1cd9200215a5d8aa481041946b5334489
Stats:     10 lines in 3 files changed: 0 ins; 3 del; 7 mod

8266190: mark hotspot compiler/codecache tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3769

From enikitin at openjdk.java.net  Wed Apr 28 19:07:10 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Wed, 28 Apr 2021 19:07:10 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion. [v2]
In-Reply-To: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
References: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
Message-ID: <6Cyzy_C3CHFVumBzXWdzuPyfJNkAo8Xfd6DfqCQyG4g=.770d16f6-da35-4bdc-9098-47a6f93a116e@github.com>

> The bug: https://bugs.openjdk.java.net/browse/JDK-8265349
> 
> A repetition of the JDK-8058176 (mlvm tests cause code cache exhaustion), this time with -Xcomp. My measurements show up max code cache consumption of 400-500 kb per test thread and tree (depends on random tree and other factors, of course, but still). For the whole test which usually doesn't exceed 10 threads, I've got max. value of 6.1M for one sequence/tree build (between checks for remaining free space).
> 
> So I suggest to raise the allowances to 10M, just to be safe. Compared to the 103 Mb of required code cache space that test requests via the 'run' parameter, it doesn't look that much.
> 
> Thanks in advance,
> // Evgeny Nikitin.

Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:

  Make code cache allowance Xcomp-dependent

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3762/files
  - new: https://git.openjdk.java.net/jdk/pull/3762/files/1c2cd63f..fa15d577

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3762&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3762&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3762.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3762/head:pull/3762

PR: https://git.openjdk.java.net/jdk/pull/3762

From enikitin at openjdk.java.net  Wed Apr 28 19:09:51 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Wed, 28 Apr 2021 19:09:51 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion.
In-Reply-To: <0SCSfAUu0QbDs34bUJKl6x-fyHFJ7zFuEyDzSYk5zlQ=.ddf4d426-3ef9-4895-8afd-e85996073dd0@github.com>
References: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
 <0SCSfAUu0QbDs34bUJKl6x-fyHFJ7zFuEyDzSYk5zlQ=.ddf4d426-3ef9-4895-8afd-e85996073dd0@github.com>
Message-ID: <QJ49fS_2paxO4kgeYxMlQ0FWF5bOjaRNzMAcWUmEZN4=.bf6feee6-3825-47c6-a9ac-83e2c48f862d@github.com>

On Wed, 28 Apr 2021 16:01:51 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Will it make sense to make `NON_SEGMENTED_CACHE_ALLOWANCE` / `SEGMENTED_CACHE_ALLOWANCE` value dependent on `Platform::isComp`?

Please take a look at the new version. I measured code cache usage without the Xcomp, and it falls within 1-2MB per cycle/tree with 10 threads setup (I've did several runs). I suggest 5M in this case, just to be sure we'll not hit some high-amplitude resonance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3762

From kvn at openjdk.java.net  Wed Apr 28 19:13:50 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 19:13:50 GMT
Subject: RFR: 8266232: compiler.c1.TestRangeCheckEliminated should be run
 in driver mode [v2]
In-Reply-To: <zuBHGBlvVLY4rjE6AaNeofOThW5Pujxog8GeSnK3gtk=.5b117536-59ca-47ef-b9c0-0ca7a034adde@github.com>
References: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>
 <zuBHGBlvVLY4rjE6AaNeofOThW5Pujxog8GeSnK3gtk=.5b117536-59ca-47ef-b9c0-0ca7a034adde@github.com>
Message-ID: <lG4ZJWptH86qnqEZ5qqpOszncj-KVm3ZwB5BsSqJl70=.919b4f02-b954-4cc2-91e2-a9c349d981e9@github.com>

On Wed, 28 Apr 2021 18:41:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small patch that changes `compiler.c1.TestRangeCheckEliminated` to be run in driver mode (as the actual testing is done in the JVMs spawned by it, `TestRangeCheckEliminated` just verifies their output)? the patch also makes a few small code style changes.
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added oracle copyright line

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3772

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 28 19:26:21 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 28 Apr 2021 19:26:21 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v12]
In-Reply-To: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
Message-ID: <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>

> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
> 
> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
> 
> Base:
> 
> Benchmark                       Mode Cnt Score Error Units
> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
> 
>  
> Optimized:
> signum intrinsic patch
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:

  jatin-bhateja review
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3581/files
  - new: https://git.openjdk.java.net/jdk/pull/3581/files/c3478950..a3fae395

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=10-11

  Stats: 24 lines in 2 files changed: 5 ins; 14 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581

PR: https://git.openjdk.java.net/jdk/pull/3581

From github.com+168222+mgkwill at openjdk.java.net  Wed Apr 28 19:26:22 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 28 Apr 2021 19:26:22 GMT
Subject: RFR: 8265491: Math Signum optimization for x86
In-Reply-To: <R6I61hf1_yOOru812U3yV0G2b5O2ccs43Te4grxtzgg=.1a96a013-80bb-4d83-bdf5-05d91dc0c19e@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <R6I61hf1_yOOru812U3yV0G2b5O2ccs43Te4grxtzgg=.1a96a013-80bb-4d83-bdf5-05d91dc0c19e@github.com>
Message-ID: <nCYIQlAhrgIq0qq-bUImVe95e2fwjRC7Zm54PWnB7Po=.00f64a03-c1f9-4238-829a-b0e1e57eec21@github.com>

On Tue, 20 Apr 2021 08:38:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  ns/op
>> 
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> @mgkwill,  your newly added benchmark has 4 micro worklets, please publish the results for all of them.

Thanks for your review @jatin-bhateja. I've implemented your suggested changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From iignatyev at openjdk.java.net  Wed Apr 28 19:54:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 19:54:52 GMT
Subject: RFR: 8266232: compiler.c1.TestRangeCheckEliminated should be run
 in driver mode [v2]
In-Reply-To: <zuBHGBlvVLY4rjE6AaNeofOThW5Pujxog8GeSnK3gtk=.5b117536-59ca-47ef-b9c0-0ca7a034adde@github.com>
References: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>
 <zuBHGBlvVLY4rjE6AaNeofOThW5Pujxog8GeSnK3gtk=.5b117536-59ca-47ef-b9c0-0ca7a034adde@github.com>
Message-ID: <chuoVd4ScGQnoTn07VVTEK4xvP7gvOQcNgMD52FvQ_0=.e4b72e14-0003-4b5e-822c-8370a7e71172@github.com>

On Wed, 28 Apr 2021 18:41:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small patch that changes `compiler.c1.TestRangeCheckEliminated` to be run in driver mode (as the actual testing is done in the JVMs spawned by it, `TestRangeCheckEliminated` just verifies their output)? the patch also makes a few small code style changes.
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added oracle copyright line

thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3772

From iignatyev at openjdk.java.net  Wed Apr 28 19:54:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 19:54:52 GMT
Subject: Integrated: 8266232: compiler.c1.TestRangeCheckEliminated should be
 run in driver mode
In-Reply-To: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>
References: <mCSnNAxKkgLcTDM8ybx5Uz_Xjprv2zGEwxhA_rhnNFk=.e307af42-0b90-49cf-8509-c0e524445a02@github.com>
Message-ID: <2iROAKOIxDhCPsEySlGZMWX_vKGlxd1-mxeoKE3bOEU=.ff947fb0-c8eb-4d71-b28c-392243857d7e@github.com>

On Wed, 28 Apr 2021 17:46:01 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that changes `compiler.c1.TestRangeCheckEliminated` to be run in driver mode (as the actual testing is done in the JVMs spawned by it, `TestRangeCheckEliminated` just verifies their output)? the patch also makes a few small code style changes.
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 73cfc26d
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/73cfc26dc28b46654cfe5b4b6c5dee3f7e5af482
Stats:     13 lines in 1 file changed: 3 ins; 2 del; 8 mod

8266232: compiler.c1.TestRangeCheckEliminated should be run in driver mode

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3772

From iignatyev at openjdk.java.net  Wed Apr 28 20:50:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 20:50:55 GMT
Subject: RFR: 8266230: mark hotspot compiler/c2 tests which ignore VM flags
In-Reply-To: <X14N7nNMFEsKJzkQfmKz2u07ArZthD2dodDmB798bJU=.fda0a967-a6cd-416b-ae39-ef39810cc6c8@github.com>
References: <X14N7nNMFEsKJzkQfmKz2u07ArZthD2dodDmB798bJU=.fda0a967-a6cd-416b-ae39-ef39810cc6c8@github.com>
Message-ID: <OIgU6A05E5cjRnLt0oDL9ee9LOezOsFKp08s9njgiU4=.d657da29-f2ce-4b7b-80e5-de7071ccb23b@github.com>

On Wed, 28 Apr 2021 17:28:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/c2 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Thank you, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3770

From iignatyev at openjdk.java.net  Wed Apr 28 20:50:56 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 20:50:56 GMT
Subject: Integrated: 8266230: mark hotspot compiler/c2 tests which ignore VM
 flags
In-Reply-To: <X14N7nNMFEsKJzkQfmKz2u07ArZthD2dodDmB798bJU=.fda0a967-a6cd-416b-ae39-ef39810cc6c8@github.com>
References: <X14N7nNMFEsKJzkQfmKz2u07ArZthD2dodDmB798bJU=.fda0a967-a6cd-416b-ae39-ef39810cc6c8@github.com>
Message-ID: <rHpu-f21h8JzChvR-tTLeMjH_qFgygT_CV_UOr5Ij8I=.82dafddc-3f31-4c70-a18c-b201f39eaac2@github.com>

On Wed, 28 Apr 2021 17:28:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/c2 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: f75dd802
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f75dd80254159fc318a7b7e500aae4885eda38fa
Stats:     13 lines in 6 files changed: 7 ins; 1 del; 5 mod

8266230: mark hotspot compiler/c2 tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3770

From iignatyev at openjdk.java.net  Wed Apr 28 20:52:56 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 20:52:56 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion. [v2]
In-Reply-To: <6Cyzy_C3CHFVumBzXWdzuPyfJNkAo8Xfd6DfqCQyG4g=.770d16f6-da35-4bdc-9098-47a6f93a116e@github.com>
References: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
 <6Cyzy_C3CHFVumBzXWdzuPyfJNkAo8Xfd6DfqCQyG4g=.770d16f6-da35-4bdc-9098-47a6f93a116e@github.com>
Message-ID: <Oy98q09lN7STsjWC0gshI1dZiG0Lm_XqMPEtf-xDj44=.53ae47e9-9139-4e53-a5ad-89873083eedb@github.com>

On Wed, 28 Apr 2021 19:07:10 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> The bug: https://bugs.openjdk.java.net/browse/JDK-8265349
>> 
>> A repetition of the JDK-8058176 (mlvm tests cause code cache exhaustion), this time with -Xcomp. My measurements show up max code cache consumption of 400-500 kb per test thread and tree (depends on random tree and other factors, of course, but still). For the whole test which usually doesn't exceed 10 threads, I've got max. value of 6.1M for one sequence/tree build (between checks for remaining free space).
>> 
>> So I suggest to raise the allowances to 10M, just to be safe. Compared to the 103 Mb of required code cache space that test requests via the 'run' parameter, it doesn't look that much.
>> 
>> Thanks in advance,
>> // Evgeny Nikitin.
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make code cache allowance Xcomp-dependent

I don't like that we kinda guessing here, but on the other hand, I don't think we have much of the choice.

could you please add the comment which roughly explains why it's 10kk and 5kk? so the next person who reads/modifies this piece of code will have an idea of how/why we get the current numbers.

-------------

Changes requested by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3762

From iignatyev at openjdk.java.net  Wed Apr 28 21:01:05 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 21:01:05 GMT
Subject: RFR: 8266231: mark hotspot compiler/c1 tests which ignore VM flags
Message-ID: <Aqbyt7Iozn5oMaaGU16Ptk_8EQgqp9GI7z8JeAU1Igs=.54960312-3ebf-4274-820b-c878764338f3@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/c1 ` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - 8266231

Changes: https://git.openjdk.java.net/jdk/pull/3773/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3773&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266231
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3773.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3773/head:pull/3773

PR: https://git.openjdk.java.net/jdk/pull/3773

From iignatyev at openjdk.java.net  Wed Apr 28 21:10:17 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 21:10:17 GMT
Subject: RFR: 8266251: compiler.inlining.InlineAccessors shouldn't run a test
 in driver VM
Message-ID: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>

Hi all,

could you please review the patch which removes redundant and "incorrect" testing from `InlineAccessors` test? as `InlineAccessors::doTest` is called by the JVM which runs `Launcher` class, we aren't actually losing any coverage.

from JBS:
> `compiler.inlining.InlineAccessors` test executes `doTest` method in its `InlineAccessors::main`, but InlineAccessors is run in driver mode (so it's not expected to do actual testing and strictly speaking can be executed in JVM other than JVM under test).

Thanks,
-- Igor

-------------

Commit messages:
 - 8266251

Changes: https://git.openjdk.java.net/jdk/pull/3774/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3774&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266251
  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3774.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3774/head:pull/3774

PR: https://git.openjdk.java.net/jdk/pull/3774

From sviswanathan at openjdk.java.net  Wed Apr 28 21:11:26 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 28 Apr 2021 21:11:26 GMT
Subject: RFR: 8265783: Create a separate library for x86 Intel SVML
 assembly intrinsics [v2]
In-Reply-To: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
References: <d1zcsxv07lbau9ILb_-GhSNireYkQ9682gvFJ8amMio=.25239bbf-e999-4b08-8784-9bf9cddab8b4@github.com>
Message-ID: <Fy20Oea0qndYRbGqHye4TF1X-uqe-zQU8pzXsMAPsVs=.98d69659-1fdb-4ec7-8857-abe600df6ea3@github.com>

> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods.
> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll.
> 
> The following changes are made:
>    The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml.
>    The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?.
>    The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk.
>    Changes are made to build system to support dependency tracking for assembly files with includes.
>    The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux.
>    The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library.
> 
> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com).
> 
> This work is part of second round of incubation of the Vector API.
> JEP: https://bugs.openjdk.java.net/browse/JDK-8261663
> 
> Please review.
> 
> Performance:
> Micro benchmark Base Optimized Unit Gain(Optimized/Base)
> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90
> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05
> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94
> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79
> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55
> Double128Vector.COS 49.94 245.89 ops/ms 4.92
> Double128Vector.COSH 26.91 126.00 ops/ms 4.68
> Double128Vector.EXP 71.64 379.65 ops/ms 5.30
> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18
> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44
> Double128Vector.LOG 61.95 279.84 ops/ms 4.52
> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03
> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79
> Double128Vector.SIN 49.36 240.79 ops/ms 4.88
> Double128Vector.SINH 26.59 103.75 ops/ms 3.90
> Double128Vector.TAN 41.05 152.39 ops/ms 3.71
> Double128Vector.TANH 45.29 169.53 ops/ms 3.74
> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96
> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01
> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78
> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44
> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04
> Double256Vector.COS 58.26 389.77 ops/ms 6.69
> Double256Vector.COSH 29.44 151.11 ops/ms 5.13
> Double256Vector.EXP 86.67 564.68 ops/ms 6.52
> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80
> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62
> Double256Vector.LOG 71.52 394.90 ops/ms 5.52
> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54
> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05
> Double256Vector.SIN 57.06 380.98 ops/ms 6.68
> Double256Vector.SINH 29.40 117.37 ops/ms 3.99
> Double256Vector.TAN 44.90 279.90 ops/ms 6.23
> Double256Vector.TANH 54.08 274.71 ops/ms 5.08
> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35
> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57
> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04
> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32
> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69
> Double512Vector.COS 59.88 837.04 ops/ms 13.98
> Double512Vector.COSH 30.34 172.76 ops/ms 5.70
> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14
> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34
> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34
> Double512Vector.LOG 74.84 996.00 ops/ms 13.31
> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72
> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34
> Double512Vector.POW 37.42 384.13 ops/ms 10.26
> Double512Vector.SIN 59.74 728.45 ops/ms 12.19
> Double512Vector.SINH 29.47 143.38 ops/ms 4.87
> Double512Vector.TAN 46.20 587.21 ops/ms 12.71
> Double512Vector.TANH 57.36 495.42 ops/ms 8.64
> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06
> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16
> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44
> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28
> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53
> Double64Vector.COS 23.42 152.01 ops/ms 6.49
> Double64Vector.COSH 17.34 113.34 ops/ms 6.54
> Double64Vector.EXP 27.08 203.53 ops/ms 7.52
> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15
> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59
> Double64Vector.LOG 26.75 142.63 ops/ms 5.33
> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40
> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38
> Double64Vector.SIN 23.28 146.91 ops/ms 6.31
> Double64Vector.SINH 17.62 88.59 ops/ms 5.03
> Double64Vector.TAN 21.00 86.43 ops/ms 4.12
> Double64Vector.TANH 23.75 111.35 ops/ms 4.69
> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92
> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06
> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15
> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42
> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93
> Float128Vector.COS 42.82 803.02 ops/ms 18.75
> Float128Vector.COSH 31.44 118.34 ops/ms 3.76
> Float128Vector.EXP 72.43 855.33 ops/ms 11.81
> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38
> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12
> Float128Vector.LOG 52.95 877.94 ops/ms 16.58
> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26
> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61
> Float128Vector.SIN 43.38 745.31 ops/ms 17.18
> Float128Vector.SINH 31.11 112.91 ops/ms 3.63
> Float128Vector.TAN 37.25 332.13 ops/ms 8.92
> Float128Vector.TANH 57.63 453.77 ops/ms 7.87
> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90
> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10
> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61
> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07
> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93
> Float256Vector.COS 43.75 926.69 ops/ms 21.18
> Float256Vector.COSH 33.52 130.46 ops/ms 3.89
> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05
> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84
> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34
> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00
> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17
> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66
> Float256Vector.SIN 44.07 911.04 ops/ms 20.67
> Float256Vector.SINH 33.16 122.50 ops/ms 3.69
> Float256Vector.TAN 37.85 497.75 ops/ms 13.15
> Float256Vector.TANH 64.27 537.20 ops/ms 8.36
> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52
> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93
> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69
> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57
> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11
> Float512Vector.COS 40.92 1567.93 ops/ms 38.32
> Float512Vector.COSH 33.42 138.36 ops/ms 4.14
> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41
> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35
> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47
> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64
> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02
> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81
> Float512Vector.POW 32.73 1015.85 ops/ms 31.04
> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56
> Float512Vector.SINH 33.05 129.39 ops/ms 3.91
> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53
> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90
> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85
> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02
> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40
> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04
> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60
> Float64Vector.COS 44.28 394.33 ops/ms 8.91
> Float64Vector.COSH 28.35 95.27 ops/ms 3.36
> Float64Vector.EXP 65.80 486.37 ops/ms 7.39
> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48
> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93
> Float64Vector.LOG 51.93 163.25 ops/ms 3.14
> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99
> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77
> Float64Vector.SIN 44.41 382.09 ops/ms 8.60
> Float64Vector.SINH 28.20 90.68 ops/ms 3.22
> Float64Vector.TAN 36.29 160.89 ops/ms 4.43
> Float64Vector.TANH 47.65 214.04 ops/ms 4.49

Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge master
 - remove whitespace
 - Merge master
 - Small fix
 - cleanup
 - x86 short vector math optimization for Vector API

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=01
  Stats: 417102 lines in 120 files changed: 416935 ins; 123 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638

PR: https://git.openjdk.java.net/jdk/pull/3638

From iignatyev at openjdk.java.net  Wed Apr 28 21:28:03 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 21:28:03 GMT
Subject: RFR: 8266255:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo.java uses wrong package
 name
Message-ID: <iwfPzRdKI_eRJEiwRqN59WFCbd4B9Ib0pgJdDq8MhmI=.70eaf721-f94e-4811-aa01-fbb70941b2fc@github.com>

Hi all,

could you please review this small and trivial patch that fixes the package name used in `compiler/eliminateAutobox/TestEliminateBoxInDebugInfo.java`?

Thanks,
-- Igor

-------------

Commit messages:
 - 8266255

Changes: https://git.openjdk.java.net/jdk/pull/3775/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3775&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266255
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3775.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3775/head:pull/3775

PR: https://git.openjdk.java.net/jdk/pull/3775

From iignatyev at openjdk.java.net  Wed Apr 28 21:32:49 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Apr 2021 21:32:49 GMT
Subject: RFR: 8266251: compiler.inlining.InlineAccessors shouldn't do
 testing in driver VM
In-Reply-To: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
References: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
Message-ID: <c6yAvP8rSMl2bfZ6ZouFbmaBqAwGAdMeTrAiO0S_VPo=.b76c4264-2628-445e-b41a-67000777daa0@github.com>

On Wed, 28 Apr 2021 21:03:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which removes redundant and "incorrect" testing from `InlineAccessors` test? as `InlineAccessors::doTest` is called by the JVM which runs `Launcher` class, we aren't actually losing any coverage.
> 
> from JBS:
>> `compiler.inlining.InlineAccessors` test executes `doTest` method in its `InlineAccessors::main`, but InlineAccessors is run in driver mode (so it's not expected to do actual testing and strictly speaking can be executed in JVM other than JVM under test).
> 
> Thanks,
> -- Igor

thanks, Katya.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3774

From epavlova at openjdk.java.net  Wed Apr 28 21:32:48 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Wed, 28 Apr 2021 21:32:48 GMT
Subject: RFR: 8266251: compiler.inlining.InlineAccessors shouldn't do
 testing in driver VM
In-Reply-To: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
References: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
Message-ID: <XfOz7TMFUOW3DNMF4HPQdxR6cd1jEqYdDdktftUIR8I=.d91ac727-1aa3-4af6-8fe3-87d61b39af12@github.com>

On Wed, 28 Apr 2021 21:03:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which removes redundant and "incorrect" testing from `InlineAccessors` test? as `InlineAccessors::doTest` is called by the JVM which runs `Launcher` class, we aren't actually losing any coverage.
> 
> from JBS:
>> `compiler.inlining.InlineAccessors` test executes `doTest` method in its `InlineAccessors::main`, but InlineAccessors is run in driver mode (so it's not expected to do actual testing and strictly speaking can be executed in JVM other than JVM under test).
> 
> Thanks,
> -- Igor

Looks good

-------------

PR: https://git.openjdk.java.net/jdk/pull/3774

From kvn at openjdk.java.net  Wed Apr 28 22:13:48 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 22:13:48 GMT
Subject: RFR: 8266231: mark hotspot compiler/c1 tests which ignore VM flags
In-Reply-To: <Aqbyt7Iozn5oMaaGU16Ptk_8EQgqp9GI7z8JeAU1Igs=.54960312-3ebf-4274-820b-c878764338f3@github.com>
References: <Aqbyt7Iozn5oMaaGU16Ptk_8EQgqp9GI7z8JeAU1Igs=.54960312-3ebf-4274-820b-c878764338f3@github.com>
Message-ID: <-GCpS_UHMGuTkVurtTCBxa4JISNralJKEJy4o1nNgrI=.7c187f59-cd86-4b21-a6c0-4b551233ea3b@github.com>

On Wed, 28 Apr 2021 20:53:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/c1 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3773

From kvn at openjdk.java.net  Wed Apr 28 22:16:49 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 22:16:49 GMT
Subject: RFR: 8266255:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo.java uses wrong package
 name
In-Reply-To: <iwfPzRdKI_eRJEiwRqN59WFCbd4B9Ib0pgJdDq8MhmI=.70eaf721-f94e-4811-aa01-fbb70941b2fc@github.com>
References: <iwfPzRdKI_eRJEiwRqN59WFCbd4B9Ib0pgJdDq8MhmI=.70eaf721-f94e-4811-aa01-fbb70941b2fc@github.com>
Message-ID: <yr-fw-C0lLgtkSa6lJlwXBdiMm1Dge4BugjCBK8dNME=.09755bdd-41ca-4370-b5e9-9e894d41ccb9@github.com>

On Wed, 28 Apr 2021 21:21:44 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that fixes the package name used in `compiler/eliminateAutobox/TestEliminateBoxInDebugInfo.java`?
> 
> Thanks,
> -- Igor

good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3775

From kvn at openjdk.java.net  Wed Apr 28 22:16:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Apr 2021 22:16:52 GMT
Subject: RFR: 8266251: compiler.inlining.InlineAccessors shouldn't do
 testing in driver VM
In-Reply-To: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
References: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
Message-ID: <b9N5IuN0_So96VrEB4Vooc5wPgYrVz4wVlC0epXq9_M=.b29d8400-b64d-4e2b-951f-3973aafdde62@github.com>

On Wed, 28 Apr 2021 21:03:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which removes redundant and "incorrect" testing from `InlineAccessors` test? as `InlineAccessors::doTest` is called by the JVM which runs `Launcher` class, we aren't actually losing any coverage.
> 
> from JBS:
>> `compiler.inlining.InlineAccessors` test executes `doTest` method in its `InlineAccessors::main`, but InlineAccessors is run in driver mode (so it's not expected to do actual testing and strictly speaking can be executed in JVM other than JVM under test).
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3774

From jiefu at openjdk.java.net  Wed Apr 28 23:34:11 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Apr 2021 23:34:11 GMT
Subject: RFR: 8265940: Enable C2's optimization for Math.pow(x,
 0.5) on all platforms [v2]
In-Reply-To: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
References: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
Message-ID: <b1CfTg75z-ZVkhQSnGNN0nvrOBu03YF10P4PAGNPDgg=.1ec21e65-8fcc-4e11-8156-a5751cfdb9e5@github.com>

> Hi all,
> 
> I'd like to enable C2's optimization for Math.pow(x, 0.5) on all platforms.
> 
> This is fine because:
>  1) For x86, it will call the assembly stubs.
>     This opt has already been implemented for x86_64 [1]. 
>     And the x86_32 version is added in this patch.
>  2) For non-x86, it will call the shared runtime c code [2], which does the same opt too.
> 
> Testing:
>   - tier1~3 on Linux/{x86_32, x86_64}, no regression
> 
> Thanks,
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L838
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L497

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Add comments for why -0.0/0.0 are excluded

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3755/files
  - new: https://git.openjdk.java.net/jdk/pull/3755/files/bb88f24f..0b3203ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3755&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3755&range=00-01

  Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3755.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3755/head:pull/3755

PR: https://git.openjdk.java.net/jdk/pull/3755

From jiefu at openjdk.java.net  Wed Apr 28 23:34:12 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Apr 2021 23:34:12 GMT
Subject: RFR: 8265940: Enable C2's optimization for Math.pow(x,
 0.5) on all platforms [v2]
In-Reply-To: <ESf7bnG9qx0Z1VtxQ3-T3EHV0ih3gytP6B9DsSFs8mQ=.ddeeeaf2-37bb-4f9a-9333-1a85d3ffe038@github.com>
References: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
 <ESf7bnG9qx0Z1VtxQ3-T3EHV0ih3gytP6B9DsSFs8mQ=.ddeeeaf2-37bb-4f9a-9333-1a85d3ffe038@github.com>
Message-ID: <W-7tz9lE-fQCUPa_GdVjUQGlWD1cxr0SsRceht1ZuYI=.39d41bb9-f71b-4e59-b016-16793086da6a@github.com>

On Wed, 28 Apr 2021 16:20:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Add comment about why 0. case is skipped: -0.0 case.

Thanks @vnkozlov for your review.

Comments have been added.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3755

From iignatyev at openjdk.java.net  Thu Apr 29 00:15:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 00:15:54 GMT
Subject: RFR: 8266231: mark hotspot compiler/c1 tests which ignore VM flags
In-Reply-To: <Aqbyt7Iozn5oMaaGU16Ptk_8EQgqp9GI7z8JeAU1Igs=.54960312-3ebf-4274-820b-c878764338f3@github.com>
References: <Aqbyt7Iozn5oMaaGU16Ptk_8EQgqp9GI7z8JeAU1Igs=.54960312-3ebf-4274-820b-c878764338f3@github.com>
Message-ID: <nA5LMuM3LA3flYHf3pUpIEt4kKbs1x0IOwtOYcxHqPY=.3edfc292-0463-4b94-8ba9-ad9f69aa777b@github.com>

On Wed, 28 Apr 2021 20:53:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/c1 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

thanks, Vladimir. it would seem you selected 'comment' not 'approve'.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3773

From iignatyev at openjdk.java.net  Thu Apr 29 00:15:53 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 00:15:53 GMT
Subject: RFR: 8266251: compiler.inlining.InlineAccessors shouldn't do
 testing in driver VM
In-Reply-To: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
References: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
Message-ID: <EKlh0OTgZrpVT4W2YFx4GgCgh87YQFuvcEB1TxlvFvY=.79f3652b-7035-4e12-8d88-e932190e8041@github.com>

On Wed, 28 Apr 2021 21:03:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which removes redundant and "incorrect" testing from `InlineAccessors` test? as `InlineAccessors::doTest` is called by the JVM which runs `Launcher` class, we aren't actually losing any coverage.
> 
> from JBS:
>> `compiler.inlining.InlineAccessors` test executes `doTest` method in its `InlineAccessors::main`, but InlineAccessors is run in driver mode (so it's not expected to do actual testing and strictly speaking can be executed in JVM other than JVM under test).
> 
> Thanks,
> -- Igor

Thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3774

From iignatyev at openjdk.java.net  Thu Apr 29 00:15:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 00:15:54 GMT
Subject: RFR: 8266255:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo.java uses wrong package
 name
In-Reply-To: <iwfPzRdKI_eRJEiwRqN59WFCbd4B9Ib0pgJdDq8MhmI=.70eaf721-f94e-4811-aa01-fbb70941b2fc@github.com>
References: <iwfPzRdKI_eRJEiwRqN59WFCbd4B9Ib0pgJdDq8MhmI=.70eaf721-f94e-4811-aa01-fbb70941b2fc@github.com>
Message-ID: <lNNojLWAKMKpMkxQ4H-jDWIIIvZNAsZ2QI2b1yGILDw=.2dfeeb4d-4b16-4666-9912-30c06d9dcb7f@github.com>

On Wed, 28 Apr 2021 21:21:44 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that fixes the package name used in `compiler/eliminateAutobox/TestEliminateBoxInDebugInfo.java`?
> 
> Thanks,
> -- Igor

thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3775

From iignatyev at openjdk.java.net  Thu Apr 29 00:15:53 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 00:15:53 GMT
Subject: Integrated: 8266251: compiler.inlining.InlineAccessors shouldn't do
 testing in driver VM
In-Reply-To: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
References: <-fEMCKgVGe_0TgD4cP1miN5C5HTV-psJLUry2aakzQM=.70796423-f425-4361-b451-928aea51cf40@github.com>
Message-ID: <R0M_SjkoJbJIZJSgAGvZ4WOEjL3DV-VOlclv3HJXYOo=.c275437c-4497-498e-a37c-970f4981d5f8@github.com>

On Wed, 28 Apr 2021 21:03:54 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which removes redundant and "incorrect" testing from `InlineAccessors` test? as `InlineAccessors::doTest` is called by the JVM which runs `Launcher` class, we aren't actually losing any coverage.
> 
> from JBS:
>> `compiler.inlining.InlineAccessors` test executes `doTest` method in its `InlineAccessors::main`, but InlineAccessors is run in driver mode (so it's not expected to do actual testing and strictly speaking can be executed in JVM other than JVM under test).
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 9605aedd
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9605aeddee70ba4f3dba2ae2a3d100319164b03d
Stats:     6 lines in 1 file changed: 0 ins; 4 del; 2 mod

8266251: compiler.inlining.InlineAccessors shouldn't do testing in driver VM

Reviewed-by: kvn, epavlova

-------------

PR: https://git.openjdk.java.net/jdk/pull/3774

From iignatyev at openjdk.java.net  Thu Apr 29 00:15:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 00:15:55 GMT
Subject: Integrated: 8266255:
 compiler/eliminateAutobox/TestEliminateBoxInDebugInfo.java uses wrong package
 name
In-Reply-To: <iwfPzRdKI_eRJEiwRqN59WFCbd4B9Ib0pgJdDq8MhmI=.70eaf721-f94e-4811-aa01-fbb70941b2fc@github.com>
References: <iwfPzRdKI_eRJEiwRqN59WFCbd4B9Ib0pgJdDq8MhmI=.70eaf721-f94e-4811-aa01-fbb70941b2fc@github.com>
Message-ID: <k1L_RUUJkVET9LJRQZ8JGMZa7C62KTw_OZ516T-Uqxs=.0f1c7d8f-6899-4f39-9829-4474088bd4d0@github.com>

On Wed, 28 Apr 2021 21:21:44 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that fixes the package name used in `compiler/eliminateAutobox/TestEliminateBoxInDebugInfo.java`?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 03d4149d
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03d4149d0cd6a33bf42f978a2501664884ebb773
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8266255: compiler/eliminateAutobox/TestEliminateBoxInDebugInfo.java uses wrong package name

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3775

From kvn at openjdk.java.net  Thu Apr 29 00:17:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 29 Apr 2021 00:17:52 GMT
Subject: RFR: 8265940: Enable C2's optimization for Math.pow(x,
 0.5) on all platforms [v2]
In-Reply-To: <b1CfTg75z-ZVkhQSnGNN0nvrOBu03YF10P4PAGNPDgg=.1ec21e65-8fcc-4e11-8156-a5751cfdb9e5@github.com>
References: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
 <b1CfTg75z-ZVkhQSnGNN0nvrOBu03YF10P4PAGNPDgg=.1ec21e65-8fcc-4e11-8156-a5751cfdb9e5@github.com>
Message-ID: <OHR9F_WN13xjV2M6hEaFLIE4_ZoFX-CrWI61YGyhkw8=.23d1f4e8-a67e-4ef0-9f1e-8200219786cf@github.com>

On Wed, 28 Apr 2021 23:34:11 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> I'd like to enable C2's optimization for Math.pow(x, 0.5) on all platforms.
>> 
>> This is fine because:
>>  1) For x86, it will call the assembly stubs.
>>     This opt has already been implemented for x86_64 [1]. 
>>     And the x86_32 version is added in this patch.
>>  2) For non-x86, it will call the shared runtime c code [2], which does the same opt too.
>> 
>> Testing:
>>   - tier1~3 on Linux/{x86_32, x86_64}, no regression
>> 
>> Thanks,
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L838
>> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L497
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments for why -0.0/0.0 are excluded

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3755

From iignatyev at openjdk.java.net  Thu Apr 29 01:05:02 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 01:05:02 GMT
Subject: RFR: 8266256: compiler.vectorization.TestBufferVectorization does
 testing twice
Message-ID: <p43mQF1RoWfCuyrotDEWAw8n1knEh-XcV6B3Mr7Xp6c=.bfc20005-2c43-4bb5-9b8b-6e5036144d7f@github.com>

Hi all,

could you please review this patch that removes work duplication within `TestBufferVectorization` test? 

from JBS:
> `compiler.vectorization.TestBufferVectorization` runs the testing twice, one time in the JVM created by jtreg, and once again by the JVM created by TestBufferVectorization.

after the duplication was removed, it became possible to change the execution mode to `driver`, which is done as part of this patch as well as small refactoring.

Thanks,
-- Igor

-------------

Commit messages:
 - use j.t.lib.Platform::is32bit
 - use switch expression
 - switch to driver mode
 - remove work duplication

Changes: https://git.openjdk.java.net/jdk/pull/3781/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3781&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266256
  Stats: 80 lines in 1 file changed: 30 ins; 42 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3781/head:pull/3781

PR: https://git.openjdk.java.net/jdk/pull/3781

From iignatyev at openjdk.java.net  Thu Apr 29 01:34:07 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 01:34:07 GMT
Subject: RFR: 8266238: mark hotspot compiler/inlining tests which ignore VM
 flags
Message-ID: <2E2gRb8Io5PmZEUEa_EmRKQOj-HVzJgTdJonN-kXYo0=.260f300b-6ced-4471-8e20-8c032c6aaa26@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/inlining` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - copyright year
 - 8266238

Changes: https://git.openjdk.java.net/jdk/pull/3782/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3782&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266238
  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3782.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3782/head:pull/3782

PR: https://git.openjdk.java.net/jdk/pull/3782

From iignatyev at openjdk.java.net  Thu Apr 29 01:37:57 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 01:37:57 GMT
Subject: RFR: 8266264: mark hotspot compiler/eliminateAutobox tests which
 ignore VM flags
Message-ID: <PzepSuIlIDc3B4M76nlv9hptS1wmwT0zMCT80vcQi4c=.6409fe71-4675-483e-92cd-45d9559d4182@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/eliminateAutobox` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - 8266264

Changes: https://git.openjdk.java.net/jdk/pull/3783/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3783&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266264
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3783.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3783/head:pull/3783

PR: https://git.openjdk.java.net/jdk/pull/3783

From yyang at openjdk.java.net  Thu Apr 29 02:33:52 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 02:33:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v2]
In-Reply-To: <Q0BkGMwL3g4JdhCsLQ11X7xlGAfdsyTzY7SqXLw-uJk=.992c8a34-e6f5-4941-be46-53ba5a557df2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <vIU4YK7NVn0A6DV3_vWfyAu_Pma29IufDGkURX9yU5k=.832f8ba4-2243-4743-8ead-214e67218686@github.com>
 <Q0BkGMwL3g4JdhCsLQ11X7xlGAfdsyTzY7SqXLw-uJk=.992c8a34-e6f5-4941-be46-53ba5a557df2@github.com>
Message-ID: <y2RFgnTfMyO9FW5rCXH2HDuOlBhTVTBXVNHUTWeEepQ=.71027855-d8a3-4485-a681-51d85f975cb9@github.com>

On Wed, 28 Apr 2021 17:32:18 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Do we need to keep this flag?

Exactly, the flag should be removed.

Thanks,
Yang

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Thu Apr 29 02:47:19 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 02:47:19 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v3]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <oO4tk_2Yiw_kYXN-HKcgyD9P4T4pIU9x2LL-L7UJjb0=.9563d0aa-8437-4ac6-b23b-0331b030e081@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  remove InlineNIOCheckIndex flag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/7f30dc48..db8b6ef4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=01-02

  Stats: 23 lines in 3 files changed: 11 ins; 11 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Thu Apr 29 02:53:18 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 02:53:18 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v4]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <ECpWrl-zwxikeEMmm9o3N20vuTp-4DymPKnEnYgMmWE=.2cb02211-dbe7-496a-bc3f-386a2fe3173b@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  remove extra newline

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/db8b6ef4..bbdf4b9e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Thu Apr 29 02:58:51 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 02:58:51 GMT
Subject: RFR: 8265711: C1: Intrinsify Class.getModifier method [v3]
In-Reply-To: <rMBogIoB8y6JLdsOI62S7vkgSIQLwFqg4YOjq3KMoDM=.414b238f-4640-4a6a-bae7-009af46ceb92@github.com>
References: <vpN-fONcprAUa3zMPUztCPIOqSq0LdDRMkG3GrGT34w=.8194a8f6-6a31-4b6f-8297-331e913d3a26@github.com>
 <rMBogIoB8y6JLdsOI62S7vkgSIQLwFqg4YOjq3KMoDM=.414b238f-4640-4a6a-bae7-009af46ceb92@github.com>
Message-ID: <APvsZA9jdraLhcej8xM67i-qgGGqZW_VdyRAkRspzg8=.212f906e-bc1d-4be3-bbbd-01e80b405d29@github.com>

On Wed, 28 Apr 2021 06:43:19 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> It's relatively a common case to get modifiers from a constant Class instance, i.e. ThirdPartyClass.class.getModifiers(). Currently, C1 Canonicalizer missed the opportunity of replacing Class.getModifiers intrinsic calls with compile-time constants.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename; redundant reloading

Thank Tobias for reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3616

From kvn at openjdk.java.net  Thu Apr 29 03:39:53 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 29 Apr 2021 03:39:53 GMT
Subject: RFR: 8266231: mark hotspot compiler/c1 tests which ignore VM flags
In-Reply-To: <Aqbyt7Iozn5oMaaGU16Ptk_8EQgqp9GI7z8JeAU1Igs=.54960312-3ebf-4274-820b-c878764338f3@github.com>
References: <Aqbyt7Iozn5oMaaGU16Ptk_8EQgqp9GI7z8JeAU1Igs=.54960312-3ebf-4274-820b-c878764338f3@github.com>
Message-ID: <_kEkf_krvmnVrHIrqtozTHES83aiG9kATt4u20IdLiU=.cf6babe6-d5fc-4135-90cf-286ceece6ae9@github.com>

On Wed, 28 Apr 2021 20:53:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/c1 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3773

From iignatyev at openjdk.java.net  Thu Apr 29 03:39:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 03:39:54 GMT
Subject: Integrated: 8266231: mark hotspot compiler/c1 tests which ignore VM
 flags
In-Reply-To: <Aqbyt7Iozn5oMaaGU16Ptk_8EQgqp9GI7z8JeAU1Igs=.54960312-3ebf-4274-820b-c878764338f3@github.com>
References: <Aqbyt7Iozn5oMaaGU16Ptk_8EQgqp9GI7z8JeAU1Igs=.54960312-3ebf-4274-820b-c878764338f3@github.com>
Message-ID: <U9CYCPyDZS0qHNNyAqy5ZAS-O7v3ZMVWmlPT5dc8zwU=.07cd6ba4-d4ab-44ce-a08c-1a1eaa4f1485@github.com>

On Wed, 28 Apr 2021 20:53:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/c1 ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 69155f43
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/69155f43c18839fec03d315ec6e4ba7b0797da30
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8266231: mark hotspot compiler/c1 tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3773

From kvn at openjdk.java.net  Thu Apr 29 03:45:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 29 Apr 2021 03:45:51 GMT
Subject: RFR: 8266238: mark hotspot compiler/inlining tests which ignore
 VM flags
In-Reply-To: <2E2gRb8Io5PmZEUEa_EmRKQOj-HVzJgTdJonN-kXYo0=.260f300b-6ced-4471-8e20-8c032c6aaa26@github.com>
References: <2E2gRb8Io5PmZEUEa_EmRKQOj-HVzJgTdJonN-kXYo0=.260f300b-6ced-4471-8e20-8c032c6aaa26@github.com>
Message-ID: <YfAGGjM6oOJzC1-nL7F-k25g5_FJ04sXjeGhpRsR4a8=.b8b5d9ff-1b26-4533-9009-28f3b01037af@github.com>

On Thu, 29 Apr 2021 01:27:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/inlining` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3782

From kvn at openjdk.java.net  Thu Apr 29 03:45:50 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 29 Apr 2021 03:45:50 GMT
Subject: RFR: 8266256: compiler.vectorization.TestBufferVectorization does
 testing twice
In-Reply-To: <p43mQF1RoWfCuyrotDEWAw8n1knEh-XcV6B3Mr7Xp6c=.bfc20005-2c43-4bb5-9b8b-6e5036144d7f@github.com>
References: <p43mQF1RoWfCuyrotDEWAw8n1knEh-XcV6B3Mr7Xp6c=.bfc20005-2c43-4bb5-9b8b-6e5036144d7f@github.com>
Message-ID: <OdJG2vDy-sE2dofNZDcsFtYp7Q_pk8rhvuKAS2yrWoM=.88aac255-0bb0-46dd-9e58-a6200de44e15@github.com>

On Thu, 29 Apr 2021 00:58:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this patch that removes work duplication within `TestBufferVectorization` test? 
> 
> from JBS:
>> `compiler.vectorization.TestBufferVectorization` runs the testing twice, one time in the JVM created by jtreg, and once again by the JVM created by TestBufferVectorization.
> 
> after the duplication was removed, it became possible to change the execution mode to `driver`, which is done as part of this patch as well as small refactoring.
> 
> Thanks,
> -- Igor

Nice fix.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3781

From kvn at openjdk.java.net  Thu Apr 29 03:46:56 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 29 Apr 2021 03:46:56 GMT
Subject: RFR: 8266264: mark hotspot compiler/eliminateAutobox tests which
 ignore VM flags
In-Reply-To: <PzepSuIlIDc3B4M76nlv9hptS1wmwT0zMCT80vcQi4c=.6409fe71-4675-483e-92cd-45d9559d4182@github.com>
References: <PzepSuIlIDc3B4M76nlv9hptS1wmwT0zMCT80vcQi4c=.6409fe71-4675-483e-92cd-45d9559d4182@github.com>
Message-ID: <Nfl-JVo-r4eEuga2_4VO-k7hg6uZeRuPSMQDtvflOhI=.1c0cf71d-3dec-4617-82ef-2daf2de5b03c@github.com>

On Thu, 29 Apr 2021 01:30:47 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/eliminateAutobox` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3783

From iignatyev at openjdk.java.net  Thu Apr 29 03:52:56 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 03:52:56 GMT
Subject: RFR: 8266238: mark hotspot compiler/inlining tests which ignore
 VM flags
In-Reply-To: <2E2gRb8Io5PmZEUEa_EmRKQOj-HVzJgTdJonN-kXYo0=.260f300b-6ced-4471-8e20-8c032c6aaa26@github.com>
References: <2E2gRb8Io5PmZEUEa_EmRKQOj-HVzJgTdJonN-kXYo0=.260f300b-6ced-4471-8e20-8c032c6aaa26@github.com>
Message-ID: <veYtJd6-dLVK5On_WG6GBwY38bjUBmotnA5b8JKNQPk=.ad44267b-1539-41e4-9ab4-987eac3c540a@github.com>

On Thu, 29 Apr 2021 01:27:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/inlining` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Thank you, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3782

From iignatyev at openjdk.java.net  Thu Apr 29 03:53:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 03:53:52 GMT
Subject: RFR: 8266256: compiler.vectorization.TestBufferVectorization does
 testing twice
In-Reply-To: <p43mQF1RoWfCuyrotDEWAw8n1knEh-XcV6B3Mr7Xp6c=.bfc20005-2c43-4bb5-9b8b-6e5036144d7f@github.com>
References: <p43mQF1RoWfCuyrotDEWAw8n1knEh-XcV6B3Mr7Xp6c=.bfc20005-2c43-4bb5-9b8b-6e5036144d7f@github.com>
Message-ID: <JJFfQ6B5eXa3u-k5kbZE_V60DqiE30b6qK5raMY13Ww=.55cc4d7b-a9c8-482e-8acf-f0b584ce3078@github.com>

On Thu, 29 Apr 2021 00:58:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this patch that removes work duplication within `TestBufferVectorization` test? 
> 
> from JBS:
>> `compiler.vectorization.TestBufferVectorization` runs the testing twice, one time in the JVM created by jtreg, and once again by the JVM created by TestBufferVectorization.
> 
> after the duplication was removed, it became possible to change the execution mode to `driver`, which is done as part of this patch as well as small refactoring.
> 
> Thanks,
> -- Igor

Thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3781

From iignatyev at openjdk.java.net  Thu Apr 29 03:53:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 03:53:52 GMT
Subject: Integrated: 8266256: compiler.vectorization.TestBufferVectorization
 does testing twice
In-Reply-To: <p43mQF1RoWfCuyrotDEWAw8n1knEh-XcV6B3Mr7Xp6c=.bfc20005-2c43-4bb5-9b8b-6e5036144d7f@github.com>
References: <p43mQF1RoWfCuyrotDEWAw8n1knEh-XcV6B3Mr7Xp6c=.bfc20005-2c43-4bb5-9b8b-6e5036144d7f@github.com>
Message-ID: <1HvC4pYDKIMIh37e3tra35j4kNu8jv9C7slt-6cYv6o=.8207cbeb-060c-487a-9b69-85b959bad4bb@github.com>

On Thu, 29 Apr 2021 00:58:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this patch that removes work duplication within `TestBufferVectorization` test? 
> 
> from JBS:
>> `compiler.vectorization.TestBufferVectorization` runs the testing twice, one time in the JVM created by jtreg, and once again by the JVM created by TestBufferVectorization.
> 
> after the duplication was removed, it became possible to change the execution mode to `driver`, which is done as part of this patch as well as small refactoring.
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 6b263e68
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b263e6832ca13e43b0389434ef196ee7be458c7
Stats:     80 lines in 1 file changed: 30 ins; 42 del; 8 mod

8266256: compiler.vectorization.TestBufferVectorization does testing twice

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3781

From iignatyev at openjdk.java.net  Thu Apr 29 03:54:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 03:54:54 GMT
Subject: RFR: 8266264: mark hotspot compiler/eliminateAutobox tests which
 ignore VM flags
In-Reply-To: <PzepSuIlIDc3B4M76nlv9hptS1wmwT0zMCT80vcQi4c=.6409fe71-4675-483e-92cd-45d9559d4182@github.com>
References: <PzepSuIlIDc3B4M76nlv9hptS1wmwT0zMCT80vcQi4c=.6409fe71-4675-483e-92cd-45d9559d4182@github.com>
Message-ID: <_lav2wr7eZCJyrK1W1-d46A0tu8kF7pVqZzZf4M_QUE=.4b85090a-2390-4ef3-b62d-7baa4d95e8bc@github.com>

On Thu, 29 Apr 2021 01:30:47 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/eliminateAutobox` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Thanks, Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3783

From iignatyev at openjdk.java.net  Thu Apr 29 03:54:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 03:54:55 GMT
Subject: Integrated: 8266264: mark hotspot compiler/eliminateAutobox tests
 which ignore VM flags
In-Reply-To: <PzepSuIlIDc3B4M76nlv9hptS1wmwT0zMCT80vcQi4c=.6409fe71-4675-483e-92cd-45d9559d4182@github.com>
References: <PzepSuIlIDc3B4M76nlv9hptS1wmwT0zMCT80vcQi4c=.6409fe71-4675-483e-92cd-45d9559d4182@github.com>
Message-ID: <G_JLnxGMOUbE9sufhCjyv3hnjC4CK3hygtxsTEHJNKA=.49a80dab-9fb1-488f-b30f-28516fda6d09@github.com>

On Thu, 29 Apr 2021 01:30:47 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/eliminateAutobox` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: df3b2d04
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/df3b2d0495d4517832c8059ab80911f1e6e3a2bb
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8266264: mark hotspot compiler/eliminateAutobox tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3783

From iignatyev at openjdk.java.net  Thu Apr 29 03:55:51 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 03:55:51 GMT
Subject: Integrated: 8266238: mark hotspot compiler/inlining tests which
 ignore VM flags
In-Reply-To: <2E2gRb8Io5PmZEUEa_EmRKQOj-HVzJgTdJonN-kXYo0=.260f300b-6ced-4471-8e20-8c032c6aaa26@github.com>
References: <2E2gRb8Io5PmZEUEa_EmRKQOj-HVzJgTdJonN-kXYo0=.260f300b-6ced-4471-8e20-8c032c6aaa26@github.com>
Message-ID: <yJaYb_iz1pjGrJ2G7Z_xfsX3yRwTKgnp8xdSomGD4xs=.fd04a16a-73ff-42df-9a2d-54650782856a@github.com>

On Thu, 29 Apr 2021 01:27:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/inlining` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: b305eff7
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b305eff7d358799b91d17f1e4acd3aab1ba5a397
Stats:     3 lines in 2 files changed: 2 ins; 0 del; 1 mod

8266238: mark hotspot compiler/inlining tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3782

From iignatyev at openjdk.java.net  Thu Apr 29 04:27:07 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 04:27:07 GMT
Subject: RFR: 8266265: mark hotspot compiler/vectorization tests which ignore
 VM flags
Message-ID: <mkAONKvaXwreZCg9PEwYq1U6M1DQ7yyNmGr4uBzS_F4=.cd8e8e6b-fe02-4c49-9300-c1a398cba7fc@github.com>

Hi all,

could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/vectorization ` tests that ignore VM flags?

Thanks,
-- Igor

-------------

Commit messages:
 - 8266265

Changes: https://git.openjdk.java.net/jdk/pull/3785/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3785&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266265
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3785.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3785/head:pull/3785

PR: https://git.openjdk.java.net/jdk/pull/3785

From kvn at openjdk.java.net  Thu Apr 29 04:46:50 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 29 Apr 2021 04:46:50 GMT
Subject: RFR: 8266265: mark hotspot compiler/vectorization tests which
 ignore VM flags
In-Reply-To: <mkAONKvaXwreZCg9PEwYq1U6M1DQ7yyNmGr4uBzS_F4=.cd8e8e6b-fe02-4c49-9300-c1a398cba7fc@github.com>
References: <mkAONKvaXwreZCg9PEwYq1U6M1DQ7yyNmGr4uBzS_F4=.cd8e8e6b-fe02-4c49-9300-c1a398cba7fc@github.com>
Message-ID: <Kc-kzBs_-ctfMZxGDVOfjzzrUv177Vh-sZ-VTkp2z8A=.459b5366-c372-4e36-ac11-75cf4d125af1@github.com>

On Thu, 29 Apr 2021 04:17:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/vectorization ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3785

From iignatyev at openjdk.java.net  Thu Apr 29 04:56:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 04:56:48 GMT
Subject: RFR: 8266265: mark hotspot compiler/vectorization tests which
 ignore VM flags
In-Reply-To: <mkAONKvaXwreZCg9PEwYq1U6M1DQ7yyNmGr4uBzS_F4=.cd8e8e6b-fe02-4c49-9300-c1a398cba7fc@github.com>
References: <mkAONKvaXwreZCg9PEwYq1U6M1DQ7yyNmGr4uBzS_F4=.cd8e8e6b-fe02-4c49-9300-c1a398cba7fc@github.com>
Message-ID: <B9e2oVfbxLr9SqB7gXtZ2Mv2J4ffDTcUVRtk5I9DX3s=.5a7f193c-78e4-40f5-92f1-e094535ac6b8@github.com>

On Thu, 29 Apr 2021 04:17:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/vectorization ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

Thanks, Vladimir!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3785

From iignatyev at openjdk.java.net  Thu Apr 29 04:56:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Apr 2021 04:56:48 GMT
Subject: Integrated: 8266265: mark hotspot compiler/vectorization tests which
 ignore VM flags
In-Reply-To: <mkAONKvaXwreZCg9PEwYq1U6M1DQ7yyNmGr4uBzS_F4=.cd8e8e6b-fe02-4c49-9300-c1a398cba7fc@github.com>
References: <mkAONKvaXwreZCg9PEwYq1U6M1DQ7yyNmGr4uBzS_F4=.cd8e8e6b-fe02-4c49-9300-c1a398cba7fc@github.com>
Message-ID: <q0kUYdQ6h7_1fZmCoh6eqCmnscCesmrmfkBwHOi0PEA=.c4faa37f-4d8a-44d2-8e03-375aabeaeb2d@github.com>

On Thu, 29 Apr 2021 04:17:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial patch that adds `@requires vm.flagless` to `compiler/vectorization ` tests that ignore VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 56cde70d
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/56cde70da271ef5437d5544b3bd9ba26e4148af1
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8266265: mark hotspot compiler/vectorization tests which ignore VM flags

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3785

From jiefu at openjdk.java.net  Thu Apr 29 05:11:00 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 29 Apr 2021 05:11:00 GMT
Subject: RFR: 8266267: Remove unnecessary jumps in Intel Math Library
 StubRoutines
Message-ID: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>

Hi all,

May I get reviews for this small change?

If I look at the StubRoutines::libmPow carefully, an unnecessary jump instruction can be found, which is generated here [1].

- - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
StubRoutines::libmPow [0x00007f0f8455ddd1, 0x00007f0f8455ef05] (4404 bytes)
--------------------------------------------------------------------------------
  0x00007f0f8455ddd1:   push   %rbp
  0x00007f0f8455ddd2:   mov    %rsp,%rbp
  0x00007f0f8455ddd5:   jmpq   0x00007f0f8455ddda          <--- unnecessary jump
  0x00007f0f8455ddda:   sub    $0x28,%rsp
  0x00007f0f8455ddde:   vmovsd %xmm0,0x8(%rsp)
  0x00007f0f8455dde4:   vmovsd %xmm1,0x10(%rsp)
  ...


And similar issues can be found for StubRoutines::libmLog and StubRoutines::libmExp.

- - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
StubRoutines::libmLog [0x00007f3fb94d48a6, 0x00007f3fb94d4b22] (636 bytes)
--------------------------------------------------------------------------------
  0x00007f3fb94d48a6:   push   %rbp
  0x00007f3fb94d48a7:   mov    %rsp,%rbp
  0x00007f3fb94d48aa:   jmpq   0x00007f3fb94d48af          <--- unnecessary jump
  0x00007f3fb94d48af:   sub    $0x18,%rsp
  0x00007f3fb94d48b3:   vmovsd %xmm0,(%rsp)
  0x00007f3fb94d48b8:   movabs $0x3ff0000000000000,%rax
  ...



- - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
StubRoutines::libmExp [0x00007f3fb94d4579, 0x00007f3fb94d48a6] (813 bytes)
--------------------------------------------------------------------------------
  0x00007f3fb94d4579:   push   %rbp
  0x00007f3fb94d457a:   mov    %rsp,%rbp
  0x00007f3fb94d457d:   jmpq   0x00007f3fb94d4582          <--- unnecessary jump
  0x00007f3fb94d4582:   sub    $0x18,%rsp
  0x00007f3fb94d4586:   vmovsd %xmm0,0x8(%rsp)
  0x00007f3fb94d458c:   vunpcklpd %xmm0,%xmm0,%xmm0


I can't find a reason why we need an extra jump there.
So I suggest removing them.

Testing:
  - tier1 ~ tier3 on Linux/x64, no regression

Am I missing something?

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8266267: Remove unnecessary jumps in Intel Math Library StubRoutines

Changes: https://git.openjdk.java.net/jdk/pull/3784/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3784&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266267
  Stats: 7 lines in 3 files changed: 2 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3784.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3784/head:pull/3784

PR: https://git.openjdk.java.net/jdk/pull/3784

From jiefu at openjdk.java.net  Thu Apr 29 07:04:52 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 29 Apr 2021 07:04:52 GMT
Subject: Integrated: 8265940: Enable C2's optimization for Math.pow(x,
 0.5) on all platforms
In-Reply-To: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
References: <WJwM004AxWs0xUHE7SUcaWcrmsYz7ClFIPuHOh8MCI8=.bdd6472d-4928-478f-b5e9-90d2376f576e@github.com>
Message-ID: <G-rN2CbXQL7dmx9myrFUEe9h_4HE8sgYJ1mwkmRYgsg=.0524371d-b039-41ea-908f-e87ac35a14c3@github.com>

On Wed, 28 Apr 2021 08:10:36 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to enable C2's optimization for Math.pow(x, 0.5) on all platforms.
> 
> This is fine because:
>  1) For x86, it will call the assembly stubs.
>     This opt has already been implemented for x86_64 [1]. 
>     And the x86_32 version is added in this patch.
>  2) For non-x86, it will call the shared runtime c code [2], which does the same opt too.
> 
> Testing:
>   - tier1~3 on Linux/{x86_32, x86_64}, no regression
> 
> Thanks,
> Best regards,
> Jie
> 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp#L838
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntimeTrans.cpp#L497

This pull request has now been integrated.

Changeset: 91226fa1
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/91226fa12247765f53469ad8db02db7b7b23aaf1
Stats:     27 lines in 3 files changed: 20 ins; 4 del; 3 mod

8265940: Enable C2's optimization for Math.pow(x, 0.5) on all platforms

Reviewed-by: neliasso, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3755

From whuang at openjdk.java.net  Thu Apr 29 08:05:50 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 29 Apr 2021 08:05:50 GMT
Subject: RFR: 8265244: assert(false) failed: bad AD file [v2]
In-Reply-To: <RWSogn_WX6pqEdOkKWMxcaBtx6FsojnSZytqZ0oUfpI=.1a6863a2-dd64-41f8-8b5f-17a39cdc5f3b@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
 <RWSogn_WX6pqEdOkKWMxcaBtx6FsojnSZytqZ0oUfpI=.1a6863a2-dd64-41f8-8b5f-17a39cdc5f3b@github.com>
Message-ID: <SusvEXYoPJy2QBy1mU78ZINJfa3TwFJaH07lRDTBoYs=.2125d7a9-bef5-4e7e-97f4-d4aa80089d11@github.com>

On Wed, 28 Apr 2021 12:53:24 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Please change the bug and PR title to something that describes the problem or solution.

Thank you for  your review. I will change that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3507

From xgong at openjdk.java.net  Thu Apr 29 09:05:07 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 29 Apr 2021 09:05:07 GMT
Subject: RFR: 8265956: JVM crashes when matching LShiftVB Node [v2]
In-Reply-To: <5foREhwZRJeBLxZAVwi8ZrLr1lrZKAOgBi9bQkfLSo4=.f2dfed9b-61bc-4f95-a8c8-250fcec83bbc@github.com>
References: <0lX7U-sIV4c6Wi1Cyw3caRD6ZTVCIYzbiiji3uPXf4M=.c0494113-32c5-40c4-bdd7-93b226ffe236@github.com>
 <xLNhEF-RBuHsL7HMxPn_JhdySfiJeztSQnJXUOVdsVk=.45dbda60-97dc-4173-9772-d8c7325b67ec@github.com>
 <5foREhwZRJeBLxZAVwi8ZrLr1lrZKAOgBi9bQkfLSo4=.f2dfed9b-61bc-4f95-a8c8-250fcec83bbc@github.com>
Message-ID: <WPyXLvAszFwAB9loB-m6QdRmevvjMowvwjDxVDsr0IQ=.adfdfb84-ba95-4936-9f0b-a205b8b6f1de@github.com>

On Thu, 29 Apr 2021 08:58:35 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add m4 file
>
> src/hotspot/cpu/aarch64/aarch64_neon.ad line 5292:
> 
>> 5290:             n->as_Vector()->length() == 8);
>> 5291:   match(Set dst (LShiftVB src (LShiftCntV shift)));
>> 5292:   match(Set dst (LShiftVB src shift));
> 
> Does it make sense if changing the mid-end codes to make sure the immediate shift is broadcasted to a vector?

This could avoid fixing the missing rules for all related architecture.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3747

From xgong at openjdk.java.net  Thu Apr 29 09:05:06 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 29 Apr 2021 09:05:06 GMT
Subject: RFR: 8265956: JVM crashes when matching LShiftVB Node [v2]
In-Reply-To: <xLNhEF-RBuHsL7HMxPn_JhdySfiJeztSQnJXUOVdsVk=.45dbda60-97dc-4173-9772-d8c7325b67ec@github.com>
References: <0lX7U-sIV4c6Wi1Cyw3caRD6ZTVCIYzbiiji3uPXf4M=.c0494113-32c5-40c4-bdd7-93b226ffe236@github.com>
 <xLNhEF-RBuHsL7HMxPn_JhdySfiJeztSQnJXUOVdsVk=.45dbda60-97dc-4173-9772-d8c7325b67ec@github.com>
Message-ID: <5foREhwZRJeBLxZAVwi8ZrLr1lrZKAOgBi9bQkfLSo4=.f2dfed9b-61bc-4f95-a8c8-250fcec83bbc@github.com>

On Wed, 28 Apr 2021 09:52:22 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> It is fount that the rule `match(Set dst (LShiftVB src shift))` is missing on many cpus, such like `aarch64` and `x86`. It is this reason that JVM will crash under `JDK-8265956`'s test case. In this commit, I :
>> * show the crash case `TestVectorShuffleIotaShort`
>> * solve the issue on `aarch64` and `x86` by adding the rule. 
>> * test after fixing on tire1~3
>> 
>> Thank you for your review. Any suggestion is welcome. 
>>                          Wang Huang
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add m4 file

src/hotspot/cpu/aarch64/aarch64_neon.ad line 5292:

> 5290:             n->as_Vector()->length() == 8);
> 5291:   match(Set dst (LShiftVB src (LShiftCntV shift)));
> 5292:   match(Set dst (LShiftVB src shift));

Does it make sense if changing the mid-end codes to make sure the immediate shift is broadcasted to a vector?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3747

From jbhateja at openjdk.java.net  Thu Apr 29 09:07:56 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 29 Apr 2021 09:07:56 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v12]
In-Reply-To: <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>
Message-ID: <FK4kqyBzqgQvplorM0EcuEziNsUlBzQ-XYbs-9OxMHM=.d1ab9fa4-3de7-4b83-ac50-4e05b555d42f@github.com>

On Wed, 28 Apr 2021 19:26:21 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:
> 
>   jatin-bhateja review
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marked as reviewed by jbhateja (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From jbhateja at openjdk.java.net  Thu Apr 29 09:07:56 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 29 Apr 2021 09:07:56 GMT
Subject: RFR: 8265491: Math Signum optimization for x86
In-Reply-To: <R6I61hf1_yOOru812U3yV0G2b5O2ccs43Te4grxtzgg=.1a96a013-80bb-4d83-bdf5-05d91dc0c19e@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <R6I61hf1_yOOru812U3yV0G2b5O2ccs43Te4grxtzgg=.1a96a013-80bb-4d83-bdf5-05d91dc0c19e@github.com>
Message-ID: <eWhLQg_8RE_mzdwq4UfFulIycjG5UrNDaWGaWmy_kCo=.9f661ee9-125b-44ec-86d5-f3c8d57c64aa@github.com>

On Tue, 20 Apr 2021 08:38:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  ns/op
>> 
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> @mgkwill,  your newly added benchmark has 4 micro worklets, please publish the results for all of them.

> Thanks for your review @jatin-bhateja. I've implemented your suggested changes.

Thanks Marcus!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From xgong at openjdk.java.net  Thu Apr 29 09:08:54 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 29 Apr 2021 09:08:54 GMT
Subject: RFR: 8265907: JVM crashes when matching VectorMaskCmp Node [v3]
In-Reply-To: <_otBn8mWHgqdIjnZ6yiBu_T6F5076C_aKL7yMHe-sHo=.d94a0510-0e91-4286-814c-5b568d7ce923@github.com>
References: <u-7MdHM6IGvkXcRUDh8miqL3nMx7SKaHxTD1WMqX674=.b791dd7f-1d65-42ba-9c6e-9ff1eee73ce3@github.com>
 <_otBn8mWHgqdIjnZ6yiBu_T6F5076C_aKL7yMHe-sHo=.d94a0510-0e91-4286-814c-5b568d7ce923@github.com>
Message-ID: <4RMST03w1Ki2jJXp9kcW_klAc78RhD5Jv_H4GYXt26c=.31270330-a7fb-4818-a559-ece801629fac@github.com>

On Mon, 26 Apr 2021 07:47:05 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * fix the issue JDK-8265907
>> * all archs might be effected by this bug. I fixed x86 and aarch64.
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix x86's bug

src/hotspot/cpu/x86/x86.ad line 1814:

> 1812:         return false;
> 1813:       }
> 1814:       break;

Did you also see the crash on x86?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3670

From xgong at openjdk.java.net  Thu Apr 29 09:17:53 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 29 Apr 2021 09:17:53 GMT
Subject: RFR: 8265244: Remove useless comparation in
 LibraryCallKit::inline_vector_convert() [v2]
In-Reply-To: <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
Message-ID: <EP012IjVxLL4jjOV58gqFrqPvZYuZ0F9j8TUeb_ieV0=.659cb492-9f54-4a53-b86b-544288923716@github.com>

On Fri, 16 Apr 2021 02:10:10 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * aarch64 can only accept `VectorReinterpret` with 64/128 bits.
>> * I will fix this bug by adding a rule for `VectorReinterpret` in `match_rule_supported_vector`
>> * after changing note with @nsjian and @XiaohongGong , I think that two checks in `inline_vector_conver` is useless now. However, these checks impact other cpus, so I need more reviewers.
>
> Wang Huang 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 JDK-8265244
>  - 8265244: assert(false) failed: bad AD file

src/hotspot/cpu/aarch64/aarch64.ad line 2405:

> 2403:     switch (opcode) {
> 2404:     case Op_VectorReinterpret:
> 2405:       if (bit_size != 64 && bit_size != 128) {

bit_size < 64 ?

test/hotspot/jtreg/compiler/vectorapi/TestCast4STo2I.java line 39:

> 37: 
> 38: public class TestCast4STo2I {
> 39:     static final VectorSpecies<Short> SPECIESs = ShortVector.SPECIES_64;

SPECIES_S?

test/hotspot/jtreg/compiler/vectorapi/TestCast4STo2I.java line 40:

> 38: public class TestCast4STo2I {
> 39:     static final VectorSpecies<Short> SPECIESs = ShortVector.SPECIES_64;
> 40:     static final VectorSpecies<Integer> SPECIESi = IntVector.SPECIES_64;

ditto

test/hotspot/jtreg/compiler/vectorapi/TestCast4STo2I.java line 72:

> 70:         for (int i = 0; i < SIZE; i++) {
> 71:             System.out.print(ai[i] + ", ");
> 72:         }

It's better to add the correctness testing as well to make sure the results are right.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3507

From whuang at openjdk.java.net  Thu Apr 29 09:17:55 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 29 Apr 2021 09:17:55 GMT
Subject: RFR: 8265244: Remove useless comparation in
 LibraryCallKit::inline_vector_convert() [v2]
In-Reply-To: <EP012IjVxLL4jjOV58gqFrqPvZYuZ0F9j8TUeb_ieV0=.659cb492-9f54-4a53-b86b-544288923716@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
 <EP012IjVxLL4jjOV58gqFrqPvZYuZ0F9j8TUeb_ieV0=.659cb492-9f54-4a53-b86b-544288923716@github.com>
Message-ID: <RKlLaUzr3lcEH8NQ5BlC732VAHgH2NczaCkANhmlGis=.0a88bd22-35ee-4b51-ae1d-b979e06a1aa7@github.com>

On Thu, 29 Apr 2021 09:08:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Wang Huang 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 JDK-8265244
>>  - 8265244: assert(false) failed: bad AD file
>
> src/hotspot/cpu/aarch64/aarch64.ad line 2405:
> 
>> 2403:     switch (opcode) {
>> 2404:     case Op_VectorReinterpret:
>> 2405:       if (bit_size != 64 && bit_size != 128) {
> 
> bit_size < 64 ?

Reinterpret's size should bit_size == 64 ||  bit_size == 128

-------------

PR: https://git.openjdk.java.net/jdk/pull/3507

From jiefu at openjdk.java.net  Thu Apr 29 09:18:53 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 29 Apr 2021 09:18:53 GMT
Subject: RFR: 8265956: JVM crashes when matching LShiftVB Node [v2]
In-Reply-To: <xLNhEF-RBuHsL7HMxPn_JhdySfiJeztSQnJXUOVdsVk=.45dbda60-97dc-4173-9772-d8c7325b67ec@github.com>
References: <0lX7U-sIV4c6Wi1Cyw3caRD6ZTVCIYzbiiji3uPXf4M=.c0494113-32c5-40c4-bdd7-93b226ffe236@github.com>
 <xLNhEF-RBuHsL7HMxPn_JhdySfiJeztSQnJXUOVdsVk=.45dbda60-97dc-4173-9772-d8c7325b67ec@github.com>
Message-ID: <MMXOsTWaW1QtSecL_T5TB9CtgH1uXvtIasgDTwExTj0=.fbbdec5b-29b4-458f-bda6-ff60f83feab2@github.com>

On Wed, 28 Apr 2021 09:52:22 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> It is fount that the rule `match(Set dst (LShiftVB src shift))` is missing on many cpus, such like `aarch64` and `x86`. It is this reason that JVM will crash under `JDK-8265956`'s test case. In this commit, I :
>> * show the crash case `TestVectorShuffleIotaShort`
>> * solve the issue on `aarch64` and `x86` by adding the rule. 
>> * test after fixing on tire1~3
>> 
>> Thank you for your review. Any suggestion is welcome. 
>>                          Wang Huang
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add m4 file

test/hotspot/jtreg/compiler/vectorapi/TestVectorShuffleIotaShort.java line 44:

> 42:     static short[] as = {87, 65, 78, 71, 72, 69, 82, 69};
> 43: 
> 44:     public static void testShuffleS() {

IMO, this test is not enough since the assembly code is not easy to get reviewed.

So I suggest to improve your test:
 1) Test as many match-patterns you added as possible
 2) Verify the results in your tests

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3747

From jiefu at openjdk.java.net  Thu Apr 29 09:22:52 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 29 Apr 2021 09:22:52 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v12]
In-Reply-To: <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>
Message-ID: <uSGgAmMWiljiX9a64Ke5k89084rzb-R78N50PxvuNqk=.e42f6594-aa3b-4302-8e89-15dcca48c44c@github.com>

On Wed, 28 Apr 2021 19:26:21 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:
> 
>   jatin-bhateja review
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marked as reviewed by jiefu (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From enikitin at openjdk.java.net  Thu Apr 29 09:24:12 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Thu, 29 Apr 2021 09:24:12 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion. [v3]
In-Reply-To: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
References: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
Message-ID: <o3wUK_MDh_CQn2bO03PJKln--Y7ZoclXghDKGxAuT_w=.694a8917-cb2c-443c-a525-87a031bd6c3e@github.com>

> The bug: https://bugs.openjdk.java.net/browse/JDK-8265349
> 
> A repetition of the JDK-8058176 (mlvm tests cause code cache exhaustion), this time with -Xcomp. My measurements show up max code cache consumption of 400-500 kb per test thread and tree (depends on random tree and other factors, of course, but still). For the whole test which usually doesn't exceed 10 threads, I've got max. value of 6.1M for one sequence/tree build (between checks for remaining free space).
> 
> So I suggest to raise the allowances to 10M, just to be safe. Compared to the 103 Mb of required code cache space that test requests via the 'run' parameter, it doesn't look that much.
> 
> Thanks in advance,
> // Evgeny Nikitin.

Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:

  Explain limits numbers, extract code cache monitoring into a class

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3762/files
  - new: https://git.openjdk.java.net/jdk/pull/3762/files/fa15d577..c3f52fbf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3762&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3762&range=01-02

  Stats: 74 lines in 1 file changed: 37 ins; 16 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3762.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3762/head:pull/3762

PR: https://git.openjdk.java.net/jdk/pull/3762

From whuang at openjdk.java.net  Thu Apr 29 09:32:50 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 29 Apr 2021 09:32:50 GMT
Subject: RFR: 8265956: JVM crashes when matching LShiftVB Node [v2]
In-Reply-To: <WPyXLvAszFwAB9loB-m6QdRmevvjMowvwjDxVDsr0IQ=.adfdfb84-ba95-4936-9f0b-a205b8b6f1de@github.com>
References: <0lX7U-sIV4c6Wi1Cyw3caRD6ZTVCIYzbiiji3uPXf4M=.c0494113-32c5-40c4-bdd7-93b226ffe236@github.com>
 <xLNhEF-RBuHsL7HMxPn_JhdySfiJeztSQnJXUOVdsVk=.45dbda60-97dc-4173-9772-d8c7325b67ec@github.com>
 <5foREhwZRJeBLxZAVwi8ZrLr1lrZKAOgBi9bQkfLSo4=.f2dfed9b-61bc-4f95-a8c8-250fcec83bbc@github.com>
 <WPyXLvAszFwAB9loB-m6QdRmevvjMowvwjDxVDsr0IQ=.adfdfb84-ba95-4936-9f0b-a205b8b6f1de@github.com>
Message-ID: <__0_MjMYQoONMscsj41KZYOgKZef6mj9kmRm9WjuO74=.26c46cb6-01c2-4357-b471-feafa44678f6@github.com>

On Thu, 29 Apr 2021 09:01:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/aarch64_neon.ad line 5292:
>> 
>>> 5290:             n->as_Vector()->length() == 8);
>>> 5291:   match(Set dst (LShiftVB src (LShiftCntV shift)));
>>> 5292:   match(Set dst (LShiftVB src shift));
>> 
>> Does it make sense if changing the mid-end codes to make sure the immediate shift is broadcasted to a vector?
>
> This could avoid fixing the missing rules for all related architecture.

`x86` misses the rule `match(Set dst (LShiftVB src (LShiftCntV imm))); `. If we choose to fix it by adding IR `LShiftCntV`.  Anyway,  adding a `LShiftCntV` here may be more clear. I will refact the code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3747

From dfuchs at openjdk.java.net  Thu Apr 29 09:33:58 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 29 Apr 2021 09:33:58 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v4]
In-Reply-To: <ECpWrl-zwxikeEMmm9o3N20vuTp-4DymPKnEnYgMmWE=.2cb02211-dbe7-496a-bc3f-386a2fe3173b@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <ECpWrl-zwxikeEMmm9o3N20vuTp-4DymPKnEnYgMmWE=.2cb02211-dbe7-496a-bc3f-386a2fe3173b@github.com>
Message-ID: <gYK8_Hj986HHZwEI1OhRFqEj3OpaQAIr_vCuoIFbIUU=.280ab91b-8ea7-473e-9271-7c8aeff3253e@github.com>

On Thu, 29 Apr 2021 02:53:18 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove extra newline

test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 60:

> 58:         } catch (IndexOutOfBoundsException e) {
> 59:             // got it!
> 60:         }

In all places where `Precondition.checkIndex` is expected to throw, an AssertionError should  be generated if it doesn't throw:


        try {
            Preconditions.checkIndex(1, 1, null);
            throw new AssertionError("Expected IndexOutOfBoundsException not thrown");
        } catch (IndexOutOfBoundsException e) {
            // got it!
        }

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From whuang at openjdk.java.net  Thu Apr 29 09:49:51 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 29 Apr 2021 09:49:51 GMT
Subject: RFR: 8265956: JVM crashes when matching LShiftVB Node [v2]
In-Reply-To: <MMXOsTWaW1QtSecL_T5TB9CtgH1uXvtIasgDTwExTj0=.fbbdec5b-29b4-458f-bda6-ff60f83feab2@github.com>
References: <0lX7U-sIV4c6Wi1Cyw3caRD6ZTVCIYzbiiji3uPXf4M=.c0494113-32c5-40c4-bdd7-93b226ffe236@github.com>
 <xLNhEF-RBuHsL7HMxPn_JhdySfiJeztSQnJXUOVdsVk=.45dbda60-97dc-4173-9772-d8c7325b67ec@github.com>
 <MMXOsTWaW1QtSecL_T5TB9CtgH1uXvtIasgDTwExTj0=.fbbdec5b-29b4-458f-bda6-ff60f83feab2@github.com>
Message-ID: <60cbUKCkV72llQ8cxJa08bTGnaRt25UspcoD-I-6NeI=.8edd573c-f0b3-45a8-b421-717fdfdd74f9@github.com>

On Thu, 29 Apr 2021 09:16:04 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add m4 file
>
> test/hotspot/jtreg/compiler/vectorapi/TestVectorShuffleIotaShort.java line 44:
> 
>> 42:     static short[] as = {87, 65, 78, 71, 72, 69, 82, 69};
>> 43: 
>> 44:     public static void testShuffleS() {
> 
> IMO, this test is not enough since the assembly code is not easy to get reviewed.
> 
> So I suggest to improve your test:
>  1) Test as many match-patterns you added as possible
>  2) Verify the results in your tests
> 
> Thanks.

Thank you for your review.
1 There is only one match-pattern here .
2 I will add checking code here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3747

From whuang at openjdk.java.net  Thu Apr 29 09:58:54 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 29 Apr 2021 09:58:54 GMT
Subject: RFR: 8265956: JVM crashes when matching LShiftVB Node [v2]
In-Reply-To: <MMXOsTWaW1QtSecL_T5TB9CtgH1uXvtIasgDTwExTj0=.fbbdec5b-29b4-458f-bda6-ff60f83feab2@github.com>
References: <0lX7U-sIV4c6Wi1Cyw3caRD6ZTVCIYzbiiji3uPXf4M=.c0494113-32c5-40c4-bdd7-93b226ffe236@github.com>
 <xLNhEF-RBuHsL7HMxPn_JhdySfiJeztSQnJXUOVdsVk=.45dbda60-97dc-4173-9772-d8c7325b67ec@github.com>
 <MMXOsTWaW1QtSecL_T5TB9CtgH1uXvtIasgDTwExTj0=.fbbdec5b-29b4-458f-bda6-ff60f83feab2@github.com>
Message-ID: <OzU4yjpWduAlyyB6bx6mHG5JLOn6jiWL8BtCjLOeqNI=.e3e6c12d-d9f7-4d98-8771-a1b45d4483b3@github.com>

On Thu, 29 Apr 2021 09:16:04 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add m4 file
>
> test/hotspot/jtreg/compiler/vectorapi/TestVectorShuffleIotaShort.java line 44:
> 
>> 42:     static short[] as = {87, 65, 78, 71, 72, 69, 82, 69};
>> 43: 
>> 44:     public static void testShuffleS() {
> 
> IMO, this test is not enough since the assembly code is not easy to get reviewed.
> 
> So I suggest to improve your test:
>  1) Test as many match-patterns you added as possible
>  2) Verify the results in your tests
> 
> Thanks.

@DamonFool I will add  other vector lengths here. Thank you for your review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3747

From yyang at openjdk.java.net  Thu Apr 29 10:01:52 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 10:01:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v4]
In-Reply-To: <gYK8_Hj986HHZwEI1OhRFqEj3OpaQAIr_vCuoIFbIUU=.280ab91b-8ea7-473e-9271-7c8aeff3253e@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <ECpWrl-zwxikeEMmm9o3N20vuTp-4DymPKnEnYgMmWE=.2cb02211-dbe7-496a-bc3f-386a2fe3173b@github.com>
 <gYK8_Hj986HHZwEI1OhRFqEj3OpaQAIr_vCuoIFbIUU=.280ab91b-8ea7-473e-9271-7c8aeff3253e@github.com>
Message-ID: <ewDu_uDXvo4AcNMVI9sTYEzXHbl-dCjR2bQzg400uAc=.f55cf572-be46-42ef-8254-47f8a113d1ba@github.com>

On Thu, 29 Apr 2021 09:30:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove extra newline
>
> test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 60:
> 
>> 58:         } catch (IndexOutOfBoundsException e) {
>> 59:             // got it!
>> 60:         }
> 
> In all places where `Precondition.checkIndex` is expected to throw, an AssertionError should  be generated if it doesn't throw:
> 
> 
>         try {
>             Preconditions.checkIndex(1, 1, null);
>             throw new AssertionError("Expected IndexOutOfBoundsException not thrown");
>         } catch (IndexOutOfBoundsException e) {
>             // got it!
>         }

Yes, it does make sense

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From dfuchs at openjdk.java.net  Thu Apr 29 10:16:20 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 29 Apr 2021 10:16:20 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v5]
In-Reply-To: <mq9_O5lfLDVrZDWVzcd6jBk4jvufm6LZSh7a9pJzKfo=.20ed970f-53be-489d-8ea5-7628737cf6fb@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <mq9_O5lfLDVrZDWVzcd6jBk4jvufm6LZSh7a9pJzKfo=.20ed970f-53be-489d-8ea5-7628737cf6fb@github.com>
Message-ID: <TfUCHYj3Tzsl2zIEj1SUbvFoO7hr8ioncgvKGr5c1sg=.d259e35e-25e6-42d1-a4d8-86d008a11952@github.com>

On Thu, 29 Apr 2021 10:13:16 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AssertionError when expected exception was not thrown

test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 86:

> 84:             // read fields
> 85:             Preconditions.checkIndex(limit + 1, limit, (s, integers) -> new MyException("Reason:" + s + "::" + integers));
> 86:             throw new AssertionError("Expected IndexOutOfBoundsException not thrown");

nit: well maybe here it should be:

throw new AssertionError("Expected MyException not thrown");

test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 94:

> 92:     static void check1(int i) {
> 93:         try {
> 94:             Preconditions.checkIndex(i, 9999, (s, integers) -> new RuntimeException("ex"));

I believe 

throw new AssertionError("Expected IndexOutOfBoundsException not thrown");


should be added in `check1`...`check4` as well...

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From yyang at openjdk.java.net  Thu Apr 29 10:16:19 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 10:16:19 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v5]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <mq9_O5lfLDVrZDWVzcd6jBk4jvufm6LZSh7a9pJzKfo=.20ed970f-53be-489d-8ea5-7628737cf6fb@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  AssertionError when expected exception was not thrown

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/bbdf4b9e..1a96be7e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=03-04

  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From thartmann at openjdk.java.net  Thu Apr 29 10:20:50 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 29 Apr 2021 10:20:50 GMT
Subject: RFR: 8266267: Remove unnecessary jumps in Intel Math Library
 StubRoutines
In-Reply-To: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
References: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
Message-ID: <ecq7chREpNlhsKxMAWbhCgBHNh22zBTwdge1bR_rgPs=.4a67b834-98bb-4bac-b180-ffe47dbec9a5@github.com>

On Thu, 29 Apr 2021 03:47:41 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> May I get reviews for this small change?
> 
> If I look at the StubRoutines::libmPow carefully, an unnecessary jump instruction can be found, which is generated here [1].
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmPow [0x00007f0f8455ddd1, 0x00007f0f8455ef05] (4404 bytes)
> --------------------------------------------------------------------------------
>   0x00007f0f8455ddd1:   push   %rbp
>   0x00007f0f8455ddd2:   mov    %rsp,%rbp
>   0x00007f0f8455ddd5:   jmpq   0x00007f0f8455ddda          <--- unnecessary jump
>   0x00007f0f8455ddda:   sub    $0x28,%rsp
>   0x00007f0f8455ddde:   vmovsd %xmm0,0x8(%rsp)
>   0x00007f0f8455dde4:   vmovsd %xmm1,0x10(%rsp)
>   ...
> 
> 
> And similar issues can be found for StubRoutines::libmLog and StubRoutines::libmExp.
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmLog [0x00007f3fb94d48a6, 0x00007f3fb94d4b22] (636 bytes)
> --------------------------------------------------------------------------------
>   0x00007f3fb94d48a6:   push   %rbp
>   0x00007f3fb94d48a7:   mov    %rsp,%rbp
>   0x00007f3fb94d48aa:   jmpq   0x00007f3fb94d48af          <--- unnecessary jump
>   0x00007f3fb94d48af:   sub    $0x18,%rsp
>   0x00007f3fb94d48b3:   vmovsd %xmm0,(%rsp)
>   0x00007f3fb94d48b8:   movabs $0x3ff0000000000000,%rax
>   ...
> 
> 
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmExp [0x00007f3fb94d4579, 0x00007f3fb94d48a6] (813 bytes)
> --------------------------------------------------------------------------------
>   0x00007f3fb94d4579:   push   %rbp
>   0x00007f3fb94d457a:   mov    %rsp,%rbp
>   0x00007f3fb94d457d:   jmpq   0x00007f3fb94d4582          <--- unnecessary jump
>   0x00007f3fb94d4582:   sub    $0x18,%rsp
>   0x00007f3fb94d4586:   vmovsd %xmm0,0x8(%rsp)
>   0x00007f3fb94d458c:   vunpcklpd %xmm0,%xmm0,%xmm0
> 
> 
> I can't find a reason why we need an extra jump there.
> So I suggest removing them.
> 
> Testing:
>   - tier1 ~ tier3 on Linux/x64, no regression
> 
> Am I missing something?
> 
> Thanks.
> Best regards,
> Jie

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3784

From rraghavan at openjdk.java.net  Thu Apr 29 10:34:12 2021
From: rraghavan at openjdk.java.net (Rahul Raghavan)
Date: Thu, 29 Apr 2021 10:34:12 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class [v2]
In-Reply-To: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
Message-ID: <Wmlyu6VyPS9S4k5Eax8rqBNYutlXu8QCwDhO_sALlEw=.02b8a18f-b27d-4319-9227-fcc1fe4d4f79@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8264395
> 
> Reported assert failure, during compilation triggered by Whitebox API `enqueueInitializerForCompilation` method,
> is fixed by adding support to to bail out if a class not initialized yet.
> 
> Confirmed the new `compiler/whitebox/TestEnqueueInitializerForCompilation.java` test passes with the proposed `whitebox.cpp` changes and fails with reported assert without this fix.
> No issues with tier tests.

Rahul Raghavan has updated the pull request incrementally with one additional commit since the last revision:

  8264395: WB_EnqueueInitializerForCompilation fails with "method holder must be initialized" when called for uninitialized class

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3757/files
  - new: https://git.openjdk.java.net/jdk/pull/3757/files/5a737641..bae30303

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3757&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3757&range=00-01

  Stats: 13 lines in 1 file changed: 0 ins; 9 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3757.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3757/head:pull/3757

PR: https://git.openjdk.java.net/jdk/pull/3757

From rraghavan at openjdk.java.net  Thu Apr 29 10:34:15 2021
From: rraghavan at openjdk.java.net (Rahul Raghavan)
Date: Thu, 29 Apr 2021 10:34:15 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class [v2]
In-Reply-To: <K1Mr0JImlogw5c_cV9wlstr_jxO9mjkCC-5lS_YUtJA=.22ed7613-e8a0-4f64-9ace-90612c17752f@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
 <K1Mr0JImlogw5c_cV9wlstr_jxO9mjkCC-5lS_YUtJA=.22ed7613-e8a0-4f64-9ace-90612c17752f@github.com>
Message-ID: <M6cyHGCLXL_a5zAtR99QxNYkY-sekk5vsWyUO3DIX3k=.f53ba6e5-9cb8-4077-acc3-c16c6fca8a65@github.com>

On Wed, 28 Apr 2021 13:16:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Rahul Raghavan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8264395: WB_EnqueueInitializerForCompilation fails with "method holder must be initialized" when called for uninitialized class
>
> test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8264395
>> 27:  * @summary testing of WB::enqueueInitializerForCompilation()
> 
> Maybe change the summary to something explaining that we are testing compilation of the class initializer of a class that is not initialized yet.

Done.

> test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 28:
> 
>> 26:  * @bug 8264395
>> 27:  * @summary testing of WB::enqueueInitializerForCompilation()
>> 28:  * @library /test/lib /
> 
> `/test/lib` is not required, right?

Changed to @library /test/lib (required for sun.hotspot.WhiteBox)

> test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 31:
> 
>> 29:  * @build sun.hotspot.WhiteBox
>> 30:  * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox
>> 31:  * @run main/othervm/timeout=300 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions
> 
> Why do you need a non-default timeout?

Removed.

> test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 42:
> 
>> 40: 
>> 41:     public static void main(String[] args) {
>> 42:         WhiteBox.getWhiteBox().enqueueInitializerForCompilation(LongWrapper.class, 4);
> 
> What if compilation level 4 (= C2) is not available?

Found unavailable/bad comp levels handled in WhiteBox::compile_method() or later in CompileBroker::compile_method.

> test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 53:
> 
>> 51:         }
>> 52: 
>> 53:         static LongWrapper wrap(long val) {
> 
> `wrap` is unused. Are fields required?

Removed. Used smallest possible class.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3757

From rraghavan at openjdk.java.net  Thu Apr 29 10:38:56 2021
From: rraghavan at openjdk.java.net (Rahul Raghavan)
Date: Thu, 29 Apr 2021 10:38:56 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class [v2]
In-Reply-To: <K1Mr0JImlogw5c_cV9wlstr_jxO9mjkCC-5lS_YUtJA=.22ed7613-e8a0-4f64-9ace-90612c17752f@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
 <K1Mr0JImlogw5c_cV9wlstr_jxO9mjkCC-5lS_YUtJA=.22ed7613-e8a0-4f64-9ace-90612c17752f@github.com>
Message-ID: <Th_sZjigixsL6WHb3d-oUU114qJ7L9JyxrrKWlMJZp4=.f5f7d6a6-5c80-4153-a5a8-ce9bd3303579@github.com>

On Wed, 28 Apr 2021 13:20:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Rahul Raghavan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8264395: WB_EnqueueInitializerForCompilation fails with "method holder must be initialized" when called for uninitialized class
>
> Changes requested by thartmann (Reviewer).

Thank you @TobiHartmann for the comment suggestions. Please note now tried revising the fix for further review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3757

From thartmann at openjdk.java.net  Thu Apr 29 10:38:58 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 29 Apr 2021 10:38:58 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class [v2]
In-Reply-To: <M6cyHGCLXL_a5zAtR99QxNYkY-sekk5vsWyUO3DIX3k=.f53ba6e5-9cb8-4077-acc3-c16c6fca8a65@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
 <K1Mr0JImlogw5c_cV9wlstr_jxO9mjkCC-5lS_YUtJA=.22ed7613-e8a0-4f64-9ace-90612c17752f@github.com>
 <M6cyHGCLXL_a5zAtR99QxNYkY-sekk5vsWyUO3DIX3k=.f53ba6e5-9cb8-4077-acc3-c16c6fca8a65@github.com>
Message-ID: <L1NUB1ecGwtpPmd5672AGhNjS-PC98YyiEEXjH5s_UI=.7f47c6c4-e5b9-4a01-997f-d89bc2d4a10c@github.com>

On Thu, 29 Apr 2021 10:30:11 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/whitebox/TestEnqueueInitializerForCompilation.java line 42:
>> 
>>> 40: 
>>> 41:     public static void main(String[] args) {
>>> 42:         WhiteBox.getWhiteBox().enqueueInitializerForCompilation(LongWrapper.class, 4);
>> 
>> What if compilation level 4 (= C2) is not available?
>
> Found unavailable/bad comp levels handled in WhiteBox::compile_method() or later in CompileBroker::compile_method.

Right but wouldn't we hit an assert there if C2 is not available?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3757

From yyang at openjdk.java.net  Thu Apr 29 10:40:52 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 10:40:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v5]
In-Reply-To: <TfUCHYj3Tzsl2zIEj1SUbvFoO7hr8ioncgvKGr5c1sg=.d259e35e-25e6-42d1-a4d8-86d008a11952@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <mq9_O5lfLDVrZDWVzcd6jBk4jvufm6LZSh7a9pJzKfo=.20ed970f-53be-489d-8ea5-7628737cf6fb@github.com>
 <TfUCHYj3Tzsl2zIEj1SUbvFoO7hr8ioncgvKGr5c1sg=.d259e35e-25e6-42d1-a4d8-86d008a11952@github.com>
Message-ID: <8qnpaKEeGr3iGKtcGK8l5YjtxP_Y3cdmwbbDVvr-Y7Y=.d0a0cc48-3027-4b15-982b-88b18c4d0830@github.com>

On Thu, 29 Apr 2021 10:13:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AssertionError when expected exception was not thrown
>
> test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 94:
> 
>> 92:     static void check1(int i) {
>> 93:         try {
>> 94:             Preconditions.checkIndex(i, 9999, (s, integers) -> new RuntimeException("ex"));
> 
> I believe 
> 
> throw new AssertionError("Expected IndexOutOfBoundsException not thrown");
> 
> 
> should be added in `check1`...`check4` as well...

Hmm.. They would throw desired exceptions only if i==9999.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From neliasso at openjdk.java.net  Thu Apr 29 10:45:50 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 29 Apr 2021 10:45:50 GMT
Subject: RFR: 8266267: Remove unnecessary jumps in Intel Math Library
 StubRoutines
In-Reply-To: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
References: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
Message-ID: <32WbIq_AVZyShhfqfBFzTI0SSt9VRPmKAmxwn7JkvVE=.67952d49-01fb-4182-8aab-cf27834f693d@github.com>

On Thu, 29 Apr 2021 03:47:41 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> May I get reviews for this small change?
> 
> If I look at the StubRoutines::libmPow carefully, an unnecessary jump instruction can be found, which is generated here [1].
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmPow [0x00007f0f8455ddd1, 0x00007f0f8455ef05] (4404 bytes)
> --------------------------------------------------------------------------------
>   0x00007f0f8455ddd1:   push   %rbp
>   0x00007f0f8455ddd2:   mov    %rsp,%rbp
>   0x00007f0f8455ddd5:   jmpq   0x00007f0f8455ddda          <--- unnecessary jump
>   0x00007f0f8455ddda:   sub    $0x28,%rsp
>   0x00007f0f8455ddde:   vmovsd %xmm0,0x8(%rsp)
>   0x00007f0f8455dde4:   vmovsd %xmm1,0x10(%rsp)
>   ...
> 
> 
> And similar issues can be found for StubRoutines::libmLog and StubRoutines::libmExp.
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmLog [0x00007f3fb94d48a6, 0x00007f3fb94d4b22] (636 bytes)
> --------------------------------------------------------------------------------
>   0x00007f3fb94d48a6:   push   %rbp
>   0x00007f3fb94d48a7:   mov    %rsp,%rbp
>   0x00007f3fb94d48aa:   jmpq   0x00007f3fb94d48af          <--- unnecessary jump
>   0x00007f3fb94d48af:   sub    $0x18,%rsp
>   0x00007f3fb94d48b3:   vmovsd %xmm0,(%rsp)
>   0x00007f3fb94d48b8:   movabs $0x3ff0000000000000,%rax
>   ...
> 
> 
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmExp [0x00007f3fb94d4579, 0x00007f3fb94d48a6] (813 bytes)
> --------------------------------------------------------------------------------
>   0x00007f3fb94d4579:   push   %rbp
>   0x00007f3fb94d457a:   mov    %rsp,%rbp
>   0x00007f3fb94d457d:   jmpq   0x00007f3fb94d4582          <--- unnecessary jump
>   0x00007f3fb94d4582:   sub    $0x18,%rsp
>   0x00007f3fb94d4586:   vmovsd %xmm0,0x8(%rsp)
>   0x00007f3fb94d458c:   vunpcklpd %xmm0,%xmm0,%xmm0
> 
> 
> I can't find a reason why we need an extra jump there.
> So I suggest removing them.
> 
> Testing:
>   - tier1 ~ tier3 on Linux/x64, no regression
> 
> Am I missing something?
> 
> Thanks.
> Best regards,
> Jie

Looks good.

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3784

From jcm at openjdk.java.net  Thu Apr 29 10:57:10 2021
From: jcm at openjdk.java.net (Jamsheed Mohammed C M)
Date: Thu, 29 Apr 2021 10:57:10 GMT
Subject: RFR: 8266288: assert root method not found in
 witnessed_reabstraction_in_supers is too strong
Message-ID: <h_nVzWQJE29HUZka1YJLbDXhl46NoBdhj7fIv_z4amM=.b9408393-a866-499f-90ed-a562f96d1a0e@github.com>

removing the assert as it is strong for miranda root_m.

-------------

Commit messages:
 - assert root method not found in witnessed_reabstraction_in_supers is too strong
 - Merge pull request #5 from openjdk/master
 - Merge branch 'master' of https://github.com/jamsheedcm/jdk
 - Merge pull request #4 from openjdk/master
 - Merge branch 'master' of https://github.com/jamsheedcm/jdk
 - Merge pull request #3 from openjdk/master
 - Merge branch 'master' of https://github.com/jamsheedcm/jdk
 - Merge pull request #2 from openjdk/master
 - Merge branch 'master' of https://github.com/jamsheedcm/jdk
 - Merge pull request #1 from openjdk/master

Changes: https://git.openjdk.java.net/jdk/pull/3793/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3793&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266288
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3793.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3793/head:pull/3793

PR: https://git.openjdk.java.net/jdk/pull/3793

From vlivanov at openjdk.java.net  Thu Apr 29 11:07:51 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 29 Apr 2021 11:07:51 GMT
Subject: RFR: 8266288: assert root method not found in
 witnessed_reabstraction_in_supers is too strong
In-Reply-To: <h_nVzWQJE29HUZka1YJLbDXhl46NoBdhj7fIv_z4amM=.b9408393-a866-499f-90ed-a562f96d1a0e@github.com>
References: <h_nVzWQJE29HUZka1YJLbDXhl46NoBdhj7fIv_z4amM=.b9408393-a866-499f-90ed-a562f96d1a0e@github.com>
Message-ID: <HVA6ZRlROs4IMFg0-aFD3PZJ0XtWv3pFff2tKmClDJQ=.7502d00e-d351-42ee-a0d7-0d4b18114f7f@github.com>

On Thu, 29 Apr 2021 10:50:03 GMT, Jamsheed Mohammed C M <jcm at openjdk.org> wrote:

> removing the assert as it is strong for miranda root_m.

Marked as reviewed by vlivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3793

From jiefu at openjdk.java.net  Thu Apr 29 11:11:56 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 29 Apr 2021 11:11:56 GMT
Subject: RFR: 8266267: Remove unnecessary jumps in Intel Math Library
 StubRoutines
In-Reply-To: <ecq7chREpNlhsKxMAWbhCgBHNh22zBTwdge1bR_rgPs=.4a67b834-98bb-4bac-b180-ffe47dbec9a5@github.com>
References: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
 <ecq7chREpNlhsKxMAWbhCgBHNh22zBTwdge1bR_rgPs=.4a67b834-98bb-4bac-b180-ffe47dbec9a5@github.com>
Message-ID: <Nl3X1WRxp7ul3N_35xuzAZCQPMCyusZ42411JL6e0z4=.a505519f-7efe-4fe9-b64a-331cc2b8c5b5@github.com>

On Thu, 29 Apr 2021 10:17:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Hi all,
>> 
>> May I get reviews for this small change?
>> 
>> If I look at the StubRoutines::libmPow carefully, an unnecessary jump instruction can be found, which is generated here [1].
>> 
>> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> StubRoutines::libmPow [0x00007f0f8455ddd1, 0x00007f0f8455ef05] (4404 bytes)
>> --------------------------------------------------------------------------------
>>   0x00007f0f8455ddd1:   push   %rbp
>>   0x00007f0f8455ddd2:   mov    %rsp,%rbp
>>   0x00007f0f8455ddd5:   jmpq   0x00007f0f8455ddda          <--- unnecessary jump
>>   0x00007f0f8455ddda:   sub    $0x28,%rsp
>>   0x00007f0f8455ddde:   vmovsd %xmm0,0x8(%rsp)
>>   0x00007f0f8455dde4:   vmovsd %xmm1,0x10(%rsp)
>>   ...
>> 
>> 
>> And similar issues can be found for StubRoutines::libmLog and StubRoutines::libmExp.
>> 
>> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> StubRoutines::libmLog [0x00007f3fb94d48a6, 0x00007f3fb94d4b22] (636 bytes)
>> --------------------------------------------------------------------------------
>>   0x00007f3fb94d48a6:   push   %rbp
>>   0x00007f3fb94d48a7:   mov    %rsp,%rbp
>>   0x00007f3fb94d48aa:   jmpq   0x00007f3fb94d48af          <--- unnecessary jump
>>   0x00007f3fb94d48af:   sub    $0x18,%rsp
>>   0x00007f3fb94d48b3:   vmovsd %xmm0,(%rsp)
>>   0x00007f3fb94d48b8:   movabs $0x3ff0000000000000,%rax
>>   ...
>> 
>> 
>> 
>> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> StubRoutines::libmExp [0x00007f3fb94d4579, 0x00007f3fb94d48a6] (813 bytes)
>> --------------------------------------------------------------------------------
>>   0x00007f3fb94d4579:   push   %rbp
>>   0x00007f3fb94d457a:   mov    %rsp,%rbp
>>   0x00007f3fb94d457d:   jmpq   0x00007f3fb94d4582          <--- unnecessary jump
>>   0x00007f3fb94d4582:   sub    $0x18,%rsp
>>   0x00007f3fb94d4586:   vmovsd %xmm0,0x8(%rsp)
>>   0x00007f3fb94d458c:   vunpcklpd %xmm0,%xmm0,%xmm0
>> 
>> 
>> I can't find a reason why we need an extra jump there.
>> So I suggest removing them.
>> 
>> Testing:
>>   - tier1 ~ tier3 on Linux/x64, no regression
>> 
>> Am I missing something?
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Looks good to me.

Thanks @TobiHartmann and @neliasso .

-------------

PR: https://git.openjdk.java.net/jdk/pull/3784

From yyang at openjdk.java.net  Thu Apr 29 11:48:56 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 29 Apr 2021 11:48:56 GMT
Subject: RFR: 8265322: C2: Simplify control inputs for
 BarrierSetC2::obj_allocate
In-Reply-To: <cj-4QRaigsBPew_jBiuDMO4E9TdXXL1TUH9KZg5Oi-g=.1cb90d4f-6a1b-48aa-b731-4cab4a2681df@github.com>
References: <_NicB3VpqFwTiu2-bKLNhfnQAxJmbtND66g3Md5ck5g=.f9b4edcd-fa2b-4917-9092-bccc38b202df@github.com>
 <cj-4QRaigsBPew_jBiuDMO4E9TdXXL1TUH9KZg5Oi-g=.1cb90d4f-6a1b-48aa-b731-4cab4a2681df@github.com>
Message-ID: <SNXXXqrLw0a8ULE9U6V5mgyNJWbngM7W6Y__myHyGLQ=.7c80f9ff-da8d-42b7-89c5-92052e70bea9@github.com>

On Mon, 19 Apr 2021 17:26:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> While just using BarrierSetC2::obj_allocate in https://github.com/openjdk/valhalla/pull/385, I noticed the control input `ctrl` for obj_allocate is not so much necessary. This PR simplifies control inputs for BarrierSetC2::obj_allocate. In most cases, it doesn't change anything since `toobig_false` is equivalent to `ctrl`. In other cases, `toobig_false` is created for Unsafe.allocateInstance while instance size is not statically known, `ctrl` would become control input of IfNode whose projects are `toobig_false` and `toobig_true`, old eden_end and old_eden_top can simply accept `toobig_false` as their control input rather than `ctrl`.
>
>> > From compiler code POV the fix is reasonable and correct.
>> Do you think it's reasonable to move PhaseMacroExpand::set_eden_pointers to BarrierSetC2? It seems that that's GC knowledge area about how to set eden_top/eden_end w or w/o turning UseTLAB.
> 
> It is up to GC group but it is common code for all GCs. As I understand BarrierSetC2 is used for GC variations code.

Thanks @vnkozlov and @neliasso for reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3529

From vlivanov at openjdk.java.net  Thu Apr 29 12:01:14 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 29 Apr 2021 12:01:14 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
Message-ID: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>

As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.

It served quite well for many years, but it accumulated significant complexity
to support different corner cases over time and inevitable evolution of the JVM
stretched the whole approach way too much (to the point where it become almost
impossible to extend the analysis any further).

It turns out the root problem is the decision to reimplement method resolution
and method selection logic from scratch and to perform it on JVM internal
representation. It makes it very hard to reason about correctness and the
implementation becomes sensitive to changes in internal representation.

So, the main motivation for the redesign is twofold: 
 * reduce maintenance burden and increase confidence in the code;
 * unlock some long-awaited enhancements.

Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
any possible enhancements are deliberately kept out of scope for the current PR.
(It does deliver a bit of minor enhancements front as the changes in
compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
of the other changes and was not the goal of the current work.)

Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
and relies on vtable/itable information to detect target method for every
subclass it visits. It removes all the complexity associated with method
resolution and method selection logic and leaves only essential logic to prepare for method selection.

Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
Instead of supporting not yet linked case, it is simply ignored. It is safe to
skip them (treat as "effectively non-concrete") since it is guaranteed there
are no instances created yet. But it requires VM to check dependencies once a
class is linked.

I ended up with 2 separate dependency validation passes (when class is loaded
and when it is linked). To avoid duplicated work, only dependencies
which may be affected by class initialization state change
(`unique_concrete_method_4`) are visited. 

(I experimented with merging passes into a single pass (delay the pass until
linkage is over), but it severely affected other class-related dependencies and
relevant optimizations.code.)

Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.

Old implementation is kept intact for now (will be removed later) to:
  - JVMCI hasn't been migrated to the new implementation yet;
  - enable verification that 2 implementations (old and new) agree on the results;
  - temporarily keep an option to revert to the original implementation in case any regressions show up.

Testing:
- [x] hs-tier1 - hs-tier9
- [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
- [x] performance testing
  
Thanks!

-------------

Commit messages:
 - Introduce NewKlassDepChange and KlassInitDepChange
 - LinkedConcreteMethodFinder
 - Dependencies::assert_unique_concrete_method
 - 4-arg dependency support: Dependencies::assert_common_4 et al

Changes: https://git.openjdk.java.net/jdk/pull/3727/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3727&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266074
  Stats: 542 lines in 11 files changed: 468 ins; 6 del; 68 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3727/head:pull/3727

PR: https://git.openjdk.java.net/jdk/pull/3727

From thartmann at openjdk.java.net  Thu Apr 29 12:36:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 29 Apr 2021 12:36:51 GMT
Subject: RFR: 8266288: assert root method not found in
 witnessed_reabstraction_in_supers is too strong
In-Reply-To: <h_nVzWQJE29HUZka1YJLbDXhl46NoBdhj7fIv_z4amM=.b9408393-a866-499f-90ed-a562f96d1a0e@github.com>
References: <h_nVzWQJE29HUZka1YJLbDXhl46NoBdhj7fIv_z4amM=.b9408393-a866-499f-90ed-a562f96d1a0e@github.com>
Message-ID: <BngEceOO0pW5fZxJfQNMqu6Au9aKHKbxWPG0VGt6QWc=.ea74dc37-e2e2-4138-8e66-c114783bb0c1@github.com>

On Thu, 29 Apr 2021 10:50:03 GMT, Jamsheed Mohammed C M <jcm at openjdk.org> wrote:

> removing the assert as it is strong for miranda root_m.

Marked as reviewed by thartmann (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3793

From aph at openjdk.java.net  Thu Apr 29 15:08:54 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 29 Apr 2021 15:08:54 GMT
Subject: RFR: 8265244: Remove useless comparation in
 LibraryCallKit::inline_vector_convert() [v2]
In-Reply-To: <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
Message-ID: <l1m6pe5teNPUYc94D6Dg-VMQMk6cwxhsuleVdpbdHCY=.50f973c7-35bb-4ebc-afcc-fb28ed194894@github.com>

On Fri, 16 Apr 2021 02:10:10 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * aarch64 can only accept `VectorReinterpret` with 64/128 bits.
>> * I will fix this bug by adding a rule for `VectorReinterpret` in `match_rule_supported_vector`
>> * after changing note with @nsjian and @XiaohongGong , I think that two checks in `inline_vector_conver` is useless now. However, these checks impact other cpus, so I need more reviewers.
>
> Wang Huang 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 JDK-8265244
>  - 8265244: assert(false) failed: bad AD file

Please change the title of this to

8265244: AArch64: Remove useless comparation in LibraryCallKit::inline_vector_convert()

since it affects the AArch64 port. This makes the logs and the mailing lists much easier to read.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3507

From jcm at openjdk.java.net  Thu Apr 29 16:19:51 2021
From: jcm at openjdk.java.net (Jamsheed Mohammed C M)
Date: Thu, 29 Apr 2021 16:19:51 GMT
Subject: Integrated: 8266288: assert root method not found in
 witnessed_reabstraction_in_supers is too strong
In-Reply-To: <h_nVzWQJE29HUZka1YJLbDXhl46NoBdhj7fIv_z4amM=.b9408393-a866-499f-90ed-a562f96d1a0e@github.com>
References: <h_nVzWQJE29HUZka1YJLbDXhl46NoBdhj7fIv_z4amM=.b9408393-a866-499f-90ed-a562f96d1a0e@github.com>
Message-ID: <m4yk-345mqHJxvYCqB4LYDIYKLTO1OzXuHmBHUQ6zGs=.dc02d229-69ff-41df-a215-5df336d854ef@github.com>

On Thu, 29 Apr 2021 10:50:03 GMT, Jamsheed Mohammed C M <jcm at openjdk.org> wrote:

> removing the assert as it is strong for miranda root_m.

This pull request has now been integrated.

Changeset: 49d04586
Author:    Jamsheed Mohammed C M <jcm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/49d04586ed27fc905083d60aa68793d84824c7f3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8266288: assert root method not found in witnessed_reabstraction_in_supers is too strong

Reviewed-by: vlivanov, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3793

From jcm at openjdk.java.net  Thu Apr 29 16:19:51 2021
From: jcm at openjdk.java.net (Jamsheed Mohammed C M)
Date: Thu, 29 Apr 2021 16:19:51 GMT
Subject: RFR: 8266288: assert root method not found in
 witnessed_reabstraction_in_supers is too strong
In-Reply-To: <h_nVzWQJE29HUZka1YJLbDXhl46NoBdhj7fIv_z4amM=.b9408393-a866-499f-90ed-a562f96d1a0e@github.com>
References: <h_nVzWQJE29HUZka1YJLbDXhl46NoBdhj7fIv_z4amM=.b9408393-a866-499f-90ed-a562f96d1a0e@github.com>
Message-ID: <7PQkyn3lFHGcw9vmLF9wooqcCkVyVxT6-jvIrxaHoqE=.2b90f137-b4c3-4f66-b165-9416b3947ed5@github.com>

On Thu, 29 Apr 2021 10:50:03 GMT, Jamsheed Mohammed C M <jcm at openjdk.org> wrote:

> removing the assert as it is strong for miranda root_m.

Thank you for the reviews, Vladimir, Tobias.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3793

From kvn at openjdk.java.net  Thu Apr 29 16:28:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 29 Apr 2021 16:28:51 GMT
Subject: RFR: 8266267: Remove unnecessary jumps in Intel Math Library
 StubRoutines
In-Reply-To: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
References: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
Message-ID: <OUlI4RF0Cb7GZudTeGzrjvLwtB0jq2NXfUsfq1jBMAo=.a59d812c-0bbc-41df-bd0a-301ec359ea5c@github.com>

On Thu, 29 Apr 2021 03:47:41 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> May I get reviews for this small change?
> 
> If I look at the StubRoutines::libmPow carefully, an unnecessary jump instruction can be found, which is generated here [1].
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmPow [0x00007f0f8455ddd1, 0x00007f0f8455ef05] (4404 bytes)
> --------------------------------------------------------------------------------
>   0x00007f0f8455ddd1:   push   %rbp
>   0x00007f0f8455ddd2:   mov    %rsp,%rbp
>   0x00007f0f8455ddd5:   jmpq   0x00007f0f8455ddda          <--- unnecessary jump
>   0x00007f0f8455ddda:   sub    $0x28,%rsp
>   0x00007f0f8455ddde:   vmovsd %xmm0,0x8(%rsp)
>   0x00007f0f8455dde4:   vmovsd %xmm1,0x10(%rsp)
>   ...
> 
> 
> And similar issues can be found for StubRoutines::libmLog and StubRoutines::libmExp.
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmLog [0x00007f3fb94d48a6, 0x00007f3fb94d4b22] (636 bytes)
> --------------------------------------------------------------------------------
>   0x00007f3fb94d48a6:   push   %rbp
>   0x00007f3fb94d48a7:   mov    %rsp,%rbp
>   0x00007f3fb94d48aa:   jmpq   0x00007f3fb94d48af          <--- unnecessary jump
>   0x00007f3fb94d48af:   sub    $0x18,%rsp
>   0x00007f3fb94d48b3:   vmovsd %xmm0,(%rsp)
>   0x00007f3fb94d48b8:   movabs $0x3ff0000000000000,%rax
>   ...
> 
> 
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmExp [0x00007f3fb94d4579, 0x00007f3fb94d48a6] (813 bytes)
> --------------------------------------------------------------------------------
>   0x00007f3fb94d4579:   push   %rbp
>   0x00007f3fb94d457a:   mov    %rsp,%rbp
>   0x00007f3fb94d457d:   jmpq   0x00007f3fb94d4582          <--- unnecessary jump
>   0x00007f3fb94d4582:   sub    $0x18,%rsp
>   0x00007f3fb94d4586:   vmovsd %xmm0,0x8(%rsp)
>   0x00007f3fb94d458c:   vunpcklpd %xmm0,%xmm0,%xmm0
> 
> 
> I can't find a reason why we need an extra jump there.
> So I suggest removing them.
> 
> Testing:
>   - tier1 ~ tier3 on Linux/x64, no regression
> 
> Am I missing something?
> 
> Thanks.
> Best regards,
> Jie

How you found them?

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3784

From sviswanathan at openjdk.java.net  Thu Apr 29 17:18:54 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 29 Apr 2021 17:18:54 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v12]
In-Reply-To: <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>
Message-ID: <J5Jvl4p-qq3J6PZIHJhk0WBsLS03zklaXgWw0qzDxVs=.07250e70-969d-481e-bfdc-baa8664d715f@github.com>

On Wed, 28 Apr 2021 19:26:21 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:
> 
>   jatin-bhateja review
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

@vnkozlov @neliasso Could you please help review this small patch from Marcus.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From neliasso at openjdk.java.net  Thu Apr 29 18:23:53 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 29 Apr 2021 18:23:53 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v12]
In-Reply-To: <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>
Message-ID: <_VXARuqmXZCTBAD-R0vOMp0_Q2kTi5cLEtbtWqqar_U=.41a4ad63-1316-478c-b03a-286595c6d837@github.com>

On Wed, 28 Apr 2021 19:26:21 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM.
>> 
>> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization.
>> 
>> Base:
>> 
>> Benchmark                       Mode Cnt Score Error Units
>> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op
>> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op
>> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op
>> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op
>> 
>>  
>> Optimized:
>> signum intrinsic patch
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> Signum._1_signumFloatTest       avgt    5  3.769 ? 0.015  ns/op
>> Signum._2_overheadFloat         avgt    5  3.312 ? 0.025  ns/op
>> Signum._3_signumDoubleTest      avgt    5  3.765 ? 0.005  ns/op
>> Signum._4_overheadDouble        avgt    5  3.309 ? 0.010  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:
> 
>   jatin-bhateja review
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Looks good!

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3581

From sviswanathan at openjdk.java.net  Thu Apr 29 18:30:00 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 29 Apr 2021 18:30:00 GMT
Subject: RFR: 8265491: Math Signum optimization for x86 [v12]
In-Reply-To: <_VXARuqmXZCTBAD-R0vOMp0_Q2kTi5cLEtbtWqqar_U=.41a4ad63-1316-478c-b03a-286595c6d837@github.com>
References: <mo42m_u7_rjFUw--k8GBRRJx4GxuU7HaRwlmaV0dSPU=.96453706-c7ce-41e6-9e39-c9df8d6ead49@github.com>
 <fb9FJLUbhSaBlSjmMMbtfqjNGm8-slho4TBppXAwzKg=.4f655761-3911-4761-9915-e71f986759fe@github.com>
 <_VXARuqmXZCTBAD-R0vOMp0_Q2kTi5cLEtbtWqqar_U=.41a4ad63-1316-478c-b03a-286595c6d837@github.com>
Message-ID: <Ngw4d3YVoIMhOLSzVzy_Id2_GshMrcaSxxd4NeXEa1A=.9a947562-9316-4ab5-a3dc-1331571031f1@github.com>

On Thu, 29 Apr 2021 18:21:12 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   jatin-bhateja review
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Looks good!

@neliasso Thanks a lot for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3581

From enikitin at openjdk.java.net  Thu Apr 29 20:27:52 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Thu, 29 Apr 2021 20:27:52 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion. [v2]
In-Reply-To: <Oy98q09lN7STsjWC0gshI1dZiG0Lm_XqMPEtf-xDj44=.53ae47e9-9139-4e53-a5ad-89873083eedb@github.com>
References: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
 <6Cyzy_C3CHFVumBzXWdzuPyfJNkAo8Xfd6DfqCQyG4g=.770d16f6-da35-4bdc-9098-47a6f93a116e@github.com>
 <Oy98q09lN7STsjWC0gshI1dZiG0Lm_XqMPEtf-xDj44=.53ae47e9-9139-4e53-a5ad-89873083eedb@github.com>
Message-ID: <8jUiSKQkB-ZeWnjTBGInSUjYY3IAClBZ6iSB1qcIyW0=.d4e63540-d7a5-4637-b4b5-62dcb0508a7d@github.com>

On Wed, 28 Apr 2021 20:50:15 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> I don't like that we kinda guessing here, but on the other hand, I don't think we have much of the choice.
> 
> could you please add the comment which roughly explains why it's 10kk and 5kk? so the next person who reads/modifies this piece of code will have an idea of how/why we get the current numbers.

I've added an explanation and extracted the code cache monitoring in a sub-class (because it had lots of members and explanations dedicated only to this functionality).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3762

From github.com+2249648+johntortugo at openjdk.java.net  Thu Apr 29 20:37:12 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 29 Apr 2021 20:37:12 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v9]
In-Reply-To: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
Message-ID: <YtnKURoLWf0E_D--86VXzQ8_L3aRVamShXGLCyfLscU=.70b73430-3879-4cdc-90d8-0a99b7b1d735@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:

  Encode cdql/cdqq using MacroAssembler.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2420/files
  - new: https://git.openjdk.java.net/jdk/pull/2420/files/4b0912ce..92a242b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2420&range=07-08

  Stats: 73 lines in 1 file changed: 11 ins; 41 del; 21 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 Apr 29 20:41:59 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 29 Apr 2021 20:41:59 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v8]
In-Reply-To: <AFQ7u2FdiJg1cE0k1VHPlLJVOSgDf3KiSFKdhPXHqVI=.b4ad8621-a12d-4775-9fac-59981bfd327b@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <f5ZnAIf7-onkXq2Vw4oEmwbdaAaXUxLZTqrBV4G7nMI=.287d5c62-2eee-4b5e-bfa6-16809ae3f4cf@github.com>
 <AFQ7u2FdiJg1cE0k1VHPlLJVOSgDf3KiSFKdhPXHqVI=.b4ad8621-a12d-4775-9fac-59981bfd327b@github.com>
Message-ID: <XIja2YaEwaS3QeepX5vWVkvevZ0P0nYq6HfYU-t1Of0=.963158bb-b315-4d89-8c03-ac611a99b3a7@github.com>

On Thu, 22 Apr 2021 23:50:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix cast of constant
>
> I got a lot of failures on Windows only. Almost all test/hotspot/jtreg/serviceability/sa/ tests failed and others.
> Examples:
> 
> serviceability/sa/TestSysProps.java
> 
> #  Internal Error (t:\\workspace\\open\\src\\hotspot\\share\\runtime\\stackValue.cpp:139), pid=7572, tid=26052
> #  assert(oopDesc::is_oop_or_null(val, false)) failed: bad oop found
> 
> compiler/c2/Test6800154.java
> java.lang.InternalError: 9223372036854775807 / -9223372036854775808 failed: 65547 != 0
> 	at compiler.c2.Test6800154.run(Test6800154.java:111)
> 	at compiler.c2.Test6800154.main(Test6800154.java:97)

@vnkozlov - thank you so much for running the tests! The cause of the problems you reported were the last changes I made to the div/mod instructions. I fixed the code and ran all tests again on Linux, macOS, and Windows and they are looking good (jdk tier1, 2, 3, and hotspot_all.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From sviswanathan at openjdk.java.net  Thu Apr 29 21:39:11 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 29 Apr 2021 21:39:11 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice operations
Message-ID: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>

All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).

Changes include:
 * Rewrite Vector API slice/unslice using already intrinsic methods
 * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
 * Vector API conversion tests thresholds adjustment
 
Base Performance:
Benchmark (size) Mode Cnt Score Error Units
TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms

Performance with patch:
Benchmark (size) Mode Cnt Score Error Units
TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

-------------

Commit messages:
 - 8265128: [REDO] Optimize Vector API slice and unslice operations

Changes: https://git.openjdk.java.net/jdk/pull/3804/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265128
  Stats: 886 lines in 44 files changed: 175 ins; 518 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3804.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3804/head:pull/3804

PR: https://git.openjdk.java.net/jdk/pull/3804

From vlivanov at openjdk.java.net  Thu Apr 29 21:57:20 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 29 Apr 2021 21:57:20 GMT
Subject: RFR: 8266328: C2: Remove InlineWarmCalls
Message-ID: <hWRsELCx7_oNek3k00sxUIVN2afL0xKEBZU3TQWc2us=.f3b441f7-261f-4f6a-896f-2ae908cdbbf2@github.com>

Remove InlineWarmCalls and all relevant code.

It was introduced long time ago and didn't get much attention since then. I don't see any value in keeping it around.
And there's incremental inlining support in C2 now.

Testing:
- [x] hs-tier1 - hs-tier2

-------------

Commit messages:
 - Formatting
 - Merge branch 'master' into inline_warm_call.removal
 - Remove WarmCallInfo

Changes: https://git.openjdk.java.net/jdk/pull/3805/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3805&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266328
  Stats: 588 lines in 8 files changed: 6 ins; 560 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3805.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3805/head:pull/3805

PR: https://git.openjdk.java.net/jdk/pull/3805

From psandoz at openjdk.java.net  Thu Apr 29 23:12:51 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 29 Apr 2021 23:12:51 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations
In-Reply-To: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
Message-ID: <EV_vCwC-iVsJ_MUPJfX-tUglh7lrGO3S9DPjC9PNdrU=.7dba7cfc-4e93-446d-a7d9-72e8bcddda1d@github.com>

On Thu, 29 Apr 2021 21:29:03 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2283:

> 2281:     @ForceInline
> 2282:     $abstractvectortype$ sliceTemplate(int origin) {
> 2283:         Objects.checkIndex(origin, length());

For `Objects.checkIndex` the upper bound is exclusive, where as i think in this case it needs to be inclusive.

The original bound check was:

       if ((origin < 0) || (origin >= VLENGTH)) {
         throw new ArrayIndexOutOfBoundsException("Index " + origin + " out of bounds for vector length " + VLENGTH);
       }
...

in accordance with the spec in the JavaDoc.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2284:

> 2282:     $abstractvectortype$ sliceTemplate(int origin) {
> 2283:         Objects.checkIndex(origin, length());
> 2284:         VectorShuffle<$Boxtype$> Iota = iotaShuffle();

Suggestion:

        VectorShuffle<$Boxtype$> iota = iotaShuffle();

use lower case first letter for variable names.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2287:

> 2285:         VectorMask<$Boxtype$> BlendMask = Iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));
> 2286:         Iota = iotaShuffle(origin, 1, true);
> 2287:         return vspecies().zero().blend(this.rearrange(Iota), BlendMask);

Observation: this is like `this.rearrange(iota, blendMask)` but we avoid the checking for exceptional shuffle indexes, since we know there are no such exceptional indexes.

And, of course,this method is like `slice(origin vspecies().zero())`. I wonder if this template should defer to the vector accepting tempting? Or the method on vector itself?

test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java line 51:

> 49:     }
> 50: 
> 51:     static final int INVOC_COUNT = Integer.getInteger("jdk.incubator.vector.test.loop-iterations", 100);

Why did you change this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From jiefu at openjdk.java.net  Thu Apr 29 23:21:55 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 29 Apr 2021 23:21:55 GMT
Subject: RFR: 8266267: Remove unnecessary jumps in Intel Math Library
 StubRoutines
In-Reply-To: <OUlI4RF0Cb7GZudTeGzrjvLwtB0jq2NXfUsfq1jBMAo=.a59d812c-0bbc-41df-bd0a-301ec359ea5c@github.com>
References: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
 <OUlI4RF0Cb7GZudTeGzrjvLwtB0jq2NXfUsfq1jBMAo=.a59d812c-0bbc-41df-bd0a-301ec359ea5c@github.com>
Message-ID: <sKAjgWR9eI8Nz37YpK9Tqnmk80nGRNwNnHeIYOJLqwE=.f5fa4c28-faea-4ed4-b4c6-37371fb09aec@github.com>

On Thu, 29 Apr 2021 16:25:35 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> How you found them?

To make sure the x64's stub code works for x=-0.0 while doing https://github.com/openjdk/jdk/pull/3712 , I took a look at the generated code.
Then I found the unnecessary jump at the beginning of dpow's stub.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3784

From sviswanathan at openjdk.java.net  Thu Apr 29 23:39:00 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 29 Apr 2021 23:39:00 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations
In-Reply-To: <EV_vCwC-iVsJ_MUPJfX-tUglh7lrGO3S9DPjC9PNdrU=.7dba7cfc-4e93-446d-a7d9-72e8bcddda1d@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <EV_vCwC-iVsJ_MUPJfX-tUglh7lrGO3S9DPjC9PNdrU=.7dba7cfc-4e93-446d-a7d9-72e8bcddda1d@github.com>
Message-ID: <gwPwtC3waBKmpr9y-Yh5GlMMKohxeU1Kb_8B98c9qnA=.60fedc2f-b968-4834-a4b5-6a2251a401a7@github.com>

On Thu, 29 Apr 2021 22:59:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2283:
> 
>> 2281:     @ForceInline
>> 2282:     $abstractvectortype$ sliceTemplate(int origin) {
>> 2283:         Objects.checkIndex(origin, length());
> 
> For `Objects.checkIndex` the upper bound is exclusive, where as i think in this case it needs to be inclusive.
> 
> The original bound check was:
> 
>        if ((origin < 0) || (origin >= VLENGTH)) {
>          throw new ArrayIndexOutOfBoundsException("Index " + origin + " out of bounds for vector length " + VLENGTH);
>        }
> ...
> 
> in accordance with the spec in the JavaDoc.

Thanks for pointing this out. I will update this to Objects.checkIndex(origin, length()+1);

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2284:
> 
>> 2282:     $abstractvectortype$ sliceTemplate(int origin) {
>> 2283:         Objects.checkIndex(origin, length());
>> 2284:         VectorShuffle<$Boxtype$> Iota = iotaShuffle();
> 
> Suggestion:
> 
>         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 
> use lower case first letter for variable names.

I will make this change.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2287:
> 
>> 2285:         VectorMask<$Boxtype$> BlendMask = Iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));
>> 2286:         Iota = iotaShuffle(origin, 1, true);
>> 2287:         return vspecies().zero().blend(this.rearrange(Iota), BlendMask);
> 
> Observation: this is like `this.rearrange(iota, blendMask)` but we avoid the checking for exceptional shuffle indexes, since we know there are no such exceptional indexes.
> 
> And, of course,this method is like `slice(origin vspecies().zero())`. I wonder if this template should defer to the vector accepting tempting? Or the method on vector itself?

Trying to optimize as much as possible:
  There is overhead in checking for exception shuffle indices. 
  The slice(origin, vector) version has one extra rearrange call.

> test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java line 51:
> 
>> 49:     }
>> 50: 
>> 51:     static final int INVOC_COUNT = Integer.getInteger("jdk.incubator.vector.test.loop-iterations", 100);
> 
> Why did you change this?

Following reasons:
The INVOC_COUNT is set as 100 for all other tests.
The conversion tests take longer time to complete than other tests.
For the conversion tests it looks like the intrinsics don't trigger sometimes and tests take longer to execute and timeout. This was one of the reasons for backout last time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Fri Apr 30 00:17:24 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 00:17:24 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v2]
In-Reply-To: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
Message-ID: <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments implementation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3804/files
  - new: https://git.openjdk.java.net/jdk/pull/3804/files/54dd9206..59275ff6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=00-01

  Stats: 140 lines in 7 files changed: 0 ins; 0 del; 140 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3804.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3804/head:pull/3804

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Fri Apr 30 00:17:24 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 00:17:24 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations
In-Reply-To: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
Message-ID: <2opc6tTQSrlcWwUz_hpbX80AVyujsk_SPBDtXaCcMDo=.5f9cd5c2-ebe3-4a99-b384-e174b979ae7b@github.com>

On Thu, 29 Apr 2021 21:29:03 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

@PaulSandoz I have implemented your review comments. Please take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From psandoz at openjdk.java.net  Fri Apr 30 00:26:57 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 00:26:57 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v2]
In-Reply-To: <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>
Message-ID: <ujfoAas6-HvMY_RChzMRRJn5BVgvkt--LDLD5j4M5qs=.e019f2cb-4cf8-4fe3-9b0b-e5fd07bf582a@github.com>

On Fri, 30 Apr 2021 00:17:24 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments implementation

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2255:

> 2253:         Objects.checkIndex(origin, length() + 1);
> 2254:         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 2255:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));

Suggestion:

        VectorMask<$Boxtype$> blendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2257:

> 2255:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));
> 2256:         iota = iotaShuffle(origin, 1, true);
> 2257:         return (($abstractvectortype$)v1).rearrange(iota).blend(this.rearrange(iota), BlendMask);

Suggestion:

        return that.rearrange(iota).blend(this.rearrange(iota), blendMask);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2285:

> 2283:         Objects.checkIndex(origin, length() + 1);
> 2284:         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 2285:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));

Suggestion:

        VectorMask<$Boxtype$> blendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2287:

> 2285:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.LT, (broadcast(($type$)(length() - origin))));
> 2286:         iota = iotaShuffle(origin, 1, true);
> 2287:         return vspecies().zero().blend(this.rearrange(iota), BlendMask);

Suggestion:

        return vspecies().zero().blend(this.rearrange(iota), blendMask);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2306:

> 2304:         Objects.checkIndex(origin, length() + 1);
> 2305:         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 2306:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare((part == 0) ? VectorOperators.GE : VectorOperators.LT,

Suggestion:

        VectorMask<$Boxtype$> blendMask = iota.toVector().compare((part == 0) ? VectorOperators.GE : VectorOperators.LT,

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2309:

> 2307:                                                                   (broadcast(($type$)(origin))));
> 2308:         iota = iotaShuffle(-origin, 1, true);
> 2309:         return (($abstractvectortype$)w).blend(this.rearrange(iota), BlendMask);

Suggestion:

        return that.blend(this.rearrange(iota), blendMask);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2346:

> 2344:         Objects.checkIndex(origin, length() + 1);
> 2345:         VectorShuffle<$Boxtype$> iota = iotaShuffle();
> 2346:         VectorMask<$Boxtype$> BlendMask = iota.toVector().compare(VectorOperators.GE,

Suggestion:

        VectorMask<$Boxtype$> blendMask = iota.toVector().compare(VectorOperators.GE,

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2349:

> 2347:                                                                   (broadcast(($type$)(origin))));
> 2348:         iota = iotaShuffle(-origin, 1, true);
> 2349:         return vspecies().zero().blend(this.rearrange(iota), BlendMask);

Suggestion:

        return vspecies().zero().blend(this.rearrange(iota), blendMask);

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From psandoz at openjdk.java.net  Fri Apr 30 00:26:58 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 00:26:58 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v2]
In-Reply-To: <gwPwtC3waBKmpr9y-Yh5GlMMKohxeU1Kb_8B98c9qnA=.60fedc2f-b968-4834-a4b5-6a2251a401a7@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <EV_vCwC-iVsJ_MUPJfX-tUglh7lrGO3S9DPjC9PNdrU=.7dba7cfc-4e93-446d-a7d9-72e8bcddda1d@github.com>
 <gwPwtC3waBKmpr9y-Yh5GlMMKohxeU1Kb_8B98c9qnA=.60fedc2f-b968-4834-a4b5-6a2251a401a7@github.com>
Message-ID: <WwxdocDVhbI52IuBGm3UW6qcQFeabkHANYbf8O5GKMM=.a63c0a29-361d-4490-9b2c-65c1ad93d2d4@github.com>

On Thu, 29 Apr 2021 23:36:22 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java line 51:
>> 
>>> 49:     }
>>> 50: 
>>> 51:     static final int INVOC_COUNT = Integer.getInteger("jdk.incubator.vector.test.loop-iterations", 100);
>> 
>> Why did you change this?
>
> Following reasons:
> The INVOC_COUNT is set as 100 for all other tests.
> The conversion tests take longer time to complete than other tests.
> For the conversion tests it looks like the intrinsics don't trigger sometimes and tests take longer to execute and timeout. This was one of the reasons for backout last time.

ok

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From whuang at openjdk.java.net  Fri Apr 30 01:34:52 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 30 Apr 2021 01:34:52 GMT
Subject: RFR: 8265907: JVM crashes when matching VectorMaskCmp Node [v3]
In-Reply-To: <4RMST03w1Ki2jJXp9kcW_klAc78RhD5Jv_H4GYXt26c=.31270330-a7fb-4818-a559-ece801629fac@github.com>
References: <u-7MdHM6IGvkXcRUDh8miqL3nMx7SKaHxTD1WMqX674=.b791dd7f-1d65-42ba-9c6e-9ff1eee73ce3@github.com>
 <_otBn8mWHgqdIjnZ6yiBu_T6F5076C_aKL7yMHe-sHo=.d94a0510-0e91-4286-814c-5b568d7ce923@github.com>
 <4RMST03w1Ki2jJXp9kcW_klAc78RhD5Jv_H4GYXt26c=.31270330-a7fb-4818-a559-ece801629fac@github.com>
Message-ID: <y2injqHUyPh2_awgewWX4CK80doM5eZjYT4HB6ffa54=.997c69ce-b994-4e69-a30d-513406cf87fa@github.com>

On Thu, 29 Apr 2021 09:05:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix x86's bug
>
> src/hotspot/cpu/x86/x86.ad line 1814:
> 
>> 1812:         return false;
>> 1813:       }
>> 1814:       break;
> 
> Did you also see the crash on x86?

Yes, this bug effects x86.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3670

From sviswanathan at openjdk.java.net  Fri Apr 30 01:58:27 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 01:58:27 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
Message-ID: <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>

> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
> 
> Changes include:
>  * Rewrite Vector API slice/unslice using already intrinsic methods
>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>  * Vector API conversion tests thresholds adjustment
>  
> Base Performance:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
> 
> Performance with patch:
> Benchmark (size) Mode Cnt Score Error Units
> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments: blendmask etc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3804/files
  - new: https://git.openjdk.java.net/jdk/pull/3804/files/59275ff6..94f184ef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3804&range=01-02

  Stats: 56 lines in 7 files changed: 0 ins; 0 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3804.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3804/head:pull/3804

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Fri Apr 30 01:58:30 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 01:58:30 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v2]
In-Reply-To: <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <AUqtIIQUivxQWyRRXO_sA_PCss7N-riok2dFz30PZWY=.01504b9c-7b8c-47bc-a640-7ce8dffa6923@github.com>
Message-ID: <9y-PxR99CcZJTpYG8NvzZtAz4PO7m-N7APoIe7kWruk=.75d590cc-5cb8-4588-9a62-c3f013f85291@github.com>

On Fri, 30 Apr 2021 00:17:24 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments implementation

@PaulSandoz Thanks a lot for these suggestions. I have included all of them in this updated commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From yyang at openjdk.java.net  Fri Apr 30 02:19:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 30 Apr 2021 02:19:30 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
Message-ID: <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  better check1-4

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/1a96be7e..954abc6e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=04-05

  Stats: 32 lines in 1 file changed: 31 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615

PR: https://git.openjdk.java.net/jdk/pull/3615

From whuang at openjdk.java.net  Fri Apr 30 02:26:53 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 30 Apr 2021 02:26:53 GMT
Subject: RFR: 8265244: Remove useless comparation in
 LibraryCallKit::inline_vector_convert() [v2]
In-Reply-To: <l1m6pe5teNPUYc94D6Dg-VMQMk6cwxhsuleVdpbdHCY=.50f973c7-35bb-4ebc-afcc-fb28ed194894@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
 <l1m6pe5teNPUYc94D6Dg-VMQMk6cwxhsuleVdpbdHCY=.50f973c7-35bb-4ebc-afcc-fb28ed194894@github.com>
Message-ID: <SGfQEj5z8KY3MYEKCMXISNnnVRbbaT13Nf3etuSIBoM=.7084db29-5e44-49e2-a164-a5ebe8af9eae@github.com>

On Thu, 29 Apr 2021 15:06:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Please change the title of this to
> 
> 8265244: AArch64: Remove useless comparation in LibraryCallKit::inline_vector_convert()
> 
> since it affects the AArch64 port. This makes the logs and the mailing lists much easier to read.
> 
> Thanks.

Thank you for your suggestion. There is only one question here:

 the comparation 

int num_elem_for_cast = MIN2(num_elem_from, Matcher::max_vector_size(elem_bt_to));

which will be removed here can effect all cpus.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3507

From jiefu at openjdk.java.net  Fri Apr 30 02:33:56 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 30 Apr 2021 02:33:56 GMT
Subject: Integrated: 8266267: Remove unnecessary jumps in Intel Math Library
 StubRoutines
In-Reply-To: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
References: <__kNSqm0nMzlVjDoNTYv5bazKaIKdjUqO8PxQVInWbA=.dc7ff2af-9bf8-4135-864a-74c8fe6d3785@github.com>
Message-ID: <tH8Ay61uPKwBtAXnGXlyq4Z5VKpNBlnqlDmoUlBp6Cw=.0fa36e3b-877b-401e-8aad-7121b68ea654@github.com>

On Thu, 29 Apr 2021 03:47:41 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> May I get reviews for this small change?
> 
> If I look at the StubRoutines::libmPow carefully, an unnecessary jump instruction can be found, which is generated here [1].
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmPow [0x00007f0f8455ddd1, 0x00007f0f8455ef05] (4404 bytes)
> --------------------------------------------------------------------------------
>   0x00007f0f8455ddd1:   push   %rbp
>   0x00007f0f8455ddd2:   mov    %rsp,%rbp
>   0x00007f0f8455ddd5:   jmpq   0x00007f0f8455ddda          <--- unnecessary jump
>   0x00007f0f8455ddda:   sub    $0x28,%rsp
>   0x00007f0f8455ddde:   vmovsd %xmm0,0x8(%rsp)
>   0x00007f0f8455dde4:   vmovsd %xmm1,0x10(%rsp)
>   ...
> 
> 
> And similar issues can be found for StubRoutines::libmLog and StubRoutines::libmExp.
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmLog [0x00007f3fb94d48a6, 0x00007f3fb94d4b22] (636 bytes)
> --------------------------------------------------------------------------------
>   0x00007f3fb94d48a6:   push   %rbp
>   0x00007f3fb94d48a7:   mov    %rsp,%rbp
>   0x00007f3fb94d48aa:   jmpq   0x00007f3fb94d48af          <--- unnecessary jump
>   0x00007f3fb94d48af:   sub    $0x18,%rsp
>   0x00007f3fb94d48b3:   vmovsd %xmm0,(%rsp)
>   0x00007f3fb94d48b8:   movabs $0x3ff0000000000000,%rax
>   ...
> 
> 
> 
> - - - [BEGIN] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> StubRoutines::libmExp [0x00007f3fb94d4579, 0x00007f3fb94d48a6] (813 bytes)
> --------------------------------------------------------------------------------
>   0x00007f3fb94d4579:   push   %rbp
>   0x00007f3fb94d457a:   mov    %rsp,%rbp
>   0x00007f3fb94d457d:   jmpq   0x00007f3fb94d4582          <--- unnecessary jump
>   0x00007f3fb94d4582:   sub    $0x18,%rsp
>   0x00007f3fb94d4586:   vmovsd %xmm0,0x8(%rsp)
>   0x00007f3fb94d458c:   vunpcklpd %xmm0,%xmm0,%xmm0
> 
> 
> I can't find a reason why we need an extra jump there.
> So I suggest removing them.
> 
> Testing:
>   - tier1 ~ tier3 on Linux/x64, no regression
> 
> Am I missing something?
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 51b21884
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51b218842f001f1c4fd5ca7a02a2ba21e9e8a82c
Stats:     7 lines in 3 files changed: 2 ins; 5 del; 0 mod

8266267: Remove unnecessary jumps in Intel Math Library StubRoutines

Reviewed-by: thartmann, neliasso, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3784

From psandoz at openjdk.java.net  Fri Apr 30 02:33:52 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 02:33:52 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
Message-ID: <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>

On Fri, 30 Apr 2021 01:58:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> All the slice and unslice variants that take more than one argument can benefit from already intrinsic methods on similar lines as slice(origin) and unslice(origin).
>> 
>> Changes include:
>>  * Rewrite Vector API slice/unslice using already intrinsic methods
>>  * Fix in library_call.cpp:inline_preconditions_checkIndex() to not modify control if intrinsification fails
>>  * Vector API conversion tests thresholds adjustment
>>  
>> Base Performance:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11763.372 ? 254.580 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 599.286 ? 326.770 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6627.601 ? 22.060 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 401.858 ? 220.340 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 421.993 ? 231.703 ops/ms
>> 
>> Performance with patch:
>> Benchmark (size) Mode Cnt Score Error Units
>> TestSlice.vectorSliceOrigin 1024 thrpt 5 11792.091 ? 37.296 ops/ms
>> TestSlice.vectorSliceOriginVector 1024 thrpt 5 8388.174 ? 115.886 ops/ms
>> TestSlice.vectorSliceUnsliceOrigin 1024 thrpt 5 6662.159 ? 8.203 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVector 1024 thrpt 5 5206.300 ? 43.637 ops/ms
>> TestSlice.vectorSliceUnsliceOriginVectorPart 1024 thrpt 5 5194.278 ? 13.376 ops/ms
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments: blendmask etc

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From kvn at openjdk.java.net  Fri Apr 30 04:42:55 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 04:42:55 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v9]
In-Reply-To: <YtnKURoLWf0E_D--86VXzQ8_L3aRVamShXGLCyfLscU=.70b73430-3879-4cdc-90d8-0a99b7b1d735@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <YtnKURoLWf0E_D--86VXzQ8_L3aRVamShXGLCyfLscU=.70b73430-3879-4cdc-90d8-0a99b7b1d735@github.com>
Message-ID: <4I3lYx2yFSzlzbuopEvH8Hpi7Kq2VEl-nG-Jmo-y8D8=.997c82ce-b671-4fef-a878-b1dbd3121b96@github.com>

On Thu, 29 Apr 2021 20:37:12 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Encode cdql/cdqq using MacroAssembler.

I started new testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From kvn at openjdk.java.net  Fri Apr 30 04:47:49 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 04:47:49 GMT
Subject: RFR: 8266328: C2: Remove InlineWarmCalls
In-Reply-To: <hWRsELCx7_oNek3k00sxUIVN2afL0xKEBZU3TQWc2us=.f3b441f7-261f-4f6a-896f-2ae908cdbbf2@github.com>
References: <hWRsELCx7_oNek3k00sxUIVN2afL0xKEBZU3TQWc2us=.f3b441f7-261f-4f6a-896f-2ae908cdbbf2@github.com>
Message-ID: <mua97yePUfYcSiggts2GFSUWMQMA9UWtNz8iKBQ_o4g=.80fb9478-0a48-4ba9-8020-9ceed6cf845f@github.com>

On Thu, 29 Apr 2021 21:46:36 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Remove InlineWarmCalls and all relevant code.
> 
> It was introduced long time ago and didn't get much attention since then. I don't see any value in keeping it around.
> And there's incremental inlining support in C2 now.
> 
> Testing:
> - [x] hs-tier1 - hs-tier2

I assume @veresov uses different approach.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3805

From iveresov at openjdk.java.net  Fri Apr 30 04:51:54 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 30 Apr 2021 04:51:54 GMT
Subject: RFR: 8266328: C2: Remove InlineWarmCalls
In-Reply-To: <hWRsELCx7_oNek3k00sxUIVN2afL0xKEBZU3TQWc2us=.f3b441f7-261f-4f6a-896f-2ae908cdbbf2@github.com>
References: <hWRsELCx7_oNek3k00sxUIVN2afL0xKEBZU3TQWc2us=.f3b441f7-261f-4f6a-896f-2ae908cdbbf2@github.com>
Message-ID: <LxLNcVc4EsfqujiadKMrVUurYG2dK1Zx0ZU5P7tz3Go=.ed614da4-0335-4f29-914c-ac832cc1b23a@github.com>

On Thu, 29 Apr 2021 21:46:36 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Remove InlineWarmCalls and all relevant code.
> 
> It was introduced long time ago and didn't get much attention since then. I don't see any value in keeping it around.
> And there's incremental inlining support in C2 now.
> 
> Testing:
> - [x] hs-tier1 - hs-tier2

Marked as reviewed by iveresov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3805

From iignatyev at openjdk.java.net  Fri Apr 30 05:29:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 30 Apr 2021 05:29:52 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion. [v3]
In-Reply-To: <o3wUK_MDh_CQn2bO03PJKln--Y7ZoclXghDKGxAuT_w=.694a8917-cb2c-443c-a525-87a031bd6c3e@github.com>
References: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
 <o3wUK_MDh_CQn2bO03PJKln--Y7ZoclXghDKGxAuT_w=.694a8917-cb2c-443c-a525-87a031bd6c3e@github.com>
Message-ID: <dTLeVDjoMN03tpLKIvkajI7QuQYetC3a5qnByOtyBD8=.d2948899-8a5f-4625-b8f9-f8bf3b289db3@github.com>

On Thu, 29 Apr 2021 09:24:12 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> The bug: https://bugs.openjdk.java.net/browse/JDK-8265349
>> 
>> A repetition of the JDK-8058176 (mlvm tests cause code cache exhaustion), this time with -Xcomp. My measurements show up max code cache consumption of 400-500 kb per test thread and tree (depends on random tree and other factors, of course, but still). For the whole test which usually doesn't exceed 10 threads, I've got max. value of 6.1M for one sequence/tree build (between checks for remaining free space).
>> 
>> So I suggest to raise the allowances to 10M, just to be safe. Compared to the 103 Mb of required code cache space that test requests via the 'run' parameter, it doesn't look that much.
>> 
>> Thanks in advance,
>> // Evgeny Nikitin.
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explain limits numbers, extract code cache monitoring into a class

other than a typo, LGTM.

test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/share/MHTransformationGen.java line 92:

> 90:         // |      10        |    1 - 2 M    |    5-6 M   |
> 91:         //
> 92:         // Those numbers are approximate (since threes are generated randomly and the total consumption

s/threes/trees/ ?

-------------

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3762

From rraghavan at openjdk.java.net  Fri Apr 30 07:53:51 2021
From: rraghavan at openjdk.java.net (Rahul Raghavan)
Date: Fri, 30 Apr 2021 07:53:51 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class [v2]
In-Reply-To: <L1NUB1ecGwtpPmd5672AGhNjS-PC98YyiEEXjH5s_UI=.7f47c6c4-e5b9-4a01-997f-d89bc2d4a10c@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
 <K1Mr0JImlogw5c_cV9wlstr_jxO9mjkCC-5lS_YUtJA=.22ed7613-e8a0-4f64-9ace-90612c17752f@github.com>
 <M6cyHGCLXL_a5zAtR99QxNYkY-sekk5vsWyUO3DIX3k=.f53ba6e5-9cb8-4077-acc3-c16c6fca8a65@github.com>
 <L1NUB1ecGwtpPmd5672AGhNjS-PC98YyiEEXjH5s_UI=.7f47c6c4-e5b9-4a01-997f-d89bc2d4a10c@github.com>
Message-ID: <4Su69ifgcvrCOnY8GXCjKD0MXEflBXj7Zsp_cw8OQAg=.5919171a-c603-4580-b4a2-e1f7fe7fb629@github.com>

On Thu, 29 Apr 2021 10:36:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Found unavailable/bad comp levels handled in WhiteBox::compile_method() or later in CompileBroker::compile_method.
>
> Right but wouldn't we hit an assert there if C2 is not available?

For the case scenario mentioned found that the test simply displays a WB whitebox error that is ignored.
So seems we can go ahead with the current test case itself. Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/3757

From aph at redhat.com  Fri Apr 30 08:04:09 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 30 Apr 2021 09:04:09 +0100
Subject: RFR: 8265244: Remove useless comparation in
 LibraryCallKit::inline_vector_convert() [v2]
In-Reply-To: <SGfQEj5z8KY3MYEKCMXISNnnVRbbaT13Nf3etuSIBoM=.7084db29-5e44-49e2-a164-a5ebe8af9eae@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
 <l1m6pe5teNPUYc94D6Dg-VMQMk6cwxhsuleVdpbdHCY=.50f973c7-35bb-4ebc-afcc-fb28ed194894@github.com>
 <SGfQEj5z8KY3MYEKCMXISNnnVRbbaT13Nf3etuSIBoM=.7084db29-5e44-49e2-a164-a5ebe8af9eae@github.com>
Message-ID: <27fa3cb5-2c9c-9ebf-167a-54e6f8aceafd@redhat.com>

On 4/30/21 3:26 AM, Wang Huang wrote:
> There is only one question here:
> 
>  the comparation 
> 
> int num_elem_for_cast = MIN2(num_elem_from, Matcher::max_vector_size(elem_bt_to));
> 
> which will be removed here can effect all cpus.

Perhaps so. However, you need to do something with the title because this patch
does not simply remove a useless comparison. You might make life easier for
everyone by splitting this patch into two parts.

-- 
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 aph at openjdk.java.net  Fri Apr 30 08:04:53 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 30 Apr 2021 08:04:53 GMT
Subject: RFR: 8265244: Remove useless comparation in
 LibraryCallKit::inline_vector_convert() [v2]
In-Reply-To: <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
Message-ID: <DlA7l2Ux9_UFoW34oZmJJqVxqPi6kJ_jCiTeU9ujMx4=.09aac61c-1f54-4495-89a9-3fa91729ecd1@github.com>

On Fri, 16 Apr 2021 02:10:10 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> * aarch64 can only accept `VectorReinterpret` with 64/128 bits.
>> * I will fix this bug by adding a rule for `VectorReinterpret` in `match_rule_supported_vector`
>> * after changing note with @nsjian and @XiaohongGong , I think that two checks in `inline_vector_conver` is useless now. However, these checks impact other cpus, so I need more reviewers.
>
> Wang Huang 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 JDK-8265244
>  - 8265244: assert(false) failed: bad AD file

src/hotspot/share/opto/vectorIntrinsics.cpp line 1452:

> 1450:       // Since input and output number of elements are not consistent, we need to make sure we
> 1451:       // properly size. Thus, first make a cast that retains the number of elements from source.
> 1452:       // In case the size exceeds the arch size, we do the minimum.

If you're going to remove the MIN2 you must also change this comment.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1471:

> 1469:     } else if (num_elem_from > num_elem_to) {
> 1470:       // Since number elements from input is larger than output, simply reduce size of input (we are supposed to
> 1471:       // drop top elements anyway).

This one too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3507

From thartmann at openjdk.java.net  Fri Apr 30 08:12:50 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 30 Apr 2021 08:12:50 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class [v2]
In-Reply-To: <Wmlyu6VyPS9S4k5Eax8rqBNYutlXu8QCwDhO_sALlEw=.02b8a18f-b27d-4319-9227-fcc1fe4d4f79@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
 <Wmlyu6VyPS9S4k5Eax8rqBNYutlXu8QCwDhO_sALlEw=.02b8a18f-b27d-4319-9227-fcc1fe4d4f79@github.com>
Message-ID: <C4cnSGJWfBVeuerXRLwC9M9DShA0mp36JOyOlGGbbL8=.98ed1d5f-369c-4fa8-a917-0529ae356325@github.com>

On Thu, 29 Apr 2021 10:34:12 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8264395
>> 
>> Reported assert failure, during compilation triggered by Whitebox API `enqueueInitializerForCompilation` method,
>> is fixed by adding support to to bail out if a class not initialized yet.
>> 
>> Confirmed the new `compiler/whitebox/TestEnqueueInitializerForCompilation.java` test passes with the proposed `whitebox.cpp` changes and fails with reported assert without this fix.
>> No issues with tier tests.
>
> Rahul Raghavan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264395: WB_EnqueueInitializerForCompilation fails with "method holder must be initialized" when called for uninitialized class

Marked as reviewed by thartmann (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3757

From thartmann at openjdk.java.net  Fri Apr 30 08:12:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 30 Apr 2021 08:12:51 GMT
Subject: RFR: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class [v2]
In-Reply-To: <4Su69ifgcvrCOnY8GXCjKD0MXEflBXj7Zsp_cw8OQAg=.5919171a-c603-4580-b4a2-e1f7fe7fb629@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
 <K1Mr0JImlogw5c_cV9wlstr_jxO9mjkCC-5lS_YUtJA=.22ed7613-e8a0-4f64-9ace-90612c17752f@github.com>
 <M6cyHGCLXL_a5zAtR99QxNYkY-sekk5vsWyUO3DIX3k=.f53ba6e5-9cb8-4077-acc3-c16c6fca8a65@github.com>
 <L1NUB1ecGwtpPmd5672AGhNjS-PC98YyiEEXjH5s_UI=.7f47c6c4-e5b9-4a01-997f-d89bc2d4a10c@github.com>
 <4Su69ifgcvrCOnY8GXCjKD0MXEflBXj7Zsp_cw8OQAg=.5919171a-c603-4580-b4a2-e1f7fe7fb629@github.com>
Message-ID: <E3TpAcrrMX4ObCoIiSZ0OlJWzkuBbwbOynzVn6fon78=.4bc002fc-0ef2-4932-be55-856586394edb@github.com>

On Fri, 30 Apr 2021 07:51:16 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

>> Right but wouldn't we hit an assert there if C2 is not available?
>
> For the case scenario mentioned found that the test simply displays a WB whitebox error that is ignored.
> So seems we can go ahead with the current test case itself. Thanks

Yes, as we've discussed off-thread, that's fine. Thanks for investigating.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3757

From rraghavan at openjdk.java.net  Fri Apr 30 08:26:56 2021
From: rraghavan at openjdk.java.net (Rahul Raghavan)
Date: Fri, 30 Apr 2021 08:26:56 GMT
Subject: Integrated: 8264395: WB_EnqueueInitializerForCompilation fails with
 "method holder must be initialized" when called for uninitialized class
In-Reply-To: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
References: <aDXMu2FeLuwRq2Yg6bxo7qi0_JngNgmiHDBj13ePZDo=.8a629d55-139d-4f7a-8214-2bae6e6408b4@github.com>
Message-ID: <PjEldkyEJPu-kzN0mK7QtQByxpzyhi52e60-sANLbf4=.2806548d-b998-4711-a881-be73a658ea52@github.com>

On Wed, 28 Apr 2021 09:39:08 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8264395
> 
> Reported assert failure, during compilation triggered by Whitebox API `enqueueInitializerForCompilation` method,
> is fixed by adding support to to bail out if a class not initialized yet.
> 
> Confirmed the new `compiler/whitebox/TestEnqueueInitializerForCompilation.java` test passes with the proposed `whitebox.cpp` changes and fails with reported assert without this fix.
> No issues with tier tests.

This pull request has now been integrated.

Changeset: 3554dc29
Author:    Rahul Raghavan <rraghavan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3554dc299dd242ffea63be9c5958be7a08d53509
Stats:     49 lines in 2 files changed: 48 ins; 0 del; 1 mod

8264395: WB_EnqueueInitializerForCompilation fails with "method holder must be initialized" when called for uninitialized class

Reviewed-by: chagedorn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3757

From whuang at openjdk.java.net  Fri Apr 30 08:30:53 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Fri, 30 Apr 2021 08:30:53 GMT
Subject: RFR: 8265244: Remove useless comparation in
 LibraryCallKit::inline_vector_convert() [v2]
In-Reply-To: <DlA7l2Ux9_UFoW34oZmJJqVxqPi6kJ_jCiTeU9ujMx4=.09aac61c-1f54-4495-89a9-3fa91729ecd1@github.com>
References: <TUfb4mb0zSHV77FWN6IxWudlHpr8kYWV1bfsDMagSF4=.c25aee19-d9f5-4fc8-bc7f-b3dbf4a01b87@github.com>
 <op1x8uQQ8Nhp7m9u5l1M0TIygS5vqmfI5nrzFXgL82Y=.0d41bc90-d269-4954-b372-9aede9ad6004@github.com>
 <DlA7l2Ux9_UFoW34oZmJJqVxqPi6kJ_jCiTeU9ujMx4=.09aac61c-1f54-4495-89a9-3fa91729ecd1@github.com>
Message-ID: <SraUbxDZSRJb526JETqKyg6SpqMrAx948giSdufSgkA=.37067d53-7307-4548-8a33-48dbdcdd16ca@github.com>

On Fri, 30 Apr 2021 08:01:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Wang Huang 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 JDK-8265244
>>  - 8265244: assert(false) failed: bad AD file
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1452:
> 
>> 1450:       // Since input and output number of elements are not consistent, we need to make sure we
>> 1451:       // properly size. Thus, first make a cast that retains the number of elements from source.
>> 1452:       // In case the size exceeds the arch size, we do the minimum.
> 
> If you're going to remove the MIN2 you must also change this comment.

Sure. I will remove that in next commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3507

From dfuchs at openjdk.java.net  Fri Apr 30 08:59:51 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 30 Apr 2021 08:59:51 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
Message-ID: <7a4Q1KdYnrj-8iKArQaCHP_s6QHuN58Gz1PpvlSOKzo=.03f760ef-75a4-4882-ac3a-b5a21bc3d73d@github.com>

On Fri, 30 Apr 2021 02:19:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better check1-4

Thanks for taking this feedback into account and updating the test!
Note: I only reviewed the test.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3615

From enikitin at openjdk.java.net  Fri Apr 30 09:37:23 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 30 Apr 2021 09:37:23 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion. [v4]
In-Reply-To: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
References: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
Message-ID: <N6vgMceHxmFk8AiTxPXPTkCtjlst2GonZm4rtZ_HfWw=.58c4f3c5-8755-4f5e-94f6-c366f27d57ce@github.com>

> The bug: https://bugs.openjdk.java.net/browse/JDK-8265349
> 
> A repetition of the JDK-8058176 (mlvm tests cause code cache exhaustion), this time with -Xcomp. My measurements show up max code cache consumption of 400-500 kb per test thread and tree (depends on random tree and other factors, of course, but still). For the whole test which usually doesn't exceed 10 threads, I've got max. value of 6.1M for one sequence/tree build (between checks for remaining free space).
> 
> So I suggest to raise the allowances to 10M, just to be safe. Compared to the 103 Mb of required code cache space that test requests via the 'run' parameter, it doesn't look that much.
> 
> Thanks in advance,
> // Evgeny Nikitin.

Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo threes -> trees

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3762/files
  - new: https://git.openjdk.java.net/jdk/pull/3762/files/c3f52fbf..a5beaa06

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3762&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3762&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3762.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3762/head:pull/3762

PR: https://git.openjdk.java.net/jdk/pull/3762

From enikitin at openjdk.java.net  Fri Apr 30 09:37:23 2021
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 30 Apr 2021 09:37:23 GMT
Subject: RFR: 8265349: vmTestbase/../stress/compiler/deoptimize/Test.java
 fails with OOME due to CodeCache exhaustion. [v3]
In-Reply-To: <dTLeVDjoMN03tpLKIvkajI7QuQYetC3a5qnByOtyBD8=.d2948899-8a5f-4625-b8f9-f8bf3b289db3@github.com>
References: <Ca3FX0178mVxZoe5ePBIwAyPZ1Y4BFeSaPZyFSVTW7w=.f7ba57d3-e631-4eab-a7ed-af79cdf19850@github.com>
 <o3wUK_MDh_CQn2bO03PJKln--Y7ZoclXghDKGxAuT_w=.694a8917-cb2c-443c-a525-87a031bd6c3e@github.com>
 <dTLeVDjoMN03tpLKIvkajI7QuQYetC3a5qnByOtyBD8=.d2948899-8a5f-4625-b8f9-f8bf3b289db3@github.com>
Message-ID: <T-dCKc1KWhr8AggpGTYHh20uQMKWM6KYtpVQEZDzvB0=.2bcd07c5-d359-4ad3-8d81-f8e9b96a4e9d@github.com>

On Fri, 30 Apr 2021 05:24:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> s/threes/trees/ ?

How did you know that these were not actual threes / troikas? :))

Fixed, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3762

From mdoerr at openjdk.java.net  Fri Apr 30 09:50:20 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 30 Apr 2021 09:50:20 GMT
Subject: RFR: 8265784: [C2] Hoisting of DecodeN leaves MachTemp inputs behind
Message-ID: <2jy2CBKOYJx9mu017Cm4M2yQYWivb2kK1gCvrZAxD7Y=.a7d2d333-a630-4956-abc6-8d461417ff92@github.com>

PPC64 and s390 have DecodeN implementations which use a MachTemp input. When LCM hoists the DecodeN, the MachTemp nodes reside in the old block, but should get hoisted together with the DecodeN node.
Same is true for load Base input which exists on s390 for example. Unfortunately, that's just a platform specific MachNode which is not nicely recognizable in LCM.

-------------

Commit messages:
 - More generic condition for input node hoisting decision
 - Fix indentation.
 - Also support hoisting of load Base input. Remove assertion again which would require more changes.
 - Move hoisting of MachTemp inputs before hoisting of DecodeN. Add stronger assertion to PhaseCFG::verify()
 - 8265784: [C2] Hoisting of DecodeN leaves MachTemp inputs behind

Changes: https://git.openjdk.java.net/jdk/pull/3637/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3637&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265784
  Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3637.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3637/head:pull/3637

PR: https://git.openjdk.java.net/jdk/pull/3637

From goetz at openjdk.java.net  Fri Apr 30 09:50:21 2021
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Fri, 30 Apr 2021 09:50:21 GMT
Subject: RFR: 8265784: [C2] Hoisting of DecodeN leaves MachTemp inputs
 behind
In-Reply-To: <2jy2CBKOYJx9mu017Cm4M2yQYWivb2kK1gCvrZAxD7Y=.a7d2d333-a630-4956-abc6-8d461417ff92@github.com>
References: <2jy2CBKOYJx9mu017Cm4M2yQYWivb2kK1gCvrZAxD7Y=.a7d2d333-a630-4956-abc6-8d461417ff92@github.com>
Message-ID: <OmB9DL2jaWshusnDORpilNYfkNGYLfa0m1VeYqpMsIM=.afd94f4a-8b33-44f7-af2f-d371f3ae8b0e@github.com>

On Thu, 22 Apr 2021 18:58:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 and s390 have DecodeN implementations which use a MachTemp input. When LCM hoists the DecodeN, the MachTemp nodes reside in the old block, but should get hoisted together with the DecodeN node.
> Same is true for load Base input which exists on s390 for example. Unfortunately, that's just a platform specific MachNode which is not nicely recognizable in LCM.

Hi Martin, 
I think the loop must go before the block->add_inst(val); .
Else you get a cycle within the block.
The MachTemp must be before the node that uses them in the list.
Best regards,
  Goetz.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3637

From jbhateja at openjdk.java.net  Fri Apr 30 12:59:34 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 30 Apr 2021 12:59:34 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v2]
In-Reply-To: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
Message-ID: <YcxnCbTjMJi0n5ftQm1iYxc2JDTezQvoHkaWd0olAU8=.f3ffc87a-06ea-40b3-9956-14ff566159d8@github.com>

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server)
> 
> ``
> Benchmark | (TESTSIZE) | Baseline (ops/min) | Withopt (ops/min) | Gain %
> -- | -- | -- | -- | --
> RotateBenchmark.testRotateLeftI | 64 | 6813.033 | 6936.507 | 1.81
> RotateBenchmark.testRotateLeftI | 64 | 11549.524 | 12109.845 | 4.85
> RotateBenchmark.testRotateLeftI | 64 | 17780.166 | 18180.083 | 2.25
> RotateBenchmark.testRotateLeftI | 128 | 3355.631 | 3426.436 | 2.11
> RotateBenchmark.testRotateLeftI | 128 | 5925.534 | 6096.71 | 2.89
> RotateBenchmark.testRotateLeftI | 128 | 8847.645 | 8964.224 | 1.32
> RotateBenchmark.testRotateLeftI | 256 | 1704.192 | 1779.964 | 4.45
> RotateBenchmark.testRotateLeftI | 256 | 2919.158 | 3000.392 | 2.78
> RotateBenchmark.testRotateLeftI | 256 | 4386.134 | 4514.211 | 2.92
> RotateBenchmark.testRotateLeftL | 64 | 3419.193 | 3500.522 | 2.38
> RotateBenchmark.testRotateLeftL | 64 | 5982.87 | 6056.589 | 1.23
> RotateBenchmark.testRotateLeftL | 64 | 8829.172 | 8949.157 | 1.36
> RotateBenchmark.testRotateLeftL | 128 | 1684.745 | 1784.49 | 5.92
> RotateBenchmark.testRotateLeftL | 128 | 2942.226 | 2947.684 | 0.19
> RotateBenchmark.testRotateLeftL | 128 | 4385.488 | 4554.113 | 3.85
> RotateBenchmark.testRotateLeftL | 256 | 834.195 | 856.939 | 2.73
> RotateBenchmark.testRotateLeftL | 256 | 1463.802 | 1551.051 | 5.96
> RotateBenchmark.testRotateLeftL | 256 | 2187.005 | 2268.596 | 3.73
> RotateBenchmark.testRotateRightI | 64 | 6676.132 | 7077.587 | 6.01
> RotateBenchmark.testRotateRightI | 64 | 11452.825 | 11855.45 | 3.52
> RotateBenchmark.testRotateRightI | 64 | 17507.286 | 18164.757 | 3.76
> RotateBenchmark.testRotateRightI | 128 | 3412.394 | 3519.829 | 3.15
> RotateBenchmark.testRotateRightI | 128 | 5905.677 | 5875.698 | -0.51
> RotateBenchmark.testRotateRightI | 128 | 8745.95 | 8890.757 | 1.66
> RotateBenchmark.testRotateRightI | 256 | 1681.176 | 1708.54 | 1.63
> RotateBenchmark.testRotateRightI | 256 | 3004.008 | 3005.606 | 0.05
> RotateBenchmark.testRotateRightI | 256 | 4466.633 | 4548.232 | 1.83
> RotateBenchmark.testRotateRightL | 64 | 3361.499 | 3461.121 | 2.96
> RotateBenchmark.testRotateRightL | 64 | 5873.37 | 6072.209 | 3.39
> RotateBenchmark.testRotateRightL | 64 | 8820.284 | 9016.172 | 2.22
> RotateBenchmark.testRotateRightL | 128 | 1715.556 | 1720.67 | 0.30
> RotateBenchmark.testRotateRightL | 128 | 2957.337 | 3149.193 | 6.49
> RotateBenchmark.testRotateRightL | 128 | 4440.468 | 4473.221 | 0.74
> RotateBenchmark.testRotateRightL | 256 | 851.391 | 875.371 | 2.82
> RotateBenchmark.testRotateRightL | 256 | 1452.422 | 1522.942 | 4.86
> RotateBenchmark.testRotateRightL | 256 | 2208.454 | 2263.349 | 2.49
> 
>  ``

Jatin Bhateja 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 four additional commits since the last revision:

 - 8266054: Review comments resolution.
 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - 8266054: Changing gen-src.sh file permissions
 - 8266054: VectorAPI rotate operation optimization

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3720/files
  - new: https://git.openjdk.java.net/jdk/pull/3720/files/1e3e350e..eee407b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=00-01

  Stats: 6574 lines in 245 files changed: 4515 ins; 1280 del; 779 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720

PR: https://git.openjdk.java.net/jdk/pull/3720

From jbhateja at openjdk.java.net  Fri Apr 30 13:09:16 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 30 Apr 2021 13:09:16 GMT
Subject: RFR: 8265126: unified handling for VectorMask object
 re-materialization during de-optimization (re-submit) [v2]
In-Reply-To: <2KlypmIXfPwTn6dp0AG9W0LMqvu6griQnWjSEQBwn2o=.6b09a942-e241-4ff6-b581-1810aa6bb124@github.com>
References: <2KlypmIXfPwTn6dp0AG9W0LMqvu6griQnWjSEQBwn2o=.6b09a942-e241-4ff6-b581-1810aa6bb124@github.com>
Message-ID: <jfG3BcKcXm-P83GrkP2MCp8oLhOvKXI7cl600ta46GM=.55c12095-0ec2-4511-b6b2-32c24670ca11@github.com>

> Following flow describes object reconstruction for de-optimization:-
> 
> 1. PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
> 2. During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
> 3. De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
> 4. During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings.
> 
> By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.
> 
> tier1-tier3 regressions are clean with UseAVX=2/3.

Jatin Bhateja 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 http://github.com/openjdk/jdk into JDK-8265126
 - 8265126:[REDO] unified handling for VectorMask object re-materialization during de-optimization

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3721/files
  - new: https://git.openjdk.java.net/jdk/pull/3721/files/b35e1345..70c03aa3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3721&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3721&range=00-01

  Stats: 7915 lines in 259 files changed: 5651 ins; 1373 del; 891 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3721.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3721/head:pull/3721

PR: https://git.openjdk.java.net/jdk/pull/3721

From hshi at openjdk.java.net  Fri Apr 30 14:24:10 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Fri, 30 Apr 2021 14:24:10 GMT
Subject: RFR: 8265767: compiler/eliminateAutobox/TestIntBoxing.java crashes on
 arm32 after 8264649 in debug VMs
Message-ID: <iap-eRiBcBdxqF0E7z1_3ZWEIoXlrJbVmKph6Ly7Itg=.1aeb8fe0-c90f-49bd-8cb1-c68f9ac97fa2@github.com>

This patch fix failure exposed by JDK-8264649.

compiler/eliminateAutobox/TestIntBoxing.java crashes on arm32 in Compile::check_no_dead_use assertion.
In LoadNode::eliminate_autobox, early "result" is dead after line 1450 but not added into PhaseGVN worklist for optimization.
Its out_cnt is 0. If it isn't removed, will trigger assertion in Compile::check_no_dead_use.


1443             } else if (result->is_Add() && result->in(2)->is_Con() &&
1444                        result->in(1)->Opcode() == Op_LShiftX &&
1445                        result->in(1)->in(2) == phase->intcon(shift)) {
1446               // We can't do general optimization: ((X<<Z) + Y) >> Z ==> X + (Y>>Z)
1447               // but for boxing cache access we know that X<<Z will not overflow
1448               // (there is range check) so we do this optimizatrion by hand here.
1449               Node* add_con = new RShiftXNode(result->in(2), phase->intcon(shift));
                       --- result before is  dead and might not removed
1450               result = new AddXNode(result->in(1)->in(1), phase->transform(add_con)); 
1451             } else 


Detail analysis is in https://bugs.openjdk.java.net/browse/JDK-8265767 

@mychris  I have verified compiler/eliminateAutobox/TestIntBoxing.java on qemu, it failed with same assertion and now passes with this fix. Would you please help verify it on arm32 machine?

Testing:
- Passed Tier1-3 on Linux x86_64, release and fastdebug build,  default option and -XX:-TieredCompilation.
- compiler/eliminateAutobox/TestIntBoxing.java on arm32 release/fastdebug/slowdebug

-------------

Commit messages:
 - 8265767: compiler/eliminateAutobox/TestIntBoxing.java crashes on arm32 after 8264649 in debug VMs

Changes: https://git.openjdk.java.net/jdk/pull/3818/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3818&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265767
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3818/head:pull/3818

PR: https://git.openjdk.java.net/jdk/pull/3818

From psandoz at openjdk.java.net  Fri Apr 30 15:48:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 15:48:03 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v2]
In-Reply-To: <YcxnCbTjMJi0n5ftQm1iYxc2JDTezQvoHkaWd0olAU8=.f3ffc87a-06ea-40b3-9956-14ff566159d8@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <YcxnCbTjMJi0n5ftQm1iYxc2JDTezQvoHkaWd0olAU8=.f3ffc87a-06ea-40b3-9956-14ff566159d8@github.com>
Message-ID: <HBXgFsgLdv7Sxkr2rVZxvrINOPs1W3evCYYTIeANxE4=.e30ef1cb-443b-4da6-a04b-95b48ebf213b@github.com>

On Fri, 30 Apr 2021 12:59:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server)
>> 
>> ``
>> Benchmark | (TESTSIZE) | Baseline (ops/min) | Withopt (ops/min) | Gain %
>> -- | -- | -- | -- | --
>> RotateBenchmark.testRotateLeftI | 64 | 6813.033 | 6936.507 | 1.81
>> RotateBenchmark.testRotateLeftI | 64 | 11549.524 | 12109.845 | 4.85
>> RotateBenchmark.testRotateLeftI | 64 | 17780.166 | 18180.083 | 2.25
>> RotateBenchmark.testRotateLeftI | 128 | 3355.631 | 3426.436 | 2.11
>> RotateBenchmark.testRotateLeftI | 128 | 5925.534 | 6096.71 | 2.89
>> RotateBenchmark.testRotateLeftI | 128 | 8847.645 | 8964.224 | 1.32
>> RotateBenchmark.testRotateLeftI | 256 | 1704.192 | 1779.964 | 4.45
>> RotateBenchmark.testRotateLeftI | 256 | 2919.158 | 3000.392 | 2.78
>> RotateBenchmark.testRotateLeftI | 256 | 4386.134 | 4514.211 | 2.92
>> RotateBenchmark.testRotateLeftL | 64 | 3419.193 | 3500.522 | 2.38
>> RotateBenchmark.testRotateLeftL | 64 | 5982.87 | 6056.589 | 1.23
>> RotateBenchmark.testRotateLeftL | 64 | 8829.172 | 8949.157 | 1.36
>> RotateBenchmark.testRotateLeftL | 128 | 1684.745 | 1784.49 | 5.92
>> RotateBenchmark.testRotateLeftL | 128 | 2942.226 | 2947.684 | 0.19
>> RotateBenchmark.testRotateLeftL | 128 | 4385.488 | 4554.113 | 3.85
>> RotateBenchmark.testRotateLeftL | 256 | 834.195 | 856.939 | 2.73
>> RotateBenchmark.testRotateLeftL | 256 | 1463.802 | 1551.051 | 5.96
>> RotateBenchmark.testRotateLeftL | 256 | 2187.005 | 2268.596 | 3.73
>> RotateBenchmark.testRotateRightI | 64 | 6676.132 | 7077.587 | 6.01
>> RotateBenchmark.testRotateRightI | 64 | 11452.825 | 11855.45 | 3.52
>> RotateBenchmark.testRotateRightI | 64 | 17507.286 | 18164.757 | 3.76
>> RotateBenchmark.testRotateRightI | 128 | 3412.394 | 3519.829 | 3.15
>> RotateBenchmark.testRotateRightI | 128 | 5905.677 | 5875.698 | -0.51
>> RotateBenchmark.testRotateRightI | 128 | 8745.95 | 8890.757 | 1.66
>> RotateBenchmark.testRotateRightI | 256 | 1681.176 | 1708.54 | 1.63
>> RotateBenchmark.testRotateRightI | 256 | 3004.008 | 3005.606 | 0.05
>> RotateBenchmark.testRotateRightI | 256 | 4466.633 | 4548.232 | 1.83
>> RotateBenchmark.testRotateRightL | 64 | 3361.499 | 3461.121 | 2.96
>> RotateBenchmark.testRotateRightL | 64 | 5873.37 | 6072.209 | 3.39
>> RotateBenchmark.testRotateRightL | 64 | 8820.284 | 9016.172 | 2.22
>> RotateBenchmark.testRotateRightL | 128 | 1715.556 | 1720.67 | 0.30
>> RotateBenchmark.testRotateRightL | 128 | 2957.337 | 3149.193 | 6.49
>> RotateBenchmark.testRotateRightL | 128 | 4440.468 | 4473.221 | 0.74
>> RotateBenchmark.testRotateRightL | 256 | 851.391 | 875.371 | 2.82
>> RotateBenchmark.testRotateRightL | 256 | 1452.422 | 1522.942 | 4.86
>> RotateBenchmark.testRotateRightL | 256 | 2208.454 | 2263.349 | 2.49
>> 
>>  ``
>
> Jatin Bhateja 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 four additional commits since the last revision:
> 
>  - 8266054: Review comments resolution.
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - 8266054: Changing gen-src.sh file permissions
>  - 8266054: VectorAPI rotate operation optimization

src/hotspot/cpu/x86/x86.ad line 1652:

> 1650:     case Op_RotateRightV:
> 1651:     case Op_RotateLeftV:
> 1652:       if (is_subword_type(bt)) {

Does that have the effect of not intrinsifying for `byte` or `short`?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 728:

> 726:                 case VECTOR_OP_URSHIFT: return (v0, v1) ->
> 727:                         v0.bOp(v1, (i, a, n) -> ($type$)((a & LSHR_SETUP_MASK) >>> n));
> 728: #if[long]

I recommend you create new methods in `IntVector` etc called `rotateLeft` and `rotateRight` that do what is in the lambda expressions. Then you can collapse this to non-conditional cases calling those methods.

Do the same for the tests (like i did with the unsigned support), see

https://github.com/openjdk/jdk/blob/a31777959abc7cac1bf6d2a453d6fc15b628d866/test/jdk/jdk/incubator/vector/templates/Unit-header.template#L1429

and

https://github.com/openjdk/jdk/blob/a31777959abc7cac1bf6d2a453d6fc15b628d866/test/jdk/jdk/incubator/vector/gen-template.sh#L491

That will avoid the embedding of complex expressions.

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 37:

> 35: 
> 36:   @Param({"64","128","256"})
> 37:   public int TESTSIZE;

Suggestion:

  int size;

Lower case for instance field names (same applies to the species).
No need for `public`.

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 55:

> 53: 
> 54:   public final long[] specialValsL = {0L, -0L, Long.MIN_VALUE, Long.MAX_VALUE};
> 55:   public final int[] specialValsI = {0, -0, Integer.MIN_VALUE, Integer.MAX_VALUE};

Suggestion:

  static final long[] specialValsL = {0L, -0L, Long.MIN_VALUE, Long.MAX_VALUE};
  static final int[] specialValsI = {0, -0, Integer.MIN_VALUE, Integer.MAX_VALUE};

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 83:

> 81:   @Benchmark
> 82:   public void testRotateLeftI(Blackhole bh) {
> 83:     for(int i = 0 ; i < 10000; i++) {

No need for the outer loop. JMH will do that for you.

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 85:

> 83:     for(int i = 0 ; i < 10000; i++) {
> 84:       for (int j = 0 ; j < TESTSIZE; j+= ISPECIES.length()) {
> 85:         vecI = IntVector.fromArray(ISPECIES, inpI, j);

Suggestion:

        var vecI = IntVector.fromArray(ISPECIES, inpI, j);

Use a local variable instead of storing to a field

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 91:

> 89:         vecI = vecI.lanewise(VectorOperators.ROL, i);
> 90:         vecI.lanewise(VectorOperators.ROL, i).intoArray(resI, j);
> 91:       }

Suggestion:

      }
      return resI;

return the result to better ensure HotSpot does not detect the result is unused.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From kvn at openjdk.java.net  Fri Apr 30 16:52:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 16:52:52 GMT
Subject: RFR: 8265784: [C2] Hoisting of DecodeN leaves MachTemp inputs
 behind
In-Reply-To: <2jy2CBKOYJx9mu017Cm4M2yQYWivb2kK1gCvrZAxD7Y=.a7d2d333-a630-4956-abc6-8d461417ff92@github.com>
References: <2jy2CBKOYJx9mu017Cm4M2yQYWivb2kK1gCvrZAxD7Y=.a7d2d333-a630-4956-abc6-8d461417ff92@github.com>
Message-ID: <8hMJJg_5eABiCGYJ73pXn1FRu8ue22Wk1mBu97IFfuI=.e6103262-c055-4784-bf34-500bff0b41bc@github.com>

On Thu, 22 Apr 2021 18:58:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 and s390 have DecodeN implementations which use a MachTemp input. When LCM hoists the DecodeN, the MachTemp nodes reside in the old block, but should get hoisted together with the DecodeN node.
> Same is true for load Base input which exists on s390 for example. Unfortunately, that's just a platform specific MachNode which is not nicely recognizable in LCM.

Moving additional TEMP and CONST? input edges to the same block is correct.
Is base always constant (like CompressedOops::base())? Otherwise you may need add anti dependences for load.
Can you show where MachTemp edges are added for DecodeN?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3637

From kvn at openjdk.java.net  Fri Apr 30 17:04:57 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 17:04:57 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v9]
In-Reply-To: <YtnKURoLWf0E_D--86VXzQ8_L3aRVamShXGLCyfLscU=.70b73430-3879-4cdc-90d8-0a99b7b1d735@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <YtnKURoLWf0E_D--86VXzQ8_L3aRVamShXGLCyfLscU=.70b73430-3879-4cdc-90d8-0a99b7b1d735@github.com>
Message-ID: <wGQqydAGJ0KGySNVCwz0wNpsIBOpsQmIBUkfcEORbn4=.e9f357e1-cd1d-4bb5-b4d3-fd6acd741b28@github.com>

On Thu, 29 Apr 2021 20:37:12 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Encode cdql/cdqq using MacroAssembler.

Preliminary result shows compiler/c2/cr6340864/TestLongVect.java test failure on linux and windows -x64 when run with not G1 gc (Serial, Parallel, ZGC) (the line could be different again due to use of latest source base):

#  Internal Error (/workspace/open/src/hotspot/cpu/x86/assembler_x86.cpp:10753), pid=9483, tid=9495
#  assert(isByte(imm8)) failed: not a byte
#
# JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build 17-internal+0-LTS-2021-04-30-0438565.jdkgit)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-internal+0-LTS-2021-04-30-0438565.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x6471b4]  Assembler::sarq(RegisterImpl*, int)+0x164

V  [libjvm.so+0x6471b4]  Assembler::sarq(RegisterImpl*, int)+0x164
V  [libjvm.so+0x34d566]  sarL_rReg_immNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0xb6
V  [libjvm.so+0x1588551]  PhaseOutput::scratch_emit_size(Node const*)+0x421
V  [libjvm.so+0x157f3f8]  PhaseOutput::shorten_branches(unsigned int*)+0x2b8
V  [libjvm.so+0x159165a]  PhaseOutput::Output()+0xcca
V  [libjvm.so+0xa0636b]  Compile::Code_Gen()+0x43b

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From kvn at openjdk.java.net  Fri Apr 30 17:09:54 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 17:09:54 GMT
Subject: RFR: 8241502: C2: Migrate x86_64.ad to MacroAssembler [v9]
In-Reply-To: <YtnKURoLWf0E_D--86VXzQ8_L3aRVamShXGLCyfLscU=.70b73430-3879-4cdc-90d8-0a99b7b1d735@github.com>
References: <UXKug9HfdxFKLZcq908fwIjjED5yoYDQqt0-8VlbYf4=.2ad09b97-36ad-4d96-b1fe-01ff640948a4@github.com>
 <YtnKURoLWf0E_D--86VXzQ8_L3aRVamShXGLCyfLscU=.70b73430-3879-4cdc-90d8-0a99b7b1d735@github.com>
Message-ID: <kVscdSzt0qWYHFIxuIBUsyt55NzFzx7Z-hhx0ueku0g=.2b37ebd6-52df-4d21-8a4e-475e94a57772@github.com>

On Thu, 29 Apr 2021 20:37:12 GMT, John Tortugo <github.com+2249648+JohnTortugo 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.
>
> John Tortugo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Encode cdql/cdqq using MacroAssembler.

Got additional result and it failed with G1 too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2420

From sviswanathan at openjdk.java.net  Fri Apr 30 17:12:54 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 17:12:54 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
 <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
Message-ID: <OKiLq6ekHxo2uDtmrQSMo2lZshGkqZW3KpjH7xcoC8U=.0b1d9a95-44cb-44e5-99a7-3c306e936ac2@github.com>

On Fri, 30 Apr 2021 02:31:07 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments: blendmask etc
>
> Marked as reviewed by psandoz (Reviewer).

@PaulSandoz would it be possible for you to run this through your testing?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From rraghavan at openjdk.java.net  Fri Apr 30 17:28:04 2021
From: rraghavan at openjdk.java.net (Rahul Raghavan)
Date: Fri, 30 Apr 2021 17:28:04 GMT
Subject: RFR: 8252237: C2: Call to compute_separating_interferences has wrong
 argument order
Message-ID: <xaThXKbYTwTPArjzs7CRYKJ_fvwTlRqPFg57w-r4aIg=.c7c38518-71dc-4f70-87f2-941b37cbf444@github.com>

`https://bugs.openjdk.java.net/browse/JDK-8252237`

<Copying details from Old PR - `https://github.com/openjdk/jdk/pull/1533`>
      (**NOTE: This old PR was approved then.
      But we did not commit the changes then because of last stage of JDK 16 
      and waited for more tests, performance runs. 
      Results of multiple test run, performance benchmarks are available now and confirmed no issues)


[`src/hotspot/share/opto/coalesce.hpp`] -
`112 uint compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint rm_size, uint reg_degree, uint lr1, uint lr2);`


[`src/hotspot/share/opto/coalesce.cpp`] -

..........
538 uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint reg_degree, uint rm_size, uint lr1, uint lr2 ) {
.................
747 reg_degree = compute_separating_interferences(dst_copy, src_copy, b, bindex, rm, rm_size, reg_degree, lr1, lr2 );



So fixing the argument order - [`/src/hotspot/share/opto/coalesce.cpp`]

-uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint reg_degree, uint rm_size, uint lr1, uint lr2 ) {
+uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint rm_size, uint reg_degree, uint lr1, uint lr2 ) {

-------------

Commit messages:
 - 8252237: C2: Call to compute_separating_interferences has wrong argument order

Changes: https://git.openjdk.java.net/jdk/pull/3820/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3820&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252237
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3820.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3820/head:pull/3820

PR: https://git.openjdk.java.net/jdk/pull/3820

From psandoz at openjdk.java.net  Fri Apr 30 17:33:52 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 17:33:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
Message-ID: <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>

On Fri, 30 Apr 2021 02:19:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better check1-4

It was my hope this would eventually happen when we added `Objects.checkIndex` and the underlying intrinsic. Very good!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From psandoz at openjdk.java.net  Fri Apr 30 17:47:57 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 17:47:57 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
 <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
Message-ID: <-VJVRq98DoOIRYPdSB8b2k1oOAI2vHeyKgo00bvGbSE=.00ef20ca-d072-4426-9e8e-c0e5433d3440@github.com>

On Fri, 30 Apr 2021 02:31:07 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments: blendmask etc
>
> Marked as reviewed by psandoz (Reviewer).

> @PaulSandoz would it be possible for you to run this through your testing?

Started, will report back when done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From kvn at openjdk.java.net  Fri Apr 30 17:49:54 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 17:49:54 GMT
Subject: RFR: 8265767: compiler/eliminateAutobox/TestIntBoxing.java
 crashes on arm32 after 8264649 in debug VMs
In-Reply-To: <iap-eRiBcBdxqF0E7z1_3ZWEIoXlrJbVmKph6Ly7Itg=.1aeb8fe0-c90f-49bd-8cb1-c68f9ac97fa2@github.com>
References: <iap-eRiBcBdxqF0E7z1_3ZWEIoXlrJbVmKph6Ly7Itg=.1aeb8fe0-c90f-49bd-8cb1-c68f9ac97fa2@github.com>
Message-ID: <IfqsBahZKNzJoZ9cB0ixRx9zUtKGZ2GR30LfyWrmKdE=.9c2315b5-8ca3-4262-b8d7-9e36ee400382@github.com>

On Fri, 30 Apr 2021 14:17:23 GMT, Hui Shi <hshi at openjdk.org> wrote:

> This patch fix failure exposed by JDK-8264649.
> 
> compiler/eliminateAutobox/TestIntBoxing.java crashes on arm32 in Compile::check_no_dead_use assertion.
> In LoadNode::eliminate_autobox, early "result" is dead after line 1450 but not added into PhaseGVN worklist for optimization.
> Its out_cnt is 0. If it isn't removed, will trigger assertion in Compile::check_no_dead_use.
> 
> 
> 1443             } else if (result->is_Add() && result->in(2)->is_Con() &&
> 1444                        result->in(1)->Opcode() == Op_LShiftX &&
> 1445                        result->in(1)->in(2) == phase->intcon(shift)) {
> 1446               // We can't do general optimization: ((X<<Z) + Y) >> Z ==> X + (Y>>Z)
> 1447               // but for boxing cache access we know that X<<Z will not overflow
> 1448               // (there is range check) so we do this optimizatrion by hand here.
> 1449               Node* add_con = new RShiftXNode(result->in(2), phase->intcon(shift));
>                        --- result before is  dead and might not removed
> 1450               result = new AddXNode(result->in(1)->in(1), phase->transform(add_con)); 
> 1451             } else 
> 
> 
> Detail analysis is in https://bugs.openjdk.java.net/browse/JDK-8265767 
> 
> @mychris  I have verified compiler/eliminateAutobox/TestIntBoxing.java on qemu, it failed with same assertion and now passes with this fix. Would you please help verify it on arm32 machine?
> 
> Testing:
> - Passed Tier1-3 on Linux x86_64, release and fastdebug build,  default option and -XX:-TieredCompilation.
> - compiler/eliminateAutobox/TestIntBoxing.java on arm32 release/fastdebug/slowdebug

The fix is reasonable.
Add comment `// remove dead node later`
Pass `PhaseIterGVN* igvn` instead of `eliminate_autobox(PhaseGVN* phase)` to simplify code. Note, `can_reshape == true` only for PhaseIterGVN.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3818

From iignatyev at openjdk.java.net  Fri Apr 30 19:15:02 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 30 Apr 2021 19:15:02 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
 <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>
Message-ID: <Iv_wApDfqdfY2muggzWqm4QumlHY7FZC3FnqIDUG4fs=.cac90f16-5bc4-4f0f-895f-05cd3aa4cc9b@github.com>

On Fri, 30 Apr 2021 18:22:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix XCOMP cases from old framework and turn it into new debug flag -DIgnoreCompilerControls
>>  - Apply review comments: Added new Compiler annotation class for @DontCompile, changed C1 into C1_SIMPLE, refactored code for ExcludeRandom and FlipC1C2, added missing flag description in README, and some other smaller refactoring/renamings
>
> test/lib/jdk/test/lib/hotspot/ir_framework/TestInfo.java line 57:
> 
>> 55:      * allowing a compilation on the requested level in {@link Test#compLevel()}.
>> 56:      *
>> 57:      * @return {@code true} if the framework compiled the test;
> 
> as in `RunInfo`:
> s/compiled/skipped compilation of/

btw, do we really need these methods in both `RunInfo` and `TestInfo`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3508

From iignatyev at openjdk.java.net  Fri Apr 30 19:15:01 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 30 Apr 2021 19:15:01 GMT
Subject: RFR: 8254129: IR Test Framework to support regex-based matching
 on the IR in JTreg compiler tests [v7]
In-Reply-To: <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com>
 <CRIhti9uhUeomQiRSNw_37RrtiZNDcgTCRITdw8WYFQ=.a39401f2-eb72-4a9e-95e9-8a7922488785@github.com>
Message-ID: <Z6cOgjgAztCdO5ZlauvqCkWXSUHfmtnPejsmQcqNOCA=.1162cfa5-0e9d-40a9-ade9-4e614103d7dc@github.com>

On Tue, 27 Apr 2021 15:37:58 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags.
>> 
>> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point.
>> 
>> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes.
>> 
>> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE.
>> 
>> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)):
>> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline.
>> 
>> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework):
>> 
>> -  without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions.
>>    - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests)  and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions
>>       - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`)
>>       - which leaves 4382 lines of code inserted 
>> 
>> Big thanks to:
>> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla.
>> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs.
>> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure.
>> - and others who provided valuable feedback.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix XCOMP cases from old framework and turn it into new debug flag -DIgnoreCompilerControls
>  - Apply review comments: Added new Compiler annotation class for @DontCompile, changed C1 into C1_SIMPLE, refactored code for ExcludeRandom and FlipC1C2, added missing flag description in README, and some other smaller refactoring/renamings

Hi Christian,

I've reviewed all the files but `examples` and `tests`, for them I'd actually recommend you to put `examples` into `tests` (possible in a subdir), and just update readme to say that the examples can be found in test directory.

I'd also recommend you to put your java files into separate packages to reflect their decision b/w multiple JVMs (flag, test, driver), so you will end up w/ 3-4 subpackages (+1 for the code shared b/w 3 JVMs), this will make it easier to reason about and maintain the framework.

Thanks,
-- Igor

test/lib/jdk/test/lib/hotspot/ir_framework/RunInfo.java line 89:

> 87:      * {@link #isCompilationSkipped(String)}.
> 88:      *
> 89:      * @return {@code true} if the framework compiled the test;

s/compiled/skipped compilation of/ ?

test/lib/jdk/test/lib/hotspot/ir_framework/RunInfo.java line 105:

> 103:      *
> 104:      * @param testName the test method for which the method object should be returned.
> 105:      * @return {@code true} if the framework compiled the test;

the same comment as above

test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 984:

> 982:     private final String hotspotPidFileName;
> 983: 
> 984:     JVMOutput(OutputAnalyzer oa, Scenario scenario, ProcessBuilder process) {

instead of passing a ProcessBuilder, you can either pass a command-line or better just past prepared flags, and make it JVMOutput's (you will need a better name) responsibility to execute the process, create OutputAnalyzer, etc. 

Suggestion:

    JVMOutput(List<String> cmds, Scenario scenario) {
    var pb = ProcessTools.createJavaProcessBuilder(cmds);
    try {
            // Calls 'main' of TestFrameworkExecution to run all specified tests with commands 'cmds'.
            // Use executeProcess instead of executeTestJvm as we have already added the JTreg VM and
            // Java options in prepareTestVMFlags().
            this.oa = ProcessTools.executeProcess(process);
        } catch (Exception e) {
            throw new TestFrameworkException("Error while executing Test VM", e);
        }
        this.cmd = pb.command();
        ...


and then runTest will be smth like

    private void runTestVM(List<String> additionalFlags) {
          List<String> cmds = prepareTestVMFlags(additionalFlags);
          socket.start();
          JVMOutput output = new JVMOutput(cmds, scenario);
          ...

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 375:

> 373:             case 2 -> compiler = Compiler.C2;
> 374:             default -> compiler = Compiler.ANY;
> 375:         }

Suggestion:

        Compiler compiler =  switch (Utils.getRandomInstance().nextInt() % 3) {
            case 1 -> Compiler.C1;
            case 2 -> Compiler.C2;
            default -> Compiler.ANY;
        }

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 796:

> 794:             if (VERBOSE) {
> 795:                 System.out.println("Run " + test.toString());
> 796:             } else if (testFilterPresent) {

I'm not sure, but it feels like it shouldn't be `else if`

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 819:

> 817:             if (GC_AFTER) {
> 818:                 System.out.println("doing GC");
> 819:                 System.gc();

since this VM has access to WhiteBox API, you can call `WhiteBox.fullGC()` here as it's more "reliable".

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 827:

> 825:             System.out.println(System.lineSeparator() + System.lineSeparator() + "Test execution times:");
> 826:             for (Map.Entry<Long, String> entry : durations.entrySet()) {
> 827:                 System.out.format("%-10s%15d ns" + System.lineSeparator(), entry.getValue() + ":", entry.getKey());

instead of System.lineSeparator(), you can use `%n` in the format string

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 960:

> 958:  * Abstract super class for base, checked and custom run tests.
> 959:  */
> 960: abstract class AbstractTest {

can you move this  and all the classes below into their own .java files? you might want to put them into a separate package (as a way to group/isolate them)

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkPrepareFlags.java line 92:

> 90:                           + String.join(TestFramework.TEST_VM_FLAGS_DELIMITER, flags)
> 91:                           + System.lineSeparator() + TestFramework.TEST_VM_FLAGS_END;
> 92:         TestFrameworkSocket.write(encoding, "flag encoding");

I don't see a need to use socket here, it will significantly simplify the code, the failure analysis, and reproducing if we just save prepared flags into a file w/ a well-known location (e.g. passed as an argument/property to `TestFrameworkPrepareFlags`), and when used command-line argument file (`@-file`) to pass these flags to the test VM.

test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkSocket.java line 87:

> 85: 
> 86:     /**
> 87:      * Waits for client sockets (created by flag or test VM) to connect. Return the messages received by the clients.

it actually waits for just one client, and return the message sent by it (ore received from):
Suggestion:

     * Waits for a client (created by flag or test VM) to connect. Return the messages received from the client.

test/lib/jdk/test/lib/hotspot/ir_framework/TestInfo.java line 57:

> 55:      * allowing a compilation on the requested level in {@link Test#compLevel()}.
> 56:      *
> 57:      * @return {@code true} if the framework compiled the test;

as in `RunInfo`:
s/compiled/skipped compilation of/

test/lib/jdk/test/lib/hotspot/ir_framework/TestVMException.java line 34:

> 32:     TestVMException(String exceptionInfo) {
> 33:         super("There were one or multiple errors. Please check stderr for more information.");
> 34:         this.exceptionInfo = exceptionInfo;

why can't this info be stored as `Throwable::message`?

-------------

Changes requested by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3508

From vlivanov at openjdk.java.net  Fri Apr 30 19:16:55 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 30 Apr 2021 19:16:55 GMT
Subject: RFR: 8265126: unified handling for VectorMask object
 re-materialization during de-optimization (re-submit) [v2]
In-Reply-To: <jfG3BcKcXm-P83GrkP2MCp8oLhOvKXI7cl600ta46GM=.55c12095-0ec2-4511-b6b2-32c24670ca11@github.com>
References: <2KlypmIXfPwTn6dp0AG9W0LMqvu6griQnWjSEQBwn2o=.6b09a942-e241-4ff6-b581-1810aa6bb124@github.com>
 <jfG3BcKcXm-P83GrkP2MCp8oLhOvKXI7cl600ta46GM=.55c12095-0ec2-4511-b6b2-32c24670ca11@github.com>
Message-ID: <pZKKlcbIp1R95mOkaglzhamWHEdINtkCED8jt8_oFlE=.0ed5fad9-2619-4348-b16d-e264e040f318@github.com>

On Fri, 30 Apr 2021 13:09:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Following flow describes object reconstruction for de-optimization:-
>> 
>> 1. PhaseVector::scalarize_vbox_node() creates SafePointScalarObjectNode to captures the box type information, also it connects to node holding the boxed value.
>> 2. During code emit phase (PhaseOutput) C2 process above information to dumps ObjectValue holding the box information and LocationValue to holding the value information into ScopeDescriptor corresponding to Safepoint PC.
>> 3. De-optimization blobs dump the value held in registers to the stack locations using RegisterSave::save_live_registers() and a mapping b/w register and its stack location is added to RegisterMap.
>> 4. During de-optimization, compiled frame objects are re-allocated using identity information held in ObjectValue and their fields are initialized using values held in the stack locations accessed through register-stack mappings.
>> 
>> By inserting a VectorStoreMaskNode before stitching the mask holding node to Safepoint we make sure that value held in opmask/vector register is transferred to a byte vector. Thus rest of the flow works as it is, stack location will hold the value in the form of a byte array irrespective of the box shape.
>> 
>> tier1-tier3 regressions are clean with UseAVX=2/3.
>
> Jatin Bhateja 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 http://github.com/openjdk/jdk into JDK-8265126
>  - 8265126:[REDO] unified handling for VectorMask object re-materialization during de-optimization

Submitted the patch for testing (hs-tier1 - hs-tier4).

src/hotspot/share/opto/vector.cpp line 244:

> 242:     SafePointNode* sfpt = safepoints.pop()->as_SafePoint();
> 243: 
> 244:     ciInstanceKlass* iklass = vec_box->box_type()->klass()->as_instance_klass();

Why do you remove that code? It was added to avoid a crash with -XX:+PrintAssembly.

src/hotspot/share/prims/vectorSupport.cpp line 100:

> 98: void VectorSupport::init_payload_element(typeArrayOop arr, BasicType elem_bt, int index, address addr) {
> 99:   switch (elem_bt) {
> 100:     case T_BOOLEAN: arr->  byte_at_put(index,   *(jboolean*)addr); break;

Please, use `bool_at_put` and fix formatting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3721

From iveresov at openjdk.java.net  Fri Apr 30 19:23:52 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 30 Apr 2021 19:23:52 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
References: <u_5GWEVwAy96Rdhg68EV3SBKdrFw0tRT-RIqL9Bc03w=.27b7f010-f2a1-4766-8510-85b9501749e2@github.com>
 <XhO1jaST4ykd7dDgqa4OklmXQmOApe3QU0A3OSTG9Nw=.fe3fb576-2fa3-4dd7-935a-dc9298592d8c@github.com>
Message-ID: <Uf0aONZoxL2AE5JwWz23tigdbIG4wWcicoT4TGMCabc=.9b789615-35ed-4434-8e03-5b2bbb90291c@github.com>

On Fri, 30 Apr 2021 02:19:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better check1-4

Looks like now the test fails in the pre-submit tests?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3615

From kvn at openjdk.java.net  Fri Apr 30 19:26:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 19:26:52 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
Message-ID: <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>

On Tue, 27 Apr 2021 20:15:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
> 
> It served quite well for many years, but it accumulated significant complexity
> to support different corner cases over time and inevitable evolution of the JVM
> stretched the whole approach way too much (to the point where it become almost
> impossible to extend the analysis any further).
> 
> It turns out the root problem is the decision to reimplement method resolution
> and method selection logic from scratch and to perform it on JVM internal
> representation. It makes it very hard to reason about correctness and the
> implementation becomes sensitive to changes in internal representation.
> 
> So, the main motivation for the redesign is twofold: 
>  * reduce maintenance burden and increase confidence in the code;
>  * unlock some long-awaited enhancements.
> 
> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
> any possible enhancements are deliberately kept out of scope for the current PR.
> (It does deliver a bit of minor enhancements front as the changes in
> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
> of the other changes and was not the goal of the current work.)
> 
> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
> and relies on vtable/itable information to detect target method for every
> subclass it visits. It removes all the complexity associated with method
> resolution and method selection logic and leaves only essential logic to prepare for method selection.
> 
> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
> Instead of supporting not yet linked case, it is simply ignored. It is safe to
> skip them (treat as "effectively non-concrete") since it is guaranteed there
> are no instances created yet. But it requires VM to check dependencies once a
> class is linked.
> 
> I ended up with 2 separate dependency validation passes (when class is loaded
> and when it is linked). To avoid duplicated work, only dependencies
> which may be affected by class initialization state change
> (`unique_concrete_method_4`) are visited. 
> 
> (I experimented with merging passes into a single pass (delay the pass until
> linkage is over), but it severely affected other class-related dependencies and
> relevant optimizations.code.)
> 
> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
> 
> Old implementation is kept intact for now (will be removed later) to:
>   - JVMCI hasn't been migrated to the new implementation yet;
>   - enable verification that 2 implementations (old and new) agree on the results;
>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
> 
> Testing:
> - [x] hs-tier1 - hs-tier9
> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
> - [x] performance testing
>   
> Thanks!

In general looks good. I have few comments.

src/hotspot/share/code/dependencies.hpp line 138:

> 136:     // than {M1}.
> 137:     unique_concrete_method_2, // one unique concrete method under CX
> 138:     unique_concrete_method_4, // one unique concrete method under CX

Needs comment to distinguish from `unique_concrete_method_2`.

test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java line 35:

> 33:  *
> 34:  * @run main/othervm -Xbootclasspath/a:. -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions
> 35:  *                   -XX:+UseVtableBasedCHA

`UseVtableBasedCHA` is `true` by default. May be duplicate these `runs` for both cases: on and off.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From vlivanov at openjdk.java.net  Fri Apr 30 19:34:06 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 30 Apr 2021 19:34:06 GMT
Subject: RFR: 8266388: C2: Improve constant ShiftCntV on x86
Message-ID: <JxTRUYcRCiKCZMPF7eQJ9xle_ycXTRxwkLV37nJJ4nA=.00a086b0-cb14-4e32-839c-42b2c57f65b2@github.com>

Clone ShiftCntV w/ a constant input during matching on x86. 
It enables `vshiftI_imm`/`vshiftL_imm` when ShiftCntV is shared.

Testing:
- [x] hs-tier1 - hs-tier4

-------------

Commit messages:
 - 8266388: C2: Improve ShiftCntV with a constant shift on x86

Changes: https://git.openjdk.java.net/jdk/pull/3823/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3823&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266388
  Stats: 6 lines in 3 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3823.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3823/head:pull/3823

PR: https://git.openjdk.java.net/jdk/pull/3823

From vlivanov at openjdk.java.net  Fri Apr 30 19:37:52 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 30 Apr 2021 19:37:52 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
Message-ID: <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>

On Fri, 30 Apr 2021 19:15:50 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
>> 
>> It served quite well for many years, but it accumulated significant complexity
>> to support different corner cases over time and inevitable evolution of the JVM
>> stretched the whole approach way too much (to the point where it become almost
>> impossible to extend the analysis any further).
>> 
>> It turns out the root problem is the decision to reimplement method resolution
>> and method selection logic from scratch and to perform it on JVM internal
>> representation. It makes it very hard to reason about correctness and the
>> implementation becomes sensitive to changes in internal representation.
>> 
>> So, the main motivation for the redesign is twofold: 
>>  * reduce maintenance burden and increase confidence in the code;
>>  * unlock some long-awaited enhancements.
>> 
>> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
>> any possible enhancements are deliberately kept out of scope for the current PR.
>> (It does deliver a bit of minor enhancements front as the changes in
>> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
>> of the other changes and was not the goal of the current work.)
>> 
>> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
>> and relies on vtable/itable information to detect target method for every
>> subclass it visits. It removes all the complexity associated with method
>> resolution and method selection logic and leaves only essential logic to prepare for method selection.
>> 
>> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
>> Instead of supporting not yet linked case, it is simply ignored. It is safe to
>> skip them (treat as "effectively non-concrete") since it is guaranteed there
>> are no instances created yet. But it requires VM to check dependencies once a
>> class is linked.
>> 
>> I ended up with 2 separate dependency validation passes (when class is loaded
>> and when it is linked). To avoid duplicated work, only dependencies
>> which may be affected by class initialization state change
>> (`unique_concrete_method_4`) are visited. 
>> 
>> (I experimented with merging passes into a single pass (delay the pass until
>> linkage is over), but it severely affected other class-related dependencies and
>> relevant optimizations.code.)
>> 
>> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
>> 
>> Old implementation is kept intact for now (will be removed later) to:
>>   - JVMCI hasn't been migrated to the new implementation yet;
>>   - enable verification that 2 implementations (old and new) agree on the results;
>>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier9
>> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
>> - [x] performance testing
>>   
>> Thanks!
>
> test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java line 35:
> 
>> 33:  *
>> 34:  * @run main/othervm -Xbootclasspath/a:. -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions
>> 35:  *                   -XX:+UseVtableBasedCHA
> 
> `UseVtableBasedCHA` is `true` by default. May be duplicate these `runs` for both cases: on and off.

The test assumes `UseVtableBasedCHA` is on and some of the assertions it makes fail with `-XX:-UseVtableBasedCHA`. So, it would require all the changes in the test logic have to be guarded by a check whether UseVtableBasedCHA is on or off.

Considering `UseVtableBasedCHA` is turned on by default in the PR, I don't see much value in complicating the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From kvn at openjdk.java.net  Fri Apr 30 20:03:49 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 20:03:49 GMT
Subject: RFR: 8252237: C2: Call to compute_separating_interferences has
 wrong argument order
In-Reply-To: <xaThXKbYTwTPArjzs7CRYKJ_fvwTlRqPFg57w-r4aIg=.c7c38518-71dc-4f70-87f2-941b37cbf444@github.com>
References: <xaThXKbYTwTPArjzs7CRYKJ_fvwTlRqPFg57w-r4aIg=.c7c38518-71dc-4f70-87f2-941b37cbf444@github.com>
Message-ID: <hcD6mzf1GqG0E9jea3S4kvwhBFTa-Zblqp2KBhaoqhs=.760b4701-a39c-4b61-b4c4-540d1fbc5de6@github.com>

On Fri, 30 Apr 2021 15:37:07 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

> `https://bugs.openjdk.java.net/browse/JDK-8252237`
> 
> <Copying details from Old PR - `https://github.com/openjdk/jdk/pull/1533`>
>       (**NOTE: This old PR was approved then.
>       But we did not commit the changes then because of last stage of JDK 16 
>       and waited for more tests, performance runs. 
>       Results of multiple test run, performance benchmarks are available now and confirmed no issues)
> 
> 
> [`src/hotspot/share/opto/coalesce.hpp`] -
> `112 uint compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint rm_size, uint reg_degree, uint lr1, uint lr2);`
> 
> 
> [`src/hotspot/share/opto/coalesce.cpp`] -
> 
> ..........
> 538 uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint reg_degree, uint rm_size, uint lr1, uint lr2 ) {
> .................
> 747 reg_degree = compute_separating_interferences(dst_copy, src_copy, b, bindex, rm, rm_size, reg_degree, lr1, lr2 );
> 
> 
> 
> So fixing the argument order - [`/src/hotspot/share/opto/coalesce.cpp`]
> 
> -uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint reg_degree, uint rm_size, uint lr1, uint lr2 ) {
> +uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint rm_size, uint reg_degree, uint lr1, uint lr2 ) {

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3820

From kvn at openjdk.java.net  Fri Apr 30 20:07:50 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 20:07:50 GMT
Subject: RFR: 8266388: C2: Improve constant ShiftCntV on x86
In-Reply-To: <JxTRUYcRCiKCZMPF7eQJ9xle_ycXTRxwkLV37nJJ4nA=.00a086b0-cb14-4e32-839c-42b2c57f65b2@github.com>
References: <JxTRUYcRCiKCZMPF7eQJ9xle_ycXTRxwkLV37nJJ4nA=.00a086b0-cb14-4e32-839c-42b2c57f65b2@github.com>
Message-ID: <LjPos2ehYh0hi6iVqzKC-rXfYOy2EPndhRBJpORvyYM=.67a0d313-2109-4d52-b84d-77a0ab601a88@github.com>

On Fri, 30 Apr 2021 19:18:37 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Clone ShiftCntV w/ a constant input during matching on x86. 
> It enables `vshiftI_imm`/`vshiftL_imm` when ShiftCntV is shared.
> 
> Testing:
> - [x] hs-tier1 - hs-tier4

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3823

From kvn at openjdk.java.net  Fri Apr 30 20:16:11 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 20:16:11 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
 <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>
Message-ID: <JGLHRtT7a3fRS2dNxDAaq0G4bGhLMvszHzH9-jTBS-Q=.146dfa8d-ff45-4f9b-8316-4bcee5be01ef@github.com>

On Fri, 30 Apr 2021 19:34:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java line 35:
>> 
>>> 33:  *
>>> 34:  * @run main/othervm -Xbootclasspath/a:. -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions
>>> 35:  *                   -XX:+UseVtableBasedCHA
>> 
>> `UseVtableBasedCHA` is `true` by default. May be duplicate these `runs` for both cases: on and off.
>
> The test assumes `UseVtableBasedCHA` is on and some of the assertions it makes fail with `-XX:-UseVtableBasedCHA`. So, it would require all the changes in the test logic have to be guarded by a check whether UseVtableBasedCHA is on or off.
> 
> Considering `UseVtableBasedCHA` is turned on by default in the PR, I don't see much value in complicating the test.

So only new implementation is tested with these changes in test. Got it. May be use:
`@requires vm.opt.final.UseVtableBasedCHA == true`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From rraghavan at openjdk.java.net  Fri Apr 30 20:18:51 2021
From: rraghavan at openjdk.java.net (Rahul Raghavan)
Date: Fri, 30 Apr 2021 20:18:51 GMT
Subject: Integrated: 8252237: C2: Call to compute_separating_interferences has
 wrong argument order
In-Reply-To: <xaThXKbYTwTPArjzs7CRYKJ_fvwTlRqPFg57w-r4aIg=.c7c38518-71dc-4f70-87f2-941b37cbf444@github.com>
References: <xaThXKbYTwTPArjzs7CRYKJ_fvwTlRqPFg57w-r4aIg=.c7c38518-71dc-4f70-87f2-941b37cbf444@github.com>
Message-ID: <DgKSEuCdVbUZiISX2pxnqUYd54MYkzzOpfkJ7x086zM=.5ecb8501-c633-4c5a-a21f-ead5d5ac7a81@github.com>

On Fri, 30 Apr 2021 15:37:07 GMT, Rahul Raghavan <rraghavan at openjdk.org> wrote:

> `https://bugs.openjdk.java.net/browse/JDK-8252237`
> 
> <Copying details from Old PR - `https://github.com/openjdk/jdk/pull/1533`>
>       (**NOTE: This old PR was approved then.
>       But we did not commit the changes then because of last stage of JDK 16 
>       and waited for more tests, performance runs. 
>       Results of multiple test run, performance benchmarks are available now and confirmed no issues)
> 
> 
> [`src/hotspot/share/opto/coalesce.hpp`] -
> `112 uint compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint rm_size, uint reg_degree, uint lr1, uint lr2);`
> 
> 
> [`src/hotspot/share/opto/coalesce.cpp`] -
> 
> ..........
> 538 uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint reg_degree, uint rm_size, uint lr1, uint lr2 ) {
> .................
> 747 reg_degree = compute_separating_interferences(dst_copy, src_copy, b, bindex, rm, rm_size, reg_degree, lr1, lr2 );
> 
> 
> 
> So fixing the argument order - [`/src/hotspot/share/opto/coalesce.cpp`]
> 
> -uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint reg_degree, uint rm_size, uint lr1, uint lr2 ) {
> +uint PhaseConservativeCoalesce::compute_separating_interferences(Node *dst_copy, Node *src_copy, Block *b, uint bindex, RegMask &rm, uint rm_size, uint reg_degree, uint lr1, uint lr2 ) {

This pull request has now been integrated.

Changeset: 928d6324
Author:    Rahul Raghavan <rraghavan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/928d63242e614676f96bd3e6bfdee499779d0d4f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8252237: C2: Call to compute_separating_interferences has wrong argument order

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/3820

From jrose at openjdk.java.net  Fri Apr 30 20:26:54 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Fri, 30 Apr 2021 20:26:54 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
Message-ID: <wWFDcRLKlZl6hTk0v8mgFzMce7YFmXL58e8WjUcgTsc=.43bfe2b3-84ab-48d3-88f7-3ef32f03402f@github.com>

On Tue, 27 Apr 2021 20:15:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
> 
> It served quite well for many years, but it accumulated significant complexity
> to support different corner cases over time and inevitable evolution of the JVM
> stretched the whole approach way too much (to the point where it become almost
> impossible to extend the analysis any further).
> 
> It turns out the root problem is the decision to reimplement method resolution
> and method selection logic from scratch and to perform it on JVM internal
> representation. It makes it very hard to reason about correctness and the
> implementation becomes sensitive to changes in internal representation.
> 
> So, the main motivation for the redesign is twofold: 
>  * reduce maintenance burden and increase confidence in the code;
>  * unlock some long-awaited enhancements.
> 
> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
> any possible enhancements are deliberately kept out of scope for the current PR.
> (It does deliver a bit of minor enhancements front as the changes in
> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
> of the other changes and was not the goal of the current work.)
> 
> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
> and relies on vtable/itable information to detect target method for every
> subclass it visits. It removes all the complexity associated with method
> resolution and method selection logic and leaves only essential logic to prepare for method selection.
> 
> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
> Instead of supporting not yet linked case, it is simply ignored. It is safe to
> skip them (treat as "effectively non-concrete") since it is guaranteed there
> are no instances created yet. But it requires VM to check dependencies once a
> class is linked.
> 
> I ended up with 2 separate dependency validation passes (when class is loaded
> and when it is linked). To avoid duplicated work, only dependencies
> which may be affected by class initialization state change
> (`unique_concrete_method_4`) are visited. 
> 
> (I experimented with merging passes into a single pass (delay the pass until
> linkage is over), but it severely affected other class-related dependencies and
> relevant optimizations.code.)
> 
> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
> 
> Old implementation is kept intact for now (will be removed later) to:
>   - JVMCI hasn't been migrated to the new implementation yet;
>   - enable verification that 2 implementations (old and new) agree on the results;
>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
> 
> Testing:
> - [x] hs-tier1 - hs-tier9
> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
> - [x] performance testing
>   
> Thanks!

This is a major bit of stewardship.  Here's a bit of old history:  The approximate dependencies walk code was hacked in the earliest days, for devirtualization?a new and cool thing back then.  At the same time the vtable code was hacked in, and both sets of logic were hacked until the bugs went away.  It took a while for all of us to fully understand the VM we were building.  (This is why we had to add ACC_SUPER and class loader ~dependencies~ constraints, for example.)   A couple engineers cleaned up the vtable stuff to its present state, and I and others cleaned up the CHA logic to its present state, before you touched it.  It?s great to see those two bodies of code converging; thank you very very much.

Reviewed!

One question, which the review doesn't depend on:  Are get getting closer to being able to apply CHA to interfaces? Unique-implementor and unique-method optimizations on interfaces are important.  I ask because of some comments that throw shade on interfaces in the unit tests.

src/hotspot/share/code/dependencies.cpp line 1521:

> 1519:     selected_method = recv_klass->method_at_itable_or_null(_declaring_klass, _vtable_index,
> 1520:                                                            implements_interface); // out parameter
> 1521:     assert(implements_interface, "not implemented");

Looking at `recv_klass->method_at_itable_or_null`, I wonder if there can be ?holes? in the itable for missing methods.  They would lead to `AME` if called.  They might also trigger your assert here:  `assert(implements_interface, "not implemented")`.  Is there some reason that `select_method` cannot possibly encounter a missing method?

Answer to self:  I don't remember whether the JVM creates itable methods on the fly, but I suppose it does, so the code would see an synthetic abstract method.  (Decades ago we named those Miranda Methods because if you don't have a responding method "one will be provided for you".)  And itables are just aliases of vtable slices, so the miranda placed in the vtable will be seen also in the itable.

(Overall comment on this area of the code:  It looks great, much better than when I touched it last.  Thanks!)

-------------

Marked as reviewed by jrose (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3727

From vlivanov at openjdk.java.net  Fri Apr 30 20:38:56 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 30 Apr 2021 20:38:56 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <wWFDcRLKlZl6hTk0v8mgFzMce7YFmXL58e8WjUcgTsc=.43bfe2b3-84ab-48d3-88f7-3ef32f03402f@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <wWFDcRLKlZl6hTk0v8mgFzMce7YFmXL58e8WjUcgTsc=.43bfe2b3-84ab-48d3-88f7-3ef32f03402f@github.com>
Message-ID: <J_QtjzW5SvYZyN_nO_F2BheFKuj67wq9ShAGUVyo2A0=.d6228c75-08a1-4727-b041-634d79daf6a8@github.com>

On Fri, 30 Apr 2021 20:24:23 GMT, John R Rose <jrose at openjdk.org> wrote:

> Are get getting closer to being able to apply CHA to interfaces?

Yes! Though it is always the case now that any interface method case can be strength-reduced to a virtual call (due to unique implementor constraint), I deliberately kept interface dispatch support in place. Once there's a reliable way to enumerate all implementors, it becomes straightforwad to apply CHA when interface type information can be trusted. 

And, as a first step, it would be very interesting to experiment with sealed interface support .

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From vlivanov at openjdk.java.net  Fri Apr 30 21:47:52 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 30 Apr 2021 21:47:52 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <wWFDcRLKlZl6hTk0v8mgFzMce7YFmXL58e8WjUcgTsc=.43bfe2b3-84ab-48d3-88f7-3ef32f03402f@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <wWFDcRLKlZl6hTk0v8mgFzMce7YFmXL58e8WjUcgTsc=.43bfe2b3-84ab-48d3-88f7-3ef32f03402f@github.com>
Message-ID: <eYKXm0dkoWL62DchbGcEZ6hnbv3Pys5r5dUB8mfl3qY=.c4a2c7e5-c15f-4050-9ad8-4dbaf3df920e@github.com>

On Fri, 30 Apr 2021 20:08:39 GMT, John R Rose <jrose at openjdk.org> wrote:

>> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy.
>> 
>> It served quite well for many years, but it accumulated significant complexity
>> to support different corner cases over time and inevitable evolution of the JVM
>> stretched the whole approach way too much (to the point where it become almost
>> impossible to extend the analysis any further).
>> 
>> It turns out the root problem is the decision to reimplement method resolution
>> and method selection logic from scratch and to perform it on JVM internal
>> representation. It makes it very hard to reason about correctness and the
>> implementation becomes sensitive to changes in internal representation.
>> 
>> So, the main motivation for the redesign is twofold: 
>>  * reduce maintenance burden and increase confidence in the code;
>>  * unlock some long-awaited enhancements.
>> 
>> Though I did experiment with relaxing existing constraints (e.g., enable default method support), 
>> any possible enhancements are deliberately kept out of scope for the current PR.
>> (It does deliver a bit of minor enhancements front as the changes in
>> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect
>> of the other changes and was not the goal of the current work.)
>> 
>> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation
>> and relies on vtable/itable information to detect target method for every
>> subclass it visits. It removes all the complexity associated with method
>> resolution and method selection logic and leaves only essential logic to prepare for method selection.
>> 
>> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. 
>> Instead of supporting not yet linked case, it is simply ignored. It is safe to
>> skip them (treat as "effectively non-concrete") since it is guaranteed there
>> are no instances created yet. But it requires VM to check dependencies once a
>> class is linked.
>> 
>> I ended up with 2 separate dependency validation passes (when class is loaded
>> and when it is linked). To avoid duplicated work, only dependencies
>> which may be affected by class initialization state change
>> (`unique_concrete_method_4`) are visited. 
>> 
>> (I experimented with merging passes into a single pass (delay the pass until
>> linkage is over), but it severely affected other class-related dependencies and
>> relevant optimizations.code.)
>> 
>> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed.
>> 
>> Old implementation is kept intact for now (will be removed later) to:
>>   - JVMCI hasn't been migrated to the new implementation yet;
>>   - enable verification that 2 implementations (old and new) agree on the results;
>>   - temporarily keep an option to revert to the original implementation in case any regressions show up.
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier9
>> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA`
>> - [x] performance testing
>>   
>> Thanks!
>
> src/hotspot/share/code/dependencies.cpp line 1521:
> 
>> 1519:     selected_method = recv_klass->method_at_itable_or_null(_declaring_klass, _vtable_index,
>> 1520:                                                            implements_interface); // out parameter
>> 1521:     assert(implements_interface, "not implemented");
> 
> Looking at `recv_klass->method_at_itable_or_null`, I wonder if there can be ?holes? in the itable for missing methods.  They would lead to `AME` if called.  They might also trigger your assert here:  `assert(implements_interface, "not implemented")`.  Is there some reason that `select_method` cannot possibly encounter a missing method?
> 
> Answer to self:  I don't remember whether the JVM creates itable methods on the fly, but I suppose it does, so the code would see an synthetic abstract method.  (Decades ago we named those Miranda Methods because if you don't have a responding method "one will be provided for you".)  And itables are just aliases of vtable slices, so the miranda placed in the vtable will be seen also in the itable.
> 
> (Overall comment on this area of the code:  It looks great, much better than when I touched it last.  Thanks!)

Regarding "holes" in itables: yes, it happens in practice. `select_method` is allowed to return a `NULL` and it is used by `LinkedConcreteMethodFinder` as a sentinel value for `AME` (when placed in `_found_methods` array). That's why `Dependencies::find_unique_concrete_method()` check `participant(0)`:

   Method* fm = wf.found_method(0);  // Will be NULL if num_parts == 0.
   Klass*   p = wf.participant(0);   // Will be NULL if num_parts == 0.
   ...
   if (Dependencies::is_concrete_method(m, ctxk)) {
     if (fm == NULL && p == NULL) {
       // It turns out that m was always the only implementation.
       fm = m;
     }


Now I think that it's not clear enough from the code. I'll elaborate on it in the additional comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From vlivanov at openjdk.java.net  Fri Apr 30 21:51:54 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 30 Apr 2021 21:51:54 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <eYKXm0dkoWL62DchbGcEZ6hnbv3Pys5r5dUB8mfl3qY=.c4a2c7e5-c15f-4050-9ad8-4dbaf3df920e@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <wWFDcRLKlZl6hTk0v8mgFzMce7YFmXL58e8WjUcgTsc=.43bfe2b3-84ab-48d3-88f7-3ef32f03402f@github.com>
 <eYKXm0dkoWL62DchbGcEZ6hnbv3Pys5r5dUB8mfl3qY=.c4a2c7e5-c15f-4050-9ad8-4dbaf3df920e@github.com>
Message-ID: <tmByDoe8orkISUVcdJQqSFaG0xOLwxbU8jFfN96IUo4=.aa78981b-8e5b-44c9-a216-334e2f1ebfb5@github.com>

On Fri, 30 Apr 2021 21:44:34 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/code/dependencies.cpp line 1521:
>> 
>>> 1519:     selected_method = recv_klass->method_at_itable_or_null(_declaring_klass, _vtable_index,
>>> 1520:                                                            implements_interface); // out parameter
>>> 1521:     assert(implements_interface, "not implemented");
>> 
>> Looking at `recv_klass->method_at_itable_or_null`, I wonder if there can be ?holes? in the itable for missing methods.  They would lead to `AME` if called.  They might also trigger your assert here:  `assert(implements_interface, "not implemented")`.  Is there some reason that `select_method` cannot possibly encounter a missing method?
>> 
>> Answer to self:  I don't remember whether the JVM creates itable methods on the fly, but I suppose it does, so the code would see an synthetic abstract method.  (Decades ago we named those Miranda Methods because if you don't have a responding method "one will be provided for you".)  And itables are just aliases of vtable slices, so the miranda placed in the vtable will be seen also in the itable.
>> 
>> (Overall comment on this area of the code:  It looks great, much better than when I touched it last.  Thanks!)
>
> Regarding "holes" in itables: yes, it happens in practice. `select_method` is allowed to return a `NULL` and it is used by `LinkedConcreteMethodFinder` as a sentinel value for `AME` (when placed in `_found_methods` array). That's why `Dependencies::find_unique_concrete_method()` check `participant(0)`:
> 
>    Method* fm = wf.found_method(0);  // Will be NULL if num_parts == 0.
>    Klass*   p = wf.participant(0);   // Will be NULL if num_parts == 0.
>    ...
>    if (Dependencies::is_concrete_method(m, ctxk)) {
>      if (fm == NULL && p == NULL) {
>        // It turns out that m was always the only implementation.
>        fm = m;
>      }
> 
> 
> Now I think that it's not clear enough from the code. I'll elaborate on it in the additional comments.

Regarding the assert: the itable should always be found. First, because only implementors are enumerated during the analysis (currently, subclasses of the unique direct implementor). Second, because itable stubs rely on itable contents when performing receiver subtype checks. So, all superinterfaces should have a corresponding itable present (even an empty one).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From vlivanov at openjdk.java.net  Fri Apr 30 22:05:52 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 30 Apr 2021 22:05:52 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <JGLHRtT7a3fRS2dNxDAaq0G4bGhLMvszHzH9-jTBS-Q=.146dfa8d-ff45-4f9b-8316-4bcee5be01ef@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
 <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>
 <JGLHRtT7a3fRS2dNxDAaq0G4bGhLMvszHzH9-jTBS-Q=.146dfa8d-ff45-4f9b-8316-4bcee5be01ef@github.com>
Message-ID: <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com>

On Fri, 30 Apr 2021 20:13:19 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The test assumes `UseVtableBasedCHA` is on and some of the assertions it makes fail with `-XX:-UseVtableBasedCHA`. So, it would require all the changes in the test logic have to be guarded by a check whether UseVtableBasedCHA is on or off.
>> 
>> Considering `UseVtableBasedCHA` is turned on by default in the PR, I don't see much value in complicating the test.
>
> So only new implementation is tested with these changes in test. Got it. May be use:
> `@requires vm.opt.final.UseVtableBasedCHA == true`

I'm fine with both approaches. 

Explicitly setting the flag looked to me more robust and clearer communicating the intent. But if you prefer `@requires`, I'll use it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From kvn at openjdk.java.net  Fri Apr 30 22:12:52 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 30 Apr 2021 22:12:52 GMT
Subject: RFR: 8266074: Vtable-based CHA implementation
In-Reply-To: <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com>
References: <i8s36noGsQhQEyMX7TwKydCZo65zxOiJL8dBgd3A5Ms=.baa80151-063e-4f09-b6f9-ef2782989b81@github.com>
 <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com>
 <jqGxb0ggg-MEk9RzN_0w8XyQEEVFqS9o8VwnNXC1AFM=.d3f4330e-aaa2-4c83-8832-9f0f7b416548@github.com>
 <JGLHRtT7a3fRS2dNxDAaq0G4bGhLMvszHzH9-jTBS-Q=.146dfa8d-ff45-4f9b-8316-4bcee5be01ef@github.com>
 <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com>
Message-ID: <Q0UuO-Jq1sXd1_AKqvGSeFL13-QgFEx_ArOtUjUlwZc=.718a1d6e-282e-4ac4-a6c2-9fb77af44b58@github.com>

On Fri, 30 Apr 2021 22:03:11 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> So only new implementation is tested with these changes in test. Got it. May be use:
>> `@requires vm.opt.final.UseVtableBasedCHA == true`
>
> I'm fine with both approaches. 
> 
> Explicitly setting the flag looked to me more robust and clearer communicating the intent. But if you prefer `@requires`, I'll use it.

Let hear @iignatev opinion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3727

From vlivanov at openjdk.java.net  Fri Apr 30 22:19:49 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 30 Apr 2021 22:19:49 GMT
Subject: RFR: 8266328: C2: Remove InlineWarmCalls
In-Reply-To: <hWRsELCx7_oNek3k00sxUIVN2afL0xKEBZU3TQWc2us=.f3b441f7-261f-4f6a-896f-2ae908cdbbf2@github.com>
References: <hWRsELCx7_oNek3k00sxUIVN2afL0xKEBZU3TQWc2us=.f3b441f7-261f-4f6a-896f-2ae908cdbbf2@github.com>
Message-ID: <dmOIi37RAQhy0f_dVq9d_lgQcQSNdcgUAA-csLa4R4M=.2b670971-58ad-42e7-853b-6dbe85c6999a@github.com>

On Thu, 29 Apr 2021 21:46:36 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Remove InlineWarmCalls and all relevant code.
> 
> It was introduced long time ago and didn't get much attention since then. I don't see any value in keeping it around.
> And there's incremental inlining support in C2 now.
> 
> Testing:
> - [x] hs-tier1 - hs-tier2

Thanks for the reviews, Vladimir and Igor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3805

From vlivanov at openjdk.java.net  Fri Apr 30 22:19:50 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 30 Apr 2021 22:19:50 GMT
Subject: Integrated: 8266328: C2: Remove InlineWarmCalls
In-Reply-To: <hWRsELCx7_oNek3k00sxUIVN2afL0xKEBZU3TQWc2us=.f3b441f7-261f-4f6a-896f-2ae908cdbbf2@github.com>
References: <hWRsELCx7_oNek3k00sxUIVN2afL0xKEBZU3TQWc2us=.f3b441f7-261f-4f6a-896f-2ae908cdbbf2@github.com>
Message-ID: <DMoQl1BBhlgQxVn9z6WkGTv7duhzOUOxRrhz2Kpn1uw=.df392117-48d5-416c-b12d-85e3753824a1@github.com>

On Thu, 29 Apr 2021 21:46:36 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Remove InlineWarmCalls and all relevant code.
> 
> It was introduced long time ago and didn't get much attention since then. I don't see any value in keeping it around.
> And there's incremental inlining support in C2 now.
> 
> Testing:
> - [x] hs-tier1 - hs-tier2

This pull request has now been integrated.

Changeset: f86b70c3
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f86b70c391c2909676a7d9821b7367269aa85206
Stats:     588 lines in 8 files changed: 6 ins; 560 del; 22 mod

8266328: C2: Remove InlineWarmCalls

Reviewed-by: kvn, iveresov

-------------

PR: https://git.openjdk.java.net/jdk/pull/3805

From psandoz at openjdk.java.net  Fri Apr 30 23:37:52 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Apr 2021 23:37:52 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <-VJVRq98DoOIRYPdSB8b2k1oOAI2vHeyKgo00bvGbSE=.00ef20ca-d072-4426-9e8e-c0e5433d3440@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
 <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
 <-VJVRq98DoOIRYPdSB8b2k1oOAI2vHeyKgo00bvGbSE=.00ef20ca-d072-4426-9e8e-c0e5433d3440@github.com>
Message-ID: <ysTwtqvI0ilgSba2hO4nQgOaY6fFgIsQO6B6UNompEs=.425c083f-60de-418b-ac14-a59ca3fc1535@github.com>

On Fri, 30 Apr 2021 17:44:38 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > @PaulSandoz would it be possible for you to run this through your testing?
> 
> Started, will report back when done.

Tier 1 to 3 tests all pass on build profiles linux-x64 linux-aarch64 macosx-x64 windows-x64

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804

From sviswanathan at openjdk.java.net  Fri Apr 30 23:47:52 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 30 Apr 2021 23:47:52 GMT
Subject: RFR: 8265128: [REDO] Optimize Vector API slice and unslice
 operations [v3]
In-Reply-To: <ysTwtqvI0ilgSba2hO4nQgOaY6fFgIsQO6B6UNompEs=.425c083f-60de-418b-ac14-a59ca3fc1535@github.com>
References: <RI6Qj7oscg1x0S5xjNQR0_aWQJeb2BEih8VNT5cxMYc=.a28da1df-4153-4127-8183-ed2d0c81c585@github.com>
 <rGj78liV9B_dy7q_AqHkY19fnm0dzuMC2dVrdaMTgX0=.42d2a648-6f4b-4b8e-80c8-28b65693a557@github.com>
 <oMk-JOlRY4BHHx67VqzQ6ZXcQXt7xdBC3L5lh2i-v58=.ce652670-6ece-4c3d-a0d5-83090db71293@github.com>
 <-VJVRq98DoOIRYPdSB8b2k1oOAI2vHeyKgo00bvGbSE=.00ef20ca-d072-4426-9e8e-c0e5433d3440@github.com>
 <ysTwtqvI0ilgSba2hO4nQgOaY6fFgIsQO6B6UNompEs=.425c083f-60de-418b-ac14-a59ca3fc1535@github.com>
Message-ID: <9rAKGIqXwGbYSc5i6a7t7Rgbdleyv1EBNvzJwU84GWc=.f64d2522-0576-43ac-8c32-ca748f8f83c5@github.com>

On Fri, 30 Apr 2021 23:34:15 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > > @PaulSandoz would it be possible for you to run this through your testing?
> > 
> > 
> > Started, will report back when done.
> 
> Tier 1 to 3 tests all pass on build profiles linux-x64 linux-aarch64 macosx-x64 windows-x64

@PaulSandoz Thanks a lot!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3804